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

How to establish oracle data guard in physical way, aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Establishing oracle data guard in physical way (1): prelude

After tossing around for a week or so, I have matched the physical establishment of ORACLE data guard. My colleagues have helped a lot. I would like to express my thanks here. In this process, we encountered a lot of problems, some of which were very simple and were solved at once; some of the problems were caused by carelessness, for example, there was less writing in the server parameter file, and it took a long time to troubleshoot. Some problems are encountered for the first time, and I am very excited after solving them, because I have accumulated experience, just like the problem I encountered when configuring HP MC dual computers, which I have never encountered before. I still know such a command like kcmodule with some different kernel parameters.

I also tried to configure data guard before, referred to some documentation books, and finally failed, and there was no turning back on the problem that the log files of the primary and standby nodes could not be synchronized. After this time, I found that many reference documents and even published technical books on the Internet are ambiguous and incomplete, and many areas that should be specifically pointed out have been ignored by them. many places that can be omitted have spent a lot of space to explain, which is not necessary.

"the original parameters of RAC remain unchanged, and the following parameters are added:

The "service.name" in the sentence "service.name=wxxr_rac" should be "service.names". Without a "s", sometimes this is the case, and the parameters involved should be more rigorous. I also encountered such a mistake once in the course of the experiment, which made the whole person collapse. Fortunately, I found the problem later.

In addition, the process of switching between active and standby nodes is also relatively rough, a bit of a passing feeling, in fact, this part is precisely more important.

In my opinion, the more important files involved in the process of configuring data guard are server parameter files, password files, listener.ora files and tnsnames.ora files, among which server parameter files and listener.ora are the most important, because the static way to configure listener.ora files here is not feasible in the past, because it is necessary to ensure that the standby node can also register with the database in mount mode. This cannot be done in a dynamic manner.

ORACLE data guard and ORACLE RAC are both popular stars, becoming more and more popular, playing an important role in banks, enterprises, government agencies and so on. In

"the strength of RAC lies in solving single points of failure and load balancing, so RAC solutions are common in 24-7 core systems. However, there is only one data in the RAC scheme. Although storage failures can be avoided through mechanisms such as RAID, the data itself is not redundant and is easy to form a single point of failure. Data Guard provides data protection through redundant data. The synchronization between the redundant data and the main database is ensured by the log synchronization mechanism, which can be real-time, delayed, synchronous and asynchronous. Often used for remote disaster recovery and high availability solutions for small businesses. "

There are two ways to implement ORACLE data guard, one is data guard in physical mode, which is used in my experiment, which is realized by synchronizing redo logs on master node on the slave node, and the other is data guard in logic mode, which synchronizes logs by applying SQL statements converted from redo logs on master node on slave node. Since this method is not as common as the physical method, I will do the data guard experiment in the physical mode for the time being and talk about it logically later.

Let's get down to business.

Establishing oracle data guard in physical way (2): environment

First, the operating system, the two partitions on the HP rx8640 server used here, create the "/ dev/vg00/lv_oracle" file system and mount it to the "/ home/db/oracle" directory, and then create the "/ dev/vg00/lv_arch" file system and mount it to the "/ arch" directory as a place to store the archive logs. Remember to give the directory the correct oracle:dba and permissions after creation, otherwise there will be a big problem.

ORACLE version is used here is 10.2.0.1, before the first experiment did not notice that the two selected partition oracle version is not the same, one node version is 10.2.0.1, the other node version is 10.2.0.3. At first, when I used RMAN for backup and restore to the standby node, the system suddenly reminded me that the data needed to be upgraded, which made me stupefied. I checked carefully and found that the version of the database was inconsistent. Although the version is inconsistent, it can be done. This is the case when the situation is better. The oracle version of the master node is lower than that of the slave node. It will be troublesome if the oracle version of the master node is higher than that of the slave node.

Another problem is SID. I set the SID of the instance to ora for both the primary node and the slave node. This is for convenience, or the instance names of both sides can be set to inconsistent. The advantage of making it consistent is that it is less troublesome to modify server parameter files, less modification, less work, and naturally fewer errors.

Let's get back to the topic again, first, install the oracle10.2.0.1 version database software in the correct path of the primary node and the standby node respectively (the standby node does not need to establish the database separately through the graphical interface, but recover from the primary node), and then build the database on the primary node through the dbca way of the graphical interface. In order to facilitate the map and meet the experimental results, neither bare equipment nor ASM is used to build the library here, everything can go down according to the default way of the system.

Because the master node needs to be set to archive mode, we can specify the archive mode when building the database, and specify the archive path as "/ arch", so that we do not have to manually modify it to archive mode after the database is built, as shown below:

SQL > archive log list

Database log mode Archive Mode

Automatic archival Enabled

Archive destination / arch

Oldest online log sequence 1

Next log sequence to archive 2

Current log sequence 2

Establishing oracle data guard in physical way (3): start construction

The following sets the primary node database to force logging mode:

SQL > alter database force logging

Database altered.

The meaning of the existence of force logging: to make Oracle write redo no matter what it does.

Through the select statement, you can see:

SQL > select FORCE_LOGGING from v$database

FOR

-

YES

Since the database has just been established and the archive log has not yet been generated, we can manually switch the log to let the database generate log files:

SQL > alter system switch logfile

System altered.

SQL > alter system switch logfile

System altered.

SQL > alter system switch logfile

System altered.

SQL > select name from v$archived_log

NAME

/ arch/1_2_697298091.dbf

/ arch/1_3_697298091.dbf

/ arch/1_4_697298091.dbf

View existing log files:

SQL > select * from v$logfile

Rows will be truncated

GROUP# STATUS TYPE MEMBER

3 ONLINE / home/db/oracle/oradata/ora/redo03.log

2 ONLINE / home/db/oracle/oradata/ora/redo02.log

1 ONLINE / home/db/oracle/oradata/ora/redo01.log

Create three sets of log files of the same size for the standby node and verify:

SQL > alter database add standby logfile group 4 ('/ home/db/oracle/oradata/ora/redo04.log') size 50m

Database altered.

SQL > alter database add standby logfile group 5 ('/ home/db/oracle/oradata/ora/redo05.log') size 50m

Database altered.

SQL > alter database add standby logfile group 6 ('/ home/db/oracle/oradata/ora/redo06.log') size 50m

Database altered.

SQL > select * from v$logfile

Rows will be truncated

GROUP# STATUS TYPE MEMBER

3 ONLINE / home/db/oracle/oradata/ora/redo03.log

2 ONLINE / home/db/oracle/oradata/ora/redo02.log

1 ONLINE / home/db/oracle/oradata/ora/redo01.log

5 STANDBY / home/db/oracle/oradata/ora/redo05.log

4 STANDBY / home/db/oracle/oradata/ora/redo04.log

6 STANDBY / home/db/oracle/oradata/ora/redo06.log

6 rows selected.

Shutting down the database is coming to the first important step of modifying the server parameter file.

SQL > shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

Establishing oracle data guard in physical way (4): change

The newly established database is started in the form of a server parameter file, and what we want to modify is the parameter file. Here we briefly talk about the difference and relationship between the server parameter file and the parameter file. The server parameter file is spfileSID.ora, its content is binary and cannot be edited manually, while the parameter file, initSID.ora, whose content is text, can be edited manually. Here I need to modify the parameter file.

Generally speaking, there will be a default parameter file init.ora, but what we need here is initora.ora, which can be created by command if not, as shown below:

SQL > create pfile='/home/db/oracle/10g/dbs/initora.ora' from spfile

To see whether the current database is started as a server parameter file or a parameter file, you can view it through the command, as shown below:

SQL > show parameter spfile

NAME TYPE VALUE

-

Spfile string / home/db/oracle/10g/dbs/spfile

Ora.ora

If there is a corresponding file under VALUE, it is started in the form of spfile, that is, the server parameter file. On the contrary, it is started as a parameter file. The previous article stopped the database in order to start the database with the newly modified parameter file after the parameter file was modified.

The following is the revised parameter file, which is indicated in boldface:

