Summary of common maintenance commands for Oracle 10g Dataguard

Dataguard can provide redundancy of Oracle database, data protection, fault recovery and so on, realize fast handover and disaster recovery of database. When the production database is guaranteed transactional consistency, a standby database is created using a physical full backup of the production library, which is automatically maintained by an archive log or redo entry that is transferred from the production library.

Dataguard Data synchronization technology has the following advantages:

1 The Oracle database itself has built-in functionality that is fully compatible with the new features of each Oracle new release and does not require additional billing.
2 configuration management is simpler, do not need to be familiar with other third party software products.
3 The physical standby database supports any type of data object and data type;
4 The logical standby database is open, you can keep the data synchronized while executing the query and other operations.
5 in the maximum protection mode, you can ensure that 0 of the data loss.

Now we're going to get you guys to sort out some common maintenance commands for Oracle 10g Dataguard.

Basic common

1. Stop standby


Select process, status from V$managed_standby; --See if the standby is restored in the application log


ALTER DATABASE recover managed standby database cancel;


Shutdown immediate;





2. Switch to read-only mode


-----switched from Shutdown mode to read-only mode-------


Startup Nomount;


ALTER DATABASE mount standby database;


ALTER DATABASE open read only;


-----switched from Application log mode to read-only mode-------


ALTER DATABASE recover managed standby database cancel; --Cancel Log application


ALTER DATABASE open read only;





3. Switch back to admin recovery mode


Startup Nomount;


ALTER DATABASE mount standby database;


ALTER DATABASE recover managed standby database disconnect from session; --Start Log application


ALTER DATABASE recover managed standby database using current logfile disconnect from session;





4. Role switching between the primary and standby libraries


4.1 Master library switch to standby library


ALTER DATABASE commit to switchover to physical standby;


The time when the ALTER database commit to switchover to physical standby and session shutdown;--The main library is connected


Shutdown immediate


Startup Nomount;


ALTER DATABASE mount standby database;


ALTER DATABASE recover managed standby database disconnect from session;





4.2 Switch from library to main library


ALTER DATABASE commit to switchover to primary;


Shutdown immediate;


Startup


alter system switch logfile;





5. The standby library automatically uses the log from the main library to restore


ALTER DATABASE recover automatic standby database;





6. Change protection mode


ALTER DATABASE set standby database to maximize protection;


ALTER DATABASE set standby database to maximize availability;


ALTER DATABASE set standby database to maximize Performancen;





7. Cancel Automatic recovery mode


ALTER DATABASE recover managed standby database cancel;


ALTER DATABASE recover managed standby database finish;


ALTER DATABASE recover managed standby database finish force;

The first part of daily maintenance

Opening the main and standby libraries correctly
1 Main Library:
Sql> STARTUP MOUNT;
sql> ALTER DATABASE Archivelog;
sql> ALTER DATABASE OPEN;
2 Reserve Library:
Sql> STARTUP MOUNT;
sql> ALTER database RECOVER MANAGED STANDBY database DISCONNECT from session;

Two correct shutdown order

1 Reserve Library:
sql> ALTER database RECOVER MANAGED STANDBY database CANCEL;
Sql>shutdown IMMEDIATE;
2 Main Library
Sql>shutdown IMMEDIATE;

Three-Spare library read-only mode open

Current Main Library normal open state
The standby is in log shipping state.
1 Stop log shipping in the repository
sql> Recover managed standby database cancel;
2 Standby read-only Mode open
Sql> ALTER DATABASE open read only;
3 Reserve Library back to log shipping mode
sql> Recover managed Standby database disconnect from session;
Media recovery complete.
Sql> select status from V$instance;
STATUS
------------
Mounted

4th Log Transfer Status monitoring

1 Main Library View current log status


Sql> select Sequence#,status from V$log;


sequence# STATUS


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


Wuyi ACTIVE


Current


M INACTIVE


2 Repository View RFS (Remote File Service) receive log status and MRP Application Log Sync Master library condition


