11g：Rolling Upgrade With Physical Standby

aaaaaaaa2000

版主，我在做11g的Rolling Upgrade With Physical Standby将物理库临时转换为逻辑库的时候，都快2个小时了，这个还是没有执行成功，不知道是啥原因？？



BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production


SQL> select database_role from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;[/code]
备库的日志一直停在这：
Tue May 15 22:46:33 2012
ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY
Media Recovery Start: Managed Standby Recovery (oral1)
Serial Media Recovery started
Managed Standby Recovery not using Real Time Apply
Media Recovery Log /home/oracle/archive_local/1_126_782775644.dbf
Media Recovery Log /home/oracle/archive_local/1_127_782775644.dbf
Media Recovery Log /home/oracle/archive_local/1_128_782775644.dbf
Tue May 15 22:46:44 2012
Media Recovery Log /home/oracle/archive_local/1_129_782775644.dbf
Media Recovery Log /home/oracle/archive_local/1_130_782775644.dbf
Media Recovery Waiting for thread 1 sequence 131 (in transit)
望刘总解答，多谢

Maclean Liu(刘相兵

你的 primary 执行过 EXECUTE DBMS_LOGSTDBY.BUILD;   吗？

aaaaaaaa2000

执行了的，要不再执行一遍？

saup007

执行EXECUTE DBMS_LOGSTDBY.BUILD这个，一定是standby已经cancel的时候。。。
其实再执行一次，也可以。

aaaaaaaa2000

错了错了，我主库执行 EXECUTE DBMS_LOGSTDBY.BUILD; 之后我主备库切换过，可能这样导致有问题了吧
刚才在主库上又重新执行了 EXECUTE DBMS_LOGSTDBY.BUILD; ，然后再改成逻辑库没有问题了，多谢刘总！！！！

aaaaaaaa2000

1. SQL> shut immediate
   
2. Database closed.
   
3. Database dismounted.
   
4. ORACLE instance shut down.
   
5. SQL> startup nomount
   
6. ORACLE instance started.
   
7. 
   
8. Total System Global Area  304807936 bytes
   
9. Fixed Size                  2212856 bytes
   
10. Variable Size             138415112 bytes
    
11. Database Buffers          159383552 bytes
    
12. Redo Buffers                4796416 bytes
    
13. SQL> alter database mount standby database;
    
14. 
    
15. Database altered.
    
16. 
    
17. SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;
    
18. 
    
19. Database altered.
    
20. 
    
21. SQL> select database_role from v$database;
    
22. 
    
23. DATABASE_ROLE
    
24. ----------------
    
25. PHYSICAL STANDBY
    
26. 
    
27. SQL>

复制代码

后台日志如下：

1. Completed: alter database mount standby database
   
2. ARC3: Archival started
   
3. ARC0: STARTING ARCH PROCESSES COMPLETE
   
4. Wed May 16 00:37:41 2012
   
5. Using STANDBY_ARCHIVE_DEST parameter default value as /home/oracle/archive_local
   
6. RFS[1]: Assigned to RFS process 3072
   
7. RFS[1]: Identified database type as 'physical standby': Client is ARCH pid 2481
   
8. Wed May 16 00:37:44 2012
   
9. RFS[2]: Assigned to RFS process 3074
   
10. RFS[2]: Identified database type as 'physical standby': Client is LGWR ASYNC pid 2485
    
11. Primary database is in MAXIMUM PERFORMANCE mode
    
12. RFS[2]: Opened log for thread 1 sequence 135 dbid 857913116 branch 782775644
    
13. Archived Log entry 68 added for thread 1 sequence 135 rlc 782775644 ID 0x33275ebc dest 2:
    
14. RFS[2]: Opened log for thread 1 sequence 136 dbid 857913116 branch 782775644
    
15. Wed May 16 00:38:44 2012
    
16. ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY
    
17. Media Recovery Start: Managed Standby Recovery (oral1)
    
18. Serial Media Recovery started
    
19. Managed Standby Recovery not using Real Time Apply
    
20. Media Recovery Not Required
    
21. Completed: ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY

复制代码

为啥执行完了之后还是物理库那？？

aaaaaaaa2000

求解答，多谢啊啊！！！

Maclean Liu(刘相兵

尝试以下 步骤:

我们还需要完成一系列逻辑备库的配置:

a.禁止在逻辑备库端删除外籍日志

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');
BEGIN DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE'); END;

ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'DBMS_LOGSTDBY.APPLY_SET' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

/* 缺少DBMS_LOGSTDBY包，可以从以下脚本创建 */

SQL> @?/rdbms/admin/dbmslsby.sql

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', 'FALSE');
PL/SQL procedure successfully completed.

b.执行以下语句可以将逻辑备库不支持的而又在主库上运行过的事务记录到DBA_LOGSTDBY_EVENTS中

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('MAX_EVENTS_RECORDED',DBMS_LOGSTDBY.MAX_EVENTS);
PL/SQL procedure successfully completed.

c.启动在逻辑备库上的SQL APPLY:

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

aaaaaaaa2000

刘总是这的：

1. SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY;
   
2. 
   
3. Database altered.
   
4. 
   
5. SQL> select database_role from v$database;
   
6. 
   
7. DATABASE_ROLE
   
8. ----------------
   
9. PHYSICAL STANDBY
   
10. 
    
11. SQL>

复制代码

现在这个库还是物理库，按道理来说应该变成逻辑库了才对啊，但是查询状态还是物理库

Maclean Liu(刘相兵

执行上面的 语句 报上面错吗？

aaaaaaaa2000

没有错，后台日志如下：

1. ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY
   
2. Media Recovery Start: Managed Standby Recovery (oral1)
   
3. Serial Media Recovery started
   
4. Managed Standby Recovery not using Real Time Apply
   
5. Media Recovery Not Required
   
6. Completed: ALTER DATABASE RECOVER TO LOGICAL STANDBY KEEP IDENTITY

复制代码

aaaaaaaa2000

刘大，又出新问题了，因为一直没有转换为逻辑库，所以就把redo应用打开了，结果报了ora-600的错误，能帮忙看一下吗？

1. alter database recover managed standby database  disconnect
   
2. Attempt to start background Managed Standby Recovery process (oral1)
   
3. Wed May 16 23:54:34 2012
   
4. MRP0 started with pid=28, OS id=15820
   
5. MRP0: Background Managed Standby Recovery process started (oral1)
   
6. Serial Media Recovery started
   
7. Managed Standby Recovery not using Real Time Apply
   
8. Waiting for all non-current ORLs to be archived...
   
9. All non-current ORLs have been archived.
   
10. Wed May 16 23:54:40 2012
    
11. Completed: alter database recover managed standby database  disconnect
    
12. Media Recovery Log /home/oracle/archive_local/1_133_782775644.dbf
    
13. Errors in file /home/oracle/app/diag/rdbms/standby/oral1/trace/oral1_mrp0_15820.trc  (incident=12225):
    
14. ORA-00600: internal error code, arguments: [krr_media_9], [974338], [974340], [4294967295], [], [], [], [], [], [], [], []
    
15. Incident details in: /home/oracle/app/diag/rdbms/standby/oral1/incident/incdir_12225/oral1_mrp0_15820_i12225.trc
    
16. Wed May 16 23:54:44 2012
    
17. Trace dumping is performing id=[cdmp_20120516235444]
    
18. Wed May 16 23:54:44 2012
    
19. MRP0: Background Media Recovery terminated with error 600
    
20. Errors in file /home/oracle/app/diag/rdbms/standby/oral1/trace/oral1_mrp0_15820.trc:
    
21. ORA-00600: internal error code, arguments: [krr_media_9], [974338], [974340], [4294967295], [], [], [], [], [], [], [], []
    
22. Recovery interrupted!
    
23. Errors in file /home/oracle/app/diag/rdbms/standby/oral1/trace/oral1_mrp0_15820.trc:
    
24. ORA-00600: internal error code, arguments: [krr_media_9], [974338], [974340], [4294967295], [], [], [], [], [], [], [], []
    
25. Errors in file /home/oracle/app/diag/rdbms/standby/oral1/trace/oral1_mrp0_15820.trc:
    
26. ORA-00600: internal error code, arguments: [krr_media_9], [974338], [974340], [4294967295], [], [], [], [], [], [], [], []
    
27. Wed May 16 23:54:47 2012
    
28. Sweep [inc][12225]: completed
    
29. Sweep [inc2][12225]: completed

复制代码

aaaaaaaa2000

Bug 7486595  Standby media recovery fails with OERI:[krr_media_9] or OERI:[kcramr_8]

This note gives a brief overview bug 7486595.
The content was last updated on: 18-NOV-2010
Click here for details of each of the sections below.
Affects:

Product (Component)         Oracle Server (Rdbms)
Range of versions believed to be affected         Versions BELOW 11.2
Versions confirmed as being affected       
11.1.0.7
Platforms affected         Generic (all / most platforms affected)
Fixed:

This issue is fixed in       
11.2.0.1 (Base Release)
11.1.0.7.1 (Patch Set Update)
11.1.0.7 Patch 11 on Windows Platforms
11.1.0.7 Data Guard Physical Recommended Patch Bundle #1

看起来像是bug，但是11.2.0.1已经解决了，我的版本就是11.2.0.1

Maclean Liu(刘相兵

建议你 按照这个文档 重试 http://www.oracledatabase12g.com ... ysical-standby.html

aaaaaaaa2000

好吧，重新做吧！！！！