クラウドの新しい DBA – 移行後の Azure SQL Database の管理

適用対象:Azure SQL データベース

セルフマネージド環境から Azure SQL Database などの PaaS への移行は複雑な場合があります。 この記事では、単一データベースとプールされたデータベースに対する Azure SQL Database の主な機能を取り上げ、アプリケーションの利用、パフォーマンス、セキュリティ、回復性を維持するのに役立ちます。

Azure SQL Database の主な特性は次のとおりです。

• Azure portal を使用したデータベースの監視
• ビジネス継続性とディザスター リカバリー (BCDR)
• セキュリティとコンプライアンス
• インテリジェントなデータベースの監視とメンテナンス
• データの移動

Azure ポータルを使用したデータベースの監視

推奨されるアラート ルールを含む、Azure Monitor のメトリックとアラートについては、「メトリックとアラートを使用して Azure SQL データベースを監視する」をご覧ください。 サービス レベルの詳細については、 DTU ベースの購入モデルの概要 と 仮想コアベースの購入モデルに関するページを参照してください。

パフォーマンス メトリックに対してアラートを構成できます。 [メトリック] ウィンドウの [アラートの追加] ボタンを選択します。 ウィザードの指示に従ってアラートを構成します。 メトリックが特定のしきい値を超えた場合、またはメトリックが特定のしきい値を下回った場合にアラートを生成できます。

たとえば、データベースのワークロードが増加する見込みの場合、データベースのいずれかのパフォーマンス メトリックが 80% に達すると電子メールのアラートを送信するように構成できます。 これは、次に大きいコンピューティング サイズにいつ切り替える必要があるかを見つけるための早期警告として使用できます。

下位のコンピューティング サイズにダウングレードできるかどうかを判断するために、パフォーマンス メトリックを利用することもできます。 ただし、下位のコンピューティング サイズへの移行を決定する前に、急上昇や変動するワークロードに注意してください。

ビジネス継続性とディザスター リカバリー (BCDR)

ビジネス継続性とディザスター リカバリー機能を使用すると、障害が発生した場合にビジネスを継続できます。 この場合の障害は、データベース レベルのイベント (たとえば、ユーザーが誤って重要なテーブルを削除した) や、データ センター レベルのイベント (津波などの地域災害) です。

SQL Database でバックアップを作成および管理する方法

Azure SQL Database では、データベースが自動的にバックアップされます。 プラットフォームは、ディザスター リカバリーが効率的であり、データ損失が最小限になるように、毎週完全バックアップ、数時間ごとに差分バックアップ、5 分ごとにログ バックアップを実行します。 データベースを作成するとすぐに、最初の完全バックアップが行われます。 これらのバックアップは、 保有期間と呼ばれる一定期間利用できます。これは、選択したサービス レベルによって異なります。 ポイントインタイム リカバリー (PITR) を使用して、この保持期間内の任意の時点に復元できます。

さらに、 長期保有バックアップ 機能を使用すると、バックアップ ファイルを最大 10 年間保持し、その期間内の任意の時点でこれらのバックアップからデータを復元できます。 データベース バックアップは、地域的な災害に耐えるために、地域間複製ストレージに保持されます。 Azure リージョン内のバックアップを保有期間の任意の時点に復元することもできます。 詳細については、「 Azure SQL Database でのビジネス継続性」を参照してください。

データセンター レベルの災害や地域の大災害が発生した場合にビジネス継続性を確保するにはどうすればよいですか?

データベース バックアップは geo レプリケートされた記憶域に格納されるので、リージョン レベルの災害が発生した間でも、別の Azure リージョンにバックアップを復元することができます。 これは geo リストアと呼ばれます。 geo リストアの詳細とタイミングについては、Azure SQL Database の geo リストアに関するページを参照してください。

ミッションクリティカルなデータベースに対して、Azure SQL データベースはアクティブなアクティブ geo レプリケーションを提供し、地理的に複製された元のデータベースのセカンダリコピーを別の地域に作成します。 たとえば、データベースが当初 Azure 米国西部リージョンでホストされていて、地域的な災害回復力を求める場合、米国西部から米国東部にデータベースのアクティブなジオ・レプリカを作成します。 米国西部で災害が発生した場合は、米国東部リージョンにフェールオーバーできます。

アクティブ geo レプリケーションに加えて、フェールオーバー グループを使用すると、データベースのグループのレプリケーションとフェールオーバーを管理できます。 同じリージョンまたは異なるリージョンに複数のデータベースを含むフェールオーバー グループを作成できます。 その後、フェールオーバー グループ内のすべてのデータベースのセカンダリ リージョンへのフェールオーバーを開始できます。 詳細については、「 フェールオーバー グループの概要とベスト プラクティス (Azure SQL Database)」を参照してください。

データセンターまたは可用性ゾーンの障害に対する回復性を実現するには、データベースまたはエラスティック プールに対してゾーンの冗長性が有効になっていることを確認します。

アプリケーションの障害を積極的に監視し、セカンダリへのフェールオーバーを開始します。 このようなアクティブ geo レプリカは、異なる Azure リージョンに最大 4 個まで作成できます。 回復力がさらに向上します。 これらのセカンダリ アクティブ geo レプリカには読み取り専用でアクセスすることもできます。 これは、地理的に分散されたアプリケーション シナリオの待機時間を短縮するのに役立ちます。

SQL Database でのディザスター リカバリーの概要

アクティブ geo レプリケーションまたはフェールオーバー グループを使用する場合、Azure SQL データベースでの数回のステップだけで、ディザスター リカバリーの構成と管理を行うことができます。 引き続き、アプリケーションとそのデータベースで地域の障害を監視し、セカンダリ リージョンにフェールオーバーしてビジネス継続性を復元する必要があります。

詳細については、「 Azure SQL Database ディザスター リカバリー 101」を参照してください。

セキュリティとコンプライアンス

SQL Database 内のセキュリティは、データベース レベルとプラットフォーム レベルで使用できます。 次のように、アプリケーションの最適なセキュリティを制御して提供できます。

• ID と 認証 (MICROSOFT Entra ID を使用した SQL 認証と認証)。
• アクティビティの監視 (監査および脅威の検出)。
• 実際のデータの保護 (Transparent Data Encryption [TDE] と Always Encrypted)。
• 機密データと特権データへのアクセスの制御 (行レベルのセキュリティ と 動的データ マスク)。

Microsoft Defender for Cloud は、Azure、オンプレミス、他のクラウドで実行されているワークロード全体でのセキュリティ管理を一元化します。 監査や Transparent Data Encryption [TDE] などの重要な SQL Database 保護がすべてのリソースで構成されているかどうかを確認し、独自の要件に基づいてポリシーを作成できます。

SQL Database では、どのようなユーザー認証方法が提供されますか?

SQL Database では 2 種類の認証方法が提供されています。

• Microsoft Entra 認証
• SQL 認証

Windows 認証はサポートされません。 Microsoft Entra ID は、一元化された ID およびアクセス管理サービスです。 Microsoft Entra ID は、組織内の担当者にシングル サインオン (SSO) アクセスを提供します。 これは、認証を容易にするために資格情報が Azure サービス間で共有されることを意味します。

Microsoft Entra ID は 多要素認証をサポートしており、Windows Server Active Directory と簡単に統合できます。 これを使用すると、SQL Database および Azure Synapse Analytics で、Microsoft Entra ドメイン内において Multi-Factor Authentication とゲスト ユーザー アカウントを提供できます。 既に Active Directory をオンプレミスで使用している場合、Microsoft Entra ID とフェデレーションして Azure へ拡張できます。

SQL 認証では、特定のサーバー上の任意のデータベースに対してユーザーを認証するためのユーザー名とパスワードのみがサポートされます。

データベースへの接続アクセスを制限または制御するにはどうすればよいですか?

複数の方法から適切なものを選んで、アプリケーションの最適な接続編成を実現できます。

• ファイアウォール ルール
• 仮想ネットワーク サービス エンドポイント
• 予約済み IP

