Bréking nyúz: Microsoft® SQL Server® 2008 Internals

Múlt héten jelent meg a Microsoft® SQL Server® 2008 Internals könyv, melyet a megszokott Inside SQL Server sorozatíró Kalen Delaney mellett személyes kedvenceim, Paul Randal és neje, Kimberly Tripp neve is fémjelez. Az SQL 2005-nél kimaradt az all-in-one feeling, itt most megint van egy könyv mind felett, 784 oldalon (azért megjegyzem, Itzik Ben-Gan megírta a maga külön könyvét a T-SQL-ről). A könyv tartalomjegyzéke megtekinthető az MSPress blogján, szerintem nagyon ígéretes. Rosszkor jött ez nekem, mert ha kiadták volna szeptemberben, akkor 8000 Ft-ért megszerezhettem volna, így most 12K körül lesz… Gonosz világválság…

Compressed backup – egy szép történet

Épp olvastam Paul Randal blogjában egy kis high-end SQL szerverről. Mivel egyszer volt egy közepesen kellemetlen beszélgetésem arról, hogy hogyan lehet nagy (terás) SQL adatbázisokat menteni, ez a téma különösen érdekel engem, és hát ők 12 backup device-ra mentettek 2 óra alatt, kicsit tuningolva az opciókon és több hálókártyát használva.
Hab a tortán: SQL 2008 backup compressionnel a 2 TB-ot 36 perc alatt mentik…

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 :)

SQL Server 2008 Launch

Az SQL Server 2008 végre itthon is bemutatódott a szakmai közösségnek, nagy az öröm minden szinten, legalábbis nálam, hiszen abszolváltam életem első nagyszámú közönség előtti szakmai előadását, és egész jó lett szerintem, sajnos a végére kicsit elcsúsztam az idővel. Volt egy-két dolog, amit már nem tudtam elmagyarázni, megmutogatni, inkább majd én is megírom őket, mint Soci :) És megjelent a cikkem is a Technet Magazinban, persze CTP termékről írni mindig szép kihívás, egy-két dolog már nem is úgy van, mint ahogy leírtam. Majd ezeket is leírom…

UNIQUE és több NULL

(This article has an English version…)
Ha szeretnénk biztosítani azt, hogy egy oszlop értékei mind egyeidek legyenek, akkor használhatjuk a UNIQUE kulcsszót (akár constraint, akár index formában), hogy ezt kierőszakoljuk. Ez eddig szép és jó, de mi a helyzet a NULL értékekkel? Egy NULL-t simán be tudunk szúrni (ez ugye a nagy különbség a UNIQUE és a PRIMARY KEY között, utóbbi nem enged semmilyen NULL-t), de mi van, ha sok NULL-t akarok bepakolni? Continue reading ‘UNIQUE és több NULL’ »