Azure SQL Database Hiperskala — często zadawane pytania

Baza danych w warstwie Hiperskala to baza danych w usłudze SQL Database, która jest wspierana przez technologię magazynu skalowalnego w poziomie w warstwie Hiperskala. Baza danych w warstwie Hiperskala obsługuje do 128 TB danych i zapewnia wysoką przepływność i wydajność, a także szybkie skalowanie w celu dostosowania się do wymagań dotyczących obciążenia. Łączność, przetwarzanie zapytań, funkcje aparatu bazy danych itd. działają jak każda inna baza danych w usłudze Azure SQL Database.

Warstwa usługi Hiperskala jest dostępna tylko dla pojedynczych baz danych korzystających z modelu zakupów opartego na rdzeniach wirtualnych w usłudze Azure SQL Database. Nie jest ona dostępna w modelu zakupów opartym na jednostkach DTU.

Warstwy usług oparte na rdzeniach wirtualnych są zróżnicowane na podstawie dostępności bazy danych i typu magazynu, wydajności i maksymalnego rozmiaru magazynu zgodnie z opisem w porównaniu z limitami zasobów.

Warstwa usługi Hiperskala jest dla wszystkich klientów, którzy szukają wyższej wydajności i dostępności, szybkiej kopii zapasowej i przywracania, szybkiego magazynu i skalowalności obliczeniowej. Obejmuje to klientów, którzy zaczynają się rozwijać, którzy uruchamiają duże bazy danych o znaczeniu krytycznym, ci, którzy przechodzą do chmury, aby zmodernizować swoje aplikacje i klientów, którzy już korzystają z innych warstw usług w usłudze Azure SQL Database. Korzyści warstwy Hiperskala:

• Rozmiar bazy danych, który może wzrosnąć z 10 GB do 128 TB.
• Zasoby rdzeni wirtualnych obliczeniowych z 2 rdzeni wirtualnych do 128 rdzeni wirtualnych
• Szybkie kopie zapasowe baz danych niezależnie od rozmiaru bazy danych (kopie zapasowe są oparte na migawkach magazynu).
• Szybkie przywracanie bazy danych niezależnie od rozmiaru bazy danych (przywracanie pochodzi z migawek magazynu).
• Większa przepływność dziennika niezależnie od rozmiaru bazy danych i liczby rdzeni wirtualnych.
• Odczyt skalowania w poziomie przy użyciu co najmniej jednej repliki tylko do odczytu używanej do odciążania obciążeń tylko do odczytu lub jako baz danych rezerwowych.
• Szybkie skalowanie w górę zasobów obliczeniowych w stałym czasie w celu obsługi dużych obciążeń, a następnie skalowanie w dół w stałym czasie. Operacje skalowania zajmują jednocyfrowe minuty w przypadku aprowizowania zasobów obliczeniowych i mniej niż sekundę w przypadku obliczeń bezserwerowych, niezależnie od rozmiaru bazy danych.
• Opcja płacenia za zasoby obliczeniowe bezserwerowe, w przypadku których obliczanie jest rozliczane na podstawie użycia.

Warstwa usługi Hiperskala jest dostępna we wszystkich regionach, w których jest dostępna usługa Azure SQL Database.

Tak. Aby uzyskać więcej informacji i limitów liczby baz danych na serwer, zobacz Limity zasobów usługi SQL Database dla pojedynczych baz danych i baz danych w puli na serwerze.

Architektura hiperskala zapewnia wysoką wydajność i przepływność przy jednoczesnym obsłudze dużych rozmiarów baz danych.

Hiperskala zapewnia szybką skalowalność na podstawie zapotrzebowania na obciążenie.

• Skalowanie w górę/w dół

  W warstwie Hiperskala można skalować w górę podstawowy rozmiar obliczeniowy pod względem zasobów, takich jak procesor CPU i pamięć, a następnie skalować w dół w stałym czasie. Ponieważ magazyn jest zdalny, skalowanie w górę i skalowanie w dół nie jest rozmiarem operacji danych.

  Obsługa bezserwerowych obliczeń zapewnia automatyczne skalowanie w górę i w dół, a obliczenia są rozliczane na podstawie użycia.

• Skalowanie w/wy

  W warstwie Hiperskala można użyć trzech rodzajów replik pomocniczych, aby zaspokoić wymagania dotyczące skalowania w poziomie, wysokiej dostępności i replikacji geograficznej. Obejmuje to:

  • Maksymalnie cztery repliki o wysokiej dostępności mają taki sam rozmiar obliczeniowy jak podstawowy. Służą one jako repliki rezerwowe do szybkiego przełączania w tryb failover z serwera podstawowego. Można ich również użyć do odciążania obciążeń odczytu z podstawowego.
  • Do 30 nazwanych replik o takim samym lub innym rozmiarze obliczeniowym niż podstawowy, aby zaspokoić różne scenariusze skalowania odczytu.
  • Replika geograficzna w innym regionie świadczenia usługi Azure w celu ochrony przed awariami regionalnymi i włączenia geograficznego skalowania odczytu w poziomie.

Tak, możesz.

Nie, model programowania aplikacji pozostaje taki sam jak w przypadku każdej innej bazy danych MSSQL. Używasz parametry połączenia jak zwykle i innych regularnych sposobów interakcji z bazą danych w warstwie Hiperskala. Gdy aplikacja korzysta z bazy danych Hiperskala, aplikacja może korzystać z funkcji, takich jak repliki pomocnicze.

W repliki podstawowej domyślny poziom izolacji transakcji to RCSI (odczyt zatwierdzonej izolacji migawki). W replikach pomocniczych skalowalnego w poziomie do odczytu domyślny poziom izolacji to Migawka. Jest to takie samo, jak w każdej innej bazie danych Azure SQL Database.

W przypadku nowych, uproszczonych cen od 15 grudnia 2023 r. cena obliczeń została obniżona dla nowo utworzonych baz danych hiperskala, wszystkich bezserwerowych baz danych hiperskala i wszystkich elastycznych pul w warstwie Hiperskala. W przypadku nowych, uproszczonych cen nie ma potrzeby stosowania Korzyść użycia hybrydowego platformy Azure (AHB) w celu uzyskania równoważnych oszczędności. Korzyść użycia hybrydowego platformy Azure (AHB) można stosować tylko do starszych (utworzonych przed 15 grudnia 2023 r.) pojedynczych baz danych w warstwie Hiperskala z aprowizowaną bazą danych. W przypadku starszych baz danych usługa AHB ma zastosowanie tylko do grudnia 2026 r., po czym te bazy danych będą również rozliczane zgodnie z nowymi, uproszczonymi cenami. Aby uzyskać więcej informacji, zobacz blog dotyczący cennika hiperskala i hiperskala usługi Azure SQL Database — niższe, uproszczone ceny!.

Hiperskala działa dobrze dla wszystkich typów obciążeń, w tym OLTP, hybrydowych (HTAP) i analitycznych (składnic danych).

Jeśli obecnie uruchamiasz interakcyjne zapytania analityczne przy użyciu programu SQL Server jako magazynu danych, hiperskala jest doskonałym rozwiązaniem, ponieważ można hostować małe i średnie magazyny danych (takie jak kilka TB do 128 TB) przy niższych kosztach, a obciążenia magazynu danych programu SQL Server można migrować do warstwy Hiperskala przy minimalnych zmianach kodu T-SQL.

Jeśli uruchamiasz analizę danych na dużą skalę ze złożonymi zapytaniami i trwałymi współczynnikami pozyskiwania wyższym niż 100 MB/s lub korzystasz z równoległego magazynu danych (PDW), Teradata lub innych magazynów danych masowego przetwarzania równoległego (MPP), takich jak usługa Azure Synapse Analytics, usługa Microsoft Fabric może być najlepszym wyborem.

Szybkość pozyskiwania lub generowania dzienników wynosząca 150 MB/s jest dostępna jako funkcja w wersji zapoznawczej. Aby uzyskać więcej informacji i wyrazić zgodę na 150 MB/s, zobacz Blog: listopad 2024 r. Ulepszenia hiperskala.

Obecnie nie jest to możliwe. Można jednak skalować zasoby obliczeniowe i liczbę replik w dół, aby zmniejszyć koszty w czasie nieokreślonym lub używać bezserwerowych do automatycznego skalowania zasobów obliczeniowych na podstawie użycia.

W przypadku obciążeń odczytu można utworzyć nazwaną replikę o większym rozmiarze obliczeniowym (więcej rdzeni i pamięci) niż podstawowa. Aby uzyskać więcej informacji na temat dostępnych rozmiarów obliczeniowych, zobacz Magazyn w warstwie Hiperskala i rozmiary obliczeń.

W przypadku obciążeń odczytu można to osiągnąć przy użyciu nazwanych replik.

Liczbę replik pomocniczych wysokiej dostępności można skalować z zakresu od 0 do 4 przy użyciu witryny Azure Portal lub interfejsu API REST. Ponadto można utworzyć maksymalnie 30 nazwanych replik dla wielu scenariuszy skalowania odczytu w poziomie.

W bazach danych w warstwie Hiperskala odporność danych jest zapewniana na poziomie magazynu. Aby zapewnić odporność, potrzebna jest tylko jedna replika (podstawowa). Gdy replika obliczeniowa nie działa, nowa replika jest tworzona automatycznie bez utraty danych.

Jeśli jednak istnieje tylko replika podstawowa, utworzenie nowej repliki po przejściu w tryb failover może potrwać minutę lub dwie sekundy w przypadku dostępności repliki pomocniczej wysokiej dostępności. Nowa replika będzie początkowo mieć zimne pamięci podręczne, co może spowodować większe opóźnienie magazynu i zmniejszenie wydajności zapytań natychmiast po przejściu w tryb failover.

W przypadku aplikacji o krytycznym znaczeniu, które wymagają wysokiej dostępności z minimalnym wpływem na tryb failover, należy aprowizować co najmniej jedną replikę pomocniczą wysokiej dostępności, aby upewnić się, że replika rezerwowa gorąca jest dostępna do obsługi jako cel trybu failover.

Maksymalny rozmiar pojedynczej bazy danych w warstwie Hiperskala wynosi obecnie 128 TB. Maksymalny rozmiar bazy danych w elastycznej puli hiperskala wynosi obecnie 100 TB.

W hiperskali dziennik transakcji jest praktycznie nieskończony, z ograniczeniem, że aktywna część dziennika nie może przekraczać 1 TB. Aktywna część dziennika może rosnąć z powodu długotrwałych transakcji lub z powodu przetwarzania przechwytywania zmian danych , które nie nadąża za zmianami danych. Unikaj niepotrzebnie długich i dużych transakcji, aby pozostać poniżej tego limitu. Poza tym ograniczeniem nie musisz martwić się o brak miejsca w dzienniku w systemie, który ma wysoką przepływność dziennika. Jednak szybkość generowania dzienników może być ograniczona w przypadku obciążeń ciągłego agresywnego zapisywania. Szczytowy trwały współczynnik generowania dziennika wynosi 100 MB/s.

Szybkość generowania dzienników wynosząca 150 MB/s jest dostępna jako funkcja w wersji zapoznawczej. Aby uzyskać więcej informacji i wyrazić zgodę na 150 MB/s, zobacz Blog: listopad 2024 r. Ulepszenia hiperskala.

Baza tempdb danych znajduje się w lokalnym magazynie SSD i ma proporcjonalny rozmiar do rozmiaru obliczeniowego (liczby rdzeni), który aprowizujesz. tempdb Rozmiar elementu nie jest konfigurowalny i jest zarządzany za Ciebie. Aby określić maksymalny tempdb rozmiar bazy danych, zobacz Magazyn w warstwie Hiperskala i rozmiary obliczeniowe.

Rozmiar bazy danych automatycznie rośnie w miarę wstawiania/pozyskiwania większej ilości danych.

10 GB. Baza danych w warstwie Hiperskala jest tworzona z rozmiarem początkowym o rozmiarze 10 GB i rośnie zgodnie z potrzebami we fragmentach o rozmiarze 10 GB.

Każdy plik danych rośnie o 10 GB. Wiele plików danych może rosnąć w tym samym czasie.

W warstwie Hiperskala pliki danych są przechowywane w magazynie w warstwie Standardowa platformy Azure. Dane są w pełni buforowane w lokalnym magazynie SSD na serwerach stronicowych, które są zdalne do replik obliczeniowych. Ponadto repliki obliczeniowe mają pamięci podręczne danych na lokalnym dysku SSD i w pamięci, aby zmniejszyć częstotliwość pobierania danych z zdalnych serwerów stron.

L.p. Pliki danych są dodawane automatycznie do PRIMARY grupy plików. Typowe przyczyny tworzenia dodatkowych grup plików nie mają zastosowania w architekturze magazynu w warstwie Hiperskala ani w usłudze Azure SQL Database w szerszym zakresie.

L.p.

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

Tak, podobnie jak w przypadku każdej innej bazy danych Azure SQL DB. Obejmuje to kompresję wiersza, strony i magazynu kolumn.

Tak. Strony danych skojarzone z daną tabelą mogą znajdować się w wielu plikach danych, które są częścią tej samej grupy plików. Aparat bazy danych MSSQL używa strategii wypełniania proporcjonalnego do dystrybuowania danych za pośrednictwem plików danych.

Tak. Istniejące bazy danych można przenieść w usłudze Azure SQL Database do warstwy Hiperskala. W przypadku weryfikacji koncepcji zalecamy utworzenie kopii bazy danych i przeprowadzenie migracji kopii do warstwy Hiperskala.

Czas wymagany do przeniesienia istniejącej bazy danych do warstwy Hiperskala składa się z czasu kopiowania danych oraz czasu ponownego odtworzenia zmian w źródłowej bazie danych podczas kopiowania danych. Czas kopiowania danych jest proporcjonalny do rozmiaru danych. Czas ponownego odtwarzania zmian jest krótszy, jeśli przenoszenie odbywa się w okresie małej aktywności zapisu.

Pobierz przykładowy kod umożliwiający migrację istniejących baz danych Azure SQL Database do warstwy Hiperskala w witrynie Azure Portal, interfejsie wiersza polecenia platformy Azure, programie PowerShell i języku Transact-SQL w temacie Migrowanie istniejącej bazy danych do warstwy Hiperskala.

Odwrotna migracja do warstwy usługi Ogólnego przeznaczenia umożliwia klientom, którzy niedawno zmigrowali istniejącą bazę danych w usłudze Azure SQL Database do warstwy usługi Hiperskala, aby powrócić, jeśli hiperskala nie spełnia swoich potrzeb. Podczas gdy migracja odwrotna jest inicjowana przez zmianę warstwy usługi, zasadniczo jest to operacja o rozmiarze danych między różnymi architekturami. Podobnie jak w przypadku migracji do warstwy Hiperskala, migracja odwrotna jest szybsza w przypadku przeprowadzania w okresie niskiej aktywności zapisu. Zapoznaj się z ograniczeniami migracji wstecznej.

