Był sobie job, który miał wykonać DBCC dla wszystkich baz znajdujących się na serwerze. Job kończył się komunikatem:
The database could not be exclusively locked to perform the operation. [SQLSTATE 42000] (Error 5030) Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details. [SQLSTATE 42000] (Error 7926). The step failed.Co się stało? Kiedy uruchamiasz DBCC, SQL w pierwszej kolejności próbuje utworzyć snapshot sprawdzanej bazy danych i tworzy go w katalogu, w którym znajduje się baza danych. W moim przypadku z pewnego powodu (o tym dalej) snapshot nie mógł być utworzony. W takim przypadku DBCC przechodzi w inny tryb pracy. Po kolei próbuje zakładać lock na każdy z obiektów w bazie danych i go sprawdza. Powoduje to duży rozrost tempdb i na dodatek może się nie udać jeżeli na bazie pracują inni użytkownicy. Tymczasem metoda ze snapshotem jest zaprojektowana pod kątem umożliwienia sprawdzenia bazy przy jednoczesnej pracy wielu użytkowników.
Rozwiązaniem polecanym na wielu forach poświęconych SQL jest nadanie uprawnień Full Control do dysku na którym znajduje się baza danych. Prosta sprawa – nadajesz uprawnienia na dysk, potem zaglądasz do wszystkich folderów jeżeli dziedziczenie uprawnień jest gdzieś złamane, to nadajesz je indywidualnie.
Sęk w tym, że u mnie to nie pomogło. Przyczyną było to, że dane umieszczone były na dyskach montowanych do katalogów:
Uprawnienia do dysków możesz dodawać także wykorzystując przystawkę do zarządzania dyskami:
Dla każdego dysku wykorzystywanego przez SQL należy nadać uprawnienia full control dla konta usługi SQL. Po tych zmianach
a potem zakładka Security:
