クラウドの新しい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分ごとにログバックアップを行い、災害復旧が効率的になりデータ損失を最小限に抑えるよう努めています。 データベースを作成するとすぐに、最初の完全バックアップが行われます。 これらのバックアップには「 保持期間」と呼ばれる一定期間アクセスできますが、これは選択したサービス層によって異なります。 この保持期間内の任意の時点に復元は 、Point in Time Recovery(PITR)を利用すれば可能です。

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

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

地域の災害時に別のAzureリージョンにバックアップを復元できるように、データベースのバックアップをジオレプリケートストレージに保存してください。 この機能はジオリストアと呼ばれます。 geo リストアの詳細とタイミングについては、Azure SQL Database の geo リストアに関するページを参照してください。

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

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

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

アプリケーションの障害を積極的に監視し、セカンダリへのフェールオーバーを開始します。 このようなアクティブ geo レプリカは、異なる Azure リージョンに最大 4 個まで作成できます。 さらに良くなります。 また、これらの二次的なアクティブジオレプリカに読み取り専用アクセスも可能で、ジオ分散アプリケーションシナリオでの遅延削減に役立ちます。

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

アクティブなジオレプリケーションやフェイルオーバーグループを使う場合、Azure SQL Databaseで数ステップで災害復旧戦略を設定できます。 引き続き、アプリケーションとそのデータベースで地域の障害を監視し、セカンダリ リージョンにフェールオーバーしてビジネス継続性を復元する必要があります。

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

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

Azure SQL Databaseは、データベースレベルとプラットフォームレベルの両方でセキュリティを提供します。 以下の機能を用いて、アプリケーションの最適なセキュリティを制御し提供することができます:

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

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

SQLデータベースはどのようなユーザー認証方法を提供していますか?

SQLデータベースは2つの認証方法を提供しています:

• Microsoft Entra 認証
• SQL 認証

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

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

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

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

アプリケーションの接続性を整理するために、以下の手法を用いてください。

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

ファイアウォール

デフォルトでは、論理SQLサーバーは他のAzureサービスからの接続を除き、すべてのデータベース接続を許可しません。 ファイアウォールルールを使うことで、あなたが承認したエンティティ(例えば開発者マシン)に対してのみ、そのコンピュータのIPアドレスをファイアウォールを通じて許可することで、サーバーへのアクセスを開放できます。 また、サーバーへのアクセスを許可したいIPの範囲を指定することもできます。 例えば、ファイアウォール設定ページで範囲を指定することで、組織内で開発者のマシンIPアドレスを一度に追加できます。

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

サービス エンドポイント

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

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

予約済み IP

他の選択肢としては、VM に予約済み IP をプロビジョニングし、サーバーのファイアウォール設定でこれらの VM IP アドレスを追加します。 予約IPを割り当てることで、IPアドレスを変更するファイアウォールルールを更新する必要はありません。

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

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

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

SQL データベース監査

Azure SQL Database 監査では、 データベース イベントが記録され、Azure Storage アカウントの監査ログ ファイルに書き込まれます。 監査は、潜在的なセキュリティやポリシー違反の洞察を得たい場合、規制遵守の維持などに特に役立ちます。 事前に設定されたレポートとダッシュボードを提供し、データベース上で発生するイベントの概要を把握できます。 監査が必要なイベントのカテゴリを定義・設定できます。

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

脅威の検出

脅威検出を活用することで、監査で発見されたセキュリティやポリシー違反に対して対応できます。 セキュリティの専門家でなくても、システム内の潜在的な脅威や違反に対応できます。 脅威検出には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データベースは、不正なユーザーが機密データを閲覧するのを防ぐために2つのアプローチを提供しています。

• 動的データマスキング は、機密データの露出を非特権ユーザーにマスクすることで制限できるデータマスキング機能です。 マスキングパターンを作るマスキングルールを定義します。 例えば、国民ID番号の下4桁だけを表示でき、残りはXXX-XX-0000文字で隠すX。 動的データマスキングでは、マスキングルールから除外されているユーザーを特定し、マスクされていないデータを確認できます。 マスキングはリアルタイムで行われ、異なるデータカテゴリごとにさまざまなマスキング機能が利用可能です。

• 行レベルのセキュリティ を使用すると、行レベルでアクセスを制御できます。 この機能は、クエリを実行するユーザー(グループメンバーシップまたは実行コンテキスト)に基づいてデータベーステーブル内の特定の行を隠します。 アクセス制限はアプリケーション層ではなくデータベース層で行われているため、アプリのロジックが簡素化されます。 まず、露出していない行をフィルタリングする述語を作成します。 その後、これらの行へのアクセス権を定義するセキュリティポリシーを作成します。 最後に、エンドユーザーはクエリを実行し、ユーザーの権限によっては制限された行を見るか、まったく見えないかのどちらかです。

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

Always Encrypted(クライアント側暗号化)と透過データ暗号化(静止時の暗号化)の両方は 、顧客管理の鍵 オプションを提供します。 暗号化鍵は定期的にローテーションしましょう。 社内の規則やコンプライアンス要件に合ったローテーション頻度を選びましょう。

Transparent Data Encryption(TDE)

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

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