ファイアウォール

既定では、(必要に応じて) 他の Azure サービスからの接続を除き、サーバー内のデータベースへのすべての接続は許可されません。 ファイアウォール規則を使用すると、そのコンピューターの IP アドレスをファイアウォール経由で許可することで、承認したエンティティ (開発者マシンなど) に対してのみサーバーへのアクセスを開くことができます。 また、サーバーへのアクセスを許可する IP の範囲を指定することもできます。 たとえば、ファイアウォール設定ページで範囲を指定することにより、組織内の開発者コンピューターの IP アドレスを一度に追加できます。

サーバー レベルまたはデータベース レベルで、ファイアウォール ルールを作成できます。 サーバー レベルの IP ファイアウォール規則は、Azure portal または SSMS で作成できます。 サーバー レベルおよびデータベース レベルのファイアウォール規則を設定する方法の詳細については、「 SQL Database での IP ファイアウォール規則の作成」を参照してください。

サービス エンドポイント

既定では、Azure サービスとリソースがこのサーバーへのアクセスを許可するようにデータベースが構成されています。つまり、Azure 内のすべての仮想マシンがデータベースへの接続を試みる可能性があります。 これらの試みも認証を受ける必要があります。 Azure IP からデータベースにアクセスできないようにするには、[ Azure サービスとリソースにこのサーバーへのアクセスを許可する] を無効にします。 さらに、 仮想ネットワーク サービス エンドポイントを構成することもできます。

サービス エンドポイントを使用すると、重要な Azure リソースを Azure 内の独自のプライベート仮想ネットワークにのみ公開できます。 このオプションを使用すると、リソースへのパブリック アクセスが不要になります。 仮想ネットワークと Azure の間のトラフィックは、Azure のバックボーン ネットワーク上に留まります。 サービス エンドポイントがないと、パケット ルーティングが強制トンネリングされます。 仮想ネットワークはインターネット トラフィックを強制的に組織に送り、Azure サービス トラフィックは同じルートを経由します。 サービス エンドポイントを使用すると、パケットが仮想ネットワークから Azure バックボーン ネットワーク上のサービスに直接流れるので、これを最適化できます。

予約済み IP

他の選択肢としては、VM に予約済み IP をプロビジョニングし、サーバーのファイアウォール設定でこれらの VM IP アドレスを追加します。 予約済み IP アドレスを割り当てると、IP アドレスを変更した場合にファイアウォールの規則を更新する手間が省けます。

SQL Database に接続するポートは何ですか?

SQL Database はポート 1433 を介して通信します。 企業ネットワーク内から接続するには、組織のファイアウォール設定に送信ルールを追加する必要があります。 ガイドラインとして、Azure 境界の外部にはポート 1433 を公開しないでください。

SQL Database のサーバーとデータベースのアクティビティを監視および調整するにはどうすればよいですか?

SQL Database 監査

Azure SQL Database 監査では、 データベース イベントが記録され、Azure Storage アカウントの監査ログ ファイルに書き込まれます。 監査は、潜在的なセキュリティとポリシー違反に関する洞察を得て、規制コンプライアンスを維持する場合などに特に役立ちます。これにより、監査が必要であると思われるイベントの特定のカテゴリを定義および構成できます。それに基づいて、構成済みのレポートとダッシュボードを取得して、データベースで発生するイベントの概要を取得できます。

これらの監査ポリシーは、データベース レベルまたはサーバー レベルで適用できます。 詳細については、「 SQL Database 監査を有効にする」を参照してください。

脅威の検出

脅威検出を使用すると、監査によって検出されたセキュリティまたはポリシー違反に対処できます。 セキュリティの専門家でなくても、システム内の潜在的な脅威や違反に対応できます。 脅威検出には、データベース アプリケーションを攻撃する非常に一般的な方法である SQL インジェクション検出などのいくつかの組み込み機能もあります。 脅威検出では、潜在的な脆弱性と SQL インジェクション攻撃を検出する複数のアルゴリズム セットと、異常なデータベース アクセス パターン (通常とは異なる場所からのアクセスや、未知のプリンシパルによるアクセスなど) が実行されます。

