I’ve been dreaming of this kind of feature: just because most of the ODA configurations now include Disaster Recovery capabilities, through Data Guard or Dbvisit standy. If Dbvisit will obviously never be integrated to odacli, the lack of Data Guard features is now solved by the very latest 19.8 ODA software appliance kit.<\/p>\n
Those who have been using ODA and Data Guard for a while know that ODA was not aware of a Data Guard configuration. With odacli, you can create databases, mostly primaries, and you can also create an instance, which is a database without any file, just to get the database item in the reposity and a started instance. Creating a standby was done with the standard tools, RMAN for database duplication, and eventually system commands to edit and copy the pfile to standby server. Configuring Data Guard was done with the Data Guard broker dgmgrl, nothing specific to ODA. Lots of steps were also needed, the standby logs creation, the unique naming of the databases, the configuration of standby_file_managemement, … Actually quite a lot of operations not so easy to fully automate.<\/p>\n
As this 19.8 is brand new, I picked up this from the documentation. Quite impatient to test these features as soon as possible.<\/p>\n
First, odacli is now aware of Data Guard and can manage a Data Guard configuration. A Data Guard configuration is now an object in the repository, you can manage multiple Data Guard configurations, linking primary and standby databases together. You can also do the SWITCHOVER and FAILOVER operations with odacli. The use of dgmgrl doesn’t seem mandatory here.<\/p>\n
The goal of odacli’s Data Guard integration is to simplify everything, as this is the purpose of an appliance.<\/p>\n
For using Data Guard on ODA you will need:
\n– at least 2 ODAs
\n– at least 2 different sites (reliable Disaster Recovery absolutely requires different sites)
\n– similar ODA configuration: mix of lite and HA ODAs is not supported
\n– Enterprise Edition on your ODAs: Data Guard is embedded with Enterprise Edition and do not exist in Standard Edition 2
\n– Twice the database size in space (never forget that)
\n– similar database configuration (shape and settings) and storage configuration. Mix of ASM and ACFS is not supported. Actually, these are best practices.
\n– All ODAs deployed or upgraded to 19.8 or later but with the same version
\n– OS customizations, if exist, should be the same on all the ODAs
\n– ODA backup configuration should exist, to OCI Object Storage or to NFS server (odacli create-backupconfig and odacli modify-database)
\n– your primary database should already exist<\/p>\n
First, create a backup on the primary with: From now, you have 2 nearly identical databases. You can now create the Data Guard configuration with: You’ll also have to manage the TrustStore passwords, as described in the documentation. I don’t know if it’s new but never have to manage it before.<\/p>\n To have an overview of all your Data Guard configurations, you can use:<\/p>\n As you can imagine, each Data Guard configuration is identified by an id, and with this id you can have detailed view of the configuration:<\/p>\n odacli is even able to do the switchover and failover operations you were doing with dgmgrl before: With ODA, you can quite simply migrate a database moving from one home to another. This feature now supports a Data Guard configuration, but you will have to manually disable transport and apply during migration with dgmgrl. It’s quite nice to be able to keep the configuration and not having the need to rebuild it in case of database migration.<\/p>\n If you need to remove a Data Guard configuration, you can do that through odacli: If you want to use a dedicated network for Data Guard, this is also possible with the network management option of odacli.<\/p>\n The Data Guard management was missing on ODA, and this new version seems to bring nearly all the features. Let’s try it on the next projects!<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction I’ve been dreaming of this kind of feature: just because most of the ODA configurations now include Disaster Recovery capabilities, through Data Guard or Dbvisit standy. If Dbvisit will obviously never be integrated to odacli, the lack of Data Guard features is now solved by the very latest 19.8 ODA software appliance kit. How […]<\/p>\n","protected":false},"author":45,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229,198,199,42,59],"tags":[2042,221,999,2043,2044,79,1327,1330,1331,1332,1697,1698,1699],"type_dbi":[],"class_list":["post-14447","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","category-database-management","category-hardware-storage","category-operating-systems","category-oracle","tag-19-8","tag-data-guard","tag-dataguard","tag-dgmgrl","tag-manage-dataguard-odacli","tag-oda","tag-odacli","tag-x7-2ha","tag-x7-2m","tag-x7-2s","tag-x8-2ha","tag-x8-2m","tag-x8-2s"],"acf":[],"yoast_head":"\n
\nodacli create-backup<\/code>
\nOnce done, save the backup report to a text file with:
\nodacli describe-backupreport<\/code>
\nCopy this backup report to standby ODA and do the restore with:
\nodacli irestore-database<\/code>
\nYou will need to restore this database with the STANDBY type (will basically flag the controlfile to standby database).<\/p>\n
\nodacli configure-dataguard<\/code> from the primary ODA. This command will prompt you for various parameters, like the standby ODA IP address, the name of the Data Guard configuration you want, the network to use for Data Guard, the transport type, the listener ports, the protection mode, aso. What’s interesting here is that you can also provide a json file with all these parameters, the same way you do when you deploy the appliance. Far more convenient, and much faster:
\nodacli configure-dataguard -r my_DG_config.json<\/code><\/p>\nHow to manage Data Guard through odacli?<\/h2>\n
odacli list-dataguardstatus<\/code><\/p>\nodacli describe-dataguardstatus -i xxx<\/code><\/p>\n
\n
\nodacli switchover-dataguard -i xxx
\nodacli failover-dataguard -i xxx
\n<\/code>
\nIn case of a failover, you probably know that the reinstate of the old primary is needed (because of its current SCN probably being greater than the SCN on standby when the failover was done), you can do the reinstate with odacli too:<\/p>\nodacli reinstate-dataguard -i xxx<\/code><\/p>\nOther features<\/h2>\n
odacli deconfigure-dataguard -i xxx<\/code><\/p>\nConclusion<\/h2>\n