Skalowanie zasobów pojedynczej bazy danych w usłudze Azure SQL Database
Dotyczy:
Azure SQL Database
W tym artykule opisano sposób skalowania zasobów obliczeniowych i magazynu dostępnych dla usługi Azure SQL Database w aprowizowanej warstwie obliczeniowej. Alternatywnie bezserwerowa warstwa obliczeniowa zapewnia automatyczne skalowanie obliczeń i naliczanie opłat na sekundę za wykorzystane zasoby obliczeniowe.
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 rzeczywistych doświadczeń 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 dla baz danych 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:
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 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.
Zmień trasowanie 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 baz danych może zmniejszyć wpływ związany z przerywaniem 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 pojedynczej bazy danych typu Basic. Pojedyncza baza danych w warstwie standardowej (S0-S1) |
Do standardowej bazy danych jednolitej (S2-S12), Pojedyncza baza danych ogólnego przeznaczenia, Podstawowa elastyczna baza danych w puli, Standardowa elastyczna baza danych w puli, Baza danych ogólnego przeznaczenia w puli |
Dla pojedynczej bazy danych w warstwie Premium lub bazy danych w puli, Krytyczna dla biznesu baza danych, pojedyncza lub w puli |
Hiperskalowanie pojedynczej bazy danych lub bazy danych w puli. |
|---|---|---|---|---|
|
z Podstawowej pojedynczej bazy danych, 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, Standardowa pojedyncza baza danych (S2-S12), Standardowa zunifikowana baza danych Pojedyncza baza danych do ogólnego użytku lub baza danych współużytkowana |
- 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 elastycznych pul 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 premium lub bazy danych w puli, Krytyczna baza danych dla biznesu: pojedyncza lub 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 Odwrotna migracja z Hiperskali, 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 Standard (S2-S12) oraz General Purpose, opóźnienie przy przenoszeniu bazy danych do puli elastycznej lub pomiędzy pulami elastycznymi będzie proporcjonalne do rozmiaru bazy danych, jeśli baza danych korzysta z magazynu Premium File Share (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 w kolumnie AccountType wartość to
PremiumFileStoragelubPremiumFileStorage-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ść nadmiarowości strefowej pozostanie domyślnie taka sama podczas skalowania pojedynczej bazy danych z warstwy Krytyczna dla Biznesu 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.
Napiwek
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.
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 trwającego wdrożenia.
Na wynikowej stronie Bieżące operacje wybierz pozycję Anuluj tę operację.
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 master, członkiem roli bazy danych db_owner w bieżącej bazie danych lub dbo bazy danych. Aby uzyskać więcej informacji, zobacz ALTER DATABASE.
Aby skalować bazy danych za pośrednictwem portalu Azure, PowerShell, Azure CLI lub REST API: potrzebne są uprawnienia Azure RBAC, w szczególności rola Współautora, Współautora bazy danych SQL lub Współautora SQL Server. Aby uzyskać więcej informacji, zobacz wbudowane role RBAC w 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.
- pl-PL: W przypadku obniżenia z warstwy Premium do warstwy Standard dodatkowy koszt magazynowania ma zastosowanie, jeśli (1) maksymalny rozmiar bazy danych jest obsługiwany w docelowym rozmiarze obliczeniowym, i (2) maksymalny rozmiar przekracza ilość magazynu wliczoną w docelowy rozmiar obliczeniowy. Jeśli na przykład baza danych P1 o maksymalnym rozmiarze 500 GB zostanie zmniejszona do warstwy S3, zostanie doliczony dodatkowy koszt przechowywania, ponieważ usługa S3 obsługuje maksymalny rozmiar 1 TB, a jej uwzględniona ilość miejsca do przechowywania 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 Automatyczne kopie zapasowe w usłudze 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 danychwycofywanie długotrwałych transakcji nie jest znaczącym źródłem opóźnienia, ale wysokie jednoczesne wykorzystanie zasobów może pozostawić mniej mocy obliczeniowej, zasobów magazynowych i przepustowości sieciowej na potrzeby skalowania, szczególnie w przypadku mniejszych konfiguracji 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.
Zmień rozmiar przechowywania
Model zakupów oparty na vCore.
Magazyn danych można przydzielać do maksymalnego limitu rozmiaru przy użyciu przyrostów wielkości 1 GB. Minimalny konfigurowalny magazyn danych to 1 GB. Aby uzyskać maksymalne limity rozmiaru magazynu danych w każdym celu serwisowym, zobacz strony dokumentacji limitów zasobów dla pojedynczych baz danych przy użyciu modelu zakupów vCore oraz modelu zakupów 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 maksymalna wartość rozmiaru jest określona w bajtach, musi to być wielokrotność 1 GB (1 073 741 824 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
tempdbbazy danych.tempdbznajduje się w lokalnym magazynie SSD we wszystkich warstwach usług. Koszt elementutempdbjest 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 dla baz danych 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 udostępnić, zwiększając jej rozmiar maksymalny przy użyciu portalu Azure, języka Transact-SQL, programu PowerShell, Azure CLI 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 dla baz danych 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. Później 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, bazy danych pomocnicze muszą 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 serwer pomocniczy znajduje się w regionie, który nie obsługuje więcej niż 1 TB, serwer główny 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.