Optimalizálása dbcc checkdb
Az Ön felelőssége, mint a DBA, valószínűleg tartalmazza a teljesítmény optimalizálása, a hasznosítás, a hozzáférési jogosultságok beállítása stb. De sokan hajlamosak elfelejteni egy ilyen fontos műveletet ellenőrizni kell az adatbázis integritását (DBCC CHECKDB). Meg lehet oldani ezt a problémát egyszerűen azáltal, hogy karbantartási terv «» Check adatbázis integritását feladat», de ez csak checkdbox.
Mint látható, itt szinte nem képes ellenőrizni semmit, de ez a művelet, sok érdekes gombokat. Azt hiszem, meg kell, hogy merüljön el részletesen a DBCC CHECKDB és hozzon létre saját megfelelő az Ön számára, a munkát. A fő előnye a saját feladat az lenne, hogy csökkentik a működési időt, és ennek következtében a csökkentése szükséges erőforrások a műveletet. Ugyanez lehet előnye, mint a rugalmasság, kezelhetőség, hibakezelés, és így tovább.
A csökkenés a teljesítmény és összegyűjtése a hibák:
Nem számít, hogy hol fut CHECKDB, mindig kezdeni a kívánt opciót NO_INFOMSGS. Ez az egyszerű beállítás megakadályoz minden információs üzenetek, amelyek egyszerűen megmondja, hogy hány sort az egyes táblák, ha szüksége van az információk, akkor kap ez a DMV, az CHECKDB parancsot.
Csak a fizikai adatok ellenőrzéséhez termelési környezetben:
A legtöbb esetben CHECKDB tölti a legtöbb időt a logikai adatérvényesítés. Ha lehetősége van arra, hogy egy ilyen teszt lebonyolítására vonatkozó megbízható adatok másolatát, akkor elsősorban csak a fizikai szerkezete a termelési rendszer. Az autentikus másolatot az adatok, értem csak vissza az adatbázist a backup egy másik szerverre.
Ilyen módszerek például:
- AlwaysOn Szabad csoportok
- Pillanatkép a tetején az adatbázis tükrözés
- naplótovábbítási
- És így tovább.
Nem megbízható másolatot az adatok és a logikai ellenőrzés ezeket a technológiákat, nem ad megbízható eredményt, tekintettel a termelési környezet. Csak pontosan ugyanaz az adatbázis másolatát lehet pontos.
Kísérletek trace flag 2549, 2562 és 2566:
Azt találták, hogy a nyomkövetési zászlókat 2549 és 2562 javíthatja CHECKDB teljesítményét. Keresse meg a leírása ezen zászlókat lehet KB # 2634571. de általában:
Trace Flag 2549 (optimalizálja a folyamat ellenőrzését a számítás, hogy minden egyes adatbázis-adatfájlt saját meghajtóra. A zászló akkor használható, ha az adatbázist adatfájlt vagy adatfájlt a meghajtón, különben ez rontja a teljesítményét CHECKDB)
Ha úgy dönt, hogy használja ezeket a zászlókat, akkor én nagyon ajánlom fordult őket használni DBCC TRACEON keresztül, hanem az indítási paraméterek SQL Server. Ez lehetővé teszi, hogy kapcsolja ki a zászlókat újraindítás nélkül.
Terhelésének csökkentése érdekében a lemez alrendszer (optimalizálás tempdb):
DBCC CHECKDB is erősen betölteni tempdb megpróbálja kiosztani az adatbázisban van elég erőforrás (teszt).
Terhelésének csökkentése érdekében a lemez alrendszer (pillanatkép):
Elindítása DBCC CHECKDB, modern változata az SQL Server teremt rejtett pillanatkép az adatbázis ugyanazon a meghajtón (vagy ugyanazon a lemezen Ha több tempdb fájlok). Nem tudod irányítani ezt a mechanizmust, de ha azt szeretnénk, hogy pontosan meghatározza, hol kell hozzon létre egy pillanatképet, akkor lehet, hogy a snapshot bármilyen meghajtó (csak az Enterprise Edition) és fuss DBCC CHECKDB a pillanatkép. A legjobb, ha ezt a módszert használja az időszakban a minimális aktivitás utáni frissítés az adatbázis.
Akkor felgyorsítja a DBCC CHECKDB fut offline módban (zárak) segítségével a kívánt opciót TABLOCK. Azt javasoljuk, hogy ne használja azt, mivel ez jelentősen rontják a rendelkezésre álló adatbázis.
Terhelésének csökkentése érdekében a CPU:
DBCC CHECKDB fut párhuzamosan az alapértelmezett mód, de csak akkor, ha az Enterprise Edition. Ha van elég CPU erőforrásokat, akkor csökkentheti az átfedést többféleképpen
By Sajnos a Microsoft nem tervezi, hogy hajtsák végre a használat MAXDOP hogy CHECKDB, bár többször kérte.
Saját eredmények:
CHECKDB eredmények ellen 7 GB adatbázis
Aztán növelte az adatbázis mérete 70 GB, és futott a teszt ismét:
CHECKDB eredmények ellen 70 GB adatbázis
A fő gondolatok A vizsgálatok után:
- Amikor futtatom DBCC CKECKDB logikai teszt leküzdésére szerveren:
- A kis adatbázis NO_INFOMSGS opció jelentősen csökkenti a teljesítési időt, amikor fut SSMS. A nagy adatbázisok hatása csökken.
- Mindkét trace flag jelentősen befolyásolta a teljesítményét DBCC CHECKDB (40% -60%, ha együtt használják)
- Amikor futtatom DBCC CKECKDB logikai teszt a másodlagos:
- I. csökkentette a futási idő 70-80% -kal, a harci rendszer.
Szeretném megmutatni a terhelést a CPU alatt vremyaDBCC CHECKDB:
CPU hatása alatt CHECKDB - minta mód
CPU hatása alatt CHECKDB - történeti módban
A nagy adatbázis eredmények változhatnak, ezért el kell végeznie a saját tesztelés.
következtetés:
DBCC CHECKDB egy nagyon fontos és gyakran alábecsült feladat DBA. Ne azt a hibát, hogy más DBA.