The document provides an overview of Oracle Database hot backup and recovery procedures, detailing the hot backup process while the database is operational and under fuzzy state with user transactions. It covers the implications of hot backup on data file headers and the generation of redo logs, as well as measures for recovering parameter files, control files, and data files in various failure scenarios. The document emphasizes best practices for maintaining data integrity during hot backups and outlines necessary steps for effective recovery when data files or logs are lost.

1. ORACLE
DATABASE HOT
BACKUP AND
RECOVERY

2. Hot Backup Overview
Taking the backup while the database is up and running is called hot
backup
During hot backup database will be in fuzzy state and still users can
perform transactions which makes backup inconsistent
Whenever we place a tablespace or database in begin backup mode,
following happens
The corresponding datafiles header will be freezed i.e CKPT process will
not update latest SCN

3. Body of the datafile is still active i.e DBWRn will write the dirty blocks to
datafiles
After end backup, datafile header will be unfreezed and CKPT process
will update latest SCN immediately by taking that information from
controlfiles
During hot backup, we will observe much redo generated because
oracle will copy entire data block as redo entry into LBC. This is to avoid
fractured block

4. A block fracture occurs when a block is being read by the backup, and
being written to at the same time by DBWR. Because the OS (usually)
reads blocks at a different rate than Oracle, your OS copy will pull
pieces of an Oracle block at a time. What if the OS copy pulls half a
block, and while that is happening, the block is changed by DBWR?
When the OS copy pulls the second half of the block it will result in
mismatched halves, which Oracle would not know how to reconcile
This is also why the SCN of the datafile header does not change
when a tablespace enters hot backup mode. The current SCNs are
recorded in redo, but not in the datafile. This is to ensure that Oracle
will always recover over the datafile contents with redo entries. When
recovery occurs, the fractured datafile block will be replaced with a
complete block from redo, making it whole again
Note: Database should be in archivelog mode to perform hot backup

5. Taking hot backup
Put the database in begin backup mode
Copy all database related files to backup location. Create
a location on OS where you can copy backup files. Eg
/u02/db_backup/hot_bkp_12_jan/

6. Get the location of datafiles, controlfiles, redolog files
Copy above files using Linx cp command to backup location

7. Put DB in end backup mode
Take manual controlfile backup

8. Backup the archive logs generated during the begin backup and end
backup mode.
Copy above archive log files to the backup location using the Linux cp
command.

9. Sometimes you want to check which tablespaces inside
the database are specifically kept in BACKUP mode. Use
below query to get all the tablespaces which are ACTIVE
mode (means they are under BEGIN BACKUP mode).
Important queries

10. The following sample output shows that the example and
users tablespaces currently have ACTIVE status:

11. Parameter file recovery
There are three scenarios when you loose parameter file and how to
recover using hot backups.

12. Scenario 1: When you have parameter file backup
Let us simulate a failure. We assume that we already have taken the hot backup.
DB is up and running
Delete both pfile and spfile under $ORACLE_HOME/dbs
location
Connect to sqlplus and shutdown the database
Now start the database and it should throw below error

13. Recovering the parameter file:
Exit the sqlplus
Go to hot backup location
Copy parameter files (pfile & spfile) to $ORACLE_HOME/dbs location
Connect to sqlplus and start your database!

14. Scenario 2: When you do not have parameter file backup
Let us assume we do not have hot backup of the parameter files, then
follow below method to recovery your parameter file:
Goto alert log location (Generally
/u01/app/oracle/diag/rdbms/testdb/testdb/trace)
Cat the alert log file (cat alert_testdb.log)
Find last time database was started
Copy all the non-default parameters into notepad

15. Create a pfile under $ORACLE_HOME/dbs location
The file name should be init<sid>.ora
Paste all contents from notepad
Start the database!

16. From 11g onwards, you can recreate parameter file in case the database
is up and running. Even if you loose parameter file but database instance
is still running, we can recreate parameter file from memory:
Scenario 3: When you do not have parameter file
backup in 11g

17. Control file recovery
Simulate failure (we assume that hot backup is already taken).
Without shutting down the database, delete database control file at
OS level

18. Scenario 1: steps for control file incomplete recovery
Scenario 2: steps for control file complete recovery

19. Goto udump location and copy the first create
controlfile script to a file called control.sql
Note: After creating control files using above
procedure, there will be no SCN in that. So server
process will write the latest SCN to control files in
this situation by taking info from datafile header.

20. Redolog recovery
Let’s try to recovery our database with loss of redolog files. Simulate
a failure and let us delete redologs at OS level

21. Recover redo log file in archive log mode
What resetlogs will do?
Create new redolog files at OS level (location and size will be
taken from controlfile) if not already existing

22. Whenever database is opened with resetlogs option, we will say
database entered into new incarnation. If database is in new
incarnation, the backups which were taken till now are no more
useful. So, whenever we perform an incomplete recovery we
need to take full backup of database immediately
We can find the prev incarnation information of a database from
below query
Resets the log seq number (LSN) to 1, 2, 3 etc for the created
files

23. Tablespace recovery
Delete all the data files related to particular tablespace and follow
below recovery steps

24. Datafile recovery
Delete only one data file related to a tablespace and follow below
steps to recover the data file

25. System tablespace
recovery
Delete all the data files related to system tablespace and use below
steps to recover the system tablespace

26. Entire database
recovery
Let us simulate a failure (make sure you have already taken the
database backup). Delete all the data files, control files and redo
log files associated to the database.

27. Follow below steps to perform entire database recovery
Note: we can drop a single datafile using below command
When we use above command, it will delete the file at OS level, but
data dictionary will not be updated and never we can get back that
file even if we have backup. So, don’t use this in real time.

28. Datafile recovery
without backup
In case you do not have hot backup of the database or a particular
data file still you can recover entire data file but you need to have
all the archive logs from the day data file was first created.

29. To simulate this type of failure, do following:
Create a tablespace
Create user to store one table inside new tablespace
Delete data file at OS level

30. Now use below queries to recover the data file (note we do
not have any hot backup)

31. Courses | Projects | Bootcamps