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á ř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 PowerShell `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. Pro filtrování záloh databáze použijte parametr `DatabaseState` a návratovou hodnotu `DatabaseDeletionTime`.
Cíl relace událostí system_health, event_file, 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ě T-SQL skriptu pro vytvoření relace system_health, kterou lze upravit k vytvoření vlastního ekvivalentu system_health, naleznete v části Použití relace system_health.
Procedura sp_send_dbmail může selhat, když je zadaný parametr @query.
Procedura sp_send_dbmail může selhat, pokud je parametr @query použit. 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 tím, jak sp_send_dbmail používá impersonaci.
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 2:00 v sobotu 1. dubna 2023 se oficiální čas posune o 60 minut dopředu. 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í neovlivní připojení přes koncový bod 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í odstraně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
Procedura sp_send_dbmail může přechodně selhat při použití parametru @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 aplikovat, abyste měli jistotu, že jsou distribuované transakce zakázané, a tím je uživatelsky iniciované ruční převzetí služeb při selhání na 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.comserveru 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 požadavek na podporu pro uvolnění názvu logického serveru.
Služba Principal nemá přístup k Microsoft Entra ID a Azure Key Vault.
V některých případech může dojít k problému se zástupcem služby 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 služby Azure SQL Managed Instance nemusí za určitých okolností fungovat správně.
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 v případě, že jste k tomuto problému už došlo po příkazech aktualizace, přejděte na stránku Přehled spravované instance SQL na webu Azure Portal. V části Nastavení vyberte Microsoft Entra ID pro přístup na stránku správce Microsoft Entra ID služby SQL Managed Instance. Ověřte, jestli se zobrazí chybová zpráva "Spravovaná instance potřebuje instanční objekt pro přístup k Microsoft Entra ID." Kliknutím sem vytvoříte klientskou identitu. 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í zahrnuje instance 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ě.
Alternativní řešení: Spuštění převzetí služeb při selhání prostřednictvím portálu ze sekundární geografické instance.
Role agenta SQL musí mít explicitní oprávnění SPUSTIT pro přihlášení s rolí jinou než sysadmin
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 pro In-memory OLTP se nepoužívají.
Úroveň služby Business Critical v některých případech nesprávně uplatňuje maximální limity paměti pro paměťově optimalizované objekty. 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 bude i nadále pokoušet odstranit soubor a operace se ukončí neúspěšně 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í
Probíhající RESTORE příkaz, migrační proces služby Data Migration Service a integrovaná obnova k určitému bodu v čase zablokují aktualizaci úrovně služby, změnu velikosti stávající instance a vytvoření nových instancí, dokud se proces obnovy 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 neselžou ani nevyprší časový limit. Pokračují, jakmile je proces obnovení dokončen nebo zrušen.
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 Business Critical může být potřeba překonfigurovat po převzetí služeb při selhání.
Resource Governor funkce, která umožňuje omezit prostředky přiřazené k uživatelským úlohám, může po převzetí služeb při selhání nebo při uživatelsky iniciované změně úrovně služby (například změna maximálního počtu virtuálních jader nebo maximální velikosti úložiště instance) nesprávně klasifikovat některé uživatelské úlohy.
Alternativní řešení: Spusťte ALTER RESOURCE GOVERNOR RECONFIGURE úlohu SQL pravidelně nebo jako součást úlohy agenta SQL, která spouští úlohu SQL při spuštění instance, pokud používáte Resource Governor.
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, které byly vytvořeny pomocí příkazu BEGIN DIALOG a odkazují na Service Brokers v jiných databázích, přestanou doručovat zprávy do cílové služby.
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 v obecném účelu může mít například jeden velký soubor o velikosti 1,2 TB umístěný na 4TB disku. 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í, kvůli specifickému rozložení souborů, může instance SQL Managed Instance dosáhnout limitu 35 TB, který je vyhrazený pro připojený disk Azure Premium, což byste možná neočekávali.
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=<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();
}
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í
Rozdílové zálohy se neprovedou, když je instance propojená s SQL Serverem
Při konfiguraci propojení mezi SQL Serverem a službou Azure SQL Managed Instance se pro spravovanou instanci provádějí automatizované úplné zálohy a zálohy protokolů transakcí, ať už je v primární roli. Rozdílové zálohy se ale v současné době neprovádějí, což vede k delším než očekávaným časům obnovení.
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.
Přihlašování a uživatelé Microsoft Entra nejsou v SSDT podporováni.
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 nebo EXECUTE AS LOGIN následujících principálů Microsoft Entra se nepodporuje:
- Aliasovaní uživatelé Microsoft Entra. 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 selhání překonfigurována.
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 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í, mohou být protokoly chyb automaticky vymazány. 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 při použití poslechového rozhraní skupiny 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í jejímu přidruženému naslouchacímu procesu skupiny převzetí služeb při selhání do nového virtuálního clusteru. Tento naslouchací proces může být pro čtení i zápis, pokud je instance aktuálním geografickým primárním, nebo pouze pro čtení, pokud je instance aktuálním geografickým sekundárním.
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
Tabulka ručních záloh v msdb nezachová uživatelské jméno
(Vyřešeno v srpnu 2023) Nedávno jsme zavedli podporu automatických záloh, msdbale tabulka momentálně neobsahuje informace o uživatelském jménu.
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
(Vyřešeno v červnu 2020) 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 po detekci automaticky vyřeší, což vede k restartování procesu agenta.
Oprávnění ke skupině prostředků se na spravovanou instanci SQL nepoužijí
Pokud je role kontributoru Azure pro spravovanou instanci SQL použita na skupinu prostředků (RG), není použita na spravovanou instanci SQL a nemá žádný účinek.
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 portálu Azure navrhující opětovné vytvoření objektu služby
Na administrační stránce Active Directory v Azure portálu pro spravovanou instanci Azure SQL se může zobrazit následující chybová zpráva, i když objekt služby již existuje:
Spravovaná instance potřebuje servisního uživatele pro přístup k Microsoft Entra ID (dříve známému jako Azure Active Directory). Klikněte zde pro vytvoření principálu služby.
Tuto chybovou zprávu můžete ignorovat, pokud již existuje Service Principal pro spravovanou instanci a/nebo ověřování Microsoft Entra na spravované instanci funguje.
Pokud chcete zkontrolovat, jestli služební principál existuje, přejděte na stránku Podnikové aplikace v Azure portálu, 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ů, Service Principal již existuje a nejsou zapotřebí žádné další kroky.
Pokud jste už postupovali podle pokynů z chybové zprávy a vybrali odkaz z chybové zprávy, byl hlavní objekt služby spravované instance znovu vytvořen. V takovém případě přiřaďte nově vytvořenému služebnímu principálu oprávnění ke čtení Microsoft Entra ID, aby ověřování Microsoft Entra probíhalo 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 webu 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.