Új DBA a felhőben – Az Azure SQL Database kezelése a migrálás után

A következőkre vonatkozik:Azure SQL Database

Az ön által felügyelt környezetből egy PaaS-be, például az Azure SQL Database-be való migrálás összetett lehet. Ez a cikk az Azure SQL Database legfontosabb funkcióit emeli ki az önálló és készletezett adatbázisokhoz, így az alkalmazások elérhetőek, teljesíthetők, biztonságosak és rugalmasak maradnak.

Az Azure SQL Database alapvető jellemzői a következők:

• Adatbázis-monitorozás az Azure Portallal
• Üzletmenet-folytonosság és vészhelyreállítás (BCDR)
• Biztonság és megfelelőség
• Intelligens adatbázisok monitorozása és karbantartása
• Adatáthelyezés

Jegyzet

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

Adatbázisok monitorozása az Azure Portal használatával

Az Azure Monitor metrikái és riasztásai, beleértve az ajánlott riasztási szabályokat, megtalálhatók a következő dokumentumban: Az Azure SQL Database monitorozása metrikákkal és riasztásokkal. További információ a szolgáltatási szintekről a DTU-alapú vásárlási modell áttekintésében és a vCore-alapú vásárlási modellben található.

A teljesítménymetrikák riasztásait konfigurálhatja. Válassza a Riasztás hozzáadása gombot a Metrika ablakban. A riasztás konfigurálásához kövesse a varázslót. Riasztást kaphat, ha a metrikák túllépnek egy bizonyos küszöbértéket, vagy ha a metrika egy bizonyos küszöbérték alá esik.

Ha például az adatbázis számítási feladatainak növekedésére számít, beállíthatja az e-mail-riasztást, amikor az adatbázis eléri a 80% bármelyik teljesítménymetrikán. Ezt korai figyelmeztetésként használhatja annak megállapításához, hogy mikor kell a következő legnagyobb számítási méretre váltania.

A teljesítménymetrikák segítségével azt is megállapíthatja, hogy alacsonyabb számítási méretre tud-e visszaminősíteni. Vegye figyelembe azonban azokat a számítási feladatokat, amelyek kiugróan magasak vagy ingadoznak, mielőtt döntést hoz az alacsonyabb számítási méretre való áttérésről.

Üzletmenet-folytonosság és vészhelyreállítás (BCDR)

Az üzletmenet-folytonosság és a vészhelyreállítási képességek lehetővé teszik a vállalkozás folytatását vészhelyzet esetén. A katasztrófa lehet adatbázisszintű esemény (például valaki véletlenül elvet egy kulcsfontosságú táblát), vagy egy adatközpontszintű esemény (regionális katasztrófa, például szökőár).

Hogyan hozhatok létre és kezelhetek biztonsági mentéseket az SQL Database-en?

Az Azure SQL Database automatikusan biztonsági másolatot készít az adatbázisokról. A platform minden héten teljes biztonsági mentést, néhány óránként különbségi biztonsági mentést és 5 percenként napló biztonsági mentést készít a vészhelyreállítás hatékonyságának biztosítása érdekében, és az adatvesztés minimális. Az első teljes biztonsági mentés azonnal megtörténik, amint létrehoz egy adatbázist. Ezek a biztonsági másolatok egy bizonyos, megőrzési időszaknak nevezett időszakra érhetők el, amely a választott szolgáltatási szinttől függően változik. A megőrzési időszakon belül bármely időpontra visszaállíthatja a point in Time Recovery (PITR) használatával.

Emellett a hosszú távú adatmegőrzési biztonsági mentési funkció lehetővé teszi, hogy a biztonsági mentési fájlokat akár 10 évig is megőrizze, és ezen időszakon belül bármikor visszaállítsa az adatokat ezekből a biztonsági másolatokból. Az adatbázis biztonsági másolatai georeplikált tárolóban vannak tárolva, hogy rugalmasságot biztosítsanak a regionális katasztrófáktól. Ezeket a biztonsági másolatokat bármely Azure-régióban bármikor visszaállíthatja a megőrzési időszakon belül. További információ: Üzletmenet-folytonosság az Azure SQL Database-ben.

Hogyan biztosítható az üzletmenet folytonossága adatközpontszintű katasztrófa vagy regionális katasztrófa esetén?

Az adatbázis biztonsági másolatai georeplikált tárolóban vannak tárolva, hogy regionális katasztrófa esetén visszaállíthassa a biztonsági mentést egy másik Azure-régióba. Ezt geo-visszaállításnak nevezzük. A geo-visszaállításokkal kapcsolatos további információkért és időzítésért lásd: Geo-visszaállítás az Azure SQL Database.

Kritikus fontosságú adatbázisok esetén az Azure SQL Database aktív georeplikációskínál, amely az eredeti adatbázis georeplikált másodlagos másolatát hozza létre egy másik régióban. Ha például az adatbázis eredetileg az USA nyugati régiójában található, és regionális katasztrófatűrést szeretne, hozzon létre egy aktív georeplikát az USA nyugati régiójában és az USA keleti régiójában. Amikor katasztrófa sújtja az USA nyugati régióját, áttérhet az USA keleti régiójára.

Az aktív georeplikáció mellett a feladatátvételi csoportok segítenek az adatbázisok csoportjainak replikációját és feladatátvételét kezelni. Létrehozhat egy feladatátvételi csoportot, amely ugyanazon vagy különböző régiókban több adatbázist tartalmaz. Ezután kezdeményezheti a feladatátvételi csoport összes adatbázisának feladatátvételét a másodlagos régióba. További információ: Feladatátvételi csoportok áttekintése & ajánlott eljárások (Azure SQL Database).

Az adatközpontok vagy a rendelkezésre állási zónák hibáinak rugalmassága érdekében győződjön meg arról, hogy a zónaredundancia engedélyezve van az adatbázis vagy a rugalmas készlet számára.

Aktívan figyelje az alkalmazást egy katasztrófa esetére, és kezdjék el a feladatátvételt a másodlagos rendszerre. Legfeljebb négy ilyen aktív georeplikát hozhat létre különböző Azure-régiókban. Még jobb lesz. Ezekhez a másodlagos aktív georeplikákhoz csak olvasási hozzáféréssel is hozzáférhet. Ez segít csökkenteni a földrajzilag elosztott alkalmazásforgatókönyvek késését.

Hogyan néz ki a vészhelyreállítás az SQL Database-ben?

A vészhelyreállítás konfigurálása és kezelése az Azure SQL Database-ben csupán néhány lépéssel elvégezhető, ha az aktív georeplikációt vagy az átvételi csoportokathasználja. Továbbra is figyelnie kell az alkalmazást és annak adatbázisát bármilyen regionális katasztrófa esetén, és át kell állnia a másodlagos régióba az üzletmenet folytonosságának helyreállítása érdekében.

További információ: Azure SQL Database Disaster Recovery 101.

Biztonság és megfelelőség

Az SQL Database-en belüli biztonság adatbázisszinten és platformszinten érhető el. Az alábbiak szerint szabályozhatja és biztosíthatja az alkalmazás optimális biztonságát:

• Identitás> hitelesítés (SQL-hitelesítés és hitelesítés a Microsoft Entra-azonosítóval).
• Monitorozási tevékenység (ellenőrzési és fenyegetés érzékelési).
• A tényleges adatok védelme (transzparens adattitkosítás [TDE] és Always Encrypted).
• Bizalmas és kiemelt adatokhoz való hozzáférés szabályozása (sorszintű biztonság és dinamikus adatmaszkolás).

Microsoft Defender for Cloud központosított biztonsági felügyeletet biztosít az Azure-ban, a helyszínen és más felhőkben futó számítási feladatok között. Megtekintheti, hogy az alapvető SQL Database-védelem, például a naplózás és a transzparens adattitkosítás [TDE] konfigurálva van-e minden erőforráson, és saját igényei alapján hozhat létre szabályzatokat.

Milyen felhasználói hitelesítési módszerek érhetők el az SQL Database-ben?

Az SQL Database-ben két hitelesítési módszer érhető el:

• Microsoft Entra hitelesítés
• SQL-hitelesítés

A Windows-hitelesítés nem támogatott. A Microsoft Entra ID egy központosított identitás- és hozzáférés-kezelési szolgáltatás. A Microsoft Entra ID egyszeri bejelentkezési (SSO) hozzáférést biztosít a szervezet személyzetéhez. Ez azt jelenti, hogy a hitelesítő adatok meg vannak osztva az Azure-szolgáltatásokban a könnyebb hitelesítés érdekében.

A Microsoft Entra ID támogatja többtényezős hitelesítést, és könnyen integrálható a Windows Server Active Directory. Ez lehetővé teszi továbbá, hogy az SQL Database és az Azure Synapse Analytics többtényezős hitelesítést és vendégfelhasználói fiókokat kínáljon egy Microsoft Entra-tartományon belül. Ha már használja a helyszíni Active Directoryt, összevonhatja a Microsoft Entra-azonosítóval, hogy kiterjeszthesse a címtárat az Azure-ra.

Az SQL-hitelesítés csak a felhasználónevet és a jelszót támogatja a felhasználók hitelesítéséhez egy adott kiszolgálón lévő adatbázishoz.

Ha...	SQL Database / Azure Synapse Analytics
SQL Server helyszíni környezetben használt AD	AD összekapcsolása a Microsoft Entra-azonosítóval, és a Microsoft Entra-hitelesítés használata. A szövetség lehetővé teszi az egyszeri belépés használatát.
Többtényezős hitelesítés kényszerítése	Többtényezős hitelesítés megkövetelése szabályzatként feltételes hozzáféréssel, és a Microsoft Entra többtényezős hitelesítés használata.
Ön a Microsoft Entra hitelesítő adataival jelentkezik be a Windowsba összevont tartományból.	Microsoft Entra-hitelesítés használata.
Az Azure-ral nem összefűzött tartomány hitelesítő adataival bejelentkezett felhasználók a Windowsba	Használja a Microsoft Entra integrált hitelesítést.
Olyan középső szintű szolgáltatások használata, amelyeknek csatlakozniuk kell az SQL Database-hez vagy az Azure Synapse Analyticshez	Használja a Microsoft Entra integrált hitelesítést.
Technikai követelmény az SQL-hitelesítés használatához	SQL-hitelesítés használata

