Nie można kontynuować skanowania za pomocą NOLOCK z powodu przenoszenia danych

10

Korzystamy z programu SQL Server 2000 i co wieczór otrzymujemy kilka takich błędów.

Could not continue scan with NOLOCK due to data movement

Zapytanie zgłaszające ten błąd jest dużym złożonym zapytaniem, które łączy kilkanaście tabel. Nasze podstawowe dane mogą być często aktualizowane.

Kulturowa „najlepsza praktyka” polega na tym, że w przeszłości wprowadzanie NOLOCKwskazówek zwiększyło wydajność i poprawiło współbieżność. To zapytanie nie musi być w 100% dokładne, tzn. Będziemy tolerować nieczytelne odczyty itp. Jednak staramy się zrozumieć, dlaczego baza danych generuje ten błąd, mimo że mamy wszystkie te wskazówki blokujące.

Czy ktoś może rzucić na to trochę światła - bądź łagodny, właściwie jestem programistą, a nie DBA :)

PS: Zastosowaliśmy poprawkę wymienioną wcześniej: http://support.microsoft.com/kb/815008

Ciaran Archer
źródło
3
Upuszczę NOLOCK i naprawię zapytanie / indeksy / proces. Oczywiście możemy pomóc ... Zobacz także: en.wikipedia.org/wiki/Halloween_Problem
gbn
3
@SQLKiwi: SQL 2012 odzyskuje wdzięcznie w wielu przypadkach przenoszenia danych podczas brudnych skanów (ciąg dalszy na następnej stronie w kolejności przydzielania).
Remus Rusanu,
1
@SQLKiwi: tak, nadal istnieją. Dobra wiadomość: również kursory wspierane przez brudne skany powinny sobie z tym poradzić z wdziękiem.
Remus Rusanu,

Odpowiedzi:

7

Jest to dość dobrze znany problem z SQL Server 2000 - zasadniczo dzieje się tak, jeśli wiersz zostanie usunięty przez proces A, podczas gdy proces B wykonuje skanowanie (albo w READ UNCOMMITTEDalbo WITH (NOLOCK)), wtedy proces B przechodzi „huh, co się stało z tymi danymi „kiedy próbuje to przeczytać. Dokładniej, wiersz musi zostać usunięty po odczytaniu indeksu przez proces B, ale przed próbą odczytania wiersza danych.

Craig Freedman dobrze tu pisze

Na szczęście poprawka jest stosunkowo prosta: http://support.microsoft.com/kb/815008

Jeśli to nie zadziała, masz nieco bardziej bolesną opcję usunięcia wszystkich WITH (NOLOCK)podpowiedzi i ustawienia poziomu izolacji transakcji na coś powyżej READ UNCOMMITTED.

Simon Righarts
źródło
Jesteśmy na bieżąco z tą poprawką - zastosowaliśmy flagę, uruchomiliśmy ją ponownie i nadal otrzymujemy te błędy.
Ciaran Archer,