Rollback

Elnézést az angol címért, de ez történt. Létrehoztam tegnap egy szűrt tranzakcionális publikációt (ez szerintetek jobb?), és ma ránéztem a szerverre, és azt láttam, hogy a logreader agent (naplóolvasó ügynök) le van maradva súlyos órákkal. Megnéztem a sysprocesses táblában, hogy mennyi erőforrást eszik, és azt láttam, hogy rohadt sokat. Állítgattam egy kicsit az agent paramétereken, de igazából nem értettem a helyzetet, és nem is segített a piszkálgatás.
Kénytelen voltam gondolkodni, és arra jutottam, hogy profiler kell nekem. És tényleg, a logreader agent spidjére szűrve elkezdtek záporozni a cpu-t és io-t evő eventek: dolgozta fel a filtert a szerencsétlen: where id in (select id from tabla2 where location_code = 144). Úgy döntöttem, hogy ez nekem annyira nem kell. Eldobtam az új publikációt, és… nem történt semmi változás a lemaradásban. Újraindítottam az agentet, semmi. Ekkor gondoltam, hogy le kéne menni a boltba birkaveséért, megszárítani, porrá törni, és beszórni vele a szervert. Ez segített, mert hirtelen elkezdett esni a delivery latency. Úgy látszik, hogy a filterezés tényleg kikészítette öreg barátunkat.
Hepiend.

(a történeti hűség és politikai korrektség jegyében meg kell mondanom, hogy ez a szerver egy muzeális darab, még SQL 2000-et futtat)

Mostanság SQL DBA-t keresek, és szakmai tesztekkel és interjúkkal is töltöm rengeteg szabadidőmet. Alapvetően megerősítve látom azon véleményemet, hogy az informatika vallásközeli tudomány, és sokan transzcendens vonásokat találnak a szerverek működésében, és babonás eszközökkel közelítik meg őket. Az egyik ilyen misztikus terület a tranzakciós log szerepe és használata.
Mindenekelőtt szeretném leszögezni a következőt: a tranzakció teljesülését a diszkre fogja kiírni rögtön az SQL szerver, nem a memóriában írja a tranzakciós logot, mert annak ugye nem volna sok értelme, ha a commit tényét egy illékony tárban rögzítené. De ez részletkérdés pillanatnyi motivációm szempontjából, nézzük inkább meg, hogy mikor szabadítja fel az SQL a tranzakciós logot. Három feltételnek kell tejesülnie:

1. Az adatbázis recovery modellje simple vagy (full és bulk-logged esetén) az adott naplórész le lett backupolva.
2. A tranzakciós log szóban forgó része nem tartalmaz aktív tranzakciót, azaz minden olyan tranzakció, ami a log írásakor aktív volt, már véget ért (ha rollback lett ,akkor a rollback is véget ért).
3. Az adatbázis nincs replikálva vagy ha igen, akkor a Log Reader Agent már elolvasta az adott részt

Ezeknek a feltételeknek egyszerre teljesülniük kell. Azaz ha leállítom a Log Reader Agentet, akkor elkezd nőni a tranlog az égig, hogy ne rontsa el a replikációt. Hasonlóan elkezd nőni a log, ha sikerült egy tranzakicónak nyitva maradnia az adatbázisban, és lassan az egész tranlog aktívvá válik miatta.
Tehát ha megnő a log, érdemes a fenti pontokat ellenőrizni, körülbelül ebben a sorrendben (recovery model/utolsó log backup; legrégebbi nyitott tranzakció; replikáció esetén LRA).
Ja, még egy utolsó: a TRUNCATE LOG parancsok margójára: ha valaki rendszeresen kiadja a truncate log parancsot, akkor gondolkozzon el azon, hogy miért van full recovery model beállítva, és gyorsan állítsa át simple-re. Köszi.

Pár hónapja találkoztam egy érdekes problémával: adott egy többszintű MSSQL tranzakcionális replikáció, azaz a subscriber továbbpublisholja az adatokat valahova, ahonnan ezt még tovább publikálják. Hogy mi ebben a ráció, azt nem akarom firtatni, a lényeg, hogy azért van benne, például nem látják egymást a gépek, és az eleje és a vége között van párezer mérföld távolság. Ebben a helyzetben a második publishert kellett kicserélni, mivel upgrade-elték az SQL-t 2005-re. A replikált adatmennyiség elég nagy volt, WAN-on napokig tartott egy újrainicializálás, úgyhogy valami frappáns megoldás után néztem… A végeredmény sokak szerint merész lett, de senki nem tudott belekötni, úgyhogy ezt javasoltam végső megoldásnak.
Az “adatforrás” szervert nevezzük A-nak, az ő subscriberét B-nek, aki publikálja az A-tól kapott adatokat C-nek, és ne is menjünk tovább, ennyi elég a történet szempontjából, hiszen B-t cseréljük ki BB-re. A legegyszerűbb felállásban új publikációkat kellett volna létrehozni BB-n, amire C-nek fel kell iratkozni, és a kezdeti incializálás duplán fáj: a hosszú snapshot applikáció mellett a már a C-n lévő adatokat onnan előbb el kell tüntetni: vagy delete, ami többgigás tábláknál elég csúnya hatással van az adatbázis használhatóságára, ráadásul továbbreplikálódik D-re, ahol ugyanezt a hatást váltja ki; vagy drop-create table, ami gyorsabb, de ehhez a C-n lévő publikációt el kell dobni és újra létrehozni majd, ami egy vertikálisan és horizontálisan is filterezett gigásznál szintén elég kalandos tud lenni. Continue reading ‘Többszintű replikáció költöztetése’ »

Irodalmi bevezető

A replikáció érdekes terület az SQL szerverben. Sokkal kevesebben használják, mint ahányan félnek tőle, és ez valahogy azt sugallja az embernek, hogy ő se akarja használni. Pedig a replikáció szép és jó, csak tudni kell, hogy hol a helye.

Először is próbáljuk meg tisztázni, mi is a replikáció, mire is való, és mire nem. A replikáció tulajdonképpen arról szól, hogy egy adatbázis tetszőlegesen kiválasztott részét többszörözzük. Continue reading ‘…ó …ió …ció …Replikáció!’ »