Amol Bhoite

Protect Oracle12c with Hitachi Data Instance Director in a single site

Blog Post created by Amol Bhoite on Oct 9, 2015

Why Hitachi Data Instance Director for Oracle?


Business Problem Statement


Oracle Databases form the backbone to many critical applications. Traditionally their data is protected using RMAN backups to stream data and logs to a backup target. The amount of time needed to complete backups and recoveries are not meeting business requirements.

 

Backup windows are under pressure to shrink due to the performance impact of backup and the 24/7 nature of modern business, but the amount of data to protect is constantly growing. Traditional backup takes hours to complete. This means that until backup can be completed database records may be at risk of loss, or need to be rolled back or re-entered, in the event of a failure of any type.

 

To address these problems, customers are increasingly turning to hardware-based snapshots and replication but this is not easy. Generally, in-depth knowledge is needed to create scripts to manage this hardware based data protection. Changes to the environment such as the addition of capacity need careful management and constant updating of scripts. Customers rely on staff with this deep technical knowledge during setup, maintenance and restoration of data. There is risk in having human generated scripts and there is risk in reliance on a handful of staff with this specialized knowledge.

 

Business benefit and Solution Value Propositions


This blog describes the answer to this problem from HDS is the Hitachi Data Instance Director (HDID) for Oracle 12c Real application cluster.

Having a seamless end-to-end optimized Solution for Backup and Recovery for Oracle and Data Protection.


This pretested, backup solution and Recovery can be used to accelerate data protection with redundancy, high availability and management with HDID centralized console.


High-level concepts covered:

 

  • How to Backup Oracle - Scheduled snapshot (TI)
    • How to take scheduled snapshot(TI)
  • How to Restore Oracle - Scheduled snapshot (TI)
    • Restore database using revert snapshot(TI)
    • Restore datafiles from mounted snapshot(TI)
  • How to Recover Oracle - Scheduled snapshot (TI)
    • Manual steps for database complete disaster recovery
    • Manual steps for database point in time(PIT) or system change number (SCN) recovery
    • Manual steps for datafiles recovery

 

Test Environment Overview

 

This test details about how to protect Oracle Real Application Cluster 12c database with Hitachi Data Instance Director in a single site.

 

  • Hitachi Compute Blade 2500 chassis with three full-width 520X B2 server blades
    • Server Blade 1 Oracle RAC NODE 1
    • Server Blade 2 Oracle RAC NODE 2
    • Server Blade 3Microsoft Windows® 2012 R2 Hyper-V® host with:
      • HDID Master Node VM
      • HDID Repository Node VM
  • Hitachi Virtual Storage Platform G600 with Hitachi Accelerated Flash
  • 16 Gb/sec switched SAN infrastructure
  • 10 GbE LAN infrastructure

 

Storage and Database Configuration

 

Below is the storage and database configuration used while creating a test environment.

 

Create the RAID groups and storage pools with Hitachi Dynamic Provisioning and Hitachi Thin Image on Hitachi Virtual Storage Platform G600 as shown in the below Figure 1.

Oracle Database setting and parameters are mentioned in the below tables.


 

NewStorage.png

 

Database ParametersValue
cluster_databaseTRUE
cluster_database_instances2
compatible12.1.0.2.0
db_nameHDIDDB
db_create_file_dest+DATADG
db_create_online_log_dest_1+REDODG01
db_create_online_log_dest_2+REDODG02
db_recovery_file_dest+FRADG
Archive destinationUSE_DB_RECOVERY_FILE_DEST
PGA_AGGREGATE_TARGET25 GB
DB_CACHE_SIZE16 GB
DB_KEEP_CACHE_SIZE16 GB
DB_RECYCLE_CACHE_SIZE16 GB
LOG_BUFFER255066112
USE_LARGE_PAGESTRUE
FILESYSTEMIO_OPTIONSSETALL


HDID configuration And Operations with Oracle

 

Below Table and Figure and describes which oracle database ASM disk groups are involved during HDID Snapshot, Mount, and Revert operations.

 

  • SNAPSHOT : HDID TI Snapshot will take snapshot of disk groups including Data files, Redo logs, Archive log files.
  • MOUNT : Snapshots cannot be mounted on the production server at the original location because the location is already occupied by original production database disk groups. If the original disk group is dropped, then you can only mount a snapshot at the original location.
  • REVERT : HDID TI Revert will revert only data files disk groups.

 

NewHDIDDiag.png

 

ASM Disk GroupSNAPSHOTREVERTMOUNT
OCRDGNoNoNo
CONTROLNoNoNo
REDO01YesNoNo
REDO02YesNoNo
FRADGYesNoNo
DATADGYesYesNo
DATAFMDYesYesNo

Figure 2

 

 

Lab Test Report

 

This section summarizes the key observations from the test results with Hitachi Data Instance Director for Oracle 12c Real Application Cluster Database.

 

Performing Manual Complete Database Recovery after  HDID TI Snapshot Revert

Performing Manual PIT/SCN Incomplete Recovery after  HDID TI Snapshot Revert

Performing Manual Data file Recovery of an

Open Database After HDID TI Snapshot MOUNT

TI Snapshot revert time:

7 Minutes 40 Seconds

TI Snapshot revert time

7 Minutes 40 Seconds

TI Snapshot Mount time

11 Minutes 11 Seconds

Manual Recovery Time

Approximately 5 Minutes

Manual Recovery Time

Approximately 4 Minutes

Manual Recovery Time

Approximately 6 Minutes

[oracle@hdid-oracle-rac1]$ srvctl status database -d HDIDDB

Instance HDIDDB1 is not running on node hdid-oracle-rac1

