Ezt az adatforrást kézzel nem lehet elindítani, be kell állítani, hogy ütemezetten fusson. A háttérben van elegendő joga a futáshoz.
Célszerű úgy beütemezni, hogy naponta fusson le, így napközben meg lehet nézni eredményhalmaz-lekérdezéssel vagy automatikus eseménnyel email-t lehet küldeni az eredményről. A leválogatás most-ot nem szabad megnyomni, mert alkalmazásszerepben futva kiürül az eredmény viszont a feltöltése hibára fog futni. (Ennek a tiltásához vagy "futtatás saját joggal" pipához lehet, hogy kellene egy EH-s fejlesztés majd)
Az eredményben (általában) van egy link, ami útmutatást nyújt a probléma értelmezéséhez.
A következő ellenőrzések futnak most:
- sp_WhoIsActive nincs telepítve. Probléma esetén tanácsadók bele tudnak nézni az SQL szerverbe mi fut, fut-e egyáltalán valami. Szerintem a licensz megengedi https://whoisactive.com/docs/03_license/ "If you’re a developer working on a database-backed application—either for your company or even for resale—and you want to monitor the database using Who is Active, download and enjoy. "
- FirstResponderKit nincs telepítve. Az ellenőrzések egy részét ez végzi. MIT licensz megengedi a használatát, ha feltüntetjük a felhasznált források közt. Ha nem tölti le csak a saját ellenőrzéseink futnak. http://firstresponderkit.org. Az innen származó üzenetek egy része angol nyelvű, igyekszem majd fordítani.
- Alapértelmezéstől eltérő sql beállítások. Azokat az eltéréseket nem mutatjuk, amit mi állítottunk át. Ajánlott eltéréseket az alapértelmezéstől lentebb részletezem.
- cost threshold for parallelism alapértelmezett értékét (5) célszerű magasabbra (>200) állítani. Az alapértelmezést 1997-ben állították be egy akkori PC-n, már nem aktuális.
- backup checksum A mentés integritásellenőrzésére szolgál, nincs értelme nem bekapcsolni.
- backup compression Tömörített mentés bekapcsolása. Kicsit több CPU-t használ, de ha utána úgyis tömörítenénk miért ne tennénk meg azonnal. Kevesebb helyet használ, gyorsabban megy át a hálózaton. Érdemes rögtön hálózati meghajtóra menteni, így teljesül, hogy nem ugyanoda kerül, ahol az adataink is vannak.
- kerülendő szerver beállítások
- min memory = max memory Ha a memóriafoglalás eléri ezt a szintet, akkor megáll a dinamikus foglalás/felszabadítás. Nincs értelme a min memory-t állítgatni.
- max memory > fizikai memória Ha a fizikai memória méretétől magasabbra állítjuk, akkor a Windows virtuálismemória kezelése is beleszólhat. Ezt nem akarjuk.
- auto-close on Durva lassulást okozhat, mert inaktivitás esetén diszkre írja az állapotot és törli a cache-t. Ha ismét használni akarjuk az adatbázist nagyjából az történik, mint a gép újraindítása után. Nagyon ritkán használt adatbázisnál lehet esetleg értelme.
- auto-shrink on Az adatbázisfájl méretének gyakori növelése/csökkentése kerülendő, mert érezhető teljesítménycsökkenést okoz. ("egy-egy pillanatra megáll az élet") Jobb, ha mindig van szabad hely az adatbázisban. Ha "véletlenül" indokolatlanul nagyra nő az adatbázis, akkor kézzel kell shrinkelni ésszerű (maradjon szabad hely a várható növekedésre) méretre.
- 10%-nál kevesebb hely van az MDF fájlok meghajtóján
- Az adatbázis automatikus növelése be van korlátozva / ki van kapcsolva. Ha eléri a méretet/betelik garantált hibaüzeneteket eredményez.
- Hibás állapotban lévő ütemezett feladatok vannak az adatbázisban. Pillanatnyilag szkripttel lehet javítani HibasConversationLezaras.sql
- Sok függőben lévő feladat vár a queue-ban (segíthet az előző szkript)
- valamelyik queue áll.
- nem célszerű ugyanarra a diszkre menteni, mint amin az adatok vannak. Bekapcsolt tömörítést mellett hálózati meghajtóra történő mentés sem lassabb és az adatbiztonság is jobb.
- régi/ nincs mentés
- valamikor korábban dumpolt (exception-el elszállt) az sql szerver. Általában sql server frissítés segít a problémán. RPM verzióknál gyakoribb. Utána kell járni, mert akár adatvesztéssel is járhat.
