Skalowanie zasobów pojedynczej bazy danych w usłudze Azure SQL Database

W tym artykule opisano sposób skalowania zasobów obliczeniowych i magazynowych dostępnych dla usługi Azure SQL Database w aprowizowanej warstwie obliczeniowej. Alternatywnie bezserwerowa warstwa obliczeniowa zapewnia skalowanie automatyczne obliczeń i opłaty na sekundę dla używanych zasobów obliczeniowych.

Po początkowym wybraniu liczby rdzeni wirtualnych lub jednostek DTU można skalować pojedynczą bazę danych w górę lub w dół dynamicznie na podstawie rzeczywistego środowiska przy użyciu:

Ważne

W pewnych okolicznościach może być konieczne zmniejszenie bazy danych w celu odzyskania nieużywanego miejsca. Aby uzyskać więcej informacji, zobacz Zarządzanie miejscem na pliki w usłudze Azure SQL Database.

Uwaga

Microsoft Entra ID był wcześniej znany jako Azure Active Directory (Azure AD).

Wpływ

Zmiana warstwy usługi lub rozmiaru obliczeniowego obejmuje głównie usługę wykonującą następujące czynności:

  1. Utwórz nowe wystąpienie obliczeniowe dla bazy danych.

    Zostanie utworzone nowe wystąpienie obliczeniowe z żądaną warstwą usługi i rozmiarem obliczeniowym. W przypadku niektórych kombinacji warstwy usług i zmian rozmiaru obliczeniowego należy utworzyć replikę bazy danych w nowym wystąpieniu obliczeniowym, które obejmuje kopiowanie danych i może mieć duży wpływ na ogólne opóźnienie. Niezależnie od tego, baza danych pozostaje w trybie online w tym kroku, a połączenia nadal są kierowane do bazy danych w oryginalnym wystąpieniu obliczeniowym.

  2. Przełączanie routingu połączeń do nowego wystąpienia obliczeniowego.

    Istniejące połączenia z bazą danych w oryginalnym wystąpieniu obliczeniowym są porzucane. Wszystkie nowe połączenia są ustanawiane z bazą danych w nowym wystąpieniu obliczeniowym. W przypadku niektórych kombinacji zmian warstwy usługi i rozmiaru obliczeniowego pliki bazy danych są odłączane i ponownie dołączane podczas przełączania. Niezależnie od tego przełącznik może spowodować krótką przerwę w działaniu usługi, gdy baza danych jest ogólnie niedostępna przez mniej niż 30 sekund i często trwa tylko kilka sekund. Jeśli podczas porzucania połączeń występują długotrwałe transakcje, czas trwania tego kroku może potrwać dłużej, aby odzyskać przerwane transakcje. Przyspieszone odzyskiwanie bazy danych może zmniejszyć wpływ na przerywanie długotrwałych transakcji.

Ważne

Żadne dane nie są tracone w żadnym kroku przepływu pracy. Upewnij się, że zaimplementowano logikę ponawiania prób w aplikacjach i składnikach korzystających z usługi Azure SQL Database podczas zmiany warstwy usługi.

Opóźnienie

Szacowane opóźnienie zmiany warstwy usługi, skalowanie rozmiaru obliczeniowego pojedynczej bazy danych lub elastycznej puli, przenoszenie bazy danych do elastycznej puli lub przenoszenie bazy danych między pulami elastycznymi jest sparametryzowane w następujący sposób:

Opóźnienie skalowania bazy danych Do podstawowej pojedynczej bazy danych,
pojedyncza baza danych w warstwie Standardowa (S0-S1)
Do standardowej pojedynczej bazy danych (S2-S12),
pojedyncza baza danych ogólnego przeznaczenia,Podstawowa
elastyczna baza danych w puli,Standardowa elastyczna baza danych,Baza

danych w puli ogólnego przeznaczenia
Do pojedynczej bazy danych w warstwie Premium lub bazy danych w puli Krytyczne dla działania firmy
pojedynczej bazy danych lub bazy danych w puli
Do pojedynczej bazy danych w warstwie Hiperskala lub bazy danych w puli
Z pojedynczej bazy danych w warstwie Podstawowa,
pojedyncza baza danych w warstwie Standardowa (S0-S1)
• Stałe opóźnienie czasu niezależne od używanego miejsca.
• Zazwyczaj mniej niż 5 minut.
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
Z bazy danych w puli Podstawowa,
pojedyncza baza danych w warstwie Standardowa (S2-S12),
baza danych w puli w warstwie Standardowa,
pojedyncza baza danych ogólnego przeznaczenia lub baza danych w puli
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
• W przypadku pojedynczych baz danych stałe opóźnienie czasu niezależne od używanego miejsca.
• Zazwyczaj mniej niż 5 minut dla pojedynczych baz danych.
• W przypadku pul elastycznych proporcjonalnie do liczby baz danych.
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
Z pojedynczej bazy danych w warstwie Premium lub bazy danych
w puli Krytyczne dla działania firmy pojedynczej bazy danych lub bazy danych w puli
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych.
• Zazwyczaj mniej niż 1 minuta na GB używanego miejsca.
Z pojedynczej bazy danych w warstwie Hiperskala lub bazy danych w puli Nie dotyczy Zobacz Migracja odwrotna z warstwy Hiperskala , aby zapoznać się z obsługiwanymi scenariuszami i ograniczeniami. Nie dotyczy • Stałe opóźnienie czasu niezależne od używanego miejsca.
• Zazwyczaj mniej niż 2 minuty.

Uwaga

  • Ponadto w przypadku baz danych w warstwie Standardowa (S2-S12) i ogólnego przeznaczenia opóźnienie przenoszenia bazy danych w puli elastycznej lub między pulami elastycznymi będzie proporcjonalne do rozmiaru bazy danych, jeśli baza danych korzysta z magazynu udziału plików w warstwie Premium (PFS).
  • W przypadku przenoszenia bazy danych do/z elastycznej puli tylko miejsce używane przez bazę danych ma wpływ na opóźnienie, a nie miejsce używane przez pulę elastyczną.
  • Aby określić, czy baza danych korzysta z magazynu PFS, wykonaj następujące zapytanie w kontekście bazy danych. Jeśli wartość w kolumnie AccountType to PremiumFileStorage lub PremiumFileStorage-ZRS, baza danych używa magazynu PFS.
SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

Uwaga

  • Właściwość strefowo nadmiarowa pozostanie domyślnie taka sama podczas skalowania pojedynczej bazy danych z Krytyczne dla działania firmy do warstwy Ogólnego przeznaczenia.
  • Opóźnienie operacji skalowania w przypadku zmiany nadmiarowości strefy dla pojedynczej bazy danych ogólnego przeznaczenia jest proporcjonalne do rozmiaru bazy danych.

Monitorowanie lub anulowanie zmian skalowania

Można monitorować i anulować operację zmiany warstwy usług lub operacji skalowania zasobów obliczeniowych.

Na stronie Przegląd bazy danych SQL wyszukaj baner wskazujący, że trwa operacja skalowania, a następnie wybierz link Zobacz więcej dla wdrożenia w toku.

Screenshot from the Azure portal showing a scaling operation in progress.

Na wynikowej stronie Bieżące operacje wybierz pozycję Anuluj tę operację.

Screenshot from the Azure portal showing the Ongoing operations page and the cancel this operation button.

Uprawnienia

Do skalowania baz danych za pomocą języka Transact-SQL ALTER DATABASE jest używany. Aby skalować bazę danych, identyfikator logowania musi być identyfikatorem logowania administratora serwera (utworzonym podczas aprowizowania serwera logicznego usługi Azure SQL Database), administratorem firmy Microsoft Entra serwera, członkiem roli bazy danych dbmanager w programie , członkiem roli bazy danych db_owner w masterbieżącej bazie danych lub dbo bazy danych. Aby uzyskać więcej informacji, zobacz ALTER DATABASE.

