augusztus 2014 havi bejegyzések

SQL Server maintenance sorrend

Erre minden adatbázisnak szüksége van. Amikből lehet válogatni:

  1. DBCC CHECKDB
  2. Shrink database
  3. Index rebuild
  4. Index reorganize
  5. Update statistics
  6. Cleanup history
  7. Backup database
  8. Maintenance cleanup task

Egyszer megkérdezték tőlem, hogy szerintem mi a megfelelő sorrend (az nem volt opció, hogy mit hagyjunk ki), amire azt válaszoltam, hogy “attól függ”. Erre megkaptam, hogy “olyan nincs”. Pedig az attól függ sok mindenre jó megkerülő válasz 🙂

No, de komolyan gondoltam a válaszom. Szóval mitől is függ? A körülményektől.
Mielőtt a körülményekre térnék, nézzük meg nagy vonalakban, hogy melyik mire jó.

  1. DBCC CHECKDB: Az adatbázis konzisztencia problémákat hivatott jelezni, kijavítani. Nagy hátránya, hogy felolvassa a diszkről az adatbázis összes lapját, így szépen ki is takarítja a memóriát. Nagy teljesítményű szervereken product környezetben veszélyes a használata. Ha esetleg futtatni akarjátok, akkor nem szükséges napi szinten.
  2. Shrink database: Egyetlen használható formája a TRUNCATEONLY kapcsoló, egyébként ezt a parancsot messziről kerülni kell. Tökéletesen alkalmas arra, hogy szanaszét tördelje az indexeket és az adatbázis fájlokat. Mellesleg arra jó, hogy csökkentse az adatfájlok méretét a diszken.
  3. Index rebuild: Ez a parancs végzi az indexek karbantartását és nélkülözhetetlen az adatbázisok megfelelő működéséhez. Lehet online és offline futtatni. Az online csak enterprise és developer edition-ok alatt érhető el. Az online azt jelenti, hogy “jó eséllyel online”, ugyanis simán összeakadhat egyéb tranzakciókkal (Láttam már olyat, hogy deadlock-ba keveredett egy user processzal), bár nem ez a jellemző. Az offline alatt nem érhető el a tábla, legalábbis onnantól, hogy beérkezik az első adatmódosító utasítás (insert, update, delete). Ami fontos, hogy ha full recovery modellben van az adatbázis, akkor nagyra duzzadhat a tranzakciós log, tehát erre különösen figyelni kell.
  4. Index reorganize: Az index rebuild kistestvére. Annyit csinál, hogy az index levél lapjait rakja sorba. Minden sql szerver edition-ön lehet futtatni és online. Az online itt is azt jelenti, hogy “jó eséllyel online”, ugyanis ezt is láttam már, hogy deadlockba futott. Kell róla tudni, hogy nem lehet örökké csak ezt használni (mert ugye az indexek közbenső lapjait nem rakja rendbe). Vannak mindenféle számok, a neten, pl: 30%-os töredezettség felett az index rebuil-ot futtassuk, alatta pedig a reorganize-t. Ezt mindenkinek magának kell eldöntse, hogy hol húzza meg a határt (erősen függhet az adatbázistól is), ha egyáltalán húz ilyen határt.
  5. Update statitics: Az oszlopok, indexek statisztikáját lehet frissíteni, ami az optimalizáló számára fontos a hatékony működéshez. Ha nem fullscan módban használjuk, akkor csak egy százalékos statisztikát gyűjt, aminek sok értelme nincs, ha meg fullscan-el használjuk, akkor az szintén kitakarítja a memóriát a nagy méretű tábláknál. Tehát ezzel a paranccsal is csínján kell bánni. Ez a maintenance task nálam másodjára ott verte ki a biztosítékot, amikor a system adatbázisokra beállítottam és simán hozzáadott a cpu használathoz 15-20%-ot, a batch request-hez meg kb. 1.500-at.
  6. Cleanup history: Amikor maintenance fut, akkor arról készül bejegyzés az msdb adatbázisa. Ha ezeket a bejegyzéseket nem takarítjuk, akkor az msdb adatbázis folyamatosan növekedni fog. Tehát ez is fontos.
  7. Backup database: Az adatbázisok mentésére szolgál és szintén nélkülözhetetlen parancs, bár ez nem a működéshez kell, hanem egy esetleges helyreállításhoz.
  8. Maintenance cleanup task: A segítségével tudunk a diszkről fájlokat (backup, txt, stb) törölni. Pl: be tudjuk állítani, hogy a 10 napnál régebbi backup-okat törölje a diszkről.

 

Visszatérve a körülményekhez. Ha van 1 szerverem, ahol bőven van hely és memória, esténként nincsenek felhasználók, akkor beállítom a fenti 8 parancsot, a fent írt sorrendben a 2-es kivételével, mert azt kihagyom, mivel a 2-es az közellenség.
Ha nincs elég hely a diszken, akkor előbb a fájlokat törlöm és csak utána futtatok backup-ot.
Ha egy business critical adatbázisról van szó, ami 7×24-ben kell menjen, akkor a DBCC CHECKDB jó eséllyel repül a kukába.
Ha nagy terheltségű a szerver, akkor az update statistics is megy utána.
Ez néhány eset volt, viszont ennél sokkal több körülmény van / lehet, amit figyelembe kell venni.

Az a szép az informatikában, hogy nem mindenre ugyanaz a válasz (kivéve a 2-esre, mert a 2-es az közellenség). Gondolkodni kell, hogy mit és hogyan építsünk fel, hogy megfeleljen a körülményeknek és az üzleti igényeknek.