JAK: Rozwiązywanie problemów z wydajnością programu SQL Server

Tłumaczenia artykułów Tłumaczenia artykułów
Numer ID artykułu: 224587 - Zobacz jakich produktów dotyczą zawarte w tym artykule porady.
Rozwiń wszystko | Zwiń wszystko

Na tej stronie

Streszczenie

W tym artykule opisano krok po kroku, jak rozwiązywać problemy z wydajnością programu SQL Server. Rozwiązywanie problemów z wydajnością wiąże się z wykonaniem serii kroków mających na celu wyizolowanie i określenie przyczyny spowolnienia działania aplikacji. Możliwe przyczyny to między innymi:
  • Blokowanie.
  • Rywalizacja o zasoby systemowe.
  • Problemy wynikające z projektu aplikacji.
  • Konkretny zestaw kwerend lub procedur przechowywanych o długich czasach wykonania.
W tym artykule opisano, jak określić źródło problemów z wydajnością. Znajdują się tu także odsyłacze do innych artykułów z bazy wiedzy Microsoft Knowledge Base omawiających szczegółowo konkretne problemy z wydajnością i dodatkowe informacje na temat rozwiązywania problemów.

SQL Profiler


Program SQL Profiler to narzędzie zapewniające ogromne możliwości rozwiązywania problemów z wydajnością programu SQL Server 7.0 i jego nowszych wersji. Umożliwia on łatwe wychwytywanie wszystkich zdarzeń mających miejsce na serwerze przy typowym obciążeniu i zapewnia dostęp do informacji na ich temat. Korzystając z programu SQL Profiler w powiązaniu z monitorem wydajności systemu Microsoft Windows NT oraz z kilku prostych kwerend w celu stwierdzenia, czy ma miejsce blokowanie, można uzyskać informacje niezbędne do rozwiązania znakomitej większości problemów z wydajnością.

Co monitorować

