TAKE BACK CONTROL OF YOUR ORACLE DATABASE BACKUPS · With the database mode confirmed to be set, we can now proceed with backing up the Oracle database. Backup. DDBEA Oracle backups

TAKE BACK CONTROL OF YOUR ORACLE DATABASE BACKUPSChris MavromatisSME, Data Protection & Availability Solutions Dell EMC | Technical Support Services [email protected]

2016 EMC Proven Professional Knowledge Sharing 2

Table of Contents

Introduction .................................................................................................................................................. 3

Prerequisites ................................................................................................................................................. 4

Installation .................................................................................................................................................... 5

Backup ........................................................................................................................................................... 9

Backup Performance ................................................................................................................................... 15

Disclaimer: The views, processes or methodologies published in this article are those of the authors.

They do not necessarily reflect Dell EMC’s views, processes or methodologies.


Introduction

Many IT staff in small companies find themselves tasked with the responsibility of handling multiple disjointed duties/roles in their computer environments. This often leads personnel to juggle database administration, data storage administration, and daily backup tasks. Although a daunting task, it does afford certain advantages as well. For example, database administrators not only need to run the normal business of the database, but also ensure data protection, and availability, along with meeting the Recovery Time Objective (RTO) imposed by the business. Having total control of the Oracle database, including the task of data protection does empower the DBA however to retain control of the daily backups, and thus not rely on a backup administrator’s success and accuracy of those backups. Commonly, as the size of the corporation increases, so does the delegation of the various responsibilities, and thus a separate team of staff would be in charge of Data storage, Backup Operations, and Database Administration. One of the most popular Enterprise databases is Oracle, and in many environments where Oracle is deployed you will often find one person or more in charge of the database administration duties. In speaking to database administrators and asking them what their preference would be for backup and recovery of the Oracle database, a common theme discovered is the requirement of performing daily full backups, as well as having full control/jurisdiction over the time and method of the backup. This desire for independence often clashes with staff responsible for Backup Administration of the entire Data Zone. Their responsibility is often to perform backups on all machines and databases alike, regardless of the Operating System of the database involved. Faced with the choice of protecting a large database, or multiple databases onto local disk across the various DB hosts, thus consuming critical primary storage, all while struggling to meet the backup window often results in the DBA letting go some of the control, and charging the backup admin with the daily backups. This leaves the DBA dependent on a set of operations outside his visibility, but yet still responsible in many ways to meet the defined RTO. DBA’s however do have a new set of options available to them through the use of Dell EMC Data Domain® Boost for Enterprise Applications (DDBEA), which empowers the DBA to direct RMAN backups to a Data Domain deduplication array and thus retain control of the database backup operations. In addition, while leveraging Boost technology the DBA can efficiently and rapidly back up large databases via deduplication thus reducing the amount of storage footprint required to perform backups.


Figure 1

DDBEA can be used to conduct daily full RMAN backups to the local Data Domain array, while sending only new unique data not previously seen by the Data Domain array, effectively reducing space requirements needed to store that data. In addition, via the replication mechanisms already available to the Data Domain array, the backup can be replicated to another Data Domain array offsite, all while using the same efficient method of sending unique data to the remote array. The DBA can now restore the data if required from the local or remote array should there be a need.

Prerequisites

Prior to setting up DDBEA, you should gather some information from the Data Domain machine(s) that you would be performing Oracle backups to. This includes:

TCP/IP hostname of the Data Domain array

ddboost user name and password that is configured on the Data Domain array

Storage unit on the Data Domain that will be used for RMAN backups The above information is often provided by the administrator of the Data Domain array. This information can be reviewed using the following commands: To view the ddboost user defined on the array

ddboost user show i.e.

sysadmin@ddve11# ddboost user show DD Boost user ------------- ostuser11 -------------


To view the storage units on the Data Domain

ddboost storage-unit show i.e.

sysadmin@ddve11# ddboost storage-unit show Name Pre-Comp (GiB) Status User Report Physical Size (MiB) ----------------- -------------- ------ --------- --------------- STU1 1369. RW ostuser11 - Evie 1411. RW ostuser11 - Ethan 2608. RW ostuser11 - werbk001 0.0 RW ostuser11 - ----------------- -------------- ------ --------- --------------- Q : Quota Defined RO : Read Only RW : Read Write RD : Replication Destination sysadmin@ddve11#

