セクション: [なし]
Explanation:
シナリオ: Active Directory 資格情報を使用してデータベース ユーザーを認証します。
構成手順には、Azure Active Directory を構成して使用するための次の手順が含まれます。
認証。
1. Azure AD を作成して設定します。
2. オプション: 現在 Azure サブスクリプションに関連付けられている Active Directory を関連付けるか変更します。
3. Azure Active Directory 管理者を作成します。（ステップ1）
4. クライアント コンピュータを設定します。
5. Azure AD ID にマップされた包含データベース ユーザーをデータベース内に作成します。（ステップ2）
6. Azure AD ID を使用してデータベースに接続します。(ステップ3)
参照：
https://docs.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-overview

参照：
https://techcommunity.microsoft.com/t5/azure-sql-database/native-database-backup-in-azure-sql-managed-instance/ba-p/386154

セクション: [なし]
Explanation:
代わりに、Business Critical サービス層と可用性ゾーンを使用する Azure SQL データベースをデプロイします。
注: プレミアム サービス レベルとビジネス クリティカル サービス レベルは、プレミアム可用性モデルを活用しており、
単一ノード上のコンピューティング リソース (sqlservr.exe プロセス) とストレージ (ローカルに接続された SSD)。高い
可用性は、コンピューティングとストレージの両方を追加のノードに複製して 3 ～ 4 つのノードを作成することで実現されます。
ノードクラスター。
デフォルトでは、プレミアム可用性モデルのノードのクラスターは同じデータセンターに作成されます。とともに
Azure Availability Zones の導入により、SQL Database はビジネス クリティカル ゾーンのさまざまなレプリカを配置できるようになります。
データベースを同じリージョン内の異なるアベイラビリティ ゾーンに接続します。単一障害点を排除するには、コントロール リングを使用します。
また、3 つのゲートウェイ リング (GW) として複数のゾーンにわたって複製されます。
参照：
https://docs.microsoft.com/en-us/azure/azure-sql/database/high-availability-sla

