Shulou(Shulou.com)06/01 Report--

Previous address http://blog.itpub.net/29047826/viewspace-1284906/

1. The source side performs RMAN full database backup.

The backup path is the local disk of the node node1. In order to copy the backup to the disaster recovery side, this backup cannot be saved on ASM.

Run {

Allocate channel ch01 device type disk

Allocate channel ch02 device type disk

Backup

Format'/ backup/full_%d_%s_%T_%p.bak'

Database include current controlfile

Sql 'alter system archive log current'

Backup

Archivelog all format'/ backup/arch_%d_%s_%T_%p'

Release channel ch02

Release channel ch01

}

2. View the backup film where the controlfile is located. The controlfile is also read from this backup when the disaster recovery side is recovering.

RMAN > list backup of controlfile

List of Backup Sets

=

BS Key Type LV Size Device Type Elapsed Time Completion Time

37 Full 17.80m DISK 00:00:00 2014-09-28 23:53:06

BP Key: 37 Status: AVAILABLE Compressed: NO Tag: TAG20140928T235259

Piece Name: / backup/full_PROD_36_20140928_1.bak

Control File Included: Ckp SCN: 1260618 Ckp time: 2014-09-28 23:53:06

3. Get the last SCN number of the inactive (INACTIVE) archived log. If there are multiple archived INACTIVE groups, take the maximum FIRST_CHANGE# 1260645.

The SCN number is used as the SCN of the recover database until on the disaster recovery side, and this SCN should also be referenced after the replication process is restarted.

SYS@PROD1 > select inst_id,group#,thread#,sequence#,archived,status,first_change# from gv$log order by status

INST_ID GROUP# THREAD# SEQUENCE# ARC STATUS FIRST_CHANGE#

-

1 3 2 25 NO CURRENT 1260660

2 3 2 25 NO CURRENT 1260660

1 1 1 29 NO CURRENT 1260655

2 1 1 29 NO CURRENT 1260655

12 1 28 YES INACTIVE 1260638

1 4 2 24 YES INACTIVE 1260645

2 2 1 28 YES INACTIVE 1260638

24 2 24 YES INACTIVE 1260645

4. Copy the source-side backup to the disaster recovery side

[oracle@node1 ~] $scp / backup/* oracle@172.16.228.103:/backup/

5. Stop the replication process on the disaster recovery side and prepare to recover the database.

GGSCI (node3) 4 > stop rt1

Sending STOP request to REPLICAT RT1...

Request processed.

After stopping the replication process, you can continue to perform some DML operations on the source side. These operations will be obtained normally through the extraction process, and the delivery process will be delivered to the remote trail directory of the disaster recovery side, but it will not be appended by the replication process for the time being.

6. Close the database on the disaster recovery side.

[root@node3] # srvctl stop database-d prod

7. The disaster recovery side starts the database from RMAN to nomount status.

[root@node3 ~] # su-oracle

[oracle@node3 ~] $rman target /

RMAN > startup nomount

Oracle instance started

Total System Global Area 672256000 bytes

Fixed Size 2256272 bytes

Variable Size 520094320 bytes

Database Buffers 146800640 bytes

Redo Buffers 3104768 bytes

8. The disaster recovery end recovers the control files from RMAN

RMAN > restore controlfile from'/ backup/full_PROD_24_20140928_1.bak'

Starting restore at 2014-09-28 20:14:13

Allocated channel: ORA_DISK_1

Channel ORA_DISK_1: SID=34 instance=PROD1 device type=DISK

Channel ORA_DISK_1: restoring control file

Channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Output file name=+DATA/prod/controlfile/current.260.859387343

Output file name=+ARCH/prod/controlfile/current.256.859387345

Finished restore at 2014-09-28 20:14:14

9. The disaster recovery control file loads the copied backup set information and checks the control file information.

RMAN > catalog start with'/ backup/'

RMAN > list backup

10. The disaster recovery end recovers the database from RMAN

RMAN > restore database

11. The disaster recovery end recovers archived logs from RMAN

RMAN > run {

Allocate channel c1 type disk

Allocate channel c2 type disk

Restore archivelog all

Release channel c1

Release channel c2

}

12. The disaster recovery end recovers from the SCN specified by RMAN. The SCN is the SCN whose status is the largest in the INACTIVE after the source database performs a RMAN backup.

RMAN > recover database until scn 1260645

13. The disaster recovery end checks whether the scn of the file header is consistent through the control file in the mount status.

SYS@PROD1 > select checkpoint_change# from v$datafile_header

CHECKPOINT_CHANGE#

-

1260645

1260645

1260645

1260645

1260645

1260645

1260645

7 rows selected.

SYS@PROD1 > select checkpoint_change# from v$datafile

CHECKPOINT_CHANGE#

-

1260645

1260645

1260645

1260645

1260645

1260645

1260645

14. The database is opened by resetlogs on the disaster recovery side.

Alter database open resetlogs

[root@node3] # srvctl start database-d prod

15. The disaster recovery end reconfigures checkpoint

[oracle@node3 goldengate] $ggsci

GGSCI (node3) 1 > DBLOGIN USERID oggadmin,PASSWORD oggadmin

GGSCI (node3) 2 > ADD CHECKPOINTTABLE oggadmin.checkpointtable

GGSCI (node3) 14 > DELETE REPLICAT rt1

GGSCI (node3) 15 > ADD REPLICAT rt1, EXTTRAIL / goldengate/dirdat/rt, checkpointtable oggadmin.checkpointtable

16. The disaster recovery side restarts the replication process, starting with a SCN of 1260645

Be careful that this word is not misspelled aftercsn

GGSCI (node3) 16 > start rt1 aftercsn 1260645

Sending START request to MANAGER...

REPLICAT RT1 starting

17. Whether the DML generated during the recovery of the database by the disaster recovery end through sqlplus query has been successfully appended

Sqlplus / as sysdba

Select * from snow.t1

This initialization walkthrough is over.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.