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
Błąd 8992 podczas uruchamiania polecenia DBCC CHECKDB na bazie danych SQL Server pochodzącej z zarządzanego wystąpienia SQL.
Po uruchomieniu polecenia DBCC CHECKDB w bazie danych SQL Server 2022, po usunięciu indeksu lub tabeli z indeksem, możesz zobaczyć następujący błąd, jeśli baza danych pochodzi z usługi Azure SQL Managed Instance. Może to się zdarzyć na przykład po przywróceniu pliku kopii zapasowej lub przy wykorzystaniu funkcji linku usługi Managed Instance.
_Msg 8992, Level 16, State 1, Line <Line_Number>an
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 usłudze Azure SQL Managed Instance, a następnie przywrócić lub połączyć bazę danych z programem SQL Server 2022 ponownie. Jeśli ponowne utworzenie bazy danych ze źródłowej usługi Azure SQL Managed Instance nie jest możliwe, skontaktuj się z pomocą techniczną firmy Microsoft, aby rozwiązać ten problem.
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ó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 oraz wartości zwracanej DatabaseDeletionTime w celu filtrowania kopii zapasowych dla bazy danych.
Plik 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 sesji system_health z celem event_file w systemie 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.
Procedura sp_send_dbmail może zakończyć się niepowodzeniem, gdy @query parametr
Procedura sp_send_dbmail może zakończyć się niepowodzeniem, gdy zostanie użyty parametr @query. Błędy występują, gdy procedura składowana jest wykonywana na koncie sysadmin.
Ten problem jest spowodowany przez znaną usterkę związaną z tym, jak sp_send_dbmail używa impersonacji.
Obejście: Upewnij się, że wywołujesz sp_send_dbmail w ramach odpowiedniego konta niestandardowego, które utworzyłeś, a nie w ramach 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 zostanie przesunięty o 60 minut do przodu. 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 failover.
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.
Obejście: Usuń i utwórz ponownie grupę przełączania awaryjnego po zmianie typu połączenia.
Procedura sp_send_dbmail może przejściowo zawieść, gdy używany jest parametr @query
Procedura sp_send_dbmail może chwilowo zawieść, gdy używany jest parametr @query. 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 tym, jak sp_send_dbmail używa uwierzytelniania i buforowania połączeń.
Aby obejść ten problem, umieść kod wysyłania wiadomości e-mail w mechanizmie ponawiania, który opiera się na parametrze wyjściowym @mailitem_id. 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 instancji zarządzanej 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 z grupy zaufania serwera lub usunięciu grupy, nadal możliwe może być wykonanie transakcji rozproszonych. Istnieje obejście problemu, które można zastosować, aby upewnić się, że transakcje rozproszone są wyłączone, a także ręcznie inicjowane przez użytkownika przełączanie awaryjne na 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 <name>.database.windows.com jest tworzony, gdy tworzysz serwer logiczny w Azure dla 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 zgłoszenie do pomocy technicznej, aby zwolnić nazwę serwera logicznego.
Principal usługi nie może uzyskać dostępu do Microsoft Entra ID i Azure Key Vault.
W niektórych okolicznościach może wystąpić problem z zasadniczą usługą używaną do dostępu do 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 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 Ustawieniach wybierz Microsoft Entra ID, aby uzyskać dostęp do strony administratora Microsoft Entra ID wystąpienia zarządzanego SQL. Sprawdź, czy widzisz komunikat o błędzie "Wystąpienie zarządzane wymaga głównej usługi, aby uzyskać dostęp do Microsoft Entra ID." 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 przełączania na tryb awaryjny za pośrednictwem portalu dla grup przełączania awaryjnego
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 instancji pomocniczej obszaru geograficznego.
Role agenta SQL wymagają jawnych uprawnień do wykonywania poleceń dla logowań 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 w zakresie pamięci w niektórych przypadkach. Zarządzana instancja SQL może pozwolić obciążeniu na użycie większej ilości pamięci dla operacji OLTP z wykorzystaniem pamięci, co może wpływać na dostępność i stabilność instancji. 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 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 Data Migration Service oraz wbudowane przywracanie do punktu w czasie zablokują aktualizowanie warstwy usługi, zmianę rozmiaru istniejącego wystąpienia i tworzenie nowych wystąpień aż do 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. 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: Poczekaj na zakończenie procesu przywracania lub, jeśli operacja tworzenia lub aktualizacji warstwy usługi ma wyższy priorytet, anuluj proces przywracania.
Po przełączeniu awaryjnym może być konieczne ponowne skonfigurowanie Zarządcy zasobów w warstwie usługi krytycznej dla biznesu.
Funkcja Resource Governor, która umożliwia ograniczanie zasobów przypisanych do obciążenia użytkownika, może niepoprawnie sklasyfikować obciążenie użytkownika po awarii failover lub zmianie poziomu usług przez użytkownika (na przykład zmiana maksymalnej liczby rdzeni wirtualnych lub maksymalnej wielkości pamięci dla instancji).
Obejście: Uruchamiaj ALTER RESOURCE GOVERNOR RECONFIGURE okresowo lub w ramach zadania agenta SQL, które wykonuje zadanie SQL przy starcie instancji, jeśli używasz Menadżera Zasobów.
Okna dialogowe brokera usług między bazami danych muszą zostać ponownie zainicjowane po aktualizacji poziomu usługi.
Dialogi międzybazowego Service Broker przestaną dostarczać komunikaty do usług w innych bazach danych po zmianie poziomu usługi. Komunikaty nie zostaną utracone i można je znaleźć w kolejce nadawcy. Każda zmiana liczby rdzeni wirtualnych lub rozmiaru magazynu w SQL Managed Instance powoduje zmianę wartości service_broke_guid w widoku sys.databases dla wszystkich baz danych. Każdy DIALOG utworzony przy użyciu instrukcji BEGIN DIALOG odwołującej się do Brokerów Usług w innej bazie danych przestaje dostarczać 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 po zmianie warstwy usługi istnieją pozostałe komunikaty, które nie zostały dostarczone, 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 DATABASE, ALTER DATABASE ADD FILE i RESTORE DATABASE instrukcje mogą zakończyć się niepowodzeniem, ponieważ wystąpienie może osiągnąć limit usługi Azure Storage.
Każda instancja ogólnego przeznaczenia SQL Managed Instance ma do 35 TB zarezerwowanej przestrzeni dyskowej 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. 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 instancja zarządzana, która nie potrzebuje łącznie 8 TB, w niektórych przypadkach może przekroczyć limit przestrzeni dyskowej na platformie Azure wynoszący 35 TB.
Na przykład instancja ogólnego przeznaczenia usługi Instancja Zarządzana SQL może mieć 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 specyficzną dystrybucję plików, wystąpienie usługi SQL Managed Instance może niespodziewanie osiągnąć limit 35 TB, który jest zarezerwowany dla zamontowanego dysku Azure Premium.
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 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 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, 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 systemowe logowanie 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 to konto logowania jest odtwarzane, a z powodu błędu w systemie poprzednie konto logowania nie jest usuwane. 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.
Logowania i użytkownicy Microsoft Entra nie są obsługiwani w SSDT
Narzędzia SQL Server Data Tools nie obsługują w pełni loginów i użytkowników Microsoft Entra.
Podszywanie się pod typy logowania Microsoft Entra nie jest obsługiwane
Personifikacja przy użyciu EXECUTE AS USER lub EXECUTE AS LOGIN dla następujących podmiotów zabezpieczeń firmy Microsoft Entra nie jest obsługiwana:
- Aliasowani użytkownicy Microsoft Entra. W tym przypadku zwracany jest następujący błąd:
15517. - Loginy i użytkownicy Microsoft Entra, bazujące na aplikacjach lub głównych zasadach usługi Microsoft Entra. W tym przypadku zwracane są następujące błędy:
15517i15406.
Replikacja transakcyjna musi zostać ponownie skonfigurowana po awarii geograficznej.
Jeśli replikacja transakcyjna jest włączona w bazie danych w grupie awaryjnego przełączania, administrator instancji zarządzanej SQL musi wyczyścić wszystkie publikacje na starej instancji podstawowej i ponownie je skonfigurować na nowej instancji podstawowej po przełączeniu 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 instancja uruchamia się lub przełącza w tryb awaryjny, a wszelkie zmiany wprowadzone w tempdb 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 słuchacza grupy awaryjnej 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 przełączania awaryjnego, rekord DNS odpowiadający skojarzonemu odbiornikowi grupy przełączania awaryjnego (odbiornikowi odczytu i zapisu, jeśli wystąpienie jest bieżącym głównym geograficznym, lub odbiornikowi tylko do odczytu, jeśli wystąpienie jest bieżącym pomocniczym geograficznym) zostanie przeniesiony do nowego klastra wirtualnego.
W obecnym projekcie operacji skalowania rekordy DNS związane z listenerem są usuwane z początkowego klastra wirtualnego, zanim zarządzane wystąpienie zostanie w pełni przeniesione do nowego klastra wirtualnego, co w niektórych sytuacjach może prowadzić do wydłużonego okresu, w którym adres IP wystąpienia nie może być poprawnie rozpoznany przy użyciu listenera. W tym czasie klient SQL próbujący uzyskać dostęp do skalowanego wystąpienia przy użyciu końcowego punktu nasłuchującego 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.
Rozwiązano
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 dotyczące tabeli zewnętrznej kończy się niepowodzeniem z komunikatem o błędzie nieobsługiwanym.
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 PolyBase, należy włączyć PolyBase w wystąpieniu zarządzanym, uruchamiając polecenie sp_configure.
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 niekompatybilnych tabel zewnętrznych Elastic Query do wykonywania zapytań dotyczących danych w Azure SQL Database lub Azure Synapse z wystąpienia zarządzanego, powinieneś użyć funkcji serwera połączonego. Aby nawiązać połączenie serwera połączonego z zarządzanego wystąpienia SQL do bazy danych SQL, 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 instancję), które umożliwią zapytania 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 CHECKSUM może zakończyć się niepowodzeniem
(Rozwiązano w czerwcu 2020 r.) W pewnych okolicznościach ręcznie wykonana kopia zapasowa baz danych w wystąpieniu zarządzanym bez sumy kontrolnej może zakończyć się niepowodzeniem przy przywracaniu. W takich przypadkach ponów próbę przywrócenia kopii zapasowej do momentu pomyślnego zakończenia.
Obejście: Wykonuj ręcznie kopie zapasowe 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 usuwany po wykryciu, co skutkuje ponownym uruchomieniem procesu agenta.
Uprawnienia do grupy zasobów nie są stosowane do usługi SQL Managed Instance
Gdy rola SQL Managed Instance Contributor w Azure jest stosowana do grupy zasobów (RG), nie jest stosowana do 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:
Zarządzane wystąpienie wymaga podmiotu zabezpieczeń usługi, aby dostać się do Microsoft Entra ID (dawniej Azure Active Directory). Kliknij tutaj, aby utworzyć jednostkę usługi"
Ten komunikat o błędzie można zignorować, jeśli zasada usługi dla zarządzanego wystąpienia już istnieje i/lub jeśli uwierzytelnianie Microsoft Entra na zarządzanym wystąpieniu działa poprawnie.
Aby sprawdzić, czy jednostka usługi istnieje, przejdź do strony Aplikacje dla przedsiębiorstw w portalu Azure, wybierz pozycję Tożsamości zarządzane z listy rozwijanej Typ aplikacji, wybierz 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 danych Microsoft Entra ID do nowo utworzonego głównego obiektu usługi, aby uwierzytelnianie przy użyciu 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, zapoznaj się z Przewodnikiem dla współautorów dokumentacji.
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.