Známé problémy se službou Azure SQL Managed Instance
Platí pro: 
Azure SQL Managed Instance
Tento článek obsahuje seznam aktuálně známých problémů se službou Azure SQL Managed Instance a jejich datum řešení nebo možné alternativní řešení. Další informace o službě Azure SQL Managed Instance najdete v tématu Co je Azure SQL Managed Instance? a Co je nového ve službě Azure SQL Managed Instance?
Poznámka:
ID Microsoft Entra se dříve označovalo jako Azure Active Directory (Azure AD).
Známé problémy
Má alternativní řešení
Seznam dlouhodobých záloh na webu Azure Portal zobrazuje záložní soubory pro aktivní a odstraněné databáze se stejným názvem.
Dlouhodobé zálohy je možné uvést a spravovat na stránce webu Azure Portal pro spravovanou instanci Azure SQL na kartě Zálohy . Stránka obsahuje seznam aktivních nebo odstraněných databází, základní informace o jejich dlouhodobých zálohách a odkaz pro správu záloh. Když vyberete odkaz Spravovat , otevře se nové boční podokno se seznamem záloh. Kvůli problému s logikou filtrování se v seznamu zobrazují zálohy pro aktivní databázi i odstraněné databáze se stejným názvem. To vyžaduje zvláštní pozornost při výběru záloh pro odstranění, aby se zabránilo odstranění záloh pro nesprávnou databázi.
Alternativní řešení: Pomocí zobrazených informací o čase zálohování (UTC) v seznamu můžete odlišit zálohy patřící do databází se stejným názvem, který existoval v instanci v různých obdobích. Případně můžete použít příkazy PowerShellu Get-AzSqlInstanceDatabaseLongTermRetentionBackup a Remove-AzSqlInstanceDatabaseLongTermRetentionBackup nebo příkazy rozhraní příkazového řádku az sql midb ltr-backup list a az sql midb ltr-backup delete ke správě dlouhodobých záloh pomocí parametru DatabaseState a DatabaseDeletionTime vrátí hodnotu pro filtrování záloh databáze.
Cíl event_file relace událostí system_health není přístupný.
Když se pokusíte přečíst obsah event_file cíle system_health relace události, zobrazí se chyba 40538, "Platná adresa URL začínající na "https://" je vyžadována jako hodnota pro každou zadanou cestu k souboru. K tomu dochází v aplikaci SQL Server Management Studio nebo při čtení dat relace pomocí funkce sys.fn_xe_file_target_read_file .
Tato změna chování je nezamýšleným důsledkem nedávné požadované opravy zabezpečení. Zkoumáme proveditelnost další změny, která by zákazníkům umožnila bezpečně používat relaci ve system_health službě Azure SQL Managed Instance. Mezitím můžou zákazníci tento problém obejít vytvořením vlastního ekvivalentu system_health relace s event_file cílem ve službě Azure Blob Storage. Další informace, včetně skriptu T-SQL k vytvoření system_health relace, kterou lze upravit a vytvořit vlastní ekvivalent system_health, naleznete v tématu Použití relace system_health.
Procedura sp_send_dbmail může selhat, když @query parametr
Procedura sp_send_dbmail může selhat při @query použití parametru.. K chybám dochází, když se uložená procedura spustí v rámci účtu sysadmin.
Příčinou tohoto problému je známá chyba související s sp_send_dbmail používáním zosobnění.
Alternativní řešení: Ujistěte se, že voláte sp_send_dbmail pod odpovídajícím vlastním účtem, který jste vytvořili, a ne pod účtem sysadmin.
Tady je příklad, jak můžete vytvořit vyhrazený účet a upravit existující objekty, které odesílají e-maily prostřednictvím 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
Dočasné pokyny k aktualizacím časových pásem 2022 pro Chile
8. srpna 2022 chilská vláda oznámila oficiální oznámení o změně časového pásma letního času (DST). Od 12:00 v sobotu 10. září 2022 do 12:00 soboty, 1. dubna 2023 bude oficiální čas 60 minut pokračovat. Tato změna má vliv na následující tři časová pásma: Pacific SA Standard Time, Easter Island Standard Time a Magallanes Standard Time. Spravované instance Azure SQL využívající ovlivněná časová pásma neodráží změny , dokud Microsoft nevyvolá aktualizaci operačního systému, která tuto podporu podporuje, a služba Azure SQL Managed Instance absorbuje aktualizaci na úrovni operačního systému.
Alternativní řešení: Pokud potřebujete změnit ovlivněná časová pásma pro spravované instance, mějte na paměti omezení a postupujte podle pokynů v dokumentaci.
Změna typu připojení nemá vliv na připojení prostřednictvím koncového bodu skupiny převzetí služeb při selhání
Pokud se instance účastní skupiny převzetí služeb při selhání, změna typu připojení instance se neprojeví u připojení vytvořených prostřednictvím koncového bodu naslouchacího procesu skupiny převzetí služeb při selhání.
Alternativní řešení: Po změně typu připojení zahoďte a znovu vytvořte skupinu převzetí služeb při selhání.
Procedura sp_send_dbmail může přechodně selhat při @query použití parametru
Při použití parametru může procedura sp_send_dbmail přechodně selhat @query . Pokud k tomuto problému dojde, každé druhé spuštění procedury sp_send_dbmail selže s chybou Msg 22050, Level 16, State 1 a zprávou Failed to initialize sqlcmd library with error number -2147467259. Chcete-li tuto chybu správně zobrazit, měla by být volána procedura s výchozí hodnotou 0 parametru @exclude_query_output, jinak se chyba nerozšíší.
Příčinou tohoto problému je známá chyba související s sp_send_dbmail používáním zosobnění a sdružování připojení.
Chcete-li tento problém obejít, zabalte kód pro odeslání e-mailu do logiky opakování, která spoléhá na výstupní parametr @mailitem_id. Pokud se spuštění nezdaří, hodnota parametru má hodnotu NULL, což znamená sp_send_dbmail , že by se mělo zavolat ještě jednou, aby se úspěšně odeslal e-mail. Tady je příklad této logiky opakování:
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
Distribuované transakce je možné spustit po odebrání spravované instance ze skupiny důvěryhodnosti serveru.
Skupiny důvěryhodnosti serveru slouží k navázání vztahu důvěryhodnosti mezi spravovanými instancemi, které jsou nezbytné pro provádění distribuovaných transakcí. Po odebrání spravované instance ze skupiny důvěryhodnosti serveru nebo odstranění skupiny stále můžete provádět distribuované transakce. Existuje alternativní řešení, které můžete použít, abyste měli jistotu, že jsou distribuované transakce zakázané a že se jedná o ruční převzetí služeb při selhání iniciované uživatelem ve spravované instanci.
Distribuované transakce nejde spustit po operaci škálování spravované instance.
Operace škálování služby SQL Managed Instance, které zahrnují změnu úrovně služby nebo počtu virtuálních jader, obnoví nastavení skupiny důvěryhodnosti serveru v back-endu a zakáže spouštění distribuovaných transakcí. Jako alternativní řešení odstraňte a vytvořte novou skupinu důvěryhodnosti serveru na webu Azure Portal.
Nejde vytvořit spravovanou instanci SQL se stejným názvem jako logický server, který jste předtím odstranili.
Záznam DNS se vytvoří při vytváření logického <name>.database.windows.com serveru v Azure pro Azure SQL Database a při vytváření spravované instance SQL. Záznam DNS musí být jedinečný. Pokud například vytvoříte logický server pro SLUŽBU SQL Database a pak ho odstraníte, bude prahová doba 7 dnů před uvolněním názvu ze záznamů. V tomto období nejde vytvořit spravovanou instanci SQL se stejným názvem jako odstraněný logický server. Jako alternativní řešení použijte jiný název pro spravovanou instanci SQL nebo vytvořte lístek podpory pro vydání názvu logického serveru.
Instanční objekt nemá přístup k MICROSOFT Entra ID a AKV
V některých případech může dojít k problému s instančním objektem používaným pro přístup ke službám Microsoft Entra ID (dříve Azure Active Directory) a azure Key Vault (AKV). V důsledku toho se tento problém týká použití ověřování Microsoft Entra a transparentního šifrování dat (TDE) se službou SQL Managed Instance. Může k tomu dojít jako občasný problém s připojením nebo nejde spustit příkazy, jako jsou CREATE LOGIN/USER FROM EXTERNAL PROVIDER nebo EXECUTE AS LOGIN/USER. Nastavení transparentního šifrování dat s klíčem spravovaným zákazníkem v nové instanci Azure SQL Managed Instance nemusí za určitých okolností fungovat.
Alternativní řešení: Pokud chcete zabránit výskytu tohoto problému ve službě SQL Managed Instance před spuštěním jakýchkoli aktualizačních příkazů, nebo pokud jste k tomuto problému už došlo po příkazech aktualizace, přejděte na web Azure Portal, přejděte na stránku pro správu služby SQL Managed Instance Active Directory. Ověřte, jestli se zobrazí chybová zpráva Spravovaná instance potřebuje instanční objekt pro přístup k ID Microsoft Entra. Kliknutím sem vytvoříte instanční objekt. Pokud jste narazili na tuto chybovou zprávu, vyberte ji a postupujte podle podrobných pokynů uvedených, dokud se tato chyba nevyřeší.
Omezení ručního převzetí služeb při selhání prostřednictvím portálu pro skupiny převzetí služeb při selhání
Pokud skupina převzetí služeb při selhání překlenuje mezi instancemi v různých předplatných Nebo skupinách prostředků Azure, ruční převzetí služeb při selhání nejde zahájit z primární instance ve skupině převzetí služeb při selhání.
Alternativní řešení: Spuštění převzetí služeb při selhání prostřednictvím portálu z geograficky sekundární instance
Role agenta SQL musí mít explicitní oprávnění SPUSTIT pro jiná přihlášení než správce systému
Pokud se přihlašovací údaje jiného správce než sysadmin přidají do jakékoli pevné databázové role agenta SQL, existuje problém, kdy je potřeba udělit explicitní oprávnění EXECUTE třem uloženým procedurám v master databázi, aby tato přihlášení fungovala. Pokud k tomuto problému dojde, zobrazí se chybová zpráva The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) .
Alternativní řešení: Po přidání přihlášení do pevné databázové role agenta SQL (SQLAgentUserRole, SQLAgentReaderRole nebo SQLAgentOperatorRole) pro každé přihlášení přidané do těchto rolí spusťte následující skript T-SQL, který explicitně udělí oprávnění EXECUTE k uvedeným uloženým procedurám.
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 paměti OLTP v paměti se nepoužívají.
Úroveň služby Pro důležité obchodní informace v některých případech nepoužívá maximální limity paměti pro objekty optimalizované pro paměť. Sql Managed Instance může umožnit úlohě využívat více paměti pro operace OLTP v paměti, které můžou ovlivnit dostupnost a stabilitu instance. Dotazy OLTP v paměti, které dosáhnou limitů, nemusí okamžitě selhat. Dotazy, které používají více paměti OLTP v paměti, selžou dříve, pokud dosáhnou limitů.
Alternativní řešení: Pomocí aplikace SQL Server Management Studio monitorujte využití úložiště OLTP v paměti, abyste zajistili, že úloha nepoužívá více než dostupnou paměť. Zvyšte limity paměti, které závisí na počtu virtuálních jader, nebo optimalizujte úlohu tak, aby využívala méně paměti.
Při pokusu o odebrání souboru, který není prázdný, se vrátila chybná chyba
SQL Server a SQL Managed Instance neumožňují uživateli vyhodit soubor, který není prázdný. Pokud se pokusíte odebrat neprázdný datový soubor pomocí ALTER DATABASE REMOVE FILE příkazu, chyba Msg 5042 – The file '<file_name>' cannot be removed because it is not empty se okamžitě nevrátí. Sql Managed Instance se bude snažit soubor vypustit a operace se nezdaří po 30 minutách s Internal server error.
Průběžné obnovení databáze blokuje změny úrovně služby a operace vytváření instancí
Průběžný RESTORE příkaz, proces migrace služby Data Migration Service a integrované obnovení k určitému bodu v čase, bude blokovat aktualizaci úrovně služby nebo změnu velikosti stávající instance a vytváření nových instancí, dokud se proces obnovení nedokončí.
Proces obnovení blokuje tyto operace ve spravovaných instancích a fondech instancí ve stejné podsíti, ve které je spuštěný proces obnovení. Instance ve fondech instancí nejsou ovlivněny. Operace vytvoření nebo změny úrovně služby selžou nebo vyprší časový limit. Po dokončení nebo zrušení procesu obnovení budou pokračovat.
Alternativní řešení: Počkejte, až se proces obnovení dokončí, nebo proces obnovení zrušte, pokud má operace vytvoření nebo aktualizace na úrovni služby vyšší prioritu.
Správce prostředků na úrovni služby Pro důležité obchodní informace může být potřeba po převzetí služeb při selhání překonfigurovat.
Funkce Správce prostředků, která umožňuje omezit prostředky přiřazené k uživatelské úloze, může po převzetí služeb při selhání nesprávně klasifikovat některé uživatelské úlohy nebo změnu úrovně služby iniciované uživatelem (například změna maximální velikosti úložiště virtuálních jader nebo maximální velikosti úložiště instance).
Alternativní řešení: Pokud používáte správce prostředků, spusťte ALTER RESOURCE GOVERNOR RECONFIGURE úlohu SQL pravidelně nebo jako součást úlohy agenta SQL, která spouští úlohu SQL.
Dialogy Service Broker napříč databázemi musí být po upgradu úrovně služby znovu inicializovány.
Dialogy Service Broker mezi databázemi přestanou po změně úrovně služby doručovat zprávy do služeb v jiných databázích. Zprávy se neztratí a dají se najít ve frontě odesílatele. Jakákoli změna velikosti úložiště virtuálních jader nebo instance ve službě SQL Managed Instance způsobí service_broke_guid změnu hodnoty v zobrazení sys.databases pro všechny databáze. Všechny DIALOG vytvořené pomocí příkazu BEGIN DIALOG , který odkazuje na Service Brokers v jiné databázi, přestane do cílové služby doručovat zprávy.
Alternativní řešení: Před aktualizací úrovně služby zastavte všechny aktivity, které používají dialogové konverzace služby Service Broker napříč databázemi, a potom je znovu inicializovat. Pokud existují zbývající zprávy, které se po změně úrovně služby nedoručí, přečtěte si zprávy ze zdrojové fronty a znovu je odešlete do cílové fronty.
Překročení prostoru úložiště malými databázovými soubory
CREATE DATABASE, ALTER DATABASE ADD FILEa RESTORE DATABASE příkazy můžou selhat, protože instance může dosáhnout limitu služby Azure Storage.
Každá instance služby SQL Managed Instance pro obecné účely má až 35 TB úložiště vyhrazeného pro místo na disku Azure Premium. Každý soubor databáze je umístěn na samostatném fyzickém disku. Velikost disků může být 128 GB, 256 GB, 512 GB, 1 TB nebo 4 TB. Nevyužité místo na disku není zpoplatněno, ale celkový součet velikostí disků Azure Premium nesmí překročit 35 TB. V některých případech může spravovaná instance, která nepotřebuje celkem 8 TB, kvůli interní fragmentaci překročit limit velikosti úložiště Azure (35 TB).
Instance služby SQL Managed Instance může mít například jeden velký soubor o velikosti 1,2 TB na disku s 4 TB. Může mít také 248 souborů, které mají 1 GB a jsou umístěné na samostatných 128GB discích. V tomto příkladu:
- Celková přidělená velikost diskového úložiště je 1 x 4 TB + 248 x 128 GB = 35 TB.
- Celkový rezervovaný prostor pro databáze v instanci je 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.
Tento příklad ukazuje, že za určitých okolností může instance spravované instance SQL dosáhnout limitu 35 TB, který je vyhrazený pro připojený disk Azure Premium, když ho možná neočekáváte.
V tomto příkladu stávající databáze nadále fungují a můžou růst bez problémů, pokud nebudou přidány nové soubory. Nové databáze nelze vytvořit ani obnovit, protože není dostatek místa pro nové diskové jednotky, i když celková velikost všech databází nedosahuje limitu velikosti instance. Chyba vrácená v takovém případě není jasná.
Počet zbývajících souborů můžete zjistit pomocí systémových zobrazení. Pokud dosáhnete tohoto limitu, zkuste pomocí příkazu DBCC SHRINKFILE vyprázdnit a odstranit některé menší soubory nebo přepnout na úroveň Pro důležité obchodní informace, která tento limit nemá.
Hodnoty GUID zobrazené místo názvů databází
Několik systémových zobrazení, čítačů výkonu, chybových zpráv, XEvents a položek protokolu chyb zobrazují identifikátory databáze GUID místo skutečných názvů databází. Nespoléhejte na tyto identifikátory GUID, protože se můžou v budoucnu nahradit skutečnými názvy databází.
Alternativní řešení: Použití sys.databases zobrazení k překladu skutečného názvu databáze z fyzického názvu databáze zadaného ve formě identifikátorů databáze GUID:
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
Moduly CLR a odkazované servery někdy nemůžou odkazovat na místní IP adresu
Moduly CLR ve službě SQL Managed Instance a odkazované servery nebo distribuované dotazy, které odkazují na aktuální instanci, někdy nemůžou přeložit IP adresu místní instance. Tato chyba je přechodný problém.
Obor transakcí ve dvou databázích ve stejné instanci není podporován.
(Vyřešeno v březnu 2020) Třída TransactionScope v .NET nefunguje, pokud se dva dotazy odesílají do dvou databází ve stejné instanci ve stejném oboru transakce:
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;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=mypassword;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
Alternativní řešení (není potřeba od března 2020): Použijte SqlConnection.ChangeDatabase(String) k použití jiné databáze v kontextu připojení místo dvou připojení.
Bez rozlišení
Zvýšený počet systémových přihlášení používaných pro transakční replikaci
Služba Azure SQL Managed Instance vytváří přihlášení systému pro účely transakční replikace. Toto přihlášení najdete v nástroji SSMS (v Průzkumníku objektů, v části Zabezpečení, Přihlášení) nebo v systémovém zobrazení sys.syslogins. Formát přihlašovacího jména vypadá takto 'DBxCy\WF-abcde01234QWERT'a přihlašovací jméno má roli veřejného serveru. Za určitých podmínek se toto přihlášení znovu vytvoří a kvůli chybě v systému se předchozí přihlášení neodstraní. To může vést ke zvýšení počtu přihlášení. Tato přihlášení nepředstavují bezpečnostní hrozbu. Mohou být bezpečně ignorovány. Tato přihlášení by se neměla odstranit, protože alespoň jedno z nich se používá pro transakční replikaci.
Tabulka ručních záloh v msdb nezachová uživatelské jméno
Nedávno jsme zavedli podporu automatických záloh, msdbale tabulka momentálně neobsahuje informace o uživatelském jménu.
Přihlášení Microsoft Entra a uživatelé se v SSDT nepodporují.
SQL Server Data Tools plně nepodporují přihlášení a uživatele Microsoft Entra.
Zosobnění typů přihlášení Microsoft Entra se nepodporuje.
Zosobnění pomocí EXECUTE AS USER EXECUTE AS LOGIN následujících objektů zabezpečení Microsoft Entra se nepodporuje:
- Aliased Microsoft Entra users. V tomto případě se vrátí následující chyba:
15517. - Microsoft Entra přihlášení a uživatelé na základě aplikací Microsoft Entra nebo instančních objektů. V tomto případě se vrátí následující chyby:
15517a15406.
Transakční replikace musí být po geografickém převzetí služeb při selhání překonfigurovaná.
Pokud je u databáze ve skupině převzetí služeb při selhání povolená transakční replikace, musí správce spravované instance SQL vyčistit všechny publikace na staré primární databázi a po převzetí služeb při selhání do jiné oblasti je znovu nakonfigurovat na nové primární. Další informace naleznete v tématu Replikace.
tempdb struktura a obsah se znovu vytvoří.
Databáze je vždy rozdělená tempdb na 12 datových souborů a strukturu souborů nelze změnit. Maximální velikost souboru nelze změnit a do souboru nelze přidat tempdbnové soubory . Databáze tempdb se při spuštění instance nebo převzetí služeb při selhání vždy znovu vytvoří jako prázdná databáze a všechny změny provedené v tempdb této instanci se nezachovají.
Protokoly chyb se neuchovávají
Protokoly chyb, které jsou dostupné ve službě SQL Managed Instance, se neuchovávají a jejich velikost není zahrnutá v maximálním limitu úložiště. Pokud dojde k převzetí služeb při selhání, můžou se protokoly chyb automaticky vymazat. V historii protokolu chyb může docházet k mezerám, protože spravovaná instance SQL byla několikrát přesunuta na několik virtuálních počítačů.
Dočasná nedostupnost instance pomocí naslouchacího procesu skupiny převzetí služeb při selhání během operace škálování
Škálování spravované instance někdy vyžaduje přesun instance do jiného virtuálního clusteru spolu s přidruženými záznamy DNS spravovanými službami. Pokud se spravovaná instance účastní skupiny převzetí služeb při selhání, přesune se záznam DNS odpovídající jeho přidruženému naslouchacímu procesu skupiny převzetí služeb při selhání (naslouchací proces pro čtení i zápis, pokud je instance aktuálním geograficky sekundárním) do nového virtuálního clusteru.
V návrhu aktuální operace škálování se záznamy DNS naslouchacího procesu odeberou z původního virtuálního clusteru předtím, než se samotná spravovaná instance plně migruje do nového virtuálního clusteru, což v některých situacích může vést k prodloužení doby, během které se IP adresa instance nedá vyřešit pomocí naslouchacího procesu. Během této doby může klient SQL, který se pokouší o přístup ke škálované instanci pomocí koncového bodu naslouchacího procesu, očekávat selhání přihlášení s následující chybovou zprávou: Chyba 40532: Server "xxx.xxx.xxx.xxx" požadovaný pro přihlášení nelze otevřít. Přihlášení se nezdařilo. (Microsoft SQL Server, chyba: 40532)".
Tento problém se vyřeší změnou návrhu operace škálování.
Vyřešeno
Dotaz na externí tabulku selže s nepodporou chybovou zprávou
Dotazování externí tabulky může selhat s obecnou chybovou zprávou Dotazy nad externími tabulkami nejsou podporovány s aktuální úrovní služby nebo úrovní výkonu této databáze. Zvažte upgrade úrovně služby nebo úrovně výkonu databáze. Jediným typem externích tabulek podporovaných ve službě Azure SQL Managed Instance jsou externí tabulky PolyBase (ve verzi Preview). Pokud chcete povolit dotazy na externí tabulky PolyBase, musíte povolit PolyBase ve spravované instanci spuštěním sp_configure příkazu.
Externí tabulky související s funkcí Elastic Query služby Azure SQL Database nejsou ve službě SQL Managed Instance podporované , ale jejich vytváření a dotazování nebylo explicitně blokováno. S podporou externích tabulek PolyBase byly zavedeny nové kontroly, které blokují dotazování libovolného typu externí tabulky ve spravované instanci, pokud není povolena Funkce PolyBase.
Pokud k dotazování dat ve službě Azure SQL Database nebo Azure Synapse ze spravované instance používáte nepodporované externí tabulky Elastic Query, měli byste místo toho použít funkci Propojeného serveru. Pokud chcete vytvořit připojení propojeného serveru ze spravované instance SQL ke službě SQL Database, postupujte podle pokynů v tomto článku. Pokud chcete vytvořit připojení propojeného serveru ze spravované instance SQL ke službě SQL Synapse, projděte si podrobné pokyny. Vzhledem k tomu, že konfigurace a testování připojení k propojenému serveru nějakou dobu trvá, můžete alternativní řešení použít jako dočasné řešení, které umožňuje dotazování externích tabulek souvisejících s funkcí Elastic Query:
Alternativní řešení: Spusťte následující příkazy (jednou za instanci), které umožňují dotazy na externí tabulky:
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
Při použití ověřování SQL Serveru se nepodporují uživatelská jména s znakem @.
Uživatelská jména, která obsahují symbol @uprostřed (například 'abc@xy') se nemůžou přihlásit pomocí ověřování SQL Serveru.
Obnovení ruční zálohy bez kontrolního součtu může selhat
Za určitých okolností může dojít k selhání ruční zálohy databází, které byly provedeny ve spravované instanci bez funkce CHECKSUM. V takových případech zkuste zálohování obnovit, dokud nebudete úspěšní.
Alternativní řešení: Proveďte ruční zálohování databází ve spravovaných instancích s povoleným kontrolním součtem.
Agent přestane reagovat při úpravě, zakázání nebo povolení existujících úloh
Za určitých okolností může změna, zakázání nebo povolení existující úlohy způsobit, že agent přestane reagovat. Problém se automaticky zmírní při detekci, což vede k restartování procesu agenta.
Oprávnění ke skupině prostředků se na spravovanou instanci SQL nepoužijí
Pokud se role Azure přispěvatele spravované instance SQL použije na skupinu prostředků (RG), nepoužije se na spravovanou instanci SQL a nemá žádný vliv.
Alternativní řešení: Nastavení role Přispěvatel spravované instance SQL pro uživatele na úrovni předplatného
Úlohy agenta SQL je možné přerušit restartováním procesu agenta.
(Vyřešeno v březnu 2020) Agent SQL vytvoří novou relaci při každém spuštění úlohy a postupně zvyšuje spotřebu paměti. Aby nedošlo k dosažení limitu interní paměti, což by zablokovalo provádění plánovaných úloh, proces agenta se restartuje, jakmile spotřeba paměti dosáhne prahové hodnoty. Může dojít k přerušení provádění úloh spuštěných v okamžiku restartování.
@query parametr není v sp_send_db_mail podporován
Parametr @query v sp_send_db_mail postupu nefunguje.
Zavádějící chybová zpráva na webu Azure Portal s návrhem opětovného využití instančního objektu
Na stránce pro správu Active Directory na webu Azure Portal pro spravovanou instanci Azure SQL se může zobrazit následující chybová zpráva, i když instanční objekt již existuje:
Spravovaná instance potřebuje instanční objekt pro přístup k Microsoft Entra ID (dříve Azure Active Directory). Kliknutím sem vytvoříte instanční objekt.
Tuto chybovou zprávu můžete zanedbávat, pokud již existuje instanční objekt spravované instance a/nebo ověřování Microsoft Entra ve spravované instanci funguje.
Pokud chcete zkontrolovat, jestli instanční objekt existuje, přejděte na stránku Podnikové aplikace na webu Azure Portal, v rozevíracím seznamu Typ aplikace zvolte Spravované identity, vyberte Použít a do vyhledávacího pole zadejte název spravované instance. Pokud se název instance zobrazí v seznamu výsledků, instanční objekt již existuje a nejsou potřeba žádné další akce.
Pokud jste už postupovali podle pokynů z chybové zprávy a vybrali odkaz z chybové zprávy, instanční objekt spravované instance se znovu vytvořil. V takovém případě přiřaďte nově vytvořenému instančnímu objektu oprávnění ke čtení ID Microsoft Entra, aby ověřování Microsoft Entra fungovalo správně. Můžete to provést pomocí Azure PowerShellu podle pokynů.
Příspěvky k obsahu
Pokud chcete přispívat do dokumentace k Azure SQL, přečtěte si příručku pro přispěvatele Na docs.
Související obsah
Seznam aktualizací a vylepšení služby SQL Managed Instance najdete v tématu Aktualizace služby SQL Managed Instance.
Informace o aktualizacích a vylepšeních všech služeb Azure najdete v tématu Aktualizace služeb.
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro