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
Jeśli przeprowadzasz migrację bazy danych do Azure SQL Managed Instance z SQL Server 2019 lub nowszych wersji z włączonym przyspieszonym odzyskiwaniem bazy danych, ale magazyn wersji trwałej (PVS) jest skonfigurowany na inny niż PRIMARY grupę plików, możesz napotkać błędy podczas operacji przywracania w docelowym wystąpieniu zarządzanym SQL.
Aby obejść ten problem, przed przeprowadzeniem migracji do usługi SQL Managed Instance upewnij się, że magazyn wersji trwałej (PVS) ma wartość PRIMARY w źródłowej bazie danych programu SQL Server. Jeśli baza danych została już zmigrowana bez ustawienia PVS na PRIMARY, możesz ustawić ją w źródłowej bazie danych programu SQL Server, a następnie ponownie przeprowadzić migrację bazy danych do usługi SQL Managed Instance.
Nie można użyć przyspieszonego odzyskiwania bazy danych po migracji do usługi SQL Managed Instance
Począwszy od programu SQL Server 2019, jeśli migrujesz bazę danych do usługi Azure SQL Managed Instance, a źródłowa baza danych ma wyłączone przyspieszone odzyskiwanie bazy danych, nie można użyć przyspieszonego odzyskiwania bazy danych w docelowym wystąpieniu zarządzanym SQL.
Aby obejść ten problem, przed przeprowadzeniem migracji do usługi SQL Managed Instance upewnij się, że włączono przyspieszone odzyskiwanie bazy danych w źródłowej bazie danych programu SQL Server. 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 programu SQL Server, a następnie ponownie zmigrować bazę danych do wystąpienia zarządzanego SQL.
Program SQL Server 2017 i starsze wersje nie obsługują przyspieszonego odzyskiwania bazy danych, więc ten problem nie dotyczy baz danych migrowanych z tych wersji programu SQL Server.
Nie można użyć usługi Service Broker po przeprowadzeniu migracji do usługi SQL Managed Instance
Jeśli migrujesz bazę danych do usługi Azure SQL Managed Instance, a usługa Service Broker jest wyłączona w źródłowej bazie danych, nie możesz użyć usługi Service Broker w docelowym wystąpieniu zarządzanym SQL.
Aby obejść ten problem, przed migracją do usługi SQL Managed Instance upewnij się, że włączono usługę Service Broker w źródłowej bazie danych programu 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 programu SQL Server, a następnie ponownie zmigrować bazę danych do usługi SQL Managed Instance.
Modyfikowanie okresu przechowywania kopii zapasowych dla bezpłatnej oferty
Zasady przechowywania kopii zapasowych Twoich baz danych w bezpłatnym zarządzanym wystąpieniu SQL można modyfikować tylko przy użyciu REST API, PowerShell lub poleceń 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 repliką pomocniczą tylko do odczytu w grupie failover lub bazą danych replikowaną za pośrednictwem linku 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
Możesz zobaczyć następujący błąd podczas uruchamiania polecenia DBCC CHECKDB w bazie danych SQL Server 2022 po usunięciu indeksu lub tabeli z indeksem. Baza danych pochodzi z Azure SQL Managed Instance, na przykład po przywróceniu pliku kopii zapasowej lub z 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ą firmy 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.
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 rozwiązać 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 główną usługą, służącą 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 usługa SQL Managed Instance nie zezwalają użytkownikowi na usuwanie 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 w repliki pomocniczej z możliwością odczytu wymaga ponownej konfiguracji po przejściu w tryb failover
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ągnie limit Azure Storage warstwy usługi ogólnego przeznaczenia, ale nie uaktualnienia do warstwy usługi nowej generacji ogólnego przeznaczenia lub warstwy usługi krytycznej dla działania firmy.
Każde wystąpienie usługi SQL Managed Instance klasy Ogólnego przeznaczenia ma do 35 TB magazynu zarezerwowanego na miejsce na dysku 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 całkowita suma rozmiarów dysków Azure Premium nie może przekroczyć 35 TB. W niektórych przypadkach zarządzane wystąpienie SQL, które nie wymaga łącznie 8 TB, może przekroczyć limit Azure dotyczący rozmiaru magazynu 35 TB z powodu fragmentacji wewnętrznej.
Na przykład instancja General Purpose SQL Managed Instance może zawierać 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 specyficzny rozkład plików, wystąpienie SQL Managed Instance może osiągnąć limit 35 TB zarezerwowany dla dołączonego dysku Azure Premium, kiedy można tego nie oczekiwać.
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 a Azure SQL Managed Instance, automatyczne pełne i transakcyjne kopie zapasowe są wykonywane na zarządzanym wystąpieniu SQL, niezależnie od tego, czy jest ono 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
Azure SQL Managed Instance tworzy systemowe dane logowania do celów replikacji transakcyjnej. Ten identyfikator logowania można znaleźć w programie SSMS (w Object Explorer>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.
Logowania i użytkownicy Microsoft Entra nie są obsługiwani w programie SSDT.
SQL Server Data Tools nie w pełni obsługują loginy i użytkowników Microsoft Entra.
Personifikacja typów logowania Microsoft Entra nie jest obsługiwana
Personifikacja przy użyciu EXECUTE AS USER lub EXECUTE AS LOGIN nie jest obsługiwana dla następujących zasad Microsoft Entra:
- Aliasowani użytkownicy Microsoft Entra. W tym przypadku operacja zwraca błąd
15517. - Logowanie do Microsoft Entra i użytkownicy na podstawie aplikacji Microsoft Entra lub podmiotów usługi. W tym przypadku operacja zwraca błędy
15517i15406.
Replikacja transakcyjna musi zostać ponownie skonfigurowana po awarii geograficznej
Jeśli włączysz replikację transakcyjną w bazie danych znajdującej się w grupie trybu failover, administrator SQL Managed Instance musi usunąć wszystkie publikacje z poprzedniego serwera podstawowego i ponownie je skonfigurować na nowym serwerze podstawowym po wystąpieniu przełączenia awaryjnego 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
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. Firma Microsoft opublikowała powiązane aktualizacje Windows w lutym i marcu 2025 r.. Wystąpienia zarządzane SQL korzystające z objętej strefy czasowej odzwierciedlają tę zmianę i są 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 wpływa na SQL Managed Instance i nie ma żadnego skutku.
Workaround: Konfigurowanie roli współautora SQL Managed Instance dla użytkowników na poziomie subskrypcji.
Błędny komunikat o błędzie w portalu Azure sugerujący odtworzenie podmiotu usługi
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 zlekceważyć, jeśli główny użytkownik usługi dla zarządzanego wystąpienia SQL już istnieje i/lub uwierzytelnianie Microsoft Entra działa w zarządzanym wystąpieniu SQL.
Aby sprawdzić, czy jednostka usługi istnieje, przejdź do strony Enterprise applications w portalu Azure, wybierz pozycję Managed Identities z listy rozwijanej Application type, kliknij 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 do nowo utworzonej głównej jednostki 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 event_file docelowym 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 rozmiaru rdzeni wirtualnych lub magazynu wystąpień w SQL Managed Instance powoduje zmianę wartości service_broke_guid w sys.databases widoku 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 przyczynić się do tworzenia dokumentacji Azure SQL, zapoznaj się z przewodnikiem dla współautorów 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.