Udostępnij za pośrednictwem

Zarządzanie zasobami w ramach gęstych pul elastycznych

  • Artykuł

Dotyczy: Azure SQL Database

Elastyczne pule usługi Azure SQL Database to ekonomiczne rozwiązanie do zarządzania wieloma bazami danych o różnym użyciu zasobów. Wszystkie bazy danych w elastycznej puli współdzielą tę samą alokację zasobów, takich jak procesor CPU, pamięć, wątki procesów roboczych, miejsce do magazynowania, , przy założeniu, tempdbże tylko podzbiór baz danych w puli będzie używać zasobów obliczeniowych w danym momencie. To założenie umożliwia ekonomiczne korzystanie z elastycznych pul. Zamiast płacić za wszystkie zasoby każda pojedyncza baza danych może potencjalnie potrzebować, klienci płacą za znacznie mniejszy zestaw zasobów, współużytkowany przez wszystkie bazy danych w puli.

Nadzór nad zasobami

Udostępnianie zasobów wymaga od systemu dokładnego kontrolowania użycia zasobów w celu zminimalizowania efektu "hałaśliwego sąsiada", w którym baza danych o wysokim zużyciu zasobów wpływa na inne bazy danych w tej samej elastycznej puli. Usługa Azure SQL Database osiąga te cele, wdrażając nadzór nad zasobami. Jednocześnie system musi zapewnić wystarczające zasoby dla funkcji, takich jak wysoka dostępność i odzyskiwanie po awarii (HADR), tworzenie kopii zapasowych i przywracanie, monitorowanie, magazyn zapytań, automatyczne dostrajanie itp., aby działać niezawodnie.

Głównym celem projektowania elastycznych pul jest opłacalne. Z tego powodu system celowo umożliwia klientom tworzenie gęstych pul, czyli pul z liczbą baz danych zbliżających się lub maksymalnie dozwolonych, ale przy umiarkowanej alokacji zasobów obliczeniowych. Z tego samego powodu system nie rezerwuje wszystkich potencjalnie potrzebnych zasobów dla procesów wewnętrznych, ale umożliwia udostępnianie zasobów między wewnętrznymi procesami a obciążeniami użytkowników.

Takie podejście umożliwia klientom korzystanie z gęstych elastycznych pul w celu osiągnięcia odpowiedniej wydajności i dużych oszczędności kosztów. Jeśli jednak obciążenie dla wielu baz danych w gęstej puli jest wystarczająco intensywne, rywalizacja o zasoby staje się znacząca. Rywalizacja o zasoby zmniejsza wydajność obciążeń użytkowników i może negatywnie wpływać na procesy wewnętrzne.

Ważne

W gęstych pulach z wieloma aktywnymi bazami danych może nie być możliwe zwiększenie liczby baz danych w puli do maksymalnych wartości udokumentowanych dla jednostek DTU i elastycznych pul rdzeni wirtualnych.

Liczba baz danych, które można umieścić w gęstych pulach bez powodowania rywalizacji o zasoby i problemy z wydajnością, zależy od liczby współbieżnych aktywnych baz danych oraz zużycia zasobów przez obciążenia użytkowników w każdej bazie danych. Ta liczba może ulec zmianie wraz ze zmianą obciążeń użytkowników.

Ponadto jeśli minimalna liczba rdzeni wirtualnych na bazę danych lub minimalna liczba jednostek DTU na bazę danych zostanie ustawiona na wartość większą niż 0, maksymalna liczba baz danych w puli będzie niejawnie ograniczona. Aby uzyskać więcej informacji, zobacz Właściwości bazy danych dla baz danych z rdzeniami wirtualnymi w puli i Właściwości bazy danych dla baz danych DTU w puli.

Gdy rywalizacja o zasoby występuje w gęsto zapakowanej puli, klienci mogą wybrać jedną lub więcej z następujących akcji, aby temu zapobiec:

  • Dostrajanie obciążenia zapytań w celu zmniejszenia zużycia zasobów lub rozłożenia użycia zasobów w wielu bazach danych w czasie.
  • Zmniejsz gęstość puli, przenosząc niektóre bazy danych do innej puli lub tworząc je autonomiczne bazy danych.
  • Skaluj pulę w górę, aby uzyskać więcej zasobów.

Aby uzyskać sugestie dotyczące implementowania dwóch ostatnich akcji, zobacz Zalecenia operacyjne w dalszej części tego artykułu. Zmniejszenie rywalizacji o zasoby zapewnia korzyści zarówno dla obciążeń użytkowników, jak i procesów wewnętrznych, i umożliwia niezawodne utrzymanie oczekiwanego poziomu usług przez system.

Monitorowanie użycia zasobów

Aby uniknąć obniżenia wydajności ze względu na rywalizację o zasoby, klienci korzystający z gęstych elastycznych pul powinni aktywnie monitorować zużycie zasobów i podejmować czasochłonne działania, jeśli zwiększenie rywalizacji o zasoby zacznie wpływać na obciążenia. Ciągłe monitorowanie jest ważne, ponieważ użycie zasobów w puli zmienia się w czasie, ze względu na zmiany obciążenia użytkownika, zmiany woluminów danych i dystrybucji, zmiany gęstości puli i zmiany w usłudze Azure SQL Database.

Usługa Azure SQL Database udostępnia kilka metryk, które są istotne dla tego typu monitorowania. Przekroczenie zalecanej wartości średniej dla każdej metryki wskazuje rywalizację o zasoby w puli i należy rozwiązać problem przy użyciu jednej z akcji wymienionych wcześniej.

Aby wysłać alert, gdy użycie zasobów puli (procesor CPU, operacje we/wy danych, operacje we/wy dziennika, procesy robocze itp.) przekracza próg, rozważ utworzenie alertów za pośrednictwem witryny Azure Portal lub polecenia cmdlet Add-AzMetricAlertRulev2 programu PowerShell. Podczas monitorowania elastycznych pul należy również rozważyć utworzenie alertów dla poszczególnych baz danych w puli w razie potrzeby w danym scenariuszu. Aby zapoznać się z przykładowym scenariuszem monitorowania elastycznych pul, zobacz Monitorowanie wydajności usługi Azure SQL Database i zarządzanie nią w wielodostępnej aplikacji SaaS.

Nazwa metryki opis Zalecana średnia wartość
avg_instance_cpu_percent Wykorzystanie procesora CPU procesu SQL skojarzonego z pulą elastyczną mierzone przez bazowy system operacyjny. Dostępny w widoku sys.dm_db_resource_stats w każdej bazie danych i w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie nosi nazwę sql_instance_cpu_percent, i może być widoczna w witrynie Azure Portal. Ta wartość jest taka sama dla każdej bazy danych w tej samej elastycznej puli. Poniżej 70%. Okazjonalne krótkie skoki do 90% mogą być akceptowalne.
max_worker_percent Wykorzystanie wątków roboczych. Podana dla każdej bazy danych w puli, a także dla samej puli. Istnieją różne limity liczby wątków roboczych na poziomie bazy danych i na poziomie puli, dlatego zaleca się monitorowanie tej metryki na obu poziomach. Dostępny w widoku sys.dm_db_resource_stats w każdej bazie danych i w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie nosi nazwę workers_percent, i może być widoczna w witrynie Azure Portal. Poniżej 80%. Skoki do 100% spowodują niepowodzenie prób połączenia i zapytania.
avg_data_io_percent Wykorzystanie operacji we/wy na sekundę dla operacji we/wy odczytu i zapisu fizycznego. Podana dla każdej bazy danych w puli, a także dla samej puli. Istnieją różne limity liczby operacji we/wy na sekundę na poziomie bazy danych i na poziomie puli, dlatego zaleca się monitorowanie tej metryki na obu poziomach. Dostępny w widoku sys.dm_db_resource_stats w każdej bazie danych i w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie nosi nazwę physical_data_read_percent, i może być widoczna w witrynie Azure Portal. Poniżej 80%. Okazjonalne krótkie skoki do 100% mogą być dopuszczalne.
avg_log_write_percent Wykorzystanie przepływności dla operacji we/wy zapisu dziennika transakcji. Podana dla każdej bazy danych w puli, a także dla samej puli. Istnieją różne limity przepływności dziennika na poziomie bazy danych i na poziomie puli, dlatego zaleca się monitorowanie tej metryki na obu poziomach. Dostępny w widoku sys.dm_db_resource_stats w każdej bazie danych i w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie nosi nazwę log_write_percent, i może być widoczna w witrynie Azure Portal. Gdy ta metryka jest blisko 100%, wszystkie modyfikacje bazy danych (INSERT, UPDATE, DELETE, MERGE instrukcje, SELECT ... INTO, BULK INSERT itp.) będzie wolniejsza. Poniżej 90%. Okazjonalne krótkie skoki do 100% mogą być dopuszczalne.
oom_per_second Szybkość błędów braku pamięci (OOM) w elastycznej puli, która jest wskaźnikiem ciśnienia pamięci. Dostępny w widoku sys.dm_resource_governor_resource_pools_history_ex . Zobacz Przykłady przykładowego zapytania, aby obliczyć tę metrykę. Aby uzyskać więcej informacji, zobacz Limity zasobów dla pul elastycznych przy użyciu jednostek DTU lub elastycznych pul przy użyciu rdzeni wirtualnych oraz Rozwiązywanie problemów z błędami braku pamięci w usłudze Azure SQL Database. Jeśli wystąpią błędy dotyczące braku pamięci, przejrzyj widok sys.dm_os_out_of_memory_events. 0
avg_storage_percent Łączna ilość miejsca do magazynowania używanego przez dane we wszystkich bazach danych w elastycznej puli. Nie zawiera pustego miejsca w plikach bazy danych. Dostępny w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie nosi nazwę storage_percent, i może być widoczna w witrynie Azure Portal. Poniżej 80%. Może zbliżyć się do 100% dla pul bez wzrostu danych.
avg_allocated_storage_percent Łączna ilość miejsca do magazynowania używanego przez pliki bazy danych we wszystkich bazach danych w elastycznej puli. Zawiera puste miejsce w plikach bazy danych. Dostępny w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie nosi nazwę allocated_data_storage_percent, i może być widoczna w witrynie Azure Portal. Poniżej 90%. Może zbliżyć się do 100% dla pul bez wzrostu danych.
tempdb_log_used_percent Wykorzystanie miejsca w dzienniku tempdb transakcji w bazie danych. Mimo że obiekty tymczasowe utworzone w jednej bazie danych nie są widoczne w innych bazach danych w tej samej elastycznej puli, tempdb jest zasobem udostępnionym dla wszystkich baz danych w tej samej puli. Długotrwała lub oddzielona transakcja uruchomiona tempdb z jednej bazy danych w puli może zużywać dużą część dziennika transakcji i powodować błędy zapytań w innych bazach danych w tej samej puli. Pochodzi z widoków sys.dm_db_log_space_usage i sys.database_files . Ta metryka jest również emitowana do usługi Azure Monitor i może być widoczna w witrynie Azure Portal. Zobacz Przykłady przykładowego zapytania, aby zwrócić bieżącą wartość tej metryki. Poniżej 50%. Okazjonalne skoki do 80% są akceptowalne.

Oprócz tych metryk usługa Azure SQL Database udostępnia widok, który zwraca rzeczywiste limity ładu zasobów, a także dodatkowe widoki zwracające statystyki wykorzystania zasobów na poziomie puli zasobów i na poziomie grupy obciążeń.

Nazwa widoku opis
sys.dm_user_db_resource_governance Zwraca rzeczywiste ustawienia konfiguracji i pojemności używane przez mechanizmy zapewniania ładu zasobów w bieżącej bazie danych lub elastycznej puli.
sys.dm_resource_governor_resource_pools Zwraca informacje o bieżącym stanie puli zasobów, bieżącej konfiguracji pul zasobów i skumulowanych statystyk puli zasobów.
sys.dm_resource_governor_workload_groups Zwraca skumulowane statystyki grupy obciążeń i bieżącą konfigurację grupy obciążeń. Ten widok można połączyć z sys.dm_resource_governor_resource_pools w kolumnie pool_id , aby uzyskać informacje o puli zasobów.
sys.dm_resource_governor_resource_pools_history_ex Zwraca statystyki wykorzystania puli zasobów dla najnowszej historii na podstawie liczby dostępnych migawek. Każdy wiersz reprezentuje przedział czasu. Czas trwania interwału jest podany w kolumnie duration_ms . Kolumny delta_ zwracają zmianę w każdej statystyce w interwale.
sys.dm_resource_governor_workload_groups_history_ex Zwraca statystyki wykorzystania grup obciążeń dla najnowszej historii na podstawie liczby dostępnych migawek. Każdy wiersz reprezentuje przedział czasu. Czas trwania interwału jest podany w kolumnie duration_ms . Kolumny delta_ zwracają zmianę w każdej statystyce w interwale.

Napiwek

Aby wykonać zapytania dotyczące tych i innych dynamicznych widoków zarządzania przy użyciu podmiotu zabezpieczeń innego niż administrator serwera, dodaj ten podmiot zabezpieczeń do ##MS_ServerStateReader## roli serwera.

Te widoki mogą służyć do monitorowania wykorzystania zasobów i rozwiązywania problemów z rywalizacją o zasoby niemal w czasie rzeczywistym. Obciążenie użytkownika w replikach pomocniczych podstawowych i możliwych do odczytu, w tym replik geograficznych, jest klasyfikowane do SloSharedPool1 puli zasobów i UserPrimaryGroup.DBId[N] grupy obciążeń, gdzie N oznacza wartość identyfikatora bazy danych.

Oprócz monitorowania bieżącego wykorzystania zasobów klienci korzystający z gęstych pul mogą utrzymywać historyczne dane użycia zasobów w oddzielnym magazynie danych. Te dane mogą być używane w analizie predykcyjnej do proaktywnego zarządzania wykorzystaniem zasobów na podstawie trendów historycznych i sezonowych.

Zalecenia operacyjne

Pozostaw wystarczającą ilość miejsca na zasoby. Jeśli wystąpi rywalizacja o zasoby i obniżenie wydajności, środki zaradcze mogą obejmować przeniesienie niektórych baz danych z puli elastycznej lub skalowanie w górę puli, jak wspomniano wcześniej. Jednak te akcje wymagają wykonania dodatkowych zasobów obliczeniowych. W szczególności w przypadku pul Premium i Krytyczne dla działania firmy te akcje wymagają przeniesienia wszystkich danych dla przenoszonych baz danych lub wszystkich baz danych w elastycznej puli, jeśli pula jest skalowana w górę. Transfer danych to długotrwała operacja intensywnie korzystająca z zasobów. Jeśli pula jest już pod wysokim ciśnieniem zasobów, sama operacja ograniczania ryzyka jeszcze bardziej obniży wydajność. W skrajnych przypadkach może nie być możliwe rozwiązanie rywalizacji o zasoby za pośrednictwem przenoszenia bazy danych lub skalowania puli w górę, ponieważ wymagane zasoby nie są dostępne. W takim przypadku tymczasowe zmniejszenie obciążenia zapytań w objętej elastycznej puli może być jedynym rozwiązaniem.

Klienci korzystający z gęstych pul powinni uważnie monitorować trendy wykorzystania zasobów zgodnie z wcześniejszym opisem i podejmować działania korygujące, podczas gdy metryki pozostają w zalecanych zakresach i nadal są wystarczające zasoby w elastycznej puli.

Wykorzystanie zasobów zależy od wielu czynników, które zmieniają się w czasie dla każdej bazy danych i każdej elastycznej puli. Osiągnięcie optymalnego współczynnika cen/wydajności w gęstych pulach wymaga ciągłego monitorowania i ponownego równoważenia, czyli przenoszenia baz danych z bardziej wykorzystywanych pul do mniej wykorzystywanych pul oraz tworzenia nowych pul w razie potrzeby w celu dostosowania się do zwiększonego obciążenia.

Uwaga

W przypadku elastycznych pul JEDNOSTEK DTU metryka eDTU na poziomie puli nie jest wartością MAX ani SUMą indywidualnego wykorzystania bazy danych. Jest ona otrzymywana na podstawie wykorzystania różnych metryk na poziomie puli. Limity zasobów na poziomie puli mogą być wyższe niż limity na poziomie poszczególnych baz danych, więc istnieje możliwość osiągnięcia określonego limitu zasobu (procesora, operacji we/wy danych, operacji we/wy dziennika itp.), nawet jeśli raportowanie jednostek eDTU dla puli nie wskazuje osiągnięcia jakiegokolwiek limitu.

Nie należy przenosić "gorących" baz danych. Jeśli rywalizacja o zasoby na poziomie puli jest spowodowana głównie przez niewielką liczbę wysoce wykorzystywanych baz danych, może być kuszące przeniesienie tych baz danych do mniej używanej puli lub utworzenie ich autonomicznych baz danych. Jednak wykonanie tej czynności, gdy baza danych pozostaje wysoce wykorzystywana, nie jest zalecana, ponieważ operacja przenoszenia jeszcze bardziej obniży wydajność, zarówno dla przenoszonej bazy danych, jak i całej puli. Zamiast tego zaczekaj na ustąpienie wysokiego wykorzystania lub przenieś mniej używane bazy danych, aby zmniejszyć wykorzystanie zasobów na poziomie puli. Jednak przenoszenie baz danych z bardzo niskim wykorzystaniem nie zapewnia żadnych korzyści w tym przypadku, ponieważ nie powoduje to istotnego zmniejszenia wykorzystania zasobów na poziomie puli.

Utwórz nowe bazy danych w puli "kwarantanna". W scenariuszach, w których tworzone są często nowe bazy danych, takie jak aplikacje korzystające z modelu dzierżawy na bazę danych, istnieje ryzyko, że nowa baza danych umieszczona w istniejącej elastycznej puli niespodziewanie zużywa znaczne zasoby i wpływa na inne bazy danych i procesy wewnętrzne w puli. Aby ograniczyć to ryzyko, utwórz oddzielną pulę "kwarantanny" z dużą alokacją zasobów. Użyj tej puli dla nowych baz danych z jeszcze nieznanymi wzorcami zużycia zasobów. Gdy baza danych pozostanie w tej puli na potrzeby cyklu biznesowego, takiego jak tydzień lub miesiąc, a jego zużycie zasobów jest znane, można przenieść ją do puli z wystarczającą pojemnością, aby pomieścić to dodatkowe użycie zasobów.

Monitoruj zarówno używane, jak i przydzielone miejsce. Gdy przydzielone miejsce w puli (całkowity rozmiar wszystkich plików bazy danych w magazynie dla wszystkich baz danych w puli) osiągnie maksymalny rozmiar puli, mogą wystąpić błędy braku miejsca. Jeśli przydzielone trendy przestrzeni są wysokie i są na dobrej drodze, aby osiągnąć maksymalny rozmiar puli, dostępne są następujące opcje ograniczania ryzyka:

  • Przenoszenie niektórych baz danych z puli w celu zmniejszenia całkowitego przydzielonego miejsca
  • Zmniejszanie plików bazy danych w celu zmniejszenia ilości pustego przydzielonego miejsca w plikach
  • Skalowanie puli w górę do celu usługi przy użyciu większego maksymalnego rozmiaru puli

Jeśli używane miejsce w puli (łączny rozmiar danych we wszystkich bazach danych w puli, bez pustego miejsca w plikach) trendy wysokie i jest na dobrej drodze, aby osiągnąć maksymalny rozmiar puli, opcje ograniczania ryzyka obejmują:

  • Przenoszenie niektórych baz danych z puli w celu zmniejszenia całkowitej ilości używanego miejsca
  • Przenoszenie (archiwizowanie) danych poza bazą danych lub usuwanie nie wymaga już danych
  • Implementowanie kompresji danych
  • Skalowanie puli w górę do celu usługi przy użyciu większego maksymalnego rozmiaru puli

Unikaj nadmiernie gęstych serwerów. Usługa Azure SQL Database obsługuje maksymalnie 5000 baz danych na serwer. Klienci korzystający z elastycznych pul z tysiącami baz danych mogą rozważyć umieszczenie wielu elastycznych pul na jednym serwerze z całkowitą liczbą baz danych do obsługiwanego limitu. Jednak serwery z wieloma tysiącami baz danych tworzą wyzwania operacyjne. Operacje wymagające wyliczania wszystkich baz danych na serwerze, na przykład wyświetlanie baz danych w portalu, będą wolniejsze. Błędy operacyjne, takie jak niepoprawne modyfikacje identyfikatorów logowania na poziomie serwera lub reguły zapory, będą mieć wpływ na większą liczbę baz danych. Przypadkowe usunięcie serwera będzie wymagać pomocy od pomoc techniczna firmy Microsoft odzyskania baz danych na usuniętym serwerze i spowoduje długotrwałą awarię dla wszystkich baz danych, których dotyczy problem.

Ogranicz liczbę baz danych na serwer do mniejszej liczby niż maksymalna obsługiwana. W wielu scenariuszach optymalne jest użycie maksymalnie 1000–2000 baz danych na serwer. Aby zmniejszyć prawdopodobieństwo przypadkowego usunięcia serwera, umieść blokadę usuwania na serwerze lub w grupie zasobów.

Przykłady

Wyświetlanie poszczególnych ustawień pojemności bazy danych

Użyj dynamicznego sys.dm_user_db_resource_governance widoku zarządzania, aby wyświetlić rzeczywiste ustawienia konfiguracji i pojemności używane przez nadzór nad zasobami w bieżącej bazie danych lub elastycznej puli. Aby uzyskać więcej informacji, zobacz sys.dm_user_db_resource_governance.

Uruchom to zapytanie w dowolnej bazie danych w elastycznej puli. Wszystkie bazy danych w puli mają te same ustawienia ładu zasobów.

SELECT * FROM sys.dm_user_db_resource_governance AS rg
WHERE database_id = DB_ID();

Monitorowanie ogólnego użycia zasobów puli elastycznej

Użyj widoku wykazu systemu, sys.elastic_pool_resource_stats aby monitorować zużycie zasobów całej puli. Aby uzyskać więcej informacji, zobacz sys.elastic_pool_resource_stats.

To przykładowe zapytanie, aby wyświetlić ostatnie 10 minut, powinno zostać uruchomione w master bazie danych logicznego serwera Azure SQL server zawierającego żądaną elastyczną pulę.

SELECT * FROM sys.elastic_pool_resource_stats AS rs
WHERE rs.start_time > DATEADD(mi, -10, SYSUTCDATETIME()) 
AND rs.elastic_pool_name = '<elastic pool name>';

Monitorowanie użycia poszczególnych zasobów bazy danych

Użyj dynamicznego sys.dm_db_resource_stats widoku zarządzania, aby monitorować użycie zasobów poszczególnych baz danych. Aby uzyskać więcej informacji, zobacz sys.dm_db_resource_stats. Jeden wiersz istnieje co 15 sekund, nawet jeśli nie ma żadnego działania. Dane historyczne są przechowywane przez około godzinę.

To przykładowe zapytanie w celu wyświetlenia ostatnich 10 minut danych powinno zostać uruchomione w żądanej bazie danych.

SELECT * FROM sys.dm_db_resource_stats AS rs
WHERE rs.end_time > DATEADD(mi, -10, SYSUTCDATETIME());

Aby uzyskać dłuższy czas przechowywania z mniejszą częstotliwością, rozważ następujące zapytanie w sys.resource_statsusłudze , uruchom polecenie w master bazie danych serwera logicznego Usługi Azure SQL. Aby uzyskać więcej informacji, zobacz sys.resource_stats (Azure SQL Database). Jeden wiersz istnieje co pięć minut, a dane historyczne są przechowywane przez dwa tygodnie.

SELECT * FROM sys.resource_stats
WHERE [database_name] = 'sample'
ORDER BY [start_time] desc;

Monitorowanie wykorzystania pamięci

To zapytanie oblicza oom_per_second metryki dla każdej puli zasobów dla najnowszej historii na podstawie liczby dostępnych migawek. To przykładowe zapytanie pomaga zidentyfikować ostatnią średnią liczbę alokacji pamięci zakończonych niepowodzeniem w puli. To zapytanie można uruchomić w dowolnej bazie danych w elastycznej puli.

SELECT pool_id,
       name AS resource_pool_name,
       IIF(name LIKE 'SloSharedPool%' OR name LIKE 'UserPool%', 'user', 'system') AS resource_pool_type,
       SUM(CAST(delta_out_of_memory_count AS decimal))/(SUM(duration_ms)/1000.) AS oom_per_second
FROM sys.dm_resource_governor_resource_pools_history_ex
GROUP BY pool_id, name
ORDER BY pool_id;

Monitorowanie tempdb wykorzystania miejsca w dzienniku

To zapytanie zwraca bieżącą wartość tempdb_log_used_percent metryki z względnym wykorzystaniem dziennika transakcji względem maksymalnego dozwolonego tempdb rozmiaru. To zapytanie można uruchomić w dowolnej bazie danych w elastycznej puli.

SELECT (lsu.used_log_space_in_bytes / df.log_max_size_bytes) * 100 AS tempdb_log_space_used_percent
FROM tempdb.sys.dm_db_log_space_usage AS lsu
CROSS JOIN (
           SELECT SUM(CAST(max_size AS bigint)) * 8 * 1024. AS log_max_size_bytes
           FROM tempdb.sys.database_files
           WHERE type_desc = N'LOG'
           ) AS df
;

Następne kroki