Sql> SELECT PROCESS, STATUS, thread#, sequence#, block#, BLOCKS


2 from V$managed_standby;


PROCESS STATUS thread# sequence# block# BLOCKS


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


ARCH CONNECTED 0 0 0 0


ARCH CONNECTED 0 0 0 0


RFS receiving 0 0 0 0


MRP0 Wait_for_log 1 52 0 0


RFS receiving 0 0 0 0


You can see that the standby MPR0 is waiting for the sequence# to be 52 redo.


3 See if the repository is synchronized with the main library


Sql> SELECT archived_thread#, archived_seq#, applied_thread#, applied_seq#


2 from V$archive_dest_status;


archived_thread# archived_seq# applied_thread# applied_seq#


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


0 0 0 0


0 0 0 0


0 0 0 0


0 0 0 0


0 0 0 0


0 0 0 0


0 0 0 0


0 0 0 0


0 0 0 0


0 0 0 0


1 51 1 50


You can see that the standby has archived the SEQUENCE#51 logs and has applied the sequence#50 redo to the repository.


SEQUENCE#51 's previous data will not be lost because the sequence#51 log has been archived.

4 redo that have been archived by the standby library

Sql> SELECT Registrar, CREATOR, thread#, sequence#, first_change#,
2 next_change# from V$archived_log;
Registr CREATOR thread# sequence# first_change# next_change#
------- ------- ---------- ---------- ------------- ------------
SRMN SRMN 1 37 572907 573346
RFS ARCH 1 38 573346 573538
RFS ARCH 1 39 573538 573623
RFS ARCH 1 40 573623 573627
RFS ARCH 1 41 573627 574326
RFS ARCH 1 42 574326 574480
RFS ARCH 1 43 574480 590971
RFS ARCH 1 44 590971 593948
RFS FGRD 1 45 593948 595131
RFS FGRD 1 46 595131 595471
FGRD FGRD 1 46 595131 595471
Registr CREATOR thread# sequence# first_change# next_change#
------- ------- ---------- ---------- ------------- ------------
RFS ARCH 1 47 595471 595731
RFS ARCH 1 48 595731 601476
RFS ARCH 1 49 601476 601532
RFS ARCH 1 50 601532 606932
RFS ARCH 1 51 606932 607256

5 The redo that has been applied to the standby library

Sql> SELECT thread#, sequence#, first_change#, next_change#


2 from V$log_history;


thread# sequence# first_change# next_change#


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


1 1 366852 368222


1 2 368222 369590


1 3 369590 371071


1 4 371071 372388


1 5 372388 376781


1 6 376781 397744


1 7 397744 407738


1 8 407738 413035


1 9 413035 413037


1 10 413037 413039


1 11 413039 413098


thread# sequence# first_change# next_change#


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


1 12 413098 428161


1 13 428161 444373


1 14 444373 457815


1 15 457815 463016


1 16 463016 476931


1 17 476931 492919


1 18 492919 505086


1 19 505086 520683


1 20 520683 530241


1 21 530241 545619


1 22 545619 549203


thread# sequence# first_change# next_change#


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


1 23 549203 552403


1 24 552403 553230


1 25 553230 553398


1 26 553398 553695


1 27 553695 554327


1 28 554327 557569


1 29 557569 561279


1 30 561279 561385


1 31 561385 566069


1 32 566069 566825


1 33 566825 570683


thread# sequence# first_change# next_change#


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


1 34 570683 571627


1 35 571627 571867


1 36 571867 572907


1 37 572907 573346


1 38 573346 573538


1 39 573538 573623


1 40 573623 573627


1 41 573627 574326


1 42 574326 574480


1 43 574480 590971


1 44 590971 593948


thread# sequence# first_change# next_change#


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


1 45 593948 595131


1 46 595131 595471


1 47 595471 595731


1 48 595731 601476


1 49 601476 601532


1 50 601532 606932


1 51 606932 607256


You can see that the standby has already applied the archive file sequence# 51 to the repository.

