Transcript Sereseability_Database Recovery_B

Database systems Implementation
Third year, first Semester 2010/2011
Database Backups and Recovery
Backup and Recovery
Database Backups
A backup is a copy of data. This copy can include
important parts of the database, such as the control
file and data files.
A backup is a safeguard against unexpected data loss
and application errors. If you lose the original data,
then you can reconstruct it by using a backup.
Note:
•
.LOG files are typically generated automatically, while .TXT files are created by the
•
user. For example, when a software installer is run, it may create a log file that
contains a log of files that were installed.
Standard text files, on the other hand, are typically created in a word processor by
a user. For example, if you create a new file with Notepad, it saves the file with a
".txt" extension.
Backups are divided into physical backups and logical
backups.
Physical backups, which are the primary concern in a
backup and recovery strategy, are copies of physical
database files. You can make physical backups with
either the Recovery Manager (RMAN) utility or
operating system utilities.
In contrast, logical backups contain logical data (for
example, tables and stored procedures) extracted
with an Oracle utility and stored in a binary file. You
can use logical backups to supplement physical
backups.
Backups cont..
A backup and recovery strategy is essential to prevent
data loss regardless of your database management
system; this is one of the most important aspects of
database administration.
Oracle database, backup categories in physical that
copied of the physical database file and logical
backup that able to recover at the individual schema
object level this performance by export utility, export
the object into a binary file which can only read by
import utility.
Database Recovery
To restore a physical backup of a data file or control file
is to reconstruct it and make it available to the Oracle
database server. To recover a restored data file is to
update it by applying archived redo logs and online
redo logs, that is, records of changes made to the
database after the backup was taken.
• Process of restoring database to a correct state in the
event of a failure.
• Need for Recovery Control
Database Recovery cont..
Two types of storage:
volatile (main memory)
and nonvolatile.
• Volatile storage does not survive system
crashes.
• Stable storage represents information that has
been replicated in several nonvolatile storage
media with independent failure modes.
Types of Failures
• System crashes, resulting in loss of main
memory.
• Media failures, resulting in loss of parts of
secondary storage.
• Application software errors.
• Natural physical disasters.
• Carelessness or unintentional destruction of
data or facilities.
• Sabotage (damage).
Transactions and Recovery
• Transactions represent basic unit of recovery.
• Recovery manager responsible for atomicity
and durability.
• If failure occurs between commit and database
buffers being flushed to secondary storage
then, to ensure durability, recovery manager
has to redo (roll forward) transaction’s updates.
Transactions and Recovery
• If transaction had not committed at failure
time, recovery manager has to undo (rollback)
any effects of that transaction for atomicity.
• Partial undo - only one transaction has to be
undone.
• Global undo - all transactions have to be
undone.
Example
• DBMS starts at time t0, but fails at time tf.
• Assume data for transactions T2 and T3 have been written to secondary
storage.
• T1 and T6 have to be undone. In absence of any other information,
recovery manager has to redo T2, T3, T4, and T5.
Recovery Facilities
DBMS should provide following facilities to assist
with recovery:
• Backup mechanism, which makes periodic
backup copies of database.
• Logging facilities, which keep track of current
state of transactions and database changes.
• Checkpoint facility, which enables updates to
database in progress to be made permanent.
• Recovery manager, which allows DBMS to
restore database to consistent state following a
failure.
Log File
A .log file is a text file that can be found in many
locations on your computer. It can be found in
your root drive, your Windows folder.
It Contains information about all updates to
database:
• Transaction records.
• Checkpoint records.
• Often used for other purposes (for example,
auditing).
Log File
Transaction records contain:
• Transaction identifier.
• Type of log record, (transaction start, insert,
update, delete, abort, commit).
• Identifier of data item affected by database
action (insert, delete, and update operations).
• Before-image of data item.
• After-image of data item.
• Log management information.
Sample log file
1. INFO----**** New configuration ****
2.
3. Section name : Test2
4. grfFlags : 63
5. cAttributes : 0
6. aAttributes : NONE
7. pdwFlags : 0
8.
9. INFO----Successfully bound filter.
10.
11. PASS----Init() returned a valid value for pdwFlags.
12.
13. INFO----Successfully initialized filter.
14.
15. INFO----Performing validation test. In this part of the test, the chunks
structures
16.
returned by the filter are checked for correctness, and the return
values
17.
of the filter calls are checked.
18.
19. PASS----GetChunk() succeeded.
20.
21. PASS----The current chunk has a legal value for the flags field.
Check pointing
Checkpoint is a Point of synchronization
between database and log file. All buffers are
force-written to secondary storage.
• Checkpoint record is created containing
identifiers of all active transactions.
• When failure occurs, redo all transactions that
committed since the checkpoint and undo all
transactions active at time of crash.
Check pointing
• In previous example, with checkpoint at time
tc, changes made by T2 and T3 have been
written to secondary storage.
Thus:
• only redo T4 and T5,
• undo transactions T1 and T6.
Recovery Techniques
If database has been damaged:
• Need to restore last backup copy of database
and reapply updates of committed transactions
using log file.
If database is only inconsistent:
• Need to undo changes that caused inconsistency.
May also need to redo some transactions to
ensure updates reach secondary storage.
• Do not need backup, but can restore database
using before- and after-images in the log file.
Log based recovery
The most widely used structure for recording
database modifications is the log. The log is a
sequence of log records and maintains a history
of all update activities in the database.
There are several types of log records.
• An update log record describes a single database
write:
• Transactions identifier.
• Data-item identifier.
• Old value.
• New value.
Shadow paging
Shadow paging is an alternative to logbased recovery techniques, which has
both advantages and disadvantages. It
may require fewer disk accesses, but it is
hard to extend paging to allow multiple
concurrent transactions. The paging is
very similar to paging schemes used by
the operating system for memory
management.
Cont..
The idea is to maintain two page tables during
the life of a transaction: the current page table
and the shadow page table. When the
transaction starts, both tables are identical.
The shadow page is never changed during the
life of the transaction. The current page is
updated with each write operation. Each table
entry points to a page on the disk.
Cont..
When the transaction is committed, the shadow page
entry becomes a copy of the current page table entry
and the disk block with the old data is released. If the
shadow is stored in nonvolatile memory and a
system crash occurs, then the shadow page table is
copied to the current page table.
This guarantees that the shadow page table will point
to the database pages corresponding to the state of
the database prior to any transaction that was active
at the time of the crash, making aborts automatic.
Shadow paging cont..
There are drawbacks to the shadow-page technique:
• Commit overhead. The commit of a single
transaction using shadow paging requires multiple
blocks to be output -- the current page table, the
actual data and the disk address of the current page
table. Log-based schemes need to output only the
log records.
• Data fragmentation. Shadow paging causes database
pages to change locations (therefore, no longer
contiguous.
Garbage collection. Each time that a transaction
commits, the database pages containing the old
version of data changed by the transactions must
become inaccessible. Such pages are considered to
be garbage since they are not part of the free space
and do not contain any usable information.
Periodically it is necessary to find all of the garbage
pages and add them to the list of free pages. This
process is called garbage collection and imposes
additional overhead and complexity on the system.
The end
Questions and Answers..!