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

W tym artykule opisano sposób skalowania zasobów obliczeniowych i magazynu dostępnych dla Azure SQL Database w aprowizowanej warstwie obliczeniowej. Alternatywnie warstwa obliczeniowa bezserwerowa 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 dynamicznie skalować pojedynczą bazę danych w górę lub w dół na podstawie rzeczywistego środowiska przy użyciu:

• Transact-SQL
• Witryna Azure Portal
• Program PowerShell
• Interfejs wiersza polecenia platformy Azure
• Interfejs API REST

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 Azure SQL Database.

Wpływ

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

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, 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 nadal są 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ą ustanawiane z bazą danych w nowym wystąpieniu obliczeniowym. W przypadku niektórych kombinacji warstwy usługi i zmian 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 zostaną utracone w żadnym kroku przepływu pracy. Upewnij się, że zaimplementowano logikę ponawiania prób w aplikacjach i składnikach korzystających z 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/z elastycznej puli lub przenoszenie bazy danych między pulami elastycznymi jest sparametryzowane w następujący sposób:

Warstwa usług	Podstawowa pojedyncza baza danych,Standardowa (S0-S1)	Podstawowa elastyczna pula,Standardowa (S2-S12), Ogólnego przeznaczenia pojedynczą bazę danych lub pulę elastyczną	Pojedyncza baza danych lub elastyczna pula Premium lub Krytyczne dla działania firmy	Hiperskala
Podstawowa pojedyncza baza danych, Standardowa (S0-S1)	• Stałe opóźnienie czasu niezależnie 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
Podstawowa elastyczna pula, Standardowa (S2-S12), Ogólnego przeznaczenia pojedyncza baza danych lub elastyczna pula	• 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 opóźnienie czasu stałego niezależnie 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
Pojedyncza baza danych lub elastyczna pula Premium lub Krytyczne dla działania firmy	• 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
Hiperskala	NIE DOTYCZY	NIE DOTYCZY	NIE DOTYCZY	• Stałe opóźnienie czasu niezależnie 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 Premium udziałów plików (PFS).

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 z Krytyczne dla działania firmy do warstwy Ogólnego przeznaczenia. Opóźnienie dla tej zmiany na starszą skalę, gdy jest włączona nadmiarowość strefy, a także opóźnienie przełączania do nadmiarowości strefy dla warstwy Ogólnego przeznaczenia będzie proporcjonalna 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 tych dwóch poleceń programu PowerShell: Get-AzSqlDatabaseActivity i Stop-AzSqlDatabaseActivity.

Anulowanie zmian

Można anulować operację zmiany warstwy usługi lub skalowania zasobów obliczeniowych.

Witryna Azure Portal

W bloku Przegląd bazy danych przejdź do obszaru Powiadomienia i kliknij kafelek wskazujący, że trwa operacja:

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

PowerShell

W wierszu polecenia programu PowerShell ustaw polecenie $resourceGroupName, $serverNamei $databaseName, a następnie uruchom następujące 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 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.
• Podczas obniżania poziomu z Premium do warstwy Standardowa naliczany jest dodatkowy koszt magazynowania, jeśli maksymalny rozmiar bazy danych (1) jest obsługiwany w docelowym rozmiarze obliczeniowym, a (2) maksymalny rozmiar przekracza uwzględniony rozmiar magazynu docelowego rozmiaru obliczeniowego. Jeśli na przykład baza danych P1 o maksymalnym rozmiarze 500 GB jest wyłączona do S3, dodatkowy koszt magazynu ma zastosowanie, ponieważ 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ć informacje o cenach dodatkowego magazynu, zobacz cennik 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 wymagane jest, aby pomocnicza baza danych została najpierw uaktualniona.
• Podczas 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). Podczas obniżania poziomu do innej wersji wymagane jest, aby podstawowa baza danych została najpierw obniżona.
• Oferowane usługi przywracania różnią się w zależności do warstwy usługi. Jeśli obniżasz poziom warstwy Podstawowa , jest niższy okres przechowywania kopii zapasowych. Zobacz Azure SQL Database Kopie zapasowe.
• 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 równoczesne do operacji skalowania może spowodować dłuższy czas skalowania. 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

• Storage można aprowizować maksymalnie limit 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 dotyczące 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 Azure SQL Database automatycznie przydziela 30% więcej miejsca do użycia w dzienniku transakcji.
• 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.
• Cena magazynu dla pojedynczej bazy danych lub elastycznej puli to suma ilości magazynu danych i magazynu dziennika transakcji pomnożona przez cenę jednostkową warstwy usług. Koszt jest tempdb uwzględniony w cenie. Aby uzyskać szczegółowe informacje na temat ceny magazynu, zobacz cennik 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 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 Storage i rozmiary obliczeń).
• 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 kwota magazynu pomnożona przez dodatkową cenę jednostkową warstwy usług. Aby uzyskać szczegółowe informacje na temat ceny dodatkowego 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 miejscem na pliki w Azure SQL Database.

Replikowana geograficznie baza danych

Aby zmienić rozmiar bazy danych replikowanej 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, gdy maksymalny rozmiar przekracza 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 przywrócić ją tylko lub skopiować 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, pomocnicza(ies) musi być również P11 lub P15. Mniejszy rozmiar obliczeniowy jest odrzucany jako pomocnicze, ponieważ nie jest 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 tę 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 uaktualniony.
• Używanie usługi Import/Export do ładowania baz danych P11/P15 z więcej niż 1 TB 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 rdzeniach wirtualnych — pojedyncze bazy danych i Azure SQL Database limity zasobów opartych na jednostkach DTU — pojedyncze bazy danych.