Zarządzanie zasobami w Azure SQL Database

DOTYCZY: Azure SQL Database

Ten artykuł zawiera omówienie zarządzania zasobami w Azure SQL Database. Zawiera on informacje o tym, co się dzieje po osiągnięciu limitów zasobów, oraz opisuje mechanizmy zarządzania zasobami, które są używane do wymuszania tych limitów.

Aby uzyskać informacje na temat limitów określonych zasobów na warstwę cenową (znaną również jako cel usługi) dla pojedynczych baz danych, zapoznaj się z limitami zasobów pojedynczej bazy danych opartymi na jednostce DTU lub limitami zasobów pojedynczej bazy danych opartymi na rdzeniu wirtualnych. Aby uzyskać informacje na temat limitów zasobów puli elastycznej, zapoznaj się z limitami zasobów puli elastycznej opartymi na jednostce DTU lub limitami zasobów puli elastycznej opartymi na rdzeniu rdzeni wirtualnych.

Porada

Aby uzyskać informacje na SQL usługi Azure SQL Managed Instance, zobacz Limity zasobów dla wystąpień zarządzanych.

Aby Azure Synapse Analytics limity SQL puli, zobacz limity pojemności oraz limity pamięci i współbieżności.

Limity serwerów logicznych

Zasób Limit
Bazy danych na serwer logiczny 5000
Domyślna liczba serwerów logicznych na subskrypcję w regionie 20
Maksymalna liczba serwerów logicznych na subskrypcję w regionie 250
Limit przydziału jednostek DTU/eDTU na serwer logiczny 54,000
Limit przydziału rdzeni wirtualnych na serwer logiczny 540
Maksymalna liczba elastycznych pul na serwer logiczny Ograniczone przez liczbę jednostek DTU lub rdzeni wirtualnych. Jeśli na przykład każda pula ma 1000 jednostek DTU, serwer może obsługiwać 54 pule.

Ważne

Gdy liczba baz danych zbliża się do limitu na serwer logiczny, mogą wystąpić następujące zdarzenia:

  • Zwiększenie opóźnienia w uruchamianiu zapytań względem bazy danych master. Obejmuje to widoki statystyk wykorzystania zasobów, takich jak sys.resource_stats .
  • Zwiększenie opóźnienia operacji zarządzania i renderowania punktów widoków portalu, które obejmują wyliczanie baz danych na serwerze.

Uwaga

Aby uzyskać większy limit przydziału jednostek DTU/eDTU, limit przydziału rdzeni wirtualnych lub więcej serwerów logicznych niż liczba domyślna, prześlij nowy wniosek o pomoc techniczną w Azure Portal. Aby uzyskać więcej informacji, zobacz Żądanie zwiększenia limitu przydziału dla Azure SQL Database.

Co się stanie po osiągnięciu limitów zasobów

Procesor obliczeniowy

Gdy wykorzystanie procesora obliczeniowego bazy danych staje się wysokie, zwiększa się opóźnienie zapytań, a zapytania mogą nawet przekraczać czas. W tych warunkach zapytania mogą być kolejkowane przez usługę i są udostępniane zasoby do wykonania, gdy zasoby stają się bezpłatne. W przypadku wysokiego wykorzystania zasobów obliczeniowych dostępne są następujące opcje ograniczania ryzyka:

Storage

Gdy używana przestrzeń bazy danych osiągnie maksymalny limit rozmiaru danych, baza danych wstawia i aktualizuje dane, które zwiększają rozmiar danych, a klienci otrzymują komunikat o błędzie. Instrukcje SELECT i DELETE pozostają niezmienione.

W Premium i Krytyczne dla działania firmy usług klienci otrzymują również komunikat o błędzie, jeśli łączne użycie magazynu przez dane, dziennik transakcji i bazę danych tempdb przekroczy maksymalny rozmiar magazynu lokalnego. Aby uzyskać więcej informacji, zobacz Storage nadzoru nad przestrzenią.

W przypadku wystąpienia wysokiego wykorzystania miejsca dostępne są następujące opcje ograniczania ryzyka:

  • Zwiększ maksymalny rozmiar danych bazy danych lub elastycznej puli albo przeskaluj w górę do celu usługi z wyższym limitem maksymalnego rozmiaru danych. Zobacz Skalowanie zasobów pojedynczej bazy danych i Skalowanie zasobów elastycznej puli.
  • Jeśli baza danych znajduje się w elastycznej puli, alternatywnie bazę danych można przenieść poza pulę, aby jej miejsce do magazynowania nie było udostępniane innym bazom danych.
  • Zmniejszanie bazy danych w celu odzyskania nieużywanego miejsca. W pulach elastycznych zmniejszanie bazy danych zapewnia więcej miejsca do magazynowania dla innych baz danych w puli. Aby uzyskać więcej informacji, zobacz Zarządzanie przestrzenią plików w Azure SQL Database.
  • Sprawdź, czy wysokie wykorzystanie miejsca jest spowodowane skokowym rozmiarem magazynu trwałych wersji (PVS). PvS jest częścią każdej bazy danych i służy do implementowaćprzyspieszone odzyskiwanie bazy danych . Aby określić bieżący rozmiar pvS, zobacz PVS troubleshooting (Rozwiązywanie problemów z siecią PVS). Częstą przyczyną dużego rozmiaru sieci PVS jest transakcja, która jest otwarta przez długi czas (godziny), uniemożliwiając czyszczenie starszych wersji w sieci PVS.
  • W przypadku dużych baz danych w warstwach usług Premium i Krytyczne dla działania firmy może wystąpić błąd chybnej ilości miejsca, nawet jeśli ilość używanego miejsca w bazie danych jest poniżej maksymalnego limitu rozmiaru danych. Może się tak zdarzyć, jeśli baza danych tempdb lub dziennik transakcji zużywa dużą ilość miejsca w magazynie w celu osiągnięcia maksymalnego limitu magazynu lokalnego. Przejmij bazę danych lub elastyczną pulę w celu zresetowania bazy danych tempdb do początkowego mniejszego rozmiaru lub zmniejszenia dziennika transakcji w celu zmniejszenia użycia magazynu lokalnego.

Sesje i pracownicy (żądania)

Maksymalna liczba sesji i węzłów pracy zależy od warstwy usługi i rozmiaru obliczeniowego. Nowe żądania są odrzucane po osiągnięciu limitów sesji lub procesu roboczego, a klienci otrzymują komunikat o błędzie. Chociaż liczba dostępnych połączeń może być kontrolowana przez aplikację, liczba współbieżnych pracowników jest często trudniejsza do oszacowania i kontroli. Jest to szczególnie istotne w okresach szczytowego obciążenia, gdy zostaną osiągnięte limity zasobów bazy danych, a pracownicy się rozsypują z powodu dłuższych zapytań, dużych łańcuchów blokowania lub nadmiernej równoległości zapytań.

W przypadku wystąpienia wysokiego wykorzystania sesji lub procesu roboczego dostępne są następujące opcje ograniczania ryzyka:

  • Zwiększenie warstwy usługi lub rozmiaru obliczeniowego bazy danych lub elastycznej puli. Zobacz Skalowanie zasobów pojedynczej bazy danych i Skalowanie zasobów elastycznej puli.
  • Optymalizacja zapytań w celu zmniejszenia wykorzystania zasobów poszczególnych zapytań, jeśli przyczyną zwiększonego wykorzystania procesów roboczych jest skwedowanie zasobów obliczeniowych. Aby uzyskać więcej informacji, zobacz Podpowiedzi i dostrajanie zapytań.
  • Zmniejszenie ustawienia MAXDOP (maksymalny stopień równoległości).
  • Optymalizacja obciążenia zapytaniami w celu zmniejszenia liczby wystąpień i czasu trwania blokowania zapytań. Aby uzyskać więcej informacji, zobacz Understand and resolve Azure SQL blocking problems (Opis i rozwiązywanie problemów z blokowaniem usługi Azure SQL).

Pamięć