1. Ustaw przechwytywanie śledzenia w programie SQL Profiler. Aby to zrobić, wykonaj następujące kroki:
  1. Otwórz program SQL Profiler.
  2. W menu Tools (Narzędzia) kliknij polecenie Options (Opcje).
  3. Upewnij się, że są zaznaczone opcje All Event Classes (Wszystkie klasy zdarzeń) oraz All Data Columns (Wszystkie kolumny danych).
  4. Kliknij przycisk OK.
  5. Utwórz nowe śledzenie.
  6. W menu File (Plik) wskaż polecenie New (Nowy), a następnie kliknij opcję Trace (Śledzenie).
  7. Na karcie General (Ogólne) określ nazwę śledzenia oraz plik, do którego mają być przechwytywane dane.
  8. Na karcie Events (Zdarzenia) dodaj następujące typy zdarzeń do śledzenia:

    Zwiń tę tabelęRozwiń tę tabelę
    NagłówekZdarzenie do dodaniaOpis
    CursorsCursorPrepareTo zdarzenie oznacza, że kursor w instrukcji SQL został przygotowany za pomocą bazy danych ODBC, OLEDB lub biblioteki bazy danych.
    Error and WarningMissing Column StatisticsTo zdarzenie oznacza, że nie były dostępne statystyki kolumn, które mogły być przydatne dla optymalizatora. W kolumnie Text (Tekst) jest widoczna lista kolumn, dla których nie ma statystyk. To zdarzenie w powiązaniu ze zdarzeniem Misc: Auto-UpdateStats oznacza, że była wyzwolona opcja Auto Create Statistics (Automatyczne tworzenie statystyk).
    Misc.AttentionTo zdarzenie oznacza, że przez klienta został wysłany sygnał attention (uwaga).
    Misc.Auto-UpdateStatsTo zdarzenie oznacza, że została wyzwolona opcja Auto Update Statistics (Automatyczna aktualizacja statystyk).
    Misc.Exec Prepared SQLTo zdarzenie oznacza, że baza danych ODBC, OLE DB lub biblioteka bazy danych wykonała uprzednio przygotowaną instrukcję (lub instrukcje) Transact-SQL.
    Misc.Execution PlanTo zdarzenie przedstawia drzewo planu wykonanej instrukcji Transact-SQL.
    Misc.Prepare SQLTo zdarzenie oznacza, że aplikacja ODBC, OLE DB lub biblioteki bazy danych przygotowała do użycia instrukcję (lub instrukcje) Transact-SQL.
    Misc.Unprepare SQLTo zdarzenie oznacza, że aplikacja ODBC, OLE DB lub biblioteki bazy danych anulowała przygotowanie do użycia instrukcji Transact-SQL.
    SessionsConnectTo zdarzenie oznacza, że ustanowiono nowe połączenie.
    SessionsDisconnectTo zdarzenie oznacza, że klient został odłączony.
    SessionsExisting ConnectionTo zdarzenie oznacza, że istniało połączenie, gdy uruchomiono śledzenie w programie SQL Profiler.
    Stored ProceduresSP: CompletedTo zdarzenie określa, kiedy zakończyło się wykonywanie procedury przechowywanej.
    Stored ProceduresSP: RecompileTo zdarzenie określa, że procedura przechowywana została ponownie skompilowana podczas wykonywania.
    Stored ProceduresSP: StartingTo zdarzenie określa, kiedy rozpoczęło się wykonywanie procedury przechowywanej.
    Stored ProceduresSP: StmtCompletedTo zdarzenie określa, kiedy zakończyło się wykonywanie instrukcji procedury przechowywanej.
    TSQL:SQL:BatchCompletedTo zdarzenie oznacza zakończenie działania programu wsadowego języka Transact-SQL. Kolumna Text zawiera wykonaną instrukcję.
    TSQL:SQL:StmtCompletedTo zdarzenie oznacza zakończenie wykonywania instrukcji języka Transact-SQL. Kolumna Text zawiera wykonaną instrukcję.
    TSQL:RPC:CompletedTo zdarzenie określa, że zakończyło się zdalne wywołanie procedury (RPC).
  9. Jeśli w aplikacji występują błędy przekroczenia limitu czasu, aplikacja przestaje odpowiadać (zawiesza się) lub jeśli występują inne zdarzenia, na skutek których problematyczne instrukcje nie kończą działania, należy uwzględnić także następujące zdarzenia:

    Zwiń tę tabelęRozwiń tę tabelę
    TSQL:SQL:BatchStartingTo zdarzenie oznacza rozpoczęcie działania programu wsadowego języka Transact-SQL. Kolumna Text zawiera wykonywaną instrukcję.
    TSQL:SQL:StmtStartingTo zdarzenie oznacza rozpoczęcie wykonywania instrukcji języka Transact-SQL. Kolumna Text zawiera wykonywaną instrukcję.
    TSQL:RPC:StartingTo zdarzenie określa początek zdalnego wywołania procedury (RPC).
    Stored ProceduresSP: StmtStartingTo zdarzenie określa, kiedy rozpoczęło się wykonywanie instrukcji procedury przechowywanej.


    Dzięki temu można mieć pewność, że będą widoczne instrukcje wykonywane w chwili przekroczenia limitu czasu.
  10. Upewnij się, że na karcie Data Columns (Kolumny danych) uwzględnione są następujące kolumny:

    W wypadku programu SQL Server 2000

    Start Time (Czas rozpoczęcia)

    End Time (Czas zakończenia)

    LoginSid

    SPID

    Event Class (Klasa zdarzenia)

    TextData (Dane tekstowe)

    IntegerData (Dane całkowite)

    BinaryData (Dane binarne)

    Duration (Czas trwania)

    CPU (Procesor)

    Reads (Odczyty)

    Writes (Zapisy)

    Application Name (Nazwa aplikacji)

    NT User Name (Nazwa użytkownika systemu NT)

    DBUserName (Nazwa użytkownika bazy danych)


    W wypadku programu SQL Server 7.0

    Start Time (Czas rozpoczęcia)

    End Time (Czas zakończenia)

    Connection ID (Identyfikator połączenia)

    SPID

    Event Class (Klasa zdarzenia)

    Text (Tekst)

    Integer Data (Dane całkowite)

    Binary Data (Dane binarne)

    Duration (Czas trwania)

    CPU (Procesor)

    Reads (Odczyty)

    Writes (Zapisy)

    Application Name (Nazwa aplikacji)

    NT User Name (Nazwa użytkownika systemu NT)

    SQL User Name (Nazwa użytkownika programu SQL)

Informacje na temat używania programu SQL Profiler można znaleźć w dokumentacji SQL Server 7.0 oraz SQL Server 2000 Books Online.