Aby skalować bazy danych za pośrednictwem witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST, wymagane są uprawnienia RBAC platformy Azure, w szczególności role Współautor, Współautor bazy danych SQL lub Współautor RBAC programu SQL Server. Aby uzyskać więcej informacji, odwiedź stronę Role wbudowane kontroli dostępu opartej na rolach platformy Azure.

Uwagi dodatkowe

  • W przypadku uaktualniania do wyższej warstwy usługi lub wyższego rozmiaru obliczeniowego maksymalny rozmiar bazy danych nie zwiększa się, chyba że jawnie określisz większy rozmiar (maxsize).
  • Aby obniżyć poziom bazy danych, używana przestrzeń bazy danych musi być mniejsza niż maksymalny dozwolony rozmiar docelowej warstwy usług i rozmiar obliczeniowy.
  • W przypadku obniżenia z warstwy Premium do warstwy Standardowa dodatkowy koszt magazynowania ma zastosowanie, jeśli maksymalny rozmiar bazy danych jest obsługiwany w docelowym rozmiarze obliczeniowym, a (2) maksymalny rozmiar magazynu przekracza uwzględniony rozmiar docelowego rozmiaru obliczeniowego. Jeśli na przykład baza danych P1 o maksymalnym rozmiarze 500 GB zostanie wyłączona do warstwy S3, zostanie zastosowany dodatkowy koszt magazynowania, ponieważ usługa S3 obsługuje maksymalny rozmiar 1 TB, a jego uwzględniona ilość miejsca do magazynowania wynosi tylko 250 GB. Dlatego dodatkowa ilość miejsca do magazynowania wynosi 500 GB – 250 GB = 250 GB. Aby uzyskać cennik dodatkowego magazynu, zobacz Cennik usługi Azure SQL Database. Jeśli rzeczywista ilość używanego miejsca jest mniejsza niż uwzględniona ilość miejsca do magazynowania, można uniknąć tego dodatkowego kosztu, zmniejszając maksymalny rozmiar bazy danych do uwzględnionej kwoty.
  • Podczas uaktualniania bazy danych z włączoną replikacją geograficzną uaktualnij pomocnicze bazy danych do żądanej warstwy usługi i rozmiaru obliczeniowego przed uaktualnieniem podstawowej bazy danych (ogólne wskazówki dotyczące najlepszej wydajności). Podczas uaktualniania do innej wersji wymagana jest najpierw uaktualnienie pomocniczej bazy danych.
  • W przypadku obniżania poziomu bazy danych z włączoną replikacją geograficzną należy obniżyć jej podstawowe bazy danych do żądanej warstwy usługi i rozmiaru obliczeniowego przed obniżeniem poziomu pomocniczej bazy danych (ogólne wskazówki dotyczące najlepszej wydajności). W przypadku obniżania poziomu do innej wersji należy najpierw obniżyć podstawową bazę danych.
  • Oferowane usługi przywracania różnią się w zależności do warstwy usługi. W przypadku obniżenia poziomu do warstwy Podstawowa jest krótszy okres przechowywania kopii zapasowych. Zobacz Tworzenie kopii zapasowych usługi Azure SQL Database.
  • Nowe właściwości bazy danych nie są stosowane do momentu ukończenia zmian.
  • Gdy kopiowanie danych jest wymagane do skalowania bazy danych (zobacz Opóźnienie) podczas zmiany warstwy usługi, wysokie wykorzystanie zasobów współbieżnych do operacji skalowania może spowodować dłuższe skalowanie. W przypadku przyspieszonego odzyskiwania bazy danych (ADR) wycofywanie długotrwałych transakcji nie jest znaczącym źródłem opóźnienia, ale wysokie współbieżne użycie zasobów może pozostawić mniej zasobów obliczeniowych, magazynu i przepustowości sieci na potrzeby skalowania, szczególnie w przypadku mniejszych rozmiarów obliczeniowych.

