Sdílet prostřednictvím


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

Platí pro:Azure SQL Database

Migrace ze samoobslužného prostředí na PaaS, jako je Azure SQL Database, může být složitá. Tento článek popisuje klíčové funkce služby Azure SQL Database pro izolované databáze a databáze ve fondu, které pomáhají udržovat aplikace dostupné, výkonné, zabezpečené a odolné.

Mezi základní charakteristiky služby Azure SQL Database patří:

  • Monitorování databází pomocí webu Azure Portal
  • 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 tématu Přehled nákupního modelu založeného na DTU a nákupním modelu založeném 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 upozornit, pokud metriky překročí určitou prahovou hodnotu nebo pokud metrika klesne pod určitou prahovou hodnotu.

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 umožňují pokračovat ve vaší firmě, pokud dojde k havárii. 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).

Jak vytvořím a spravujem zálohy ve službě SQL Database?

Azure SQL Database automaticky zálohuje databáze za vás. 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, že zotavení po havárii je efektivní a ztráta dat je minimální. První úplné zálohování proběhne hned po vytvoření databáze. Tyto zálohy jsou vám k dispozici po určitou dobu označovanou jako doba uchovávání, která se liší podle zvolené úrovně služby. K obnovení k libovolnému bodu v čase během této doby uchování můžete použít obnovení k bodu v čase (PITR).

Kromě toho funkce Dlouhodobé uchovávání záloh umožňuje uchovávat záložní soubory 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 uchovávají v geograficky replikovaném úložišti za účelem zajištění odolnosti 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 tématu Provozní kontinuita ve službě Azure SQL Database.

Jak zajistím 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í. Další informace a načasování geografických obnovení najdete v tématu Geografické obnovení služby Azure SQL Database.

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 pomáhají skupiny převzetí služeb při selhání spravovat replikaci 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 Přehled skupin převzetí služeb při selhání a osvědčené postupy (Azure SQL Database).

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 pomáhá snížit latenci 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ů

Zabezpečení v rámci služby SQL Database je k dispozici na úrovni databáze a na úrovni platformy. Optimální zabezpečení aplikace můžete řídit a poskytovat následujícím způsobem:

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 zobrazit, jestli je pro všechny prostředky nakonfigurovaná základní ochrana služby SQL Database, jako je auditování a transparentní šifrování dat , 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í systému Windows se nepodporuje. Microsoft Entra ID je centralizovaná služba pro správu identit a přístupu. Microsoft Entra ID poskytuje pracovníkům ve vaší organizaci přístup pomocí jednotného přihlašování (SSO). To znamená, že přihlašovací údaje se sdílejí napříč službami Azure, aby se usnadnilo 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 a používat vícefaktorové ověřování Microsoft Entra.
Jsou přihlášeni k systému Windows pomocí přihlašovacích údajů Microsoft Entra z federované domény. Použijte 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.
Máte 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

Jak omezím nebo řídím 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žby virtuální sítě
  • Vyhrazené IP adresy

Brána firewall

Ve výchozím nastavení jsou všechna připojení k databázím uvnitř serveru zakázaná, s výjimkou (volitelně) 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 jenom 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 naleznete 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, což 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 dostupná z jakýchkoli IP adres Azure, můžete zakázat 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 umožňují zveřejnit důležité prostředky Azure pouze pro vaši vlastní privátní virtuální síť v Azure. Tato možnost eliminuje 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 koncových bodů služby je směrování paketů řešeno 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.

Na jakém portu se připojím ke službě SQL Database?

SQL Database komunikuje přes port 1433. 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 aktivitu na serveru a databázi ve službě SQL Database?

Auditování služby SQL Database

Auditování služby Azure 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. Další informace najdete v tématu Povolení auditování služby SQL Database.

Detekce hrozeb

Díky detekci hrozeb získáte možnost 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, což je poměrně běžný způsob útoku na databázovou aplikaci. Detekce hrozeb spouští několik sad algoritmů, které detekují potenciální zranitelnosti a útoky prostřednictvím SQL injekce, a anomální vzory přístupu k databázi (například přístup z neobvyklého umístění nebo neznámého subjektu).

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.

Jak obecně chráním svá 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:

  • Neaktivní data v klidovém stavu v souborech dat a protokolů
  • Vaše data v letu

Ve službě SQL Database jsou ve výchozím nastavení uložená data v klidu v datových souborech a souborech protokolů v subsystému úložiště vždy zcela šifrována prostřednictvím transparentní šifrování dat [TDE]. Vaše zálohy jsou také šifrované. U TDE nejsou na straně vaší aplikace, která přistupuje k těmto datům, potřeba žádné změny. Šifrování a dešifrování probíhá transparentně; a název.

Pro ochranu citlivých dat při přenosu a v klidu poskytuje SQL Database funkci Always Encrypted. Always Encrypted 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. Funkce Always Encrypted šifruje citlivé sloupce na konci tabulky od neautorizovaných klientů na fyzický disk.

Funkce Always Encrypted podporuje porovnání rovnosti, takže dbA mohou 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í 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á citlivá data v databázi, která musí být chráněná 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. V takových případech je potřeba citlivá data buď maskovat, nebo je vůbec nezpřístupněte. 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 tak, aby se zobrazily pouze poslední čtyři číslice SSN národního ID: XXX-XX-0000 a většinu z nich maskujte pomocí znaku X ) a určete, kteří uživatelé se mají z pravidla maskování vyloučit. 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í.

Jak můžu spravovat šifrovací klíče v cloudu?

Existují možnosti správy klíčů pro funkci 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 (TDE)

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ď:

Ve výchozím nastavení je hlavní klíč pro transparentní šifrování dat (TDE) spravován službou Azure SQL Database. 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:

Diagram poskytovatelů úložiště CMK s funkcí 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 se obvykle směruje přes veřejnou síť. Tuto cestu ale můžete optimalizovat a zajistit lepší zabezpečení pomocí Azure ExpressRoute. ExpressRoute rozšiřuje vaši 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 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í:

ExpressRoute vám také umožňuje navýšit až 2x limit šířky pásma, který si koupíte, 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 místa propojování. Následující články popisují Express Route podrobněji:

Vyhovuje SQL Database nějakým zákonným požadavkům a 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 kompliancí, které služba SQL Database splnila, navštivte Centrum zabezpečení Microsoftu a zkontrolujte kompatibilitu, která jsou pro vaši organizaci důležitá, abyste zjistili, jestli je služba SQL Database součástí kompatibilních služeb Azure. I když je 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 byste měli databázi monitorovat (například zkontrolovat, jak se využití prostředků podobá, nebo kontroly DBCC) a provádět pravidelnou údržbu (například opětovné sestavení nebo změna uspořádání indexů, statistik atd.). SQL Database 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. 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 se zobrazí přizpůsobený seznam kroků, které lze provést, a skripty pro nápravu a sestavu posouzení, která se dá použít ke splnění 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. 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 a plánovat a spravovat náklady na službu Azure SQL Database.

Jak můžu monitorovat výkon 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:

sledovač 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:

Azure Portal

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.

Snímek obrazovky webu Azure Portal s grafem monitorování databázové DTU

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 tématu Vytváření upozornění pro Azure SQL Database a Azure Synapse Analytics pomocí webu Azure Portal.

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. Dotazy můžete rychle identifikovat TOP 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í.

Snímek obrazovky webu Azure Portal s přehledem výkonu dotazů

Všiml(a) jsem si problé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á: stejný databázový stroj využívá cloud. Azure SQL Database vám může 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ě přinést výhody díky inteligentním funkcím, jako jsou QPI (Query Performance Insight ) 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 tomu, co vám může 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 by probíhalo mnoho krátkých požadavků (tzv. "chatty") a v přetížené síti by se tyto zpětné cesty rychle sčítaly. K vylepšení výkonu v tomto případě můžete použít dávkové dotazy, které pomáhají 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. Pokud je vaše databáze hladověná, může to mít vliv na výkon. 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.

Jak zajistím, ž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. Další informace najdete v tématu Porovnání nákupních modelů založených na virtuálních jádrech a DTU služby Azure SQL Database.

Spotřebu prostředků dotazů a databází můžete monitorovat v obou nákupních modelech. 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 se vám zdá, že prostředky nepoužíváte tolik během špičky, zvažte zmenšení z aktuálního výpočetního výkonu. 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 musím spustit kontroly integrity pro svou databázi?

SQL Database dokáže zpracovávat určité třídy poškození dat automaticky a bez ztráty dat. Tyto integrované techniky služba používá v případě potřeby. Zálohy databáze napříč službou se pravidelně testují jejich obnovením a spuštěním DBCC CHECKDB na nich. Pokud dojde k problémům, SQL Database je aktivně řeší.

Automatická oprava stránky slouží k opravě stránek, které jsou poškozené nebo mají problémy s integritou dat. Stránky databáze jsou vždy ověřeny s výchozím CHECKSUM nastavením, které ověřuje integritu stránky. SQL Database aktivně monitoruje a kontroluje integritu dat vaší databáze a řeší problémy při jejich vzniku. Volitelně můžete podle potřeby spustit vlastní kontroly integrity. Další informace naleznete v tématu Integrita dat ve službě SQL Database.

Přesun dat po migraci

Jak můžu 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:

    Snímek obrazovky webu Azure Portal s tlačítkem Exportovat databázi v databázi Azure SQL

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

    Snímek obrazovky webu Azure Portal s tlačítkem Importovat databázi na serveru Azure SQL

Jak můžu synchronizovat data 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 databází 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í: Díky replikaci 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.