Networker 8.1 was included in the July product update announcements a few weeks ago, and lots of lovely new shiny features were mentioned. One was the additional method of doing Oracle backups. This article looks at this new feature of the Networker Module for DB and Application (NMDA) version 1.5.
First let’s consider the usual ways that you can use to protect Oracle:
- Dump and sweep – the Oracle admin dumps his backups to a Flash Recovery Area (FRA), then a completely disconnected backup job sweeps the files off to the backup server. The backup server doesn’t know it is a DB backup and the recovery is in two steps.
- DB Backup Module – this is where the Oracle backup is directed using a DB module for a backup application. The data streams straight out of the Oracle server to the backup server. The potential disadvantage is that the Oracle admin feels he hasn’t got his FRA copy for fast recovery.
- Oracle direct to Data Domain – This is where the DD Boost agent is installed on an Oracle server and the RMAN script runs as usual, but the data is intercepted by the DD Boost agent, deduped and placed on a DD. In these cases it is often advantageous to have the FRA on the DD too, something that Oracle admins are often nervous to do.
NMDA 1.5 – the new workflow…
The new feature we are discussing sees Networker adding a new workflow for Oracle backups. It uses the Networker Module for DBs and Applications (NMDA 1.5) to monitor the FRA and if an RMAN backup has been written to the FRA it will initiate a Networker backup. NMDA will perform the backup into Networker where it will be indexed as an Oracle DB backup. Because the Networker backup uses RMAN SBT it will also be cataloged in Oracle. This allows the DBA to perform his usual backups to the FRA and then automagically a Networker Oracle backup will run after the DBAs backup. The DBA doesn’t need to know anything about Networker and the NMDA backup happens without his input.
Because the backup in Networker is cataloged in Oracle, it means that the DBA can access it for a one-step restore, rather than having to do the traditional file restore to the FRA then Oracle restore to the DB.
The way that NMDA 1.5 monitors the FRA to check for new RMAN backups is by using the probe-based backup feature. The probe runs based on the interval that you set in Networker, when it runs, it checks a certain condition, this condition is described below:
“DBA_DISK_BACKUP=TRUE, if the probe finds any new Oracle disk backups and no Oracle disk backup is currently running for the database, the probe triggers an NMDA scheduled backup of the new disk backups.”
A picture speaks a thousand words
So in diagrammatic form let’s look at the workflow:
18:00 – Oracle RMAN backup is running
1a – Oracle DBA runs his usual RMAN backup to the FRA, he doesn’t need any other software or knowledge of Networker.
1b – NMDA probes the FRA while the RMAN backup is running, it finds a new backup but also finds a RMAN backup in progress. NMDA backs away and waits for the next probe interval.
19:00 – FRA is all quiet…
2a – NMDA probes again and finds new backup data and no other activity on the FRA, it initiates a NMDA backup.
2b – NMDA performs an Oracle RMAN SBT backup of the contents of the FRA.
2c – Networker then updates the Oracle catalog to make it aware of the backup that just occurred.
So hope that was all clear… if not tough, I am not saying it again.