6 View the standby receiving, the application of redo data process.

sql> SELECT message from V$dataguard_status;


Message


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


Arc0:archival started


Arc0:becoming the ' no FAL ' ARCH


Arc0:becoming the ' no SRL ' ARCH


Arc1:archival started


Arc1:becoming the Heartbeat ARCH


Redo Shipping Client Connected as Public


--Connected User is Valid


RFS[1]: Assigned to RFS process 19740


RFS[1]: Identified database type as ' physical standby '


Primary database is in MAXIMUM performance mode


Attempt to start background Managed Standby Recovery process


Message


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


Mrp0:background Managed Standby Recovery process started


Managed Standby Recovery not using real time Apply


Clearing online redo logfile 7/oraguard/redo1/redo_7_1.log


Clearing online redo LogFile 7 complete


Media Recovery waiting for thread 1 sequence 47


RFS[1]: No standby redo LogFiles created


Redo Shipping Client Connected as Public


--Connected User is Valid


RFS[2]: Assigned to RFS process 19746


RFS[2]: Identified database type as ' physical standby '


Primary database is in MAXIMUM performance mode


Message


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


Committing creation of Archivelog '/arch/1_47_552308270.arc '


Media Recovery Log/arch/1_47_552308270.arc


Media Recovery waiting for thread 1 sequence 48


Mrp0:background Media Recovery cancelled with status 16037


Mrp0:background Media Recovery Process shutdown


Managed Standby Recovery Canceled


Attempt to start background Managed Standby Recovery process


Mrp0:background Managed Standby Recovery process started


Managed Standby Recovery not using real time Apply


Media Recovery waiting for thread 1 sequence 48


RFS[1]: No standby redo LogFiles created


Message


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


Committing creation of Archivelog '/arch/1_48_552308270.arc '


Media Recovery Log/arch/1_48_552308270.arc


Media Recovery waiting for thread 1 sequence 49


RFS[1]: No standby redo LogFiles created


Committing creation of Archivelog '/arch/1_49_552308270.arc '


Media Recovery Log/arch/1_49_552308270.arc


Media Recovery waiting for thread 1 sequence 50


RFS[1]: No standby redo LogFiles created


Committing creation of Archivelog '/arch/1_50_552308270.arc '


Media Recovery Log/arch/1_50_552308270.arc


Media Recovery waiting for thread 1 sequence 51


Message


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


RFS[1]: No standby redo LogFiles created


Committing creation of Archivelog '/arch/1_51_552308270.arc '


Media Recovery Log/arch/1_51_552308270.arc


Media Recovery waiting for thread 1 sequence 52


You can see that RFS receives the sequence# 51 archive file to the standby archive directory/arch/1_51_552308270.arc.


Oracle Automatic application file/arch/1_51_552308270.arc to synchronize the repository with the main library


Oracle continues to wait for the main library sequence 52 archive

Maintenance of archive directory of five spare repositories

1 Find the Repository archive directory
Sql> Show Parameter Log_archive_dest_1
NAME TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
Log_archive_dest_1 string
Location=/arch
Valid_for= (All_logfiles,all_ro
LES)
Db_unique_name=ora2
Log_archive_dest_10 string

2 Maintenance Strategy

Weekly 2,4,7 Delete archived files that have been applied
See appendix II specifically

The second part of the main library normal switching

A manual intervention of the main library normal switching
1 Check the database to switch state on the main library side
Sql> SELECT switchover_status from V$database;
Switchover_status
-----------------
To STANDBY
1 row selected

Switchover_status:to standby indicates that you can switch normally.
If the value of Switchover_status is sessions active, indicates that there is currently a session in active state

2 Start Main Library normal switch

If the value of Switchover_status is to STANDBY:
Sql> ALTER DATABASE COMMIT to switchover to physical STANDBY;
If the value of Switchover_status is sessions ACTIVE:
Sql> ALTER DATABASE COMMIT to switchover to physical STANDBY with session SHUTDOWN;
When this command is successfully run, the main library is modified to a standby library

