Warstwa usługi Hiperskala

Dotyczy:Azure SQL Database

Usługa Azure SQL Database jest oparta na architekturze aparatu bazy danych programu SQL Server dostosowanej dla środowiska chmury w celu zapewnienia wysokiej dostępności nawet w przypadku awarii infrastruktury. W modelu zakupów rdzeni wirtualnych dla usługi Azure SQL Database można wybrać trzy warstwy usług:

• Ogólnego przeznaczenia
• Krytyczne dla działania firmy
• Hiperskala

Warstwa usługi Hiperskala jest odpowiednia dla wszystkich typów obciążeń. Architektura natywna dla chmury zapewnia niezależne skalowalne zasoby obliczeniowe i magazynowe do obsługi najszerszej gamy tradycyjnych i nowoczesnych aplikacji. Zasoby obliczeniowe i magazynowe w warstwie Hiperskala znacznie przekraczają zasoby dostępne w warstwach Ogólnego przeznaczenia i Krytyczne dla działania firmy.

Aby uzyskać szczegółowe informacje na temat warstw usług Ogólnego przeznaczenia i Krytyczne dla działania firmy w modelu zakupów opartym na rdzeniach wirtualnych, zobacz Warstwy usług ogólnego przeznaczenia i Krytyczne dla działania firmy. Aby porównać model zakupów oparty na rdzeniach wirtualnych z modelem zakupów opartym na jednostkach DTU, zobacz Porównanie modeli zakupów opartych na rdzeniach wirtualnych i jednostkach DTU w usłudze Azure SQL Database.

Warstwa usługi Hiperskala jest obecnie dostępna tylko dla usługi Azure SQL Database, a nie dla usługi Azure SQL Managed Instance.

Jakie są możliwości warstwy Hiperskala

Warstwa usługi Hiperskala w usłudze Azure SQL Database zapewnia następujące dodatkowe możliwości:

• Szybkie skalowanie w górę — możesz skalować zasoby obliczeniowe w górę w górę, aby w razie potrzeby obsłużyć duże obciążenia, a następnie skalować zasoby obliczeniowe z powrotem w dół, gdy nie są potrzebne.
• Szybkie skalowanie w poziomie — można aprowizować co najmniej jedną replikę tylko do odczytu na potrzeby odciążania obciążenia odczytu i do użycia jako rezerwowe.
• Automatyczne skalowanie w górę, skalowanie w dół i rozliczenia zasobów obliczeniowych na podstawie użycia bezserwerowego.
• Zoptymalizowana cena/wydajność dla grupy baz danych w warstwie Hiperskala z różnym zapotrzebowaniem na zasoby w pulach elastycznych.
• Automatyczne skalowanie magazynu z obsługą do 128 TB bazy danych lub 100 TB rozmiaru elastycznej puli.
• Wyższa ogólna wydajność ze względu na większą przepływność dziennika transakcji i szybsze czasy zatwierdzania transakcji niezależnie od woluminów danych.
• Szybkie kopie zapasowe bazy danych (na podstawie migawek plików) niezależnie od rozmiaru bez wpływu operacji we/wy na zasoby obliczeniowe.
• Szybkie przywracanie lub kopiowanie bazy danych (na podstawie migawek plików) w minutach, a nie godzinach lub dniach.

Warstwa usługi Hiperskala usuwa wiele praktycznych limitów tradycyjnie spotykanych w bazach danych w chmurze. Jeśli większość innych baz danych jest ograniczona przez zasoby dostępne w jednym węźle, bazy danych w warstwie usługi Hiperskala nie mają takich limitów. Dzięki elastycznej architekturze magazynu magazyn rośnie w miarę potrzeb. W rzeczywistości bazy danych w warstwie Hiperskala nie są tworzone przy użyciu zdefiniowanego maksymalnego rozmiaru. Baza danych w warstwie Hiperskala rośnie zgodnie z potrzebami — a opłaty są naliczane tylko za przydzieloną pojemność magazynu. W przypadku obciążeń intensywnie korzystających z odczytu warstwa usługi Hiperskala zapewnia szybkie skalowanie w poziomie, aprowizując dodatkowe repliki zgodnie z potrzebami na potrzeby odciążania obciążeń odczytu.

