Znane problemy z usługą Azure SQL Managed Instance
Dotyczy: 
Azure SQL Managed Instance
W tym artykule wymieniono obecnie znane problemy z usługą Azure SQL Managed Instance oraz datą rozwiązania lub możliwym obejściem. Aby dowiedzieć się więcej o usłudze Azure SQL Managed Instance, zobacz Co to jest usługa Azure SQL Managed Instance? i Co nowego w usłudze Azure SQL Managed Instance?
Uwaga
Microsoft Entra ID był wcześniej znany jako Azure Active Directory (Azure AD).
Znane problemy
Ma obejście
Lista długoterminowych kopii zapasowych w witrynie Azure Portal zawiera pliki kopii zapasowej dla aktywnych i usuniętych baz danych o tej samej nazwie
Długoterminowe kopie zapasowe można wyświetlać na stronie witryny Azure Portal i zarządzać nimi dla usługi Azure SQL Managed Instance na karcie Kopie zapasowe. Strona zawiera listę aktywnych lub usuniętych baz danych, podstawowe informacje o ich długoterminowych kopiach zapasowych i link do zarządzania kopiami zapasowymi. Po wybraniu linku Zarządzaj zostanie otwarte nowe okienko boczne z listą kopii zapasowych. Ze względu na problem z logiką filtrowania lista zawiera kopie zapasowe zarówno dla aktywnej bazy danych, jak i usuniętych baz danych o tej samej nazwie. Wymaga to szczególnej uwagi podczas wybierania kopii zapasowych do usunięcia, aby uniknąć usuwania kopii zapasowych dla nieprawidłowej bazy danych.
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óra istniała w wystąpieniu 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 dla bazy danych.
Obiekt docelowy event_file sesji zdarzeń system_health jest niedostępny
Podczas próby odczytania zawartości event_file docelowej 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. Dzieje się tak w programie SQL Server Management Studio lub podczas odczytywania danych sesji przy użyciu funkcji sys.fn_xe_file_target_read_file .
Ta zmiana zachowania jest niezamierzoną konsekwencją niedawnej wymaganej poprawki zabezpieczeń. Badamy wykonalność dodatkowej zmiany, która umożliwiłaby klientom bezpieczne korzystanie z system_health sesji w usłudze Azure SQL Managed Instance. W międzyczasie klienci mogą obejść ten problem, tworząc własny odpowiednik system_health sesji z obiektem event_file docelowym w usłudze Azure Blob Storage. Aby uzyskać więcej informacji, w tym skrypt języka T-SQL w celu utworzenia sesji, którą można zmodyfikować w celu utworzenia system_health własnego odpowiednika system_healthprogramu , zobacz Use the system_health session (Używanie sesji system_health).
Procedura sp_send_dbmail może zakończyć się niepowodzeniem, gdy @query parametr
Procedura sp_send_dbmail może zakończyć się niepowodzeniem w przypadku @query użycia parametru. Błędy występują, gdy procedura składowana jest wykonywana na koncie sysadmin.
Ten problem jest spowodowany przez znaną usterkę związaną z używaniem sp_send_dbmail personifikacji.
Obejście: Upewnij się, że wywołasz konto sp_send_dbmail niestandardowe w ramach utworzonego konta niestandardowego, a nie w obszarze konta sysadmin.
Oto przykład tworzenia dedykowanego konta i modyfikowania istniejących obiektów wysyłających wiadomości e-mail za pośrednictwem usługi 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
EXEC 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.
EXEC 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
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO
Tymczasowe wskazówki dotyczące aktualizacji strefy czasowej 2022 dla Chile
8 sierpnia 2022 r. chilijski rząd ogłosił oficjalne ogłoszenie o zmianie strefy czasowej czasu letniego (DST). Począwszy od 12:00 w sobotę, 10 września 2022 r., do 12:00 w sobotę, 1 kwietnia 2023 r., oficjalny czas przejdzie 60 minut. Zmiana dotyczy następujących trzech stref czasowych: Pacyfik SA (czas standardowy), Easter Island (Czas standardowy) i Magallanes (czas standardowy). Usługi Azure SQL Managed Instances korzystające ze stref czasowych, których dotyczy problem, nie odzwierciedlają zmian , dopóki firma Microsoft nie wyda aktualizacji systemu operacyjnego w celu jej obsługi, a usługa Azure SQL Managed Instance pochłania aktualizację na poziomie systemu operacyjnego.
Obejście: Jeśli musisz zmienić strefy czasowe dla wystąpień zarządzanych, pamiętaj o ograniczeniach i postępuj zgodnie ze wskazówkami z dokumentacji.
Zmiana typu połączenia nie ma wpływu na połączenia za pośrednictwem punktu końcowego grupy trybu failover
Jeśli wystąpienie uczestniczy w grupie trybu failover, zmiana typu połączenia wystąpienia nie będzie obowiązywać dla połączeń ustanowionych za pośrednictwem punktu końcowego odbiornika grupy trybu failover.
Obejście: Upuść i utwórz ponownie grupę trybu failover po zmianie typu połączenia.
Procedura sp_send_dbmail może zakończyć się przejściowym niepowodzeniem w przypadku @query użycia parametru
Procedura sp_send_dbmail może ulec przejściowej awarii, gdy @query jest używany parametr. W przypadku wystąpienia tego problemu co drugie wykonanie procedury sp_send_dbmail kończy się niepowodzeniem z błędem Msg 22050, Level 16, State 1 i komunikatem Failed to initialize sqlcmd library with error number -2147467259. Aby można było prawidłowo zobaczyć ten błąd, należy wywołać procedurę z wartością domyślną 0 dla parametru @exclude_query_output. W przeciwnym razie błąd nie jest propagowany.
Ten problem jest spowodowany przez znaną usterkę związaną z używaniem sp_send_dbmail personifikacji i buforowania połączeń.
Aby obejść ten problem, zawijaj kod wysyłania wiadomości e-mail do logiki ponawiania, która opiera się na parametrze @mailitem_idwyjściowym . Jeśli wykonanie zakończy się niepowodzeniem, wartość parametru ma wartość NULL, co wskazuje sp_send_dbmail , że powinna zostać wywołana jeszcze raz, aby pomyślnie wysłać wiadomość e-mail. Oto przykład logiki ponawiania prób:
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
Transakcje rozproszone można wykonywać po usunięciu wystąpienia zarządzanego z grupy zaufania serwera
Grupy zaufania serwera służą do ustanawiania zaufania między wystąpieniami zarządzanymi, które są wymaganiami wstępnymi dotyczącymi wykonywania transakcji rozproszonych. Po usunięciu wystąpienia zarządzanego z grupy zaufania serwera lub usunięciu grupy nadal może być możliwe wykonanie transakcji rozproszonych. Istnieje obejście problemu, które można zastosować, aby upewnić się, że transakcje rozproszone są wyłączone i że ręczne przełączanie w tryb failover inicjowane przez użytkownika w wystąpieniu zarządzanym.
Transakcje rozproszone nie mogą być wykonywane po operacji skalowania wystąpienia zarządzanego
Operacje skalowania usługi SQL Managed Instance, które obejmują zmianę warstwy usługi lub liczby rdzeni wirtualnych, zresetują ustawienia grupy zaufania serwera na zapleczu i wyłączą uruchamianie transakcji rozproszonych. Aby obejść ten problem, usuń i utwórz nową grupę zaufania serwera w witrynie Azure Portal.
Nie można utworzyć wystąpienia zarządzanego SQL o takiej samej nazwie jak wcześniej usunięty serwer logiczny
Rekord DNS jest <name>.database.windows.com tworzony podczas tworzenia serwera logicznego na platformie Azure dla usługi Azure SQL Database oraz podczas tworzenia wystąpienia zarządzanego SQL. Rekord DNS musi być unikatowy. W związku z tym, jeśli utworzysz serwer logiczny dla usługi SQL Database, a następnie usuniesz go, istnieje okres progowy z siedmiu dni przed zwolnieniem nazwy z rekordów. W tym okresie nie można utworzyć wystąpienia zarządzanego SQL o tej samej nazwie co usunięty serwer logiczny. Aby obejść ten problem, użyj innej nazwy wystąpienia zarządzanego SQL lub utwórz bilet pomocy technicznej, aby zwolnić nazwę serwera logicznego.
Jednostka usługi nie może uzyskać dostępu do identyfikatora Entra firmy Microsoft i usługi AKV
W niektórych okolicznościach może wystąpić problem z jednostką usługi używaną do uzyskiwania dostępu do usługi Microsoft Entra ID (dawniej Azure Active Directory) i usług Azure Key Vault (AKV). W rezultacie ten problem ma wpływ na użycie uwierzytelniania w usłudze Microsoft Entra i przezroczystego szyfrowania danych (TDE) za pomocą usługi SQL Managed Instance. Może to wystąpić jako sporadyczne problemy z łącznością lub nie można uruchomić 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 w nowym wystąpieniu zarządzanym azure SQL może również nie działać w pewnych okolicznościach.
Obejście: Aby zapobiec wystąpieniu tego problemu w wystąpieniu zarządzanym SQL, przed wykonaniem jakichkolwiek poleceń aktualizacji lub w przypadku, gdy ten problem wystąpił już po zaktualizowaniu poleceń, przejdź do strony Przegląd wystąpienia zarządzanego SQL w witrynie Azure Portal. W obszarze Ustawienia wybierz pozycję Microsoft Entra ID, aby uzyskać dostęp do strony administratora wystąpienia zarządzanego SQL Microsoft Entra ID. Sprawdź, czy widzisz komunikat o błędzie "Wystąpienie zarządzane wymaga jednostki usługi, aby uzyskać dostęp do identyfikatora Entra firmy Microsoft. Kliknij tutaj, aby utworzyć jednostkę usługi". W przypadku napotkania tego komunikatu o błędzie wybierz go i postępuj zgodnie z podanymi instrukcjami krok po kroku, dopóki ten błąd nie zostanie rozwiązany.
Ograniczenie ręcznego przechodzenia w tryb failover za pośrednictwem portalu dla grup trybu failover
Jeśli grupa trybu failover obejmuje wiele wystąpień w różnych subskrypcjach platformy Azure lub grupach zasobów, ręczne przejście w tryb failover nie może być inicjowane z wystąpienia podstawowego w grupie trybu failover.
Obejście: Zainicjuj tryb failover za pośrednictwem portalu z wystąpienia pomocniczego obszaru geograficznego.
Role agenta SQL wymagają jawnych uprawnień do wykonywania w przypadku identyfikatorów logowania innych niż sysadmin
Jeśli do jakichkolwiek stałych ról bazy danych agenta SQL dodano identyfikatory logowania inne niż administrator systemu, istnieje problem polegający na tym, że jawne uprawnienia EXECUTE muszą zostać przyznane trzem procedurom składowanymi w master bazie danych, aby te identyfikatory logowania działały. Jeśli ten problem zostanie napotkany, zostanie wyświetlony komunikat The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) o błędzie.
Obejście: Po dodaniu identyfikatorów logowania do stałej roli bazy danych agenta SQL (SQLAgentUserRole, SQLAgentReaderRole lub SQLAgentOperatorRole) dla każdego z identyfikatorów logowania dodanych do tych ról wykonaj następujący skrypt języka T-SQL, aby jawnie udzielić uprawnień EXECUTE do wymienionych procedur składowanych.
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
Limity pamięci OLTP w pamięci nie są stosowane
Warstwa usługi Krytyczne dla działania firmy nie stosuje poprawnie maksymalnych limitów pamięci dla obiektów zoptymalizowanych pod kątem pamięci w niektórych przypadkach. Wystąpienie zarządzane SQL może umożliwić obciążeniu użycie większej ilości pamięci dla operacji OLTP w pamięci, co może mieć wpływ na dostępność i stabilność wystąpienia. Zapytania OLTP w pamięci, które osiągają limity, mogą nie zakończyć się natychmiast niepowodzeniem. Zapytania korzystające z większej ilości pamięci OLTP w pamięci kończą się niepowodzeniem wcześniej, jeśli osiągną limity.
Obejście: Monitoruj użycie magazynu OLTP w pamięci przy użyciu programu SQL Server Management Studio, aby upewnić się, że obciążenie nie korzysta z więcej niż dostępnej pamięci. Zwiększ limity pamięci, które zależą od liczby rdzeni wirtualnych, lub zoptymalizuj obciążenie, aby używać mniejszej ilości pamięci.
Wystąpił nieprawidłowy błąd podczas próby usunięcia pliku, który nie jest pusty
Programy SQL Server i SQL Managed Instance nie zezwalają użytkownikowi na usunięcie pliku, który nie jest pusty. Jeśli spróbujesz usunąć nieistniejący plik danych przy użyciu ALTER DATABASE REMOVE FILE instrukcji , błąd Msg 5042 – The file '<file_name>' cannot be removed because it is not empty nie zostanie natychmiast zwrócony. Wystąpienie zarządzane SQL będzie nadal próbowało usunąć plik, a operacja zakończy się niepowodzeniem po 30 minutach.Internal server error
Zmiana warstwy usługi i operacje tworzenia wystąpienia są blokowane przez trwające przywracanie bazy danych
Bieżąca RESTORE instrukcja, proces migracji usługi Data Migration Service i wbudowane przywracanie do punktu w czasie, zablokuje aktualizowanie warstwy usługi lub zmianę rozmiaru istniejącego wystąpienia i tworzenie nowych wystąpień do momentu zakończenia procesu przywracania.
Proces przywracania blokuje te operacje w wystąpieniach zarządzanych i pulach wystąpień w tej samej podsieci, w której jest uruchomiony proces przywracania. Nie ma to wpływu na wystąpienia w pulach wystąpień. 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: Zaczekaj na zakończenie procesu przywracania lub anuluj proces przywracania, jeśli operacja tworzenia lub aktualizacji warstwy usługi ma wyższy priorytet.
Zarządca zasobów w warstwie usługi Krytyczne dla działania firmy może być konieczne ponowne skonfigurowanie po przejściu w tryb failover
Funkcja Zarządca zasobów, która umożliwia ograniczenie zasobów przypisanych do obciążenia użytkownika, może niepoprawnie sklasyfikować obciążenie użytkownika po przejściu w tryb failover lub zmianie warstwy usługi zainicjowanej przez użytkownika (na przykład zmiana maksymalnego rozmiaru rdzeni wirtualnych lub maksymalnego rozmiaru magazynu wystąpień).
Obejście: Uruchamiaj ALTER RESOURCE GOVERNOR RECONFIGURE okresowo lub w ramach zadania agenta SQL, które wykonuje zadanie SQL, gdy wystąpienie jest uruchamiane, jeśli używasz zarządcy zasobów.
Okna dialogowe brokera usług między bazami danych muszą zostać ponownie zainicjowane po uaktualnieniu warstwy usługi
Okna dialogowe usługi Service Broker między bazami danych przestaną dostarczać komunikaty do usług w innych bazach danych po zmianie operacji warstwy usług. Komunikaty nie zostaną utracone i można je znaleźć w kolejce nadawcy. Każda zmiana rozmiaru rdzeni wirtualnych lub magazynu wystąpień w usłudze SQL Managed Instance powoduje zmianę service_broke_guid wartości w widoku sys.databases dla wszystkich baz danych. Każda DIALOG utworzona przy użyciu instrukcji BEGIN DIALOG odwołującej się do usługi Service Brokers w innej bazie danych przestaje dostarczać komunikaty do usługi docelowej.
Obejście: Zatrzymaj wszelkie działania korzystające z konwersacji dialogowych między bazami danych usługi Service Broker przed zaktualizowaniem warstwy usługi i zainicjuj je później. Jeśli po zmianie warstwy usługi istnieją pozostałe komunikaty, które nie zostały spełnione, odczytaj komunikaty z kolejki źródłowej i wyślij je ponownie do kolejki docelowej.
Przekraczanie rozmiaru przestrzeni dyskowej w przypadku małych plików bazy danych
CREATE DATABASEinstrukcje , ALTER DATABASE ADD FILEi RESTORE DATABASE mogą zakończyć się niepowodzeniem, ponieważ wystąpienie może osiągnąć limit usługi Azure Storage.
Każde wystąpienie ogólnego przeznaczenia usługi SQL Managed Instance ma do 35 TB miejsca na dysku w warstwie Premium platformy Azure. 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. Nieużywane miejsce na dysku nie jest obciążane opłatą, ale łączna suma rozmiarów dysków platformy Azure w warstwie Premium nie może przekroczyć 35 TB. Z powodu fragmentacji wewnętrznej wystąpienie zarządzane, które nie wymaga łącznie 8 TB, może w niektórych przypadkach przekroczyć limit przestrzeni dyskowej platformy Azure wynoszący 35 TB.
Na przykład wystąpienie ogólnego przeznaczenia usługi SQL Managed Instance może mieć jeden duży plik o rozmiarze 1,2 TB umieszczonym 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 usługi SQL Managed Instance może osiągnąć limit 35 TB zarezerwowany dla dołączonego dysku Azure Premium Disk, gdy może się tego nie spodziewać.
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 utworzyć ani przywrócić 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 w tym przypadku 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 XEvents i wpisów dziennika błędów wyświetla identyfikatory bazy danych identyfikatorów GUID 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 usłudze SQL Managed Instance i połączone serwery lub zapytania rozproszone odwołujące się do bieżącego wystąpienia czasami nie mogą rozpoznać adresu IP wystąpienia lokalnego. Ten błąd jest przejściowym problemem.
Zakres transakcji w dwóch bazach danych w tym samym wystąpieniu nie jest obsługiwany
(Rozwiązano w marcu 2020 r.) Klasa TransactionScope na platformie .NET nie działa, jeśli dwa zapytania są wysyłane do dwóch baz danych w tym samym wystąpieniu w tym samym zakresie transakcji:
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=<password>;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
Obejście problemu (nie jest wymagane od marca 2020 r.): Użyj polecenia SqlConnection.ChangeDatabase(String), aby użyć innej bazy danych w kontekście połączenia zamiast używania dwóch połączeń.
Brak rozwiązania
Różnicowe kopie zapasowe nie są wykonywane, gdy wystąpienie jest połączone z programem SQL Server
Podczas konfigurowania połączenia między programem SQL Server i usługą Azure SQL Managed Instance automatyczne kopie zapasowe dzienników pełnych i transakcyjnych są wykonywane na wystąpieniu zarządzanym, niezależnie od tego, czy znajduje się on w roli podstawowej. Jednak różnicowe kopie zapasowe nie są obecnie wykonywane, gdy mogą 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 identyfikator logowania systemu do celów replikacji transakcyjnej. Ten identyfikator logowania można znaleźć w programie SSMS (w Eksploratorze obiektów w obszarze Zabezpieczenia, Identyfikatory logowania) lub w widoku sys.sysloginssystemowym . 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 z powodu błędu w poprzednim logowaniu systemu nie zostanie usunięty. Może to prowadzić do zwiększenia liczby logowań. Te identyfikatory logowania nie reprezentują zagrożenia bezpieczeństwa. Można je bezpiecznie zignorować. Te identyfikatory logowania nie powinny być usuwane, ponieważ co najmniej jeden z nich jest używany do replikacji transakcyjnej.
Identyfikatory logowania i użytkownicy usługi Microsoft Entra nie są obsługiwane w programie SSDT
Narzędzia SQL Server Data Tools nie obsługują w pełni identyfikatorów logowania i użytkowników firmy Microsoft.
Personifikacja typów logowania entra firmy Microsoft nie jest obsługiwana
Personifikacja przy użyciu lub EXECUTE AS USER EXECUTE AS LOGIN następujących podmiotów zabezpieczeń firmy Microsoft Entra nie jest obsługiwana:
- Aliasowani użytkownicy firmy Microsoft Entra. W tym przypadku zwracany jest następujący błąd:
15517. - Identyfikatory logowania i użytkownicy firmy Microsoft Entra są oparte na aplikacjach firmy Microsoft lub jednostkach usługi. W tym przypadku zwracane są następujące błędy:
15517i15406.
Replikacja transakcyjna musi zostać ponownie skonfigurowana po przejściu w tryb failover geograficznie
Jeśli replikacja transakcyjna jest włączona w bazie danych w grupie trybu failover, administrator usługi SQL Managed Instance musi wyczyścić wszystkie publikacje w starym podstawowym i ponownie skonfigurować je w nowym podstawowym po przejściu w tryb failover do innego regionu. Aby uzyskać więcej informacji, zobacz Replikacja.
tempdb struktura i zawartość jest tworzona ponownie
Baza tempdb danych jest zawsze podzielona na 12 plików danych, a nie można zmienić struktury plików. Nie można zmienić maksymalnego rozmiaru pliku i nie można dodać nowych plików do tempdbprogramu . Baza tempdb danych jest zawsze tworzona ponownie jako pusta baza danych, gdy wystąpienie uruchamia się lub przechodzi w tryb failover, a wszelkie zmiany wprowadzone w tempdb programie nie są zachowywane.
Dzienniki błędów nie są utrwalane
Dzienniki błędów, które są dostępne w usłudze 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. W historii dziennika błędów mogą występować luki, ponieważ wystąpienie zarządzane SQL zostało przeniesione kilka razy na kilku maszynach wirtualnych.
Tymczasowa niedostępność wystąpienia przy użyciu odbiornika grupy trybu failover podczas operacji skalowania
Skalowanie wystąpienia zarządzanego czasami wymaga przeniesienia wystąpienia do innego klastra wirtualnego wraz ze skojarzonymi rekordami DNS obsługiwanymi przez usługę. Jeśli wystąpienie zarządzane uczestniczy w grupie trybu failover, rekord DNS odpowiadający skojarzonemu odbiornikowi grupy trybu failover (odbiornikowi odczytu i zapisu, jeśli wystąpienie jest bieżącym odbiornikiem tylko do odczytu geograficznego, jeśli wystąpienie jest bieżącym pomocniczym obszarem geograficznym) zostanie przeniesione do nowego klastra wirtualnego.
W bieżącym projekcie operacji skalowania rekordy DNS odbiornika są usuwane z klastra wirtualnego źródłowego, zanim wystąpienie zarządzane zostanie w pełni zmigrowane do nowego klastra wirtualnego, co w niektórych sytuacjach może prowadzić do dłuższego czasu, w którym adres IP wystąpienia nie może zostać rozwiązany przy użyciu odbiornika. W tym czasie klient SQL próbujący uzyskać dostęp do skalowanego wystąpienia przy użyciu punktu końcowego odbiornika może oczekiwać niepowodzeń logowania z następującym komunikatem o błędzie: "Błąd 40532: Nie można otworzyć serwera "xxx.xxx.xxx.xxx" żądanego podczas logowania. Logowanie nie powiodło się. (Microsoft SQL Server, błąd: 40532)".
Problem zostanie rozwiązany przez przeprojektowanie operacji skalowania.
Resolved
Tabela ręcznego tworzenia kopii zapasowych w witrynie msdb nie zachowuje nazwy użytkownika
(Rozwiązano w sierpniu 2023 r.) Niedawno wprowadziliśmy obsługę automatycznych kopii zapasowych w programie msdb, ale tabela nie zawiera obecnie informacji o nazwie użytkownika.
Zapytanie w tabeli zewnętrznej kończy się niepowodzeniem z komunikatem o błędzie nieobsługiwanymi
Wykonywanie zapytań względem tabeli zewnętrznej może zakończyć się niepowodzeniem z ogólnym komunikatem o błędzie "Zapytania dotyczące tabel zewnętrznych nie są obsługiwane z bieżącą warstwą usługi lub poziomem wydajności tej bazy danych. Rozważ wybór wyższej warstwy usługi lub poziomu wydajności bazy danych”. Jedynym typem tabeli zewnętrznej obsługiwanym w usłudze Azure SQL Managed Instance są tabele zewnętrzne polyBase (w wersji zapoznawczej). Aby zezwolić na zapytania w tabelach zewnętrznych programu PolyBase, należy włączyć program PolyBase w wystąpieniu zarządzanym, uruchamiając sp_configure polecenie .
Tabele zewnętrzne powiązane z funkcją Elastic Query usługi Azure SQL Database nie są obsługiwane w usłudze SQL Managed Instance, ale tworzenie i wykonywanie zapytań nie zostało jawnie zablokowane. Dzięki obsłudze tabel zewnętrznych polyBase wprowadzono nowe kontrole, blokując wykonywanie zapytań dowolnego typu tabeli zewnętrznej w wystąpieniu zarządzanym, chyba że technologia PolyBase jest włączona.
Jeśli używasz nieobsługiwanych tabel zewnętrznych Elastic Query do wykonywania zapytań dotyczących danych w usłudze Azure SQL Database lub Azure Synapse z wystąpienia zarządzanego, zamiast tego należy użyć funkcji serwera połączonego. Aby nawiązać połączenie serwera połączonego z wystąpienia zarządzanego SQL do usługi SQL Database, postępuj zgodnie z instrukcjami z tego artykułu. Aby ustanowić połączenie serwera połączonego z usługi SQL Managed Instance do usługi SQL Synapse, sprawdź instrukcje krok po kroku. Ponieważ konfigurowanie i testowanie połączenia serwera połączonego zajmuje trochę czasu, możesz użyć obejścia jako tymczasowego rozwiązania umożliwiającego wykonywanie zapytań dotyczących tabel zewnętrznych związanych z funkcją Elastic Query:
Obejście: Wykonaj następujące polecenia (raz na wystąpienie), które umożliwiają wykonywanie zapytań w tabelach zewnętrznych:
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
W przypadku korzystania z uwierzytelniania programu 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 programu SQL Server.
Przywracanie ręcznej kopii zapasowej bez sumy KONTROLNEj może zakończyć się niepowodzeniem
(Rozwiązano w czerwcu 2020 r.) W pewnych okolicznościach ręczne tworzenie kopii zapasowych baz danych w wystąpieniu zarządzanym bez sumy KONTROLNEj 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: Ręczne tworzenie kopii zapasowych baz danych w wystąpieniach zarządzanych z włączoną funkcją CHECKSUM.
Agent przestaje odpowiadać podczas modyfikowania, wyłączania lub włączania istniejących zadań
W pewnych okolicznościach modyfikowanie, wyłączanie lub włączanie istniejącego zadania może spowodować, że agent przestanie odpowiadać. Problem jest automatycznie ograniczany po wykryciu, co powoduje ponowne uruchomienie procesu agenta.
Uprawnienia do grupy zasobów nie są stosowane do usługi SQL Managed Instance
Gdy rola współautora wystąpienia zarządzanego SQL jest stosowana do grupy zasobów (RG), nie jest stosowana do usługi SQL Managed Instance i nie ma żadnego wpływu.
Obejście: Skonfiguruj rolę współautora wystąpienia zarządzanego SQL dla użytkowników na poziomie subskrypcji.
Zadania agenta SQL mogą zostać przerwane przez ponowne uruchomienie procesu agenta
(Rozwiązano w marcu 2020 r.) Agent SQL tworzy nową sesję za każdym razem, gdy zadanie jest uruchamiane, stopniowo zwiększając zużycie pamięci. Aby uniknąć osiągnięcia limitu pamięci wewnętrznej, co spowoduje zablokowanie wykonywania zaplanowanych zadań, proces agenta zostanie uruchomiony ponownie po osiągnięciu progu użycia pamięci. Może to spowodować przerwanie wykonywania zadań uruchomionych w momencie ponownego uruchomienia.
@query parametr nie jest obsługiwany w sp_send_db_mail
Parametr @query w procedurze sp_send_db_mail nie działa.
Mylący komunikat o błędzie w witrynie Azure Portal sugerujący odtworzenie jednostki usługi
Strona administratora usługi Active Directory w witrynie Azure Portal dla usługi Azure SQL Managed Instance może wyświetlić następujący komunikat o błędzie, mimo że jednostka usługi już istnieje:
"Wystąpienie zarządzane wymaga jednostki usługi, aby uzyskać dostęp do identyfikatora entra firmy Microsoft (dawniej Azure Active Directory). Kliknij tutaj, aby utworzyć jednostkę usługi"
Ten komunikat o błędzie można pominąć, jeśli jednostka usługi dla wystąpienia zarządzanego już istnieje i/lub uwierzytelnianie firmy Microsoft Entra w wystąpieniu zarządzanym działa.
Aby sprawdzić, czy jednostka usługi istnieje, przejdź do strony Aplikacje dla przedsiębiorstw w witrynie Azure Portal, wybierz pozycję Tożsamości zarządzane z listy rozwijanej Typ aplikacji, wybierz pozycję Zastosuj i wpisz nazwę wystąpienia zarządzanego 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 z komunikatu o błędzie, jednostka usługi wystąpienia zarządzanego została ponownie utworzona. W takim przypadku przypisz uprawnienia do odczytu identyfikatora Entra firmy Microsoft do nowo utworzonej jednostki usługi, aby uwierzytelnianie firmy Microsoft Entra działało prawidłowo. Można to zrobić za pomocą programu Azure PowerShell, postępując zgodnie z instrukcjami.
Współtworzenie zawartości
Aby współtworzyć dokumentację usługi Azure SQL, zobacz Przewodnik współautora witryny Docs.
Powiązana zawartość
Aby uzyskać listę aktualizacji i ulepszeń usługi SQL Managed Instance, zobacz Aktualizacje usługi SQL Managed Instance.
Aby uzyskać informacje o aktualizacjach i ulepszeniach wszystkich usług platformy Azure, zobacz Aktualizacje usługi.