The process of recovering an Oracle instance with a variety of tools such as dump, bbed

---Friendship tips, more content, you can choose from the top left of the + Directory selection section to facilitate reading.

Experimental thinking:--Experimental related trace file: http://download.csdn.net/detail/q947817003/6646723

1. Database open, do DML operation do not commit, view checkpoint.

2.SHUTDOWN abort and reboot to mount and query checkpoints

3.DUMP Control File View Checkpoint_change#/rba

4.DUMP data file View Checkpoint_change#/rba, compared with dump control file

5.DUMP Redo log file, view, compare Checkpoint_change#/rba

6. Use bbed to view the Checkpoint_change#/rba in the header of the data file

7. Execute Event statement, open database, dump control file

8. The recovery process that is viewed through the alert log when the Open is analyzed-roll forward

9. In the analysis of open, event event generated trace to view the recovery process-roll forward

10.OPEN database, the rollback of an instance recovery is resolved through the alert log and trace information generated by event events

11. Analyze the control file information after open

References and thanks:

Guoyjoe http://blog.csdn.net/guoyJoe/article/details/9034425

Dbsnake http://www.dbsnake.com/oracle-instance-recovery-end-point.html

The experimental conclusions are as follows:

1. The control file provides RBA information about the current redo log required for recovery, the current redo log provides specific log content for recovery, and ultimately the application of the log content to the data file. --there is no shortage of instance recovery.

2. Database open when the start of the instance recovery, the first application of the log content, after application from the alert log to see that you can connect to the database, at this time if the undo is not completed, there are users to issue operations, the database process will be rolled back to the user--there may be waiting

3. Important point, the data file, the current redo log file, the control file normal instance recovery without DBA intervention, automatic completion haha.

4. If the current redo log is lost, only do not fully recover.

About instance recovery start point:--from Dbsnake

An on Disk RBA may appear smaller than the low Cache RBA, and if Oracle finds this, it will force write redo.

On disk RBA only indicates that instance recovery should be restored at least to on disk RBA, which is only the end of the real current redo log file, a front mirror.

The starting point for instance recovery is the large value in the low Cache RBA and thread Checkpoint RBA; the end of the instance recovery is the end of the current redo log file. On-disk RBA is the lowest point to restore to-in fact, as long as On-disk RBA after the log block will be restored.

Oracle, when doing instance recovery, is controlled by the implied parameter _two_pass, which implicitly considers true, which means that Oracle is to do the recovery of the two pass Recovery, that is, to scan current redo log file two times.

The core of the two pass recovery is to remove the corresponding redo record,oracle of the data blocks that have been written to the data file when the instance is restored, which is called the redo record as the block written (BWR).

###################################################################

1. Database normal operation, a variety of ways to view the checkpoint in the database

DML operation not committed under normal user

bys@ Bys3>set time on

13:18:17 bys@ Bys3>select * from A; -This table is in the user table space.

B

----------

55

8

0

3

13:18:21 bys@ Bys3>delete A;

4 rows deleted.

13:18:36 bys@ Bys3>select * from A;

No rows selected

Open a session again (the same session switch user will submit the operation), a variety of ways to view the database checkpoint: see: http://blog.csdn.net/q947817003/article/details/11590735

sys@ Bys3>set time on

13:18:44 sys@ bys3>col name for A35

13:18:52 sys@ bys3>select dbid,name,checkpoint_change# from V$database;

DBID NAME checkpoint_change#

---------- ----------------------------------- ------------------

3358363031 BYS3 1991217

13:18:59 sys@ bys3>select File#,name,checkpoint_change#,to_char (checkpoint_time, ' yyyy-mm-dd hh24:mi:ss ') cptime From V$datafile;

file# NAME checkpoint_change# Cptime

---------- ----------------------------------- ------------------ -------------------

1/U01/ORADATA/BYS3/SYSTEM01.DBF 1991217 2013-12-02 13:17:26

2/U01/ORADATA/BYS3/SYSAUX01.DBF 1991217 2013-12-02 13:17:26

3/U01/ORADATA/BYS3/UNDOTBS01.DBF 1991217 2013-12-02 13:17:26

4/U01/ORADATA/BYS3/USER01.DBF 1991217 2013-12-02 13:17:26

13:19:25 sys@ bys3>select name,checkpoint_change# from V$datafile_header;

NAME checkpoint_change#

----------------------------------- ------------------

/U01/ORADATA/BYS3/SYSTEM01.DBF 1991217

/U01/ORADATA/BYS3/SYSAUX01.DBF 1991217

/U01/ORADATA/BYS3/UNDOTBS01.DBF 1991217

/U01/ORADATA/BYS3/USER01.DBF 1991217

Current current redo Log usage:

13:19:57 sys@ Bys3>col for A30

13:20:01 sys@ bys3>select a.member,a.type,b.thread#,b.sequence#,b.bytes/1024/1024 MB,b.status,b.archived from v$ LogFile A,v$log b where a.group#=b.group#;

Member TYPE thread# sequence# MB STATUS ARC

------------------------------ ------- ---------- ---------- ---------- ---------------- ---

/u01/oradata/bys3/redo01.log ONLINE 1 INACTIVE YES

/u01/oradata/bys3/redo02.log ONLINE 1 Current NO

/u01/oradata/bys3/redo03.log ONLINE 1 INACTIVE YES

###################################################################

2. Simulate power--shutdown abort and reboot to mount query checkpoint

13:20:02 sys@ Bys3>shutdown abort; Finish this command----13:22:11

ORACLE instance shut down.

13:22:11 sys@ bys3>

Alert log:--Recommend a small method: make the alert log a soft link to the Oracle User home directory for easy viewing.

[Oracle@bys3 ~]$ Cat Alert_bys3.log

Mon Dec 02 13:22:09 2013

Shutting down instance (abort)

License High Water mark = 4

USER (ospid:846): terminating the instance

Instance terminated by USER, PID = 846

Mon Dec 02 13:22:11 2013

Instance shutdown complete

######################################