In this final (for now, at least) blog post I will show the pro tips that might come in handy. It is a little mix and match of all my notes that didn’t make it into the previous blog posts, but are still too good to go.
Pro Tip 1: Converting To Snapshot Standby For Testing
This is a really cool feature of ZDM (or in fact any migration that uses a standby database). Once the standby database has been built in OCI and while you are waiting to do the switch-over, you can use the database in OCI for testing. So you can do realistic testing on the database you are about to switch over to. To convert the standby database to a snapshot standby database:
alter database recover managed standby database cancel; shutdown immediate startup mount alter database convert to snapshot standby; alter database open;
Now, the database is opened in READ WRITE mode and you can use it for testing. Don’t worry, the database is fully protected by flashback logs so you can always rewind any changes made, and resync with the primary database. To convert back to a physical standby database:
shutdown immediate startup mount alter database convert to physical standby; shutdown immediate startup alter database recover managed standby database disconnect from session;
You can even do this multiple times if you want several test runs on your OCI database. If you want you can read more about the different standby databases or snapshot standby databases in particular.
Pro Tip 2: Monitoring Queries
When you have created the standby database in OCI and are waiting for the switch-over you can use these commands for monitoring. On the source/primary database:
SELECT host_name, instance_name, db_unique_name, status, database_role, open_mode FROM v$database, v$instance; SELECT thread#, max(sequence#) FROM v$archived_log GROUP BY thread#;
On the target/standby database:
SELECT host_name, instance_name, db_unique_name, status, database_role, open_mode FROM v$database, v$instance; SELECT thread#, max(sequence#) FROM v$archived_log WHERE applied='YES' GROUP BY thread#; --MRP process should be 'APPLYING_LOG' SELECT process, status, sequence# FROM v$managed_standby; SELECT * FROM v$archive_gap;
Pro Tip 3: Log Files
If something goes south where can you find the log files? On the ZDM service host:
On the source and target hosts you can also find additional log files containg all the commands that are executed by ZDM:
- /tmp/zdm-[some number]/zdm/log
Pro Tip 4: Troubleshooting
When you a troubleshooting it is sometimes useful to get rid of all the log files and have ZDM start all over. Some of the log files get really big and are a hard to read, so I usually stop the ZDM service, delete all the log files, and restart ZDM and my troubleshooting. But only do this if there are no other jobs running than the one you are troubleshooting:
[zdmuser@zdm]$ $ZDM_HOME/bin/zdmservice stop [zdmuser@zdm]$ rm $ZDM_BASE/crsdata/*/rhp/rhpserver.log* [zdmuser@zdm]$ rm $ZDM_BASE/chkbase/scheduled/* [zdmuser@zdm]$ $ZDM_HOME/bin/zdmservice start
There is also a chapter about troubleshooting in the documentation but it more or less says the same.
Pro Tip 5: Aborting A Job
Some times it is useful to completely restart a migration. If a database migration is already registered in ZDM, you are not allowed to specify another migration job. First, you have to abort the existing job, before you can enter a new migration job.
[zdmuser@zdm]$ $ZDM_HOME/bin/zdmcli abort job -jobid n
Now, you can use
zdmcli migrate database command again. By the way, the
abort job command is missing from the CLI reference but it is a valid, and fully supported command.
Pro Tip 6: Show All Phases
A ZDM migration is split into phases, and you can have ZDM pause after each of the phases. The documentation has a list of all phases but you can also get it directly from the ZDM tool itself for a specific migration job:
[zdmuser@zdm]$ $ZDM_HOME/bin/zdmcli migrate database \ -rsp ~/migrate.rsp ... \ ... \ ... \ -listphases
Pro Tip 7: Adding Custom Scripts
You can add your own custom scripts to run before or after a phase in the migration job. You can use the
-listphases command (described above) to get a list of all the phases. Then decide whether your script should run before or after that phase. This is called an action plug-in. You can bundle those together in a template to make it easier to re-use. If this is something you need, you should dive into the documentation.
Pro Tip 8: Remember To Patch On-Premises Oracle Home
If your OCI Oracle Home is running on a newer Release Update (i.e. higher patch level) then you have to patch your on-premises Oracle Home after the switch-over – and before you execute
datapatch. The two patch levels should be identical after the switch-over.
Release Updates are always Standby-First Installable. That means that it is allowed to have a standby database running on an Oracle Home of newer patch level – but not older one. This concept is widely used to reduce downtime during database patching and it is basically the same concept that applies for ZDM.
Pro Tip 9: Fallback To On-Premises Database
It is possible to configure ZDM to keep the on-premises database after the switch-over. It will then become a physical standby database. If something happens with the OCI database, you can do an additional switch-over and run off the original on-premises source database. This is a very nice and handy fallback method. If you want to read about it that procedure I suggest that you visit the MOS note MAA Practices for Cloud Migration Using ZDM (Doc ID 2562063.1). Be aware, falling back to the source database requires a license for Advanced Security Option. The target database in OCI is encryted using TDE Tablespace Encryption. You get that as part of any OCI DB System offering. Once the OCI database is the primary database it will generate encrypted redo – and if the source database has to apply that – it must have a license for the Advanced Security Option.
Pro Tip 10: Convert From Single Instance To RAC
A useful feature of ZDM is that it can convert a single instance database to a RAC database in OCI. And it is super simple to do that. The only thing you have to do is to create the target placeholder database as a RAC database. ZDM will detect that and take care of the rest.
Finally, let me mention that if the source database is RAC One Node or RAC, then the target database must be a RAC database. Be sure to create the target placeholder database as RAC.