“华为四核honor”与小米2同一天登陆

    看到一条新闻,华为推出了"honor四核版"手机,售价也只有1888元。海思 K3V2四核1.4GHz处理器、4.5英寸1280×720分辨率 IPS屏幕,拥有2G RAM,摄像头达到800万像素,电池容量2230mAh。在加上今天是期待已久的小米2的网络发售时间,中午的时候在我努力的" 刷新"页面、"不断F5"时,面对半瘫不瘫的页面,nothing you can do but wait….终于,不到3分钟,终于有了反馈,售 罄、抢购完毕,88,11月再来,很无奈,还真是成了之前提过的"期货小米2"。曾想华为下午推出了这个利器,挑在这个时间点,不知华为终端是有意,还是 巧合,但看配置,小米2其实没太多亮点了,后者逐渐在赶上。

    其实,我一直有个观点:粘着用户的应该是易用的ROM(miui),而不是硬件配置。当下,手机的硬件配置已经不是瓶颈了,某种程度来讲,已经出现“配置 过剩”了,而小米做得不错的地方是在混乱的android市场上,一直在不断优化自己的rom,将其易用性不断提升,一直有不少的粉丝,用心可见。记得几 个月前,给父母买了小米,60左右的老人在两天内基本把功能摸熟了,其实这个就是最好的易用性体现,手机是否好用,让老年人或者没有“背景”的人用就可以 了,产品好坏很容易分辨出来。就当某个周五,老爹在应用小米例行的更新之后,惊奇的发现之前手机上已经硕大的字体,变得更大了,之前偏小的二级菜单字体也 变大了,老爹如获至宝,多年未解决的问题,在智能手机时代搞定了,我也松了一口气。要知道为了给老爹换个称心如意的手机,在市面上,我跑了很久,一直在山 寨手机里面找来找去的我,也终于卸下重担,仅仅是为了满足老人“字大”、“手写”的两个简单的需求。

   也许,只有老罗那样非常追求完美的家伙能做出超过miui的rom了,于是,非常期待一个月后老罗的ROM。

    华为应当完善自己的rom,在易用性上投入本来具备优势的研发力量,打造好自己的rom,加上华为在运营商那里耕耘这么多年,没有理由做得比miui差 的。当然,在变化迅速的互联网行业,华为欠缺的是“迅速”,如何让“大象跳舞”?面对快速变化的而用户需求,如何快速满足,打造好自己的产品?

    四 核,小米2会慢慢的面对很多四核的竞争对手,例如后面会问世的LG nexus 4:高通骁龙S4四核1.5GHz处理器,搭配的内存高达 2GB base on android 4.2,价格1900人民币,是的,没错,只有1900元,想必小米2背后是阵阵凉气。"期货小米2"随着时间 的推移,不久其性价比就不会再那么优势明显了,强敌在后,小心了,2012的第四季度,好戏上演,精彩连连。


–EOF–

 

 

how to set hangcheck for linux

客户询问在10g rac实施的时候,hangcheck模块的参数设置,我转了篇文档给他,以供参考。

support.oracle.com上有篇文档写得很清楚了,可以参考:

 

In this Document

  Purpose
  Scope
  Details
  References

 

Applies to:

Oracle Server – Enterprise Edition – Version 9.2.0.8 to 11.1.0.7 [Release 9.2 to 11.1]
Linux x86
Linux x86-64

Purpose

Hangcheck_timer module is required to run a supported configuration in Oracle Real Application Clusters environments on Linux, with Oracle releases 9i, 10g, or 11gR1 RAC.  This note identifies and outlines the requirements needed to configure hangcheck-timer in an Oracle Enterprise Linux, Red Hat Linux, or SUSE Linux environment.
 

Note : Hangheck timer is not required starting with Oracle Clusterware 11gR2

//oracle clusterware 11gr2之后,hangcheck模块不在被需要了。

Scope

This article is provided for product management, system architects, and system administrators involved in deploying and configuring Oracle RAC 9i, 10g, or 11gR1 in a Linux environment. This document will also be useful to field engineers and consulting organizations to facilitate installations and configuration requirements of Oracle in a Linux RAC environment.

Details

