分类目录归档:Oracle

Oracle RAC导致实例逐出的五大问题

这篇文档在MOS上看到被翻译成了中文,觉得比较实用,可适用于10.2.0.1至11.2.0.3版本的RAC,因此贴出来方便别人查阅,后期会尽量多贴一些MOS上的中文技术资料,希望可以帮到别人,同时也算是自己学习积累的过程。

问题 1:警报日志显示 ora-29740 是实例崩溃/驱逐的原因
症状:
实例崩溃,警报日志显示“ORA-29740:evicted by member …(被成员…驱逐)”错误。
可能的原因:
一个实例将另一个实例从 RAC 数据库驱逐时,出现了 ORA-29740 错误。被驱逐的实例会在警报日志中报告 ora-29740 错误。
此问题的部分原因是集群中的通信错误、向控制文件发送“心跳”失败以及其它原因。
检查所有实例的 lmon 跟踪文件,这对确定实例驱逐的原因代码而言非常重要。查找包含“kjxgrrcfgchk:Initiating reconfig”的行。
这将提供一个原因代码,如“kjxgrrcfgchk:Initiating reconfig, reason 3”。实例驱逐时发生的大多数 ora-29740 错误是由于原因 3(“通信故障”) 造成的。
Document 219361.1 (Troubleshooting ORA-29740 in a RAC Environment) 介绍了以下几种可能造成原因 3的 ora-29740 错误原因:
a) 网络问题。
b) 资源耗尽(CPU、I/O 等)
c) 严重的数据库争用。
d) Oracle bug。
解决方案:
1) 检查网络,确保无网络错误,如 UDP 错误或 IP 数据包丢失或故障错误。
2) 检查网络配置,确保所有节点上的所有网络配置均设置正确。
   例如,所有节点上 MTU 的大小必须相同,并且如果使用巨帧,交换机也能够支持大小为 9000 的 MTU。
3) 检查服务器是否存在 CPU 负载问题或可用内存不足。
4) 检查数据库在实例驱逐之前是否正处于挂起状态或存在严重的性能问题。
5) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在特定平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
6) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助。

问题 2:警报日志在实例崩溃或驱逐前显示“ipc send timeout”错误
症状:
实例驱逐时,警报日志显示许多“IPC send timeout”错误。此消息通常伴随数据库性能问题。
可能的原因:
在 RAC 中,数据库进程,例如 lmon、lmd 和 lms 会不断地和其他实例的进程通信。lmd0 进程负责管理 enqueue,而 lms 进程负责管理数据块资源并传输数据块以支持 Cache Fusion。如果这些进程中的一个或多个受阻、死循环或异常繁忙,则可能导致“IPC send timeout(IPC 发送超时)”错误。
lmon、lms 和 lmd 进程报告“IPC send timeout”错误的另一个原因是网络问题或服务器资源(CPU 和内存)问题。这些进程可能无法获得 CPU 运行调度或这些进程发送的网络数据包丢失。
涉及 lmon、lmd 和 lms 进程的通信问题导致实例驱逐。被驱逐实例的警报日志显示的信息类似于如下示例
IPC Send timeout detected.Sender: ospid 1519
Receiver: inst 8 binc 997466802 ospid 23309
如果某实例被驱逐,警报日志中的“IPC Send timeout detected(检测到 IPC 发送超时)”通常伴随着其它问题,如 ora-29740 和“Waiting for clusterware split-brain resolution(等待集群件“脑裂”解决方案)”
解决方案:
此处的解决方案与问题 1 相似。
1) 检查网络,确保无网络错误,如 UDP 错误或 IP 数据包丢失或故障错误。
2) 检查网络配置,确保所有节点上的所有网络配置均设置正确。
   例如,所有节点上 MTU 的大小必须相同,并且如果使用巨帧,交换机也能够支持大小为 9000 的 MTU。
3) 检查服务器是否存在 CPU 负载问题或可用内存不足。
4) 检查数据库在实例驱逐之前是否正处于挂起状态或存在严重的性能问题。
5) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在特定平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
6) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助。

问题 3:在实例崩溃或驱逐前,问题实例处于挂起状态
症状:
在实例崩溃/驱逐前,该实例或数据库正处于挂起状态。当然,也可能是节点挂起。
可能的原因:
由于 lmon、lmd 和 lms 等不同进程与其它实例上对应的进程通信,因此当实例和数据库挂起时,这些进程可能正在等待某个资源,如 latch、enqueue 或数据块。这些等待中的进程得不到网络响应,或无法通过网络向远程实例发送任何通信。因此,其它实例将驱逐问题实例。
在执行驱逐其他实例动作的实例警报日志中,您可能会看到与以下消息类似的消息:
Remote instance kill is issued [112:1]:8
或者
Evicting instance 2 from cluster
解决方案:
1) 查找数据库或实例挂起的原因。对数据库或实例挂起问题进行故障排除时,获取全局 systemstate 转储和全局hang analyze 转储是关键。如果无法获取全局 systemstate 转储,则应获取在大致相同时间所有实例的本地 systemstate 转储。
2) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在某些平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
3) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助。

问题 4:在一个或多个实例崩溃或驱逐前,警报日志显示“Waiting for clusterware split-brain resolution(等待集群“脑裂”解决方案)”
症状:
在一个或多个实例崩溃之前,警报日志显示“Waiting for clusterware split-brain resolution(等待集群件“脑裂”解决方案)”。这通常伴随着“Evicting instance n from cluster(从集群驱逐实例 n)”,其中 n 是指被驱逐的实例编号。
可能的原因
lmon 进程向远程实例发送一个网络 ping,如果远程实例上的 lmon 进程不响应,则出现实例级别的“脑裂”。因此,查找 lmon 不能相互通信的原因对解决此问题而言非常重要。
常见原因有:
1) 实例级别的“脑裂”通常由网络问题导致,因此检查网络设置和连接非常重要。但是,因为如果网络已关闭,集群件 (CRS) 就会出现故障,所以只要 CRS 和数据库使用同一网络,则网络不太可能会关闭。  
2) 服务器非常繁忙和/或可用内存量低(频繁的交换和内存扫描),将阻止 lmon 进程被调度。
3) 数据库或实例正处于挂起状态,并且 lmon 进程受阻。
4) Oracle bug
以上原因与问题 1的原因相似(警报日志显示 ora-29740 是实例崩溃/驱逐的原因)。
解决方案:
此处的解决方案与问题 1 相似。
1) 检查网络,确保无网络错误,如 UDP 错误或 IP 数据包丢失或故障错误。
2) 检查网络配置,确保所有节点上的所有网络配置均设置正确。
   例如,所有节点上 MTU 的大小必须相同,并且如果使用巨帧,交换机也能够支持大小为 9000 的 MTU。
3) 检查服务器是否存在 CPU 负载问题或可用内存不足。
4) 检查数据库在实例驱逐之前是否正处于挂起状态或存在严重的性能问题。
5) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在特定平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
6) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助。

问题 5:另一个实例尝试驱逐问题实例,但由于一些原因未能成功驱逐,最终CRS会终止该问题实例。
症状:
一个实例驱逐其他实例时,在问题实例自己关闭之前,所有实例都处于等待状态,但是如果问题实例因为某些原因不能终止自己,发起驱逐的实例将发出 Member Kill 请求。Member Kill 请求会要求 CRS 终止问题实例。此功能适用于 11.1 及更高版本。
可能的原因:
要求 CRS 终止问题实例的实例警报日志显示
Remote instance kill is issued [112:1]:8
例如,以上消息表示终止实例 8 的 Member Kill 请求已发送至 CRS。
问题实例由于某种原因正处于挂起状态且无响应。这可能是由于节点存在 CPU 和内存问题,并且问题实例的进程无法获得 CPU 运行调度。
第二个常见原因是数据库资源争用严重,导致问题实例无法完成远程实例驱逐该实例的请求。
另一个原因可能是由于实例尝试中止自己时,一个或多个进程“幸存”了下来。除非实例的所有进程全部终止,否则 CRS 不认为该实例已终止,而且不会通知其它实例该问题实例已经被终止。这种情况下的一个常见问题是一个或多个进程变成僵尸进程且未终止。
并导致CRS通过节点重启或 rebootless restart( CRS 重新启动但节点不重启)进行重新启动。这种情况下,问题实例的警报日志显示
Instance termination failed to kill one or more processes
Instance terminated by LMON, pid = 23305
(实例终止未能终止一个或多个进程
实例被 LMON, pid = 23305 终止)
解决方案:
此问题的解决方案与问题 3 相似
1) 查找数据库或实例挂起的原因。对数据库或实例挂起问题进行故障排除时,获取全局 systemstate 转储和全局hang analyze 转储是关键。如果无法获取全局 systemstate 转储,则应获取在大致相同时间所有实例的本地 systemstate 转储。
2) 检查 CHM (Cluster Health Monitor) 输出,以查看服务器是否存在 CPU 或内存负载问题、网络问题或者 lmd 或 lms 进程出现死循环。CHM 输出只能在某些平台和版本中使用,因此请参阅 CHM 常见问题 Document 1328466.1
3) 如果 OSWatcher 尚未设置,请按照 Document 301137.1 中的说明进行设置以运行 OSWatcher。
CHM 输出不可用时,使用 OSWatcher 输出将有所帮助.

如何简化Oracle Linux上安装Oracle Database

对于广大Oracle数据库技术爱好者来讲,在虚拟机上安装部署学习Oracle数据库无疑是一个不错的选择,我们既可以按照自己的需求进行系统的配置,也可以在很短的时间内搭建出需要的运行环境,既保证了实用性,也满足了高效性,而Linux平台则更是广大技术爱好者的首选实验环境平台。

在Linux平台上,通常在运行./runInstaller图形界面安装Oracle Database时,我们需要先做一些准备工作,比如安装必备的RPM包,修改系统内核参数,创建必要的用户和用户组,这些操作本身没有什么难度,因为我们可以按照Oracle文档说明去完成些操作,最多是多花一点时间。本文将介绍一种新的方法,可以让你省去这些繁琐的准备工作,使在Linux 平台上安装Oracle Database变的更加快捷和方便。

由于之前Oracle发布的linux平台版本的数据库产品主要面向于RedHat,但在RedHat上安装部署Oracle 数据库经常会出现一些问题,加之Linux开源及Oracle公司势力日益扩增,因此Oracle公司最终对外宣布推出了自己的Linux系统(Oracle Linux),虽然Oracle公司推出了自己的Linux系统,但事实上Oracle公司是拿RedHat Linux做内核,仅将RedHat图标改为Oracle,将之前在RedHat Linux上运行Oracle数据库出现的问题和Bug修复,最多也就增强了一些功能而已。本文就是介绍在Oracle Linux上如何简化安装Oracle Database,因为该方法只支持Oracle Linux版本,对于Oracle Linux系统的安装在此不作说明,下面直接从安装完系统开始安装Oracle数据库前演示。

由于数据库需要某些软件包、软件包版本以及内核参数微调,在系统上安装Oracle Database 10g或11g之前,需要预先配置操作环境。在Oracle Linux上,有一种非常轻松的办法可以让系统满足这些安装先决条件,安装一个名为oracle-validated的RPM软件包,该RPM包可以帮你自动完成Oracle数据库所必须的RPM包的安装,修改系统内核参数,创建必要的用户和用户组等。此RPM执行以下预配置步骤:
1)促使下载和安装数据库安装所需的各种软件包和特定版本,通过yum或up2date功能来解析软件包依赖项;
2)创建用户oracle和组oinstall及dba,这些将在数据库安装期间使用;
3)修改/etc/sysctl.conf中的内核参数以更改共享内存、信号、最大文件描述符数量等设置;
4)设置/etc/security/limits.conf中的软硬shell资源限制,如锁定内存地址空间、打开的文件数量、进程数和核心文件大小;
5)针对x86_64计算机,在内核中设置numa=off;

请注意oracle-validated只是根据数据库安装的需要来分析现有的/etc/sysctl.conf 和/etc/security/limits.conf文件并更新值,所有与数据库安装无关的预自定义设置保持不变,oracle-validated RPM软件包可通过Oracle Unbreakable Linux Network(ULN需要支持合同)、Oracle Linux 发行介质或Oracle公共yum信息库获取。因此,无论系统是否在ULN注册访问Oracle补丁和支持,您均可使用 oracle-validated来简化Oracle Linux上的数据库安装,不过要记住,Oracle公共yum信息库不会更新安全更新和错误修补,因此保持最新和安全的系统的最佳方式是使用ULN订阅。

安装oracle-validated.rpm
  首先,设置一个yum配置文件,让其指向正确的信息库,然后从该信息库安装oracle-validated RPM,使用yum安装oracle-validated RPM包,主要是为了解决安装该包的依赖关系。为了简化操作,我直接将Oracle Linux系统安装光盘挂载在/mnt目录下,作为信息库,以下是针对Oracle Database安装使用oracle-validated对系统进行预配置的步骤:
1.作为一个授权用户(如 root)检索配置信息库位置的文件:

[root@11gR2 ~]# cd /etc/yum.repos.d/
[root@11gR2 yum.repos.d]#

2.在该目录下创建一个后缀为.repo任意名文件,其内容如下:

[ol5_u8_base]
name=Jialin.Lee Oracle Linux 5.8
baseurl=file:///mnt/Server/
gpgcheck=0
enabled=1

3.使用yum install命令安装oracle-validated RPM
注:清单1中的输出显示了安装过程如何检查依赖项然后下载和安装所需软件包 

[root@11gR2 yum.repos.d]# yum install oracle-validated*.rpm
Loaded plugins: rhnplugin, security
This system is not registered with ULN.
ULN support will be disabled.
oel-base | 1.1 kB 00:00
oel-base/primary | 1.4 MB 00:00
oel-base 3298/3298
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package oracle-validated.x86_64 0:1.1.0-15.el5 set to be updated
oel-base/filelists | 3.1 MB 00:00
--> Processing Dependency: sysstat for package: oracle-validated
--> Processing Dependency: /usr/lib/libaio.so for package: oracle-validated
--> Processing Dependency: glibc-headers for package: oracle-validated
--> Processing Dependency: elfutils-libelf-devel for package: oracle-validated
--> Processing Dependency: unixODBC-devel for package: oracle-validated
--> Processing Dependency: /usr/lib64/libodbccr.so for package: oracle-validated
--> Processing Dependency: gcc-c++ for package: oracle-validated
--> Processing Dependency: libaio-devel for package: oracle-validated
--> Processing Dependency: gcc for package: oracle-validated
--> Processing Dependency: /usr/lib/gcc/x86_64-redhat-linux/4.1.1/libstdc++.a for package: oracle-validated
--> Processing Dependency: /usr/lib/libodbc.so.1 for package: oracle-validated
--> Processing Dependency: /usr/lib/libc.so for package: oracle-validated
--> Processing Dependency: /usr/lib64/libaio.so for package: oracle-validated
--> Processing Dependency: /usr/lib64/libc.so for package: oracle-validated
--> Processing Dependency: /usr/lib/libodbccr.so for package: oracle-validated
--> Processing Dependency: libXp.so.6 for package: oracle-validated
--> Processing Dependency: libodbc.so.1()(64bit) for package: oracle-validated
--> Running transaction check
---> Package elfutils-libelf-devel.x86_64 0:0.137-3.el5 set to be updated
--> Processing Dependency: elfutils-libelf-devel-static-x86_64 = 0.137-3.el5 for package: elfutils-libelf-devel
---> Package gcc.x86_64 0:4.1.2-52.el5 set to be updated
---> Package gcc-c++.x86_64 0:4.1.2-52.el5 set to be updated
---> Package glibc-devel.i386 0:2.5-81 set to be updated
---> Package glibc-devel.x86_64 0:2.5-81 set to be updated
---> Package glibc-headers.x86_64 0:2.5-81 set to be updated
--> Processing Dependency: kernel-headers >= 2.2.1 for package: glibc-headers
--> Processing Dependency: kernel-headers for package: glibc-headers
---> Package libXp.i386 0:1.0.0-8.1.el5 set to be updated
---> Package libaio-devel.i386 0:0.3.106-5 set to be updated
---> Package libaio-devel.x86_64 0:0.3.106-5 set to be updated
---> Package libstdc++-devel.x86_64 0:4.1.2-52.el5 set to be updated
---> Package sysstat.x86_64 0:7.0.2-11.el5 set to be updated
---> Package unixODBC-devel.i386 0:2.2.11-10.el5 set to be updated
--> Processing Dependency: unixODBC = 2.2.11-10.el5 for package: unixODBC-devel
---> Package unixODBC-devel.x86_64 0:2.2.11-10.el5 set to be updated
---> Package unixODBC-libs.i386 0:2.2.11-10.el5 set to be updated
---> Package unixODBC-libs.x86_64 0:2.2.11-10.el5 set to be updated
--> Running transaction check
---> Package elfutils-libelf-devel-static.x86_64 0:0.137-3.el5 set to be updated
---> Package kernel-headers.x86_64 0:2.6.18-308.el5 set to be updated
---> Package unixODBC.x86_64 0:2.2.11-10.el5 set to be updated
--> Finished Dependency Resolution
  
Dependencies Resolved
  
