Yesterday we saw the latest decision in the long-running legal spectacle of Oracle suing Google for allegedly infringing Oracle’s Java API.
Google defeats Oracle in Java code copyright case
I am not a lawyer, nor do I claim any depth of legal expertise. And as engineers, its easy to dismiss these events as one tech giant looking to squeeze some money from another tech giant using their lawyers instead of their products.
But as engineers, these courtroom events should directly concern us.
Increasingly the old paradigm of nightly backing up your large Oracle database to tape, or writing the backup to a NAS share which is then mysteriously swept to tape by some unseen force (the Sys Admins), is becoming an unsustainable approach when backup windows are shrinking, 24/7 availability is becoming the norm and databases are getting larger and larger.
Backup Appliances, such as Sun’s ZDLRA or EMC’s Data Domain, offer many performance and manageability advantages over traditional approaches, and much of the work of traditional backup software is now baked into the appliance itself.
A modern database backup and recovery appliance should include features such as data encryption, compression, de-duplication and remote replication as standard features, to offload those functions from the host CPUs which we want to dedicate to running the database software.
EMC’s Data Domain includes SISL technology – Stream-Informed Segment Layout – to yield some very impressive data reduction numbers using a combination of de-duplication and compression.
But what happens if we choose to use RMAN features in addition to those offered by the backup applicance? What happens if we try to encrypt, de-duplicate, or compress, an RMAN backupset that is itself encrypted or compressed?
During install of Oracle RAC 12c (188.8.131.52), the installer, or possibly the cluster verification utility reports an error:
PRVG-11850 : The system call "connect" failed with error "111" while executing exectask on node ...
So your dutiful Infrastructure Team upgrades the Data Domain backup appliance with the latest DD OS code and patches, bringing you up to the latest patch level.
After this, your RMAN backups using DD Boost start failing, and checking the sbtio.log file, which is found in the user dump destination, we see entries like this:
SBT-27970 (211074992) 04/01/16 21:45:01 ERR : [6D42:C94BFB0] ddp_open_file() failed for File: dd0205_boost/XIO11WSB_df_svr1vlas_1_1.bk, Err: 5034-nfs create failed (nfs: Permission denied)
SBT-27970 (211074992) 04/01/16 21:45:01 error 7501: sbtbackup: Could not create file XIO11WSB_df_svr1vlas_1_1.bk on host rstdd0205mgmt.us.oracle.com, error 5034
SBT-27973 (227712944) 04/01/16 21:45:01 ERR : [6D45:D929FB0] ddp_open_file() failed for File: dd0205_boost/XIO11WSB_df_t0r1vlas_1_1.bk, Err: 5034-nfs create failed (nfs: Permission denied)
SBT-27973 (227712944) 04/01/16 21:45:01 error 7501: sbtbackup: Could not create file XIO11WSB_df_t0r1vlas_1_1.bk on host rstdd0205mgmt.us.oracle.com, error 5034
Here’s a scenario I’ve been asked about a few times.
The DBA has backed up the database using RMAN and Data Domain DDBoost and dutifully stored details of the backup in the RMAN catalog.
But then he needs to restore and recover the database to a new server without the RMAN catalog.
This can happen, for example, if an entire data center goes down. Many Data Domain users use the automatic replication option, whereby Data Domain will replicate RMAN backupsets from one device to another, often to a remote data center, but without the original RMAN catalog to inspect, how do we restore and recover our database?
In an earlier post, I looked at using RMAN managed replication to make two copies of an RMAN backupset to two separate Data Domains.
In the post Replicating an RMAN Backupset with Data Domain and DD Boost I then restored the database from the secondary copy to demonstrate that RMAN managed replication could be a useful tool for DBAs to protect against data center failures.
In this example however, I am going to use Data Domain’s native Mtree replication instead of RMAN’s managed replication.
In this post, we will replicate an RMAN backupsets using RMAN managed replication and DD Boost.
In an earlier post, I showed how it was possible to use Data Domain’s Mtree replication to ensure that your Oracle RMAN backups are safely replicated to a second backup appliance when using Data Domain as an NFS target.
Replicating the RMAN backupset is important to protect databases from failures that might affect a whole data center, such as prolonged power or network failures, or events such as a flood that might destroy infrastructure.
These scenarios are rare but should they occur, having the RMAN backups of our databases available at a second location can be the different between an organization surviving such an event, or not.