1. מימוש מערכות מסדי נתונים (236510)
Lecture 2 & 3 :
Oracle 12c Database Recovery
By David Itshak
Global Hebrew Virtual PASS Chapter :
Sqlsaturday Israel 2016 :
Oracle Database 11g: Administration Workshop I

2. Oracle Database 11g: Administration Workshop I 9 - 2
Reference and Credits
Apress Oracle Database Transactions and Locking Revealed (2014) Chapter 6: Redo and Undo RMAN Recipes for Oracle Database 12c: A Problem-Solution Approach, 2nd Ed. Chapter 13: Performing Flashback Recovery Oracle® Database Concepts 12c Release 1 (12.1) E Overview of Checkpoints 13.4 Overview of Instance Recovery Oracle® Database Backup and Recovery User's Guide E
Oracle Database 11g: Administration Workshop I

3. Why Backups Are So Important ?

4. Why Backups Are So Important ?

5. פיגוע ה-11 בספטמבר התאומים
                                                                      
התאומים

6. Worst Practices Failing to keep offsite backup copies of data
Failing to monitor your backup job effectively
Using manual or obsolete procedure
No written plans
Lack of backup integrity (backing up files, not DB )
Not testing the backup (no dry run)
Doing no backup at all

7. תוכנית התאוששות מאסון (DRP)
Disaster Recovery Plan
תוכנית הכוללת תהליכים, מדיניות ונהלים המשמשים להתאוששות מאסון המשבית לזמן לא קצר את התשתית הטכנולוגית החיונית לפעילותו של ארגון.
כוללת תכנון לחידוש של יישומים, נתונים, חומרה, תקשורת (כגון רשת) ואלמנטים אחרים של טכנולוגית המידע.
דוגמאות : שריפה, רעידת אדמה, הצפה, התפוצצות פצצה, קריסת בניין, מחיקה מוטעית וכדומה
0-7 7

8. מדדים (RTO) Recovery Time Objective (RPO) Recovery Point Objective
הזמן המרבי עד לחזרתה של המערכת לתפקוד מלא עבור תהליכים עסקיים שונים
(RPO) Recovery Point Objective
הזמן המרבי שלגבי ניתן לאבד מידע . כמות המידע שהארגון מוכן לאבד ? יום שלם , מספר שעות /דקות
משתנה באותה סקלה כמו RTO אבל לא תלוי בו (מערכות מסחר RPO אפס אבל RTO גדול יותר) .
Service Level Agreement
בהקשר לזה מדברים על זמינות , MTTF(Mean Time Between Failure) , MTTR (Mean time To recover)
זמינות גבוהה (Hign avalability)
יכולת של המשתמש לגשת למערכת לצורך אחזור נתונים בכל עת
חוסר זמינות= downtime
1-8 8

9. BCP – Business Continuity Plan
DRP היא קבוצת משנה של תהליך גדול יותר - הבטחת הרציפות העסקית
כוללת בנוסף תכנון של היבטים שאינם קשורים לטכנולוגית המידע כגון שמירה על אנשי מפתח , מתקנים, תקשורת
דחיפה משמעותית בעקבות פיגועי 11 בספטמבר - חוקים המחייבים חברות מסוימות (בתי חולים למשל) לנהל תוכנית התאוששות מאסון אפקטיבית.
בין 2%-4% מתקציב הטכנולוגיה בחברות הגדולות.
0-9 9

10. הפעלה מאתר מרוחק חלופי
תשתית עם מענה לצרכים מינימליזם בעת חירום: מערכות נדרשות , תקשורת , תחנות עבודה וכולי

11. סנכרון לאתר מרוחק Step 1: Baseline Step 2: Updates OR LAN/WAN LAN/WAN
Source
Target
SAN or NAS Attached hosts
of source volume(s)
Baseline copy
LAN/WAN
…... OR
Immediate Write Acknowledgement
Step 2: Updates
Source
Target
SAN or NAS Attached hosts
of changed blocks
Periodic updates
LAN/WAN
…...
Immediate Write Acknowledgement

12. X Disaster Recovery Process שחזור מטייפ גיבוי יכול לקחת ימים
Data Centric Environments
צמצום “Mean Time To Recovery” אחרי אירוע DRP
(redirect) X
LAN/WAN
Production Site
Disaster Recovery Site
(resync backwards after source restoration)

13. Oracle Data Guard Architecture
Production
Database
Network
Physical
Standby
Open R/O
Sync or Async
Redo Shipping
Redo
Apply
Backup

14. אירוע DRP אתר ראשי מסונכרן לאתר משני קרה אסון באתר ראשי
סנכרון מופסק וה- storage באתר הופך להיות פעיל . בסיסי הנתונים לR/W-
סנכרון
אתר ראשי
(Primary Site)
אתר משני
(DR Site)
השרתים הופכים להיות פעילים 14 14

15. Oracle Database 11g: Administration Workshop I 9 - 15
Types of DB Failures
Oracle Database 11g: Administration Workshop I

16. Types of DB Failures Statement Failure User Process Failure
A program attempts to enter invalid data into an Oracle table.
Programmatic logical errors.
Long data insertion job or a data import job to fail midway because there is no more room to put in the data
User Process Failure
User performing an abnormal disconnect or performing a terminal program error and losing the session connection.
As a DBA, there is not much you need to do
Oracle background processes will roll back any committed changes to the data and release the locks that were held by the abnormally disconnected user session. The user will have to reconnect after the abrupt termination.
Types of Database Failures
Since database backups are made to protect against a database failure, let’s quickly review the types of database
failures that can occur. A database can fail, either entirely or partially, for various reasons. You can recover from some
types of database failure with scarcely any effort on your part, because the Oracle database can recover automatically
from some types of failures. The more critical types of failures require you to go in and “recover” the database by using
your backups. You can divide database failures into the categories covered in the following sections.
Statement Failure
A typical example of a statement failure is when a program attempts to enter invalid data into an Oracle table. The
statement will fail because of the checks built into the data insertion process. The solution here is to clean up the data
by validating or correcting it. Sometimes a program may fail to complete because of programmatic logical errors. You
must then refer the problem to the development group for corrections.
It is fairly common for a long data insertion job or a data import job to fail midway because there is no more room
to put in the data. If you haven’t already invoked the resumable space allocation feature, you must add space to the
relevant tablespace. Another common cause of a statement failure is not having the proper privileges to perform a task.
Your task as a DBA is to simply grant the appropriate privileges for the user who invoked the failed SQL statement.
User Process Failure
Sometimes a user process may be terminated abruptly because of, say, the user performing an abnormal disconnect
or performing a terminal program error and losing the session connection. As a DBA, there is not much you need to do
here: the Oracle background processes will roll back any uncommitted changes to the data and release the locks that
were held by the abnormally disconnected user session. The user will have to reconnect after the abrupt termination.
Network Failure
A network failure can also cause a database failure. Network failures can occur because the Oracle Net listener, the
network interface card (NIC), or the network connection has failed. The DBA must configure multiple network cards
and a backup network connection and backup listener to protect against these errors. In addition, you can use the
connect-time failover feature to protect against a network failure.
Instance Failure
You experience an Oracle instance failure when your database instance comes down because of an event such as
a hardware failure, a power failure, or an emergency shutdown procedure. You may also experience an instance
shutdown when the key Oracle background process, such as PMON, shuts down because of an error condition.
Following an instance failure, first you check the alert log and trace files for any potential hints about the cause of
the instance failure. Following this, you can just restart the database instance by using the Oracle command startup
from the SQL*Plus command line.
Since the database wasn’t cleanly shut down and the database files aren’t synchronized, Oracle will perform an
automatic instance or crash recovery at this point. Oracle will automatically perform a rollback of the uncommitted
transactions by using data from the undo segments and will roll forward the committed changes it finds in the online
redo log files. You don’t need to use any sort of backup when restarting the database instance following an instance
failure. Once the uncommitted changes are backed out and the committed changes are rolled forward, the data files
are in sync again and will contain only committed data.
User Error
Inadvertently dropping a table is every DBA’s nightmare. In addition to accidentally dropping a table, users can also
wrongly modify or delete data from a table. You can use techniques such as the flashback table or the new Oracle
12c RMAN command recover table to restore a table to a previous point in time. You can use the flashback drop
feature to recover an accidentally dropped table. Of course, if the transaction isn’t committed yet, you can simply roll
back the unwanted changes. Oracle’s LogMiner tool also comes in handy in such situations.
Media Failure
Media failure occurs when you lose a disk or a disk controller fails, hindering access to your database. A head crash, a file
corruption, and the overwriting or deletion of a data file are all examples of a media failure. In general, any failure to read
from or write to a disk constitutes a media failure. Although the first four types of failures don’t require you to resort to a
backup (except the new RMAN command recover table, which does need an RMAN backup), media failure in most
cases would require performing a media recovery with the help of backups of the data files and archived redo logs.
Each type of media failure may have a different solution as far as recovery is concerned. For example, if a control
file copy is accidentally deleted, you won’t have to go to your backups. On the other hand, deleting a data file most
likely requires you to restore the data file from a backup as well as use the archived redo logs to bring the database
up-to-date. If only a few blocks in a data file are corrupt, you may use RMAN’s block media recovery feature instead of
restoring data files and performing media recovery.
In this book, we are mostly concerned with problems caused by media failures and how to recover from them.
For this reason, let’s analyze how database failures can occur because of media problems. Once your Oracle database
instance is running in open mode, it could crash because of the loss of several types of files. For example, the database
will crash if any of the following are true:
Any of the multiplexed control files are deleted or lost because of a disk failure. • You must restore
the missing control file by copying from an existing control file and restarting the instance.
• Any data file belonging to the system or the undo tablespace is deleted or lost because of a
disk failure. If you lose one of these files, the instance may or may not shut down immediately.
If the instance is still running, shut it down with the shutdown abort statement. You then start
up the database in mount state, restore the lost data file, and recover it before opening the
database for public access.
• An entire redo log group is lost. If you have at least one member of the redo log group, your
database instance can continue to operate normally. Restore the missing log file by copying
one of the other members of the same group.
The database won’t crash if any of the following are true:
• Any nonsystem or undo tablespace data file is lost. If you lose a nonsystem or undo
tablespace file, also known as a noncritical data file from the point of view of the Oracle
server, you must first restore and then recover that data file. The database instance can
continue operating in the meantime.
• At least a single member of each redo log group is available, although you might have lost
other members of one or more groups.

17. Types of DB Failures: User Error
User Accidentally dropping a table p or wrongly modify or delete data from a table.
Use flashback table or the new Oracle 12c RMAN command recover table to restore a table to a previous point in time.
Use the flashback drop feature to recover an accidentally dropped table.
If the transaction isn’t committed yet, you can simply rollback the unwanted changes or Oracle’s LogMiner tool
UPDATE BANK _TBL SET BALANCE=500
WHERE ACCOUNT_NO=123456
Types of Database Failures
Since database backups are made to protect against a database failure, let’s quickly review the types of database
failures that can occur. A database can fail, either entirely or partially, for various reasons. You can recover from some
types of database failure with scarcely any effort on your part, because the Oracle database can recover automatically
from some types of failures. The more critical types of failures require you to go in and “recover” the database by using
your backups. You can divide database failures into the categories covered in the following sections.
Statement Failure
A typical example of a statement failure is when a program attempts to enter invalid data into an Oracle table. The
statement will fail because of the checks built into the data insertion process. The solution here is to clean up the data
by validating or correcting it. Sometimes a program may fail to complete because of programmatic logical errors. You
must then refer the problem to the development group for corrections.
It is fairly common for a long data insertion job or a data import job to fail midway because there is no more room
to put in the data. If you haven’t already invoked the resumable space allocation feature, you must add space to the
relevant tablespace. Another common cause of a statement failure is not having the proper privileges to perform a task.
Your task as a DBA is to simply grant the appropriate privileges for the user who invoked the failed SQL statement.
User Process Failure
Sometimes a user process may be terminated abruptly because of, say, the user performing an abnormal disconnect
or performing a terminal program error and losing the session connection. As a DBA, there is not much you need to do
here: the Oracle background processes will roll back any uncommitted changes to the data and release the locks that
were held by the abnormally disconnected user session. The user will have to reconnect after the abrupt termination.
Network Failure
A network failure can also cause a database failure. Network failures can occur because the Oracle Net listener, the
network interface card (NIC), or the network connection has failed. The DBA must configure multiple network cards
and a backup network connection and backup listener to protect against these errors. In addition, you can use the
connect-time failover feature to protect against a network failure.
Instance Failure
You experience an Oracle instance failure when your database instance comes down because of an event such as
a hardware failure, a power failure, or an emergency shutdown procedure. You may also experience an instance
shutdown when the key Oracle background process, such as PMON, shuts down because of an error condition.
Following an instance failure, first you check the alert log and trace files for any potential hints about the cause of
the instance failure. Following this, you can just restart the database instance by using the Oracle command startup
from the SQL*Plus command line.
Since the database wasn’t cleanly shut down and the database files aren’t synchronized, Oracle will perform an
automatic instance or crash recovery at this point. Oracle will automatically perform a rollback of the uncommitted
transactions by using data from the undo segments and will roll forward the committed changes it finds in the online
redo log files. You don’t need to use any sort of backup when restarting the database instance following an instance
failure. Once the uncommitted changes are backed out and the committed changes are rolled forward, the data files
are in sync again and will contain only committed data.
User Error
Inadvertently dropping a table is every DBA’s nightmare. In addition to accidentally dropping a table, users can also
wrongly modify or delete data from a table. You can use techniques such as the flashback table or the new Oracle
12c RMAN command recover table to restore a table to a previous point in time. You can use the flashback drop
feature to recover an accidentally dropped table. Of course, if the transaction isn’t committed yet, you can simply roll
back the unwanted changes. Oracle’s LogMiner tool also comes in handy in such situations.
Media Failure
Media failure occurs when you lose a disk or a disk controller fails, hindering access to your database. A head crash, a file
corruption, and the overwriting or deletion of a data file are all examples of a media failure. In general, any failure to read
from or write to a disk constitutes a media failure. Although the first four types of failures don’t require you to resort to a
backup (except the new RMAN command recover table, which does need an RMAN backup), media failure in most
cases would require performing a media recovery with the help of backups of the data files and archived redo logs.
Each type of media failure may have a different solution as far as recovery is concerned. For example, if a control
file copy is accidentally deleted, you won’t have to go to your backups. On the other hand, deleting a data file most
likely requires you to restore the data file from a backup as well as use the archived redo logs to bring the database
up-to-date. If only a few blocks in a data file are corrupt, you may use RMAN’s block media recovery feature instead of
restoring data files and performing media recovery.
In this book, we are mostly concerned with problems caused by media failures and how to recover from them.
For this reason, let’s analyze how database failures can occur because of media problems. Once your Oracle database
instance is running in open mode, it could crash because of the loss of several types of files. For example, the database
will crash if any of the following are true:
Any of the multiplexed control files are deleted or lost because of a disk failure. • You must restore
the missing control file by copying from an existing control file and restarting the instance.
• Any data file belonging to the system or the undo tablespace is deleted or lost because of a
disk failure. If you lose one of these files, the instance may or may not shut down immediately.
If the instance is still running, shut it down with the shutdown abort statement. You then start
up the database in mount state, restore the lost data file, and recover it before opening the
database for public access.
• An entire redo log group is lost. If you have at least one member of the redo log group, your
database instance can continue to operate normally. Restore the missing log file by copying
one of the other members of the same group.
The database won’t crash if any of the following are true:
• Any nonsystem or undo tablespace data file is lost. If you lose a nonsystem or undo
tablespace file, also known as a noncritical data file from the point of view of the Oracle
server, you must first restore and then recover that data file. The database instance can
continue operating in the meantime.
• At least a single member of each redo log group is available, although you might have lost
other members of one or more groups.