W przeciwieństwie do innych zasobów (procesora CPU, awarii, magazynu) osiągnięcie limitu pamięci nie ma negatywnego wpływu na wydajność zapytań ani nie powoduje błędów ani błędów. Zgodnie ze szczegółowym opisem w przewodniku po architekturze zarządzania pamięciąaparat bazy danych często używa całej dostępnej pamięci zgodnie z projektem. Pamięć jest używana głównie do buforowania danych, aby uniknąć wolniejszego dostępu do magazynu. W związku z tym większe wykorzystanie pamięci zwykle zwiększa wydajność zapytań ze względu na szybsze odczyty z pamięci, a nie wolniejsze odczyty z magazynu.

Po uruchomieniu aparatu bazy danych, gdy obciążenie rozpoczyna odczytywanie danych z magazynu, aparat bazy danych agresywnie buforuje dane w pamięci. Po początkowym okresie podniesienia często kolumny i w programie sys.dm_db_resource_stats powinny być zbliżone do avg_memory_usage_percent avg_instance_memory_percent 100% lub równe 100%, szczególnie w przypadku baz danych, które nie są bezczynne i nie w pełni mieszczą się w pamięci.

Oprócz pamięci podręcznej danych pamięć jest używana w innych składnikach aparatu bazy danych. Gdy istnieje zapotrzebowanie na pamięć i cała dostępna pamięć została użyta przez pamięć podręczną danych, aparat bazy danych dynamicznie zmniejsza rozmiar pamięci podręcznej danych, aby udostępnić pamięć innym składnikom, i dynamicznie powiększa pamięć podręczną danych, gdy inne składniki zwalniają pamięć.

W rzadkich przypadkach wystarczająco wymagające obciążenie może spowodować niewystarczający stan pamięci, co może prowadzić do błędów braku pamięci. Może się to zdarzyć na dowolnym poziomie wykorzystania pamięci od 0% do 100%. Jest to bardziej prawdopodobne w przypadku mniejszych rozmiarów zasobów obliczeniowych, które mają proporcjonalnie mniejsze limity pamięci i/lub w przypadku obciążeń używających większej ilości pamięci na potrzeby przetwarzania zapytań, takich jak gęste pule elastyczne.

W przypadku wystąpienia błędów braku pamięci dostępne są następujące opcje ograniczania ryzyka:

Rozwiązanie Opis
Zmniejszanie rozmiaru grantów pamięci Aby uzyskać więcej informacji na temat udzielania pamięci, zobacz wpis w blogu Understanding SQL Server memory grant (Informacje o przyznawaniu pamięci). Powszechnym rozwiązaniem w celu uniknięcia nadmiernego grantu pamięci jest utrzymywanie aktualnych statystyk. Powoduje to dokładniejsze oszacowanie zużycia pamięci przez aparat zapytań, co pozwala uniknąć niepotrzebnie dużych grantów pamięci.

W bazach danych korzystających z poziomu zgodności 140 lub powyższego aparat bazy danych może automatycznie dostosowywać rozmiar udzielania pamięci przy użyciu funkcji udzielania opinii o pamięci w trybie wsadowym. W bazach danych korzystających z poziomu zgodności 150 i większej aparat bazy danych podobnie używa opinii o przyznaniu pamięci w trybie wiersza wprzypadku bardziej typowych zapytań w trybie wiersza. Ta wbudowana funkcja pomaga uniknąć błędów braku pamięci z powodu niepotrzebnie dużych grantów pamięci.
Zmniejszanie rozmiaru pamięci podręcznej planu zapytania Aparat bazy danych buforuje plany zapytań w pamięci, aby uniknąć kompilowania planu zapytań dla każdego wykonania zapytania. Aby uniknąć buforowania pamięci podręcznej planu zapytania spowodowanego przez plany buforowania, które są używane tylko raz, włącz konfigurację OPTIMIZE_FOR_AD_HOC_WORKLOADS w zakresie bazy danych.
Zmniejszanie rozmiaru pamięci blokady Aparat bazy danych używa pamięci dla blokad. Jeśli to możliwe, unikaj dużych transakcji, które mogą uzyskać dużą liczbę blokad i spowodować wysokie użycie pamięci blokady.

