Wymuszenie limitu czasu zapytania w SQL Server

Question

Wystąpił problem z blokiem kodu, który reaguje słabo w obliczu powolnych baz danych ("Craps the bed on a query timeout"). Stworzyliśmy łatkę i jesteśmy w trakcie jej uruchamiania poprzez regresję.

Nie możemy uzyskać limitu czasu. Otworzyłem transakcję z SQL Mgmt Studio i zaktualizowałem każdy wiersz, aby je zablokować, ale to nie powoduje INSERTs do limitu czasu (który jest tym, czego potrzebuję).

Czy można uzyskać blokadę na poziomie stołu za pomocą T-SQL? Czy muszę się bawić w mistrza? Czy mogę łatwo wymusić timeout bez blokowania? Dowolne wejście jest doceniane.

Answer 1

run to a następnie spróbować insert ...

select * from yourTable with (holdlock,tablockx) 

tutaj, można zablokować go przez 5 minut:

BEGIN TRANSACTION 

SELECT * FROM yourTable WITH (TABLOCKX, HOLDLOCK) 

WHERE 0 = 1 

WAITFOR DELAY '00:05' 

ROLLBACK TRANSACTION 

Answer 2

Można tylko powiedzieć kodu SQL, aby czekać na minutę przed powrotem:

WaitFor Delay '00:01:00' 

Answer 3

Zobacz ten post na blogu. Zasadniczo SQL Server nie ma limitu czasu zapytania. Klienci mogą wymuszać limit czasu SQL, ale sam silnik nie.

http://blogs.msdn.com/khen1234/archive/2005/10/20/483015.aspx

Answer 4

Na stronie Wskazówka: Jeśli połączenie jest konfigurowalny, zmniejszyć limit czasu połączenia ciąg do 1 sekundy - to ułatwi. Wypełnij tabelę wieloma danymi, a 3 inne procesy zakręcają w pętli aktualizując fragmenty tej tabeli z transakcją wokół pętli. Nie zmieniaj rzeczywistej procedury wywoływanej przez aplikację (wstrzykiwanie waitfor). To unieważnia test integracji.

Ale tak naprawdę jest to studium przypadku na korzyść testów jednostkowych i zastrzyku zależności. Niektóre rzeczy są trudne do testu integracyjnego. Test jednostkowy + dependency injection.

• Prawdziwe: Kod, który craps -> Limit czasu bazy danych (trudny do odtworzenia).
• Refactor: Kod że kości -> Repository (ma dostępu do danych tylko) -> Database
• Test Jednostka: kod, który Kości>Mock repository rzucać -> NULL
• Teraz masz uszkodzoną test kodu kości i może to naprawić.

To jest zastrzyk "zależny". Dev może wstrzyknąć zależność do bazy danych, zastępując coś, co symuluje zachowanie zależności. Dobrze zrobić dla wszystkich testów bazy danych. W każdym razie, z testem jednostkowym, wiesz, że poprawka robi coś, co powinna, ale nadal potrzebujesz testów integracyjnych. W takim przypadku lepiej skupić się na regresji - co oznacza, że ​​testowanie nie spowodowało niczego innego, a funkcja nadal działa.

Utworzono już poprawkę, więc sądzę, że moja odpowiedź jest za późna.