Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A következőre vonatkozik: :
Azure SQL Managed Instance
Ez a cikk a Azure SQL Managed Instance jelenleg ismert problémáit, valamint azok megoldási dátumát vagy lehetséges kerülő megoldását sorolja fel. Az Azure SQL Managed Instance további információkért tekintse meg: Mi az Azure SQL Managed Instance? és Mi újdonság az Azure SQL Managed Instance-ben?
Jegyzet
Microsoft Entra ID korábban Azure Active Directory (Azure AD) néven ismerték.
Ismert problémák
Van áthidaló megoldás
Az MSDASQL-t használó csatolt kiszolgálói lekérdezések a 7416-os hibával meghiúsulnak
Az ODBC-hez készült Microsoft OLE DB-szolgáltatót (MSDASQL) használó és szolgáltatói sztringet (@provstr) használó társított kiszolgálólekérdezések a következő hibával hiúsulhatnak meg:
Msg 7416, Level 16
Access to the remote server is denied because no login-mapping exists.
Ez a probléma olyan bejelentkezéseket érint, amelyek nem tagjai a sysadmin rögzített kiszolgálói szerepkörnek. Ez akkor is előfordulhat, ha a csatolt kiszolgáló és a bejelentkezési leképezések megfelelően vannak konfigurálva.
A MSDASQL szolgáltatót használó egyes csatolt kiszolgálókonfigurációkban a Database Engine szigorúbb kapcsolatérvényesítési ellenőrzése elutasíthatja a korábbi buildekben engedélyezett kapcsolatokat.
Megkerülő megoldás: Használja az alábbi lehetőségek egyikét:
Távolítsa el a @provstr a csatolt kiszolgáló definíciójából, ha a konfigurációhoz nincs szükség rá.
Adja hozzá
User ID=<value>@provstr. A bejelentkezésnek továbbra is meg kell adniaUID-t a szolgáltatói karaktersorozatban.
Az érintett bejelentkezési sysadmin megadása szintén megakadályozza a hibát, de nem ajánlott.
Visszaállítási műveletek meghibásodásai a SQL Managed Instance áthelyezése után
Ha áthelyez egy adatbázist az Azure SQL Managed Instance-ba a SQL Server 2019 vagy későbbi verzióiból, miközben az accelerated database recovery engedélyezve van, de a persistent version store (PVS) nem a PRIMARY fájlcsoporthoz van konfigurálva, előfordulhatnak visszaállítási műveletek hibái a cél felügyelt SQL-példányon.
A probléma megoldásához állítsa a perzistent verziótárolót (PVS) ELSŐDLEGES értékre a forrás SQL Server adatbázison, mielőtt áttelepítené azt a SQL Managed Instance. Ha már migrálta az adatbázist anélkül, hogy a PVS-t PRIMARY értékre állította volna, beállíthatja a forrás SQL Server adatbázison, majd újra migrálhatja az adatbázist SQL Managed Instance.
Gyorsított adatbázis-helyreállítás nem használható az SQL Managed Instance-re való áttérés után.
A SQL Server 2019-től kezdve, ha egy adatbázist áthelyez az Azure SQL Managed Instance-re, és a forrásadatbázisban az accelerated database recovery le van tiltva, nem használhat gyorsított adatbázis-helyreállítást a cél felügyelt SQL-példányon.
A probléma megoldásához győződjön meg arról, hogy gyorsított adatbázis-helyreállítás aktiválva legyen a forrás SQL Server adatbázison, mielőtt áttelepítené azt az SQL Managed Instance-re. Ha a gyorsított adatbázis-helyreállítás engedélyezése nélkül már migrálta az adatbázist, engedélyezheti azt a forrás SQL Server adatbázison, majd újra migrálhatja az adatbázist egy SQL kezelt példányba.
SQL Server 2017-ben és a korábbi verziókban nem támogatott a gyorsított adatbázis-helyreállítás, ezért ez a probléma nem vonatkozik a SQL Server ezen verzióiból áttelepített adatbázisokra.
A Service Broker nem használható a SQL Managed Instance-re való áttelepítés után.
Ha az Azure SQL Managed Instance alá migrál egy adatbázist, és a Szolgáltatás-közvetítő le van tiltva a forrásadatbázison, akkor nem használhatja a Szolgáltatás-közvetítőt a célzott SQL Managed Instance-példányon.
A probléma megoldásához engedélyezze a Service Broker-t a forrás SQL Server-adatbázison, mielőtt áttelepítené a SQL Managed Instance-ba. Ha a Service Broker engedélyezése nélkül már migrálta az adatbázist, először engedélyezheti azt az SQL Server forrásadatbázison, majd újra migrálhatja az adatbázist az SQL Managed Instance-ra.
A biztonsági másolatok megőrzési idejének módosítása az ingyenes ajánlathoz
Az adatbázisok biztonsági mentési megőrzési szabályzatát csak az ingyenes felügyelt SQL-példányban módosíthatja a REST API, PowerShell és Azure CLI parancsok használatával. A biztonsági mentés adatmegőrzési házirendje nem módosítható a Azure portálon.
A másodlagos olvasási bejelentkezés a "HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING" hosszú várakozása miatt meghiúsult
Ez a hiba kivételként jelenhet meg a Microsoft OLE DB Driver 19 for SQL Server illesztőprogram esetében, amikor egy failover csoport írásvédett másodlagos replikájához próbál csatlakozni vagy egy Managed Instance hivatkozáson keresztül replikált adatbázishoz.
Ez a hiba akkor fordul elő, ha a másodlagos replika nem érhető el a bejelentkezésekhez, mert a sorverziók hiányoznak az olyan tranzakciók esetében, amelyek a másodlagos replika újraindításakor vagy újrahasznosításakor voltak folyamatban, akár karbantartás céljából, akár feladatátvétel miatt. Amikor egy példány újraindul vagy átáll, a rendszer törli a tárolt tempdb verzióadatokat. A másodlagos olvasási lekérdezések megszakadnak, ha a feladatátvétel vagy az újraindítás előtt hosszú ideig futó aktív tranzakciók kezdődtek.
A probléma megoldásához helyezze vissza vagy véglegesítse az aktív tranzakciókat az elsődleges replikán. A hiba elkerülése érdekében minimalizálja a hosszú ideig futó írási tranzakciókat az elsődleges replikán.
Error 8992, amikor a DBCC CHECKDB-t SQL Server adatbázison futtatja, amely SQL Managed Instance-ból származik.
A következő hibaüzenet jelenhet meg, ha a DBCC CHECKDB parancsot egy SQL Server 2022-adatbázison futtatja, miután törölt egy indexet vagy egy indexet tartalmazó táblát, és az adatbázis Azure SQL Managed Instance származik, például egy biztonsági mentési fájl visszaállítása után, vagy a SQL Managed Instance hivatkozás funkcióból:
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.
A probléma megoldásához először távolítsa el az indexet, vagy az indexet tartalmazó táblát a forrásadatbázisból az Azure SQL Managed Instance-ben, majd állítsa vissza, vagy csatolja újra az adatbázist a SQL Server 2022-höz. Ha az adatbázist nem lehet újra létrehozni a forrásból Azure SQL Managed Instance, forduljon Microsoft ügyfélszolgálatához a probléma megoldásához.
Figyelmeztetés
Ha particionált indexet hoz létre egy táblán, miután elvetett egy indexet az ebben a forgatókönyvben leírtak szerint, a tábla elérhetetlenné válik.
1412-s hiba Managed Instance hivatkozás létrehozásakor
Amikor először hoz létre egy hivatkozást, a folyamat első része teljes biztonsági másolatot készít az adatbázisról az elsődleges replikáról a másodlagos replikára. A teljes biztonsági mentés üzembe helyezése után a hivatkozás elkezdi replikálni az adatokat az elsődleges replika különbségadatainak a másodlagos replikára való alkalmazásával. Ez a folyamat határozatlan ideig folytatódik, amíg ki nem ad egy feladatátvételi parancsot, vagy el nem távolítja a hivatkozást.
Ha a tranzakciós napló mentésére az elsődleges replikán kerül sor a teljes biztonsági mentés kezdetekor, a tranzakciós napló csonkolódik. A hivatkozás létrehozása 1412-as hibával meghiúsul, mivel a tranzakciónaplóban a kezdeti vetéshez szükséges adatok már nem érhetők el.
Ha a Azure SQL Managed Instance SQL Server hibanaplójában 1412-s hiba jelenik meg, akkor drop kell újra létrehoznia a hivatkozást. A probléma előzetes elkerüléséhez szüneteltetje a tranzakciónaplók biztonsági mentését a kezdeti bevezetési fázisban. Ha a kezdeti bevezetési fázisban szükség van a tranzakciónapló biztonsági mentésére, akkor nyisson meg egy nyitott tranzakciót a napló csonkolásának megakadályozása érdekében. További információ: Error 1412 Managed Instance hivatkozás létrehozásakor a hivatkozás funkció hibaelhárítási útmutatójában.
Az Azure portál hosszú távú biztonsági mentéseinek listája az azonos nevű aktív és törölt adatbázisok biztonsági mentési fájljait jeleníti meg
A hosszú távú biztonsági mentések a Backups lapon található Azure SQL Managed Instance Azure portállapján listázhatók és kezelhetők. Az oldal felsorolja az aktív vagy törölt adatbázisokat, a hosszú távú biztonsági mentésekkel kapcsolatos alapvető információkat, valamint a biztonsági mentések kezelésére szolgáló hivatkozást. Amikor kiválasztja a Manage linket, megnyílik egy új oldalpanel a biztonsági másolatok listájával. A szűrési logikával kapcsolatos probléma miatt a lista az aktív adatbázis és az azonos nevű törölt adatbázisok biztonsági másolatait is megjeleníti. Ez különös figyelmet igényel a törléshez szükséges biztonsági másolatok kiválasztásakor, hogy ne töröljön biztonsági másolatokat egy rossz adatbázisból.
Megkerülő megoldás: A listán szereplő biztonsági mentési idő (UTC) adatok felhasználásával különböztetheti meg a példányon különböző időszakokban használt azonos nevű adatbázisokhoz tartozó biztonsági másolatokat. Másik lehetőségként használja a PowerShell parancsokat Get-AzSqlInstanceDatabaseLongTermRetentionBackup és Remove-AzSqlInstanceDatabaseLongTermRetentionBackup, vagy a CLI parancsokat az sql midb ltr-backup list és az sql midb ltr-backup delete a hosszú távú biztonsági mentések kezeléséhez, miközben a DatabaseState paramétert és a DatabaseDeletionTime visszatérési értéket használja az adatbázisok biztonsági mentéseinek szűréséhez.
Az eljárás sp_send_dbmail sikertelen lehet @query paraméter használatakor
A sp_send_dbmail tárolt eljárás meghiúsulhat, amikor a @query paramétert használják. Hibák akkor fordulnak elő, ha a tárolt eljárást egy sysadmin-fiókban hajtják végre.
Ezt a problémát egy ismert hiba okozza, amely a sp_send_dbmail megszemélyesítés használatával kapcsolatos.
Megkerülő megoldás: Győződjön meg arról, hogy a megfelelő egyéni fiók alatt hívja meg a sp_send_dbmail, és nem a sysadmin fiók alatt.
Íme egy példa arra, hogyan hozhat létre dedikált fiókot, és hogyan módosíthatja az e-maileket sp_send_dbmailküldő meglévő objektumokat.
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
Az elosztott tranzakciók végrehajthatók, miután eltávolították a felügyelt SQL-példányt a kiszolgáló megbízhatósági csoportjából
kiszolgálómegbízhatósági csoportok olyan felügyelt példányok közötti megbízhatósági kapcsolatot hoznak létre, amelyek előfeltételei elosztott tranzakciókvégrehajtásának. A felügyelt SQL-példány kiszolgálómegbízhatósági csoportból való eltávolítása vagy a csoport törlése után továbbra is végrehajthat elosztott tranzakciókat. Az elosztott tranzakciók letiltásának ellenőrzéséhez hajtsa végre a felhasználó által kezdeményezett manuális feladatátvételt a felügyelt SQL-példányon .
A korábban törölt logikai kiszolgáló nevével megegyező nevű SQL Managed Instance nem hozható létre
Amikor létrehoz egy logikai kiszolgálót az Azure-ban az Azure SQL Database vagy SQL Managed Instance számára, a rendszer létrehoz egy DNS-rekordot <name>.database.windows.com számára. Ennek a DNS-rekordnak egyedinek kell lennie. Ha létrehoz egy logikai kiszolgálót az SQL Database-hez, majd törli azt, a név hét napig marad fenntartva. Ebben az időszakban nem hozhat létre olyan SQL Managed Instance, amelynek neve megegyezik a törölt logikai kiszolgáló nevével. Áthidaló megoldásként használjon másik nevet a SQL Managed Instance számára, vagy hozzon létre egy támogatási jegyet a logikai kiszolgáló név felszabadításához.
A szolgáltatási főszereplő nem fér hozzá a Microsoft Entra ID-hoz és az Azure Kulcstárhoz.
Bizonyos körülmények között probléma merül fel a Microsoft Entra ID (korábban Azure Active Directory) és Azure Key Vault (AKV) szolgáltatások eléréséhez használt Service Principal-lel kapcsolatban. Ennek eredményeképpen ez a probléma hatással van a Microsoft Entra hitelesítés és a transzparens adattitkosítás (TDE) használatára az SQL Managed Instance esetében. Előfordulhat, hogy ezt a problémát időszakos kapcsolati problémaként tapasztalja, vagy nem tudja futtatni az ilyen vagy ehhez hasonló CREATE LOGIN/USER FROM EXTERNAL PROVIDEREXECUTE AS LOGIN/USERutasításokat. Előfordulhat, hogy a TDE ügyfél által felügyelt kulccsal való beállítása új Azure SQL Managed Instance bizonyos körülmények között nem is működik.
Workaround: Ha meg szeretné akadályozni, hogy ez a probléma megjelenjen az SQL Managed Instance-ben, mielőtt bármilyen frissítési parancsot futtat, vagy ha a frissítések után már tapasztalta ezt a problémát, lépjen az SQL Managed Instance Overview lapjára az Azure portálon. A Settings területen válassza a Microsoft Entra ID lehetőséget a SQL Managed Instance Microsoft Entra ID rendszergazdai lap eléréséhez. Keresse meg a következő hibaüzenetet:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Ha ezt a hibaüzenetet tapasztalja, jelölje ki, és kövesse a hiba elhárításáig megadott részletes utasításokat.
Hibás hiba történt egy nem üres fájl eltávolításakor
SQL Server és SQL Managed Instance nem engedélyezi a felhasználónak, hogy töröljön egy nem üres fájlt. Ha egy utasítássalALTER DATABASE REMOVE FILE próbál eltávolítani egy nem üres adatfájlt, a következő hibaüzenet jelenik meg:
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.
A szolgáltatásszint módosítása és a példányműveletek létrehozása a folyamatban lévő adatbázis-visszaállítás által blokkolva van
A folyamatban lévő RESTORE utasítás, a Data Migration Service migrálási folyamata és a beépített időponthoz kötött visszaállítás blokkolhatja a szolgáltatási szint frissítéseit, vagy átméretezheti a meglévő példányt, és új példányokat hozhat létre, amíg a visszaállítási folyamat befejeződik.
A visszaállítási folyamat letiltja ezeket a műveleteket a felügyelt példányokon és példánykészleteken ugyanabban az alhálózatban, ahol a visszaállítási folyamat fut. Az példánykészletekben lévő példányokat nem érinti. A szolgáltatásszint-műveletek létrehozása vagy módosítása nem hiúsul meg és nem lép időtúllépésbe. Ezek csak akkor folytatódnak, ha a visszaállítási folyamat befejeződött vagy megszakításra került.
Kerülő megoldás: Várjon, amíg a visszaállítási folyamat befejeződik, vagy mondja le a visszaállítási folyamatot, ha a létrehozási vagy frissítési szolgáltatási szintű művelet nagyobb prioritással rendelkezik.
A Resource Governor újrakonfigurálásra szorul egy olvasható másodlagos replikán a feladatátvételt követően.
Az Erőforrás-vezérlő funkció, amely lehetővé teszi a felhasználói számítási feladathoz rendelt erőforrások korlátozását, helytelenül osztályozhat bizonyos felhasználói számítási feladatokat a feladatátvétel vagy a szolgáltatásszint felhasználó által kezdeményezett módosítása (például a maximális virtuális mag vagy a példány maximális tárterületének módosítása) után.
Megkerülő megoldás: Futtassa ALTER RESOURCE GOVERNOR RECONFIGURE rendszeresen vagy egy SQL Agent-feladat részeként, amely végrehajtja az SQL-feladatot az olvasható másodlagos replika indításakor, ha Erőforrás-vezérlőt használ.
Tárterület túllépése kis adatbázisfájlokkal
CREATE DATABASE, ALTER DATABASE ADD FILE és RESTORE DATABASE utasítások sikertelenek lehetnek, mert a példány eléri az Azure Storage általános célú szolgáltatási szintjének korlátját, de nem a Next-gen General Purpose szint frissítésén vagy az üzleti szempontból kritikus szolgáltatási szinten.
A SQL Managed Instance minden általános célú példánya legfeljebb 35 TB tárterülettel rendelkezik Azure Prémium szintű lemezterülethez. Minden adatbázisfájl külön fizikai lemezre kerül. A lemez mérete 128 GB, 256 GB, 512 GB, 1 TB vagy 4 TB lehet. A lemezen nem használt területért nem kell fizetnie, de a prémium szintű lemezméretek Azure teljes összege nem haladhatja meg a 35 TB-ot. Bizonyos esetekben előfordulhat, hogy egy felügyelt SQL-példány, amely nem igényel összesen 8 TB-ot, a belső töredezettség miatt meghaladhatja a 35 TB-os Azure tárterület-korlátot.
Előfordulhat például, hogy a SQL Managed Instance általános célú példánya egy 1,2 TB méretű, 4 TB-os lemezre helyezett nagyméretű fájllal rendelkezik. Emellett 248 fájl is lehet, amelyek egyenként 1 GB méretűek, és amelyek külön 128 GB-os lemezeken vannak elhelyezve. Ebben a példában:
- A lefoglalt lemezterület teljes mérete 1 x 4 TB + 248 x 128 GB = 35 TB.
- A példányon lévő adatbázisok teljes fenntartott területe 1 x 1,2 TB + 248 x 1 GB = 1,4 TB.
Ez a példa azt szemlélteti, hogy bizonyos körülmények között a fájlok meghatározott eloszlása miatt a SQL Managed Instance egy példánya elérheti a 35 TB-os korlátot, amely egy csatolt Azure Premium Disk számára van fenntartva, amikor nem biztos, hogy elvárja.
Ebben a példában a meglévő adatbázisok továbbra is működnek, és probléma nélkül növekedhetnek, amíg nem adnak hozzá új fájlokat. Nem hozhat létre és nem állíthat vissza új adatbázisokat, mert nincs elegendő hely az új lemezmeghajtók számára, még akkor sem, ha az összes adatbázis teljes mérete nem éri el a példány méretkorlátját. A visszaadott hiba nem egyértelmű.
Rendszernézetek használatával azonosíthatja a fennmaradó fájlok számát,. Ha eléri ezt a korlátot, próbálja meg kiüríteni és törölni néhány kisebb fájlt a DBCC SHRINKFILE utasítással vagy váltson a üzletileg kritikus szintre, amely nem rendelkezik ezzel a korláttal.
Az adatbázisnevek helyett a GUID-értékek jelennek meg
Számos rendszernézet, teljesítményszámláló, hibaüzenet, XEvents és hibanapló-bejegyzés a tényleges adatbázisnevek helyett GUID-adatbázis-azonosítókat jelenít meg. Ne hivatkozz ezekre a GUID-azonosítókra, mert előfordulhat, hogy a jövőben tényleges adatbázisnevekre cserélik őket.
Megkerülő megoldás: A sys.databases nézetben a tényleges adatbázisnevet feloldhatja a fizikai adatbázis nevéből, amelyet GUID adatbázis azonosítók formájában adtak meg.
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
A CLR-modulok és a csatolt kiszolgálók néha nem tudnak helyi IP-címre hivatkozni
Az aktuális példányra hivatkozó CLR-modulok SQL Managed Instance és csatolt kiszolgálókon vagy elosztott lekérdezésekben néha nem tudják feloldani egy helyi példány IP-címét. Ez a hiba átmeneti probléma.
Nincs megoldás
Félrevezető hibaüzenet, amikor érvénytelen hitelesítő adatokkal csatlakozik egy olvasási replikához
Amikor egy üzletileg kritikus szintű példány olvasási-másodlagos replikájához próbál csatlakozni ApplicationIntent=ReadOnly és érvénytelen hitelesítő adatokkal, a példány hibát jelez, amely azt jelzi, hogy az master adatbázis írásvédett. A példány nem jelzi helyesen, hogy a hitelesítő adatok érvénytelenek.
A differenciális biztonsági másolatokat nem készítenek, ha egy példány hozzá van kapcsolva az SQL Serverhez.
Ha linket konfigurál SQL Server és Azure SQL Managed Instance között, a felügyelt SQL-példányon automatikusan teljes és tranzakciónaplós biztonsági mentés készül, függetlenül attól, hogy az elsődleges szerepkörben van-e. A különbségi biztonsági mentések azonban jelenleg nem készülnek, ami a vártnál hosszabb visszaállítási időhöz vezethet.
A tranzakciós replikációhoz használt rendszer-bejelentkezések számának növelése
Azure SQL Managed Instance szolgáltatás létrehoz egy rendszer-bejelentkezést tranzakciós replikáció céljából. Ezt a bejelentkezést az SSMS-ben (Object Explorer>Security>Logins) vagy a sys.syslogins rendszernézetben találja. A bejelentkezési név formátuma így néz DBxCy\WF-abcde01234QWERTki, és a bejelentkezés nyilvános kiszolgálói szerepkörrel rendelkezik. Bizonyos feltételek mellett a rendszer újra létrehozza ezt a bejelentkezést, és belső probléma miatt az előző bejelentkezés nem törlődik. Ez a hiba a bejelentkezések számának növekedéséhez vezethet. Ezek a bejelentkezések nem jelentenek biztonsági fenyegetést, és nyugodtan figyelmen kívül hagyhatja őket. Ne törölje ezeket a bejelentkezéseket, mert a rendszer legalább egyet használ a tranzakciós replikációhoz.
Microsoft Entra bejelentkezések és felhasználók nem támogatottak az SSDT-ben
SQL Server Data Tools nem támogatják teljes mértékben Microsoft Entra bejelentkezéseket és felhasználókat.
A Microsoft Entra bejelentkezési típusok megszemélyesítése nem támogatott
A EXECUTE AS USER vagy EXECUTE AS LOGIN használatával történő megszemélyesítés nem támogatott a következő Microsoft Entra tagok esetében:
- Alias-szal rendelkező Microsoft Entra felhasználók. Ebben az esetben a művelet hibát
15517ad vissza. - Microsoft Entra bejelentkezéseket és felhasználókat Microsoft Entra alkalmazások vagy szolgáltatásnevek alapján. Ebben az esetben a művelet hibákat
15517és15406.
A tranzakciós replikációt újra kell konfigurálni a geo feladatátvétel után
Ha egy feladatátvételi csoport adatbázisán engedélyezi a tranzakciós replikációt, a SQL Managed Instance rendszergazdának törölnie kell a régi elsődlegesen lévő összes kiadványt, és újra kell konfigurálnia őket az új elsődlegesen, miután feladatátvétel történt egy másik régióba. További információért lásd: Replikáció.
A hibanaplók nem maradnak meg
A SQL Managed Instance elérhető hibanaplók nem maradnak meg, és méretük nem szerepel a maximális tárterületkorlátban. Feladatátvétel esetén előfordulhat, hogy a hibanaplók automatikusan törlődnek. Rések lehetnek a hibanapló előzményeiben, mivel az SQL Managed Instance-t több alkalommal áthelyezték több virtuális gépre.
Megoldani
A system_health esemény munkamenetének event_file célja nem érhető el
(2026 márciusában megoldva) Amikor megpróbálta beolvasni az event_file esemény-munkamenet céljának system_health tartalmát, a 40538-as hibaüzenet jelenik meg, amely szerint a megadott fájlfájlok értékeként a "https://" kezdetű érvényes URL-cím szükséges."
Ez a probléma SQL Server Management Studio (SSMS) vagy a munkamenet adatainak a sys.fn_xe_file_target_read_file függvény használatával történő beolvasása során jelentkezett. A probléma mindkét esetben megoldódott.
Ez a viselkedésbeli változás nem várt következménye volt egy szükséges biztonsági javításnak. Az ügyfelek megkerülhetik ezt a problémát, ha a system_health munkamenet saját megfelelőjeként létrehoznak egy event_file célt Azure blobtárolóban. További információkért, beleértve a system_health munkamenet létrehozásához szükséges T-SQL-szkriptet is, amely a system_healthsaját megfelelőjének létrehozásához módosítható, olvassa el A system_health munkamenethasználata című témakört.
Átmeneti útmutatás a 2024-es paraguayi időzóna-frissítésekhez
(2026 februárjában feloldva)
2024. október 14-én a paraguayi kormány bejelentette az időzóna-politika állandó módosítását. Paraguay nyári időszámítást egész évben fenntartja, elfogadva ezzel az UTC-3-at, mint az alapértelmezett időzónát. Ennek eredményeképpen az órák nem haladtak 60 perccel 2025. március 23-án 12:00-kor a korábban ütemezett módon. Ez a változás a Paraguay Standard időzónát érinti. Microsoft 2025 februárjában és márciusában kiadott kapcsolódó Windows frissítéseket. Az érintett időzónát használó FELÜGYELT SQL-példányok tükrözik ezt a változást, és igazodnak az új UTC-3 eltoláshoz.
A kapcsolattípus módosítása nem befolyásolja a feladatátvételi csoport végpontja közötti kapcsolatokat
(2025 novemberében megoldódott)
Ha egy példány részt vesz egy feladatátvételi csoport, a példány kapcsolattípusának módosítása nem lép érvénybe a feladatátvevő csoport figyelővégpontján létrehozott kapcsolatok esetében.
Ideiglenes példányelérhetetlenség a feladatátvételi csoport figyelőjén keresztül a skálázási művelet során
(2025 áprilisában feloldva)
A felügyelt SQL-példányok skálázásához néha egy másik virtuális fürtre kell áthelyezni a példányt a társított szolgáltatás által karbantartott DNS-rekordokkal együtt. Ha a felügyelt SQL-példány egy feladatátvételi csoportban vesz részt, a társított feladatátvevő csoport figyelőjének megfelelő DNS-rekord (olvasási-írási figyelő, ha a példány az aktuális geo-elsődleges írásvédett figyelő, ha a példány az aktuális geo-másodlagos) az új virtuális fürtre kerül.
Az aktuális méretezési művelet tervezete szerint a figyelő DNS-rekordjait eltávolítják az eredeti virtuális fürtből, mielőtt teljesen áthelyezné a felügyelt SQL-példányt az új virtuális fürtbe. Bizonyos esetekben ez a kialakítás hosszabb időt eredményez, amely során a példány IP-címe nem oldható fel a figyelő használatával. Ez időközben, ha egy SQL-ügyfél próbál egy példányhoz hozzáférni, amelyet a figyelő végpont használatával skáláznak, bejelentkezési hibákra számíthat a következő hibaüzenettel:
Error 40532: Cannot open server "xxx.xxx.xxx.xxx" requested by the login. The login failed. (Microsoft SQL Server, Error: 40532).
A problémát a skálázási művelet újratervezésével hárítjuk el.
Az msdb manuális biztonsági mentéseinek táblázata nem őrzi meg a felhasználónevet
(2023 augusztusában feloldva) Az automatikus biztonsági mentések msdb nemrég bevezetett támogatása jelenleg nem tartalmaz felhasználónevet.
Ha SQL Server hitelesítést használ, a @névvel rendelkező felhasználónevek nem támogatottak
A középső @ szimbólumot (például abc@xy) tartalmazó felhasználónevek nem tudnak SQL Server hitelesítéssel bejelentkezni.
Sikertelen lehet a manuális biztonsági mentés visszaállítása a CHECKSUM nélkül
(2020 júniusában megoldódott) Bizonyos körülmények között a felügyelt SQL-példányon készített adatbázisok manuális biztonsági mentésének CHECKSUM nélküli visszaállítása sikertelen lehet. Ilyen esetekben próbálkozzon újra a biztonsági mentés visszaállításával, amíg sikeres nem lesz.
Megkerülő megoldás: Manuálisan készítsen biztonsági másolatot a felügyelt SQL-példányokon CHECKSUM lévő adatbázisokról engedélyezve.
Az erőforráscsoportra vonatkozó engedélyek nincsenek alkalmazva a SQL Managed Instance
Ha a SQL Managed Instance közreműködői Azure szerepkört egy erőforráscsoportra (RG) alkalmazza, az nem vonatkozik a SQL Managed Instance, és nincs hatása.
Munka: SQL Managed Instance közreműködői szerepkör beállítása a felhasználók számára az előfizetés szintjén.
Félrevezető hibaüzenet az Azure portálon, amely a Szolgáltatásfelelős újralétrehozására utal.
A Azure SQL Managed Instance Azure portáljának Active Directory rendszergazdai oldala a következő hibaüzenetet jelenítheti meg, annak ellenére, hogy a szolgáltatásnév már létezik:
Managed Instance needs a Service Principal to access Microsoft Entra ID. Click here to create a Service Principal.
Ezt a hibaüzenetet figyelmen kívül hagyhatja, ha már létezik Szolgáltatásfelelős a felügyelt SQL-példányhoz, és a Microsoft Entra hitelesítés a felügyelt SQL-példányhoz működik.
A Szolgáltatásnév meglétének ellenőrzéséhez lépjen az Vállalati alkalmazások lapra az Azure portálon, válassza a Felügyelt identitások lehetőséget a Alkalmazás típusa legördülő listából, válassza az Alkalmaz lehetőséget, és írja be a felügyelt SQL-példány nevét a keresőmezőbe. Ha a példány neve megjelenik az eredménylistában, a szolgáltatási főazonosító már létezik, és nincs szükség további műveletekre.
Ha már követte a hibaüzenet utasításait, és kiválasztotta a hivatkozást, a rendszer újra létrehozza a felügyelt SQL-példány szolgáltatásnevét. Ebben az esetben rendeljen Microsoft Entra ID olvasási engedélyeket az újonnan létrehozott Szolgáltatási főnévhez, hogy a Microsoft Entra hitelesítés megfelelően működjön. Ezt a lépést az Azure PowerShell is futtathatja az utasítások követésével.
A system_health esemény munkamenetének event_file célja nem érhető el
(2025 májusában részben megoldották) Amikor megkísérli elolvasni az event_filesystem_health esemény-munkamenet céljának tartalmát, a következő 40538-as hibaüzenet jelenik meg: "A megadott fájlútértékként érvényes URL-cím https:// szükséges."
Ez a probléma eredetileg SQL Server Management Studio (SSMS) vagy a munkamenet adatainak a sys.fn_xe_file_target_read_file függvény használatával történő beolvasása során jelentkezett.
2025 májusában ez a probléma megoldódott az SSMS munkamenetadatainak olvasása során. Az eseményadatok sys.fn_xe_file_target_read_file funkcióval történő olvasásakor a probléma nem oldódik meg.
Ez a viselkedésbeli változás egy szükséges biztonsági javítás nem szándékos következménye. A probléma megkerüléséhez hozza létre saját magának megfelelő system_health munkamenetet egy event_file célponttal az Azure Blob Storage rendszerben. További információkért, beleértve a system_health munkamenet létrehozásához szükséges T-SQL-szkriptet is, amely a system_healthsaját megfelelőjének létrehozásához módosítható, olvassa el A system_health munkamenethasználata című témakört.
Az adatbázisközi Szolgáltatásközvetítő párbeszédpaneleknek újrainicializálásra van szükségük a szolgáltatási szint frissítése után
(2020 januárjában feloldva) Az adatbázisközi szolgáltatásközvetítő párbeszédpanelek a szolgáltatásszint-művelet módosítása után nem küldik el az üzeneteket más adatbázisok szolgáltatásainak. Az üzenetek nem vesznek el, és megtalálhatók a feladói üzenetsorban. Az SQL Managed Instance vCore-ok vagy példány tárhely méretének bármilyen módosítása megváltoztatja az service_broke_guid nézetben szereplő értékét az összes adatbázis esetében. Minden olyan DIALOGBEGIN DIALOG utasítással létrehozott, amely más adatbázisok szolgáltatásközvetítőire hivatkozik, nem küld üzeneteket a célszolgáltatásnak.
Megkerülő megoldás: Állítsa le az adatbázisközi Service Broker párbeszédpanel-beszélgetéseket használó tevékenységeket a szolgáltatási szint frissítése előtt, majd később újraincializálja őket. Ha a nem kézbesített üzenetek a szolgáltatási szint módosítása után is megmaradnak, olvassa el az üzeneteket a forrássorból, és adja vissza őket a célsorba.
Közreműködés a tartalomhoz
A Azure SQL dokumentációban való közreműködéshez tekintse meg a Docs közreműködői útmutatóját.
Kapcsolódó tartalom
A SQL Managed Instance frissítések és fejlesztések listáját a SQL Managed Instance szolgáltatásfrissítések című témakörben találja.
Az összes Azure szolgáltatás frissítései és fejlesztései: Szolgáltatás-frissítések.