Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Oracle Database 12c Backup and Recovery Survival Guide

You're reading from   Oracle Database 12c Backup and Recovery Survival Guide A comprehensive guide for every DBA to learn recovery and backup solutions

Arrow left icon
Product type Paperback
Published in Sep 2013
Publisher Packt
ISBN-13 9781782171201
Length 440 pages
Edition 1st Edition
Arrow right icon
Toc

Table of Contents (22) Chapters Close

Oracle Database 12c Backup and Recovery Survival Guide
Credits
About the Author
Acknowledgement
About the Author
Acknowledgement
About the Reviewers
www.PacktPub.com
Preface
1. Understanding the Basics of Backup and Recovery 2. NOLOGGING Operations FREE CHAPTER 3. What is New in 12c 4. User-managed Backup and Recovery 5. Understanding RMAN and Simple Backups 6. Configuring and Recovering with RMAN 7. RMAN Reporting and Catalog Management 8. RMAN Troubleshooting and Tuning 9. Understanding Data Pump 10. Advanced Data Pump 11. OEM12c and SQL Developer Scenarios and Examples – A Hands-on Lab Index

What is redo?


Let's look briefly at the redo process. When Oracle blocks (the smallest unit of storage in a database) are changed, including UNDO blocks, Oracle records the changes in the form of vector changes, which are referred to as redo entries or redo records. The changes are written by the server process to the redo log buffer in the System Global Area (SGA). The redo log buffer will then be flushed into the online redo logs in near real-time fashion by the log writer (LGWR) process (if the redo log buffer is too small, then you will start seeing log buffer space waits during bursts of redo generation).

The redo entries are written by the LGWR to a disk when:

  • A user issues a commit

  • The log buffer is one third full

  • The amount of unwritten redo entries is 1 MB

  • When a database checkpoint takes place

  • Otherwise every three seconds

Redo entries are written to disk when one of the situations mentioned take place first. In the event of a checkpoint, the redo entries are written before the checkpoint to ensure recoverability.

Redo log files record changes to the database as a result of transactions and internal Oracle server actions. Redo log files protect the database from loss of integrity due to system failures caused by power outages, disk failures, and so on. Redo log files must be multiplexed using different disks (use of fast disk is preferred) to ensure that the information stored in them is not lost in the event of a disk failure.

The redo log consists of groups of redo log files. A group consists of a redo log file and its multiplexed copies. Each identical copy is said to be a member of that group, and each group is identified by a number. The LGWR process writes redo records from the redo log buffer to all members of a redo log group until the file is filled or a log switch operation is requested. Then, it switches and writes to the files in the next group. Redo log groups are used in a circular fashion as shown in the following figure:

Tip

Redo log groups need to have at least two files per group, with the files distributed on separate disks or controllers so that no single disk failure destroys an entire log group. Also, never rely exclusively on your ASM disk group or the file system if they have mirrored disks underneath. Remember that mirroring will not protect your database in the event of your online redo log file being deleted or corrupted.

The loss of an entire log group is one of the most serious possible media failures you can come across because it can result in loss of data. The loss of a single member within a multiple-member log group is trivial and does not affect database operation, other than causing an alert to be published in the alert log.

Remember that redo logs heavily influence database performance because a commit cannot be completed until the transaction information has been written to the logs. You must place your redo log files on your fastest disks served by your fastest controllers. If possible, do not place any other database files on the same disks as your redo log files.

Tip

It's not advisable to place members of different groups on the same disk. That's because the archiving process reads the online redo log files and will end up competing with the LGWR process.

As a resume about redo log files and redo log groups, it is important always to:

  • Have a minimum of three redo log groups. If your database switches too often and you do not have an appropriate number of redo log groups, the LGWR process will need to wait until the next group is available before being able to overwrite it.

  • All online redo logs and standby redo logs are equal in size.

  • Tune your redo log files size to allow redo log switches to happen at no less than 20 minutes from each other at peak times.

  • Remember to place the redo log files on high performance disks.

  • Remember to have a minimum of two redo log members per group to reduce risk, and place them in different disks away from the data.

  • Do not multiplex standby redo logs to prevent additional writes in the redo transport.

Remember as mentioned earlier that it is important to note that not all Oracle databases will have the archive process enabled.

lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image