Filtered transactional replication vs performance

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)

4 Comments

  1. zsorzs:

    Szia!
    Ehhez is lenne hozzáfűznivalóm.
    Nálunk a cégnél használunk filterezett tranzakcionális replikációt, vertikálisat is meg horizontálisat is, már több éve MSSQL 2000-es környezetben: egy publisherrel és két subscriberrel. Olyat, amit írtál, na olyat szerencsére nem tapasztaltunk ez idő alatt, lehet hogy simán csak szerencsés csillag alatt született a szerverünk. De:
    1. A publisher tehermentesítése céljából egy külön distributor szervert vettetünk be (titkárnőszervernek hívjuk), amely már MS SQL 2005-ös, és nemcsak a két régi (MS SQL200-es) sunbscribereknek disztribútál, hanem saját magának is. Ez utóbbinak főleg az a célja, hogy a fejlesztők ne karácsonyfának használják a szegény publishert, hanem inkább a titkárnőről olvasgassanak, és hagyják a publishert is dolgozni. Valamilyen genetikai hiba, vagy perverzió miatt a fejlesztőink csak pollozós, és a connection pool-t gyűlölő programokat tudnak írni…
    Na de a probléma: azt vettük észre hogy a leszkriptelt GYÁRI replikációs scriptek nem jók, vagyis a Visual Studió (VS) által generált scriptek nem használhatók, kell hozzá kézi machina, mert nem támogatott paramétereket akarnak használni, az agenteknek hülye nevet adnak, stb…summa summárum: futásképtelenek! Konkrét dolgot tudok küldeni, ha mélyebben érdekel. Szóval a replikáció menedzselése nem annyira környezetbarát a 2005-ben, mint a 2000-ben volt.
    2. Ha VS-sel generálsz egy adatbázisra sok replikációs szálat és a publisher MS SQL2000-es, akkor abba a csapdába vagy feature-be(?) eshetsz, hogy a publisher oladon nem egy, hanem sok logreader agent fog futni. És ha elég sokan vannak (vagyis sok replikációs szálat készítesz), akkor képesek egymást agyontaposni. Ezt úgy lehet megoldani, hogy a subscriberek készítése ELŐTT megváltoztatod a publikáció azon rejtett tulajdonságát, amiben engedélyezve van a több agent. Az már X-aktás eset, hogy miért nem lehet induláskor ezt letiltani, és miért alapértelmezés ez a 2000-ressel nem kompatibilis multi-agentes futás? Talán, hogy a DBA-ra szükség legyen 2005-ben is?
    3. Na ez idegesítőbb: a cégünk igazából több cég, és ez miatt több hasonló adatbázisból áll, és emellett mindegyik céges adatbázis egy jó rovarhoz méltóan 3 részből is áll: fej (publisher), tor (1. subscriber) és potroh (2.subscriber). De mégsem, mert ugye van egy 3.előfizető is: a fent említett titkárnőszerver, de ő most nem lényeges asszem. Ezzel még tán nem árultam el üzleti titkot. Na a lényeg: a fentiek szerint adatbázisonként szigorúan egy-egy logreader agent van, tök egyformák a replikácós szálak. Mégis az egyik dbhez (persze a legnagyobbhoz) kapcsolódó az egyik subscriberen (1.számú), a replikációs szálak indokolatlanul sokat dolgoznak, és folyamtosan futnak az sp_MS… replikációs tárolt eljárások is. A szálak közt van szűrt és van szűretlen is. Csináltunk már mindent, újrépítettük, próbáltuk a birkavesés megoldást is. Semmi. Nem értjük miért van a túlzot terhelés. Minden relpikáció tranzakcionális push, a publisher és az subscriberek mind MSSQL 2000-esek, a distributor 2005-ös.
    4.És hogy valami pozitívvel zárjam, még egy szó a vertikális tranzakcióról, és ez még MsSQL 2000-ben is így van: ha egy replikációban van where alapú vertikális szűrés, akkor az nagyon okos: ha a publishernél egy tétel úgy változik, hogy a feltétel szerint már nem replikálandó, akkor a subscribereknél el is tűnik! A másik eset persze triviálisabb (vagyis hogy a feltétel alapján replikálni kell mostantól), persze az is műxik, de az első esetre azért nem gondoltam volna. Az ember azt várná, hogy snapshot kell ilyen esetre, de nem! Megy anélkül is! Ipari környezetben bizonyított, hogy a vertikális szűrés a subsriber oldalon minden esetben a distributor szerinti állapotot tükrözi, és ez erősíti bennem a nirvána érzést, és hogy DBA-nak lenni jó.

  2. erik:

    Szia Zsorzs!

    (most jutottam el a komment-erdőd végéhez:). Nálunk ebbe a jelenségbe belejátszik az is, hogy a hardver csutkára ki van használva, illetve az is rontott a helyzeten, hogy subquery volt a filter.
    A replikáció szerintem külön művészet. Öreg, sokmindenhez értő rókák hirtelen elhallgatnak, amikor replikációról van szó. Én a tranzakcionálisba beleástam magam, merem állítani, hogy elégéé értek hozzá, de a merge ott aláz meg, ahol ér…
    Ha jól értem, akkor a 3-ban az 1. subscriber teker sokat. Ez elég rejtélyes, mindenesetre lehet próbálkozni ilyen hülyeségekkel, mint retentiont csökkenteni, ha lehet; megnézni, hogy konkrétan melyik agent eszi az erőforrásokat (a sysprocesses tábla vagy a SSMS activity monitor kiválóan megteszi); illetve ha minden kötél szakad, akkor lehet logoltatni is az agenteket, de ezt 2000 alatt nem tudom jó szívvel ajánlani, mert a log ugyan kiváló, de egyetlen dolog kimaradt belőle: a timestamp :) Egyébként ha nem folyamatosan futnak az agentek, hanem scheduled módban, és egyszerre több is indul, az nagyon durván tud ütni nagyobb distribution db-nél. Amúgy nekünk az volt egy kedves jelenség, hogy a distribution command tábla meghízott, ott szörfözött rajta 15-20 distrib agent, egy logreader, és néha előugrott a distribution cleanup, elkezdett törölni, és hazavágott mindenkit.
    Ha tudok valamit segíteni, írj bátran – lehet, hogy lassan, de azért megírom, amit tudok.
    Erik

  3. m@te:

    Hello Erik!
    Látom, hogy itt már egy ideje nincs mozgás replikáció ügyben, de én kérdeznék.
    Tranzakcionális replikációm van, két subscriber-el. Hozzá kell adnom egy olyan táblát ami eddig nem volt benne az egész replikációban, tehát bele kell tennem a publikációba és a subscriber-eket rá kell mozdítani. Ennek ugye 3 esete lehet:
    1. A táblát most hoztuk létre és nincs benne adat (a legegyszerűbb, ezt meg is tudom csinálni)
    2. A tábla létezik már a subscriber-eken, de nincs szinkronizálva és már tartalmaz adatokat, de eltérőket a publisher-től (még ez is menne bár még nem próbáltam)
    3. A tábla tartalmaz adatokat és ebben a pillanatban is aktív igénybevételnek van kitéve: másodpercenként 2-3 módosító tranzakció

    Nos nekem a 3. esetem van és nem tudom, hogyan tudnám úgy hozzáadni, hogy ne kelljen az egész subscription-t újra inicializálni 0-ról. Nem használok snapshot-ot és a snapshot agent is ki van kapcsolva (mert túl sokáig tart, túl nagy méretű és zárolja a táblákat).

    Hogyan tudom ezt megoldani? Köszönöm előre is a segítséget!

    Ui.:
    Azért leírom, hogy én hogyan képzeltem a megoldást:
    1. Készítek egy FULL BACKUP-ot.
    2. A mentést RESTORE-olom más néven NORECOVERY-vel.
    3. Leállítom a LogReader Agent-et.
    4. Készítek egy LOG mentést
    5. A log mentést RESTORE-olom RECOVERY-vel.
    6. A subsribereken létrehozom a táblát és/vagy TRUNCATE-elem.
    7. A más néven visszállított db-ből feltöltöm a táblát a subscribereken (IDENTITY INSERT-el)
    8. Leállítom a Distribution Agent-eket is.
    9. sp_addarticle-vel hozzáadom az új táblát a publikációhoz és sp_addsubscription-el ‘initialize with backup’ opcióval megadom a replikáció folytatásának pontját a LOG backup alapján.
    10. Ezután elindítom az Agent-eket és várom a csodát.

  4. Erik:

    Szia!

    Én mást tennék: hozzáadnám az új article-eket a publikációhoz. Erre illik generálnia egy új snapshotot a snapshot ágnesnek, mivel vannak (részleges) inicializálásra szoruló subscriberek. Aztán a distribution agent lesz okos csak az új táblákat inicializálni. Legalábbis a 2008 igen. Legalábbis elméletileg. Bár egyszer már megcsinálta gyakorlatban is.

    Ha nem akarsz snapshotolni, akkor lehet, h jó, amit leírtál, én még soha nem használtam backupot alapnak. Azért nézd meg a tablediff nevű command line utilityt is, ha hekkelni akarsz :)

    Erik

Leave a comment