2. Użyj monitora wydajności do przechwycenia liczników systemu Windows NT oraz programu SQL Server. Aby to zrobić, wykonaj następujące kroki:
  1. Uruchom monitor wydajności systemu Microsoft Windows NT.
  2. W menu Widok kliknij polecenie Dziennik.
  3. W menu Opcje kliknij polecenie Dziennik.
  4. Określ nazwę i lokalizację pliku dziennika liczników wydajności. Możesz dostosować interwał aktualizacji.
  5. W menu Edycja kliknij polecenie Dodaj do dziennika.
  6. Dodaj wszystkie obiekty. Zarówno obiekty systemu Windows NT, jak i programu SQL Server.
  7. Aby rozpocząć rejestrowanie, w menu Opcje kliknij polecenie Dziennik, a następnie kliknij przycisk Rozpoczynanie rejestrowania.

Aby uzyskać dodatkowe informacje, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
150934 Tworzenie dziennika monitora wydajności na potrzeby rozwiązywania problemów w systemie Windows NT

3. Sprawdź, czy występuje blokowanie.

Aby sprawdzić, czy występuje blokowanie, uruchom systemową procedurę przechowywaną sp_who:
exec sp_who
Wynik będzie zawierać kolumnę blk. Sprawdź, czy produkt wyjściowy zawiera jakiekolwiek niezerowe wpisy wskazujące, że ma miejsce blokowanie. Uruchamiaj tę procedurę okresowo w czasie, gdy występuje obniżenie wydajności.

Uwaga: Uruchomienie systemowej procedury przechowywanej sp_who to sprawdzenie, czy występuje blokowanie. Na ogół nie zapewnia to wystarczających informacji do pełnego rozwiązania problemu z blokowaniem. Aby uzyskać dodatkowe informacje, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
251004 INF: How to Monitor SQL Server 7.0 Blocking

Uruchamianie aplikacji przy typowym obciążeniu

Idealnym rozwiązaniem jest przechwytywanie wyników programu SQL Profiler, monitora wydajności oraz blokowania w tym samym czasie. Ten czas musi obejmować moment, w którym wydajność aplikacji zmienia się z dobrej na niską. Połączenie tych informacji pozwala uzyskać lepszy obraz miejsca, w którym występuje spowolnienie.


