Jakie ryzyko istnieje, jeśli umożliwimy odczytanie zatwierdzonej migawki na serwerze SQL?

Przeczytałem tutaj, że niektóre dodatkowe dane będą przechowywane w wierszu, więc możemy zaobserwować spadek wydajności, ale jakie są inne zagrożenia?

na przykład. Czy wpłynie to na odzyskiwanie bazy danych? Czy jest coś jeszcze, co musimy zrobić, aby z tego skorzystać?

Planuję wykonać następujące polecenia:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

Wierzę, że da nam to coś bliższego wyroczni, gdzie jeśli jedna transakcja aktualizuje, inne transakcje mogą nadal czytać stare dane. Czy to jest poprawne?

Rozważam to, ponieważ mam dość problemów z blokowaniem w SQL Server 2005. Mam nadzieję, że może to zmniejszyć sporadyczne impasy, które widzą nasi użytkownicy, poprawić ogólną wydajność naszej aplikacji i zachęcić naszych programistów do wykonania więcej niż jednej operacji na transakcję bez strach.

Podsumowanie

1. Jeśli masz problemy z blokowaniem, masz problem z kodem: to nie jest silnik bazy danych
2. To nie jest magiczna kula
3. Możesz dodać więcej problemów

Obciążenie

Zwiększy to także obciążenie twojego tempdb i procesora . Zobacz także:

• „Wpływ na wydajność: potencjalny koszt Read_Committed_Snapshot” (Linchi Shea)

Bezpieczeństwo

Co najważniejsze, izolacje migawkowe nie są w wielu przypadkach domyślnie bezpieczne . Przeczytaj „Izolacja migawki” (Wikipedia), aby uzyskać więcej informacji na temat anomalii skosu zapisu. Następna sekcja to „Making Serializable Snapshot Isolation”, aby obejść ten problem.

Ogólnie rzecz biorąc, izolacja migawek nakłada część problemu utrzymania nietrywialnych ograniczeń na użytkownika, który może nie docenić ani potencjalnych pułapek, ani możliwych rozwiązań. Zaletą tego transferu jest lepsza wydajność.

Zobacz także:

• „Potencjalne niebezpieczeństwa związane z odczytanym poziomem izolacji migawki” (JimMcLeod, kwestionowany w komentarzach Alexa Kuzniecow)
• Deadlocked !: „przeczytaj zatwierdzoną migawkę” Objaśnienie (Nick Berardi)
• Serializable vs. Snapshot Isolation Level, the Marble problem (Craig Freedman)
• Odczyty dotyczące UDF pod READ_COMMITTED_SNAPSHOT mogą wydawać się niespójne (Alex Kuznetsov)

Wiem, że to stary wątek, ale powiedziałbym, że izolacja migawek w dużym stopniu jest magiczną kulą. Wyeliminuje to całe blokowanie czytelników i pisarzy. To jednak będzie nie zapobiega blokowaniu innych pisarzy pisarzy. Nie można tego obejść.

Z mojego doświadczenia wynika, że ​​dodatkowe obciążenie TEMPDB jest znikome, a korzyści wynikające z wersjonowania wierszy w zmniejszaniu zablokowanych czytników są ogromne.

Dla porównania, wersjonowanie wierszy (izolacja migawki) to metoda stosowana przez Oracle od dziesięcioleci w celu uzyskania izolacji bez blokowania czytników, a bazy danych Oracle, nad którymi pracowałem przez prawie 20 lat, mają znacznie mniej problemów z blokowaniem niż SQL Server. Jednak większość programistów SQL waha się przed izolacją migawek, ponieważ przetestowali swój kod tylko w bazach danych, które używają ustawienia domyślnego.

Kilka dodatkowych punktów do dodania do innych odpowiedzi:

SET ALLOW_SNAPSHOT_ISOLATION ONumożliwia tylko izolowanie migawek w bazie danych. Aby z niego skorzystać, należy przekodować i SET TRANSACTION ISOLATION LEVEL SNAPSHOTdla transakcji, których ma dotyczyć. Kod wywołujący musi zostać zmieniony, aby obsługiwać błędy konfliktu aktualizacji.

Po SET READ_COMMITTED_SNAPSHOT ONzatwierdzeniu instrukcji w trakcie odczytu użyj wersji wiersza. Uwaga: jest to wersja wierszowania na poziomie instrukcji tylko do odczytu . W przypadku aktualizacji pobierany jest „prawdziwy” wiersz i stosowane są blokady aktualizacji. Zobacz sekcję Podsumowanie zachowania w Zrozumienie poziomów izolacji opartych na wersjach wierszy

Niezależnie od trasy, bez wyczerpujących testów, prawdopodobnie wprowadzisz do systemu zupełnie nowy zestaw problemów.

Wierzę, że da nam to coś bliższego wyroczni, gdzie jeśli jedna transakcja aktualizuje, inne transakcje mogą nadal czytać stare dane. Czy to jest poprawne?

Tak, to prawda .

Warto przeczytać linki w odpowiedzi gbn i uważam, że to samo dotyczy domyślnego MVCC Oracle, jak i SQL Server w trybie izolacji migawki. Dodałbym, że jeśli rozumiesz potencjalne pułapki, korzyści IMO znacznie przewyższają dodatkowe trudności (mówiąc z perspektywy Oracle) - i oczywiście niektóre problemy z blokowaniem legalnie znikają, to jest sedno MVCC (istnieje również klasa blokowanie problemów, które nie znikną z powodu problemów z kodem, ale zakładam, że to rozumiesz).

Używamy SNAPSHOT ISOLATION we wszystkich naszych projektach korzystających z SQL Server DB. Nigdy więcej 1205 błędów SQL, które nie są spowodowane niewłaściwym kodem aplikacji, ale domyślnym blokowaniem stron i blokowaniem wierszy.

Wpływ na wydajność jest minimalny i do tej pory minęło 7 lat, setki milionów operacji zostały przetworzone w różnych systemach, bez problemów związanych z izolacją SNAPSHOT.

Sytuacje, w których kilka różnych wątków aktualizuje kluczowe informacje biznesowe w jednym rzędzie równolegle, są wyjątkowo wyjątkowe, a szanse, że SNAPSHOT ISOLATION będzie przyczyną wszelkich problemów z niespójnością, są bardzo bliskie zeru.

Jeśli masz system OLTP, który przez projekt aktualizuje pojedynczy wiersz na podstawie bieżących danych wierszy w wielu wątkach, oczywiście SNAPSHOTS nie są w takich przypadkach dopuszczalne.

mieliśmy ją aktywną, a dziwna instrukcja select sql działająca na 4 blokowała cały db bez względu na liczbę rdzeni i wszystkich. Wyłączenie RCSI naprawiło to. Chciałbym włączyć go, gdy napotkasz inne zakleszczenia, nie domyślnie.