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 && 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> 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>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> 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> ALTER DATABASE Open
Consider the master switch modifying standby at the same time, executing on the standby
Sql>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> 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> INSERT into T values (3);
1 lines have been created.
Sql> commit;
Submit completed.
Perform log switching
sql> alter system switch logfile;
View the primary library protection level again
Sql> 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> ALTER DATABASE recover managed standby database cancel;
The database has changed.
sql> ALTER DATABASE open;
The database has changed.
Sql> 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> select Protection_mode,protection_level from V$database;
Protection_mode Protection_level
-------------------- --------------------
MAXIMUM Avai
L
Standby Library
Sql> 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> STARTUP FORCE;
2. Restart the redo application, begin to redo the application
sql> 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> 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;