Interpretacja wyników

  1. Sprawdź, czy występuje blokowanie.

    Jeśli kolumna blk na wyjściu procedury sp_who zawiera niezerową wartość, w systemie występuje blokowanie. Jeśli procesy blokują się nawzajem, procesy zablokowane mogą się cechować dłuższymi czasami działania. Aby uzyskać dodatkowe informacje, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
    224453 INF: Understanding and Resolving SQL Server 7.0 or 2000 Blocking Problems
  2. Przeanalizuj wyniki programu SQL Profiler.

    Efektywne wyświetlanie danych programu SQL Profiler jest niezwykle przydatne przy rozwiązywaniu problemów z wydajnością. Najważniejsze to uświadomić sobie, że nie trzeba przeglądać wszystkich przechwyconych danych. Należy postępować selektywnie. Program SQL Profiler umożliwia efektywne przeglądanie przechwyconych danych. Na karcie Properties (Właściwości) (kliknij polecenie Properties w menu File (Plik)) program SQL Profiler umożliwia ograniczenie wyświetlanych danych przez usunięcie kolumn danych lub zdarzeń, grupowanie (sortowanie) według kolumn danych oraz stosowanie filtrów. Konkretnych wartości można szukać w całym śledzeniu lub w konkretnej kolumnie (w menu Edit (Edycja), kliknij polecenie Find (Znajdź)). Można też zapisać dane programu SQL Profiler w tabeli programu SQL Server (w menu File (Plik) wskaż polecenie Save As (Zapisz jako), kliknij opcję Trace Table (Śledź tabelę)), a następnie uruchom na niej kwerendy SQL.

    Pamiętaj, aby filtrowanie wykonywać jedynie na uprzednio zapisanym pliku śledzenia. Wykonanie tych kroków na aktywnym śledzeniu wiąże się z ryzykiem utraty danych przechwyconych od czasu uruchomienia śledzenia. Przed kontynuowaniem należy zapisać aktywne śledzenie w pliku lub w tabeli (w menu File (Plik) kliknij polecenie Save As (Zapisz jako)), a następnie ponownie je otworzyć (w menu File (Plik) kliknij polecenie Open (Otwórz)). Podczas pracy na zapisanym pliku śledzenia filtrowanie nie powoduje trwałego usunięcia odfiltrowanych danych; te dane nie są jedynie wyświetlane. Można dodawać i usuwać zdarzenia i kolumny danych, aby zawęzić wyszukiwanie.

    Pierwszy krok w analizowaniu plików śledzenia programu SQL Profiler pod kątem problemów z wydajnością to stwierdzenie, czy na serwerze występują różne typy zdarzeń.

    Grupowanie śledzenia według klas zdarzeń:

    a. W menu File (Plik) kliknij polecenie Properties (Właściwości).

    b. Na karcie Data Columns (Kolumny danych) użyj przycisku DO GÓRY, aby przenieść kolumnę Event Class (Klasa zdarzeń) poniżej nagłówka Groups (Grupy), i przycisku W DÓŁ, aby usunąć wszystkie pozostałe kolumny poniżej nagłówka Groups.

    c. Kliknij przycisk OK.

    Grupowanie na podstawie kolumny klasy zdarzenia umożliwia wyświetlenie typów i częstotliwości zdarzeń występujących w programie SQL Server. Należy poszukać w tej kolumnie następujących zdarzeń:

    SP:RECOMPILE

    To zdarzenie określa, że procedura przechowywana została ponownie skompilowana podczas wykonywania. Kilka zdarzeń ponownej kompilacji kwerendy wskazuje, że program SQL Server zużywa zasoby na kompilację kwerend, a nie na ich wykonywanie.

    Aby uzyskać dodatkowe informacje na temat rozwiązywania problemów z ponownymi kompilacjami procedury przechowywanej, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
    243586 INF: Rozwiązywanie problemów z ponowną kompilacją procedury przechowywania


    Attention

    Sygnał attention wskazuje, że kwerenda została anulowana przez klienta. Na ogół jest to spowodowane jedną z dwóch przyczyn:

    Użytkownik jawnie anulował kwerendę lub zamknął aplikację.

    – lub –

    Został przekroczony limit czasu kwerendy.

    Występowanie sygnałów attention może oznaczać, że niektóre kwerendy działają za wolno.

    Aby uzyskać dodatkowe informacje, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
    243589 JAK: Rozwiązywanie problemów z wolno działającymi kwerendami w programie SQL Server 7.0 lub nowszym
    Aby określić kwerendę, do której został wysłany sygnał, należy poprawić śledzenie, tak aby nie było pogrupowane według jakiejkolwiek kolumny danych, i odfiltrować identyfikator procesu systemowego (SPID), który otrzymał ten sygnał (na karcie Filters (Filtry) ustaw wartość SPID = x). Zdarzenia SQL:StmtStarting, SQL:BatchStarting lub SP:StmtStarting bezpośrednio poprzedzające sygnał attention to kwerenda, w której nastąpiło przekroczenie limitu czasu lub która została anulowana. Można przeszukać kolumnę Event Class (Klasa zdarzenia) dla zdarzenia Attention, aby łatwo je było zlokalizować (w menu Edit (Edycja) kliknij polecenie Find (Znajdź)).

    Zdarzenia PREPARE SQL i EXEC PREPARED SQL

    Zdarzenie Prepare SQL oznacza, że aplikacja ODBC, OLE DB lub biblioteki bazy danych przygotowała do użycia instrukcję (lub instrukcje) Transact-SQL. Zdarzenie Exec Prepared SQL oznacza, że aplikacja użyła istniejącej przygotowanej instrukcji do uruchomienia polecenia.

    Należy porównać liczbę wystąpień obu tych zdarzeń. W idealnej sytuacji aplikacja musi przygotować instrukcję SQL jeden raz i uruchomić ją kilka razy. To pozwala Optymalizatorowi oszczędzić koszty kompilacji nowego planu przy każdym wykonaniu instrukcji. Dlatego liczba zdarzeń Exec Prepared SQL powinna być znacznie większa niż liczba zdarzeń Prepare SQL. Jeśli liczba zdarzeń Prepare SQL jest w przybliżeniu równa liczbie zdarzeń Exec Prepared SQL, być może aplikacja nie korzysta w najlepszy sposób z modelu przygotowanie/wykonanie. Najlepszym rozwiązaniem jest nieprzygotowywanie instrukcji, która ma być wykonana jeden raz. Aby uzyskać więcej informacji na temat przygotowywania instrukcji SQL, zobacz temat „Preparing SQL Statements” (Przygotowywanie instrukcji SQL) w dokumentacji SQL Server 7.0 Books Online.

    Jeśli liczba zdarzeń Exec Prepared SQL nie jest większa od trzech do pięciu razy od liczby zdarzeń Prepare SQL, być może aplikacja nie korzysta efektywnie z modelu przygotowanie/wykonanie. Aby uzyskać dodatkowe informacje, kliknij następujący numer artykułu w celu wyświetlenia tego artykułu z bazy wiedzy Microsoft Knowledge Base:
    243588 JAK: Rozwiązywanie problemów z wydajnością kwerend ad hoc

    W programie SQL Server 2000 nadmiarowe rundy na zdarzenia przygotowanie/wykonanie będą wyeliminowane, więc stosunek 3-5 nie jest rygorystycznie wymagany. Wciąż jednak dobrą regułą jest dokładanie starań, aby przygotowany plan był użyty więcej niż jeden raz.

    Missing Column Statistics

    To zdarzenie oznacza, że nie były dostępne informacje statystyczne, które mogły być użyte przez optymalizatora do wygenerowania lepszego planu kwerend. To oznacza, że kwerenda nie ma przydatnych indeksów na co najmniej jednej używanej tabeli. Oprócz braku przydatnego indeksu program SQL Server nie ma danych statystycznych na temat kolumn użytych do podjęcia świadomej decyzji odnośnie do planu kwerend. Wynik wygenerowanego planu kwerend może nie być optymalny. Jeśli te zdarzenia są widoczne, należy zwrócić uwagę na kwerendę i wygenerowany plan wykonania, a następnie zajrzeć do następującego artykułu z bazy wiedzy Microsoft Knowledge Base w celu uzyskania informacji, jakie kroki należy podjąć, aby poprawić wydajność kwerendy:
    243589 JAK: Rozwiązywanie problemów z wolno działającymi kwerendami w programie SQL Server 7.0 lub nowszym

    Podczas analizowania zdarzeń Missing Column Statistics w pierwszej kolejności należy się skoncentrować na tych zdarzeniach, które występują w powiązaniu z długo działającymi kwerendami. Niektóre zdarzenia mogą być generowane i rozwiązywane automatycznie przez program SQL Server przy użyciu statystyk automatycznych i mogą nie wymagać interwencji użytkownika. Dlatego najlepsza strategia polega na skoncentrowaniu się w pierwszej kolejności na kwerendach o długich czasach zapytań, tak jak to zaprezentowano w dalszej części tego artykułu, oraz na sprawdzeniu, czy występują skojarzone zdarzenia Missing Column Statistics.

    Jeśli nie ma wystąpień zdarzeń tych klas, następny krok polega na określeniu, na co jest zużywany czas.

    Grupowanie wyniku śledzenia według czasu trwania:

    a. W menu File (Plik) kliknij polecenie Properties (Właściwości).

    b. Na karcie Data Columns (Kolumny danych) użyj przycisku DO GÓRY, aby przenieść kolumnę Duration (Czas trwania) poniżej nagłówka Groups (Grupy), i przycisku W DÓŁ, aby usunąć wszystkie pozostałe kolumny poniżej nagłówka Groups.

    c. Na karcie Events (Zdarzenia) usuń wszystkie grupy z wyjątkiem grup TSQL i Stored Procedures (Procedury przechowywane).

    d. Kliknij przycisk OK.

    Dzięki grupowaniu na podstawie czasu trwania można łatwo odszukać instrukcje języka SQL, programy wsadowe i procedury działające najwolniej. Bardzo ważne jest zwrócenie uwagi nie tylko na czas w momencie wystąpienia problemu, ale także uzyskanie obrazu czasu, gdy wydajność jest zadowalająca, w celu porównania. Można przefiltrować czas rozpoczęcia, aby rozbić śledzenie na sekcje, gdy wydajność jest dobra, i na osobną sekcję, gdy wydajność jest niska. Należy poszukać kwerend o najdłuższym czasie wykonania, gdy wydajność jest dobra. Są to najbardziej prawdopodobne przyczyny problemu. Jeśli ogólna wydajność system jest obniżona, nawet dobre kwerendy mogą się cechować długimi czasami wykonania, gdyż czekają na zasoby systemowe.

    Jeśli występuje niewielka liczba kwerend o długich czasach wykonania, zobacz następujący artykuł z bazy wiedzy Microsoft Knowledge Base:
    243589 JAK: Rozwiązywanie problemów z wolno działającymi kwerendami w programie SQL Server 7.0 lub nowszym
    Jeśli można zaobserwować, że czas wykonania poszczególnych kwerend jest krótki, ale jest ich kilka i wartość licznika Kompilacje SQL/s w monitorze wydajności (opisana dalej) jest wysoka, zobacz następujący artykuł z bazy wiedzy Microsoft Knowledge Base:
    243588 JAK: Rozwiązywanie problemów z wydajnością kwerend ad hoc
    Analiza pozostałych kolumn danych:

    Dodatkowy wgląd w charakter problemów z wydajnością można uzyskać, przeglądając inne kolumny danych w danych śledzenia. Oto kilka spraw, które należy uwzględnić:

    Jeśli użycie procesora jest wysokie, należy pogrupować dane według procesora, aby stwierdzić, które kwerendy w największym stopniu zużywają czas procesora. W kolumnie Text należy poszukać wpisów „hash” lub „merge” , aby stwierdzić, który plan wykonania kwerend korzysta z tych typów łączenia. Zużywają one więcej czasu procesora i pamięci niż połączenie „nested loop” , które intensywnie używa operacji wejścia/wyjścia.

    Jeśli wąskie gardło stanowią dyskowe operacje wejścia/wyjścia, należy pogrupować dane według kolumn Reads i Writes. Należy zwrócić uwagę na pola Application Name, NT User Name oraz SQL User Name, aby wyizolować źródło problemów z długo działającymi kwerendami.

    Kolumna danych całkowitych zdarzenia wyjątku będzie oznaczać błędy zwrócone do klienta. Tekst komunikatu o błędzie można znaleźć, odszukując jego numer błędu w dokumentacji SQL Server 7.0 Books Online.

    Pole Connection ID pomaga upewnić się, że oglądane są te same sesje dla konkretnego klienta. Nie może tego zapewnić identyfikator SPID, gdyż użytkownik mógł się odłączyć, a nowy użytkownik podłączyć, otrzymując ten sam identyfikator SPID.

    Informacje uzyskane z tych pól mogą się różnić w zależności od scenariusza, ale należy je przeanalizować, jeśli informacje z pól omówionych wcześniej nie pozwalają uzyskać odpowiedzi.
  3. Przeanalizuj dane wyjściowe monitora wydajności.

    Monitor wydajności pozwala zidentyfikować ogólne wąskie gardła systemu. Być może program SQL Server i aplikacja działają zgodnie z oczekiwaniami, ale komputer jest za słaby, brakuje mu pamięci lub innych zasobów. Na niektórych komputerach mogą występować problemy ze sposobem, w jaki działa aplikacja i program SQL Server. Należy co najmniej sprawdzić następujące liczniki:

  • Obiekt: Proces

    Licznik: Procesor

    Wystąpienie: SQL Server

  • Obiekt: Procesor

    Licznik: Czas procesora (%)

    Wystąpienie: Sprawdź wystąpienie każdego procesora

  • Obiekt: Dysk fizyczny

    Licznik: Średnia długość kolejki dysku

    Wystąpienie: Sprawdź wystąpienie każdego dysku fizycznego

  • Obiekt: SQL Server:Statystyki SQL

    Licznik: Kompilacje SQL/s
Poszukaj trendu w ramach czasowych, w których wydajność aplikacji zmieniła się z dobrej na niską: co wzrosło najpierw? Czy ma to związek z procesorem komputera czy z operacjami wejścia-wyjścia dysku? Te informacje, wraz z danymi wyjściowymi programu Profiler opisanymi wcześniej w tym artykule, pomogą zawęzić obszary, w których występuje problem. Problemy związane z obciążeniem procesora mogą sugerować bardzo dużą liczbę rekompilacji procedur przechowywanych, kompilacje ad-hoc kwerend lub intensywne użycie połączeń „hash” i „merge” . Należy zapoznać się z artykułami wspomnianymi wcześniej w tym artykule, aby określić prawidłowy sposób postępowania. Duże długości kolejki dysku mogą sugerować konieczność dodania pamięci systemowej lub poprawienia podsystemu dyskowego.

Właściwości

Numer ID artykułu: 224587 - Ostatnia weryfikacja: 3 stycznia 2008 - Weryfikacja: 4.1
Informacje zawarte w tym artykule dotyczą:
  • Microsoft SQL Server 7.0 Standard Edition
Słowa kluczowe: 
kbhowto kbhowtomaster kbinfo kbproductlink KB224587

Przekaż opinię

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com