25 06, 2008
这篇文章是偶用半生不熟的E文翻译过来的，所以很多可能看着很别扭，E文好的建议直接看原文，在METALINK中的294430.1，284752.1和309542.1三篇文章中。
CSS的MISSCOUNT参数定义了集群重新配置并驱逐一个节点前，这个节点的心跳可以缺失的时间，单位是秒。其中各个平台的缺省的MISSCOUNT如下：
Linux下60秒，Unix、VMS和Windows下都是30秒，对于其他非ORACLE提供的CLUSTER来说，缺省的MISSCOUNT是600秒，这是为了给其他的集群提供商提供足够的时间来解决任何场景下的脑裂。
CSS心跳的机制和他们之间的相互关系:
查看全文18 06, 2008
系统日志中出现大量的truncating integer value to 32 bits信息
REDHAT AS4U4的X86_64系统，在系统的/VAR/LOG/MESSAGE日志中出现大量的truncating integer value to 32 bits信息，完整的信息如下：
Jun 18 11:22:10 billdb1 snmpd[26994]: send response:
Jun 18 11:22:10 billdb1 snmpd[26994]: truncating integer value to 32 bits
Jun 18 11:22:10 billdb1 snmpd[26994]: truncating uinteger value to 32 bits
Jun 18 11:22:10 billdb1 snmpd[26994]: truncating uinteger value to 32 bits
Jun 18 11:22:13 billdb1 snmpd[26994]: truncating integer value to 32 bits
Jun 18 11:22:13 billdb1 snmpd[26994]: truncating uinteger value to 32 bits
Jun 18 11:22:13 billdb1 snmpd[26994]: truncating uinteger value to 32 bits
Jun 18 11:22:16 billdb1 snmpd[26994]: truncating integer value to 32 bits
Jun 18 11:22:16 billdb1 snmpd[26994]: truncating uinteger value to 32 bits
Jun 18 11:22:16 billdb1 snmpd[26994]: truncating uinteger value to 32 bits
因为系统有使用SNMP进行部分监控，导致上面信息不停的出现在MESSAGE日志中，导致有用的系统信息被淹没其中。GOOGLE了半天，应该是REDHAT平台上的NET-SNMP包的一个BUG导致的。
查看全文16 06, 2008
因为业务需要，不得不在生产上更新一个千万级的大表，更新过程中产生了4个G左右的日志后发现此更新会导致其他问题，取消更新，然后更正更新的逻辑后，重新对这千万级的数据进行更新，产生6个多G的日志后，更新完成，但是却造成了其他两个逻辑STANDBY的大量延迟。如何加快这些日志的应用，是一个比较严重的问题。
查看全文14 06, 2008
ORACLE CRS日志中的ClssnmPollingThread Missed Checkins Messages
最近发现CRS日志中的missed checkin很多，有时候有连着将近20次，之前有过一次RAC的宕机记录，所以对这个咚咚很警觉。CRS中，会定期的去读取VOTING DISK上的信息来判断CLUSTER中的每个节点的活动状态，如果出现多次的读取失败，则认为这个节点已经死掉，机会把它赶出CLUSTER了。读取失败的参数是可以通过CRSCTL命令设置的，这个值缺省是60次。crsctl get css misscount命令可以返回当前设置的值，crsctl set css misscount 120则是把失败次数设置为120次。一般是不需要调整这个值的，如果调整也不要调的太大。还是来看看metalink上是怎么说的吧。
查看全文5 06, 2008
LINTENER.ORA中的SID_NAME和SERVICE_NAME大写导致ORA-01031: insufficient privileges
创建一个RAC TO RAC的STANDBY，走到为STANDBY创建口令文件，然后STARTUP STANDBY库到NOMOUNT状态，然后从主库开始RMAN恢复来创建STANDBY的时候，报错：ORA-01031: insufficient privilege，于是尝试手工的通过SQLPLUS SYS/PASSWORD@TNSNAME AS SYSDBA，报同样的错误，这样的错误碰见几次了，无非就是口令文件的问题，或者就是remote_login_passwordfile参数设置的问题，再者就是SQLNET.ORA的问题了，结果这三招用遍了都不好使，见鬼。
查看全文31 05, 2008
碰见一个BLOCKING_SESSION显示不正确的BUG
REDHAT LINUX AS4U4上运行的3个节点的ORACLE 10.2.0.2系统，因为前台应用的原因，会导致某些事务一直不提交也不回滚，所以这个事务影响的记录就会出于加锁状态，从而导致后来的事务需要操作相同记录的就会出现一个锁等待事件，为了确定是哪个SESSION BLOCK其他事务，于是根据锁等待时间最长的SESSION的SID去V$SESSION视图中查找BLOCKING_SESSION的值，得到是谁BLOCK了这个SESSION，以便找到问题的根源，然后奇怪的问题发生了，找到的这个BLOCKING_SESSION的值去V$LOCK中查找，却发现这个session根本没有LOCK任何资源，而且，把这个SESSION杀掉之后，原先被BLOCK的SESSION还是处于BLOCK的状态，看来是杀错SESSION了。
感觉不可思议，ORACLE BUG碰见的多，碰见这种鬼问题首先想到的就是METALINK了，查了下，果然是个BUG，看看上面是怎么说的吧。
查看全文29 05, 2008
最近在看ORA-04031，结果在METALINK上看一个文档，会引出另外几个相关的文档，看了前面忘了后面，干脆把这些文档一个个的看完，然后翻译一下，希望最后能有时间再写个大汇总来把这些问题汇总一遍，应该大多数的ORA-04031问题就能够被解决了。
此文档在METALINK的ID:146599.1
查看全文27 05, 2008
之前一直没有注意过，而且都是使用现成的文档来手工建库，今天才发现我们的手册没有执行catblock.sql这个脚本，所以就没有创建这些视图。这些视图不是必须的，但是有了这些视图可能会使用起来方便点。
ORACLE自动创建了如下几个视图：
DBA_KGLLOCK
DBA_LOCK
DBA_LOCK_INTERNAL
DBA_DML_LOCKS
DBA_DDL_LOCKS
DBA_WAITERS
DBA_BLOCKERS
他们各自的含义其实只要看catblock.sql脚本中的注释就可以了，这里只是把注释搬过来，记录一下。
查看全文27 05, 2008
如果/VAR/LOG/MESSAGE中出现了上面的错误，那就是因为某些进程因为内存不够而被系统自动杀掉了，系统自动杀掉某些进程主要是出于对系统整体的保护，避免整个系统HANG掉。
下面转载的文章中详细描述了这种问题发生的原因和避免的办法
查看全文26 05, 2008
SHARED POOL中KGH: NOACCESS占用大量内存的问题分析
接上篇的ORA-04031错误，知道整个SHARED POOL的组件中，ASM extent pointer array占用很大的内存是显示的一个BUG后，继续分析各个组件占用的内存大小，结果发现KGH: NO ACCESS组件也占用了400多M，这个又是个什么鬼东西呢？还是看看METALINK上怎么说的吧。
查看全文25 05, 2008
shared pool中的ASM extent pointer array组件大小显示异常的BUG
数据库报告0RA-04031错误，这个是个很常见的错误了，十之八九是因为SHARED POOL不够大了，导致新的对SHARED POOL的申请需求失败而报错。于是登陆数据库查看V$SGA_STAT视图，看看整个shared pool分配中，各个组件占用多少内存，是否是真的shared pool不够了，还是某些组件发生异常导致。结果发现一个很奇怪的现象，整个shared pool设置为600M,但是ASM extent pointer array组件占用的内存却已经有1500M了，见鬼，这个是个啥东西，居然占用1500M的空间啊？？
查看全文23 05, 2008
转载自：http://www.linuxdiyf.com/viewarticle.php?id=89776
很多人会遇到在操作系统上rm掉一个大的文件，以解决文件系统超标的问题，可是有的时侯文件删除掉了，而空间却未释放出来。论坛上也常常见这样贴子，为什么会这样，如何解决呢？本文只局限于Hp unix的操作系统。
原因其实很简单，主要是因为被删除的文件在删除的时侯还是进程在操作(打开、访问等)的缘故，rm只完成了在磁盘上文件实体的释放，而类似free list结构中相应的文件系统因进程的操作相应的inode并未释放。
查看全文14 05, 2008
最近看到了有EXT4的文件系统的介绍，找了一下这个升级版的文件系统的NEW FEATURE：
1 Multiblock Allocation
2 Delayed Allocation
3 Break 32000 subdirectory limit
4 directory Inodes reservation
5 nsec timestamps
6 inode version on disk
7 uninitialized groups
8 journal checksumming
9 persistent preallocation
10 Online Defragmentation
11 Undelete Feature for Ext4
12 Large file support
简单看了看，其实对于大多数系统来说，子目录数、单个文件等等估计都很难达到EXT3的限制的，所以这些吸引力估计不大。
我比较关心的是Undelete Feature和directory Inodes reservation,一个是数据的UNDELETE，另一个是因为我碰见过因为Inodes满导致listener不能启动的案例，当时是找到系统生成很多零碎的日志，把这些日志删除了。其实如果Inodes也可以和Block一样预留一点，那生产系统发生问题的时候，至少可以先使用预留的部分来救火，然后再慢慢的解决问题了。
不过，简单查了些资料，在目前的linux系统中，好像完全实现上面12个功能的发布版还没有，很多都只是提供了部分的功能，而且把EXT3 MOUNT为EXT4的时候，是MOUNT EXT4DEV格式的，从这里也可以看出，目前的EXT4应该是处于开发中的EXT4DEV，而不是包含全部FEATURE的，所以使用的时候要看仔细。
14 05, 2008
在逻辑STANDBY上使用EXPDP进行数据导出备份的问题，ORA-39004，ORA-39091，ORA-16103
因为在逻辑STANDBY上建了另外的SCHEMA来做报表，而且报表库很小，所以打算每天使用EXPDP把报表库备份一下，可是使用EXPDP进行备份的时候，却出现错误提示：
ORA-39004: invalid state
ORA-39091: unable to determine logical standby and streams status
ORA-16103: Logical Standby apply must be stopped to allow this operation
提示很清楚，执行这个操作的时候，必须停止STANDBY APPLY，于是把APPLY停，见鬼的是居然还是不行，这咋回事呢？
13 05, 2008
遭遇ORA-00600: internal error code, arguments: [kcrrrfswda.11], [4], [368], [], [], [], [], []
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb1_lns1_28689.trc:
ORA-00272: error writing archive log
Thu May 8 22:23:26 2008
LGWR: I/O error 272 archiving log 2 to 'dgp'
DGP是PHYSICAL DATAGUARD，看来是往物理DATAGUARD上写日志的时候出现问题，于是登陆物理DATAGUARD机器检查，却发现DATAGUARD机器出现如标题所示的600错误，查看TRACE文件，一堆二进制的天书。咋办呢？ 查看全文