データベースで脅威が検出された場合、セキュリティ責任者またはその他の指定された管理者に電子メール通知が送られます。 各通知には、不審なアクティビティの詳細情報と、脅威に対して推奨されるさらなる調査方法や軽減策が記載されています。 脅威検出を有効にする方法については、「脅威検出を 有効にする」を参照してください。

SQL Database でデータを一般的に保護するにはどうすればよいですか?

暗号化は、機微なデータをセキュリティで保護して侵入者から守るための強力なメカニズムを提供します。 復号化キーがなくては、侵入者は暗号化されたデータを使用できません。 したがって、暗号化は SQL Database に組み込まれている既存のセキュリティ レイヤーの上に別の保護レイヤーを追加します。 SQL Database のデータの保護には 2 つの側面があります。

• 保存状態のデータとログ ファイル内のデータ
• 転送中のデータ

SQL Database では、既定では、ストレージ サブシステム上のデータ ファイルとログ ファイル内の保存データは、 透過的なデータ暗号化 [TDE] を使用して完全かつ常に暗号化されます。 バックアップも暗号化されます。 TDE では、アプリケーション側でこのデータにアクセスする変更は必要ありません。 名前のとおり、暗号化と復号化は透過的に行われます。

処理中および保存中の機密データを保護するために、SQL Database には Always Encrypted という機能が用意されています。 Always Encrypted は、データベース内の機密性の高い列を暗号化するクライアント側暗号化の一種です (そのため、データベース管理者と未承認のユーザーに対して暗号化テキストになります)。 サーバーは、最初に暗号化されたデータを受け取ります。

Always Encrypted のキーもクライアント側に格納されるため、機密列の暗号化を解除できるのは承認済みクライアントのみに限られます。 暗号化キーはクライアントに格納されるため、サーバー管理者およびデータ管理者は機微なデータを確認することはできません。 Always Encrypted では、承認されていないクライアントから物理ディスクまで、テーブル内の機密性の高い列がエンド ツー エンドで暗号化されます。

Always Encrypted では等価比較がサポートされているため、DBA は SQL コマンドの一部として引き続き暗号化された列のクエリを実行できます。 Always Encrypted は、Azure Key Vault、Windows 証明書ストア、ローカル ハードウェアのセキュリティ モジュールなどの多様なキー ストア オプションと組み合わせて使用できます。

データベース内の機密データへのアクセスを制限するにはどうすればよいですか?

すべてのアプリケーションには、すべてのユーザーに表示されないように保護する必要がある機密データがデータベースに含まれます。 組織内の特定の担当者はこのデータを見る必要がありますが、他の人達はこのデータを見ることができないようにする必要があります。 このような場合は、機密データをマスクするか、まったく公開しない必要があります。 SQL Database には、機微なデータを未承認ユーザーが表示できないようにする 2 つのアプローチがあります。

• 動的データ マスク は、アプリケーション レイヤー上の特権のないユーザーに対して機密データの公開を制限できるデータ マスク機能です。 マスク パターンを作成できるマスク ルールを定義し (たとえば、国内 ID SSN の最後の 4 桁のみを表示する: XXX-XX-0000 し、その大部分を X 文字でマスク) し、マスク ルールから除外するユーザーを識別します。 マスクの適用は処理中に行われ、さまざまなデータ カテゴリにさまざまなマスク関数を使用できます。 動的データ マスクを使うと、データベースの機微なデータを自動的に検出して、マスクを適用できます。

• 行レベルのセキュリティ を使用すると、行レベルでアクセスを制御できます。 つまり、クエリを実行するユーザー (グループ メンバーシップまたは実行コンテキスト) に基づいて、データベース テーブル内の特定の行が隠ぺいされます。 このアクセス制限は、アプリのロジックを簡素化するため、アプリケーション層ではなくデータベース層で行われます。 最初に公開されない行を排除するフィルター述語を作成し、次にこれらの行にアクセスできるユーザーを定義するセキュリティ ポリシーを作成します。 最後に、エンド ユーザーがクエリを実行すると、ユーザーの特権に応じて、制限された行が表示されるか、またはまったく表示されません。

