10. december 2003 - 10:39Der er
12 kommentarer og 2 løsninger
Pladsforbrug i forb. m. sletning og oprettelse
Jeg har en MS SQL Server database, med 100.000+ posteringer. Jeg har hidtil valgt at TRUNCATE hele tabellen og så lave en INSERT påny, for på den måde at få lagt nye informationer ind. Det bliver imidlertid meget omstændigt når det drejer sig om måske en kvart million posteringer. Jeg vil derfor gerne nøjes med at lave en opdatering af kun det nyeste. Problemet her er så:
Jeg har ikke en fortløbende primærnøgle, og den sammensatte primærnøgle er for svær at gennemskue til, at den kan bruges til sammenligning. Tilbage har jeg så en posteringsdato, som jeg har tænkt mig at bruge således:
Jeg overfører data fra dags dato og 30 dage tilbage. Disse data skal så lægges ind i databasen. Nogle af disse data er helt nye, og eksisterer således ikke i databasen. Andre data er allerede i databasen, og skal derfor ikke oprettes. De 30 dage er en slags sikkerhedsmargen der skal til, for at være sikker på, at jeg får alle posteringer med. Problemet er så, at jeg ikke kan bruge en UPDATE INTO, da den ikke opretter nye poster, hvis ikke de eksisterer i forvejen. Den opdaterer jo kun de eksisterende. Jeg kan heller ikke bruge INSERT INTO hvis der i forvejen er et felt med samme navn. Så jeg burde egentlig have en slags mellemting, der laver en UPDATE hvis feltet allerede eksisterer, og en INSERT hvis dette ikke er tilfældet. Denne funktionalitet eksisterer så vidt jeg ved ikke. Hvis den gør, hører jeg gerne fra jer.
Mit forslag til løsningen er så:
Jeg sletter alt i databasen fra dags dato og 30 dage tilbage. Derefter indsætter jeg de data jeg har hentet (som jo også er fra dags dato og 30 dage tilbage). På den måde er jeg sikker på, at alt der var i databasen i forvejen stadig er der, samt at de nye data også er blevet opdateret. Problemet her er så måske, og det er det jeg søger endegyldigt svar på:
Vil der, såfremt jeg sletter 100-400 poster hver dag, og genoprettet 120-500 poster igen - nogle med samme feltværdier og delt primærnøgle, være meget spildplads? Jeg har set, at der er dette problem i Access, hvor man skal lave en manuel "oprydning". Gør SQL-Server selv det? Jeg har jo ikke noget fortløbende autonummer.
Denne side indeholder artikler med forskellige perspektiver på Identity & Access Management i private og offentlige organisationer. Artiklerne behandler aktuelle IAM-emner og leveres af producenter, rådgivere og implementeringspartnere.
Du kan være nød til at køre en DBCC INDEXDEFRAG en gang i mellem for at defragmentere dine index / tabeller, men du skal ikke være bekymret for spildplads.
Du skal tilg engæld være opmærksom på din logfil. Er basen sat til Simple Recovery Model (truncate log) er der ikke noget problem, men ved Full Recovery Model skal du sørge for at der tages backup.
Med simple recovery model skal der "blot" være plads til en transaktion i loggen (den største forekommende), mens der med full recovery model skal være plads til samtlige transaktioner der kan forekomme indenfor et backup interval.
Hvis du kører med Full Recovery Model og en automatisk voksende log og ingen backup - så vil din log før eller siden fylde disken op; Det vil crashe din database og du vil have svært ved at få basen op at køre igen.
Hvordan kan jeg se, hvilken recovery model jeg benytter? Hvordan ved jeg, om den backup der er foretaget så har renset loggen? Er der en automatisk backup-funktion i sql-server? Det er fordi, at vi har en ekstern server til at køre vores sql-server. Mon ikke de laver backup? Og tror du i så fald, at de renser loggen? Håber I kan svare...
idle er her ikke ment som en tilstand hvor der intet sker. Men bare at loaded er mindre. Algoritmen i detaljer har jeg aldrig fundet.
I den online dokumentation der følger med en sql server er der masser af læsestof omkring dette.
Men efter nogen års erfaring kan jeg fortælle dig om nogle oplevelser, hvis du indsætter mange(læse 1M + rekords) hvorefter du begynder at forespørge på de samme dataer kan du være udsat for at databasen ned priotere dine forspørgelser. Eller eks. har jeg en aften sloges med en langsom database hvor jeg lidt uforstået undres, tager hjem for at sove på problemet, og dagen efter er problemet væk :)
Ok. Lyder underligt. Men hvad vil du foreslå jeg gør? Er løsningen groft set, at slette data for de sidste 30 dage, og så genoprette de samme data + de nye? Eller er der en smartere måde? (den der UPDATE/INSERT kombination jeg nævnte).
DBCC INDEXDEFRAG skal (bør) køres via Query Analyzer - men du skal have SysAdmin privilegier for at afvikle den (mener ikke at DBO er nok).
Jeg ville ikke kalde en DBCC kommando fra et normalt program;
INDEXDEFRAG skal kun køres når en DBCC SHOWCONTIG viser en høj fragmentation - det afhænger ganske af aktiviteten; Vi har baser hvor vi aldrig bekymrer os om en INDEXDEFRAg - andre hvor vi gør det hver 2-3 måned.
Via Enterprise Mgr kan du i øvrigt sætte en maintaince plan op for en base - der kan du vælge defragmentering.
Og ganske rigtigt - Defragmenteringen har intet at gøre med backup.
TAk for hjælpen gutter. Og hurtig service må man sige!
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.