===========================================================================================
Package Arch Version Repository Size
===========================================================================================
Installing:
oracle-validated x86_64 1.1.0-15.el5 oel-base 24 k
Installing for dependencies:
elfutils-libelf-devel x86_64 0.137-3.el5 oel-base 24 k
elfutils-libelf-devel-static x86_64 0.137-3.el5 oel-base 64 k
gcc x86_64 4.1.2-52.el5 oel-base 5.3 M
gcc-c++ x86_64 4.1.2-52.el5 oel-base 3.8 M
glibc-devel i386 2.5-81 oel-base 2.0 M
glibc-devel x86_64 2.5-81 oel-base 2.4 M
glibc-headers x86_64 2.5-81 oel-base 596 k
kernel-headers x86_64 2.6.18-308.el5 oel-base 1.4 M
libXp i386 1.0.0-8.1.el5 oel-base 22 k
libaio-devel i386 0.3.106-5 oel-base 12 k
libaio-devel x86_64 0.3.106-5 oel-base 11 k
libstdc++-devel x86_64 4.1.2-52.el5 oel-base 2.8 M
sysstat x86_64 7.0.2-11.el5 oel-base 187 k
unixODBC x86_64 2.2.11-10.el5 oel-base 291 k
unixODBC-devel i386 2.2.11-10.el5 oel-base 738 k
unixODBC-devel x86_64 2.2.11-10.el5 oel-base 793 k
unixODBC-libs i386 2.2.11-10.el5 oel-base 551 k
unixODBC-libs x86_64 2.2.11-10.el5 oel-base 554 k
  
Transaction Summary
===========================================================================================
Install 19 Package(s)
Upgrade 0 Package(s)
  
Total download size: 21 M
Is this ok [y/N]: y
Downloading Packages:
-------------------------------------------------------------------------------------------
Total 1.5 GB/s | 21 MB 00:00
Running RPM_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : unixODBC-libs 1/19
Installing : unixODBC 2/19
Installing : libstdc++-devel 3/19
Installing : sysstat 4/19
Installing : unixODBC-devel 5/19
Installing : kernel-headers 6/19
Installing : glibc-headers 7/19
Installing : glibc-devel 8/19
Installing : glibc-devel 9/19
Installing : libaio-devel 10/19
Installing : libaio-devel 11/19
Installing : unixODBC-libs 12/19
Installing : libXp 13/19
Installing : gcc 14/19
Installing : gcc-c++ 15/19
Installing : unixODBC-devel 16/19
Installing : elfutils-libelf-devel 17/19
Installing : oracle-validated 18/19
Installing : elfutils-libelf-devel-static 19/19
  
Installed:
oracle-validated.x86_64 0:1.1.0-15.el5
  
Dependency Installed:
elfutils-libelf-devel.x86_64 0:0.137-3.el5
elfutils-libelf-devel-static.x86_64 0:0.137-3.el5
gcc.x86_64 0:4.1.2-52.el5
gcc-c++.x86_64 0:4.1.2-52.el5
glibc-devel.i386 0:2.5-81
glibc-devel.x86_64 0:2.5-81
glibc-headers.x86_64 0:2.5-81
kernel-headers.x86_64 0:2.6.18-308.el5
libXp.i386 0:1.0.0-8.1.el5
libaio-devel.i386 0:0.3.106-5
libaio-devel.x86_64 0:0.3.106-5
libstdc++-devel.x86_64 0:4.1.2-52.el5
sysstat.x86_64 0:7.0.2-11.el5
unixODBC.x86_64 0:2.2.11-10.el5
unixODBC-devel.i386 0:2.2.11-10.el5
unixODBC-devel.x86_64 0:2.2.11-10.el5
unixODBC-libs.i386 0:2.2.11-10.el5
unixODBC-libs.x86_64 0:2.2.11-10.el5
  
Complete!

注:yum安装过程在/var/log/oracle-validated/results/orakernel.log文件中记录有关内核更改的消息,并在 /var/log/oracle-validated/backup目录中备份当前系统设置。

至此系统已准备好,可以安装Oracle Database了,举例来说,若要安装Oracle Database 11g第2版,请按照“适用于Linux的数据库安装指南”的第4章“安装 Oracle Database”中的说明进行操作。在运行./runInstaller起图形界面安装Oracle数据软件时会执行一些检查,验证是否已经安装必要的操作系统软件包和版本,此外还检查通过oracle-validated安装设置的内核参数。在内核设置检查期间,安装程序可能将一些设置标志为“failed”,您应对这些失败进行分析,在有些情况下,您仍可以继续数据库安装。如果您检查/etc/sysctl.conf中的内核设置,将发现oracle-validated为Oracle Database 10g推荐的设置不同于Oracle Database 11g,如果需要,您可以(以root身份)编辑/etc/sysctl.conf文件来手动指定设置。Oracle Universal Installer还会执行其他检查,如验证glibc版本、磁盘空间是否足够、环境变量和路径设置,以及物理内存和交换空间是否足够,一般来说,安装oracle-validated可解决先决条件,因此您可以直接继续安装数据库。

安装oracle-validated.rpm可以节省在Oracle Linux上安装Oracle Database 10g或11g的时间,RPM 能让系统满足Oracle Database安装的大多数先决条件,从而简化了安装过程。

PS: 这篇文章来源于笔者曾经新浪博客…