クラウドで暗号化キーを管理するにはどうすればよいですか?

Always Encrypted (クライアント側暗号化) と Transparent Data Encryption (保存時の暗号化) の両方に対するキー管理オプションがあります。 暗号化キーを定期的にローテーションすることをお勧めします。 ローテーションの頻度は、組織内部の規制とコンプライアンス要件の両方に合わせる必要があります。

透過的なデータ暗号化 (TDE)

TDE は 2 キー階層になっており、各ユーザー データベースのデータは対称的でデータベース固有の AES-256 データベース暗号化キー (DEK) で暗号化され、さらにサーバー固有の非対称の RSA 2048 マスター キーで暗号化されます。 マスター キーは次のどちらかで管理できます。

• Azure SQL Database によって自動的に
• または、キー ストアとして Azure Key Vault を使用する

既定では、TDE のマスター キーは Azure SQL Database によって管理されます。 組織でマスター キーを制御する場合は、キー ストアとして Azure Key Vault を使用できます。 Azure Key Vault を使用する場合、組織でキーのプロビジョニング、ローテーション、および権限管理を制御することになります。 TDE マスター キーは DEK を再暗号化しただけのものであるため、このキーのローテーションおよび種類の切り替えは短時間で行うことができます。 セキュリティとデータ管理で役割が分けられている組織の場合、セキュリティ管理者が TDE マスター キーの主要な素材を Azure Key Vault にプロビジョニングし、サーバーでの保存時暗号化用に使用する Azure Key Vault キー ID をデータベース管理者に提供できます。 Key Vault は、マイクロソフトが暗号化キーを確認または抽出しないように作られています。 また、組織のキーを一元的に管理できます。

常に暗号化されています

Always Encrypted は 2 キー階層になっており、機密データの列は AES 256 列暗号化キー (CEK) で暗号化され、さらに列マスター キー (CMK) で暗号化されます。 Always Encrypted で提供されるクライアント ドライバーには、CMK の長さに関する制限はありません。 CEK の暗号化値はデータベースに格納され、CMK は Windows 証明書ストア、Azure Key Vault、ハードウェア セキュリティ モジュールなどの信頼できるキー ストアに格納されます。

• CEK と CMK はともにローテーションさせることができます。

• CEK のローテーションはデータ操作のサイズであり、暗号化された列を含むテーブルのサイズによっては時間がかかる場合があります。 そのため、CEK のローテーションを適切に計画することをお勧めします。

• ただし、CMK のローテーションはデータベースのパフォーマンスに影響しないため、個別のロールを使用して行うことができます。

次の図は、Always Encrypted の列マスター キーのキー ストア オプションを示しています。

組織と SQL Database の間のトラフィックを最適化してセキュリティで保護するにはどうすればよいですか?

組織と SQL Database の間のネットワーク トラフィックは、通常、パブリック ネットワーク経由でルーティングされます。 ただし、このパスを最適化し、Azure ExpressRoute を使用してセキュリティを強化することができます。 ExpressRoute は、プライベート接続を介して企業ネットワークを Azure プラットフォームに拡張します。 これにより、パブリック インターネットを使う必要がなくなります。 また、セキュリティ、信頼性、ルーティングの最適化が向上し、ネットワークの待機時間が短くなり、通常のパブリック インターネット経由よりも高速になります。 組織と Azure の間で大きなデータ チャンクを転送することを計画している場合、ExpressRoute を使うとコストの点でメリットがあります。 組織 から Azure への接続は、3 つの異なる接続モデルから選ぶことができます。

• Cloud Exchange Colocation
• 任意の環境間
• ポイント ツー ポイント

ExpressRoute では、追加料金なしで購入した帯域幅の上限の 2 倍までバーストすることもできます。 また、ExpressRoute を使用してリージョン間接続を構成することもできます。 ExpressRoute 接続プロバイダーの一覧については、「 ExpressRoute パートナーとピアリングの場所」を参照してください。 次の記事では、ExpressRoute についてさらに詳しく説明されています。

