2010-08-22

Är du en ofrivillig MS SQL Databasadministratör? (del 4)

Denna post är del 4 i en serie. Här är samtliga delar i denna serie:

del 1 - Data och Logfils hantering
del 2 - Index, Statistics
del 3 - Korrupt data
del 4 - Backupper
del 5- Sammanfattning

Igår handlade det om hur data kan "gå sönder" i tabeller eller indexar och hur vi kan upptäcka detta.
Idag handlar det om vad man måste ha på plats för att kunna återskapa informationen om man får korrupt data... En backup/restore rutin.
Det är förvånansvärt många företag som inte har koll på sina backupper. Detta trots att alla har tjatat om detta sedan urminnes tider. På mitt jobb tog vi fram ett gäng frågor gällande backupper (vi skrev en del erfarenheter och liknande) och på varje fråga kunde man svara "Ja det finns", "Nej det finns inte", "Inte applicerbart/behövs inte".

Jag inte ännu inte sett något företag som har svarat på alla dessa frågor utan att svara "Nej det finns inte" på någon fråga...
Vad säger detta? Att företagen är kass på att ta backupper? Nej, jag anser att det beror på att backup/restore är något ganska komplicerat.

Backup
I denna blogpost tänkte jag tala lite om backupper i MS SQL. Tyvärr räcker det dock inte alltid att säga att vi har allt som behövs bara för att databasen har en backup. Finns det backupper på anslutningssträngar (typ ODBC-kopplingar) till databaserna? Finns alla användarnamn och lösenord som används av olika applikationer dokumenterade? Finns det backupper på certifikat som används för att skydda nätverkstrafik? Finns det beroenden i applikationerna som i sin tur använder databaserna som gör att man måste göra på nått speciellt sätt (läs: exempelvis Sharepoint).

Många DBAer jag träffat förespråkar att använda den inbyggda backupfunktionen i MS SQL. Den funkar normalt så att man dumpar ut en backup till en fil någonstanns på en hårddisk. Denna hårddisk bör vara monterad i SQL-servern (alltså inte någott filshare som man ansluter mot). Det går dock att göra backup till en UNC-sökväg (typ file://filserver/SQLbackupper/) men det är inget som rekommenderas.
Det skall sägas att den inbyggda backuppen fungerar mycket bra. En nackdel är att man måste ha hårddiskplats tillgängligt för att lagra backupperna (som blir lika stora som databaserna...ungefär...). Från MS SQL 2008 Enterprise kan man göra komprimering av backuppen utan 3:e parts program vara. I MS SQL 2008 R2 införde man det även i Standard edition (alla versioner av MS SQL 2008 och senare kan läsa tillbaka en komprimerad backup).

Ett flertal använder MS SQL agenter till den 3:e partsprogramvara man har för backupper (den som tar backupper på alla andra servrar). En fördel med att använda denna typ av SQL agenter är att en restore av en databas görs från samma gränssnitt som övriga restores utförs, det behövs normalt ingen DBA för att göra en restore. En annan fördel är att man inte behöver en massa disk på varje SQL-server för att lagra backupper.
En stor nackdel (som flera fått lära sig den hårda vägen) är om man har databaser med recoverymodel satt som "bulk-logged" eller "Full" och gör backupper/transaktionsloggsbackupper både genom SQL-agenten från 3:e parts tillverkarn, och samtidigt gör backupper/transaktionsloggsbackuper med den inbyggda backupfunktionen i MS SQL.. är det upplagt för knas. Transaktionslogg backupper kommer att vara ur synk och man får ett helt h----te när man skall få upp allting.
Många tror sig har "båda hängslen och livrem" genom att göra så, men vad man har gjort är att man klippt av hängslet och haft sönder livremmen. Uppvaknandet ur detta brukar inte vara vackert...

Ett annat problem är de som inte har backupper på alla databaser. De enda två databaserna man normalt kan ignorera när det gäller backupper är "TempDB" och "model". (bara för att man kan betyder inte det att man bör. Model bör man göra backup på precis som alla andra databaser, det underlättar så mycket om det blir fel någonstanns och dessutom är den ju i princip tom så backuppen går toksnabbt)
"TempDB" skapas om varje gång SQL-servertjänsten startas upp, den innehåller bara temporärdata.
"Model" är en databas som används som "modell" (jupp helt crazy!!) när man skapar en ny databas. Det tas helt enkelt en kopia på model-databasen och sedan så döps den om till det namn som man vill ha på sin nya databas.  Om model-skulle gå sönder så är det faktiskt dåligt eftersom att den används när man skall skapa nya databaser, men det går att göra en repair (skapa ny model-databas) som det skulle behövas...

Så backupper då.
Vad jag rekommenderar? Gör backupper!!!
Lättast är att använda en maintenance plan och låta den dumpa ut backupperna till en lokalt ansluten disk på SQL-servern.
Beroende på vilka krav som organisationen har så får man anpassa mängden backupper. Minst en fullbackup per dygn brukar vara praxis. :)
Se till att dumpen av backupperna till disk är klar innan man drar igång 3:e parts backupperna.
Exempelvis:
- klockan 22.00 drar SQL agent igång ett backuppjobb som gör full backup och dumpar ut alla databaser till filer och lägger dessa på "G:\SQLbackup\
- Demma dump tar en timme
- klockan 23:30 drar BackupExec igång ett jobb som gör backup på hela SQL-servern (fast inte exempelvis kataloger där transaktionsloggar och databaser ligger). I denna backup tas även mappen G:\SQLbackup med. Dessa backuper hamnar på backupband och lagras på en helt annan plats än serverrummet...


För att återknyta lite till gårdagens artikel. Om man får korrupt data i en databas... Hur lagar man det?
Tja, det finns ett gäng DBCC-kommandon som kan laga enklare inkonsistenser i databaser, men det enda helt säkra sättet är att gå tillbaka till en backup som inte hade denna inkonsistens. Dock kommer man då (normalt sett) att tappa all information som lagts in/ändrat/raderats sedan denna backup.

En viktig sak förutom att göra fullbackupper är att hålla koll på vilken recovery model som databasen har. Om den är satt som "bulk-logged" eller "Full" så bör man (läs: skall man!!!) göra transaktionsloggsbackupper. Annars kommer transaktionsloggen att växa i all oändlighet (eller om den är satt med maxstorlek så kommer databasen att stanna).
Jag har tidigare skrivit två inlägg om backupper och recovery models...

Dessa rekommenderas varm (den första av dessa är den absolut vanligaste träffen från Google till denna blogg :)).

Ett annat sätt är att använda Ola Hallgrens script (som jag talade om igår när det gällde index uppdateringar). Han har en lösning som själv förstår om man har simple mode, bulk-logged eller Full och gör rätt typ av backup efter vad som behövs.
På simple-talk ligger det en artikel (läs här) som beskiver hur man tar Olas lösning i drift (denna artikel rekommenderas!!)

Inga kommentarer:

Skicka en kommentar

Related Posts Plugin for WordPress, Blogger...