RMAN in Oracle Database 10g Best Practices for Maximum Benefit
About The Client
Yell is a leading international directories business operating in the classified advertising market through printed, on-line and phone-based media in the UK, US, Spain and Latin America. Yell bring buyers and sellers together via the book, the phone and the web.
Overview & Challenges
Yellow relies on Oracle Recovery Manager (RMAN) for guaranteed backup and more importantly, recovery of its Oracle databases that underpin a comprehensive suite of SAP applications, servicing 1000+ UK-based employees. In addition, Yell utilizes RMAN to automate the cloning of SAP databases for QA and development purposes, and to effectively restore all databases at a secondary site in the event the production data center suffers a complete disaster or outage.
We evaluated and improved the clients’ backup and recovery systems, and developed a solution strategy to achieve the clients’ recovery window. We conducted a backup/recovery assessment exercise and helped the client define future recovery processes.
RMAN improves ability to clone Oracle Databases
Subsets of the databases are regularly cloned (or, “refreshed”) for QA and development environments. Production cloning refreshes occur on-demand. On occasion, project database refreshes are requested to different points-in-time, to accommodate various project phases. In just one day, these refreshes can incur 5+ TB of data movement.
Yell faced many challenges to support ongoing development projects. The SAP DBA group depended on a myriad of SQL and shell scripts to perform refreshes. As data volume steadily grew, refreshes were not completing within the required refresh window, which interfered with development schedules.
With RMAN, Yell consolidated to a single set of RMAN scripts accessible by all databases. By using the RMAN DUPLICATE to clone a database, Yell greatly simplified their scripts and expanded their level of automation.
RMAN enables Yell.com to
- Easily refresh an instance to the same or a different host, at a current or point-in-time, and automate renaming of datafiles
- Reduce tape consumption by 80% by utilizing incremental backups, which only backup changed blocks
- Detect physical block-level corruptions during backup and restore
- Validate block integrity of weekly full backups using RESTORE DATABASE VALIDATE
- Ensure that all files needed for restore are present
- Configure backup retention policy to easily obsolete backups that are no longer required
- Centralize backup and recovery management for 40+ databases
RMAN enables the DBAs at Yell to meet their SLA 99.99%
- Recovery time objective (RTO) for complete restore of the production databases ASAP, from declaration of disaster.
- Weekly full backup to tape completing in 5 hrs over weekend and after office night time when no active users are on system.
- Development-mandated refresh windows. For example, a 2 TB refresh to be completed in 9 hours.
Backup & Recovery Solution
- Oracle Recovery Manager, Oracle 22.214.171.124 /10.2.0.2
- 100GB to 4+ TB per database
- 50 – 400 datafiles per database
- 1,000+ named users
- Weekly incremental level 0 of production databases to tape
- Daily incremental level 1 backups
- 10+ TB across 117+ databases for QA, development environments
- Monthly RMAN DUPLICATE to refresh QA instances
- Disaster recovery time objective of 24 hrs, for restoring production databases at remote site