$vi initora.ora

Ora.__db_cache_size=780140544

Ora.__java_pool_size=4194304

Ora.__large_pool_size=4194304

Ora.__shared_pool_size=276824064

Ora.__streams_pool_size=0

* .audit_file_dest='/home/db/oracle/admin/ora/adump'

* .background_dump_dest='/home/db/oracle/admin/ora/bdump'

* .compatible='10.2.0.1.0'

* .control_files='/home/db/oracle/oradata/ora/control01.ctl','/home/db/oracle/oradata/ora/control02.ctl','/home/db/oracle/oradata/ora/control03.ctl'

* .core_dump_dest='/home/db/oracle/admin/ora/cdump'

* .db_block_size=8192

* .db_domain=''

* .db_file_multiblock_read_count=16

* .db_name='ora'

* .db_recovery_file_dest='/home/db/oracle/flash_recovery_area'

* .db_recovery_file_dest_size=2147483648

* .db_unique_name='10gpri'

* .dispatchers=' (PROTOCOL=TCP) (SERVICE=oraXDB)'

* .fal_client='10gstandby'

* .fal_server='10gpri'

* .job_queue_processes=10

* .log_archive_config='DG_CONFIG= (10g primer 10g standby)'

* .log_archive_dest_1='LOCATION=/arch VALID_FOR= (all_logfiles,all_roles) db_unique_name=10gpri'

* .log_archive_dest_2='service=10gstandby arch async valid_for= (online_logfiles,primary_role) db_unique_name=10gstandby'

* .log_archive_dest_state_1='enable'

* .log_archive_dest_state_2='enable'

* .log_archive_format='%t_%s_%r.dbf'

* .open_cursors=300

* .pga_aggregate_target=3418357760

* .processes=150

* .remote_login_passwordfile='EXCLUSIVE'

* .sga_target=1073741824

* .standby_file_management='auto'

* .undo_management='AUTO'

* .undo_tablespace='UNDOTBS1'

* .user_dump_dest='/home/db/oracle/admin/ora/udump'

As for why to add and modify these parameters, official documents, other people's documents, technical books all say, google or Baidu or Baiguhu a lot, I will not elaborate. In short, db_unique_name is very important, and if the instance names of the primary and back nodes are the same, it should be distinguished by this.

Establishing oracle data guard in physical way (5): metamorphosis

The next thing to do is to start the database with the modified parameter file and generate the server parameter file, and then let the database start the database as the server parameter file:

1. Start the database to nomount mode using the modified parameter file:

SQL > startup pfile='/home/db/oracle/10g/dbs/initora.ora' nomount

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 1999160 bytes

Variable Size 285216456 bytes

Database Buffers 780140544 bytes

Redo Buffers 6385664 bytes

2. Create a server parameter file:

SQL > create spfile from pfile='/home/db/oracle/10g/dbs/initora.ora'

File created.

3. Start the database as the default server parameter file of the system:

SQL > shutdown immediate

ORA-01507: database not mounted

ORACLE instance shut down.

SQL > startup

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 1999160 bytes

Variable Size 285216456 bytes

Database Buffers 780140544 bytes

Redo Buffers 6385664 bytes

Database mounted.

Database opened.

4. Create a password file (if it exists after the database is built, there is no need to create a separate password file):

$orapwd file=/home/db/oracle/10g/dbs/orapwora password=oracle entries=10

$ls

Alert_ora.log init.ora lk10GPRI lkORA_SINGLE snapcf_ora.f

Hc_ora.dat initdw.ora lkORA orapwora spfileora.ora

I made a low-level mistake in this place and wasted a lot of time, which I said in the final summary.

Now it's time to talk about listening files and TNS files, and put down a topic in an article, because this step is very important. If it is not done well, the consequences will be very serious.

/

Establishing oracle data guard in physical way (6): movement

Next, let's talk about monitoring. This is where Carmen spent the longest time doing experiments, and this is also where the author of "lie ORACLE RAC" did not explain clearly. Many documents have mentioned that it is necessary to configure monitoring and TNS to a certain extent in the experiment to facilitate the interoperability between master and standby nodes. But ignore to mention that monitoring can be divided into dynamic monitoring and static monitoring, we must use static monitoring in the oracle data guard experiment, otherwise the experiment can not be carried out.

Let's first pick up a few concepts about dynamic and static monitoring:

Static listening refers to reading the listener.ora configuration file and registering the instance and service with the listener when the instance is started. Whenever a database is started, two pieces of information are registered with the listener by default: instance and service

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = Ora8)

(SID_NAME = test)

)

)

LISTENER =

(DESCRIPTION =

(ADDRESS = (HOST = 192.168.0.88) (PROTOCOL = TCP) (PORT = 1522))

)

This is the simplest static listening configuration file, where the GLOBAL_DBNAME in the SID_LIST_LISTENER section represents the name of the service provided to the outside, and SID_NAME is the instance that provides registration. In the CONNECT_DATA section of the tnsnames.ora file, you can select SERVICE_NAME=Ora8 or SID=test to provide the client with a connection.

Dynamic registration does not need to display the configuration listener.ora file, when the instance is started, the PMON process dynamically registers the instance and service into listerer according to the instance_name,service_name parameter. If instance_name is not set, the parameter value is initialized using db_name. If service_names is not set, the db_name and db_domain parameter values are concatenated to register snooping.

If I still don't quite understand what I said above, let me briefly say the most important difference. In the oracle data guard experiment, sometimes we need to boot the standby node into mount mode to accept the redo log files of the primary node to complete its own synchronization process. The premise of this process is that there should be an interaction between the two on the Internet, that is, you can stare at me and I can care about you. If dynamic snooping is configured, as long as an instance is not started to open state, the service cannot be registered to the database through the network, and only static snooping can accomplish this task. Many documents point out the need to modify listener.ora files, but do not implement what is static monitoring and what is dynamic monitoring, so it is easy to make mistakes in specific operation, and then wonder if there is something wrong with the configuration of parameter files.

The following shows the static listening content I configured as well as the contents of the TNS file:

$cat listener.ora

# listener.ora Network Configuration File: / u1/app/oracle/product/10.2.0/db_1/network/admin/listener.ora

# Generated by Oracle configuration tools.

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = 128.199.36.152) (PORT = 1521))

)

)

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(SID_NAME = PLSExtProc)

(ORACLE_HOME = / home/db/oracle/10g)

(PROGRAM = extproc)

)

(SID_DESC =

(GLOBAL_DBNAME = ora)

(ORACLE_HOME = / home/db/oracle/10g)

(SID_NAME = ora)

)

)

Unlike dynamic snooping, the ORACLE_HOME path and SID name are manually specified.

$cat tnsnames.ora

# tnsnames.ora Network Configuration File: / home/db/oracle/10g/network/admin/tnsnames.ora

# Generated by Oracle configuration tools.

10GPRI =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = 128.199.36.152) (PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = ora)

)

)

ORA =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = 128.199.36.152) (PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = ora)

)

)

10GSTANDBY =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = 128.199.36.53) (PORT = 1521))

)

(CONNECT_DATA =

(SERVICE_NAME = ora)

)

)

The two services are 10GPRI and 10GSTANDBY.

/ / /

Establishing oracle data guard in physical way (7): testing

Dynamic monitoring and static monitoring have been explained earlier. Let's do an experiment to see whether the database can be registered to the database through the network in the mount state. Here is the implementation process:

1. Before starting, it is important to note that the opening and closing of the monitoring has something to do with the opening and closing of the database. The correct order is to start listening first, and then to open the database to mount. If you want to do it again, shut down the database first, and then restart listening.

2. Close the primary node database and start it to mount (so far, the operation on the slave node has not started yet):

SQL > shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL > startup mount

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 1999160 bytes

Variable Size 285216456 bytes

Database Buffers 780140544 bytes

Redo Buffers 6385664 bytes

Database mounted.

3. Start listening:

$lsnrctl start

LSNRCTL for HPUX: Version 10.2.0.1.0-Production on 11-SEP-2009 14:13:53