Jeśli wcześniej przeprowadzono migrację istniejącej bazy danych Azure SQL Database do warstwy usługi Hiperskala, możesz cofnąć migrację 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 zmodyfikuj warstwę usługi. Migracja odwrotna to rozmiar operacji danych.

Nie można przenieść baz danych utworzonych w warstwie usługi Hiperskala do innych warstw usług.

Dowiedz się, jak cofnąć migrację z warstwy Hiperskala, w tym ograniczenia dotyczące migracji odwrotnej i zasad kopii zapasowych, których dotyczy ten wpływ.

Tak. Niektóre funkcje usługi Azure SQL Database nie są jeszcze obsługiwane w warstwie Hiperskala. Jeśli niektóre z tych funkcji są włączone dla bazy danych, migracja do warstwy Hiperskala może zostać zablokowana lub te funkcje przestaną działać po migracji. Oczekujemy, że te ograniczenia będą tymczasowe. Aby uzyskać szczegółowe informacje, zobacz Znane ograniczenia.

Tak. Za pomocą wielu istniejących technologii migracji można przeprowadzić migrację do warstwy Hiperskala, w tym replikację transakcyjną i inne technologie przenoszenia danych (Kopiowanie zbiorcze, Azure Data Factory, Azure Databricks, SSIS). Zobacz również usługę Azure Database Migration Service, która obsługuje wiele scenariuszy migracji.

Przestój migracji do warstwy Hiperskala jest taki sam jak przestój podczas migrowania baz danych do innych warstw usługi Azure SQL Database. Replikacja transakcyjna umożliwia zminimalizowanie migracji przestojów dla baz danych o rozmiarze do kilku TB. W przypadku bardzo dużych baz danych (10+ TB) można rozważyć zaimplementowanie procesu migracji przy użyciu usług ADF, Spark lub innych technologii przenoszenia danych zbiorczych.

Hiperskala może zużywać 100 MB/s nowych/zmienionych danych, ale czas potrzebny do przeniesienia danych do baz danych w usłudze Azure SQL Database ma również wpływ na dostępną przepływność sieci, szybkość odczytu źródła i docelowy cel poziomu usługi bazy danych. Szybkość generowania dzienników wynosząca 150 MB/s jest dostępna jako funkcja w wersji zapoznawczej. Aby uzyskać więcej informacji i wyrazić zgodę na 150 MB/s, zobacz Blog: listopad 2024 r. Ulepszenia hiperskala.

Możesz mieć aplikację kliencką do odczytu danych z usługi Azure Storage i załadować dane do bazy danych w warstwie Hiperskala (podobnie jak w przypadku dowolnej innej bazy danych w usłudze Azure SQL Database). Technologia Polybase nie jest obecnie obsługiwana w usłudze Azure SQL Database. Alternatywą dla zapewnienia szybkiego ładowania jest użycie usługi Azure Data Factory lub użycie zadania Spark w usłudze Azure Databricks z łącznikiem Spark dla języka SQL. Łącznik Spark do języka SQL obsługuje wstawianie zbiorcze.

Istnieje również możliwość zbiorczego odczytu danych z magazynu obiektów blob platformy Azure przy użyciu funkcji BULK INSERT lub OPENROWSET: Przykłady zbiorczego dostępu do danych w usłudze Azure Blob Storage.

Prosty model odzyskiwania lub rejestrowania zbiorczego nie jest obsługiwany w warstwie Hiperskala. Pełny model odzyskiwania jest wymagany do zapewnienia wysokiej dostępności i odzyskiwania do punktu w czasie. Jednak architektura dziennika hiperskala zapewnia lepszą szybkość pozyskiwania danych w porównaniu z innymi warstwami usługi Azure SQL Database.

L.p. Hiperskala to architektura symetrycznego przetwarzania wielodyskładnikowego (SMP, symmetric multi-processing) i nie jest wysoce równoległym przetwarzaniem (MPP) ani architekturą wielowzorcową. Można tworzyć tylko wiele replik w celu skalowania obciążeń tylko do odczytu w poziomie.

Tak. Usługa Azure Database Migration Service obsługuje wiele scenariuszy migracji.

Zobacz Umowa SLA dla usługi Azure SQL Database. Zalecamy dodanie replik pomocniczych wysokiej dostępności dla obciążeń krytycznych. Zapewnia to szybsze przejście w tryb failover i zmniejsza potencjalny wpływ na wydajność natychmiast po przejściu w tryb failover.

Tak.

Tak, hiperskala obsługuje konfigurację strefowo nadmiarową. Do włączenia konfiguracji strefowo nadmiarowej dla warstwy Hiperskala wymagana jest co najmniej jedna replika pomocnicza wysokiej dostępności i użycie magazynu strefowo nadmiarowego lub magazynu strefowo nadmiarowego.

Tak. Aby uzyskać więcej informacji, zobacz Elastyczne pule hiperskala i blog: Elastyczne pule hiperskala są teraz ogólnie dostępne.