Rozliczenia

Opłaty są naliczane za każdą godzinę, w której baza danych istnieje przy użyciu najwyższej warstwy usług i rozmiaru obliczeniowego zastosowanego w tej godzinie, niezależnie od użycia lub tego, czy baza danych była aktywna przez mniej niż godzinę. Jeśli na przykład utworzysz pojedynczą bazę danych i usuniesz ją pięć minut później, rachunek odzwierciedla opłatę za jedną godzinę bazy danych.

Zmienianie rozmiaru magazynu

Model zakupów oparty na rdzeniach wirtualnych

  • Magazyn można aprowizować do maksymalnego limitu rozmiaru magazynu danych przy użyciu przyrostów 1 GB. Minimalny konfigurowalny magazyn danych to 1 GB. Aby uzyskać maksymalne limity rozmiaru magazynu danych w każdym celu usługi, zobacz strony dokumentacji limitu zasobów dla limitów zasobów dla pojedynczych baz danych przy użyciu modelu zakupów rdzeni wirtualnych i limitów zasobów dla pojedynczych baz danych przy użyciu modelu zakupów jednostek DTU.

  • Magazyn danych dla pojedynczej bazy danych można aprowizować przez zwiększenie lub zmniejszenie rozmiaru maksymalnego przy użyciu witryny Azure Portal, języka Transact-SQL, programu PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST. Jeśli wartość rozmiaru maksymalnego jest określona w bajtach, musi być wielokrotnością 1 GB (1073741824 bajtów).

  • Ilość danych, które mogą być przechowywane w plikach danych bazy danych, jest ograniczona przez maksymalny rozmiar skonfigurowanego magazynu danych. Oprócz tego magazynu usługa Azure SQL Database automatycznie dodaje 30% więcej miejsca do użycia w dzienniku transakcji. Cena magazynu dla pojedynczej bazy danych lub elastycznej puli to suma ilości magazynu danych i magazynu dzienników transakcji pomnożona przez cenę jednostkową warstwy usługi. Jeśli na przykład magazyn danych jest ustawiony na 10 GB, dodatkowy magazyn dziennika transakcji wynosi 10 GB * 30% = 3 GB, a łączna kwota rozliczanego magazynu wynosi 10 GB + 3 GB = 13 GB.

    Uwaga

    Maksymalny rozmiar pliku dziennika transakcji jest zarządzany automatycznie, a w niektórych przypadkach może być większy niż 30% maksymalnego rozmiaru magazynu danych. Nie zwiększa to ceny magazynu dla bazy danych.

  • Usługa Azure SQL Database automatycznie przydziela 32 GB na rdzeń wirtualny dla tempdb bazy danych. tempdb znajduje się w lokalnym magazynie SSD we wszystkich warstwach usług. Koszt jest tempdb uwzględniony w cenie pojedynczej bazy danych lub elastycznej puli.

  • Aby uzyskać szczegółowe informacje na temat ceny magazynu, zobacz Cennik usługi Azure SQL Database.

Ważne

W pewnych okolicznościach może być konieczne zmniejszenie bazy danych w celu odzyskania nieużywanego miejsca. Aby uzyskać więcej informacji, zobacz Zarządzanie miejscem na pliki w usłudze Azure SQL Database.

