Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
Oracle数据库数据恢复、性能优化»论坛 › Oracle › Oracle数据库管理 › 关于dg的两个问题
发新帖
miloluo

45

积分

0

好友

0

主题

关于dg的两个问题

1#
发表于 2012-5-23 15:31:57 | 查看: 7085| 回复: 6
Hi， 各位
有两个关于DG的问题想请教各位：
1. 环境：
OS: OEL 5.4 64 bit
Oracle Version: Oracle Enterprise Edition 10.2.0.1 64bit ,  之后升级到 10.2.0.4 64bit

2. 问题描述：
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
问题1：有两台机器做成了物理standby的dg环境(dga 为 Primary, dgb为 physical standby)，昨天在vbox上做了个升级的测试。
主要想测试目的是：在主库做了升级后，备库在应用主库升级过程中的日志，备库在直接升级oracle软件，能否正常完成升级过程。

步骤大致如下：
-1. primary 升级oracle软件，升级库
-2. standby（10.2.0.1)先进行主库升级过程中的日志应用，再进行oracle软件升级。
-3. 尝试打开standby的库，查看是否能正常打开(open readonly)。


在这个过程中出现了意外情况，在升级Primary过程中（使用手工升级），不断有包shared pool和java pool的不足的报错（最糟糕的情况是写了500m的trace），
因为是虚拟环境，内存不太足够。之后，把primary的sga_target,sga_max_size 从160M，调整至180M,并相应调高share pool和java pool的最小值。再重跑@?/rdbms/admin/catupgrd.sql
。
升级过程中还是报出了少量报错。

报错如下：
  1. Tue May 22 19:28:44 2012
  2. Errors in file /opt/oracle/admin/dgb/bdump/dgb_mmon_344.trc:
  3. ORA-00604: error occurred at recursive SQL level 2
  4. ORA-04031: unable to allocate 4120 bytes of shared memory ("shared pool","select name,password,datats#...","Typecheck","kgghteInit")
复制代码



但是最后，都过去了。
通过查询dba_registry，发现有个em组件为upgrading的状态。

  1. SQL> set linesize 200;
  2. SQL> r
  3.   1* select comp_name, version, status from dba_registry

  5. COMP_NAME                                VERSION                        STATUS
  6. ---------------------------------------- ------------------------------ -----------
  7. Oracle Database Catalog Views            10.2.0.4.0                     VALID
  8. Oracle Database Packages and Types       10.2.0.4.0                     VALID
  9. Oracle Workspace Manager                 10.2.0.4.3                     VALID
  10. JServer JAVA Virtual Machine             10.2.0.4.0                     VALID
  11. Oracle XDK                               10.2.0.4.0                     VALID
  12. Oracle Database Java Packages            10.2.0.4.0                     VALID
  13. Oracle Expression Filter                 10.2.0.4.0                     VALID
  14. Oracle Data Mining                       10.2.0.4.0                     VALID
  15. Oracle Text                              10.2.0.4.0                     VALID
  16. Oracle XML Database                      10.2.0.4.0                     VALID
  17. Oracle Rules Manager                     10.2.0.1.0                     VALID

  19. COMP_NAME                                VERSION                        STATUS
  20. ---------------------------------------- ------------------------------ -----------
  21. Oracle interMedia                        10.2.0.4.0                     VALID
  22. OLAP Analytic Workspace                  10.2.0.4.0                     VALID
  23. Oracle OLAP API                          10.2.0.4.0                     VALID
  24. OLAP Catalog                             10.2.0.4.0                     VALID
  25. Spatial                                  10.2.0.4.0                     VALID
  26. Oracle Enterprise Manager                10.2.0.1.0                     UPGRADING

  28. 17 rows selected.
复制代码



