Leta i den här bloggen

2010-08-21

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

Denna post är del 3 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 skrev jag om den ofrivillige DBAn och om Indexar och statistik på databas-filer.. Idag tänkte jag fortsätta med korrupt data och hur man upptäcker detta. Målet är precis som tidigare inte att få den perfekta MS SQL miljön utan en miljö som är "tillräckligt bra".
Hittills har vi talat om prestandafrågor. Hur filer skall hanteras och hur Indexar och Statistiken skall uppdateras. Dessa saker är prestandarellaterade.
Men det är ju inte allt. Jag har vid ett flertal tillfällen varit ute hos kunder, eller fått telefonsamtal från någon som har en databas som man inta kan komma åt längre och så är den markerad som "suspect" i SQL server manager...
Målet är ju oftast att:
- Sätta upp miljön så att risken för fel minimeras
- När det väl blir fel så vill man upptäcka dem tidigt, innan de blir så stora att det blir jobbigt att laga dem

Om det "tokskiter sig" (tm) så har man ju alltid backuppen (som kommer i sista artikeln)... för det har väl alla? :)

Nåja, nu skall det handla om databaser som blir korrupta.

Korrupta databaser.
Nej, detta har faktiskt ingenting med bruna kuvert med sedlar, möten i mörka garage eller liknande. Istället handlar det om att man har databaser där man förväntar sig att en viss information skall lagras, men det faktiskt står nått helt annat... alternativt att informationen har försvunnit helt.
Jag tänker inte ägna mig åt korruption som beror på buggar i applikationerna som jobbar mot SQL-servern. Det är en helt annan sak och är något som måste hanteras av den/de som har byggt applikationen.
Istället tänkte jag börja med en annan orsak till korrupt data. Det som kallas för hårdvaruproblem... Hårdvaruproblem är inte bara hårdvara (hårdvara är sånt man kan tappa i golvet) utan här räknas även allting in som har med I/O systemet som ligger under SQL-server och då betyder det att även Operativsystem, drivrutiner, RAID-kort, hårddiskar, nätverk, kablar, minnen, processorer osv.
Det absolut vanligaste är att man av någon anledning får strömavbrott till en server samtidigt som serern höll på och skriva till hårddiskarna. Då finns det en risk att inte hela data page (se tidigare post om hur dessa funkar) skrivs till disken och därmed är den inkonsistent. Detta kallas för en "torn page".
För att minimera risken för att detta skall hända har vi ordentlig hårdvara i våra servrar (och inte en vanlig desktopmaskin) som minimerar risken för att hårdvaran går sönder. Vi ser till att ha ordentlig kyla för hårdvaran för att minimera risken att hårdvaran skall gå sönder. Ofta har vi batteribackup monterat på RAID-korten i servern så att om den inte hunnit skriva ned datat på disken så ligger det kvar i cachen på RAID-kortet och vid nästa omstart så kan informationen skrivas till disk (alternativt att batteriet kan driva diskarnat tills dess att informationen är nedskriven på disk). Vi ser till att det är bra minnen med inbyggd felkorrigering i servrarna osv...

Men trots att vi lägger en massa pengar på bra hårdvara så händer det ändå att det blir fel ibland. Vilken tur att MS SQL kan upptäcka om vi får en tornpage. Upp till och med MS SQL 2000 användes en teknik att spara några bitar från varje sektor på en data page (en page består av 16st 512-bytes sektorer) och att skriva ett speciellt mönster på dessa platser. När man sedan läste tillbaka data pagen så kontrollerades om mönstret stämde och om det inte gjorde det så var det en "torn page" och ett felmeddelande dök upp.
Från SQL 2005 och uppåt används en checksumma istället för varje data page.
Som standard är torn protection aktierat från SQL 2000 och uppåt. Dock om man uppgraderar en databas från 2000 till 2005 eller 2008 så måste man aktivt välja att slå på checksumma kontrollen. Annars används den mycket enklare (enklare som i "Det här hotellet hade verkligen enkel standard på sina hotellrum, knappt sängar...", inte enklare som i "Oj vad enkelt det var att slå i spiken").
Om man aktiverar checksumma så kommer inte datat att vara skyddat innan data pagen har laddats till bufferpoolen, ändrats på nått sätt och sedan skrivits ut på disk igen. Detta måste ske för samtliga data pages för att de skall vara skyddade.
Ett enkelt sätt att manuellt kolla hur databaser mår är att köra DBCC-kommandot. I stil med:

DBCC CHECKDB ('MinDatabas') WITH NO_INFOMSGS, ALL_ERRORMSGS

Får man en massa info från detta kommando så har man en korrupt databas. Då börjar det bli dags att fundera på hur backupperna har funkat.

Men i det dagliga arbetet så håller man oftast inte på och kör DBCC manuellt på alla databaser man har hand om.. Lättast är att lägga upp en Maintenance Plan som innehåller punkten "Check Database Integrity Task" och schemalägga denna en gång per dag eller en gång per vecka (vad som passar, men absolut så bör man köra den minst lika ofta som man kör fullbackup). Denna kör en DBCC CHECDB på databaserna och sedan kan man få detta jobb att larma om det blir nått fel.

Om man vill få larm när en torn page uppstår och inte behöva vänta tills dess att maintenace planen är schemalags så i SQL Server Management Studio får man gå in under "SQL Server Agent" och där under "Alerts" så får man lägga upp ett larm. För att få larm för torn pages så är det "severity 24" som används (024 - Fatal Error: Hardvare error).

Inga kommentarer:

Skicka en kommentar

Related Posts Plugin for WordPress, Blogger...