Zużycie zasobów przez obciążenia użytkowników i procesy wewnętrzne

Azure SQL Database zasobów obliczeniowych w celu zaimplementowania podstawowych funkcji usług, takich jak wysoka dostępność i odzyskiwanie po awarii, tworzenie kopii zapasowych i przywracanie bazy danych, monitorowanie, magazyn zapytań, automatyczne dostrajanie itp. System odkłada pewną ograniczoną część ogólnych zasobów dla tych procesów wewnętrznych przy użyciu mechanizmów zarządzania zasobami, dzięki czemu pozostała część zasobów jest dostępna dla obciążeń użytkowników. W czasie, gdy procesy wewnętrzne nie są przy użyciu zasobów obliczeniowych, system udostępnia je obciążeniom użytkowników.

Łączne użycie procesora CPU i pamięci przez obciążenia użytkowników i procesy wewnętrzne jest zgłaszane w widokach sys.dm_db_resource_stats i sys.resource_stats, w avg_instance_cpu_percent kolumnach avg_instance_memory_percent i . Te dane są również zgłaszane za pośrednictwem metryk Azure Monitor i dla pojedynczych baz danych i sqlserver_process_core_percent sqlserver_process_memory_percent pul elastycznych na poziomie puli.

Użycie procesora i pamięci przez obciążenia użytkowników w każdej bazie danych jest zgłaszane w widokach sys.dm_db_resource_stats i sys.resource_stats, w avg_cpu_percent kolumnach avg_memory_usage_percent i . W przypadku pul elastycznych zużycie zasobów na poziomie puli jest zgłaszane w sys.elastic_pool_resource_stats widoku. Użycie procesora CPU obciążenia użytkownika jest również zgłaszane za pośrednictwem metryki Azure Monitor dla pojedynczych baz danych i cpu_percent pul elastycznych na poziomie puli.

Bardziej szczegółowy podział ostatniego użycia zasobów według obciążeń użytkowników i procesów wewnętrznych jest zgłaszany w widokach sys.dm_resource_governor_resource_pools_history_ex i sys.dm_resource_governor_workload_groups_history_ex użytkownika. Aby uzyskać szczegółowe informacje o pulach zasobów i grupach obciążeń, do których odwołują się te widoki, zobacz Zarządzanie zasobami. Te widoki raportuje wykorzystanie zasobów według obciążeń użytkowników i określonych procesów wewnętrznych w skojarzonych pulach zasobów i grupach obciążeń.

W kontekście monitorowania wydajności i rozwiązywania problemów należy wziąć pod uwagę zarówno użycie procesora CPU użytkownika (, ), jak i całkowite użycie procesora przez obciążenia użytkowników i procesy avg_cpu_percent wewnętrzne ( , cpu_percent avg_instance_cpu_percent sqlserver_process_core_percent ).

Użycie procesora CPU przez użytkownika jest obliczane jako procent limitów obciążenia użytkownika w każdym celu usługi. Użycie procesora CPU użytkownika na poziomie 100% oznacza, że obciążenie użytkownika osiągnęło limit celu usługi. Jednak gdy całkowite użycie procesora CPU osiągnie zakres 70–100%, można zobaczyć, że przepływność obciążenia użytkownika spłaszcza się i zwiększa opóźnienie zapytań, nawet jeśli zgłoszone użycie procesora CPU użytkownika pozostaje znacznie poniżej 100%. Jest to bardziej prawdopodobne w przypadku korzystania z mniejszych celów usługi przy umiarkowanej alokacji zasobów obliczeniowych, ale stosunkowo intensywnych obciążeń użytkowników, takich jak gęste pule elastyczne. Może to również wystąpić w przypadku mniejszych celów usługi, gdy procesy wewnętrzne tymczasowo wymagają dodatkowych zasobów, na przykład podczas tworzenia nowej repliki bazy danych lub tworzenia kopii zapasowej bazy danych.

Gdy łączne użycie procesora CPU jest wysokie, opcje ograniczania ryzyka są takie same jak w sekcji Procesor obliczeniowy i obejmują zwiększenie celu usługi i/lub optymalizację obciążenia użytkownika.