18. Types of DB Failures: Media Failure
When you lose a disk or a disk controller fails
Any failure to read from or write to a disk .
Ex : A head crash, a file corruption, and the overwriting or deletion of a data file.
Require performing a media recovery with the help of backups of the data files and archived redo logs.
Types of Database Failures
Since database backups are made to protect against a database failure, let’s quickly review the types of database
failures that can occur. A database can fail, either entirely or partially, for various reasons. You can recover from some
types of database failure with scarcely any effort on your part, because the Oracle database can recover automatically
from some types of failures. The more critical types of failures require you to go in and “recover” the database by using
your backups. You can divide database failures into the categories covered in the following sections.
Statement Failure
A typical example of a statement failure is when a program attempts to enter invalid data into an Oracle table. The
statement will fail because of the checks built into the data insertion process. The solution here is to clean up the data
by validating or correcting it. Sometimes a program may fail to complete because of programmatic logical errors. You
must then refer the problem to the development group for corrections.
It is fairly common for a long data insertion job or a data import job to fail midway because there is no more room
to put in the data. If you haven’t already invoked the resumable space allocation feature, you must add space to the
relevant tablespace. Another common cause of a statement failure is not having the proper privileges to perform a task.
Your task as a DBA is to simply grant the appropriate privileges for the user who invoked the failed SQL statement.
User Process Failure
Sometimes a user process may be terminated abruptly because of, say, the user performing an abnormal disconnect
or performing a terminal program error and losing the session connection. As a DBA, there is not much you need to do
here: the Oracle background processes will roll back any uncommitted changes to the data and release the locks that
were held by the abnormally disconnected user session. The user will have to reconnect after the abrupt termination.
Network Failure
A network failure can also cause a database failure. Network failures can occur because the Oracle Net listener, the
network interface card (NIC), or the network connection has failed. The DBA must configure multiple network cards
and a backup network connection and backup listener to protect against these errors. In addition, you can use the
connect-time failover feature to protect against a network failure.
Instance Failure
You experience an Oracle instance failure when your database instance comes down because of an event such as
a hardware failure, a power failure, or an emergency shutdown procedure. You may also experience an instance
shutdown when the key Oracle background process, such as PMON, shuts down because of an error condition.
Following an instance failure, first you check the alert log and trace files for any potential hints about the cause of
the instance failure. Following this, you can just restart the database instance by using the Oracle command startup
from the SQL*Plus command line.
Since the database wasn’t cleanly shut down and the database files aren’t synchronized, Oracle will perform an
automatic instance or crash recovery at this point. Oracle will automatically perform a rollback of the uncommitted
transactions by using data from the undo segments and will roll forward the committed changes it finds in the online
redo log files. You don’t need to use any sort of backup when restarting the database instance following an instance
failure. Once the uncommitted changes are backed out and the committed changes are rolled forward, the data files
are in sync again and will contain only committed data.
User Error
Inadvertently dropping a table is every DBA’s nightmare. In addition to accidentally dropping a table, users can also
wrongly modify or delete data from a table. You can use techniques such as the flashback table or the new Oracle
12c RMAN command recover table to restore a table to a previous point in time. You can use the flashback drop
feature to recover an accidentally dropped table. Of course, if the transaction isn’t committed yet, you can simply roll
back the unwanted changes. Oracle’s LogMiner tool also comes in handy in such situations.
Media Failure
Media failure occurs when you lose a disk or a disk controller fails, hindering access to your database. A head crash, a file
corruption, and the overwriting or deletion of a data file are all examples of a media failure. In general, any failure to read
from or write to a disk constitutes a media failure. Although the first four types of failures don’t require you to resort to a
backup (except the new RMAN command recover table, which does need an RMAN backup), media failure in most
cases would require performing a media recovery with the help of backups of the data files and archived redo logs.
Each type of media failure may have a different solution as far as recovery is concerned. For example, if a control
file copy is accidentally deleted, you won’t have to go to your backups. On the other hand, deleting a data file most
likely requires you to restore the data file from a backup as well as use the archived redo logs to bring the database
up-to-date. If only a few blocks in a data file are corrupt, you may use RMAN’s block media recovery feature instead of
restoring data files and performing media recovery.
In this book, we are mostly concerned with problems caused by media failures and how to recover from them.
For this reason, let’s analyze how database failures can occur because of media problems. Once your Oracle database
instance is running in open mode, it could crash because of the loss of several types of files. For example, the database
will crash if any of the following are true:
Any of the multiplexed control files are deleted or lost because of a disk failure. • You must restore
the missing control file by copying from an existing control file and restarting the instance.
• Any data file belonging to the system or the undo tablespace is deleted or lost because of a
disk failure. If you lose one of these files, the instance may or may not shut down immediately.
If the instance is still running, shut it down with the shutdown abort statement. You then start
up the database in mount state, restore the lost data file, and recover it before opening the
database for public access.
• An entire redo log group is lost. If you have at least one member of the redo log group, your
database instance can continue to operate normally. Restore the missing log file by copying
one of the other members of the same group.
The database won’t crash if any of the following are true:
• Any nonsystem or undo tablespace data file is lost. If you lose a nonsystem or undo
tablespace file, also known as a noncritical data file from the point of view of the Oracle
server, you must first restore and then recover that data file. The database instance can
continue operating in the meantime.
• At least a single member of each redo log group is available, although you might have lost
other members of one or more groups.

19. Types of DB Failures: Network Failure
Oracle Net listener, network interface card (NIC), or the network connection has failed.
DBA must configure multiple network cards and a backup network connection and backup listener to protect against these errors.
You can use the connect-time failover feature to protect against a network failure
Types of Database Failures
Since database backups are made to protect against a database failure, let’s quickly review the types of database
failures that can occur. A database can fail, either entirely or partially, for various reasons. You can recover from some
types of database failure with scarcely any effort on your part, because the Oracle database can recover automatically
from some types of failures. The more critical types of failures require you to go in and “recover” the database by using
your backups. You can divide database failures into the categories covered in the following sections.
Statement Failure
A typical example of a statement failure is when a program attempts to enter invalid data into an Oracle table. The
statement will fail because of the checks built into the data insertion process. The solution here is to clean up the data
by validating or correcting it. Sometimes a program may fail to complete because of programmatic logical errors. You
must then refer the problem to the development group for corrections.
It is fairly common for a long data insertion job or a data import job to fail midway because there is no more room
to put in the data. If you haven’t already invoked the resumable space allocation feature, you must add space to the
relevant tablespace. Another common cause of a statement failure is not having the proper privileges to perform a task.
Your task as a DBA is to simply grant the appropriate privileges for the user who invoked the failed SQL statement.
User Process Failure
Sometimes a user process may be terminated abruptly because of, say, the user performing an abnormal disconnect
or performing a terminal program error and losing the session connection. As a DBA, there is not much you need to do
here: the Oracle background processes will roll back any uncommitted changes to the data and release the locks that
were held by the abnormally disconnected user session. The user will have to reconnect after the abrupt termination.
Network Failure
A network failure can also cause a database failure. Network failures can occur because the Oracle Net listener, the
network interface card (NIC), or the network connection has failed. The DBA must configure multiple network cards
and a backup network connection and backup listener to protect against these errors. In addition, you can use the
connect-time failover feature to protect against a network failure.
Instance Failure
You experience an Oracle instance failure when your database instance comes down because of an event such as
a hardware failure, a power failure, or an emergency shutdown procedure. You may also experience an instance
shutdown when the key Oracle background process, such as PMON, shuts down because of an error condition.
Following an instance failure, first you check the alert log and trace files for any potential hints about the cause of
the instance failure. Following this, you can just restart the database instance by using the Oracle command startup
from the SQL*Plus command line.
Since the database wasn’t cleanly shut down and the database files aren’t synchronized, Oracle will perform an
automatic instance or crash recovery at this point. Oracle will automatically perform a rollback of the uncommitted
transactions by using data from the undo segments and will roll forward the committed changes it finds in the online
redo log files. You don’t need to use any sort of backup when restarting the database instance following an instance
failure. Once the uncommitted changes are backed out and the committed changes are rolled forward, the data files
are in sync again and will contain only committed data.
User Error
Inadvertently dropping a table is every DBA’s nightmare. In addition to accidentally dropping a table, users can also
wrongly modify or delete data from a table. You can use techniques such as the flashback table or the new Oracle
12c RMAN command recover table to restore a table to a previous point in time. You can use the flashback drop
feature to recover an accidentally dropped table. Of course, if the transaction isn’t committed yet, you can simply roll
back the unwanted changes. Oracle’s LogMiner tool also comes in handy in such situations.
Media Failure
Media failure occurs when you lose a disk or a disk controller fails, hindering access to your database. A head crash, a file
corruption, and the overwriting or deletion of a data file are all examples of a media failure. In general, any failure to read
from or write to a disk constitutes a media failure. Although the first four types of failures don’t require you to resort to a
backup (except the new RMAN command recover table, which does need an RMAN backup), media failure in most
cases would require performing a media recovery with the help of backups of the data files and archived redo logs.
Each type of media failure may have a different solution as far as recovery is concerned. For example, if a control
file copy is accidentally deleted, you won’t have to go to your backups. On the other hand, deleting a data file most
likely requires you to restore the data file from a backup as well as use the archived redo logs to bring the database
up-to-date. If only a few blocks in a data file are corrupt, you may use RMAN’s block media recovery feature instead of
restoring data files and performing media recovery.
In this book, we are mostly concerned with problems caused by media failures and how to recover from them.
For this reason, let’s analyze how database failures can occur because of media problems. Once your Oracle database
instance is running in open mode, it could crash because of the loss of several types of files. For example, the database
will crash if any of the following are true:
Any of the multiplexed control files are deleted or lost because of a disk failure. • You must restore
the missing control file by copying from an existing control file and restarting the instance.
• Any data file belonging to the system or the undo tablespace is deleted or lost because of a
disk failure. If you lose one of these files, the instance may or may not shut down immediately.
If the instance is still running, shut it down with the shutdown abort statement. You then start
up the database in mount state, restore the lost data file, and recover it before opening the
database for public access.
• An entire redo log group is lost. If you have at least one member of the redo log group, your
database instance can continue to operate normally. Restore the missing log file by copying
one of the other members of the same group.
The database won’t crash if any of the following are true:
• Any nonsystem or undo tablespace data file is lost. If you lose a nonsystem or undo
tablespace file, also known as a noncritical data file from the point of view of the Oracle
server, you must first restore and then recover that data file. The database instance can
continue operating in the meantime.
• At least a single member of each redo log group is available, although you might have lost
other members of one or more groups.

20. Types of DB Failures : Instance Failure
Reasons :
A hardware failure, a power failure, or an emergency shutdown procedure.
when the key Oracle background process, such as PMON, shuts down because of an error
Oracle will perform an automatic instance or crash recovery at this point.
Oracle will automatically perform a rollback of the uncommitted transactions by using data from the undo segments and will roll forward the committed changes it finds in the online redo log files.
Once the uncommitted changes are backed out and the committed changes are rolled forward, the data files are in sync again and will contain only committed data.
Types of Database Failures
Since database backups are made to protect against a database failure, let’s quickly review the types of database
failures that can occur. A database can fail, either entirely or partially, for various reasons. You can recover from some
types of database failure with scarcely any effort on your part, because the Oracle database can recover automatically
from some types of failures. The more critical types of failures require you to go in and “recover” the database by using
your backups. You can divide database failures into the categories covered in the following sections.
Statement Failure
A typical example of a statement failure is when a program attempts to enter invalid data into an Oracle table. The
statement will fail because of the checks built into the data insertion process. The solution here is to clean up the data
by validating or correcting it. Sometimes a program may fail to complete because of programmatic logical errors. You
must then refer the problem to the development group for corrections.
It is fairly common for a long data insertion job or a data import job to fail midway because there is no more room
to put in the data. If you haven’t already invoked the resumable space allocation feature, you must add space to the
relevant tablespace. Another common cause of a statement failure is not having the proper privileges to perform a task.
Your task as a DBA is to simply grant the appropriate privileges for the user who invoked the failed SQL statement.
User Process Failure
Sometimes a user process may be terminated abruptly because of, say, the user performing an abnormal disconnect
or performing a terminal program error and losing the session connection. As a DBA, there is not much you need to do
here: the Oracle background processes will roll back any uncommitted changes to the data and release the locks that
were held by the abnormally disconnected user session. The user will have to reconnect after the abrupt termination.
Network Failure
A network failure can also cause a database failure. Network failures can occur because the Oracle Net listener, the
network interface card (NIC), or the network connection has failed. The DBA must configure multiple network cards
and a backup network connection and backup listener to protect against these errors. In addition, you can use the
connect-time failover feature to protect against a network failure.
Instance Failure
You experience an Oracle instance failure when your database instance comes down because of an event such as
a hardware failure, a power failure, or an emergency shutdown procedure. You may also experience an instance
shutdown when the key Oracle background process, such as PMON, shuts down because of an error condition.
Following an instance failure, first you check the alert log and trace files for any potential hints about the cause of
the instance failure. Following this, you can just restart the database instance by using the Oracle command startup
from the SQL*Plus command line.
Since the database wasn’t cleanly shut down and the database files aren’t synchronized, Oracle will perform an
automatic instance or crash recovery at this point. Oracle will automatically perform a rollback of the uncommitted
transactions by using data from the undo segments and will roll forward the committed changes it finds in the online
redo log files. You don’t need to use any sort of backup when restarting the database instance following an instance
failure. Once the uncommitted changes are backed out and the committed changes are rolled forward, the data files
are in sync again and will contain only committed data.
User Error
Inadvertently dropping a table is every DBA’s nightmare. In addition to accidentally dropping a table, users can also
wrongly modify or delete data from a table. You can use techniques such as the flashback table or the new Oracle
12c RMAN command recover table to restore a table to a previous point in time. You can use the flashback drop
feature to recover an accidentally dropped table. Of course, if the transaction isn’t committed yet, you can simply roll
back the unwanted changes. Oracle’s LogMiner tool also comes in handy in such situations.
Media Failure
Media failure occurs when you lose a disk or a disk controller fails, hindering access to your database. A head crash, a file
corruption, and the overwriting or deletion of a data file are all examples of a media failure. In general, any failure to read
from or write to a disk constitutes a media failure. Although the first four types of failures don’t require you to resort to a
backup (except the new RMAN command recover table, which does need an RMAN backup), media failure in most
cases would require performing a media recovery with the help of backups of the data files and archived redo logs.
Each type of media failure may have a different solution as far as recovery is concerned. For example, if a control
file copy is accidentally deleted, you won’t have to go to your backups. On the other hand, deleting a data file most
likely requires you to restore the data file from a backup as well as use the archived redo logs to bring the database
up-to-date. If only a few blocks in a data file are corrupt, you may use RMAN’s block media recovery feature instead of
restoring data files and performing media recovery.
In this book, we are mostly concerned with problems caused by media failures and how to recover from them.
For this reason, let’s analyze how database failures can occur because of media problems. Once your Oracle database
instance is running in open mode, it could crash because of the loss of several types of files. For example, the database
will crash if any of the following are true:
Any of the multiplexed control files are deleted or lost because of a disk failure. • You must restore
the missing control file by copying from an existing control file and restarting the instance.
• Any data file belonging to the system or the undo tablespace is deleted or lost because of a
disk failure. If you lose one of these files, the instance may or may not shut down immediately.
If the instance is still running, shut it down with the shutdown abort statement. You then start
up the database in mount state, restore the lost data file, and recover it before opening the
database for public access.
• An entire redo log group is lost. If you have at least one member of the redo log group, your
database instance can continue to operate normally. Restore the missing log file by copying
one of the other members of the same group.
The database won’t crash if any of the following are true:
• Any nonsystem or undo tablespace data file is lost. If you lose a nonsystem or undo
tablespace file, also known as a noncritical data file from the point of view of the Oracle
server, you must first restore and then recover that data file. The database instance can
continue operating in the meantime.
• At least a single member of each redo log group is available, although you might have lost
other members of one or more groups.