3 Reboot the previous main library

Sql> SHUTDOWN IMMEDIATE;
Sql> STARTUP MOUNT;

4 Verify the Switchable state in the repository

Sql> SELECT switchover_status from V$database;
Switchover_status
-----------------
To_primary
1 row selected
5 converting the target repository to the main library

If the value of Switchover_status is to STANDBY:
Sql> ALTER DATABASE COMMIT to switchover to PRIMARY;
If the value of Switchover_status is sessions ACTIVE:
Sql> ALTER DATABASE COMMIT to switchover to PRIMARY with the session SHUTDOWN;

When this command is successfully run, the repository is modified to the main library

6 Restart target Reserve

Sql> SHUTDOWN IMMEDIATE;
Sql> STARTUP;
7 previous Main Library start log shipping process
sql> ALTER DATABASE recover managed standby database disconnect;
Summary: This is the main library of a normal switch to complete. After the switch state, the original main library into a standby repository, the original repository changed to the main library.

Second, through the running script to achieve the main library normal switching
1 Master library switch to standby library
Running scripts on the main library
/admin/dataguard/switchover/primary_to_standby.sh

2 Reserve Library Switch Main Library
Run the script on the standby
/admin/dataguard/switchover/standby_to_primary.sh
After script 1 runs successfully, run script 2 again, and you cannot run two scripts at the same time.
After this handover, the original main library becomes a standby repository, the original reserve becomes the main data and open provides services for the application.
3 Recovery Initial State

Run a script on the original repository
/admin/dataguard/switchover/primary_to_standby.sh
After successful completion
Run scripts on the original library
/admin/dataguard/switchover/standby_to_primary.sh

Part III primary library disaster switching

A human intervention in the main library disaster switching
The second is to implement the master library disaster switching by running the script
Sql>alter database recover managed standby database cancel;
Sql>shutdown Immediate
Sql>startup Mount
Sql>alter database SET STANDBY database to maximize performance;
Sql>alter database recover managed standby database finish;
--Switch
Sql>alter database commit to switchover to primary with the session shutdown;
--Open
Sql>shutdown Immediate
Sql>startup
Report:
A selective view of redo transmission and application

Select Message from V$dataguard_status
where message_num>&message_num;

Second Standby archive directory maintenance script

Customize daily execution removecommand.sh in crontab.
Process: Daily 11:50pm execution removecommand.sh
assumes that today, in 2005-04-05, 04-04 and 04-03 days have been deleted. Keep the archived logs applied Today
[Oracle@db_gurid admin]$ crontab-l
* * * sh/oraguard/admin/removecommand.sh>>removearch.log
##################
[ Oracle@db_gurid admin]$ cat removecommand.sh
#!/bin/sh
Export Oracle_base=/ora10g/app
Export oracle_home=$ Oracle_base/product/10.1.0/db_1
Export oracle_sid=ora2
cd/oraguard/admin
$ORACLE _home/bin/sqlplus/ Nolog<<eof
Conn/as sysdba
@/oraguard/admin/removearch.sql
EOF
chmod +x/oraguard/admin/ removearch.sh
/oraguard/admin/removearch.sh>>removearch2.log
##################
[oracle@db_ Gurid admin]$ cat Removearch.sql
Set feed off
set heading out
Set echo off
spool removearch.sh
Select ' RM ' | | Name from V$archived_log where applied= ' YES ' and Completion_time>trunc (sysdate-3) and Completion_time<trunc ( Sysdate);
Spool off

Fourth part physical Dataguard daily operation Management (i)

3.1 Dataguard Common parameters

The transmission and application of logs can be counted as the core of Dataguard. As we build DG, how to configure the optimized Log transport service is related to the performance and availability of the entire DG system. Also, different protection modes require no combination of parameters. 10g, There are several main parameters that affect the configuration log transport:


1. ARCH/LGWR


