Microsoft Azure Database Administrator Associate
最終確認：2026年5月
DP-300 試験で問われるアーキテクチャパターンのスキャン可能なリファレンス。上から順に読むか、セクションへジャンプ。
ミッションクリティカルなSQLデータベースは、99.995%のSLA、ゾーン冗長HA、および読み取りスケールアウト機能を必要とします。
Azure SQL Databaseを、ゾーン冗長を有効にしたBusiness Criticalサービス層を使用してデプロイします。
理由: Business Criticalは最高のSLAを提供し、低レイテンシのためにローカルSSDを使用し、追加費用なしで組み込みの読み取り可能なセカンダリレプリカを含みます。General PurposeはSLAが低く、組み込みの読み取りレプリカがありません。
データベースには、予測不能な断続的な使用パターンと長いアイドル期間があります。コスト最適化が重要です。
Azure SQL Databaseを、Serverlessコンピューティングモデルを備えたGeneral Purpose層を使用してデプロイします。
理由: Serverlessは需要に基づいてコンピューティングを自動的にスケールし、非アクティブ時には自動一時停止できるため、ストレージに対してのみ課金されます。これは、連続的ではないワークロードにとってProvisionedコンピューティングよりも費用対効果が高いです。
SQL Server Agent、クロスデータベースクエリ、Service Brokerなどの機能に大きく依存するオンプレミスSQL Serverを移行します。
Azure SQL Managed Instanceに移行します。
理由: Managed InstanceはオンプレミスのSQL Serverとほぼ100%の互換性を提供し、Azure SQL Databaseでは利用できないインスタンスレベルの機能を保持します。
アプリケーションがOSレベルアクセス、ファイルシステムアクセス（例：Filestream用）、またはPaaSサービスではサポートされていない機能（EXTERNAL_ACCESS付きのCLRなど）を必要とします。
SQL ServerをAzure Virtual Machine (IaaS) にデプロイします。
理由: IaaSはオペレーティングシステムとSQL Serverインスタンスに対する完全な制御を提供し、管理オーバーヘッドの増加を伴うものの、オンプレミス構成との最大の互換性を提供します。
データベースが4 TBを超え、最大100 TBまで成長すると予想され、迅速なストレージスケーリングと高速な復元を必要とします。
Azure SQL DatabaseをHyperscaleサービス層を使用してデプロイします。
理由: HyperscaleはVery Large Databases (VLDB) 向けに設計されており、最大100 TBのストレージを自動的にスケールします。ページサーバーを使用した独自のアーキテクチャにより、サイズに関係なく高速で一定時間でのデータベース復元を実現します。
SaaSアプリケーションが多くの小さなデータベースをホストしており、使用パターンが様々で予測不能です。共有リソースを提供しながらコストを最適化する必要があります。
データベースをAzure SQL Databaseエラスティックプールにグループ化します。
理由: エラスティックプールを使用すると、複数のデータベースが設定された価格でリソース（eDTUまたはvCore）のセットを共有できます。これは、すべてのテナントで使用状況が一定でない場合に、個々のデータベースをプロビジョニングするよりも費用対効果が高くなります。
Azure SQL Managed Instanceを仮想ネットワークにデプロイします。
最小サイズ/27（32アドレス）の専用サブネットを作成し、それをMicrosoft.Sql/managedInstancesに委任します。
理由: Managed Instanceは、その内部コンポーネントと将来のスケーリングのために十分なIPアドレスを持つ専用の空のサブネットを必要とします。/27がサポートされる最小サイズです。
大規模なミッションクリティカルなオンプレミスSQL Serverデータベースを最小限のダウンタイムでAzureに移行します。
Azure Database Migration Service (DMS) をオンライン移行モードで使用します。
理由: DMSのオンライン移行は、初期ロードを実行し、その後連続データ同期（ログシッピング）を使用してターゲットを同期状態に保つため、非常に短いカットオーバー期間で移行が可能です。
大規模なシーケンシャル読み取りを伴うデータウェアハウスワークロードをホストするAzure VM上のSQL Serverのストレージを構成します。
Premium SSDを使用します。データファイルには読み取り専用ホストキャッシュを、ログファイルにはキャッシュなしを設定します。
理由: 読み取り専用キャッシュは、データウェアハウスで一般的な大規模なシーケンシャル読み取りに最適です。ログファイルは書き込みの永続性を確保し、データ損失を防ぐためにキャッシュを無効にする必要があります。
セキュリティポリシーにより、すべてのデータベース接続が暗号化され、サーバー証明書を検証する必要があります。
サーバーで最小TLSバージョンを1.2に設定します。クライアント接続文字列では、`Encrypt=Strict`を使用します。
理由: サーバーで最小TLSを設定することで、安全でないプロトコルネゴシエーションを防ぎます。`Encrypt=Strict` (TDS 8.0+) は暗号化と完全な証明書検証を強制し、中間者攻撃を防ぎます。
特定の列（例：SSN）の機密データは暗号化する必要がありますが、アプリケーションは暗号化されたデータに対して等価検索と結合を実行する必要があります。
検索可能な列には、決定論的暗号化を使用したAlways Encryptedを使用します。
理由: 決定論的暗号化は、特定のプレーンテキスト値に対して同じ暗号文を生成するため、等価比較が可能です。ランダム化された暗号化はより強力な保護を提供しますが、これらの操作はできません。
保存データの暗号化が必要ですが、組織は暗号化キーを完全に管理する必要があります。
Azure Key Vaultに保存された顧客管理キー (BYOK) を使用してTransparent Data Encryption (TDE) を有効にします。
理由: この構成により、組織は自身のKey Vaultでキーのライフサイクル（ローテーション、失効）を管理でき、キーの所有権に関する制御とコンプライアンス要件を満たすことができます。
Azure SQL Databaseは特定のAzure Virtual Networkからのみアクセス可能である必要があり、パブリックインターネットアクセスは完全にブロックされます。
SQL Server用のPrivate Endpointを構成し、「パブリックネットワークアクセスを拒否」を「はい」に設定します。
理由: Private Endpointは、SQLデータベースにVNet内のプライベートIPアドレスを与えます。パブリックアクセスを無効にすることで、それが唯一の接続方法となり、完全なネットワーク分離が提供されます。
マルチテナントアプリケーションは、ユーザーが共有テーブル内で自分のデータのみを参照できるようにする必要があります。
セキュリティ述語（インラインテーブル値関数）と、それをテーブルに適用するセキュリティポリシーを作成して、行レベルセキュリティ (RLS) を実装します。
理由: RLSは、ユーザーコンテキスト（例：USER_NAME()やSESSION_CONTEXT）に基づいて行を透過的にフィルタリングし、アプリケーションの変更なしにデータベースエンジンレベルでデータ分離を強制します。
データベース管理者はデータベースを管理する必要がありますが、特定の列の機密データを表示できないようにする必要があります。
機密列にDynamic Data Masking (DDM) を実装します。DBAにUNMASK権限を付与しないでください。
理由: DDMは、特権のないユーザーのクエリ結果でデータを難読化し、保存されているデータを変更しません。これにより、DBAは実際の機密情報を参照せずに職務を遂行できます。
セキュリティポリシーにより、Azure SQL DBまたはManaged Instanceの一元的なID管理とMFAを強制するためにSQL認証を無効にすることが義務付けられています。
サーバーのAzure AD管理者を設定し、「Azure AD専用認証」プロパティを有効にします。
理由: この設定により、SQL認証エンドポイントが完全に無効になり、すべての接続がAzure ADを使用するように強制されます。これは、最新の認証ポリシーを適用するための重要なステップです。
潜在的なSQLインジェクション、異常なアクセスパターン、ブルートフォース攻撃など、異常なデータベースアクティビティを検出してアラートを受信する必要があります。
Microsoft Defender for SQL（以前のAdvanced Threat Protection）を有効にします。
理由: Defender for SQLは、疑わしいアクティビティについてデータベースログを分析し、セキュリティアラートを生成することで、基本的なアクセス制御を超えた重要な脅威検出レイヤーを提供します。
Azure SQL Databaseの監査ログは数年間保持され、コンプライアンスおよびセキュリティ調査のために検索可能である必要があります。
必要なデータ保持期間が構成されたLog Analyticsワークスペースにログを送信するようにAzure SQL Auditingを構成します。
理由: Log Analyticsは、長期保持と強力なKQLベースのクエリ機能を提供し、検索可能な長期監査データのためにBlob Storageよりも優れています。
トラブルシューティングのために、DevOpsチームにデータベースへの一時的、時間制限付き、承認ゲート付きのアクセスを提供します。
Azure AD Privileged Identity Management (PIM) を使用して、データベースアクセスを持つAzure ADグループの資格を管理します。
理由: PIMは、監査可能で、正当性を要求し、自動的に期限切れになるジャストインタイム (JIT) アクセスを提供し、最小限の特権の原則に準拠します。
システムは、厳格な規制コンプライアンスを満たすために、すべてのデータ変更の検証可能で改ざん防止された履歴を必要とします。
Azure SQL Databaseの台帳機能を使用します。
理由: 台帳テーブルはブロックチェーンの概念を使用してデータの変更を暗号化的にリンクし、独立して検証可能な不変の履歴を作成します。これは、改ざん防止されていないテンポラルテーブルよりも強力です。
データベースでパフォーマンスの低下が発生しています。リソースを最も消費しているクエリを特定し、プランの変更を追跡し、パフォーマンスの回帰を見つける必要があります。
Query Storeを有効にして利用します。
理由: Query Storeはクエリパフォーマンスのための組み込みの「フライトデータレコーダー」です。クエリ履歴、プラン、待機統計を自動的にキャプチャし、時間経過に伴うパフォーマンスの問題を診断するための主要なツールです。
クエリは、非代表的なパラメーター値のために実行プランが最適化されるパラメーター嗅ぎ取りの問題により、時には良好に動作し、時には低速に動作します。
Query Storeを使用して異なるプランを特定し、一貫して良好な実行プランを強制します。
理由: Query Storeのプラン強制は、コード変更なしで問題のあるクエリのパフォーマンスを安定させるための迅速かつ効果的な方法を提供します。オプティマイザーの選択を既知の良好なプランで上書きします。
rowstoreでのバッチモード、メモリ許可フィードバック、テーブル変数遅延コンパイルなどの機能を活用して、コード変更なしでクエリパフォーマンスを向上させます。
データベース互換性レベルを150 (SQL 2019の機能の場合) 以上に設定します。
理由: Intelligent Query Processing (IQP) 機能セットは、データベース互換性レベルによって有効になります。レベル150以上は、クエリプロセッサーにおける幅広い「コード変更なし」のパフォーマンス強化をアクティブにします。
運用チームは、CPU使用率やデッドロックなどの主要なパフォーマンスメトリックが定義されたしきい値を超えたときに通知を受ける必要があります。
Azure Monitorを使用して、Action Groupをトリガーするメトリックアラート（CPU用）とログアラート（デッドロック用）を作成します。
理由: Azure Monitorは、Azureリソースの監視とアラートのための集中プラットフォームです。Action Groupは、柔軟な通知チャネル（メール、SMS、Webhookなど）を提供します。
読み取りクエリで使用されていないインデックスを特定して削除することで、書き込みパフォーマンスを向上させます。
`sys.dm_db_index_usage_stats` DMVをクエリします。
理由: このDMVは、インデックスの使用状況（シーク、スキャン、ルックアップ）と更新状況を追跡します。更新が多くても使用がゼロまたは非常に少ないインデックスは、削除の有力候補であり、メンテナンスのオーバーヘッドを削減します。
間欠的なブロックの問題について、ブロックチェーンに関与するステートメントやセッションを含む詳細な情報をキャプチャする必要があります。
`blocked_process_report`イベントをキャプチャするExtended Eventsセッションを構成します。
理由: このイベントは、`blocked process threshold`を超えたときにブロックチェーンの詳細なXMLレポートを提供し、DMVでは利用できない深い診断情報を提供します。
データベースは、手動介入なしに、変化するワークロードパターンに自動的に適応するインデックス戦略を必要とします。
Azure SQL Database自動チューニングでCREATE_INDEXオプションを有効にします。
理由: この機能により、Azureはワークロードを分析し、影響の大きい不足しているインデックスを特定し、それらを作成し、そのパフォーマンス上の利点を検証することで、主要なDBAタスクを自動化します。
Business CriticalまたはPremium層のプライマリOLTPデータベースから、読み取り負荷の高いレポートワークロードをオフロードします。
アプリケーションの読み取り専用接続文字列に`ApplicationIntent=ReadOnly`を含めるように変更します。
理由: これらの層には、無料の組み込み読み取り可能なセカンダリレプリカが含まれています。接続文字列の`ApplicationIntent`プロパティは、読み取り専用接続をこのレプリカに自動的にルーティングし、読み取りワークロードを分離します。
データウェアハウス内の大規模なファクトテーブルが、集計クエリ (SUM, COUNT, AVG) で頻繁に使用され、パフォーマンスが低下しています。
ファクトテーブルにクラスター化されたColumnstoreインデックスを作成します。
理由: Columnstoreインデックスはデータを列形式で保存し、非常に高いデータ圧縮を提供し、バッチモード実行を可能にします。これにより、集計とスキャン負荷の高い分析クエリが劇的に高速化されます。
データベースで、読み取りクエリ（レポート）と書き込みクエリ（トランザクション）の間で著しいブロッキング競合が発生しています。
データベースでRead Committed Snapshot Isolation (RCSI) を有効にします。
理由: RCSIは行バージョン管理を使用し、読み取り側が共有ロックを取らずにデータの最後にコミットされたバージョンを参照できるようにするため、書き込み側からのブロックを排除します。書き込み側は読み取り側をブロックしません。
Serverlessデータベースを使用するアプリケーションで、非アクティブ期間の後、初期接続時間が遅くなることがあります。
自動一時停止の遅延を減らすか、最小vCore値をゼロより大きい値に構成します。
理由: この遅延は、データベースが一時停止状態から再開する（コールドスタート）ことによって引き起こされます。最小vCore値を設定すると、データベースが完全に一時停止するのを防ぎ、再開のレイテンシを排除できますが、一部の継続的なコンピューティング料金が発生します。
自動化され、バージョン管理され、再現可能なデータベーススキーマデプロイのためのCI/CDパイプラインを実装します。
SQL Database Project (例: Visual Studio) を使用してDACPACファイルを生成します。Azure DevOpsパイプラインを使用してDACPACをデプロイします。
理由: これはSQLスキーマの標準的なInfrastructure as Code (IaC) パターンです。DACPACはスキーマの宣言的モデルであり、デプロイツールは差分スクリプトの生成を処理し、一貫性を確保します。
Azure SQL Databaseは、スケジュールまたはメトリックしきい値（例：高CPU）に基づいて自動的にスケールアップまたはスケールダウンする必要があります。
スケジュールまたはAzure MonitorアラートによってトリガーされるAzure Automation Runbook (PowerShell) を使用します。
理由: Azure SQL Database (Provisioned層) には組み込みの自動スケーリング機能がありません。Azure Automationは、スクリプトとスケジュールを使用してこの種の運用タスクをオーケストレーションするための標準ツールです。
メンテナンススクリプト（例：インデックス再構築）を何百ものAzure SQLデータベースに対して実行する必要があります。
Elastic Jobsを使用します。
理由: Elastic Jobsは、データベースのターゲットグループ全体でT-SQLジョブを実行し、資格情報、スケジューリング、およびログ記録を一元的に管理するために特別に設計されたPaaSサービスです。
サブスクリプション内の新しく作成されたすべてのAzure SQL Serverが、TDEやAuditingなどの特定の機能をデフォルトで有効にしていることを確認します。
`DeployIfNotExists`または`Modify`効果を持つAzure Policyを作成します。
理由: Azure Policyは大規模なガバナンスを提供します。`DeployIfNotExists`効果は、リソース作成時に不足している設定を自動的に構成し、手動介入なしにコンプライアンスを強制します。
Azure SQL Managed Instanceで定期的なT-SQLスクリプトまたはメンテナンスを実行します。
組み込みのSQL Server Agentを使用します。
理由: Managed Instanceには完全なSQL Server Agentが含まれており、外部の自動化サービスを必要とせずに、オンプレミスのSQL Serverと同じおなじみのジョブスケジューリング機能を提供します。
ビジネス運用への影響を最小限に抑えるために、AzureがAzure SQL DatabaseまたはManaged Instanceで計画的なメンテナンスを実行する時期を制御します。
リソースのメンテナンスウィンドウを構成します。
理由: この機能により、Azureが更新プログラムを適用する事前定義された時間枠（例：週末）を選択でき、サービスに影響を与えるメンテナンスの予測可能性が向上します。
アプリケーションは、接続文字列の変更なしに、災害復旧のためにセカンダリリージョンへの自動フェールオーバーを必要とします。
プライマリデータベース/インスタンスとセカンダリデータベース/インスタンス間に自動フェールオーバーグループを構成します。
理由: フェールオーバーグループは、読み書きおよび読み取り専用リスナーエンドポイントを提供します。これらのエンドポイントは、フェールオーバー後にトラフィックを現在のプライマリ/セカンダリサーバーに自動的にリダイレクトするため、プロセスがアプリケーションに対して透過的になります。
法的または規制上のコンプライアンス要件を満たすために、データベースのバックアップは長期間（例：7～10年）保持する必要があります。
長期バックアップ保持 (LTR) ポリシーを構成します。
理由: 標準のPoint-in-Time Restore (PITR) バックアップは最大35日間保持されます。LTRは、コンプライアンス要件のために、完全バックアップを個別のAzure Blob Storageに最大10年間保存します。
データベースは、単一のAzureリージョン内のデータセンター（可用性ゾーン）障害中も利用可能である必要があります。
Business CriticalまたはPremium層データベースのゾーン冗長構成を有効にします。
理由: ゾーン冗長は、同じリージョン内の異なる物理データセンターに同期セカンダリレプリカをデプロイし、ゾーンレベルの障害に対してRPOがほぼゼロの自動フェールオーバーを提供します。
Azure SQL Managed Instanceは、ペアになったAzureリージョンに自動フェールオーバー機能を備えた災害復旧ソリューションを必要とします。
Managed Instanceの自動フェールオーバーグループを構成します。
理由: これはManaged Instanceの標準的なDRパターンであり、非同期レプリケーション、透過的なアプリケーションフェールオーバーのためのリスナーエンドポイント、および自動フェールオーバーオプションを提供します。
過去1ヶ月間の任意の特定の秒にデータベースを復元できる必要があります。
短期バックアップ保持（PITR）期間を30〜35日に構成します。
理由: Azure SQLは、完全バックアップ、差分バックアップ、および頻繁なトランザクションログバックアップを自動的に取得します。PITR保持設定（1〜35日）は、これらのバックアップが保持される期間を決定し、ポイントインタイム復元のウィンドウを定義します。
Azure VM上でSQL Server Always On可用性グループのためのWindows Server Failover Clusterを構成します。
クォーラム監視としてCloud Witnessを使用します。
理由: Cloud WitnessはAzure Blob Storageを使用し、Azure内のクラスターにとって推奨される最も回復力のあるオプションです。これにより、ファイル共有監視のための3番目のVMや複雑な共有ディスク構成が不要になります。
共有ストレージを必要とするAzure VM上でSQL Server Failover Cluster Instance (FCI) を実装します。
Azure Shared Disks（複数のVMにマネージドディスクをアタッチする）を使用します。
理由: Azure Shared Disksは、複数のVMからアクセスできるブロックストレージを提供するAzureネイティブソリューションであり、従来のFCIの前提条件です。
フェールオーバーグループの災害復旧プロセスを、本番プライマリデータベースに影響を与えずにテストする必要があります。
影響の少ないメンテナンスウィンドウ中に計画的な（手動）フェールオーバーを開始し、アプリケーション接続を検証してからフェールバックします。
理由: 計画的なフェールオーバーはデータ損失がないことを保証し、DNS伝播やアプリケーションの再接続を含むDRプロセス全体を検証する最も徹底的な方法です。これは、短時間で制御された本番イベントです。