With the basic prerequisite information gathered, we can install the DDBEA agent. Installation

Installation of the software is performed as the root user, using the native Operating System installer. For example, rpm is used on Linux [root@pro-ora1 2.5]# rpm -i emcddbda-2.5.0-1.x86_64.rpm Lockbox in the directory /var/opt/ddbda/lockbox has been updated. ** Important information for completing your database app agent ** ** for DDBEA and ProtectPoint installation: ** --------------------------------------------------------------------- If you wish to grant a DBA group write access to the lockbox for registration and unregistration of the Data Domain systems, and for lockbox update, then run ddbmadmin -L. --------------------------------------------------------------------- If you wish to use an existing lockbox in a nondefault directory, then run ddbmadmin -U as the root user after the installation to update the lockbox. --------------------------------------------------------------------- Depending on the database or application that you want to protect, there might be additional post-install steps you have to perform. Refer to the installation instructions in the product administration guide. [root@pro-ora1 2.5]#


With the DDBEA product now installed, we have to now modify the installed DDBEA template to be able to direct the RMAN backups onto the Data Domain device, and leverage the Boost distributed segment processing. The DDBEA config file for Oracle RMAN backups is located in the /opt/ddbda/config/oracle_ddbda.cfg. Although there are several parameters listed in the configuration file, most are optional and not required to get the product configured. In order to get the Oracle RMAN backups to be saved onto the Data Domain array you need to specify values for the following variables

DDBOOST_USER = DEVICE_HOST = DEVICE_PATH =

Where: DDBOOST is the DD Boost user name that is configured on the primary Data Domain system DEVICE_HOST is the TCP/IP hostname of the primary Data Domain system DEVICE_PATH is the top-level directory within the storage unit on the primary Data Domain system In the event you are replicating your backup from the primary Data Domain system to a secondary one (possibly in a remote location), you can also update the remote Data Domain options needed in order to restore from the remote array in the event the primary array is not accessible.

DDBOOST_USER_SECONDARY = DEVICE_HOST_SECONDARY = DEVICE_PATH_SECONDARY =

Where: DDBOOST is the DD Boost user name that is configured on the secondary Data Domain system DEVICE_HOST is the TCP/IP hostname of the secondary Data Domain system DEVICE_PATH is the top-level directory within the storage unit on the secondary Data Domain system For example, here are the relevant completed sections # ############################################################################# # MANDATORY PARAMETERS (BACKUP AND RESTORE) # ############################################################################# DDBOOST_USER =ostuser DEVICE_HOST =ddve10 DEVICE_PATH =/StorageUnit1


# ############################################################################## # OPTIONAL PARAMETERS (RESTORE ONLY) # ############################################################################## DDBOOST_USER_SECONDARY =ostuser11 DEVICE_HOST_SECONDARY =ddve11 DEVICE_PATH_SECONDARY =/STU1 With the config file updated, we can now register the Data Domain information into the lockbox. The DDBEA lockbox is an encrypted file that contains protected information from unauthorized access. The lockbox stores the Data Domain system information, including credentials for the DD Boost user.

[root@pro-ora1 config]# /opt/ddbda/bin/ddbmadmin -P -z /opt/ddbda/config/oracle_ddbda.cfg Performing the registration of the device host 'ddve10' for DD Boost user 'ostuser'. Enter password: Confirm password: Logging in to the device host 'ddve10' with DD Boost credentials. Logging in to the device host 'ddve10' with DD Boost credentials was successful. Continue with the registration of the secondary device host 'ddve11' for DD Boost user 'ostuser11'? [y/n]: y Performing the registration of the device host 'ddve11' for DD Boost user 'ostuser11'. Enter password: Confirm password: Logging in to the device host 'ddve11' with DD Boost credentials. Logging in to the device host 'ddve11' with DD Boost credentials was successful. Lockbox directory is '/var/opt/ddbda/lockbox'. Device host 'ddve10' for DD Boost user 'ostuser' has been registered in the lockbox. Device host 'ddve11' for DD Boost user 'ostuser11' has been registered in the lockbox. [root@pro-ora1 config]# Now that the Data Domain credentials are registered in the lockbox, we can start performing Oracle RMAN backups. The first thing that should be verified in the Oracle database is for the target database to be in “Archive Mode”. Although this is not the default mode for the database at the time of creation, it is highly recommended to run the database in this mode so that online – or Hot backups – can be performed. In addition, running the database in Archive Mode allows the DBA to perform Point-in-Time restores (or incomplete recoveries).