Nadzór nad zasobami

Aby wymusić limity zasobów, Azure SQL Database korzysta z implementacji ładu zasobów opartej na zarządcy zasobów SQL Server,zmodyfikowanej i rozszerzonej do uruchamiania w chmurze. W SQL Database pule zasobów i grupy obciążeń zlimitami zasobów ustawionymi na poziomie puli i grupy zapewniają zrównoważoną bazę danych jako usługę. Obciążenia użytkowników i obciążenia wewnętrzne są klasyfikowane w oddzielnych pulach zasobów i grupach obciążeń. Obciążenie użytkownikami w podstawowych i czytelnych replikach pomocniczych, w tym replikach geograficznych, jest klasyfikowane do puli zasobów i grup obciążeń, gdzie oznacza wartość SloSharedPool1 UserPrimaryGroup.DBId[N] identyfikatora bazy [N] danych. Ponadto istnieje wiele pul zasobów i grup obciążeń dla różnych obciążeń wewnętrznych.

Oprócz korzystania z zarządcy zasobów do zarządzania zasobami w a aparatze bazy danych program Azure SQL Database używa również obiektów zadań usługi Windows do zarządzania zasobami na poziomie procesu oraz usługi Windows File Server Resource Manager (FSRM) do zarządzania przydziałami magazynu.

Azure SQL Database zasobów jest z natury hierarchiczne. Od góry do dołu limity są wymuszane na poziomie systemu operacyjnego i na poziomie woluminu magazynu przy użyciu mechanizmów zarządzania zasobami systemu operacyjnego i zarządcy zasobów, następnie na poziomie puli zasobów przy użyciu zarządcy zasobów, a następnie na poziomie grupy obciążeń przy użyciu zarządcy zasobów. Limity ładu zasobów obowiązujące dla bieżącej bazy danych lub elastycznej puli są zgłaszane w widoku sys.dm_user_db_resource_governance zasobów.

Ład we/wy danych

Ład we/wy danych to proces w Azure SQL Database w celu ograniczenia odczytu i zapisu fizycznych we/wy względem plików danych bazy danych. Limity IOPS są ustawiane dla każdego poziomu usługi w celu zminimalizowania efektu "hałaśliwego sąsiada", zapewnienia sprawiedliwości alokacji zasobów w usłudze wielodostępnej i pozostania w zakresie możliwości podstawowego sprzętu i magazynu.

W przypadku pojedynczych baz danych limity grup obciążeń są stosowane do wszystkich we/wy magazynu względem bazy danych. W przypadku pul elastycznych limity grup obciążeń mają zastosowanie do każdej bazy danych w puli. Ponadto limit puli zasobów jest dodatkowo stosowana do skumulowanych we/wy puli elastycznej. We/wy bazy danych Tempdb podlegają limitom grup obciążeń, z wyjątkiem warstwy usługi Podstawowa, Standardowa i Ogólnego przeznaczenia, w której mają zastosowanie wyższe limity we/wy bazy danych tempdb. Ogólnie rzecz biorąc, limity puli zasobów mogą być nieoczywalne dla obciążenia bazy danych (pojedynczej lub w puli), ponieważ limity grup obciążeń są niższe niż limity puli zasobów i wcześniej ograniczają liczbę IOPS/przepływność. Jednak łączne obciążenie może osiągać limity puli dla wielu baz danych w tej samej puli.

Jeśli na przykład zapytanie generuje 1000 IOPS bez nadzoru nad zasobami we/wy, ale maksymalny limit liczby IOPS grupy obciążeń jest ustawiony na 900 IOPS, zapytanie nie będzie w stanie wygenerować więcej niż 900 IOPS. Jeśli jednak maksymalny limit liczby IOPS puli zasobów jest ustawiony na 1500 IOPS, a łączna liczba we/wy ze wszystkich grup obciążeń skojarzonych z pulą zasobów przekracza 1500 IOPS, liczba we/wy tego samego zapytania może zostać zmniejszona poniżej limitu 900 IOPS grupy roboczej.

Wartości maksymalnej wartości IOPS i przepływności zwracane przez widok sys.dm_user_db_resource_governance działają jako limity/limity, a nie jako gwarancje. Ponadto nadzór nad zasobami nie gwarantuje żadnego określonego opóźnienia magazynu. Najlepsze możliwe do wykorzystania opóźnienie, IOPS i przepływność dla danego obciążenia użytkownika zależą nie tylko od limitów zarządzania zasobami we/wy, ale również od kombinacji używanych rozmiarów operacji we/wy oraz od możliwości bazowego magazynu. SQL Database korzysta z we/wy o różnych rozmiarach od 512 KB do 4 MB. Na potrzeby wymuszania limitów IOPS każde we/wy jest uwzględniane niezależnie od jego rozmiaru, z wyjątkiem baz danych z plikami danych w usłudze Azure Storage. W takim przypadku iOs większe niż 256 KB są rozliczane jako wiele obiektów we/wy o rozmiarze 256 KB, aby dostosować je do ewidencjonowania Storage Platformy Azure.

W przypadku baz danych w warstwie Podstawowa, Standardowa i Ogólnego przeznaczenia, które korzystają z plików danych w usłudze Azure Storage, wartość może nie być osiągalna, jeśli baza danych nie ma wystarczającej liczby plików danych, aby zbiorczo podać tę liczbę IOPS, lub jeśli dane nie są równomiernie dystrybuowane między plikami lub jeśli warstwa wydajności bazowych obiektów blob ogranicza liczbę IOPS/przepływność poniżej limitów ładu primary_group_max_io zasobów. Podobnie w przypadku małych operacji we/wy dzienników generowanych przez częste zatwierdzanie transakcji wartość może być nieoczyszczona przez obciążenie z powodu limitu liczby operacji we/wy na we/wy na bazowy obiekt blob usługi primary_max_log_rate Azure Storage blob. W przypadku baz danych korzystających z usługi Azure Premium Storage Azure SQL Database używa wystarczająco dużych obiektów blob magazynu, aby uzyskać potrzebną liczbę IOPS/przepływność, niezależnie od rozmiaru bazy danych. W przypadku większych baz danych tworzonych jest wiele plików danych w celu zwiększenia całkowitej liczby IOPS/pojemności przepływności.

Wartości wykorzystania zasobów, takie jak i , zgłaszane w widokach sys.dm_db_resource_stats , sys.resource_stats i sys.elastic_pool_resource_stats, są obliczane jako wartości procentowe maksymalnych avg_data_io_percent avg_log_write_percent limitów zarządzania zasobami. W związku z tym, gdy czynniki inne niż zarządzanie zasobami ograniczają liczbę IOPS/przepływność, można zobaczyć, że liczba IOPS/przepływność spłaszcza się, a opóźnienia rosną w miarę wzrostu obciążenia, mimo że zgłoszone wykorzystanie zasobów pozostaje poniżej 100%.

Aby określić odczyt i zapis operacji we/wy na sekundę, przepływność i opóźnienie na plik bazy danych, użyj funkcji sys.dm_io_virtual_file_stats(). Ta funkcja dotyczy wszystkich operacji we/wy bazy danych, w tym operacji we/wy w tle, które nie są uwzględnione w operacji we/wy, ale używa operacji we/wy na koncie i przepływności bazowego magazynu oraz może mieć wpływ na zaobserwowane opóźnienie avg_data_io_percent magazynu. Funkcja zgłasza dodatkowe opóźnienie, które może zostać wprowadzone przez nadzór nad zasobami we/wy dla operacji odczytu i zapisu, odpowiednio w io_stall_queued_read_ms io_stall_queued_write_ms kolumnach i .

Zarządzanie szybkością dziennika transakcji