Copyright (c) 1991, 2005, Oracle. All rights reserved.

Starting / home/db/oracle/10g/bin/tnslsnr: please wait...

TNSLSNR for HPUX: Version 10.2.0.1.0-Production

System parameter file is / home/db/oracle/10g/network/admin/listener.ora

Log messages written to / home/db/oracle/10g/network/log/listener.log

Listening on: (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=128.199.36.152) (PORT=1521)

Connecting to (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=128.199.36.152) (PORT=1521)

STATUS of the LISTENER

-

Alias LISTENER

Version TNSLSNR for HPUX: Version 10.2.0.1.0-Production

Start Date 11-SEP-2009 14:13:53

Uptime 0 days 0 hr. 0 min. 0 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File / home/db/oracle/10g/network/admin/listener.ora

Listener Log File / home/db/oracle/10g/network/log/listener.log

Listening Endpoints Summary...

(DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=128.199.36.152) (PORT=1521))

Services Summary...

Service "PLSExtProc" has 1 instance (s).

Instance "PLSExtProc", status UNKNOWN, has 1 handler (s) for this service...

Service "ora" has 1 instance (s).

Instance "ora", status UNKNOWN, has 1 handler (s) for this service...

The command completed successfully

From here, you can see that the monitor has been activated successfully. It is worth mentioning that when static listening is enabled, the status of the instance is displayed as "UNKNOWN", while when dynamic monitoring is enabled, the status of the instance should be displayed as "READY". According to this point, we can also judge how the monitoring is started.

4. The test registers to the database in a network way:

$sqlplus sys/oracle@10gpri as sysdba

SQL*Plus: Release 10.2.0.1.0-Production on Fri Sep 11 15:01:20 2009

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

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-64bit Production

With the Partitioning, OLAP and Data Mining options

SQL >

Note: if you type "sqlplus system/oracle@10gpri as sysdba may still not register to the database, this needs to be done by giving sysdba the command to the system user."

After the success of this step, the following process will be easier to handle.

/ / /

Establishing oracle data guard in physical way (8): accident

The previous article mentioned that it is a relatively smooth situation to register the database on the network when starting static monitoring and booting the database to mount mode. I also encountered a more confusing problem before. Let's discuss this situation below.

Previously, the listening file and TNS file were successfully configured, and the database was also launched to mount, but the database could not be registered through the network. The following error message appears:

ORA-01031: insufficient privileges

The prompt does not have enough permissions, are you kidding me? I am logged in as a sys user, doesn't sys have the highest privileges? And the password was not typed incorrectly. Check the listener.ora and tnsnames.ora files carefully to make sure there are no problems. Because that's how it's set up in another environment. Try to look at the users with SYSDBA privileges:

SQL > select * from v$pwfile_users

USERNAME SYSDB SYSOP

No rows selected.

See here, the problem is clearer, the password file did not work. Because the database is registered through the network, it is necessary to read the password file, and SYS has SYSDBA permissions by default, which cannot be displayed here, indicating that the password file has not been successfully read, so it will naturally be unable to register to the database. To make a simple analogy, Xiao Ming wants to cheat before a Chinese final exam. The way to cheat is to spend some money to buy an answer, and as a result, he buys a fake answer, which naturally fails the exam. This situation leads to the same goal by different routes.

Recall that after the system built the library, a correct password file was generated by default, but I was cheap, so I deleted the file, recreated it, and named it orapw10gstandby.ora. This naming made two mistakes, which also led me to re-examine my understanding of the standardization of password files. First of all, password files do not have a .ora suffix; second, the suffix should be named in the standard "orapwSID" way. In this way, I deleted the misnamed password file and re-created the password file:

Orapwd file=/home/db/oracle/10g/dbs/orapwora password=oracle entries=10

Re-query the database for users with SYSDBA:

SQL > select * from v$pwfile_users

USERNAME SYSDB SYSOP

SYS TRUE TRUE

This is not, back again, and then check through the network registration database, everything is normal, so this problem is over.

