it-swarm.dev

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, abyśmy mogli 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 Oracle, 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.

73
Adam Butler

Podsumowanie

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

Załaduj

Zwiększy to również obciążenie tempdb i CPU . Zobacz także:

Bezpieczeństwo

Najważniejsze, izolacje migawek nie są bezpieczne w wielu przypadkach domyślnie. 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:

49
gbn

Wiem, że to stary wątek, ale powiedziałbym, że w dużym stopniu izolacja migawek is magiczna kula. To wyeliminuje wszystkie twoje blokowanie między czytelnikami a pisarzami. To jednak nie uniemożliwi pisarzom blokowanie innych 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 i baz danych Oracle, nad którymi pracowałem przez prawie 20 lat doświadczenia daleko mniej problemów z blokowaniem niż SQL Serwer ma. 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.

36
Chuck

Kilka dodatkowych punktów do dodania do innych odpowiedzi:

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

Po SET READ_COMMITTED_SNAPSHOT ON, instrukcje w trakcie odczytu zatwierdzone używają wersji wiersza. Uwaga: jest to poziom instrukcji wersjonowanie wierszy dla 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

W obu przypadkach bez wyczerpujących testów prawdopodobnie wprowadzisz do systemu zupełnie nowy zestaw problemów.

26

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

Tak, to jest poprawne .

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, w różnych systemach przetworzono setki milionów operacji, bez żadnych problemów związanych z izolacją SNAPSHOT.

Sytuacje, w których kilka różnych wątków aktualizuje krytyczne informacje biznesowe w jednym rzędzie równolegle, są wyjątkowo wyjątkowe, a szanse, że SNAPSHOT ISOLATION będzie przyczyną każdego problemu niespójności, są bardzo zbliżone do zera.

Jeśli masz system OLTP), który przez projekt aktualizuje pojedynczy wiersz w oparciu o bieżące dane wiersza w wielu wątkach, oczywiście SNAPSHOTS nie są w takich przypadkach dopuszczalne.

10