トレーニング
認定資格
Microsoft Certified: Azure Database Administrator Associate - Certifications
Microsoft PaaS リレーショナル データベース オファリングを使用して、クラウド、オンプレミス、ハイブリッド リレーショナル データベースの SQL Server データベース インフラストラクチャを管理します。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
注意
Microsoft Purview データ カタログは、名前を Microsoft Purview 統合カタログに変更しています。 すべての機能は同じままです。 新しい Microsoft Purview データ ガバナンス エクスペリエンスがリージョンで一般公開されると、名前の変更が表示されます。 リージョン内の名前を確認します。
この記事では、organizationに運用環境の展開で Microsoft Purview 統合ガバナンス ソリューションがある場合のバックアップと回復の戦略に関するガイダンスを提供します。 この一般的なガイドラインを使用して、アカウントの移行を実装することもできます。 この記事では、API を使用して自動化できる 手動 BCDR メソッドについて説明します。
Azure データ センターの停止はまれですが、数分から数時間かかる場合があります。 データ センターの停止により、データ ガバナンスに依存している環境が中断される可能性があります。 この記事で詳しく説明されている手順に従うと、Microsoft Purview アカウントのプライマリ リージョンでデータ センターが停止した場合でも、引き続きデータを管理できます。
ヒント
Microsoft Purview の信頼性の詳細については、信頼性に関する ドキュメントを参照してください。
Microsoft Purview インスタンスのビジネス継続性とディザスター リカバリー (BCDR) とは、ビジネスがデータ損失を保護し、中断が発生した場合(特にスキャン、カタログ、分析情報のレベル)で運用を継続できるようにするメカニズム、ポリシー、手順を指します。 このページでは、Microsoft Purview のディザスター リカバリー環境を構成する方法について説明します。
現在、Microsoft Purview は自動 BCDR をサポートしていません。 そのサポートが追加されるまでは、バックアップと復元のアクティビティの処理を行う必要があります。 別のリージョンでウォーム スタンバイ インスタンスとしてセカンダリ Microsoft Purview アカウントを手動で作成できます。
次の手順は、ディザスター リカバリーを手動で実現する方法をまとめたものです。
プライマリ Microsoft Purview アカウントが作成されたら、別のリージョンに 1 つ以上のセカンダリ Microsoft Purview アカウントを作成します。
重要
Microsoft Purview では現在、テナントごとに 1 つの Microsoft Purview インスタンスがサポートされています。 バックアップとディザスター リカバリー用の 2 つ目のアカウントを作成するには、 サポートにお問い合わせください
プライマリ Microsoft Purview アカウントで実行されるすべてのアクティビティは、セカンダリ Microsoft Purview アカウントでも実行する必要があります。 保持されるデータには以下が含まれます。
ディザスター リカバリー アカウントを作成および管理するための具体的な手順については、記事の後半で説明します。 それらに従う前に、制限事項と考慮事項を確認してください。
手動 BCDR プランを作成するときは、次の点に注意してください。
プライマリとセカンダリの Microsoft Purview インスタンスに対して課金されます。
プライマリとセカンダリの Microsoft Purview アカウントは、同じAzure Data Factory Azure Data Share と Synapse Analytics アカウント (該当する場合) に構成することはできません。 その結果、Azure Data Factoryと Azure Data Shareからの系列は、セカンダリ Microsoft Purview アカウントでは確認できません。 この制限は、自動 BCDR がサポートされている場合に対処されます。
統合ランタイムは、Microsoft Purview アカウントに固有です。 そのため、スキャンはプライマリとセカンダリの Microsoft Purview アカウントで並列で実行する必要があります。複数のセルフホステッド統合ランタイムを維持する必要があります。 この制限は、自動 BCDR がサポートされている場合にも対処されます。
同じソース上のプライマリとセカンダリの両方の Microsoft Purview アカウントからのスキャンの並列実行は、ソースのパフォーマンスに影響する可能性があります。 これにより、スキャン期間が Microsoft Purview アカウントによって異なる場合があります。
"スキャンされた" 資産の詳細をバックアップすることはお勧めしません。 資産に対する分類や用語集のマッピングなど、キュレーションされたデータのみをバックアップする必要があります。 資産の詳細をバックアップする必要がある唯一のケースは、カスタム typeDef
を使用してカスタム資産を使用する場合です。
バックアップされた資産の数は、100,000 個未満の資産にする必要があります。 メイン ドライバーは、検索クエリ API を使用して資産を取得する必要があり、返される資産は 100,000 個に制限されています。 ただし、API 呼び出しごとに少ない数の資産を取得するために検索クエリをセグメント化できる場合は、100,000 を超える資産をバックアップできます。
2 つのアカウント間で資産を継続的に "同期" する場合は、この記事では詳しく説明しない他の手順があります。 Microsoft Purview の Event Hubs を使用して、別のアカウントにエンティティをサブスクライブして作成する必要があります。 ただし、Event Hubs には Atlas 情報のみが含まれます。 Microsoft Purview では、Event Hubs では使用できない 用語集 や 連絡先 などの他の機能が追加されました。
organizationに既に複数の Microsoft Purview アカウントがある場合は、次のガイドの指示に従って新しい Microsoft Purview アカウントを作成できます。クイック スタート: Azure portalで Microsoft Purview アカウントを作成する
organizationにテナント/組織の Microsoft Purview アカウントが 1 つしかない場合は、バックアップと回復のアカウントを作成するには、サポートにお問い合わせください。
後で変更できないこれらの構成項目を計画します。
以下の手順では、プログラムを使用してバックアップ アカウントをすばやく立ち上げることができるように、 Microsoft Purview API のドキュメント を参照しています。
タスク | 説明 |
---|---|
アカウント情報 | ルート レベルで管理者またはサービス プリンシパルのアクセス権をアカウントに付与することで、アカウント情報を維持する |
コレクション | コレクションを作成および管理し、ソースとコレクションの関連付けを行います。 List Collections API を呼び出し、Get Collection API を使用して各コレクションの特定の詳細を取得できます |
スキャン ルール セット | カスタム スキャン ルール セットを作成および管理します。 List カスタム スキャン ルール セット API を呼び出し、スキャン ルール セット API の取得を呼び出して詳細を取得する必要があります |
手動分類 | get classifications API を呼び出して、すべての手動分類の一覧を取得し、各分類の詳細を取得します |
リソース セットルール | リソース セット ルールを作成および管理します。 リソース セットの取得ルール API を呼び出して、ルールの詳細を取得できます |
データ ソース | すべてのデータ ソースの取得 API を呼び出して、詳細を含むデータ ソースを一覧表示します。 また、 Get trigger API を呼び出してトリガーを取得する必要もあります。 新しいアカウントで ソース を一括で再作成する必要がある場合は、データ ソースの作成 API もあります。 |
資格情報 | スキャン中に使用される資格情報を作成および管理します。 資格情報を抽出する API がないため、これは新しいアカウントでやり直す必要があります。 |
セルフホステッド統合ランタイム (SHIR) | SHIR の一覧を取得し、新しいアカウントから更新されたキーを取得し、SHIR を更新します。 これは、 SHIR のホスト内で手動で行う必要があります。 これらは、スキャンを作成する前に実行されている必要があります。 |
ADF 接続 | 現在、ADF は一度に 1 つの Microsoft Purview に接続できます。 失敗した Microsoft Purview アカウントから ADF を切断し、後で新しいアカウントに再接続する必要があります。 |
重要
スキャンを作成する前 に、セルフホステッド統合ランタイム が構成されていて、実行されていて使用可能であることを確認します。
これにより、すべての資産に既定の typedef
が設定されます。 スキャンをもう一度実行する理由と、既存の資産をエクスポートして新しいアカウントにインポートする理由はいくつかあります。
資産をエクスポートするために、検索クエリから返される資産の上限は 100,000 です。
リレーションシップを使用して資産をエクスポートするのは面倒です。
スキャンを再実行すると、すべてのリレーションシップと資産の詳細が最新の状態で取得されます。
Microsoft Purview には新しい機能が定期的に用意されているため、新しいスキャンを実行するときに他の機能からメリットを得ることができます。
スキャンの実行は、Microsoft Purview が既にサポートしているすべてのデータ ソースの資産を取得する最も効果的な方法です。
organizationが Microsoft Purview でカスタム型を作成した場合は、手動で移行する必要があります。
すべてのカスタム typedef
を識別するには、 get all type definitions API を使用します。 これにより、各型が返されます。 次のような形式でカスタム型を識別する必要があります。 "serviceType": "<custom_typedef>"
カスタム資産をエクスポートするには、これらのカスタム資産を検索し、探索 API を使用して適切なカスタム typedef
を渡します
注意
検索結果ごとに 100,000 の戻り値の制限があります。 100,000 を超えるレコードが返されないように、検索クエリを中断しなければならない場合があります。
検索クエリをスコープダウンして資産のサブセットを取得するには、いくつかの方法があります。
Keyword
の使用: などの親 FQN を渡すKeyword: "<Parent String>/*"
Filter
の使用: 検索に特定のカスタム typedef
を含むassetType
を含める (例:"assetType": "<custom_typedef>"
特定のストレージ アカウント (exampleaccount
) 内の資産のみが返されるようにkeywords
をカスタマイズして、検索ペイロードの例を次に示します。
{
"keywords": "adl://exampleaccount.azuredatalakestore.net/*",
"filter": {
"and": [
{
"not": {
"or": [
{
"attributeName": "size",
"operator": "eq",
"attributeValue": 0
},
{
"attributeName": "fileSize",
"operator": "eq",
"attributeValue": 0
}
]
}
},
{
"not": {
"classification": "MICROSOFT.SYSTEM.TEMP_FILE"
}
},
{
"not": {
"or": [
{
"entityType": "AtlasGlossaryTerm"
},
{
"entityType": "AtlasGlossary"
}
]
}
}
]
},
"limit": 10,
"offset": 0,
"facets": [
{
"facet": "assetType",
"count": 0,
"sort": {
"count": "desc"
}
},
{
"facet": "classification",
"count": 10,
"sort": {
"count": "desc"
}
},
{
"facet": "contactId",
"count": 10,
"sort": {
"count": "desc"
}
},
{
"facet": "label",
"count": 10,
"sort": {
"count": "desc"
}
},
{
"facet": "term",
"count": 10,
"sort": {
"count": "desc"
}
}
]
}
返される資産には、詳細を抽出できるキー/ペア値があります。
{
"referredEntities": {},
"entity": {
"typeName": "column",
"attributes": {
"owner": null,
"qualifiedName": "adl://exampleaccount.azuredatalakestore.net/123/1/DP_TFS/CBT/Extensions/DTTP.targets#:xml/Project/Target/XmlPeek/@XmlInputPath",
"name": "~XmlInputPath",
"description": null,
"type": "string"
},
"guid": "5cf8a9e5-c9fd-abe0-2e8c-d40024263dcb",
"status": "ACTIVE",
"createdBy": "ExampleCreator",
"updatedBy": "ExampleUpdator",
"createTime": 1553072455110,
"updateTime": 1553072455110,
"version": 0,
"relationshipAttributes": {
"schema": [],
"inputToProcesses": [],
"composeSchema": {
"guid": "cc6652ae-dc6d-90c9-1899-252eabc0e929",
"typeName": "tabular_schema",
"displayText": "tabular_schema",
"relationshipGuid": "5a4510d4-57d0-467c-888f-4b61df42702b",
"relationshipStatus": "ACTIVE",
"relationshipAttributes": {
"typeName": "tabular_schema_columns"
}
},
"meanings": [],
"outputFromProcesses": [],
"tabular_schema": null
},
"classifications": [
{
"typeName": "MICROSOFT.PERSONAL.EMAIL",
"lastModifiedTS": "1",
"entityGuid": "f6095442-f289-44cf-ae56-47f6f6f6000c",
"entityStatus": "ACTIVE"
}
],
"contacts": {
"Expert": [
{
"id": "30435ff9-9b96-44af-a5a9-e05c8b1ae2df",
"info": "Example Expert Info"
}
],
"Owner": [
{
"id": "30435ff9-9b96-44af-a5a9-e05c8b1ae2df",
"info": "Example Owner Info"
}
]
}
}
}
注意
また、出力から用語テンプレート typedef
移行する必要があります。
カスタム エンティティを再作成する場合は、API に送信する前にペイロードの準備が必要になる場合があります。
注意
最初の目標は、リレーションシップやマッピングなしですべてのエンティティを移行することです。 これにより、潜在的なエラーが回避されます。
updateTime
、updateTime
、lastModifiedTS
など、すべてのtimestamp
値は null にする必要があります。
guid
は以前とまったく同じように再生成できないため、エラーを回避するには、"-5000" などの負の整数を渡す必要があります。
guids
が同じではないか、まだ作成されていない可能性があるため、relationshipAttributes
のコンテンツはペイロードの一部にしないでください。 ペイロードを送信する前に、 relationshipAttributes
を空の配列に変換する必要があります。
meanings
には、エンティティの作成後に一括で更新されるすべての用語集マッピングが含まれています。同様に、 classifications
は、後で別の API を使用して一括エンティティへの分類マッピングを作成する必要があるため、エンティティを作成するためにペイロードを送信するときにも空の配列である必要があります。
資産の移行を完了するには、リレーションシップを再マップする必要があります。 次の 3 つのタスクがあります。
リレーションシップ API を呼び出して、エンティティ間のリレーションシップ情報を取得します。guid
古い Microsoft Purview アカウントで古い guids
へのハード 参照がないように、リレーションシップ ペイロードを準備します。 これらの guids
を新しいアカウントの guids
に更新する必要があります。
注意
用語を移行する前に、用語テンプレートを移行する必要があります。 この手順は、カスタム typedef
移行で既に説明されている必要があります。
用語集の用語を移行する最も簡単な方法は、 用語を .csv ファイルにエクスポートすることです。 これを行うには、Microsoft Purview ガバナンス ポータルを使用します。
用語集の移行を自動化するには、まず、用語集 API を使用して用語集のguid
(glossaryGuid
) を取得する必要があります。
glossaryGuid
は、最上位/ルート レベルの用語集guid
です。
次の応答例は、後続の API 呼び出しに使用する guid
を提供します。
"guid": "c018ddaf-7c21-4b37-a838-dae5f110c3d8"
glossaryGuid
が完了したら、次の 2 つの手順で用語の移行を開始できます。
注意
この手順の前提条件は、[ 構成項目の移行 ] ステップの新しいアカウントですべての分類を使用できるようにするためです。
資産への分類の割り当てを取得するには、 探索 API を呼び出す必要があります。 これは、すべての資産に適用されます。 カスタム資産を移行した場合、分類の割り当てに関する情報は、 classifications
プロパティで既に使用できます。 分類を取得するもう 1 つの方法は、古いアカウントのguid
ごとの分類を一覧表示することです。
資産に分類を割り当てるには、API を使用して 分類を複数のエンティティに一括で関連付ける 必要があります。
前の手順から資産情報を抽出した場合、連絡先の詳細は 探索 API から入手できます。
資産に連絡先を割り当てるには、 guids
の一覧を作成し、連絡先のすべての objectid
を識別する必要があります。 エンティティの 作成または更新 API を使用して、すべての資産を反復処理し、すべての資産に連絡先を再割り当てすることで、このプロセスを自動化できます。
トレーニング
認定資格
Microsoft Certified: Azure Database Administrator Associate - Certifications
Microsoft PaaS リレーショナル データベース オファリングを使用して、クラウド、オンプレミス、ハイブリッド リレーショナル データベースの SQL Server データベース インフラストラクチャを管理します。