デフォルトでは、Azure SQL DatabaseがTDEマスターキーを管理します。 もし組織がマスターキーの管理を望むなら、鍵ストアとしてAzure Key Vaultを使いましょう。 Azure Key Vault を使用する場合、組織でキーのプロビジョニング、ローテーション、および権限管理を制御することになります。 TDE マスター キーは DEK を再暗号化しただけのものであるため、このキーのローテーションおよび種類の切り替えは短時間で行うことができます。 セキュリティとデータ管理の役割が分離されている組織では、セキュリティ管理者がAzure Key VaultでTDEマスターキーのキー素材をプロビジョニングし、サーバー上の静止暗号化に使えるAzure Key Vaultキー識別子をデータベース管理者に提供できます。 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データベース間のネットワークトラフィックは、一般的にパブリックネットワーク経由でルーティングされます。 しかし、Azure ExpressRouteを使うことでこの経路を最適化し、より安全にすることができます。 ExpressRouteは、プライベート接続を通じて企業ネットワークをAzureプラットフォームへ拡張し、パブリックインターネットを迂回します。 また、セキュリティ、信頼性、ルーティングの最適化が向上し、ネットワークの待機時間が短くなり、通常のパブリック インターネット経由よりも高速になります。 組織とAzure間で大量のデータ転送を計画している場合、ExpressRouteを使うことでコスト面でのメリットがあります。 組織 から Azure への接続は、3 つの異なる接続モデルから選ぶことができます。

• Cloud Exchange コロケーション
• 任意のもの同士
• ポイント ツー ポイント

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

• 前提条件
• ワークフロー

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

Azure SQL Databaseは、さまざまな規制要件に準拠しています。 SQL Databaseが満たす最新のコンプライアンスをご覧になりたい場合は、Microsoft Trust Centerを訪れ、組織にとって重要なコンプライアンスを確認し、SQL Databaseが準拠Azureサービスに含まれるかどうかを確認してください。 SQL Database は準拠しているサービスとして認定されていますが、組織のサービスのコンプライアンスに役立ちますが、自動的には保証されません。

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

データベースをSQLデータベースに移行した後は、データベースを監視し(例えばリソース利用状況や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 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ポータルでは、データベースを選択し、概要ペインでチャートを選択すると、そのデータベースの利用状況が表示されます。 このグラフは、CPU 使用率、DTU の割合、データ IO の割合、セッションの割合、データベース サイズの割合など、複数のメトリックを表示するように変更できます。

このグラフでは、リソース別のアラートを構成することもできます。 これらのアラートは、リソースの状態にメールで応答したり、HTTPS/HTTPエンドポイントに書き込みをしたり、アクションを実行したりすることを可能にします。 詳細については、「Azureポータルを使ったAzure SQL Databaseのアラート作成」をご覧ください。

動的管理ビュー

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

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

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

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

クエリやデータベースのパフォーマンス問題を診断する際に使うほとんどのトラブルシューティング手法は、オンプレミスのSQL Serverと同じです。 Azure SQL Databaseも同じSQL データベース エンジンを使用しています。 しかし、Azureの機能により、パフォーマンスの問題のトラブルシューティングや診断がさらに簡単にできます。 また、これらの是正措置の一部をあなたの代わりに実行し、場合によっては自動的に修正することも可能です。

パフォーマンス問題のトラブルシューティングには 、Query Performance Insight (QPI)や Database Advisorなどのインテリジェントな機能を使うことで大きな恩恵を受けられます。 方法論の違いは、問題のトラブルシューティングに役立つ重要な詳細を手作業で整理する必要がなくなったことです。 難しい作業はプラットフォームがやってくれます。 その一例がQPIです。 QPIを使うことで、クエリレベルまで掘り下げて過去の傾向を見て、クエリがいつ回帰したのかを正確に把握できます。 データベースアドバイザーは、インデックスの欠落、インデックスの削除、クエリのパラメータ付けなど、全体的なパフォーマンス向上に役立つ提案をしてくれます。

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

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

パフォーマンス問題のチューニングに関する包括的な推奨事項については 、「Tune your Database」をご覧ください。

適切なサービス層とコンピュートサイズを使っていることをどうやって確認すればいいですか?

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

どちらの購入モデルでも、クエリとデータベース リソースの消費量を監視できます。 詳細については、監視とパフォーマンス チューニングに関するページをご覧ください。 もしデータベースが常に高い利用率で動作しているなら、より大きな計算サイズへのスケーリングを検討してください。 同様に、ピーク時にリソースをあまり使わない場合は、現在の計算サイズから縮小を検討してください。 Azure Automationを使って、スケジュールに合わせてSQLデータベースをスケールさせることを検討してみてください。

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

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

SQL Database では、特定のクラスのデータ破損を自動的に処理でき、データが失われる必要はありません。 必要に応じて、サービスはこれらの組み込み技術を使用します。 問題があれば、SQLデータベースはそれを積極的に対処します。 追加の保護層として、バックアップ復元のテストや完全性チェックを行うこともあります。 詳細については、Azure SQL Databaseのデータ整合性をご覧ください。

自動ページ修復 は、破損したページやデータの整合性に問題があるページの修正に使用されます。 CHECKSUM設定は常にデータベースページの整合性を検証します。 詳細については、「 SQL Database のデータ整合性」を参照してください。

移行後のデータの移動

Azureポータルを使ってSQLデータベースからBACPACファイルとしてデータをエクスポート・インポートするにはどうすればいいですか?

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

  

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

  

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

データ同期の代替手段の詳細については、「 代替ソリューションへの移行」をご覧ください。

関連するコンテンツ

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