Hogyan korlátozhatjam vagy szabályozhatom az adatbázisomhoz való kapcsolódást?

Több technika is rendelkezésre áll, amelyekkel optimális kapcsolatszervezést érhet el az alkalmazás számára.

• Tűzfalszabályok
• Virtuális hálózati szolgáltatásvégpontok
• Fenntartott IP-címek

Tűzfal

Alapértelmezés szerint a kiszolgálón belüli adatbázisokhoz való összes kapcsolat nem engedélyezett, kivéve (opcionálisan) a más Azure-szolgáltatásokból érkező kapcsolatokat. Tűzfalszabályokkal csak olyan entitások (például fejlesztői gépek) számára nyithatja meg a kiszolgálóhoz való hozzáférést, amelyeket jóváhagy, ha engedélyezi a számítógép IP-címét a tűzfalon keresztül. Emellett megadhatja a kiszolgálóhoz való hozzáférést engedélyezni kívánt IP-címek tartományát is. A szervezet fejlesztői gépének IP-címei például egyszerre is hozzáadhatók, ha megad egy tartományt a Tűzfal beállításai lapon.

Tűzfalszabályokat a kiszolgáló szintjén vagy az adatbázis szintjén hozhat létre. A kiszolgálószintű IP-tűzfalszabályok az Azure Portalon vagy az SSMS-sel hozhatók létre. További információ a kiszolgálószintű és adatbázisszintű tűzfalszabály beállításáról: IP-tűzfalszabályok létrehozása az SQL Database-ben.

Szolgáltatásvégpontok

Alapértelmezés szerint az adatbázis úgy van konfigurálva, hogy engedélyezze az Azure-szolgáltatások és -erőforrások számára a kiszolgáló elérését, ami azt jelenti, hogy az Azure-beli virtuális gépek megpróbálhatnak csatlakozni az adatbázishoz. Ezeket a kísérleteket továbbra is hitelesíteni kell. Ha nem szeretné, hogy az adatbázist bármely Azure IP-cím elérhetővé tegye, letilthatja az Azure-szolgáltatások és -erőforrások számára a kiszolgáló elérését. Emellett a virtuális hálózati szolgáltatásvégpontokat is konfigurálhatja.

A szolgáltatásvégpontok lehetővé teszik, hogy kritikus Azure-erőforrásait csak a saját privát azure-beli virtuális hálózata számára tegye elérhetővé. Ez a beállítás megszünteti az erőforrásokhoz való nyilvános hozzáférést. A virtuális hálózat és az Azure közötti forgalom az Azure gerinchálózatán marad. Szolgáltatásvégpontok nélkül kényszerített bújtatású csomag-útválasztást kap. A virtuális hálózat arra kényszeríti az internetes forgalmat a szervezet és az Azure Service felé, hogy ugyanazon az útvonalon haladjon át. A szolgáltatásvégpontok esetében ezt optimalizálhatja, mivel a csomagok közvetlenül a virtuális hálózatból a szolgáltatásba áramlanak az Azure gerinchálózatán.

Fenntartott IP-címek

Egy másik lehetőség a fenntartott IP-címek kiépítése a virtuális gépekhez, és a konkrét virtuális gépek IP-címeit a kiszolgáló tűzfalbeállításaihoz hozzáadni. Ha fenntartott IP-címeket rendel hozzá, elkerülheti azt a problémát, hogy a változó IP-címek miatt frissítenie kell a tűzfalszabályokat.

Milyen porton csatlakozom az SQL Database-hez?

Az SQL Database az 1433-as porton keresztül kommunikál. Ha vállalati hálózaton belülről szeretne csatlakozni, egy kimenő szabályt kell hozzáadnia a szervezet tűzfalbeállításaihoz. Útmutatásként kerülje el az 1433-as port hozzáférhetővé tételét az Azure környezetén kívül.

Hogyan monitorozhatom és szabályozhatom a tevékenységet a kiszolgálón és az adatbázison az SQL Database-ben?

SQL Database auditálása

Az Azure SQL Database naplózása rögzíti az adatbázis-eseményeket, és egy naplófájlba írja őket az Azure Storage-fiókjában. A naplózás különösen akkor hasznos, ha szeretne betekintést nyerni a lehetséges biztonsági és szabályzatsértésekbe, a jogszabályi megfelelőség fenntartásába stb. Ez lehetővé teszi az események bizonyos kategóriáinak definiálását és konfigurálását, amelyekről úgy gondolja, hogy naplózásra van szükség, és ennek alapján előre konfigurált jelentéseket és irányítópultokat kaphat az adatbázisban előforduló események áttekintéséhez.

Ezeket a naplózási szabályzatokat az adatbázis szintjén vagy a kiszolgáló szintjén is alkalmazhatja. További információkért engedélyezze az SQL Database naplózását.

Fenyegetésészlelés

A fenyegetésészlelés lehetővé teszi a naplózással felderített biztonsági vagy szabályzatsértések elhárítását. Nem kell biztonsági szakértőnek lennie ahhoz, hogy elhárítsa a rendszer lehetséges fenyegetéseit vagy szabálysértéseit. A fenyegetésészlelés olyan beépített képességekkel is rendelkezik, mint például az SQL-injektálási észlelés, amely az adatbázis-alkalmazások támadásának meglehetősen gyakori módja. A fenyegetésészlelés több algoritmuskészletet futtat, amelyek észlelik a lehetséges biztonsági réseket és az SQL-injektálási támadásokat, valamint rendellenes adatbázis-hozzáférési mintákat (például szokatlan helyről vagy ismeretlen tagtól való hozzáférést).

A biztonsági tisztviselők vagy más kijelölt rendszergazdák e-mailben értesítést kapnak, ha fenyegetést észlelnek az adatbázisban. Minden értesítés részletesen ismerteti a gyanús tevékenységeket, és javaslatokat tesz a fenyegetés további kivizsgálására és enyhítésére. A fenyegetésészlelés bekapcsolásáról további információt a fenyegetésészlelés engedélyezése című témakörben talál.

Hogyan védhetem meg az adataimat általában az SQL Database-ben?

A titkosítás erős módszert biztosít a bizalmas adatok védelmére és biztosítására a behatolókkal szemben. A titkosított adatok a visszafejtési kulcs nélkül nem használhatók a behatoló számára. Így egy további védelmi réteget ad hozzá az SQL Database-ben beépített meglévő biztonsági rétegekhez. Az SQL Database-ben az adatok védelmének két aspektusa van:

• A tárolt adatok az adat- és naplófájlokban
• Az adatok repülés közben

Az SQL Database-ben alapértelmezés szerint a tárolóalrendszeren nyugalomban lévő adatok és naplófájlok mindig transzparens adattitkosítással (TDE) vannak védve. A biztonsági másolatok is titkosítva vannak. A TDE-vel nem szükséges módosításokat végrehajtani az alkalmazás oldalán, amelyek hozzáférnek ezekhez az adatokhoz. A titkosítás és a visszafejtés transzparens módon történik; ezért a nevet.

A bizalmas adatok repülés közbeni és inaktív védelméhez az SQL Database egy Always Encrypted nevű funkciót biztosít. Az Always Encrypted az ügyféloldali titkosítás egy formája, amely titkosítja az adatbázis bizalmas oszlopait (így titkosítva vannak az adatbázisgazdák és a jogosulatlan felhasználók számára). A kiszolgáló először megkapja a titkosított adatokat.

Az Always Encrypted kulcsa is az ügyféloldalon van tárolva, így csak a jogosult ügyfelek fejthetik vissza a bizalmas oszlopokat. A kiszolgáló és az adatgazdák nem látják a bizalmas adatokat, mivel a titkosítási kulcsok az ügyfélen vannak tárolva. Az Always Encrypted a tábla végén lévő bizalmas oszlopokat titkosítja a jogosulatlan ügyfelektől a fizikai lemezig.

Az Always Encrypted támogatja az egyenlőségi összehasonlításokat, így a DBA-k továbbra is lekérdezhetik a titkosított oszlopokat az SQL-parancsaik részeként. Az Always Encrypted számos kulcstároló-beállítással használható, például Azure Key Vault, Windows tanúsítványtárolóval és helyi hardveres biztonsági modulokkal.

Jellemzők	Mindig Titkosítva	Transzparens adattitkosítás
titkosítás span	Teljes körű	Nyugalmi állapotban lévő adatok
kiszolgáló hozzáférhet a bizalmas adatokhoz	Nem	Igen, mivel a titkosítás a inaktív adatokhoz tartozik
Engedélyezett T-SQL-műveletek	Egyenlőség összehasonlítása	Minden T-SQL-felület elérhető
A funkció használatához szükséges alkalmazásmódosítások	Minimális	Minimális
Titkosítás részletessége	Oszlopszint	Adatbázis szintje

Hogyan korlátozhatjam az adatbázis bizalmas adataihoz való hozzáférést?

Minden alkalmazás bizalmas adatokkal rendelkezik az adatbázisban, amelyeket védeni kell attól, hogy mindenki látható legyen. A szervezet bizonyos munkatársainak meg kell tekintenie ezeket az adatokat, másoknak azonban nem szabad, hogy megtekintsék ezeket az adatokat. Ilyen esetekben a bizalmas adatokat maszkolva kell megadni, vagy egyáltalán nem szabad közzétenni. Az SQL Database két ilyen módszert kínál, hogy megakadályozza a jogosulatlan felhasználók számára a bizalmas adatok megtekintését:

• A dinamikus adatmaszkolás egy adatmaszkolási funkció, amely lehetővé teszi a bizalmas adatexpozíció korlátozását azáltal, hogy maszkolja azokat az alkalmazásréteg nem kiemelt felhasználói számára. Olyan maszkolási szabályt definiálhat, amely maszkolási mintát hoz létre (például az állampolgári azonosító SSN utolsó négy számjegyének megjelenítésére: XXX-XX-0000, és a legtöbb karaktert X karakterrel maszkolja), valamint meghatározhatja, hogy mely felhasználókat zárják ki a maszkolási szabályból. A maszkolás menet közben történik, és különböző maszkoló funkciók érhetők el a különböző adatkategóriákhoz. A dinamikus adatmaszkolással automatikusan észlelheti az adatbázisban lévő bizalmas adatokat, és maszkolást alkalmazhat rá.

• A sorszintű biztonság lehetővé teszi a sorszintű hozzáférés szabályozását. Ez azt jelenti, hogy az adatbázistábla bizonyos sorai a lekérdezést végrehajtó felhasználó (csoporttagság vagy végrehajtási környezet) alapján rejtettek. Az alkalmazáslogika egyszerűsítése érdekében a hozzáférési korlátozás az adatbázis szintjén, nem pedig az alkalmazásszinten történik. Először hozzon létre egy szűrő predikátumot, szűrje ki a nem közzétett sorokat, és a következő biztonsági szabályzat határozza meg, hogy kik férhetnek hozzá ezekhez a sorokhoz. Végül a végfelhasználó futtatja a lekérdezést, és a felhasználó jogosultságától függően vagy megtekinti ezeket a korlátozott sorokat, vagy egyáltalán nem látja őket.

Hogyan kezelhetem a titkosítási kulcsokat a felhőben?

Az Always Encrypted (ügyféloldali titkosítás) és a Transzparens adattitkosítás (inaktív titkosítás) esetében is vannak kulcskezelési lehetőségek. Javasoljuk, hogy rendszeresen forgassa el a titkosítási kulcsokat. A rotációs gyakoriságnak összhangban kell lennie a belső szervezeti előírásokkal és a megfelelőségi követelményekkel.

Transzparens adattitkosítás (TDE)

A TDE-ben kétkulcsos hierarchia van – az egyes felhasználói adatbázisok adatait egy szimmetrikus AES-256 adatbázis-egyedi adatbázistitkosítási kulcs (DEK) titkosítja, amelyet egy kiszolgáló-egyedi aszimmetrikus RSA 2048 főkulcs titkosít. A főkulcs a következők valamelyikével kezelhető:

• Automatikusan az Azure SQL Database által
• Vagy ha az Azure Key Vaultot használja kulcstárolóként

Alapértelmezés szerint a TDE főkulcsát az Azure SQL Database kezeli. Ha a szervezet szeretné szabályozni a főkulcsot, az Azure Key Vaultot használhatja kulcstárolóként. Az Azure Key Vault használatával a szervezet átveszi a kulcsok biztosításának, cseréjének és az engedélyek vezérlésének irányítását. TDE főkulcsának elforgatása vagy váltása gyors, mivel csak újra titkosítja a DEK-t. A biztonsági és adatkezelési szerepkörök elkülönítésével rendelkező szervezetek esetében a biztonsági rendszergazda kiépítheti a TDE-főkulcs kulcsanyagát az Azure Key Vaultban, és egy Azure Key Vault-kulcsazonosítót adhat meg az adatbázis-rendszergazdának a kiszolgáló inaktív állapotában történő titkosításhoz. A Key Vault úgy lett kialakítva, hogy a Microsoft ne lát és ne nyerje ki a titkosítási kulcsokat. Emellett központosított kulcskezelést is kap a szervezet számára.

Mindig Titkosítva

Az Always Encryptedben kétkulcsos hierarchia is – a bizalmas adatok oszlopát egy AES 256 oszlopos titkosítási kulcs (CEK) titkosítja, amelyet viszont egy oszlop főkulcsa (CMK) titkosít. Az Always Encryptedhez megadott ügyfélillesztők nem korlátozzák a CMK-k hosszát. A CEK titkosított értékét az adatbázis tárolja, a CMK pedig egy megbízható kulcstárolóban, például a Windows Tanúsítványtárolóban, az Azure Key Vaultban vagy egy hardveres biztonsági modulban van tárolva.

• A CEK és a CMK is elforgatható.

• A CEK rotációja egy adatkezelési művelet, és a titkosított oszlopokat tartalmazó táblák méretétől függően időigényes lehet. Ezért érdemes ennek megfelelően megtervezni a CEK-rotációkat.

• A CMK forgatása azonban nem befolyásolja az adatbázis teljesítményét, és külön szerepkörökkel is megvalósítható.

Az alábbi ábra az Always Encrypted oszlop főkulcsainak kulcstároló beállításait mutatja be:

Hogyan optimalizálhatom és biztonságossá tehetem a szervezetem és az SQL Database közötti forgalmat?

A szervezet és az SQL Database közötti hálózati forgalom általában a nyilvános hálózaton keresztül van irányítva. Ezt az útvonalat azonban optimalizálhatja, és biztonságosabbá teheti az Azure ExpressRoute-tal. Az ExpressRoute privát kapcsolaton keresztül kiterjeszti a vállalati hálózatot az Azure-platformra. Ezzel nem megy át a nyilvános interneten. Emellett nagyobb biztonságot, megbízhatóságot és útválasztás-optimalizálást is kaphat, amely alacsonyabb hálózati késéseket és gyorsabb sebességet eredményez, mint általában a nyilvános interneten. Ha jelentős adattömb átvitelét tervezi a szervezet és az Azure között, az ExpressRoute használata költségelőnyt jelenthet. Három különböző kapcsolati modell közül választhat a szervezet és az Azure közötti kapcsolathoz:

