Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Applies to:
Azure SQL Managed Instance
Tento článek uvádí aktuálně známé problémy s Azure SQL Managed Instance a jejich datem řešení nebo možným alternativním řešením. Další informace o Azure SQL Managed Instance najdete v tématu Co je Azure SQL Managed Instance? a Co je nového v Azure SQL Managed Instance?
Poznámka:
Microsoft Entra ID se dříve označovala jako Azure Active Directory (Azure AD).
Známé problémy
Má řešení
Selhání operace obnovení po migraci na SQL Managed Instance
Pokud migrujete databázi do Azure SQL Managed Instance z SQL Server 2019 a novějších verzí s zrychleným obnovením databáze povoleno, ale je nakonfigurované s trvalým úložištěm verzí (PVS) nastaveným na jinou než PRIMARY skupinu souborů, můžete zaznamenat selhání operace obnovení cílové spravované instance SQL.
Pokud chcete tento problém vyřešit, nezapomeňte před migrací do SQL Managed Instance nastavit úložiště verzí persistent (PVS) na PRIMÁRNÍ ve zdrojové databázi SQL Server. Pokud jste databázi už migrovali bez nastavení pvS na PRIMARY, můžete ji nastavit ve zdrojové databázi SQL Server a pak databázi znovu migrovat na SQL Managed Instance.
Po migraci na SQL Managed Instance nejde použít zrychlené obnovení databáze
Od SQL Server 2019 platí, že pokud migrujete databázi do Azure SQL Managed Instance a zdrojová databáze má zrychlené obnovení databáze zakázáno, nemůžete u cílové spravované instance SQL použít akcelerované obnovení databáze.
Pokud chcete tento problém vyřešit, ujistěte, že na zdrojovém SQL Serveru zapnete zrychlené obnovení databáze, než ji přenesete na instanci SQL Managed Instance. Pokud jste databázi už migrovali bez povolení akcelerovaného obnovení databáze, můžete ji povolit ve zdrojové SQL Server databázi a pak databázi znovu migrovat do spravované instance SQL.
SQL Server 2017 a starších verzích nepodporují zrychlené obnovení databáze, takže se tento problém netýká databází migrovaných z těchto verzí SQL Server.
Po migraci na SQL Managed Instance nejde použít Service Broker
Pokud migrujete databázi na Azure SQL Managed Instance a Služba Broker je ve zdrojové databázi zakázaná, nemůžete v cílové spravované instanci SQL použít Service Broker.
Chcete-li tento problém vyřešit, před migrací do SQL Managed Instance nezapomeňte ve zdrojové databázi SQL Server povolit službu Service Broker. Pokud jste databázi už migrovali bez povolení nástroje Service Broker, můžete ji povolit ve zdrojové databázi SQL Server a pak databázi znovu migrovat na SQL Managed Instance.
Úprava doby uchovávání záloh pro bezplatnou nabídku
Zásady uchovávání záloh databází v bezplatné spravované instanci SQL můžete upravit jenom pomocí příkazů >REST API, PowerShell a Azure CLI. Zásady uchovávání záloh nemůžete upravovat prostřednictvím portálu Azure.
Přihlášení k funkci read-secondary selhalo kvůli dlouhému čekání na HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING
Tato chyba se může zobrazit jako výjimka pro ovladač Microsoft OLE DB Driver 19 pro SQL Server při pokusu o připojení k sekundární replice skupiny pro převzetí služeb při selhání nebo databáze replikované přes odkaz na Spravovanou instanci.
K této chybě dochází, když sekundární replika není k dispozici pro přihlašování, protože chybí verze řádků pro transakce, které běžely v době restartu nebo recyklace sekundární repliky, ať už z důvodu údržby nebo převzetí služeb po selhání. Když se instance restartuje nebo dojde k přepnutí při selhání, vymažou se data správy verzí uložená v tempdb. Sekundární dotazy pro čtení jsou přerušeny, pokud existují probíhající dlouhé aktivní transakce, které byly zahájeny před přepnutím při selhání či restartováním.
Pokud chcete tento problém vyřešit, vraťte aktivní transakce zpět nebo je potvrďte na primární replice. Chcete-li se této chybě vyhnout, minimalizujte dlouhotrvající transakce zápisu na primární replice.
Chyba 8992 při spuštění DBCC CHECKDB v SQL Server databázi, která pochází z SQL Managed Instance
Při spuštění příkazu DBCC CHECKDB v databázi SQL Server 2022 se může po odstranění indexu nebo tabulky s indexem zobrazit následující chyba a databáze pochází z Azure SQL Managed Instance, například po obnovení záložního souboru nebo z funkce odkazu SQL Managed Instance:
Msg 8992, Level 16, State 1, Line <Line_Number>
Check Catalog Msg 3853, State 1: Attribute (%ls) of row (%ls) in sys.sysrowsetrefs does not have a matching row (%ls) in sys.indexes.
Pokud chcete tento problém obejít, nejprve vypusťte index nebo tabulku s indexem ze zdrojové databáze v Azure SQL Managed Instance a pak databázi znovu obnovte nebo propojte s SQL Server 2022. Pokud opětovné vytvoření databáze ze zdrojového Azure SQL Managed Instance není možné, požádejte o pomoc s řešením tohoto problému podporu Microsoft.
Upozornění
Pokud v tabulce vytvoříte dělený index po vyřazení indexu, jak je popsáno v tomto scénáři, tabulka bude nepřístupná.
Chyba 1412 při vytváření odkazu Managed Instance
Při prvním vytvoření propojení se první část procesu vytvoří úplnou zálohu databáze z primární repliky do sekundární repliky. Po dokončení úplného zálohování začne spojení replikovat data aplikací rozdílových dat z primární repliky na sekundární repliku. Tento proces pokračuje po neomezenou dobu, dokud se nevydá failover příkaz nebo se link neodstraní.
Pokud se záloha transakčního protokolu vyskytne na primární replice během počátečního zálohování úplného zálohování, protokol transakcí se zkrátí. Vytvoření propojení selže s chybou 1412, protože data v transakčním protokolu potřebná pro počáteční zasetí již nejsou k dispozici.
Pokud se v chybovém protokolu SQL Serveru zobrazí chyba 1412 na Azure SQL Managed Instance, musíte propojení zrušit a znovu vytvořit. Chcete-li předejít tomuto problému, pozastavte zálohy transakčních protokolů během počáteční fáze nasazení. Pokud jsou zálohy transakčních protokolů nezbytné během počáteční fáze nasazení, zahajte otevřenou transakci, aby se zabránilo truncaci protokolu. Další informace najdete v Chyba 1412 při vytváření odkazu Managed Instance v průvodci odstraňováním potíží s funkcí odkazu.
Seznam dlouhodobých záloh na portálu Azure zobrazuje záložní soubory pro aktivní a odstraněné databáze se stejným názvem
Dlouhodobé zálohy je možné zobrazit a spravovat na stránce portálu Azure pro Azure SQL Managed Instance na kartě Backups. 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. cs-CZ: Alternativně můžete použít příkazy PowerShell Get-AzSqlInstanceDatabaseLongTermRetentionBackup a Remove-AzSqlInstanceDatabaseLongTermRetentionBackup nebo příkazy rozhraní příkazového řádku CLI az sql midb ltr-backup list a az sql midb ltr-backup delete ke správě dlouhodobých záloh pomocí parametru DatabaseState a návratové hodnoty DatabaseDeletionTime, abyste mohli filtrovat zálohy pro určitou databázi.
Procedura sp_send_dbmail může selhat při použití parametru @query
Uložená procedura sp_send_dbmail může selhat při použití parametru @query . K chybám dochází, když se uložená procedura spustí pod účtem sysadmin .
Příčinou tohoto problému je známá chyba související s tím, jak sp_send_dbmail používá zosobnění.
Alternativní řešení: Ujistěte se, že voláte sp_send_dbmail pod odpovídajícím vlastním účtem, který vytvoříte, a ne pod účtem správce systému .
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
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_user_name = N'user_name';
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name];
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXECUTE msdb.dbo.sp_update_jobstep
@job_name = N'db_mail_sending_job',
@step_id = db_mail_sending_job_id,
@database_name = N'msdb';
GO
-- Step 4: Set a principal in the email profile
EXECUTE msdb.dbo.sysmail_add_principalprofile_sp
@principal_name = N'user_name',
@profile_name = N'profile_name',
@is_default = 0;
GO
Distribuované transakce je možné spustit po odebrání spravované instance SQL 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 SQL ze skupiny důvěryhodnosti serveru nebo odstranění skupiny můžete stále být schopni spouštět distribuované transakce. Pro ověření, že jsou distribuované transakce zakázány, proveďte uživatelem iniciované ruční převzetí služeb při selhání ve spravované instanci SQL.
Nejde vytvořit SQL Managed Instance se stejným názvem jako dříve odstraněný logický server
Když vytvoříte logický server v Azure pro Azure SQL Database nebo SQL Managed Instance, systém vytvoří záznam DNS pro <name>.database.windows.com. Tento záznam DNS musí být jedinečný. Pokud vytvoříte logický server pro službu SQL Database a pak ho odstraníte, název zůstane rezervovaný po dobu sedmi dnů. Během tohoto období nemůžete vytvořit SQL Managed Instance se stejným názvem jako odstraněný logický server. Jako alternativní řešení použijte pro SQL Managed Instance jiný název nebo vytvořte podpůrný požadavek pro uvolnění názvu logického serveru.
Služební objekt nemá přístup k Microsoft Entra ID a AKV
V některých případech existuje problém se služebním principalem používaným pro přístup ke službám Microsoft Entra ID (dříve známé jako 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) s SQL Managed Instance. Můžete narazit na tento problém jako na přerušované problémy s připojením, nebo tím, že nemůžete spustit příkazy jako 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 na novém Azure SQL Managed Instance nemusí za určitých okolností fungovat.
Workaround: Pokud chcete zabránit výskytu tohoto problému na vašem SQL Managed Instance, před spuštěním jakýchkoli aktualizačních příkazů nebo v případě, že k tomuto problému došlo po příkazech aktualizace, přejděte na stránku V zobrazení vašeho SQL managed instance na portálu Azure. V části Nastavení vyberte Microsoft Entra ID a přejděte na stránku správce SQL Managed Instance Microsoft Entra ID. Vyhledejte následující chybovou zprávu:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Pokud narazíte na tuto chybovou zprávu, vyberte ji a postupujte podle podrobných pokynů uvedených, dokud se tato chyba nevyřeší.
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 odstranit 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` isn't immediately returned. SQL Managed Instance keeps trying to drop the file, and the operation fails after 30 minutes with `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, proces migrace služby Data Migration Service a integrované obnovení k určitému bodu v čase můžou blokovat aktualizace na úrovni služby nebo změnu velikosti stávající instance nebo 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 v instančních fondech 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 čitelné sekundární replice potřebuje po převzetí služeb při selhání rekonfiguraci.
Funkce Správce prostředků , která umožňuje omezit prostředky přiřazené k uživatelské úloze, můžou 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í: Pravidelně nebo jako součást úlohy agenta SQL spusťte ALTER RESOURCE GOVERNOR RECONFIGURE, který provádí úlohu SQL při spuštění čitelné sekundární repliky, pokud používáte správce prostředků.
Překročení prostoru úložiště malými databázovými soubory
příkazy CREATE DATABASE, ALTER DATABASE ADD FILE a RESTORE DATABASE můžou selhat, protože instance dosáhne limitu Azure Storage na úrovni služby Pro obecné účely, ale ne na úrovni služby pro obecné účely nové generace Upgrad úrovně služby Pro obecné účely nové generace nebo úroveň služby Business Critical.
Každá instance pro obecné účely SQL Managed Instance má až 35 TB úložiště vyhrazeného pro Azure místa na disku 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. Za nevyužité místo na disku se vám neúčtuje, ale celkový součet Azure velikostí disků Premium nesmí překročit 35 TB. V některých případech může spravovaná instance SQL, která nepotřebuje celkem 8 TB, překročit 35 TB Azure limit velikosti úložiště kvůli interní fragmentaci.
Instance pro obecné účely SQL Managed Instance může mít například jeden velký soubor o velikosti 1,2 TB umístěný na disku o kapacitě 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 SQL Managed Instance kvůli určité distribuci souborů dosáhnout limitu 35 TB vyhrazeného pro připojený disk Azure Premium, pokud ho 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. Nemůžete vytvářet ani obnovovat nové databáze, protože není dostatek místa pro nové diskové jednotky, i když celková velikost všech databází nedosahuje limitu velikosti instance. Vrácená chyba 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žijte sys.databases zobrazení k určení 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 v SQL Managed Instance a propojené servery nebo distribuované dotazy, které odkazují na aktuální instanci, někdy nemohou přeložit IP adresu místní instance. Tato chyba je přechodný problém.
Bez rozlišení
Zavádějící chybová zpráva při připojování k replice pro čtení pomocí neplatných přihlašovacích údajů
Když se pokusíte připojit k sekundární replikě instance úrovně Business Critical pro čtení pomocí ApplicationIntent=ReadOnly a neplatných přihlašovacích údajů, instance hlásí chybu, která značí, že master databáze je jen pro čtení. Instance nehlásí správně, že přihlašovací údaje jsou neplatné.
Rozdílové zálohy se neprovedou, když je instance propojená s SQL Server
Při konfiguraci link mezi SQL Server a Azure SQL Managed Instance se pro spravovanou instanci SQL pořídí automatizované úplné zálohy a zálohy transakčních protokolů bez ohledu na to, jestli jsou 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
Azure SQL Managed Instance služba vytvoří přihlášení systému pro účely transakční replikace. Toto přihlášení najdete v nástroji SSMS (v Průzkumník objektů>Security>Logins) nebo v zobrazení systému sys.syslogins. Formát přihlašovacího jména vypadá takto DBxCy\WF-abcde01234QWERTa 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 internímu problému se předchozí přihlášení neodstraní. Tato chyba může vést ke zvýšení počtu přihlášení. Tato přihlášení nepředstavují bezpečnostní hrozbu a můžete je bezpečně ignorovat. Neodstraňujte tato přihlášení, protože alespoň jedna z nich se používá pro transakční replikaci.
Microsoft Entra přihlášení a uživatelé nejsou v SSDT podporovány.
SQL Server Data Tools plně nepodporuje Microsoft Entra přihlášení a uživatele.
Zosobnění typů přihlášení Microsoft Entra se nepodporuje.
Zosobnění pomocí EXECUTE AS USER nebo EXECUTE AS LOGIN není podporováno pro následující principály Microsoft Entra:
- Aliasovaní uživatelé Microsoft Entra V tomto případě operace vrátí chybu
15517. - Přihlášení a uživatelé Microsoft Entra založené na aplikacích Microsoft Entra nebo objektech služby. V tomto případě operace vrací chyby
15517a15406.
Transakční replikace musí být po geografickém selhání překonfigurována.
Pokud povolíte transakční replikaci na databázi ve skupině pro převzetí služeb při selhání, administrátor služby SQL Managed Instance musí vyčistit všechny publikace na staré primární instanci a znovu je nakonfigurovat na nové primární po selhání a při převzetí služeb do jiné oblasti. Další informace naleznete v tématu Replikace.
Protokoly chyb se neuchovávají
Protokoly chyb, které jsou k dispozici v 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 mohou existovat mezery, protože SQL Managed Instance bylo několikrát přesunuto na několik virtuálních počítačů.
Vyřešeno
Cíl relace událostí system_health, event_file, není přístupný.
(Vyřešeno v březnu 2026) Když jste se pokusili přečíst obsah event_file cíle system_health relace událostí, 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 tomuto problému došlo v SQL Server Management Studio (SSMS) nebo při čtení dat relace pomocí funkce sys.fn_xe_file_target_read_file. Problém se vyřeší v obou případech.
Tato změna chování byla nezamýšleným důsledkem požadované opravy zabezpečení. Zákazníci můžou tento problém obejít vytvořením vlastního ekvivalentu relace system_health s cílem event_file v úložišti objektů blob Azure. 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.
Prozatímní pokyny k aktualizacím časových pásem 2024 pro Paraguay
(Vyřešeno v únoru 2026)
14. října 2024 oznámila vláda Paraguayan trvalou změnu politiky časového pásma. Paraguay nyní zůstává na letním čase (DST) ročně, efektivně přijímá UTC-3 jako svůj standardní čas. V důsledku toho hodiny nepřešly o 60 minut v 12:00 23. března 2025, jak bylo naplánováno dříve. Tato změna se týká standardního časového pásma Paraguay. Microsoft vydali související aktualizace Windows v únoru a březnu 2025. Spravované instance SQL používající ovlivněné časové pásmo odrážejí tuto změnu a odpovídají novému posunu UTC-3.
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í
(Vyřešeno v listopadu 2025)
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 naslouchacího koncového bodu této skupiny.
Dočasná nedostupnost instance při použití poslechového rozhraní skupiny při selhání během operace škálování.
(Vyřešeno v dubnu 2025)
Škálování spravované instance SQL někdy vyžaduje přesunutí 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 SQL účastní skupiny převzetí služeb při selhání, záznam DNS odpovídající jejímu přidruženému posluchači skupiny převzetí služeb při selhání (posluchač pro čtení i zápis, pokud je instance aktuálním geo-primárním serverem, nebo posluchač pro čtení, pokud je instance aktuálním geo-sekundárním serverem) se přesune do nového virtuálního clusteru.
V současném návrhu operace škálování se DNS záznamy nasluchače odeberou z výchozího virtuálního clusteru před tím, než se spravovaná instance SQL plně migruje do nového virtuálního clusteru. V některých situacích tento návrh vede k delší době, 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:
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
Tento problém se vyřeší změnou návrhu operace škálování.
Tabulka ručních záloh v msdb nezachová uživatelské jméno
(Vyřešeno v srpnu 2023) Nedávno zavedená podpora automatických záloh v msdb současné době neobsahuje informace o uživatelském jménu.
Pokud používáte ověřování SQL Server, uživatelská jména s znakem @se nepodporují.
Uživatelská jména obsahující symbol @ uprostřed (například abc@xy) se nemůžou přihlásit pomocí ověřování SQL Server.
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 obnovení ruční zálohy databází, kterou jste provedli ve spravované instanci SQL, bez CHECKSUM selhat. 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 SQL s povolenou CHECKSUM možností.
Oprávnění ke skupině prostředků se neaplikuje na SQL Managed Instance
Když použijete roli přispěvatele SQL Managed Instance Azure pro skupinu prostředků (RG), nevztahuje se na SQL Managed Instance a nemá žádný vliv.
Workaround: Nastavte roli přispěvatele SQL Managed Instance pro uživatele na úrovni předplatného.
Zavádějící chybová zpráva na portálu Azure naznačující nutnost opětovného vytvoření Service Principal.
Na stránce služba Active Directory admin portálu Azure pro Azure SQL Managed Instance se může zobrazit následující chybová zpráva, i když Service Principal již existuje:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Tuto chybovou zprávu můžete ignorovat, pokud již existuje Service Principal pro SQL spravovanou instanci a/nebo funguje ověřování Microsoft Entra na spravované instanci SQL.
Pokud chcete zkontrolovat, jestli aplikační objekt existuje, přejděte na stránku Enterprise aplikace na portálu Azure. V rozevíracím seznamu Typ aplikace vyberte Spravované identity, vyberte Apply a do vyhledávacího pole zadejte název spravované instance SQL. 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, instanční objekt spravované instance SQL se znovu vytvoří. V takovém případě přiřaďte nově vytvořenému Service Principal oprávnění ke čtení v rámci Microsoft Entra ID, aby ověřování Microsoft Entra fungovalo správně. Tento krok můžete spustit také pomocí Azure PowerShell pomocí instrukcí.
Cíl event_file relace událostí system_health není přístupný.
(Částečně vyřešeno v květnu 2025) Když se pokusíte přečíst obsah event_file cíle system_health relace událostí, zobrazí se chyba 40538, "Platná adresa URL začínající https:// je vyžadována jako hodnota pro každou zadanou cestu k souboru".
Původně k tomuto problému došlo v SQL Server Management Studio (SSMS) nebo při čtení dat relace pomocí funkce sys.fn_xe_file_target_read_file.
V květnu 2025 se tento problém vyřešil pro čtení dat relací z aplikace SSMS. Problém se nevyřeší při čtení dat událostí pomocí sys.fn_xe_file_target_read_file funkce.
Tato změna chování je nezamýšleným důsledkem požadované opravy zabezpečení. Tento problém můžete vyřešit vytvořením vlastního ekvivalentu relace system_health s cílem event_file v 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.
Dialogy Service Broker napříč databázemi potřebují po upgradu úrovně služby znovu inicializaci.
(Vyřešeno v lednu 2020) Dialogy Service Broker mezi databázemi přestanou po změně operace úrovně služby doručovat zprávy službám 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 instancí v SQL Managed Instance způsobí, že se u všech databází změní hodnota service_broke_guid v zobrazení sys.databases. Všechny DIALOG vytvořené pomocí příkazu BEGIN DIALOG, který odkazuje na zprostředkovatele služeb v jiných databázích, přestane 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 nedoručené zprávy zůstanou po změně úrovně služby, přečtěte si zprávy ze zdrojové fronty a znovu je odešlete do cílové fronty.
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 Docs.
Související obsah
Seznam aktualizací a vylepšení SQL Managed Instance najdete v tématu SQL Managed Instance aktualizace služeb.
Pro aktualizace a vylepšení všech služeb Azure viz Aktualizace služeb.