Dla baz danych w warstwie Hiperskala nie są używane tradycyjne pełne i różnicowe kopie zapasowe oraz kopie zapasowe dziennika transakcji. Zamiast tego istnieją regularne migawki magazynu plików danych z oddzielnym cyklem migawek dla każdego pliku. Wygenerowany dziennik transakcji jest zachowywany zgodnie ze skonfigurowanym okresem przechowywania. W czasie przywracania odpowiednie rekordy dziennika transakcji są stosowane do przywróconych migawek magazynu. Niezależnie od rytmu migawek powoduje to transakcyjnie spójną bazę danych bez utraty danych zgodnie z określonym punktem w czasie w okresie przechowywania. W efekcie kopia zapasowa bazy danych w warstwie Hiperskala jest ciągła.

Tak.

Cel punktu odzyskiwania dla przywracania do punktu w czasie wynosi 0 minut. Większość operacji przywracania do punktu w czasie kończy się w ciągu 60 minut niezależnie od rozmiaru bazy danych. Czas przywracania może być dłuższy dla większych baz danych, a jeśli w bazie danych wystąpiła znaczna aktywność zapisu przed i do punktu przywracania w czasie. Zmiana nadmiarowości magazynu podczas wydawania przywracania może spowodować wydłużenie czasu przywracania, ponieważ przywracanie ma rozmiar danych, a tym samym czas będzie proporcjonalny do rozmiaru bazy danych.

L.p. Kopie zapasowe są zarządzane przez podsystem magazynu i używają migawek magazynu. Nie wpływają one na obciążenia użytkowników.

Tak. Przywracanie geograficzne jest w pełni obsługiwane, jeśli jest używany magazyn geograficznie nadmiarowy. Jest to ustawienie domyślne dla nowych baz danych. W przeciwieństwie do przywracania do punktu w czasie przywracanie geograficzne wymaga operacji rozmiaru danych. Pliki danych są kopiowane równolegle, więc czas trwania tej operacji zależy przede wszystkim od rozmiaru największego pliku w bazie danych, a nie całkowitego rozmiaru bazy danych. Czas przywracania geograficznego będzie znacznie krótszy, jeśli baza danych zostanie przywrócona w regionie świadczenia usługi Azure sparowanym z regionem źródłowej bazy danych.

Tak. Replikację geograficzną można skonfigurować dla baz danych w warstwie Hiperskala.

L.p. Format magazynu dla baz danych w warstwie Hiperskala różni się od dowolnej wydanej wersji programu SQL Server i nie kontrolujesz kopii zapasowych ani nie masz do nich dostępu. Aby pobrać dane z bazy danych w warstwie Hiperskala, możesz wyodrębnić dane przy użyciu dowolnych technologii przenoszenia danych, czyli usługi Azure Data Factory, Azure Databricks, SSIS itp.

Tak. Od 4 maja 2022 r. opłaty za kopie zapasowe dla wszystkich nowych baz danych są naliczane na podstawie używanego magazynu kopii zapasowych i wybranej nadmiarowości magazynu według stawek przechwyconych na stronie cennika usługi Azure SQL Database. W przypadku baz danych w warstwie Hiperskala utworzonych przed 4 maja 2022 r. opłaty za kopie zapasowe będą naliczane tylko wtedy, gdy przechowywanie kopii zapasowych będzie większe niż siedem dni. Aby dowiedzieć się więcej, zobacz Hiperskala backups and storage redundancy (Tworzenie kopii zapasowych w warstwie Hiperskala i nadmiarowość magazynu).

Szczegółowe informacje na temat mierzenia rozmiaru magazynu kopii zapasowych są przechwytywane w automatycznych kopiach zapasowych.

Aby określić rachunek za magazyn kopii zapasowych, rozmiar magazynu kopii zapasowych jest obliczany okresowo i mnożony przez szybkość magazynowania kopii zapasowych oraz liczbę godzin od czasu ostatniego obliczenia. Aby oszacować rachunek za kopię zapasową dla okresu, pomnóż rozliczany rozmiar magazynu kopii zapasowych przez każdą godzinę według współczynnika magazynowania kopii zapasowych i sumuj wszystkie kwoty godzinowe. Aby programowo wykonywać zapytania dotyczące odpowiednich metryk usługi Azure Monitor dla wielu interwałów godzinowych, użyj interfejsu API REST usługi Azure Monitor. Rozliczenia kopii zapasowych w warstwie obliczeniowej bezserwerowej są takie same jak w aprowizowanej warstwie obliczeniowej.

Koszty tworzenia kopii zapasowych będą wyższe w przypadku obciążeń, które dodają, modyfikują lub usuwają duże ilości danych w bazie danych. Z drugiej strony obciążenia, które są głównie tylko do odczytu, mogą mieć mniejsze koszty tworzenia kopii zapasowych.

Szczegółowe informacje na temat minimalizowania kosztów magazynu kopii zapasowych są przechwytywane w automatycznych kopiach zapasowych.

Obecnie nie można przywrócić geograficznie kopii zapasowych warstw usług innych niż Hiperskala (Standardowa/Premium/Ogólnego przeznaczenia/Krytyczne dla działania firmy) do warstwy usługi Hiperskala i odwrotnie. Aby przekonwertować bazę danych inną niż Hiperskala na bazę danych w warstwie Hiperskala, zmień warstwę usługi po przywróceniu.

Limit przepływności dziennika transakcji jest ustawiony na 100 MB/s dla dowolnego rozmiaru obliczeniowego warstwy Hiperskala. Możliwość osiągnięcia tej szybkości zależy od wielu czynników, w tym między innymi typów obciążeń, konfiguracji klienta i wydajności oraz wystarczającej pojemności obliczeniowej w podstawowej repliki obliczeniowej do tworzenia rekordów dzienników w tym tempie. Szybkość generowania dzienników wynosząca 150 MB/s jest dostępna jako funkcja w wersji zapoznawczej. Aby uzyskać więcej informacji i wyrazić zgodę na 150 MB/s, zobacz Blog: listopad 2024 r. Ulepszenia hiperskala.

Opóźnienie operacji we/wy na sekundę i operacji we/wy będzie się różnić w zależności od wzorców obciążeń. Jeśli dostęp do danych jest buforowany w replice obliczeniowej RBPEX, podobna wydajność operacji we/wy będzie widoczna w warstwach usług Krytyczne dla działania firmy lub Premium.

L.p. Obliczenia są oddzielone od warstwy magazynu. Eliminuje to wpływ tworzenia kopii zapasowej na wydajność.

Ponieważ magazyn jest współużytkowany i nie ma bezpośredniej replikacji fizycznej między replikami podstawowymi i pomocniczymi obliczeniowymi, przepływność repliki podstawowej nie będzie miała bezpośredniego wpływu na dodanie replik pomocniczych. Jednak obciążenia ciągłego i agresywnego zapisu mogą być ograniczane na poziomie podstawowym, aby umożliwić stosowanie dziennika na replikach pomocniczych i serwerach stron w celu nadrobienia zaległości. Pozwala to uniknąć niskiej wydajności odczytu replik pomocniczych i długiego odzyskiwania po przejściu w tryb failover do repliki pomocniczej wysokiej dostępności.

Tak. Jednak podobnie jak w przypadku innych baz danych usługi Azure SQL DB połączenia mogą być przerywane przez bardzo rzadkie błędy przejściowe, które mogą przerwać długotrwałe zapytania i wycofać transakcje. Jedną z przyczyn błędów przejściowych jest to, że system szybko przenosi bazę danych do innego węzła obliczeniowego, aby zapewnić ciągłą dostępność zasobów obliczeniowych i magazynu lub przeprowadzić planowaną konserwację. Większość z tych zdarzeń rekonfiguracji kończy się w mniej niż 10 sekundach. Aplikacje łączące się z bazą danych powinny być tworzone, aby oczekiwać i tolerować te rzadko występujące błędy przejściowe przez zaimplementowanie logiki ponawiania prób. Ponadto rozważ skonfigurowanie okna obsługi zgodnego z harmonogramem obciążenia, aby uniknąć przejściowych błędów spowodowanych planowaną konserwacją.

W przypadku większości problemów z wydajnością, szczególnie tych, które nie zostały zakorzenione w wydajności magazynu, mają zastosowanie typowe kroki diagnostyczne SQL i rozwiązywania problemów. Aby uzyskać informacje na temat diagnostyki magazynu specyficznego dla warstwy Hiperskala, zobacz Diagnostyka rozwiązywania problemów z wydajnością hiperskala SQL.

Maksymalna ilość pamięci, którą baza danych bezserwerowa może skalować w górę, wynosi 3 GB/rdzeń wirtualny, a maksymalna liczba rdzeni wirtualnych skonfigurowanych w porównaniu do ponad 5 GB/rdzeni wirtualnych w aprowizowanej liczbie rdzeni wirtualnych. Aby uzyskać szczegółowe informacje, przejrzyj bezserwerowe limity zasobów w warstwie Hiperskala.

Skalowanie w górę lub w dół w aprowizowanej warstwie obliczeniowej zwykle trwa do 2 minut, niezależnie od rozmiaru danych. W bezserwerowej warstwie obliczeniowej, w której zasoby obliczeniowe są automatycznie skalowane na podstawie zapotrzebowania na obciążenie, czas skalowania jest zwykle podrzędny, ale czasami może trwać tak długo, jak podczas skalowania aprowizowanego środowiska obliczeniowego.

L.p. Baza danych pozostaje w trybie online podczas operacji skalowania w górę lub w dół.

Skalowanie aprowizowanego obliczeniowego w górę lub w dół powoduje porzucenie połączeń po przejściu w tryb failover na końcu operacji skalowania. W przypadku obliczeń bezserwerowych automatyczne skalowanie zwykle nie powoduje porzucania połączenia, ale może wystąpić sporadycznie. Dodawanie lub usuwanie replik pomocniczych nie powoduje spadku połączenia na serwerze podstawowym.