The reason for writing such a long article is to emphasize the importance of password files, and what we often ignore is the most worthy of attention.

/ / /

Establishing oracle data guard in physical way (9): favor

Up to now, I can't tell whether I'm writing a technology blog or a life blog. I'm more or less personal. After all, I haven't been studying data guard for a short time. It should be that there is little talent and learning, or it is too stupid to learn things slowly, but I can't restrain my excitement when I see progress. Not to mention gossiping, the next step is to spoil the lucky node. After all, the military medal of data guard has half of the master node and half of the backup node.

The steps that the master node needs us to complete are roughly those mentioned in the previous articles, leaving only the final switching test process. The backup node needs to pay attention to the following aspects:

Directories, parameter files, password files, listening files, TNS files, SID (continue to use ora here)

At this point, in addition to parameter files and listening files that need to be slightly changed, other files such as password files and TNS files can be copied from the master node, and the directory can be created manually according to the same path of the master node, which is just mkdir under unix. Faster, you can implement it with mkdir-p. Here is the specific process:

1. Create / home/db/oracle/oradata/ora home directory and udump, adump, cdump, bdump and other subdirectories under the home directory

2. Copy the password file and TNS file under the master node by ftp

3. Perform several log switches on the master node to generate a certain amount of archived log files:

SQL > alter system switch logfile

System altered.

SQL > alter system switch logfile

System altered.

SQL > alter system switch logfile

System altered.

SQL > select name from v$archived_log

NAME

/ arch/1_2_697298091.dbf

/ arch/1_3_697298091.dbf

/ arch/1_4_697298091.dbf

/ arch/1_5_697298091.dbf

/ arch/1_6_697298091.dbf

/ arch/1_7_697298091.dbf

6 rows selected.

4. Stop the master node database and copy the archive log files and all data files

NOTE: after copying to the slave node, check whether the owner is correct, otherwise modify as follows:

Root@hpvm3:/home/db/oracle/oradata/ora#chown oracle:dba *

5. Start the master node database into mount mode and create a standby control file:

SQL > startup mount

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 1999160 bytes

Variable Size 289410760 bytes

Database Buffers 775946240 bytes

Redo Buffers 6385664 bytes

Database mounted.

SQL > alter database create standby controlfile as'/ arch/standby.ctl'

Database altered.

6. Copy the standby control file to the slave node and assign it to the correct master:

Root@hpvm3:/home/db/oracle/oradata/ora#chown oracle:dba standby.ctl

7. Modify the slave node parameter file as follows:

Root@hpvm3:/arch#vi initstandby.ora

"initstandby.ora" 35 lines, 1328 characters

Ora.__db_cache_size=805306368

Ora.__java_pool_size=4194304

Ora.__large_pool_size=4194304

Ora.__shared_pool_size=251658240

Ora.__streams_pool_size=0

* .audit_file_dest='/home/db/oracle/admin/ora/adump'

* .background_dump_dest='/home/db/oracle/admin/ora/bdump'

* .compatible='10.2.0.1.0'

* .control_files='/home/db/oracle/oradata/ora/standby.ctl'

* .core_dump_dest='/home/db/oracle/admin/ora/cdump'

* .db_block_size=8192

* .db_domain=''

* .db_file_multiblock_read_count=16

* .db_name='ora'

* .DB_UNIQUE_NAME='10gstandby'

* .log_archive_config='DG_CONFIG= (10g primer 10g standby)'

* .db_recovery_file_dest='/home/db/oracle/flash_recovery_area'

* .db_recovery_file_dest_size=2147483648

* .dispatchers=' (PROTOCOL=TCP) (SERVICE=oraXDB)'

* .job_queue_processes=10

* .log_archive_dest_1='LOCATION=/arch VALID_FOR= (ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=10gstandby'

* .log_archive_dest_2='service=10gpri arch ASYNC VALID_FOR= (ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=10gpri'

* .LOG_ARCHIVE_DEST_STATE_1=ENABLE

* .LOG_ARCHIVE_DEST_STATE_2=ENABLE

* .FAL_SERVER=10gstandby

* .FAL_CLIENT=10gpri

