Skip to content

最近买房,忙着打了一堆证明~~所以blog短暂没有更新.

这个错误是昨天一个客户把兄弟单位的错误转过来的,这里感谢客户对我的信任.由于是生产,当时因为丢失了11w条数据,后来我远程给恢复完成后,客户工程师在调试过程中遭遇12537,该错误伴随Linux Error 29,当时电话交流时候初步判断网络出现回路,而经过一翻查验,问题确实出在Oracle网络上.

首先查证Oracle监听报错如下:

oracle@localhost ~]$ lsnrctl start

LSNRCTL for Linux: Version 11.2.0.1.0 - Production on 03-SEP-2014 17:09:56 Copyright (c) 1991, 2009, Oracle. All rights reserved.

Starting /opt/ora11g/product/11.2.0/dbhome_1/bin/tnslsnr: please wait...

TNS-12537: TNS:connection closed
TNS-12560: TNS:protocol adapter error
TNS-00507: Connection closed
Linux Error: 29: Illegal seek

Oracle DB的alert log报错如下:

Wed Sep 03 17:08:01 2014
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x2F518C2, nttaddr2bnd()+2158] [flags: 0x0, count: 1]
Errors in file /opt/ora11g/diag/rdbms/jcls/JCLS/trace/JCLS_d000_7563.trc  (incident=9683):
ORA-07445: exception encountered: core dump [nttaddr2bnd()+2158] [SIGSEGV] [ADDR:0x0] [PC:0x2F518C2] [Address not mapped to object] []

经过以上的信息,作为trouble shooting的需求是应该对trace进行进一步分析的,但从排障以及及时恢复生产的角度,客户的紧迫度已到了一个比较崩神经的地步了,所以我还是从个人判断的角度检查了网路可能出现回路的几个地方查验,首先就是ip的设置如下:

hosts文件内容

oracle@localhost ~]$ 
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
8.0.1.152   localhost

network内容:

oracle@localhost ~]$ 
NETWORKING=yes
HOSTNAME=localhost

按照自己的思路才检查就发现了问题所在了,主机名localhost冲突,而上面告警日志的07445的内存错误也初步怀疑是和该网络回路有关.

使用ping localhost时候会发现返回数据包的ip地址为127.0.0.1,这是这个错误的问题错在,而真实的情况是应该由8.0.1.152ip返回数据包,这里主要为hostname 设置出错.

[oracle@localhost ~]$ ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.061 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.031 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.030 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.030 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.040 ms
64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.032 ms
64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.030 ms

这里的处理办法为将8.0.1.152的ip对于的hostname改为对于的hostname(比如oradbhost01),然后更改network文件下的hostname,并通过命令hostname更新内存中的hostname,重启网络和修改监听的hostname并重启监听,问题可以得到解决.

TNS-12537/Linux Error: 29: Illegal seek

Oracle数据库版本支持结束时间表以及数据库版本发行时间表

数据库版本支持时间表:

 
大版本
(点击查看详情)
当前补丁集 下一补丁集 标准服务结束日期 扩展服务结束日期 注释
12.1.0.X 12.1.0.2 - - 基版本为 12.1.0.1。
11.2.0.X 11.2.0.4 2015年1月 2018年1月
扩展服务第一年(2015年1月到2016年1月)的费用取消
基版本为 11.2.0.1。
11.2.0.4 为 11.2 的最终补丁集
11.2 每一个补丁集都是完整安装程序包 – 详见 Note:1189783.1
11.2.0.1 在2011年9月13日后停止提供新的补丁
11.2.0.2 在2013年10月31日后停止提供新的补丁
11.2.0.3 在2015年8月27日后停止提供新的补丁 – 详见 Note:742060.1
11.1.0.X 11.1.0.7 2012年8月 2015年8月 基版本为 11.1.0.6。
11.1.0.7 是 11.1 的最终补丁集
10.2.0.X 10.2.0.5 2010年7月 2013年7月
自2013年8月至2015年7月提供有限的扩展服务。详见 “Oracle Software Technical Support Policies”

Extended Support 部分.

10.2.0.5 是 10.2 的最终补丁集。免费的扩展服务在2011年7月31日结束。
在此之后只有有限的平台会继续提供补丁

– 特定平台结束日期详见Note:742060.1

10.1.0.X 10.1.0.5 2009年1月 2012年1月 10.1.0.5 是 10.1 的最终补丁集。
10.1 的扩展服务已经结束 – 详见 Note:761713.1
9.2.0.X 9.2.0.8 2007年7月 2010年7月
自2010年7月至2012年7月提供有限的扩展服务。
详见这里
9.2.0.8 是 9.2 的最终补丁集。
免费的扩展服务在2008年7月31日结束。 详见 Note:392222.1

 