• ExpressRoute の概要
• 前提条件
• ワークフロー

SQL Database は規制要件に準拠しており、自分の組織のコンプライアンスにどのように役立ちますか?

SQL Database は、さまざまな規制に準拠しています。 SQL Database によって満たされた最新の準拠のセットを表示するには、 Microsoft セキュリティ センター にアクセスし、組織にとって重要なコンプライアンスを確認して、準拠している Azure サービスに SQL Database が含まれているかどうかを確認します。 SQL Database は準拠しているサービスとして認定されていますが、組織のサービスのコンプライアンスに役立ちますが、自動的には保証されません。

移行後のインテリジェントなデータベースの監視とメンテナンス

データベースを SQL Database に移行したら、データベースを監視し (リソース使用率の確認や DBCC チェックなど)、定期的なメンテナンス (インデックスの再構築や再構成、統計など) を実行する必要があります。 SQL Database では、履歴の傾向と記録されたメトリックと統計を使用して、データベースの監視と保守に積極的に役立て、アプリケーションが常に最適に実行されるようにします。 構成のセットアップによっては、Azure SQL Database はメンテナンス タスクを自動的に実行できる場合もあります。 SQL Database のデータベースの監視には、3 つの側面があります。

• パフォーマンスの監視と最適化
• セキュリティの最適化
• コストの最適化

パフォーマンスの監視と最適化

Query Performance Insights を使用すると、アプリケーションを最適なレベルで実行し続けることができるように、データベース ワークロードに合わせて調整された推奨事項を取得できます。 推奨事項を自動的に適用し、面倒なメンテナンス タスクを実行しなくてよいように設定することもできます。 SQL Database Advisor を使用すると、ワークロードに基づいてインデックスの推奨事項を自動的に実装できます。 これは自動チューニングと呼ばれます。 推奨事項はアプリケーション ワークロードの変化に応じて進化し、最も重要な推奨事項が提供されます。 また、手動でこれらの推奨事項を確認し、自分で判断して適用することもできます。

セキュリティの最適化

SQL Database では、データの保護に役立つ実践的なセキュリティの推奨事項と、データベースに対する潜在的な脅威になる不審なデータベース アクティビティを識別して調査する脅威検出が提供されます。 脆弱性評価: データベース スキャンおよびレポート サービスであり、大規模なデータベースのセキュリティ状態を監視して、セキュリティ上のリスクおよびユーザーが定義したセキュリティ ベースラインからのずれを特定します。 スキャンのたびに、実行可能な手順と修復スクリプトのカスタマイズされた一覧と、コンプライアンス要件を満たすために使用できる評価レポートが提供されます。

Microsoft Defender for Cloud では、全体的なセキュリティ推奨事項を確認し、それらをすばやく適用できます。

コストの最適化

Azure SQL プラットフォームにより、サーバーのデータベース全体の使用履歴が分析され、お客様に適したコストの最適化オプションが評価および推奨されます。 この分析により実践的な推奨事項を分析して作成するには、通常数週間のアクティビティが必要です。

コストに関する推奨事項のバナー通知を Azure SQL Server で受信する場合があります。 詳細については、 Azure SQL Database で複数のデータベースを管理およびスケーリングするのに役立つエラスティック プールと、Azure SQL Database の コストを計画および管理する方法に関するページを参照してください。

SQL Database のパフォーマンスとリソース使用率を監視するにはどうすればよいですか?

SQL Database のパフォーマンスとリソース使用率は、次の方法で監視できます。

Database Watcher

Database Watcher は、データベースのパフォーマンス、構成、正常性の詳細ビューを提供するために、ワークロード監視データを詳細に収集します。 Azure portal のダッシュボードでは、Azure SQL 資産の単一ウィンドウ ビューと、各監視対象リソースの詳細ビューが提供されます。 データは、Azure サブスクリプションの中央データ ストアに収集されます。 収集されたデータのクエリ、分析、エクスポート、視覚化、およびダウンストリーム システムとの統合を行うことができます。