Skalowanie w aprowizowanych obliczeniach jest wykonywane przez użytkownika końcowego. Automatyczne skalowanie w obliczeniach bezserwerowych jest wykonywane przez usługę.

Tak. Rozmiar tempdb bazy danych i pamięci podręcznej RBPEX w węzłach obliczeniowych jest automatycznie skalowany w górę w miarę zwiększania liczby rdzeni. Aby uzyskać szczegółowe informacje, zobacz Rozmiary magazynu i obliczeń w warstwie Hiperskala.

L.p. Tylko podstawowa replika obliczeniowa akceptuje żądania odczytu/zapisu. Pomocnicze repliki obliczeniowe akceptują tylko żądania tylko do odczytu.

Hiperskala obsługuje repliki wysokiej dostępności, nazwane repliki i repliki geograficzne. Aby uzyskać szczegółowe informacje, zobacz Repliki pomocnicze w warstwie Hiperskala.

Od 0 do 4. Jeśli chcesz dostosować liczbę replik, możesz to zrobić przy użyciu witryny Azure Portal lub interfejsu API REST.

Możesz nawiązać połączenie z tymi dodatkowymi replikami obliczeniowymi tylko do odczytu, ustawiając ApplicationIntent właściwość w parametry połączenia na ReadOnlywartość . Wszystkie połączenia oznaczone za pomocą ReadOnly są automatycznie kierowane do jednej z replik pomocniczych wysokiej dostępności, jeśli istnieją. Aby uzyskać szczegółowe informacje, zobacz Używanie replik tylko do odczytu w celu odciążania obciążeń zapytań tylko do odczytu.

Możesz wykonać następujące zapytanie T-SQL: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Wynikiem jest READ_ONLY połączenie z repliką pomocniczą tylko do odczytu i READ_WRITE połączeniem z repliką podstawową. Kontekst bazy danych musi być ustawiony na nazwę bazy danych, a nie na master bazę danych.

L.p. Można łączyć się tylko z replikami pomocniczymi wysokiej dostępności, określając wartość ApplicationIntent=ReadOnly. Można jednak użyć dedykowanych punktów końcowych dla nazwanych replik.

L.p. Nowe połączenie z intencją tylko do odczytu jest przekierowywane do dowolnej pomocniczej repliki wysokiej dostępności.

Nie w aprowizowanej warstwie obliczeniowej. Repliki pomocnicze wysokiej dostępności są używane jako obiekty docelowe trybu failover o wysokiej dostępności, dlatego muszą mieć taką samą konfigurację jak podstawowa, aby zapewnić oczekiwaną wydajność po przejściu w tryb failover. W przypadku bezserwerowych obliczenia są skalowane automatycznie dla każdej repliki wysokiej dostępności na podstawie indywidualnego zapotrzebowania na obciążenie. Każda pomocnicza wysoka dostępność może nadal automatycznie skalować do skonfigurowanych maksymalnych rdzeni, aby uwzględnić rolę po przejściu w tryb failover. Nazwane repliki umożliwiają niezależne skalowanie każdej repliki.

L.p. Baza tempdb danych jest skonfigurowana na podstawie aprowizowanego rozmiaru obliczeniowego. Repliki pomocnicze wysokiej dostępności mają ten sam rozmiar, w tym tempdb, co podstawowe zasoby obliczeniowe. W nazwanych replikach tempdbrozmiar jest zgodny z rozmiarem obliczeniowym repliki, dlatego może być mniejszy lub większy niż tempdb w przypadku repliki podstawowej.

