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 Azure SQL Database w aprowizowanych warstwach obliczeniowych. Alternatywnie warstwa obliczeniowa bez serwera zapewnia automatyczne skalowanie obliczeń i rachunki za sekundę dla używanych zasobów obliczeniowych.

Po początkowym wybieraniu liczby rdzeni wirtualnych lub jednostek DTU można dynamicznie skalować pojedynczą bazę danych w górę lub w dół na podstawie rzeczywistego doświadczenia, używając:

Poniższy klip wideo przedstawia dynamiczne zmienianie warstwy usługi i rozmiaru obliczeniowego w celu zwiększenia liczby dostępnych jednostek DTU dla pojedynczej bazy danych.

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 przestrzenią plików w programie Azure SQL Database.

Wpływ

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

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

    Tworzone jest nowe wystąpienie obliczeniowe z żądaną warstwą usługi i rozmiarem obliczeniowym. W przypadku niektórych kombinacji zmian warstwy usługi i rozmiaru zasobów obliczeniowych replika bazy danych musi zostać utworzona w nowym wystąpieniu obliczeniowym, co 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 są nadal kierowane do bazy danych w oryginalnym wystąpieniu obliczeniowym.

  2. Przełącz routing 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ą ustanowione z bazą danych w nowym wystąpieniu obliczeniowym. W przypadku niektórych kombinacji zmian warstwy usługi i rozmiaru zasobów obliczeniowych pliki bazy danych są odłączane i ponownie dopinane 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, a często tylko przez kilka sekund. Jeśli istnieją długotrwałe transakcje uruchomione po porzuceniu połączeń, czas trwania tego kroku może potrwać dłużej, aby odzyskać przerwane transakcje. przyspieszone odzyskiwanie bazy danych może zmniejszyć wpływ przerywania długotrwałych transakcji.

Ważne

Żadne dane nie są utracone podczas dowolnego kroku przepływu pracy. Upewnij się, że zaimplementowano logikę ponawiania prób w aplikacjach i składnikach, które 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 elastycznymi pulami jest sparametryzowane w następujący sposób:

Warstwa usług Podstawowa pojedyncza baza danych,
Standardowa (S0–S1)
Podstawowa pula elastyczna,
Standardowa (S2–S12),
Ogólnego przeznaczenia pojedynczej bazy danych lub elastycznej puli
Premium lub Krytyczne dla działania firmy pojedyncza baza danych lub elastyczna pula Hiperskala
Podstawowa pojedyncza baza
danych, Standardowa (S0-S1)
• Stałe opóźnienie czasu niezależne od używanego miejsca
• Zwykle mniej niż 5 minut
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle mniej niż 1 minuta na GB używanego miejsca
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle mniej niż 1 minuta na GB używanego miejsca
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle mniej niż 1 minuta na GB używanego miejsca
Podstawowa pula
elastyczna, Standardowa (S2-S12),
Ogólnego przeznaczenia pojedyncza baza danych lub pula elastyczna
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle 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
• Zwykle mniej niż 5 minut w przypadku 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
• Zwykle mniej niż 1 minuta na GB używanego miejsca
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle mniej niż 1 minuta na GB używanego miejsca
Premium lub Krytyczne dla działania firmy pojedyncza baza danych lub elastyczna pula • Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle mniej niż 1 minuta na GB używanego miejsca
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle mniej niż 1 minuta na GB używanego miejsca
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle mniej niż 1 minuta na GB używanego miejsca
• Opóźnienie proporcjonalne do przestrzeni bazy danych używanej z powodu kopiowania danych
• Zwykle mniej niż 1 minuta na GB używanego miejsca
Hiperskala NIE DOTYCZY NIE DOTYCZY NIE DOTYCZY • Stałe opóźnienie czasu niezależne od używanego miejsca
• Zwykle mniej niż 2 minuty

Uwaga

Ponadto w przypadku baz danych w standardowych (S2-S12) i Ogólnego przeznaczenia opóźnienie przenoszenia bazy danych do/z elastycznej puli lub między pulami elastycznymi będzie proporcjonalne do rozmiaru bazy danych, jeśli baza danych korzysta z magazynu z udziałami plików w chmurze Premium(PFS).

Aby określić, czy baza danych używa magazynu PFS, wykonaj następujące zapytanie w kontekście bazy danych. Jeśli wartość w kolumnie AccountType to PremiumFileStorage lub , baza danych używa magazynu PremiumFileStorage-ZRS 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 domyślnie pozostanie taka sama podczas skalowania z warstwy Krytyczne dla działania firmy do Ogólnego przeznaczenia warstwy. Opóźnienie dla tej obniżania poziomu po włączeniu nadmiarowości strefy, a także opóźnienie przełączania na nadmiarowość strefową dla warstwy Ogólnego przeznaczenia będzie proporcjonalne do rozmiaru bazy danych.

Porada

Aby monitorować operacje w toku, zobacz: Zarządzanie operacjami przy użyciu interfejsu API REST SQL,Zarządzanie operacjami przy użyciu interfejsu wiersza polecenia, Monitorowanie operacji przy użyciu języka T-SQL i następujące dwa polecenia programu PowerShell: Get-AzSqlDatabaseActivity i Stop-AzSqlDatabaseActivity.

Anulowanie zmian

Operację zmiany warstwy usługi lub operacji ponownego skalowania obliczeń można anulować.

Witryna Azure Portal

W bloku przeglądu bazy danych przejdź do powiadomienia i kliknij kafelek wskazujący, że trwa operacja:

Bieżąca operacja

Następnie kliknij przycisk z etykietą Anuluj tę operację.

Anulowanie trwającej operacji

PowerShell

W wierszu polecenia programu PowerShell ustaw $resourceGroupName , i , a następnie uruchom następujące $serverName $databaseName polecenie:

$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

Dodatkowe zagadnienia

  • W przypadku uaktualniania do wyższej warstwy usługi lub 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żywane miejsce w bazie danych musi być mniejsze niż maksymalny dozwolony rozmiar docelowej warstwy usługi i rozmiaru obliczeniowego.
  • W przypadku spadku z warstwy Premium do warstwy Standardowa obowiązuje dodatkowy koszt magazynu, jeśli zarówno (1) maksymalny rozmiar bazy danych jest obsługiwany w docelowym rozmiarze obliczeniowym, jak i (2) maksymalny rozmiar przekracza uwzględnioną ilość miejsca do magazynowania docelowego rozmiaru obliczeniowego. Jeśli na przykład baza danych P1 o maksymalnym rozmiarze 500 GB zostanie downsized do S3, będzie obowiązuje dodatkowy koszt magazynu, ponieważ magazyn S3 obsługuje maksymalny rozmiar 1 TB, a 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ć informacje o cenach dodatkowego magazynu, zobacz Azure SQL Database cennik . 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 jej 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 należy najpierw uaktualnić pomocniczą bazę 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 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ć poziom podstawowej bazy danych.
  • Oferowane usługi przywracania różnią się w zależności do warstwy usługi. W przypadku obniżania poziomu do warstwy Podstawowa istnieje niższy okres przechowywania kopii zapasowych. Zobacz Azure SQL Database Kopii zapasowych.
  • Nowe właściwości bazy danych są stosowane dopiero po zakończeniu zmian.
  • Gdy kopiowanie danych jest wymagane do skalowania bazy danych (zobacz Opóźnienie )podczas zmiany warstwy usługi, wysokie wykorzystanie zasobów współbieżne z operacją skalowania może powodować dłuższe czasy skalowania. W przyspieszone odzyskiwanie bazy danych (ADR)wycofywanie długotrwałych transakcji nie jest znaczącym źródłem opóźnień, ale wysokie współbieżne użycie zasobów może pozostawić mniej zasobów obliczeniowych, magazynu i przepustowości sieci na skalowanie, szczególnie w przypadku mniejszych rozmiarów zasobów obliczeniowych.

Rozliczenia

Opłaty są naliczane za każdą godzinę, gdy baza danych istnieje przy użyciu najwyższej warstwy usługi 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ć informacje na temat limitów maksymalnego rozmiaru magazynu danych w poszczególnych celach usługi, zobacz strony dokumentacji limitów zasobów dotyczące limitów zasobów dla pojedynczych baz danych przy użyciu modelu zakupów rdzeni wirtualnych i Limity zasobów dla pojedynczych baz danych korzystających z modelu zakupów jednostek DTU.
  • Magazyn danych dla pojedynczej bazy danych można aprowizowany przez zwiększenie lub zmniejszenie maksymalnego rozmiaru przy użyciu poleceń Azure Portal, Transact-SQL, PowerShell, interfejsuwiersza polecenia platformy Azure lub interfejsu API REST. Jeśli wartość maksymalnego rozmiaru 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 skonfigurowany maksymalny rozmiar magazynu danych. Oprócz tego magazynu program Azure SQL Database automatycznie przydziela o 30% więcej miejsca do magazynowania na dziennik transakcji.
  • Azure SQL Database automatycznie przydziela 32 GB na rdzeń wirtualnych dla bazy tempdb danych. tempdb znajduje się w lokalnym magazynie SSD we wszystkich warstwach usług.
  • Cena magazynu dla pojedynczej bazy danych lub elastycznej puli to suma ilości magazynu danych i magazynu dzienników transakcji pomnożona przez cenę jednostki magazynu warstwy usługi. Koszt jest tempdb uwzględniany w cenie. Aby uzyskać szczegółowe informacje na temat ceny magazynu, zobacz Azure SQL Database cennik.

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 przestrzenią plików w programie Azure SQL Database.

Model zakupów oparty na jednostce DTU

  • Cena jednostek DTU dla pojedynczej bazy danych obejmuje pewną ilość miejsca bez dodatkowych kosztów. Dodatkowy magazyn poza uwzględnioną kwotą można aprowizować na dodatkowy koszt aż do maksymalnego limitu rozmiaru w przyrostach od 250 GB do 1 TB, a następnie w przyrostach 256 GB powyżej 1 TB. Aby uzyskać informacje na temat uwzględnionych ilości magazynów i limitów maksymalnego rozmiaru, zobacz Pojedyncza baza danych: Rozmiary magazynu i rozmiary obliczeniowe.
  • Dodatkowy magazyn dla pojedynczej bazy danych można aprowizował, zwiększając jego maksymalny rozmiar przy użyciu języka Azure Portal, języka Transact-SQL,programu PowerShell,interfejsu wiersza polecenia platformy Azurelub interfejsu API REST.
  • Cena dodatkowego magazynu dla pojedynczej bazy danych to dodatkowa ilość miejsca do magazynowania pomnożona przez dodatkową cenę jednostki magazynu warstwy usługi. Aby uzyskać szczegółowe informacje na temat ceny dodatkowego magazynu, zobacz cennik Azure SQL Database magazynu.

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 przestrzenią plików w programie Azure SQL Database.

Baza danych z replikacją geograficzną

Aby zmienić rozmiar bazy danych replikowanej pomocniczej bazy danych, zmień rozmiar podstawowej bazy danych. Ta zmiana zostanie następnie zreplikowana i zaimplementowana w pomocniczej bazie danych.

Ograniczenia P11 i P15, gdy maksymalny rozmiar jest większy niż 1 TB

Więcej niż 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 był kiedykolwiek ustawiony na wartość większą niż 1 TB, można ją przywrócić lub skopiować tylko do bazy danych P11 lub P15. Następnie bazę danych można przeskalować do innego rozmiaru obliczeniowego, pod warunkiem, że ilość miejsca przydzielonego w czasie operacji ponownego skalowania nie przekracza limitów maksymalnego rozmiaru nowego rozmiaru obliczeniowego.
  • W przypadku scenariuszy aktywnej replikacji geograficznej:
    • Konfigurowanie relacji replikacji geograficznej: jeśli podstawowa baza danych to P11 lub P15, pomocniczą bazą danych musi być również P11 lub P15. Mniejszy rozmiar zasobów obliczeniowych jest odrzucany jako pliki drugie, ponieważ nie są one w stanie obsługiwać więcej niż 1 TB.
    • Uaktualnianie podstawowej bazy danych w relacji replikacji geograficznej: zmiana maksymalnego rozmiaru na ponad 1 TB w podstawowej bazie danych wyzwala tę samą zmianę w pomocniczej bazie danych. Oba uaktualnienia muszą zostać pomyślnie wprowadzone, aby zmiana w podstawowej wersji obowiązywała. Obowiązują ograniczenia regionu dla opcji o pojemności większej niż 1 TB. Jeśli pomocniczy region znajduje się w regionie, który nie obsługuje więcej niż 1 TB, podstawowy nie jest uaktualniany.
  • Ładowanie baz danych P11/P15 o pojemności większej niż 1 TB przy użyciu usługi Import/Export nie jest obsługiwane. Użyj SqlPackage.exe do importowania i eksportowania danych.

Następne kroki

Aby uzyskać ogólne limity zasobów, zobacz Azure SQL Database limity zasobów oparte na rdzeniu rdzeni wirtualnych — pojedyncze bazy danych i limity zasobów oparte Azure SQL Database DTU — pojedyncze bazy danych.