Explanation:
ボックス 1: sys.resource_stats
sys.resource_stats は、Azure SQL Database の CPU 使用率とストレージ データを返します。これには、database_name 列と start_time 列があります。
ボックス 2: 日付の追加
次の例では、過去 1 週間のコンピューティング使用率の平均が少なくとも 80% であるすべてのデータベースを返します。
@s の日時を宣言します。
DECLARE @e 日時;
SET @s= DateAdd(d,-7,GetUTCDate());
SET @e= GETUTCDATE();
SELECT データベース名, AVG(avg_cpu_percent) AS Average_Compute_Utilization FROM sys.resource_stats WHERE start_time BETWEEN @s AND @e GROUP BY データベース名 HAVING AVG(avg_cpu_percent) >= 80 不正解:
sys.dm_exec_requests:
sys.dm_exec_requests は、SQL Server で実行されている各要求に関する情報を返します。これには、database_name という名前の列がありません。
sys.dm_db_resource_stats:
sys.dm_db_resource_stats には start_time 列がありません。
注: sys.dm_db_resource_stats は、Azure SQL Database データベースの CPU、I/O、およびメモリ消費量を返します。データベースにアクティビティがない場合でも、15 秒ごとに 1 行が存在します。履歴データは約 1 時間保持されます。
Sys.dm_user_db_resource_governance は、現在のデータベースまたはエラスティック プールのリソース ガバナンス メカニズムによって使用される実際の構成と容量の設定を返します。start_time 列はありません。
参照：
https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-resource-stats-azure-sql-database クエリ パフォーマンスの最適化テストレット 1 これはケース スタディです。ケーススタディは個別に時間が設定されるわけではありません。各ケースを完了したいだけ試験時間を費やすことができます。ただし、この試験には追加のケーススタディやセクションが存在する場合があります。この試験に含まれるすべての質問を指定された時間内に完了できるように時間を管理する必要があります。
ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示やその他のリソースが含まれる場合があります。このケーススタディでは、各質問は他の質問から独立しています。
このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを開始するには
このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。質問に答える前に、左側のペインのボタンを使用してケーススタディの内容を調べてください。これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。ケーススタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。
既存の環境
ネットワーク環境
製造データセンターと研究データセンターは、VPN を使用してプライマリ データセンターに接続します。
プライマリ データセンターには、Microsoft ピアリングとプライベート ピアリングの両方を使用する ExpressRoute 接続があります。
プライベート ピアリングは、HubVNet という名前の Azure 仮想ネットワークに接続します。
アイデンティティ環境
Litware には、litwareinc.com という名前のドメインを使用するハイブリッド Azure Active Directory (Azure AD) デプロイがあります。
すべての Azure サブスクリプションは、litwareinc.com Azure AD テナントに関連付けられています。
データベース環境
営業部門には次のデータベース ワークロードがあります。
* SERVER1 という名前のオンプレミスは、Microsoft SQL Server 2012 のインスタンスと 2 つの 1 TB データベースをホストします。
* SalesSrv01A という名前の論理サーバーには、SalesSQLDb1 という名前の geo レプリケーションされた Azure SQL データベースが含まれています。
SalesSQLDb1 は、SalesSQLDb1Pool という名前のエラスティック プール内にあります。SalesSQLDb1 は、データベース ファイアウォール ルールと包含データベース ユーザーを使用します。
* SalesSQLDb1App1 という名前のアプリケーションは SalesSQLDb1 を使用します。
製造オフィスには、SERVER2 および SERVER3 という名前の 2 台のオンプレミス SQL Server 2016 サーバーが含まれています。サーバーは、同じ Always On 可用性グループ内のノードです。可用性グループには、ManufacturingSQLDb1 という名前のデータベースが含まれています。 データベース管理者は、Windows Server 2019 を実行し、すべての Azure データベースを管理するために使用される VM1 および VM2 という名前の HubVnet 内に 2 つの Azure 仮想マシンを持っています。
ライセンス契約
Litware は、ソフトウェア アシュアランスによるライセンス モビリティを備えた Microsoft ボリューム ライセンスの顧客です。
現在の問題
SalesSQLDb1 では、古い統計と頻繁なブロック クエリが原因である可能性が高いパフォーマンスの問題が発生します。
要件
計画された変更
Litware は次の変更を実装する予定です。
* Azure に 30 の新しいデータベースを実装します。これらは、さまざまな使用パターンを持つ時間に敏感な製造アプリによって使用されます。各データベースのサイズは約 20 GB になります。
* ResearchSrv01 という名前の論理サーバー上に ResearchDB1 という名前の新しい Azure SQL データベースを作成します。
ResearchDB1 には個人識別情報 (PII) データが含まれます。
* 研究部門が ResearchDB1 にデータを入力してアクセスするために使用する ResearchApp1 という名前のアプリを開発します。
* ManufacturingSQLDb1 を Azure 仮想マシン プラットフォームに移行します。
* SERVER1 データベースを Azure SQL データベース プラットフォームに移行します。
技術的要件
Litware は次の技術要件を特定します。
※メンテナンス作業は自動化する必要があります。
* 30 の新しいデータベースは自動的に拡張する必要があります。
* オンプレミス インフラストラクチャの使用は最小限に抑える必要があります。
* Azure SQL Database の展開には、Azure ハイブリッド使用特典を利用する必要があります。
* CPU とストレージの使用量と制限に関連するすべての SQL Server および Azure SQL Database メトリックは、Azure の組み込み機能を使用して分析する必要があります。
セキュリティとコンプライアンスの要件
Litware は、次のセキュリティおよびコンプライアンスの要件を特定します。
* 暗号化キーを Azure Key Vault に保存します。
* PII データのバックアップは 2 か月間保持します。
* 保存中、転送中、および使用中の PII データを暗号化します。
* 可能な限り最小特権の原則を使用します。
* Active Directory 資格情報を使用してデータベース ユーザーを認証します。
* データベース レベルのファイアウォール ルールを使用して、Azure SQL Database インスタンスを保護します。
* Azure でホストされているすべてのデータベースが、パブリック エンドポイントに依存せずに VM1 および VM2 からアクセスできることを確認します。
ビジネス要件
Litware は次のビジネス要件を特定します。
* すべての Azure デプロイメントで 99.99% の可用性の SLA を満たします。
* SERVER1 データベースの移行中のダウンタイムを最小限に抑えます。
* ワークロードを Azure に移行する場合は、Azure ハイブリッド利用特典を使用してください。
* すべての要件が満たされたら、可能な限りコストを最小限に抑えます。