The increment of the sequence of SCN does not change with any database operation, even the RESETLOGS. RESETLOGS clears redo records not applied in all online log files, RES
The increment of the sequence of SCN does not change with any database operation, even the RESETLOGS. RESETLOGS clears redo records not applied in all online log files, RES
Theoretical Basis of the experiment:
The increment of the sequence of SCN does not change with any database operation, even the RESETLOGS.
RESETLOGS clears redo records not applied in all online log files. RESETLOGS only resets the log file's serial number to 1, but does not affect SCN. The SCN continues to increase progressively according to the original sequence.
Save the resetlogs SCN and counter in the control file to uniquely identify each open database operation performed with the RESETLOGS option.
This value is written into each data file header and redo log file.
If the log serial number of the redo log file does not match the Oracle value, the redo log file cannot be applied during restoration.
After Incomplete recovery, the database requires the log file with the log serial number of 1, so the remaining log files in the original log sequence will not be available.
The RESETLOGS operation creates a new form of the database, that is, a database with a new log serial number stream starting from 1.
According to the above theory: SCN is a sequential data stream, which always increments during the database existence, while the log file sequence stream is also an incremental sequence, but it will be reset to 1 due to RESETLOGS, however, the SCN sequence streams in the log file sequence streams keep increasing.
Therefore, you can use the archive log stream before RESETLOGS and the archive log stream after RESETLOGS to connect and continue the SCN sequence stream, so that you can use the backup before RESETLOGS to restore the data after RESETLOGS.
Prerequisites:
Ensure that the two log streams (archive log streams before RESETLOGS and archive log streams after RESETLOGS) are complete, and there are corresponding control files for the two log streams.
Suggestion: Before RESETLOGS, ensure the security of the data backed up before the database. Before creating the first consistent backup after RESETLOGS, you must not delete the consistent Database Backup created before RESETLOGS.
If you have enough space, we recommend that you keep the consistent Database Backup created before RESETLOGS.
Experiment ideas and steps:
1. Shut down the database for backup-RMAN, write down the SCN and time, record the sequence number and REDO.
2. Open the database, write down the time/SCN, delete a user, and perform Incomplete recovery based on the time point. Records the SCN after Incomplete recovery, archive sequence number
3. In the recovered database, write down the time/SCN and delete another user. Using the backup in step 1, you can re-perform Incomplete recovery on the database after RESETLOS.
######################################## ######################################## ##########################
Step 1: Close the database for backup-RMAN, and record the archive log number. 1. query the serial number of the current archived log
SYS @ bys1> col name for a50
SYS @ bys1> select * from (select name, recid, sequence #, status, applied from v $ archived_log order by recid desc) where rownum <5;
Name recid sequence # S APPLIED
--------------------------------------------------------------------------------
/U01/archbys1/arc_201731_829941492.arc 120 31 A NO
/U01/archbys1/arc_201730_829941492.arc 119 30 A NO
/U01/archbys1/arc_201729_829941492.arc 118 29 A NO
/U01/archbys1/arc_rj28_829941492.arc 117 28 A NO
BYS @ bys1> select incarnation #, resetlogs_change #, resetlogs_time, prior_resetlogs_time, status, resetlogs_id from v $ database_incarnation
INCARNATION # RESETLOGS_CHANGE # RESETLOGS_TIME PRIOR_RESETLOGS_TIM STATUS RESETLOGS_ID
--------------------------------------------------------------------------------------
1 1 2009/08/13 23:00:48 PARENT 694825248
2 754488 08:58:04 2009/08/13 23:00:48 PARENT 822301084
3 2541692 19:18:12 08:58:04 PARENT 829941492
4 3228984 00:14:08 19:18:12 PARENT 830736848
5 3229505 00:27:42 00:14:08 CURRENT 830737662
2. Close the database and start it to MOUNT for full backup
SYS @ bys1> startup mount;
ORACLE instance started.
Total System Global Area 631914496 bytes
Fixed Size 1338364 bytes
Variable Size 385876996 bytes
Database Buffers 239075328 bytes
Redo Buffers 5623808 bytes
SYS @ bys1> exit
3. Use the prepared backup script for full backup-note that df-h is used to determine that the Backup Directory has sufficient space.
[Oracle @ bys001 ~] $ Cat fullback. sh
Rman log/home/oracle/backfull-'date + % Y % m % d-% H % M'. log < Connect target /;
Run {
Backup full tag 'bys001-full' database
Format "/home/oracle/bys001full _ % d _ % t _ % s"
Plus archivelog
Format "/home/oracle/bys001arch _ % d _ % t _ % s"
Delete all input;
}
Exit
[Oracle @ bys001 ~] $ Sh fullback. sh
RMAN> 2> 3> 4> 5> 6> 7> RMAN>
[Oracle @ bys001 ~] $ Sqlplus/as sysdba
SYS @ bys1> alter database open;
Database altered.
###############
4. Record the SCN of the current system and delete a user
SYS @ bys1> select open_mode from v $ database;
OPEN_MODE
--------------------
READ WRITE
SYS @ bys1> select dbid, checkpoint_change # from v $ database;
DBID CHECKPOINT_CHANGE #
----------------------------
3957527513 3228508
SYS @ bys1> col name for a40
SYS @ bys1> 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/bys1/system01.dbf 3228508 23:51:15
2/u01/oradata/bys1/sysaux01.dbf 3228508 23:51:15
3/u01/oradata/bys1/undotbs01.dbf 3228508 23:51:15
4/u01/oradata/bys1/users01.dbf 3228508 23:51:15
5/u01/oradata/bys1/example01.dbf 3228508 23:51:15
6/u01/oradata/bys1/test1.dbf 3228508 23:51:15
SYS @ bys1> select GROUP #, sequence #, STATUS, FIRST_CHANGE #, to_char (FIRST_TIME, 'yyyy/mm/dd: hh24: mi: ss') time from V $ log;
GROUP # SEQUENCE # STATUS FIRST_CHANGE # TIME
--------------------------------------------------------------------
1 31 INACTIVE 3222825: 22: 08: 56
2 32 CURRENT 3228378: 23: 38: 08 you can see that the number of the current redo log is 32
3 30 INACTIVE 3218774: 22: 00: 30
SYS @ bys1> set time on
23:55:34 SYS @ bys1> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER
------------------------
3228983
23:55:35 SYS @ bys1> conn test/test
Connected.
At 23:55:53 TEST @ bys1> select * from cat;
TABLE_NAME TABLE_TYPE
-----------------------------------------
TEST1 SYNONYM
23:56:06 TEST @ bys1> conn/as sysdba
Connected.
23:56:18 SYS @ bys1> drop user test cascade;
User dropped.
User deleted
######################################## ##############################
Step 2: Perform Incomplete recovery for the first time. 1. First, start the database to MOUNT, and then perform Incomplete recovery based on SCN.