I must thank my fellow DBA César Aguilar and Joel Pérez for his publication in Spanish OTN.
The following article is part of a series that describes the behavior of “Pluggable databases (PDB)” in a Disaster Recovery and High Availability environment designed with Oracle Data Guard 12c on a base Of Container data, it will be demonstrated how the process of configuration of the Data Guard in a Multitenant architecture is reduced, we will exemplify different scenarios of the PDBs in a Data Guard, thus exhibiting the characteristics of simplification, consolidation and provisioning of this architecture.
What is data guard ?
Oracle Data Guard is the management, monitoring, and automation software infrastructure that creates, maintains, and monitors one or more standby databases to protect enterprise data from failures, disasters, errors, and corruptions.
Oracle provides both graphical user interface (GUI) and command-line interface (CLI) tools for managing Data Guard configurations.
Advantages of data guard.
- Data Guard provide high availability for database servers
- Reduces the amount of human intervention required to switch between sites
- There is no distance limitation – the secondary site can be located thousands of kilometres away.
The ability to create standby databases was first offered as a feature in Oracle 8i, although users were creating manual standby databases since Oracle 7.3
Features introduced in Oracle 8i:
- Read-only physical standby database
- Managed recovery of standby
- Remote archiving of redo log files
Features introduced in Oracle 9i:
- Integrated zero-data-loss capability
- Data Guard Broker w/ Data Guard Manager GUI
- Command Line Interface (CLI)
- Switchover and Failover operations
- Automatic gap resolution
- Automatic Synchronization
- Logical standby databases
- Maximum protection / availability
- Enhanced Data Guard Broker
- Cascaded redo log destinations
Features introduced in Oracle 10g:
- Real-time apply
- Recovery through OPEN RESETLOGS
- Simplified configuration with VALID_FOR attribute
- Standby redo log support on logical standby databases
- Improved redo transmission security
- Improved support for RAC
- Zero downtime instantiation of logical standby databases
- Fast-start Failover
- Flashback Database across Data Guard switchovers
- Asynchronous Redo Transmission
- Faster Redo Apply failover
Features introduced with Oracle 11g:
- Standby databases can remain open while doing recovery
- Heterogeneous platform support (standby can be on a different platform). For example, production on Linux and standby on Windows.
Features introduced with Oracle 12c:
We know there are 500+ features introduced with Oracle 12c
- Far Sync :-This feature allows you to failover to a standby database even if it is remotely located in another site thousands of miles away. You do this without any data loss and without negatively affecting the performance of the primary database. Far Sync also keeps things simple and your costs down.
- Fast Sync:-This feature gives you the easiest way to improve the database performance when you have synchronous no data loss setups. When a standby database gets a redo in memory, it will check with the primary database, even without getting a disk I/O to a redo log file in the standby. Fast Sync then effectively reduces the total round trip time between the standby and primary, resulting in better primary database performance. You should know, however, that there is a minute chance that data loss would happen when you use Fast Sync. But Oracle assures you that these instances would be so rare and it has to happen when both databases fail milliseconds within each other.
- Real – time Cascading:-Real-time Cascade allows your standby database to immediately transmit a redo to another standby database even when it has yet to be archived in the redo log file. Before 12c, redo is only cascade after the standby redo log file has finished being archived locally.
- SysDG:-SYSDG is an administration privilege wherein the user can only perform basic administration actions and tasks. As such, SYSDG privileges are limited to STARTUP, SHUTDOWN, ALTER DATABASE, ALTER SESSION, ALTER SYSTEM, CREATE RESTORE POINT, CREATE SESSION, DROP RESTORE POINT, FLASHBACK DATABASE, SELECT ANY DICTIONARY, DELETE, and EXECUTE.
- Data Manipulation Language operations are now permitted on global temporary tables on the standby. You no longer have to add the USING CURRENT LOGFILE clause when you initiate real-time apply.You can now use sequences in a Data Guard environment.
It is important to have no doubts in the main concept of the Oracle Multitenant architecture and Oracle Data Guard.
The Oracle Multitenant architecture is based on a “Container” database which can house many individual DBMSs called “Plugaggable Databases”. The redo logs only belong to the “Container” database and the “Plugaggables” databases do not have their own online redo log files.
With respect to Oracle Data Guard, it is a solution of high availability and recovery against disasters whose main function is to keep a copy of the production database synchronized in a database in standby mode that allows to offer the services in In case the “Primary” production base is inaccessible among other functions.
Data Guard manages one or more synchronized copies of the “Primary” database by sending and applying redo logs from the “Primary” database to the “Standby” database.
In the versions of Oracle Data Guard prior to 12c, in which there was no concept of “Multitenant”, for each database you want to install a Data Guard, it was necessary to create a separate configuration, that is if we have 20 Databases in which we need to configure Data Guard, we would have to make 20 configurations separately (tnsnames.ora, listener, backup tasks, among others)
In Oracle Data Guard 12c the configuration of a database “Container” is at the level of the “Container” and not at the level of the individual databases “Plugaggable Databases”. The redo logs are managed by the “Container” database and applied to the “Container Standby” level, protecting each of the individual “Plugaggables” databases, the Primary and Standby database roles are Related to the “Container”.
In this first part we will present a scenario in which we will create a new pluggable database in a container with Data Guard configured and observe the behavior of the container standby database.
Our CDB1 test environment is a Container Database with Data Guard configured and has two Pluggable databases: PDB1, PDB2.
We enter the primary server to list the existing pluggable databases and validate the role of the container database:
[Oracle @ rfcg ~] $ export ORACLE_SID = CDB1 [Oracle @ rfcg ~] $ sqlplus / as sysdba SQL * Plus: Release 12.1.0.2.0 Production on Mon Mar 27 09:26:36 2017Copyright © 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With Partitioning, OLAP, Advanced Analytics And Real Application Testing options SQL> select name, cdb from v $ database; NAME CDB (I.e. CDB1 YES SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB $ SEED READ ONLY NO 3 PDB1 READ WRITE NO 4 PDB2 READ WRITE NO SQL> select database_role fromv $ database; DATABASE_ROLE ---------------- PRIMARY
Scenario 1:
We will create a new “Plugaggable Database” “PDB_SERA” through the Database Configuration Assistant (DBCA). We will look at how it automatically forms part of the high availability configuration.
Process:
We started the dbca
Select the option “Manage Pluggable Databases”
We indicate the type of operation that we are going to carry out in the container: “Create a Pluggable Database”
Select the container database: CDB1
We select the option to create a new pluggable database: “Create a new Pluggable Database”
We indicate the name of the pluggable database: PDB_SERA, we specify the location of the files of the new pluggable and the data of the administrator account of the same one
We look at the summary of the creation of the PDB database and select “Finish” to start the process.
We wait while the pluggable database is created.
Finally select “Close” and we will have created the new PDB_SERA pluggable database.
We enter the standby server and observe how we automatically have the PDB_SERA pluggable database included in high availability environment without requiring any other configuration.
[Oracle @ rfcg2 ~] $ export ORACLE_SID = cdb1 [Oracle @ rfcg2 ~] $ sqlplus / as sysdba SQL * Plus: Release 12.1.0.2.0 ProductiononMon Mar 27 09:43:13 2017 Copyright (c) 1982, 2014, Oracle. Allrightsreserved. Connected to: Oracle Database 12c Enterprise EditionRelease 12.1.0.2.0 - 64bit Production WiththePartitioning, OLAP, AdvancedAnalytics and Real ApplicationTestingoptions SQL> show pdbs CON_ID CON_NAME OPEN MODE RESTRICTED ---------- ------------------------------ ---------- ---------- 2 PDB $ SEED MOUNTED 3 PDB1 MOUNTED 4 PDB2 MOUNTED 5 PDB_SERA MOUNTED SQL> select database_role from v $ database; DATABASE_ROLE ---------------- PHYSICAL STANDBY
Conclusion:
As you can see, the Multitenant architecture allows you to quickly obtain standby databases by simplifying the configuration tasks of versions prior to 12c.