Ponadto czas wymagany do utworzenia kopii zapasowych bazy danych lub skalowania w górę lub w dół nie jest już powiązany z ilością danych w bazie danych. Bazy danych w warstwie Hiperskala są tworzone praktycznie natychmiast. Bazę danych można również skalować w dziesiątkach terabajtów w górę lub w dół w ciągu kilku minut w aprowizowanej warstwie obliczeniowej lub używać bezserwerowej do automatycznego skalowania zasobów obliczeniowych. Ta funkcja pozwala uwolnić Cię od obaw dotyczących bycia w pudełku przez początkowe opcje konfiguracji.

Aby uzyskać więcej informacji na temat rozmiarów obliczeniowych dla warstwy usługi Hiperskala, zobacz Właściwości warstwy usługi.

Kto powinien rozważyć warstwę usługi Hiperskala

Warstwa usługi Hiperskala jest przeznaczona dla wszystkich klientów, którzy wymagają wyższej wydajności i dostępności, szybkiej kopii zapasowej i przywracania oraz/lub szybkiego magazynu i skalowalności obliczeniowej. Obejmuje to klientów, którzy przechodzą do chmury, aby zmodernizować swoje aplikacje, oraz klientów, którzy już korzystają z innych warstw usług w usłudze Azure SQL Database. Warstwa usługi Hiperskala obsługuje szeroką gamę obciążeń baz danych— od czystego OLTP po czystą analizę. Jest zoptymalizowany pod kątem obciążeń OLTP i hybrydowych transakcji i przetwarzania analitycznego (HTAP).

Model cen hiperskala

Uwaga

Uproszczone ceny dla hiperskala usługi Azure SQL Database zostały dodane! Zapoznaj się z nową warstwą cenową dla ogłoszenia o hiperskala usługi Azure SQL Database i aby uzyskać szczegółowe informacje o zmianach cen, zobacz Hiperskala usługi Azure SQL Database — niższe, uproszczone ceny!.

Warstwa usługi Hiperskala jest dostępna tylko w modelu rdzeni wirtualnych. Aby dostosować się do nowej architektury, model cenowy różni się nieco od warstw ogólnego przeznaczenia lub Krytyczne dla działania firmy warstw usług:

• Aprowizowania zasobów obliczeniowych:

  Cena jednostek obliczeniowych w warstwie Hiperskala jest naliczana za replikę. Użytkownicy mogą dostosować łączną liczbę replik pomocniczych o wysokiej dostępności z zakresu od 0 do 4, w zależności od wymagań dotyczących dostępności i skalowalności, i utworzyć maksymalnie 30 nazwanych replik, aby obsługiwać różne obciążenia skalowania odczytu w poziomie.

• Obliczenia bezserwerowe:

  Rozliczenia obliczeń bezserwerowych są oparte na użyciu. Aby uzyskać więcej informacji, zobacz Warstwa obliczeniowa bezserwerowa dla usługi Azure SQL Database.

• Magazyn:

  Podczas konfigurowania bazy danych w warstwie Hiperskala nie trzeba określać maksymalnego rozmiaru danych. W warstwie Hiperskala opłaty za magazyn bazy danych są oparte na rzeczywistej alokacji. Magazyn jest przydzielany automatycznie w zakresie od 10 GB do 128 TB i zwiększa się o 10 GB w razie potrzeby.

Aby uzyskać więcej informacji na temat cennika hiperskala, zobacz Cennik usługi Azure SQL Database.

Architektura funkcji rozproszonych

Hiperskala oddziela aparat przetwarzania zapytań od składników, które zapewniają długoterminowe przechowywanie i trwałość danych. Ta architektura umożliwia płynne skalowanie pojemności magazynu w zależności od potrzeb (do 128 TB) oraz możliwość szybkiego skalowania zasobów obliczeniowych.

Na poniższym diagramie przedstawiono funkcjonalną architekturę hiperskala:

Dowiedz się więcej o architekturze funkcji rozproszonych w warstwie Hiperskala.

Zalety skalowania i wydajności

Dzięki możliwości szybkiego uruchamiania dodatkowych węzłów obliczeniowych tylko do odczytu architektura hiperskala umożliwia znaczne możliwości skalowania odczytu i może również zwolnić podstawowy węzeł obliczeniowy do obsługi większej liczby żądań zapisu. Ponadto węzły obliczeniowe można szybko skalować w górę/w dół ze względu na architekturę magazynu współdzielonego architektury hiperskala. Węzły obliczeniowe tylko do odczytu w warstwie Hiperskala są również dostępne w bezserwerowej warstwie obliczeniowej, która automatycznie skaluje zasoby obliczeniowe na podstawie zapotrzebowania na obciążenia.

Wysoka dostępność bazy danych w warstwie Hiperskala

Podobnie jak we wszystkich innych warstwach usług warstwa Hiperskala gwarantuje trwałość danych dla zatwierdzonych transakcji niezależnie od dostępności repliki obliczeniowej. Zakres przestoju spowodowany tym, że replika podstawowa staje się niedostępna, zależy od typu trybu failover (planowanego i nieplanowanego), czy jest skonfigurowana nadmiarowość strefy, oraz od obecności co najmniej jednej repliki o wysokiej dostępności. W przypadku planowanego przejścia w tryb failover (na przykład zdarzenia konserwacji) system tworzy nową replikę podstawową przed zainicjowaniem trybu failover lub używa istniejącej repliki o wysokiej dostępności jako celu trybu failover. W nieplanowanym trybie failover (takim jak awaria sprzętowa repliki podstawowej) system używa repliki wysokiej dostępności jako elementu docelowego trybu failover, jeśli istnieje, lub tworzy nową replikę podstawową z puli dostępnej pojemności obliczeniowej. W tym ostatnim przypadku czas trwania przestoju jest dłuższy z powodu dodatkowych kroków wymaganych do utworzenia nowej repliki podstawowej.

Możesz wybrać okno obsługi, które pozwala na przewidywalne i mniej zakłócające działanie obciążenia.

Aby uzyskać informacje na temat umowy SLA w warstwie Hiperskala, zobacz Umowa SLA dla usługi Azure SQL Database.

Pula, odporne rozszerzenie puli i ciągłe tworzenie

W warstwie Hiperskala usługi Azure Database istnieje odrębna separacja między obliczeniami i magazynem. Magazyn zawiera wszystkie strony bazy danych w jednej bazie danych i można je przydzielić na wiele maszyn w miarę rozwoju bazy danych. Węzeł obliczeniowy buforuje jednak tylko to, co jest ostatnio używane. Najgorętsze strony w obliczeniach są przechowywane w pamięci w strukturze nazywanej pulą (BP). Jest on również przechowywany na lokalnym dysku SSD, odpornym rozszerzeniu puli (RBPEX), dzięki czemu dane mogą być pobierane szybciej w przypadku ponownego uruchomienia procesu obliczeniowego.

W systemie w chmurze obliczenia mogą przejść do różnych maszyn zgodnie z potrzebami. Warstwa obliczeniowa może mieć wiele replik. Jeden jest podstawowy i odbiera wszystkie aktualizacje, podczas gdy inne są replikami pomocniczymi. W przypadku awarii podstawowej jeden z replik pomocniczych o wysokiej dostępności można szybko awansować do podstawowej w procesie nazywanym trybem failover. Replika pomocnicza może nie mieć pamięci podręcznej w bp i RBPEX zoptymalizowanej pod kątem obciążenia podstawowego.

Ciągłe tworzenie kopii zapasowej to proces, który zbiera informacje o tym, które strony są najgorętsze we wszystkich replikach obliczeniowych. Te informacje są agregowane, a repliki pomocnicze o wysokiej dostępności używają listy najgorętszych stron odpowiadających typowemu obciążeniu klienta. To wypełnia zarówno BP, jak i RBPEX, najgorętsze strony, stale, aby nadążyć za zmianami w obciążeniu klienta.

Bez ciągłego tworzenia, zarówno BP, jak i RBPEX nie są dziedziczone przez nowe repliki wysokiej dostępności i są odtwarzane tylko podczas obciążenia użytkownika. Ciągłe zapełnianie oszczędza czas i zapobiega niespójnej wydajności, ponieważ nie ma oczekiwania, zanim pamięci podręczne zostaną ponownie w pełni nawodnione. Dzięki ciągłemu zasypowaniu nowe repliki pomocnicze o wysokiej dostępności natychmiast zaczną priming ich BP i RBPEX. Dzięki temu wydajność będzie bardziej spójna w miarę przechodzenia w tryb failover.

Ciągłe umieszczanie działa na oba sposoby: repliki pomocnicze o wysokiej dostępności będą buforowane strony używane w replice podstawowej, a podstawowa buforuje strony z obciążeniem z replik pomocniczych.

Uwaga

Ciągłe tworzenie baz danych jest obecnie dostępne w wersji zapoznawczej bezserwerowej. Aby uzyskać więcej informacji i wyrazić zgodę na ciągłe tworzenie warstwy, zobacz Blog: listopad 2024 r. Ulepszenia hiperskala.

Kopia zapasowa i przywracanie

Operacje tworzenia kopii zapasowych i przywracania baz danych w warstwie Hiperskala są oparte na migawkach plików. Dzięki temu te operacje mogą być niemal natychmiastowe. Ponieważ architektura hiperskala korzysta z warstwy magazynu na potrzeby tworzenia kopii zapasowych i przywracania, obciążenie przetwarzania i wpływ wydajności na repliki obliczeniowe są zmniejszane. Dowiedz się więcej na temat tworzenia kopii zapasowych w warstwie Hiperskala i nadmiarowości magazynu.

Odzyskiwanie po awarii dla baz danych w warstwie Hiperskala

Jeśli musisz przywrócić bazę danych w warstwie Hiperskala w usłudze Azure SQL Database do regionu innego niż aktualnie hostowany, w ramach operacji odzyskiwania po awarii lub przechodzenia do szczegółów, relokacji lub innego powodu, podstawową metodą jest wykonywanie przywracania geograficznego bazy danych. Przywracanie geograficzne jest dostępne tylko wtedy, gdy magazyn geograficznie nadmiarowy (RA-GRS) został wybrany do nadmiarowości magazynu.

Dowiedz się więcej na temat przywracania bazy danych w warstwie Hiperskala do innego regionu.

Porównanie limitów zasobów

Warstwy usług oparte na rdzeniach wirtualnych są zróżnicowane na podstawie dostępności bazy danych, typu magazynu, wydajności i maksymalnego rozmiaru magazynu. Te różnice opisano w poniższej tabeli:

ㅤ	Ogólnego przeznaczenia	Krytyczne dla działania firmy	Hiperskala
Najlepsze dla	Oferuje opcje zasobów obliczeniowych i magazynowych w zrównoważonym budżecie.	Aplikacje OLTP z wysokim współczynnikiem transakcji i małym opóźnieniem we/wy. Zapewnia wysoką odporność na awarie i szybkie przechodzenie w tryb failover przy użyciu wielu replik rezerwowych.	Najszersza różnorodność obciążeń. Automatyczne skalowanie rozmiaru magazynu do 128 TB, szybkie skalowanie w pionie i w poziomie, szybkie przywracanie bazy danych.
Rozmiar obliczeniowy	Od 2 do 128 rdzeni wirtualnych	Od 2 do 128 rdzeni wirtualnych	Od 2 do 128 rdzeni wirtualnych
Typ magazynu	Magazyn zdalny w warstwie Premium (na wystąpienie)	Superszybkie lokalny magazyn SSD (na wystąpienie)	Oddzielony magazyn z lokalną pamięcią podręczną SSD (na replikę obliczeniową)
Rozmiar magazynu	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
Liczba operacji we/wy na sekundę	320 operacji we/wy na sekundę na rdzeń wirtualny z maksymalną 16 000 operacji we/wy na sekundę	4000 operacji we/wy na sekundę na rdzeń wirtualny z maksymalną 327 680 operacjami we/wy na sekundę	327 680 operacji we/wy na sekundę z maksymalnym lokalnym dyskiem SSD Hiperskala to wielowarstwowa architektura z buforowaniem na wielu poziomach. Efektywne operacje we/wy na sekundę zależą od obciążenia.
Pamięć/rdzeń wirtualny	5,1 GB	5,1 GB	5,1 GB lub 10,2 GB
Dostępność	Jedna replika, brak skalowania odczytu w poziomie, strefowo nadmiarowa wysoka dostępność	Trzy repliki, jedna skalowana w poziomie, strefowo nadmiarowa wysoka dostępność	Wiele replik, maksymalnie cztery skalowanie odczytu w poziomie, strefowo nadmiarowa wysoka dostępność
Tworzenie kopii zapasowych	Wybór magazynu lokalnie nadmiarowego (LRS), strefowo nadmiarowego (ZRS) lub magazynu geograficznie nadmiarowego (GRS) Przechowywanie przez 1–35 dni (domyślnie siedem dni) z dostępnym okresem przechowywania długoterminowego do 10 lat	Wybór magazynu lokalnie nadmiarowego (LRS), strefowo nadmiarowego (ZRS) lub magazynu geograficznie nadmiarowego (GRS) Przechowywanie przez 1–35 dni (domyślnie siedem dni) z dostępnym okresem przechowywania długoterminowego do 10 lat	Wybór magazynu lokalnie nadmiarowego (LRS), strefowo nadmiarowego (ZRS) lub magazynu geograficznie nadmiarowego (GRS) Przechowywanie przez 1–35 dni (domyślnie siedem dni) z dostępnym okresem przechowywania długoterminowego do 10 lat
Cennik/rozliczenia	Opłaty za rdzenie wirtualne, magazyn zarezerwowany i magazyn kopii zapasowych są naliczane. Nie są naliczane opłaty za operacje we/wy na sekundę.	Opłaty za rdzenie wirtualne, magazyn zarezerwowany i magazyn kopii zapasowych są naliczane. Nie są naliczane opłaty za operacje we/wy na sekundę.	Opłaty za rdzeń wirtualny dla każdej repliki, przydzielonego magazynu danych i magazynu kopii zapasowych są naliczane. Nie są naliczane opłaty za operacje we/wy na sekundę.
Modele rabatów1	Wystąpienia zarezerwowane Korzyść użycia hybrydowego platformy Azure 2 Subskrypcje ofert enterprise i Płatność zgodnie z rzeczywistym użyciem — tworzenie i testowanie	Wystąpienia zarezerwowane Korzyść użycia hybrydowego platformy Azure 2 Subskrypcje ofert enterprise i Płatność zgodnie z rzeczywistym użyciem — tworzenie i testowanie	Wystąpienia zarezerwowane Korzyść użycia hybrydowego platformy Azure 2 Subskrypcje ofert enterprise i Płatność zgodnie z rzeczywistym użyciem — tworzenie i testowanie

¹ Uproszczony cennik hiperskala usługi SQL Database przybył w grudniu 2023 r. Aby uzyskać szczegółowe informacje, zapoznaj się z blogiem dotyczącym cennika hiperskala.

² Od grudnia 2023 r. Korzyść użycia hybrydowego platformy Azure nie jest dostępna dla nowych baz danych w warstwie Hiperskala ani w subskrypcjach tworzenia/testowania. Istniejące pojedyncze bazy danych w warstwie Hiperskala z aprowizowaną usługą obliczeniową mogą nadal korzystać z Korzyść użycia hybrydowego platformy Azure, aby zaoszczędzić na kosztach obliczeń do grudnia 2026 r. Aby uzyskać więcej informacji, zapoznaj się z blogiem dotyczącym cen hiperskala.

Zasoby obliczeniowe

Zapisz konfigurację sprzętu	Procesor CPU	Memory (Pamięć)
Seria Standardowa (Gen5)	Aprowidowane obliczenia - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, PROCESORy AMD EPYC 7763v (Milan) - Aprowizuj maksymalnie 80 rdzeni wirtualnych (hiperwątkowy) Bezserwerowe usługi obliczeniowe - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, PROCESORy AMD EPYC 7763v (Milan) - Autoskaluj do 80 rdzeni wirtualnych (hiperwątkowa) - Stosunek pamięci do rdzeni wirtualnych dynamicznie dostosowuje się do użycia pamięci i procesora CPU na podstawie zapotrzebowania na obciążenie i może wynosić nawet 24 GB na rdzeń wirtualny. Na przykład w danym momencie obciążenie może używać i być rozliczane za 240 GB pamięci i tylko 10 rdzeni wirtualnych.	Aprowidowane obliczenia - 5,1 GB na rdzeń wirtualny - Aprowizuj do 625 GB Bezserwerowe usługi obliczeniowe - Autoskaluj do 24 GB na rdzeń wirtualny - Autoskaluj maksymalnie 240 GB
Seria Premium	- Procesory Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) - Aprowizuj maksymalnie 128 rdzeni wirtualnych (hiperwątkowy)	- 5,1 GB na rdzeń wirtualny
Zoptymalizowana pod kątem pamięci serii Premium	- Procesory Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) - Aprowizuj maksymalnie 80 rdzeni wirtualnych (hiperwątkowy)	- 10,2 GB na rdzeń wirtualny

¹ W widoku zarządzania dynamicznego sys.dm_user_db_resource_governance generowanie sprzętu dla baz danych przy użyciu procesorów Intel® SP-8160 (Skylake) jest wyświetlane jako Gen6, generacja sprzętu dla baz danych korzystających z technologii Intel® 8272CL (Cascade Lake) jest wyświetlana jako Gen7, a generacja sprzętu dla baz danych korzystających z technologii Intel® Xeon® Platinum 8370C (Ice Lake) lub AMD® EPYC® 7763v (Milan) jest wyświetlana jako Gen8. W przypadku danego rozmiaru obliczeniowego i konfiguracji sprzętu limity zasobów są takie same niezależnie od typu procesora CPU. Aby uzyskać więcej informacji, zobacz Limity zasobów dla pojedynczych baz danych i pul elastycznych.

Bezserwerowe jest obsługiwane tylko na sprzęcie z serii Standardowa (Gen5).

Tworzenie baz danych w warstwie Hiperskala i zarządzanie nimi

Bazy danych hiperskala można tworzyć i zarządzać nimi przy użyciu witryny Azure Portal, języka Transact-SQL, programu PowerShell i interfejsu wiersza polecenia platformy Azure. Aby uzyskać więcej informacji, zobacz Szybki start: tworzenie bazy danych w warstwie Hiperskala.

Operacja	Szczegóły	Dowiedz się więcej
Tworzenie bazy danych w warstwie Hiperskala	Bazy danych w warstwie Hiperskala są dostępne tylko przy użyciu modelu zakupów opartego na rdzeniach wirtualnych.	Znajdź przykłady tworzenia bazy danych w warstwie Hiperskala w przewodniku Szybki start: tworzenie bazy danych w warstwie Hiperskala w usłudze Azure SQL Database.
Uaktualnianie istniejącej bazy danych do warstwy Hiperskala	Migrowanie istniejącej bazy danych w usłudze Azure SQL Database do warstwy Hiperskala jest rozmiarem operacji na danych.	Dowiedz się , jak przeprowadzić migrację istniejącej bazy danych do warstwy Hiperskala.
Odwrotna migracja bazy danych hiperskala do warstwy usługi Ogólnego przeznaczenia	Jeśli wcześniej przeprowadzono migrację istniejącej bazy danych Azure SQL Database do warstwy usługi Hiperskala, możesz cofnąć migrację bazy danych do warstwy usługi Ogólnego przeznaczenia w ciągu 45 dni od pierwotnej migracji do warstwy Hiperskala. Jeśli chcesz przeprowadzić migrację bazy danych do innej warstwy usługi, takiej jak Krytyczne dla działania firmy, najpierw przeprowadź migrację odwrotną do warstwy usługi Ogólnego przeznaczenia, a następnie zmień warstwę usługi.	Dowiedz się , jak cofnąć migrację z warstwy Hiperskala, w tym ograniczenia dotyczące migracji odwrotnej.

Zmniejsz rozmiar

Operacje zmniejszania bazy danych i plików są obecnie dostępne w wersji zapoznawczej dla hiperskala usługi Azure SQL Database. Aby uzyskać więcej informacji na temat wersji zapoznawczej, zobacz Shrink for Azure SQL Database Hyperscale (Zmniejszanie warstwy hiperskala usługi Azure SQL Database).

Znane ograniczenia

Są to bieżące ograniczenia warstwy usługi Hiperskala. Aktywnie pracujemy nad usunięciem jak największej liczby tych ograniczeń.