Starting in release 9.2.0.2 and later, Oracle RAC environments required using a new I/O fencing model, named the hangcheck-timer module. This module was implemented to replace the Watchdog module, which provided similar fencing functionality. Hangcheck-timer was subsequently delivered as part of the standard kernel distribution for Linux kernel releases 2.4 and above. 

Hangcheck-timer should be loaded at boot time, and monitors the Linux kernel for long operating system hangs that could affect the reliability of a RAC node.  It runs in kernel mode and uses the Time Stamp Counter (TSC) to catch scheduling delays or node hangs.  This is done by setting a timer, then checking when the timer fires as to whether it was delayed by more than the allowed margin of error.  If the duration exceeds the allowed time of (hangcheck_tick + hangcheck_margin seconds), the machine is restarted.  Hangcheck-timer will not cause reboots to occur due to CPU starvation.

 Hangcheck-timer requires three configuration parameters:

  • hangcheck_tick – defines how often, in seconds, the hangcheck-timer checks the node for hangs. The default value is 60 seconds.
  • hangcheck_margin – defines how much margin is allowed, in seconds, between expected scheduling and real scheduling time. The default value is 180 seconds.
  • hangcheck_reboot – determines if the hangcheck-timer restarts the node if the kernel fails to respond within the sum of the hangcheck_tick and hangcheck_margin parameter values. If the value of hangcheck_reboot is equal to or greater than 1, then the hangcheck-timer module restarts the system. If the hangcheck_reboot parameter is set to zero, then the hangcheck-timer module will not reboot the node, even if a hang is detected.   The default value varies by kernel version.  In the 2.4 kernel, the default is 1.  In 2.6 kernels, the default is 0.
All hangcheck-timer default values should be explicitly overridden when loading the kernel module, based on the Oracle release as follows: 
  • 9i: Assuming the default setting of "oracm misscount" is set to 220 seconds
    hangcheck_tick=30 hangcheck_margin=180 hangcheck_reboot=1
  • 10g/11gR1: Assuming the default setting of "CSS misscount" is set to either 30 or 60 seconds:
    hangcheck_tick=1 hangcheck_margin=10 hangcheck_reboot=1

You must always ensure that the Cluster misscount setting is greater than the sum of the setting for hangcheck_tick + hangcheck_margin.

@  Unpublished information for Oracle Support Internal Use: 

When running Oracle Clusterware on Linux, hangcheck-timer should always be configured on each RAC cluster node, as the functionality of this module is required to provide I/O Fencing to ensure no stray writes will occur from an evicted node in a RAC cluster.  To verify if the hangcheck-timer module is running on a node execute as the root or oracle user:
 

# /sbin/lsmod | grep hangcheck

 

hangcheck-timer         2672   0


If the hangcheck-timer module is loaded (running) you will see output similar to above. When hangcheck-timer is not loaded no output is generated, and the command prompt is returned to the user.

In an Oracle Enterprise Linux, Red Hat 4/5, or SUSE 9/10 environment the hangcheck-timer module is loaded using the modprobe command:
 

# modprobe hangcheck-timer  hangcheck_tick=1 hangcheck_margin=10 hangcheck_reboot=1


In order to ensure the module is loaded at boot time, you should also place the same command in the appropriate local command execution directory (e.g. /etc/rc.d/rc.local, or /etc/init.d/boot.local).  In earlier releases, hangcheck-timer was loaded using insmod in place of modprobe. Consult your release specific documentation to determine which initialization method is required.

Hangcheck-timer will provide message logging to the system messages log when a failure is detected, and a node restart is initiated by the module:

  • When Hangcheck-timer reboots it may leave "Hangcheck: hangcheck is restarting the machine" message in /var/log/messages
  • If you see the following message in /var/log/messages:  "Hangcheck: hangcheck value past margin!" this means a reboot was required but was not performed, because hangcheck_reboot was not set to 1.  If this message is seen, you must reload the hangcheck module as described earlier in this note, with the hangcheck_reboot value set to 1.


Known Issues

  • Bug:6125546 which can prevent hangcheck-timer from rebooting in RHEL4 (fixed in 2.6.9.56 or RHEL4.6)

 

 

Database – RAC/Scalability Community
To discuss this topic further with Oracle experts and industry peers, we encourage you to review, join or start a discussion in the My Oracle Support Database – RAC/Scalability Community

References

