Using ZDM to migrate to ADB
Using ZDM to migrate to ADB

Migration to oracle Autonomous Database (ADB) is one of the hot topics today as many DBAs are going through this process currently or preparing for such process MIgration to ADB can be done using different tools and techniques but there is one tool That I found it to be the best and most automated way to migrate to ADB, it's the ZDM And in this article I’ll quickly review ZDM and the main requirements and steps  that are needed to use it to perform Online migration to ADB. This is not a detailed step by step guide but rather a high level overview.  


What is ZDM?  

Zero Downtime Migration (ZDM) is the Oracle Maximum Availability Architecture (MAA)-recommended solution to migrate Oracle Databases to the Oracle Cloud.   The Source Database to be migrated can be on-premises or deployed Oracle Cloud Infrastructure. The Target Database deployment can be in a Database Cloud Service on Oracle Cloud Infrastructure (OCI) Virtual Machine, Exadata Cloud Service (ExaData CS), Exadata Cloud at Customer (ExaData CC), or Autonomous Database. ZDM automates the entire migration process ZDM takes advantage of Oracle Database-integrated high availability (HA) technologies such as Oracle Data Guard and GoldenGate and follows all MAA best practices that ensure no significant downtime of production environments. Oracle ZDM supports both Physical and Logical Migration workflows. So basically ZDM serves as an automation tool that uses existing oracle technologies to perform the migration with minimum effort required from the DBAs.  


Logical not physical   

When you migrate to ADB there are some conditions and prerequisites that need to be met Things like database upgrade, restriction on some object types and features all these lead to A very clear conclusion which is that you can not perform a physical migration to ADB so it  Has to be a logical migration and ZDM supports many migration modes and scenarios including Online and Offline logical migrations.  


Offline Vs Online  

We have the choice between offline and online migration when migrating to ADB, and DBAs will Decide which is the best for the business needs.

In case of Offline logical migration the workflow will be something like this:

  1. Configuration Validation: ZDM will run checks to make sure everything is in place before starting the migration process
  1. ZDM will connect to the backup location: Backup location when using offline mode can be Oracle Object Storage (recommended) or NFS.
  2. Export: ZDM will use data pump to export from the source to the backup location.
  3. Import: ZDM will import the data  pump files from the backup location to the target database.
  4. .Instantiation: ZDM will start the target database.
  5. Switchover: ZDM will switch over to the target database

ofline

The online logical migration the workflow is different because now we have GoldenGate hub so will go like this:
  1. Connection establishment: ZDM Connects to the source, the target and the Backup location. 
  2. GoldenGate Hub start: ZDM will Configures GoldenGate and start capturing source transactions
  3. Export: ZDM will export from source  via Data Pump to backup location.
  4. Import: ZDM will import the data  pump files from the backup location to the target database.
  5. Applying changes: ZDM  Will Configure GoldenGate and Start Applying changes on the target database.
  6. Switchover: ZDM will switch over to the target database.


online



Requirements and configurations  


ZDM Host:

  • ZDM must be installed on a dedicated separate host, it can be on premise or a VM on OCI regardless, this host must meet the following  requirements:
  • Linux host running on Oracle 7 
  • 100 GB of free storage space•
  • A “zdmgroup” and a “zdmuseras” part of this group.
  • Also some packages must be available on this host:
            Glibc-devel,expect,unzip,libaio and  oraclelinux-developer-release-el7
  • All host names and IP addresses are defined and accessible.
  • ZDM supports Oracle Database versions 11.2.0.4, 12.1.0.2, 12.2.0.1, 18c, 19c & 21c as source. And while physical migration workflow requires the Source and Target Databases to be in the same database release,  ZDM supports database cross-version migration, or in other words an in-flight upgrade while migrating.when using logical migration workflow and with an autonomous database as a target we need a Logical Migration workflow.
  • ZDM connects via SSH to the Source Database servers; So you need to create an SSH key pair for the zdmuser.
  • The OCI user requires an Authentication Token, which can be created from the user’s detail page.
  • Install the Oracle Cloud Infrastructure command-line tool (OCI CLI).
  • ZDM uses an API Signing Public Key to call REST APIs. so you need to create the API Keys
  • ZDM uses a response file which is customizable by the DBA., and there are many parameters for the logical migration that allows you to configure the migration according to the use case. You will need to prepare the response file before starting the migration.



  Source Database requirements:

  • The Source Database must be running in ARCHIVELOG mode.
  • The Source Database must use a server parameter file (SPFILE).
  • The system time of the ZDM host and source database server should be in sync with the target Database.
  • If the Source is Oracle Database 11.2, apply the mandatory 11.2.0.4 RDBMS patches on the Source Database.
  • If the source is Oracle Database 12.1.0.2 or a later release, apply mandatory RDBMS patches on the Source Database.
  • FORCE LOGGING must be enabled.
  • The initialization parameter ENABLE_GOLDENGATE_REPLICATION must be enabled.
  • You will also need to enable database minimal supplemental logging.
  • You need to create a GoldenGate administration user and grant it all required permissions (if not already existent).
  • Make sure the needed ports are open (22, 1521, 2484 or a DB SCAN listener port, 443).


Target Database Requirements:

  • Make sure you choose the right storage size for your target database.
  • While cross-version migration is supported with logical migration but you can not downgrade, in other words the target must be the same version of the source or a higher one but not older or lesser version.
  • Because the ADB is  configured to use SSL/TLS, you must store the wallet containing the TLS authentication certificates in the correct location on the GoldenGate hub VM.
  • Make sure the needed ports are open (22, 1521, 2484 or a DB SCAN listener port, 443)
  • The Autonomous Database has a pre-created GoldenGate user named ggadmin, it is required that this user is unlocked and its locked by default so you need to unlock it.
  • the character set on the Source and Target Database must be the same.


The GoldenGate Hub:
  • You will get the golden gate hub image from the marketplace and you don't need a license for this hub and you will pay only for the VM that will host the GG Hub.
  • Your security list on the subnet that hosts the target database must have ingress rules for Port 443 and Port 1521.
  • During the installation of GG Hub make sure to choose the VCN and the Subnet used for the migration and Assign Public IP for your hub in order to be able access it from the ZDM host.


Object Storage Requirements (Backup Location):
  • You need to create a bucket specially for the migration process and its highly recommended that you use a new empty bucket and also don't forget to save all the details about the bucket because you will need it later on.


The migration  


After you perform all the needed steps and preparations you can startt the migration by issuing one command from the ZDM host, the command in the case of online migration to ADB should look like this:

zdmuser> $ZDM_HOME/bin/zdmcli migrate database -rsp file_path -sourcedb source_db_unique_name_value -sourcenode host -srcauth zdmauth -srcarg1 user:username -srcarg2 identity_file:ssh_key_path -srcarg3 sudo_location:sudo_path -eval [-advisor [-ignoreadvisor] | -skipadvisor]]  


The ‘eval’ parameter will not perform the actual migration but rather will check everything just like a real migration but without migrating the data to make sure everything is in place. This is a great option that will allow you to make sure one final time that the migration will succeed and run smoothly. To start the migration remove the eval option. You can also notice that you can pass arguments to the source and target database.  


Conclusion:

We are living in the age of cloud migration, and migrating the databases is a very critical job that can represent a challenge to any DBA. Using ZDM can really streamline the migration process especially when migrating to ADB It's a FREE tool that is very well documented and supported by oracle, and it offers a wide range of options and parameters that allows any user to customize the migration process as they need.