Model zakupów oparty na jednostkach DTU

  • Cena jednostki DTU dla pojedynczej bazy danych obejmuje pewną ilość miejsca do magazynowania bez dodatkowych kosztów. Dodatkowy magazyn, poza uwzględnioną ilością miejsca, można aprowizować za dodatkową opłatą aż do maksymalnego limitu rozmiaru w przyrostach 250 GB do 1 TB, a powyżej 1 TB w przyrostach 256 GB. Aby uzyskać informacje o uwzględnionych ilościach magazynu i maksymalnych limitach rozmiaru, zobacz Single database: Storage sizes and compute sizes (Pojedyncze bazy danych: rozmiary magazynu i rozmiary obliczeniowe).
  • Dodatkowy magazyn dla pojedynczej bazy danych można aprowizować przez zwiększenie rozmiaru maksymalnego przy użyciu witryny Azure Portal, języka Transact-SQL, programu PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST.
  • Cena dodatkowego magazynu dla pojedynczej bazy danych to dodatkowa ilość miejsca w magazynie pomnożona przez dodatkową cenę jednostkową warstwy usług. Aby uzyskać szczegółowe informacje na temat ceny dodatkowego magazynu, zobacz Cennik usługi Azure SQL Database.

Ważne

W pewnych okolicznościach może być konieczne zmniejszenie bazy danych w celu odzyskania nieużywanego miejsca. Aby uzyskać więcej informacji, zobacz Zarządzanie miejscem na pliki w usłudze Azure SQL Database.

Baza danych z replikacją geograficzną

Aby zmienić rozmiar bazy danych dla zreplikowanej pomocniczej bazy danych, zmień rozmiar podstawowej bazy danych. Ta zmiana zostanie następnie zreplikowana i zaimplementowana również w pomocniczej bazie danych.

Ograniczenia P11 i P15 w przypadku maksymalnego rozmiaru większego niż 1 TB

Ponad 1 TB magazynu w warstwie Premium jest obecnie dostępne we wszystkich regionach, z wyjątkiem: Chiny Wschodnie, Chiny Północne, Niemcy Środkowe i Niemcy Północno-Wschodnie. W tych regionach maksymalna wielkość magazynu w warstwie Premium jest ograniczona do 1 TB. Następujące zagadnienia i ograniczenia dotyczą baz danych P11 i P15 o maksymalnym rozmiarze większym niż 1 TB:

  • Jeśli maksymalny rozmiar bazy danych P11 lub P15 został kiedykolwiek ustawiony na wartość większą niż 1 TB, można go przywrócić lub skopiować tylko do bazy danych P11 lub P15. Następnie bazę danych można ponownie przeskalować do innego rozmiaru obliczeniowego, pod warunkiem że ilość miejsca przydzielonego w czasie operacji skalowania ponownego nie przekracza maksymalnych limitów rozmiaru nowego rozmiaru obliczeniowego.
  • W przypadku aktywnych scenariuszy replikacji geograficznej:
    • Konfigurowanie relacji replikacji geograficznej: jeśli podstawowa baza danych to P11 lub P15, pomocniczy (ies) musi być również P11 lub P15. Mniejsze rozmiary obliczeniowe są odrzucane jako pomocnicze, ponieważ nie są w stanie obsługiwać więcej niż 1 TB.
    • Uaktualnianie podstawowej bazy danych w relacji replikacji geograficznej: zmiana maksymalnego rozmiaru na więcej niż 1 TB w podstawowej bazie danych powoduje taką samą zmianę w pomocniczej bazie danych. Aby zmiany podstawowe zaczęły obowiązywać, oba uaktualnienia muszą zakończyć się pomyślnie. Obowiązują ograniczenia regionów dla opcji większej niż 1 TB. Jeśli pomocnicza znajduje się w regionie, który nie obsługuje więcej niż 1 TB, podstawowy nie jest uaktualniany.
  • Ładowanie baz danych P11/P15 z więcej niż 1 TB za pomocą usługi Import/Export nie jest obsługiwane. Importowanie i eksportowanie danych za pomocą pakietu SqlPackage.

Aby uzyskać ogólne limity zasobów, zobacz Limity zasobów opartych na rdzeniach wirtualnych usługi Azure SQL Database — pojedyncze bazy danych i limity zasobów oparte na jednostkach DTU usługi Azure SQL Database — pojedyncze bazy danych.