BUG:6125546 – FASTER FENCING: EXECUTE SYSREQ B IMMEDIATELY
NOTE:232355.1 – Hangcheck Timer FAQ
@NOTE:259487.1 – Hangcheck-Timer Module Details
NOTE:559365.1 – Using Diagwait as a diagnostic to get more information for diagnosing Oracle Clusterware Node evictions
NOTE:567730.1 – Changes in Oracle Clusterware on Linux with the 10.2.0.4 Patchset

还有一篇 "best practice on oracle10gRac on linux"可以用作实施参考。

–EOF–

google adsense

在blog上设置了google adsense代码,是通过wordpress插件的模式进行的,但一直没有什么显现的效果。什么时候才能通过呢?也不知道进度,头疼啊,发了几封邮件给google一直没有人回复,国外的人工就是贵啊,什么事情都会有help guide。

那天在万寿路等mm下班,凯德那个大厦不错,有我喜欢的南京大排档、简单的咖啡馆、面包店。costa和巴黎贝甜紧紧挨着,相互补充,当然,如果能有startbuck就更好了。记得在伦敦的时候,满大街costa要多于starbuck,问了当地人反馈也是如此,伦敦人似乎对于老美那一套挺抵触的,一股傲慢,不,或者说骨气体现在很多方面。即使和欧盟,都有着很多的差异,古板的按照自己的节奏,根本不理会外界,其实这点挺好的。

 

some basic operations of LVM

 

1.change the partition id to LVM format(id=8e)
 
after "fdisk /dev/sdb",you can go through fdisk–>t—>8e to change the partition to linux LVM format
 
//to check the partition id information 
fdisk -l
 
Disk /dev/sda: 21.4 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        2458    19743853+  83  Linux
/dev/sda2            2459        2610     1220940   82  Linux swap / Solaris
 
Disk /dev/sdb: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         125     1004031    8e  Linux LVM
/dev/sdb2             126         261     1092420   8e  Linux LVM
 
Disk /dev/sdc: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1         125     1004031   8e  Linux LVM
/dev/sdc2             126         261     1092420   8e  Linux LVM
 
2.create pv
pvcreate /dev/sdb1 /dev/sdb2
Physical volume "/dev/sdb1" successfully created
Physical volume "/dev/sdb2" successfully created
 
//query the pv info
pvscan
PV /dev/sdb1                      lvm2 [980.50 MB]
PV /dev/sdb2                      lvm2 [1.04 GB]
 
3.create vg
[root@hundsun ~]# vgcreate testvg /dev/sdb1 /dev/sdb2
Volume group "testvg" successfully created
//query the vg information you just created
 
[root@hundsun ~]# vgscan
Reading all physical volumes.  This may take a while…
Found volume group "testvg" using metadata type lvm2
 
4.display the information
//you can see the pv information 
 
[root@hundsun ~]# pvdisplay
  "/dev/sdb1" is a new physical volume of "980.50 MB"
  — NEW Physical volume —
  PV Name               /dev/sdb1
  VG Name
  PV Size               980.50 MB
  Allocatable           NO
  PE Size (KByte)       0
  Total PE                  0
  Free PE                  0
  Allocated PE          0
  PV UUID               UuuhUL-TIJx-JT0w-1yqv-ugWx-aWaj-gExW6w
 
  "/dev/sdb2" is a new physical volume of "1.04 GB"
  — NEW Physical volume —
  PV Name               /dev/sdb2
  VG Name
  PV Size               1.04 GB
  Allocatable           NO
  PE Size (KByte)       0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               gi9xoW-qvv7-pSWP-ovcG-vjrt-NaI1-KwzyAa
 
5.display vg information
//display the information of vg
 
[root@hundsun ~]# vgdisplay
  — Volume group —
  VG Name               testvg
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  1
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                0
  Open LV               0
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               2.00 GB
  PE Size               4.00 MB
  Total PE              511
  Alloc PE / Size       0 / 0
  Free  PE / Size       511 / 2.00 GB
  VG UUID               M8rjyz-egoA-Oyda-u8Ou-nS4l-gkrf-1Jjen6
 
6.delete a vg
[root@hundsun ~]# vgremove testvg
Volume group "testvg" successfully removed
 
7.create LV
[root@hundsun mapper]# lvcreate -L 200M -n firstLV testvg
Logical volume "firstLV" created
 
