Accelerating Oracle Recoveries with NetWorker 18.1

Introduction

When NetWorker 18.1 was released, it wasn’t just the core NetWorker environment that got an update – the application and database modules  (including Microsoft modules) also got an update.

For me, one of the cooler things that got included in NMDA was a feature developed initially for the Data Domain Boost Application Plugins (“DDBEA”), which allows a faster recovery by having Data Domain compress content as it is being recovered, before it’s sent across the network to the database server.

High Speed

In most instances, you can get reasonable deduplication out of your database backups, and compressed recoveries take advantage of that by reducing the overall amount of data that has to be sent back to the database server during a recovery process. This can (particularly for larger databases) make a substantial improvement in the recovery performance, unless your database is just chock full of encrypted/precompressed data.

Simply put, a compressed recovery works along the lines of the following:

Compressed Recovery
Compressed Recovery

With the inclusion of this functionality in NMDA (for Oracle and DB2), database administrators in a NetWorker environment can now get access to this accelerated recovery option that’s been in DDBEA for a while.

While I’ve used the compressed recovery option in DDBEA, I thought its inclusion in NMDA was a perfect excuse for me to roll up my sleeves and get a little practice in with Oracle again.

To start with, I deployed a CentOS 6.9 server, and allocated using thick, eager zero’d thin provisioning:

  • OS space
  • 56 GB for the database install and data files
  • 42 GB for a flash recovery area (which I then didn’t get around to using)

I had the Oracle 12cR1 installer do its usual “do you want to create a database?” option, then to that database added a new tablespace and table, which I loaded with a pile of ‘junk’ data: half of it filenames (an initial file listing, then multiple ROT-n rotations all appended), and a million or so paragraphs from a lorem-ipsum generator. The net result was 171,313,545 rows in the table – about 26GB of data in the tablespace dedicated to that table.

So that you can seem I’m using very average lab equipment, the virtual machine specs were as follows:

  • The virtual Oracle server was running on an environment where it had 4GB of RAM and 2 x 3.2GHz vCPU, with the underlying disk being 4 x 2TB SATA 7200 RPM drives in a RAID-5 configuration.
  • The DDVE was a 0.5TB install with 6GB of RAM, 2 x 2.2GHz vCPU, and running on a consumer level SSD.
  • The NetWorker 18.1 server was running on on the same hypervisor as the DDVE, with 16GB of RAM, 2 x 2.2GHz vCPU and working on another consumer level SSD.

Moving on from that, the sequence was:

  1. Install the base 18.1 NetWorker client for Linux.
  2. Get a backup configured and run to confirm filesystem backup connectivity.
  3. Install the NMDA 18.1 module.
  4. Get a backup configured and run in NMC to confirm basic connectivity.
  5. Configure an RMAN script on the Oracle server for backup and run.
  6. Run a DDBoost Compressed recovery of the large tablespace.
  7. Run a standard (uncompressed) recovery of the large tablespace.

Let’s get cracking.

NetWorker Filesystem Client Wizard

The client wizard hasn’t changed much between NetWorker 9.x and NetWorker 18.1, but I stepped through it quickly to get a basic filesystem client for my database server, ‘aal’, configured. The sequence was pretty much the following:

01 OS Client Config
01 OS Client Config
02 OS Client Config
02 OS Client Config
03 OS Client Config
03 OS Client Config
04 OS Client Config
04 OS Client Config
05 OS Client Config
05 OS Client Config
06 OS Client Config
06 OS Client Config

With the base client configuration performed, I quickly setup an adhoc policy to run the client backup, confirming a successful standard backup. Then it was time to install the NMDA plugin on the client so I could configure the Oracle client instance.

Oracle Client Wizard

I generally recommend to use the client wizard in NetWorker to create the first instance of the Oracle client, even if DBAs are going to write and run their own RMAN scripts. This lets you do a quick sanity check that the NetWorker server can talk to the Oracle plugin/client successfully. The process I went through was as follows:

07 Oracle Client Config
07 Oracle Client Config
08 Oracle Client Config
08 Oracle Client Config
09 Oracle Client Config
09 Oracle Client Config
10 Oracle Client Config
10 Oracle Client Config
11 Oracle Client Config
11 Oracle Client Config
12 Oracle Client Config
12 Oracle Client Config
13 Oracle Client Config
13 Oracle Client Config

I then created a basic backup policy and workflow for Oracle:

14 Oracle Backup Policy
14 Oracle Backup Policy

Here’s the backup running:

15 Oracle Backup Running
15 Oracle Backup Running

