it-swarm.dev

Jak mogę powiedzieć DLACZEGO wkładka do określonego stołu jest wolna?

Wiem, że INSERT w tabeli SQL może być powolny z wielu powodów:

  • Istnienie INSERT TRIGGERs na stole
  • Wiele wymuszonych ograniczeń, które należy sprawdzić (zwykle klucze obce)
  • Strona dzieli się w indeks klastrowany, gdy wiersz jest wstawiany na środku tabeli
  • Aktualizowanie wszystkich powiązanych indeksów nieklastrowych
  • Blokowanie innych działań na stole
  • Słaba IO czas zapisu zapisu
  • ... coś mi umknęło?

Jak mogę określić, która jednostka jest odpowiedzialna w moim konkretnym przypadku? Jak mogę zmierzyć wpływ podziału strony na aktualizacje indeksów nieklastrowanych i wszystko inne?

Mam zapisany proc, który wstawia około 10 000 wierszy na raz (z tabeli tymczasowej), co zajmuje około 90 sekund na 10 000 wierszy. Jest to niedopuszczalnie wolne, ponieważ powoduje przekroczenie limitu czasu przez inne pająki.

Przejrzałem plan wykonania i widzę zadanie INSERT CLUSTERED INDEX oraz wszystkie INDEX SEEKS z wyszukiwania FK, ale wciąż nie mówi mi to na pewno, dlaczego trwa to tak długo. Brak wyzwalaczy, ale tabela zawiera garść FKeys (które wydają się być poprawnie zindeksowane).

To jest baza danych SQL 2000.

30
BradC

Niektóre rzeczy, na które możesz spojrzeć ...

Zmniejsz rozmiar partii ze 10000 do czegoś mniejszego, na przykład 2000 lub 1000 (nie powiedziałeś, jak duży jest twój rozmiar wiersza).

Spróbuj włączyć IO Statystyki), aby zobaczyć, ile IO zajmują wyszukiwania FK.

Jakie jest oczekiwanie spowodowane przez wstawianie go (master.dbo.sysprocesses)?

Zacznijmy tutaj i zobaczmy, dokąd zmierzamy.

10
mrdenny

Ćwiek,

Powinieneś sprawdzić statystyki oczekiwania dla twojego zapytania. W SQL 2000 można użyć składni DBCC SQLPERF („statystyki czekania”), aby uzyskać te szczegóły.

7
SQLRockstar

Potrafię powiedzieć, czego szukam, analizując wydajność zapytania. Może to pomaga.

  • analizować plan wykonania zapytań i sprawdzać skany indeksu, skany tabeli, użycie funkcji konwersji_prostej dla typów danych SQL, równoległość.
  • uruchom zapytanie z SET STATISTICS IO ON i SET STATISTICS TIME ON), aby zobaczyć czas wykonania i odczyt/zapis io dla każdej wstawki.
  • sprawdź czas oczekiwania z sysprocesses dla twojej sesji sesji.
  • uruchom profiler i wybierz standardowy szablon. wybierz następujące: Statystyka wydajności (jeśli się powtórzy, to Twój plan jest wielokrotnie kompilowany - źle), RPC: zakończone, SQL: zakończono wsadowo i SQL: uruchomiono wsadowo. Dodaj do nich kolumnę liczba wierszy, aby zobaczyć dokładnie liczbę wierszy w partii. Filtruj wyniki, aby wyświetlić tylko zapytanie.
  • w końcu zbierz oczekiwana długość życia strony licznik z Windows perfmon, a jeśli jest poniżej 300 (5 minut), to SQL ma mało pamięci. Zbierz także liczniki dysków: długość kolejki dysk, Czas dysku (dysk z plikami danych), Czas dysku (dysk z plikami dziennika), aby sprawdzić, czy na dyskach występuje presja.
6
yrushka

Spróbuj użyć:

SET STATISTICS IO ON

i

SET STATISTICS PROFILE ON

STATYSTYKA IO

Może być przydatny w informowaniu, które tabele wykonują najwięcej operacji skanowania tabel, odczytów logicznych i fizycznych (używam tych trzech, aby skupić się na tym, która część planu zapytań wymaga największej regulacji)

PROFIL STATYSTYCZNY

Zwróci przede wszystkim plan zapytań w formacie tabelarycznym, możesz następnie spojrzeć na kolumny IO i CPU), które kosztują najwięcej w zapytaniu (czy to skanowanie tabeli w tabeli tymczasowej w porównaniu z tym, co robi, aby wstawić do klucza klastrowanego itp.)

5
Andrew Bickerton