//a device will be created at /dev/mapper/{vg_name-lv_name}
[root@hundsun mapper]# ls -l /dev/mapper/testvg-firstLV
brw-rw—- 1 root disk 253, 0 Oct 15 05:09 /dev/mapper/testvg-firstLV
 
//lvdisplay will display the all the lv information
[root@hundsun testvg]# lvdisplay
  — Logical volume —
  LV Name                /dev/testvg/firstLV
  VG Name                testvg
  LV UUID                vf8a9c-jHAC-She5-yzqh-rvod-osv7-vaSYfp
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                200.00 MB
  Current LE             50
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  – currently set to     256
  Block device           253:0
 
[root@hundsun testvg]# pwd
/dev/testvg
[root@hundsun testvg]# ls -lrt
total 0
lrwxrwxrwx 1 root root 26 Oct 15 05:09 firstLV -> /dev/mapper/testvg-firstLV
 
//you can see the /dev/mapper/lv was referenced by /dev/testvg/firstLV
 
//after create lv,use mkfs.ext3 to mk a ext3 filesystem and mount it 
 
8.create a ext3 filesystem using the lv just created and mount it
 
[root@hundsun testvg]# mkfs.ext3 /dev/testvg/firstLV
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
51200 inodes, 204800 blocks
10240 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=67371008
25 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729
 
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
 
This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
 