Set the shipping mode for the log, using arch transfer by default. The transfer occurs at the edge of the log switch, in maximum available and maximum protection mode, and requires the use of LGWR to transfer the log. Using LGWR transfer logs, you need a standby to build standby logfile, and support the real-time application of the log.


2. Sync/async


This parameter represents the operation of network I/O, and sync indicates that network I/O will be synchronized with redo log writes, waiting for network I/O to finish receiving the response and continue with the next write operation. While async means that the log is delivered asynchronously, Oracle facilitates the LNS process, Receive the redo log information sent by LGWR into the buffer and asynchronously to the standby, or you can manually specify the size of the buffer


In maximum protection and maximum available mode, it needs to be set to sync Affim mode.


3. affimaffirm


This parameter is a property in the LGWR transfer mode that represents the disk I/O mode of the redo log, Affim indicates synchronization and sends a successful write operation state to the primary database, noaffirm indicates that the master library does not need to wait for the log write success of the standby.


4. mandatory/optional


This parameter represents the mode of the archive, and the default value is optional. Mandatory represents a mandatory archive, which can cause the primary library to wait for an archive if it is unsuccessful.


5. Reopenreopen


This parameter indicates whether the archive file receives an error message, retries, and the minimum time between retries.


6. Max_failure/nomax_failur


This parameter represents the maximum number of retries for a target file that was closed due to a failure. The set number is exceeded and will no longer be retried.


Nomax_failur says it's been retried.


7. Net_timeout


This parameter indicates the maximum wait time before the LNS process of the primary database abandons the network connection in the event of a network exception or some circumstances.


8. Delaydelay


This parameter represents the application mode of the log, delay indicates that the time delay specifies the application of the transferred log, nodelay indicates no delay.


This parameter action can also be implemented by releasing ALTER DATABASE recover managed standby database delay.


9. Valid_for


The introduction of Valid_for, in order to better implement the master-standby smooth switch, is used to describe when the target file is available and archived redo log types.


The Valid_for property consists of 2 parts: Archive_source (online_logfile,standby_logfile,all_logfiles) and Database_role (Primary_role, Standby_role,all_role).


Online_logfile: Indicates archived online redo logs


Standby_logfile: means redo Log/accepted redo log for archive standby database


All_logfiles:online_logfile &amp;&amp; Standby_logfile


Primary_role: Archiving takes effect only when the database role is the primary library


Standby_role: Only when the database role is archived for the standby


All_role: Any role archive takes effect

3.2 Choose Data protection mode


Table 3.2 log_archive_dest_n parameter property settings under different protection modes


Maximum protection Highest available Highest performance
REDO write process LGWR LGWR LGWR or ARCH
Network transmission mode SYNC SYNC LGSYNC process SYNC or ASYNC, ARCH process SYNC
Disk write operations AFFIRM AFFIRM AFFIRM or NOAFFIRM
Do I need Standby Redolog YES YES No, but it is recommended

 Below we enter the practice section to change a Data Guard configuration from the highest performance mode to the highest availability mode. The following operations are performed on the primary database side unless otherwise noted.

3.2.1 Change DG Maximum available mode





Master Library to view the main library protection mode by executing the following command





Sql&gt; select Protection_mode,protection_level from V$database;





Protection_mode Protection_level


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


MAXIMUM Performance MAXIMUM Perform


A





The current main library mode is the maximum performance mode, but also the establishment of the DG default mode, stop the log application of the repository, prior to the establishment of DG, the main reserve library has increased the standby_redolog, this step directly to do protection mode conversion





The following statement is executed on the main library


Sql&gt;alter system set log_archive_dest_2= ' service=syw01


LGWR SYNC


Affirm


Valid_for= (online_logfiles,primary_role) db_unique_name=syw01 '





Reboot the main library to the Mount State and execute the following statement on the main library





Sql&gt; ALTER DATABASE set standby database to maximize availability;


Performance mode,


Now let's test it. First disconnect the physical standby database network, when primary and standby are unable to communicate and transfer logs








