Nová dba v cloudu – správa služby Azure SQL Database po migraci

Platí pro: Azure SQL Database

Přechod z tradičního samoobslužného prostředí s vlastním ovládáním na prostředí PaaS se zpočátku může zdát trochu ohromující. Jako vývojář aplikací nebo DBA byste chtěli znát základní funkce platformy, které by vám pomohly udržet aplikaci dostupnou, výkonnou, zabezpečenou a odolnou – vždy. Cílem tohoto článku je přesně to udělat. Tento článek stručně uspořádá prostředky a poskytuje několik doprovodných materiálů k tomu, jak nejlépe využít klíčové funkce Azure SQL Database s jednoúčelovými a fondovými databázemi ke správě a zajištění efektivního fungování aplikace a dosažení optimálních výsledků v cloudu. Typická cílová skupina tohoto článku by byla ta, kdo:

• Vyhodnocují migraci jejich aplikací do služby Azure SQL Database – modernizace aplikací.
• Probíhá migrace aplikací – probíhající scénář migrace.
• Nedávno jste dokončili migraci do služby Azure SQL Database – Nová dba v cloudu.

Tento článek popisuje některé základní charakteristiky azure SQL Database jako platformy, kterou můžete snadno použít při práci s izolované databáze a databázemi ve fondu v elastických fondech. Jsou to tyto:

• Monitorování databází na portálu Azure
• Provozní kontinuita a zotavení po havárii (BCDR)
• Zabezpečení a dodržování předpisů
• Inteligentní monitorování a údržba databáze
• Pohyb dat

Poznámka:

ID Microsoft Entra se dříve označovalo jako Azure Active Directory (Azure AD).

Monitorování databází na portálu Azure

Informace o metrikách a upozorněních služby Azure Monitor, včetně doporučených pravidel upozornění, najdete v tématu Monitorování služby Azure SQL Database s metrikami a upozorněními. Další informace o úrovních služeb najdete v článcích o nákupním modelu založeném na DTU a nákupních modelech založených na virtuálních jádrech.

Můžete nakonfigurovat upozornění na metriky výkonu. V okně Metrika vyberte tlačítko Přidat upozornění. Nastavte upozornění podle pokynů průvodce. Můžete určit, zda chcete být upozorněni na překročení zadané prahové hodnoty, nebo naopak když metrika poklesne pod zadanou mez.

Například pokud očekáváte nárůst zatížení databáze, můžete nastavit e-mailové upozornění pro případ, že databáze překročí 80 % kterékoli výkonové metriky. Můžete to použít jako včasné upozornění, abyste zjistili, kdy možná budete muset přepnout na další nejvyšší velikost výpočetních prostředků.

Metriky výkonu vám také můžou pomoct určit, jestli můžete downgradovat na nižší výpočetní velikost. Mějte ale na paměti úlohy, které se špičkou nebo fluktuací před rozhodováním o přechodu na nižší velikost výpočetních prostředků.

Provozní kontinuita a zotavení po havárii (BCDR)

Možnosti provozní kontinuity a zotavení po havárii vám umožní pokračovat v podnikání jako obvykle v případě havárie. Havárií může být událost na úrovni databáze (například někdo omylem zahodí zásadní tabulku) nebo událost na úrovni datového centra (například regionální katastrofa, například datová katastrofa).

Návody vytváření a správa záloh ve službě SQL Database

V Azure SQL Database nevytáčíte zálohy, a to proto, že nemusíte. SQL Database automaticky zálohuje databáze za vás, takže už se nemusíte starat o plánování, pořizování a správu záloh. Platforma provádí úplné zálohování každý týden, rozdílové zálohování každých několik hodin a zálohování protokolů každých 5 minut, aby se zajistilo efektivní zotavení po havárii a minimální ztráta dat. První úplné zálohování proběhne hned po vytvoření databáze. Tyto zálohy jsou pro vás k dispozici po určitou dobu s názvem Doba uchovávání informací a liší se podle zvolené úrovně služby. SQL Database poskytuje možnost obnovení k jakémukoli bodu v čase v tomto období uchovávání pomocí obnovení k určitému bodu v čase (PITR).

Kromě toho funkce Dlouhodobé uchovávání (LTR) umožňuje uchovávat soubory záloh po delší dobu, konkrétně po dobu až 10 let, a obnovit data z těchto záloh v jakémkoli okamžiku v daném období. Zálohy databází se navíc uchovávají v geograficky replikovaném úložišti, aby se zajistila odolnost proti regionální katastrofě. Tyto zálohy můžete obnovit také v libovolné oblasti Azure v libovolném časovém okamžiku v rámci doby uchovávání. Další informace najdete v přehledu provozní kontinuity.

Návody zajistit kontinuitu podnikových procesů v případě havárie na úrovni datacentra nebo regionální katastrofy

