Azure SQL Kezelt Példány – gyakori kérdések (GYIK)

A következőkre vonatkozik:Felügyelt Azure SQL-példány

Ez a cikk a felügyelt Azure SQL-példány kapcsolatos leggyakoribb kérdéseket tartalmazza.

Jegyzet

Microsoft Entra ID korábban Azure Active Directory (Azure AD) néven ismert.

Támogatott funkciók

Hol találom a felügyelt SQL-példányon támogatott funkciók listáját?

A felügyelt SQL-példányok támogatott funkcióinak listáját Felügyelt Azure SQL-példány funkcióinakcímű cikkben találja.

Az Azure SQL-felügyelt példány és az SQL Server szintaxisa és viselkedésbeli különbségeiért lásd az SQL Server T-SQL eltérései.

Műszaki specifikáció, erőforráskorlátok és egyéb korlátozások

Hol találhatók a felügyelt SQL-példány műszaki jellemzői és erőforráskorlátjai?

A rendelkezésre álló hardverjellemzőkért lásd a hardverkonfigurációk technikai különbségeit. Az elérhető szolgáltatási szintekről és jellemzőikről lásd a szolgáltatási szintekközötti technikai különbségeket.

Milyen szolgáltatási szintre jogosult vagyok?

Bármely ügyfél jogosult bármely szolgáltatási szintre. A Szoftvergarancia által lefedett Standard és Enterprise kiadási licencek is lefoglalhatók az SQL Server adatbázismotorhoz az Azure Hybrid Benefit (AHB) használatával az általános célú szolgáltatási szint (amely magában foglalja a következő generációs általános célú szolgáltatási szint frissítését) vagy az üzletileg kritikus szolgáltatási szint esetében. Az Azure Hybrid Benefit a következő cserearányokat használja: 1 Standard kiadás = 1 Általános célú, 1 Nagyvállalati kiadás = 1 Üzleti szempontból kritikus, 1 Nagyvállalati kiadás = 4 Általános célú és 4 Általános célú = 1 Nagyvállalati kiadás. További információ: Az Azure Hybrid Benefit konkrét jogai.

Milyen előfizetéstípusokat támogat a felügyelt SQL-példány?

A támogatott előfizetéstípusok listáját támogatott előfizetéstípusokcímű témakörben találja.

Mely Azure-régiók támogatottak?

A felügyelt példányok az Azure legtöbb régiójában hozhatók létre; lásd: felügyelt SQL-példányok támogatott régiói. Ha olyan régióban van szüksége felügyelt SQL-példányra, amely jelenleg nem támogatott, küldjön támogatási kérést az Azure Portalon keresztül.

Vannak kvótakorlátozások a felügyelt SQL-példányok üzembe helyezéséhez?

A felügyelt SQL-példánynak két alapértelmezett korlátja van: a használható alhálózatok számának korlátja, valamint a kiosztható virtuális magok számának korlátja. A korlátozások az előfizetések típusaitól és régióitól függően változnak. A regionális erőforráskorlátozások előfizetéstípus szerinti listájáért tekintse meg a regionális erőforráskorlátozások táblázatát. Ezek a puha korlátok igény szerint növelhetők. Ha az aktuális régiókban több felügyelt példányt szeretne kiépíteni, küldjön egy támogatási kérést a kvóta növeléséhez az Azure Portalon. További információ: Kéréskvóta növelése az Azure SQL Database.

Igény szerint növelhetem az adatbázis-korlátot (100) a felügyelt SQL-példányon?

A felügyelt SQL-példányonkénti 100 adatbázis korlátja egy szigorú korlát, amely az általános célú és az üzleti szempontból kritikus szolgáltatási szinteken nem módosítható. Legfeljebb 500 adatbázissal rendelkezhet az Következő generációs általános célú szolgáltatásszinten.

Hol lehet migrálni, ha több mint 16 TB adatom van?

Fontolja meg a számítási feladatnak megfelelő más Azure változatokra való migrálást: Azure SQL Database Hyperscale vagy SQL Server az Azure platformon futó virtuális gépeken.

Hol lehet migrálni, ha konkrét hardverkövetelményekkel rendelkezem, például nagyobb RAM-ról virtuális magra vagy több processzorra?

Érdemes lehet az Azure-beli virtuális gépeken SQL Serverre való migrálást vagy Azure SQL Database- memóriát/processzort optimalizálni.

Ismert problémák és hibák

Hol találhatók az ismert problémák és hibák?

A termékhibákkal és az ismert problémákkal kapcsolatban lásd ismert problémákat.

Új funkciók

Hol találhatók a legújabb funkciók és a funkciók a nyilvános előzetes verzióban?

Az új és előzetes verziójú funkciókért tekintse meg Újdonságokcímű témakört.

Felügyelt SQL-példány létrehozása, frissítése, törlése vagy áthelyezése

Hogyan építhetek ki felügyelt SQL-példányt?

Felügyelt SQL-példányt hozhat létre az Azure portálról, a PowerShellből, az Azure CLI-ből és az ARM-sablonokból.

Előkészíthetem a SQL-felügyelt példányokat egy meglévő előfizetésben?

Igen, kiépítheti a felügyelt SQL-példányt egy meglévő előfizetésben, ha az előfizetés a támogatott előfizetés-típusokhoz tartozik.

Miért nem sikerült kiépítsem egy felügyelt SQL-példányt egy olyan alhálózatban, amelynek neve számjegyből indul ki?

Az alhálózat nevének számjegyekkel való indítása egy mögöttes összetevő jelenlegi korlátozása, amely ellenőrzi az alhálózat nevét a regexben:

^[a-zA-Z_][^\\\/\:\*\?\"\<\>\|\`\'\^]*(?<![\.\s])$

A regexnek megfelelő és érvényes alhálózati nevek jelenleg támogatottak.

Hogyan méretezhetem a felügyelt SQL-példányomat?

A felügyelt SQL-példányt skálázhatja az Azure Portalról, a PowerShellből, az Azure CLI-ből vagy az ARM-sablonokból.

Áthelyezhetem a felügyelt SQL-példányomat egyik régióból a másikba?

Igen, megteheted. Útmutatásért lásd: Erőforrások áthelyezése régiók között.

Hogyan törölhetem a felügyelt SQL-példányomat?

A felügyelt SQL-példányokat az Azure Portalon, a PowerShellen, az Azure CLI-en vagy a Resource Manager REST API-ján keresztül törölheti.

Mennyi időt vesz igénybe egy példány létrehozása vagy frissítése, vagy egy adatbázis visszaállítása?

Az új felügyelt SQL-példány létrehozásához vagy a szolgáltatási szintek (virtuális magok, tárolók) módosításához szükséges várható idő számos tényezőtől függ. Lásd: Felügyeleti műveletek.

Adatbázis létrehozása, frissítése, törlése vagy áthelyezése

Elvethetek és újra létrehozhatok egy adatbázist egy felügyelt SQL-példányon ugyanazzal az adatbázisnévvel?

Az egyes adatbázisok visszaállítása a teljes meghatározott megőrzési időszak alatt garantált – még azokat az adatbázisokat is, amelyeket csak néhány másodperc után hoztak létre, majd töröltek. Adatbázis létrehozásakor, törlésekor vagy visszaállításakor a rendszer különböző időközönként készít biztonsági másolatot az adatok megőrzése érdekében, hogy az adott megőrzési időszak alatt visszaállítható legyen. Ha egy adatbázist a biztonsági mentési művelet befejezése előtt elvet a rendszer, az alábbi hibával blokkolhatja az elvetési műveletet:

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

A hiba elkerülése érdekében ellenőrizze az elvetési művelet állapotát, mielőtt egy azonos nevű adatbázist újranevelne. További információ: sys.dm_operation_status. Ha a művelet állapota Befejezettjelenik meg, visszaállíthatja vagy létrehozhat egy azonos nevű adatbázist.

A következő gyakori használati esetek valószínűleg ezt a hibát fogják tapasztalni:

• Ha több adatbázist törölnek, majd rövid időn belül egymás után ugyanazzal a névvel újra létrehoznak. Egy adatbázis elvetésekor a tranzakciónapló fennmaradó végének biztonsági mentése szinkron módon történik, mielőtt az elvetési művelet befejeződik, ahogy a képen látható:

  

  Nem hozható létre ugyanazzal a névvel rendelkező adatbázis, amíg a tail-log biztonsági másolatot nem készít és az elvetési művelet befejeződik. Az elvetési művelet szekvenciális jellege miatt a rövid idő alatt elvetett adatbázisok várólistába kerülnek, ami meghosszabbíthatja az adatbázisok elvetésének folyamatát, és késleltetheti az azonos nevű újak létrehozását.

• Ha egy adatbázis visszaállításra kerül, majd törlésre, mielőtt egy teljes biztonsági mentés létrejön. Az adatbázis visszaállításakor a visszaállítási folyamat első lépése az adatbázis új teljes biztonsági mentése. Ha megpróbál visszaállítani egy adatbázist, majd közvetlenül a teljes biztonsági mentés befejezése előtt elveti, nem tudja elvetni az adatbázist, és létrehozni egy másik adatbázist ugyanazzal a névvel, amíg a teljes biztonsági mentés el nem készül, és az adatbázis elvetési művelete befejeződik. Az adatbázis méretétől függően a teljes biztonsági mentés órákat is igénybe vehet.

Ingyenes felügyelt SQL-példányajánlat

Segítség! Már nem tudok csatlakozni a példányomhoz!

Valószínű, hogy elfogytak a kreditjei a hónapra vonatkozóan. Nyissa meg a felügyelt SQL-példányt az Azure Portalon, és ellenőrizze az állapotot. Ellenőrizze, hogy a példány leállt állapotban van-e az elégtelen kreditek miatt.

A vCore órákat a vártnál gyorsabban használom el. Hogyan láthatom, hogy mi használja pontosan a vCore órákat?

Ez a funkció jelenleg nem érhető el.

Visszaállíthatok egy adatbázist az ingyenes példányra?

Igen, visszaállíthatja az automatikus biztonsági mentéseket más felügyelt SQL-példányokról, vagy visszaállíthatja a helyszíni adatbázis biztonsági mentését az SQL Server Management Studio (SSMS) használatával , vagy futtathat egy RESTORE DATABASE parancsot, és megcélozhatja .bak a fájlokat az Azure Storage-ból vagy S3-gyűjtőkből.

Az ingyenes Azure SQL Managed Instance-ajánlat éles minőségű példányt biztosít?

Az erőforráskorlátozások ellenére az ingyenes felügyelt SQL úgy lett kialakítva, hogy hatás nélkül tesztelje a számítási feladatokat. Az ingyenes felügyelt SQL-példány használata során tapasztalt teljesítmény megegyezik a példány éles verziójának teljesítményével.

Frissíthetek nagyobb vagy hatékonyabb példányra?

Az ingyenes felügyelt SQL-példány csak 4 és 8 vCore-t kínál. Ha vállalata több erőforrással rendelkező példányt igényel, fontolja meg a teljes körű fizetős felügyelt SQL-példányra való frissítését.

Módosíthatom a biztonsági mentési beállítást georedundáns tárolásra?

Az ingyenes felügyelt SQL-példány legfeljebb 7 napig támogatja a PITR-t. Más biztonsági mentési beállítások nem módosíthatók az ingyenes felügyelt SQL-példányhoz.

Elnevezési konvenciók

A felügyelt SQL-példányok neve megegyezhet a helyszíni SQL Server-példány nevével?

A felügyelt SQL-példány nevének módosítása nem támogatott.

Módosíthatom a DNS-zóna előtagot?

Igen, a felügyelt SQL-példány alapértelmezett DNS-zónája .database.windows.net a sajátjával módosítható. A felügyelt SQL-példány hosztnevének, amely a teljes tartománynév része, beleértve a véletlenszerű alzónát (például sqlmiFQDN.randomized-subzone az .database.windows.net előtti rész), változatlannak kell maradnia.

Ha egy másik DNS-zónát szeretne használni az alapértelmezett helyett, például .contoso.com:

• Alias definiálásához használja az SQL Server ügyfélhálózati segédprogramját (CliConfg). Használhatja csak a felügyelt SQL-példány gazdagépnevét, vagy a felügyelt SQL-példány gazdagépnevét, majd egy egyéni tartománynevet. A CliConfg eszköz egy aliast ad hozzá a beállításjegyzékhez a HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo vagy a HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo alatt, attól függően, hogy a 64 bites verziót (C:\Windows\System32\cliconfg.exe) vagy a 32 bites verziót (C:\Windows\SysWOW64\cliconfg.exe) használja-e. Aliasokat csoportházirend vagy szkript használatával is felveheti, de mindkettőt használnia kell annak biztosítására, hogy a 32 bites és a 64 bites programok felismerhessék az aliast.
• Használjon CNAME rekordot a DNS-ben úgy, hogy a felügyelt SQL-példány gazdagépneve a felügyelt SQL-példány VNet-helyi végpontjának tartománynevére mutat. Ebben az esetben HostNameInCertificate=<VNet-local endpoint domain name> (ajánlott) vagy TrustServerCertificate=TRUE a Microsoft Entra-hitelesítés használatakor szükséges.
• Használjon A rekordot a DNS-ben, amelyben a felügyelt SQL-példány gazdagépneve a felügyelt SQL-példány IP-címére mutat. AZ IP-cím használata nem ajánlott, mivel az értesítés nélkül változhat. Ebben az esetben HostNameInCertificate=<VNet-local endpoint domain name> (ajánlott) vagy TrustServerCertificate=TRUE a Microsoft Entra-hitelesítés használatakor szükséges.

Áttelepítési lehetőségek

Hogyan migrálhatok önálló vagy rugalmas Azure SQL Database-készletből felügyelt SQL-példányba?

A felügyelt Azure SQL-példány számítási és tárolási méretenként ugyanazokat a teljesítményszinteket kínálja, mint az Azure SQL Database más üzembehelyezési lehetőségei. Ha egyetlen példányon szeretné összesíteni az adatokat, vagy olyan funkcióra van szüksége, amely kizárólag a felügyelt SQL-példányban támogatott. Az adatokat exportálási/importálási (BACPAC) funkcióval migrálhatja. Az SQL Database felügyelt SQL-példányra való migrálásának további módjai:

• Külső adatforrás használata
• SQLPackage használata
• BCP használata

Hogyan migrálhatom a példányadatbázisomat egyetlen Azure SQL Database-be?

Az egyik lehetőség az adatbázis BACPAC- exportálása, majd a BACPAC-fájlimportálása. Ez a módszer akkor ajánlott, ha az adatbázis kisebb, mint 100 GB.

Tranzakciós replikációs akkor használható, ha az adatbázis összes táblája elsődleges kulcsokkal rendelkezik, és az adatbázisban nincsenek memóriabeli OLTP-objektumok.

Hogyan migrálhatom az SQL Server-példányomat felügyelt SQL-példányba?

Az SQL Server-példány migrálásához tekintse meg az SQL Server és az Azure SQL Managed Instance útmutatót.

Hogyan migrálhatok más platformokról felügyelt SQL-példányra?

A más platformokról való migrálással kapcsolatos migrálási információkért tekintse meg az Azure Database migrálási útmutatói című témakört.

Teljesítmény

Hogyan hasonlíthatom össze az Azure SQL Managed Instance teljesítményét az SQL Server teljesítményével?

A felügyelt SQL-példány és az SQL Server teljesítmény-összehasonlításához jó kiindulópont az Azure SQL Managed Instance és az SQL Server teljesítmény-összehasonlításának ajánlott eljárásai.

Mi okozza a felügyelt SQL-példány és az SQL Server közötti teljesítménybeli különbségeket?

Lásd felügyelt SQL-példány és az SQL Serverközötti teljesítménybeli különbségek fő okait. A tranzakciónapló fájlmérete hatással lehet az általános célú felügyelt SQL-példány teljesítményére. További információért lásd: A naplófájl méretének hatása az általános célú felhasználásra.

Hogyan hangolhatom a felügyelt SQL-példány teljesítményét?

A felügyelt SQL-példány teljesítményét az alábbiakkal optimalizálhatja:

• Automatikus finomhangolás, amely mesterséges intelligencia és gépi tanulás alapú folyamatos teljesítményhangolással biztosítja a csúcsteljesítményt és a stabil számítási feladatokat.
• memóriabeli OLTP, amely javítja a tranzakciós feldolgozási számítási feladatok átviteli sebességét és késését, és gyorsabb üzleti elemzéseket biztosít.
• Az alkalmazás- és adatbázis-hangolás ajánlott eljárásainak alkalmazása.
• A kapcsolat típusának váltása proxyról átirányítási módra alacsonyabb késés és nagyobb átviteli sebesség érdekében, ha a számítási feladat sok kis tranzakcióból áll.

Hogyan hangolhatom tovább az általános célú felügyelt SQL-példány teljesítményét?

Az általános célú példányok teljesítményének javítása érdekében fontolja meg az adatfájl méreténeknövelését. Az Általános Célú példányok tárolási teljesítményének optimalizálásához tekintse meg az általános célú rétegre vonatkozó tárolási legjobb gyakorlatokat.

A lekérdezés időtartama túl hosszú. Hogyan elemezhetem a felügyelt SQL-példány várakozási statisztikáit?

Lásd: A felügyelt SQL-példányok várakozási statisztikáinak elemzése. A várakozási statisztikák olyan információk, amelyek segíthetnek megérteni, hogy miért hosszú a lekérdezés időtartama, és azonosíthatja azokat a lekérdezéseket, amelyek valamire várnak az adatbázismotorban.

Hogyan oldhatja meg a felügyelt SQL-példány "MSSQLSERVER_833" hibáját?

MSSQLSERVER_833 azt jelzi, hogy egy I/O-kérés végrehajtása több mint 15 másodpercet vett igénybe. Ez a hiba a felügyelt Azure SQL-példányban az általános infrastruktúra-feltételekhez kapcsolódik, nem pedig a számítási feladathoz. A felhőalapú környezetekben és a távoli tárolást használó rendszerekben több architekturális réteg van, amelyek egyetlen I/O-kérést érintenek. Ez a viselkedés várható, és a szolgáltatás ismert korlátozása, amely általában átmeneti hálózati problémákból vagy az Azure Storage-erőforrások ideiglenes elérhetetlenné válásából ered. A rendszer általában beavatkozás nélkül helyreáll.

Ez az előfordulás ritka, és nem befolyásolja a távoli tárolóba irányuló I/O-kérések átlagos késését. Az I/O-kérést kezdeményező számítási feladattól vagy száltól függően az ügyfelek megfigyelhetik az SQL-parancsok időtúllépéseit és a megnövekedett késést bizonyos helyzetekben, míg mások egyáltalán nem tapasztalnak semmilyen hatást. Például nem minden hosszan futó I/O-kérés akadályozza a műveleteket, mint például az előre olvasható oldalhozzáférés, amely gyakran nincs hatással az olvasási folyamatokra.

A következő generációs általános célú szolgáltatásszint-frissítés segíthet a probléma megoldásában, mivel többletköltség nélkül javítja a teljesítményt és a megbízhatóságot. A vásárlókat arra ösztönözzük, hogy fedezzék fel, ezáltal javítva a szolgáltatás minőségét.

Ha ez a hiba tartósan jelentkezik, fontolja meg a számítási feladatok mintáinak, a tárolási teljesítménynek és a hálózati konfigurációknak a áttekintését. Emellett fontolja meg az alacsony I/O-késési követelményekkel rendelkező alkalmazásokhoz tervezett üzletileg kritikus szolgáltatási szint használatát is.

Figyelés, metrikák és riasztások

Milyen lehetőségek vannak a felügyelt SQL-példány monitorozására és riasztására?

Az összes lehetséges lehetőségről a felügyelt SQL-példányok fogyasztásának és teljesítményének monitorozására és riasztására, lásd az Azure SQL Managed Instance monitorozási lehetőségeiről szóló blogbejegyzést. A felügyelt SQL-példány valós idejű teljesítményének monitorozásához lásd: Felügyelt Azure SQL-példány valós idejű teljesítménymonitorozása.

Hogyan monitorozhatom a felügyelt SQL-példány teljesítményét?

Lásd megfigyelés és teljesítmény optimalizálás.

Hogyan monitorozhatom a felügyelt SQL-példány valós idejű teljesítményét?

Lásd felügyelt Azure SQL-példányok valós idejű teljesítményfigyelését.

Használhatom az SQL Profilert a teljesítménykövetéshez?

Igen, az SQL Profiler támogatott a felügyelt SQL-példányon. További információ: SQL Profiler. Ehelyett azonban érdemes megfontolni az Extended Events használatát a "nyomkövetési" tevékenységhez, mivel ez kevésbé befolyásolja a figyelt példányt. További információ: Bővített események.

Támogatott a Database Advisor és a Lekérdezési teljesítményelemzés felügyelt SQL-példányok adatbázisai esetében?

Nem, ezek nincsenek támogatva. A DMVs és LekérdezéstárSQL Profiler és XEvents segítségével monitorozhatja az adatbázisokat.

Hogyan monitorozhatom a processzorhasználatot a felügyelt SQL-példányon?

Lásd Az SQL Server és az Azure SQLprocesszorhasználatának monitorozása című témakört.

Létrehozhatok metrikariasztásokat a felügyelt SQL-példányon?

Igen. Útmutatásért lásd: Felügyelt SQL-példányok riasztásainak létrehozása. További tippek és trükkök: a blog.

Létrehozhatok metrikariasztásokat egy felügyelt SQL-példány adatbázisán?

A riasztási metrikák csak felügyelt SQL-példányokhoz érhetők el. A felügyelt SQL-példányban lévő egyes adatbázisokra vonatkozó riasztási metrikák nem érhetők el.

Tárterület mérete

Mi a felügyelt SQL-példány maximális tárterületmérete?

A felügyelt SQL-példány tárolási mérete a kiválasztott szolgáltatási szinttől függ (általános célú, következő generációs általános célú vagy üzleti szempontból kritikus). A szolgáltatási szintek tárolási korlátozásairól Erőforráskorlátokcímű témakörben olvashat.

Mi a felügyelt SQL-példány minimális tárterületmérete?

A példányokban elérhető tárhely minimális mérete 32 GB. A tárterület 32 GB-os növekményekben adható hozzá a maximális tárterületméretig. Az első 32 GB ingyenes.

Növelhetim a példányhoz rendelt tárterületet a számítási erőforrásoktól függetlenül?

Igen, megvásárolhatja a kiegészítő tárhelyet a számítástól függetlenül, bizonyos mértékig. Nézze meg a maximális példány fenntartott tárhelyet a Táblában.

Hogyan optimalizálhatom a tárolási teljesítményt az általános célú szolgáltatási szinten?

A tárolási teljesítmény optimalizálásához tekintse meg a általános célú tárolás legjobb gyakorlatait.

Biztonsági mentés és visszaállítás

Levonták-e a biztonsági mentési tárhelyet az SQL-felügyelt példány tárolójából?

Nem, a biztonsági mentési tárterület nem lesz levonva a felügyelt SQL-példány tárterületéből. A biztonsági mentési tároló független a példány tárterületétől, és mérete nem korlátozott. A biztonsági mentési tárterületet a példányadatbázisok biztonsági mentésének megőrzéséhez szükséges időtartam korlátozza, amely legfeljebb 35 napig konfigurálható. További információ: Automatikus biztonsági mentések.

Hogyan tekinthetem meg, hogy mikor készül automatikus biztonsági mentés a felügyelt SQL-példányomon?

A felügyelt SQL-példányok automatikus biztonsági mentéseinek nyomon követéséhez tekintse át a biztonsági mentési tevékenység monitorozását.

Támogatott az igény szerinti biztonsági mentés?

Igen, az Azure Blob Storage-ban létrehozhat egy csak másolásra alkalmas teljes biztonsági másolatot, de az csak felügyelt SQL-példányra visszaállítható. További részletekért lásd: Csak másolási biztonsági másolatok. A csak másolással történő biztonsági mentés azonban nem lehetséges, ha az adatbázist a szolgáltatás által felügyelt TDE titkosítja, mivel a titkosításhoz használt tanúsítvány nem érhető el. Ilyen esetben az időponthoz kötött visszaállítás funkcióval helyezze át az adatbázist egy másik felügyelt SQL-példányba, vagy váltson az ügyfél által felügyelt kulcsra.

Támogatott a natív visszaállítás (.bak fájlokból) felügyelt SQL-példányra?

Igen, az SQL Server 2005+ verzióiban támogatott és elérhető. Natív visszaállítás használatához töltse fel a .bak fájlt az Azure Blob Storage-ba, és hajtsa végre a T-SQL-parancsokat. További információ: natív visszaállítás URL-címről.

Támogatott a natív visszaállítás a felügyelt SQL-példányról az SQL Serverre?

Igen, de csak az SQL Server 2022-re, az SQL Server 2022 általános támogatási időszakában. Lehetséges, hogy a jövőben néhány felügyelt Azure SQL-példány-szolgáltatás is bevezethető, amelyek az adatbázis formátumának módosítását igénylik, így a biztonsági másolatok nem kompatibilisek az SQL Server legújabb verziójával. Az ilyen funkciókhoz való hozzáféréshez explicit bejelentkezés szükséges.

Üzletmenet-folytonosság

Az én rendszeradatbázisaim le vannak replikálva a feladatátvételi csoport másodlagos példányára?

A rendszeradatbázisok nem replikálódnak a feladatátvételi csoport másodlagos példányára. Ezért a rendszeradatbázisok objektumaitól függő forgatókönyvek a másodlagos példányon lehetetlenek, kivéve, ha az objektumok manuálisan jönnek létre a másodlagos példányon. Kerülő megoldásért lásd: Az objektumtól függő forgatókönyvek engedélyezése a rendszeradatbázisokból.

Hálózatkezelési követelmények

Melyek a felügyelt SQL-példány alhálózatára vonatkozó aktuális bejövő/kimenő NSG-korlátozások?

A szükséges NSG- és UDR-szabályok dokumentálva vannak a szolgáltatás által támogatott alhálózati konfigurációban, és a szolgáltatás automatikusan beállítja. Ne feledje, hogy ezek a szabályok csak azok, amelyekre szükségünk van a szolgáltatás fenntartásához. Ha egy felügyelt SQL-példányhoz szeretne csatlakozni, és különböző funkciókat szeretne használni, be kell állítania más funkcióspecifikus szabályokat, és fenn kell tartania őket.

Hogyan állíthatok be bejövő NSG-szabályokat a felügyeleti portokon?

A felügyelt SQL-példány felelős a felügyeleti portokra vonatkozó szabályok beállításáért. A szabályok a szolgáltatás által támogatott alhálózati konfiguráció nevű funkciókon keresztül vannak beállítva. Ennek célja a felügyeleti forgalom zavartalan áramlásának biztosítása az SLA teljesítéséhez.

Lekérhetem a bejövő felügyeleti forgalomhoz használt forrás IP-tartományokat?

Igen. Elemezheti a hálózati biztonsági csoporton áthaladó forgalmat a Network Watcher-folyamatnaplókkonfigurálásával.

Beállíthatom az NSG-t az adatvégponthoz való hozzáférés szabályozására (1433-os port)?

Igen. Miután kiépített egy felügyelt SQL-példányt, beállíthatja az 1433-at futtató port bejövő hozzáférését vezérlő NSG-t. Javasoljuk, hogy a lehető legnagyobb mértékben szűkítse az IP-tartományát.

Beállíthatom az NVA-t vagy a helyszíni tűzfalat, hogy a kimenő felügyeleti forgalmat az FQDN-ek alapján szűrje?

Nem. Ez több okból sem támogatott:

• A bejövő felügyeleti kérelmekre adott válaszként szolgáló útválasztási forgalom aszimmetrikus lenne, és nem működne.
• A forgalom Azure Storage-ba való átirányítását az átviteli sebesség korlátozásai és késése befolyásolná, így így nem tudjuk biztosítani a várt szolgáltatásminőséget és rendelkezésre állást.
• Ezek a konfigurációk hajlamosak a hibákra, és nem támogathatók.

Beállíthatom az NVA-t vagy a tűzfalat a kimenő nem felügyelt forgalomhoz?

Igen. A legegyszerűbb módszer egy 0/0 szabály hozzáadása egy felügyelt SQL-példány alhálózatához társított UDR-hez a forgalom NVA-n keresztüli átirányításához.

Hány IP-címre van szükségem egy felügyelt SQL-példányhoz?

Az alhálózatnak elegendő számú elérhető IP-címmel kell rendelkeznie. A felügyelt SQL-példányhoz tartozó virtuális hálózati alhálózat méretének meghatározásához tekintse meg a felügyelt Azure SQL-példányhoz szükséges alhálózatméretet és -tartományt.

Mi a teendő, ha nincs elegendő IP-cím a példányfrissítési művelet végrehajtásához?

Ha nincs elegendő IP-cím abban az alhálózatban, ahol a felügyelt SQL-példány ki van építve, hozzon létre egy új alhálózatot, és helyezze át a felügyelt SQL-példányt. Azt is javasoljuk, hogy az új alhálózat több lefoglalt IP-címmel legyen létrehozva, hogy a jövőbeli frissítési műveletek elkerüljék a hasonló helyzeteket. Megtudhatja, hogyan áthelyezni a felügyelt Azure SQL-példányt az alhálózatok között.

Szükség van egy üres alhálózatra egy felügyelt SQL-példány létrehozásához?

Nem. Használhat egy üres alhálózatot vagy egy olyan alhálózatot, amely már tartalmaz felügyelt példányokat.

Módosíthatom az alhálózat címtartományát?

Csak akkor nem, ha vannak felügyelt példányok benne. Ez egy Azure-beli hálózati infrastruktúra korlátozása. Csak megengedett további címterület hozzáadása egy üres alhálózathoz.

Áthelyezhetem a felügyelt SQL-példányomat egy másik alhálózatra?

Igen. A felügyelt SQL-példányok online módon áthelyezhetők egy másik alhálózatra ugyanazon a virtuális hálózaton belül vagy egy másik virtuális hálózaton belül. Megtudhatja, hogyan áthelyezni a felügyelt Azure SQL-példányt az alhálózatok között.

Szükség van egy üres virtuális hálózatra egy felügyelt SQL-példány létrehozásához?

Ez nem kötelező. Létrehozhat virtuális hálózatot felügyelt Azure SQL-példányhoz, vagy Konfigurálhat egy meglévő virtuális hálózatot a felügyelt Azure SQL-példányokhoz.

Elhelyezhetek egy felügyelt SQL-példányt más szolgáltatásokkal egy alhálózaton?

Nem. Jelenleg nem támogatjuk a felügyelt SQL-példányok olyan alhálózatban való elhelyezését, amely már tartalmaz más erőforrástípusokat.

Hálózati csatlakozás

Csatlakozhatok a felügyelt SQL-példányhoz az IP-címével?

Nem, ez nem támogatott. Egy felügyelt SQL-példány gazdagépneve leképezésre kerül a felügyelt SQL-példány virtuális fürtje előtt elhelyezkedő terheléselosztóra. Mivel egy virtuális klaszter több felügyelt példányt is üzemeltethet, a kapcsolat nem irányítható a megfelelő SQL-felügyelt példányhoz, ha nincs megadva a neve. További információ a felügyelt SQL-példány virtuális fürt architektúrájáról: Virtuális fürt kapcsolati architektúrája.

A felügyelt SQL-példány rendelkezhet statikus IP-címmel?

Jelenleg csak a felügyelt SQL-példányok privát végpontjai garantálják a statikus IP-címeket.

Ritka, de szükséges helyzetekben előfordulhat, hogy egy felügyelt SQL-példányt online módon migrálunk egy új virtuális fürtbe, vagy a virtuális fürtön belül egy másik virtuális gép csoportba, a technológiai verem módosításai miatt, amelyek a szolgáltatás biztonságát és megbízhatóságát javítják. Amikor egy új virtuális gépcsoportba vagy virtuális klaszterbe migrál, az SQL kezelőpéldány gazdagépnevéhez hozzárendelt IP-cím megváltozik. A felügyelt SQL-példányok szolgáltatása nem nyújt statikus IP-címtámogatást, és fenntartja a jogot az IP-cím előzetes értesítés nélküli módosítására a rendszeres karbantartási ciklusok részeként.

Ezért a virtuális hálózat helyi és nyilvános végpontjai csak a hozzájuk társított tartománynevekkel érhetők el. Határozottan elriasztjuk attól, hogy az IP-címük változatlanságára hagyatkozzanak, mivel ez elérhetetlenséghez vezethet annak ellenére, hogy a szolgáltatás jól működik.

Ha olyan statikus IP-címre van szüksége, amely a virtuális hálózaton kívülről érhető el, üzembe helyezheti az Azure Firewallt egy előtérbeli nyilvános IP-címmel, és konfigurálhat egy NAT-szabályt, amely lefordítja a bejövő forgalmat egy felügyelt SQL-példány privát végpontjára. Ezután állítsa be a DNS-feloldásokat, vagy konfigurálja az ügyfél-aliasokat úgy, hogy az SQL-ügyfelek a felügyelt SQL-példány teljes tartománynevén keresztül csatlakozzanak a tűzfal nyilvános IP-címéhez.

Rendelkezik nyilvános végponttal a Felügyelt SQL-példány?

Igen, egy nyilvános végpont engedélyezhető az internetről érkező bejövő forgalom engedélyezéséhez a felügyelt SQL-példány eléréséhez. További információ: Felügyelt SQL-példány használata nyilvános végpontokkal és Nyilvános végpont konfigurálása felügyelt SQL-példányban.

Megadhatok egyéni portot az SQL-adatvégpontokhoz?

Nem, egyéni port használata nem érhető el. A virtuális hálózatok helyi végpontjai esetében a felügyelt SQL-példány az alapértelmezett 1433-es portszámot használja, a nyilvános adatvégpontok esetében pedig a felügyelt SQL-példány az alapértelmezett 3342-es portszámot használja.

Mi a különböző régiókban elhelyezett felügyelt példányok csatlakoztatásának ajánlott módja?

A globális virtuális hálózatok közötti társviszony-létesítés és az Azure virtual WAN is ajánlott módszer két felügyelt példány csatlakoztatására különböző régiókban. Az Express Route-kapcsolatcsoport-társviszony-létesítés alternatív lehetőség. Ha a környezetben egyik lehetőség sem lehetséges, az egyetlen másik csatlakozási módszer a helyek közötti VPN-kapcsolat. Helyek közötti VPN konfigurálása az Azure portalon, PowerShell, vagy a Azure CLI használatával.

Támogatja a felügyelt SQL-példány a globális virtuális hálózatok közötti társviszony-létesítést?

Az Azure SQL Managed Instance támogatása 2020. szeptember 22-én bővült az újonnan létrehozott virtuális fürtök globális virtuális hálózati peeringjével. Így a virtuális hálózatok közötti társviszony-létesítés támogatott az üres alhálózatokban 2020. szeptember 22. után létrehozott felügyelt példányok esetében. Az ezen időpont előtt üzembe helyezett példányok esetében a peering támogatása az ugyanazon régión belüli hálózatokra korlátozódik, mivel a globális virtuális hálózati peering korlátozásai ezt szükségessé teszik. További információkért tekintse át az Azure Virtual Networks gyakori kérdésekvonatkozó szakaszát.

Globális virtuális hálózati társítás használatához a 2020. szeptember előtt létrehozott példányokkal fontolja meg egy karbantartási idősáv konfigurálását. Vagy érdemes lehet áthelyezni a példányt egy új alhálózatra. Bármelyik lehetőség áthelyezi a példányt egy új virtuális fürtre, amely támogatja a globális virtuális hálózatok közötti összekapcsolást.

Tekintse meg , hogyan ellenőrizheti, hogy a virtuális fürt támogatja-e a globális virtuális hálózati társviszony-létesítést, szükség esetén.

Adatszűrés kockázatának csökkentése

Hogyan mérsékelhetem az adatkiszivárgási kockázatokat?

Az adatkiszivárgási kockázatok csökkentése érdekében az ügyfeleknek ajánlott biztonsági beállításokat és vezérlőket alkalmazniuk:

• Kapcsolja be transzparens adattitkosítás (TDE) minden adatbázison.
• A Common Language Runtime (CLR) kikapcsolása. Ez a beállítás a helyszínen is ajánlott.
• Csak Microsoft Entra-hitelesítést használjon.
• A példány elérése alacsony szintű jogosultsággal rendelkező DBA-fiókkal.
• Konfigurálja a JIT jumpbox-hozzáférést a sysadmin-fiókhoz.
• Kapcsolja be SQL-naplózási, és integrálja riasztási mechanizmusokkal.
• Kapcsolja be fenyegetésészlelési a Microsoft Defender for SQL csomagból.
• Alkalmazzon egy szolgáltatásvégpont-szabályzatot az alhálózatra az Azure Storage felé irányuló kimenő forgalom szabályozásához.
• A CREATE EXTERNAL TABLE AS SELECT (CETAS) alapértelmezés szerint tiltva van. Ha engedélyezni szeretné a CETAS-t a allowPolyBaseExport kiszolgáló konfigurációs beállításával, tekintse meg KÜLSŐ TÁBLA LÉTREHOZÁSA SELECT (CETAS).

DNS

Konfigurálhatok egyéni DNS-feloldót felügyelt SQL-példányhoz?

Igen. Lásd: Privát DNS-nevek feloldása felügyelt Azure SQL-példányban.

Végezhetek DNS-frissítést?

Igen. Lásd: Privát DNS-nevek feloldása felügyelt Azure SQL-példányban.

Időzóna módosítása

Módosíthatom egy meglévő felügyelt SQL-példány időzónát?

Az időzóna konfigurációja akkor állítható be, ha egy felügyelt SQL-példány első üzembe helyezése történik. A meglévő felügyelt SQL-példány időzónájának módosítása nem támogatott. További információ: időzóna korlátozásai.

A megkerülő megoldások közé tartozik egy új felügyelt SQL-példány létrehozása a megfelelő időzónával, majd manuális biztonsági mentés és visszaállítás végrehajtása, vagy az ajánlott, példányközi időponthoz kötött visszaállítás végrehajtása.

Biztonság és adatbázis-titkosítás

Elérhető a sysadmin kiszolgálói szerepkör felügyelt SQL-példányhoz?

Igen, az ügyfelek létrehozhatnak olyan bejelentkezéseket, amelyek a sysadmin szerepkör tagjai. Azok az ügyfelek, akik a sysadmin jogosultságot feltételezik, szintén felelősséget vállalnak a példány működtetéséért, ami negatívan befolyásolhatja az SLA-kötelezettségvállalást. Ha bejelentkezést szeretne hozzáadni a sysadmin kiszolgálói szerepkörhöz, tekintse meg a Microsoft Entra-hitelesítést.

Támogatott a felügyelt SQL-példány transzparens adattitkosítása?

Igen, a felügyelt Azure SQL-példány támogatja a transzparens adattitkosítást (TDE). További információ: felügyelt SQL-példány transzparens adattitkosítása.

Használhatom a "saját kulcs" modellt a TDE-hez?

Igen, az Azure Key Vault a BYOK-szcenárióhoz elérhető az Azure SQL Felügyelt Példányhoz. További információ: Transzparens adattitkosítás ügyfél által felügyelt kulccsal.

Migrálhatok titkosított SQL Server-adatbázist?

Igen, megteheted. Titkosított SQL Server-adatbázis migrálásához exportálnia és importálnia kell a meglévő tanúsítványokat a felügyelt SQL-példányba. Ezután készítsen egy teljes adatbázis-biztonsági másolatot, és állítsa vissza egy felügyelt SQL-példányra.

Az Azure Database Migration Service használatával is migrálhatja a TDE titkosított adatbázisokat.

Hogyan konfigurálhatom a felügyelt SQL-példány TDE-védőforgatását?

A felügyelt SQL-példány TDE-védője az Azure Cloud Shell használatával elforgatható. Útmutatásért tekintse meg felügyelt SQL-példány transzparens adattitkosítását az Azure Key Vaultsaját kulcsával.

Visszaállíthatom a titkosított adatbázist felügyelt SQL-példányra?

Igen, nem kell visszafejtenie az adatbázist a felügyelt SQL-példányra való visszaállításhoz. A titkosított biztonsági mentési fájlból való adatolvasáshoz meg kell adnia egy tanúsítványt/kulcsot, amelyet a forrásrendszer titkosítási kulcsának védelmeként használnak a felügyelt SQL-példánynak. Kétféleképpen teheti meg:

• Tanúsítványvédő feltöltése a felügyelt SQL-példányhoz. Ez csak a PowerShell használatával végezhető el. A példaszkript az egész folyamatot ismerteti.
• Aszimmetrikus kulcsvédő feltöltése az Azure Key Vaultba, és az SQL-felügyelt példány arra mutat. Ez a megközelítés hasonlít a saját kulcsú (BYOK) TDE-használati esethez, amely a Key Vault-integrációt is használja a titkosítási kulcs tárolásához. Ha nem titkosítási kulcsvédőként szeretné használni a kulcsot, és csak elérhetővé szeretné tenni a kulcsot a felügyelt SQL-példány számára a titkosított adatbázisok visszaállításához, kövesse a BYOK TDE beállításának utasításait, és ne jelölje be a jelölőnégyzetet : A kijelölt kulcs legyen az alapértelmezett TDE-védő.

Miután elérhetővé tette a titkosítási védőt a felügyelt SQL-példány számára, folytathatja a szabványos adatbázis-visszaállítási eljárást.

Vásárlási modellek és előnyök

Milyen vásárlási modellek érhetők el a felügyelt SQL-példányokhoz?

A SQL Managed Instance egy vCore-alapú vásárlási modellt kínál.

Milyen költségelőnyök érhetők el a felügyelt SQL-példányhoz?

Az Azure SQL előnyeivel a következő módokon takaríthat meg költségeket:

• Maximalizálhatja a helyszíni licencekbe történő meglévő befektetéseket, és akár 55%-ot is megtakaríthat Azure Hybrid Benefit.
• Véglegesítse a számítási erőforrások foglalását, és takarítson meg akár 33%-ot Azure Reservations előnyével. Kombinálja ezt az előnyt az Azure Hybrid juttatással akár 82%-os megtakarítás érdekében.
• Akár 55 százalékot is megtakaríthat a listaárakhoz képest Azure Dev/Test Pricing Benefit, amely kedvezményes díjszabást kínál a folyamatban lévő fejlesztési és tesztelési számítási feladatokhoz.

Ki jogosult a Fenntartott példányok juttatásra?

A fenntartott példány előny igénybevételéhez az előfizetési típusnak vállalati szerződésnek (ajánlatszámok: MS-AZR-0017P vagy MS-AZR-0148P) vagy egyedi szerződésnek, amely használatalapú fizetéses díjszabást alkalmaz (ajánlatszámok: MS-AZR-0003P vagy MS-AZR-0023P) kell lennie. További információ a foglalásokról: Azure Reservations.

Lehetséges a foglalások lemondása, cseréje vagy visszatérítése?

Bizonyos korlátozásokkal lemondhatja, kicserélheti vagy visszatérítheti a foglalásokat. További információért lásd az Azure Foglalások önkiszolgáló cseréit és visszatérítéseit.

Azure SQL-felügyelt példány és biztonsági mentési tárhely számlázása

Mik a felügyelt SQL-példány díjszabási beállításai?

A felügyelt SQL-példány díjszabási beállításainak megismeréséhez tekintse meg Díjszabás lap.

Hogyan követhetim nyomon a felügyelt SQL-példány számlázási költségeit?

Ezt a Microsoft Cost Management megoldáshasználatával teheti meg. Lépjen a Előfizetések az Azure portal részére, és válassza a Költségelemzést lehetőséget.

Használja a Halmozott költségek lehetőséget, majd szűrjön Erőforrástípus szerintmicrosoft.sql/managedinstances.

Használhatok microsoftos vagy külső (fejlesztői és egyéb) eszközöket a felügyelt SQL-példányok további költségek nélküli eléréséhez?

Kompatibilis Microsoft- vagy külső ügyféleszközökkel érheti el a felügyelt SQL-példányt, és az Azure-számlán nem számítunk fel további költségeket. Ha azonban egyes eszközök licencet igényelnek, akkor jogi licenccel rendelkező szoftverre van szükség. Ezt a követelményt az egyes szerszámgyártókkal kötött külön megállapodások szabályozzák.

Mennyibe kerülnek az automatikus biztonsági mentések?

A megvásárolt fenntartott adattárterülettel egyenlő mennyiségű szabad biztonsági mentési tárhelyet kap, függetlenül a biztonsági mentési megőrzési időszaktól. Ha a biztonsági mentési tárterület kihasználtsága a lefoglalt ingyenes biztonsági mentési tárterületen belül van, a felügyelt SQL-példányok automatikus biztonsági mentései nem járnak többletköltséggel, ezért ingyenesek. A biztonsági mentési tárterület szabad terület feletti használatának túllépése további költségeket eredményez. A részletekért tekintse meg a díjszabási lapjának Biztonsági mentési tár című szakaszát. A felügyelt SQL-példányok automatikus biztonsági mentéséről további technikai információk érhetők el A biztonsági mentési tár használatánakismertetése.

Hogyan monitorozhatom a biztonsági mentési tárterületem számlázási költségeit?

A biztonsági mentési tárterület költségeit az Azure Portalon követheti nyomon. Útmutatásért lásd: Automatikus biztonsági mentések költségeinek monitorozása.

Hogyan optimalizálhatom a biztonsági másolatok tárolási költségeit a felügyelt SQL-példányon?

A biztonsági mentés tárolási költségeinek optimalizálásához tekintse meg a felügyelt SQL-példány biztonsági mentési tárolási költségeinek finomhangolását.

Költségtakarékos használati esetek

Hol találom a használati eseteket és az ebből eredő költségmegtakarítást a felügyelt SQL-példányokkal?

Az Azure SQL Managed Instance üzembe helyezésével járó előnyök, költségek és kockázatok jobb megismeréséhez elérhető egy Forrester-tanulmány is: Az Azure SQL Managed Instance adatbázisok teljes gazdasági hatása.

Jelszóházirend

Milyen jelszószabályzatokat alkalmaz a felügyelt SQL-példány sql-bejelentkezéseihez?

Az SQL-bejelentkezésekhez tartozó felügyelt SQL-példány jelszavas szabályzata örökli az Azure platformszabályzatait, amelyek a felügyelt SQL-példányt tartalmazó virtuális fürtöt alkotó virtuális gépekre lesznek alkalmazva. Jelenleg ezen beállítások egyikét sem lehet módosítani, mivel ezeket a beállításokat az Azure határozza meg, és a felügyelt SQL-példány örökli.

Fontos

Az Azure platform anélkül módosíthatja a szabályzat követelményeit, hogy a szabályzatra támaszkodó szolgáltatások értesítése nélkül értesítenék.

Mik a jelenlegi Azure-platformszabályzatok?

Minden bejelentkezéskor be kell állítania a jelszavát, és a maximális életkor elérése után módosítania kell a jelszavát.

szabályzat	biztonsági beállítások
Jelszó maximális életkora	42 nap
Jelszó minimális életkora	Egy napon
Jelszó minimális hossza	14 karakter
A jelszónak meg kell felelnie az összetettségi követelményeknek	Engedélyezve

Le lehet tiltani a jelszó összetettségét és lejáratát a felügyelt SQL-példányban a bejelentkezési szinten?

Igen, a bejelentkezési szinten szabályozható CHECK_POLICY és CHECK_EXPIRATION mezők. Az aktuális beállításokat a következő T-SQL-parancs végrehajtásával ellenőrizheti:

SELECT *
FROM sys.sql_logins

Ezt követően módosíthatja a megadott bejelentkezési beállításokat a következő végrehajtásával:

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(Cserélje le a "teszt" elemet a kívánt bejelentkezési névre, és módosítsa a szabályzatot és a lejárati értékeket.)

Szolgáltatásfrissítések

Mi az Azure SQL Database és a SQL Managed Instance gyökér hitelesítésszolgáltatójának módosítása?

Lásd az Azure SQL Database & SQL Managed Instance tanúsítványcseréjét.

Mi a felügyelt SQL-példány tervezett karbantartási eseménye?

Lásd SQL Managed Instance esetén az Azure karbantartási események tervét.

Már nem látom a 2022. novemberi funkcióhullámot az Azure Portalon. Miért?

A 2022. novemberi funkcióhullámban bevezetett módosítások és képességek alapértelmezés szerint minden példány számára elérhetők. Mivel már nem szükséges külön műveletet elvégezni egy példány regisztrálásához, a 2022. novemberi funkcióhullámot említő beállítások el lettek távolítva az Azure Portalról.

Azure-visszajelzés és támogatás

Hol hagyhatom el a felügyelt SQL-példány fejlesztéseivel kapcsolatos ötleteimet?

Szavazhat egy új felügyelt SQL-példány funkcióra, vagy létrehozhat egy új fejlesztési ötletet a felügyelt SQL-példány visszajelzési fórumában. Így hozzájárulhat a termékfejlesztéshez, és segíthet rangsorolni a lehetséges fejlesztéseket.

Hogyan hozhatok létre Azure-támogatási kérést?

Az Azure-támogatási kérések létrehozásának módjáról az Azure támogatási kérésének létrehozása című témakörben olvashat.

Következő generációs általános célú szolgáltatásszint-frissítés

Miért nem engedélyezhetem a zónaredundanciát a következő generációs általános célú felügyelt SQL-példányhoz?

A zónaredundancia jelenleg nem támogatott a következő generációs általános célú szolgáltatási szint esetében.

Engedélyezhetem a következő generációs általános célú frissítést a példánykészletemhez?

Nem, a következő generációs általános célú szolgáltatásszint-frissítés jelenleg nem támogatott a példánykészletek vagy a készleten belüli példányok esetében.

A következőkre vonatkozik:Felügyelt Azure SQL-példány

Ez a cikk a felügyelt Azure SQL-példány kapcsolatos leggyakoribb kérdéseket tartalmazza.

Jegyzet

Microsoft Entra ID korábban Azure Active Directory (Azure AD) néven ismert.

A felügyelt SQL-példányok támogatott funkcióinak listáját Felügyelt Azure SQL-példány funkcióinakcímű cikkben találja.

Az Azure SQL-felügyelt példány és az SQL Server szintaxisa és viselkedésbeli különbségeiért lásd az SQL Server T-SQL eltérései.

A rendelkezésre álló hardverjellemzőkért lásd a hardverkonfigurációk technikai különbségeit. Az elérhető szolgáltatási szintekről és jellemzőikről lásd a szolgáltatási szintekközötti technikai különbségeket.

Bármely ügyfél jogosult bármely szolgáltatási szintre. A Szoftvergarancia által lefedett Standard és Enterprise kiadási licencek is lefoglalhatók az SQL Server adatbázismotorhoz az Azure Hybrid Benefit (AHB) használatával az általános célú szolgáltatási szint (amely magában foglalja a következő generációs általános célú szolgáltatási szint frissítését) vagy az üzletileg kritikus szolgáltatási szint esetében. Az Azure Hybrid Benefit a következő cserearányokat használja: 1 Standard kiadás = 1 Általános célú, 1 Nagyvállalati kiadás = 1 Üzleti szempontból kritikus, 1 Nagyvállalati kiadás = 4 Általános célú és 4 Általános célú = 1 Nagyvállalati kiadás. További információ: Az Azure Hybrid Benefit konkrét jogai.

A támogatott előfizetéstípusok listáját támogatott előfizetéstípusokcímű témakörben találja.

A felügyelt példányok az Azure legtöbb régiójában hozhatók létre; lásd: felügyelt SQL-példányok támogatott régiói. Ha olyan régióban van szüksége felügyelt SQL-példányra, amely jelenleg nem támogatott, küldjön támogatási kérést az Azure Portalon keresztül.

A felügyelt SQL-példánynak két alapértelmezett korlátja van: a használható alhálózatok számának korlátja, valamint a kiosztható virtuális magok számának korlátja. A korlátozások az előfizetések típusaitól és régióitól függően változnak. A regionális erőforráskorlátozások előfizetéstípus szerinti listájáért tekintse meg a regionális erőforráskorlátozások táblázatát. Ezek a puha korlátok igény szerint növelhetők. Ha az aktuális régiókban több felügyelt példányt szeretne kiépíteni, küldjön egy támogatási kérést a kvóta növeléséhez az Azure Portalon. További információ: Kéréskvóta növelése az Azure SQL Database.

A felügyelt SQL-példányonkénti 100 adatbázis korlátja egy szigorú korlát, amely az általános célú és az üzleti szempontból kritikus szolgáltatási szinteken nem módosítható. Legfeljebb 500 adatbázissal rendelkezhet az Következő generációs általános célú szolgáltatásszinten.

Fontolja meg a számítási feladatnak megfelelő más Azure változatokra való migrálást: Azure SQL Database Hyperscale vagy SQL Server az Azure platformon futó virtuális gépeken.

Érdemes lehet az Azure-beli virtuális gépeken SQL Serverre való migrálást vagy Azure SQL Database- memóriát/processzort optimalizálni.

A termékhibákkal és az ismert problémákkal kapcsolatban lásd ismert problémákat.

Az új és előzetes verziójú funkciókért tekintse meg Újdonságokcímű témakört.

Felügyelt SQL-példányt hozhat létre az Azure portálról, a PowerShellből, az Azure CLI-ből és az ARM-sablonokból.

Igen, kiépítheti a felügyelt SQL-példányt egy meglévő előfizetésben, ha az előfizetés a támogatott előfizetés-típusokhoz tartozik.

Az alhálózat nevének számjegyekkel való indítása egy mögöttes összetevő jelenlegi korlátozása, amely ellenőrzi az alhálózat nevét a regexben:

^[a-zA-Z_][^\\\/\:\*\?\"\<\>\|\`\'\^]*(?<![\.\s])$

A regexnek megfelelő és érvényes alhálózati nevek jelenleg támogatottak.

A felügyelt SQL-példányt skálázhatja az Azure Portalról, a PowerShellből, az Azure CLI-ből vagy az ARM-sablonokból.

Igen, megteheted. Útmutatásért lásd: Erőforrások áthelyezése régiók között.

A felügyelt SQL-példányokat az Azure Portalon, a PowerShellen, az Azure CLI-en vagy a Resource Manager REST API-ján keresztül törölheti.

Az új felügyelt SQL-példány létrehozásához vagy a szolgáltatási szintek (virtuális magok, tárolók) módosításához szükséges várható idő számos tényezőtől függ. Lásd: Felügyeleti műveletek.

Az egyes adatbázisok visszaállítása a teljes meghatározott megőrzési időszak alatt garantált – még azokat az adatbázisokat is, amelyeket csak néhány másodperc után hoztak létre, majd töröltek. Adatbázis létrehozásakor, törlésekor vagy visszaállításakor a rendszer különböző időközönként készít biztonsági másolatot az adatok megőrzése érdekében, hogy az adott megőrzési időszak alatt visszaállítható legyen. Ha egy adatbázist a biztonsági mentési művelet befejezése előtt elvet a rendszer, az alábbi hibával blokkolhatja az elvetési műveletet:

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

A hiba elkerülése érdekében ellenőrizze az elvetési művelet állapotát, mielőtt egy azonos nevű adatbázist újranevelne. További információ: sys.dm_operation_status. Ha a művelet állapota Befejezettjelenik meg, visszaállíthatja vagy létrehozhat egy azonos nevű adatbázist.

A következő gyakori használati esetek valószínűleg ezt a hibát fogják tapasztalni:

• Ha több adatbázist törölnek, majd rövid időn belül egymás után ugyanazzal a névvel újra létrehoznak. Egy adatbázis elvetésekor a tranzakciónapló fennmaradó végének biztonsági mentése szinkron módon történik, mielőtt az elvetési művelet befejeződik, ahogy a képen látható:

  

  Nem hozható létre ugyanazzal a névvel rendelkező adatbázis, amíg a tail-log biztonsági másolatot nem készít és az elvetési művelet befejeződik. Az elvetési művelet szekvenciális jellege miatt a rövid idő alatt elvetett adatbázisok várólistába kerülnek, ami meghosszabbíthatja az adatbázisok elvetésének folyamatát, és késleltetheti az azonos nevű újak létrehozását.

• Ha egy adatbázis visszaállításra kerül, majd törlésre, mielőtt egy teljes biztonsági mentés létrejön. Az adatbázis visszaállításakor a visszaállítási folyamat első lépése az adatbázis új teljes biztonsági mentése. Ha megpróbál visszaállítani egy adatbázist, majd közvetlenül a teljes biztonsági mentés befejezése előtt elveti, nem tudja elvetni az adatbázist, és létrehozni egy másik adatbázist ugyanazzal a névvel, amíg a teljes biztonsági mentés el nem készül, és az adatbázis elvetési művelete befejeződik. Az adatbázis méretétől függően a teljes biztonsági mentés órákat is igénybe vehet.

Valószínű, hogy elfogytak a kreditjei a hónapra vonatkozóan. Nyissa meg a felügyelt SQL-példányt az Azure Portalon, és ellenőrizze az állapotot. Ellenőrizze, hogy a példány leállt állapotban van-e az elégtelen kreditek miatt.

Ez a funkció jelenleg nem érhető el.

Igen, visszaállíthatja az automatikus biztonsági mentéseket más felügyelt SQL-példányokról, vagy visszaállíthatja a helyszíni adatbázis biztonsági mentését az SQL Server Management Studio (SSMS) használatával , vagy futtathat egy RESTORE DATABASE parancsot, és megcélozhatja .bak a fájlokat az Azure Storage-ból vagy S3-gyűjtőkből.

Az erőforráskorlátozások ellenére az ingyenes felügyelt SQL úgy lett kialakítva, hogy hatás nélkül tesztelje a számítási feladatokat. Az ingyenes felügyelt SQL-példány használata során tapasztalt teljesítmény megegyezik a példány éles verziójának teljesítményével.

Az ingyenes felügyelt SQL-példány csak 4 és 8 vCore-t kínál. Ha vállalata több erőforrással rendelkező példányt igényel, fontolja meg a teljes körű fizetős felügyelt SQL-példányra való frissítését.

Az ingyenes felügyelt SQL-példány legfeljebb 7 napig támogatja a PITR-t. Más biztonsági mentési beállítások nem módosíthatók az ingyenes felügyelt SQL-példányhoz.

A felügyelt SQL-példány nevének módosítása nem támogatott.

Igen, a felügyelt SQL-példány alapértelmezett DNS-zónája .database.windows.net a sajátjával módosítható. A felügyelt SQL-példány hosztnevének, amely a teljes tartománynév része, beleértve a véletlenszerű alzónát (például sqlmiFQDN.randomized-subzone az .database.windows.net előtti rész), változatlannak kell maradnia.

Ha egy másik DNS-zónát szeretne használni az alapértelmezett helyett, például .contoso.com:

• Alias definiálásához használja az SQL Server ügyfélhálózati segédprogramját (CliConfg). Használhatja csak a felügyelt SQL-példány gazdagépnevét, vagy a felügyelt SQL-példány gazdagépnevét, majd egy egyéni tartománynevet. A CliConfg eszköz egy aliast ad hozzá a beállításjegyzékhez a HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo vagy a HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo alatt, attól függően, hogy a 64 bites verziót (C:\Windows\System32\cliconfg.exe) vagy a 32 bites verziót (C:\Windows\SysWOW64\cliconfg.exe) használja-e. Aliasokat csoportházirend vagy szkript használatával is felveheti, de mindkettőt használnia kell annak biztosítására, hogy a 32 bites és a 64 bites programok felismerhessék az aliast.
• Használjon CNAME rekordot a DNS-ben úgy, hogy a felügyelt SQL-példány gazdagépneve a felügyelt SQL-példány VNet-helyi végpontjának tartománynevére mutat. Ebben az esetben HostNameInCertificate=<VNet-local endpoint domain name> (ajánlott) vagy TrustServerCertificate=TRUE a Microsoft Entra-hitelesítés használatakor szükséges.
• Használjon A rekordot a DNS-ben, amelyben a felügyelt SQL-példány gazdagépneve a felügyelt SQL-példány IP-címére mutat. AZ IP-cím használata nem ajánlott, mivel az értesítés nélkül változhat. Ebben az esetben HostNameInCertificate=<VNet-local endpoint domain name> (ajánlott) vagy TrustServerCertificate=TRUE a Microsoft Entra-hitelesítés használatakor szükséges.

A felügyelt Azure SQL-példány számítási és tárolási méretenként ugyanazokat a teljesítményszinteket kínálja, mint az Azure SQL Database más üzembehelyezési lehetőségei. Ha egyetlen példányon szeretné összesíteni az adatokat, vagy olyan funkcióra van szüksége, amely kizárólag a felügyelt SQL-példányban támogatott. Az adatokat exportálási/importálási (BACPAC) funkcióval migrálhatja. Az SQL Database felügyelt SQL-példányra való migrálásának további módjai:

• Külső adatforrás használata
• SQLPackage használata
• BCP használata

Az egyik lehetőség az adatbázis BACPAC- exportálása, majd a BACPAC-fájlimportálása. Ez a módszer akkor ajánlott, ha az adatbázis kisebb, mint 100 GB.

Tranzakciós replikációs akkor használható, ha az adatbázis összes táblája elsődleges kulcsokkal rendelkezik, és az adatbázisban nincsenek memóriabeli OLTP-objektumok.

Az SQL Server-példány migrálásához tekintse meg az SQL Server és az Azure SQL Managed Instance útmutatót.

A más platformokról való migrálással kapcsolatos migrálási információkért tekintse meg az Azure Database migrálási útmutatói című témakört.

A felügyelt SQL-példány és az SQL Server teljesítmény-összehasonlításához jó kiindulópont az Azure SQL Managed Instance és az SQL Server teljesítmény-összehasonlításának ajánlott eljárásai.

Lásd felügyelt SQL-példány és az SQL Serverközötti teljesítménybeli különbségek fő okait. A tranzakciónapló fájlmérete hatással lehet az általános célú felügyelt SQL-példány teljesítményére. További információért lásd: A naplófájl méretének hatása az általános célú felhasználásra.

A felügyelt SQL-példány teljesítményét az alábbiakkal optimalizálhatja:

• Automatikus finomhangolás, amely mesterséges intelligencia és gépi tanulás alapú folyamatos teljesítményhangolással biztosítja a csúcsteljesítményt és a stabil számítási feladatokat.
• memóriabeli OLTP, amely javítja a tranzakciós feldolgozási számítási feladatok átviteli sebességét és késését, és gyorsabb üzleti elemzéseket biztosít.
• Az alkalmazás- és adatbázis-hangolás ajánlott eljárásainak alkalmazása.
• A kapcsolat típusának váltása proxyról átirányítási módra alacsonyabb késés és nagyobb átviteli sebesség érdekében, ha a számítási feladat sok kis tranzakcióból áll.

Az általános célú példányok teljesítményének javítása érdekében fontolja meg az adatfájl méreténeknövelését. Az Általános Célú példányok tárolási teljesítményének optimalizálásához tekintse meg az általános célú rétegre vonatkozó tárolási legjobb gyakorlatokat.

Lásd: A felügyelt SQL-példányok várakozási statisztikáinak elemzése. A várakozási statisztikák olyan információk, amelyek segíthetnek megérteni, hogy miért hosszú a lekérdezés időtartama, és azonosíthatja azokat a lekérdezéseket, amelyek valamire várnak az adatbázismotorban.

MSSQLSERVER_833 azt jelzi, hogy egy I/O-kérés végrehajtása több mint 15 másodpercet vett igénybe. Ez a hiba a felügyelt Azure SQL-példányban az általános infrastruktúra-feltételekhez kapcsolódik, nem pedig a számítási feladathoz. A felhőalapú környezetekben és a távoli tárolást használó rendszerekben több architekturális réteg van, amelyek egyetlen I/O-kérést érintenek. Ez a viselkedés várható, és a szolgáltatás ismert korlátozása, amely általában átmeneti hálózati problémákból vagy az Azure Storage-erőforrások ideiglenes elérhetetlenné válásából ered. A rendszer általában beavatkozás nélkül helyreáll.

Ez az előfordulás ritka, és nem befolyásolja a távoli tárolóba irányuló I/O-kérések átlagos késését. Az I/O-kérést kezdeményező számítási feladattól vagy száltól függően az ügyfelek megfigyelhetik az SQL-parancsok időtúllépéseit és a megnövekedett késést bizonyos helyzetekben, míg mások egyáltalán nem tapasztalnak semmilyen hatást. Például nem minden hosszan futó I/O-kérés akadályozza a műveleteket, mint például az előre olvasható oldalhozzáférés, amely gyakran nincs hatással az olvasási folyamatokra.

A következő generációs általános célú szolgáltatásszint-frissítés segíthet a probléma megoldásában, mivel többletköltség nélkül javítja a teljesítményt és a megbízhatóságot. A vásárlókat arra ösztönözzük, hogy fedezzék fel, ezáltal javítva a szolgáltatás minőségét.

Ha ez a hiba tartósan jelentkezik, fontolja meg a számítási feladatok mintáinak, a tárolási teljesítménynek és a hálózati konfigurációknak a áttekintését. Emellett fontolja meg az alacsony I/O-késési követelményekkel rendelkező alkalmazásokhoz tervezett üzletileg kritikus szolgáltatási szint használatát is.

Az összes lehetséges lehetőségről a felügyelt SQL-példányok fogyasztásának és teljesítményének monitorozására és riasztására, lásd az Azure SQL Managed Instance monitorozási lehetőségeiről szóló blogbejegyzést. A felügyelt SQL-példány valós idejű teljesítményének monitorozásához lásd: Felügyelt Azure SQL-példány valós idejű teljesítménymonitorozása.

Lásd megfigyelés és teljesítmény optimalizálás.

Lásd felügyelt Azure SQL-példányok valós idejű teljesítményfigyelését.

Igen, az SQL Profiler támogatott a felügyelt SQL-példányon. További információ: SQL Profiler. Ehelyett azonban érdemes megfontolni az Extended Events használatát a "nyomkövetési" tevékenységhez, mivel ez kevésbé befolyásolja a figyelt példányt. További információ: Bővített események.

Nem, ezek nincsenek támogatva. A DMVs és LekérdezéstárSQL Profiler és XEvents segítségével monitorozhatja az adatbázisokat.

Lásd Az SQL Server és az Azure SQLprocesszorhasználatának monitorozása című témakört.

Igen. Útmutatásért lásd: Felügyelt SQL-példányok riasztásainak létrehozása. További tippek és trükkök: a blog.

A riasztási metrikák csak felügyelt SQL-példányokhoz érhetők el. A felügyelt SQL-példányban lévő egyes adatbázisokra vonatkozó riasztási metrikák nem érhetők el.

A felügyelt SQL-példány tárolási mérete a kiválasztott szolgáltatási szinttől függ (általános célú, következő generációs általános célú vagy üzleti szempontból kritikus). A szolgáltatási szintek tárolási korlátozásairól Erőforráskorlátokcímű témakörben olvashat.

A példányokban elérhető tárhely minimális mérete 32 GB. A tárterület 32 GB-os növekményekben adható hozzá a maximális tárterületméretig. Az első 32 GB ingyenes.

Igen, megvásárolhatja a kiegészítő tárhelyet a számítástól függetlenül, bizonyos mértékig. Nézze meg a maximális példány fenntartott tárhelyet a Táblában.

A tárolási teljesítmény optimalizálásához tekintse meg a általános célú tárolás legjobb gyakorlatait.

Nem, a biztonsági mentési tárterület nem lesz levonva a felügyelt SQL-példány tárterületéből. A biztonsági mentési tároló független a példány tárterületétől, és mérete nem korlátozott. A biztonsági mentési tárterületet a példányadatbázisok biztonsági mentésének megőrzéséhez szükséges időtartam korlátozza, amely legfeljebb 35 napig konfigurálható. További információ: Automatikus biztonsági mentések.

A felügyelt SQL-példányok automatikus biztonsági mentéseinek nyomon követéséhez tekintse át a biztonsági mentési tevékenység monitorozását.

Igen, az Azure Blob Storage-ban létrehozhat egy csak másolásra alkalmas teljes biztonsági másolatot, de az csak felügyelt SQL-példányra visszaállítható. További részletekért lásd: Csak másolási biztonsági másolatok. A csak másolással történő biztonsági mentés azonban nem lehetséges, ha az adatbázist a szolgáltatás által felügyelt TDE titkosítja, mivel a titkosításhoz használt tanúsítvány nem érhető el. Ilyen esetben az időponthoz kötött visszaállítás funkcióval helyezze át az adatbázist egy másik felügyelt SQL-példányba, vagy váltson az ügyfél által felügyelt kulcsra.

Igen, az SQL Server 2005+ verzióiban támogatott és elérhető. Natív visszaállítás használatához töltse fel a .bak fájlt az Azure Blob Storage-ba, és hajtsa végre a T-SQL-parancsokat. További információ: natív visszaállítás URL-címről.

Igen, de csak az SQL Server 2022-re, az SQL Server 2022 általános támogatási időszakában. Lehetséges, hogy a jövőben néhány felügyelt Azure SQL-példány-szolgáltatás is bevezethető, amelyek az adatbázis formátumának módosítását igénylik, így a biztonsági másolatok nem kompatibilisek az SQL Server legújabb verziójával. Az ilyen funkciókhoz való hozzáféréshez explicit bejelentkezés szükséges.

A rendszeradatbázisok nem replikálódnak a feladatátvételi csoport másodlagos példányára. Ezért a rendszeradatbázisok objektumaitól függő forgatókönyvek a másodlagos példányon lehetetlenek, kivéve, ha az objektumok manuálisan jönnek létre a másodlagos példányon. Kerülő megoldásért lásd: Az objektumtól függő forgatókönyvek engedélyezése a rendszeradatbázisokból.

A szükséges NSG- és UDR-szabályok dokumentálva vannak a szolgáltatás által támogatott alhálózati konfigurációban, és a szolgáltatás automatikusan beállítja. Ne feledje, hogy ezek a szabályok csak azok, amelyekre szükségünk van a szolgáltatás fenntartásához. Ha egy felügyelt SQL-példányhoz szeretne csatlakozni, és különböző funkciókat szeretne használni, be kell állítania más funkcióspecifikus szabályokat, és fenn kell tartania őket.

Hogyan állíthatok be bejövő NSG-szabályokat a felügyeleti portokon?

A felügyelt SQL-példány felelős a felügyeleti portokra vonatkozó szabályok beállításáért. A szabályok a szolgáltatás által támogatott alhálózati konfiguráció nevű funkciókon keresztül vannak beállítva. Ennek célja a felügyeleti forgalom zavartalan áramlásának biztosítása az SLA teljesítéséhez.

Igen. Elemezheti a hálózati biztonsági csoporton áthaladó forgalmat a Network Watcher-folyamatnaplókkonfigurálásával.

Igen. Miután kiépített egy felügyelt SQL-példányt, beállíthatja az 1433-at futtató port bejövő hozzáférését vezérlő NSG-t. Javasoljuk, hogy a lehető legnagyobb mértékben szűkítse az IP-tartományát.

Nem. Ez több okból sem támogatott:

• A bejövő felügyeleti kérelmekre adott válaszként szolgáló útválasztási forgalom aszimmetrikus lenne, és nem működne.
• A forgalom Azure Storage-ba való átirányítását az átviteli sebesség korlátozásai és késése befolyásolná, így így nem tudjuk biztosítani a várt szolgáltatásminőséget és rendelkezésre állást.
• Ezek a konfigurációk hajlamosak a hibákra, és nem támogathatók.

Igen. A legegyszerűbb módszer egy 0/0 szabály hozzáadása egy felügyelt SQL-példány alhálózatához társított UDR-hez a forgalom NVA-n keresztüli átirányításához.

Az alhálózatnak elegendő számú elérhető IP-címmel kell rendelkeznie. A felügyelt SQL-példányhoz tartozó virtuális hálózati alhálózat méretének meghatározásához tekintse meg a felügyelt Azure SQL-példányhoz szükséges alhálózatméretet és -tartományt.

Ha nincs elegendő IP-cím abban az alhálózatban, ahol a felügyelt SQL-példány ki van építve, hozzon létre egy új alhálózatot, és helyezze át a felügyelt SQL-példányt. Azt is javasoljuk, hogy az új alhálózat több lefoglalt IP-címmel legyen létrehozva, hogy a jövőbeli frissítési műveletek elkerüljék a hasonló helyzeteket. Megtudhatja, hogyan áthelyezni a felügyelt Azure SQL-példányt az alhálózatok között.

Nem. Használhat egy üres alhálózatot vagy egy olyan alhálózatot, amely már tartalmaz felügyelt példányokat.

Csak akkor nem, ha vannak felügyelt példányok benne. Ez egy Azure-beli hálózati infrastruktúra korlátozása. Csak megengedett további címterület hozzáadása egy üres alhálózathoz.

Igen. A felügyelt SQL-példányok online módon áthelyezhetők egy másik alhálózatra ugyanazon a virtuális hálózaton belül vagy egy másik virtuális hálózaton belül. Megtudhatja, hogyan áthelyezni a felügyelt Azure SQL-példányt az alhálózatok között.

Ez nem kötelező. Létrehozhat virtuális hálózatot felügyelt Azure SQL-példányhoz, vagy Konfigurálhat egy meglévő virtuális hálózatot a felügyelt Azure SQL-példányokhoz.

Nem. Jelenleg nem támogatjuk a felügyelt SQL-példányok olyan alhálózatban való elhelyezését, amely már tartalmaz más erőforrástípusokat.

Nem, ez nem támogatott. Egy felügyelt SQL-példány gazdagépneve leképezésre kerül a felügyelt SQL-példány virtuális fürtje előtt elhelyezkedő terheléselosztóra. Mivel egy virtuális klaszter több felügyelt példányt is üzemeltethet, a kapcsolat nem irányítható a megfelelő SQL-felügyelt példányhoz, ha nincs megadva a neve. További információ a felügyelt SQL-példány virtuális fürt architektúrájáról: Virtuális fürt kapcsolati architektúrája.

Jelenleg csak a felügyelt SQL-példányok privát végpontjai garantálják a statikus IP-címeket.

Ritka, de szükséges helyzetekben előfordulhat, hogy egy felügyelt SQL-példányt online módon migrálunk egy új virtuális fürtbe, vagy a virtuális fürtön belül egy másik virtuális gép csoportba, a technológiai verem módosításai miatt, amelyek a szolgáltatás biztonságát és megbízhatóságát javítják. Amikor egy új virtuális gépcsoportba vagy virtuális klaszterbe migrál, az SQL kezelőpéldány gazdagépnevéhez hozzárendelt IP-cím megváltozik. A felügyelt SQL-példányok szolgáltatása nem nyújt statikus IP-címtámogatást, és fenntartja a jogot az IP-cím előzetes értesítés nélküli módosítására a rendszeres karbantartási ciklusok részeként.

Ezért a virtuális hálózat helyi és nyilvános végpontjai csak a hozzájuk társított tartománynevekkel érhetők el. Határozottan elriasztjuk attól, hogy az IP-címük változatlanságára hagyatkozzanak, mivel ez elérhetetlenséghez vezethet annak ellenére, hogy a szolgáltatás jól működik.

Ha olyan statikus IP-címre van szüksége, amely a virtuális hálózaton kívülről érhető el, üzembe helyezheti az Azure Firewallt egy előtérbeli nyilvános IP-címmel, és konfigurálhat egy NAT-szabályt, amely lefordítja a bejövő forgalmat egy felügyelt SQL-példány privát végpontjára. Ezután állítsa be a DNS-feloldásokat, vagy konfigurálja az ügyfél-aliasokat úgy, hogy az SQL-ügyfelek a felügyelt SQL-példány teljes tartománynevén keresztül csatlakozzanak a tűzfal nyilvános IP-címéhez.

Igen, egy nyilvános végpont engedélyezhető az internetről érkező bejövő forgalom engedélyezéséhez a felügyelt SQL-példány eléréséhez. További információ: Felügyelt SQL-példány használata nyilvános végpontokkal és Nyilvános végpont konfigurálása felügyelt SQL-példányban.

Nem, egyéni port használata nem érhető el. A virtuális hálózatok helyi végpontjai esetében a felügyelt SQL-példány az alapértelmezett 1433-es portszámot használja, a nyilvános adatvégpontok esetében pedig a felügyelt SQL-példány az alapértelmezett 3342-es portszámot használja.

A globális virtuális hálózatok közötti társviszony-létesítés és az Azure virtual WAN is ajánlott módszer két felügyelt példány csatlakoztatására különböző régiókban. Az Express Route-kapcsolatcsoport-társviszony-létesítés alternatív lehetőség. Ha a környezetben egyik lehetőség sem lehetséges, az egyetlen másik csatlakozási módszer a helyek közötti VPN-kapcsolat. Helyek közötti VPN konfigurálása az Azure portalon, PowerShell, vagy a Azure CLI használatával.

Az Azure SQL Managed Instance támogatása 2020. szeptember 22-én bővült az újonnan létrehozott virtuális fürtök globális virtuális hálózati peeringjével. Így a virtuális hálózatok közötti társviszony-létesítés támogatott az üres alhálózatokban 2020. szeptember 22. után létrehozott felügyelt példányok esetében. Az ezen időpont előtt üzembe helyezett példányok esetében a peering támogatása az ugyanazon régión belüli hálózatokra korlátozódik, mivel a globális virtuális hálózati peering korlátozásai ezt szükségessé teszik. További információkért tekintse át az Azure Virtual Networks gyakori kérdésekvonatkozó szakaszát.

Globális virtuális hálózati társítás használatához a 2020. szeptember előtt létrehozott példányokkal fontolja meg egy karbantartási idősáv konfigurálását. Vagy érdemes lehet áthelyezni a példányt egy új alhálózatra. Bármelyik lehetőség áthelyezi a példányt egy új virtuális fürtre, amely támogatja a globális virtuális hálózatok közötti összekapcsolást.

Tekintse meg , hogyan ellenőrizheti, hogy a virtuális fürt támogatja-e a globális virtuális hálózati társviszony-létesítést, szükség esetén.

Az adatkiszivárgási kockázatok csökkentése érdekében az ügyfeleknek ajánlott biztonsági beállításokat és vezérlőket alkalmazniuk:

• Kapcsolja be transzparens adattitkosítás (TDE) minden adatbázison.
• A Common Language Runtime (CLR) kikapcsolása. Ez a beállítás a helyszínen is ajánlott.
• Csak Microsoft Entra-hitelesítést használjon.
• A példány elérése alacsony szintű jogosultsággal rendelkező DBA-fiókkal.
• Konfigurálja a JIT jumpbox-hozzáférést a sysadmin-fiókhoz.
• Kapcsolja be SQL-naplózási, és integrálja riasztási mechanizmusokkal.
• Kapcsolja be fenyegetésészlelési a Microsoft Defender for SQL csomagból.
• Alkalmazzon egy szolgáltatásvégpont-szabályzatot az alhálózatra az Azure Storage felé irányuló kimenő forgalom szabályozásához.
• A CREATE EXTERNAL TABLE AS SELECT (CETAS) alapértelmezés szerint tiltva van. Ha engedélyezni szeretné a CETAS-t a allowPolyBaseExport kiszolgáló konfigurációs beállításával, tekintse meg KÜLSŐ TÁBLA LÉTREHOZÁSA SELECT (CETAS).

Igen. Lásd: Privát DNS-nevek feloldása felügyelt Azure SQL-példányban.

Igen. Lásd: Privát DNS-nevek feloldása felügyelt Azure SQL-példányban.

Az időzóna konfigurációja akkor állítható be, ha egy felügyelt SQL-példány első üzembe helyezése történik. A meglévő felügyelt SQL-példány időzónájának módosítása nem támogatott. További információ: időzóna korlátozásai.

A megkerülő megoldások közé tartozik egy új felügyelt SQL-példány létrehozása a megfelelő időzónával, majd manuális biztonsági mentés és visszaállítás végrehajtása, vagy az ajánlott, példányközi időponthoz kötött visszaállítás végrehajtása.

Igen, az ügyfelek létrehozhatnak olyan bejelentkezéseket, amelyek a sysadmin szerepkör tagjai. Azok az ügyfelek, akik a sysadmin jogosultságot feltételezik, szintén felelősséget vállalnak a példány működtetéséért, ami negatívan befolyásolhatja az SLA-kötelezettségvállalást. Ha bejelentkezést szeretne hozzáadni a sysadmin kiszolgálói szerepkörhöz, tekintse meg a Microsoft Entra-hitelesítést.

Igen, a felügyelt Azure SQL-példány támogatja a transzparens adattitkosítást (TDE). További információ: felügyelt SQL-példány transzparens adattitkosítása.

Igen, az Azure Key Vault a BYOK-szcenárióhoz elérhető az Azure SQL Felügyelt Példányhoz. További információ: Transzparens adattitkosítás ügyfél által felügyelt kulccsal.

Igen, megteheted. Titkosított SQL Server-adatbázis migrálásához exportálnia és importálnia kell a meglévő tanúsítványokat a felügyelt SQL-példányba. Ezután készítsen egy teljes adatbázis-biztonsági másolatot, és állítsa vissza egy felügyelt SQL-példányra.

Az Azure Database Migration Service használatával is migrálhatja a TDE titkosított adatbázisokat.

A felügyelt SQL-példány TDE-védője az Azure Cloud Shell használatával elforgatható. Útmutatásért tekintse meg felügyelt SQL-példány transzparens adattitkosítását az Azure Key Vaultsaját kulcsával.

Igen, nem kell visszafejtenie az adatbázist a felügyelt SQL-példányra való visszaállításhoz. A titkosított biztonsági mentési fájlból való adatolvasáshoz meg kell adnia egy tanúsítványt/kulcsot, amelyet a forrásrendszer titkosítási kulcsának védelmeként használnak a felügyelt SQL-példánynak. Kétféleképpen teheti meg:

• Tanúsítványvédő feltöltése a felügyelt SQL-példányhoz. Ez csak a PowerShell használatával végezhető el. A példaszkript az egész folyamatot ismerteti.
• Aszimmetrikus kulcsvédő feltöltése az Azure Key Vaultba, és az SQL-felügyelt példány arra mutat. Ez a megközelítés hasonlít a saját kulcsú (BYOK) TDE-használati esethez, amely a Key Vault-integrációt is használja a titkosítási kulcs tárolásához. Ha nem titkosítási kulcsvédőként szeretné használni a kulcsot, és csak elérhetővé szeretné tenni a kulcsot a felügyelt SQL-példány számára a titkosított adatbázisok visszaállításához, kövesse a BYOK TDE beállításának utasításait, és ne jelölje be a jelölőnégyzetet : A kijelölt kulcs legyen az alapértelmezett TDE-védő.

Miután elérhetővé tette a titkosítási védőt a felügyelt SQL-példány számára, folytathatja a szabványos adatbázis-visszaállítási eljárást.

A SQL Managed Instance egy vCore-alapú vásárlási modellt kínál.

Az Azure SQL előnyeivel a következő módokon takaríthat meg költségeket:

• Maximalizálhatja a helyszíni licencekbe történő meglévő befektetéseket, és akár 55%-ot is megtakaríthat Azure Hybrid Benefit.
• Véglegesítse a számítási erőforrások foglalását, és takarítson meg akár 33%-ot Azure Reservations előnyével. Kombinálja ezt az előnyt az Azure Hybrid juttatással akár 82%-os megtakarítás érdekében.
• Akár 55 százalékot is megtakaríthat a listaárakhoz képest Azure Dev/Test Pricing Benefit, amely kedvezményes díjszabást kínál a folyamatban lévő fejlesztési és tesztelési számítási feladatokhoz.

A fenntartott példány előny igénybevételéhez az előfizetési típusnak vállalati szerződésnek (ajánlatszámok: MS-AZR-0017P vagy MS-AZR-0148P) vagy egyedi szerződésnek, amely használatalapú fizetéses díjszabást alkalmaz (ajánlatszámok: MS-AZR-0003P vagy MS-AZR-0023P) kell lennie. További információ a foglalásokról: Azure Reservations.

Bizonyos korlátozásokkal lemondhatja, kicserélheti vagy visszatérítheti a foglalásokat. További információért lásd az Azure Foglalások önkiszolgáló cseréit és visszatérítéseit.

A felügyelt SQL-példány díjszabási beállításainak megismeréséhez tekintse meg Díjszabás lap.

Ezt a Microsoft Cost Management megoldáshasználatával teheti meg. Lépjen a Előfizetések az Azure portal részére, és válassza a Költségelemzést lehetőséget.

Használja a Halmozott költségek lehetőséget, majd szűrjön Erőforrástípus szerintmicrosoft.sql/managedinstances.

Kompatibilis Microsoft- vagy külső ügyféleszközökkel érheti el a felügyelt SQL-példányt, és az Azure-számlán nem számítunk fel további költségeket. Ha azonban egyes eszközök licencet igényelnek, akkor jogi licenccel rendelkező szoftverre van szükség. Ezt a követelményt az egyes szerszámgyártókkal kötött külön megállapodások szabályozzák.

A megvásárolt fenntartott adattárterülettel egyenlő mennyiségű szabad biztonsági mentési tárhelyet kap, függetlenül a biztonsági mentési megőrzési időszaktól. Ha a biztonsági mentési tárterület kihasználtsága a lefoglalt ingyenes biztonsági mentési tárterületen belül van, a felügyelt SQL-példányok automatikus biztonsági mentései nem járnak többletköltséggel, ezért ingyenesek. A biztonsági mentési tárterület szabad terület feletti használatának túllépése további költségeket eredményez. A részletekért tekintse meg a díjszabási lapjának Biztonsági mentési tár című szakaszát. A felügyelt SQL-példányok automatikus biztonsági mentéséről további technikai információk érhetők el A biztonsági mentési tár használatánakismertetése.

A biztonsági mentési tárterület költségeit az Azure Portalon követheti nyomon. Útmutatásért lásd: Automatikus biztonsági mentések költségeinek monitorozása.

A biztonsági mentés tárolási költségeinek optimalizálásához tekintse meg a felügyelt SQL-példány biztonsági mentési tárolási költségeinek finomhangolását.

Az Azure SQL Managed Instance üzembe helyezésével járó előnyök, költségek és kockázatok jobb megismeréséhez elérhető egy Forrester-tanulmány is: Az Azure SQL Managed Instance adatbázisok teljes gazdasági hatása.

Az SQL-bejelentkezésekhez tartozó felügyelt SQL-példány jelszavas szabályzata örökli az Azure platformszabályzatait, amelyek a felügyelt SQL-példányt tartalmazó virtuális fürtöt alkotó virtuális gépekre lesznek alkalmazva. Jelenleg ezen beállítások egyikét sem lehet módosítani, mivel ezeket a beállításokat az Azure határozza meg, és a felügyelt SQL-példány örökli.

Fontos

Az Azure platform anélkül módosíthatja a szabályzat követelményeit, hogy a szabályzatra támaszkodó szolgáltatások értesítése nélkül értesítenék.

Minden bejelentkezéskor be kell állítania a jelszavát, és a maximális életkor elérése után módosítania kell a jelszavát.

szabályzat	biztonsági beállítások
Jelszó maximális életkora	42 nap
Jelszó minimális életkora	Egy napon
Jelszó minimális hossza	14 karakter
A jelszónak meg kell felelnie az összetettségi követelményeknek	Engedélyezve

Igen, a bejelentkezési szinten szabályozható CHECK_POLICY és CHECK_EXPIRATION mezők. Az aktuális beállításokat a következő T-SQL-parancs végrehajtásával ellenőrizheti:

SELECT *
FROM sys.sql_logins

Ezt követően módosíthatja a megadott bejelentkezési beállításokat a következő végrehajtásával:

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(Cserélje le a "teszt" elemet a kívánt bejelentkezési névre, és módosítsa a szabályzatot és a lejárati értékeket.)

Lásd az Azure SQL Database & SQL Managed Instance tanúsítványcseréjét.

Lásd SQL Managed Instance esetén az Azure karbantartási események tervét.

A 2022. novemberi funkcióhullámban bevezetett módosítások és képességek alapértelmezés szerint minden példány számára elérhetők. Mivel már nem szükséges külön műveletet elvégezni egy példány regisztrálásához, a 2022. novemberi funkcióhullámot említő beállítások el lettek távolítva az Azure Portalról.

Szavazhat egy új felügyelt SQL-példány funkcióra, vagy létrehozhat egy új fejlesztési ötletet a felügyelt SQL-példány visszajelzési fórumában. Így hozzájárulhat a termékfejlesztéshez, és segíthet rangsorolni a lehetséges fejlesztéseket.

Az Azure-támogatási kérések létrehozásának módjáról az Azure támogatási kérésének létrehozása című témakörben olvashat.

A zónaredundancia jelenleg nem támogatott a következő generációs általános célú szolgáltatási szint esetében.

Nem, a következő generációs általános célú szolgáltatásszint-frissítés jelenleg nem támogatott a példánykészletek vagy a készleten belüli példányok esetében.