Mi is ez? Mikor használható? Hogyan kell beállítani? Mire is jó ez nekem SQL Server esetén? Milyen problémákat vet fel? Ezekre a kérdésekre próbálok választ adni az alábbiakban.
Mi is ez?
Az instant file inicializálás egy olyan “szolgáltatás” ami az NTFS file allokáció során nem nullázza ki a lefoglalni kívánt területet, hanem csak megjelöli, hogy ettől-eddig akarja majd használni. Ezzel nagyon hamar nagy területet le lehet foglalni. Későbbiekben látni fogjuk, miért lényeges ez.
Mikor használható?
Gyakorlatilag az SQL Server esetén az adat file létrehozásakor/növekedésekor használható, a transaction log esetében nem, ott kötelezen kell a kinullázás – lásd Paul Randal (B | T) cikke: Understanding Logging and Recovery in SQL Server (kötelező olvasmány!). Ez a funkció Windows Server 2003 és újabb, illetve SQL Server 2005 és újabb verziók esetében érhető el.
Hogyan kell beállítani?
A beállítás során a Perform volume maintenance task biztonsági beállításhoz adjuk hozzá az SQL Server database engine service account-ját. Ezt az alábbiak szerint lehet megtenni:
- Indítsuk el a secpol.msc konzolt.
- A Security Settings\Local Policies\User Rights Assignment alatt adjuk hozzá a felhasználót/csoportot a Perform volume maintenance task biztonsági beállításhoz.
Mire is jó ez nekem SQL Server esetén?
Az alábbi esetekben lehet igen hasznos ez a beálítás:
- Előre, nagy területet le szeretnék foglalni az adatbázis számára,
- biztonsági mentésből állok vissza és nagy/előre lefoglalt területet igényel az adabázis,
- az adatbázis elérte az előre meghatározott méretet és az előre meghatározott beállításik szerint növekedni szeretne.
Mindegyik esetben, előre le kell foglalni a lemezen a felhasználandó területet. Amikor egy visszaállítás van, nem mindegy, hogy várnom kell egy pl. 2TB-os helyfoglalásra perceket/órákat vagy szinte azonnal el tudom kezdeni a visszaállítást (lásd RTO). A másik kedvenc felhasználási területem, amikor az adatbázis file növekszik. Persze lehet mondani, hogy ne növekedjen vagy csak felügyelettel. Ez mind igaz is, de mi van akkor, amikor szabin vagyunk vagy épp senki nincs ott a gépnél, mert ebédelni van 
? Álljon le minden? Persze, hogy nem. Éppen ezért szoktam engedélyezve hagyni az Autogrowth beállítást. Igen ám, de amikor növekszik az adatbázis file és nincs beállítva az instant file inicializálás, akkor addig várnak a kérések, amíg kinullázásra kerül a növekmény is. Ezt sem igazán szeretnénk.
Nézzük ezt egy példán keresztül.
Ahhoz, hogy látványos legyen a dolog, két nem dokumentált trace flag fog segíteni:
- 3004: ez kiírja a kinullázás adatait az error logba.
- 3605: csak akkor kerül be az error logba a 3004-es trace flag által megjelenítendő infó, ha ezt is bekapcsoljuk.
USE [master];
GO
DBCC TRACEON (3004) -- az error log-ba kiírja a zero inicializálás lépéseit
DBCC TRACEON (3605) -- a parancsok kimenentét az error log-ba írja.
GO
A következő lépésben létrehozok egy adatbázist a Perform volume maintenance task beállítás nélkül, előtte pedig újrainicilaizálom az error logot.
-- újrainicilaizálom az error log-ot
EXEC sp_cycle_errorlog
GO
--adatbázis létrehozésa IFI nélkül
CREATE DATABASE LargeDB
ON (NAME = 'LargeDB_Data', FILENAME = 'C:\Temp\LargeDB.mdf', SIZE = 1024 MB, FILEGROWTH = 512 MB)
LOG ON
(NAME = 'LargeDB_Log', FILENAME = 'C:\Temp\LargeDB.ldf', SIZE = 512 MB, FILEGROWTH = 512 MB);
GO
Ez eltart egy ideig – nálam kb 8 másodperc volt, majd a végén az error logból lekérdezem a file inicializálásra vonatkozó információkat az alábbi lekérdezéssel:
EXEC sp_readerrorlog 0,1, 'zeroing';
Ennek az eredménye az alábbi lett nálam:
LogDate ProcessInfo Text
2012-11-22 16:03:06.450 spid51 Zeroing C:\Temp\LargeDB.mdf from page 0 to 131072 (0x0 to 0x40000000)
2012-11-22 16:03:10.560 spid51 Zeroing completed on C:\Temp\LargeDB.mdf
2012-11-22 16:03:10.600 spid51 Zeroing C:\Temp\LargeDB.ldf from page 0 to 65536 (0x0 to 0x20000000)
2012-11-22 16:03:17.990 spid51 Zeroing completed on C:\Temp\LargeDB.ldf
2012-11-22 16:03:18.090 spid51 FixupLogTail(progress) zeroing C:\Temp\LargeDB.ldf from 0x5000 to 0x6000.
2012-11-22 16:03:18.090 spid51 Zeroing C:\Temp\LargeDB.ldf from page 3 to 483 (0x6000 to 0x3c6000)
2012-11-22 16:03:18.120 spid51 Zeroing completed on C:\Temp\LargeDB.ldf
Látható, hogy a LargeDB.mdf kinullázása kb. 4 másodperc volt, ami 65536 8KB-os lapot érintett. A transaction log inicializálása 8 másodperc volt és 480 darab 8KB-os lapot érintett. Az időtartam mindig függ a lemezek típusától, számától és a RAID szinttől, illetve az aktuális IO terheléstől is!
Most beállítom, hogy a service account-nak a Perform volume maintenance task jogot és újraindítom az SQL Server szolgáltatást. Ezek után megismétlem a fenti lépéseket.
LogDate ProcessInfo Text
2012-11-22 16:21:49.480 spid51 Zeroing C:\Temp\LargeDB.ldf from page 0 to 65536 (0x0 to 0x20000000)
2012-11-22 16:21:51.690 spid51 Zeroing completed on C:\Temp\LargeDB.ldf
2012-11-22 16:21:51.810 spid51 FixupLogTail(progress) zeroing C:\Temp\LargeDB.ldf from 0x5000 to 0x6000.
2012-11-22 16:21:51.810 spid51 Zeroing C:\Temp\LargeDB.ldf from page 3 to 483 (0x6000 to 0x3c6000)
2012-11-22 16:21:51.840 spid51 Zeroing completed on C:\Temp\LargeDB.ldf
Hűűű, itt már érdekesebb az eredmény: a log file továbbra is kinullázásra kerül és ez tart kb 2 másodpercet, de hová lett az adat file? Hát, ott van az, csak nem kellett kinullázni, így ezért nem látszik az error logban.
Így már látható, hogy miért is olyan fontos ennek az engedélyezése, mit lehet ezzel elérni.
Milyen problémákat vet fel?
A legnagyobb probléma, hogy nem írja felül ez esetben a lemezen tárolt adatokat, így simán visszaolvasható az előzőleg ott tárolt adat – ennek a demója talán majd egy másik alkalommal. Érzékeny adatok estén nem javasolt, sőt PCI DSS esetén szigorúan tilos ennek az engedélyezése.
A demók SQL Server 10.50.2500.0 verzióval készültek.