dataguard,取消应用日志，关闭备库，启动次序，日常维护，切换
...........
http://zhaolinjnu.blog.sohu.com/30862949.html
data guard中主备库的启动顺序
今天有网友在itpub上讨论data guard中主备库的启动顺序问题,针对data guard采用不同的模式,主备库的启动顺序如下:
max performance(最大性能):主库,备库的启动和关闭顺序没有先后
max availability(最大可用):要先启动备库,再启动主库,如果启动顺序相反,主库仍然能启动,但会在主库的alert.log文件中出现如下出错提示:
Tue Jan 23 09:36:26 2007
alter database open
Tue Jan 23 09:36:26 2007
LGWR: Primary database is in CLUSTER CONSISTENT mode
LGWR: Primary database is in MAXIMUM AVAILABILITY mode
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
LNS0 started with pid=12
Tue Jan 23 09:36:29 2007
LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2
LGWR: Continuing...
Tue Jan 23 09:36:29 2007
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
Thread 1 opened at log sequence 73
Current log# 3 seq# 73 mem# 0: /forum_dbf/redo03.log
Successful open of redo thread 1
Tue Jan 23 09:36:33 2007
ARC0: Evaluating archive log 1 thread 1 sequence 72
ARC0: Beginning to archive log 1 thread 1 sequence 72
Creating archive destination LOG_ARCHIVE_DEST_1: '/archive_log/archive/1_72.arc'
Tue Jan 23 09:36:33 2007
ARC1: Evaluating archive log 1 thread 1 sequence 72
ARC1: Unable to archive log 1 thread 1 sequence 72
Log actively being archived by another process
Tue Jan 23 09:36:33 2007
SMON: enabling cache recovery
Tue Jan 23 09:36:33 2007
ARC0: Completed archiving log 1 thread 1 sequence 72
Tue Jan 23 09:36:33 2007
Successfully onlined Undo Tablespace 1.
Tue Jan 23 09:36:33 2007
SMON: enabling tx recovery
Tue Jan 23 09:36:33 2007
Database Characterset is US7ASCII
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open
max protection(最大保护):先启动备库,再启动主库,如果顺序相反,主库实例会自动中断,数据库无法启动,并会在alert.log文件中留下如下的信息:
Tue Jan 23 09:34:00 2007
alter database open
Tue Jan 23 09:34:00 2007
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 2007
LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2
LGWR: Continuing...
Tue Jan 23 09:34:03 2007
Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30812.trc:
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 2007
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
###################
http://www.itpub.net/thread-1382270-1-1.html
不取消日志应用，直接关闭dg物理备库，会不会有问题？
即直接执行：
SHUTDOWN IMMEDIATE;
而不执行：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
--------
只要 不是最大保护状态，
|
你直接关掉唯一的物理备库，是没有问题的。主库会报一些日志无法应用还是传输的错误。对主库没有影响。
|
| 最好不要这样~而且还应该在备库停止日志应用之前先让主库停止日志发送，这样更好 |
这要看你主库的参数配置了,如果主库设置了最少归档成功数,备库关闭后,会导致主库出问题.
另外,备库关闭了,主库在向备库归档时,发现备库关闭,会报错的.
#####################
http://space.itpub.net/12087396/viewspace-625818
1。然后给主库关闭数据库（不行把，呵呵，都进不去了怎么执行SHUTDOWN。。命令啊。没办法直接重起机器，打上了补丁，STARTUP数据库）还好比较顺利/
2。物理DG跟主库是一样的配置，所以跟主库一样进行处理，但是并没有那么顺利，机器起动不起来了，查找了许久（大概1。2小时），才发现是盘挂载不上去了。然后进行了一些修复，谢天谢地，终于顺利启动起来了。然后也打上了补丁，启动了备库，查看了ALTER日志发现MRP进程在恢复几个归档。以为就没事了。
3。第二天上班检查发现备库接收不到主库传送的归档，那个急啊，马上开始找原因了，A：查看网络（主备库互相都可以TNSPING通 log_archive_config='dg_config=(AAA,BBB)'的AAA,BBB），B：密码文件又没去动过它，应该不是这里的问题。C：开始查看参数文件，仔细的核对该有的参数都有了，也没去动过它。问题也不应该不在这啊，反反复复GOOGLE来GOOGLE去，也没搞出结果，最后看到有人说主库重起一下就好了（这个是正解），可是不敢确定啊，而且生产库岂是你随便可以起的。最后还是寻求了一些帮助进行确认，然后跟主管进行请示（夜里重起DB），终于在夜里得到了验证。心理松了好大一口气，可以睡个好觉拉/
4。我觉的应该是主库在往备库传归档的时候在一定时间或者是一定数据后如果传不过去，那主库将停止往备库传归档（因为我后来发现我手工切换主库日期，归档没传到备库，但是主库也ALTER日志也没报任何错误，备库更是没信息，可见主库已经“抛弃”备库了），而我主库当时起来的时候，备库还是挂起的状态，主库尝试往备库发归档，始终不成功。之后主库就开始“抛弃”备库了。初步我就这么解释这个原因了/
5 好了改睡觉拉/困/
#########################
http://www.eygle.com/archives/2009/11/dataguard_restart_lns.html
Oracle Dataguard备库失败与主库响应测试
在客户环境中，使用了Oracle 10.2.0.4 DataGuard技术，通过最大可用性模式进行数据保护。
以下简单测试，当备库关闭后，再重启备库，主库及备库的响应过程。
在备库执行如下步骤：
SQL> shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1610612736 bytes
Fixed Size 2084400 bytes
Variable Size 385876432 bytes
Database Buffers 1207959552 bytes
Redo Buffers 14692352 bytes
Database mounted.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Database altered.
SQL> exit
当备库关闭后，主库立即检测到备库的失败：
Tue Nov 17 20:34:58 2009
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
PING[ARC1]: Error 3113 when pinging standby STANDBY.
Tue Nov 17 20:35:17 2009
LGWR: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
LGWR: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
Tue Nov 17 20:35:17 2009
Errors in file /opt/oracle/admin/oradbt/bdump/oradbt_lgwr_319632.trc:
ORA-03113: end-of-file on communication channel
LGWR: Network asynch I/O wait error 3113 log 1 service 'STANDBY'
Tue Nov 17 20:35:17 2009
Destination LOG_ARCHIVE_DEST_2 is UNSYNCHRONIZED
LGWR: Failed to archive log 1 thread 1 sequence 3466 (3113)
Tue Nov 17 20:35:18 2009
LGWR: Closing remote archive destination LOG_ARCHIVE_DEST_2: 'STANDBY' (error 3113)
(oradbt)
Tue Nov 17 20:35:18 2009
Errors in file /opt/oracle/admin/oradbt/bdump/oradbt_lgwr_319632.trc:
ORA-01041: internal error. hostdef extension doesn't exist
LGWR: Error 1041 closing archivelog file 'STANDBY'
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'STANDBY'
当备库重启后：
Tue Nov 17 20:35:23 2009
Thread 1 advanced to log sequence 3467 (LGWR switch)
Current log# 2 seq# 3467 mem# 0: /redodata/oradbt/redo02.log
Tue Nov 17 20:38:34 2009
Thread 1 advanced to log sequence 3468 (LGWR switch)
Current log# 3 seq# 3468 mem# 0: /redodata/oradbt/redo03.log
Tue Nov 17 20:39:59 2009
Thread 1 cannot allocate new log, sequence 3469
Checkpoint not complete
Current log# 3 seq# 3468 mem# 0: /redodata/oradbt/redo03.log
LNSb started with pid=19, OS id=573716
Tue Nov 17 20:40:05 2009
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
LGWR: Standby redo logfile selected to archive thread 1 sequence 3469
LGWR: Standby redo logfile selected for thread 1 sequence 3469 for destination LOG_ARCHIVE_DEST_2
Tue Nov 17 20:40:05 2009
Thread 1 advanced to log sequence 3469 (LGWR switch)
Current log# 1 seq# 3469 mem# 0: /redodata/oradbt/redo01.log
Tue Nov 17 20:40:05 2009
ARC0: LGWR is actively archiving destination LOG_ARCHIVE_DEST_2
ARC0: Standby redo logfile selected for thread 1 sequence 3468 for destination LOG_ARCHIVE_DEST_2
此时备库也恢复了同步：
Tue Nov 17 20:35:30 2009
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
Tue Nov 17 20:35:30 2009
Attempt to start background Managed Standby Recovery process (oradbt)
MRP0 started with pid=19, OS id=254276
Tue Nov 17 20:35:30 2009
MRP0: Background Managed Standby Recovery process started (oradbt)
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 11 processes
Tue Nov 17 20:35:35 2009
Waiting for all non-current ORLs to be archived...
Media Recovery Waiting for thread 1 sequence 3466
Tue Nov 17 20:35:36 2009
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 172068
RFS[1]: Identified database type as 'physical standby'
Tue Nov 17 20:39:58 2009
RFS LogMiner: Client disabled from further notification
RFS[1]: Archived Log: '/oradata/archive/1_3466_690213276.dbf'
RFS[1]: Archived Log: '/oradata/archive/1_3467_690213276.dbf'
Tue Nov 17 20:40:00 2009
Media Recovery Log /oradata/archive/1_3466_690213276.dbf
Media Recovery Log /oradata/archive/1_3467_690213276.dbf
Media Recovery Waiting for thread 1 sequence 3468
Tue Nov 17 20:40:05 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 1441960
RFS[2]: Identified database type as 'physical standby'
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to RESYNCHRONIZATION level
Primary database is in MAXIMUM AVAILABILITY mode
Changing standby controlfile to MAXIMUM AVAILABILITY level
RFS[2]: Successfully opened standby log 4: '/redodata/oradbt/stdrd1.log'
Tue Nov 17 20:40:05 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[3]: Assigned to RFS process 1442140
RFS[3]: Identified database type as 'physical standby'
RFS[3]: Successfully opened standby log 5: '/redodata/oradbt/stdrd2.log'
Tue Nov 17 20:40:06 2009
Media Recovery Log /oradata/archive/1_3468_690213276.dbf
Media Recovery Waiting for thread 1 sequence 3469 (in transit)
检查主库的LGWR日志，可以看到整个过程的后台处理：
*** 2009-11-17 20:35:23.248 64165 kcrr.c
LGWR: Error 1041 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'STANDBY'
Ignoring krslcmp() detach error 1041
kcrrtsync: Standby mount ID 0xc896b692 not found
*** 2009-11-17 20:35:23.249 2342 krsl.c
No standby database destinations have been configured
as being archived by the LGWR process
This instance will operate at a reduced protection mode until
network connectivity to the standby databases is restored and
all archivelog gaps have been resolved.
*** 2009-11-17 20:38:34.160
kcrrtsync: Standby mount ID 0xc896b692 not found
*** 2009-11-17 20:38:34.160 2342 krsl.c
No standby database destinations have been configured
as being archived by the LGWR process
This instance will operate at a reduced protection mode until
network connectivity to the standby databases is restored and
all archivelog gaps have been resolved.
*** 2009-11-17 20:40:02.286
kcrrtsync: Standby mount ID 0xc896b692 not found
Oracle通过数据库的Mount ID来查找目标实例，备库关闭Mount ID不存在，则错误出现。
重新初始化加你LNS进程的过程如下：
*** 2009-11-17 20:40:02.286 56939 kcrr.c
Initializing NetServer[LNSb] for dest=STANDBY mode SYNC
LNSb is not running anymore.
New SYNC LNSb needs to be started
Waiting for subscriber count on LGWR-LNSb channel to go to zero
Subscriber count went to zero - time now is <11/17/2009 20:40:02>
Starting LNSb ...
Waiting for LNSb to initialize itself
*** 2009-11-17 20:40:05.330 57230 kcrr.c
Netserver LNSb [pid 573716] for mode SYNC has been initialized
Performing a channel reset to ignore previous responses
Successfully started LNSb [pid 573716] for dest STANDBY mode SYNC ocis=0x1104db358
*** 2009-11-17 20:40:05.330 57733 kcrr.c
Making upiahm request to LNSb [pid 573716]: Begin Time is <11/17/2009 20:40:02>. NET_TIMEOUT = <180> seconds
Waiting for LNSb to respond to upiahm
*** 2009-11-17 20:40:05.413 57897 kcrr.c
upiahm connect done status is 0
Receiving message from LNSb
Receiving message from LNSb
Receiving message from LNSb
*** 2009-11-17 20:40:05.609 59112 kcrr.c
Making upinbls request to LNSb (ocis 0x1104db358). Begin time is <11/17/2009 20:40:02> and NET_TIMEOUT is <180> seconds
NetServer pid:573716
清晰的了解这个过程是很有意思的，记录一下。
-The End-
###############################
http://www.itpub.net/thread-1459850-1-1.html
另外问下 到底是哪个为准？
网络上有人这样确定启动关闭主从次序
第一种日常维护先后次序
1、正确打开主库和备库
主库:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
备库:
SQL> STARTUP MOUNT;
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT FROM SESSION;
2、正确关闭顺序
备库:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL>SHUTDOWN IMMEDIATE;
主库
SQL>SHUTDOWN IMMEDIATE;
第二种日常维护先后次序
但是有一些文档说的启动应该是
先备库 后从库
关闭先主库 后备库。
现在头疼 以哪一个为准？
=======
其实你只要搞清原理无所谓哪个先后的~
DG很强大的
我一般都是先停掉主库archive 发送
然后备库停止应用然后再关闭备库
启动的时候先启动备库在启动主库~
主要是减少无谓的报错和对DG工作原理的熟悉很重要
######################################
http://space.itpub.net/23071790/viewspace-688383
DataGuard物理standby管理 - 主备切换
switchover一般用于数据库或硬件升级，这时只需要较短时间中断数据库访问，主备库的角色切换完成后，即可打开primary角色的备库来提供数据库访问。
failover，主库已经无法使用，必须切换到备库，当备库failover切换为primary，则主库不再是dataguard的一部分，无法再转换为备库。
如果是RAC的物理standby，则在执行切换时只能启动一个instance，切换完毕后再启动其他实例。
Switchover
一定要按照先主库，后备库的顺序执行切换命令，否则会报错，如果强行切换就变成failover了。
主库端：
由于主库是处于open状态，有访问的，所以v$database视图中，switchover_status为sessions active。而由primary切换到standby需要数据库为open状态，因此，执行切换命令时，带上with session shutdown选项即可。
执行完切换命令后，关闭数据库，重新启动数据库到mount状态等待日志传输，开启日志应用。
查看alert.log可以看到主库做了哪些动作：主库断开所有session（未提交事务会回滚），切换日志并归档，传输日志到备库，给备库一个End-Of-REDO的信号，切换为standby，重新启动到mount。
SYS@dev01> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STAT
--------------- ---------------
PRIMARY SESSIONS ACTIVE
SYS@dev01>alter database commit to switchover to physical standby with session shutdown;
Database altered.
SYS@dev01> shutdown immediate;
ORA-01507: database not mounted
ORACLE instance shut down.
SYS@dev01> startup mount;
ORACLE instance started.
Total System Global Area 536870912 bytes
Fixed Size 2085288 bytes
Variable Size 209718872 bytes
Database Buffers 318767104 bytes
Redo Buffers 6299648 bytes
Database mounted.
SYS@dev01>alter database recover managed standby database using current logfile disconnect from session;
Database altered.
SYS@dev01> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYSESSIONS ACTIVE
SYS@dev01>
备库端：
确认是否可以切换为主库，如果switchover_status为recovery needed或switchover latent，需要apply完所有归档日志才能切换。如果是sessions active则带上with session shutdown选项。apply完所有日志后，即可切换为primary，然后打开数据库。
查看alert.log可以看到备库做了哪些动作：接收主库日志，接收到主库End-Of-REDO的信号，apply完所有日志，清空online redo log以便打开数据库，切换为primary，打开数据库。
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYSWITCHOVER LATENT
SYS@dev01dg> alter database commit to switchover to primary with session shutdown;
alter database commit to switchover to primary with session shutdown
*
ERROR at line 1:
ORA-16139: media recovery required
SYS@dev01dg>alter database recover managed standby database disconnect from session;
Database altered.
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYTO PRIMARY
SYS@dev01dg>alter database commit to switchover to primary with session shutdown;
Database altered.
SYS@dev01dg>alter database open;
Database altered.
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PRIMARY SESSIONS ACTIVE
SYS@dev01dg>
以上过过程中，由于主库断开所有session并归档，传输日志到备库，发给备库End-Of-REDO的信号，因此正常switchover时，是不会丢失数据的。
切换完成后可以在主库归档，验证一下是否切换成功，备库是否能正常接收日志。
Failover
当主库当掉，无法使用时，此时的切换即为failover，如果保护模式为最大性能模式，是可能丢失数据的。
备库端：
如果是最大保护和最大可用性模式，则可以直接在备库端执行failover切换。如果是最大性能模式，为了尽可能减少数据丢失，需要检查主库是否有日志没有传输到备库，手动传输备库进行注册和恢复。注意RAC环境下，归档日志是分线程的。
SYS@dev01dg>select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;
THREAD# A
---------- ----------
1 457
SYS@dev01dg>
[oracle@testdb dev01]$ scp * oracle@192.168.0.8:/u01/archive/dev01dg
注册归档日志有如下两种方法，较为简单当然是用rman了，一次注册多个。
RMAN>catalog start with '/u01/archive/dev01';
SYS@dev01dg>alter database register logfile '/u01/archive/dev01dg/arch_e8fe6364_1_712757927_460.dbf';
apply归档日志也有两种方法。
SYS@dev01dg>alter database recover managed standby database disconnect from session;
Database altered.
SYS@dev01dg>
SYS@dev01dg>recover standby database;
ORA-00279: change 2863819 generated at 03/20/2010 21:58:17 needed for thread 1
ORA-00289: suggestion : /u01/archive/dev01dg/arch_e8fe6364_1_712757927_461.dbf
ORA-00280: change 2863819 for thread 1 is in sequence #461
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
Media recovery cancelled.
SYS@dev01dg>
当手动apply完所有日志后，就可以failover切换到primary了。但是要注意的时，由于备库没有收到主库End-Of-REDO的信号，所以直接转换会报错，要求介质恢复。此时需要提交命令告诉备库，日志恢复已经finish了，需要进行failover切换。注意switchover时千万不要带有finish选项，否则就会变成failover了。
SYS@dev01dg> alter database commit to switchover to primary with session shutdown;
alter database commit to switchover to primary with session shutdown
*
ERROR at line 1:
ORA-16139: media recovery required
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYNOT ALLOWED
SYS@dev01dg>alter database recover managed standby databasefinish[force];
Database altered.
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PHYSICAL STANDBYTO PRIMARY
SYS@dev01dg>alter database commit to switchover to primary with session shutdown;
Database altered.
SYS@dev01dg>alter database open;
Database altered.
SYS@dev01dg> select database_role,switchover_status from v$database;
DATABASE_ROLE SWITCHOVER_STATUS
---------------- --------------------
PRIMARY SESSIONS ACTIVE
SYS@dev01dg>
failover完成后，数据库其实是以resetlogs方式打开的，如果log_archive_format='arch_%d_%t_%r_%s.dbf'，可以看到归档日志的文件名会有新的resetlogs ID和sequence number，以此与原有的归档日志进行区分。
==================
http://blog.csdn.net/dream19881003/article/details/5514401
启动到管理模式
shutdown immediate
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;
启动到只读的模式
shutdown immediate
startup nomount
alter database mount standby database;
alter database database open read only;
如果在管理恢复的模式下到只读模式
recover managed standby database cancel;
alter database open read only;
这个时候可以给数据库增加临时数据库文件(这时候热备份是没有备份过来的)
在只读模式下到管理恢复方式
recover managed standby database disconnect from session;
主库和备库的切换
switchover时只能先从primary切换到standby，再从standby到primary
最简单的办法是把两个数据库的文件互换，
primary到standby
sqlplus /nolog < connect / as sysdba
alter database commit switchover to physical standby with session shutdown;
shutdown immediate;
create spfile from '/../product/10.1.0/db_1/dbs/inittbdbsdby.ora';
startup nomount;
alter database mount standby disconnect;
exit
eof
lsnrctl stop
lsnrctl start listenerdb
修改主机的tnsnames.ora 将主机的ip与备机的ip兑换
standby到primary
more switchprimary.sh
sqlplus /nolog < connect / as sysdba
shutdown immediate
create spfile from '/../product/10.1.0/db_1/dbs/inittdbdprim.ora';
startup
exit
eof
lsnrctl stop listenerdb
lsnrctl start
修改备库的tnsname.ora 主备库的ip互换
这样切换的要求是主备机各有两个listener，listener监听的是1521，listenerdb监听的是1522
任何一个节点，在primary期间启动listener，standby期间启动listenerdb
连接data guard的客户端的tnsname配置，这样可以实现失败对换，对客户端是透明的：
BOSS =
(DESCRIPTION =
(failover = on )
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 主)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 备)(PORT = 1521))
)
(CONNECT_DATA =
(SID = BOSS)
)
备库的失败切换
1，失败的切换
一般是主服务器已经不能使用，必须切换到备用的服务器，所以只操作备用服务器这一端，提供一切换脚本
more switchprimary.sh
cd $HOME
.bash_profile
sqlplus /nolog < connect / as sysdba
recover managed standby database cancel;
--if standby hava standby redo logfile;
--alter database recover managed standby database finish;
--else
alter database recover managed standby database finish skip standby logfile;
--switch
alter database recover managed standby database finish skip standby logfile;
--open
shutdown immediate
create spfile from '/../product/10.1.0/db_1/dbs/inittbdbprim.ora';
startup
exit
eof
lsnrctl stop linstenerdb
lsnrctl start
最后将tnsname.ora将住备库的ip对换
如果在备用端有活动的为归档的日志，或者有从主数据库拷贝过来的联机日志，可以采用如下的办法注册并恢复
alter database register logfile '/../oradata/tbdb/archive/1_87.dbf';
recover standby database;
如果有活动日志必须用
alter database recover managed standby database finish;
否则用
alter database recover managed standby database finish skip standby logfile;
这样切换的备用服务器可以避免最小的数据丢失和不用retlogs，特别是对于用多个备用服务器的时候，该服务器可以马上作为主服务器而不用重新创建备用的服务器。
强行切换(激活)
这种切换是以激活备用服务器来完成的，在重新启动数据库的时候，备用激活resetlogs，这样会影响到其他的备用服务器而且必须重新再主服务器上重新构造备用服务器，一般不建议这样做
$more activeprimary.sh
#!/bin/bash
#switch to primary with cancel;
cd $HOME
. .bash_profile
#cancel and startup database;
sqlplus /notog < connect / as sysdba
alter system arcive log current;
recover managed standby database cancel;
alter database activete standby database;
shutdown immediate;
create spfile from '/../product/10.1.0/db_1/dbs/inittbdbprim.ora';
startup
exit
eof
lsnrctl stop listenerdb
lsnrctl start
备用库的备份与恢复
1,从备用库上恢复主库的数据文件
在某些情况下，主服务器可能会损坏一到两个数据文件，如果是从主库的备份设备恢复，理论是可以的，但是可能会因为需要太多的日志，实际耗时太大，这个时候，我们可以考虑从备份的服务器上恢复该数据，因为备份的服务器和主数据库一般只是相差一个日志文件左右。
1》关闭备用的数据库
recover managed standby database cancel;
shutdown immediate;
2》拷贝或ftp损坏的数据文件到主数据库
3》在主数据库recover database datafile ‘文件名'即可
2，在备用数据库上进行备份
如果想减轻主库的压力，可以在备用数据库上进行备份，因为备用数据库的特性关系，在对standby的rman备份中，不能修改rman的配置，所以没有办法自动备份控制文件。
可以采取一下方法进行备份
1》备份备用数据库，可以停止恢复进程，跳转到read only的模式下，通过backup database，来备份数据库，这样的数据库处于一致的模式下
2》采用恢复目录备份standby数据库
rman target sys@dbstandby
backup database format '/../oradata/rman_backup/full_%d_%T_s%s_p%p';
backup archivelog all delete input format '/../oradate/rman_backup/ctl_%d_%T_s%s_p%p';
如果采用控制文件做恢复的目录，注意
alter database backup controlfile to '/../ordata/rman_backup/ctl_%d_%T_s%s_p%p';
#############################################
http://space.itpub.net/658698/viewspace-622212
第一部分 日常维护
一 正确打开主库和备库
1 主库:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
2 备库:
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
二 正确关闭顺序
1 备库:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL>SHUTDOWN IMMEDIATE;
2 主库
SQL>SHUTDOWN IMMEDIATE;
三 备库Read-Only模式打开
当前主库正常OPEN状态
备库处于日志传送状态.
1 在备库停止日志传送
SQL> recover managed standby database cancel;
2 备库Read-only模式打开
SQL> alter database open read only;
3 备库回到日志传送模式
SQL> recover managed standby database disconnect from session;
Media recovery complete.
SQL> select status from v$instance;
STATUS
------------
MOUNTED
四 日志传送状态监控
1 主库察看当前日志状况
SQL> select sequence#,status from v$log;
SEQUENCE# STATUS
---------- ----------------
51 ACTIVE
52 CURRENT
50 INACTIVE
2 备库察看RFS(Remote File Service)接收日志情况和MRP应用日志同步主库情况
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
可以看到备库MPR0正等待SEQUENCE#为52的redo.
3 察看备库是否和主库同步
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
可以看到备库已经将SEQUENCE#51的日志归档,已经将SEQUENCE#50的redo应用到备库.
由于已经将SEQUENCE#51的日志归档,所以SEQUENCE#51以前的数据不会丢失.
4 察看备库已经归档的redo
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 察看备库已经应用的redo
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
可以看到备库已经将SEQUENCE#为51的归档文件应用到备库.
6 察看备库接收,应用redo数据过程.
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
可以看到RFS接收到sequence#为51的归档文件并存至备库归档目录/arch/1_51_552308270.arc.
Oracle自动应用文件/arch/1_51_552308270.arc进行备库与主库同步
Oracle继续等待主库sequence 52的归档文件
五 备库归档目录维护
1 找到备库归档目录
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 维护策略
每周2,4,7删除已经应用的归档文件
具体参见附录二
第二部分 主库正常切换
一 人工干预主库正常切换
1 在主库端检验数据库可切换状态
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
1 row selected
SWITCHOVER_STATUS:TO STANDBY表示可以正常切换.
如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE,表示当前有会话处于ACTIVE状态
2 开始主库正常切换
如果SWITCHOVER_STATUS的值为TO STANDBY 则:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE 则:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
成功运行这个命令后，主库被修改为备库
3 重启先前的主库
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
4 在备库验证可切换状态
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected
5 将目标备库转换为主库
如果SWITCHOVER_STATUS的值为TO STANDBY 则:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE 则:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
成功运行这个命令后，备库被修改为主库
6 重启目标备库
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
7 先前主库启动日志传送进程
SQL> alter database recover managed standby database disconnect;
总结: 这样主库的一次正常切换完成.切换后的状态,原先的主库变为备库,原先的备库变为主库.
二 通过运行脚本实现主库正常切换
1 主库切换为备库
在主库上运行脚本
/admin/dataGuard/switchover/primary_to_standby.sh
2 备库切换为主库
在备库上运行脚本
/admin/dataGuard/switchover/standby_to_primary.sh
脚本1成功运行后,再运行脚本2,不能同时运行两个脚本.
经过这次切换后原来的主库变为备库,原先的备库变为主数据并且OPEN对应用提供服务.
3 复原最初状态
在原备库上运行脚本
/admin/dataGuard/switchover/primary_to_standby.sh
成功完成后
在原主库上运行脚本
/admin/dataGuard/switchover/standby_to_primary.sh
第三部分 主库灾难切换
一 人工干预主库灾难切换
二 通过运行脚本实现主库灾难切换
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 session shutdown;
-- open
SQL>shutdown immediate
SQL>startup
附:
一 有选择察看redo传送与应用情况
select message from v$dataguard_status
where message_num>&message_num;
二 备库归档目录维护脚本
在crontab 中定制每日执行removeCommand.sh即可。
流程:每日11:50PM执行removeCommand.sh
假设今日2005-04-05 则删除04-04和04-03两日已应用归档日志.保留今日已应用归档日志
[oracle@db_gurid admin]$ crontab -l
50 23 * * * 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 off
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
#####################################################
http://www.qqread.com/oracle/2010/01/q488670.html
一、日志应用服务介绍
日志应用服务自动应用重做到备数据库，以维护与主数据库的同步并允许对数据库的事务一致性访问。
默认地，日志应用服务在应用归档重做日志文件到备数据库之前等待完全的归档重做日志文件到达备数据库。从主数据库传送的重做数据被备系统上的远程文件服务进程（RFS）接收，在那里RFS 进程写重做数据到归档重做日志文件或备重做日志文件。然而，如果你使用备重做日志文件，你能允许实时应用，这允许Data Guard从正在被RFS 进程写的当前备重做日志文件恢复重做数据。
日志应用服务使用下面的方法来维护物理和逻辑备数据库：
重做应用（只有物理备数据库）
使用介质恢复来保持主和物理备数据库同步。
注意：
你也能以只读模式打开物理备数据库，允许用户查询备数据库用作报表用途。当打开的时候，还是接收重做数据的；然而，重做应用停止并且物理备数据库没有与主数据库保持同步。如果在此时间发生故障，会延长故障转移操作完成所需的时间
SQL应用（只有逻辑备数据库）
从主数据库接收的重做重组SQL语句并在逻辑备数据库上执行SQL语句。
逻辑备数据库能以读/写模式打开，但是由逻辑备数据库维护的目标表只能以只读模式打开以用于报表用途（倘若数据库guard 适当设置）。SQL 应用允许你使用逻辑备数据库用于报表活动，即使当SQL 语句被应用时。
二、日志应用服务配置选项
使用实时应用来立即应用重做数据
如果允许了实时应用特性，日志应用服务能在接收重做数据时应用，而不用等待当前备重做日志文件归档。这导致更快的切换和故障转移时间，因为备重做日志文件在故障转移或切换开始的时候已经应用到备数据库。
使用 ALTER DATABASE 语句来允许实时应用特性，如下：
对于物理备数据库，执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 语句。
对于逻辑备数据库，执行ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE 语句。
注意：使用实时应用需要备重做日志文件。
图 1 显示了使用本地目的地和备目的地的Data Guard 配置。当远程文件服务（RFS）进程在备数据上写重做数据到备重做日志文件时，日志应用服务能从正在被写的备重做日志文件恢复重做。
图1 使用实时应用应用重做数据到备目的地
对归档重做日志文件的应用指定时间延迟
在一些情况下，你可能想在重做数据从主站点接收到它应用到备数据库的时间之间创建一个时间延迟。你能指定时间间隔（分钟）来保护损坏或错误的数据的应用到备数据库，当你设置DELAY 间隔，它不是延迟重做数据的传输到备数据库。替代地，你指定的时间延迟从重做数据完整地归档到备目的地开始。
注：如果你定义对一个允许实时应用的目的地的延迟，则该延迟被忽略。
指定时间延迟
你能使用 LOG_ARCHIVE_DEST_n 初始化参数的DELAY=minutes 属性，在主和备数据库上设置时间延迟来延迟应用归档重做日志文件到备数据库。默认地，没有时间延迟。如果你指定DELAY 而没有指定一个值，则默认的延迟间隔是30 分钟。
取消时间延迟
你能取消指定的延迟间隔，如下：
对于物理备数据库，使用 RECOVER MANAGED STANDBY DATABASE 字句的NODELAY 关键词：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY；
对于逻辑备数据库，指定下面的 SQL 语句：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY；
这些命令导致日志应用在时间间隔过期之前，立即开始应用归档重做日志文件到备数据库。
使用Flashback 数据库作为设置时间延迟的另一选择
作为设置应用延迟的另一选择，你能使用Flashback 数据库来从损坏或错误数据的应用中恢复到备数据库。Flashback 数据库能快速、简单地闪回备数据库到一个任意的时间点。
三、应用重做数据到物理备数据库
默认地，重做数据从归档重做日志文件应用。当执行重做应用时，物理备数据库能使用实时应用特性来从正在被RFS 进程写的备重做日志文件直接应用重做。注意当物理备数据库以只读模式打开时日志应用服务不能应用重做数据。
开始重做应用
要在物理备数据库上开始日志应用服务，确保物理备数据库是启动并安装的，然后使用SQL:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 语句来开始重做应用。
你能指定重做应用作为前台会话或后台进程运行，并允许它实时应用。
要在前台开始重做应用，执行下面的 SQL 语句：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE；
如果你开始一个前台会话，控制不会返回到命令提示符，直到恢复被其它会话取消了。?? 要在后台开始重做应用，在 SQL 语句中包括DISCONNECT 关键词。例如：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT；
这条语句开始了一个分离的服务进程并立即返回控制到用户。当管理恢复进程在后台执行恢复，执行RECOVER 语句的前台进程能继续执行其它任务。这不会断开当前的SQL 会话。
要开始实时应用，在 SQL 语句上包含USING CURRENT LOGFILE 字句。例如：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE；
停止重做应用
要停止重做应用，在其它窗口执行下面的 SQL 语句：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL；
四、应用重做数据到逻辑备数据库
SQL 应用从归档重做日志或备重做日志转换数据到SQL 语句，然后在逻辑备数据库上执行这些SQL 语句。因为逻辑备数据库保持打开，维护的表能同时用于其它任务，如报表、总结、和查询。
开始SQL 应用
要开始 SQL 应用，启动逻辑备数据库并执行下面语句：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
在逻辑备数据库上停止SQL应用
要停止SQL 应用，在逻辑备数据库上执行下面语句：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
当你执行该语句，SQL 应用等待直到它提交了所有在应该过程中完成的事务。这样，该命令可能不能立即停止SQL 应用进程。如果你想立即停止 SQL 应用，执行下面语句：
SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;
