A felügyelt Azure SQL-példány ismert problémái
A következőre vonatkozik:
Felügyelt Azure SQL-példány
Ez a cikk felsorolja a felügyelt Azure SQL-példánysal kapcsolatos jelenleg ismert problémákat, valamint azok megoldási dátumát vagy lehetséges kerülő megoldását. A felügyelt Azure SQL-példányokkal kapcsolatos további információkért tekintse meg az áttekintést és az újdonságokat.
Feljegyzés
A Microsoft Entra ID az Azure Active Directory (Azure AD) új neve. Jelenleg frissítjük a dokumentációt.
Ismert problémák
Áthidaló megoldás
A system_health esemény munkamenetének event_file célja nem érhető el
Amikor megkísérli elolvasni az event_file esemény-munkamenet célhelyének system_health tartalmát, a 40538-as hibaüzenet jelenik meg: "A megadott fájlútértékként érvényes URL-cím szükséges a "https://" kezdettől kezdve." Ez az SQL Server Management Studióban vagy a munkamenet-adatok sys.fn_xe_file_target_read_file függvény használatával történő olvasásakor fordul elő.
Ez a viselkedésbeli változás nem szándékos következménye egy nemrégiben szükséges biztonsági javításnak. Egy további módosítás megvalósíthatóságát vizsgáljuk, amely lehetővé tenné az ügyfelek számára, hogy biztonságosan használják a munkamenetet a system_health felügyelt példányon. Addig is az ügyfelek megkerülhetik ezt a problémát, ha létrehoznak egy saját megfelelőt a system_health munkamenethez egy event_file azure blobtárolóban lévő célhellyel. További információkért, beleértve a saját megfelelőjének system_healthlétrehozásához módosítható munkamenet létrehozásához system_health szükséges T-SQL-szkriptet is, olvassa el a system_health munkamenet használata című témakört.
Az eljárás sp_send_dbmail sikertelen lehet, ha @query a paramétert nov22FW-kompatibilis felügyelt példányokon használják
A paraméter használatakor az eljárás sp_send_dbmail sikertelen @query lehet, és ez azokra a példányokra vonatkozik, amelyeken engedélyezve van a 2022. novemberi funkcióhullám. Hibák akkor fordulnak elő, ha a tárolt eljárást 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 létrehozott egyéni fiókban, és nem a Sysadmin-fiókban hívja sp_send_dbmail meg a hívást.
Í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
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
Időközi útmutató Chile 2022-ben történő időzóna-frissítéséhez
2022. augusztus 8-án a chilei kormány hivatalos bejelentést tett a nyári időszámítás (DST) időzónájának módosításáról. 2022. szeptember 10-én, szombaton 12:00-tól 2023. április 1-jén, szombat 12:00-ig a hivatalos idő 60 percet vesz igénybe. A változás a következő három időzónát érinti: Pacific SA Standard Time, Easter Island Standard Time és Magallanes Standard Time. Az érintett időzónákat használó Felügyelt Azure SQL-példányok nem tükrözik a módosításokat , amíg a Microsoft nem ad ki operációsrendszer-frissítést ennek támogatásához, és az Azure SQL Managed Instance szolgáltatás az operációs rendszer szintjén veszi fel a frissítést.
Megkerülő megoldás: Ha módosítania kell a felügyelt példányok érintett időzónáit, vegye figyelembe a korlátozásokat , és kövesse a dokumentáció útmutatását.
A kapcsolattípus módosítása nem befolyásolja a feladatátvételi csoport végpontja közötti kapcsolatokat
Ha egy példány részt vesz egy feladatátvételi csoportban, a példány kapcsolattípusának módosítása nem lép érvénybe a feladatátvevő csoport figyelővégpontján keresztül létrehozott kapcsolatok esetében.
Megkerülő megoldás: A feladatátvételi csoport elvetése és újbóli létrehozása a kapcsolattípus módosítása után.
A paraméter használatakor az eljárás sp_send_dbmail átmenetileg meghiúsulhat @query
A paraméter használatakor az eljárás sp_send_dbmail átmenetileg meghiúsulhat @query . Ha ez a probléma jelentkezik, az eljárás sp_send_dbmail minden második végrehajtása hibaüzenettel Msg 22050, Level 16, State 1 és üzenettel Failed to initialize sqlcmd library with error number -2147467259meghiúsul. A hiba megfelelő megjelenítéséhez az eljárást a paraméter @exclude_query_outputalapértelmezett 0 értékével kell meghívni, ellenkező esetben a hiba propagálása nem történik meg.
Ezt a problémát egy ismert hiba okozza, amely a sp_send_dbmail megszemélyesítés és a kapcsolatkészletezés használatával kapcsolatos.
A probléma megkerüléséhez csomagolja be az e-mailek kimeneti paraméterre @mailitem_idtámaszkodó újrapróbálkozásra szolgáló logikába való küldésének kódját. Ha a végrehajtás sikertelen, akkor a paraméter értéke NULL, ami azt jelzi sp_send_dbmail , hogy még egyszer meg kell hívni az e-mail sikeres elküldéséhez. Íme egy példa erre az újrapróbálkozásos logikára.
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
Az elosztott tranzakciók a felügyelt példány kiszolgálómegbízhatósági csoportból való eltávolítása után végrehajthatók
A 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 az elosztott tranzakciók végrehajtásának előfeltételei. A felügyelt 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. Van egy áthidaló megoldás, amellyel meggyőződhet arról, hogy az elosztott tranzakciók le vannak tiltva, és ez a felügyelt példányon a felhasználó által kezdeményezett manuális feladatátvétel .
Az elosztott tranzakciók nem hajthatóak végre a felügyelt példány skálázási művelete után
A felügyelt SQL-példányok skálázási műveletei, amelyek tartalmazzák a szolgáltatási szint vagy a virtuális magok számát, visszaállítják a kiszolgáló megbízhatósági csoport beállításait a háttérrendszeren, és letiltják az elosztott tranzakciók futtatását. Kerülő megoldásként törölje és hozza létre az új kiszolgálói megbízhatósági csoportot az Azure Portalon.
A korábban törölt logikai kiszolgáló nevével megegyező nevű felügyelt SQL-példány nem hozható létre
A rendszer dns-rekordot <name>.database.windows.com hoz létre, amikor logikai kiszolgálót hoz létre az Azure for Azure SQL Database-ben , és amikor létrehoz egy felügyelt SQL-példányt. A DNS-rekordnak egyedinek kell lennie. Ilyen esetben, ha létrehoz egy logikai kiszolgálót az SQL Database-hez, majd törli azt, a név rekordokból való felszabadítása előtt hét napos küszöbérték van. Ebben az időszakban a felügyelt SQL-példány nem hozható létre a törölt logikai kiszolgáló nevével megegyező néven. Áthidaló megoldásként használjon egy másik nevet a felügyelt SQL-példányhoz, vagy hozzon létre egy támogatási jegyet a logikai kiszolgáló nevének kiadásához.
A szolgáltatásnév nem fér hozzá a Microsoft Entra-azonosítóhoz és az AKV-hoz
Bizonyos körülmények között probléma merülhet fel a Microsoft Entra ID (korábbi nevén Azure Active Directory) és az Azure Key Vault (AKV) szolgáltatások eléréséhez használt szolgáltatásnévvel kapcsolatban. Ennek eredményeképpen ez a probléma hatással van a Microsoft Entra-hitelesítés és a felügyelt SQL-példány transzparens adattitkosításának (TDE) használatára. Ez időszakos kapcsolati problémaként jelenhet meg, vagy nem tud olyan utasításokat futtatni, mint az vagy CREATE LOGIN/USER FROM EXTERNAL PROVIDEREXECUTE AS LOGIN/USER. Előfordulhat, hogy a TDE ügyfél által felügyelt kulccsal való beállítása egy új felügyelt Azure SQL-példányon bizonyos körülmények között nem működik.
Megkerülő megoldás: Ha meg szeretné akadályozni, hogy ez a probléma a felügyelt SQL-példányon a frissítési parancsok végrehajtása előtt jelentkezik, vagy ha már tapasztalta ezt a problémát a frissítési parancsok után, nyissa meg az Azure Portalt, és nyissa meg az SQL Managed Instance Active Directory felügyeleti oldalát. Ellenőrizze, hogy megjelenik-e a következő hibaüzenet: "A felügyelt példánynak szolgáltatásnévre van szüksége a Microsoft Entra-azonosító eléréséhez. Kattintson ide a szolgáltatásnév létrehozásához". Ha ezt a hibaüzenetet észlelte, jelölje ki, és kövesse a hiba elhárításáig megadott részletes utasításokat.
A manuális feladatátvétel korlátozása a portálon a feladatátvételi csoportok esetében
Ha egy feladatátvételi csoport különböző Azure-előfizetésekben vagy erőforráscsoportokban lévő példányokra terjed ki, a manuális feladatátvétel nem indítható el a feladatátvételi csoport elsődleges példányából.
Megkerülő megoldás: A feladatátvétel kezdeményezése a portálon keresztül a geo-másodlagos példányról.
Az SQL-ügynök szerepköreinek kifejezett EXECUTE engedélyekre van szükségük a nem sysadmin (nem rendszergazdai) bejelentkezésekhez
Ha nem sysadmin típusú bejelentkezéseket ad hozzá bármely SQL Agent rögzített adatbázis-szerepkörhöz, akkor fennáll egy probléma, amely miatt explicit VÉGREHAJTÁSI engedélyeket kell adni az master adatbázisban három tárolt eljáráshoz a bejelentkezések működéséhez. Ha ez a probléma jelentkezik, megjelenik a hibaüzenet The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) .
Megkerülő megoldás: Miután bejelentkezett egy SQL Agent rögzített adatbázis-szerepkörbe (SQLAgentUserRole, SQLAgentReaderRole vagy SQLAgentOperatorRole), a szerepkörökhöz hozzáadott összes bejelentkezéshez hajtsa végre a következő T-SQL-szkriptet, hogy explicit módon adjon VÉGREHAJTÁSI engedélyeket a felsorolt tárolt eljárásokhoz.
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];
A memóriabeli OLTP memóriakorlátjai nincsenek alkalmazva
A üzletileg kritikus szolgáltatásszint bizonyos esetekben nem alkalmazza megfelelően a memóriaoptimalizált objektumok maximális memóriakorlátját. A felügyelt SQL-példány lehetővé teheti, hogy a számítási feladatok több memóriát használjanak a memórián belüli OLTP-műveletekhez, ami befolyásolhatja a példány rendelkezésre állását és stabilitását. Előfordulhat, hogy a memóriában lévő, a korlátokat elérő OLTP-lekérdezések nem hiúsulnak meg azonnal. A memóriabeli OLTP-memóriát használó lekérdezések hamarabb meghiúsulnak, ha elérik a korlátokat.
Megkerülő megoldás: Monitorozza a memórián belüli OLTP-tárolóhasználatot az SQL Server Management Studióval annak érdekében, hogy a számítási feladat ne használjon több memóriát, mint a rendelkezésre álló memória. Növelje a virtuális magok számától függő memóriakorlátokat, vagy optimalizálja a számítási feladatot, hogy kevesebb memóriát használjon.
Hibás hiba történt egy nem üres fájl eltávolításakor
Az SQL Server és a felügyelt SQL-példány nem teszi lehetővé, hogy a felhasználó elvetjen egy nem üres fájlt. Ha egy utasítással próbál eltávolítani egy nem megfelelő adatfájlt ALTER DATABASE REMOVE FILE , a rendszer nem adja vissza azonnal a hibát Msg 5042 – The file '<file_name>' cannot be removed because it is not empty . A felügyelt SQL-példány továbbra is megpróbálja elvetni a fájlt, és a művelet 30 perc után Internal server errormeghiúsul.
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 letiltja a szolgáltatási szint frissítését vagy a meglévő példány átméretezését, és új példányokat hoz létre a visszaállítási folyamat befejezéséig.
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. A példánykészletekben lévő példányokra nincs hatással. A szolgáltatásszint-műveletek létrehozása vagy módosítása nem hiúsul meg vagy időtúllépést okoz. A visszaállítási folyamat befejezése vagy megszakítása után folytatódnak.
Megkerülő megoldás: Várjon, amíg a visszaállítási folyamat befejeződik, vagy megszakítja 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.
Előfordulhat, hogy a feladatátvétel után újra kell konfigurálni üzletileg kritikus szolgáltatási szinten lévő erőforrás-kormányzót
Előfordulhat , hogy 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 maximális példány tárterületének módosítása) után az Erőforrás-vezérlő funkció, amely lehetővé teszi a felhasználói számítási feladatokhoz rendelt erőforrások korlátozását.
Megkerülő megoldás: Futtassa ALTER RESOURCE GOVERNOR RECONFIGURE rendszeresen vagy egy SQL Agent-feladat részeként, amely végrehajtja az SQL-feladatot, amikor a példány elindul, ha Resource Governort használ.
Az adatbázisközi Szolgáltatásközvetítő párbeszédpaneleket újra kell újrainicializálni a szolgáltatási szint frissítése után
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 a feladó üzenetsorában találhatók. A felügyelt SQL-példány virtuális magjainak vagy példányainak tárterületének bármilyen módosítása esetén service_broke_guid a sys.databases nézetben lévő érték minden adatbázis esetében megváltozik. Minden olyan DIALOG BEGIN DIALOG utasítással létrehozott, amely más adatbázisban lévő Szolgáltatásközvetítőkre hivatkozik, nem küld üzeneteket a célszolgáltatásnak.
Megkerülő megoldás: A szolgáltatásszint frissítése előtt állítsa le az adatbázisközi Szolgáltatásközvetítő párbeszédpanel-beszélgetéseket használó tevékenységeket, majd később újraincializálja őket. Ha vannak olyan üzenetek, amelyek a szolgáltatási szint módosítása után nem kézbesíthetők, olvassa el az üzeneteket a forrássorból, és adja vissza őket a célsorba.
Tárterület kapacitásának túllépése kis méretű adatbázisfájlok miatt
CREATE DATABASE, ALTER DATABASE ADD FILEés RESTORE DATABASE az utasítások meghiúsulhatnak, mert a példány elérheti az Azure Storage korlátját.
A felügyelt SQL-példányok minden általános célú példánya legfeljebb 35 TB tárterülettel rendelkezik az Azure Premium Disk számára. Mindegyik adatbázisfájlt egy külön fizikai lemezen helyezi el a rendszer. A lemezek 128 GB, 256 GB, 512 GB, 1 TB vagy 4 TB méretűek lehetnek. A lemezen fel nem használt területért nem fizetendő díj, de a prémium szintű Azure-lemezek összmérete nem haladhatja meg a 35 TB-ot. Bizonyos esetekben az összesen 8 TB lemezterületet nem igénylő felügyelt példány mérete a belső töredezettség miatt meghaladhatja a tárterület méretére vonatkozó 35 TB-os Azure-korlátot.
A felügyelt SQL-példányok általános célú példánya például egy 1,2 TB méretű nagy fájllal rendelkezhet, amely egy 4 TB-os lemezre van helyezve. 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 felügyelt SQL-példányok elérhetik a csatolt Azure Premium Disk számára fenntartott 35 TB-os korlátot, amikor esetleg nem számít rá.
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. Az új adatbázisok nem hozhatók létre és nem állíthatók vissza, 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. Az ebben az esetben visszaadott hiba nem egyértelmű.
A fennmaradó fájlok számának megállapításához rendszernézeteket használhat. Ha eléri ezt a korlátot, próbálkozzon néhány kisebb fájl ürítésével és törlésével a DBCC SHRINKFILE utasítást használva, vagy váltson az üzletileg kritikus szintre, amelyre nem érvényes ez a korlát.
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 nézet segítségével sys.databases feloldhatja a tényleges adatbázisnevet a fizikai adatbázis nevéből, GUID-adatbázis-azonosítók formájában megadva:
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
A felügyelt SQL-példány CLR-moduljai, valamint az aktuális példányra hivatkozó csatolt kiszolgálók vagy elosztott lekérdezések néha nem tudják feloldani egy helyi példány IP-címét. Ez a hiba átmeneti probléma.
Az ugyanazon példányon belüli két adatbázis tranzakciós hatóköre nem támogatott
(2020 márciusában megoldódott) A TransactionScope .NET osztálya nem működik, ha a rendszer két lekérdezést küld két, ugyanazon példányon belüli adatbázisba ugyanabban a tranzakciós hatókörben:
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();
}
Megkerülő megoldás (2020 márciusa óta nem szükséges): Sql Csatlakozás ion használata. Módosítsa azDatabase(Sztring) függvényt, hogy két kapcsolat helyett egy másik adatbázist használjon egy kapcsolati környezetben.
Nincs megoldás
A tranzakciós replikációhoz használt rendszer-bejelentkezések számának növelése
Az Azure SQL Managed Instance szolgáltatás tranzakciós replikáció céljából hoz létre rendszer-bejelentkezést. Ez a bejelentkezés az SSMS-ben (a Biztonság objektumkezelőben, a Bejelentkezések szakaszban) vagy a rendszernézetben sys.sysloginstalálható. A bejelentkezési név formátuma így néz 'DBxCy\WF-abcde01234QWERT'ki, é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 a rendszer hibája miatt az előző bejelentkezés nem törlődik. Ez a bejelentkezések számának növekedéséhez vezethet. Ezek a bejelentkezések nem jelentenek biztonsági fenyegetést. Biztonságosan figyelmen kívül hagyhatók. Ezeket a bejelentkezéseket nem szabad törölni, mert legalább az egyiket tranzakciós replikációhoz használják.
msdb a manuális biztonsági mentések táblája nem őrzi meg a felhasználónevet
Nemrég bevezettük az automatikus biztonsági mentések msdbtámogatását, de a tábla jelenleg nem tartalmaz felhasználónevet.
A Microsoft Entra-bejelentkezések és -felhasználók nem támogatottak az SSDT-ben
Az SQL Server Data Tools nem támogatja teljes mértékben a Microsoft Entra-bejelentkezéseket és -felhasználókat.
A Microsoft Entra bejelentkezési típusok megszemélyesítése nem támogatott
Az alábbi Microsoft Entra-tagok megszemélyesítése EXECUTE AS USEREXECUTE AS LOGIN nem támogatott:
- Aliasos Microsoft Entra-felhasználók. Ebben az esetben a következő hiba jelenik meg:
15517. - Microsoft Entra-bejelentkezések és felhasználók a Microsoft Entra-alkalmazások vagy szolgáltatásnevek alapján. Ebben az esetben a következő hibák jelennek meg:
15517és15406.
A tranzakciós replikációt újra kell konfigurálni a geo feladatátvétel után
Ha a tranzakciós replikáció engedélyezve van egy feladatátvételi csoportban lévő adatbázisban, a felügyelt SQL-példány rendszergazdájának törölnie kell a régi elsődleges példány összes kiadványát, és újra kell konfigurálnia őket az új elsődleges helyen, miután feladatátvétel történt egy másik régióba. További információ: Replikáció.
tempdb a struktúra és a tartalom újra létrejön
Az tempdb adatbázis mindig 12 adatfájlra van felosztva, és a fájlstruktúra nem módosítható. A fájlonkénti maximális méret nem módosítható, és új fájlok nem vehetők fel a fájlba tempdb. Az tempdb adatbázis mindig üres adatbázisként jön létre, amikor a példány elindul vagy meghiúsul, és a benne végrehajtott tempdb módosítások nem maradnak meg.
A hibanaplók nem maradnak meg
A felügyelt SQL-példányban 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. A hibanapló előzményei között rések lehetnek, mert a felügyelt SQL-példányt többször áthelyezték több virtuális gépen.
Ideiglenes elérhetetlenség a feladatátvételi csoport figyelőjével a skálázási művelet során
A felügyelt 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 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, azaz í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 skálázási művelet tervezésekor a figyelő DNS-rekordjai el lesznek távolítva az eredeti virtuális fürtből, mielőtt maga a felügyelt példány teljesen áttelepítené magát az új virtuális fürtre, ami bizonyos esetekben hosszabb időt vehet igénybe, amíg a példány IP-címe nem oldható fel a figyelő használatával. Ez idő alatt a figyelővégpont használatával skálázott példányt elérni próbáló SQL-ügyfél a következő hibaüzenettel várhatja a bejelentkezési hibákat: "40532-es hiba: A bejelentkezés által kért "xxx.xxx.xxx.xxx" kiszolgáló nem nyitható meg. A bejelentkezés sikertelen volt. (Microsoft SQL Server, Hiba: 40532)".
A problémát a skálázási művelet újratervezésével hárítjuk el.
Feloldva
A külső tábla lekérdezése „nem támogatott” hibaüzenettel meghiúsul
A külső tábla lekérdezése meghiúsulhat a "Külső táblákon végzett lekérdezések nem támogatottak az adatbázis aktuális szolgáltatási szintjével vagy teljesítményszintjével. Fontolja meg az adatbázis szolgáltatási vagy a teljesítményszintjének növelését.” Az Azure SQL Managed Instance-példány által támogatott külső táblák egyetlen típusa a PolyBase külső táblák (előzetes verzióban). A PolyBase külső táblák lekérdezésének engedélyezéséhez engedélyeznie kell a PolyBase-t a felügyelt példányon a parancs futtatásával sp_configure .
Az Azure SQL Database Elastic Query funkciójával kapcsolatos külső táblák nem támogatottak a felügyelt SQL-példányokban, de a létrehozásuk és lekérdezésük nem volt kifejezetten letiltva. A PolyBase külső táblák támogatásával új ellenőrzéseket vezettek be, amelyek letiltják a felügyelt példányban lévő bármilyen típusú külső tábla lekérdezését, kivéve, ha a PolyBase engedélyezve van.
Ha nem támogatott Elastic Query külső táblákat használ az Azure SQL Database-ben vagy az Azure Synapse-ben lévő adatok felügyelt példányból való lekérdezéséhez, akkor inkább a Csatolt kiszolgáló funkciót kell használnia. Ha társított kiszolgálókapcsolatot szeretne létesíteni a felügyelt SQL-példány és az SQL Database között, kövesse a jelen cikk utasításait. A felügyelt SQL-példány és az SQL Synapse összekapcsolt kiszolgálói kapcsolatának létrehozásához tekintse meg a részletes utasításokat. Mivel a csatolt kiszolgáló kapcsolatának konfigurálása és tesztelése némi időt vesz igénybe, áthidaló megoldásként ideiglenes megoldásként engedélyezheti a Rugalmas lekérdezés funkcióhoz kapcsolódó külső táblák lekérdezését:
Megkerülő megoldás: Hajtsa végre a következő parancsokat (példányonként egyszer), amelyek engedélyezik a külső táblák lekérdezését:
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
SQL Server-hitelesítés használata esetén a@azonosítójú felhasználónevek nem támogatottak
A középső "@" szimbólumot tartalmazó felhasználónevek (például 'abc@xy') 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
Bizonyos körülmények között előfordulhat, hogy a CHECKSUM nélküli felügyelt példányon készített adatbázisok manuális biztonsági mentése nem állítható vissza. 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: Készítsen manuális biztonsági másolatot az adatbázisokról felügyelt példányokon, ha engedélyezve van a CHECKSUM.
Az ügynök nem válaszol, ha módosítja, letiltja vagy engedélyezi a meglévő feladatokat
Bizonyos körülmények között a meglévő feladatok módosítása, letiltása vagy engedélyezése miatt az ügynök nem válaszolhat. A probléma automatikusan elhárítható az észleléskor, ami az ügynökfolyamat újraindítását eredményezi.
A felügyelt SQL-példányra nem alkalmazott erőforráscsoport engedélyei
Ha a felügyelt SQL-példány közreműködői Azure-szerepköre egy erőforráscsoportra (RG) van alkalmazva, az nincs alkalmazva a felügyelt SQL-példányra, és nincs hatása.
Megkerülő megoldás: Felügyelt SQL-példány közreműködői szerepkör beállítása a felhasználók számára az előfizetés szintjén.
Az SQL Agent-feladatokat megszakíthatja az ügynökfolyamat újraindítása
(2020 márciusában megoldódott) Az SQL Agent minden feladat indításakor létrehoz egy új munkamenetet, fokozatosan növelve a memóriahasználatot. Annak érdekében, hogy ne érje el a belső memóriakorlátot, amely blokkolná az ütemezett feladatok végrehajtását, az ügynökfolyamat újraindul, amint a memóriahasználat eléri a küszöbértéket. Ez az újraindítás pillanatában futó feladatok végrehajtásának megszakítását eredményezheti.
@query paraméter nem támogatott a sp_send_db_mail
A @query sp_send_db_mail eljárás paramétere nem működik.
Félrevezető hibaüzenet az Azure Portalon, amely a szolgáltatásnév rekreációjára utal
A felügyelt Azure SQL-példányhoz készült Azure Portal Active Directory felügyeleti oldala a következő hibaüzenetet jelenítheti meg, annak ellenére, hogy a szolgáltatásnév már létezik:
"A felügyelt példánynak szolgáltatásnévre van szüksége a Microsoft Entra-azonosító (korábbi nevén Azure Active Directory) eléréséhez. Kattintson ide szolgáltatásnév létrehozásához"
Ezt a hibaüzenetet figyelmen kívül hagyhatja, ha már létezik szolgáltatásnév a felügyelt példányhoz, és/vagy a felügyelt példányon a Microsoft Entra-hitelesítés működik.
Annak ellenőrzéséhez, hogy létezik-e szolgáltatásnév, lépjen az Azure Portal Vállalati alkalmazások lapjára, válassza a Felügyelt identitások lehetőséget az Alkalmazástípus legördülő listából, válassza az Alkalmaz lehetőséget, és írja be a felügyelt példány nevét a keresőmezőbe. Ha a példány neve megjelenik az eredménylistában, a szolgáltatásnév 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 a hibaüzenetből kiválasztotta a hivatkozást, a felügyelt példány szolgáltatásnévét újra létrehozták. Ebben az esetben rendelje hozzá a Microsoft Entra ID olvasási engedélyeit az újonnan létrehozott szolgáltatásnévhez, hogy a Microsoft Entra-hitelesítés megfelelően működjön. Ezt az Azure PowerShell használatával teheti meg az alábbi utasításokat követve.
Tartalmi közreműködés
Az Azure SQL dokumentációjában való közreműködéshez tekintse meg a Docs közreműködői útmutatóját.
Következő lépések
A felügyelt SQL-példány frissítéseinek és fejlesztéseinek listáját az SQL Managed Instance szolgáltatásfrissítései című témakörben találja.
Az összes Azure-szolgáltatás frissítéseit és fejlesztéseit a Szolgáltatásfrissítések című témakörben találja.
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: