Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to configure Step By Step in Oracle 11gR2 Active DataGuard. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

After the various configurations, we can proceed with the duplicate process.

7. RMAN performs duplicate operation

There are different ways to build physical standby in different versions of Oracle, and these methods are backward compatible. In other words, the old version of the standby build method is fine under the new version. Moreover, some methods have strong practical scenarios.

11g Oracle has introduced a method of building active database using RMAN, which can continue to build standby without downtime of the main library. Traditionally, parameter files and control files that need to be prepared separately can also be sorted out by scripting.

When the standby instance is started, we just set the db_name parameter. Other Data Guard-related parameters need to be configured during RMAN execution. In previous versions, these parameters needed to be set manually.

Prepare the script:

Run {

Duplicate target database for standby from active database

Spfile

Parameter_value_convert 'ora11g','ora11gsy'

Set db_unique_name='ora11gsy'

Set control_files='/u01/app/oradata/ORA11GSY/controlfile/ora11gsby01.ctl'

Set db_file_name_convert='ORA11G','ORA11GSY'

Set log_file_name_convert='ORA11G','ORA11GSY'

Set log_archive_max_processes='5'

Set fal_client='ora11gsy'

Set fal_server='ora11g'

Set standby_file_management='AUTO'

Set log_archive_config='dg_config= (ora11g,ora11gsy)'

Set log_archive_dest_2='service=ora11g async valid_for= (ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=ora11g'

}

Here are some caveats: control_files must be added to represent the control file method of the standby database. Other DG-related parameters are involved in the script. The valid_for project configured in Log_archive_dest_2 indicates that the database will only pass logs to the main library ora11g when it is in the primary_role role.

Save the script as a file, cr_standby_script.

[oracle@SimpleLinux dbs] $ls-l | grep cr

-rw-r--r--. 1 oracle oinstall 653 Apr 13 13:31 cr_standby_script

Start RMAN to duplicate, connect target and auxiliary.

[oracle@SimpleLinux dbs] $rman nocatalog

Recovery Manager: Release 11.2.0.4.0-Production on Sun Apr 13 13:32:18 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.

RMAN > connect target sys/oracle@ora11g

Connected to target database: ORA11G (DBID=4239941846)

Using target database control file instead of recovery catalog

RMAN > connect auxiliary sys/oracle@ora11gsy

Connected to auxiliary database: ORA11GSY (not mounted)

Execute the script:

RMAN > @ cr_standby_script

RMAN > run {

2 > duplicate target database for standby from active database

3 > spfile

4 > parameter_value_convert 'ora11g','ora11gsy'

5 > set db_unique_name='ora11gsy'

6 > set control_files='/u01/app/oradata/ORA11GSY/controlfile/ora11gsby01.ctl'

7 > set db_file_name_convert='ORA11G','ORA11GSY'

8 > set log_file_name_convert='ORA11G','ORA11GSY'

9 > set log_archive_max_processes='5'

10 > set fal_client='ora11gsy'

11 > set fal_server='ora11g'

12 > set standby_file_management='AUTO'

13 > set log_archive_config='dg_config= (ora11g,ora11gsy)'

14 > set log_archive_dest_2='service=ora11g async valid_for= (ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=ora11g'

15 >}

Starting Duplicate Db at 13-APR-14

Allocated channel: ORA_AUX_DISK_1

Channel ORA_AUX_DISK_1: SID=19 device type=DISK

(for reasons of space, there are omissions. )

Input datafile copy RECID=3 STAMP=844781878 file name=/u01/app/oradata/ORA11GSY/datafile/o1_mf_undotbs1_9mnjs068_.dbf

Datafile 4 switched to datafile copy

Input datafile copy RECID=4 STAMP=844781878 file name=/u01/app/oradata/ORA11GSY/datafile/o1_mf_users_9mnjs074_.dbf

Finished Duplicate Db at 13-APR-14

RMAN > * * end-of-file**

The script did not report an error and the execution was successful.

8. DG test

Next, let's check the effect of installing DG. On the standby side, you can log in to the database to check the status.

[oracle@SimpleLinux dbs] $env | grep ORACLE_SID

ORACLE_SID=ora11gsy

SQL > select name, open_mode, database_role from v$database

NAME OPEN_MODE DATABASE_ROLE

ORA11G MOUNTED PHYSICAL STANDBY

By default, Standby maintains the mounted state. The status of the main library is as follows:

SQL > select name, open_mode, database_role from v$database

NAME OPEN_MODE DATABASE_ROLE

ORA11G READ WRITE PRIMARY

Note: we modify the main database data on the basis of scope=spfile. Restart the main library:

SQL > startup force

ORACLE instance started.

Total System Global Area 372449280 bytes

Fixed Size 1364732 bytes

Variable Size 301993220 bytes

Database Buffers 62914560 bytes

Redo Buffers 6176768 bytes

Database mounted.

Database opened.

Check the database DG delivery, first check the log_archive_dest status. If valid is displayed, it means that it has been connected.

SQL > select dest_id, dest_name, status, binding, archiver, destination from v$archive_dest

DEST_ID DEST_NAME STATUS BINDING ARCHIVER DESTINATION

1 LOG_ARCHIVE_DEST_1 VALID MANDATORY ARCH USE_DB_RECOVERY_FILE_DEST

2 LOG_ARCHIVE_DEST_2 VALID OPTIONAL LGWR ora11gsy

For synchronization, check it in the v$archived_log view and notice the applied column. If it is passed to the standby side and apply is applied, the data is Yes.

SQL > select sequence#, name, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where standby_dest='YES' order by sequence#

SEQUENCE# NAME STANDBY_DEST ARCHIVED APPLIED

--

6 ora11gsy YES YES NO

7 ora11gsy YES YES NO

8 ora11gsy YES YES NO

Start the synchronization, to start the operation in the standby database. Apply is a continuous process, and we must add the disconnect from session command to start the connection operation, so that the application execution action can be carried out in the background.

SQL > alter database recover managed standby database using current logfile disconnect from session

Database altered

The application of each archive log in the main library is as follows:

SQL > select sequence#, name, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log where standby_dest='YES' order by sequence#

SEQUENCE# NAME STANDBY_DEST ARCHIVED APPLIED

--

6 ora11gsy YES YES YES

7 ora11gsy YES YES YES

8 ora11gsy YES YES YES

9 ora11gsy YES YES NO

You can also see the application process in the archive log on the Standby side.

SQL > select sequence#, name, STANDBY_DEST, ARCHIVED, APPLIED from v$archived_log order by sequence#

SEQUENCE# NAME STANDBY_DEST ARCHIVED APPLIED

-

6 / u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_13/o1_mf_1_6_9nn99r20_.a NO YES YES

7 / u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_13/o1_mf_1_7_9nn99k17_.a NO YES YES

8 / u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_13/o1_mf_1_8_9nn99qff_.a NO YES YES

9 / u01/app/fast_recovery_area/ORA11GSY/archivelog/2014_04_13/o1_mf_1_9_9nn9zxyx_.a NO YES IN-MEMORY

Synchronization is successful!

9. Synchronous testing

Let's verify the database synchronization action through a simple experiment. Create a database table under user scott.

SQL > conn scott/tiger@ora11g

Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.4.0

Connected as scott

SQL > create table t_psby as select * from dba_objects

Table created

SQL > select count (*) from t_psby

COUNT (*)

-

86032

Switch to the standby library, which cannot be read in the mount state, and requires the first open database. But the lab failed.

[oracle@SimpleLinux ~] $sqlplus / nolog

SQL*Plus: Release 11.2.0.4.0 Production on Sun Apr 13 14:05:26 2014

Copyright (c) 1982, 2013, Oracle. All rights reserved.

SQL > conn / as sysdba

Connected.

SQL > alter database open

Alter database open

*

ERROR at line 1:

ORA-10456: cannot open standby database; media recovery session may be in

Progress

We are currently applying the status of log synchronization. When synchronizing, you cannot open. We need to first synchronize this log action in cancel.

SQL > conn / as sysdba

Connected.

SQL > alter database recover managed standby database cancel

Database altered.

SQL > alter database open

Database altered.

Scott user data table creation.

SQL > conn scott/tiger@ora11gsy

Connected.

SQL > select count (*) from t_psby

COUNT (*)

-

86032

Add data to the main database data table and modify it.

SQL > insert into t_psby select * from dba_objects

86032 rows inserted

SQL > commit

Commit complete

SQL > select count (*) from t_psby

COUNT (*)

-

172064

At this point, the standby library is not synchronized. Because we just turned off cancel synchronization. Let's start the synchronization process and accept the new data.

SQL > alter database recover managed standby database using current logfile disconnect from session

Database altered.

SQL > select open_mode from v$database

OPEN_MODE

-

READ ONLY WITH APPLY

SQL > select count (*) from scott.t_psby

COUNT (*)

-

172064

Synchronization is successful! Note: in 11g, the READ ONLY WITH APPLY status indicates that the database Redo Log can be applied at the same time as synchronization. In the case of a previous version, the database needs to be restored to the mount state. This is the Advanced in 11g.

This is the end of this article on "how to configure Step By Step in Oracle 11gR2 Active DataGuard". I hope the above content can be helpful to you so that you can learn more knowledge. if you think the article is good, please share it out for more people to see.

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.