OracleBlog – 第 29 页 – 笑看数据库江湖的那些事儿……

又见bug，动态调整SGA参数导致数据库crash

2010-11-13 一条评论

最近遇到这样一个事情，在动态的调整sga的一个参数的时候，数据库就down了：

SQL> alter system set DB_KEEP_CACHE_SIZE=1g;
alter system set DB_KEEP_CACHE_SIZE=1g
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel


SQL>

1

2

3

4

5

6

7

8

SQL> alter system set DB_KEEP_CACHE_SIZE=1g;

alter system set DB_KEEP_CACHE_SIZE=1g

*

ERROR at line 1:

ORA-03113: end-of-file on communication channel

SQL>

对应的，在alertlog中的报错为：

Sat Nov 13 03:56:00 2010
Errors in file /u01/app/oracle/product/10.2.0/admin/MICPRD/bdump/micprd_mman_3264732.trc:
ORA-00600: internal error code, arguments: [kmgs_update_target_size_1], [0], [], [], [], [], [], []
Sat Nov 13 03:56:01 2010
Errors in file /u01/app/oracle/product/10.2.0/admin/MICPRD/bdump/micprd_mman_3264732.trc:
ORA-00600: internal error code, arguments: [kmgs_update_target_size_1], [0], [], [], [], [], [], []
Sat Nov 13 03:56:01 2010
MMAN: terminating instance due to error 822
Sat Nov 13 03:56:01 2010
Errors in file /u01/app/oracle/product/10.2.0/admin/MICPRD/bdump/micprd_mmon_2969868.trc:
ORA-00600: internal error code, arguments: [kmgs_perform_parameter_updates_1], [0], [], [], [], [], [], []
Sat Nov 13 03:56:03 2010
Errors in file /u01/app/oracle/product/10.2.0/admin/MICPRD/bdump/micprd_mmon_2969868.trc:
ORA-00600: internal error code, arguments: [kmgs_parameter_update_timeout_1], [600], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [kmgs_perform_parameter_updates_1], [0], [], [], [], [], [], []
Instance terminated by MMAN, pid = 3264732

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

Sat Nov 13 03:56:00 2010

Errors in file /u01/app/oracle/product/10.2.0/admin/MICPRD/bdump/micprd_mman_3264732.trc:

ORA-00600: internal error code, arguments: [kmgs_update_target_size_1], [0], [], [], [], [], [], []

Sat Nov 13 03:56:01 2010

Errors in file /u01/app/oracle/product/10.2.0/admin/MICPRD/bdump/micprd_mman_3264732.trc:

ORA-00600: internal error code, arguments: [kmgs_update_target_size_1], [0], [], [], [], [], [], []

Sat Nov 13 03:56:01 2010

MMAN: terminating instance due to error 822

Sat Nov 13 03:56:01 2010

Errors in file /u01/app/oracle/product/10.2.0/admin/MICPRD/bdump/micprd_mmon_2969868.trc:

ORA-00600: internal error code, arguments: [kmgs_perform_parameter_updates_1], [0], [], [], [], [], [], []

Sat Nov 13 03:56:03 2010

Errors in file /u01/app/oracle/product/10.2.0/admin/MICPRD/bdump/micprd_mmon_2969868.trc:

ORA-00600: internal error code, arguments: [kmgs_parameter_update_timeout_1], [600], [], [], [], [], [], []

ORA-00600: internal error code, arguments: [kmgs_perform_parameter_updates_1], [0], [], [], [], [], [], []

Instance terminated by MMAN, pid = 3264732

对应的tace文件中的call stack为： […]

..experience, Working case

DG备库遭遇ORA-16146的bug

2010-11-05 一条评论

今天收到监控的一个告警：

ORA-16146: standby destination control file enqueue unavailable

1	ORA-16146: standby destination control file enqueue unavailable

登录主库和备库检查其报错信息：备库上的alertlog：

