Avatar billede lingo Nybegynder
15. april 2010 - 14:15 Der 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?

takker mange gange
Joachim
Avatar billede janus_007 Nybegynder
15. april 2010 - 14:38 #1
Tag backup af din tranactionslog ligeledes!

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 :)

Skriv hvis du behøver mere hjælp.
Avatar billede lingo Nybegynder
15. april 2010 - 14:55 #2
Databasen bliver brugt konstant temmeligt heftigt.

Kan jeg køre backup af transaction log mens den fungerer fuldt funktionel for brugere?

Udførelse:
Højre mus på databasen -> TASK -> Backup -> backup transction log.
rigtigt?


Hvis nu noget går galt med transaction loggen, kan jeg så bare restore fra min fulde backup?


pft
Avatar billede try-nerd Nybegynder
15. april 2010 - 15:01 #3
Hej Lingo

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.

Håber det kan bruges.
Avatar billede try-nerd Nybegynder
15. april 2010 - 15:04 #4
Rettelse: det er selvfølgelig DBCC SHRINKDATABASE [database]

Du kan sagtens lave backuppen mens databasen er kørende.
Avatar billede lingo Nybegynder
15. april 2010 - 15:10 #5
Vil det sige at jeg først laver backup af transactionlog således:

Udførelse:
1)Højre mus på databasen -> TASK -> Backup -> backup transction log.


Herefter åbner en query og skriver:
2)DBCC SHRINKDATABASE [kundedatabase]

og lige den sidste:
Hvis nu noget går galt med transaction loggen, kan jeg så bare restore fra min fulde backup? (dog med tabt transactionlog)

Tak :)
Avatar billede hrc Mester
15. april 2010 - 15:12 #6
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".
Avatar billede lingo Nybegynder
15. april 2010 - 15:18 #7
Umiddelbart genskaber jeg aldrig efter loggen, men har i stedet sat den til at lave full backup hver 3. time.


Vil det gøre tricket med simple?
og hvordan gøres dette?


pft
Avatar billede try-nerd Nybegynder
15. april 2010 - 16:37 #8
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).
Avatar billede janus_007 Nybegynder
15. april 2010 - 19:24 #9
Stop stop stop...

Kør aldrig DBCC SHIRNKDATABASE og jeg gentager ALDRIG DBCC SHIRNKDATABASE, slå heller aldrig transactionlog fra ved at slå til simple.

Hvad dælen er da det for nogle totalt latterlige råd at komme med? Du skal da nok få ødelagt den performance big time på den måde.

Kør en back transaction log som jeg skrev og vend tilbage :)
Avatar billede janus_007 Nybegynder
15. april 2010 - 19:27 #10
try-nerd-> (hvis du ikke shrinker din db, så vil den vokse sig stor igen). 

- Bullshit
Avatar billede janus_007 Nybegynder
15. april 2010 - 20:05 #11
Så også lige dene fra hrc "Desuden kører det meget hurtigere i "simple mode". "

- Nej, tværtimod!!
Avatar billede hrc Mester
15. april 2010 - 20:28 #12
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.
Avatar billede janus_007 Nybegynder
15. april 2010 - 21:53 #13
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.
Avatar billede hrc Mester
16. april 2010 - 10:40 #14
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.
Avatar billede janus_007 Nybegynder
16. april 2010 - 12:53 #15
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 :)
Avatar billede hrc Mester
16. april 2010 - 14:43 #16
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.
Avatar billede janus_007 Nybegynder
17. april 2010 - 14:25 #17
No problemo.. Jeg kan faktisk rigtigt godt li at forklare når nogen gider lytte :)
Avatar billede arne_v Ekspert
17. april 2010 - 22:06 #18
Man kan sagtens køre med recover mode simple.

Forudsat at man er ligeglad om man mister alle opdateringer siden sidste data backup.
Avatar billede janus_007 Nybegynder
18. april 2010 - 14:06 #19
Nåh da arne, godt set :-p
Avatar billede lingo Nybegynder
19. april 2010 - 11:08 #20
Puha... Jeg prøver lige at opsummere hvad jeg skal gøre her. Som sagt kører jeg full backup 3 gange om dagen, mens der arbejdes.

Janus 007, hvad siger du at jeg skal gøre? Gerne skrevet brugervenligt, da jeg som I andre ikke er haj i det her :-)
Avatar billede arne_v Ekspert
20. april 2010 - 02:08 #21
Min pointe er at der er ikke alle sammenhænge hvor recovery mode full er nødvendigt.

F.eks. ikke hvis alle opdateringer findes andet sted og kan reloades.
Avatar billede lingo Nybegynder
20. april 2010 - 10:01 #22
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
Avatar billede janus_007 Nybegynder
20. april 2010 - 10:06 #23
Hej lingo

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.
Avatar billede janus_007 Nybegynder
20. april 2010 - 10:14 #24
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 :)
Avatar billede lingo Nybegynder
20. april 2010 - 11:27 #25
okok...

Jeg har nu gjort som du skrev...
Det virkede.. :-)


Det er dog gjort på en backup database....

Er vi(dig ;-) ) sikre på at der ikke sker noget med data eller funktionalitet?


Hvis jeg indlæser backup fra i går, går jeg ud fra at transaction loggen er de 82 GB igen?


Send det gerne som svar, så du kan få dine fortjente point :-D
Avatar billede janus_007 Nybegynder
20. april 2010 - 15:56 #26
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)
Avatar billede lingo Nybegynder
20. april 2010 - 16:14 #27
Lige et ja/nej her til sidst for at sikre jeg forstår korrekt.

I teorien; nu tager jeg 3 fulde backups HVER dag. Jeg bruger aldrig transactionlogs til recovery, men mine fulde backups.

I det tilfælde er transactionslog backup fuldstændig ligegyldig ikke?
Avatar billede janus_007 Nybegynder
20. april 2010 - 18:12 #28
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 :)
Avatar billede lingo Nybegynder
21. april 2010 - 08:42 #29
Thx a lot...

Tror faktisk jeg har fået meget godt styr på emnet nu..

Tak for hjælpen og alle inputs :-)
Avatar billede jensriis Novice
26. april 2010 - 20:33 #30
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.

Mvh.
Jens Riis
MCTIP + MCTS i SQLserver 2008
Avatar billede hrc Mester
26. april 2010 - 22:43 #31
Fed tråd denne her.

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.
Avatar billede lingo Nybegynder
27. april 2010 - 08:24 #32
Jens Riis... ;-)

Tak for et super velskrevet overblik :-)
Avatar billede hrc Mester
09. november 2010 - 15:03 #33
Lige lidt opfølgning på det med at shrinke en database/fil

http://www.sqlservercentral.com/articles/SHRINKFILE/71414/
Avatar billede jensriis Novice
09. november 2010 - 16:03 #34
Ja HRC - det bekræfter til fulde hvad jeg sagde om shink af databaser.
Det er en nødløsning
Avatar billede Ny bruger Nybegynder

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.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester