Zarządzanie zasobami w ramach gęstych pul elastycznych

Dotyczy: baza danych Azure SQL

Azure SQL Elastyczne pule bazy danych 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 procesu roboczego, 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, aby system dokładnie kontrolować użycie zasobów, aby zminimalizować efekt "hałaśliwy sąsiad", w którym baza danych o wysokim zużyciu zasobów wpływa na inne bazy danych w tej samej elastycznej puli. Azure SQL Database osiąga te cele, implementując nadzór nad zasobami. Jednocześnie system musi zapewniać 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 procesami wewnętrznymi 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 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 mieć negatywny wpływ 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 problemów z rywalizacją o zasoby i wydajnością, zależy od liczby współbieżnie aktywnych baz danych oraz zużycia zasobów przez obciążenia użytkowników w każdej bazie danych. Ta liczba może zmieniać się wraz z upływem czasu w miarę zmiany obciążeń użytkowników.

Ponadto, jeśli minimalna liczba rdzeni wirtualnych na bazę danych lub minimalna liczba jednostek DTU na bazę danych jest 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 rdzeni wirtualnych w puli i Właściwości bazy danych dla baz danych jednostek 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 rozwiązać ten problem:

  • Dostrajanie obciążenia zapytań w celu zmniejszenia zużycia zasobów lub rozłożenia zuż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 przynosi korzyści zarówno dla obciążeń użytkowników, jak i procesów wewnętrznych, i umożliwia systemowi niezawodne utrzymywanie oczekiwanego poziomu usług.

Monitorowanie zużycia zasobów

Aby uniknąć obniżenia wydajności z powodu rywalizacji o zasoby, klienci korzystający z gęstych elastycznych pul powinni aktywnie monitorować zużycie zasobów i podejmować czasowe 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.

Azure SQL Database udostępnia kilka metryk, które są istotne dla tego typu monitorowania. Przekroczenie zalecanej średniej wartości dla każdej metryki wskazuje rywalizację o zasoby w puli i należy rozwiązać ten 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 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, jeśli jest to konieczne w danym scenariuszu. Aby zapoznać się z przykładowym scenariuszem monitorowania elastycznych pul, zobacz Monitorowanie wydajności usługi Azure SQL Database w wielodostępnej aplikacji SaaS i zarządzanie nią.

Nazwa metryki Opis Zalecana średnia wartość
avg_instance_cpu_percent Użycie procesora CPU procesu SQL skojarzonego z pulą elastyczną mierzone przez bazowy system operacyjny. Dostępne w widoku sys.dm_db_resource_stats w każdej bazie danych oraz w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie jest nazwanasqlserver_process_core_percent i może być widoczna w 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ć dopuszczalne.
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ępne w widoku sys.dm_db_resource_stats w każdej bazie danych oraz w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie jest nazwanaworkers_percent i może być widoczna w 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ępne w widoku sys.dm_db_resource_stats w każdej bazie danych oraz w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie jest nazwanaphysical_data_read_percent i może być widoczna w Azure Portal. Poniżej 80%. Czasami 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ępne w widoku sys.dm_db_resource_stats w każdej bazie danych oraz w widoku sys.elastic_pool_resource_stats w master bazie danych. Ta metryka jest również emitowana do usługi Azure Monitor, gdzie jest nazwanalog_write_percent i może być widoczna w 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%. Czasami krótkie skoki do 100% mogą być dopuszczalne.
oom_per_second Szybkość błędów braku pamięci (OOM) w elastycznej puli, co jest wskaźnikiem ciśnienia pamięci. Dostępne 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 korzystających z jednostek DTU lub pul elastycznych 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 jest nazwanastorage_percent i może być widoczna w Azure Portal. Poniżej 80%. Może zbliżyć się do 100% w przypadku pul bez wzrostu danych.
avg_allocated_storage_percent Łączna ilość miejsca do magazynowania używanego przez pliki bazy danych w magazynie 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 jest nazwanaallocated_data_storage_percent i może być widoczna w Azure Portal. Poniżej 90%. Może zbliżyć się do 100% w przypadku 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 Azure Portal. Zobacz Przykłady przykładowego zapytania, aby zwrócić bieżącą wartość tej metryki. Poniżej 50%. Od czasu do czasu skoki do 80% są dopuszczalne.

Oprócz tych metryk usługa Azure SQL Database udostępnia widok, który zwraca rzeczywiste limity nadzoru nad zasobami, 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 zarządzania zasobami 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.

Porada

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 podstawowej i czytelnej repliki pomocniczej, w tym repliki geograficzne, 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 pul gęstych mogą utrzymywać historyczne dane użycia zasobów w oddzielnym magazynie danych. Te dane mogą być używane w analizie predykcyjnej do aktywnego zarządzania wykorzystaniem zasobów na podstawie historycznych i sezonowych trendów.

Zalecenia operacyjne

Pozostaw wystarczającą ilość miejsca na zasoby. W przypadku wystąpienia rywalizacji o zasoby i obniżenia 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 jest długotrwałą operacją intensywnie korzystającą 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 puli elastycznej, którego dotyczy problem, może być jedynym rozwiązaniem.

Klienci korzystający z gęstych pul powinni ściśle 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 pulach gęstych 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 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 użycia bazy danych. Jest on tworzony 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 zasobów (procesora CPU, operacji we/wy danych, operacji we/wy dziennika itp.), nawet jeśli raportowanie jednostek eDTU dla puli nie wskazuje osiągnięcia limitu.

Nie przenoś "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 w przypadku przenoszenia 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 żadnej korzyści w tym przypadku, ponieważ nie powoduje istotnego zmniejszenia wykorzystania zasobów na poziomie puli.

Utwórz nowe bazy danych w puli "kwarantanna". W scenariuszach, w których nowe bazy danych są często tworzone, 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 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 ją przenieść 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 trendy przydzielonego miejsca 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łkowitej ilości 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 uwzględniania pustego miejsca w plikach), trendy 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łkowitej ilości używanego miejsca
  • Przenoszenie (archiwizowanie) danych poza bazą danych lub usuwanie danych nie jest już potrzebne
  • 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 nieprawidłowe 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 ustawień pojemności poszczególnych baz danych

Widok dynamicznego sys.dm_user_db_resource_governance zarządzania umożliwia wyświetlenie rzeczywistych ustawień konfiguracji i pojemności używanych 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

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

To przykładowe zapytanie w celu wyświetlenia ostatnich 10 minut powinno zostać uruchomione w master bazie danych serwera Azure SQL logicznego zawierającego żądaną pulę elastyczną.

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ć zuż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 żadnej aktywności. 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_statssystemie , uruchom polecenie w master bazie danych serwera logicznego 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, przedstawiającą względne wykorzystanie 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