Database Watcher の詳細については、以下の記事を参照してください。

• Database Watcher を使用して Azure SQL ワークロードを監視する (プレビュー)
• クイック スタート: 監視ツールを作成して Azure SQL を監視する (プレビュー)
• ウォッチャーを作成して構成する (プレビュー)
• Database Watcher のデータ コレクションとデータセット (プレビュー)
• Database Watcher の監視データの分析 (プレビュー)
• Database Watcher に関するよくあるご質問

Azure portal

Azure portal でデータベースを選択し [概要] ペインのグラフを選択すると、データベースの使用率が表示されます。 このグラフは、CPU 使用率、DTU の割合、データ IO の割合、セッションの割合、データベース サイズの割合など、複数のメトリックを表示するように変更できます。

このグラフでは、リソース別のアラートを構成することもできます。 これらのアラートを使用することで、リソースの状態に電子メールで対応したり、HTTPS/HTTP エンドポイントに書き込んだり、アクションを実行することができます。 詳細については、 Azure portal を使用した Azure SQL Database と Azure Synapse Analytics のアラートの作成に関するページを参照してください。

動的管理ビュー

リソース使用率の統計について、sys.dm_db_resource_stats 動的管理ビューでクエリを実行すると過去 1 時間における履歴を確認でき、sys.resource_stats システム カタログ ビューでクエリを実行すると過去 14 日間の履歴を確認できます。

クエリ パフォーマンスの分析情報

クエリ パフォーマンスの分析情報では、指定したデータベースについて、リソース使用率が上位のクエリおよび実行時間が長いクエリの履歴を確認できます。 リソースの使用率、期間、実行頻度によって、 TOP クエリをすばやく識別できます。 クエリを追跡し、回帰を検出できます。 この機能を使用するには、データベースでクエリ ストアを有効化しアクティブにする必要があります。

パフォーマンスの問題に気付く: SQL Database のトラブルシューティング手法と SQL Server の違い

クエリとデータベースのパフォーマンスの問題の診断に使用するトラブルシューティング手法の主な部分は変わりません。同じデータベース エンジンがクラウドに電力を供給します。 Azure SQL Database は、パフォーマンスの問題のトラブルシューティングと診断をさらに簡単に行うのに役立ちます。 また、これらの是正措置の一部をユーザーに代わって実行することもでき、場合によっては自動的に事前に修正することもできます。

パフォーマンスの問題のトラブルシューティングに向けたアプローチでは、 Query Performance Insight (QPI) や Database Advisor などのインテリジェントな機能を組み合わせて使用することで大きなメリットが得られます。そのため、方法論の違いはその点で異なります。手元の問題のトラブルシューティングに役立つ重要な詳細を手動で処理する必要がなくなりました。 難しい作業はプラットフォームがやってくれます。 その 1 つの例は QPI です。 QPI では、クエリ レベルまでドリルダウンし、過去の傾向を見て、クエリが回帰したときを正確に識別できます。 データベース アドバイザーでは、インデックスの不足、インデックスの削除、クエリのパラメーター化など、全体的なパフォーマンスの向上に役立つ可能性のある推奨事項が提供されます。

パフォーマンスのトラブルシューティングでは、アプリケーションだけの問題であるか、それともデータベースの問題がアプリケーションのパフォーマンスに影響しているのかを、識別することが重要です。 多くの場合、パフォーマンスの問題はアプリケーション層にあります。 アーキテクチャまたはデータ アクセス パターンが原因である可能性があります。 たとえば、ネットワーク待ち時間の影響を受けやすい、おしゃべりなアプリケーションがあるとします。 この場合、アプリケーションとサーバー間、および混雑したネットワークでは、多数の短い要求が往復する ("おしゃべり") ため、アプリケーションが影響を受けます。これらの往復はすぐに蓄積され、影響が増大します。 この場合のパフォーマンスを向上させるために、 バッチ クエリを使用すると、ラウンドトリップ待機時間を短縮し、アプリケーションのパフォーマンスを向上させることができます。

