Zacznijmy od niegroźnego polecenia
CHECKPOINT
Powoduje ono uruchomienie procesu CHECKPOINT polegającego na przepisaniu „brudnych stron” z bufora SQL Serwera na dysk. Domyślnie czynność ta wykonuje się sama, bez naszej ingerencji, a wpływ ma na nią opcja serwera 'Recovery Interval’. Jeżeli chcesz aby baza danych po awarii odtwarzała się szybciej to zmniejsz recovery interval. Chceckpointy będą występować częściej. Można śledzić kiedy dochodzi do systemowego CHECKPOINTA poprzez pefrmon.
Polecenie CHECKPOINT uruchamiane z ręki wywołuje zapis tylko dla bieżącej bazy danych.
Drugie nietypowe polecenie to KILL. Argumentem dla tego polecenia jest numer ID połączenia, który zamierzasz zabić np
KILL 56
zamknie sesję numer 56. Możesz np w ten sposób przerwać przebudowę indeksu, jeżeli trwa ona za długo, jednak pamiętaj. Przebudowa indeksu jest transakcją i jej wycofanie… również będzie trwało. Dlatego nim zabijesz taki proces spróbuj zbadać ile czasu będzie trwało wycofywanie tego zadania poprzez:
KILL 56 WITH STATUSONLY
Polecenie wyświetli tylko informacje o tym ile będzie trwało wycofywanie danej czynności, bez jej aktualnego wycofnia.
Ostatniego polecenia z tej serii nie uruchamiaj dla testu na maszynie produkcyjnej, gdyż jest to polecenie:
SHUTDOWN
Spowoduje ono wyłączenie serwera. Wyłączenie będzie miało jak najbardziej poprawny przebieg tzn. przed zamknięciem SQL Servera wykona się CHECKPOINT na każdej bazie danych, co też może potrwać. Można jednak wywołać polecenie
SHUTDOWN WITH NOWAIT
i wtedy CHECPOINTY się nie wykonają, ale za to dłużej będzie trwało włączanie bazy danych. Krótko mówiąc coś za coś…