21. Types of DB Failures : Instance Failure
First phase : cache recovery or rolling forward reapplying all of the changes recorded in the online redo log to the data files.
Because rollback data is recorded in the online redo log, rolling forward also regenerates the corresponding undo segments.
Instance Recovery Phases
The first phase of instance recovery is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the online redo log to the data files. Because rollback data is recorded in the online redo log, rolling forward also regenerates the corresponding undo segments.
Rolling forward proceeds through as many online redo log files as necessary to bring the database forward in time. After rolling forward, the data blocks contain all committed changes recorded in the online redo log files. These files could also contain uncommitted changes that were either saved to the data files before the failure, or were recorded in the online redo log and introduced during cache recovery.
After the roll forward, any changes that were not committed must be undone. Oracle Database uses the checkpoint position, which guarantees that every committed change with an SCN lower than the checkpoint SCN is saved on disk. Oracle Database applies undo blocks to roll back uncommitted changes in data blocks that were written before the failure or introduced during cache recovery. This phase is called rolling back or transaction recovery. Figure illustrates rolling forward and rolling back, the two steps necessary to recover from database instance failure.

22. Types of DB Failures : Instance Failure
After rolling forward, data blocks contain all committed changes recorded in the online redo log files.
Files could also contain uncommitted changes that were either saved to the data files before the failure, or were recorded in the online redo log and introduced during cache recovery.
Instance Recovery Phases
The first phase of instance recovery is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the online redo log to the data files. Because rollback data is recorded in the online redo log, rolling forward also regenerates the corresponding undo segments.
Rolling forward proceeds through as many online redo log files as necessary to bring the database forward in time. After rolling forward, the data blocks contain all committed changes recorded in the online redo log files. These files could also contain uncommitted changes that were either saved to the data files before the failure, or were recorded in the online redo log and introduced during cache recovery.
After the roll forward, any changes that were not committed must be undone. Oracle Database uses the checkpoint position, which guarantees that every committed change with an SCN lower than the checkpoint SCN is saved on disk. Oracle Database applies undo blocks to roll back uncommitted changes in data blocks that were written before the failure or introduced during cache recovery. This phase is called rolling back or transaction recovery. Figure illustrates rolling forward and rolling back, the two steps necessary to recover from database instance failure.

23. Types of DB Failures : Instance Failure
After the roll forward, any changes that were not committed must be undone.
Oracle Database uses the checkpoint position, which guarantees that every committed change with an SCN lower than the checkpoint SCN is saved on disk.
Oracle Database applies undo blocks to roll back uncommitted changes in data blocks that were written before the failure or introduced during cache recovery.
This phase is called rolling back or transaction recovery
Instance Recovery Phases
The first phase of instance recovery is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the online redo log to the data files. Because rollback data is recorded in the online redo log, rolling forward also regenerates the corresponding undo segments.
Rolling forward proceeds through as many online redo log files as necessary to bring the database forward in time. After rolling forward, the data blocks contain all committed changes recorded in the online redo log files. These files could also contain uncommitted changes that were either saved to the data files before the failure, or were recorded in the online redo log and introduced during cache recovery.
After the roll forward, any changes that were not committed must be undone. Oracle Database uses the checkpoint position, which guarantees that every committed change with an SCN lower than the checkpoint SCN is saved on disk. Oracle Database applies undo blocks to roll back uncommitted changes in data blocks that were written before the failure or introduced during cache recovery. This phase is called rolling back or transaction recovery. Figure illustrates rolling forward and rolling back, the two steps necessary to recover from database instance failure.

24. Methods of Data Protection
Backup types
Physical backup are copies of physical database files
Logical backups are backups for logical data such as tables or Stord procedures
Backup methods :
Oracle tools : Rman ; EM Cloud control 12C
User-managed backup and recovery (OS commands ,3rd party tools )
Backup-related procedures
Data archival : Copying data to long-term storage
Data transfer : ETL or OLAP scenarios

25. Oracle Database 12C backup and Recovery Tools
Recovery Manager (Rman) command line tool
Oracle Enterprise Manager Cloud Control 12C
GUI front-end to Rman
Data Recovery Advisor (DRA) – Automated corruption detection and repair utility (Rman interface)
Oracle Data Pump:
PL/SQL packages to run from the command line
Perform logical import and exports

26. RMAM Architecture RMAN Components Recovery Manager Architecture
RMAN and Oracle Secure Backup are accessible both from the command line and
from Enterprise Manager Cloud Control (Cloud Control).
Cloud Control provides a graphical front end and scheduling facility for RMAN. You
enter job parameters, and then specify a job schedule. Cloud Control runs RMAN at
the designated time or designated repeat interval to conduct the backup and recovery
operations. Cloud Control provides access to RMAN through a set of wizards. These
wizards lead you through a variety of recovery procedures based on an analysis of
your database, your available backups, and your data recovery objectives.
By using Cloud Control, you can perform the simpler restore and recovery scenarios
outlined in this documentation. You can also use more sophisticated restore and
recovery techniques such as point-in-time recovery and Oracle Flashback operations,
which allow for efficient repair of media failures and user errors. Using Cloud Control
is often simpler than the RMAN command-line client.
The following graphic shows a sample RMAN architecture. The RMAN client,
accessible through Enterprise Manager, uses server sessions on a target database to
back up data to disk or tape. RMAN can update an external recovery catalog with
backup metadata.
Whichever backup and recovery technique you use, Oracle recommends that you
configure a fast recovery area. This database-managed directory, file system, or Oracle
ASM disk group centralizes backup and recovery files, including active control files,
online and archived redo log files, and backups. Oracle Database recovery
components interact with the fast recovery area to ensure database recoverability.

27. Preliminary Fata Protection tasks
Enable ARCHIVELOG Mode
Periodically archives (backs up)the online redo log files
Backup UNDO tablespace
Specify the fast recovery area
Configure Flashback features
Multiplex and back up the control file
Relocating you data filed to different disks : Backup on showers disks
Back up server parameter file

28. Flow of data changes through an Oracle instance and database
To understand what type of recovery is required, it’s helpful to first understand the mechanics of how Oracle
handles transactions. Here’s a typical transaction:
SQL> insert into my_table values(1);
SQL> commit;
Commit complete.
When you see Commit complete, Oracle guarantees that a record of that transaction has been safely written to the
current online redo log file on disk. That does not mean the modified block has yet been written to the appropriate
data file. The transaction information in the online redo log buffer is written very frequently to disk by the log writer
background process, whereas changes to the modified blocks in the database buffer are intermittently written to disk
by the database writer background process.
Periodically, all changed (dirty) block buffers in memory are written (by database writer) to the data files on disk.
This is known as a checkpoint. When a checkpoint occurs, the checkpoint process records the current checkpoint SCN
in the control files and the corresponding SCN in the data file headers. A checkpoint guarantees that the data files are
in a consistent state at a point in time.
The algorithm used by the log writer to write transaction information from the log buffer to the online redo log
files is entirely different from the algorithm used by the database writer to write changed blocks from the database
buffer to the data files. This is because the log buffer and the database buffer have entirely different goals. The purpose
of the log buffer is to temporarily buffer transaction changes and get them quickly written to a safe location on disk
(online redo log files), whereas the database buffer tries to keep blocks in memory as long as possible to increase the
performance of processes using frequently accessed blocks.
Because the log writer’s activities are not synchronized with the database writer’s activities, at any point in time
you could have committed transactions that exist in the online redo log file but do not yet have the corresponding
changed blocks written to the data files. Also, at any given time there might be blocks with uncommitted changes
written to the data files. This is the expected behavior. Oracle keeps track of what has been committed (or not) and
ensures that you’re always presented with a read consistent and committed version of the database. In the event of
an unexpected failure, Oracle is able to sort out what was committed or not via information in the redo stream and
rollback segments. Figure 11-1 shows a user process initiating data modifications resulting in server processes reading
blocks into memory, writing changes to memory, resulting in changed blocks written to data files and change vectors
written to redo logs.

29. Incomplete & Complete Recovery
Restore
RMAN restore command is used to retrieve data files, control files, archived redo log files, and server parameter files (spfiles) from backup sets.
it will reconstruct an exact copy of the data file as it was when it was backed up.
Recovery is the process of applying transactions from incremental backups (if using) and the redo files (archive and/or online) to the data files.
Complete recovery means you can recover all transactions that were committed
Incomplete recovery means that you cannot restore all committed transactions.
Required when you don’t have all the redo required to apply all committed transactions to the data files.
To restore the database to a previous state to recover data that was accidentally deleted.
Initiated with the recover database until command .
Oracle detects which data files need media recovery by comparing the system change number (SCN) information in the control file and the corresponding SCN information in the data file headers.
Performing Complete Recovery
Be thankful for problems. If they were less difficult, someone else with less ability might have your job.
—James A. Lovell
When an airplane is flying on autopilot through clear skies, you don’t worry too much about the pilot’s experience
level. It’s when an engine catches on fire that you want somebody who is prepared and trained to handle the disaster.
Or if the pilot isn’t trained, hopefully somebody has a comprehensive Recipes for Disasters book handy.
That also holds true in the database arena. When the database is up and running smoothly, nobody pays too
much attention to the database or the DBA. It’s when disaster strikes that companies are thankful they’ve invested in
a DBA who has implemented a solid backup and recovery strategy. It’s critical that you have a plan and understand
what to do when you see messages like the following:
ORA-01157: cannot identify/lock data file 1 - see DBWR trace file
ORA-01110: data file 1: '/u01/dbfile/o12c/system01.dbf'
No DBA likes to see that message. However, accidents happen. People do incorrect things. Disks fail. These are
all things that can cause failures. A media failure occurs when Oracle can’t read or write to a required database file.
Media recovery is the process of restoring files (from backups) and reapplying transactions (from logs) to recover the
data files that have experienced media failure. The next several paragraphs will explain the internals of the Oracle
restore and recovery process and many terms and definitions used by database administrators.
Background
Most recovery scenarios have two separate phases: restore and recovery. Restore is the process of retrieving files from
backups. Appropriately named, the RMAN restore command is used to retrieve data files, control files, archived redo
log files, and server parameter files (spfiles) from backup sets. When RMAN restores a data file, it will reconstruct an
exact copy of the data file as it was when it was backed up. RMAN is the only utility that can restore files from RMAN
backup pieces.
Recovery is the process of applying transactions from incremental backups (if using) and the redo files (archive
and/or online) to the data files. Complete recovery means you can recover all transactions that were committed
in your database before the failure occurred. You can use either RMAN or SQL*Plus to issue a recover command.
Aside from a few minor differences, it doesn’t matter whether you use RMAN or SQL*Plus to initiate a recovery.
Both result in redo being applied to data files to recover transactions. This book focuses on RMAN-initiated restore
and recovery examples.
For complete recovery, you do not have to restore and recover all the data files in your database. You have to restore
and recover only those data files that are damaged. Depending on the type of failure, that could be all the data files in
your database or just one data file. Oracle detects which data files need media recovery by comparing the system change
number (SCN) information in the control file and the corresponding SCN information in the data file headers.
Incomplete recovery means that you cannot restore all committed transactions. Incomplete recovery is required
when you don’t have all the redo required to apply all committed transactions to the data files. You can also initiate
incomplete recovery intentionally to restore the database to a previous state to recover data that was accidentally
deleted. Incomplete recovery is initiated with the recover database until command. Chapter 12 discusses
incomplete recovery. Chapter 13 discusses performing incomplete recovery via various flashback features.

30. Performing Complete Recovery
Oracle detects which data files need media recovery by comparing the system change number (SCN) information in the control file and the corresponding SCN information in the data file headers.
SCN Oracle Startup Checks
When you start your database, Oracle uses the SCN information in the control files and data file headers to
determine which one of the following will occur:
• Starting up normally
• Performing crash recovery
• Determining that media recovery is required
On startup, Oracle checks the instance thread status to determine whether crash recovery is required. When
the database is open for normal operations, the thread status is OPEN. When Oracle is shut down normally (normal,
immediate, or transactional), a checkpoint takes place, and the instance thread status is set to CLOSED.
When your instance abnormally terminates (such as from a shutdown abort command), the thread status
remains OPEN because Oracle didn’t get a chance to update the status to CLOSED. On startup, when Oracle detects that
an instance thread was abnormally left open, the system monitor process will automatically perform crash recovery.
The following query demonstrates how a single instance of Oracle would determine whether crash recovery is
required. Your database needs to be at least mounted to run this query:
SELECT
a.thread#, b.open_mode, a.status,
CASE
WHEN ((b.open_mode='MOUNTED') AND (a.status='OPEN')) THEN
'Crash Recovery req.'
WHEN ((b.open_mode='MOUNTED') AND (a.status='CLOSED')) THEN
'No Crash Rec. req.'
WHEN ((b.open_mode='READ WRITE') AND (a.status='OPEN')) THEN
'Inst. already open'
WHEN ((b.open_mode='READ ONLY') AND (a.status='CLOSED')) THEN
'Inst. open read only'
ELSE 'huh?'
END STATUS
FROM v$thread a
,gv$database b
WHERE a.thread# = b.inst_id;
Oracle will start up normally if the SCN information in the control files matches the SCNs in the corresponding
data files. If the checkpoint SCN in the data file is less than the corresponding SCN in the control file, Oracle will throw
a media recovery error. For example, if you restored a data file from a backup, Oracle would detect that the SCN in
the data file is less than the corresponding SCN in the control file. Therefore, a recovery is required to apply changes
to the data file to catch it up to the SCN in the control file. Table 11-1 summarizes the checks that Oracle performs to
determine whether crash or media recovery is required.