* .open_cursors=300

* .pga_aggregate_target=3418357760

* .processes=150

* .remote_login_passwordfile='EXCLUSIVE'

* .sga_target=1073741824

* .undo_management='AUTO'

* .undo_tablespace='UNDOTBS1'

* .STANDBY_FILE_MANAGEMENT=AUTO

* .user_dump_dest='/home/db/oracle/admin/ora/udump'

After all this work is done, ok, it is our turn for the backup node to enter the stage of history.

/ /

Establishing oracle data guard in physical way (10): revolution

Without mentioning the gossip, let's go straight to the point and see what the node has done:

1. Take the modified parameter file as an excellent representative, start the slave node database to nomount mode:

SQL > startup nomount pfile='/arch/initstandby.ora'

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 1999192 bytes

Variable Size 264244904 bytes

Database Buffers 805306368 bytes

Redo Buffers 2191360 bytes

2, create the server parameter file and close the database:

SQL > create spfile from pfile='/arch/initstandby.ora'

File created.

SQL > shutdown immediate

ORA-01507: database not mounted

ORACLE instance shut down.

3. Start the modified listening (you only need to modify the IP address):

$lsnrctl start

LSNRCTL for HPUX: Version 10.2.0.1.0-Production on 11-SEP-2009 15:54:36

Copyright (c) 1991, 2005, Oracle. All rights reserved.

Starting / home/db/oracle/10g/bin/tnslsnr: please wait...

TNSLSNR for HPUX: Version 10.2.0.1.0-Production

System parameter file is / home/db/oracle/10g/network/admin/listener.ora

Log messages written to / home/db/oracle/10g/network/log/listener.log

Listening on: (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=128.199.36.53) (PORT=1521)

Connecting to (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=128.199.36.53) (PORT=1521)

STATUS of the LISTENER

-

Alias LISTENER

Version TNSLSNR for HPUX: Version 10.2.0.1.0-Production

Start Date 11-SEP-2009 15:54:36

Uptime 0 days 0 hr. 0 min. 0 sec

Trace Level off

Security ON: Local OS Authentication

SNMP OFF

Listener Parameter File / home/db/oracle/10g/network/admin/listener.ora

Listener Log File / home/db/oracle/10g/network/log/listener.log

Listening Endpoints Summary...

