今天准备连接一台测试服务器的数据库,但是迟迟未能连上。直接登录主机,用sqlplus连,一直没反应。杀掉进程也无法连接sqlplus。
实在搞不清楚为什么,抱着试试看的心情搜索了一下,却发现这是普遍现象。
下面是一篇文章:
http://www.2cto.com/database/201107/96741.html
根据文中所说的几个条件,我查了一下本地的情况,服务器启动刚刚199天(uptime):
[oracle@DB ~]$ uptime
10:35:46 up 199 days, 53 min, 3 users, load average: 0.05, 0.05, 0.31
文中说从198天起刚好会出现该问题。
数据库版本是10.2.0.1,又吻合。
然后用strace命令跟踪了一下:
fcntl64(6, F_SETFD, FD_CLOEXEC) = 0
lseek(6, 0, SEEK_SET) = 0
read(6, "\25\23\"\1\23\3\t\t\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 256) = 256
lseek(6, 512, SEEK_SET) = 512
read(6, "\337y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 512) = 512
lseek(6, 1024, SEEK_SET) = 1024
read(6, "\25\7'\0072\7>\7j\7\276\17$'\6K5S\24TfT\307T(VsV\222V\6W"..., 86) = 86
times(NULL) = 2148613639
times(NULL) = 2148613639
times(NULL) = 2148613639
times(NULL) = 2148613639
times(NULL) = 2148613639
times(NULL) = 2148613639
times(NULL) = 2148613639
基本确定是bug引起:
事实上只要 Linux
x86主机运行天数是是24.8的倍数都有可能引发该bug,因为time()函数值为null,造成无限死循环,从而耗尽cpu。
解决办法有三种:
1、重启服务器(治标不治本);
2、数据库版本升级(比较耗时);
3、打patch;
以下是patch过程:
[oracle@DB packages]$ unzip p4612267_10201_LINUX32bit_198days.zip
Archive: p4612267_10201_LINUX32bit_198days.zip
creating: 4612267/
creating: 4612267/files/
creating: 4612267/files/lib/
creating: 4612267/files/lib/libcore10.a/
inflating: 4612267/files/lib/libcore10.a/sltrg.o
creating: 4612267/etc/
creating: 4612267/etc/config/
inflating: 4612267/etc/config/inventory
inflating: 4612267/etc/config/actions
creating: 4612267/etc/xml/
inflating: 4612267/etc/xml/GenericActions.xml
inflating: 4612267/etc/xml/ShiphomeDirectoryStructure.xml
inflating: 4612267/README.txt
[oracle@DB packages]$ ls
4612267 bbed cx_Oracle-5.1.2 p4612267_10201_LINUX32bit_198days.zip p4612267_10201_Linux-x86-64.zip
[oracle@DB packages]$ cd 4612267/
[oracle@DB 4612267]$ ls
etc files README.txt
[oracle@DB 4612267]$ $ORACLE_HOME/OPatch/opatch apply
Invoking OPatch 10.2.0.1.0
Oracle interim Patch Installer version 10.2.0.1.0
Copyright (c) 2005, Oracle Corporation. All rights reserved..
Oracle Home : /home/oracle/db/product/10.2.0/db_1
Central Inventory : /home/oracle/oraInventory
from : /home/oracle/db/product/10.2.0/db_1/oraInst.loc
OPatch version : 10.2.0.1.0
OUI version : 10.2.0.1.0
OUI location : /home/oracle/db/product/10.2.0/db_1/oui
Log file location : /home/oracle/db/product/10.2.0/db_1/cfgtoollogs/opatch/opatch-2017_Feb_16_10-52-33-CST_Thu.log
ApplySession applying interim patch '4612267' to OH '/home/oracle/db/product/10.2.0/db_1'
Invoking fuser to check for active processes.
Invoking fuser on "/home/oracle/db/product/10.2.0/db_1/bin/oracle"
OPatch detected non-cluster Oracle Home from the inventory and will patch the local system only.
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/home/oracle/db/product/10.2.0/db_1')
Is the local system ready for patching?
Do you want to proceed? [y|n]
y
User Responded with: Y
Backing up files and inventory (not for auto-rollback) for the Oracle Home
Backing up files affected by the patch '4612267' for restore. This might take a while...
Backing up files affected by the patch '4612267' for rollback. This might take a while...
Patching component oracle.oracore.rsf, 10.2.0.1.0...
Updating archive file "/home/oracle/db/product/10.2.0/db_1/lib/libcore10.a" with "lib/libcore10.a/sltrg.o"
Patching component oracle.rdbms, 10.2.0.1.0...
Updating archive file "/home/oracle/db/product/10.2.0/db_1/lib/libcore10.a" with "lib/libcore10.a/sltrg.o"
Running make for target client_sharedlib
Running make for target client_sharedlib
Running make for target ioracle
ApplySession adding interim patch '4612267' to inventory
The local system has been patched and can be restarted.
OPatch succeeded.
[oracle@DB 4612267]$
然后启动sqlplus,正常启动,问题解决。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12932950/viewspace-2133633/,如需转载,请注明出处,否则将追究法律责任。