Boldog új Microsoft SQL… 2009-et

Leszögezem: ilyen nevű termékről nem tudok, de ez egy kiváló modszer arra, hogy megírjam az évköszöntő postomat, és alantas trükkel növeljem látogatottságomat, miután minden SQL 2009-et kereső ember majd ide fog látogatni a bolygóról :)
Mindenesetre idén új életet kezdek, sajnos ennek egyik eleme az lesz, hogy kevesebbet fogok kétkezi munkát végezni adatbázisokkal (úgy néz ki, megtaláltuk a megfelelő embert a DBA pozícióra), cserébe viszont jóval több időm lesz (remélem). Ebben a rengeteg időben a szép új notebookomon (Lenovo T400, eddig nagyon szeretem, csak a kijelzője lehetne WXGA+ WXGA helyett) végre tudok többet írni, minek egy része ide fog kerülni, egy része pedig a megújult Technet portálra. Remélem hasznát fogja venni legalább egy ember :)
Mindenkinek olyan 2009-et kívánok, amilyet csak szeretne.

Technet SQL üzemeltetői nap előadások

A szeptember 24-i Technet üzemeltetői szemináriumon tartott előadásom – a többiekével együtt – megtalálható a Technet honlapon, a demóscriptekkel együtt. Akit érdekel, ITT találja.

Mire jó a snapshot

A Technet üzemeltetői szemináriumon beszéltem többek között a database snapshotról is, és a felkészülés során egy kicsit belementem a málnásba. Lúzerségemet büszkén felvállalva megosztom mindenkivel, nehogy más is kitalálja ezt a bénázást.
A database snapshot egy olyan read-only adatbázis, amit egy meglévő adatbázis (ez a forrásadatbázis) alapján hozunk létre, és a forrásadatbázisnak a snapshot készítésekori állapotát tartalmazza. Létrehozása nem igényel erőforrást, fenntartása igen. Létrehozáskor ugyanis az SQL Server sparse file-okként hozza létre a fájljait, azaz igazából nem foglal helyet, mert csak azokat a lapokat tartalmazza, amik megváltoztak a forrásadatbázisban. Ez a copy-on-write nevű varázslat, azaz a snapshot tulajdonképpen készít egy backupot magának a forrásadatbázis lapjairól, mielőtt azok megváltoznának. A snapshotnak amellett, hogy egy múltbeli állapotot elérhetővé tesz, van egy másik nagyon előnyös tulajdonsága: segítségével vissza lehet állni az általa tárolt állapotra.
Egy adatbázisról gyakorlatilag akárhány snapshotot tudunk készíteni, de a snapshotnak megvannak a korlátai is: Először is, a snapshot teljesen függ a forrásadatbázistól. Ha a forrásadatbázis elpusztul, vele hal a snapshot is, mivel az adatainak az a része, ami nem változott, csak a forrásadatbázisban található meg. Ebből következik az, hogy nem alkalmas a backup pótlására.
Egy adatbázisról készíthetünk rengeteg snapshotot, ezek egymástól teljesen függetlenek lesznek. Azaz ha egy forrásadatbázisról készítünk tíz snapshotot, minden egyes lap változás a forrásadatbázisban tizenegy írást fog generálni – minden snapshotban egyet, plusz a forrásadatbázisban egyet. Ennek már lehet hatása a teljesítményre. Ráadásul ha vissza akarunk állni valamelyik snapshotra, akkor az összes többit el kell dobnunk. Ez az apró kellemetlenség abból ered, hogy a snapshotolt adatbázist nem lehet restorolni, márpedig a snapshotra való visszaállás erősen hasonlít egy restore-ra, konkrétan azt írjuk bele a SSMS-be, hogy RESTORE DATABASE ForrasAdatbazis FROM SNAPSHOT Snapshot. Vagy valami hasonló.
Tehát az az elképzelésem, hogy az adatbázisról készítek egy snapshotot egy változtatás előtt, majd ha vissza kell állni, előtte is készítek egy snapshotot, meglehetősen kivitelezhetetlen. Próbáltam tovább csavarni a dolgot: ha mirrorozva van az adatbázis, akkor a mirrorról csinálok egy snapshotot visszaállás előtt, és akkor… eszembe jutott az amikor mirrorozott adatbázist kellett restore-olnom. Először tükröt kell törni, mert a mirrorozott adatbázist sem lehet restore-olni. Végül is ez lett a végállomás: tükörtörés, és amikor a restore elindul, felhozom online-ba a mirrort, és ott a visszaállás előtti utolsó adat. Persze addig nincsen mirrorom, de az akkor amúgy sem lenne. Kicsit nyakatekert, kicsit savanyú, de a mienk!
Én meg majd legközelebb elolvasom a Books Online-t, tényleg :)