• Felhőbeli Exchange-áthelyezés
• bármely
• pont–pont

Az ExpressRoute lehetővé teszi, hogy a megvásárolt sávszélesség-korlát akár kétszeresére növekedjen extra költségek nélkül. A régiók közötti kapcsolatot az ExpressRoute használatával is konfigurálhatja. Az ExpressRoute-kapcsolatszolgáltatók listáját az ExpressRoute-partnerek és a társviszony-létesítési helyek című témakörben találja. Az alábbi cikkek részletesebben ismertetik az Express Route-t:

• Bevezetés az Expressz Útvonal
• előfeltételek
• munkafolyamatok

Az SQL Database megfelel-e bármilyen jogszabályi követelménynek, és ez hogyan segíti a saját szervezetem megfelelőségét?

Az SQL Database számos szabályozási követelménynek felel meg. Ha meg szeretné tekinteni az SQL Database által teljesített legújabb kompatibilitási halmazt, látogasson el a Microsoft adatvédelmi központjába , és tekintse át a szervezet számára fontos complianciákat, hogy lássa, az SQL Database szerepel-e a megfelelő Azure-szolgáltatásokban. Bár az SQL Database megfelelő szolgáltatásként van minősítve, támogatja a szervezet szolgáltatásának megfelelőségét, de nem garantálja automatikusan.

Intelligens adatbázisok monitorozása és karbantartása a migrálás után

Miután migrálja az adatbázist az SQL Database-be, figyelnie kell az adatbázist (például ellenőriznie kell az erőforrás-kihasználtságot vagy a DBCC-ellenőrzéseket), és rendszeres karbantartást kell végeznie (például újra kell építenie vagy átrendeznie az indexeket, statisztikákat stb.). Az SQL Database az előzménytrendeket és a rögzített metrikákat és statisztikákat használja az adatbázis proaktív figyeléséhez és karbantartásához, hogy az alkalmazás mindig optimálisan fusson. Bizonyos esetekben az Azure SQL Database a konfiguráció beállításától függően automatikusan el tudja végezni a karbantartási feladatokat. Az adatbázist az SQL Database-ben három szempont figyelheti:

• Teljesítményfigyelés és -optimalizálás
• Biztonsági optimalizálás
• Költségoptimalizálás

Teljesítményfigyelés és -optimalizálás

A Lekérdezési teljesítményelemzésekkel testre szabott javaslatokat kaphat az adatbázis-számítási feladatokhoz, hogy az alkalmazások optimális szinten fussanak. Beállíthatja azt is, hogy ezek a javaslatok automatikusan érvényesüljenek, és ne kelljen karbantartási feladatokat végeznie. Az SQL Database Advisor használatával automatikusan implementálhatja az indexjavaslatokat a számítási feladat alapján. Ezt automatikus hangolásnak nevezzük. A javaslatok az alkalmazás számítási feladatainak változásakor változnak, hogy a legrelevánsabb javaslatokat nyújthassa. Lehetősége van arra is, hogy manuálisan tekintse át ezeket a javaslatokat, és saját belátása szerint alkalmazza őket.

Biztonsági optimalizálás

Az SQL Database végrehajtható biztonsági javaslatokat nyújt az adatok és a fenyegetésészlelés biztonságossá tételéhez olyan gyanús adatbázis-tevékenységek azonosításához és kivizsgálásához, amelyek potenciális szálat jelenthetnek az adatbázishoz. sebezhetőségi felmérési egy adatbázis-ellenőrzési és jelentéskészítési szolgáltatás, amely lehetővé teszi az adatbázisok biztonsági állapotának nagy mértékű monitorozását, valamint a biztonsági kockázatok azonosítását és az Ön által meghatározott biztonsági alapkonfigurációtól való eltérést. Minden vizsgálat után megjelenik a végrehajtható lépések és a szervizelési szkriptek testreszabott listája, valamint egy értékelési jelentés, amely a megfelelőségi követelmények teljesítéséhez használható.

A Microsoft Defender for Cloud segítségével azonosíthatja a biztonsági javaslatokat minden területen, és gyorsan alkalmazhatja őket.

Költségoptimalizálás

Az Azure SQL Platform elemzi a kiszolgáló adatbázisainak kihasználtsági előzményeit, hogy kiértékelje és javaslatot tesz a költségoptimalizálási lehetőségekre. Ez az elemzés általában néhány hétnyi tevékenységet vesz igénybe a végrehajtható javaslatok elemzéséhez és összeállításához.

Előfordulhat, hogy szalagcímértesítéseket kap az Azure SQL Serveren a költségjavaslatokról. További információ: Rugalmas készletek, amelyek segítségével több adatbázist kezelhet és skálázhat az Azure SQL Database-ben, valamint megtervezheti és kezelheti az Azure SQL Database költségeit.

Hogyan monitorozhatom az SQL Database teljesítményét és erőforrás-kihasználtságát?

Az SQL Database teljesítmény- és erőforrás-kihasználtságát az alábbi módszerekkel figyelheti:

adatbázis-figyelő

Az Adatbázis-figyelő részletes számítási feladatok monitorozási adatait gyűjti össze, hogy részletes képet kapjon az adatbázis teljesítményéről, konfigurációjáról és állapotáról. Az Azure Portal irányítópultjai egyablakos nézetet biztosítanak az Azure SQL-tulajdonról, valamint részletes képet az egyes figyelt erőforrásokról. Az adatok egy központi adattárba kerülnek az Azure-előfizetésében. Lekérdezheti, elemezheti, exportálhatja, megjelenítheti az összegyűjtött adatokat, és integrálhatja azokat az alárendelt rendszerekkel.

Az adatbázis-figyelőről az alábbi cikkekben talál további információt:

• Azure SQL-számítási feladatok monitorozása adatbázis-figyelővel (előzetes verzió)
• Rövid útmutató: Figyelő létrehozása az Azure SQL monitorozásához (előzetes verzió)
• Figyelő létrehozása és konfigurálása (előzetes verzió)
• Database Watcher-adatgyűjtés és -adatkészletek (előzetes verzió)
• Database Watcher monitorozási adatainak elemzése (előzetes verzió)
• Adatbázis-figyelő – gyakori kérdések

Azure Portal

Az Azure Portal egy adatbázis kihasználtságát jeleníti meg az adatbázis kiválasztásával és a diagram kiválasztásával az Áttekintés panelen. A diagramot úgy módosíthatja, hogy több metrikát jelenítsen meg, beleértve a processzor százalékos értékét, a DTU százalékát, az adat IO-százalékos értékét, a munkamenetek százalékos arányát és az adatbázis méretét.

Ebből a diagramból erőforrások alapján is konfigurálhat riasztásokat. Ezek a riasztások lehetővé teszik, hogy e-mailben válaszoljon az erőforrás-feltételekre, írjon HTTPS/HTTP-végpontra, vagy műveletet hajthasson végre. További információ: Riasztások létrehozása az Azure SQL Database-hez és az Azure Synapse Analyticshez az Azure Portal használatával.

Dinamikus felügyeleti nézetek

Lekérdezheti a sys.dm_db_resource_stats dinamikus felügyeleti nézetet, hogy visszaadja az erőforrás-felhasználás statisztikai előzményeit az elmúlt óráról, valamint a sys.resource_stats rendszerkatalógus nézetét az elmúlt 14 nap előzményeinek visszaadásához.

Lekérdezési teljesítményelemzés

lekérdezési teljesítményelemzési lehetővé teszi, hogy egy adott adatbázis fő erőforrás-felhasználó lekérdezéseinek és hosszú ideig futó lekérdezéseinek előzményeit láthassa. A lekérdezéseket gyorsan azonosíthatja TOP az erőforrások kihasználtsága, időtartama és a végrehajtás gyakorisága alapján. Nyomon követheti a lekérdezéseket, és észlelheti a regressziót. Ehhez a funkcióhoz engedélyezni kell Lekérdezéstár, és aktívnak kell lennie az adatbázishoz.

Teljesítményproblémákat tapasztalok: Miben különbözik az SQL Database hibaelhárítási módszertana az SQL Servertől?

A lekérdezési és adatbázis-teljesítményproblémák diagnosztizálására használt hibaelhárítási technikák jelentős része változatlan marad: ugyanaz az adatbázismotor működteti a felhőt. Az Azure SQL Database segítségével még egyszerűbben háríthatja el és diagnosztizálhatja a teljesítményproblémákat. Ezen korrekciós műveletek némelyikét az Ön nevében is végrehajthatja, és bizonyos esetekben proaktív módon automatikusan kijavíthatja őket.

A teljesítményproblémák elhárításának megközelítése jelentős előnyökkel járhat olyan intelligens funkciók használatával, mint a Lekérdezési teljesítményelemzés (QPI) és a Database Advisor együttes használata, így a módszertani különbségek ebben a tekintetben eltérnek – már nem kell manuális munkát végeznie, hogy kiőrölje azokat az alapvető részleteket, amelyek segíthetnek a probléma elhárításában. A platform elvégzi a kemény munkát. Erre példa a QPI. A QPI használatával egészen a lekérdezési szintig lehatolt, áttekintheti az előzménytrendeket, és megállapíthatja, hogy pontosan mikor történt a lekérdezés visszafejtése. A Database Advisor olyan javaslatokat nyújt, amelyek segíthetnek az általános teljesítmény javításában, például hiányzó indexek, indexek elvetése, lekérdezések paraméterezése stb.

A teljesítmény hibaelhárításakor fontos megállapítani, hogy csak az alkalmazás vagy az azt támogató adatbázis befolyásolja-e az alkalmazás teljesítményét. A teljesítményproblémák gyakran az alkalmazásrétegben jelentkeznek. Ez lehet az architektúra vagy az adathozzáférési minta. Tegyük fel például, hogy van egy csevegőalkalmazása, amely érzékeny a hálózati késésre. Ebben az esetben az alkalmazás nehezebben működik, mert sok rövid kérés megy oda-vissza az alkalmazás és a kiszolgáló között egy túlterhelt hálózaton, és ezek a menetidők gyorsan összejönnek. Ebben az esetben a teljesítmény javítása érdekében Batch-lekérdezéseket használhat, amelyek segítenek csökkenteni a lekerekítési késést, és javítani az alkalmazás teljesítményét.

