http://blog.rollback.hu SQL, üzemeltetés kicsiknek és nagyoknak. Thu, 17 Nov 2011 16:38:59 +0000 http://wordpress.org/?v=2.8.6 en hourly 1 http://blog.rollback.hu/2008/10/mire-jo-a-snapshot/ http://blog.rollback.hu/2008/10/mire-jo-a-snapshot/#comments Wed, 22 Oct 2008 12:16:01 +0000 Erik http://blog.rollback.hu/?p=27 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 :)

]]> http://blog.rollback.hu/2008/10/mire-jo-a-snapshot/feed/ 0