Media Recovery Waiting for thread 1 seq# 2506
Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2506.arc
Wed Oct 27 20:30:24 2010
Media Recovery Waiting for thread 1 seq# 2507
Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2507.arc
Thu Oct 28 00:13:35 2010
Media Recovery Waiting for thread 1 seq# 2508
Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2508.arc
Thu Oct 28 01:24:57 2010
RFS: controlfile enqueue unavailable
Possible invalid cross-instance archival configuration
Thu Oct 28 01:25:00 2010
Errors in file /oracle_log/JPJDE/admin/udump/jpjde_rfs_1331404.trc:
ORA-16146: standby destination control file enqueue unavailable
Thu Oct 28 01:44:42 2010
RFS: Error State mode '2'
Thu Oct 28 01:45:31 2010
Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2509.arc
Thu Oct 28 01:46:53 2010
RFS: Forced Shutdown due to RFS_ERROR state
Thu Oct 28 01:50:33 2010
Media Recovery Waiting for thread 1 seq# 2510 (in transit)
Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2510.arc
Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2511.arc
Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2512.arc
Thu Oct 28 02:11:34 2010
Media Recovery Waiting for thread 1 seq# 2513
Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2513.arc

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

Media Recovery Waiting for thread 1 seq# 2506

Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2506.arc

Wed Oct 27 20:30:24 2010

Media Recovery Waiting for thread 1 seq# 2507

Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2507.arc

Thu Oct 28 00:13:35 2010

Media Recovery Waiting for thread 1 seq# 2508

Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2508.arc

Thu Oct 28 01:24:57 2010

RFS: controlfile enqueue unavailable

Possible invalid cross-instance archival configuration

Thu Oct 28 01:25:00 2010

Errors in file /oracle_log/JPJDE/admin/udump/jpjde_rfs_1331404.trc:

ORA-16146: standby destination control file enqueue unavailable

Thu Oct 28 01:44:42 2010

RFS: Error State mode '2'

Thu Oct 28 01:45:31 2010

Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2509.arc

Thu Oct 28 01:46:53 2010

RFS: Forced Shutdown due to RFS_ERROR state

Thu Oct 28 01:50:33 2010

Media Recovery Waiting for thread 1 seq# 2510 (in transit)

Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2510.arc

Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2511.arc

Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2512.arc

Thu Oct 28 02:11:34 2010

Media Recovery Waiting for thread 1 seq# 2513

Media Recovery Log /oracle_log/JPJDE/arch_logs/stby_1_2513.arc

对应同一时间，主库上的信息： [crayon-6846df7137dce20528 […]

..experience, Working case

移动DG数据库的数据文件

2010-10-26 6条评论

今天遇到个问题，由于执行一个TSM脚本的时候，没注意到脚本中的语句会新建一个tablespace，而且新建的语句是

create tablespace tsm datafile 'tsm.dbf' size 100m autoextend off;

1	create tablespace tsm datafile 'tsm.dbf' size 100m autoextend off;

由于没有指定数据文件的绝对路径，所以默认就放在了$ORACLE_HOME/dbs路径下。数据文件路径不统一，风险可大 […]

..experience, Working case

由于TSM引起的数据库宕机

2010-10-19 2条评论

今天接到一个电话，一个应用的同事说的登录不上数据库，该数据库是在一台windows服务器上的，登录主机后，发现在系统的服务里面，oracle是启动的，但是登录数据库发现数据库已经宕机。检查数据库的alertlog发现：

Tue Oct 19 03:22:38 2010
Thread 1 advanced to log sequence 40786
  Current log# 3 seq# 40786 mem# 0: D:\ORACLE\ORADATA\JPJDE2\REDO03.LOG
Tue Oct 19 03:25:44 2010
Thread 1 advanced to log sequence 40787
  Current log# 1 seq# 40787 mem# 0: D:\ORACLE\ORADATA\JPJDE2\REDO01.LOG
Tue Oct 19 03:29:48 2010
Errors in file d:\oracle\admin\jpjde2\bdump\jpjde2_lgwr_2532.trc:
ORA-00321: log 2 of thread 1, cannot update log file header
ORA-00312: online log 2 thread 1: 'D:\ORACLE\ORADATA\JPJDE2\REDO02.LOG'
ORA-27091: skgfqio: unable to queue I/O
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.

Tue Oct 19 03:29:48 2010
Errors in file d:\oracle\admin\jpjde2\bdump\jpjde2_lgwr_2532.trc:
ORA-00321: log 2 of thread 1, cannot update log file header

LGWR: terminating instance due to error 321
Instance terminated by LGWR, pid = 2532

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

Tue Oct 19 03:22:38 2010

Thread 1 advanced to log sequence 40786

Current log# 3 seq# 40786 mem# 0: D:\ORACLE\ORADATA\JPJDE2\REDO03.LOG

Tue Oct 19 03:25:44 2010

Thread 1 advanced to log sequence 40787

Current log# 1 seq# 40787 mem# 0: D:\ORACLE\ORADATA\JPJDE2\REDO01.LOG

Tue Oct 19 03:29:48 2010

Errors in file d:\oracle\admin\jpjde2\bdump\jpjde2_lgwr_2532.trc:

ORA-00321: log 2 of thread 1, cannot update log file header

ORA-00312: online log 2 thread 1: 'D:\ORACLE\ORADATA\JPJDE2\REDO02.LOG'

ORA-27091: skgfqio: unable to queue I/O

ORA-27041: unable to open file

OSD-04002: unable to open file

O/S-Error: (OS 32) The process cannot access the file because it is being used by another process.

Tue Oct 19 03:29:48 2010

Errors in file d:\oracle\admin\jpjde2\bdump\jpjde2_lgwr_2532.trc:

ORA-00321: log 2 of thread 1, cannot update log file header

LGWR: terminating instance due to error 321

Instance terminated by LGWR, pid = 2532

看来昨天晚上3 […]

..oracle service, Working case

OOW 2010中两场Larry Ellison的keynote

2010-10-16 一条评论

在网上看到2场OOW（Oracle Open World）2010中Larry Ellison主讲的keynote，一场是2010年9月19日的，主要讲的是云计算和oracle新推出的Exalogic；另一场是在2010年的9月22日，讲的内容比较多，主要讲了oracle相关的所有内容做的集成。我 […]

..experience, Working case

crs只能启动一个asm实例

2010-10-09 3条评论

今天接到一个朋友的电话，说他有个客户rac安装的时候总是有问题。cluster软件已经装上，但是没法装数据库。由于网络环境比较差，无法远程，只能通过QQ来了解情况和诊断了。一开始，先让对方运行crs_stat -t看看各个资源的状况：

[oracle@rac01 bin]$ ./crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora....SM1.asm application    ONLINE    ONLINE    rac01       
ora....01.lsnr application    ONLINE    ONLINE    rac01       
ora.rac01.gsd  application    ONLINE    ONLINE    rac01       
ora.rac01.ons  application    ONLINE    ONLINE    rac01       
ora.rac01.vip  application    ONLINE    ONLINE    rac01       
ora....SM2.asm application    ONLINE    OFFLINE               
ora....02.lsnr application    ONLINE    ONLINE    rac02       
ora.rac02.gsd  application    ONLINE    ONLINE    rac02       
ora.rac02.ons  application    ONLINE    ONLINE    rac02       
ora.rac02.vip  application    ONLINE    ONLINE    rac02

1

2

3

4

5

6

7

8

9

10

11

12

13

[oracle@rac01 bin]$ ./crs_stat -t

Name Type Target State Host

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

ora....SM1.asm application ONLINE ONLINE rac01

ora....01.lsnr application ONLINE ONLINE rac01

ora.rac01.gsd application ONLINE ONLINE rac01

ora.rac01.ons application ONLINE ONLINE rac01

ora.rac01.vip application ONLINE ONLINE rac01

ora....SM2.asm application ONLINE OFFLINE

ora....02.lsnr application ONLINE ONLINE rac02

ora.rac02.gsd application ONLINE ONLINE rac02

ora.rac02.ons application ONLINE ONLINE rac02

ora.rac02.vip application ONLINE ONLINE rac02

It's my life

别了.cn，本站全面转向.org域名：oracleblog.org

2010-09-30 9条评论

最近被一件事情弄的很头大，上周日，我收到这样一份邮件：

oracleblog.cn 域名持有者:
　　 您好！
　　根据《工业和信息化部关于进一步深入整治手机淫秽色情专项行动工作方案》（工信部电管【2009】672号）的规定，域名注册管理和服务机构应“严格落实域名注册申请者应提交真实、准确、完整的域名注册信息的规定，违反上述规定的，依法予以注销”。
　　为保护您的合法权益，维护域名注册秩序，我中心特通知如下：
　　1、请尚未完成域名注册信息核对的域名持有者，于2010年9月30日前联系相应域名注册服务机构，提交合格的信息证明材料。
　　2、因未提交合格信息证明材料而被暂停解析的，域名持有者应尽快向所属域名注册服务机构提交信息证明材料。	
　　您在信息证明材料提交过程中遇到的任何问题，均可通过下述网址向相应注册服务机构进行咨询，各域名注册服务机构将及时为您解决。
　　域名信息核验专项服务通道：http://www.cnnic.cn/html/Dir/2010/09/14/6003.htm。
中国互联网络信息中心

1

2

3

4

5

6

7

8

9

oracleblog.cn 域名持有者:

　　您好！

　　根据《工业和信息化部关于进一步深入整治手机淫秽色情专项行动工作方案》（工信部电管【2009】672号）的规定，域名注册管理和服务机构应“严格落实域名注册申请者应提交真实、准确、完整的域名注册信息的规定，违反上述规定的，依法予以注销”。

　　为保护您的合法权益，维护域名注册秩序，我中心特通知如下：

　　1、请尚未完成域名注册信息核对的域名持有者，于2010年9月30日前联系相应域名注册服务机构，提交合格的信息证明材料。

　　2、因未提交合格信息证明材料而被暂停解析的，域名持有者应尽快向所属域名注册服务机构提交信息证明材料。

　　您在信息证明材料提交过程中遇到的任何问题，均可通过下述网址向相应注册服务机构进行咨询，各域名注册服务机构将及时为您解决。

　　域名信息核验专项服务通道：http://www.cnnic.cn/html/Dir/2010/09/14/6003.htm。

中国互联网络信息中心

看来如果不提交信息，我的cn域名活不过9月30日了。唉，为了这个域名，今年7月份的时候我忘记续费，为了再次开通我还花了500块的大米去赎回来。于是我立即登录我的域名提供商易名中 […]

It's my life

办公室政治

2010-09-13 6条评论

办公室政治哪里都有，不论大小企业，不论你身处什么岗位，只要身在江湖，就不免身陷其中。某客户的数据库近期总是发生cpu负载过高的问题，经过检查，发现cpu中的user比例很高，通常情况下user可达60%以上，峰值时达90%，于是cpu的idle就在业务忙时会出现持续为0的情况了。通过检查发现，数据 […]

Study note

dbms_backup_restore也不是那么常用嘛

2010-09-10 没有评论

之前看文章，说建议数据库用rman备份的话，最好采用catalog数据库，将备份信息保留在catalog库中。对于没有catalog的数据库rman备份，备份信息将保留在控制文件中。因此如果控制文件丢失，还原起来就比较麻烦，需要用dbms_backup_restore来进行恢复（恢复方式见文章的附 […]

It's my life

Inception观后感

2010-09-05 一条评论

今天下午和老婆一起去看了inception（盗梦空间），这部网上疯传说好看的片子。看这部片子之前，中午先睡了个午觉，不过由于设置的闹钟选项在工作日才响，差点就变成在梦中梦见我们看这部电影了。幸好及时醒来，急匆匆的打的去电影院了。这个电影的名字叫inception，中文直接翻译是“开始”、“开端”， […]

Working case

为AIX中配置sendmail relay到smtp server

2010-08-24 2条评论

今天写了一个数据库的监控脚本，在测试脚本能否正常告警时，发现邮件发不出去。这个系统的环境是这样的，在整个系统中，大部分的机器放在192.168.1网段，为trust area，数据库主机也在此网段；另外有几台机器在192.168.3网段，为DMZ area。发送邮件不能直接在数据库主机上直接发送， […]

Study note

OCM考试-总结和补充

2010-08-19 7条评论

OCM考试系列的文章写的快结束了，基本的内容都已经涉及到，在这片文章中，将对之前的OCM考试系列文章进行汇总，对一些之前没提到的知识点进行补充。 OCM考试分成8个section，时间安排为：

OCM考试一共有9个section，具体的安排如下：
第一天上午：
section 0:创建一个数据库        45分钟
section 1:数据库和网络配置      120分钟
第一天下午：
section 2:Grid control安装配置   120分钟
section 3:数据库备份恢复        60分钟
section 4:数据仓库管理          90分钟

第二天上午：
section 5:数据库管理            120分钟
section 6:数据库性能管理        120分钟
第二天下午：
section 7:部署Oracle RAC数据库  105分钟
sectoin 8:部署dataguard数据库   60分钟

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

OCM考试一共有9个section，具体的安排如下：

第一天上午：

section 0:创建一个数据库 45分钟

section 1:数据库和网络配置 120分钟

第一天下午：

section 2:Grid control安装配置 120分钟

section 3:数据库备份恢复 60分钟

section 4:数据仓库管理 90分钟

第二天上午：

section 5:数据库管理 120分钟

section 6:数据库性能管理 120分钟

第二天下午：

section 7:部署Oracle RAC数据库 105分钟

sectoin 8:部署dataguard数据库 60分钟

section 0的手工建库，相关文章见 […]