Dibaca dalam bahasa Inggeris Edit

Kongsi melalui

Database movement operations home page

  • Artikel

Database movement operations are a suite of self-service actions that can be used as part of Data Application Lifecycle Management (also referred to as DataALM). These actions provide structured processes for common implementation scenarios such as golden configuration promotion, debugging/diagnostics, destructive testing, and general refresh for training purposes.

In this article, you learn how to use database movement operations to perform refresh, export, import, and various flavors of point-in-time restore.

Database movement scenarios and quick start guides

The following table shows the various scenarios that are supported and a link to a quick start guide for each scenario.

Source environment Target environment Quick start guide Available via API Tutorials
Production Sandbox Refresh database Create refresh Refresh for training purposes
Debug a copy of the production database
Sandbox Production Refresh database Not supported Golden configuration promotion
Sandbox Sandbox Refresh database Create refresh Refresh for training purposes
Sandbox DevTest Export a database Create export Export a copy of the standard user acceptance testing (UAT) database
DevTest Sandbox Import a database Not supported Golden configuration promotion
Production DevTest Supported in Power Platform admin center Supported via Power Platform API Tutorial - Copy a Lifecycle Services Environment to a unified environment (preview)
Sandbox point-in-time Sandbox Point-in-time restore (PITR) Not supported Destructive testing
Production point-in-time Sandbox Point-in-time restore of the production database to a sandbox environment Applicable scenario for production to sandbox restore Not supported Destructive testing
Production point-in-time Production Point-in-time restore (PITR) Applicable scenario for production restore Not supported Not applicable

Penting

Database movement operations are very lengthy operations. The amount of time these operations take varies by data volume, schema complexity, and whether the target of the operation is a flat file, like a .bacpac file in the case of the export operation. In general, these operations can take up to 24 hours to complete, and during the operation there is no way to cancel. In addition, if the target of the operation is an environment like in the production to sandbox scenario, the sandbox environment will go offline at an undetermined time, when the database copy operation has completed, but before the database synchronization steps begin. This will happen with no warning to end users in the environment. As result, it is best to schedule these types of operations during non-business hours.

Database Movement API

The Database Movement application programming interface (API) lets you integrate several of the previously mentioned database movement operations into your overall ALM process. In addition, by using the API together with your preferred scheduling engine, you can build recurrence into the process, so that it runs daily or on demand.

For more information about the Database Movement API, see the following topics: