Mattias Lind är en konsult inom it-branschen. Jag är specialiserad på Microsoft SQL Server, infrastruktur, kommunikation och säkerhet.

Välkommen!

Jag driver ett eget litet företag, Fandes Sverige AB, som levererar driftstöd, optimering av databaslösningar, utbildning genom partner, Informator, och mycket mer. Jag har arbetat som konsult sedan 1992 och drivit egen verksamhet sedan 2002.

En av mina passioner är westernskytte. De som känner mig har säkert hört detta till leda. Westernskytte i Sverige drivs genom Sweden Western Shooters. Skytteformen kallas Cowboy Action Shooting, och är som namnet antyder fyllt av Action. Man skjuter tidstypiska westernvapen, i tidstypiska kläder, i scenarier och resultatet räknas i förbrukad tid med tidstillägg för missar och procedurfel. 2006 var året jag fick mitt första SM-guld i kategorin Gunfighter, man skjuter med en revolver i vardera hand.

tisdag 24 april 2007

Ring en vän...

Då är jag äntligen tillbaka i verkligheten efter intensivt jobbande.

Jag fick ett samtal idag från en kollega i branschen, jag ringde tillbaka och hamnade som vanligt när man jagar varandra på mobilsvaret. Efter ett sluddrigt svar på frågan kom jag på att det finns nog fler som behöver flytta på databaserna på sin Microsoft SQL Server av allehanda olika anledningar.

Först en liten refresh. Din databas består av några filer i filsystemet; minst två stycken; datafiler och logfiler. Datafilerna har oftast en filändelse .mdf och/eller .ndf, Master/Numerous Data File, det är dessa som är det faktiska datat i databasen lagras. Dessa filer grupperas logiskt i databasen med filgrupper för att ge oss en möjlighet att fördela tabelldata på flera fysiska och adresserbara lagringspunkter. Ett förfarande som möjliggör parallellism i databasen, t ex traversering av index samtidigt som data börjar att returneras från tabellen. Ja, det finns många anledningar till att låta databasen bestå av flera fysiska filer associerade till flera filgrupper.

Databasen består även av logfiler; transaktionsloggen; vilka brukar ges filändelsen .ldf, Log Data File. Syftet med transaktionsloggen är att säkerställa förändringar i databasen. Logfilerna placeras med fördel på andra fysiska lagringsenheter separerade från datafilerna.

Vid förändring av data läses datasidor från datafilen upp i RAM-minne på databasservern de sedan förändras för att därefter dokumenteras i logfilen. När hela transaktionens berörda datasidor är förändrade finns de lagrade i logfilen i en så kallad transaktion, antingen markerade för COMMIT eller för ROLLBACK. Logfilen läses på ett återkommande schema, CHECKPOINT, vilket vid inträffande genomför skrivning av COMMITade datasidor till datafilen. Detta gör att vid förändring av data läses datasidor sporadiskt från datafilen och skrivs likväl sporadiskt till logfilen, samt att vid CHECKPOINT läses logfilen sekvensiellt samtidigt som det skrivs till datafilen. Detta gör att man med fördel skall fysiskt separera datafiler från logfiler. Logfilen läses även vid uppstart av databasserver samt vid montering av databaser för att säkerställa skrivning av COMMITade datasidor i datafilen.

Nu kan man konfigurera databasen i olika RECOVERY-lägen; SIMPLE, BULK_LOGGED och FULL. Där SIMPLE betyder att logfilen töms vid CHECKPOINT på COMMITade och ROLLBACKade transaktioner om skrivning till datafilen lyckas. Och där FULL betyder att logfilen inte töms automatiskt utam man blir tvungen att manuellt (går att automatisera) måste tömma logfilen. Man kan märka detta genom att databasens logfil konstant växer samt att den är större än datafilen, dvs inte bara är större utan även att dess nyttjande växer. Logfilen växer för alla transaktioner som påverkar datasidor i datafilen, även om man gör BULK-operationer. Såtillvida man inte konfigurerat databasen i BULK_LOGGED-läge, där BULK-operationer flaggas för att säkerställa att eventuella ytterligare transaktionslog-backuper tas och att övriga transaktioner loggas på samma sätt som i FULL-läge.

Ok, tänker ni. Hur gör man då? Från början kan jag bara säga att man gör rätt på en gång, dvs fysiskt separerar dessa filer redan vid databasens skapande. Ok, om man nu inte gjort rätt från början. Hur ska man göra då? Nu kommer vi till frågan jag fick. De som känner mig vet att jag gärna ger ett fullständigt och uttömmande svar närhelst jag har chansen. Och så även denna gången!

För att flytta datafiler och logfiler på en befintlig databas!
Givetvis förutsätter jag att Ni tar en fullständig backup på databasen innan Ni gör någonting överhuvudtaget! Inget ansvar tas från min sida.
Grafiskt, med antingen Enterprise Manager eller Management Studio, kan du högerklicka på databasen och välja DETACH DATABASE. Då kommer databasen kopplas loss från databasservern och med ens bli otillgänglig, det får inte vara någon ansluten mot databasen då det inte går att koppla loss den annars. Därefter flyttar du både datafiler och logfiler till de fysiska lagringsenheter du önskar, notera sökvägarna noga. Efter flytt eller kopiering av datafiler och logfiler högerklickar du på Databases och väljer ATTACH DATABASE, anger sökvägarna till både datafiler och logfiler. Nu är det klart! Det går även att göra med T-SQL och då genom att köra procedurerna sp_detach_db och sp_attach_db. Kolla i Books Online efter syntaxbeskrivning, där finns färdiga exempel.

Tänk på att det finns fler databaser än bara dina egna databaser på databasservern. Du har även en uppsättning med systemdatabaser värda omtanke. Master placerar du på ett säkert och redundant disksubsystem, Model används som "mall" för alla databaser du skapar och är lätt att återskapa, MSDB som innehåller alla databsjobb, schemaläggningar med mera och bör säkerställas, TempDB som används för alla temporära objekt och bör ligga på ett snabbt disksubsystem gärna anpassad i storlek för de behov din databasserver behöver. Tips om detta hittar du i Books Online och via detta White Paper.

Lycka till!
Mattias