(DESCRIPTION= (ADDRESS= (PROTOCOL=tcp) (HOST=128.199.36.53) (PORT=1521))

Services Summary...

Service "PLSExtProc" has 1 instance (s).

Instance "PLSExtProc", status UNKNOWN, has 1 handler (s) for this service...

Service "ora" has 1 instance (s).

Instance "ora", status UNKNOWN, has 1 handler (s) for this service...

The command completed successfully

4. Start the database to mount:

$sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0-Production on Fri Sep 11 15:54:55 2009

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

Connected to an idle instance.

SQL > startup mount

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 1999192 bytes

Variable Size 264244904 bytes

Database Buffers 805306368 bytes

Redo Buffers 2191360 bytes

Database mounted.

5. There is no problem with testing to register the database in a network way:

$sqlplus sys/oracle@10gstandby as sysdba

SQL*Plus: Release 10.2.0.1.0-Production on Fri Sep 11 15:01:20 2009

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

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-64bit Production

With the Partitioning, OLAP and Data Mining options

SQL >

6. Start the master node database:

$sqlplus "/ as sysdba"

SQL*Plus: Release 10.2.0.1.0-Production on Fri Sep 11 15:59:29 2009

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

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.1.0-64bit Production

With the Partitioning, OLAP and Data Mining options

SQL > alter database open

Database altered.

7. Shut down the slave node database again and start it to mount in standby mode:

SQL > startup nomount

ORACLE instance started.

Total System Global Area 1073741824 bytes

Fixed Size 1999192 bytes

Variable Size 264244904 bytes

Database Buffers 805306368 bytes

Redo Buffers 2191360 bytes

SQL > alter database mount standby database

Database altered.

8. Change the slave node to accept the primary node redo log mode:

SQL > alter database recover managed standby database disconnect from session

Database altered.

9. Check the switching status:

SQL > select switchover_status from v$database

SWITCHOVER_STATUS

-

TO PRIMARY

If it is displayed as TO PRIMARY, everything is fine.

At this point, the revolution process of the standby node is over, and the master node echoes with each other. In order to fully receive the redo log of the master node, the master node needs to make some actions, together with the master / standby switch to the next section.

/ / / /

Establishing oracle data guard in physical way (11): meet

The work that needs to be done by the standby node has been completed, and it is time for the primary and standby nodes to ventilate each other. There are two criteria for judging whether the data guard is built successfully, one is to see whether the logs of the master / slave node can be synchronized, and the other is to see whether the master / slave can switch smoothly and complete the role conversion. The following is about to start the process of synchronization between master and slave logs:

1. Perform log switching on the primary node:

SQL > alter system switch logfile

System altered.

2. View the current number of archive logs:

SQL > select name from v$archived_log

NAME

/ arch/1_2_697298091.dbf

/ arch/1_3_697298091.dbf

/ arch/1_4_697298091.dbf

/ arch/1_5_697298091.dbf

/ arch/1_6_697298091.dbf

/ arch/1_7_697298091.dbf

/ arch/1_8_697298091.dbf

10gstandby

10gstandby

10gstandby

10gstandby

10gstandby

10gstandby

10gstandby

14 rows selected.

At this time, seven lines of 10gstandby appear, and the number of synchronized past logs under the slave node is the same as that of the archived logs under the master node, indicating that the master / slave logs are synchronized successfully. If you are not assured, you can check the synchronization of the archive log in the slave node:

SQL > select name from v$archived_log

NAME

/ arch/1_2_697298091.dbf

/ arch/1_3_697298091.dbf

/ arch/1_4_697298091.dbf

/ arch/1_5_697298091.dbf

/ arch/1_6_697298091.dbf

/ arch/1_7_697298091.dbf

/ arch/1_8_697298091.dbf

Ok, so that the master and backup nodes are synchronized with the log.

If the master / slave node cannot synchronize logs, it depends on whether there is a problem with the communication between the two nodes. This can be achieved through tnsping, for example:

$tnsping 10gpri

TNS Ping Utility for HPUX: Version 10.2.0.1.0-Production on 15-SEP-2009 09:58:22

Copyright (c) 1997, 2005, Oracle. All rights reserved.

Used parameter files:

Used TNSNAMES adapter to resolve the alias

Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (HOST = 128.199.36.152) (PORT = 1521)) (CONNECT_DATA = (SERVICE_NAME = ora)

OK (0 msec)

In addition, you can execute the command:

Alter system set log_archive_dest_state_2='defer' scope=memory

Alter system set log_archive_dest_state_2='enable' scope=memory

To try to see if it's getting better.

If there is no way to carry out these two steps, then you should take a closer look at the alert log file to see what error messages are in it, and then analyze the specific problems.

Finished, over /

Refer:

[oracle@standby admin] $cat listener.ora

# LISTENER.ORA Network Configuration File: / opt/oracle/product/9.2.0/network/admin/listener.ora

# Generated by Oracle configuration tools.

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = IPC) (KEY = EXTPROC))

)

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = standby) (PORT = 1521))

)

)

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(SID_NAME = PLSExtProc)

(ORACLE_HOME = / opt/oracle/product/9.2.0)

(PROGRAM = extproc)

)

(SID_DESC =

(GLOBAL_DBNAME = primary)

(ORACLE_HOME = / opt/oracle/product/9.2.0)

(SID_NAME = primary)

)

)

[oracle@eygle admin] $cat listener.ora

# LISTENER.ORA Network Configuration File: / opt/oracle/product/9.2.0/network/admin/listener.ora

# Generated by Oracle configuration tools.

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = eygle) (PORT = 1521))

)

)

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = primary)

(ORACLE_HOME = / opt/oracle/product/9.2.0)

(SID_NAME = primary)

)

)

This is the answer to the question about how to establish oracle data guard in the physical way. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

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.