by Porus Homi Havewala
Using Oracle Enterprise Manager Cloud Control 12c's Oracle Data Guard setup and management capabilities to control downtime and simplify disaster recovery.
Oracle Enterprise Manager 12c
Database and server downtime can either be meticulously planned or totally unplanned! So far as business dollars are concerned, any type of downtime is expensive. However, planned downtime can be controlled and reduced by Database technology features such as rolling upgrades, or out of place patching. What is costlier to business is unplanned downtime - since employees are idle during this time and corporate web sites are unreachable, resulting in revenue loss as well as prestige loss.
High Availability (HA) is the main strategy that has been used by companies to protect themselves against server failures. This technology is often implemented in the form of active-passive clusters - such has been the case for many years. In an active-passive cluster, a storage unit known as a LUN (Logical Unit Number) is shared between two servers but only accessed by one primary server at a time. The database files are placed on this LUN, and the Oracle instance starts in memory on the primary server.
When the primary server goes down, the LUN is switched over to the secondary server, and the instance is restarted in the memory of that server. This active-passive technology was the HA norm in the corporate computer centers for many years. The only complaint was that the cluster could automatically and unexpectedly switch over to the passive server, even on very trivial grounds - such as slow network access to the active server, or if the database were shut down for maintenance by a naive DBA. In the latter case, the cluster monitoring software had to be disabled first before any maintenance work was done on the database.
Oracle performed early experiments with active-active clusters. In this case a single database had instances on multiple servers, and all accessed the same database storage. The first versions were known as Oracle Parallel Server (OPS), however at that time the clustering technology was primitive and used the shared storage itself as the method to transfer blocks from node to node. This had performance limitations and was very complex to set up, and consequently implementations of OPS were rare, and DBAs who knew OPS could command a large pay packet.
The picture was decidedly and vastly improved when Oracle developed the new version of active-active clusters, and called it Oracle Real Application Clusters (RAC) beginning with Oracle 9i. This introduced the latest Oracle technology of Cache Fusion - where, in a technical breakthrough, the database used the memory (cache) of the nodes for the first time to transfer requested blocks across the interconnect.
The caches of the instances on the cluster nodes were fused together, in a manner of speaking. This technique improved cross-instance block-access performance dramatically, and made Oracle Database 9i Real Application Clusters (RAC) a very practical and scalable alternative to the active-passive technology.
Oracle RAC obviously afforded protection against server failures - if one of the nodes died, the database still stayed up since the other nodes kept on working. So this became a very valid High Availability solution.
But, in addition, the other great advantage was that an optimum use of all the servers in the cluster could be achieved - via intelligent load balancing. Because the load is shared across all nodes, the RAC cluster can scale out horizontally - something that is impossible for an active-passive cluster to achieve, unless the application and database are broken up into pieces.
But how long can you continue to slice and dice an application and database? There is no need to do this in the RAC configuration so far as the majority of applications are concerned. And you can start with a small number of RAC nodes, rather than initially deploy a large server to accommodate future growth
In late 2009, a new HA technology was introduced by Oracle - Oracle RAC One Node in Oracle 11g Release 2. This was RAC running on one node in a cluster with failover protection, the same as the active-passive scenario. The difference is that RAC One Node can easily be upgraded online to a full active-active RAC cluster. This is not possible with the other third-party active-passive clusters.
Consider the situation of the entire computer site going down - as in the case of an actual disaster, either natural or man-made. In such an event, HA technology will not be able to cope. All the active-passive or active-active RAC servers in the one site hit by the disaster would be down! We need a genuine Disaster Recovery (DR) solution, with servers ready to take over at a totally different site - distant enough not to be effected by the disaster at the primary site.
The concept of Disaster Recovery was first applied to Oracle databases by the Oracle Consulting team, in response to client requests. A manual standby database was the main instrument - this being in the days before Oracle 7.3. The technique was very primitive, but laid the groundwork for Oracle's ongoing concept of the Standby database. The steps performed were basically as follows:
However, there were issues in the process. Sometimes there arose gaps in log application - in case the archive logs were not transported to the standby server due to network failure. Or, even if transported, they were not applied on the standby due to some reason such as unauthorized deletion, or maybe hard disk corruption. The resulting gaps had to be resolved manually in all these cases.
Amazingly, there are some companies that even today deploy their standby databases using this manual scripted method. This is because they use the Oracle Database Server Standard Edition (SE) Database software - and only the Oracle Database Server Enterprise Edition (EE) allows the use of the latter-day advanced standby technology from Oracle. This is one of the many advantages of using EE instead of SE.
Oracle's official support for standby database mechanisms was first started in version 7.3 of the database software. As each version was announced, this support was developed rather considerably. In Oracle 8.1.7, the logs started to be transported between the primary and the standby via the mechanism of Oracle SqlNet 8, replacing the use of the ftp/scp operating system utilities. The other new feature introduced at that time was Managed Database Recovery, which automatically applied the transferred archive logs on the standby.
As a result of these new features, some of the manual scripts used previously in the standby setup were now unnecessary. This was a good first step to automation.
But the big thing in Version 8.1.7 was the new Oracle "Data Guard" technology - a culmination and amalgamation of what went before. You had to download Oracle Data Guard separately from the Oracle Technical Network (OTN), and then unzip it in a subdirectory under your Oracle Home.
Oracle Data Guard at that time was a collection of Unix shell scripts, such as dgdeploy.sh which deployed the Data Guard configuration of the primary and standby databases. It also had a command line interface, Data Guard Control (dgdctl) which allowed you to perform a switchover or a failover to the standby database quite easily.
In Oracle 9i, Data Guard was promoted to become part of the Oracle kernel, resulting in better performance and memory management. A new Oracle background process DMON was now started specifically for the Data Guard broker, along with all the other background processes.
Oracle, in Versions 10g and 11g, continued the enhancements to the Data Guard technology. But the setup, configuration and maintenance of Data Guard increased correspondingly in complexity, and human error became more likely in the entire process - especially if you had multiple primary databases and their corresponding standbys.
With the increasing complexity from Oracle Database 9i onwards, a powerful tool was needed which would drive the setup and configuration of Data Guard. Oracle created just the right tool - Oracle Enterprise Manager 9i, with a wizard that allowed the setup of Data Guard standbys directly from the Enterprise Manager console. You could also perform a switchover or failover to the standby database from Enterprise Manager 9i itself, instead of doing it manually using the Data Guard Command line interface.
The next version of Enterprise Manager that handled standby databases was Grid Control 10g. This further enhanced the setup process of the Data Guard configuration, and also included a monitoring interface for the entire configuration. Grid Control 11g and the latest Cloud Control 12c handle standby database creation and monitoring equally well, and in addition new features such as the Snapshot Standby database are also covered.
In general, Enterprise Manager, with its new architecture and interface, has already proven to be a great aid to the DBA. Cloud Control 12c excels at streamlining and automating many daily tasks of the DBA - tasks as varied as performance diagnosis, tuning, scheduling database and OS scripts, setting up and scheduling database RMAN backups, besides delivering and applying database patches, and configuration management and monitoring of the application, database, OS, and the server. And of course, you can also easily set up Data Guard configurations, manage the configurations, switchover or failover the database, and monitor the primary and standby databases using Cloud Control 12c - an ideal way to set up disaster recovery capabilities in your company.
One marvelous thing is that Oracle 9i, 10g, 11g as well as the recently released Oracle Database 12c are all included in the Data Guard setup and management capabilities of Enterprise Manager Cloud Control 12c. Typically a large company would have existing versions of these databases. The wizard for creating the standby database is a step-by-step, guided, error-free procedure to set up Oracle Data Guard. Using this procedure, you can set up the standby database on any server in your corporate space - provided the Cloud Control 12c agent is already installed and running on that server prior to the actual setup.
If a large company standardizes on the use of Enterprise Manager Cloud Control 12c, it would be possible to set up disaster recovery very painlessly and seamlessly, for Oracle databases in the entire corporate. A lot of time can be saved, customized scripts can be eliminated, and human error greatly reduced.
Note that the base installation of Enterprise Manager Cloud Control 12c includes several features free of charge with the purchase of any Oracle software license or Support contract. Happily, configuring and viewing standby databases using Enterprise Manager is covered under the Base Database Management Features, as explained in the Oracle Enterprise Manager Licensing Information guide.
On every host that you wish to monitor and manage via Enterprise Manager Cloud Control 12c, the 12c Agent must be installed and running. This is a prerequisite since the agent is used to communicate between the targets on the host, and the Oracle Management Service (OMS).
Presuming that the Primary database is already managed by Cloud Control 12c, you now turn to the server that is to be used as the Standby. As per Oracle Data Guard requirements, the Primary and Standby should have the same Operating System, but the OS patchset release may be different.
The requirement for the Oracle software is stricter. The Oracle software should be the same version - including the Oracle patchset release.
The first thing to do on this standby server is to install the Enterprise Manager Cloud Control 12c agent, using a separate Agent Home located on the target server. Once the EM Agent starts communicating with the central OMS, all information about the standby server is available on the central Enterprise Manager site.
After this Agent installation is complete, the standby server now has the Agent Home, but there is no Oracle Home since the Oracle database software has not been installed on this server.
You can manually install the Oracle Enterprise Edition (EE) software from a CD or use the downloaded installation files from the Oracle Technology Network (OTN). Make sure you do not install the Standard Edition (SE), since the use of Data Guard is not allowed with the Standard Edition.
Another faster and better way to do this is to use the Provisioning capabilities of Enterprise Manager Cloud Control 12c. This is accessed via Enterprise..Provisioning and Patching..Database Provisioning from the Enterprise Manager Console menu. Then, select the Deployment Procedure "Provision Oracle Database". This allows you to deploy the Oracle Software from Enterprise Manager itself, from a pre-stored Gold Copy known as a Profile in the Software Library. This capability requires the license for the Enterprise Manager Database Lifecycle Management Pack (DBLM).
After the Deployment Procedure has completed, you have a new Oracle Home on the Standby server. It is now possible to proceed with the creation of the Standby database.
Go to Targets..Databases on the Enterprise Manager Cloud Control 12c console, and select the PROD production database in the list of databases that appears.
This will be the Primary database in the Data Guard Configuration.
When the PROD database Home Page appears, select Availability..Add Standby Database from the database target menu as seen below.
If you have not logged in to the PROD database previously, you will have to do so at this point - the login screen appears.
Connect with SYSDBA privileges. This is required for setting up and monitoring Oracle Data Guard in all databases upto version 11g. In the new Oracle Database 12c, there is now a different privilege known as SYSDG. This privilege allows a user to perform Data Guard operations. This is a much sought-after enhancement that has finally been realized in Oracle Database 12c, and means that the management of Data Guard can be achieved without sysdba privileges.
The wizard now displays the next page where you can select the type of Standby Database that is to be created.
The main options are a new Physical Standby, or a new Logical Standby.
However, if you have already set up a standby database manually, it is also possible to add it at this stage to the Data Guard configuration. You can do this by choosing Manage an existing standby database with Data Guard broker.
In the case of Oracle Database 12c, when adding a Standby Database, the wizard does not continue unless all the Pluggable databases (PDBs) in the production Container database (CDB) are open. This is seen in the following screenshot. The wizard is now CDB and PDB aware, and can create a Standby Database from a Container Database. Note that the standby created is for the entire CDB and all PDBs contained in it.
When it comes to choosing between a physical standby database and a logical standby database, in most cases, a physical standby database is suitable - it has the better performance as compared to a logical standby. The logical standby also has a number of restrictions as to the data types allowed.
Hence, we select Create a new physical standby database to use a physical standby. Click on Continue. The wizard now starts, displaying the first step as shown below.
We now choose the backup method that will be used to create the Physical Standby.
The easiest option is to perform an online backup of the Primary database, via Oracle Recovery Manager (RMAN).The backup files will be copied by RMAN to the standby server.
This will provide the most recent copy of the primary database - the physical standby being an exact copy of the primary.
It is also possible to use an RMAN database backup that has been created previously, perhaps your nightly backup. You can do this if the database is large and you do not want to take an online backup again at this time.
Select Online Backup and Use Recovery Manager (RMAN) to copy database files. In this case the files will be copied by RMAN to the standby server, so a staging area is not required.
However, if you wish, you can select a staging area to be used - this must be on both the primary and standby servers.
Click Next to continue.
The Add Standby Database: Backup Options page appears.
On this page, you can enter the number of concurrent File Copy processes. These are the parallel channels to be used by RMAN to copy the database files to the Standby.
You can increase the number of processes (2 by default), but only if sufficient bandwidth is available. Using a higher number of processes can potentially speed up the creation of the standby.
A new section "Staging Area" is only visible on this page if you are creating the Standby on a separate host (not the primary host), and you are not using RMAN to copy the database files in the case of an 11g database, instead you have selected "Copy database files via staging areas" under the Online Backup option in Figure 4.
In our case, we are using RMAN, so the above screen does not display this section - indicating the dynamic nature of the screens.
The wizards also display different options in different database versions, as per the technological advances in that version.
The Primary Host Login credentials can also be specified on this page. You can use existing Preferred or Named Credentials, or create a new credential.
The section Primary Database Standby Redo Log Files indicates that Standby Redo Log Files will be added to the Primary database automatically by the wizard.
Standby Redo Logs are very important for the functioning of Data Guard. Their main purpose is to enable real time apply of redo data onto the standby, by populating the standby logs with redo data almost at the same time as the redo logs in the primary database. So you don't have to wait for the archive log to be shipped to the standby.
This means that if there is a failover, the loss of data will be minimal in the case of real time apply, since no redo data would have been lost.
Consequently, when either the synchronous or asynchronous redo transport modes are used, Standby Redo logs are mandatory at the redo transport destination.
They are also created at the Primary database, because they enable the Primary database to receive Redo Log data after it assumes the Standby database role.
In order to simplify the setup, you can use Oracle-managed files (OMF) for the Standby redo files. Oracle will automatically name and place these files in the directory structure. If you don't use OMF files, you have to specify your own file names and directory locations.
Click Next to continue.
You can specify the Standby Database attributes on the following page.
The instance name must be unique on the Standby host. In our case, you can name the Standby database "stby". Choose “File System” as the database storage type for the Standby database.
The other alternative is Oracle Automatic Storage Management (ASM). You can specify this as the Standby database storage only if an ASM instance is operating on the Standby server.
Under Standby Database Location, enter the hostname, and the Oracle Home location for the Standby Database you are creating. You can select this from a list of host targets in the Cloud Control 12c system. The list displays only hosts with the same operating system as that of the primary, since this is a requirement of Oracle Data Guard, and Enterprise Manager Cloud Control 12c understands this. The Oracle Home for the standby also needs to be of the same version as the Oracle Home on the primary. You can refer to My Oracle Support (MOS) Note 413484.1 for a list of Data Guard configurations that are supported.
Differences in Oracle Home binaries may exist due to word sizes at the database or OS level, or due to different hardware, or different operating systems, or even different Linux distributions.
In such cases you cannot create standby databases using the Data Guard standby creation wizard on such different primary and standby platforms, but you can create them manually and then start to manage them with the Data Guard broker (this option to manage existing standby databases is seen in Figure 2).
Remember that the new Oracle Home has already been created on the Standby host.
Click on Next to continue.
You can now specify the Standby Database File locations.
One option is to accept the suggested Optimal Flexible Architecture (OFA) locations, or you can change the file locations manually by clicking on the Customize button.
You can now see the suggested file locations for the Standby database. Based on OFA, the locations for Datafiles and Tempfiles are seen as follows:
If you would like to change these locations, then this can be done for a group of files at a time – such as for all datafiles together, or for tempfiles, log files, control files, directory objects and external files that are seen in various sections on the page. Scroll down to the Log files and Control Files section.
You can set the location for all the different groups of files, a group at a time, to an appropriate directory.
In the Log Files section, the standby redo logs recently added to the Primary database are seen to be Oracle-managed files.
Scroll down to the Directory Objects and External Files section, as illustrated in Figure 10.
When you accept the changes by selecting OK, a warning appears. This indicates that the directories you specified will be created automatically since they do not currently exist on the server. This is fine, so you can proceed.
You are placed back on the File Locations screen. Click on Next to continue.
The Standby Database Configuration page is now displayed.
The parameters controlling the standby can be set here. First of all, you can set the unique name of the Standby database via the DB_UNIQUE_NAME parameter.
This is set to stby. There should be no database with this name elsewhere in the company, it should be a unique name.
Next, set the target name of the Standby database. This is used as the display name of the target on the Enterprise Manager Cloud Control 12c screens. Keep this the same as the unique name, so this would be stby again.
If you wish, you can change the Standby Archive location and configure it as the Fast Recovery Area (FRA). This is where Data Guard will place the archived redo logs that are received from the Primary database.
Normally, as a rule of thumb, the size of the Fast Recovery Area should be twice the database size. However this estimate is treated differently in different companies. In our case, we decide on 7500 MB.
The Enterprise Manager monitoring credentials for Data Guard are also specified on these pages. A SYSDBA login should be used if you intend to monitor a mounted physical Standby database (only a SYSDBA can connect to a mounted database), otherwise use ordinary credentials – for example, the "dbsnmp" user to satisfy the security requirements of your company.
Scroll down to the Data Broker section on this page.
Under the Data Broker section, it is recommended that you use the Data Guard Broker to manage the Data Guard configuration.
You can either use the Enterprise Manager connect descriptors as the Data Guard Connect Identifiers for both the Primary and Standby databases, or you can use the net service names that already exist.
Click on Next to continue.
You are now on the Review page.
On this page, the Standby Database Storage section can be expanded if you wish to verify that all the locations are correctly specified.
Then select Finish.
The Enterprise Manager job system now submits the Standby Database creation job. This starts to create the Standby database using the techniques selected in the Wizard pages, whether using an RMAN backup and copy, or the other methods.
You are placed on the Data Guard Home page for this database, which you will use later on to monitor the Data Guard operations. Currently the physical standby is shown as Down, since it is still being created. Click on View job if you want to monitor the progress of the job.
The Standby creation job finally completes after a period of time which depends on the size of the primary database and the method chosen to create the standby database.
At this point of time, the Targets..Databases list of Enterprise Manager Cloud Control 12c will display the primary and standby databases, as can be seen below.
We can see a Database Instance: Primary and a Database Instance: Physical Standby. The status of both the databases are displayed as Up.
Move to the primary database's Home page in Enterprise Manager Cloud Control 12c. Select Availability from the menu.
We can now see some new options in the menu that pertain to Data Guard.
The options have appeared since Enterprise Manager is aware there is a Data Guard configuration that is active for this primary database.
The section displays the options as Data Guard Administration, Data Guard Performance, and Verify Data Guard Configuration. These options are in addition to Add Standby Database that we had noticed previously.
Select Verify Data Guard Configuration to go through scripted and automatic checks on the Data Guard configuration in order to make sure the machinery of log transport and application works as expected, without actually performing a failover or switchover.
This is recommended to be performed on initial setup and periodically thereafter. Various Primary and Standby database settings are verified by this step, as can be seen in figure 18.
As a part of this process, the current log on the Primary database is switched, followed by a verification of the fast-start failover services and a verification of the protection mode.
The Standby redo log files are then checked. The log switch is verified as successful.
The Verify Configuration process then produces a detailed report on the health of the Data Guard configuration, which helps in bringing any urgent issues to the attention of the DBA.
Select Availability..Data Guard Performance. This brings up the following screen.
On the Data Guard Performance page, you can monitor the Redo Generation Rate in the Primary database, and the Apply Rate and Lag Times in the Standby Database. There is a Switch Log button, that archives the current log file group on the Primary database.
Another useful option is the "Test Application" capability. Via the Start/Stop/Pause buttons, you can generate a load on the Primary database, and see how the Data Guard configuration copes with the increased load.
Click on "Data Guard Administration". This brings up the Data Guard Administration page, seen in the screenshot below.
This page is used for the administration and management of the entire Data Guard configuration for this primary database, and the standby databases associated with it.
The Data Guard Administration page shows the Data Guard Status, which is displayed as "Normal". It also shows the Protection Mode used – by default, this is Maximum Performance.
We can also see if Fast-Start Failover is enabled or not. By default, this feature is disabled. Fast-Start Failover was introduced as a new feature in Oracle Data Guard 10g. If this feature is enabled, the Standby database is able to assume Primary status – i.e. a failover is performed without human intervention in case the primary database has failed for any reason.
Look at the Standby Database Progress Summary Section. This displays the Transport lag and the Apply lag in a bar chart format. The Transport lag is the time difference between the last update on the primary database, and the last received redo on the standby. Whereas, the Apply lag is the same difference but pertaining to the last applied redo on the standby.
From these two lag calculations, the DBA can understand at a glance how far the standby is behind the primary, regarding both the transport of the logs, and the application of the logs.
We can also see the status of both these databases - they are at status Normal. The Administration page also displays the current log of the Primary, and the last received and last applied log on the Standby. The estimated failover time is calculated as less than 1 second.
The Data Guard Administration page also allows you to edit the Data Guard properties of the Primary or the Standby. You can even add additional Standby databases to this Data Guard configuration – up to 30 standby databases can be added in total in the case of Oracle Data Guard 11.2.
The DBA can also elect to perform a "Switchover" or a "Failover", directly from the Administration page, to the selected Standby database. A disaster scenario resulting in unplanned downtime would necessitate a failover, whereas a switchover can be used for planned downtime, such as the installation of operating system patches – or a machine upgrade.
From the Data Guard Administration page, you can edit the Data Guard properties of the Primary or Standby databases.
Select the Standby Database via the radio button, and click on the Edit button. The Edit Standby Database Properties page now appears.
In the Properties screen for the Standby Database, there are three tabs - General, Standby Role Properties and Common Properties.
In the General tab, under Redo Apply Services, you can turn the Redo Log Apply on or off so that all application of redo logs to the Standby Database, is either restarted or suspended.
You can disable the Data Guard Broker management of the Database if you wish, but that is not recommended.
There is also a Diagnostics section where you can view the Alert Logs of the Primary or Standby Databases, or open a telnet session to either of the servers if you wish.
It is also possible to enable Real-time Query on the Standby Database, which means that Redo Logs are being applied while the Database is open in the read-only mode. This is the Active Data Guard option, and requires an additional license.
Enable Real-time Query on this page, and move to the Standby Role Properties tab.
The Standby Role Properties are seen on the next tab. Here you can modify the Redo Transport Mode to SYNC – the opposite of the default ASYNC.
You can also change the Net Timeout property in case you're dealing with a slower network, and the Apply Delay to specifically leave a time gap in minutes for applying logs between the Standby Database and the Primary Database.
If any manual errors are committed by users on the Primary Database, and if the DBA becomes aware of this in time, the time gap may make it possible to recover the data from the Standby Database, or simply failover to the Standby Database.
These are important Data Guard properties, most definitely, and must be carefully understood and implemented. Enterprise Manager Cloud Control 12c shows you all the properties at a glance which aids in understanding the possibilities.
Suppose 15 minutes has been specified as the Apply Delay. This means that logs transported to the standby server will not be applied on the standby database until 15 minutes has passed. If a user now drops a table, and they make the DBA aware of this immediately, the DBA can stop the application of logs on the standby and then make an effort to recover the dropped table from the standby, or failover to the standby if need be.
You can enable Redo Compression on this page, so that redo data is transmitted in compressed form.
Move to the Common Properties tab.
Common Properties are displayed on the third tab. This tab shows the Data Guard connect identifier in use, and the number of Log archive processes.
It also displays the Log Archive Trace level. The latter can be set to a higher value when debugging the Data Guard configuration.
Click on Apply. The properties are saved.
From the Data Guard Administration page, the properties of the Primary Database can be edited by clicking on the Edit link (see Figure 25).
This brings up the Edit Primary Database Properties page. This page has three tabs similar to the Standby Database Properties page.
In the General tab, under Redo Transport Services, you can turn the Redo Log Transport on or off so that all transfer of redo logs to any of the Standby Databases, is either restarted or suspended.
You would do this in the case of a network outage or any similar event, when you know the logs cannot be sent to the Standby Database and it is pointless for the Primary Database to keep trying to send the logs across.
Or, if the Primary Database was being brought down for maintenance work, turning the Redo transport off would be a best practice.
The two other tabs, Standby Role Properties and Common Properties in the Primary Database Properties are exactly the same as in the Standby Database Properties.
Move back to the Data Guard Administration page. Notice the Convert button in the Standby Databases section. This is used to convert the Standby Database into a Snapshot Standby Database.
This kind of Database was introduced in Oracle Data Guard 11g. Once converted to a Snapshot Standby Database, the database becomes open for read-write. It can be used for testing, and once completed, can be brought back to its previous state (using Oracle Flashback Technology), and all the redo logs can be applied to bring it back into synch with production as a normal Standby Database.
Select the Standby Database you want and click on the Convert button. The following warning appears.
When you proceed with the Yes button, the Database is converted to a Snapshot Standby Database and this information now appears in the Data Guard Administration page (see Figure 29).
After your testing is completed, you can now convert it back to the Physical Standby Database by clicking on the Convert button.
We will now examine the process of Switchover and/or Failover to the Standby Database. These are important features and the very purpose of using Oracle Data Guard, and are used in scheduled downtime (for switchovers) or unscheduled downtime (for failovers) - the latter being a disaster scenario.
In the case of Oracle Database 12c, as noted earlier, the standby is at the CDB level. It is not possible to switchover or failover to individual PDBs inside a CDB.
The Data Guard Administration page now displays the Database as a Physical Standby once again (see Figure 30).
It is extremely easy to switch over to the Standby Database using Enterprise Manager. Click on the Switchover button. The following message appears.
The Switchover lets the Primary Database switch roles with the Standby Database. Since Primary Database sessions will be closed, you can browse them using the link on the page.
Optionally, you can swap monitoring settings as well, including metric thresholds.
The Switchover process starts and displays the progress (see Figure 32).
When the switchover completes, the job and monitoring settings continue being transferred in the background when you select Return to Data Guard Overview.
On the Data Guard Administration page, it is obvious that the roles have reversed and the stby Database is now the Primary Database, and the prod Database is now the Standby Database.
This can also be verified in the Data Guard command-line interface, dgmgrl.
The command-line interface of dgmgrl reflects the Enterprise Manager information, and also shows the reversed roles for the two Databases. This is via the show configuration verbose command.
You can now perform the switchover again in Enterprise Manager, to return the roles to their previous state.
We will now perform a Failover. This is used in real life disaster situations when the Primary Database has failed (for any reason whatsoever) and is no longer available. In this case, the Standby Database must be opened as the Primary Database. This process is known as Failover.
Performing the failover in dgmgrl takes place as follows.
Since the Primary Database is down, dgmgrl shows that it cannot reach this Database. Issue the command failover to stby. This succeeds.
Issuing the show configuration verbose command again, the stby Database is seen as the Primary Database.
Regarding the prod Database, it is now the Physical Standby Database, but a message is displayed indicating that the prod database must be reinstated.
The reinstatement of the prod database can be performed from Enterprise Manager, as illustrated in Figure 37. Simply click the link Database must be reinstated.
However this generates an error, since Flashback Database has not been enabled. The reinstatement uses Flashback Database technology.
Due to this error, the configuration status in dgmgrl changes to the standby database needs to be re-created (see Figure 39).
You can now easily re-create the Standby Database as prod, using the Enterprise Manager wizard as we have seen in the earlier sections in this article.
Far Sync in Oracle Database 12c
Oracle Database 12c has a new kind of standby known as Far Sync. An Oracle Data Guard far sync instance is actually a remote Oracle Data Guard destination that accepts redo from the primary database. The redo is then shipped to other members of the Oracle Data Guard configuration.
A far sync instance has a control file, receives redo into standby redo logs, and also archives those logs to local archived redo logs. However, a far sync instance does not have user data files. As such it cannot be opened for access, cannot run redo apply, and can never become a primary database or even any type of standby database.
Far sync instances are part of the Oracle Active Data Guard Far Sync feature, which requires an Oracle Active Data Guard license.
Creation of Far Sync instances is not currently supported in Enterprise Manager 12c Cloud Control. However, externally created Far Sync instances will show up on the Data Guard Administration page.
As demonstrated in this technical article, it is possible to easily set up, manage and monitor Standby Databases for any Primary Database using Oracle Enterprise Manager Cloud Control 12c. The web interface provided by Oracle for creating and managing Data Guard configurations is advanced in all aspects, and extremely easy to use.
The DBAs can utilize Enterprise Manager for the day-to-day monitoring and management of Data Guard configurations. They can also easily perform Switchovers or Failovers to the standby, in the case of planned or unplanned downtime, and they can do all this from the Enterprise Manager Cloud Control 12c console, or the dgmgrl interface.
Enterprise Manager Cloud Control 12c supplies a common, standard interface to set up and manage Oracle Data Guard for Oracle 9i, 10g, 11g and the new Oracle Database 12c. Advanced features of Oracle Data Guard in different Database versions are visible corresponding to the version, and automatically offered to the DBA, thus reducing the learning curve. Enterprise Manager Cloud Control 12c can therefore be very useful in implementing Oracle Data Guard for the varied Oracle Database versions in a large company.