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.

Nagyítás

A fenti ábrán láthatók a custom view beállításai. Úgy gondolom, a kép magáért beszél.

Nagyítás

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.

Nagyítás

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.

Nagyítás

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.

Nagyítás

É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: