SQL Server Books Online

Az SQL Server dokumentációja a legjobb, amivel találkoztam ilyen szintű terméknél. Részletes, példákkal tele, elmeséli az alapokat is meg a bitvadászatot (az esetek többségében), és 2005 óta folyamatosan frissítik. Ez fontos. Úgy értem, hogy aki használja, az használja a legújabbat belőle… Most épp a 2007 szeptemberi a legutolsó a SQL2005-höz. Én szerencsére most nem faragtam rá, de más igen

…ó …ió …ció …Replikáció!

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. Boncolgatom egy kicsit az általam most kitalált meghatározást az érhetőség kedvéért:

egy adatbázis tetszőlegesen kiválasztott része: Alapvetően általában az adatokat (azaz a táblákat) szeretnénk többszörözni, de bármilyen objektumot replikálhatunk: view-t, sp-t, udf-et. Táblák esetében a tábla tartalma mind horizontálisan, mind vertikálisan filterezhető (ez a tudományos szöveg azt hivatott elmondani, hogy mind sorokat, mind oszlopokat kihagyhatunk a táblatartalmakból ).

többszörözzük: A replikáció segítségével tetszőlegesen sok helyre szétteríthetjük a kívánt adatot, akár ugyanarra a szerverre, csak egy másik adatbázisba, akár a világ másik végére (akár egy másik adatbáziskezelőbe is, némi korlátokkal), szintén egy másik adatbázisba.

Ebből már láthatjuk kicsit, mi is az a replikáció és mire való. Gyakorlati alkalmazása lehet neki például: referenciatáblák adatainak a terjesztése; riportolás; földrajzilag távoli adatok “közelebb hozása”; egymással nem mindig kapcsolatban álló adatbázisok szinkronban tartása. Mire nem való? Hát, szöget beverni vele – arra teljesen alkalmatlan. Szokták nagy rendelkezésreállási megoldásként is reklámozni, erről én azt gondolom, hogy lehet, persze, de azért a log shipping és mirroring létezése erősen rontja ezt a képet. Leginkább annál a résznél, amikor a rugalmassághoz meg a strapabíráshoz érünk. Természetesen el tudok képzelni olyan felállást, amikor ez egy nem rossz ötlet, csak most nem jut eszembe rá példa. A teljesség igénye nélkül két nem túl valószerűtlen történet arra ,hogy én miért nem tartom jónak “tartalékadatbázis” készítésére: 1) Sémát változtatok az adatbázisban. Elég jó esélyem van arra, hogy a replikáció miatt nem tehetem meg csak úgy, illetve ha megteszem, nem megy át a replikációval a változtatás. 2) A “replikálódott” céladatbázis egy teljesen közönséges adatbázis, írható-olvasható, és (a mirroringhoz és log shippinghez képest) viszonylag nagy az esélye annak, hogy valaki valamit módosít az adatbázisban, és így elcsúszik a szinkron.

A replikáció alapjai

A bevezető után térjünk a szakmai részre. A replikációban három szerep van, és háromféle replikáció van. Mindhárom replikációban ugyanaz a három szerep. A szerepek előtt azért még a könnyebb feldolgozás kedvéért elmondom, hogy a terminológiában a lapterjesztéssel vontak párhuzamot a fejlesztők, mely párhuzam néha kicsit biceg, de azért nem dől el.

Szóval a három fő szerep a Publisher (kiadó), a Distributor (terjesztő) és a Subscriber (előfizető). Ezek inkább adatbázisokhoz kötődnek, mint szerverekhez, akár mindhárom szerep lehet ugyanazon a szerveren. A Publisher adatbázis az, amelyiknek a tartalmát szeretnénk terjeszteni, egy terjesztési egység a publication (publikáció), ami tartalmaz egy vagy több article-t (cikket). Egy article egy objektumnak felel meg, azaz lehet egy tábla, tárolt eljárás, UDF, stb.) Egy adatbázisban több publikációt is létrehozhatunk, és ugyanazt az objektumot több publikációba is betehetjük. A Distributor felelős azért, hogy a szükséges változások eljussanak a Subscriberekhez, akik pedig nem kell, hogy felelősek legyenek semmiért.

A replikációnak három típusa van, bonyolódó sorrendben: a snapshot, a transactional és a merge. A snapshot elég egyszerű, mint a neve is mutatja, egy pillanatfelvételt lehet vele terjeszteni. A Publisher adott időpontban fennálló állapotát osztja meg, a későbbi esetleges változások nem mennek át. A működési elv is egyszerű: a Publisherről készül egy séma-generáló script-csomag, plusz az érintett táblák (igény szerint filterezett) tartalma bcp-vel fájlokba ugrik. Ez a csomag a snapshot, ami hasonló logikával kerül a Subscriberre: a scriptek legenerálják a szükséges sémát, az adatokat pedig a bcp jól betölti. Tipikusan arra való, hogy ritkán változó, nem túl nagy méretű adatokat szinkronizáljunk, például referenciatáblákat (termékkatalógus, cikktörzs, irányítószámadatbázis, stb). Az adatfolyam itt mindig egyirányú: Publishertől a Subscribernek. A transactional replikáció egy picit komplexebb, itt már a változások (pontosabban a tranzakciók) is folyamatosan mennek a subsciberek felé, akik így naprakészek (vagyis percrekészek) egyfolytában. Ez használható olyan helyeken, ahol egy adatbázis egy részének olvasható elérésére van szükség, például riportozó/monitorozó alkalmazás. Az adafolyam itt általában egyirányú, de van lehetőség update-elhető publikációkat létrehozni, amikkel a Subscriber vissza tud írni az adatbázisba. Ezt akkor lehet használni, ha nagy ritkán valamiért a Subscribernek is írni kell, de általában (>99,5%) nem. Ezt ugyanis nem erre tervezték elsősorban. A merge replikációnak ellenben az a fő funkciója, hogy gyakorlatilag a különböző felek által végzett módosításokat szinkronban tartsa. Itt persze felléphetnek különböző érdekes helyzetek, de erről majd később. Persze vannak kötöttségek is: A transactional esetén csak olyan táblák replikálhatóak, amelyeken van primary key definiálva, hiszen ez lesz a későbbi update-ek esetén hivatott a rekordokat beazonosítani. A merge replikációnak pedig egy egész új oszlop kell: egy GUID, ami a rekordokat azonosítja, mivel itt már a primary key sem elég – mi történik, ha az egyik helyen pont a primary key módosul, a másikon pedig egy másik mező?

Egy fontos dolog a replikáció működéséről: tele van ágensekkel minden: a snapshotot a Snapshot Agent generálja, a tranzakciókat a tranzakciós naplóból a Log Reader Agent bányássza ki, a subscribereknek a szükséges adatokat a Distribution Agentek terjesztik, a merge replikációt pedig a Merge Agentek végzik. Ha pedig valaki a transactional replikációt update-elni akarja, hogy inzultáljam a magyar nyelvet, akkor még egy Queue Reader Agentre is számítson…

A replikáció kapcsán még egy dolog szokott előkerülni: a distribution adatbázis. Ez egy rendszer adatbázis, amiben a szerver által kezelt publikációk adatai találhatóak: a publikációk típusa, tartalma, a subscriberek, illetve maguk a terjesztendő adatok is ide kerülnek a transactional replikáció esetén.

Röviden ez a replikáció vázlatos és felületes áttekintése.

Mi az a Performance Studio?

A Microsoftnak van egy nagyon jó terméke. Ez az SQL Server, színtől, mérettől függetlenül (Pointy Hair Bossnak nincs igaza, nem a mályvában van a legtöbb RAM). És van egy másik jó terméke, a Visual Studio. Valaki pedig azt álmodta, hogy a kettőt össze kell tolni. Ami jó ötlet is lehet, csak nem mindig. Az SQL 2005-nek a menedzsment eszköze a Management Studio, ami nem véletlenül Studio, mivel leginkább egy célra faragott Visual Studionak tűnik. Ha másból nem is, abból mindenképpen, hogy 60 Mb memória alatt nincs is élet, ami a fejlesztőt nem feltétlenül zavarja, de engem, mint üzemeltetőt nem tölt el feltétlen örömmel a tény, hogy vagy az SQLCMD parancssoros felülete, ahol az első varchar(2000) oszlop kiveri a biztosítékot, vagy ez a csillagromboló. (Vagy a jó öreg Query Analyzer, mert az tud csatlakozni a SQL 2005-höz:) Aztán az SSIS (vagy DTSX?) package-ek gyártásához ott van a Business Intelligence Development Studio, ami viszont már egy teljesen igazi Visual Studio. És ekkor hallottam az SQL 2008 egyik nagy újdonságáról, a Performance Studio-ról. Ez elsőre kiverte nálam a biztosítékot. Nekiálltam túrni az új SSMS-t, de nem volt benne ilyen, megnéztem a Start menüt, programkönyvtárat, nyomát sem láttam Performance Studionak. Na de akkor hol van az a Performance Studio és mit csinál?

A Performance Studio egy virtuális toolset, hogy szép magyarsággal fejezzem ki magam. A megszokott teljesítménymonitorozó és tuningoló eszközökön (SQL Profiler, SQL Trace, Database Engine Tuning Advisor, stb.) túl az új stratégiai monitorozó-adatgyűjtő Performance Data Collection, avagy Performance Data Warehouse, és persze egy API, amin keresztül lehet bizgetni az egészet. Egyébként a Data Collection nagyon jó eszköz, végre van beépített trendelemzési meg kapacitástervezési lehetőség. Juhé!