warstwa usługi hiperskala

Azure SQL Database Hiperskala to ekonomiczna, wysokowydajna baza danych w chmurze.

Azure SQL Database jest oparta na Database Engine SQL. Warstwa Hiperskala różni się od innych warstw usług Azure SQL Database:

W przeciwieństwie do innych warstw usług warstwa Hiperskala nie ma opłaty za licencję na oprogramowanie SQL, co daje znaczną przewagę cenową nad innymi warstwami usług Azure SQL Database dla baz danych o wysokiej wydajności.
Architektura hiperskala jest odrębna: zapewnia niemal natychmiastowe kopie zapasowe, szybkie przywracanie i wysoką przepływność odczytu i zapisu.
Hiperskala zapewnia szybkie skalowanie obliczeń na żądanie bez przenoszenia danych.
Strategie skalowania w poziomie odczytu są łatwe, z maksymalnie 30 nazwanymi replikami z niezależnymi konfigurowalnymi obliczeniami oraz wbudowanymi replikami o wysokiej dostępności i konfigurowalnymi replikami geograficznymi na całym świecie.

Warstwa usługi Hyperscale jest odpowiednia dla wszystkich typów obciążeń. Zasoby obliczeniowe i magazynowe w warstwie Hiperskala znacznie przekraczają zasoby dostępne w warstwach ogólnego przeznaczenia Azure SQL Database i Krytyczne dla działania firmy.

Istniejącą bazę danych można łatwo przekonwertować na Azure SQL Database warstwę Hiperskala lub przeprowadzić migrację z dowolnej bazy danych SQL Server do warstwy Hiperskala. Aby przeprowadzić migrację innych baz danych do Azure SQL Database, zobacz przewodniki migracji bazy danych Azure.

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

Jakie są możliwości Hiperskali

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

Szybkie skalowanie w górę — skalowanie w górę zasobów obliczeniowych w celu obsługi dużych obciążeń w razie potrzeby, a następnie skalowanie zasobów obliczeniowych z powrotem w dół, gdy nie są potrzebne.
Szybkie skalowanie w poziomie — utwórz jedną lub więcej replik tylko do odczytu, aby odciążyć operacje odczytu i używać ich jako aktywnych serwerów rezerwowych.
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 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 trybie Hiperskala rośnie zgodnie z potrzebami — a opłaty są naliczane tylko za przydzieloną pojemność przechowywania. W przypadku obciążeń intensywnie korzystających z odczytu, warstwa usługi Hiperskala zapewnia szybkie skalowanie poziome, udostępniając dodatkowe repliki według potrzeby, aby odciążyć operacje 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 hiperskala są kopiowane zapasowo 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 uwalnia Cię od obaw związanych z ograniczeniami wynikającymi z początkowych wyborów dotyczących konfiguracji.

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

Aby uzyskać szczegółowe informacje na temat warstw usług Ogólnego Przeznaczenia i Krytycznych dla Działania Firmy w modelu zakupowym opartym na rdzeniach wirtualnych, zobacz Warstwy Usług Ogólnego Przeznaczenia i Krytycznych dla Działania Firmy. Porównanie modelu zakupów opartego na rdzeniach wirtualnych z modelem zakupów opartym na jednostkach DTU można znaleźć w temacie Compare vCore and DTU-based purchasing models of Azure SQL Database (Modele zakupów oparte na rdzeniach wirtualnych i jednostkach DTU).

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 szybkiego magazynu i skalowalności obliczeniowej. Hiperskala jest idealna dla klientów, którzy przechodzą do chmury, aby zmodernizować swoje aplikacje lub klientów, którzy już korzystają z innych warstw usług w 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

W przypadku baz danych o wysokiej wydajności hiperskala oferuje znaczącą przewagę cenową nad innymi warstwami usług Azure SQL Database. Aby uzyskać więcej informacji, zobacz Blog: Ogłoszenie dotyczące cennika Azure SQL Database Hyperscale z konferencji Ignite 2023. Aby uzyskać szczegółowe informacje o zmianach cen, zobacz Blog: Azure SQL Database Hiperskala — niższe, uproszczone ceny!