Zálohy databáze se ukládají do geograficky replikovaného úložiště, abyste zajistili, že během regionální havárie můžete zálohu obnovit do jiné oblasti Azure. Říká se tomu geografické obnovení. Cíl bodu obnovení (RPO) pro geografické obnovení je obecně < 1 hodina a ERT (Odhadovaná doba obnovení) – několik minut až hodin.

Azure SQL Database nabízí pro důležité databáze aktivní geografickou replikaci, která vytvoří geograficky replikovanou sekundární kopii původní databáze v jiné oblasti. Pokud je například vaše databáze původně hostovaná v oblasti Azure USA – západ a chcete odolnost proti havárii v oblasti regionální havárie, vytvořte aktivní geografickou repliku databáze v oblasti USA – západ do OBLASTI USA – východ. Když udeří kalamita na USA – západ, můžete převzít služby při selhání oblasti USA – východ.

Kromě aktivní geografické replikace poskytují skupiny převzetí služeb při selhání pohodlný způsob správy replikace a převzetí služeb při selhání skupiny databází. Můžete vytvořit skupinu převzetí služeb při selhání, která obsahuje více databází ve stejných nebo různých oblastech. Pak můžete zahájit převzetí služeb při selhání všech databází ve skupině převzetí služeb při selhání do sekundární oblasti. Další informace najdete v tématu Skupiny převzetí služeb při selhání.

Pokud chcete dosáhnout odolnosti proti chybám datového centra nebo zóny dostupnosti, ujistěte se, že je pro databázi nebo elastický fond povolená redundance zóny.

Aktivně monitorujte aplikaci po havárii a zahajte převzetí služeb při selhání sekundární. V různých oblastech Azure můžete vytvořit až čtyři takové aktivní geografické repliky. Je to ještě lepší. K těmto sekundárním aktivním geografickým replikám můžete přistupovat také pro přístup jen pro čtení. To je velmi užitečné, aby se snížila latence scénáře geograficky distribuovaných aplikací.

Jak zotavení po havárii vypadá s SQL Database

Konfiguraci a správu zotavení po havárii je možné provést jen s několika kroky ve službě Azure SQL Database, když používáte aktivní geografickou replikaci nebo skupiny převzetí služeb při selhání. Abyste obnovili kontinuitu podnikových procesů, stále musíte monitorovat aplikaci a její databázi pro případnou regionální havárii a převzít služby při selhání sekundární oblasti.

Další informace najdete v tématu Zotavení po havárii služby Azure SQL Database 101.

Zabezpečení a dodržování předpisů

SQL Database bere zabezpečení a ochranu osobních údajů velmi vážně. Zabezpečení ve službě SQL Database je k dispozici na úrovni databáze a na úrovni platformy a je nejlépe pochopitelné při kategorizaci do několika vrstev. Na každé vrstvě se dostanete k řízení a zajištění optimálního zabezpečení pro vaši aplikaci. Vrstvy jsou:

• Identita a ověřování (ověřování SQL pomocí Microsoft Entra ID (dříve Azure Active Directory).
• Aktivita monitorování (auditování a detekce hrozeb).
• Ochrana skutečných dat (transparentní šifrování dat [TDE] a Always Encrypted [AE]).
• Řízení přístupu k citlivým a privilegovaným datům (zabezpečení na úrovni řádků a dynamické maskování dat)

Microsoft Defender for Cloud nabízí centralizovanou správu zabezpečení napříč úlohami běžícími v Azure, místně a v jiných cloudech. Můžete si prohlédnout, jestli je pro všechny prostředky nakonfigurovaná základní ochrana služby SQL Database, jako je auditování a transparentní šifrování dat [TDE], a vytvářet zásady na základě vašich vlastních požadavků.

Jaké metody ověřování uživatelů se nabízejí ve službě SQL Database

Sql Database nabízí dvě metody ověřování:

• Ověřování Microsoft Entra
• Ověřování SQL

Ověřování systému Windows se nepodporuje. Microsoft Entra ID je centralizovaná služba pro správu identit a přístupu. Díky tomu můžete velmi pohodlně poskytnout přístup jednotného přihlašování (SSO) pracovníkům ve vaší organizaci. To znamená, že přihlašovací údaje se sdílejí napříč službami Azure pro jednodušší ověřování.

Microsoft Entra ID podporuje vícefaktorové ověřování a dá se snadno integrovat se službou Windows Server Active Directory. To také umožňuje službě SQL Database a Azure Synapse Analytics nabízet vícefaktorové ověřování a uživatelské účty hosta v rámci domény Microsoft Entra. Pokud už používáte místní službu Active Directory, můžete ho federovat s ID Microsoft Entra a rozšířit adresář do Azure.

Ověřování SQL podporuje pouze uživatelské jméno a heslo pro ověřování uživatelů v jakékoli databázi na daném serveru.

Pokud...	SQL Database / Azure Synapse Analytics
Místní použití AD na SQL Serveru	Federujte AD s ID Microsoft Entra a použijte ověřování Microsoft Entra. Federace umožňuje používat jednotné přihlašování.
Potřeba vynutit vícefaktorové ověřování	Vyžadovat vícefaktorové ověřování jako zásadu prostřednictvím podmíněného přístupu Microsoftu a používat vícefaktorové ověřování Microsoft Entra.
Přihlášení k Windows pomocí přihlašovacích údajů Microsoft Entra z federované domény	Použijte integrované ověřování Microsoft Entra.
Přihlášení k Windows pomocí přihlašovacích údajů z domény, která není federovaná s Azure	Použijte integrované ověřování Microsoft Entra.
Mají služby střední vrstvy, které se potřebují připojit ke službě SQL Database nebo Azure Synapse Analytics.	Použijte integrované ověřování Microsoft Entra.
Máte technický požadavek na použití ověřování SQL	Použití ověřování SQL

Návody omezit nebo řídit přístup k připojení k databázi

K dosažení optimální organizace připojení pro vaši aplikaci můžete využít několik technik.

• Pravidla brány firewall
• Koncové body služeb virtuální sítě
• Vyhrazené IP adresy

Brána firewall

Brána firewall brání přístupu k vašemu serveru z externí entity tím, že povoluje přístup k vašemu serveru pouze určitým entitám. Ve výchozím nastavení jsou všechna připojení k databázím uvnitř serveru zakázaná, s výjimkou (volitelně7) připojení přicházejících z jiných služeb Azure. Pomocí pravidla brány firewall můžete otevřít přístup k vašemu serveru pouze k entitě (například vývojářskému počítači), které schválíte, tím, že povolíte IP adresu tohoto počítače přes bránu firewall. Umožňuje také zadat rozsah IP adres, které chcete povolit přístup k serveru. NAPŘÍKLAD IP adresy vývojářských počítačů ve vaší organizaci lze přidat najednou zadáním rozsahu na stránce nastavení brány firewall.

Pravidla brány firewall můžete vytvořit na úrovni serveru nebo na úrovni databáze. Pravidla brány firewall protokolu IP na úrovni serveru je možné vytvořit pomocí webu Azure Portal nebo s SSMS. Další informace o nastavení pravidla brány firewall na úrovni serveru a databáze najdete v tématu: Vytvoření pravidel brány firewall protokolu IP ve službě SQL Database.

Koncové body služby

Ve výchozím nastavení je vaše databáze nakonfigurovaná tak, aby umožňovala službám a prostředkům Azure přístup k tomuto serveru. To znamená, že se jakýkoli virtuální počítač v Azure může pokusit připojit k vaší databázi. Tyto pokusy se stále musí ověřit. Pokud nechcete, aby vaše databáze byla přístupná žádnými IP adresami Azure, můžete zakázat možnost Povolit službám a prostředkům Azure přístup k tomuto serveru. Kromě toho můžete nakonfigurovat koncové body služeb virtuální sítě.

Koncové body služby (SE) umožňují zveřejnit důležité prostředky Azure pouze pro vaši vlastní privátní virtuální síť v Azure. Tím v podstatě eliminujete veřejný přístup k vašim prostředkům. Provoz mezi vaší virtuální sítí do Azure zůstane v páteřní síti Azure. Bez funkce SE získáte směrování paketů vynuceným tunelováním. Vaše virtuální síť vynutí internetový provoz do vaší organizace a provoz služby Azure, aby přecháděly přes stejnou trasu. S koncovými body služby to můžete optimalizovat, protože pakety proudí přímo z vaší virtuální sítě do služby v páteřní síti Azure.

Vyhrazené IP adresy

Další možností je zřídit rezervované IP adresy pro virtuální počítače a přidat tyto konkrétní IP adresy virtuálních počítačů do nastavení brány firewall serveru. Přiřazením rezervovaných IP adres ušetříte potíže s aktualizací pravidel brány firewall změnou IP adres.

Jaký port se připojím ke službě SQL Database na

Port 1433. SQL Database komunikuje přes tento port. Pokud se chcete připojit z podnikové sítě, musíte do nastavení brány firewall vaší organizace přidat odchozí pravidlo. Jako vodítko se vyhněte zveřejnění portu 1433 mimo hranice Azure.

Jak můžu monitorovat a regulovat aktivity na serveru a databázi ve službě SQL Database

Auditování služby SQL Database

S SQL Database můžete zapnout auditování ke sledování databázových událostí. Auditování služby SQL Database zaznamenává události databáze a zapisuje je do souboru protokolu auditu ve vašem účtu služby Azure Storage. Auditování je užitečné zejména v případě, že máte v úmyslu získat přehled o potenciálních porušeních zabezpečení a zásad, udržovat dodržování právních předpisů atd. Umožňuje definovat a konfigurovat určité kategorie událostí, které si myslíte, že potřebujete auditování a na základě toho můžete získat předkonfigurované sestavy a řídicí panel, abyste získali přehled událostí, ke kterým dochází ve vaší databázi. Tyto zásady auditování můžete použít na úrovni databáze nebo na úrovni serveru. Průvodce zapnutím auditování serveru nebo databáze najdete v tématu: Povolení auditování služby SQL Database.

Detekce hrozeb

Díky detekci hrozeb můžete velmi snadno reagovat na porušení zabezpečení nebo zásad zjištěných auditováním. Abyste mohli řešit potenciální hrozby nebo porušení systému, nemusíte být odborníkem na zabezpečení. Detekce hrozeb má také některé integrované funkce, jako je detekce injektáže SQL. Injektáž SQL je pokus o změnu nebo ohrožení dat a poměrně běžný způsob útoku na databázovou aplikaci obecně. Detekce hrozeb spouští několik sad algoritmů, které detekují potenciální ohrožení zabezpečení a útoky prostřednictvím injektáže SQL, a také neobvyklé vzory přístupu k databázi (například přístup z neobvyklého umístění nebo neznámého objektu zabezpečení). Bezpečnostní pracovníci nebo jiní určení správci obdrží e-mailové oznámení, pokud je v databázi zjištěna hrozba. Každé oznámení obsahuje podrobnosti o podezřelé aktivitě a doporučeních k dalšímu prošetření a zmírnění hrozby. Informace o zapnutí detekce hrozeb najdete v tématu: Povolení detekce hrozeb.

Návody obecně chránit moje data ve službě SQL Database

Šifrování poskytuje silný mechanismus pro ochranu a zabezpečení citlivých dat před útočníky. Šifrovaná data se pro útočníka bez dešifrovacího klíče nepoužívají. Tím se přidá další vrstva ochrany nad existující vrstvy zabezpečení integrovanou ve službě SQL Database. Ochrana dat ve službě SQL Database má dva aspekty:

• Vaše data uložená v datech a souborech protokolů
• Vaše data, která jsou v letu

Ve výchozím nastavení jsou neaktivní uložená data v datovém subsystému a souborech protokolů v subsystému úložiště zcela zašifrovaná prostřednictvím transparentní šifrování dat [TDE]. Vaše zálohy jsou také šifrované. U transparentního šifrování dat nejsou na straně vaší aplikace potřebné žádné změny, které k datům přistupují. Šifrování a dešifrování probíhá transparentně; a název. Pro ochranu citlivých dat v rámci letu a neaktivních uložených dat poskytuje SQL Database funkci s názvem Always Encrypted (AE). AE je forma šifrování na straně klienta, které šifruje citlivé sloupce v databázi (takže jsou v šifrovém textu správcům databází a neoprávněným uživatelům). Server obdrží zašifrovaná data, aby začal. Klíč funkce Always Encrypted je také uložený na straně klienta, takže citlivé sloupce můžou dešifrovat jenom autorizovaní klienti. Správci serveru a dat nevidí citlivá data, protože šifrovací klíče jsou uložené v klientovi. AE šifruje citlivé sloupce na konci tabulky od neautorizovaných klientů na fyzický disk. AE v současné době podporuje porovnání rovnosti, takže dbA můžou v rámci příkazů SQL dál dotazovat šifrované sloupce. Funkce Always Encrypted se dá použít s různými možnostmi úložiště klíčů, jako jsou Azure Key Vault, Úložiště certifikátů Windows a místní moduly hardwarového zabezpečení.

Charakteristiky	Funkce Always Encrypted	Transparentní šifrování dat
Rozsah šifrování	Kompletní	Neaktivní uložená data
Server má přístup k citlivým datům	No	Ano, protože šifrování je pro neaktivní uložená data
Povolené operace T-SQL	Porovnání rovnosti	K dispozici je všechna plocha T-SQL.
Změny aplikace potřebné k používání funkce	Minimální	Velmi minimální
Členitost šifrování	Úroveň sloupce	Úroveň databáze

Jak můžu omezit přístup k citlivým datům v databázi

Každá aplikace má v databázi určitou část citlivých dat, která je potřeba chránit před tím, aby byla viditelná všem. Někteří pracovníci v organizaci musí tato data zobrazit, ale ostatní by tato data neměli zobrazit. Jedním z příkladů je mzda zaměstnanců. Manažer by potřeboval přístup k informacím o mzdě pro své přímé zprávy, ale jednotliví členové týmu by neměli mít přístup k informacím o mzdách svých kolegů. Dalším scénářem jsou vývojáři dat, kteří můžou během fází vývoje nebo testování interagovat s citlivými daty, například sítě SAN zákazníků. Tyto informace nemusí být znovu vystaveny vývojáři. V takových případech musí být citlivá data buď maskovaná, nebo nemusí být vůbec zpřístupněna. SQL Database nabízí dva takové přístupy, které brání neoprávněným uživatelům v zobrazení citlivých dat:

Dynamické maskování dat je funkce maskování dat, která umožňuje omezit vystavení citlivých dat tím, že je maskuje na neprivilegované uživatele na aplikační vrstvě. Definujete pravidlo maskování, které může vytvořit vzor maskování (například pro zobrazení pouze posledních čtyř číslic národního id SSN: XXX-XX-0000 a označení většiny z nich jako Xs) a určení, kteří uživatelé mají být vyloučeni z pravidla maskování. Maskování probíhá průběžně a pro různé kategorie dat jsou k dispozici různé funkce maskování. Dynamické maskování dat umožňuje automaticky zjišťovat citlivá data v databázi a používat na ně maskování.

Zabezpečení na úrovni řádků umožňuje řídit přístup na úrovni řádku. To znamená, že určité řádky v tabulce databáze založené na uživateli, který spouští dotaz (členství ve skupině nebo kontext spuštění), jsou skryté. Omezení přístupu se provádí na databázové vrstvě místo na aplikační vrstvě, aby se zjednodušila logika vaší aplikace. Začnete tím, že vytvoříte predikát filtru, vyfiltrujete řádky, které nejsou vystavené, a zásady zabezpečení dále definující, kdo má k těmto řádkům přístup. Koncový uživatel nakonec spustí svůj dotaz a v závislosti na oprávnění uživatele buď zobrazí tyto omezené řádky, nebo je vůbec neuvidí.

Návody správa šifrovacích klíčů v cloudu

Existují možnosti správy klíčů pro šifrování Always Encrypted (šifrování na straně klienta) i transparentní šifrování dat (šifrování neaktivních uložených dat). Doporučuje se pravidelně obměňovat šifrovací klíče. Frekvence rotace by měla odpovídat interním předpisům organizace i požadavkům na dodržování předpisů.

Transparentní šifrování dat

Transparentní šifrování dat obsahuje hierarchii se dvěma klíči – data v každé uživatelské databázi se šifrují symetrickým šifrovacím klíčem databáze AES-256 (DEK), který je zase šifrovaný asymetrickým klíčem RSA 2048. Hlavní klíč je možné spravovat buď:

• Automaticky podle platformy – SQL Database.
• Nebo pomocí služby Azure Key Vault jako úložiště klíčů.

Ve výchozím nastavení je hlavní klíč pro transparentní šifrování dat spravován službou SQL Database pro usnadnění. Pokud by vaše organizace chtěla mít kontrolu nad hlavním klíčem, můžete jako úložiště klíčů použít Azure Key Vault . Pomocí služby Azure Key Vault předpokládá vaše organizace kontrolu nad zřizováním klíčů, obměnou a ovládacími prvky oprávnění. Obměny nebo přepínání typu hlavního klíče transparentního šifrování dat je rychlé, protože znovu zašifruje klíč DEK. Pro organizace s oddělením rolí mezi zabezpečením a správou dat může správce zabezpečení zřídit klíč hlavního klíče transparentního šifrování dat ve službě Azure Key Vault a poskytnout správci databáze identifikátor klíče služby Azure Key Vault, který použije k šifrování neaktivních uložených dat na serveru. Služba Key Vault je navržená tak, aby Microsoft neviděl ani extrahovala žádné šifrovací klíče. Získáte také centralizovanou správu klíčů pro vaši organizaci.

Funkce Always Encrypted

Ve funkci Always Encrypted existuje také hierarchie se dvěma klíči – sloupec citlivých dat je šifrovaný šifrovacím klíčem AES 256 sloupců (CEK), který je zase šifrovaný hlavním klíčem sloupce (CMK). Klientské ovladače poskytované pro funkci Always Encrypted nemají žádná omezení délky sad CMK. Šifrovaná hodnota klíče CEK je uložená v databázi a klíč CMK je uložený v důvěryhodném úložišti klíčů, jako je Windows Certificate Store, Azure Key Vault nebo modul hardwarového zabezpečení.

• Klíč CEK i CMK je možné otočit.
• Rotace CEK je velikost operace dat a může být časově náročná v závislosti na velikosti tabulek obsahujících šifrované sloupce. Proto je vhodné naplánovat obměny CEK odpovídajícím způsobem.
• Obměná sada CMK ale neruší výkon databáze a dá se provést s oddělenými rolemi.

Následující diagram znázorňuje možnosti úložiště klíčů pro hlavní klíče sloupců v funkci Always Encrypted.

Jak můžu optimalizovat a zabezpečit provoz mezi organizací a službou SQL Database

Síťový provoz mezi vaší organizací a službou SQL Database by se obecně směroval přes veřejnou síť. Pokud se ale rozhodnete tuto cestu optimalizovat a lépe zabezpečit, můžete se podívat na Azure ExpressRoute. ExpressRoute v podstatě umožňuje rozšířit podnikovou síť na platformu Azure přes privátní připojení. Tímto způsobem nepřejdete přes veřejný internet. Získáte také vyšší zabezpečení, spolehlivost a optimalizaci směrování, která znamená nižší latenci sítě a mnohem rychlejší rychlost, než byste normálně měli při procházení veřejného internetu. Pokud plánujete přenos významného bloku dat mezi vaší organizací a Azure, může využití ExpressRoute přinést výhody nákladů. Pro připojení z vaší organizace do Azure si můžete vybrat ze tří různých modelů připojení:

• Společné umístění cloudového Exchange
• Any-to-any
• Point-to-Point

ExpressRoute vám také umožňuje navýšit až 2x limit šířky pásma, který si koupíte, a to bez dalších poplatků. Připojení mezi oblastmi je také možné nakonfigurovat pomocí ExpressRoute. Seznam poskytovatelů připojení ExpressRoute najdete v tématu: Partneři ExpressRoute a umístění partnerských vztahů. Následující články popisují Express Route podrobněji:

• Úvod do ExpressRoute
• Požadavky
• Pracovní postupy

Je SQL Database kompatibilní se všemi zákonnými požadavky a tím, jak to pomáhá s dodržováním předpisů ve vlastní organizaci.

SQL Database je kompatibilní s celou řadou zákonných předpisů. Pokud chcete zobrazit nejnovější sadu komplimentů, které služba SQL Database splnila, navštivte Centrum zabezpečení Microsoftu a přejděte k podrobnostem o kompatibilitě, které jsou pro vaši organizaci důležité, abyste zjistili, jestli je služba SQL Database součástí kompatibilních služeb Azure. Je důležité si uvědomit, že i když je SLUŽBA SQL Database certifikovaná jako vyhovující služba, pomáhá při dodržování předpisů služby vaší organizace, ale nezaručuje ji automaticky.

Inteligentní monitorování a údržba databáze po migraci

Po migraci databáze do služby SQL Database budete chtít databázi monitorovat (například zkontrolovat, jak se využití prostředků podobá nebo jak se kontroluje DBCC) a provádět pravidelnou údržbu (například opětovné sestavení nebo změna uspořádání indexů, statistik atd.). SQL Database je naštěstí inteligentní v tom smyslu, že používá historické trendy a zaznamenané metriky a statistiky k proaktivnímu monitorování a údržbě databáze, aby vaše aplikace běžela optimálně vždy. V některých případech může Azure SQL Database automaticky provádět úlohy údržby v závislosti na vašem nastavení konfigurace. Monitorování databáze ve službě SQL Database má tři omezující vlastnosti:

• Monitorování a optimalizace výkonu
• Optimalizace zabezpečení.
• Optimalizace nákladů.

Monitorování a optimalizace výkonu

Pomocí nástroje Query Performance Insights můžete získat přizpůsobená doporučení pro úlohy databáze, aby vaše aplikace mohly běžet na optimální úrovni – vždy. Můžete ho také nastavit tak, aby se tato doporučení použila automaticky a nemusíte obtěžovat provádění úloh údržby. Pomocí sql Database Advisoru můžete automaticky implementovat doporučení indexu na základě vaší úlohy – tomu se říká automatické ladění. Doporučení se vyvíjejí s tím, jak se vaše úloha aplikace mění, aby vám poskytla nejrelevavantnější návrhy. Získáte také možnost ručně zkontrolovat tato doporučení a použít je podle vlastního uvážení.

Optimalizace zabezpečení

SQL Database poskytuje užitečná doporučení zabezpečení, která vám pomůžou zabezpečit data a detekci hrozeb pro identifikaci a prošetřování podezřelých databázových aktivit, které mohou představovat potenciální vlákno databáze. Posouzení ohrožení zabezpečení je služba pro kontrolu a vytváření sestav databáze, která umožňuje monitorovat stav zabezpečení vašich databází ve velkém měřítku a identifikovat rizika zabezpečení a odchylky od standardních hodnot zabezpečení definovaných vámi. Po každé kontrole je k dispozici přizpůsobený seznam kroků, které je možné provést, a skripty pro nápravu a také sestavu posouzení, která se dá použít k dosažení požadavků na dodržování předpisů.

Pomocí Programu Microsoft Defender for Cloud identifikujete doporučení zabezpečení na panelu a rychle je použijete.

Optimalizace nákladů

Platforma Azure SQL analyzuje historii využití napříč databázemi na serveru, aby vám vyhodnotila a doporučila možnosti optimalizace nákladů. Tato analýza obvykle trvá několik týdnů aktivity k analýze a sestavení doporučení, která se dají použít.

• Na serveru Azure SQL můžete dostávat bannerová oznámení o doporučeních k nákladům.
• Elastické fondy jsou jednou z takových možností. Další informace najdete v tématu Elastické fondy, které vám pomůžou spravovat a škálovat více databází ve službě Azure SQL Database.
• Další informace najdete v tématu Plánování a správa nákladů na službu Azure SQL Database.

Návody monitorování výkonu a využití prostředků ve službě SQL Database

Výkon a využití prostředků ve službě SQL Database můžete monitorovat pomocí následujících metod:

Sledovací proces databáze

Sledovací proces databáze shromažďuje podrobná data monitorování úloh, abyste získali podrobný přehled o výkonu, konfiguraci a stavu databáze. Řídicí panely na webu Azure Portal poskytují přehled o aktivech Azure SQL s jedním podoknem a podrobným zobrazením jednotlivých monitorovaných prostředků. Data se shromažďují do centrálního úložiště dat ve vašem předplatném Azure. Můžete dotazovat, analyzovat, exportovat, vizualizovat shromážděná data a integrovat je s podřízenými systémy.

Další informace o sledovacím nástroji databáze najdete v následujících článcích:

• Monitorování úloh Azure SQL pomocí sledovacího procesu databáze (Preview)
• Rychlý start: Vytvoření sledovacího procesu databáze pro monitorování Azure SQL (Preview)
• Vytvoření a konfigurace sledovacího procesu databáze (Preview)
• Shromažďování dat a datové sady sledovacích procesů databáze (Preview)
• Analýza dat monitorování sledovacího procesu databáze (Preview)
• Nejčastější dotazy ke sledovacím procesům databáze

portál Azure

Na webu Azure Portal se zobrazí využití databáze tak, že vyberete databázi a vyberete graf v podokně Přehled. Graf můžete upravit tak, aby zobrazoval více metrik, včetně procent procesoru, procenta DTU, procento vstupně-výstupních operací dat, procento relací a procento velikosti databáze.

V tomto grafu můžete také nakonfigurovat výstrahy podle prostředku. Tyto výstrahy umožňují reagovat na podmínky prostředků e-mailem, zapisovat do koncového bodu HTTPS/HTTP nebo provádět akci. Další informace najdete v části Vytváření upozornění.

Zobrazení dynamické správy

Dotazem na zobrazení dynamické správy sys.dm_db_resource_stats můžete vrátit historii statistik o spotřebě prostředků za poslední hodinu a zobrazení katalogu systému sys.resource_stats a vrátit historii za posledních 14 dnů.

Query Performance Insight

Přehled výkonu dotazů umožňuje zobrazit historii dotazů s nejvyšším využitím prostředků a dlouhotrvajících dotazů pro konkrétní databázi. Nejčastější dotazy můžete rychle identifikovat podle využití prostředků, doby trvání a četnosti provádění. Můžete sledovat dotazy a zjišťovat regresi. Tato funkce vyžaduje , aby úložiště dotazů bylo pro databázi povolené a aktivní.

Dochází k problémům s výkonem: Jak se metodologie řešení potíží s SQL Database liší od SQL Serveru

Hlavní část technik řešení potíží, které byste použili k diagnostice problémů s výkonem dotazů a databází, zůstávají stejné. Po všech stejných databázových strojech pohání cloud. Platforma – Azure SQL Database má ale integrovanou inteligenci. Může vám pomoct s řešením a diagnostikou problémů s výkonem ještě snadněji. Může také provádět některé z těchto nápravných akcí vaším jménem a v některých případech je proaktivně opravit – automaticky.

Váš přístup k řešení problémů s výkonem může výrazně těžit z používání inteligentních funkcí, jako jsou Query Performance Insight (QPI) a Database Advisor ve spojení, a proto se rozdíl v metodologii liší v tomto ohledu – už nemusíte provádět ruční práci s podrobnými podrobnostmi, které vám můžou pomoct s řešením problému. Platforma pro vás dělá tvrdou práci. Jedním z příkladů je QPI. Pomocí QPI můžete přejít k podrobnostem na úrovni dotazu a podívat se na historické trendy a zjistit, kdy se dotaz přesně zpomalí. Nástroj Database Advisor poskytuje doporučení k věcem, které vám můžou pomoct zlepšit celkový výkon obecně, například chybějící indexy, vyřazení indexů, parametrizaci dotazů atd.

Při řešení potíží s výkonem je důležité zjistit, jestli se jedná o aplikaci nebo databázi, která ji zálohuje, což má vliv na výkon vaší aplikace. Často problém s výkonem spočívá v aplikační vrstvě. Může se jednat o architekturu nebo vzor přístupu k datům. Představte si například, že máte chatovací aplikaci, která je citlivá na latenci sítě. V takovém případě vaše aplikace trpí, protože mezi aplikací a serverem a v síti s ingestováním by bylo mnoho krátkých požadavků ("chatty") mezi aplikací a serverem a v konestované síti, tyto zaoblení se rychle sčítají. K vylepšení výkonu v tomto případě můžete použít dávkové dotazy. Používání dávek vám velmi pomůže, protože vaše požadavky se teď zpracovávají v dávce; tím vám pomůže snížit latenci odezvy a zlepšit výkon vaší aplikace.

Pokud si navíc všimnete snížení celkového výkonu databáze, můžete monitorovat sys.dm_db_resource_stats a sys.resource_stats zobrazení dynamické správy, abyste porozuměli využití procesoru, vstupně-výstupních operací a paměti. Váš výkon může být ovlivněný, protože databáze má hladovění prostředků. Možná budete muset změnit velikost výpočetních prostředků nebo úroveň služby na základě rostoucích a zmenšovacích požadavků úloh.

Komplexní sadu doporučení pro ladění problémů s výkonem najdete v tématu: Ladění databáze.

Návody ujistěte se, že používám odpovídající úroveň služby a velikost výpočetních prostředků.

SQL Database nabízí dva různé nákupní modely: starší model DTU a přizpůsobitelný nákupní model virtuálních jader. Rozdíly najdete v tématu Porovnání nákupních modelů založených na virtuálníchjádrch

Abyste měli jistotu, že máte správnou velikost výpočetních prostředků, můžete monitorovat spotřebu prostředků dotazů a databází v nákupním modelu. Další informace najdete v tématu Monitorování a ladění výkonu. Pokud zjistíte, že dotazy nebo databáze jsou konzistentně spuštěné za provozu, můžete zvážit vertikální navýšení kapacity na vyšší velikost výpočetních prostředků. Podobně pokud si všimněte, že i během špičky, zdá se, že prostředky nepoužíváte tolik; zvažte vertikální snížení kapacity z aktuální velikosti výpočetních prostředků. Můžete zvážit použití služby Azure Automation ke škálování databází SQL podle plánu.

Pokud máte model aplikace SaaS nebo scénář konsolidace databáze, zvažte použití elastického fondu pro optimalizaci nákladů. Elastický fond je skvělý způsob, jak dosáhnout konsolidace databáze a optimalizace nákladů. Další informace o správě více databází pomocí elastického fondu najdete v tématu Správa fondů a databází.

Jak často potřebuji spustit kontroly integrity databáze pro databázi

SQL Database používá některé inteligentní techniky, které jí umožňují zpracovávat určité třídy poškození dat automaticky a bez ztráty dat. Tyto techniky jsou integrované ve službě a služba je využívá v případě potřeby. Zálohy databáze napříč službou se pravidelně testují obnovením a spuštěním DBCC CHECKDB. Pokud dojde k problémům, SQL Database je aktivně řeší. Automatická oprava stránky se využívá k opravě stránek, které jsou poškozené nebo mají problémy s integritou dat. Stránky databáze jsou vždy ověřeny pomocí výchozího nastavení CHECKSUM, které ověřuje integritu stránky. SQL Database aktivně monitoruje a kontroluje integritu dat vaší databáze a v případě problémů je řeší s nejvyšší prioritou. Kromě toho se můžete rozhodnout, že budete volitelně spouštět vlastní kontroly integrity. Další informace najdete v tématu Integrita dat ve službě SQL Database.

Přesun dat po migraci

Návody exportovat a importovat data jako soubory BACPAC ze služby SQL Database pomocí webu Azure Portal

• Export: Databázi můžete exportovat ve službě Azure SQL Database jako soubor BACPAC z webu Azure Portal.

• Import: Data můžete také importovat jako soubor BACPAC do databáze ve službě Azure SQL Database pomocí webu Azure Portal.

Návody synchronizaci dat mezi SQL Database a SQL Serverem

Můžete toho dosáhnout několika způsoby:

• Synchronizace dat – Tato funkce vám pomůže synchronizovat data obousměrně mezi několika databázemi SQL Serveru a službou SQL Database. Pokud chcete synchronizovat s databázemi SQL Serveru, musíte nainstalovat a nakonfigurovat agenta synchronizace na místním počítači nebo virtuálním počítači a otevřít odchozí port TCP 1433.
• Replikace transakcí – Pomocí replikace transakcí můžete synchronizovat data z databáze SQL Serveru do služby Azure SQL Database s instancí SQL Serveru, která je vydavatelem a azure SQL Database je odběratelem. Prozatím se podporuje jenom toto nastavení. Další informace o migraci dat z databáze SQL Serveru do Azure SQL s minimálními výpadky najdete v tématu: Použití transakční replikace

Související obsah

• Monitorování a ladění výkonu ve službě Azure SQL Database a azure SQL Managed Instance