Usługa Azure SQL Managed Instance (często zadawane pytania)

Aby uzyskać listę obsługiwanych funkcji w usłudze SQL Managed Instance, zobacz Funkcje usługi Azure SQL Managed Instance.

Aby uzyskać różnice w składni i zachowaniu między usługą Azure SQL Managed Instance i programem SQL Server, zobacz Różnice języka T-SQL z programu SQL Server.

Aby uzyskać informacje o dostępnych cechach sprzętu, zobacz Różnice techniczne w konfiguracjach sprzętu. Aby uzyskać informacje o dostępnych warstwach usług i ich cechach, zobacz Różnice techniczne między warstwami usług.

Każdy klient kwalifikuje się do dowolnej warstwy usług. Wersje Standard i Enterprise objęte pakietem Software Assurance można wymieniać przy użyciu Korzyść użycia hybrydowego platformy Azure (AHB) dla warstwy Ogólnego przeznaczenia (obejmującej uaktualnienie warstwy usługi Ogólnego przeznaczenia następnej generacji, obecnie w wersji zapoznawczej) lub Krytyczne dla działania firmy warstwa usługi używająca następujących współczynników wymiany 1 Standard Edition = 1 Ogólnego przeznaczenia, 1 Wersja Enterprise = 1 Krytyczne dla działania firmy, 1 Wersja Enterprise = 4 Ogólnego przeznaczenia i 4 Ogólnego przeznaczenia = 1 Enterprise Edition. Aby uzyskać więcej informacji, zobacz Określone prawa do AHB.

Aby uzyskać listę obsługiwanych typów subskrypcji, zobacz Obsługiwane typy subskrypcji.

Wystąpienia zarządzane można tworzyć w większości regionów świadczenia usługi Azure; zobacz Obsługiwane regiony dla usługi SQL Managed Instance. Jeśli potrzebujesz wystąpienia zarządzanego w regionie, który nie jest obecnie obsługiwany, wyślij wniosek o pomoc techniczną za pośrednictwem witryny Azure Portal.

Usługa SQL Managed Instance ma dwa domyślne limity: limit liczby podsieci, których można użyć, oraz limit liczby rdzeni wirtualnych, które można aprowizować. Limity różnią się w zależności od typów subskrypcji i regionów. Aby uzyskać listę ograniczeń zasobów regionalnych według typu subskrypcji, zobacz tabelę dotyczącą ograniczeń zasobów regionalnych. Są to miękkie limity, które można zwiększyć na żądanie. Jeśli potrzebujesz aprowizować więcej wystąpień zarządzanych w bieżących regionach, wyślij wniosek o pomoc techniczną, aby zwiększyć limit przydziału przy użyciu witryny Azure Portal. Aby uzyskać więcej informacji, zobacz Request quota increases for Azure SQL Database (Zwiększanie limitu przydziału żądań dla usługi Azure SQL Database).

Limit 100 baz danych na usługę SQL Managed Instance jest twardym limitem, którego nie można zmienić w warstwach ogólnego przeznaczenia i Krytyczne dla działania firmy usług. W warstwie usługi Ogólnego przeznaczenia następnej generacji można mieć do 500 baz danych.

Możesz rozważyć migrację do innych wersji platformy Azure odpowiadających obciążeniu: Hiperskala usługi Azure SQL Database lub programu SQL Server na maszynach wirtualnych platformy Azure.

Możesz rozważyć migrację do programu SQL Server na maszynach wirtualnych platformy Azure lub zoptymalizowanym pod kątem pamięci/procesora AZURE SQL Database .

Aby uzyskać informacje o wadach produktów i znanych problemach, zobacz Znane problemy.

Aby uzyskać informacje o nowych i w wersji zapoznawczej, zobacz Co nowego.

Wystąpienie zarządzane można aprowizować za pomocą witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure i szablonów usługi ARM.

Tak, możesz aprowizować wystąpienie zarządzane w istniejącej subskrypcji, jeśli ta subskrypcja należy do obsługiwanych typów subskrypcji.

Jest to bieżące ograniczenie dotyczące podstawowego składnika, który weryfikuje nazwę podsieci względem wyrażenia regularnego ^[a-zA-Z_][^\/:*?"<>|''^]*(?<! [.\s]) $. Wszystkie nazwy, które przekazują wyrażenie regularne i są prawidłowymi nazwami podsieci, są obecnie obsługiwane.

Wystąpienie zarządzane można skalować za pomocą witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure lub szablonów usługi ARM.

Tak, możesz. Aby uzyskać instrukcje, zobacz Przenoszenie zasobów między regionami.

Wystąpienia zarządzane można usuwać za pośrednictwem witryny Azure Portal, programu PowerShell, interfejsu wiersza polecenia platformy Azure lub interfejsów API REST usługi Resource Manager.

Oczekiwany czas utworzenia nowego wystąpienia zarządzanego lub zmiany warstw usług (rdzeni wirtualnych, magazynu) zależy od kilku czynników. Zobacz Operacje zarządzania.

Przywracanie każdej bazy danych jest gwarantowane przez cały zdefiniowany okres przechowywania — nawet utworzone bazy danych, a następnie usuwane po zaledwie kilku sekundach. Gdy baza danych zostanie utworzona, usunięta lub przywrócona, kopie zapasowe są wykonywane w różnych odstępach czasu w celu zachowania danych, dzięki czemu można je przywrócić w danym okresie przechowywania. Jeśli baza danych zostanie porzucona przed zakończeniem operacji tworzenia kopii zapasowej, operacja upuszczania może zostać zablokowana z powodu następującego błędu:

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

Aby uniknąć tego błędu, sprawdź stan operacji porzucenia przed ponownym utworzeniem bazy danych o tej samej nazwie. Aby uzyskać więcej informacji, zobacz sys.dm_operation_status. Kiedy stan operacji będzie miał wartośćUkończone, będzie można przywrócić lub utworzyć bazę danych o tej samej nazwie.

Następujące typowe przypadki użycia mogą napotkać ten błąd:

• Jeśli wiele baz danych zostanie porzuconych i utworzonych ponownie o tej samej nazwie w krótkim odstępie czasu. Gdy baza danych zostanie porzucona, kopia zapasowa pozostałego końca dziennika transakcji jest wykonywana synchronicznie przed zakończeniem operacji upuszczania, jak pokazano na obrazie:

  

  Nie można utworzyć bazy danych o tej samej nazwie, dopóki istnieje kopia zapasowa dziennika i operacja porzucania nie zostanie ukończona. Sekwencyjny charakter operacji porzucania umieszcza bazy danych porzucone w krótkim odstępie czasu w kolejce, co może przedłużyć proces porzucania baz danych i opóźnia możliwość tworzenia nowych baz danych przy użyciu tej samej nazwy.

• Jeśli baza danych zostanie przywrócona i porzucona przed utworzeniem pełnej kopii zapasowej. Po przywróceniu bazy danych pierwszym krokiem procesu przywracania jest utworzenie nowej pełnej kopii zapasowej bazy danych. Jeśli spróbujesz przywrócić bazę danych, a następnie upuść ją bezpośrednio przed ukończeniem pełnej kopii zapasowej, nie będzie można usunąć bazy danych i utworzyć inną bazę danych o tej samej nazwie, dopóki pełna kopia zapasowa nie zostanie wykonana, a operacja upuszczania bazy danych zakończy się. W zależności od rozmiaru bazy danych wykonanie pełnej kopii zapasowej może potrwać kilka godzin.

Możliwe, że Twoja subskrypcja nie kwalifikuje się do bezpłatnego wystąpienia zarządzanego SQL. W przeciwnym razie istnieje limit jednego bezpłatnego wystąpienia na subskrypcję. Aby utworzyć inne wystąpienie, musisz usunąć istniejące bezpłatne wystąpienie. Jeśli ostatnio usunięto bezpłatne wystąpienie, może upłynąć do jednej godziny, aby baner bezpłatnej oferty pojawił się ponownie.

Prawdopodobnie zabrakło środków na miesiąc. Przejdź do wystąpienia zarządzanego SQL w witrynie Azure Portal i sprawdź stan, aby sprawdzić, czy twoje wystąpienie jest w stanie zatrzymanym z powodu niewystarczających środków.

Ta funkcja jest obecnie niedostępna.

Tak, możesz przywrócić automatyczną kopię zapasową z usługi Azure Storage lub przywrócić kopię zapasową bazy danych przy użyciu programu SQL Server Management Studio (SSMS).

Pomimo ograniczeń zasobów bezpłatna usługa SQL Managed została zaprojektowana tak, aby umożliwić testowanie obciążeń bez żadnego wpływu. Wydajność używana podczas korzystania z bezpłatnego wystąpienia zarządzanego SQL jest identyczna z wydajnością produkcyjnej wersji wystąpienia.

Bezpłatna usługa SQL Managed Instance oferuje opcje 4 i 8 rdzeni wirtualnych. Jeśli Twoja firma wymaga wystąpienia z większą liczbie zasobów, utwórz w pełni płatne wystąpienie zarządzane SQL.

Nie można zmienić opcji tworzenia kopii zapasowych dla bezpłatnego wystąpienia zarządzanego SQL.

Obecnie subskrypcja Student jest niekwalifikowana. W przypadku kwalifikujących się subskrypcji zapoznaj się z bezpłatnymi wymaganiami wstępnymi ofert usługi SQL Managed Instance.

Zmiana nazwy wystąpienia zarządzanego nie jest obsługiwana.

Tak, domyślna database.windows.net strefa DNS wystąpienia zarządzanego SQL można zmienić na własną rękę. Jednak część nazwy hosta wystąpienia zarządzanego powinna pozostać taka sama.

Aby użyć innej strefy DNS zamiast domyślnej, na przykład .contoso.com:

• Użyj narzędzia sieciowego klienta programu SQL Server (CliConfg), aby zdefiniować alias. Możesz użyć tylko nazwy hosta wystąpienia zarządzanego lub nazwy hosta wystąpienia zarządzanego, a następnie niestandardowej nazwy domeny. Narzędzie CliConfg dodaje alias w rejestrze w obszarze "HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\Połączenie To" lub "HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\Połączenie To" w zależności od tego, czy Używasz wersji 64-bitowej (C:\Windows\System32\cliconfg.exe) lub 32-bitowej wersji (C:\Windows\SysWOW64\cliconfg.exe), więc można ją również wykonać przy użyciu zasad grupy lub skryptu. Użyj obu tych elementów, aby upewnić się, że programy 32-bitowe i 64-bitowe mogą rozpoznać alias.
• Użyj rekordu CNAME w systemie DNS z nazwą hosta wystąpienia zarządzanego wskazującą nazwę FQDN wystąpienia zarządzanego. W takim przypadku TrustServerCertificate=TRUE jest wymagane użycie uwierzytelniania z identyfikatorem Entra firmy Microsoft (dawniej Azure Active Directory).
• Użyj rekordu A w systemie DNS z nazwą hosta wystąpienia zarządzanego wskazującym adres IP wystąpienia zarządzanego. Używanie adresu IP nie jest zalecane, ponieważ może ulec zmianie bez powiadomienia. W takim przypadku TrustServerCertificate=TRUE jest to konieczne w przypadku korzystania z uwierzytelniania firmy Microsoft Entra.

Usługa Azure SQL Managed Instance oferuje te same poziomy wydajności na zasoby obliczeniowe i rozmiar magazynu, co inne opcje wdrażania usługi Azure SQL Database. Jeśli chcesz skonsolidować dane w jednym wystąpieniu lub po prostu potrzebujesz funkcji obsługiwanej wyłącznie w usłudze SQL Managed Instance, możesz przeprowadzić migrację danych przy użyciu funkcji eksportowania/importowania (BACPAC). Oto inne sposoby, aby rozważyć migrację usługi SQL Database do wystąpienia zarządzanego SQL:

• Korzystanie ze źródła danych zewnętrznego
• Korzystanie z pakietu SQLPackage
• Korzystanie z narzędzia BCP

Jedną z opcji jest wyeksportowanie bazy danych do pliku BACPAC , a następnie zaimportowanie pliku BACPAC. Jest to zalecane podejście, jeśli baza danych jest mniejsza niż 100 GB.

Replikacja transakcyjna może być używana, jeśli wszystkie tabele w bazie danych mają klucze podstawowe i nie ma obiektów OLTP w pamięci w bazie danych.

Aby przeprowadzić migrację wystąpienia programu SQL Server, zobacz Przewodnik po programie SQL Server do usługi Azure SQL Managed Instance.

Aby uzyskać informacje o migracji z innych platform, zobacz Przewodnik po migracji usługi Azure Database Migration.

W przypadku porównania wydajności między wystąpieniem zarządzanym a programem SQL Server dobrym punktem wyjścia jest najlepsze rozwiązania dotyczące porównania wydajności między usługą Azure SQL Managed Instance i programem SQL Server .

Zobacz Najważniejsze przyczyny różnic wydajności między usługą SQL Managed Instance i programem SQL Server. Rozmiar pliku dziennika transakcji może mieć wpływ na wydajność wystąpienia zarządzanego SQL ogólnego przeznaczenia. Aby uzyskać więcej informacji, zobacz Wpływ rozmiaru pliku dziennika na ogólnego przeznaczenia.

Wydajność wystąpienia zarządzanego można zoptymalizować, wykonując następujące czynności:

• Automatyczne dostrajanie , które zapewnia szczytową wydajność i stabilne obciążenia dzięki ciągłej dostrajaniu wydajności na podstawie sztucznej inteligencji i uczenia maszynowego.
• OlTP w pamięci, która zwiększa przepływność i opóźnienia obciążeń przetwarzania transakcyjnego i zapewnia szybsze analizy biznesowe.
• Stosowanie niektórych najlepszych rozwiązań dotyczących dostrajania aplikacji i bazy danych.
• Przełączenie typu połączenia z serwera proxy na tryb przekierowania w celu uzyskania mniejszego opóźnienia i wyższej przepływności, jeśli obciążenie składa się z wielu małych transakcji.

Aby zwiększyć wydajność wystąpienia ogólnego przeznaczenia, rozważ zwiększenie rozmiaru pliku danych. Aby zoptymalizować wydajność magazynu w wystąpieniu ogólnego przeznaczenia, zobacz Wskazówki dotyczące najlepszych rozwiązań magazynu dla warstwy Ogólnego przeznaczenia.

Zobacz Analizowanie statystyk oczekiwania w usłudze SQL Managed Instance. Statystyki oczekiwania to informacje, które mogą pomóc zrozumieć, dlaczego czas trwania zapytania jest długi i zidentyfikować zapytania oczekujące na coś w aucie bazy danych.

Aby uzyskać informacje o wszystkich możliwych opcjach monitorowania i zgłaszania alertów dotyczących użycia i wydajności usługi SQL Managed Instance, zobacz wpis w blogu Dotyczącym opcji monitorowania usługi Azure SQL Managed Instance. Aby uzyskać informacje na temat monitorowania wydajności w czasie rzeczywistym dla usługi SQL Managed Instance, zobacz Monitorowanie wydajności w czasie rzeczywistym dla usługi Azure SQL Managed Instance.

Zobacz Monitorowanie i dostrajanie wydajności.

Zobacz Monitorowanie wydajności w czasie rzeczywistym dla usługi Azure SQL Managed Instance.

Tak, program SQL Profiler jest obsługiwany w usłudze SQL Managed Instance. Aby uzyskać więcej informacji, zobacz SQL Profiler. Zamiast tego należy jednak rozważyć rozszerzone zdarzenia dla działania "śledzenia" z mniejszym wpływem na monitorowane wystąpienie. Aby uzyskać więcej informacji, zobacz Zdarzenia rozszerzone.

Nie, nie są one obsługiwane. Do monitorowania baz danych można używać widoków DMV i magazynu zapytań wraz z profilerem SQL i elementami XEvents.

Zobacz Monitorowanie użycia procesora CPU w programie SQL Server i usłudze Azure SQL.

Tak. Aby uzyskać instrukcje, zobacz Tworzenie alertów dla usługi SQL Managed Instance. Aby uzyskać więcej porad i wskazówek, zobacz blog.

Nie można, metryki alertów są dostępne tylko dla wystąpienia zarządzanego. Metryki alertów dla poszczególnych baz danych w wystąpieniu zarządzanym nie są dostępne.

Rozmiar magazynu dla usługi SQL Managed Instance zależy od wybranej warstwy usługi (Ogólnego przeznaczenia, Ogólnego przeznaczenia następnej generacji lub Krytyczne dla działania firmy). Aby uzyskać informacje o ograniczeniach magazynu tych warstw usług, zobacz Limity zasobów.

Minimalna ilość miejsca do magazynowania dostępnego w wystąpieniu wynosi 32 GB. Magazyn można dodać w przyrostach 32 GB do maksymalnego rozmiaru magazynu. Pierwsze 32 GB jest bezpłatne.

Tak, możesz zakupić magazyn dodatków niezależnie od zasobów obliczeniowych w pewnym zakresie. Zobacz Maksymalna ilość zarezerwowanego magazynu wystąpień w tabeli.

Aby zoptymalizować wydajność magazynu, zobacz Najlepsze rozwiązania dotyczące magazynu w obszarze Ogólnego przeznaczenia.

Nie, magazyn kopii zapasowych nie jest odejmowany z miejsca do magazynowania wystąpienia zarządzanego. Magazyn kopii zapasowych jest niezależny od miejsca do magazynowania wystąpienia i nie jest ograniczony. Magazyn kopii zapasowych jest ograniczony przez okres przechowywania kopii zapasowej baz danych wystąpień, konfigurowalny do 35 dni. Aby uzyskać szczegółowe informacje, zobacz Automatyczne kopie zapasowe.

Aby śledzić, kiedy automatyczne kopie zapasowe zostały wykonane w wystąpieniu zarządzanym SQL, zapoznaj się z artykułem Monitorowanie działania tworzenia kopii zapasowych.

Tak, można utworzyć pełną kopię zapasową tylko do kopiowania w usłudze Azure Blob Storage, ale będzie można ją przywrócić tylko do wystąpienia zarządzanego. Aby uzyskać szczegółowe informacje, zobacz Kopia zapasowa tylko do kopiowania. Jednak kopia zapasowa tylko do kopiowania jest niemożliwa, jeśli baza danych jest szyfrowana przez funkcję TDE zarządzaną przez usługę, ponieważ certyfikat używany do szyfrowania jest niedostępny. W takim przypadku użyj funkcji przywracania do punktu w czasie, aby przenieść bazę danych do innego wystąpienia zarządzanego lub przełączyć się na klucz zarządzany przez klienta.

Tak, jest obsługiwana i dostępna dla wersji programu SQL Server 2005 lub nowszych. Aby użyć przywracania natywnego, przekaż plik .bak do usługi Azure Blob Storage i wykonaj polecenia języka T-SQL. Aby uzyskać więcej informacji, zobacz Przywracanie natywne z adresu URL.

Tak, ale tylko do programu SQL Server 2022 w okresie wsparcia podstawowego programu SQL Server 2022. Istnieje możliwość, że w przyszłości niektóre funkcje usługi Azure SQL Managed Instance mogą zostać wprowadzone, które wymagają zmian w formacie bazy danych, co sprawia, że kopie zapasowe są niezgodne z najnowszą wersją programu SQL Server. Dostęp do takich funkcji wymaga jawnego wyrażenia zgody.

Systemowe bazy danych nie są replikowane do wystąpienia pomocniczego w grupie trybu failover. W związku z tym scenariusze zależne od obiektów z systemowych baz danych są niemożliwe w wystąpieniu pomocniczym, chyba że obiekty są tworzone ręcznie na serwerze pomocniczym. Aby obejść ten problem, zobacz Włączanie scenariuszy zależnych od obiektu z systemowych baz danych.

Wymagane reguły sieciowej grupy zabezpieczeń i trasy zdefiniowanej przez użytkownika są tutaj udokumentowane i automatycznie ustawiane przez usługę. Należy pamiętać, że te reguły są tylko tymi, których potrzebujemy do utrzymania usługi. Aby nawiązać połączenie z wystąpieniem i korzystać z różnych funkcji, należy ustawić dodatkowe, specyficzne dla funkcji reguły, które należy zachować.

Usługa SQL Managed Instance jest odpowiedzialna za ustawianie reguł na portach zarządzania. Można to osiągnąć za pomocą funkcji o nazwie konfiguracja podsieci wspomaganej przez usługę. Ma to na celu zapewnienie nieprzerwanego przepływu ruchu zarządzania w celu spełnienia umowy SLA.

Tak. Możesz przeanalizować ruch przychodzący przez grupę zabezpieczeń sieci, konfigurując dzienniki przepływu usługi Network Watcher.

Tak. Po aprowizacji wystąpienia zarządzanego można ustawić sieciową grupę zabezpieczeń, która kontroluje dostęp przychodzący do portu 1433. Zaleca się, aby jak najwięcej zawęzić zakres adresów IP.

L.p. Nie jest to obsługiwane z kilku powodów:

• Kierowanie ruchu reprezentującego odpowiedź na żądanie zarządzania przychodzącego byłoby asymetryczne i nie mogłoby działać.
• Routing ruchu do usługi Azure Storage będzie mieć wpływ na ograniczenia przepływności i opóźnienia, więc w ten sposób nie będziemy mogli zapewnić oczekiwanej jakości i dostępności usług.
• Te konfiguracje są podatne na błędy i nie są obsługiwane.

Tak. Najprostszym sposobem osiągnięcia tego celu jest dodanie reguły 0/0 do trasy zdefiniowanej przez użytkownika skojarzonej z podsiecią wystąpienia zarządzanego w celu kierowania ruchu przez urządzenie WUS.

Podsieć musi mieć wystarczającą liczbę dostępnych adresów IP. Aby określić rozmiar podsieci sieci wirtualnej dla usługi SQL Managed Instance, zobacz Określanie wymaganego rozmiaru i zakresu podsieci dla usługi Azure SQL Managed Instance.

Jeśli w podsieci nie ma wystarczającej liczby adresów IP, w których aprowizowane jest wystąpienie zarządzane SQL, utwórz nową podsieć i przenieś do niej wystąpienie zarządzane SQL. Zalecamy również utworzenie nowej podsieci przy użyciu większej liczby przydzielonych adresów IP, aby uniknąć podobnych sytuacji w przyszłych operacjach aktualizowania. Dowiedz się, jak przenosić usługę Azure SQL Managed Instance między podsieciami.

L.p. Możesz użyć pustej podsieci lub podsieci, która zawiera już wystąpienia zarządzane.

Nie, jeśli istnieją wystąpienia zarządzane wewnątrz. Jest to ograniczenie infrastruktury sieci platformy Azure. Możesz tylko dodać dodatkową przestrzeń adresową do pustej podsieci.

Tak. Wystąpienie zarządzane SQL można przenieść do innej podsieci w tej samej sieci wirtualnej lub w innej sieci wirtualnej w trybie online. Dowiedz się, jak przenosić usługę Azure SQL Managed Instance między podsieciami.

Nie jest to wymagane. Możesz utworzyć sieć wirtualną dla usługi Azure SQL Managed Instance lub skonfigurować istniejącą sieć wirtualną dla usługi Azure SQL Managed Instance.

L.p. Obecnie nie obsługujemy umieszczania wystąpienia zarządzanego w podsieci zawierającej już inne typy zasobów.

Nie, nie jest to obsługiwane. Nazwa hosta wystąpienia zarządzanego jest mapowania na moduł równoważenia obciążenia przed klastrem wirtualnym wystąpienia zarządzanego. Ponieważ jeden klaster wirtualny może hostować wiele wystąpień zarządzanych, nie można kierować połączenia do odpowiedniego wystąpienia zarządzanego bez określania jego nazwy. Aby uzyskać więcej informacji na temat architektury klastra wirtualnego usługi SQL Managed Instance, zobacz Architektura łączności klastra wirtualnego.

Obecnie tylko prywatne punkty końcowe do wystąpień zarządzanych gwarantują statyczne adresy IP.

W rzadkich, ale niezbędnych sytuacjach możemy przeprowadzić migrację online wystąpienia zarządzanego do nowego klastra wirtualnego lub innej grupy maszyn wirtualnych w klastrze wirtualnym ze względu na zmiany stosu technologii, które mają na celu poprawę bezpieczeństwa i niezawodności usługi. Migracja do nowej grupy maszyn wirtualnych lub klastra wirtualnego powoduje zmianę adresu IP mapowanego na nazwę hosta wystąpienia zarządzanego. Usługa wystąpienia zarządzanego nie zapewnia obsługi statycznych adresów IP i zastrzega sobie prawo do zmiany adresu IP bez powiadomienia w ramach regularnych cykli konserwacji.

Z powyższego powodu lokalne i publiczne punkty końcowe sieci wirtualnej powinny być dostępne tylko za pośrednictwem skojarzonych nazw domen. Zdecydowanie odradzamy poleganie na niezmienności ich adresu IP, ponieważ może to prowadzić do długotrwałej niedostępności, gdy usługa jest w dobrej kondycji.

Jeśli potrzebujesz statycznego adresu IP dostępnego spoza sieci wirtualnej, możesz wdrożyć usługę Azure Firewall z publicznym adresem IP frontonu i skonfigurować regułę translatora adresów sieciowych w celu tłumaczenia ruchu przychodzącego na prywatny punkt końcowy wystąpienia zarządzanego. Następnie skonfiguruj rozpoznawanie nazw DNS lub skonfiguruj aliasy klienta, aby klienci SQL nawiązywali połączenie z publicznym adresem IP zapory za pośrednictwem w pełni kwalifikowanej nazwy domeny wystąpienia zarządzanego.

Tak, można włączyć publiczny punkt końcowy, aby umożliwić ruch przychodzący z Internetu w celu dotarcia do usługi SQL Managed Instance. Aby uzyskać więcej informacji, zobacz Use SQL Managed Instance with public endpoints (Używanie usługi SQL Managed Instance z publicznymi punktami końcowymi) i Configure public endpoint in SQL Managed Instance (Konfigurowanie publicznego punktu końcowego w usłudze SQL Managed Instance).

Nie, użycie portu niestandardowego nie jest dostępne. W przypadku lokalnego punktu końcowego sieci wirtualnej usługa SQL Managed Instance używa domyślnego numeru portu 1433, a w przypadku publicznego punktu końcowego danych usługa SQL Managed Instance używa domyślnego numeru portu 3342.

Zarówno globalna komunikacja równorzędna sieci wirtualnych (komunikacja równorzędna sieci wirtualnych) i wirtualna sieć WAN platformy Azure są zalecanymi metodami łączenia dwóch wystąpień zarządzanych w różnych regionach. Komunikacja równorzędna obwodu usługi Express Route jest alternatywną opcją. Jeśli żadna z opcji nie jest możliwa w danym środowisku, jedyną inną metodą łączności jest połączenie sieci VPN typu lokacja-lokacja. Konfigurowanie sieci VPN typu lokacja-lokacja przy użyciu witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia platformy Azure

Obsługa globalnej komunikacji równorzędnej sieci wirtualnych (komunikacja równorzędna sieci wirtualnych) dla nowo utworzonych klastrów wirtualnych została dodana do usługi Azure SQL Managed Instance 22 września 2020 r. W związku z tym komunikacja równorzędna sieci wirtualnych jest obsługiwana w przypadku wystąpień zarządzanych utworzonych w pustych podsieciach po 22 września 2020 r. W przypadku wystąpień wdrożonych przed tą datą obsługa komunikacji równorzędnej jest ograniczona do sieci w tym samym regionie ze względu na ograniczenia globalnej komunikacji równorzędnej sieci wirtualnych. Aby uzyskać więcej informacji, zapoznaj się z odpowiednią sekcją często zadawanych pytań w sieciach wirtualnych platformy Azure.

Aby użyć globalnej komunikacji równorzędnej sieci wirtualnych z wystąpieniami utworzonymi przed wrześniem 2020 r., rozważ skonfigurowanie okna obsługi lub przeniesienie wystąpienia do nowej podsieci jako opcji spowoduje przeniesienie wystąpienia do nowego klastra wirtualnego obsługującego globalną komunikację równorzędną sieci wirtualnych.

Zobacz , jak sprawdzić, czy globalna komunikacja równorzędna sieci wirtualnych jest obsługiwana w klastrze wirtualnym w razie potrzeby.

Aby wyeliminować wszelkie zagrożenia związane z eksfiltracją danych, zaleca się stosowanie zestawu ustawień zabezpieczeń i mechanizmów kontroli:

• Włącz funkcję Transparent Data Encryption (TDE) we wszystkich bazach danych.
• Wyłącz środowisko uruchomieniowe języka wspólnego (CLR). Jest to również zalecane lokalnie.
• Użyj tylko uwierzytelniania entra firmy Microsoft.
• Uzyskaj dostęp do wystąpienia przy użyciu konta administratora bazy danych o niskim poziomie uprawnień.
• Skonfiguruj dostęp do serwera przesiadkowego JIT dla konta sysadmin.
• Włącz inspekcję SQL i zintegruj ją z mechanizmami alertów.
• Włącz funkcję wykrywania zagrożeń z pakietu Microsoft Defender for SQL .
• Stosowanie zasad punktu końcowego usługi do podsieci w celu kontrolowania ruchu wychodzącego do usługi Azure Storage.
• OPCJA CREATE EXTERNAL TABLE AS SELECT (CETAS) jest domyślnie wyłączona. Aby włączyć instrukcje CETAS za pośrednictwem allowPolyBaseExport opcji konfiguracji serwera, zobacz CREATE EXTERNAL TABLE AS SELECT (CETAS).

Tak. Zobacz Rozpoznawanie prywatnych nazw DNS w usłudze Azure SQL Managed Instance.

Tak. Zobacz Rozpoznawanie prywatnych nazw DNS w usłudze Azure SQL Managed Instance.

Konfigurację strefy czasowej można ustawić, gdy wystąpienie zarządzane jest aprowidowane po raz pierwszy. Zmiana strefy czasowej istniejącego wystąpienia zarządzanego nie jest obsługiwana. Aby uzyskać szczegółowe informacje, zobacz Ograniczenia strefy czasowej.

Obejścia obejmują utworzenie nowego wystąpienia zarządzanego z odpowiednią strefą czasową, a następnie wykonanie ręcznej kopii zapasowej i przywracania lub zalecane przez nas wykonanie przywracania do punktu w czasie między wystąpieniami.

Tak, klienci mogą tworzyć identyfikatory logowania należące do roli administratora systemu. Klienci, którzy zakładają, że uprawnienia administratora systemu również ponoszą odpowiedzialność za obsługę wystąpienia, co może negatywnie wpłynąć na zobowiązanie umowy SLA. Aby dodać identyfikator logowania do roli serwera sysadmin, zobacz Microsoft Entra authentication (Uwierzytelnianie firmy Microsoft w usłudze Entra).

Tak, usługa Azure SQL Managed Instance obsługuje funkcję Transparent Data Encryption (TDE). Aby uzyskać szczegółowe informacje, zobacz Transparent Data Encryption for SQL Managed Instance (Szyfrowanie Transparent Data Encryption dla usługi SQL Managed Instance).

Tak, usługa Azure Key Vault dla scenariusza BYOK jest dostępna dla usługi Azure SQL Managed Instance. Aby uzyskać szczegółowe informacje, zobacz Transparent Data Encryption with customer-managed key (Szyfrowanie Transparent Data Encryption z kluczem zarządzanym przez klienta).

Tak, możesz. Aby przeprowadzić migrację zaszyfrowanej bazy danych programu SQL Server, należy wyeksportować i zaimportować istniejące certyfikaty do usługi SQL Managed Instance, a następnie utworzyć pełną kopię zapasową bazy danych i przywrócić ją do wystąpienia zarządzanego.

Za pomocą usługi Azure Database Migration Service można również przeprowadzić migrację zaszyfrowanych baz danych TDE.

Funkcję ochrony TDE dla usługi SQL Managed Instance można obrócić przy użyciu usługi Azure Cloud Shell. Aby uzyskać instrukcje, zobacz Transparent Data Encryption in SQL Managed Instance using your own key from Azure Key Vault (Szyfrowanie Transparent Data Encryption w usłudze SQL Managed Instance przy użyciu własnego klucza z usługi Azure Key Vault).

Tak, nie musisz odszyfrowywać bazy danych, aby przywrócić ją do usługi SQL Managed Instance. Należy podać certyfikat/klucz używany jako funkcja ochrony klucza szyfrowania w systemie źródłowym do usługi SQL Managed Instance, aby móc odczytywać dane z zaszyfrowanego pliku kopii zapasowej. Istnieją dwa możliwe sposoby, aby to zrobić:

• Przekaż funkcję ochrony certyfikatu do usługi SQL Managed Instance. Można to zrobić tylko przy użyciu programu PowerShell. Przykładowy skrypt opisuje cały proces.
• Przekaż asymetryczną ochronę klucza do usługi Azure Key Vault i wskaż wystąpienie zarządzane SQL do niego. Takie podejście przypomina przypadek użycia funkcji TDE bring-your-own-key (BYOK), który używa również integracji z usługą Key Vault do przechowywania klucza szyfrowania. Jeśli nie chcesz używać klucza jako funkcji ochrony klucza szyfrowania i po prostu chcesz udostępnić klucz dla usługi SQL Managed Instance w celu przywrócenia zaszyfrowanych baz danych, postępuj zgodnie z instrukcjami dotyczącymi konfigurowania funkcji TDE BYOK i nie zaznacz pola wyboru Ustaw wybrany klucz jako domyślny funkcja ochrony TDE.

Po udostępnieniu funkcji ochrony szyfrowania dla usługi SQL Managed Instance można przejść do standardowej procedury przywracania bazy danych.

Usługa SQL Managed Instance oferuje model zakupów oparty na rdzeniach wirtualnych.

Możesz zaoszczędzić koszty dzięki korzyściom usługi Azure SQL w następujący sposób:

• Maksymalizuj istniejące inwestycje w licencje lokalne i oszczędzaj do 55 procent dzięki Korzyść użycia hybrydowego platformy Azure.
• Zatwierdź rezerwację dla zasobów obliczeniowych i zaoszczędź do 33 procent dzięki korzyści z wystąpienia zarezerwowanego. Połącz tę korzyść z korzyścią użycia hybrydowego platformy Azure, aby uzyskać oszczędności do 82 procent.
• Zaoszczędzenie do 55 procent w porównaniu z cenami list dzięki korzyściom cenowym tworzenia i testowania platformy Azure, która oferuje obniżone stawki dla bieżących obciążeń programistycznych i testowych.

Aby kwalifikować się do korzyści z wystąpienia zarezerwowanego, typ subskrypcji musi być umową Enterprise Agreement (numery ofert: MS-AZR-0017P lub MS-AZR-0148P) lub indywidualną umowę z cennikiem płatności zgodnie z rzeczywistym użyciem (numery ofert: MS-AZR-0003P lub MS-AZR-0023P). Aby uzyskać więcej informacji na temat rezerwacji, zobacz Korzyść wystąpienia zarezerwowanego.

Rezerwacje można anulować, wymieniać lub zwracać, jednak obowiązują przy tym pewne ograniczenia. Aby uzyskać więcej informacji, zobacz temat Self-service exchanges and refunds for Azure Reservations (Samoobsługowe wymiany i zwroty kosztów dla rezerwacji platformy Azure).

Aby zapoznać się z opcjami cen usługi SQL Managed Instance, zobacz stronę Cennik.

Możesz to zrobić przy użyciu rozwiązania Microsoft Cost Management. Przejdź do pozycji Subskrypcje w witrynie Azure Portal i wybierz pozycję Analiza kosztów.

Użyj opcji Skumulowane koszty, a następnie przefiltruj według typu zasobu jako microsoft.sql/managedinstances.

Możesz użyć zgodnych narzędzi klienckich firmy Microsoft lub innych firm, aby uzyskać dostęp do usługi SQL Managed Instance i nie będą naliczane żadne dodatkowe koszty na fakturze za platformę Azure. Jeśli jednak niektóre narzędzia wymagają licencji, wymagane jest posiadanie legalnie licencjonowanego oprogramowania. Jest to objęte oddzielnymi umowami, które są objęte poszczególnymi producentami narzędzi.

Ilość wolnego miejsca do magazynowania kopii zapasowych jest równa zakupionej zarezerwowanej przestrzeni dyskowej danych niezależnie od ustawionego okresu przechowywania kopii zapasowych. Jeśli użycie magazynu kopii zapasowych znajduje się w przydzielonym bezpłatnym miejscu do magazynowania kopii zapasowych, automatyczne kopie zapasowe w usłudze SQL Managed Instance nie są dla Ciebie dodatkowe, dlatego będą bezpłatne. Przekroczenie użycia magazynu kopii zapasowych powyżej wolnego miejsca powoduje dodatkowy koszt. Aby uzyskać szczegółowe informacje, zobacz sekcję Magazyn kopii zapasowych na stronie cennika. Więcej informacji technicznych na temat automatycznych kopii zapasowych usługi SQL Managed Instance można znaleźć w temacie Użycie magazynu kopii zapasowych.

Koszt magazynu kopii zapasowych można monitorować za pośrednictwem witryny Azure Portal. Aby uzyskać instrukcje, zobacz Monitorowanie kosztów automatycznych kopii zapasowych.

Aby zoptymalizować koszty magazynu kopii zapasowych, zobacz Dostosowywanie kopii zapasowych w usłudze SQL Managed Instance.

Analizy przypadków wystąpienia zarządzanego SQL:

• Komatsu
• KMD
• PowerDETAILS
• Wszystkie skrypty

Aby lepiej zrozumieć korzyści, koszty i czynniki ryzyka związane z wdrażaniem usługi Azure SQL Managed Instance, istnieje również badanie forrester: Łączny wpływ ekonomiczny baz danych usługi Microsoft Azure SQL Managed Instance.

Zasady haseł usługi SQL Managed Instance dla identyfikatorów logowania SQL dziedziczą zasady platformy Azure stosowane do maszyn wirtualnych tworzących klaster wirtualny z wystąpieniem zarządzanym. W tej chwili nie można zmienić żadnego z tych ustawień, ponieważ te ustawienia są definiowane przez platformę Azure i dziedziczone przez wystąpienie zarządzane.

Każde logowanie musi ustawić swoje hasło podczas logowania i zmienić hasło po osiągnięciu maksymalnego wieku.

Tak, można kontrolować pola CHECK_POLICY i CHECK_EXPIRATION na poziomie logowania. Bieżące ustawienia można sprawdzić, wykonując następujące polecenie języka T-SQL:

SELECT *
FROM sys.sql_logins

Następnie można zmodyfikować określone ustawienia logowania, wykonując polecenie :

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(Zastąp ciąg "test" żądaną nazwą logowania i dostosuj wartości zasad i wygasania).

Zobacz Rotacja certyfikatów dla usługi Azure SQL Database i wystąpienia zarządzanego SQL.

Zobacz Planowanie zdarzeń konserwacji platformy Azure w usłudze SQL Managed Instance.

Możesz głosować na nową funkcję usługi SQL Managed Instance lub utworzyć nowy pomysł na ulepszenie na forum opinii o wystąpieniu zarządzanym SQL. Dzięki temu możesz przyczynić się do rozwoju produktu i pomóc nam określić priorytety naszych potencjalnych ulepszeń.

Aby dowiedzieć się, jak utworzyć żądanie pomoc techniczna platformy Azure, zobacz Jak utworzyć żądanie pomoc techniczna platformy Azure.

Wszystkie regiony, oferty i typy subskrypcji mają włączoną falę funkcji od listopada 2023 r.

Fala funkcji jest dostępna dla wystąpień w kwalifikujących się podsieciach. Jeśli nie widzisz nowych funkcji, prawdopodobnie podsieć, w której wdrożono wystąpienie zarządzane SQL, nie kwalifikuje się.