Warstwa usługi Hiperskalowa jest dostępna tylko w modelu vCore i występuje w dwóch warstwach obliczeniowych. Rozliczenia dla warstwy Hiperskala są oparte na aprowizowanej lub bezserwerowej warstwie obliczeniowej:

Aprowizowana warstwa obliczeniowa :

Koszt mocy obliczeniowej vCore odzwierciedla całkowitą moc obliczeniową, która jest stale przydzielana aplikacji. Cena jednostek obliczeniowych w warstwie Hiperskala jest naliczana za replikę.
Bezserwerowa warstwa obliczeniowa :

Rozliczenia za użycie technologii bezserwerowej są oparte na rzeczywistym wykorzystaniu. Aby uzyskać więcej informacji, zapoznaj się z warstwą obliczeniową bez serwera dla Azure SQL Database.

Nie określasz maksymalnego rozmiaru danych podczas konfigurowania bazy danych w warstwie Hiperskala. W warstwie Hyperscale płacisz za magazyn danych na podstawie faktycznie przydzielonej przestrzeni. Pamięć masowa jest automatycznie przydzielana w zakresie od 10 GB do 128 TB i zwiększa się w razie potrzeby. Więcej informacji znajdziesz w artykule W jakich krokach rośnie rozmiar mojej bazy danych?

Zalety skalowania i wydajności

Hiperskala oddziela główny aparat bazy danych od składników zapewniających długoterminowe przechowywanie i trwałość danych. Ta architektura umożliwia szybkie skalowanie zasobów obliczeniowych bez przenoszenia danych i skalowanie magazynu (do 128 TB) niezależnie od zasobów obliczeniowych. Aby uzyskać więcej informacji, w tym diagram architektury, zobacz Architektura hiperskalowa.

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 w celu obsługi większej liczby żądań.
Możesz udostępnić zasoby obliczeniowe dla węzłów pomocniczych lub użyć bezserwerowych zasobów obliczeniowych. W obu przypadkach można je szybko skalować w górę lub w dół dzięki architekturze współdzielonej pamięci masowej usługi Hyperscale.
- Pomocnicze repliki węzłów obliczeniowych o wysokiej dostępności w warstwie Hyperscale używają tej samej warstwy obliczeniowej co węzeł podstawowy, co skutkuje przełączeniami awaryjnymi o niewielkim wpływie.
Gdy korzystasz z trybu bezserwerowego, podstawowe lub pomocnicze węzły obliczeniowe są automatycznie skalowane w zależności od zapotrzebowania obciążenia.

Podstawowa baza danych Azure SQL Database Hiperskala obsługuje obciążenia odczytu i zapisu, ale można łatwo tworzyć repliki tylko do odczytu w ramach strategii aplikacji:

W zależności od wymagań dotyczących dostępności i skalowalności można dostosować całkowitą liczbę replik pomocniczych o wysokiej dostępności z zakresu od 0 do 4.
Możesz utworzyć do 30 nazwanych replik, aby obsługiwać obciążenia związane ze skalowaniem operacji odczytu.
Geograficznie rozproszone skalowanie odczytu w globalnych centrach danych platformy Azure można uzyskać za pomocą replik geograficznych.

Wysoka dostępność bazy danych w przypadku Hiperskali

Podobnie jak we wszystkich innych warstwach usług, Hiperskala gwarantuje trwałość danych dla zatwierdzonych transakcji niezależnie od dostępności replik obliczeniowych. Zakres przestoju spowodowany tym, że replika podstawowa staje się niedostępna, zależy od typu trybu failover (planowanego lub nieplanowanego), czy nadmiarowość strefy jest skonfigurowana, 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 wysokiej dostępności jako celu trybu failover. W przypadku nieplanowanego odtwarzania awaryjnego (takiego jak awaria sprzętowa repliki podstawowej), system używa repliki o wysokiej dostępności jako celu odtwarzania awaryjnego, jeśli taka istnieje, lub tworzy nową replikę podstawową z dostępnej puli zasobów obliczeniowych. 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 konserwacyjne, aby ważne prace konserwacyjne były bardziej przewidywalne i mniej zakłócające dla Twojego obciążenia roboczego.

Aby uzyskać informacje o umowie SLA w warstwie Hiperskala, zobacz SLA dla Azure SQL Database.

Pula buforów i odporne rozszerzenie puli buforów

W Azure Database Hyperscale istnieje wyraźny podział między obliczeniami a przechowywaniem. Przechowywanie zawiera wszystkie strony bazy danych w jednej bazie danych i może być przydzielone na różne maszyny w miarę rozwoju bazy danych. Węzeł obliczeniowy buforuje jednak tylko to, co jest ostatnio używane. Najważniejsze strony w obliczeniach komputerowych są przechowywane w pamięci w strukturze nazywanej pulą buforów (BP). Jest także przechowywany na lokalnym dysku SSD, w odpornym rozszerzeniu puli buforowej (RBPEX), co pozwala na szybsze pobranie danych 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. Jedna replika jest podstawowa i odbiera wszystkie aktualizacje, podczas gdy pozostałe są replikami pomocniczymi. W przypadku awarii podstawowej system promuje jedną z replik pomocniczych o wysokiej dostępności 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 głównego obciążenia.

Ciągłe zasysanie

Ciągłe tworzenie kopii zapasowej to proces, który zbiera informacje o najczęściej używanych stronach (najgorętszych) we wszystkich replikach obliczeniowych. Proces agreguje te informacje, a pomocnicze repliki o wysokiej dostępności używają listy najczęściej używanych stron, które odpowiadają typowemu obciążeniu klienta. Ten proces stale wypełnia zarówno BP, jak i RBPEX najczęściej używanymi stronami, aby nadążać za zmianami w obciążeniu roboczym klienta.

Bez ciągłego wstępnego przygotowania ani BP, ani RBPEX nie są przenoszone do nowych replik o wysokiej dostępności i są odtwarzane dopiero w trakcie obciążenia generowanego przez użytkowników. 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 podczas występowania awarii.

Ciągłe buforowanie działa na oba sposoby: repliki pomocnicze o wysokiej dostępności będą buforować strony używane w replice podstawowej, a podstawowa replika będzie buforować strony związane z obciążeniem replik pomocniczych.

Ciągłe zasyskanie jest obecnie dostępne w aprowizowanej warstwie obliczeniowej w warstwie Hiperskala.

Kopia zapasowa i przywracanie

Operacje tworzenia kopii zapasowych i przywracania baz danych w warstwie Hiperskala są oparte na migawkach plików. Takie podejście sprawia, że te operacje są niemal natychmiastowe. Ponieważ architektura hiperskala używa warstwy magazynu do tworzenia kopii zapasowych i przywracania, zmniejsza obciążenie przetwarzania i wpływ na wydajność replik obliczeniowych. Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych w hiperskali i nadmiarowość magazynowania.

Zarządzanie awariami dla baz danych w warstwie Hiperskala

Aby przywrócić bazę danych w warstwie Hiperskala w Azure SQL Database do regionu innego niż aktualnie hostowany, wykonaj przywracanie geograficzne. Ta metoda sprawdza się w przypadku operacji odzyskiwania po awarii, ćwiczeń, relokacji lub z jakiegokolwiek innego powodu. Przywracanie geograficzne jest dostępne tylko wtedy, gdy wybierzesz magazyn geograficznie nadmiarowy (RA-GRS) jako opcję nadmiarowości magazynu.

Aby uzyskać więcej informacji, zobacz Przywracanie bazy danych w warstwie Hiperskala do innego regionu.

Porównanie limitów zasobów

Warstwy usług oparte na modelu vCore różnią się dostępnością bazy danych, typem magazynowania, wydajnością i maksymalnym rozmiarem magazynowania. W poniższej tabeli opisano te różnice:

ㅤ	Ogólne przeznaczenie	Krytyczne dla działania firmy	Hiperskala
Najlepsze dla	Ekonomiczne, zrównoważone opcje zasobów obliczeniowych i pamięci masowej.	Aplikacje OLTP z wysokim współczynnikiem transakcji i małym opóźnieniem we/wy. Wysoka odporność na awarie i szybkie przełączanie awaryjne dzięki wykorzystaniu wielu aktywnych replik zapasowych w trybie gotowości.	Zalecana i domyślna warstwa usługi dla wszystkich nowych i modernizowanych obciążeń OLTP i HTAP. Najlepsze dla najszerszej gamy obciążeń, w tym tych obciążeń z wysoce skalowalnymi wymaganiami dotyczącymi magazynu i skali odczytu. Zapewnia większą odporność na awarie, umożliwiając konfigurację więcej niż jednej repliki pomocniczej o wysokiej dostępności.
Rozmiar obliczeniowy	Od 2 do 128 vCore	Od 2 do 128 vCore	Od 2 do 192 rdzeni wirtualnych³
Typ magazynu	Pamięć zdalna Premium (na instancję)	Superszybki lokalny magazyn SSD (na instancję)	Oddzielna pamięć masowa z lokalną pamięcią podręczną SSD (na replikę obliczeniową)
Rozmiar magazynu	1 GB – 4 TB	1 GB – 4 TB	10 GB – 128 TB
Maksymalne IOPS	320 IOPS na rdzeń z maksymalną liczbą 16 000 IOPS	4 000 operacji wejścia/wyjścia (IOPS) na rdzeń wirtualny przy maksymalnie 327 680 operacjach wejścia/wyjścia na sekundę	5 500 operacji we/wy na sekundę na rdzeń wirtualny i maksymalnie 544 000 lokalnych operacji we/wy na sekundę 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
Kopie zapasowe	Wybór magazynu lokalnie nadmiarowego (LRS), strefowo nadmiarowego (ZRS) lub magazynu geograficznie nadmiarowego (GRS) Przechowywanie 1–35 dni (domyślnie 7 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 1–35 dni (domyślnie 7 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 1–35 dni (domyślnie 7 dni) z dostępnym okresem przechowywania długoterminowego do 10 lat
dostępność	Jedna replika, bez replik skalowanych w poziomie do odczytu. Strefowa redundancja wysoka dostępność	Trzy repliki, jedna replika do odczytu skalowana w poziomie. Strefowa redundancja wysoka dostępność	Wiele replik — do 4 replik do odczytu skalowanych w poziomie. Strefowa redundancja wysoka dostępność
Cennik/rozliczenia	Opłaty za vCore, zarezerwowane miejsce na dane i przechowywanie kopii zapasowych są naliczane. Nie są naliczane opłaty za IOPS.	Opłaty za vCore, zarezerwowane miejsce na dane i przechowywanie kopii zapasowych są naliczane. Nie są naliczane opłaty za IOPS.	Opłaty są naliczane za rdzeń wirtualny dla każdej repliki, przydzielony magazyn danych oraz magazyn kopii zapasowych. Nie są naliczane opłaty za IOPS.
Modele rabatów¹	Rezerwacje platformy Azure Korzyść użycia hybrydowego platformy Azure² Subskrypcje ofert Enterprise i Płatność zgodnie z rzeczywistym użyciem — oferty tworzenia i testowania	Rezerwacje platformy Azure Korzyść użycia hybrydowego platformy Azure² Subskrypcje ofert Enterprise i Płatność zgodnie z rzeczywistym użyciem — oferty tworzenia i testowania	Ponieważ warstwa Hiperskala nie ma opłaty za licencję na oprogramowanie SQL¹, Korzyść użycia hybrydowego platformy Azure nie jest dostępna dla nowych baz danych w warstwie Hiperskala².
Tabele w pamięci	No	Yes	Nie

¹ Uproszczone ceny dla SQL Database Hyperscale pojawiły się w grudniu 2023 r. Zapoznaj się z blogiem o cenach hiperskalowych dla szczegółów.

² 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 i 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 hiperskalowego.

³ Obecnie opcje 160 i 192 rdzeni wirtualnych są funkcją w wersji zapoznawczej.

Zasoby obliczeniowe

W poniższej tabeli porównaliśmy zasoby obliczeniowe w różnych konfiguracjach sprzętu i warstwach obliczeniowych dla hiperskala usługi Azure SQL Database. Aby uzyskać informacje o usłudze Azure SQL Database spoza warstwy Hiperskala, zobacz Model zakupów rdzeni wirtualnych — Azure SQL Database.

Konfiguracja sprzętu	CPU	Pamięć
Seria Standardowa (Gen5)	Zarezerwowane zasoby obliczeniowe - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milan), AMD EPYC 9004 (Genua), Intel® Xeon® Platinum 8573C (Emerald Rapids) procesory - Udostępnij maksymalnie 128 wirtualnych rdzeni (hiperwątkowy) Bezserwerowe usługi obliczeniowe - Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), Intel® 8272CL (Cascade Lake) 2,5 GHz, Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC™ 7763v (Milan), AMD EPYC 9004 (Genua), Intel® Xeon® Platinum 8573C (Emerald Rapids) procesory - Autoskaluj do 80 rdzeni wirtualnych (technologia 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.	Zarezerwowane zasoby obliczeniowe - 5,1 GB na vCore - Udostępnij do 625 GB Bezserwerowe usługi obliczeniowe - Autoskalowanie do 24 GB na vCore - Automatyczne skalowanie do maksymalnie 240 GB
Seria Premium	Zarezerwowane zasoby obliczeniowe - Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan), AMD EPYC 9004 (Genua), Intel® Xeon® Platinum 8573C (Szmaragd Rapids) procesory — Udostępnij do 192 rdzeni wirtualnych (hiperwątkowych).	5,2 GB na vCore
Seria Premium zoptymalizowana pod kątem pamięci	Zarezerwowane zasoby obliczeniowe - Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan), AMD EPYC 9004 (Genua), Intel® Xeon® Platinum 8573C (Szmaragd Rapids) procesory — Udostępnij maksymalnie 80 wirtualnych rdzeni CPU (z hiperwątkowością).	10,2 GB na rdzeń wirtualny

