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é!

Hello world!

Hosszas huzavona, bénázás és idealista tervezés után végül mégiscsak nekiállok blogot írni. Először megterveztem, hogy mennyire jó kis oldalt fogok összereszelni magamnak. Ez megtörtént, de sokkal tovább tartott, mint terveztem, és személyes oldal lett, valahogy nem passzolt bele egy inkább szakmai jellegű blog. Aztán elkezdtem tervezn ia szakmai blogot, és semmi nem lett belőle hónapokig. Végül megelégeltem a bénázásomat, és regeltem egyet a WordPressnél, amiben szintén vannak kihívások, de kezdetnek jó lesz. Úgyhogy gyorsan el is húzok aludni.