31. Performing Database-Level Recovery
$ rman target /
RMAN> startup mount;
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open.
How It Works
The restore database command will restore every data file in your database.
When you issue the recover database command, RMAN will automatically apply redo to any data files that need recovery.
The recovery :
• Incremental backup pieces (applicable only if using incremental backups)
• Archived redo log files (generated since the last backup or last incremental backup that is applied)
Online redo log files (current and unarchived)
Performing Database-Level Recovery
Problem
You’ve lost all of your data files but still have your online redo log files. You want to perform complete recovery.
Solution
You can perform a complete database-level recovery in this situation with either the current control file or a backup
control file.
Use Current Control File
You must first put your database in mount mode to perform a database-wide restore and recovery. This is because the
system tablespace data file(s) must be offline when being restored and recovered. Oracle won’t allow you to operate
your database in open mode with the system data file offline.
In this scenario, we simply start up the database in mount mode, issue the restore and recover commands, and
then open the database:
$ rman target /
RMAN> startup mount;
RMAN> restore database;
RMAN> recover database;
RMAN> alter database open;
If everything went as expected, the last message you should see is this:
Statement processed
If you’re using an older version of the database, the prior message may say “database opened.”
At this point you have restored and recovered the database to the point right before the media failure.
All committed transactions prior to the point of failure have been recovered.
■■Note Y our database has to be at least mounted to restore data files using RMAN . This is because RMAN reads
information from the control file during the restore and recovery process.
Keep in mind that if you’re using a recovery catalog, you should connect to it when performing restore and
recover operations, for example:
$ rman target / catalog
You’ll have to modify the prior information to match your environment

32. Performing Flashback Recovery
Flashback Database : Rewind a DB to an earlier time
Undropping a table : When the table is dropped, it’s it is renamed and placed recycle bin .You can reinstate the dropped table using only one simple command.
Flashing back a table : You can pull the changes made to the row data from the undo segments, as long as they are available in the undo segments . When you pull the older versions of the table, you can reinstate the entire table to a point in time in the past using these past images.
Recovering a single table from backup : You have dropped a table. Now it is gone from the recycle bin. Recover a single table, or a single partition of with a single command .
Introducing Flashback
There are four flavors of flashback:
• Flashing back a database
• Undropping a table
• Flashing back a table
• Recovering a single table from backup
Flashing Back a Database
Many times you might need to roll back the database to a point in time in the past. In earlier releases, this functionality
was present but in a very different way. For instance, in Oracle9i Database and prior versions, you would reinstate
an older backup and then roll it forward to a point in time in the past. For instance, suppose today is January 21 and
the time is 10 a.m. The database backups are taken at 5 a.m. every day. If you wanted to roll the database back to
10 p.m. January 20, you would restore the backup taken at 5 a.m. January 20 and then apply all the archived redo logs
to restore it to 10 p.m. But what if you made a mistake in your calculation and the data you wanted to recover was
deleted at 9 p.m.? After you recovered the database up to 10 p.m., all your work was in vain. There is no going back to
9 p.m.; you would have to start the process again from the beginning—restore the backup of 5 a.m. and then roll
forward all the changes by applying logs up to 9 p.m.
Oracle Database 10g changed all that by introducing a feature called flashback database. You enable flashback
on the database. This causes additional logs to be created during the database operation. These logs, called flashback
logs, are generated along with the regular archived logs. The flashback logs record changes to the database blocks
exclusively for the purpose of rolling back the block changes, so they are different from archived logs. When you flash
the database back to a point in the past, these flashback logs are read and applied to the database blocks to undo the
changes. The entire database is transported to that point in time.
Undropping a Table
This has happened to the best of us—you dropped a very important table. What can you do? In versions prior to
Oracle Database 10g Release 1, there wasn’t any choice other than to restore the backup of the corresponding
tablespace to another database, recover the tablespace, export the table, and import the table to the production
database. These tasks are time-consuming and risky, and the table is unavailable throughout them.
Starting with Oracle Database 10g, the process is less threatening. When the table is dropped, it’s not really erased
from the database; rather, it is renamed and placed in a logical container called the recycle bin, similar to the Recycle
Bin found in Windows. After you realize the mistake, you can reinstate the dropped table using only one simple
command. Who says you can’t revive the dead?
Flashing Back a Table
The Oracle9i Database introduced a feature called flashback query. When the data in the database changes,
the past images of the changed data are stored in special segments called undo segments. The reason for storing this
data is simple—if the changed data is not committed yet, the database must reconstruct the prechange data to present
a read-consistent view to the other users selecting the same data item. When the change is committed, the need for
the past image is gone, but it’s not discarded. The space is reused if necessary. The reason for keeping it around is
simple, too.
The read-consistency requirement does not stop after the data changes are committed. For instance,
a long-running query needs a read-consistent view when the query started, which could be well in the past. If the
query refers to the data that might have been changed and committed in the recent past, after the query has started,
the query must get the past image, not the image now, even though it is committed. If the query finds that the past
data is no longer available, it throws the dreaded ORA-1555 Snapshot Too Old error.
Anyway, what does the ORA-1555 error have to do with flashback operation? Plenty. Since the past image of the data
is available in the undo segment for a while, why should a long-running query be the only one to have fun? Any query
can benefit from that past image, too. That thought gave rise to flashback queries in Oracle9i Database where you could
query data as of a time in the past. With Oracle Database 10g, that functionality was made richer with flashback version
queries, where you can pull the changes made to the row data from the undo segments, as long as they are available in
the undo segments, of course. And when you pull the older versions of the table, you can effectively reinstate the entire
table to a point in time in the past using these past images. This is known as flashing back the table.
Recovering a Table
Suppose you have dropped a table. Now it is gone from the recycle bin, so you can’t get it out from there using the
undrop process mentioned earlier in this section. The only option is to get it from the backup. However, database
recovery recovers the entire database from backup and will overwrite all data as of that point in time in the past. When
all you want is to recover a single table from the backup, you can’t just surgically extract the table from the backup.
Instead, you have to create a temporary instance and recover the tablespace containing the table to the very point just
prior to the time the table was dropped. However, you need to restore and recover some other mandatory tablespaces,
such as system, sysaux, and one or more undo tablespaces. Once they are restored, you will need to recover that
temporary database to the required time, extract the table using Data Pump, and import it into the main database.
All this is a lot of work.
Oracle Database 12.1 introduces a new feature to recover a single table, or even a single partition of a table from
the backup. A single command accomplishes that objective. The job of recovering a single table is now much easier
than before.
In this chapter, you will learn to use all four types of flashback operations.

33. Flashback works both back and forth
Flashback Database
Rewind a DB to an earlier time
Enable flashback on DB
SQL> alter database flashback on;
Database altered.
Additional logs to be created during the database operation : flashback logs with the regular archived logs.
Flashback logs record changes to DB blocks exclusively for the purpose of rolling back the block changes.
When you flash DB back to a point in the past, these flashback logs are read and applied to the database blocks to undo the changes.
Entire DB is transported to that point in time.
You can flash back to the following
A specific point in time, specified by date and time
A specific SCN number
The last resetlogs operation
A named restore point
Flashback works both back and forth

34. Oracle Flashback Flashback VS Redo Fast & Easy querying/disaster tool
We can view past states of DB Objects and optionally return DB objects to those previous states
DB manage undo segments in undo tablespace (AUM)
Flashback VS Redo

35. Flashback Database to a specific SCN
Check the SCN of DB now
SQL> select current_scn 2 from v$database;
CURRENT_SCN
rman target=/
RMAN> shutdown immediate
RMAN> startup mount
Flash DB back to your desired SCN
RMAN> flashback database to scn ;
Starting flashback at 03-AUG-12 ….
Finished flashback at 03-AUG-12
RMAN> alter database open read only;
Database opened.
Check the data in the table ,if OK open DB . You can start the flashback process again to flash back to a different SCN.
RMAN> alter database open resetlogs;
database opened

36. Recovering a Dropped Table
1. Log on to the database as the table owner.
2. Check whether the table exists in the recycle bin. Issue the SQL*Plus command show recyclebin:
SQL> show recyclebin
3. Revive the table from the recycle bin by issuing the following SQL*Plus command:
SQL> flashback table test to before drop;
Flashback complete.
The table is now available in the database.
Recovering a Dropped Table
Problem
You accidentally dropped a table that should not have been dropped. You want to reinstate the table without doing a
database recovery.
Solution
If you dropped the table just moments ago, it is not actually dropped; it is placed in the recycle bin. Assume that you
dropped the table ACCOUNTS and want to revive it. You can resurrect that table from the recycle bin by following
these steps:
1. Log on to the database as the table owner.
2. Check whether the table exists in the recycle bin. Issue the SQL*Plus command show
recyclebin:
SQL> show recyclebin
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
TEST BIN$xmtCqONCcZjgQ4CohAoD7Q==$0 TABLE :01:53:19
The presence of the table TEST under the column ORIGINAL_NAME indicates that the
table is still present in the recycle bin and can be revived. If you see multiple entries with
the same ORIGINAL_NAME, it indicates the table was dropped, another table was created
with the same name, that table was dropped, too, and so on, for however many duplicate
entries you have. Recipe shows how to handle a situation in which you have
duplicate names in the recycle bin.
3. Revive the table from the recycle bin by issuing the following SQL*Plus command:
SQL> flashback table test to before drop;
Flashback complete.
The table is now available in the database.

37. Querying the History of a Table Row (Flashback Query)
Find all the changes to the row for ACCNO 3760 in table ACCOUNTS:
select acc_status, versions_starttime, versions_startscn, versions_endtime, versions_endscn,versions_xid, versions_operation
from accounts
versions between scn minvalue and maxvalue
where accno = 3760
order by 3
using timestamps :
versions between timestamp to_date(’7/12/ :00:00’, ’mm/dd/yyyy hh24:mi:ss’)
Using SCNs :
versions between SCN 1000 and 2000
Querying the History of a Table Row (Flashback Query)
Problem
You want to find how the values of the columns in a row have changed over a period of time.
Solution
To find all the changes to the row for ACCNO 3760 in table ACCOUNTS, issue the following query:
SQL> select
2 acc_status,
3 versions_starttime,
4 versions_startscn,
5 versions_endtime,
6 versions_endscn,
7 versions_xid,
8 versions_operation
9 from accounts
10 versions between scn minvalue and maxvalue
11 where accno = 3760
12 order by 3
13 /
The result comes back as follows:
A VERSIONS_STARTTIME VERSIONS_STARTSCN VERSIONS_ENDTIME VERSIONS_ENDSCN ➥
VERSIONS_XID V
A 12-JUL PM JUL PM
02002F00D U
I 12-JUL PM JUL PM
08001B00DB U
A 12-JUL PM
07002B U
A 12-JUL PM
The results show how the values of the column ACC_STATUS were changed at different points in time. Note the
column VERSIONS_OPERATION, which shows the DML operation that modified the value of the corresponding row.
The values are as follows:
I: Insert
U: Update
D: Delete
In the example output, you can see that on July 12, 2012, at 4:38:57 p.m. (the value of the column
VERSIONS_STARTTIME), someone updated the value of a row by using an Update operation. The SCN at that time
was The ACC_STATUS column was changed to A at that time. This value was unchanged until July 12, 2012,
at 4:39:03 p.m. (the value of column VERSIONS_ENDTIME).
As shown in the second record of the output, on July 12, 2012, at 4:39:03 p.m. and at SCN , another update
operation updated the ACC_STATUS to I. This is how you read the changes to the table row where ACCNO is 3760.
Note the line where VERSIONS_ENDTIME is null. This indicates the current row, which has not been changed yet.
In addition to the SCN, you can also use timestamp as a predicate, as shown here:
10 versions between timestamp minvalue and maxvalue
11 where accno = 3762
12 order by 3;
In the previous example, you specified the predicate to get all the available records. Note line 10:
versions between timestamp minvalue and maxvalue
This predicate indicates the minimum and maximum values of the timestamps available. You can specify exact
values for these as well. To get the versions on July 12 between noon and 3 p.m., you need to rewrite the query by
modifying line 10 to this:
versions between timestamp to_date(’7/12/ :00:00’, ’mm/dd/yyyy hh24:mi:ss’)
and to_date(’7/12/ :00:00’, ’mm/dd/yyyy hh24:mi:ss’)
Instead of using timestamps, you can use SCNs, such as between 1000 and 2000, to get the versions of the row.
In that case, line 10 becomes this:
versions between SCN 1000 and 2000
If you don’t see any data under the pseudocolumns, the reasons could be one of the following:
• The information has aged out of the undo segments.
• The database was recycled after the changes occurred.
How It Works
When a row is updated, the database records the relevant change details in the database blocks, in addition to
some other related details, such as the SCN of when the change occurred, the timestamp, the type of operation that
resulted in the change, and so on—a sort of “metadata” about the changes, if you will. This metadata is stored in
pseudocolumns and can be queried afterward.
Table 13-4 describes the flashback query pseudocolumns. The pseudocolumns that start with VERSIONS, such
as VERSIONS_STARTTIME, are not actually part of the table. They are computed and shown to the user at runtime.
A good everyday example of such a pseudocolumn is ROWNUM, which denotes the serial number of a row in the
returned result set. This column is not stored in the table but is computed and returned to the user when the query is
executed. Since these columns are not part of the table’s definition, they are called pseudocolumns.
Table Flashback Query Pseudocolumns
Pseudo Column Name Description
VERSIONS_STARTTIME This is the timestamp when this version of the row became effective. This is the
commit time after the row was changed.
VERSIONS_STARTSCN This is the SCN when this version became effective.
VERSIONS_ENDTIME This is the timestamp when the version became old, replaced by a new version.
This is the time of commit after the row was changed.
VERSIONS_ENDSCN This is the SCN when the row’s version was changed.
VERSIONS_XID This is the transaction ID that changed the row’s version. This can be joined with the
XID column of the dictionary view FLASHBACK_TRANSACTION_QUERY to show
the transaction that made this change. The view FLASHBACK_TRANSACTION_QUERY
also shows other relevant details of the transaction, such as who did it, when, and so on.
VERSIONS_OPERATION This is the abbreviated activity code—I, U, or D—for Insert, Update, or Delete that
resulted in this version of the row.

