データベース ポイントインタイム復元 (PITR)

  • [アーティクル]

Microsoft Dynamics Lifecycle Services (LCS) を使用し、サンドボックス ユーザー受け入れテスト (UAT) 環境、または運用環境のポイントインタイム リストア (PITR) を実行することができます。 Microsoft は、業務および財務報告用のデータベースの自動バックアップ を、運用環境の場合は 28 日間、サンドボックス環境の場合は 7 日間維持します。

セルフサービスポイントインタイム復元

標準ユーザー承認テスト (UAT) 環境のデータベースを前回のポイントインタイムに復元するには、次のステップを実行します。

  1. ターゲット サンドボックスの 環境詳細 ページを開き、 メニュー オプションから 管理>データベースの移動 を選択します。
  2. ポイントインタイム復元 を選択し、ポイントインタイムを選択します。
  3. 警告に注意してください。 前回のポイントインタイムからコピーされていないデータ要素の一覧を確認します。
  4. 復元操作をすぐに開始します。

重要

運用中のデータベースを以前のポイントインタイムにリストアすることは、一般的なライフサイクル作業ではないため、次のような問題が発生する可能性があります:

  • 実稼働環境における大規模なダウンタイム。 データベース のサイズによっては、ポイントインタイム リストア (PITR) に数時間を要する場合があります。
  • SQL データ損失。 SQL データ損失は、PITR 要求の実行時間に依存します。
  • SQL データベースの破損利用可能な復元ポイントのチェーン。

運用環境のデータベースを以前のポイントインタイムにリストアするには、以下の手順に従います:

  1. ターゲットとすつ運用環境の 環境詳細 ページを開き、 メニュー オプションから 管理>データベースの移動 を選択します。
  2. ポイントインタイム復元 を選択し、ポイントインタイムを選択します。
  3. 警告に注意してください。 前回のポイントインタイムからコピーされていないデータ要素の一覧を確認します。
  4. 復元操作をすぐに開始します。

運用環境の復元に適用されるシナリオ

運用中のデータベースを以前のポイントインタイムにリストアすることは、一般的なライフサイクル作業ではありません。 ただし、運用環境で重大なデータ破損が発生した場合は、運用環境の回復が必要になる場合があります。 この操作では、リクエストの時点までに大幅なダウンタイムが発生し、SQL データが失われる可能性があることに注意してください。

失敗した操作の復元

障害が発生した場合、復元操作は自動的にロールバックされます。 操作が最初に失敗をした後に ロールバック オプションを選択すると、ターゲット サンドボックス環境は、復元開始前の状態に復元されます。 ターゲット サンドボックスに存在するカスタマイズが、新しく復元されたデータとのデータベースの同期を完了できない場合、ロールバックが必要になることがよくあります。

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

復元後に注意が必要なデータの要素

以前の時点からデータベースを復元する場合、データベースは "現状のまま" 提供されることに注意してください。例えば、システム内のバッチ ジョブやその他のデータ要素が進行中の状態になる可能性があります。 これらの要素は、手動で確認が必要となります。

メモ

復元は、Azure Blob Storage に保存されているファイルへの参照を保存するテーブルに影響を与えます (ドキュメントの添付ファイルやカスタム Microsoft Office テンプレートなど)。 ただし、Azure Blob Storage 自体は、このプロセスの影響を受けません。復元時点の後に追加されたファイルは引き続き Azure Blob Storage に存在しますが、データベースには反映されません。

環境管理者

対象の環境のシステム管理者アカウント (AdminのUserId値を持つアカウント) が、対象の環境に存在する web.config ファイルで検出された値にリセットされます。 この値は、LCS の管理者アカウントの値と一致している必要があります。 使用するアカウントをプレビューするには、LCS でターゲット サンドボックス環境の 環境詳細 ページに移動します。 環境が最初に展開されたときに 環境管理者 フィールドで選択された値は、トランザクション データベースのシステム管理者に更新されます。 環境のテナントが環境管理者のテナントになります。

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

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

重要

Commerce headquarters データベース (以前の AOS データベース) を移行する際、関連付けられている Commerce Scale Units (CSUs) は移動されません。 場合によっては、使用する機能に応じて、CSU の再配置が必要になる場合があります。 次に、データを CSU に完全に同期して、再配置を行う必要があります。 データの不一致が残っている場合は、最終的なアクションとして CSU を削除し、新しい CSU を置き換え、新しい CSU に対するデータの完全同期を実行することです。

環境固有のレコードの中には、自動的なデータベース移動操作に含められないものがあり、その手順を追加する必要があります。 次のような役割があります。

  • コマース セルフサービス インストーラー参照。
  • Commerce Scale Unit チャネル データベースのコンフィギュレーション レコード。

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

Commerce Scale Unit の初期化

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

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

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

重要

環境の再プロビジョニング手順は、データベース移動操作の一部として完全に自動化されており、これ以上手動で実行する必要はありません。 環境再ビジョニング ツールは引き続きアセット・ライブラリで利用可能ですが、Commerce バージョン 10.0.37 以前を実行している開発環境にデータベースを復元する場合にのみ必要です。 Commerce Version 10.0.38 以降を実行している開発環境では、シールされた CSUを 使用する環境なので、環境の再プロビジョニング ツールは適用されません。

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

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

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

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

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

既知の問題

使用可能な復元ポイントのチェーンの中断

頻繁に使用するいくつかのアクションは、以前に使用したデータベースと同じ復元ポイント履歴を持たない新しいデータベースを作成します。 このアクションには、ポイント イン タイム復元、データベースの更新、データベースのインポート、運用環境からサンドボックス環境へのポイント イン タイム復元などが含まれます。 さらに、データベースの更新時に環境に適用するソフトウェア展開可能なパッケージが失敗し、LCS のロールバック機能を使用する場合、ロールバック機能はデータベースのポイント イン タイム復元を実行し、その復元は新しいデータベースも作成します。

新しいデータベースには、復元ポイント履歴はありませんが、その時点から新しい復元ポイントを取得し始めます。 前述のアクションのいずれかを実行した後、同じ復元日時を使用して再度実行することはできません。

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

環境でプラットフォーム更新 20 以前を実行している場合は、データベース復元の処理を実行することはできません。 詳細については、ソフトウェアのライフサイクル ポリシーとクラウド リリースで現在サポートされているプラットフォーム更新の一覧を参照してください。