2010-03-26

Vad är det där "Simple Mode" egentligen i MS SQL?

Denna återknyter lite till posten igår... :)
Just recovery mode är ett problem för många. Vad är det för skillnader egentligen mellan Full och Simple mode? Så här kommer lite tankar kring Simple mode för database...

Om du sätter den till simple så kommer transaktionsloggen bara att användas för den senaste transaktionen. Med andra ord så behöver den bara vara så stor att den största transaktionen som körs mot databasen får plats i den.



Det blir typ så här (hyffsat förenklat):
  • En uppdatering skall göras i databasen. I detta exempel vill vi skicka en faktura. Det innebär att vi både vill markera fakturan som fakturerad i FAKTURERINGS-tabellen, men även i tabellen LAGER så skall allting som kunden har köpt dras bort från lagersaldot. Det är alltså två olika tabeller som skall uppdateras med olika information. Dessa två uppdateringar buntar vi ihop till en så kallad "transaktion". 
  • SQL server tar reda på vilka rader som skall uppdateras och skriver i transaktionsloggen vad de nya värderna skall bli. Observera att det inte ändras i databasen, istället hamnar det i transaktionsloggen. 
  • När transaktionen är skriven på hårddisk i transaktionsloggen så markeras transaktionen som lyckad. EFtersom det gick bra så tar nu MS SQL och skriver in värdena i databasen (alla som skall uppdateras). 
  • När uppdateringen i databasfilerna är skrivna på disk så markeras transaktionen i transaktionsloggen som klar 
  • Transaktionen är nu OK att skrivas över i transaktionsloggen.
Om man kör FULL-mode på transaktionsloggen så sker inte sista steget ovan. Istället sparas alla transaktioner som en enda lång historik. Fördelen med detta är att om man behöver göra en restore från en gammal backup så kan man därefter "spela upp" transaktionsloggen en transaktion i taget och göra alla uppdateringar som behövs i databasen för att därefter ha all data intakt.

Det är alltså därför som en transaktionslogg som är ställd i FULL-mode kan bli JÄTTESTOR. Den innehåller ju ALLA transaktioner som gjorts mot databasen.


En transaktionslogg som är ställd som SIMPLE-mode blir däremot bara så stor som den största transaktionen som körs mot databasen blir.



Fråga: OK, men varför är då transaktionsloggen fortfarande stor om man har ställd den som SIMPLE-mode? Varför krymper den inte?
Jo, för att ibland vill man ha en transaktionslogg i SIMPLE-mode men ändå ha en stor fil. Exempelvis om man vet att varje natt så kör en JÄTTEtransaktion. för att då slippa att SQL skall behöva allokera en massa disk (vilket suger MASSOR med disk I/O och alltså tar en massa prestanda när den försöker utöka transaktionsloggen) så kan man ibland vilja ha en stor transaktionslogg.

Fråga: Men om jag har en databas som är ställd som SIMPLE-mode och den är jättestor, hur gör jag om jag vill ha den mindre?
Det är nu man behöver köra en shrink på databasen. Detta går utmärkt att göra antingen med SQL-kommandon eller från GUIt. VIlket man väljer är en smaksak.

Fråga: Om det nu är så att en transaktionslogg som är ställd som FULL-mode alltid bara fylls på.... hur gör jag för att den inte skall bli hur stor som helst?
Tanken med att ha en transaktionslogg i FULL-mode är ju att kunna göra en "point-in-time" restore. Alltså att från en full-backup av en databas kunna lägga in alla uppdateringar fram till en viss tidpunkt (oftast fram till precis innan problemet uppstod).

Vad man behöver är alltså en fullbackup av databasen. Dock räcker inte detta (Det är här de flesta gör fel och det är därför detta är en av de absolut vanligaste frågorna som jag får när det gäller MS SQL!)

Det räcker inte med att göra en fullbackup av databasen. Man måste även göra en transaktionslogg-backup. Det är först då som alla transaktionerna markeras om överskrivningsbara. Om man alltså gör en fullbackup på databasen och sedan gör en backup på transaktionsloggen så kommer all information som finns i transaktionsloggen att vara markerat som inaktiv. Det är detta som kallas att "Trunkera transkationsloggen". Det sker alltså när man gör en backup på transkationsloggfilen.

Om man direkt efter detta kör en Shrink på transaktionsloggen så kommer den nu att krympa.

Exakt hur mycket den kommer att krympa beror på hur stor transaktionsloggen i MODEL-databasen är (en transaktionslogg kan aldrig krympa under storleken på transaktionloggen för MODEL-databasen). Det beror även på om det fortfarande finns nya transaktionser i transaktionsloggen och vart dessa är skrivna i filen. Om de nya transaktionerna är skrivna i börja på filen så kan alla trunkerade transaktioner från slutet av filen och fram till sista aktiva transaktions-"entryt" raderas. Om det är så att de aktiva transaktionerna finns mitt i transaktionsloggen med trunkerade transaktioner före och efter de aktiva så kommer fortfarande bara de trunkerade transaktioner från slutet av filen och fram till sista aktiva transaktions-"entryt" raderas. Inte de som är från början av filen fram till den första aktiva transaktionen... För att få detta att ske så måste man typ "defagmentera" transaktionsloggen så att alla nya transaktioner hamnar först.

Hur man gör detta är jag alldeles för trött för att gå in på just nu, men ett sätt är att sätta databasen som SIMPLE-mode => Krympa filen => Ställa tillbaka till FULL-mode. Dock skall man vara medveten om att om man gör på det sättet så har man förstört möjligheten att göra "point-in-time" restore fram tills dess att man gör en ny full-backup på databas-filen... (lite överkurs här tror jag)...

Inga kommentarer:

Skicka en kommentar

Related Posts Plugin for WordPress, Blogger...