Problem	opis
Zmniejszanie jest blokowane, gdy funkcja TDE jest wyłączona	Obecnie operacje zmniejszania bazy danych i plików nie są obsługiwane, gdy funkcja Transparent Data Encryption (TDE) jest wyłączona w hiperskala usługi Azure SQL Database.
Przywracanie bazy danych z innych warstw usług	Nie można przywrócić bazy danych innej niż Hiperskala jako baza danych w warstwie Hiperskala, a baza danych w warstwie Hiperskala nie może zostać przywrócona jako baza danych innej niż Hiperskala. W przypadku baz danych migrowanych do warstw hiperskala z innych warstw usługi Azure SQL Database kopie zapasowe przed migracją są przechowywane przez okres przechowywania kopii zapasowych źródłowej bazy danych, w tym zasady przechowywania długoterminowego. Przywracanie kopii zapasowej przed migracją w okresie przechowywania kopii zapasowej bazy danych jest obsługiwane za pośrednictwem wiersza polecenia. Te kopie zapasowe można przywrócić do dowolnej warstwy usługi innej niż Hiperskala.
Migracja baz danych za pomocą obiektów OLTP w pamięci	Hiperskala obsługuje podzestaw obiektów OLTP w pamięci, w tym typy tabel zoptymalizowane pod kątem pamięci, zmienne tabeli i moduły skompilowane natywnie. Jednak jeśli w migrowanej bazie danych znajdują się obiekty OLTP w pamięci, migracja z warstw Premium i Krytyczne dla działania firmy do warstw usługi Hiperskala nie jest obsługiwana. Aby przeprowadzić migrację takiej bazy danych do warstwy Hiperskala, należy porzucić wszystkie obiekty OLTP w pamięci i ich zależności. Po przeprowadzeniu migracji bazy danych te obiekty można odtworzyć. Trwałe i nietrwałe tabele zoptymalizowane pod kątem pamięci nie są obecnie obsługiwane w warstwie Hiperskala i muszą zostać zmienione na tabele dysków.
Sprawdzanie integralności bazy danych	Baza danych DBCC CHECKDB nie jest obecnie obsługiwana w przypadku baz danych w warstwie Hiperskala. DBCC CHECKTABLE ('TableName') WITH TABLOCK i DBCC CHECKFILEGROUP WITH TABLOCK może służyć jako obejście. Aby uzyskać szczegółowe informacje na temat zarządzania integralnością danych w usłudze Azure SQL Database, zobacz Integralność danych w usłudze Azure SQL Database.
Zadania elastyczne	Używanie bazy danych w warstwie Hiperskala jako bazy danych zadań nie jest obsługiwane. Jednak zadania elastyczne mogą być przeznaczone dla baz danych w warstwie Hiperskala w taki sam sposób, jak każda inna baza danych w usłudze Azure SQL Database.
Synchronizacja danych	Używanie bazy danych w warstwie Hiperskala jako bazy danych centrum lub metadanych synchronizacji nie jest obsługiwane. Jednak baza danych w warstwie Hiperskala może być składową bazą danych w topologii usługi Data Sync.
Sprzęt warstwy usług w warstwie Hiperskala w warstwie Premium	Sprzęt z serii Premium i zoptymalizowany pod kątem pamięci w warstwie Premium nie obsługuje obecnie bezserwerowej warstwy obliczeniowej.
Dostępność w regionach	Sprzęt zoptymalizowany pod kątem pamięci w warstwie Hiperskala w warstwie Premium i premium jest dostępny w ograniczonych regionach świadczenia usługi Azure. Aby uzyskać listę, zobacz Dostępność w warstwie Premium w warstwie Hiperskala.

Powiązana zawartość

• Często zadawane pytania dotyczące hiperskala
• Porównanie modeli zakupów opartych na rdzeniach wirtualnych i jednostkach DTU w usłudze Azure SQL Database
• Zarządzanie zasobami w usłudze Azure SQL Database
• Limity zasobów dla pojedynczych baz danych podczas używania modelu zakupu opartego na rdzeniach wirtualnych
• Porównanie funkcji: Azure SQL Database i Azure SQL Managed Instance
• Architektura funkcji rozproszonych w warstwie Hiperskala
• Jak zarządzać bazą danych w warstwie Hiperskala