Tuesday Feb 12, 2013

RMAN Backup Strategy utilising multiple media (disk and tape)

RMANMost Database administrators are comfortable with setting up an Oracle RMAN backup strategy that is simple.  This would be along the lines of a full backup to tape or just a full backup to disk. This may be scripted or else a standard configuration from OEM grid control.  But what if someone wanted something more complex than this? 

An existing strategy at a client site was exactly this and the solution from a performance perspective the client ended up with backup runtimes reduced from hours to minutes with over 10 times performance gains. Not only this but tape contention was removed from the solution and by having the latest backup on disc faster restores were possible.  This paper discusses the issues and the solution in detail.

The client had performed a full backup on the weekend followed by an incremental backup on other days direct to tape. This solution had many issues with tape media failures causing backups to have to be re-executed as well as an excessive time taken for a backup to be completed. A typical full backup of just one of the many databases direct to tape if lucky to complete was in the region of 19 hours un-tuned. The over running RMAN backups themselves also had a large negative impact on the online and batch performance times due to over running. At the site there have also been many issues with tape restores and access to backups as well as restore times being extremely excessive. It was clear from a quick review that the direct tape media was a major bottleneck to the implementation and for capacity increasing reasons that the strategy had to change.

The new backup requirement from the client became to implement a backup strategy to utilize multiple media at the same time. This was an RMAN level-0 full backup to disk weekly and then to push this backup off to tape (retention 7 years) and retain the disk backup for only another week. On subsequent days take an incremental level-1 and follow the same strategy. The disk backups are only house kept as part of the following week full backup. This strategy is shown below in the calendar, it should also be noted that the project also did not want to use the Fast Recovery Area for backup storage. Due to the capacity required they chose to use a separate tier 3 storage disk group +BACKUP for archive log destination and backup piece destination. The fast recovery (tier 2 storage) area was then only utilized by flashback logs (when they wanted flashback on) and multiplexed control / online redo logs. This allowed for a storage reduction in required tier 2 storage and a cost saving.

From a recovery point of view if a failure were to occur, the client wanted the ability to be able to restore from the local diskgroup using the last level-0 full backup and any incremental / archive log backups / archive logs as required. If there were an issue or they needed to go further back then and only then would be a requirement to utilize the tape media management.

For support of this and further implementation help please contact the author of the paper as required.
The aims are purely for demonstration and training purposes.

Please Note these scripts were written only for demonstration purposes. They are not optimized and they have almost no error checking, so be careful!

Download The Full PDF here: backup_strategy_paper.pdf

Wednesday Jan 30, 2013

Taking the Black Magic Out Of Oracle Database Recovery



One of the biggest issues seen today with an Oracle database recovery is human error. More damage is done by administrators executing commands without a true understanding or an appreciation of the real condition of the existing Oracle database. Since the release of 11g it is interesting to question, how many administrators are actually using the RMAN recovery advisor which is now a tool built into the database?

The aim of this attached paper is to show that database recovery is not black magic. If a deep breath is taken at the point of failure and time is taken to properly diagnose the real condition of the database, whilst forming a firm action plan from what is available, and then the recovery becomes a simple straight forward process. That is providing any required backups are actually available of course!

Experience has shown that the main issue at the time of any fault is an administrator that jumps straight to the recovery phase with little or no analysis of the actual situation, potentially causing a bad situation to suddenly become worse.

The views expressed on this blog are those of the author and do not necessarily reflect the views of Oracle.  Please download the full paper for a detailed discussion as well as some recovery tricks you may not have come across.

Download The Full PDF hereMagic_Backup_Recovery.pdf


About Me Image
Andy Baker, Senior Principal Consultant for Oracle Consulting Services (@Bakers_byte), shares his news, views and ideas about the Oracle Database with a focus on innovation and emerging technologies.


« August 2016