几个oracle问题。

保存下来，备用

The value (30) of MAXTRANS parameter ignored.

错误现象：

alert日志中出现如下错误：

The value (30) of MAXTRANS parameter ignored.
kupprdp: master process DM00 started with pid=76, OS id=897128
         to execute - SYS.KUPM$MCP.MAIN('SYS_EXPORT_SCHEMA_01', 'SYSTEM', 'KUPC$C_1_20090924171953', 'KUPC$S_1_20090924171953', 0);
kupprdp: worker process DW01 started with worker id=1, pid=78, OS id=1089996
         to execute - SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_01', 'SYSTEM');
kupprdp: worker process DW02 started with worker id=2, pid=80, OS id=802904
         to execute - SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_01', 'SYSTEM');
kupprdp: worker process DW03 started with worker id=3, pid=81, OS id=835786
         to execute - SYS.KUPW$WORKER.MAIN('SYS_EXPORT_SCHEMA_01', 'SYSTEM');

故障诊断过程：

这个时间段正在使用expdp进行导出操作，另外从错误描述也可以看出和导出操作有关，但当时导出是成功的没有抱错。于是搜索metalink，发现这是 10.2.0.3的一个bug，Bug号为：6347775

这是由于在创建主表时使用了如下语句：
CREATE TABLE () INITRANS 10 MAXTRANS 30

而Maxtrans参数在10gR1时已经废弃，所以在告警日志中就提示：
The value (30) of MAXTRANS parameter ignored.

由于此bug没有什么影响，所以可以忽略。

Memory Notification: Library Cache Object loaded into SGA问题

Memory Notification: Library Cache Object loaded into SGA

Heap size 2289K exceeds notification threshold (2048K)

Oracle10g中，在load较大的对象进library cache中时，会记录以上警告。在版本10.2.0.1中，这个定义大对象的阈值是2M，这是有隐含参数_kgl_large_heap_warning_threshold指定的，如果系统中需要load很多大对象，又不想在alert中看到太多这类的警告信息，可以修改该参数：

SQL> alter system set "_kgl_large_heap_warning_threshold"=8388608 scope=spfile；

参数值以字节为单位，设置完后需要重启实例才能生效。

从10.2.0.2起，这个参数的默认值被修改为50M.

下面是oracle上的metalink信息：

Memory Notification: Library Cache Object Loaded Into Sga

In 10g we have a new undocumented parameter that sets the KGL heap size warning threshold. This parameter was not present in 10gR1.Warnings are written if heap size exceeds this threshold.

Set _kgl_large_heap_warning_threshold to a reasonable high value or zero to prevent these warning messages. Value needs to be set in bytes.

If you want to set this to 8192 (8192 * 1024) and are using an spfile:

(logged in as "/ as sysdba")

SQL> alter system set "_kgl_large_heap_warning_threshold"=8388608 scope=spfile ;

SQL> shutdown immediate

SQL> startup

SQL> show parameter _kgl_large_heap_warning_threshold
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_kgl_large_heap_warning_threshold integer 8388608

If using an "old-style" init parameter,

Edit the init parameter file and add

_kgl_large_heap_warning_threshold=8388608


NOTE: The default threshold in 10.2.0.1 is 2M. So these messages could show up frequently in some application environments.

In 10.2.0.2, the threshold was increased to 50MB after regression tests, so this should be a reasonable and recommended value. If you continue to see the these warning messages in the alert log after applying 10.2.0.2 or higher, please contact Oracle Support Services for further investigation of any possible shared pool problems.

oracle sqlplus没反应的问题

oracle10g的有十几个机器客户端10.2.0.1.0，执行sqlplus这个命令没反映。此时cpu使用为99.9%，观察了一会，不释放。
oracle其他命令都好使。
环境变量、ping tnsname等都没问题。。且这些机器都是至少运行了200多天左右，
但一旦重启OS就好使了。。
或者不重启OS，换成9i的客户端，sqlplus命令也好使。
alert日志没有什么明显的报警信息，客户端的sqlnet.log为空。
用strace跟踪了一下客户端10的sqlplus命令，出现：
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
--- SIGSTOP (Stopped (signal)) @ 0 (0) ---
times(NULL)                             = -2064519321
times(NULL)                             = -2064519321
times(NULL)                             = -2064519321
……
所有客户端配置一样，系统信息：
Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
2.6.9-22.ELsmp #1 SMP
客户端硬件要么联想同一型号机器，要么就是HP同以型号机器。

是不是有什么补丁没打，或者和OS什么配置有关？
系统信息类似一下：
sar -u 后%idle为0，
但sar -A 查看%idle为99.70等百分之九十多左右，
然后是%user  %system   %iowait之间互相变化。

原因是：

是不是遇上uptime的bug了？

因为oracle有bug，系统开机太长，系统会hang
所以要查看os命令uptime来看系统启动多长时间了，
一般重启会解决问题，通过升级也可以解决

问题基本定位为ORACLE客户端软件的BUG，
涉及的版本：ORACLE 10.2.0.1.0
现象就是UPTIME>50天，即有可能出现运行SQLPLUS后无反应的现象，主要原因是时间溢出错误
解决办法：升级ORACLE客户端到10.2.0.2.0,官网已经公布在这个版本解决了此问题
         （或降级到9I,9I绝对不会出现这个问题；或降级到10.1.0.4版本，这个没有经过全面测试）
接下来就是升级试试看了。

升级和重启，都可以。

文章来自互联网，感谢作者！