Zarządzanie szybkością dziennika transakcji to proces w Azure SQL Database używany do ograniczania szybkości pozyskiwania dla obciążeń, takich jak zbiorcze wstawianie, WYBIERANIE DO i kompilacje indeksów. Te limity są śledzone i wymuszane na poziomie niesekundowym do szybkości generowania rekordów dzienników, co ogranicza przepływność niezależnie od tego, ile we/wy może zostać wystawionych dla plików danych. Współczynniki generowania dzienników transakcji są obecnie skalowane liniowo w górę do punktu zależnego od sprzętu i warstwy usługi.

Stawki dzienników są ustawiane w taki sposób, aby można je było osiągnąć i utrzymać w różnych scenariuszach, podczas gdy cały system może zachować funkcjonalność przy zminimalizowanym wpływie na obciążenie użytkowników. Zarządzanie szybkością dzienników zapewnia, że kopie zapasowe dziennika transakcji pozostają w ramach opublikowanych sla możliwości odzyskiwania. Ten ład zapobiega również nadmiernej zaległości w replikach pomocniczych, co w przeciwnym razie może prowadzić do dłuższego niż oczekiwano przestoju podczas pracy w trybu failover.

Rzeczywiste fizyczne pliki dziennika operacji we/wy na transakcje nie podlegają ani nie są ograniczone. Podczas generowania rekordów dzienników każda operacja jest oceniana i oceniana pod uwagę, czy powinna być opóźniona w celu zachowania maksymalnej wymaganej szybkości dziennika (MB/s na sekundę). Opóźnienia nie są dodawane, gdy rekordy dziennika są opróżnione do magazynu, a zarządzanie szybkością dzienników jest stosowane podczas generowania szybkości dzienników.

Na rzeczywiste stawki generowania dzienników narzucone w czasie działania mogą mieć również wpływ mechanizmy opinii, tymczasowo zmniejszając dopuszczalne wartości dzienników, dzięki czemu system może się ustabilizować. Zarządzanie przestrzenią plików dziennika, uniknięcie sytuacji, w których nie ma miejsca w dzienniku, i mechanizmów replikacji danych może tymczasowo zmniejszyć ogólne limity systemu.

Kształtowanie ruchu zarządcy szybkości dzienników jest udostępniane za pośrednictwem następujących typów oczekiwania (widoczne w widokach sys.dm_exec_requests i sys.dm_os_wait_stats danych):

Typ oczekiwania Uwagi
LOG_RATE_GOVERNOR Ograniczanie bazy danych
POOL_LOG_RATE_GOVERNOR Ograniczanie puli
INSTANCE_LOG_RATE_GOVERNOR Ograniczanie poziomu wystąpienia
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE Kontrola opinii, replikacja fizyczna grupy dostępności w Premium/Krytyczne dla działania firmy nadąża za
HADR_THROTTLE_LOG_RATE_LOG_SIZE Kontrola opinii, ograniczanie liczby w celu uniknięcia stanu poza obszarem dziennika
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO Kontrola opinii replikacji geograficznej, ograniczanie szybkości dzienników w celu uniknięcia dużych opóźnień danych i niedostępności geograficznych danych dodatkowych

W przypadku napotkania limitu szybkości dziennika, który zakłóca żądaną skalowalność, należy wziąć pod uwagę następujące opcje:

  • Skaluj w górę do wyższego poziomu usługi, aby uzyskać maksymalną szybkość dziennika warstwy usługi, lub przełącz się do innej warstwy usługi. Warstwa usługi Hiperskala zapewnia szybkość dziennika 100 MB/s niezależnie od wybranego poziomu usługi.
  • Jeśli ładowane dane są przejściowe, takie jak dane przejściowe w procesie ETL, można je załadować do bazy danych tempdb (co jest rejestrowane w minimalnym stopniu).
  • W przypadku scenariuszy analitycznych załaduj dane do tabeli klastrowanego magazynu kolumn lub tabeli z indeksami, które używają kompresji danych. Zmniejsza to wymagany odsetek dzienników. Ta technika zwiększa wykorzystanie procesora CPU i ma zastosowanie tylko do zestawów danych, które korzystają z klastrowanych indeksów magazynu kolumn lub kompresji danych.

Storage nadzoru nad przestrzenią kosmiczną

W warstwach usług Premium i Krytyczne dla działania firmy dane klientów, w tym pliki danych, pliki dziennika transakcji i pliki tempdb, są przechowywane w lokalnym magazynie SSD maszyny hostującym bazę danych lub pulę elastyczną. Lokalny magazyn SSD zapewnia dużą przepływność i dużą ilość operacji we/wy oraz małe opóźnienia operacji we/wy. Oprócz danych klienta magazyn lokalny jest używany na potrzeby systemu operacyjnego, oprogramowania do zarządzania, danych monitorowania i dzienników oraz innych plików niezbędnych do działania systemu.

Rozmiar magazynu lokalnego jest ograniczony i zależy od możliwości sprzętowych, które określają maksymalny limit magazynu lokalnego lub magazynu lokalnego przeznaczonego na dane klienta. Ten limit jest ustawiany w celu zmaksymalizowania magazynu danych klienta przy jednoczesnym zapewnieniu bezpiecznego i niezawodnego działania systemu. Aby znaleźć maksymalną wartość magazynu lokalnego dla każdego celu usługi, zobacz dokumentację limitów zasobów dla pojedynczych baz danych i pul elastycznych.

Możesz również znaleźć tę wartość i ilość magazynu lokalnego aktualnie używanego przez tę bazę danych lub pulę elastyczną, używając następującego zapytania:

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();
Kolumna Opis
server_name Nazwa serwera logicznego
database_name Nazwa bazy danych
slo_name Nazwa celu usługi, w tym generacja sprzętu
user_data_directory_space_quota_mb Maksymalny rozmiar magazynu lokalnego w MB
user_data_directory_space_usage_mb Bieżące zużycie magazynu lokalnego przez pliki danych, pliki dziennika transakcji i pliki tempdb w MB. Aktualizowane co pięć minut.

To zapytanie powinno być wykonywane w bazie danych użytkownika, a nie w bazie danych master. W przypadku pul elastycznych zapytanie można wykonać w dowolnej bazie danych w puli. Zgłoszone wartości mają zastosowanie do całej puli.

Ważne

W warstwach usług Premium i Krytyczne dla działania firmy, jeśli obciążenie spróbuje zwiększyć łączne zużycie magazynu lokalnego przez pliki danych, pliki dziennika transakcji i pliki tempdb ponad maksymalny limit magazynu lokalnego, wystąpi błąd poza obszarem.

Gdy bazy danych są tworzone, usuwane oraz zwiększają się lub zmniejszają rozmiar, zużycie magazynu lokalnego na maszynie zmienia się wraz z czasem. Jeśli system wykryje, że dostępny magazyn lokalny na maszynie jest niski, a baza danych lub elastyczna pula jest za mało miejsca, baza danych lub elastyczna pula zostanie przesużona na inną maszynę z wystarczającą dostępną pamięcią lokalną.

To przeniesienie odbywa się w trybie online, podobnie jak operacja skalowania bazy danych, i ma podobny wpływ ,w tym krótki (w sekundach) tryb failover na końcu operacji. Ta trybu failover kończy otwarte połączenia i wycofuje transakcje, potencjalnie wpływając na aplikacje korzystające z bazy danych w tym czasie.

Ponieważ wszystkie dane są kopiowane do lokalnych woluminów magazynu na różnych maszynach, przenoszenie większych baz danych może wymagać znacznego czasu. W tym czasie, jeśli zużycie miejsca lokalnego przez bazę danych lub pulę elastyczną albo przez bazę danych tempdb szybko rośnie, zwiększa się ryzyko zaoki. System inicjuje ruch bazy danych w sposób zrównoważony, aby zminimalizować błędy związane z przestrzenią, jednocześnie unikając niepotrzebnych awarii.

Uwaga

Ruch bazy danych z powodu niewystarczającej ilości magazynu lokalnego występuje tylko w Premium lub Krytyczne dla działania firmy usług. Nie występuje w warstwach usług Hiperskala, Ogólnego przeznaczenia, Standardowa i Podstawowa, ponieważ w tych warstwach pliki danych nie są przechowywane w magazynie lokalnym.

Następne kroki