Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:
Azure SQL Managed Instance
W tym artykule wymieniono obecnie znane problemy z Azure SQL Managed Instance oraz datą rozwiązania lub możliwym obejściem. Aby dowiedzieć się więcej na temat Azure SQL Managed Instance, zobacz Co to jest Azure SQL Managed Instance? i Co nowego w Azure SQL Managed Instance?
Uwaga
Microsoft Entra ID wcześniej był znany jako Azure Active Directory (Azure AD).
Znane problemy
Ma obejście
Niepowodzenia operacji przywracania po migracji do usługi SQL Managed Instance
W przypadku migracji bazy danych do Azure SQL Managed Instance z SQL Server 2019 i nowszych wersji z włączonym przyspieszonym odzyskiwaniem bazy danych, ale skonfigurowanej przy użyciu magazynu wersji trwałej (PVS) ustawionego na inną niż grupa plików PRIMARY, można doświadczyć błędów podczas operacji przywracania na docelowym wystąpieniu zarządzanym SQL.
Aby obejść ten problem, upewnij się, że ustawiono magazyn wersji persistent (PVS) na PRIMARY w źródłowej bazie danych SQL Server przed przeprowadzeniem migracji do SQL Managed Instance. Jeśli baza danych została już zmigrowana bez ustawienia pvS na PRIMARY, możesz ustawić ją w źródłowej bazie danych SQL Server, a następnie ponownie zmigrować bazę danych do SQL Managed Instance.
Nie można użyć przyspieszonego odzyskiwania bazy danych po przeprowadzeniu migracji do SQL Managed Instance
Począwszy od SQL Server 2019, jeśli migrujesz bazę danych do Azure SQL Managed Instance, a źródłowa baza danych ma przyspieszone odzyskiwanie bazy danych wyłączone, nie można użyć przyspieszonego odzyskiwania bazy danych w docelowym wystąpieniu zarządzanym SQL.
Aby obejść ten problem, upewnij się, że włączysz przyspieszone odzyskiwanie bazy danych w źródłowej bazie danych SQL Server przed przeprowadzeniem migracji do SQL Managed Instance. Jeśli baza danych została już zmigrowana bez włączania przyspieszonego odzyskiwania bazy danych, możesz ją włączyć w źródłowej bazie danych SQL Server, a następnie ponownie zmigrować bazę danych do wystąpienia zarządzanego SQL.
SQL Server 2017 i wcześniejszych wersjach nie obsługują przyspieszonego odzyskiwania bazy danych, więc ten problem nie dotyczy baz danych migrowanych z tych wersji SQL Server.
Nie można użyć usługi Service Broker po przeprowadzeniu migracji do SQL Managed Instance
W przypadku migracji bazy danych do Azure SQL Managed Instance, i Service Broker jest wyłączony w źródłowej bazie danych, nie można użyć usługi Service Broker w docelowej zarządzanej instancji SQL.
Aby obejść ten problem, przed przeprowadzeniem migracji do SQL Managed Instance upewnij się, że włączono usługę Service Broker w źródłowej bazie danych SQL Server. Jeśli baza danych została już zmigrowana bez włączania usługi Service Broker, możesz ją włączyć w źródłowej bazie danych SQL Server, a następnie ponownie zmigrować bazę danych do SQL Managed Instance.
Modyfikowanie okresu przechowywania kopii zapasowych dla bezpłatnej oferty
Zasady przechowywania kopii zapasowych baz danych w bezpłatnym wystąpieniu zarządzanym SQL można modyfikować tylko przy użyciu REST API, PowerShell i Azure CLI. Nie można zmodyfikować zasad przechowywania kopii zapasowych za pomocą portalu Azure.
Logowanie do odczytu wtórnego nie powiodło się z powodu długiego oczekiwania na "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING"
Ten błąd może być widoczny jako wyjątek dla sterownika Microsoft OLE DB Driver 19 dla SQL Server podczas próby nawiązania połączenia z pomocniczą repliką tylko do odczytu grupy failover lub bazy danych replikowanej za pośrednictwem łącza Managed Instance.
Ten błąd występuje, gdy replika pomocnicza nie jest dostępna do logowania się, ponieważ brakuje wersji wierszy dla transakcji, które były przetwarzane w momencie ponownego uruchomienia lub ponownej aktywacji repliki pomocniczej, zarówno w celach konserwacyjnych, jak i z powodu przełączenia awaryjnego. Gdy wystąpienie zostanie ponownie uruchomione lub podczas przełączania awaryjnego, dane wersjonowania przechowywane w tempdb są czyszczone. Dodatkowe zapytania odczytu są przerywane, jeśli istnieją długotrwałe aktywne transakcje, które zostały uruchomione przed przełączeniem awaryjnym lub ponownym uruchomieniem.
Aby rozwiązać ten problem, wycofaj lub zatwierdź aktywne transakcje w replice podstawowej. Aby uniknąć tego błędu, zminimalizuj długotrwałe transakcje zapisu na głównej replice.
Błąd 8992 podczas uruchamiania bazy danych DBCC CHECKDB w bazie danych SQL Server pochodzącej z SQL Managed Instance
Podczas uruchamiania polecenia DBCC CHECKDB w bazie danych SQL Server 2022, możesz napotkać następujący błąd po usunięciu indeksu lub tabeli z indeksem. Może się to zdarzyć, gdy baza danych pochodzi z Azure SQL Managed Instance, na przykład po przywróceniu pliku kopii zapasowej lub z użyciem funkcji linku SQL Managed Instance.
Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.
Aby obejść ten problem, najpierw upuść indeks lub tabelę z indeksem z źródłowej bazy danych w Azure SQL Managed Instance, a następnie przywrócić lub połączyć bazę danych do SQL Server 2022 ponownie. Jeśli ponowne utworzenie bazy danych ze źródłowej Azure SQL Managed Instance nie jest możliwe, skontaktuj się z pomocą techniczną Microsoft, aby rozwiązać ten problem.
Ostrzeżenie
Jeśli utworzysz indeks partycjonowany w tabeli po usunięciu indeksu zgodnie z opisem w tym scenariuszu, tabela stanie się niedostępna.
Błąd 1412 podczas tworzenia łącza Managed Instance
Po pierwszym utworzeniu linku pierwsza część procesu tworzy pełną kopię zapasową bazy danych z repliki podstawowej do repliki pomocniczej. Po zakończeniu wstępnego ładowania pełnej kopii zapasowej łącze rozpoczyna replikowanie danych poprzez zastosowanie danych różnicowych z repliki podstawowej do repliki wtórnej. Ten proces jest kontynuowany w nieskończoność do momentu wydania polecenia trybu failover lub usunięcia linku.
Jeśli kopia zapasowa dziennika transakcji występuje na replice podstawowej podczas inicjalizacji pełnej kopii zapasowej, dziennik transakcji jest obcinany. Tworzenie łącza kończy się niepowodzeniem z powodu błędu 1412, ponieważ dane w dzienniku transakcji niezbędne do początkowego rozmieszczania nie są już dostępne.
Jeśli w dzienniku błędów SQL Server jest wyświetlany błąd 1412 w Azure SQL Managed Instance, musisz drop i utworzyć ponownie link. Aby uniknąć tego problemu, należy wstrzymać kopie zapasowe dziennika transakcji podczas początkowej fazy rozmieszczania. Jeśli kopie zapasowe dziennika transakcji są niezbędne w początkowej fazie rozmieszczania, rozpocznij otwartą transakcję, aby zapobiec obcięciu dziennika. Aby uzyskać więcej informacji, zapoznaj się z Error 1412 podczas tworzenia linku Managed Instance w przewodniku rozwiązywania problemów funkcji linku.
Lista długoterminowych kopii zapasowych w portalu Azure zawiera pliki kopii zapasowej aktywnych i usuniętych baz danych o tej samej nazwie
Długoterminowe kopie zapasowe można wyświetlać na stronie portalu Azure i zarządzać nimi dla Azure SQL Managed Instance na karcie
Obejście: Użyj wyświetlanych informacji o czasie tworzenia kopii zapasowej (UTC) na liście, aby odróżnić kopie zapasowe należące do baz danych o tej samej nazwie, które istniały na instancji w różnych okresach. Alternatywnie użyj poleceń programu PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup i Remove-AzSqlInstanceDatabaseLongTermRetentionBackup, lub poleceń interfejsu wiersza polecenia az sql midb ltr-backup list i az sql midb ltr-backup delete, aby zarządzać długoterminowymi kopiami zapasowymi przy użyciu parametru DatabaseState i wartości zwracanej DatabaseDeletionTime w celu filtrowania kopii zapasowych bazy danych.
Sp_send_dbmail procedury może zakończyć się niepowodzeniem w przypadku użycia parametru @query
Procedura sp_send_dbmail składowana może zakończyć się niepowodzeniem w przypadku użycia parametru @query . Błędy występują, gdy procedura składowana jest wykonywana na koncie administratora systemu .
Ten problem jest spowodowany przez znaną usterkę związaną ze sposobem, w jaki sp_send_dbmail wykorzystuje przejęcie tożsamości.
Obejście: Upewnij się, że wywołujesz sp_send_dbmail w ramach odpowiedniego konta niestandardowego, które utworzysz, a nie w ramach konta administratora systemu.
Oto przykład tworzenia dedykowanego konta i modyfikowania istniejących obiektów, które wysyłają wiadomość e-mail za pośrednictwem polecenia sp_send_dbmail.
USE [msdb];
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name];
GO
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_user_name = N'user_name';
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name];
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_name = N'msdb';
GO
-- Step 4: Set a principal in the email profile
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@principal_name = N'user_name',
@profile_name = N'profile_name',
@is_default = 0;
GO
Transakcje rozproszone można wykonywać po usunięciu wystąpienia zarządzanego SQL z Grupy Zaufania Serwera
Grupy zaufania serwerów są używane do ustanawiania zaufania między zarządzanymi wystąpieniami, co jest warunkiem wstępnym do wykonywania rozproszonych transakcji. Po usunięciu wystąpienia zarządzanego SQL z grupy zaufania serwera lub usunięciu grupy nadal może być możliwe wykonywanie transakcji rozproszonych. Aby upewnić się, że transakcje rozproszone są wyłączone, wykonaj inicjowane przez użytkownika ręczne przejście w tryb failover w zarządzanym wystąpieniu SQL.
Nie można utworzyć SQL Managed Instance o tej samej nazwie co wcześniej usunięty serwer logiczny
Podczas tworzenia serwera logical w Azure dla Azure SQL Database lub SQL Managed Instance system tworzy rekord DNS dla <name>.database.windows.com. Ten rekord DNS musi być unikatowy. Jeśli utworzysz serwer logiczny dla usługi SQL Database, a następnie usuniesz go, nazwa pozostanie zarezerwowana przez siedem dni. W tym okresie nie można utworzyć SQL Managed Instance o tej samej nazwie co usunięty serwer logiczny. Aby obejść ten problem, użyj innej nazwy dla SQL Managed Instance lub utwórz zgłoszenie do pomocy technicznej, aby zwolnić nazwę serwera logicznego.
Jednostka usługi nie może uzyskać dostępu do Microsoft Entra ID i usługi AKV
W niektórych okolicznościach występuje problem z jednostką usługi używaną do uzyskiwania dostępu do usług Microsoft Entra ID (formerly Azure Active Directory) i Azure Key Vault (AKV). W rezultacie ten problem ma wpływ na użycie uwierzytelniania Microsoft Entra i przezroczystego szyfrowania danych (TDE) przy użyciu SQL Managed Instance. Ten problem może wystąpić jako sporadyczne problemy z łącznością lub brak możliwości uruchamiania instrukcji, takich jak CREATE LOGIN/USER FROM EXTERNAL PROVIDER lub EXECUTE AS LOGIN/USER. Skonfigurowanie funkcji TDE przy użyciu klucza zarządzanego przez klienta na nowym Azure SQL Managed Instance może również nie działać w pewnych okolicznościach.
Workaround: Aby zapobiec wystąpieniu tego problemu na SQL Managed Instance, przed wykonaniem jakichkolwiek poleceń aktualizacji lub w przypadku, gdy ten problem wystąpił już po zaktualizowaniu poleceń, przejdź do strony Przegląd SQL managed instance w portalu Azure. W obszarze Settings wybierz Microsoft Entra ID aby uzyskać dostęp do strony administratora SQL Managed Instance Microsoft Entra ID. Poszukaj następującego komunikatu o błędzie:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Jeśli wystąpi ten komunikat o błędzie, wybierz go i postępuj zgodnie z instrukcjami krok po kroku podanymi do momentu usunięcia tego błędu.
Wystąpił nieprawidłowy błąd podczas próby usunięcia pliku, który nie jest pusty
SQL Server i SQL Managed Instance nie zezwalają użytkownikowi na usunięcie pliku, który nie jest pusty. Jeśli spróbujesz usunąć niepusty plik danych przy użyciu instrukcji ALTER DATABASE REMOVE FILE, pojawi się błąd:
Msg 5042 - The file '<file_name>' cannot be removed because it is not empty` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `Internal server error.
Trwające przywracanie bazy danych blokuje zmianę warstwy usługi i operacje tworzenia instancji
Ciągła RESTORE instrukcja, proces migracji usługi Data Migration Service i wbudowane przywracanie do punktu w czasie mogą blokować aktualizacje warstwy usługi lub zmieniać rozmiar istniejącego wystąpienia i tworzyć nowe wystąpienia do momentu zakończenia procesu przywracania.
Proces przywracania blokuje wykonywanie tych operacji na zarządzanych instancjach i pulach instancji w tej samej podsieci, w której działa proces przywracania. Wystąpienia w pulach wystąpień nie są objęte zmianami. Tworzenie lub zmienianie operacji warstwy usługi nie kończy się niepowodzeniem ani przekroczeniem limitu czasu. Są one kontynuowane po zakończeniu lub anulowaniu procesu przywracania.
Obejście: Poczekaj na zakończenie procesu przywracania lub, jeśli operacja tworzenia lub aktualizacji warstwy usługi ma wyższy priorytet, anuluj proces przywracania.
Resource Governor na wtórnej replice z możliwością odczytu wymaga ponownej konfiguracji po wykonaniu przełączenia awaryjnego.
Funkcja Resource Governor umożliwiająca ograniczenie zasobów przypisanych do obciążenia użytkownika może niepoprawnie sklasyfikować niektóre obciążenia po awarii i trybie failover lub zmianie warstwy usługi zainicjowanej przez użytkownika (na przykład zmiana maksymalnej liczby vCore lub maksymalnego rozmiaru magazynu wystąpienia).
Obejście: Uruchamiaj ALTER RESOURCE GOVERNOR RECONFIGURE okresowo lub jako część zadania agenta SQL, które wykonuje zadanie SQL przy uruchomieniu repliki pomocniczej z możliwością odczytu, jeśli używasz Resource Governor.
Przekraczanie rozmiaru przestrzeni dyskowej w przypadku małych plików bazy danych
CREATE DATABASE, ALTER DATABASE ADD FILE, i RESTORE DATABASE mogą zakończyć się niepowodzeniem, ponieważ wystąpienie osiąga limit Azure Storage w warstwie usługi Ogólnego Przeznaczenia, ale nie w warstwie usługi Ulepszonego Ogólnego Przeznaczenia ani Krytycznej dla Biznesu.
Każde wystąpienie usługi SQL Managed Instance w warstwie ogólnego przeznaczenia ma do 35 TB pamięci masowej zarezerwowanej na dysk Azure Premium. Każdy plik bazy danych jest umieszczany na osobnym dysku fizycznym. Rozmiary dysków mogą wynosić 128 GB, 256 GB, 512 GB, 1 TB lub 4 TB. Nie są naliczane opłaty za nieużywane miejsce na dysku, ale łączna rozmiar dysków Premium Azure nie może przekroczyć 35 TB. W niektórych przypadkach zarządzana instancja SQL, która nie wymaga całkowitego rozmiaru 8 TB, może przekroczyć limit 35 TB na rozmiar magazynu w Azure z powodu fragmentacji wewnętrznej.
Na przykład, w przypadku instancji SQL Managed Instance o ogólnym przeznaczeniu, może istnieć jeden duży plik o rozmiarze 1,2 TB, umieszczony na dysku o pojemności 4 TB. Może również zawierać 248 plików o rozmiarze 1 GB i umieszczanych na oddzielnych dyskach 128 GB. W tym przykładzie:
- Łączny przydzielony rozmiar magazynu dysku wynosi 1 x 4 TB + 248 x 128 GB = 35 TB.
- Łączna ilość zarezerwowanego miejsca dla baz danych w wystąpieniu wynosi 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.
W tym przykładzie pokazano, że w pewnych okolicznościach, ze względu na określoną dystrybucję plików, wystąpienie SQL Managed Instance może nieoczekiwanie osiągnąć limit 35 TB zarezerwowany dla dołączonego dysku Azure Premium Disk.
W tym przykładzie istniejące bazy danych nadal działają i mogą rosnąć bez żadnego problemu, o ile nowe pliki nie są dodawane. Nie można tworzyć ani przywracać nowych baz danych, ponieważ nie ma wystarczającej ilości miejsca na nowe dyski, nawet jeśli całkowity rozmiar wszystkich baz danych nie osiągnie limitu rozmiaru wystąpienia. Zwrócony błąd nie jest jasny.
Możesz zidentyfikować liczbę pozostałych plików przy użyciu widoków systemowych. Jeśli osiągniesz ten limit, spróbuj opróżnić i usunąć niektóre mniejsze pliki przy użyciu instrukcji DBCC SHRINKFILE lub przejść na warstwę Krytyczne dla działania firmy, która nie ma tego limitu.
Wartości identyfikatora GUID wyświetlane zamiast nazw baz danych
Kilka widoków systemu, liczników wydajności, komunikatów o błędach, elementów XEvent i wpisów dziennika błędów wyświetla identyfikatory GUID bazy danych zamiast rzeczywistych nazw baz danych. Nie należy polegać na tych identyfikatorach GUID, ponieważ mogą zostać zastąpione rzeczywistymi nazwami baz danych w przyszłości.
Obejście: Użyj sys.databases widoku, aby rozpoznać rzeczywistą nazwę bazy danych z nazwy fizycznej bazy danych określonej w postaci identyfikatorów bazy danych GUID:
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
Moduły CLR i połączone serwery czasami nie mogą odwoływać się do lokalnego adresu IP
Moduły CLR w SQL Managed Instance i połączonych serwerach lub zapytaniach rozproszonych odwołujących się do bieżącego wystąpienia czasami nie mogą rozpoznać adresu IP wystąpienia lokalnego. Ten błąd jest przejściowym problemem.
Brak rozwiązania
Mylący komunikat o błędzie podczas próby nawiązania połączenia z repliką do odczytu przy użyciu nieprawidłowych poświadczeń
Podczas próby nawiązania połączenia z repliką pomocniczą instancji w warstwie kluczowej dla firmy, przy użyciu ApplicationIntent=ReadOnly i nieprawidłowych poświadczeń, instancja zgłasza błąd wskazujący, że baza danych master jest tylko do odczytu. Wystąpienie niepoprawnie raportuje nieprawidłowość poświadczeń.
Różnicowe kopie zapasowe nie są wykonywane, gdy wystąpienie jest połączone z SQL Server
Podczas konfigurowania link między SQL Server i Azure SQL Managed Instance automatyczne kopie zapasowe dziennika pełnej i transakcyjnej są wykonywane w wystąpieniu zarządzanym SQL, niezależnie od tego, czy jest on w roli głównej. Jednak różnicowe kopie zapasowe nie są obecnie wykonywane, co może prowadzić do dłuższych niż oczekiwano czasów przywracania.
Zwiększona liczba logowań systemowych używanych do replikacji transakcyjnej
Usługa Azure SQL Managed Instance tworzy dane logowania systemu do celów replikacji transakcyjnej. Ten identyfikator logowania można znaleźć w programie SSMS (w Eksplorator obiektów>Security>Logins) lub w widoku systemu sys.syslogins. Format nazwy logowania wygląda następująco: DBxCy\WF-abcde01234QWERT, a nazwa logowania ma rolę serwera publicznego . W pewnych warunkach ta nazwa logowania zostanie ponownie utworzona i ze względu na problem wewnętrzny poprzedni identyfikator logowania nie zostanie usunięty. Ten błąd może prowadzić do zwiększenia liczby logowań. Te identyfikatory logowania nie reprezentują zagrożenia bezpieczeństwa i można je bezpiecznie zignorować. Nie usuwaj tych identyfikatorów logowania, ponieważ co najmniej jeden z nich jest używany do replikacji transakcyjnej.
Loginy i użytkownicy Microsoft Entra nie są obsługiwani w programie SSDT
SQL Server Data Tools nie obsługują w pełni Microsoft Entra logowań i użytkowników.
Personifikacja typów logowania Microsoft Entra nie jest obsługiwana
Personifikacja z użyciem EXECUTE AS USER lub EXECUTE AS LOGIN nie jest obsługiwana dla następujących obiektów Microsoft Entra:
- Użytkownicy Microsoft Entra z aliasem. W tym przypadku operacja zwraca błąd
15517. - Logowania i użytkownicy Microsoft Entra na podstawie aplikacji Microsoft Entra lub głównych usług. W tym przypadku operacja zwraca błędy
15517i15406.
Replikacja transakcyjna musi zostać ponownie skonfigurowana po awarii geograficznej
Jeśli włączysz replikację transakcyjną dla bazy danych w grupie przełączeń awaryjnych, administrator usługi SQL Managed Instance musi wyczyścić wszystkie publikacje na starym serwerze podstawowym i ponownie skonfigurować je na nowym serwerze podstawowym po przełączeniu do innego regionu. Aby uzyskać więcej informacji, zobacz Replikacja.
Dzienniki błędów nie są utrwalane
Dzienniki błędów, które są dostępne w SQL Managed Instance nie są utrwalane, a ich rozmiar nie jest uwzględniany w maksymalnym limicie magazynu. Dzienniki błędów mogą zostać automatycznie wymazane w przypadku przejścia w tryb failover. Luki mogą istnieć w historii dziennika błędów, ponieważ SQL Managed Instance został przeniesiony kilka razy na kilku maszynach wirtualnych.
Rozwiązano
Plik docelowy event_file sesji zdarzeń system_health jest niedostępny
(Rozwiązano w marcu 2026 r.) Podczas próby odczytania zawartości event_file elementu docelowego system_health sesji zdarzeń zostanie wyświetlony błąd 40538 " Prawidłowy adres URL rozpoczynający się od "https://" jest wymagany jako wartość dla każdej określonej ścieżki plików".
Ten problem wystąpił w programie SQL Server Management Studio (SSMS) lub podczas odczytywania danych sesji przy użyciu funkcji sys.fn_xe_file_target_read_file. Problem został rozwiązany w obu przypadkach.
Ta zmiana zachowania była niezamierzoną konsekwencją wymaganej poprawki zabezpieczeń. Klienci mogą obejść ten problem, tworząc własny odpowiednik sesji system_health z docelowym obiektem event_file w Blob Storage Azure. Aby uzyskać więcej informacji, w tym skrypt języka T-SQL do utworzenia sesji system_health, który można zmodyfikować, aby utworzyć własny odpowiednik system_health, zobacz Używanie sesji system_health.
Tymczasowe wskazówki dotyczące aktualizacji strefy czasowej 2024 dla Paragwaju
(Rozwiązano w lutym 2026 r.)
14 października 2024 r. rząd Paragwaju ogłosił stałą zmianę polityki strefy czasowej. Paragwaj pozostaje teraz na czas letni (DST) przez cały rok, skutecznie przyjmując UTC-3 jako standardowy czas. W rezultacie zegary nie awansowały o 60 minut o godzinie 12:00 w dniu 23 marca 2025 r., zgodnie z wcześniejszym harmonogramem. Ta zmiana wpływa na strefę czasową standardową Paragwaju. Microsoft wydała powiązane aktualizacje Windows w lutym i marcu 2025 r.. Wystąpienia zarządzane SQL używające objętej strefy czasowej odzwierciedlają tę zmianę i zostają dostosowane do nowego przesunięcia UTC-3.
Zmiana typu połączenia nie wpływa na połączenia za pośrednictwem punktu końcowego grupy failover
(Rozwiązano w listopadzie 2025 r.)
Jeśli instancja uczestniczy w grupie awaryjnego przełączania, zmiana typu połączenia nie będzie obowiązywać dla połączeń ustanowionych za pośrednictwem punktu końcowego odbiornika tej grupy.
Tymczasowa niedostępność wystąpienia z powodu użycia odbiornika grupy przełączeniowej podczas operacji skalowania
(Rozwiązano w kwietniu 2025 r.)
Skalowanie wystąpienia zarządzanego SQL czasami wymaga przeniesienia wystąpienia do innego klastra wirtualnego wraz ze skojarzonymi rekordami DNS obsługiwanymi przez usługę. Jeśli zarządzane wystąpienie SQL uczestniczy w grupie trybu failover, rekord DNS związany z odpowiednim odbiornikiem grupy trybu failover (odbiornik odczytu i zapisu, jeśli wystąpienie jest aktualnym geo-głównym, lub odbiornik wyłącznie do odczytu, jeśli wystąpienie jest aktualnym geo-pomocniczym) zostanie przeniesiony do nowego klastra wirtualnego.
W bieżącym projekcie operacji skalowania rekordy DNS nasłuchującego są usuwane z pochodzącego klastra wirtualnego, zanim nastąpi pełna migracja wystąpienia zarządzanego SQL do nowego klastra wirtualnego. W niektórych sytuacjach ten projekt prowadzi do dłuższego czasu, w którym nie można rozpoznać adresu IP wystąpienia przy użyciu odbiornika. W tym czasie klient SQL próbujący uzyskać dostęp do wystąpienia, które jest skalowane, przy użyciu punktu końcowego listenera może oczekiwać błędów logowania z następującym komunikatem o błędzie:
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
Problem zostanie rozwiązany przez przeprojektowanie operacji skalowania.
Tabela ręcznego tworzenia kopii zapasowych w witrynie msdb nie zachowuje nazwy użytkownika
(Rozwiązano w sierpniu 2023 r.) Niedawno wprowadzona obsługa automatycznych kopii zapasowych w programie msdb obecnie nie zawiera informacji o nazwie użytkownika.
W przypadku korzystania z uwierzytelniania SQL Server nazwy użytkowników z adresem "@" nie są obsługiwane
Nazwy użytkowników zawierające symbol @ w środku (na przykład abc@xy) nie mogą się zalogować przy użyciu uwierzytelniania SQL Server.
Przywracanie ręcznej kopii zapasowej bez CHECKSUM może się nie powieść
(Rozwiązano w czerwcu 2020 r.) W pewnych okolicznościach przywracanie ręcznej kopii zapasowej baz danych, które wykonano w wystąpieniu zarządzanym SQL bez CHECKSUM, może zakończyć się niepowodzeniem. W takich przypadkach ponów próbę przywrócenia kopii zapasowej do momentu pomyślnego zakończenia.
Obejście: Wykonaj ręczne kopie zapasowe baz danych w wystąpieniach zarządzanych SQL z włączonym CHECKSUM.
Uprawnienia do grupy zasobów nie są stosowane do SQL Managed Instance
Zastosowanie roli współautora SQL Managed Instance Azure do grupy zasobów (RG) nie ma zastosowania do SQL Managed Instance i nie ma żadnego wpływu.
Workaround: Konfigurowanie roli współautora SQL Managed Instance dla użytkowników na poziomie subskrypcji.
Wprowadzający w błąd komunikat o błędzie w portalu Azure sugerujący odtworzenie Service Principal
Strona Active Directory admin portalu Azure dla Azure SQL Managed Instance może wyświetlić następujący komunikat o błędzie, mimo że jednostka usługi już istnieje:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Ten komunikat o błędzie można pominąć, jeśli podmiot usługi dla zarządzanego wystąpienia SQL już istnieje i/lub uwierzytelnianie Microsoft Entra w zarządzanym wystąpieniu SQL działa.
Aby sprawdzić, czy jednostka usługi istnieje, przejdź do strony Enterprise applications w portalu Azure, wybierz pozycję Managed Identities z listy rozwijanej Application type z listy rozwijanej wybierz pozycję Apply i wpisz nazwę wystąpienia zarządzanego SQL w polu wyszukiwania. Jeśli nazwa wystąpienia jest wyświetlana na liście wyników, jednostka usługi już istnieje i nie są potrzebne żadne dalsze działania.
Jeśli już wykonano instrukcje z komunikatu o błędzie i wybrano link, główny obiekt usługi zarządzanego wystąpienia SQL został ponownie utworzony. W takim przypadku przypisz uprawnienia do odczytu Microsoft Entra ID nowo utworzonemu Obiektowi usługi, aby uwierzytelnianie Microsoft Entra działało prawidłowo. Możesz również uruchomić ten krok z Azure PowerShell, wykonując czynności opisane w instrukcje.
Obiekt docelowy event_file sesji zdarzeń system_health nie jest dostępny
(Częściowo rozwiązane w maju 2025 r.) Podczas próby odczytania zawartości event_file elementu docelowego system_health sesji zdarzeń zostanie wyświetlony błąd 40538 "Prawidłowy adres URL rozpoczynający się od https:// jest wymagany jako wartość dla każdej określonej ścieżki plików".
Pierwotnie ten problem wystąpił w programie SQL Server Management Studio (SSMS) lub podczas odczytywania danych sesji przy użyciu funkcji sys.fn_xe_file_target_read_file.
W maju 2025 r. ten problem został rozwiązany w celu odczytywania danych sesji z programu SSMS. Problem nie został rozwiązany podczas odczytywania danych zdarzeń przy użyciu sys.fn_xe_file_target_read_file funkcji .
Ta zmiana zachowania jest niezamierzoną konsekwencją wymaganej poprawki zabezpieczeń. Ten problem można obejść, tworząc własny odpowiednik sesji system_health z użyciem event_file jako docelowej w Azure Blob Storage. Aby uzyskać więcej informacji, w tym skrypt języka T-SQL do utworzenia sesji system_health, który można zmodyfikować, aby utworzyć własny odpowiednik system_health, zobacz Używanie sesji system_health.
Okna dialogowe między bazami danych usługi Service Broker wymagają ponownego zainicjowania po uaktualnieniu warstwy usługi
(Rozwiązano w styczniu 2020 r.) Dialogi Service Broker między bazami danych przestają dostarczać komunikaty do usług w innych bazach danych po operacji zmiany poziomu usługi. Komunikaty nie zostaną utracone i można je znaleźć w kolejce nadawcy. Każda zmiana liczby rdzeni wirtualnych vCores lub rozmiaru magazynu wystąpień w usłudze SQL Managed Instance powoduje zmianę wartości service_broke_guid w widoku sys.databases dla wszystkich baz danych. Każda DIALOG utworzona przy użyciu instrukcji BEGIN DIALOG, która odnosi się do Service Brokerów w innych bazach danych, przestaje wysyłać komunikaty do usługi docelowej.
Obejście: Zatrzymaj wszelkie działania wykorzystujące dialogi między bazami danych usługi Service Broker przed zaktualizowaniem warstwy usługi, a następnie je ponownie zainicjuj. Jeśli komunikaty niedostarczone pozostaną po zmianie warstwy usługi, odczytaj komunikaty z kolejki źródłowej i wyślij je ponownie do kolejki docelowej.
Współtworzenie zawartości
Aby współtworzyć dokumentację Azure SQL, zobacz przewodnik współautora Docs.
Powiązana zawartość
Aby uzyskać listę aktualizacji i ulepszeń SQL Managed Instance, zobacz SQL Managed Instance aktualizacje usługi.
Aby uzyskać informacje o aktualizacjach i ulepszeniach wszystkich usług Azure, zobacz aktualizacje usługi Usługi.