Sql&gt; ALTER DATABASE Open

Consider the master switch modifying standby at the same time, executing on the standby





Sql&gt;alter system set log_archive_dest_2= ' Service=syw


LGWR SYNC Affirm


Valid_for= (Online_logfiles,primary_role)


Db_unique_name=syw '





Note: Maximize can be followed by {PROTECTION | Availability | Performance}, which corresponds to maximum protection, maximum availability, and maximum performance, respectively.

View the main library again, Standby library protection mode


Sql&gt; select Protection_mode,protection_level from V$database;





Protection_mode Protection_level


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


MAXIMUM Availability MAXIMUM Availability





3.2.2 Test Highest Available status


When the database is in the highest availability mode, if standby is inaccessible, primary should automatically switch to the mostWhen the database is in maximum availability mode, Primary should be automatically switched to maximum if Standby is not available
high
Re-query the protection level of the main library:
SQL> select protection_mode,protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
--------------------               --------------------
MAXIMUM the AVAILABILITY RESYNCHRONIZATION
The protection level has been automatically changed to the state to be synchronized.

The warning log has the following information

Thread 1 advanced to log sequence 143


Current log# 2 seq# 143 mem# 0:/u01/app/oracle/oradata/syw/redo02.log


Sun Aug 28 11:17:06 2011


ARC3:LGWR is actively archiving destination log_archive_dest_2


Arc3:standby Redo logfile selected for thread 1 sequence to destination


Sun Aug 28 11:20:57 2011








The system has changed.


ORA-16198:LGWR received timedout error from KSR


Lgwr:attempting Destination log_archive_dest_2 Network Reconnect (16198)


Lgwr:destination log_archive_dest_2 Network Reconnect abandoned


Sun Aug 28 11:20:57 2011


Errors in FILE/U01/APP/ORACLE/ADMIN/SYW/BDUMP/SYW_LGWR_30471.TRC:


ORA-16198: Timeout on internal channel during remote archive


Lgwr:network asynch I/O wait error 16198 log 2 service ' syw01 '


Current log# 2 seq# 143 mem# 0:/u01/app/oracle/oradata/syw/redo02.log


Lgwr:failed to archive log 2 thread 1 sequence 143 (16198)


Sun Aug 28 11:21:00 2011