数据库版本停止更新时间表:

版本 结束日期 特例*
11.2.0.4 2018年1月31日
HP-UX Itanium: 停止提供补丁日期为2020年12月。 从2018年2月1日起只提供严重程度为1级的修复(不会再发布新的 PSU 和 CPU) 。
11.2.0.3 2015年8月27日
11.2.0.2 2013年10月31日 结束日期比正常晚
11.2.0.1 2011年9月13日
对于 Exadata 结束日期为2012年4月30日
11.1.0.7 2015年8月31日7
HP-UX Itanium – 结束日期为2015年12月。从2015年9月1日起只提供严重程度为1级的修复(不会再发布新的 PSU 和 CPU)。
11.1.0.6 2009年9月18日
10.2.0.5 2015年7月31日7
所有平台  – 标准 Extended Support 在2013年7月31日结束。在2013年8月至2015年7月间,提供有限支持的 Extended Support,日起只提供严重程度为1级的修复(不会再发布新的 PSU 和 CPU)。详见Oracle Software Technical Support Policies.
HP-UX, Linux, 和 Windows Itanium – 结束日期为2015年12月。从2013年8月1日起只提供严重程度为1级的修复(不会再发布新的 PSU 和CPU)。
10.2.0.4 2011年7月31日5
10.2.0.3 2009年2月22日
IBM Linux on Power
2009年4月9日
IBM Linux on System z
2009年5月16日
Microsoft Windows Itanium (64-bit)
2009年5月2日
HP Tru64 UNIX
2009年5月20日
10.1.0.4 2007年1月30日

 

快速检测多路径对应的DISK的脚本

该脚本为检测rac中disk多路径的情况,在添加磁盘进asm时候要格外小心,需要反复验证多路径对应磁盘,加错盘的情况时有发生,这脚本可以帮助DBA在添加磁盘时候判断对应lun的多路径的情况。

如果aix需要把sd改成rlv,把多路径的命令更换。

脚本为:

#!/bin/ksh
for disk in `ls /dev/sd*`
do
disk_short=`basename $disk`
wwid=`scsi_id -g -s /block/$disk_short`
if [ "$wwid" != "" ]
then
  echo -e "Disk:" $disk_short "\tWWID:" $wwid
fi
done

结果为:

 

Disk: sda       WWID: 3600601602b702d006218b7de8130e111
Disk: sdaa      WWID: 3600601602b702d000652b695c648e111
Disk: sdab      WWID: 3600601602b702d000752b695c648e111
Disk: sdac      WWID: 3600601602b702d007f2a73fbc648e111
Disk: sdad      WWID: 3600601602b702d007e2a73fbc648e111
Disk: sdae      WWID: 3600601602b702d006218b7de8130e111
Disk: sdaf      WWID: 3600601602b702d0036d7cf191241e111
Disk: sdag      WWID: 3600601602b702d0037d7cf191241e111
Disk: sdah      WWID: 3600601602b702d0038d7cf191241e111
#!/bin/bash -x
ORACLEASM=/etc/init.d/oracleasm
echo"ASM Diskgroup Mapping luns"
echo"----------------------------------------------------"
for f in `$ORACLEASMlistdisks`
do
dp=`$ORACLEASM querydisk -p  $f |head-2| grep /dev | awk-F: '{print $1}'`
echo"$f: $dp"
done

Oracle官方有使用KFED更为便捷的脚本,该文档介绍如下:

 

That information can be obtained with the following shell script:

#!/bin/bash
for asmlibdisk in `ls /dev/oracleasm/disks/*`
do
echo “ASMLIB disk name: $asmlibdisk”
asmdisk=`kfed read $asmlibdisk | grep dskname | tr -s ‘ ‘| cut -f2 -d’ ‘`
echo “ASM disk name: $asmdisk”
majorminor=`ls -l $asmlibdisk | tr -s ‘ ‘ | cut -f5,6 -d’ ‘`
device=`ls -l /dev | tr -s ‘ ‘ | grep -w “$majorminor” | cut -f10 -d’ ‘`
echo “Device path: /dev/$device”
done

The script can be run as OS user that owns ASM or Grid Infrastructure home (oracle/grid), i.e. it does not need to be run as privileged user. The only requirement it that kfed binary exists and that it is in the PATH.

If an ASMLIB disk was already deleted, it will not show up in /dev/oracleasm/disks. We can check for devices that are (or were) associated with ASM with the following shell script:

#!/bin/bash
for device in `ls /dev/sd*`
do
asmdisk=`kfed read $device | grep ORCL | tr -s ‘ ‘ | cut -f2 -d’ ‘ | cut -c1-4`
if [ "$asmdisk" = "ORCL" ]
then
echo “Disk device $device may be an ASM disk”
fi
done

The second scripts takes a peek at sd devices in /dev, so in addition to the requirement for the kfed binary to be in the PATH, it also needs to be run as privileged user. Of course we can look at /dev/dm*, /dev/mapper, etc or all devices in /dev, although that may not be a good idea.

The kfed binary should be available in RDBMS home (prior to version 11.2) and in the Grid Infrastructure home (in version 11.2 and later). If the binary is not there, it can be built as follows:

cd $ORACLE_HOME/rdbms/lib
make -f ins* ikfed

Where ORACLE_HOME is the RDBMS home (prior to version 11.2) and the Grid Infrastructure home in version 11.2 and later.

The same can be achieved without kfed with a script like this:

#!/bin/bash
for device in `ls /dev/sd*`
do
asmdisk=`od -c $device | head | grep 0000040 | tr -d ‘ ‘ | cut -c8-11`
if [ "$asmdisk" = "ORCL" ]
then
echo “Disk device $device may be an ASM disk”
fi
done
快速列出ASM DISK和OS DISK DEV设备对应的脚本

遭遇11g R2 DRM bug:gcs resource directory to be unfrozen

用户的环境是aix版本的11.2.0.2集群,数据库实例hang,看到gcs resource,第一时间就反应是drm和lmon,结合hang前的awr也发现等待事件集中在gcs resource directory to be unfrozen,这个时候一般集中检查和gcs相关的信息:数据库告警日志,lmon trace,lms trace。整个过程是DRM触发了,但是并没有切换资源,导致实例hang住,根本原因是过大的buffer cache导致,根据lmon的信息和官方bug 12879027吻合,打上11.2.0.2.7的psu(DB和GI),后续继续观察

LMON进程trace可见如下:

*** 2014-08-14 21:13:51.87
 CGS recovery timeout = 85 sec
Begin DRM(231) (swin 1)
* drm quiesce

*** 2014-08-14 21:17:06.782
* Request pseudo reconfig due to drm quiesce hang
2012-07-14 21:17:03.752735 : kjfspseudorcfg: requested with reason 5(DRM Quiesce step stall)

*** 2014-08-14 21:17:04.911
kjxgmrcfg: Reconfiguration started, type 6
CGS/IMR TIMEOUTS:
 CSS recovery timeout = 31 sec (Total CSS waittime = 65)
 IMR Reconfig timeout = 75 sec
 CGS rcfg timeout = 85 sec
kjxgmcs: Setting state to 70 0.
 - AWR Top waits are "gcs resource directory to be unfrozen" & "gc remaster"

官方文档:

Bug 12879027  LMON gets stuck in DRM quiesce causing intermittent pseudo reconfiguration

 This note gives a brief overview of bug 12879027. 
 The content was last updated on: 15-OCT-2013
 Click here for details of each of the sections below.

Affects:

Product (Component) Oracle Server (Rdbms)
Range of versions believed to be affected Versions BELOW 12.1
Versions confirmed as being affected
Platforms affected Generic (all / most platforms affected)

Fixed:

The fix for 12879027 is first included in

Interim patches may be available for earlier versions – click here to check.

Symptoms:

Related To:

Description

This bug is only relevant when using Real Application Clusters (RAC)

LMON process can get stuck in the DRM quiesce step triggering 
pseudo reconfiguration eventually.
 
Rediscovery Notes:
 DRM quiesce step hangs and triggers pseudoreconfiguration especially
 in single window DRM and when the buffer cache is very large.
 
Workaround
 None
 
Getting a Fix
 Use one of the "Fixed" versions listed above
 (for Patch Sets / bundles use the latest version available as
  contents are cumulative - the "Fixed" version listed above is
  the first version where the fix is included)
 or
 You can check for existing interim patches here: Patch:12879027
 

Please note: The above is a summary description only. Actual symptoms can vary. Matching to any symptoms here does not confirm that you are encountering this problem. For questions about this bug please consult Oracle Support.

References

Bug:12879027 (This link will only work for PUBLISHED bugs)
Note:245840.1 Information on the sections in this article