L.p. Repliki obliczeniowe bazy danych w warstwie Hiperskala współdzielą magazyn, co oznacza, że wszystkie repliki obliczeniowe widzą te same tabele, indeksy i inne obiekty bazy danych. Jeśli chcesz, aby dodatkowe indeksy zoptymalizowane pod kątem operacji odczytu w celach pomocniczych, należy dodać je do podstawowego. Nadal można tworzyć tabele tymczasowe (nazwy tabel z prefiksem # lub ##) w każdej repliki pomocniczej do przechowywania danych tymczasowych. Tabele tymczasowe to odczyt i zapis.

Opóźnienie danych od momentu zatwierdzenia transakcji na serwerze podstawowym do czasu jego odczytu w zależności od bieżącego współczynnika generowania dziennika, rozmiaru transakcji, obciążenia repliki i innych czynników. Typowe opóźnienie danych dla małych transakcji wynosi dziesiątki milisekund, ale nie ma górnej granicy opóźnienia danych. Dane na danej repliki pomocniczej są zawsze spójne transakcyjnie, dlatego propagowanie większych transakcji trwa dłużej. Jednak w danym momencie opóźnienie danych i stan bazy danych mogą być różne dla różnych replik pomocniczych. Obciążenia, które muszą natychmiast odczytywać zatwierdzone dane, powinny być uruchamiane w repliki podstawowej.

Nie, nazwane repliki nie mogą być używane jako obiekty docelowe trybu failover dla repliki podstawowej. Dodaj repliki wysokiej dostępności do tego celu.

Ponieważ każda nazwana replika może mieć inny cel poziomu usługi i dlatego może być używana w różnych przypadkach użycia, nie ma wbudowanego sposobu kierowania ruchu tylko do odczytu wysyłanego do podstawowego zestawu nazwanych replik. Na przykład można mieć osiem nazwanych replik i możesz kierować obciążenie OLTP tylko do nazwanych replik od 1 do 4, podczas gdy obciążenia analityczne usługi Power BI używają nazwanych replik 5 i 6, a obciążenie nauki o danych używa replik 7 i 8. W zależności od używanego narzędzia lub języka programowania strategie dystrybucji takiego obciążenia mogą się różnić. Aby zapoznać się z przykładem tworzenia rozwiązania do routingu obciążenia w celu umożliwienia zaplecza REST skalowania w poziomie, zapoznaj się z przykładem skalowania OLTP w poziomie.

Nie, ponieważ nazwane repliki używają tych samych serwerów stron repliki podstawowej, muszą znajdować się w tym samym regionie.

Nazwana replika nie może mieć wpływu na dostępność repliki podstawowej. Repliki nazwane, w normalnych okolicznościach, są mało prawdopodobne, aby wpłynąć na wydajność podstawowego, ale może się zdarzyć, jeśli są uruchomione intensywne obciążenia. Podobnie jak replika wysokiej dostępności, nazwana replika jest synchronizowana z podstawowym za pośrednictwem usługi dziennika transakcji. Jeśli nazwana replika, z jakiegokolwiek powodu, nie może używać dzienników transakcji wystarczająco szybko, zacznie prosić replikę podstawową o spowolnienie (ograniczanie) generowania dziennika, aby mógł nadrobić zaległości. Chociaż to zachowanie nie wpłynie na dostępność podstawowego, może to mieć wpływ na wydajność obciążeń zapisu na serwerze podstawowym. Aby uniknąć tej sytuacji, upewnij się, że nazwane repliki mają wystarczającą ilość miejsca pracy zasobów — głównie procesora CPU — do przetwarzania dziennika transakcji bez opóźnień. Jeśli na przykład podstawowy przetwarza wiele zmian danych, zaleca się posiadanie nazwanych replik z co najmniej tym samym celem poziomu usług co podstawowy, aby uniknąć saturowania procesora CPU w replikach, a tym samym wymuszenie spowolnienia podstawowego.

Repliki nazwane będą nadal dostępne dla dostępu tylko do odczytu, jak zwykle.

Domyślnie nazwane repliki nie mają własnych replik wysokiej dostępności. Przejście w tryb failover nazwanej repliki wymaga najpierw utworzenia nowej repliki, co zwykle trwa około 1–2 minut. Jednak nazwane repliki mogą również korzystać z wyższej dostępności i krótszych trybów failover oferowanych przez repliki wysokiej dostępności. Aby dodać repliki wysokiej dostępności dla nazwanej repliki, możesz użyć parametru ha-replicas z interfejsem wiersza polecenia az lub parametru HighAvailabilityReplicaCount za pomocą programu PowerShell lub highAvailabilityReplicaCount właściwości z interfejsem API REST. Liczbę replik wysokiej dostępności można ustawić podczas tworzenia nazwanej repliki i można ją zmienić — tylko za pośrednictwem interfejsu wiersza polecenia AZ, programu PowerShell lub interfejsu API REST — w dowolnym momencie po utworzeniu nazwanej repliki. Ceny replik wysokiej dostępności dla nazwanych replik są takie same jak repliki wysokiej dostępności dla zwykłych baz danych hiperskala.

Tak. Klucz główny kolumny jest przechowywany w bazie danych użytkownika i można go zweryfikować, wykonując zapytanie SELECT * FROM sys.column_master_keys. Nazwane repliki i repliki pomocnicze o wysokiej dostępności odczytują dane z tych samych serwerów stron/warstwy magazynu co podstawowa baza danych w warstwie Hiperskala. Oba typy replik są synchronizowane z podstawową bazą danych hiperskala za pośrednictwem usługi dziennika. Zmiana klucza jest uznawana za transakcję i jest automatycznie replikowana do nazwanej repliki i repliki pomocniczej o wysokiej dostępności.

Funkcja DATABASEPROPERTYEX() , gdy jest wykonywana w kontekście nazwanej repliki, może mapować element replica_id na odpowiadającą jej nazwę repliki. Jednak obecnie nie jest możliwe połączenie elementu replica_id z odpowiednią nazwaną repliką dla każdego rekordu w sys.dm_database_replica_states dynamicznym widoku zarządzania podczas wykonywania zapytań z repliki podstawowej. Poniższe przykładowe zapytanie można uruchomić w kontekście nazwanej repliki, aby zidentyfikować nazwę repliki, identyfikator repliki i szczegóły synchronizacji.

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

Powiązana zawartość

Aby uzyskać więcej informacji na temat warstwy usługi Hiperskala, zobacz Warstwa usługi Hiperskala.