* W przypadku danego rozmiaru obliczeniowego i konfiguracji sprzętu limity zasobów są takie same niezależnie od typu procesora CPU (Intel® Broadwell, Skylake, Ice Lake, Cascade Lake, Szmaragd szybkie lub AMD Milan, Genua). W widoku dynamicznego zarządzania sys.dm_user_db_resource_governance generowanie sprzętu dla baz danych przy użyciu:

Procesory Intel® SP-8160 (Skylake) są wyświetlane jako Gen6
Intel® 8272CL (Cascade Lake) jest wyświetlany jako Gen7
Intel® Xeon® Platinum 8370C (Ice Lake) lub AMD EPYC™ 7763v (Milan) pojawiają się jako Gen8
AMD EPYC™ 9004 (Genua) pojawia się jako Gen9 lub Intel® Xeon® Platinum 8573C (Emerald Rapids) pojawia się jako Gen10

Aby uzyskać więcej informacji, zobacz Limity zasobów dla pojedynczych baz danych i pul elastycznych.

Tworzenie baz danych w warstwie Hiperskala i zarządzanie nimi

Bazy danych w warstwie Hiperskala można tworzyć i zarządzać nimi przy użyciu portalu Azure, Transact-SQL, programu PowerShell i Azure CLI. 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 usługi Hiperskala są dostępne tylko w modelu zakupu opartym na jednostkach vCore.	Znajdź przykłady tworzenia bazy danych w warstwie Hiperskala w Quickstart: Tworzenie bazy danych w warstwie Hiperskala w Azure SQL Database.
Konwersja istniejącej bazy danych do Hiperskali	Istniejącą bazę danych można przekonwertować na warstwę Azure SQL Database Hiperskala. Czas trwania konwersji zależy od rozmiaru danych.	Aby uzyskać więcej informacji, zobacz Konwertowanie istniejącej bazy danych na Hiperskalę.
Odwrotna migracja bazy danych Hyperscale do warstwy usługi ogólnego przeznaczenia	Jeśli wcześniej przeprowadzono migrację istniejącej Azure SQL Database do warstwy 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 Hiperskali, w tym ograniczenia dla migracji odwrotnej.

Ograniczenia

Te ograniczenia dotyczą obecnie warstwy usługi Hiperskala. Zespół produktu aktywnie pracuje nad usunięciem jak największej liczby tych ograniczeń.

Kwestia	opis
Zmniejszanie jest blokowane, gdy funkcja TDE jest wyłączona	Obecnie Azure SQL Database Hiperskala nie obsługuje operacji zmniejszania bazy danych i plików, gdy Transparent Data Encryption (TDE) jest wyłączona.
Przywracanie bazy danych z innych warstw usług	Nie można przywrócić bazy danych spoza warstwy Hiperskala jako bazy danych w warstwie Hiperskala. Nie można również przywrócić bazy danych Hyperscale jako bazy danych innej niż Hyperscale. W przypadku baz danych migrowanych do warstwy Hyperscale z innych warstw usługi Azure SQL Database kopie zapasowe sprzed migracji są przechowywane przez okres przechowywania kopii zapasowych dla źródłowej bazy danych, w tym zgodnie z zasadami długoterminowego przechowywania. Możesz przywrócić kopię zapasową przed migracją w okresie przechowywania kopii zapasowych bazy danych 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 In-Memory OLTP, migracja z warstw Premium i Krytyczna dla działania firmy do warstw usługi Hiperskala nie jest możliwa. Aby zmigrować taką bazę danych do warstwy Hyperscale, należy usunąć wszystkie obiekty In-Memory OLTP i ich zależności. Po przeprowadzeniu migracji bazy danych można ponownie utworzyć te obiekty. Trwałe i nietrwałe tabele zoptymalizowane dla pamięci nie są obecnie obsługiwane w rozwiązaniu Hyperscale i muszą zostać zmienione na tabele dyskowe.
Sprawdzanie integralności bazy danych	`DBCC CHECKDB`i `DBCC CHECKFILEGROUP` obecnie nie są wspierane dla baz danych Azure SQL Database Hyperscale. Jako obejście użyj `DBCC CHECKTABLE ('TableName') WITH TABLOCK`. Aby uzyskać szczegółowe informacje na temat zarządzania integralnością danych w Azure SQL Database, zobacz Integralność danych w Azure SQL Database.
Zadania elastyczne	Używanie bazy danych typu Hiperskala jako bazy zadań nie jest możliwe. Jednak zadania elastyczne mogą być przeznaczone dla baz danych w warstwie Hiperskala w taki sam sposób, jak każda inna baza danych w Azure SQL Database.
Data Sync	Używanie bazy danych Hyperscale jako centralnej bazy danych lub bazy danych metadanych synchronizacji nie jest obsługiwane. Jednak baza danych Hiperskala może być bazą danych członkowską w topologii Data Sync.
Sprzęt serii Premium poziomu usług Hiperskala	Sprzęt z serii Premium oraz zoptymalizowany pod kątem pamięci sprzęt z serii Premium nie obsługuje obecnie bezserwerowej warstwy obliczeniowej. Usługi Serverless są obsługiwane tylko na sprzęcie z serii Standard (Gen5).
Dostępność w regionach	Sprzęt serii Premium i serii zoptymalizowanej pamięciowo w warstwie usługowej Hiperskala jest dostępny w ograniczonych regionach platformy Azure. Aby uzyskać listę, zobacz Dostępność serii Premium Hiperskala.

Opinia

Czy ta strona była pomocna?

Last updated on 2026-07-14