臭臭熊

客户一个sun双机数据库始终使用pfile启动数据库

查看官方文档 得知默认情况下sun双机默认会使用pfile

http://docs.sun.com/app/docs/doc/820-0182/6nbujgafj?l=en&a=view&q=HA+standby+spfile

今天客户数据库出现故障，登录查看，除了sql效率低下外，发现了一个oracle bug  from metalink Note:5918642.8

Bug 5918642 - Heavy latch contention with DB_CACHE_ADVICE on

其中的latch就是指 simulator lru latch

解决办法就是升级10.2.0.4或者设置db_cache_advice=off

SQL> l
1  select sample_time,name ,count(*)
2  from ash_tmp,v$latch_children
3  where addr=’0000000′||trim(to_char(p1,’XXXXXXXXX’))
4  and event=’latch free’
5  group by sample_time,name
6* order by 3 desc
SQL> /

SAMPLE_TIME                                                                 NAME                             COUNT(*)
————————————————————————— —————————— ———-
25-JUN-08 04.37.04.960 PM                                                   simulator lru latch                   132
25-JUN-08 04.37.26.880 PM                                                   simulator lru latch                    90
25-JUN-08 04.37.13.950 PM                                                   simulator lru latch                    75
25-JUN-08 04.37.55.470 PM                                                   simulator lru latch                    68
25-JUN-08 04.37.05.970 PM                                                   simulator lru latch                    58
25-JUN-08 04.36.13.940 PM                                                   simulator lru latch                    50
25-JUN-08 04.37.14.990 PM                                                   simulator lru latch                    42
25-JUN-08 04.37.27.910 PM                                                   simulator lru latch                    39
25-JUN-08 04.37.06.981 PM                                                   simulator lru latch                    31
25-JUN-08 04.37.16.000 PM                                                   simulator lru latch                    29
25-JUN-08 04.37.56.480 PM                                                   simulator lru latch                    16
25-JUN-08 04.37.08.001 PM                                                   simulator lru latch                    13

select to_char(sysdate-1,’d) from dual;

由于windows上ORACLE操作都集中在ORACLE.EXE一个进程上，想具体查看是那个线程占用cpu偏高，需要使用一些windows下观察线程的工具： Read the rest of this entry »

 Aix 5.3 + ORACLE10G 64bit

报错： ORA-00600: internal error code, arguments: [unable to load XDB library], [], [], [], [], [], [], []

根据metalink 417020.1

LIBPATH，LD_LIBRARY_PATH 这两个环境变量设置有问题。

数据库版本：9.2.0.8.0 操作系统：windows
错误描述：
EXP-00056: 遇到 ORACLE 错误 31600
ORA-31600: 输入值 EMIT_SCHEMA 无效, 它用于参数 NAME, 位于函数 SET_TRANSFORM_PARAM 中
ORA-06512: 在“SYS.DBMS_SYS_ERROR”, line 105
ORA-06512: 在“SYS.DBMS_METADATA_INT”, line 3926 Read the rest of this entry »

From metalink noteId:388017.1

windows下监听瘫痪，解决方法：在服务属性中修改，恢复–第一次失败自动重启服务……  :shock:

描述：现场反馈数据库主机内存占用达到峰值，windows 2003 x64系统僵死，dump文件每个几十m，共计7G左右。

alert日志：
ORA-07445: 出现异常错误: 核心转储 [ACCESS_VIOLATION] [opidsa+1266] [PC:0×29706F6] [ADDR:0×0] [UNABLE_TO_READ] []

解决：怀疑是bug，metalink搜到418531.1 ，果然，又一个地雷 ；

准备打补丁解决：
p4898608_10203_GENERIC
p6430174_10203_MSWIN-x86-64

还有另外一个方法可以缓解，那就是定期刷share pool。

问题描述：

开发人员报告数据库时快时慢，下午应用报错，系统死掉，现场重启库。

分析：

alert日志：

Thu Nov 01 08:39:12 2007
Errors in file e:\oracle\admin\gbbcrm\udump\gbbcrm_s000_3688.trc:
ORA-00600: 内部错误代码，参数: [1236], [], [], [], [], [], [], []

Thu Nov 01 08:40:00 2007
Errors in file e:\oracle\admin\gbbcrm\udump\gbbcrm_s000_3688.trc:
ORA-00600: 内部错误代码，参数: [1236], [], [], [], [], [], [], []

Errors in file e:\oracle\admin\gbbcrm\udump\gbbcrm_s002_4232.trc:
ORA-00600: 内部错误代码，参数: [16365], [0×1D6F1A30], [0], [4], [], [], [], []

Fri Nov 02 13:41:29 2007
Error 600 trapped in 2PC on transaction 20.0.2. Cleaning up.
Error stack returned to user:
ORA-00600: 内部错误代码，参数: [16365], [0×1D6F1A30], [0], [4], [], [], [], []
应用报错：

ORA-04031: 无法分配 8132 字节的共享内存 (”large pool”，”unknown object”，”cursor work he”，”qesaQBInit:buffer”)

metalink中用600那个工具搜索了一下，找到两篇相关文档：

138354.1

106607.1

说的基本都是关于共享服务器连接模式下的错误，再看看应用抛的04031，问题确认基本出在应用连数据库的模式问题上了，用lsnrct service确认，果然共享连接占大比例，目前把应用修改成专用的再观察一段。