データベースの更新

サンドボックス ユーザー受け入れテスト (UAT) 環境に対するデータベースの更新の実行に、Microsoft Dynamics Lifecycle Services (LCS) を使用することができます。 データベースの更新対象となるサンド ボックス UAT 環境に、運用環境のトランザクションおよび財務報告データベースをコピーできます。 別のサンドボックス環境を使用する場合は、その環境から対象のサンドボックス UAT 環境にデータベースをコピーすることもできます。

重要

営業時間中またはピーク時に運用データをコピーすると、生産システムに影響を与える可能性があります。 データベースの更新は、オフピーク時に行い、一度に 1 つの更新操作のみを制限することを強くお勧めします。

運用レポートを目的としてサンドボックス環境に運用データをコピーすることはできません。

データベースのセルフ サービスエ更新

人手または手動のプロセスに依存しないでお客様にデータ アプリケーション ライフサイクル管理 (DataALM とも呼ばれます) 機能を提供することを目標として、Lifecycle Services チームは自動化されたデータベースの更新アクションを導入しました。 このプロセスの概要を以下に示します。

1. ターゲット サンドボックスの 環境の詳細 ページで、メンテナンス>データベースの移動 メニューのオプションをクリックします。
2. データベースの選択 オプションを選択し、ソース環境を選択します。
3. 警告に注意し、ソース環境からコピーされていないデータの要素の一覧を確認します。
4. 更新操作がすぐに開始されます。

更新操作が失敗しました

障害が発生した場合、更新操作は自動的にロールバックされます。 ターゲットのサンドボックス環境は、更新が開始される前の状態に復元されます。 Azure SQL ポイントインタイム復元機能により、データベースを復元できるようになります。 新しく更新されたデータとのデータベースの同期を、対象となるサンドボックスにあるカスタマイズで完了できない場合に、これがよく必要になります。

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

更新中にはコピーされないデータ要素

このセクションの情報は、データベースの更新操作中にターゲット環境にコピーされないデータベースの特定の要素を一覧表示します。

サンドボックス環境またはサンドボックスから別のサンドボックス環境に運用環境を更新する場合

• LogisticsElectronicAddress テーブル内の電子メール アドレス。
• SysEmailParameters テーブルの SMTP 中継サーバー。
• PrintMgmtSettings と PrintMgmtDocInstance テーブルの印刷管理設定。
• 管理者以外のすべてのユーザーは 無効 のステータスに設定されます。
• DIMENSIONHASHMESSAGELOG、DIMENSIONDATAINTEGRITYLOG、DIMENSIONVALUERENAMEAUDIT、DIMENSIONVALUEDELETEAUDIT、DIMENSIONATTRIBUTEVALUECOMBINATIONSTATUS、DIMENSIONATTRIBUTEVALUEGROUPSTATUS、DIMENSIONDATAENTITYSFKCACHE、DIMENSIONREFERENCES などの分析コード ログおよびキャッシュ ステータス テーブル。

サンドボックス環境から運用環境に更新する場合

これは、ゴールデン構成プロモーション とも呼ばれます。

• バッチ ジョブ履歴は、BatchJobHistory、BatchHistory、および BatchConstraintHistory テーブルに格納されています。

これらの要素は、すべてのデータベースの更新操作で削除されます

• SysServerConfig、SysServerSessions、SysCorpNetPrinters、SysClientSessions、BatchServerConfig、および BatchServerGroup テーブル内の環境固有のレコード。
• Azure Blob Storage に保存されているすべてのファイル。 これには、ドキュメントの添付ファイル (DocuValue テーブルおよび DocuDeletedValue テーブルから)、およびカスタム Microsoft Office テンプレート (DocuTemplate テーブルから) が含まれます。
• すべてのバッチ ジョブは、 保留 状態に設定されます。
• すべてのユーザーのパーティション値は "初期" パーティション レコード ID にリセットされます。
• 別のデータベース サーバーでは解読できないため、すべての Microsoft 暗号化フィールドはクリアされます。 次の例は、sysemailsmtppasswordテーブルの パスワード フィールドです。
• メンテナンス モード 設定は、ソースで有効になっていた場合でも無効になります。
• 二重書き込みの構成。 この操作に成功した後にターゲット環境に新しいリンクを設定するには、「統合の有効化 」を参照 Power Platform してください。
• すべての エンティティの変更追跡 は無効になります。
• ビジネス イベントとデータ イベントのサービス エンドポイントが削除されます。

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

環境管理者

対象となる環境のシステム管理者アカウント ('Admin' の UserId) は、ターゲットの web.config file ファイルにある値にリセットされます。 これは、Lifecycle Services の管理者と同じ値になります。 これがどのアカウントになるかをプレビューするには、LCS でターゲット サンドボックスの 環境の詳細 ページにアクセスします。 環境が最初に展開されたときに選択された 環境管理者 フィールドの値は、トランザクション データベース内のシステム管理者となるように更新されます。 これは、環境のテナントが環境管理者のテナントであることも意味します。

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

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

データベース更新の条件

データベース更新の操作の要件および条件の一覧を次に示します:

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

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

重要

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) デバイスのライセンス認証 を参照してください。

既知の問題

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

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

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

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

ソース環境とターゲット環境間での財務報告の互換性のないバージョン

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

実行対象と実行元の環境でインストールしたバージョンを確認するには、 詳細バージョン情報を表示 のリンクを確認します。これは 環境の詳細 ページにあります。

MRApplicationService を検索し、対象となる環境が実行元の環境と同等かそれ以上のバージョンあることを確認してください。

バージョン 8.1 またはそれ以降を使用している顧客:

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

バージョン 8.0 またはそれ以前を使用している顧客:

1. 実行元環境の環境履歴を確認します。 具体的には、「プラットフォームおよびアプリケーションのバイナリ パッケージ」のいずれかが実行元の環境に展開されていることを確認します。対象の環境ではありませんのでご注意ください。
2. このバイナリパッケージをUAT環境に適用します。
3. エラーが解決されたことを確認してください。

ソース環境とターゲット環境間での互換性のないアプリケーション バージョン

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

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

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