Lgwr:closing Remote Archive Destination log_archive_dest_2: ' syw01 ' (Error 16198

Perform an update insert operation in the main library





Sql&gt; INSERT into T values (3);


1 lines have been created.





Sql&gt; commit;


Submit completed.





Perform log switching


sql&gt; alter system switch logfile;








View the primary library protection level again


Sql&gt; select Protection_mode,protection_level from V$database;





Protection_mode Protection_level


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


MAXIMUM Availability resynchronization

At this point primary is still the log to sync state, now connect the network cable, so that the main library and standby normal communication


The standby warning log appears with the following information





Sun Aug 28 11:29:10 2011


Media Recovery log/sywdg/arch1/1_143_758642906.dbf


Media Recovery log/sywdg/arch1/1_144_758642906.dbf


Media Recovery log/sywdg/arch1/1_145_758642906.dbf


Media Recovery log/sywdg/arch1/1_146_758642906.dbf


Media Recovery waiting for thread 1 sequence 147 (in transit)


Sun Aug 28 11:29:35 2011


Primary database is in MAXIMUM availability mode


Changing standby controlfile to MAXIMUM availability level


RFS[24]: Successfully opened standby log 4:/u01/app/oracle/oradata/stdby_redo04.log '

The main library has been changed to the maximum available mode, while executing on the standby


Ability MAXIMUM Availabilit





sql&gt; ALTER DATABASE recover managed standby database cancel;





The database has changed.





sql&gt; ALTER DATABASE open;





The database has changed.





Sql&gt; select * from T;





A


----------


1


3








Data that was insert on the main library has been synchronized to the repository, viewing the primary and standby protection levels again





Main Library


Sql&gt; select Protection_mode,protection_level from V$database;





Protection_mode Protection_level


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


MAXIMUM Avai


L





Standby Library





Sql&gt; select Protection_mode,protection_level from V$database;





Protection_mode Protection_level


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


MAXIMUM Availability MAXIMUM Availabilit





3.2.4 the database from read-only mode to the mode in which the redo log applies:








1. Terminates all active user sessions on the standby database.


Sql&gt; STARTUP FORCE;





2. Restart the redo application, begin to redo the application


sql&gt; ALTER database RECOVER MANAGED STANDBY database DISCONNECT from session;





3. To enable real-time applications, including the use of the current LOGFILE clause:





Thread 1 opened at log sequence


sql&gt; ALTER database RECOVER MANAGED STANDBY database USING current LOGFILE DISCONNECT from session;





You do not need to close the database instance to boot to these apply Mode.

Starting order of the primary repository in 3.2.5 data guard

In DG, the starting order problem of the primary Reserve library, with different modes for data guard, the starting order of the primary Reserve Library is as follows:

Max Performance (maximum performance): Main Library, the start and shutdown sequence of the standby is not successively

Max Availability (maximum available): To start a standby, and then start the main library, if the starting order is reversed, the main library can still start, but the main library in the Alert.log file in the following error prompts:

Tue 23 09:36:26 2011 ALTER DATABASE Open


Tue 23 09:36:26 2011


Lgwr:primary database is in CLUSTER consistent mode


Lgwr:primary database is in MAXIMUM availability mode


Lgwr:destination log_archive_dest_1 is isn't serviced by LGWR LNS0 started with pid=12


Tue 23 09:36:29 2011


Lgwr:error 1034 Verifying Archivelog destination log_archive_dest_2


Lgwr:continuing ... Tue 23 09:36:29 2011


Errors in FILE/OPT/ORACLE/ADMIN/DEVDB/BDUMP/TEST_LGWR_30979.TRC:


Ora-01034:oracle Not available


Lgwr:error 1034 disconnecting from Destination log_archive_dest_2 standby host ' test_stb_186 '


Thread 1 advanced to log sequence 73


73
Completed: alter database open
Max protection (max protection): start the standby database first, then start the main database, if the order is reversed, the main database instance will be automatically interrupted, and the database cannot be started
It will leave the following information in the alert.log file:

Tue Jan 23 09:34:00 2011
alter database open Tue Jan 23 09:34:00 2011
LGWR: Primary database is in CLUSTER CONSISTENT mode
LGWR: Primary database is in MAXIMUM PROTECTION mode
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR LNS0 started with pid = 12
Tue Jan 23 09:34:03 2011
LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2
LGWR: Continuing ...
Tue Jan 23 09:34:03 2011
Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30812.trc:
Step: The first is the primary operation. Modify the log_archive_dest_state_n parameter of the primary database and temporarily cancel sending logs to the standby database.
For example: SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = DEFER; When the Standby side is not accessible, Pr
ORA-01034: ORACLE not available
LGWR: Error 1034 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'test_stb_186'
LGWR: Minimum of 1 applicable standby database required
Tue Jan 23 09:34:07 2011
Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30812.trc:
ORA-16072: a minimum of one standby database destination is required
LGWR: terminating instance due to error 16072
Instance terminated by LGWR, pid = 30812 3.2.6 Stop Standby database correctly

In some cases, if the operation is improper, closing the Standby database may even cause the Primary database to be closed.

Under normal circumstances, before stopping the Standby database (including physical Standby and logical Standby), you should first stop the Primary database. If you stop the Standby database directly, then the Alert file of the Primary database records a bunch of error messages that the archive fails to send. Shut down directly. However, for some test environments, it is occasionally desirable to stop Standby for some other operations when the Primary database is running normally. In this case, it is generally recommended to use the following
No error will be reported in the Alert log file of the imary database.
Then the Standby side can stop the REDO application:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CALCEL;
 The last is to close the Standby database
SQL> SHUTDOWN IMMEDIATE;