Aplikacja nie chciała się uruchomić zgłaszając (i za to brawa dla programisty), że opcja ALLOW SNAPSHOT ISOLATION musi być włączona.
Niby prosta rzecz
ALTER DATABASE ... SET ALLOW_SNAPSHOT_ISOLATION ON
I co? Czekam i czekam… sprawdzam, co blokuje sesję. Wait time to ENABLE_VERSIONING. No dobrze – jeśli to pierwsza baza z tym ustawieniem, to może rzeczywiście coś tam się musi w tempdb przebudować? Ale komenda nie chce się skończyć!
Jak można przeczytać w https://www.sqlskills.com/help/waits/enable_versioning/
“Occurs when SQL Server waits for all update transactions in this database to finish before declaring the database ready to transition to snapshot isolation allowed state. This state is used when SQL Server enables snapshot isolation by using the ALTER DATABASE statement.
No dobrze, ale w mojej bazie nie ma już żadnych połączeń. Co może być nie tak? Nawet checkpoint wyzwoliłem ręcznie, ale nic….
Pora googlować. i trafiony zatopiony – https://social.msdn.microsoft.com/Forums/sqlserver/en-US/60065789-6972-4bf4-b1bd-123967a1db83/enaling-allowsnapshotisolation-hangs-in-sql-2016?forum=sqldatabaseengine
Czy to bug, czy nie – przyczyna znika jeśli na czas wykonania polecenia ALTER wyłaczy się audit. U mnie wystarczyło:
alter server audit ... with (state=off) go alter server audit specification ... with (state=off) go a na zakończenie: alter server audit ... with (state=on) go alter server audit specification ... with (state=on) go
Chociaż na stronie forum pisali:
Seems to be related to the DATABASE_CHANGE_GROUP server audit spec.
If I stopped the server audit, the issue would go away until I restarted the audit.
If I dropped and recreated the server audit, it seemed to fix the issue and the audit would still run
Problem występuje podobno tylko w SQL 2016 i to tylko w specyficznych CU… no to chyba bug?
