Database
 sql >> Baza danych >  >> RDS >> Database

Przestarzałe funkcje do wyjęcia z przybornika – część 1

Microsoft nie ma w dzisiejszych czasach zwyczaju deprecjonowania pewnych rzeczy, ale kiedy to robią, to z jakiegoś powodu – i na pewno nie dlatego, że chcą utrudnić ci życie. Wręcz przeciwnie, prawie zawsze dzieje się tak dlatego, że opracowali lepsze i nowocześniejsze sposoby rozwiązywania tych samych problemów.

Ale przyzwyczajenia są trudne do złamania; zapytaj, skąd wiem. Zbyt często widzę ludzi trzymających się starszego sposobu wykonania jakiegoś zadania, nawet jeśli istnieje lepszy sposób.

Chciałbym podzielić się kilkoma ostatnimi przykładami, które pomogą nam zilustrować, w jaki sposób używanie przestarzałych funkcji SQL Server nadal nas gryzie. W tej pierwszej części chcę omówić…

procesy systemowe

Tabela systemowa sys.sysprocesses został zastąpiony w SQL Server 2005 przez zestaw dynamicznych widoków zarządzania (DMV), w szczególności sys.dm_exec_requests , sys.dm_exec_sessions i sys.dm_exec_connections . Oficjalna dokumentacja sys.sysprocesses ostrzega:

Ta tabela systemowa programu SQL Server 2000 jest dołączona jako widok zapewniający zgodność z poprzednimi wersjami. Zamiast tego zalecamy używanie bieżących widoków systemowych programu SQL Server. Aby znaleźć równoważny widok systemowy lub widoki, zobacz Mapowanie tabel systemowych do widoków systemowych (języka Transact-SQL). Ta funkcja zostanie usunięta w przyszłej wersji Microsoft SQL Server. Unikaj używania tej funkcji w nowych pracach programistycznych i zaplanuj modyfikowanie aplikacji, które obecnie korzystają z tej funkcji.

Niedawny przykład

Niedawno jeden z naszych zespołów badał problem z opóźnieniem czytnika dzienników. Zwracamy tutaj dużą uwagę na opóźnienia, a także wszelkie długotrwałe transakcje, ze względu na wpływ na technologie korzystające z czytnika dzienników — takie jak grupy dostępności i replikacja transakcyjna. Nasze pierwsze ostrzeżenia są zwykle widoczne na pulpicie nawigacyjnym, który przedstawia opóźnienie czytnika dziennika w stosunku do czasu trwania transakcji (wyjaśnię momenty, w których oznaczyłem t0 i t1 wkrótce):

Ustalili, powiedzmy w czasie t0 , że pewna sesja miała otwartą transakcję blokującą proces odczytu dziennika. Najpierw sprawdzili dane wyjściowe DBCC INPUTBUFFER , aby spróbować określić, jak trwała ta sesja, ale wyniki po prostu wskazywały, że podczas transakcji wyemitowano również inne partie:

event_type       parameters   event_info
--------------   ----------   ---------------
Language Event   0            SET ROWCOUNT 0;

Zauważ, że DBCC INPUTBUFFER ma również bardziej wydajny zamiennik w nowoczesnych wersjach:sys.dm_exec_input_buffer . I chociaż nie ma wyraźnego ostrzeżenia o wycofaniu, oficjalna dokumentacja DBCC polecenie ma to delikatne pchnięcie:

Począwszy od programu SQL Server 2014 (12.x) z dodatkiem SP2, użyj sys.dm_exec_input_buffer do zwrócenia informacji o instrukcjach przesłanych do wystąpienia programu SQL Server.

Po otrzymaniu niczego z bufora wejściowego zapytali sys.sysprocesses :

SELECT 
  spid, 
  [status], 
  open_tran, 
  waittime, 
  [cpu], 
  physical_io, 
  memusage, 
  last_batch
FROM sys.sysprocesses 
WHERE spid = 107;

Wyniki były podobnie bezużyteczne, przynajmniej jeśli chodzi o określenie, co robiła sesja, aby utrzymać otwartą transakcję i zakłócić działanie czytnika dziennika:

Zaznaczam physical_io kolumna, ponieważ ta wartość wywołała dyskusję na temat tego, czy chcą zaryzykować zabicie sesji spania. Pomyślano, że w przypadku, gdy wszystkie fizyczne operacje we/wy są zapisami, zabicie transakcji może skutkować długotrwałym i destrukcyjnym wycofaniem — potencjalnie jeszcze pogorszy problem. Nie zamierzam podawać rzeczywistych czasów, ale powiedzmy, że przekształciło się to w dłuższą rozmowę i pozostawiło system w tym stanie od czasu t0 do czasu t1 na powyższym wykresie.

