15. april 2010 - 14:15Der er
33 kommentarer og 1 løsning
Transaction log
Hej, Har siddet og kigget på andre svar, men stiller alligevel spørgsmål for at være helt sikker :-)
Jeg har en database i en sql server 2005, og selve databasen (backupen; *.bak) fylder 5 GB. Min transaction log der i mod fylder 80 GB!!!!! Det er ret problematisk nu!
Jeg tager normal full backup 3 gange om dagen.
Nogen der gider at skrive en meget beskrivende guide til hvordan jeg kan gøre loggen mindre?
Jeg kan næsten regne ud at siden du har en full backup 3 gange om ugen er det vigtigt for dig at bevare data, derfor har man en transactionslog :) Dvs. du kan vha. denne restore til et point in time imellem dine fulde backups.
En god tommelfingerregel siger at transactionsloggen ca. fylder 10% af databasen, men hvis man har mange transactioner kan det naturligvis godt ændre sig.
Dvs. back din transactionlog up, evt. blot en truncate nu når den er så stor. Sæt transactionlog size til 1 GB og opsæt et schedule for at backe den op, gerne hver time, den fylder ikke særligt meget :)
Husk at bruge DBCC SHIRNKDATABASE [database] efter at der er blevet taget backup af loggen (ellers vil den stadig fylde meget).
Hvis der ikke er plads til at tage backup af loggen (i den størrelsesorden den er på nu), kan du nøjes med følgende kommando BACKUP LOG [database] WITH TRUNCATE_ONLY. Herefter skal du stadig huske DBCC SHIRNKDATABASE [database].
Hvis du ikke umiddelbart har brug for transactionsloggen, kan du med fordel sætte databasens recovery model til SIMPEL og evt. benytte AUTOSHRINK.
Er der noget til hinder for at du kan sætte databasens "Recovery Mode" til Simple? Er det kritiske data? Kun hvis du vil kunne genskabe databasen udfra log-filen er det nødvendigt. Med en backup er du godt hjulpet i forvejen. Desuden kører det meget hurtigere i "simple mode".
Det hele kan gøres via GUI'en. Under database properties kan du sætte recovery model til simpel (hvilket automatisk trunkerer loggen), herefter kan du højreklikke på databasen, vælge shrink og herefter din logfil.
Det burde minske din log med ca. 95%.
Med simple recovery model kan du evt. vælge at sætte autoshrink til enable på databsen. Dette kan også gøres via properties. Alternativt kan du køre en dbcc shrinkfile('logfil',1) som en del af dit backupjob (så er det kontrolleret). (hvis du ikke shrinker din db, så vil den vokse sig stor igen).
janus_007: Når nu du gokker mig oven i hovedet vil jeg høre hvorfor jeg så oplever, at mit program netop kører hurtigere de steder hvor databasen er sat til "simple". Logisk set bør en simple-model betyde at der skal laves meget mindre i databasen, hvilket igen logisk må betyde at det går hurtigere. Du mangler at overbevise mig om, at det er en gangbar løsning de steder hvor man laver regelmæssig backup - og jeg vil gerne du gør et forsøg.
Jeg skal ikke betvivle din kompetance, du kan givetvis din T-SQL m.m., men den bombastiske udokumenterede nedrakning har jeg svært ved at ignorere.
Jeg ville nu ikke gokke dig i hovedet ;) (nærmere try-nerd som kommer med fejlagtige informationer som kan medføre problemer)
Om man kører med en recoverymodel simple, bulk eller full, betyder blot hvordan transactionerne opbevares, ikke om de indsættes i transactionsloggen. Ved en simple model, skal der en backgrund proces til at slette de transactioner igen, hvorimod ved en full er det dig selv der bestemmer hvornår de slettes. Og derved vil performance være bedre :)
Regelmæssig full backup; en full backup låser for inserts/ updates imens den kører, ved store datafiler er det ikke så smart, derfor kører man små lette transactionslog backups der ikke blokerer for noget. Og udskyder de "store" full backup til andre tidspunkter hvor man har et bedre maintenancevindue.
Så vil nogen sikkert påstå at man jo bare kan lave en backup kl. 3 om natten, og ja det kan man da godt (hvis man kan nå det), men at lave en full backup hver 3. time har altid været uskik og bør hurtigst muligt erstattes af en transactionslog backup, det er derfor den er der :) Et betalingssite hvor VISA-betalinger og lign. skal gemmes, og forudsat man har mere end en betalende kunde om dagen, ja der skal man ikke til at fedte rundt med full backup, men arbejde med små nemme transactionslogs backup sådan at man kan restore til op til hvor det gik galt.
janus: Godt med lidt uddybning. Dit argument giver mening. Man udskyder dog kun belastningen, til et tidspunkt hvor det ikke mærkes.
Jeg har lavet en del databasekonverteringer i forb. mit program og transaktionsfilen voksede til groteske proportioner - og gav fejl når den ikke kunne blive større. I Simple mode var konverteringerne dobbelt så hurtige.
Du mangler dog lige at fortælle hvorfor man ikke skal køre "DBCC SHIRNKDATABASE" - det er det samme Management Studio gør og der vælter man ikke rundt i advarsler. Jeg plejer, try-nerd som du lidet flatterende kaldte mig, at "shrinke" før jeg laver en backup for så fyldte den ikke noget. Det kan jeg snildt gøre da der ikke er brugere på mine databaser. Hvorfor kan man, ude i den rigtige verden, ikke trunkere efter backuppen (scenarium: kunderne arbejder ikke om natten)?
try-nerd (det gjorde virkelig ondt)! Jeg er programmør (nudansk: systems developer), ikke database-administrator af andet end behov - men jeg lærer hele tiden.
Shrink db deallokerer diskspace, dvs. når databasen så skal bruge pladsen igen skal den til at allokere det. Hvis denne allokering sker midt under en operation af en art vil alle processer bliver påvirket af dette utidige disk IO for allokeringen. Det er den ene årsag, den anden og fuldt ud lige så slemme er at jo flere allokeringer du kører jo flere fragmenter vil din databasefiler ligge i og som bekendt så skal læse/ skrive hovedet derved bevæge sig endnu mere. Det gælder mest ved transactionlog fordi denne er sekvential, mindre ved datafiler (random read/ writes), undtagen på det clustered index! Dvs. "just read where..." fra table vil være langsommere ved høj filefragmentation.
"Jeg har lavet en del databasekonverteringer i forb. mit program og transaktionsfilen voksede til groteske proportioner - og gav fejl når den ikke kunne blive større." - Det sker kun fordi den ikke backes up undervejs :). Typisk vil man bulke data ind og derved mindske transactionslogforbruget.
"Hvorfor kan man, ude i den rigtige verden, ikke trunkere efter backuppen (scenarium: kunderne arbejder ikke om natten)?" - Du kan godt truncate, men så invaliderer du dine andre transactionslogbackups. Dvs. når du blot truncater så svarer det til simple, men mere tidsbestemt om man vil + man stadig har mulighed for at redde noget "if something skrews up" :)
"Man udskyder dog kun belastningen, til et tidspunkt hvor det ikke mærkes." - Det har du ret i, men som altid skal man sørge for at holde et lille maintenancevindue åbent, dels til backup, men også ligeså meget til indexrebuild mv.
Nu skal du tænke på at jeg kommer fra nogle monsterbaser og sikkert deraf er jeg farvet og intolerant overfor "det går nok" *GG*. Men man bør alligevel overveje konsekvensen af det man gør på små setups :)
Man lærer af de bedste (når de forklarer sig ... :-)). Tak, jeg vil revidere min opfattelse mht. recovery mode - og undskyld jeg ytrede min spæde røst på fora.
Nu har jeg prøvet at højre klikke på databasen og vælge backup. Her har jeg sat den til transactionlog. Størrelsen af transactionen loggen ændre sig ikke :-(
Er det fordi at jeg ikke har sat databasen til simple eller skal jeg bruge den der hedder shrink og derefter filer? :-s pft
Lige hvad du skal gøre er jo svært at sige, men som jeg hører det så har du brug for en backup plan hvor data bevares bedst muligt og derved har et system hvor datasikkerhed er i fokus. Når det er sådan noget vil jeg anbefale at du laver transactionslog backup evt. hver time og kører med fuld backup en gang i døgnet evt. om natten hvor belastningen er mindst.
Som tidligere nævnt så vil en transactionslog ikke fylde specielt meget.
Ja altså du skal jo vide at når du ikke tidligere har lavet transactionslog backup så har din log vokset sig stor.
Dvs. her initielt, gør flg:
alter database <databasename> set recovery simple dbcc schrinkfile(<TransactionLogName>, 1000) --20% af 5 gb alter database <databasename> set recovery full
Nu er du klar til at opsætte en backup plan, og hvis du så tager transactionslog backup jævnlig vil du se at den ikke vokser :)
Ja der sker ikke noget med data, det vigtige er bare at du skal opbevare både den fulde backup + de transactionslogs som du har taget for at restore til "point in time"
Eks. F = Fuld Backup T = Transactionslog Backup
Dag 1: F, T, T, T, T Dag 2: T, T, T, T, T Dag 3: F, T, T, T, T Dag 4: F, T, T, T og BUUUMMMMMM noget skete
Hvis du så vil restore frem til BUM så skal du bruge fuld backup fra Dag 4 alle 3 transactionlogs! Hvis du vil restore frem til og med Dag 3, skal du bruge den fulde fra Dag 3 + T, T, T, T eller kun bruge Dag 4, fuld backup( det kommer an på hvilket tidspunkt du vil frem til og hvad du lige finder nemmest)
Det kommer an på om du kan leve med de data du kan miste?
3 backup hver dag, svarer til 1 hver 8.time, dvs. du kan miste 8 timers data i værste fald + låse dine brugere for inserts og updates. Hvis det er ok, så skal du fortsætte med det og sætte din recovery model til simple, men hvis du gerne vil have data mere sikkert og tilgængeligt, ja evt. hver time, så bør du tage transactions log backup :)
Jeg har lavet systemer hvor der skulle kører transactions log backup hver 15. min, alt afhængig af hvad hw-setup man kører med er der forskellige løsninger og priser :)
Sikke dog en masse meninger om noget der ligger helt fast:
Først Forskellen på simpel og full.
Hvis du kører simple kan du i tilfælde at katastofe kun restore din database fra en full backup. Som man normalt kun tager en gang i døgnet. En full backup er backup af hele databasen og tager lang tid og fylder meget. Dette er velegnet til forholdvis statiske databaser eller IKKE mission critical databaser.
I alle andre tilfæde bør man køre full mode. Her tages f.eks. een full backup i døgnet og transaktionslogs 1 gang i timen. Man kan nu restore til sidste transaktionslogbackup og risikerer således kun at miste en times data. Det siger sig selv at hvis man aldrig har taget transaktionslog backup før vil den være meget stor første gang og i det tilfælde vil det være på sin plads at shinke tranktionloggen (og kun den - shrink files) een og kun en gang efterfølgende. Herefter vil transaktionsloggene være små hver time og backuppen gå lynhurtigt. Herefter vil transktionsloggen vokse en smule til sit naturlige leje afhængig af hvor mange ændringer der laves i DB. Det hjælper ikke at shrinke ustandseligt da loggen vil vokse igen. Lad endelig være med at shinke databasen medmindre der er alvorlige pladsproblemer - det er kendt sag at data ikke nødvendigvis kommer til at ligge hensigtmæssigt internt i database filer efter database shink og dette kan medføre performance degradring.
Med hensyn til at simpel skulle være meget hurtigere en full. Simple virker på den måde at når loggen er 70% full vil SQL server committe ændringer til database filerne og dermed frigøre plads i logger. Heraf følger at hvis man enten har for lille logfile eller for stor transaktionsmængde i forhold til logge vil SQL server udføre en masse housekeeping som ikke gavner performance.
Herefter Forskellen på Data og log filer. SQL server skriver altid en transaktion i logfilen først og først når den får besked fra filsystemet at loggen er skrevet med succes kan den fortsætte. Data pages holdes ofte i memory længe og skrives først til disk når der er tid eller når der mangler memory.
Heraf følger.
1. Placer altid logfiler på dine hurtigste diske - gerne raid 1.
2. Data filer er mindre kritiske og kan om nødvendig lægges på langsommere diske
3. Log filerne er GULDET. Det er dem SQLserver bruger til at genskabe databasen og tilfælde af strømmen f.eks. går.
En sidste ting. Backup er en ONLINE handling og hindrer principielt ikke brugerne i at bruge databasen - hverken full backup eller transaktionslog backup. Dog kan den forøgede mængde IO sløve ned. Derfor er mange små transaktionslogbackups i dagtimerne at foretrække fremfor store FULL backups i dagtimerne. Man skal dog være opmærksom på at overdrevet mange transaktionslogbackups kan gøre et restore scenario langsomt. Og HUSK at backups skal IKKE ligge på SQL serveren. Så er man fucked i tilfælde af diskcrash.
Der er principielt ikke mange meninger om sagen. Jeg mente bare at en daglig backup var nok i mit tilfælde. Det sammenholdt med gentagne fulde logfiler (skulle have brugt bulk-mode) og dårlig ydelse, fik mig til at sige det unævnelige "simple mode".
Med gode forklaringer viste Janus og Arne mig lyset - og nu er du også kommet med en god en. Jeg takker mange gange og det er endda ikke mit spørgsmål.
Ja HRC - det bekræfter til fulde hvad jeg sagde om shink af databaser. Det er en nødløsning
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.
Ny bruger
Nybegynder
Opret
Preview