感觉应该可以忽略掉，但是，还是想解决掉。 通过mos里的How To Diagnose Components With NON VALID Status In DBA_REGISTRY After an Upgrade [ID 753041.1]
采集了脚本中的信息，但是，发现其中有几个对象有问题。


  1. ================================
  2. List of Invalid Database Objects
  3. ================================


  6. Number of Invalid Objects
  7. ------------------------------------------------------------------
  8. There are 3 Invalid objects

  10. DOC>################################################################
  11. DOC>
  12. DOC> If there are no Invalid objects below will result in zero rows.
  13. DOC>
  14. DOC>################################################################
  15. DOC>#


  18. OWNER        OBJECT_NAME                              OBJECT_TYPE
  19. ------------ ---------------------------------------- ----------------------------------------
  20. SYSMAN       EM_PING                                  PACKAGE BODY
  21. SYSMAN       MGMT_TIME_SYNC                           PACKAGE BODY
  22. SYSMAN       MGMT$DB_INIT_PARAMS                      VIEW

  24. 3 rows selected.


  27. ======================================================
  28. Count of Invalids by Schema
  29. ======================================================


  32. OWNER        OBJECT_TYPE                                COUNT(*)
  33. ------------ ---------------------------------------- ----------
  34. PUBLIC       SYNONYM                                           1
  35. SYSMAN       PACKAGE BODY                                      2
  36. SYSMAN       VIEW                                              1
  37. ==============================================================
  38. Identifying whether a database was created as 32-bit or 64-bit
  39. ==============================================================

  41. DOC>###########################################################################
  42. DOC>
  43. DOC> Result referencing the string 'B023' ==> Database was created as 32-bit
  44. DOC> Result referencing the string 'B047' ==> Database was created as 64-bit
  45. DOC> When String results in 'B023' and when upgrading database to 10.2.0.3.0
  46. DOC> (64-bit) , For known issue refer below articles
  47. DOC>
  48. DOC> Note 412271.1 ORA-600 [22635] and ORA-600 [KOKEIIX1] Reported While
  49. DOC>               Upgrading Or Patching Databases To 10.2.0.3
  50. DOC> Note 579523.1 ORA-600 [22635], ORA-600 [KOKEIIX1], ORA-7445 [KOPESIZ] and
  51. DOC>              OCI-21500 [KOXSIHREAD1] Reported While Upgrading To 11.1.0.6
  52. DOC>
  53. DOC>###########################################################################
  54. DOC>#


  57. Metadata Initial DB Creation Info
  58. -------- -----------------------------------
  59. B047     Database was created as 64-bit

  61. ===================================================
  62. Number of Duplicate Objects Owned by SYS and SYSTEM
  63. ===================================================

  65. Counting duplicate objects ....


  68.   COUNT(1)
  69. ----------
  70.          4
复制代码



请问，我应该如何解决这个问题，@?/rdbms/admin/utlrp.sql这个已经跑了好几遍都没有把这几个有问题的对象编译完整。

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
问题2：
因为，在做的途中遇到了意外，想问下，大伙有没这么做过升级的，也就是standby直接recover primary库在升级过程中的redo？
这样做会有什么风险吗？一般会怎么去做呢，谢谢。
7#
发表于 2012-5-24 10:27:00
Hi, maclean
找到了你说的11g的特性：
http://docs.oracle.com/cd/E11882 ... ollup.htm#SBYDB4884
多谢。

回复 只看该作者 道具 举报

6#
发表于 2012-5-23 20:30:30
11g中提出了 physical standby keep identify  即物理备库可以临时 转换为 logical standby 之后再转回 physical standby的新特性， 该新特性保证了 11g中 physical standby也可以实现rolling upgrade。

但是10g中 physical standby是做不到rolling upgrade滚动升级的。

回复 只看该作者 道具 举报

5#
发表于 2012-5-23 15:49:01

回复 3# 的帖子

谢谢yingyifeng，我再检查下。

回复 只看该作者 道具 举报

4#
发表于 2012-5-23 15:46:09
谢谢Maclean.
另外还有个问题：
在10g文档中好像只提及logical standby有rolling upgrade的方式。

Physical standby + Primary的dg环境是否有rolling upgrade ? 这种rolling upgrade是不是只能保证是提供服务的库是readonly的。

回复 只看该作者 道具 举报

3#
发表于 2012-5-23 15:42:58

2

我觉得这几个对象失效，有可能是什么配置问题，查看一下主机的一些配置信息，或者跑一下预检查脚本，修复所有问题后，尝试reinstall Oracle Enterprise Manager组建

回复 只看该作者 道具 举报

2#
发表于 2012-5-23 15:38:40
1.

physical standby dg 环境的非rolling upgrade升级 的大致步骤 建议这样：


1. 停止 redo  transfer ， 关闭standby
2.升级 standby 上的database software， 之后就可以启动standby 上的recover MRP
3. 升级 primary 上的database software
4 . 运行升级脚本 catupgrd or dbua
5. 启动 redo  transfer
6.  standby 会自动应用  字典升级相关的日志，可以之后open read only 检查 dba_registry

回复 只看该作者 道具 举报

返回列表
高级模式
B Color Image Link Quote Code Smilies
您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-11-15 20:10 , Processed in 0.049014 second(s), 22 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569