Dlaczego to jest problem

Problem w tym konkretnym przypadku polega na tym, że spędzili ten czas na rozważaniu decyzji opartej na niekompletnych informacjach. Czy te wejścia/wyjścia odczytują lub zapisują? Jeśli użytkownik ma otwartą transakcję i tylko przeczytał dużo danych, wycofanie tej transakcji ma znacznie mniejszy wpływ, niż gdyby zmienili dużo danych. Więc zamiast sys.sysprocesses , zobaczmy, co bardziej nowoczesny DMV, sys.dm_exec_sessions , może pokazać nam tę sesję:

SELECT 
  session_id, 
  [status], 
  open_transaction_count, 
  cpu_time, 
  [reads], 
  writes, 
  logical_reads, 
  last_request_start_time,
  last_request_end_time
FROM sys.dm_exec_sessions 
WHERE session_id = 107;

Wyniki:

Tutaj widzimy, że sys.dm_exec_sessions rozkłada fizyczne I/O oddzielnie na odczyty i zapisy. Dzięki temu możemy podjąć bardziej świadomą decyzję, znacznie szybciej niż t1 - t0 , o potencjalnym wpływie wycofania. Jeśli wszystkie I/O są zapisane i w zależności od tego, jak wysoka jest ich liczba, możemy się trochę bardziej wahać i być może poświęcić czas na zlokalizowanie użytkownika (abyśmy mogli uderzyć go w dłonie lub zapytać, dlaczego mają otwartą transakcję ). Jeśli wiemy, że to głównie odczyty, możemy zamiast tego skłonić się do zabicia sesji i wymuszenia wycofania transakcji.

Jasne, sys.sysprocesses ma dbid i waittime . Ale dbid i tak jest niewiarygodne i marginalnie przydatne, szczególnie w przypadku zapytań między bazami danych; jest dużo lepsze informacje w sys.dm_tran_locks . Informacje o oczekiwaniu (czas i typ ostatniego oczekiwania) można znaleźć w sys.dm_exec_requests , ale znacznie bardziej szczegółowe informacje są dostępne w sys.dm_exec_session_wait_stats (dodane w SQL Server 2016). Często słyszałem wymówkę, że sys.dm_exec_sessions brakowało open_tran , ale open_transaction_count został ponownie dodany w SQL Server 2012. Nie ma więc powodu, aby nawet myśleć o użyciu sys.sysprocesses dzisiaj.

Jeśli chcesz dowiedzieć się, jak często sys.sysprocesses zostało przywołane od czasu ostatniego ponownego uruchomienia programu SQL Server, możesz uruchomić to zapytanie względem liczników wydajności DMV:

SELECT instance_name, cntr_value
  FROM sys.dm_os_performance_counters
  WHERE [object_name] LIKE N'%:Deprecated Features%'
    AND instance_name = N'sysprocesses' 
  ORDER BY cntr_value DESC;

Jeśli naprawdę chcesz uniknąć snu tej nocy lub po prostu chcesz stale dodawać do listy rzeczy, o które się martwisz, usuń predykat z instance_name . To da ci przerażające, ogólne pojęcie o tym, ile rzeczy działają w twoich instancjach, które w końcu będziesz musiał zmienić.

W międzyczasie pobierz sp_WhoIsActive , niezwykle użyteczna procedura składowana Adama Machanica do monitorowania i rozwiązywania problemów z procesami SQL Server w czasie rzeczywistym. Wdrożyliśmy tę składowaną procedurę w każdej instancji w naszym środowisku i Ty też powinieneś, niezależnie od innych zaawansowanych narzędzi do monitorowania, których możesz również używać.

Następnym razem

W części 2 opowiem trochę o SQL Server Profiler, aplikacji, której ludzie używają częściej ze względu na znajomość niż cokolwiek innego – nie zdając sobie sprawy, jak niebezpieczna może być.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Zarządzanie transakcjami z Django 1.6

  2. Czy operator łańcucha „+” jest tak prosty?

  3. Jak zaktualizować kolumnę na podstawie filtra innej kolumny?

  4. Współpraca z JDBC i Spring

  5. Unikanie rozwiązywania problemów z wydajnością Knee-Jerk