38. Querying the History of a Table Row (Flashback Query)
Flashback Query Pseudocolumns:
Querying the History of a Table Row (Flashback Query)
Problem
You want to find how the values of the columns in a row have changed over a period of time.
Solution
To find all the changes to the row for ACCNO 3760 in table ACCOUNTS, issue the following query:
SQL> select
2 acc_status,
3 versions_starttime,
4 versions_startscn,
5 versions_endtime,
6 versions_endscn,
7 versions_xid,
8 versions_operation
9 from accounts
10 versions between scn minvalue and maxvalue
11 where accno = 3760
12 order by 3
13 /
The result comes back as follows:
A VERSIONS_STARTTIME VERSIONS_STARTSCN VERSIONS_ENDTIME VERSIONS_ENDSCN ➥
VERSIONS_XID V
A 12-JUL PM JUL PM
02002F00D U
I 12-JUL PM JUL PM
08001B00DB U
A 12-JUL PM
07002B U
A 12-JUL PM
The results show how the values of the column ACC_STATUS were changed at different points in time. Note the
column VERSIONS_OPERATION, which shows the DML operation that modified the value of the corresponding row.
The values are as follows:
I: Insert
U: Update
D: Delete
In the example output, you can see that on July 12, 2012, at 4:38:57 p.m. (the value of the column
VERSIONS_STARTTIME), someone updated the value of a row by using an Update operation. The SCN at that time
was The ACC_STATUS column was changed to A at that time. This value was unchanged until July 12, 2012,
at 4:39:03 p.m. (the value of column VERSIONS_ENDTIME).
As shown in the second record of the output, on July 12, 2012, at 4:39:03 p.m. and at SCN , another update
operation updated the ACC_STATUS to I. This is how you read the changes to the table row where ACCNO is 3760.
Note the line where VERSIONS_ENDTIME is null. This indicates the current row, which has not been changed yet.
In addition to the SCN, you can also use timestamp as a predicate, as shown here:
10 versions between timestamp minvalue and maxvalue
11 where accno = 3762
12 order by 3;
In the previous example, you specified the predicate to get all the available records. Note line 10:
versions between timestamp minvalue and maxvalue
This predicate indicates the minimum and maximum values of the timestamps available. You can specify exact
values for these as well. To get the versions on July 12 between noon and 3 p.m., you need to rewrite the query by
modifying line 10 to this:
versions between timestamp to_date(’7/12/ :00:00’, ’mm/dd/yyyy hh24:mi:ss’)
and to_date(’7/12/ :00:00’, ’mm/dd/yyyy hh24:mi:ss’)
Instead of using timestamps, you can use SCNs, such as between 1000 and 2000, to get the versions of the row.
In that case, line 10 becomes this:
versions between SCN 1000 and 2000
If you don’t see any data under the pseudocolumns, the reasons could be one of the following:
• The information has aged out of the undo segments.
• The database was recycled after the changes occurred.
How It Works
When a row is updated, the database records the relevant change details in the database blocks, in addition to
some other related details, such as the SCN of when the change occurred, the timestamp, the type of operation that
resulted in the change, and so on—a sort of “metadata” about the changes, if you will. This metadata is stored in
pseudocolumns and can be queried afterward.
Table 13-4 describes the flashback query pseudocolumns. The pseudocolumns that start with VERSIONS, such
as VERSIONS_STARTTIME, are not actually part of the table. They are computed and shown to the user at runtime.
A good everyday example of such a pseudocolumn is ROWNUM, which denotes the serial number of a row in the
returned result set. This column is not stored in the table but is computed and returned to the user when the query is
executed. Since these columns are not part of the table’s definition, they are called pseudocolumns.
Table Flashback Query Pseudocolumns
Pseudo Column Name Description
VERSIONS_STARTTIME This is the timestamp when this version of the row became effective. This is the
commit time after the row was changed.
VERSIONS_STARTSCN This is the SCN when this version became effective.
VERSIONS_ENDTIME This is the timestamp when the version became old, replaced by a new version.
This is the time of commit after the row was changed.
VERSIONS_ENDSCN This is the SCN when the row’s version was changed.
VERSIONS_XID This is the transaction ID that changed the row’s version. This can be joined with the
XID column of the dictionary view FLASHBACK_TRANSACTION_QUERY to show
the transaction that made this change. The view FLASHBACK_TRANSACTION_QUERY
also shows other relevant details of the transaction, such as who did it, when, and so on.
VERSIONS_OPERATION This is the abbreviated activity code—I, U, or D—for Insert, Update, or Delete that
resulted in this version of the row.

