Éj a szerverszobában - 02
By JoeP
Oké, szorgalmatos rőzseszedegető anyókaként kezdjünk el gyűjtögetni.
Rögtön van egy rossz hÃrem. Az eventlog nagy. Nem, még annál is nagyobb. És nekünk ebbÅ‘l kell kimazsolázni durván egy hónap Online Maintenance bejegyzéseit.
Akár fel is vehetnénk középső névnek a Hamupipőkét.
Nos, akinek szerencséje van, az Windows Server 2008-ra telepÃtette az Exchange szerverét. Itt ugyanis már tudunk custom view-t generálni az eventlogon belül. A Windows Server 2003 kedvelÅ‘i… most Ãgy jártak. HamupipÅ‘ke.
A fenti ábrán láthatók a custom view beállÃtásai. Úgy gondolom, a kép magáért beszél.
Ha beállÃtottuk, akkor a következÅ‘ nézethez jutunk. Mekkora öröm, már… csak és kizárólag az OM bejegyzéseket látjuk. Nem mintha ebbÅ‘l nem lenne durva még kinyerni az összetartozó adatokat… de legalább már van némi esélyünk.
A következÅ‘ event azonosÃtók vonatkoznak az Online Maintenance folyamatra:
- 700: Online defragmentation is beginning a full pass on database XY
Az XY adatbázison elindult az offline defregmentálás. - 701: Online defragmentation has completed a full pass on database XY
Az XY adatbázison befejezÅ‘dött az offline defregmentálás. Ekkor kiÃr egy csomó adatot. Az általa jelzett idÅ‘tartamokkal ( x sec) bánjunk óvatosan, köszönÅ‘ viszonyban sincsenek a mért értékekkel. Viszont az átmozgatott lapok száma hasznos információ: egy lap 8 KB (Exchange 2003-ban 4K), tehát ebbÅ‘l megtudjuk, mekkora hely (whitespace) szabadult fel az adatbázison belül. - 702: Online defragmentation is resuming its pass on database XY
Korábban lezárt folyamat folytatása. (Egy folyamat lezáródhatott úgy, hogy váratlanul nagy terhelés érte az adatbázist, illetve lezáródhatott úgy, hogy letelt a folyamatra engedélyezett időablak.) - 703: Online defragmentation has completed the resumed pass on database XY
Lezárult egy olyan folyamat, mely menetközben meg lett megszakÃtva. - 704: Online defragmentation of database XY was interrupted and terminated. The next time online defragmentation is started on this database, it will resume from the point of interruption.
Az XY adatbázis online defregmentálása meg lett szakÃtva. - 717: Database checksumming background task has started.
Elindult egy Online Checksumming folyamat. - 718: Database page zeroing background task has started.
Elindult egy Page Zeroing folyamat. - 721: Database checksumming background task has completed.
Lezárult egy Database Checksumming folyamat. - 722: Database page zeroing background task has completed.
Lezárult egy Page Zeroing folyamat. - 723: Database checksumming background task encounters an error.
A Database Checksumming folyamat közben hiba történt. - 724: Database page zeroing background task encounters an error.
A Page Zeroing folyamat közben hiba történt. - 729: Database page zeroing has been paused.
A Page Zeroing folyamat félbeszakadt.
Na, kérem, mindent tudunk. Már csak dolgozni kell.
Az első feladat lesz a legkönyebb: ne csináljunk egy hónapig semmit. Hagyjuk az adatbázisokat az alapértelmezett értékeken - és várjuk, hadd gyűljenek a bejegyzések.
Az eventlogból kigyűjtött adatokat táblázatban összesÃtjük.
Igen, tudom, hogy erre a feladatra lehetne szkriptet is Ãrni. De most levetkÅ‘zöm a rendszergazda mentalitást és azt javaslom neked is, hogy bogarászd ki egyenként az adatokat és szépen gépeld be mindet az Excel táblába. Hidd el, ennek hamarosan meglesz a jelentÅ‘sége.
Ugyanis ahogy készen van a táblázat, jöhet az optimalizálás. Az egyetlen olyan feladat, amelyre nincs algoritmus. Csak te vagy és a józan ész.
Ezért fontos, hogy mire ide eljutsz, összebarátkozzál az adatbázisokkal. Ha egyenként gyűjtöd be az adatokat, akkor már menetközben össze fognak állni a történetek. Jellemük, viselkedésük lesz az adatbázisoknak. Lesz a lusta disznó. Lesz a lassú behemót. Lesz a szorgalmas cingár. Látod, hogy amÃg az egyik nem és nem ér egy folyamat végére, mert mindig megszakad, addig a másik olyan sokszor zajlódik le, hogy rendszerint már nulla, vagy tÃznél kevesebb lapot szabadÃt csak fel. Megtapasztalod, mitÅ‘l függnek az időértékek.
Mire kitöltöd a táblázatot, előtted lesz az egész bagázs, mint osztályfőnök előtt a diákok az első év végén.
Optimalizáljunk.
Tételezzük fel, hogy CCR rendszerünk van, a backup a paszÃv node-ról megy, azaz az OM mehet az aktÃv node-on. Az egyszerűség kedvéért most ne foglalkozzunk a Database Checksumming folyamattal.
A munkaidőt természetesen tiszteletben tartjuk, tehát reggel 7 és este 7 között az üzleté a terep. Hétvégén viszont mi vagyunk, egész nap.
Ez annyi mint 5*12+2*24 = 108 óra.
Mennyi is jött ki a táblázatból?
21+9+9+21=60. Simán beleférünk. Mi itt a probléma?
Hát példul az, hogy az OM folyamatok nem annyira udvariasak, hogy pont az időintervallum elején induljanak el. Akkor általában már egy korábban félszakadt defrag fog folytatódni. Azaz, ha teljesen biztos akarok lenni abban, hogy egy héten belül biztosan lemenjen minden adatbázisra az OM, akkor dupla annyi időt kell kapniuk, mint amennyit mértünk. Ez 120 óra.
Annyi viszont nincs.
Jöhetnek a kompromisszumok.
A DB04 a VIP adatbázis. Itt nincs kompromisszum, sÅ‘t, Å‘k inkább 44 órát kapnak, azt is összefüggÅ‘en. A DB01 adatbázisban is vannak kritikus postafiókok, Å‘k is megkapják a 42 órájukat. Viszont mi lenne, ha a maradék két adatbázis ugyanabban a szegmensben lenne? A szerver elbÃrja (úgyse dolgozik éjszaka rajta senki), és ha a maradék idÅ‘t (108-44-42=22) adjuk oda nekik, akkor jó eséllyel mind a kettÅ‘ le tud futni egyszer.
Itt is van. A VIP 44 óra és nem szakad meg, a DB01 42 óra, de azért már szakadozik, a többiek meg majd csak ellesznek valahogyan.
De ez már egészen jó kiindulási alap.
Már csak egy lépés van hátra, belÅ‘ni a backupot. Habár a két folyamat független egymástól, de célszerű a mentést rögtön az OM utánra idÅ‘zÃteni, Ãgy gyorsan el is takarÃtjuk a felesleges logfájlokat.
És ugye nem felejtettük el, hogy negyedév múlva újra elvégezzük a vizsgálatot, megnézzük, hogy amit kitaláltunk, mennyire működik jól hosszú távon.
Hasznos linkek:
By JoeP 
január 4, 2010 at 20:58
Posted in: általános
Leave a Reply