シナリオ: SalesSQLDb1 は、データベース ファイアウォール ルールと包含データベース ユーザーを使用します。
これはケーススタディです。ケーススタディは個別に時間が設定されるわけではありません。各ケースを完了したいだけ試験時間を費やすことができます。ただし、この試験には追加のケーススタディやセクションが存在する場合があります。この試験に含まれるすべての質問を指定された時間内に完了できるように時間を管理する必要があります。
ケーススタディに含まれる質問に答えるには、ケーススタディで提供される情報を参照する必要があります。ケース スタディには、ケース スタディで説明されているシナリオに関する詳細情報を提供する展示やその他のリソースが含まれる場合があります。このケーススタディでは、各質問は他の質問から独立しています。
このケーススタディの最後に、レビュー画面が表示されます。この画面では、試験の次のセクションに進む前に、回答を確認し、変更を加えることができます。新しいセクションを開始した後は、このセクションに戻ることはできません。
ケーススタディを開始するには
このケーススタディの最初の質問を表示するには、「次へ」ボタンをクリックします。
質問に答える前に、左側のペインのボタンを使用してケーススタディの内容を調べてください。
これらのボタンをクリックすると、ビジネス要件、既存の環境、問題の説明などの情報が表示されます。
ケーススタディに [すべての情報] タブがある場合、表示される情報は後続のタブに表示される情報と同じであることに注意してください。
質問に答える準備ができたら、「質問」ボタンをクリックして質問に戻ります。
概要
トピック 3、アダタム株式会社
既存の環境
ADatum には、Microsoft SQL Server 2016 がインストールされたデータベース サーバーが 1 台あります。このサーバーは、SALESDB、DOCDB、REPORTINGDB という 3 つのミッションクリティカルなデータベースをホストします。
SALESDB は店舗と Web サイトからデータを収集します。
DOCDB は、SaleSDB の販売データに接続するドキュメントを保存します。ドキュメントは、販売チャネルに基づいて 2 つの異なる JSON 形式で保存されます。
REPORTINGDB にはレポート データが格納され、いくつかの列ストア インデックスが含まれています。毎日のプロセスにより、SaleSDB のデータから REPORTINGDB にレポート データが作成されます。このプロセスは、SALESDB からストアド プロシージャを実行する SQL Server Integration Services (SSIS) パッケージとして実装されます。
要件
計画された変更
ADatum は、現在のデータ インフラストラクチャを Azure に移行することを計画しています。新しいインフラストラクチャには次の要件があります。
SALESDB と REPORTINGDB を Azure SQL データベースに移行します。
DOCDB を Azure Cosmos DB に移行します。
JSON 形式のドキュメントを含む販売データは、到着時に収集し、Azure Stream Analytics を使用してオンラインで分析する必要があります。分析プロセスでは、ギャップや重複なしに継続的に実行する必要がある集計が実行されます。
JSON 形式のすべての販売ドキュメントは、到着したら、一貫した 1 つの形式に変換する必要があります。
Azure Data Factory は、SaleSDB から REPORTINGDB にデータをコピーする SSIS プロセスを置き換えます。
技術的要件
新しい Azure データ インフラストラクチャは、次の技術要件を満たす必要があります。
SALESDB 内のデータは、透過的データ暗号化 (TDE) を使用して暗号化する必要があります。暗号化には独自のキーを使用する必要があります。
SALESDB は、過去 3 週間以内の任意の時点に復元可能である必要があります。
実際の使用パターンに基づいてワークロードのサイズが適切に設定されていることを確認するには、リアルタイム処理を監視する必要があります。
欠落しているインデックスは REPORTINGDB に対して自動的に作成する必要があります。
SALESDB では、ディスク IO、CPU、およびメモリの使用状況を監視する必要があります。

セクション: [なし]
Explanation:
ボックス 1: sys.resource_stats
sys.resource_stats は、Azure SQL Database の CPU 使用率とストレージ データを返します。データベース名があります
および start_time 列。
ボックス 2: 日付の追加
次の例では、過去のコンピューティング使用率の平均が少なくとも 80% であるすべてのデータベースを返します。
一週間。
@s の日時を宣言します。
DECLARE @e 日時;
SET @s= DateAdd(d,-7,GetUTCDate());
SET @e= GETUTCDATE();
SELECT データベース名、AVG(avg_cpu_percent) AS Average_Compute_Utilization
sys.resource_stats から
WHERE start_time BETWEEN @s と @e
GROUP BY データベース名
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 データベースの 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-
データベース

セクション: [なし]
Explanation:
デフォルトでは、プレミアム可用性モデルのノードのクラスターは同じデータセンターに作成されます。Azure Availability Zones の導入により、SQL Database は Business Critical データベースの異なるレプリカを同じリージョン内の異なる可用性ゾーンに配置できるようになります。単一障害点を排除するために、制御リングも 3 つのゲートウェイ リング (GW) として複数のゾーンにわたって複製されます。特定のゲートウェイ リングへのルーティングは、Azure Traffic Manager (ATM) によって制御されます。Premium または Business Critical サービス レベルのゾーン冗長構成では追加のデータベース冗長性が作成されないため、追加コストなしで有効にすることができます。ゾーン冗長構成を選択すると、Premium または Business Critical データベースを、壊滅的なデータセンターの停止など、より大規模な一連の障害に対する回復力を高めることができます。アプリケーションロジックを変更する必要はありません。既存の Premium または Business Critical データベースまたはプールをゾーン冗長構成に変換することもできます。
不正解:
C. この機能は SQL Managed Instance では使用できません。
参照：
https://docs.microsoft.com/en-us/azure/azure-sql/database/high-availability-sla

参照：
https://docs.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-metric-overview