//mount it to a point
[root@hundsun /]# mount -t    ext3    /dev/testvg/firstLV /data
[root@hundsun /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              19G   12G  5.9G  67%   /
tmpfs                 507M     0  507M   0%      /dev/shm
none                  507M  104K  507M   1%    /var/lib/xenstored
/dev/mapper/testvg-firstLV        194M  5.6M  179M   4% /data
 
9.extend the lv and the mount point filesystem using lvextend
//extend the lv using lvextend,but the mount point of filesystem can not sync the change untill
//you resize2fs -p /dev/testvg/{lvname}
//before you resize2fs the filesyetem,the /data have 200M and the +100M had not take place
 
[root@hundsun /]# lvextend -L +100M /dev/testvg/firstLV
  Extending logical volume firstLV to 300.00 MB
  Logical volume firstLV successfully resized
[root@hundsun /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              19G   12G  5.8G  67% /
tmpfs                 507M     0  507M   0% /dev/shm
none                  507M  104K  507M   1% /var/lib/xenstored
/dev/mapper/testvg-firstLV
                      194M  5.6M  179M   4% /data
 
//resize the filesystem to call the change of lv
[root@hundsun /]# resize2fs -p /dev/testvg/firstLV
resize2fs 1.39 (29-May-2006)
Filesystem at /dev/testvg/firstLV is mounted on /data; on-line resizing required
Performing an on-line resize of /dev/testvg/firstLV to 307200 (1k) blocks.
The filesystem on /dev/testvg/firstLV is now 307200 blocks long.
 
[root@hundsun /]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              19G   12G  5.8G  67% /
tmpfs                 507M     0  507M   0% /dev/shm
none                  507M  104K  507M   1% /var/lib/xenstored
/dev/mapper/testvg-firstLV
                      291M  6.1M  270M   3% /data
 
–EOF–

 

v$session and logon_time

the customer has a app based on a rac with load balance on,someone reboot the application server(weblogic) the services which on db side was not in the correct order.

How to find it ? How to find the exactly time the reboot operation was made?

OK, checkt out the column LOGON_TIME in v$session,it do helps a lot!

 

SQL> select username,program,logon_time from v$session;
 
USERNAME                       PROGRAM                                          LOGON_TIM
—————————— ————————————————     ———
                               oracle@node1 (q001)                                   30-SEP-12
                               oracle@node1 (q000)                                   30-SEP-12
                               oracle@node1 (QMNC)                                30-SEP-12
SYS                            racgimon@node1 (TNS V1-V3)               30-SEP-12
SYS                            racgimon@node1 (TNS V1-V3)                30-SEP-12
                          oracle@node1 (J000)                          10-OCT-12
SYS                      sqlplus@node1 (TNS V1-V3)                  10-OCT-12
                               oracle@node1 (LCK0)                                   30-SEP-12
                               oracle@node1 (MMNL)                                  30-SEP-12
                               oracle@node1 (CKPT)                                  30-SEP-12
                               oracle@node1 (MMON)                                30-SEP-12
 
USERNAME                       PROGRAM                                          LOGON_TIM
—————————— ———————————————— ———
                               oracle@node1 (CJQ0)                              30-SEP-12
                               oracle@node1 (RECO)                              30-SEP-12
                               oracle@node1 (SMON)                              30-SEP-12
                               oracle@node1 (LGWR)                              30-SEP-12
                               oracle@node1 (DBW0)                              30-SEP-12
                               oracle@node1 (MMAN)                              30-SEP-12
                               oracle@node1 (LMS0)                              30-SEP-12
                               oracle@node1 (DIAG)                              30-SEP-12
                               oracle@node1 (LMD0)                              30-SEP-12
                               oracle@node1 (LMON)                              30-SEP-12
                               oracle@node1 (PSP0)                              30-SEP-12
 
USERNAME                       PROGRAM                                          LOGON_TIM
—————————— ———————————————— ———
                               oracle@node1 (PMON)                              30-SEP-12
 
//logon_time will display the exactly time the session log on
 
–EOF–
 

ORA-00600:[kole_t2u] [34]

 

The customer reports the error message:
————————————————–
ORA-00600:[kole_t2u], [34], [], [], [], [], [], []
————————————————–
the envrionment of customer are: oracle 10201 single instance+win2k3 r2 x64.
 
there are some clue in trace file:
 
#######################################################################
Dump file e:oracleproduct10.2.0admincdwbdumpcdw_m000_14920.trc
Wed Oct 03 16:00:59 2012
ORACLE V10.2.0.1.0 – 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 – 64bit Production
With the Partitioning, OLAP and Data Mining options
Windows Server 2003 Version V5.2 Service Pack 2
CPU                 : 8 – type 8664, 2 Physical Cores
Process Affinity    : 0x0000000000000000
Memory (Avail/Total): Ph:24113M/65530M, Ph+PgF:33540M/74161M
Instance name: cdw
 
Redo thread mounted by this instance: 1
 
Oracle process number: 59
 
Windows thread id: 14920, image: ORACLE.EXE (m000)
 
 
*** ACTION NAME:(Auto-Flush Slave Action) 2012-10-03 16:00:59.425
*** MODULE NAME:(MMON_SLAVE) 2012-10-03 16:00:59.425
*** SERVICE NAME:(SYS$BACKGROUND) 2012-10-03 16:00:59.425
*** SESSION ID:(967.21972) 2012-10-03 16:00:59.425
*** 2012-10-03 16:00:59.425
ksedmp: internal or fatal error
ORA-00600: internal error: [kole_t2u], [34], [], [], [], [], [], []
Current SQL statement for this session:
INSERT INTO wrh$_sqltext    (sql_id, dbid, sql_text,     command_type, snap_id, ref_count)  SELECT    sqlid_kewrstx, :dbid, sqlfulltext_kewrstx,    cmdtype_kewrstx, :lah_snap_id, 0 ref_count  FROM x$kewrtsqltext
—– Call Stack Trace —–
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
——————– ——– ——————– —————————-
ksedst+55            CALL???  ksedst1+573          94000000000 00001D688
                                                   02CC70AB0 00001E5F0
ksedmp+663           CALL???  ksedst+55            003A750A8 000000000 02CC6F528
                                                   000000000
ksfdmp+19            CALL???  ksedmp+663           000000003 05203F9D0 05203F9D0
                                                   003A975A0
kgerinv+158          CALL???  ksfdmp+19            000000000 000000000 000000000
                                                   000000000
kgesinv+33           CALL???  kgerinv+158          000000000 028C96FD8 000000001
                                                   0000007D0
kgesin+47            CALL???  kgesinv+33           0293FD3B0 0000003E8 027130110
                                                   02CC70EE8
kole_t2u+663         CALL???  kgesin+47            027136A30 05203F9D0
                                                   1FC400000000 000000001
koklwrite+1758       CALL???  kole_t2u+663         02AC80810 02CC70F48 0000003A1
                                                   0000002EA
koklc_write+217      CALL???  koklwrite+1758       02AC80810 000000000 0000003A1
                                                   02CC71FA0
kolaslWrite+798      CALL???  koklc_write+217      000000000 000000000 000000000
                                                   05203F9D0
kolaWrite+332        CALL???  kolaslWrite+798      027136A30 05203F9D0
                                                   FA000000000 00507CC57
koklwrite+2752       CALL???  kolaWrite+332        028C89478 000000000 0000203A1
                                                   0000002EA
qerfxCreateTempClob  CALL???  koklwrite+2752       028C89478 000000000 0000203A1
#####################################################################################
 
key information:
———————————————————————————————
INSERT INTO wrh$_sqltext (sql_id, dbid, sql_text,command_type, snap_id, ref_count) 
SELECT sqlid_kewrstx,:dbid,sqlfulltext_kewrstx,cmdtype_kewrstx, :lah_snap_id, 0 ref_count FROM x$kewrtsqltext
———————————————————————————————-   
MMON slave try to insert into wrh$_sqltext and trigger the error message,mmon is the background process.
so it seems there are do nothing with the application but only some awr/ash job done by mmon process.
 
Yes,indeed,you met the bug and the it's the bug 5017909 following as below:
——————————————————————————————————-
 Incorrect CLOB splits
 
This type of problem is the hardest to detect, and usually requires extensive debugging before the problem can be located, before going down this path it is usually preferable to go through the list of known issues and apply any known patches to rule out any known problems. 
The background of this type of error comes from the fact that CLOB data is sometimes split into more manageable chunks of data of a certain length. It this split is made after a certain number of bytes (for example 1000, or 4000, etc etc), then it could happen that the split happens in the middle of a multibyte codepoint. This then leaves the previous chunk with a incomplete codepoint at the end of the data, and this error can be expected. If this type of problem occurs, it is therefore due to a bug in the way CLOB data is split into chunks. Rather than making the split based on bytes it should always be made based on full characters.
 
Bug 5017909 – fixed in 10.2.0.4 (and higher 10.2 patchsets) and 11.1 (and higher)
Due to a bug in the "cut" in the data as described above, this bug can cause v$sqlarea.sql_fulltext and v$sql.sql_fulltext to contain sql statements in whichinvalid multibyte codepoints are used. These can subsequently lead to a variety of issues, like:
 
(1)SQL Tuning advisor failing with ORA-904, ORA-911 and/or ORA-1740, and ORA-600 [kole_t2u], [34] can be found in the background.
(2)The MMON process periodically running into ORA-600 [kole_t2u], [34] errors
(3)Background processes (like MMON) running into this error when inserting into history tables like wrh$_sqltext
(4)ORA-600 [kole_t2u], [34] errors when using DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
Many of these issues have been individually raised as bugs in the past, but in most cases they go back to the bad data introduced by bug 5017909.Individual patches for some platforms are available on top of 10.1.0.5, 10.2.0.2 and 10.2.0.3.
———————————————————————————————————-
 
It's quite the same situation as (2),(3).
 
you can describe the wrh$_sqltext and x$kewrtsqltext,there is the CLOB type column which may trigger the bug as "incorrect clob split"
 
SQL> desc wrh$_sqltext;
 Name                                                              Null?    Type
 —————————————————————– ——– ——————————————–
 SNAP_ID                                                                              NUMBER
 DBID                                                              NOT NULL   NUMBER
 SQL_ID                                                            NOT NULL VARCHAR2(13)
 SQL_TEXT                                                                           CLOB
 COMMAND_TYPE                                                               NUMBER
 REF_COUNT                                                                  NUMBER
 
SQL> desc x$kewrtsqltext;
 Name                                                              Null?    Type
 —————————————————————– ——– ——————————————–
 ADDR                                                                                        RAW(8)
 INDX                                                                                    NUMBER
 INST_ID                                                                                  NUMBER
 SQLID_KEWRSTX                                                              VARCHAR2(13)
 SQLIDNUM_KEWRSTX                                                           NUMBER
 CMDTYPE_KEWRSTX                                                            NUMBER
 SQLFULLTEXT_KEWRSTX                                                     CLOB
 
solution:
try to opath the patch or update to oracle 10204.
 
References:
Bug 5017909 – V$SQL / V$SQLAREA.SQL_FULLTEXT corrupt for multibyte [ID 5017909.8]
ORA-600 [kole_t2u], [34] – description, bugs, and reasons [ID 734474.1]