さらに、データベースの全体的なパフォーマンスの低下が生じている場合は、sys.dm_db_resource_stats および sys.resource_stats の各動的管理ビューを監視して、CPU、IO、メモリ使用率を把握できます。 データベースにリソースが不足している場合、パフォーマンスが影響を受ける可能性があります。 ワークロードの需要の増加と縮小に基づいて、コンピューティング サイズやサービス レベルの変更が必要になる場合があります。

パフォーマンスの問題のチューニングに関する包括的な推奨事項については、 データベースのチューニングに関するページを参照してください。

適切なサービス レベルとコンピューティング サイズを使用していることを確認するにはどうすればよいですか?

SQL Database には、古い DTU モデルとより適応性の高い仮想コア購入モデルという 2 つの異なる購入モデルが用意されています。 詳細については、「 Azure SQL Database の仮想コアと DTU ベースの購入モデルの比較」を参照してください。

どちらの購入モデルでも、クエリとデータベース リソースの消費量を監視できます。 詳細については、監視とパフォーマンス チューニングに関するページをご覧ください。 クエリまたはデータベースによる負荷が一貫して高い場合は、上位のコンピューティング サイズへのスケールアップを検討します。 同様に、ピーク時にリソースをあまり使用していないように見える場合は、現在のコンピューティング サイズからスケールダウンすることを検討してください。 Azure Automation を使用して、スケジュールに従って SQL Database をスケーリングすることを検討できます。

SaaS アプリ パターンまたはデータベース統合シナリオがある場合は、エラスティック プールを使ってコストを最適化することを検討します。 エラスティック プールは、データベースの統合とコストの最適化を実現する優れた方法です。 エラスティック プールを使用した複数のデータベースの管理の詳細については、「 プールとデータベースの管理」を参照してください。

データベースの整合性チェックを実行する必要がある頻度はどのくらいですか?

SQL Database では、特定のクラスのデータ破損を自動的に処理でき、データが失われる必要はありません。 これらの組み込み手法は、必要に応じてサービスによって使用されます。 サービス全体のデータベース バックアップは、それらを復元し、それらに対して DBCC CHECKDB 実行することによって定期的にテストされます。 問題がある場合、SQL Database は事前にそれらに対処します。

ページの自動修復 は、破損しているページやデータ整合性の問題があるページを修正するために使用されます。 データベース ページは常に、ページの整合性を検証する既定の CHECKSUM 設定で検証されます。 SQL Database は、データベースのデータ整合性を事前に監視して確認し、問題が発生した場合に対処します。 必要に応じて、独自の整合性チェックを実行することもできます。 詳細については、「 SQL Database のデータ整合性」を参照してください。

移行後のデータの移動

Azure portal を使用して SQL Database から BACPAC ファイルとしてデータをエクスポートおよびインポートする方法

• エクスポート: Azure portal から BACPAC ファイルとして Azure SQL Database 内のデータベースをエクスポートできます。

  

• インポート: Azure portal を使用して、データを BACPAC ファイルとして Azure SQL Database のデータベースにインポートすることもできます。

  

SQL Database と SQL Server の間でデータを同期する方法

これを行うには、いくつかの方法があります。

• データ同期: この機能は、複数の SQL Server データベースと SQL Database の間で双方向にデータを同期するのに役立ちます。 SQL Server データベースと同期するには、ローカル コンピューターまたは仮想マシンに同期エージェントをインストールして構成し、発信 TCP ポート 1433 を開く必要があります。

• トランザクション レプリケーション: トランザクション レプリケーションを使用すると、SQL Server データベースから Azure SQL Database にデータを同期し、SQL Server インスタンスをパブリッシャーに、Azure SQL Database をサブスクライバーにすることができます。 現時点では、このセットアップのみがサポートされています。 最小限のダウンタイムで SQL Server データベースから Azure SQL にデータを移行する方法の詳細については、「トランザクション レプリケーションの使用」を参照してください。

関連するコンテンツ

• Azure SQL データベースと Azure SQL Managed Instance での監視とパフォーマンス チューニング