We can verify the database is in archive log mode by connecting to the target database as the oracle user, and viewing the mode. i.e. [oracle@pro-ora1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Tue Feb 16 12:40:44 2016 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics, and Real Application Testing options SQL> With a connection to the target database established, we can verify the Archive Mode using the command SQL> archive log list; Database log mode No Archive Mode Automatic archival Disabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 53 Current log sequence 55 SQL> The above confirms that the target database is in No Archive Mode. To change this mode, the DBA needs to plan for an outage in order to put the DB in mount mode. This is an Oracle limitation. i.e. SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> SQL> startup mount; ORACLE instance started. Total System Global Area 524288000 bytes Fixed Size 2926320 bytes Variable Size 444598544 bytes Database Buffers 71303168 bytes Redo Buffers 5459968 bytes


Database mounted. SQL> SQL> alter database archivelog;

Database altered. SQL>

SQL> alter database open;

Database altered. SQL> SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 53 Next log sequence to archive 55 Current log sequence 55 SQL>

With the database mode confirmed to be set, we can now proceed with backing up the Oracle database.

Backup

DDBEA Oracle backups are conducted via the Oracle RMAN backup tool that is already installed as part of the Oracle software. You may also use the Oracle Enterprise Manager GUI to perform backups, but for the purpose of this document I will illustrate the RMAN CLI method. To begin, we create an RMAN script that we would use to achieve the backup. Here is an example of such a script: run { allocate channel t1 type 'SBT_TAPE' parms="BLKSIZE=1048576,SBT_LIBRARY=/usr/lib/ddbda/lib64/libddboostora.so,SBT_PARMS=(CONFIG_FILE=/opt/ddbda/config/oracle_ddbda.cfg)"; allocate channel t2 type 'SBT_TAPE' parms="BLKSIZE=1048576,SBT_LIBRARY=/usr/lib/ddbda/lib64/libddboostora.so,SBT_PARMS=(CONFIG_FILE=/opt/ddbda/config/oracle_ddbda.cfg)"; BACKUP FULL FILESPERSET 1 FORMAT '%d_%U' DATABASE


INCLUDE CURRENT CONTROLFILE PLUS ARCHIVELOG; DELETE ARCHIVELOG UNTIL TIME "SYSDATE-3" BACKED UP 1 TIMES TO DEVICE TYPE sbt; release channel t1; release channel t2; } The above script leverages the SBT interface as provided by Oracle Corp, to load the DDBEA Oracle RMAN library named libddboostora.so, and execute SBT backups to the Data Domain array. The script allocates two RMAN channels, backs up the target database along with the control file and archive logs. Once the archive log files are confirmed to be backed up with DDBEA, all log files older than three days are removed from primary storage so as to free space and prevent the filesystem on the Oracle server from reaching capacity. Here is an example of the execution of this script. Although the DBA can execute the backup ad-hoc, they can also set this to execute on a daily basis via the crontab, Windows scheduler, Oracle Enterprise Manager, or any other scheduling application. [oracle@pro-ora1 RMAN]$ rman target / cmdfile=backup1 Recovery Manager: Release 12.1.0.2.0 - Production on Tue Feb 16 14:20:07 2016 Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL (DBID=1429445936) RMAN> run { 2> allocate channel t1 type 'SBT_TAPE' parms="BLKSIZE=1048576,SBT_LIBRARY=/usr/lib/ddbda/lib64/libddboostora.so,SBT_PARMS=(CONFIG_FILE=/opt/ddbda/config/oracle_ddbda.cfg)"; 3> allocate channel t2 type 'SBT_TAPE' parms="BLKSIZE=1048576,SBT_LIBRARY=/usr/lib/ddbda/lib64/libddboostora.so,SBT_PARMS=(CONFIG_FILE=/opt/ddbda/config/oracle_ddbda.cfg)"; 4> BACKUP 5> FULL 6> FILESPERSET 1 7> FORMAT '%d_%U' 8> DATABASE 9> INCLUDE CURRENT CONTROLFILE 10> PLUS ARCHIVELOG; 11> DELETE 12> ARCHIVELOG UNTIL TIME "SYSDATE-3" 13> BACKED UP 1 TIMES TO DEVICE TYPE sbt; 14> release channel t1; 15> release channel t2;


16> } 17> using target database control file instead of recovery catalog allocated channel: t1 channel t1: SID=32 device type=SBT_TAPE channel t1: database app agent Oracle v2.5.0.0 allocated channel: t2 channel t2: SID=33 device type=SBT_TAPE channel t2: database app agent Oracle v2.5.0.0 Starting backup at 16-FEB-16 current log archived channel t1: starting archived log backup set channel t1: specifying archived log(s) in backup set input archived log thread=1 sequence=55 RECID=59 STAMP=903968409 channel t1: starting piece 1 at 16-FEB-16 channel t1: finished piece 1 at 16-FEB-16 piece handle=ORCL_2pqu2tkp_1_1 tag=TAG20160216T142009 comment=API Version 2.0,MMS Version 2.5.0.0 channel t1: backup set complete, elapsed time: 00:00:07 Finished backup at 16-FEB-16 Starting backup at 16-FEB-16 channel t1: starting full datafile backup set channel t1: specifying datafile(s) in backup set input datafile file number=00001 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_system_cb0n9vhc_.dbf channel t1: starting piece 1 at 16-FEB-16 channel t2: starting full datafile backup set channel t2: specifying datafile(s) in backup set input datafile file number=00003 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_cb0n8r9f_.dbf channel t2: starting piece 1 at 16-FEB-16 channel t2: finished piece 1 at 16-FEB-16 piece handle=ORCL_2rqu2tl0_1_1 tag=TAG20160216T142016 comment=API Version 2.0,MMS Version 2.5.0.0 channel t2: backup set complete, elapsed time: 00:00:25 channel t2: starting full datafile backup set channel t2: specifying datafile(s) in backup set input datafile file number=00004 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_cb0nc9x4_.dbf channel t2: starting piece 1 at 16-FEB-16 channel t1: finished piece 1 at 16-FEB-16 piece handle=ORCL_2qqu2tl0_1_1 tag=TAG20160216T142016 comment=API Version 2.0,MMS Version 2.5.0.0 channel t1: backup set complete, elapsed time: 00:00:26


channel t1: starting full datafile backup set channel t1: specifying datafile(s) in backup set including current control file in backup set channel t1: starting piece 1 at 16-FEB-16 channel t1: finished piece 1 at 16-FEB-16 piece handle=ORCL_2tqu2tlq_1_1 tag=TAG20160216T142016 comment=API Version 2.0,MMS Version 2.5.0.0 channel t1: backup set complete, elapsed time: 00:00:03 channel t1: starting full datafile backup set channel t1: specifying datafile(s) in backup set input datafile file number=00006 name=/u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_cb0nc8qq_.dbf channel t1: starting piece 1 at 16-FEB-16 channel t2: finished piece 1 at 16-FEB-16 piece handle=ORCL_2squ2tlp_1_1 tag=TAG20160216T142016 comment=API Version 2.0,MMS Version 2.5.0.0 channel t2: backup set complete, elapsed time: 00:00:05 channel t2: starting full datafile backup set channel t2: specifying datafile(s) in backup set including current SPFILE in backup set channel t2: starting piece 1 at 16-FEB-16 channel t1: finished piece 1 at 16-FEB-16 piece handle=ORCL_2uqu2tlu_1_1 tag=TAG20160216T142016 comment=API Version 2.0,MMS Version 2.5.0.0 channel t1: backup set complete, elapsed time: 00:00:03 channel t2: finished piece 1 at 16-FEB-16 piece handle=ORCL_2vqu2tlu_1_1 tag=TAG20160216T142016 comment=API Version 2.0,MMS Version 2.5.0.0 channel t2: backup set complete, elapsed time: 00:00:07 Finished backup at 16-FEB-16 Starting backup at 16-FEB-16 current log archived channel t1: starting archived log backup set channel t1: specifying archived log(s) in backup set input archived log thread=1 sequence=56 RECID=60 STAMP=903968453 channel t1: starting piece 1 at 16-FEB-16 channel t1: finished piece 1 at 16-FEB-16 piece handle=ORCL_30qu2tm6_1_1 tag=TAG20160216T142054 comment=API Version 2.0,MMS Version 2.5.0.0 channel t1: backup set complete, elapsed time: 00:00:03 Finished backup at 16-FEB-16 specification does not match any archived log in the repository released channel: t1 released channel: t2


Recovery Manager complete. [oracle@pro-ora1 RMAN]$ With the backup successfully completed, we can inspect the generated metadata on the Oracle server. RMAN> list backup; using target database control file instead of recovery catalog List of Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 88 42.00M SBT_TAPE 00:00:03 16-FEB-16 BP Key: 88 Status: AVAILABLE Compressed: NO Tag: TAG20160216T142009 Handle: ORCL_2pqu2tkp_1_1 Media: database app agent/StorageUnit1 List of Archived Logs in backup set 88 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 55 2576919 16-FEB-16 2592024 16-FEB-16 BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 89 Full 528.00M SBT_TAPE 00:00:20 16-FEB-16 BP Key: 89 Status: AVAILABLE Compressed: NO Tag: TAG20160216T142016 Handle: ORCL_2rqu2tl0_1_1 Media: database app agent/StorageUnit1 List of Datafiles in backup set 89 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 3 Full 2592222 16-FEB-16 /u01/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_cb0n8r9f_.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 90 Full 659.00M SBT_TAPE 00:00:23 16-FEB-16 BP Key: 90 Status: AVAILABLE Compressed: NO Tag: TAG20160216T142016 Handle: ORCL_2qqu2tl0_1_1 Media: database app agent/StorageUnit1 List of Datafiles in backup set 90 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 1 Full 2592221 16-FEB-16 /u01/app/oracle/oradata/ORCL/datafile/o1_mf_system_cb0n9vhc_.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 91 Full 60.00M SBT_TAPE 00:00:02 16-FEB-16


BP Key: 91 Status: AVAILABLE Compressed: NO Tag: TAG20160216T142016 Handle: ORCL_2squ2tlp_1_1 Media: database app agent/StorageUnit1 List of Datafiles in backup set 91 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 4 Full 2592230 16-FEB-16 /u01/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_cb0nc9x4_.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 92 Full 10.00M SBT_TAPE 00:00:02 16-FEB-16 BP Key: 92 Status: AVAILABLE Compressed: NO Tag: TAG20160216T142016 Handle: ORCL_2tqu2tlq_1_1 Media: database app agent/StorageUnit1 Control File Included: Ckp SCN: 2592231 Ckp time: 16-FEB-16 BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 93 Full 2.00M SBT_TAPE 00:00:01 16-FEB-16 BP Key: 93 Status: AVAILABLE Compressed: NO Tag: TAG20160216T142016 Handle: ORCL_2uqu2tlu_1_1 Media: database app agent/StorageUnit1 List of Datafiles in backup set 93 File LV Type Ckp SCN Ckp Time Name ---- -- ---- ---------- --------- ---- 6 Full 2592406 16-FEB-16 /u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_cb0nc8qq_.dbf BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 94 Full 1.00M SBT_TAPE 00:00:00 16-FEB-16 BP Key: 94 Status: AVAILABLE Compressed: NO Tag: TAG20160216T142016 Handle: ORCL_2vqu2tlu_1_1 Media: database app agent/StorageUnit1 SPFILE Included: Modification time: 16-FEB-16 SPFILE db_unique_name: ORCL BS Key Size Device Type Elapsed Time Completion Time ------- ---------- ----------- ------------ --------------- 95 1.00M SBT_TAPE 00:00:00 16-FEB-16 BP Key: 95 Status: AVAILABLE Compressed: NO Tag: TAG20160216T142054 Handle: ORCL_30qu2tm6_1_1 Media: database app agent/StorageUnit1 List of Archived Logs in backup set 95 Thrd Seq Low SCN Low Time Next SCN Next Time ---- ------- ---------- --------- ---------- --------- 1 56 2592024 16-FEB-16 2592413 16-FEB-16 RMAN>


From the above we can see that each backup object was placed in its own backup set (due to filesperset=1), and that the media handle is the name of the application agent used, along with the Storage Unit name. i.e. Media: database app agent/StorageUnit1 The various Handle: values are backup set names that Oracle generated based on the format string used, and we can see the objects included into each backup set.

Backup Performance

During the above illustrated backup, the DDBEA Boost distributed segment processing feature analyzes the data stream generated from each allocated channel, and performs the following tasks. 1. Segments the data. 2. Computes IDs for the data segments. 3. Checks with the Data Domain system for duplicate segments. 4. Compresses unique segments that are not found on the Data Domain system. 5. Sends the compressed data to the Data Domain system, which writes the unique data to disk. This deduplication during the backup process generally improves throughput since only unique data is sent. The degree of throughput improvement varies according to the level of redundancy of the data being backed up. Other factors play a role on the backup performance, but because we are performing backups onto a high performance deduplication array, we need not be concerned immediately with a variety of issues that tape backups need to deal with – i.e. tape buffers not filling up, leading to frequent tape repositioning, and often referred to as “show-shining”. There are however a number of tunable parameters that have a direct impact on the RMAN backups that are directed to the Data Domain array while using DDBEA. Number of RMAN channels allocated: Each channel allocated acts as a worker process to conduct the backup, and is a degree of backup parallelism on the Oracle server. Each channel consumes system resources on the Oracle host, and thus the optimal number of channels to be used varies on the CPU and memory resources, and I/O bandwidth of the Oracle host. On the other side of these streams would be the Data Domain array, and depending on the model used, the greater number of concurrent save streams can be accommodated. Compression: RMAN can implement the BZIP2 compression mechanism while backing up the Oracle objects. This is achieved through the syntax “AS COMPRESSED” on the backup command. This compression is performed by the CPU and memory of the Oracle host during runtime and has a double negative effect on DDBEA RMAN backups. Not only does it consume valuable resources on the DB server, it also compromises the ability of the Data Domain array to find commonality. Encryption: In addition to compression, RMAN can execute encryption algorithms on the Oracle backup sets during runtime. Enabling this feature leads to an inability for DDBEA to find common segments from previous


backups, thus resulting in larger storage footprint on the Data Domain array. Therefore, it is recommended not to be enabled during the backup. Filesperset Whereas the number of allocated channels in the RMAN script controls the degree of parallelism, filesperset throttles the degree of multiplexing conducted on each given channel. With filesperset=1 (as per above example) there is no multiplexing, and therefore each Oracle backup object is placed in its own backup set. Enabling multiplexing on the Oracle host has an opposite effect on the commonality factoring on DDBEA. Since multiple Oracle objects would be interweaved into a single backup set, when DDBEA tries to segment the data stream to identify duplicate segments, it would have a lesser probability in locating duplicate segments. Because of these factors, it is generally recommended that datafiles be backed up using filesperset=1 (no multiplexing). Archivelog files can be multiplexed since they generally contain new unique data. However, for simplicity they also are set to use filesperset=1. Restore Operations Restore operations are generally conducted similar to the backups. The RMAN channels allocated for the restore must reference the DDBEA, in order to load the Media Management Library (libddboostora.so) and thus facilitate the SBT calls Oracle would generate for the restore process from the Data Domain array. In this illustration, we restore the tablespace users. The restore is driven once again via an RMAN script as previously done for the backup. For this example we first shut down the database and remove the datafiles that comprise the Oracle tablespace users. [oracle@pro-ora1 RMAN]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Tue Feb 16 16:10:34 2016 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> SQL> host; [oracle@pro-ora1 RMAN]$ rm /u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_cb0nc8qq_.dbf [oracle@pro-ora1 RMAN]$ exit exit SQL> startup


ORACLE instance started. Total System Global Area 524288000 bytes Fixed Size 2926320 bytes Variable Size 444598544 bytes Database Buffers 71303168 bytes Redo Buffers 5459968 bytes Database mounted. ORA-01157: cannot identify/lock data file 6 - see DBWR trace file ORA-01110: data file 6: '/u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_cb0nc8qq_.dbf' SQL> At this point we see that Oracle is prevented from opening the database since the DBWR background process cannot access the data files (removed in above step). This results in leaving the database in a mount state (not opened). We can now use an RMAN script to restore the tablespace using DDBEA. [oracle@pro-ora1 RMAN]$ rman target / cmdfile=restore1 Recovery Manager: Release 12.1.0.2.0 - Production on Tue Feb 16 16:22:33 2016 Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL (DBID=1429445936, not open) RMAN> run { 2> allocate channel t1 type 'SBT_TAPE' parms="BLKSIZE=1048576,SBT_LIBRARY=/usr/lib/ddbda/lib64/libddboostora.so,SBT_PARMS=(CONFIG_FILE=/opt/ddbda/config/oracle_ddbda.cfg)"; 3> restore tablespace users; 4> release channel t1; 5> } 6> 7> using target database control file instead of recovery catalog allocated channel: t1 channel t1: SID=7 device type=SBT_TAPE channel t1: database app agent Oracle v2.5.0.0 Starting restore at 16-FEB-16 channel t1: starting datafile backup set restore channel t1: specifying datafile(s) to restore from backup set


channel t1: restoring datafile 00006 to /u01/app/oracle/oradata/ORCL/datafile/o1_mf_users_cb0nc8qq_.dbf channel t1: reading from backup piece ORCL_2uqu2tlu_1_1 channel t1: piece handle=ORCL_2uqu2tlu_1_1 tag=TAG20160216T142016 channel t1: restored backup piece 1 channel t1: restore complete, elapsed time: 00:00:01 Finished restore at 16-FEB-16 released channel: t1 Recovery Manager complete. [oracle@pro-ora1 RMAN]$ With the restore complete, we have brought back the deleted datafile, and we can now apply any transactions onto the restored file, and then open the database. [oracle@pro-ora1 RMAN]$ sqlplus / as sysdba SQL*Plus: Release 12.1.0.2.0 Production on Tue Feb 16 16:34:46 2016 Copyright (c) 1982, 2014, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options SQL> SQL> recover tablespace users; Media recovery complete. SQL> alter database open;

Database altered. SQL> select instance_name, status from v$instance; INSTANCE_NAME STATUS ---------------- ------------ orcl OPEN SQL>


DBA’s can further increase the confidence of Oracle recoverability via the use of various additional options. Data Domain Replication: Although not initiated or monitored by DDBEA, replication between Data Domain arrays allows for RMAN restores to be executed from either Data Domain boxes, thus not allowing for a single point of failure (the entire array itself) in the event of a major failure. Check logical: As part of any RMAN backup, Oracle performs a checksum of the header and tail of the file, as a check for possible corruption of the data file, thus not backing up a file that is corrupt. DBA’s can force RMAN to conduct a more thorough test for data file corruption via the use of the “check logical” option. i.e. backup check logical database plus archivelog; This will cause RMAN to check for logical corruption within the blocks, as well as the head/tail checksums. This does pose an increased load on the Oracle server at backup, thus it needs to be evaluated if it is beneficial for the environment. Restore validate: This Oracle feature performs a restore similar to conducting an actual database restore operation, but without committing the actual data onto the disk. This helps check for physical or logical corruption of the backup. Summary Through the use of Dell EMC Data Domain Boost for Enterprise Applications (DDBEA), Oracle DBA’s can take ownership of the backup operations, rather than having to rely on Backup administrators who are often tasked with different organizational challenges and success metrics. Furthermore, DBA’s can run their own reports on backup events, maintain the number of backups locally available for restores, and administer Oracle backup retention features amongst a large number of other RMAN features which are already familiar to the Oracle DBA’s. Backup and recoverability can be done rapidly and efficiently via Distributed Segment processing. This reduces the storage footprint needed to protect the Oracle database, all while conducting daily level full backups – and removes the burden of protecting these mission-critical applications from overloaded backup servers that are sometimes already stretched to back up all of the other host applications in the datazone. Happy backups!


Dell EMC believes the information in this publication is accurate as of its publication date. The

information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” DELL EMC MAKES NO RESPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Use, copying and distribution of any Dell EMC software described in this publication requires an applicable software license. Dell, EMC and other trademarks are trademarks of Dell Inc. or its subsidiaries.

Documents

TAKE BACK CONTROL OF YOUR ORACLE DATABASE BACKUPS · With the database mode confirmed to be set, we can now proceed with backing up the Oracle database. Backup. DDBEA Oracle backups