Instance HDIDDB2 is not running on node hdid-oracle-rac2

 

SQL> startup mount

ORACLE instance started.

Total System Global Area 8.1336E+10 bytes

Fixed Size                  5294184 bytes

Variable Size            8589936536 bytes

Database Buffers         7.2478E+10 bytes

Redo Buffers              263139328 bytes

Database mounted.

 

SQL> RECOVER AUTOMATIC DATABASE;

Media recovery complete.

 

SQL> ALTER DATABASE OPEN;

Database altered.

 

[oracle@hdid-oracle-rac1]$ srvctl status database -d HDIDDB

Instance HDIDDB1 is running on node hdid-oracle-rac1

Instance HDIDDB2 is not running on node hdid-oracle-rac2

 

[oracle@hdid-oracle-rac1]$ srvctl start instance -d HDIDDB -i HDIDDB2

[oracle@hdid-oracle-rac1]$ srvctl status database -d HDIDDB

Instance HDIDDB1 is running on node hdid-oracle-rac1

Instance HDIDDB2 is running on node hdid-oracle-rac2

 

[oracle@hdid-oracle-rac1 cfg]$ srvctl status database -d HDIDDB

Instance HDIDDB1 is not running on node hdid-oracle-rac1

Instance HDIDDB2 is not running on node hdid-oracle-rac2

 

SQL> startup mount;

ORACLE instance started.

Total System Global Area 8.1336E+10 bytes

Fixed Size                  5294184 bytes

Variable Size            8589936536 bytes

Database Buffers         7.2478E+10 bytes

Redo Buffers              263139328 bytes

Database mounted.

 

SQL> Recover database until time '2015-09-22:03:56:43';

ORA-00279: change 6211492 generated at 09/22/2015 03:46:56 needed for thread 1

ORA-00289: suggestion :

+FRADG/HDIDDB/ARCHIVELOG/2015_09_22/thread_1_seq_372.1139.891056821

ORA-00280: change 6211492 for thread 1 is in sequence #372

06:05:43 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

AUTO

.

.

Log applied.

Media recovery complete.

 

SQL>  ALTER DATABASE OPEN RESETLOGS;

Database altered.

 

[oracle@hdid-oracle-rac1]$  srvctl status database -d HDIDDB

Instance HDIDDB1 is running on node hdid-oracle-rac1

Instance HDIDDB2 is not running on node hdid-oracle-rac2

 

[oracle@hdid-oracle-rac1]$  srvctl start instance -d HDIDDB -i HDIDDB2

 

[oracle@hdid-oracle-rac1]$  srvctl status database -d HDIDDB

Instance HDIDDB1 is running on node hdid-oracle-rac1

Instance HDIDDB2 is running on node hdid-oracle-rac2

Find the required backup file at the mounted ASM disk group location (+DATAFMD00000), and copy it to the original disk group location.

 

 

ASMCMD>  cp +DATAFMD00000/HDIDDB/DATAFILE/hdidtbs.275.890965843 +DATAFMD/HDIDDB/DATAFILE/hdidtbs.275

copying +DATAFMD00000/HDIDDB/DATAFILE/hdidtbs.275.890965843 -> +DATAFMD/HDIDDB/DATAFILE/hdidtbs.275

 

ASMCMD> ls -lt +DATAFMD/HDIDDB/DATAFILE/hdidtbs.275

Type      Redund  Striped  Time             Sys  Name

DATAFILE  UNPROT  COARSE   OCT 03 07:00:00  N    hdidtbs.275 => +DATAFMD/ASM/DATAFILE/hdidtbs.275.289.892108615

 

ASMCMD> ls -lt +DATAFMD/ASM/DATAFILE/hdidtbs.275.289.892108615

Type      Redund  Striped  Time             Sys  Name

DATAFILE  UNPROT  COARSE   OCT 03 08:00:00  Y    hdidtbs.275.289.892108615

 

SQL> Alter database datafile '+DATAFMD/HDIDDB/DATAFILE/hdidtbs.275.890965843' offline;

Database altered.

 

SQL> ALTER DATABASE RENAME FILE '+DATAFMD/HDIDDB/DATAFILE/hdidtbs.275.890965843' TO '+DATAFMD/ASM/DATAFILE/hdidtbs.275.289.892108615';

Database altered.

 

SQL> Recover automatic datafile '+DATAFMD/ASM/DATAFILE/hdidtbs.275.289.892108615';

Media recovery complete.

 

SQL> alter database datafile '+DATAFMD/ASM/DATAFILE/hdidtbs.275.289.892108615' online;

Database altered.

 

Engineering Validation

 

This describes the test methodology and test results used to validate the testing.

 

Test Results

These are the test results.

 

Backup of an Oracle Database in a Database Availability Environment

The Backup completed successfully

Restore an Oracle Database to Overwrite an Existing Database

The restore completed successfully.

Mount Snapshot to Different Location on the Database Server

The mount completed successfully.

Manual Recovery Scenarios of an Oracle Database

The recovery completed successfully.

 

MetricValue
Oracle Database size12 TB
Database ModeArchivelog
Database Storage TypeASM
Archivelog and Flash Recovery Area LocationASM
Total number of data files85 including small and big Tablespace datafiles
Database fill factor90 %
Snapshot size7.87 GB
Snapshot time taken11 Minutes 30 Seconds
Snapshot mount time11 Minutes 11 Seconds
Snapshot Revert time7 Minutes 40 Seconds
Manual Complete recovery timeApproximately 5 Minutes
Manual PIT/SCN recovery timeApproximately 4 Minutes
Manual Data file recovery timeApproximately 6 Minutes

Outcomes