39. Flashing Back a Specific Table
This prepares the table for flashback
SQL> alter table accounts enable row movement;
Table altered.
Flash the table back to a specific timestamp:
SQL> flashback table accounts to timestamp to_date (’12-JUL ’, ’dd-MON-YY hh24.mi.ss’);
Flashback complete.
You can flash back to a specific SCN as well
If you have gone too far into the past, you can flash “forward” using the same flashback statement
Flashing Back a Specific Table
Problem
You want to flash back a specific table, not the entire database, to a point in time in the past.
Solution
The table can be flashed back with a specialized adaptation of flashback queries. Here are the steps on how to do it:
1. Make sure the table has row movement enabled:
SQL> select row_movement
2 from user_tables
3 where table_name = ’ACCOUNTS’;
ROW_MOVE
ENABLED
If the output comes back as DISABLED, enable it by issuing this SQL statement:
SQL> alter table accounts enable row movement;
Table altered.
This prepares the table for flashback.
3. Check the table to see how far into the past you can flash it back. Use Recipe 13-6 to
determine how far back into the past you can go.
4. Flash the table back to a specific timestamp:
SQL> flashback table accounts to timestamp to_date (’12-JUL ’, ’dd-MON-YY hh24.mi.ss’);
Flashback complete.
You can flash back to a specific SCN as well:
5. Check the data in the table to make sure you have flashed back to the exact point you want.
If the flashback was not enough, you can flash the table back once more to a point even
further in the past. For instance, the previous step reinstated the table as of 6:23 p.m.,
which was not enough. In this step, you will flash it back to one more minute in the
past—to 6:22 p.m.
SQL> flashback table accounts to timestamp to_date (’12-JUL ’,
’dd-MON-YY hh24.mi.ss’);
6. If you have gone too far into the past, you can flash “forward” using the same flashback
statement:
SQL> flashback table accounts to timestamp to_date (’12-JUL ’,
As you can see, you can flash the table back and forth until you arrive at the exact point.
The flashback is complete. Since the table was not dropped, all dependent objects, such as triggers and indexes,
remain unaffected.

40. Recovering a Specific Table from Backup
You can specify the point in time using timestamp ot SCN
RMAN> connect target ’/ as sysdba’
RMAN> recover table SCOTT.ACCOUNTS
2> until time ’sysdate-1/60/24’
3> auxiliary destination ’+DG1’ ;
2> until scn
3> auxiliary destination ’+DG1’;
High-level steps in that operation:
Create another database instance.
Restore from the backup the tablespace containing that table along with system, sysaux and undo tablespaces in a different location.
Open that restored database.
Export the table.
Import into the main database.
Drop this temporary database and delete the instance
Recovering a Specific Table from Backup
Problem
You want to restore a specific table, not the entire database. The table is no longer in the recycle bin, but you do have
the RMAN backup.
Solution
Oracle Database 12.1 introduces a new feature that enables you to recover a table or a partition from an RMAN
backup. You can restore just the table or partion, without needing to restore the entire, containing tablespace.
Here are the steps to recover a table named ACCOUNTS in the SCOTT schema:
1. Make sure the database is in archivelog mode:
SQL> select log_mode from v$database;
LOG_MODE
ARCHIVELOG
2. Make sure the database is open in read/write mode:
SQL> select open_mode from v$database;
OPEN_MODE
READ WRITE
3. Choose where a temporary database can be created for the duration of the RMAN
operation. Designate a file system or an ASM disk group–the choice is yours. Just be sure
you choose a destination having enough space to hold SYSTEM, SYSAUX, and Undo
tablespaces along with the tablespace that holds the table. In this example, we will use the
disk group DG1.
4. Decide the point in time to restore the table to. You can specify the point in time using
either of:
a. The timestamp
b. The SCN
In this example, in step 4, we specify recovery up to one minute prior to the current time.
Since a day has 24 hours, and an hour has 60 minutes, the expression sysdate - 1/60/24
represents the time just one minute ago.
Pay careful attention to choosing the time. The table you are recovering must have been
present in the database at that time. If the table was dropped prior to that time, the
recovery will fail with "RMAN-05057: Table not found" error.
5. Connect to RMAN:
$ rman
RMAN> connect target ’/ as sysdba’
6. Issue the following command from RMAN. Be sure to plug in your chosen point in time:
RMAN> recover table SCOTT.ACCOUNTS
2> until time ’sysdate-1/60/24’
3> auxiliary destination ’+DG1’
4> ;
The command will execute with a long output, which is not reproduced here for the sake
of brevity. At the end, the table will be reinstated in the database from the backup.
If you know the SCN, you can use that instead of the timestamp. For example:
2> until scn

41. Block Media Recovery
When RMAN first detects missing or corrupt redo records during block media recovery, it does not immediately signal an error because the block undergoing recovery may create one later in the redo stream.
After block recovery begins, RMAN discovers that change 120 is missing from the redo stream, either because the log block is corrupt or because the log cannot be found. RMAN continues recovery if block 13 is re-created later in the redo stream.
Assume that in change 140 a user drops the table employees stored in block 13, allocates a new table in this block, and inserts data into the new table. At this point, the database formats block 13 as a new block. Recovery can now proceed with this block even though some redo preceding the recreation operation was missing
Block Media Recover
When RMAN first detects missing or corrupt redo records during block media recovery, it does not immediately signal an error because the block undergoing recovery may create one later in the redo stream.
When a block is re-created, all previous redo for that block becomes irrelevant because the redo applies to an old incarnation of the block. For example, the database creates a new a block when users drop or truncate a table and then use the block for other data.
After block recovery begins, RMAN discovers that change 120 is missing from the redo stream, either because the log block is corrupt or because the log cannot be found. RMAN continues recovery if block 13 is re-created later in the redo stream. Assume that in change 140 a user drops the table employees stored in block 13, allocates a new table in this block, and inserts data into the new table. At this point, the database formats block 13 as a new block. Recovery can now proceed with this block even though some redo preceding the recreation operation was missing

42. Oracle Database 11g: Administration Workshop I 9 - 42
Appendix & Extra Material
Oracle Database 11g: Administration Workshop I

43. Redo and Undo : Transaction Rollback
When a ROLLBACK statement is issued, the database uses undo records to roll back changes made to the database by the uncommitted transaction.
During recovery, DB rolls back any uncommitted changes applied from the online redo log to the data files.
Undo records provide read consistency by maintaining the before image of the data for users accessing data at the same time that another user is changing it
Redo and Undo
Key to Oracle’s durability (recovery) mechanism is redo, and core to multiversioning (read consistency) is undo.
Oracle uses redo to capture how the transaction changed the data; this allows you to replay the transaction (in the
event of an instance crash or a media failure). Oracle uses undo to store the before image of a modified block; this
allows you to reverse or rollback a transaction.

44. How Redo and Undo Work Together
What happens during the processing of an INSERT with regard to redo and undo generation
How Oracle uses this information in the event of failures at various points in time?
Undo information, stored in undo tablespaces or undo segments, is protected by redo as well.
undo data is treated just like table data or index data—changes to undo generates some redo is logged to the log buffer and then the redo log file.
Why ?
Undo data is added to the undo segment and is cached in the buffer cache, just like any other piece of data would be.

45. Example INSERT-UPDATE-DELETE-COMMIT Scenario
created a table with an index as follows:
create table t(x int, y int);
create index ti on t(x);
what might happen with a set of statements like this:
insert into t (x,y) values (1,1);
update t set x = x+1 where x = 1;
delete from t where x = 2;
What happens if the system fails a t various points in the processing of these statements?
What happens if the buffer cache fills up?
What happens if we ROLLBACK at any point?
What happens if we succeed and COMMIT?
Example INSERT-UPDATE-DELETE-COMMIT Scenario
For this example, assume we’ve created a table with an index as follows:
create table t(x int, y int);
create index ti on t(x);
And then we will investigate what might happen with a set of statements like this:
insert into t (x,y) values (1,1);
update t set x = x+1 where x = 1;
delete from t where x = 2;
We will follow this transaction down different paths and discover the answers to the following questions:
What happens if the system fails a • t various points in the processing of these statements?
• What happens if the buffer cache fills up?
• What happens if we ROLLBACK at any point?
• What happens if we succeed and COMMIT?

46. The INSERT
The initial INSERT INTO T statement will generate both redo and undo.
The undo generated will be enough information to make the INSERT “go away.”
The redo generated by the INSERT INTO T will be enough information to make the INSERT “happen again.”
The INSERT
The initial INSERT INTO T statement will generate both redo and undo. The undo generated will be enough
information to make the INSERT “go away.” The redo generated by the INSERT INTO T will be enough information to
make the INSERT “happen again.”
After the INSERT has occurred, we have the scenario illustrated in Figure
There are some cached, modified undo blocks, index blocks, and table data blocks. Each of these blocks is
protected by entries in the redo log buffer.

47. Hypothetical Scenario: The System Crashes Right Now
System crashes before a COMMIT is issued or before the redo entries are written to disk.
Everything is OK.
SGA is wiped out, but we don’t need anything that was in the SGA.
It will be as if this transaction never happened when we restart.
None of the blocks with changes got flushed to disk, and none of the redo got flushed to disk.
We have no need of any of this undo or redo to recover from an instance failure.
Hypothetical Scenario: The System Crashes Right Now
In this scenario, the system crashes before a COMMIT is issued or before the redo entries are written to disk. Everything
is OK. The SGA is wiped out, but we don’t need anything that was in the SGA. It will be as if this transaction never
happened when we restart. None of the blocks with changes got flushed to disk, and none of the redo got flushed to
disk. We have no need of any of this undo or redo to recover from an instance failure.

48. Hypothetical Scenario: The Buffer Cache Fills Up Right Now
DBWn must make room and our modified blocks are to be flushed from the cache.
DBWn will start by asking LGWR to flush the redo entries that protect these database blocks. Before DBWn can write any of the blocks that are changed to disk, LGWR must flush (to disk) the redo information related to these blocks.
At this point, We have generated some modified table and index blocks. These have associated undo segment blocks, and all three types of blocks have generated redo to protect them.
Hypothetical Scenario: The Buffer Cache Fills Up Right Now
The situation is such that DBWn must make room and our modified blocks are to be flushed from the cache. In this case, DBWn will start by asking LGWR to flush the redo entries that protect these database blocks. Before DBWn can write any of the blocks that are changed to disk, LGWR must flush (to disk) the redo information related to these blocks.
This makes sense: if we were to flush the modified blocks for table T (but not the undo blocks associated with the modifications) without flushing the redo entries associated with the undo blocks, and the system failed, we would
have a modified table T block with no undo information associated with it. We need to flush the redo log buffers before writing these blocks out so that we can redo all of the changes necessary to get the SGA back into the state it is in right now, so that a rollback can take place.
This second scenario shows some of the foresight that has gone into all of this. The set of conditions described by “If we flushed table T blocks and did not flush the redo for the undo blocks and the system failed” is starting to get complex. It only gets more complex as we add users, and more objects, and concurrent processing, and so on.
At this point, we have the situation depicted in Figure 6-1. We have generated some modified table and index blocks. These have associated undo segment blocks, and all three types of blocks have generated redo to protect them.
The redo log buffer is flushed at least every three seconds, when it is one-third full or contains 1MB of buffered data, or whenever a COMMIT or ROLLBACK takes place. It is very possible that at some point during our processing, the redo log buffer will be flushed. In that case, the picture will look like Figure.
That is, we’ll have modified blocks representing uncommitted changes in the buffer cache and redo for those uncommitted changes on disk. This is a very normal scenario that happens frequently.

49. Hypothetical Scenario: The Buffer Cache Fills Up Right Now Cont
The redo log buffer is flushed at least every three seconds, when it is one-third full or contains 1MB of buffered data, or whenever a COMMIT or ROLLBACK takes place.
It is very possible that at some point during our processing, the redo log buffer will be flushed
we’ll have modified blocks representing uncommitted changes in the buffer cache and redo for those uncommitted changes on disk. This is a very normal scenario that happens frequently.

50. The UPDATE
The UPDATE will cause much of the same work as the INSERT to take place.
This time, the amount of undo will be larger; we have some “before” images to save as a result of the UPDATE.
Dark rectangle in the redo log file represents the redo generated by the INSERT, the redo for the UPDATE is still in the SGA and has not yet been written to disk.
The UPDATE
The UPDATE will cause much of the same work as the INSERT to take place. This time, the amount of undo will be larger; we have some “before” images to save as a result of the UPDATE. Now we have the picture shown in Figure 6-3 (the dark rectangle in the redo log file represents the redo generated by the INSERT, the redo for the UPDATE is still in the SGA and has not yet been written to disk).

51. Hypothetical Scenario: The System Crashes Right Now
Let’s assume that our redo generated from the INSERT statement is on disk (in the redo log file) and redo generated from the UPDATE is in cache.
Redo for the UPDATE was only in the log buffer and never made it to disk (and was wiped out when the system crashed). That’s okay, the transaction was never committed and the data files on disk reflect the state of the system before the UPDATE took place.
However, the redo for the INSERT was written to the redo log file. Therefore Oracle would “roll forward” the INSERT.
WE would end up with modified undo blocks (information on how to undo the INSERT), modified table blocks (right after the INSERT), and modified index blocks (right after the INSERT).
We have more new undo segment blocks in the block buffer cache. To undo the UPDATE, if necessary, we have modified database table and index blocks in the cache. We have also generated more redo log buffer entries. Let’s assume that our redo generated from the INSERT statement (discussed in the prior section) is on disk (in the redo log file) and redo generated from the UPDATE is in cache.
Hypothetical Scenario: The System Crashes Right Now
Upon startup, Oracle would read the redo log files and find some redo log entries for our transaction. Given the state in which we left the system, we have the redo entries generated by the INSERT in the redo log files (which includes redo for undo segments associated with the INSERT). However, the redo for the UPDATE was only in the log buffer and never made it to disk (and was wiped out when the system crashed). That’s okay, the transaction was never
committed and the data files on disk reflect the state of the system before the UPDATE took place.
However, the redo for the INSERT was written to the redo log file. Therefore Oracle would “roll forward” the INSERT. We would end up with a picture much like Figure 6-1, with modified undo blocks (information on how to undo the INSERT), modified table blocks (right after the INSERT), and modified index blocks (right after the INSERT).
Oracle will discover that our transaction never committed and will roll it back since the system is doing crash recovery and, of course, our session is no longer connected.
To roll back the uncommitted INSERT, Oracle will use the undo it just rolled forward (from the redo and now in the buffer cache) and apply it to the data and index blocks, making them look as they did before the INSERT took place. Now everything is back the way it was. The blocks that are on disk may or may not reflect the INSERT (it depends on whether or not our blocks got flushed before the crash). If the blocks on disk do reflect the INSERT, then the INSERT
will be undone when the blocks are flushed from the buffer cache. If they do not reflect the undone INSERT, so be it—they will be overwritten later anyway.
This scenario covers the rudimentary details of a crash recovery. The system performs this as a two-step process.
First it rolls forward, bringing the system right to the point of failure, and then it proceeds to roll back everything that had not yet committed. This action will resynchronize the data files. It replays the work that was in progress and undoes anything that has not yet completed.

52. Redo and Undo : Transaction Rollback
When a ROLLBACK statement is issued, the database uses undo records to roll back changes made to the database by the uncommitted transaction.
During recovery, DB rolls back any uncommitted changes applied from the online redo log to the data files.
Undo records provide read consistency by maintaining the before image of the data for users accessing data at the same time that another user is changing it
Redo and Undo
Key to Oracle’s durability (recovery) mechanism is redo, and core to multiversioning (read consistency) is undo.
Oracle uses redo to capture how the transaction changed the data; this allows you to replay the transaction (in the
event of an instance crash or a media failure). Oracle uses undo to store the before image of a modified block; this
allows you to reverse or rollback a transaction.

53. How Redo and Undo Work Together
What happens during the processing of an INSERT with regard to redo and undo generation
How Oracle uses this information in the event of failures at various points in time?
Undo information, stored in undo tablespaces or undo segments, is protected by redo as well.
undo data is treated just like table data or index data—changes to undo generates some redo is logged to the log buffer and then the redo log file.
Why ?
Undo data is added to the undo segment and is cached in the buffer cache, just like any other piece of data would be.

54. Example INSERT-UPDATE-DELETE-COMMIT Scenario
created a table with an index as follows:
create table t(x int, y int);
create index ti on t(x);
what might happen with a set of statements like this:
insert into t (x,y) values (1,1);
update t set x = x+1 where x = 1;
delete from t where x = 2;
What happens if the system fails a t various points in the processing of these statements?
What happens if the buffer cache fills up?
What happens if we ROLLBACK at any point?
What happens if we succeed and COMMIT?
Example INSERT-UPDATE-DELETE-COMMIT Scenario
For this example, assume we’ve created a table with an index as follows:
create table t(x int, y int);
create index ti on t(x);
And then we will investigate what might happen with a set of statements like this:
insert into t (x,y) values (1,1);
update t set x = x+1 where x = 1;
delete from t where x = 2;
We will follow this transaction down different paths and discover the answers to the following questions:
What happens if the system fails a • t various points in the processing of these statements?
• What happens if the buffer cache fills up?
• What happens if we ROLLBACK at any point?
• What happens if we succeed and COMMIT?

55. The INSERT
The initial INSERT INTO T statement will generate both redo and undo.
The undo generated will be enough information to make the INSERT “go away.”
The redo generated by the INSERT INTO T will be enough information to make the INSERT “happen again.”
The INSERT
The initial INSERT INTO T statement will generate both redo and undo. The undo generated will be enough
information to make the INSERT “go away.” The redo generated by the INSERT INTO T will be enough information to
make the INSERT “happen again.”
After the INSERT has occurred, we have the scenario illustrated in Figure
There are some cached, modified undo blocks, index blocks, and table data blocks. Each of these blocks is
protected by entries in the redo log buffer.

56. Hypothetical Scenario: The System Crashes Right Now
System crashes before a COMMIT is issued or before the redo entries are written to disk.
Everything is OK.
SGA is wiped out, but we don’t need anything that was in the SGA.
It will be as if this transaction never happened when we restart.
None of the blocks with changes got flushed to disk, and none of the redo got flushed to disk.
We have no need of any of this undo or redo to recover from an instance failure.
Hypothetical Scenario: The System Crashes Right Now
In this scenario, the system crashes before a COMMIT is issued or before the redo entries are written to disk. Everything
is OK. The SGA is wiped out, but we don’t need anything that was in the SGA. It will be as if this transaction never
happened when we restart. None of the blocks with changes got flushed to disk, and none of the redo got flushed to
disk. We have no need of any of this undo or redo to recover from an instance failure.

57. Hypothetical Scenario: The Buffer Cache Fills Up Right Now
DBWn must make room and our modified blocks are to be flushed from the cache.
DBWn will start by asking LGWR to flush the redo entries that protect these database blocks. Before DBWn can write any of the blocks that are changed to disk, LGWR must flush (to disk) the redo information related to these blocks.
At this point, We have generated some modified table and index blocks. These have associated undo segment blocks, and all three types of blocks have generated redo to protect them.
Hypothetical Scenario: The Buffer Cache Fills Up Right Now
The situation is such that DBWn must make room and our modified blocks are to be flushed from the cache. In this case, DBWn will start by asking LGWR to flush the redo entries that protect these database blocks. Before DBWn can write any of the blocks that are changed to disk, LGWR must flush (to disk) the redo information related to these blocks.
This makes sense: if we were to flush the modified blocks for table T (but not the undo blocks associated with the modifications) without flushing the redo entries associated with the undo blocks, and the system failed, we would
have a modified table T block with no undo information associated with it. We need to flush the redo log buffers before writing these blocks out so that we can redo all of the changes necessary to get the SGA back into the state it is in right now, so that a rollback can take place.
This second scenario shows some of the foresight that has gone into all of this. The set of conditions described by “If we flushed table T blocks and did not flush the redo for the undo blocks and the system failed” is starting to get complex. It only gets more complex as we add users, and more objects, and concurrent processing, and so on.
At this point, we have the situation depicted in Figure 6-1. We have generated some modified table and index blocks. These have associated undo segment blocks, and all three types of blocks have generated redo to protect them.
The redo log buffer is flushed at least every three seconds, when it is one-third full or contains 1MB of buffered data, or whenever a COMMIT or ROLLBACK takes place. It is very possible that at some point during our processing, the redo log buffer will be flushed. In that case, the picture will look like Figure.
That is, we’ll have modified blocks representing uncommitted changes in the buffer cache and redo for those uncommitted changes on disk. This is a very normal scenario that happens frequently.

58. Hypothetical Scenario: The Buffer Cache Fills Up Right Now Cont
The redo log buffer is flushed at least every three seconds, when it is one-third full or contains 1MB of buffered data, or whenever a COMMIT or ROLLBACK takes place.
It is very possible that at some point during our processing, the redo log buffer will be flushed
we’ll have modified blocks representing uncommitted changes in the buffer cache and redo for those uncommitted changes on disk. This is a very normal scenario that happens frequently.

59. The UPDATE
The UPDATE will cause much of the same work as the INSERT to take place.
This time, the amount of undo will be larger; we have some “before” images to save as a result of the UPDATE.
Dark rectangle in the redo log file represents the redo generated by the INSERT, the redo for the UPDATE is still in the SGA and has not yet been written to disk.
The UPDATE
The UPDATE will cause much of the same work as the INSERT to take place. This time, the amount of undo will be larger; we have some “before” images to save as a result of the UPDATE. Now we have the picture shown in Figure 6-3 (the dark rectangle in the redo log file represents the redo generated by the INSERT, the redo for the UPDATE is still in the SGA and has not yet been written to disk).

60. Hypothetical Scenario: The System Crashes Right Now
Let’s assume that our redo generated from the INSERT statement is on disk (in the redo log file) and redo generated from the UPDATE is in cache.
Redo for the UPDATE was only in the log buffer and never made it to disk (and was wiped out when the system crashed). That’s okay, the transaction was never committed and the data files on disk reflect the state of the system before the UPDATE took place.
However, the redo for the INSERT was written to the redo log file. Therefore Oracle would “roll forward” the INSERT.
WE would end up with modified undo blocks (information on how to undo the INSERT), modified table blocks (right after the INSERT), and modified index blocks (right after the INSERT).
We have more new undo segment blocks in the block buffer cache. To undo the UPDATE, if necessary, we have modified database table and index blocks in the cache. We have also generated more redo log buffer entries. Let’s assume that our redo generated from the INSERT statement (discussed in the prior section) is on disk (in the redo log file) and redo generated from the UPDATE is in cache.
Hypothetical Scenario: The System Crashes Right Now
Upon startup, Oracle would read the redo log files and find some redo log entries for our transaction. Given the state in which we left the system, we have the redo entries generated by the INSERT in the redo log files (which includes redo for undo segments associated with the INSERT). However, the redo for the UPDATE was only in the log buffer and never made it to disk (and was wiped out when the system crashed). That’s okay, the transaction was never
committed and the data files on disk reflect the state of the system before the UPDATE took place.
However, the redo for the INSERT was written to the redo log file. Therefore Oracle would “roll forward” the INSERT. We would end up with a picture much like Figure 6-1, with modified undo blocks (information on how to undo the INSERT), modified table blocks (right after the INSERT), and modified index blocks (right after the INSERT).
Oracle will discover that our transaction never committed and will roll it back since the system is doing crash recovery and, of course, our session is no longer connected.
To roll back the uncommitted INSERT, Oracle will use the undo it just rolled forward (from the redo and now in the buffer cache) and apply it to the data and index blocks, making them look as they did before the INSERT took place. Now everything is back the way it was. The blocks that are on disk may or may not reflect the INSERT (it depends on whether or not our blocks got flushed before the crash). If the blocks on disk do reflect the INSERT, then the INSERT
will be undone when the blocks are flushed from the buffer cache. If they do not reflect the undone INSERT, so be it—they will be overwritten later anyway.
This scenario covers the rudimentary details of a crash recovery. The system performs this as a two-step process.
First it rolls forward, bringing the system right to the point of failure, and then it proceeds to roll back everything that had not yet committed. This action will resynchronize the data files. It replays the work that was in progress and undoes anything that has not yet completed.

61. Hypothetical Scenario: The System Crashes Right Now Cont.
To roll back the uncommitted INSERT, Oracle will use the undo it just rolled forward (from the redo and now in the buffer cache) and apply it to the data and index blocks, making them look as they did before the INSERT took place.
Now everything is back the way it was. The blocks that are on disk may or may not reflect the INSERT (it depends on whether or not our blocks got flushed before the crash).
If the blocks on disk do reflect the INSERT, then the INSERT will be undone when the blocks are flushed from the buffer cache. If they do not reflect the undone INSERT, so be it—they will be overwritten later anyway.

62. Hypothetical Scenario: The Application Rolls Back the Transaction
At this point, Oracle will find the undo information for this transaction either in the cached undo segment blocks (most likely) or on disk if they have been flushed (more likely for very large transactions).
It will apply the undo information to the data and index blocks in the buffer cache, or if they are no longer in the cache request, they are read from disk into the cache to have the undo applied to them.
These blocks will later be flushed to the data files with their original row values restored.
This scenario is much more common than the system crash. It is useful to note that during the rollback process, the redo logs are never involved.
The only time redo logs are read for recovery purposes is during recovery and archival. This is a key tuning concept: redo logs are written to. Oracle does not read them during normal processing. As long as you have sufficient devices so that when ARCn is reading a file, LGWR is writing to a different device, there is no contention for redo logs.
Many other databases treat the log files as “transaction logs.” They do not have this separation of redo and undo. For those systems, the act of rolling back can be disastrous—the rollback process must read the logs their log writer is trying to write to. They introduce contention into the part of the system that can least stand it. Oracle’s goal is to make it so that redo logs are written sequentially, and no one ever reads them while they are being written.
Hypothetical Scenario: The Application Rolls Back the Transaction
At this point, Oracle will find the undo information for this transaction either in the cached undo segment blocks (most likely) or on disk if they have been flushed (more likely for very large transactions). It will apply the undo information to the data and index blocks in the buffer cache, or if they are no longer in the cache request, they are read from disk into the cache to have the undo applied to them. These blocks will later be flushed to the data files with
their original row values restored.
This scenario is much more common than the system crash. It is useful to note that during the rollback process, the redo logs are never involved. The only time redo logs are read for recovery purposes is during recovery and archival. This is a key tuning concept: redo logs are written to. Oracle does not read them during normal processing.
As long as you have sufficient devices so that when ARCn is reading a file, LGWR is writing to a different device, there is no contention for redo logs. Many other databases treat the log files as “transaction logs.” They do not have this separation of redo and undo. For those systems, the act of rolling back can be disastrous—the rollback process must read the logs their log writer is trying to write to. They introduce contention into the part of the system that can least stand it. Oracle’s goal is to make it so that redo logs are written sequentially, and no one ever reads them while they are being written.

63. The DELETE
Again, undo is generated as a result of the DELETE, blocks are modified, and redo is sent over to the redo log buffer.
This is not very different from before. In fact, it is so similar to the UPDATE .
The DELETE
Again, undo is generated as a result of the DELETE, blocks are modified, and redo is sent over to the redo log
buffer. This is not very different from before. In fact, it is so similar to the UPDATE that we are going to move right
on to the COMMIT.

64. The DELETE
Oracle will flush the redo log buffer to disk. The modified blocks are in the buffer cache; maybe some of them have been flushed to disk.
All of the redo necessary to replay this transaction is safely on disk and the changes are now permanent. If we were to read the data directly from the data files, we probably would see the blocks as they existed before the transaction took place, as DBWn most likely has not yet written them.
That’s OK—the redo log files can be used to bring those blocks up to date in the
event of a failure. The undo information will hang around until the undo segment wraps around and reuses those blocks. Oracle will use that undo to provide for consistent reads of the affected objects for any session that needs them.
The COMMIT
We’ve looked at various failure scenarios and different paths, and now we’ve finally made it to the COMMIT. Here,
Oracle will flush the redo log buffer to disk, and the picture will look like Figure State of the system after a COMMIT
The modified blocks are in the buffer cache; maybe some of them have been flushed to disk. All of the redo
necessary to replay this transaction is safely on disk and the changes are now permanent. If we were to read the data
directly from the data files, we probably would see the blocks as they existed before the transaction took place, as DBWn
most likely has not yet written them. That’s OK—the redo log files can be used to bring those blocks up to date in the
event of a failure. The undo information will hang around until the undo segment wraps around and reuses those
blocks. Oracle will use that undo to provide for consistent reads of the affected objects for any session that needs them.

65. Redo Redo log files are crucial to the Oracle database.
These are the transaction logs for the database.
Oracle maintains two types of redo log files: online and archived.
They are used for recovery purposes;
Their main purpose in life is to be used in the event of an instance or media failure.
What Is Redo?
Redo log files are crucial to the Oracle database. These are the transaction logs for the database. Oracle maintains two
types of redo log files: online and archived. They are used for recovery purposes; their main purpose in life is to be
used in the event of an instance or media failure.
If the power goes off on your database machine, causing an instance failure, Oracle will use the online redo logs
to restore the system to exactly the committed point it was at immediately prior to the power outage. If your disk drive
fails (a media failure), Oracle will use both archived redo logs and online redo logs to recover a backup of the data that
was on that drive to the correct point in time. Moreover, if you “accidentally” truncate a table or remove some critical
information and commit the operation, you can restore a backup of the affected data and recover it to the point in
time immediately prior to the “accident” using online and archived redo log files.
Archived redo log files are simply copies of old, full online redo log files. As the system fills up log files, the ARCn
process makes a copy of the online redo log file in another location, and optionally puts several other copies into local
and remote locations as well. These archived redo log files are used to perform media recovery when a failure is caused
by a disk drive going bad or some other physical fault. Oracle can take these archived redo log files and apply them to
backups of the data files to catch them up to the rest of the database. They are the transaction history of the database.

66. Redo protected until the modified (dirty) buffer is written to disk
Online Redo Logs
Oracle needs to store in the online redo logs any information that would be required to perform a crash recovery
At time 1, Block A is read from Data File AA into the buffer cache and modified.
At time 2 the redo-change vector information (how the block changed) is written to the log buffer.
At time 3 the log-writer process writes the Block A change-vector information to online redo log 1.
At time 4 a log switch occurs, and online redo log 2 becomes the current online redo log.
Determining the Optimal Number of Redo Log Groups
Oracle requires at least two redo log groups in order to function. But, having just two groups sometimes isn’t enough.
To understand why this is so, remember that every time a log switch occurs, it initiates a checkpoint. As part of a
checkpoint the database writer writes all modified (dirty) blocks from the SGA to the data files on disk. Also recall
that the online redo logs are written to in a round-robin fashion and that eventually the information in a given log is
overwritten. Before the log writer can begin to overwrite information in an online redo log, all modified blocks in the
SGA associated with the redo log must first be written to a data file. If not all modified blocks have been written to the
data files, you see this message in the alert.log file:
Thread 1 cannot allocate new log, sequence <sequence number>
Checkpoint not complete
Another way to explain this issue is that Oracle needs to store in the online redo logs any information that would
be required to perform a crash recovery. To help you visualize this, see Figure
At time 1, Block A is read from Data File AA into the buffer cache and modified. At time 2 the redo-change vector
information (how the block changed) is written to the log buffer. At time 3 the log-writer process writes the Block A
change-vector information to online redo log 1. At time 4 a log switch occurs, and online redo log 2 becomes the
current online redo log.
Now, suppose that online redo log 2 fills up quickly and another log switch occurs, at which point the log writer
attempts to write to online redo log 1. The log writer isn’t allowed to overwrite information in online redo log 1 until
the database writer writes Block A to Data File AA. Until Block A is written to Data File AA, Oracle needs information
in the online redo logs to recover this block in the event of a power failure or shutdown abort. Before Oracle overwrites
information in the online redo logs, it ensures that blocks protected by redo have been written to disk. If these
modified blocks haven’t been written to disk, Oracle temporarily suspends processing until this occurs. There are a
few ways to resolve this issue:
• Add more redo log groups.
• Lower the value of FAST_START_MTTR_TARGET. Doing so causes the database writer process to
write older modified blocks to disk in a shorter time frame.
• Tune the database-writer process (modify DB_WRITER_PROCESSES).
If you notice that the Checkpoint not complete message is occurring often (say, several times a day), I recommend
that you add one or more log groups to resolve the issue. Adding an extra redo log gives the database writer more
time to write modified blocks in the database buffer cache to the data files before the associated redo with a block is
overwritten. There is little downside to adding more redo log groups. The main concern is that you could bump up
against the MAXLOGFILES value that was used when you created the database. If you need to add more groups and have
exceeded the value of MAXLOGFILES, then you must re-create your control file and specify a high value for this parameter.
If adding more redo log groups doesn’t resolve the issue, you should carefully consider lowering the value
of FAST_START_MTTR_TARGET. When you lower this value, you can potentially see more I/O because the database
writer process is more actively writing modified blocks to data files. Ideally, it would be nice to verify the impact of
modifying FAST_START_MTTR_TARGET in a test environment before making the change in production. You can modify
this parameter while your instance is up; this means you can quickly modify it back to its original setting if there are
unforeseen side effects.
Finally, consider increasing the value of the DB_WRITER_PROCESSES parameter. Carefully analyze the impact of
modifying this parameter in a test environment before you apply it to production. This value requires that you stop
and start your database; therefore, if there are adverse effects, downtime is required to change this value back to the
original setting.
Redo protected until the modified (dirty) buffer is written to disk

67. Redo All database changes generate redo Redo is used:
Records changes made to
Data and index segments
Undo segments
Data dictionary
Control files (indirectly)
Redo is used:
During recovery of database
Instance recovery
Media recovery

68. Redo and Undo : Transaction Rollback
When a ROLLBACK statement is issued, the database uses undo records to roll back changes made to the database by the uncommitted transaction.
During recovery, DB rolls back any uncommitted changes applied from the online redo log to the data files.
Undo records provide read consistency by maintaining the before image of the data for users accessing data at the same time that another user is changing it
Redo and Undo
Key to Oracle’s durability (recovery) mechanism is redo, and core to multiversioning (read consistency) is undo.
Oracle uses redo to capture how the transaction changed the data; this allows you to replay the transaction (in the
event of an instance crash or a media failure). Oracle uses undo to store the before image of a modified block; this
allows you to reverse or rollback a transaction.

69. Redo and Undo
redo
Key to Oracle’s durability (recovery) mechanism is redo
undo
Core to multiversioning (read consistency).
Oracle uses redo to capture how transaction changed the data.
Allows you to replay the transaction (in the event of an instance crash or a media failure).
Oracle uses undo to store the before image of a modified block.
Allows you to reverse or rollback a transaction.

70. Undo
Oracle DB maintains records of the actions of transactions, collectively known as undo data.
Opposite of redo.
Undo information is generated by DB as you make modifications to data so that the data can be put back the way it was before the modifications took place.
Redo is used to replay a transaction in the event of failure—to recover the transaction—undo is used to reverse the effects of a statement or set of statements.
What Is Undo?
Undo is conceptually the opposite of redo. Undo information is generated by the database as you make modifications
to data so that the data can be put back the way it was before the modifications took place. This might be done in
support of multiversioning, or in the event the transaction or statement you are executing fails for any reason, or if we
request it with a ROLLBACK statement. Whereas redo is used to replay a transaction in the event of failure—to recover
the transaction—undo is used to reverse the effects of a statement or set of statements. Undo, unlike redo, is stored
internally in the database in a special set of segments known as undo segments.
Undo Segments
Oracle Database maintains records of the actions of transactions, collectively known as
undo data. Oracle Database uses undo data to do the following:
• Roll back an active transaction
• Recover a terminated transaction
• Provide read consistency
• Perform some logical flashback operations
Oracle Database stores undo data inside the database rather than in external logs.
Undo data is stored in blocks that are updated just like data blocks, with changes to
these blocks generating redo records. In this way, Oracle Database can efficiently
access undo data without needing to read external logs.
Undo data for permanent objects is stored in an undo tablespace. Oracle Database
provides a fully automated mechanism, known as automatic undo management
mode, for managing undo segments and space in an undo tablespace.
The database separates undo data into two streams. A temporary undo stream
encapsulates only undo records generated by changes to temporary objects, whereas a
permanent undo stream encapsulates only undo records for permanent objects. The
database manages temporary and permanent undo independently. Undo separation
decreases storage and enhances performance by doing the following:
• Enabling you to configure permanent and undo tablespace sizes that best fit the
workloads for permanent and temporary tables
• Reducing the size of redo written to the online redo log
• Avoiding the need to back up temporary undo data
On an Active Data Guard instance, DML on global temporary tables requires undo to
be generated in temporary undo segments.

71. Undo Oracle Database uses undo data to :
Roll back an active transaction
Recover a terminated transaction
Provide read consistency : support of multiversioning . Uncommitted changes cannot be seen by other sessions
Perform some logical flashback operations
Oracle Database stores undo data inside the database rather than in external logs.
Undo data is stored in blocks that are updated just like data blocks, with changes to these blocks generating redo records.

72. Undo Segments and Transactions
When a transaction starts, DB assigns transaction to an undo segment, and to a transaction table, in current undo tablespace.
Multiple active transactions can write concurrently to the same undo segment or to different segments.
EX : transactions T1 and T2 can both write to undo segment U1, or T1 can write to U1 while T2 writes to undo segment U2.
Undo segment form a ring. Transactions write to one undo extent, and then to the next extent in the ring, and so on in cyclical fashion.
Undo Segments and Transactions
When a transaction starts, the database binds (assigns) the transaction to an undo
segment, and therefore to a transaction table, in the current undo tablespace. In rare
circumstances, if the database instance does not have a designated undo tablespace,
then the transaction binds to the system undo segment.
Multiple active transactions can write concurrently to the same undo segment or to
different segments. For example, transactions T1 and T2 can both write to undo
segment U1, or T1 can write to U1 while T2 writes to undo segment U2.
Conceptually, the extents in an undo segment form a ring. Transactions write to one
undo extent, and then to the next extent in the ring, and so on in cyclical fashion.
Figure shows two transactions, T1 and T2, which begin writing in the third
extent (E3) of an undo segment and continue writing to the fourth extent (E4).

73. Read Consistency and Undo Segments
To manage the multiversion read consistency model, the database must create a read consistent set of data when a table is simultaneously queried and updated. Oracle Database achieves this goal through undo data.
Guarantees that data returned by a single query is committed and consistent for a single point in time.
Depends on the transaction isolation level and the query:
In the read committed isolation level, point is time at which the statement was opened.
EX : if a SELECT statement opens at SCN 1000, then this statement is consistent to SCN 1000.
In a serializable or read-only transaction, this point is the time the transaction began.
EX : if a transaction begins at SCN 1000, and if multiple SELECT statements occur in this transaction, then each statement is consistent to SCN 1000
In a Flashback Query operation (SELECT ... AS OF), SELECT statement explicitly specifies the point in time.
EX : you can query a table as it appeared last Thursday at 2 p.m.
Locks
Before the database allows a session to modify data, the session must first lock the data that is being modified. A lock gives the session exclusive control over the data so that no other transaction can modify the locked data until the lock is released.
Transactions can lock individual rows of data, multiple rows, or even entire tables. Oracle Database supports both manual and automatic locking. Automatically acquired locks always choose the lowest possible level of locking to minimize potential conflicts with other transactions.
Note: There are many types of locks used by the Oracle instance to maintain internal consistency. In this course, we will be concentrating only locking used to protect rows and tables.
Oracle Database 11g: Administration Workshop I

74. Corruption
Sometimes a software or hardware malfunction can corrupt data .
Physical corruption :
Bad header
Block is Fractured/Incomplete
Block checksum is invalid
Block is misplaced
Logical Corruption
Block contains a valid checksum and the structure below the beginning of the block is corrupt .

75. User Error
UPDATE BANK _TBL SET BALANCE=500
WHERE ACCOUNT_NO=123456

76. Oracle Database 11g: Administration Workshop I 9 - 76
Source Of Data Loss
Oracle Database 11g: Administration Workshop I

77. Media Failure
Media failure is a physical problem with a disk that causes a failure of a read from or write to a disk that is required to run the database .
Any database file can be vulnerable to a media failure .

78. Murphy’s laws If anything can go wrong , it will
If anything just cannot go wrong , it will anyway
If everything seems to be going well , you have obviously overlocked something

79. Oracle Database 11g: Administration Workshop I 9 - 79
Reminder – Oracle Concepts
Oracle Database 11g: Administration Workshop I

80. Oracle Database 12c Architecture
There are several aspects to note about Figure 2-7. Communication with the database is initiated through a
sqlplus user process. Typically, the user process connects to the database over the network. This requires that you
configure and start a listener process. The listener process hands off incoming connection requests to an Oracle server
process, which handles all subsequent communication with the client process. If a remote connection is initiated as a
sys*-level user, then a password file is required. A password file is also required for local sys* connections that don’t
use OS authentication.
The instance consists of memory structures and background processes. When the instance starts, it reads the
parameter file, which helps establish the size of the memory processes and other characteristics of the instance.
When starting a database, the instance goes through three phases: nomount (instance started), mount (control files
opened), and open (data files and online redo logs opened).
The number of background processes varies by database version (more than 300 in the latest version of Oracle).
You can view the names and descriptions of the processes via this query:
SQL> select name, description from v$bgprocess;
The major background processes include
DBWn: The database writer wr • ites blocks from the database buffer cache to the data files.
• CKPT: The checkpoint process writes checkpoint information to the control files and
data file headers.
• LGWR: The log writer writes redo information from the log buffer to the online redo logs.
• ARCn: The archiver copies the content of online redo logs to archive redo log files.
• RVWR: The recovery writer maintains before images of blocks in the fast recovery area.
• MMON: The manageability monitor process gathers automatic workload repository statistics.
• MMNL: The manageability monitor lite process writes statistics from the active session history
buffer to disk.
• SMON: The system monitor performs system level clean-up operations, including
instance recovery in the event of a failed instance, coalescing free space, and cleaning up
temporary space.
• PMON: The process monitor cleans up abnormally terminated database connections and also
automatically registers a database instance with the listener process.
• RECO: The recoverer process automatically resolves failed distributed transactions.
Oracle Database 11g: Administration Workshop I

81. Oracle Database 12c Architecture: Major background processes
There are several aspects to note. Communication with the database is initiated through a
sqlplus user process. Typically, the user process connects to the database over the network. This requires that you
configure and start a listener process. The listener process hands off incoming connection requests to an Oracle server
process, which handles all subsequent communication with the client process. If a remote connection is initiated as a
sys*-level user, then a password file is required. A password file is also required for local sys* connections that don’t
use OS authentication.
The instance consists of memory structures and background processes. When the instance starts, it reads the
parameter file, which helps establish the size of the memory processes and other characteristics of the instance.
When starting a database, the instance goes through three phases: nomount (instance started), mount (control files
opened), and open (data files and online redo logs opened).
The number of background processes varies by database version (more than 300 in the latest version of Oracle).
You can view the names and descriptions of the processes via this query:
SQL> select name, description from v$bgprocess;
The major background processes include
DBWn: The database writer wr • ites blocks from the database buffer cache to the data files.
• CKPT: The checkpoint process writes checkpoint information to the control files and
data file headers.
• LGWR: The log writer writes redo information from the log buffer to the online redo logs.
• ARCn: The archiver copies the content of online redo logs to archive redo log files.
• RVWR: The recovery writer maintains before images of blocks in the fast recovery area.
• MMON: The manageability monitor process gathers automatic workload repository statistics.
• MMNL: The manageability monitor lite process writes statistics from the active session history
buffer to disk.
• SMON: The system monitor performs system level clean-up operations, including
instance recovery in the event of a failed instance, coalescing free space, and cleaning up
temporary space.
• PMON: The process monitor cleans up abnormally terminated database connections and also
automatically registers a database instance with the listener process.
• RECO: The recoverer process automatically resolves failed distributed transactions.
CKPT: The checkpoint process writes checkpoint information to the control files and data file headers.
ARCn: The archiver copies the content of online redo logs to archive redo log files.
DBWn: The database writer writes blocks from the database buffer cache to the data files.
LGWR: The log writer writes redo information from the log buffer to the online redo logs.
Oracle Database 11g: Administration Workshop I

82. Database Writer Process(DBWn )
Write modified (dirty) buffer in database buffer cache to disk
Asynchronously while performing other process to advance checkpoint .

83. Backup and Recovery Instance Architecture
Checkpoint Process
Signals the database writer process (DBWn) at each checkpoint.
Updates the data file headers with the checkpoint information.
Updates the control files with the checkpoint information.
Backup and Recovery Instance Architecture
The Oracle instance consists of the system global area (SGA), which is the memory allocated to the Oracle instance,
and a set of Oracle processes called the background processes. The Oracle processes start when you start the instance
and keep running as long as the instance is alive. Each of the Oracle background processes is in charge of a specific
activity, such as writing changed data to the data files, cleaning up after disconnected user sessions, and so on. We’ll
briefly review the key Oracle background processes that perform critical backup- and recovery–related tasks, which
are the checkpoint process, the log writer process, and the archiver process.
The Checkpoint Process
The checkpoint process does three things:
It signals the database wr • iter process (DBWn) at each checkpoint.
• It updates the data file headers with the checkpoint information.
• It updates the control files with the checkpoint information.

84. Checkpoint Process (CKPT)
Updates the control file and data file headers with checkpoint information and signals DBW to write blocks to disk.
Checkpoint information includes the checkpoint position, SCN, location in online redo log to begin recovery, and so on.

85. Redo Log Buffer
A circular buffer in SGA that stores redo entries describing changes made to DB .
A redo record is a data structure that contains the information necessary to reconstruct, or redo, changes made to the database by DML or DDL operations.
DB recovery applies redo entries to data files to reconstruct lost changes.
DB processes copy redo entries from the user memory space to the redo log buffer in the SGA.
Redo entries take up continuous, sequential space in the buffer .
Redo Log Buffer
The redo log buffer is a circular buffer in the SGA that stores redo entries describing
changes made to the database. A redo record is a data structure that contains the
information necessary to reconstruct, or redo, changes made to the database by DML
or DDL operations. Database recovery applies redo entries to data files to reconstruct
lost changes.
The database processes copy redo entries from the user memory space to the redo log
buffer in the SGA. The redo entries take up continuous, sequential space in the buffer.
The background process log writer process (LGWR) writes the redo log buffer to the
active online redo log group on disk. Figure shows this redo buffer activity.

86. Log Writer Process (LGWR)
Writes the redo log buffer to a redo log file on disk writes
When user commit a transaction
When the redo log buffer is one-third full
Before a DBWn process writes modified buffers to disk
Every 3 seconds

87. Online Redo Logs(ORLs )
Crucial to the Oracle database
Transaction logs for DB
Two types of redo log files: online and archived
Used for recovery purposes in the event of an instance or media failure.
What Is Redo?
Redo log files are crucial to the Oracle database. These are the transaction logs for the database. Oracle maintains two
types of redo log files: online and archived. They are used for recovery purposes; their main purpose in life is to be
used in the event of an instance or media failure.
If the power goes off on your database machine, causing an instance failure, Oracle will use the online redo logs
to restore the system to exactly the committed point it was at immediately prior to the power outage. If your disk drive
fails (a media failure), Oracle will use both archived redo logs and online redo logs to recover a backup of the data that
was on that drive to the correct point in time. Moreover, if you “accidentally” truncate a table or remove some critical
information and commit the operation, you can restore a backup of the affected data and recover it to the point in
time immediately prior to the “accident” using online and archived redo log files.
Archived redo log files are simply copies of old, full online redo log files. As the system fills up log files, the ARCn
process makes a copy of the online redo log file in another location, and optionally puts several other copies into local
and remote locations as well. These archived redo log files are used to perform media recovery when a failure is caused
by a disk drive going bad or some other physical fault. Oracle can take these archived redo log files and apply them to
backups of the data files to catch them up to the rest of the database. They are the transaction history of the database.

88. Online Redo Log Switches
log writer is the background process responsible for writing transaction information from redo log buffer (in the SGA) to the online redo log files (on disk).
Log writer flushes the contents of the redo log buffer when any of thefollowing are true:
A COMMIT is issued.
A log switch occurs.
Three seconds go by.
Redo log buffer is one-third full.
Redo log buffer fills to one megabyte.
Reuse of Online Redo Log Files
Multiple Copies of Online Redo Log Files
Online Redo Log Switches
Oracle Database uses only one online redo log file at a time to store records written
from the redo log buffer. The online redo log file to which the log writer process
(LGWR) process is actively writing is called the current online redo log file.
A log switch occurs when the database stops writing to one online redo log file and
begins writing to another. Normally, a switch occurs when the current online redo log
file is full and writing must continue. However, you can configure log switches to
occur at regular intervals, regardless of whether the current online redo log file is
filled, and force log switches manually.
Log writer writes to online redo log files circularly. When log writer fills the last
available online redo log file, the process writes to the first log file, restarting the cycle.
Figure illustrates the circular writing of the redo log.
Multiple Copies of Online Redo Log Files
Oracle Database can automatically maintain two or more identical copies of the online
redo log in separate locations. An online redo log group consists of an online redo log
file and its redundant copies. Each identical copy is a member of the online redo log
group. Each group is defined by a number, such as group 1, group 2, and so on.
Maintaining multiple members of an online redo log group protects against the loss of
the redo log. Ideally, the locations of the members should be on separate disks so that
the failure of one disk does not cause the loss of the entire online redo log.
In Figure A_LOG1 and B_LOG1 are identical members of group 1, while A_LOG2
and B_LOG2 are identical members of group 2. Each member in a group must be the
same size. LGWR writes concurrently to group 1 (members A_LOG1 and B_LOG1),
then writes concurrently to group 2 (members A_LOG2 and B_LOG2), then writes to
group 1, and so on. LGWR never writes concurrently to members of different groups.
Overview of the Online Redo Log
Physical Storage
Oracle Database 11g: Administration Workshop I

89. Reuse of Online Redo Log
At time 1, Block A is read from Data File AA into the buffer cache and modified.
At time 2 the redo-change vector information (how the block changed) is written to the log buffer.
At time 3 the log-writer process writes the Block Achange-vector information to online redo log 1.
At time 4 a log switch occurs, and online redo log 2 becomes the current online redo log
Redo protected until the modified (dirty) buffer is written to disk
At time 1, Block A is read from Data File AA into the buffer cache and modified. At time 2 the redo-change vector
information (how the block changed) is written to the log buffer. At time 3 the log-writer process writes the Block A
change-vector information to online redo log 1. At time 4 a log switch occurs, and online redo log 2 becomes the
current online redo log
Reuse of Online Redo Log Files
Oracle Database 11g: Administration Workshop I

90. Redo All database changes generate redo Redo is used:
Records changes made to
Data and index segments
Undo segments
Data dictionary
Control files (indirectly)
Redo is used:
During recovery of database
Instance recovery
Media recovery

91. Redo and Undo
redo
Key to Oracle’s durability (recovery) mechanism is redo
undo
Core to multiversioning (read consistency).
Oracle uses redo to capture how transaction changed the data.
Allows you to replay the transaction (in the event of an instance crash or a media failure).
Oracle uses undo to store the before image of a modified block.
Allows you to reverse or rollback a transaction.

92. Undo Oracle Database uses undo data to :
Roll back an active transaction
Recover a terminated transaction
Provide read consistency : support of multiversioning . Uncommitted changes cannot be seen by other sessions
Perform some logical flashback operations
Oracle Database stores undo data inside the database rather than in external logs.
Undo data is stored in blocks that are updated just like data blocks, with changes to these blocks generating redo records.

93. Backup and Recovery Instance Architecture
Log Writer Process (LGWR)
Process is responsible for transferring the contents of the redo log buffer to the online redo log files.
LGWR writes to the online redo files
At each commit
Every three seconds
When the redo log buffer is one-third full
The Log Writer Process
Oracle’s online redo log files record all changes made to the database. Oracle uses a write-ahead protocol, meaning the
logs are written to before the data files. Therefore, it is critical to always protect the online logs against loss by ensuring
they are multiplexed. Any changes made to the database are first recorded in the redo log buffer, which is part of the SGA.
Redo log files come into play when a database instance fails or crashes. Upon restart, the instance will read
the redo log files looking for any committed changes that need to be applied to the data files. Remember, when you
commit, Oracle ensures that what you are committing has first been written to the redo log files before these changes
are recorded in the actual data files. The redo log is the ultimate source of truth for all changes to the data in an Oracle
database, since an instance failure before the changes are written to the data files means that the changes are only in
the redo log files but not in the data files.
The log writer (LGWR) process is responsible for transferring the contents of the redo log buffer to the online redo
log files. The log writer writes to the online redo files under the following circumstances:
• At each commit
• Every three seconds
• When the redo log buffer is one-third full
The important thing to remember here is that the log writer process writes before the database writer does,
because of the write-ahead protocol. Data changes aren’t necessarily written to data files when you commit a
transaction, but they are always written to the redo log.

94. Logging and Archiving Redo Log Files Archive Log Files
Archiver (ARCn) is an optional background process and is in charge of archiving the filled online redo log files, before they can be overwritten by new data.
ARCn is used only if you’re running your DB in archivelog mode
Arch 1
LGWR
Group 1
Group 3
Group 2
ARCH
Arch 2
Arch 4
Arch 5
Arch 3
Arch 6
The Archiver Process
The archiver (ARCn) is an optional background process and is in charge of archiving the filled online redo log files,
before they can be overwritten by new data. The archiver background process is used only if you’re running your
database in archivelog mode.
Redo Log Files
Archive Log Files

95. Recovery From which events below can DBMS recover ? Wrong data entry
Disk failure
Fire / earthquake/ bankruptcy …
Systems crashes
Software errors
Power failures

96. Recovery

97. Performing Flashback Recovery
Flashback Database : Rewind a DB to an earlier time
Flashback Query : Run SELECTS on a past data states
Flashback version Query : Compare past data states
Flashback Transaction Query : Retrieve historical metadata from past
Flashback Table : Rewind a table to an earlier state
Flashback Table : Rewind a table to an eralier state

98. Sources of Data loss Media failure Environmental issue
Physical Problems with a disk
Remediation : fault tolerance /redundancy .
User error :
Accidental or malicious deletion
Remediation : Training ,security policy
Application error
Poorly written code can corrupt data blocks
A user session can crash
SQL statements can fail
Remediation : Code Review

99. Backup and Recovery Instance Architecture
Online redo log files record all changes made to DB .
Oracle uses a write-ahead protocol : logs are written to before the data files. Therefore, it is critical to always protect the online logs against loss by ensuring they are multiplexed.
Any changes made to DB are first recorded in the redo log buffer, which is part of the SGA.
Redo log files come into play when a database instance fails or crashes. Upon restart, the instance will read the redo log files looking for any committed changes that need to be applied to the data files.
When you commit, Oracle ensures that what you are committing has first been written to the redo log files before these changes are recorded in the actual data files.
The redo log is the ultimate source of truth for all changes to the data in an Oracle DB , since an instance failure before the changes are written to the data files means that the changes are only in the redo log files but not in the data files.
The Log Writer Process
Oracle’s online redo log files record all changes made to the database. Oracle uses a write-ahead protocol, meaning the
logs are written to before the data files. Therefore, it is critical to always protect the online logs against loss by ensuring
they are multiplexed. Any changes made to the database are first recorded in the redo log buffer, which is part of the SGA.
Redo log files come into play when a database instance fails or crashes. Upon restart, the instance will read
the redo log files looking for any committed changes that need to be applied to the data files. Remember, when you
commit, Oracle ensures that what you are committing has first been written to the redo log files before these changes
are recorded in the actual data files. The redo log is the ultimate source of truth for all changes to the data in an Oracle
database, since an instance failure before the changes are written to the data files means that the changes are only in
the redo log files but not in the data files.
The log writer (LGWR) process is responsible for transferring the contents of the redo log buffer to the online redo
log files. The log writer writes to the online redo files under the following circumstances:
• At each commit
• Every three seconds
• When the redo log buffer is one-third full
The important thing to remember here is that the log writer process writes before the database writer does,
because of the write-ahead protocol. Data changes aren’t necessarily written to data files when you commit a
transaction, but they are always written to the redo log.