サンドボックス環境への運用データベースのポイントインタイム復元

Microsoft Dynamics Lifecycle Services を使用して、運用データベースをユーザー受け入れテスト (UAT) サンドボックス環境に復元できます。 Microsoft では、運用環境では 28 日間、サンドボックス環境では 7 日間、ビジネス および財務レポート データベースの 自動バックアップ を維持しています。

運用環境からサンドボックスへのセルフサービス型ポイントイン タイム復元

ライフサイクル サービス チームは、人間または手動のプロセスに依存しないデータ アプリケーション ライフサイクル管理 (DataALM) 機能を顧客に提供するために、データベースの自動復元アクションを導入しました。 次の概要では、セルフサービス データベースの復元を実行するプロセスについて説明します。

1. ターゲット サンドボックスの [環境の詳細] ページに移動し、[ Maintain>Move database] を選択します。
2. Prod環境からSandbox環境へのポイントインタイム復元 オプションを選択し、希望する時点を選択します。
3. 警告に注意し、元の環境の前の時点からコピーされていないデータ要素のリストを確認します。
4. 復元操作がすぐに開始されます。

本番環境からサンドボックスへ復元する際に適用できるシナリオ

運用データベースをサンドボックス環境に復元すると、運用環境で誤ってデータを失った場合に役立ちます。 この方法を使用すると、データを回復し、運用環境に再入力することができます。 運用環境からサンドボックス環境へのポイントインタイム リストアを実行し、サンドボックス環境に接続して復元されたデータベースからデータを復旧してから、運用環境に再入力します。

失敗した操作の復元

復元が成功しなかった場合は、自動的に ロールバック されます。 ターゲットのサンドボックス環境は、復元が開始される前の状態に復元されます。 Azure SQL Database ポイントインタイム リストア (PITR) 機能を使用すると、ロールバックを使用できます。 対象とするサンドボックス環境に存在するカスタマイズが、新たに復元されたデータでデータベースの同期を完了できない場合に、これらが必要になります。

失敗の根本原因を特定するには、環境変更履歴 ページを使用して、ロールバックした操作のログをダウンロードします。

復元のコピー処理の過程でコピーされなかったデータ要素

運用環境をサンドボックス環境に、またはサンドボックス環境を別のサンドボックス環境に更新する際に、対象の環境にコピーされない特定のデータベース要素が存在します。 次にいくつか例を挙げます。

• LogisticsElectronicAddress テーブル内の電子メール アドレス。
• SysEmailParameters テーブルの シンプル メール トランスファー プロトコル (SMTP) リレーサーバー。
• PrintMgmtSettings と PrintMgmtDocInstance テーブルの印刷管理設定。
• SysServerConfig、SysServerSessions、SysCorpNetPrinters、SysClientSessions、BatchServerConfig、および BatchServerGroup テーブル内の環境固有のレコード。
• Azure Blob Storage に保存されているすべてのファイル。 この一覧には、ドキュメントの添付ファイル (DocuValue テーブルと DocuDeletedValue テーブルから) とカスタム Microsoft Office テンプレート (DocuTemplate テーブルから) が含まれています。
• 管理者以外のすべてのユーザーは 無効 のステータスに設定されます。
• すべてのバッチ ジョブは、 保留 状態に設定されます。
• すべてのユーザーのパーティション値は 「初期」 パーティション レコード ID にリセットされます。
• 別のデータベース サーバーでは解読できないため、すべての Microsoft 暗号化フィールドはクリアされます。 次の例は、sysemailsmtppasswordテーブルの パスワード フィールドです。
• 二重書き込みの構成。 この操作に成功した後にターゲット環境に新しいリンクを設定するには、 Power Platform 統合を有効にするを参照してください。

これらの要素は、環境固有のものであるためコピーされません。 BatchServerConfig と SysCorpNetPrinters のレコードを含む例。 サポートチケットの数が多いため、他の要素はコピーされていません。 たとえば、簡易メール転送プロトコル (SMTP) は UAT 環境でも有効になっているため、重複する電子メールが送信されてしまう可能性があります。また、バッチ ジョブも有効になっており、無効な統合メッセージが送信されてしまう可能性もあるため、管理者が復元後クリーンアップを行う前にユーザーが有効化してしまう可能性があります。

環境管理者

ターゲット環境のシステム管理者アカウント ( UserId 値が Admin のアカウント) は、ターゲット環境の web.config ファイルにある値にリセットされます。 この値は、ライフサイクル サービスの管理者アカウントの値と一致する必要があります。 このアカウントをプレビューするには、Lifecycle Services のターゲット サンドボックス環境の [ 環境の詳細] ページに移動します。 トランザクション データベース内のシステム 管理者 アカウントと一致するように環境の更新プログラムを最初に展開するときに、[環境管理者] フィールドで選択した値。 そのため、環境のテナントは、環境管理者のテナントでもあります。

環境で管理ユーザー プロビジョニング ツールを使用して web.config ファイルの値を変更すると、その値がライフサイクル サービスの値と一致しない可能性があります。 別のアカウントが必要な場合は、ターゲット サンドボックス環境の割り当てを解除して削除してから、再デプロイして別のアカウントを選択する必要があります。 その後、別のデータベース復元アクションを実行してデータを復元できます。

あるテナントから別のテナントに環境を復元することはできません。 この制限は、onmicrosoft.com テナントにも適用されます。 ソース環境とターゲット環境の管理者アカウントが同じテナント ドメインから取得されていることを確認します。

運用環境の PITR コピーをサンドボックス環境にコピーする条件

次の一覧では、データベース復元の操作の要件と条件について説明します。

• 復元操作により、元のターゲット データベースが削除されます。
• ターゲット環境は、データベースのコピーがターゲット サーバーに到達するまで使用できます。 その後、復元プロセスが完了するまで、環境はオフラインになります。
• 復元操作は、アプリケーションと財務報告データベースにのみ影響します。
• ある環境から別の環境に、Azure Blob Storage に保管してあるファイルはコピーされません。 この制限には、 ドキュメントの添付ファイルとカスタム Microsoft Office テンプレートが含まれます。 これらのドキュメントは変更されず、現在の状態のままです。
• 管理者ユーザー、およびその他の内部サービス ユーザー アカウントを除くすべてのユーザーは使用できません。 そのため、管理者ユーザーは他のユーザーがシステムに復帰する前にデータの削除や難読化することができます。
• 管理者ユーザーは、特定のサービスまたは URL に統合エンドポイントを再接続するなど、必要な構成の変更を加える必要があります。
• 定期的なインポートとエクスポートが有効になっているすべてのデータ管理統合ジョブは、復元が開始される前に、ターゲット システムで完全に処理および停止する必要があります。 さらに、すべての定期的なインポートおよびエクスポート ジョブが完全に処理された後で、ソースからデータベースを選択します。 この手順により、いずれかのシステムから孤立したファイルが Azure Storage に存在しないようにします。 対象の環境でデータベースを復元した後は、孤立したファイルを処理できないため、この手順は重要となります。 復元後、インテグレーションジョブを再開できます。
• 同じエンドポイントが使用されないように、データベースを復元する環境でビジネス イベント エンドポイントを削除および再構成する必要があります。 また、このアクションでは、環境内で構成した新しいエンドポイントにビジネス イベントを非アクティブ化して再アクティブ化する必要もあります。
• ライフサイクル サービスのプロジェクト所有者または環境マネージャー ロールを持つすべてのユーザーは、非運用環境のすべての SQL とマシンの資格情報にアクセスできます。
• データベースが Spartan で管理されていない場合は、データベースを同じ地理上の Azure リージョンでホストする必要があります。 SQL server の完全修飾アドレスの一部に ' spartan ' が含まれていれば、データベースは Spartan に管理されています。
• 実行元の環境で割り当てられたデータベースの容量は、実行対象の環境のデータベースの最大容量よりも小さくする必要があります。

コマース機能を使用する環境で復元後に実行する手順

環境間でデータベースをコピーすると、次の追加の手順を実行しない限り、移行先環境の Commerce の機能は完全には機能しません。

Commerce Scale Units の初期化

データベースをサンドボックスのユーザー受け入れテスト (UAT) または運用環境に移動する場合は、データベースの移動操作が完了した後に、Commerce Scale Unit を初期化する必要があります。 ソース環境からの Commerce Scale Unit の関連付けは、移行先の環境にコピーされません。

Commerce のセルフサービス インストーラーの同期

本部内の Commerce セルフサービス インストーラーにアクセスできるようにするには、データベースの移動操作が完了した後にセルフサービス インストーラーを同期する必要があります。

移行先の環境で環境の再プロビジョニング ツールを実行するには、次の手順を実行します。

1. ソフトウェア配置可能パッケージ セクションにある自身のプロジェクトの アセット ライブラリ で、 インポートを選択します。
2. 共用資産の一覧から、 環境再プロビジョニング ツールを選択します。
3. 移行先環境の 環境の詳細 ページで、 管理>更新プログラムを適用を順に選択します。
4. 先ほどアップロードした 環境再プロビジョニング ツールを選択し、 適用 を選択してパッケージを適用します。
5. パッケージの配置の進捗を監視します。

配置可能なパッケージの適用方法についての詳細は、 配置可能なパッケージを作成するを参照してください。 配置可能パッケージを手動で適用する方法の詳細については、 配置可能 な パッケージ を コマンド ライン から インストール するを参照してください。

POS デバイスの再アクティブ化