And a successful backup completed:

16 Oracle Backup Complete
16 Oracle Backup Complete

RMAN Script for Full Backup

With the test backup from NMC complete, I then configured the following RMAN script on the Oracle server:

[oracle@aal backup]$ cat full.rman
connect target /

run {
allocate channel t1 type 'SBT_TAPE';
allocate channel t2 type 'SBT_TAPE';

send 'NSR_ENV=(NSR_SERVER=orilla.turbamentis.int,NSR_DATA_VOLUME_POOL=BoostBackup)';

backup full filesperset 4 format 'FULL_%d_%U' (database);
backup filesperset 10 (archivelog all delete input format 'a1_%s_%p');

release channel t1;
release channel t2;
}

Running the backup from RMAN was straight forward – sample output below:

17 Command Line Oracle Backup
17 Command Line Oracle Backup

Performing a Compressed Recovery

OK, here comes the good stuff, at last! Doing a compressed restore. The first step was to write the RMAN script calling for a Boost compressed restore. Here’s what it looked like:

[oracle@aal recovery]$ cat recover-compressed-pmdg.rman
connect target /

run {
allocate channel t1 type 'SBT_TAPE';
allocate channel t2 type 'SBT_TAPE';

send 'NSR_ENV=(NSR_SERVER=orilla.turbamentis.int,DDBOOST_COMPRESSED_RESTORE=TRUE)';

restore tablespace pmdg;
recover tablespace pmdg;

release channel t1;
release channel t2;
}

In the above RMAN script, I’ve underlined the one modification I had to make to a recovery script in order to make use of DDBoost Compressed recovery. To see that I was truly getting compression from the Data Domain, I logged onto it ahead of the recovery and grabbed some Boost statistics while the recovery was running:

18 DDBoost Recovery Stats
18 DDBoost Recovery Stats
19 DDBoost Recovery Stats
19 DDBoost Recovery Stats

The key columns are “Restore KB/s” and “Network Out KB/s” – these tell us the amount of data being read from the Data Domain, and the amount of data being transmitted to the Oracle server, respectively. So in one line for instance, 171,242 KB was read, and 24,189 KB was sent. That’s effectively a 7:1 compression ratio on data read vs transmitted – certainly nothing to sneeze at.

Here’s the key output from the recovery process showing how long it took:

20 Recovery Time Compressed
20 Recovery Time Compressed

The datafile, on disk, is 26GB, so it took 3 minutes and 26 seconds to perform that recovery. It was then time to press on to perform a standard, uncompressed recovery.

(By the way, the time/date disparity between the Data Domain and the RMAN execution simply comes from me having lazily left the Data Domain at US/Pacific timezone during initial install. The Oracle server was running in the correct, Australia/Melbourne timezone.)

Performing an Uncompressed Recovery

As you might imagine from the previous RMAN script, there’s very little difference between that script and this one. The script I used for recovery was:

[oracle@aal recovery]$ cat recover-uncompressed-pmdg.rman
connect target /

run {
allocate channel t1 type 'SBT_TAPE';
allocate channel t2 type 'SBT_TAPE';

send 'NSR_ENV=(NSR_SERVER=orilla.turbamentis.int)';

restore tablespace pmdg;
recover tablespace pmdg;

release channel t1;
release channel t2;
}

So the only difference is that this script doesn’t include the NetWorker parameter option, DDBOOST_COMPRESSED_RESTORE=TRUE. (I could have alternately left that option in, but changed it to DDBOOST_COMPRESSED_RESTORE=FALSE. As you can see, the default behaviour is to not run a compressed restore.)

Here’s the key output from the uncompressed restore:

21 Recovery Time Uncompressed
21 Recovery Time Uncompressed

So, for the same amount of data, that recovery took 7 minutes and 15 seconds.

Summing Up

Even in my very basic lab environment, I more than halved the recovery time of a 26GB tablespace by turning on the compressed recovery mode.

Now, of course, you can run multiple channels to speed up database recoveries (for Oracle, channels, and files per channel – for SQL server for instance, streams) – and those techniques will work well at parallelizing your recovery and reading more data concurrently. But if you want to look at speeding up your recovery more, you’ve now got the option of doing a Boost compressed recovery, making use of the high speed CPUs in a Data Domain, and undoubtedly the excellent CPU capabilities you’ve got in your database servers as well.

Another excellent reason to upgrade to NetWorker 18.1.

1 thought on “Accelerating Oracle Recoveries with NetWorker 18.1”

  1. Really a good one . This will definitely help us to save lots of time on larger databases especially during crash .

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.