Snímek databáze poskytuje pohled pouze pro čtení na databázi SQL Server, který je transakčně konzistentní se stavem zdrojové databáze v době, kdy byl vytvořen snímek databáze. Existuje řada důvodů pro použití databázových snímků, například vytváření zpráv proti zrcadlené databázi, a DBCC CHECKDB také používá interní databázové snímky od SQL Server 2005 a novější.
Snímky databáze také umožňují vrátit zpět všechny změny, ke kterým došlo v databázi od vytvoření snímku databáze, ale s nepříjemným vedlejším efektem na transakční protokol databáze, o kterém zde Paul blogoval.
Jedna z věcí, která se u snímků databáze běžně neuvažuje ani neukazuje, je dopad na výkon, který snímek má na pracovní zátěž zápisu do databáze. Tým SQLCAT publikoval whitepaper pro SQL Server 2005, Database Snapshot Performance Accounts in I/O-Intensive Workloads, který zkoumal dopady databázových snímků na výkon, a po nedávné práci s klientem, kde databázové snímky vedly k problémům s výkonem, jsem chtěl otestujte SQL Server 2012 a zjistěte, zda došlo k nějakým změnám v režii snímků databáze po sedmi letech a třech vydáních SQL Serveru.
Test konfigurace
K testování vlivu databázových snímků na výkon zátěže při zápisu jsem použil náš Dell R720, který provedl vložení 1 000 000 řádků do nové tabulky ve zvětšené verzi databáze AdventureWorks2012. Databáze AdventureWorks2012 byla vytvořena s 8 datovými soubory rozmístěnými na dvou 640GB SSD Fusion-io ioDrive Duo, z nichž každý byl nastaven jako dva samostatné 320GB disky ve Windows, což představuje celkem 4 disky. Pro zjednodušení vysvětlení konfigurace je rozložení úložiště použité pro tyto testy uvedeno v tabulce níže:
| Disk | Konfigurace | Použití |
|---|---|---|
| K | 15K disk RAID 5–6 | Snímek |
| L | Fusion-io Card2 – strana B | Soubor protokolu |
| M | Fusion-io Card2 – strana A | 4 datové soubory |
| N | Fusion-io Card1 – strana A | 4 datové soubory |
| Q | Fusion-io Card1 – strana B | Tempdb |
| R | LSI Nytro BLP4-1600 | Snímek |
Tabulka 1 – Rozložení a použití disku serveru
Úložištěm pro snímek databáze bylo buď pole RAID-5 šesti 15k RPM disků SAS připojených přes iSCSI, nebo LSI Nytro BLP4-1600 PCI-E karta.
Testovací pracovní zátěž použila následující příkaz SELECT INTO k vygenerování tabulky s 1 000 000 řádky, která byla mezi jednotlivými testy zrušena.
SELECT TOP 1000000 * INTO tmp_SalesOrderHeader FROM Sales.SalesOrderHeaderEnlarged;
Testy byly načasovány tak, aby změřily dobu trvání bez snímku databáze a poté dobu trvání se snímkem databáze vytvořeným na každém z úložných zařízení, aby se změřilo snížení výkonu způsobené zápisem změn stránky do řídkého souboru snímku databáze. Testy byly také spuštěny pomocí dvou snímků databáze na stejném úložném zařízení, aby se zjistilo, jaká režie může mít dodatečné snímky databáze pro duplicitní operace zápisu, které je případně nutné provést.
Výsledky
Každá konfigurace testu byla provedena desetkrát a průměrná doba trvání, převedená z milisekund na sekundy pro snadnější prohlížení, je uvedena na obrázku 1 pro 0, 1 nebo 2 snímky databáze.
Obrázek 1 – Doba trvání snímku
Základní testy bez databázových snímků byly provedeny v průměru za 1,8 sekundy, ai když úložiště pro soubory databázových snímků mělo ekvivalentní výkon, existence jediného databázového snímku způsobila režii výkonu zápisu do databáze. Režie druhého snímku databáze je nižší než u prvního snímku databáze v každém z testů, ačkoli disky s 15 000 otáčkami za minutu měly mnohem obtížnější udržet krok s přidanou zátěží zápisu z druhého snímku databáze pro databázi.
Výkon na kartě LSI Nytro mě zpočátku překvapil, protože se také jednalo o PCI-X SSD. Po diskusi o výsledcích s Glennem však zmínil, že komprese řadiče Sandforce a pomalejší zápis pro náhodná data s nízkou kompresí z jeho minulých testů na disku. Stále však snadno předčila rotující média.
Před spuštěním testů mě zajímalo, jaké typy čekání nastanou během testů, takže jako součást konfigurace testu jsem vyčistil sys.dm_os_wait_stats pomocí DBCC SQLPERF a zachytil výstup z DMV pro každý testovací běh do tabulky. Nejvyšší čekání na konfigurace jednotlivých snímků byly PREEMPTIVE_OS_WRITEFILE a WRITE_COMPLETION, jak je znázorněno na obrázku 2, pro 1 nebo 2 snímky databáze.
Obrázek 2 – Snímek nejlepších čekání
Jednou ze zajímavých položek bylo přidání čekání FCB_REPLICA_WRITE při vytvoření druhého snímku. Po zkontrolování výsledků čekání na jeden snímek databáze a opětovném spuštění několika kol testů se toto čekání nikdy neobjeví u jediného snímku a nastane pouze v případě, že existuje více než jeden snímek a je spojen s kopírováním stránek do souborů snímku databáze. Čekací doby pro PREEMPTIVE_OS_WRITEFILE se blíží trendu prodlužování doby provádění pro každou z konfigurací.
S ohledem na tyto výsledky může být při kontrole systému pomocí metodologie čekání a front vidět tento typ čekání s vyššími hodnotami užitečné prozkoumat, zda pro některou z databází na serveru existují či neexistují snímky databáze.
Závěr
Při použití databázových snímků, dokonce i v SQL Server 2012, je spojena režie s dodatečnými zápisy potřebnými pro kopírování datových stránek do řídkých souborů pro snímky. Pokud je používání databázových snímků součástí vaší obecné konfigurace, byl bych opravdu opatrný při plánování I/O subsystému tak, aby splňoval požadavky na zátěž pro souběžnou I/O aktivitu s řídkými soubory databázových snímků.
Na základě výsledků těchto testů bych dokonce zvážil umístění snímků databáze na SSD před tempdb kvůli výkonu zápisu a také kvůli nižšímu dopadu údržby snímků na výkon.
Jako vždy se může váš počet najetých kilometrů lišit a určitě budete chtít otestovat výkon jakékoli konfigurace před jejím uvedením do produkčního použití.