Most 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