Emellett, ha az adatbázis általános teljesítményének romlását észleli, figyelheti a sys.dm_db_resource_stats és sys.resource_stats dinamikus felügyeleti nézeteket, hogy megértse a processzor-, az IO- és a memóriahasználatot. A teljesítményre hatással lehet, ha az adatbázis erőforrás-éhezésben van. Előfordulhat, hogy a számítási feladatok növekvő és csökkenő igényeinek megfelelően módosítania kell a számítási méretet és/vagy a szolgáltatási szintet.

A teljesítményproblémák finomhangolására vonatkozó javaslatok átfogó halmazát az adatbázis finomhangolása című témakörben találhatja meg.

Hogyan biztosíthatom, hogy a megfelelő szolgáltatási szintet és számítási méretet használjam?

Az SQL Database két különböző vásárlási modellt kínál: a régebbi DTU-modellt és a rugalmasabb vCore-vásárlási modellt. További információ: Az Azure SQL Database virtuális mag- és DTU-alapú vásárlási modelljeinek összehasonlítása.

A lekérdezési és adatbázis-erőforrás-felhasználást bármelyik vásárlási modellben figyelheti. További információ: Monitorozás és teljesítményhangolás. Ha úgy találja, hogy a lekérdezések/adatbázisok folyamatosan terheltek, fontolóra veheti magasabb számítási teljesítmény választását. Hasonlóképpen, ha úgy tűnik, hogy nem használja annyira az erőforrásokat csúcsidőben, fontolja meg a jelenlegi számítási méretről való leskálázást. Érdemes megfontolni, hogy Azure Automation segítségével egy ütemterv szerint állítsa be az SQL-adatbázisok méretezését.

Ha SaaS-alkalmazásmintával vagy adatbázis-konszolidációs forgatókönyvvel rendelkezik, fontolja meg egy rugalmas készlet használatát a költségoptimalizáláshoz. A rugalmas készlet kiválóan alkalmas adatbázis-konszolidációra és költségoptimalizálásra. További információ több adatbázis rugalmas készlet használatával történő kezeléséről: Készletek és adatbázisok kezelése.

Milyen gyakran kell adatbázis-integritási ellenőrzéseket futtatnom az adatbázisomon?

Az SQL Database automatikusan és adatvesztés nélkül képes kezelni az adatsérülés bizonyos osztályait. Ezeket a beépített technikákat a szolgáltatás az igény felmerülésekor használja. A szolgáltatásokon belüli adatbázis biztonsági mentések rendszeresen tesztelve vannak azáltal, hogy visszaállítjuk és futtatjuk rajtuk DBCC CHECKDB. Ha problémák merülnek fel, az SQL Database proaktív módon kezeli őket.

Az automatikus oldaljavítás a sérült vagy adatintegritási problémákkal rendelkező lapok kijavítására szolgál. Az adatbázisoldalak mindig az alapértelmezett CHECKSUM beállítással vannak ellenőrizve, amely ellenőrzi a lap integritását. Az SQL Database proaktívan figyeli és ellenőrzi az adatbázis adatintegritását, és elhárítja a felmerülő problémákat. Igény szerint saját integritás-ellenőrzéseket is futtathat. További információ: Adatintegritás az SQL Database-ben.

Adatáthelyezés a migrálás után

Hogyan exportálhatok és importálhatok adatokat BACPAC-fájlokként az SQL Database-ből az Azure Portal használatával?

• Exportálás: Az adatbázist BACPAC-fájlként exportálhatja az Azure SQL Database-ben az Azure Portalról:

  

• Importálás: BACPAC-fájlként is importálhat adatokat az Adatbázisba az Azure SQL Database-ben az Azure Portal használatával:

  

Hogyan szinkronizálhatom az adatokat az SQL Database és az SQL Server között?

Ezt többféleképpen érheti el:

• Adatszinkronizálás: Ez a funkció segít az adatok kétirányú szinkronizálásában több SQL Server-adatbázis és az SQL Database között. Az SQL Server-adatbázisokkal való szinkronizáláshoz telepítenie és konfigurálnia kell a szinkronizálási ügynököt egy helyi számítógépen vagy egy virtuális gépen, és meg kell nyitnia az 1433-at kimenő TCP-portot.

• Tranzakcióreplikálás: A tranzakcióreplikálással szinkronizálhatja az adatokat egy SQL Server-adatbázisból az Azure SQL Database-be úgy, hogy az SQL Server-példány a közzétevő és az Azure SQL Database az előfizető. Egyelőre csak ez a beállítás támogatott. További információ arról, hogyan migrálhatja az adatokat egy SQL Server-adatbázisból az Azure SQL-be minimális állásidővel: Tranzakcióreplikálás használata

Kapcsolódó tartalom

• Monitorozás és teljesítményhangolás az Azure SQL Database-ben és a felügyelt Azure SQL-példányban