販売時点管理 (POS) デバイスを使用する場合は、データベースをインポートした後、POS デバイスを再度アクティブ化する必要があります。 移行先環境で以前にアクティブ化されたデバイスは、機能しなくなります。 詳細については、販売時点管理 (POS) デバイスのライセンス認証 を参照してください。

既知の問題

サンドボックスのカスタマイズが運用データと互換性がない場合、復元操作は失敗します

サンドボックス環境にカスタマイズを正常に追加した場合 (つまり、顧客の AOT 配置可能パッケージが正常にインストールされた場合)、運用データに対しては成功しない可能性があります。 たとえば、顧客が仕入先名の一意のインデックスを VendTable テーブルに追加します。 サンドボックス環境に重複するベンダー名がない場合は、このカスタマイズを正常にインストールできます。 ただし、運用データベースを復元操作の一環として使用した場合、サンドボックス環境にインバウンドするデータセットに重複があると、インストールが失敗することがあります。 このデータセットの重複はサポートされていません。 したがって、復元操作を成功させる前に、カスタマイズを削除する必要があります。

プラットフォーム 更新プログラム 20 以前が稼働している環境では、復元操作は拒否されます

現在、環境がプラットフォーム更新プログラム 20 またはそれ以前を実行している場合は、データベースの復元プロセスを完了することはできません。 詳細については、現在サポートされているプラットフォーム更新の一覧 を参照してください。

実行元の環境と実行対象の環境に互換性のないバージョンの Financial Reporting が存在します

実行対象とする環境の Financial Reporting のバージョンが実行元の環境のバージョンよりも古い場合は、データベースの復元プロセス (セルフ サービスまたはサービス リクエスト経由) が正常に完了できません。 この問題を解決するには、両方の環境で財務報告が最新バージョンとなるように更新を行ってください。

実行対象と実行元の環境にインストールされているバージョンを確認するには、環境の詳細 ページの 詳細バージョン情報を表示する のリンクを確認してください。 続いて、MRApplicationServiceを検索し、実行対象の環境のバージョンが実行元の環境のバージョンと同じであるか、高いバージョンであることを確認します。

バージョン 8.1 以降を使用しているお客様は、次の手順に従う必要があります。

1. 更新 のタイルメニューを開き、UAT環境を更新します。 更新内容をプロジェクトの資産ライブラリに保存します。
2. パッケージを UAT 環境に適用します。
3. エラーが解決されたことを検証します。

バージョン 8.0 以前を使用しているお客様は、次の手順に従う必要があります。

1. 実行元の環境の環境履歴を確認してください。 具体的には、ターゲット環境ではなく、ソース環境にデプロイした "プラットフォームとアプリケーション のバイナリ パッケージ" パッケージを探します。
2. バイナリ パッケージを実行対象の環境に適用します。
3. エラーが解決されたことを検証します。

実行元の環境と実行対象の環境間での互換性のないアプリケーション バージョンが存在します

ソース環境のアプリケーション リリースとターゲット環境のアプリケーション リリースが同じでない場合は、データベース復元プロセス (セルフサービスまたはサービス要求経由) を完了できません。 これは、データの更新プロセスが、更新などのデータベースの移動操作によって実行されず、データ損失が発生する可能性があるためです。

新しいアプリケーション バージョンにサンドボックス UAT 環境をアップグレードする場合は (たとえば、7.3 から 8.1 など)、必ずアップグレードを開始する前にデータベースの復元アクションを実行してください。 サンドボックス環境を新しいバージョンにアップグレードした後は、古い運用環境データベースをサンドボックス UAT 環境に復元することはできません。

逆に、運用環境がターゲット サンドボックス環境よりも新しい場合は、復元前にターゲット サンドボックス環境をアップグレードするか、更新を行う前に環境の割り当てを解除、削除、再デプロイする必要があります。

ソースとターゲットが異なるインフラストラクチャ上にある (Microsoft が管理するインフラストラクチャとセルフサービス)

PITR プロセスは、ソースとして Microsoft 管理環境と、行先としてのセルフサービス環境の間ではサポートされません。 たとえば、運用環境が Microsoft によって管理され、米国東部にあり、セルフサービスで米国東部のサンドボックス環境に PITR が必要な場合、PITR はサポートされません。 代わりに、運用環境をセルフ サービスに移動するか、定期的なデータベース更新を選択することもできます。

異なる地域で、両方ともセルフ サービスにあるソースとターゲット間のポイントインタイム復元

PITR プロセスは、異なる地域間のセルフ サービス環境間ではサポートされていません。 たとえば、運用環境が米国東部にあり、セルフ サービスのサンドボックス環境に PITR が必要な場合、西ヨーロッパでは PITR はサポートされていません。 代わりに、環境を両方とも同じ地域にするか、定期的なデータベース更新を選択することもできます。