-
Recent Posts
Recent Comments
- yangtingkun on 非空字段空值对查询的影响
- Eric Zong on 非空字段空值对查询的影响
- Kamus on Oracle Ace Director
- 设置全局死锁优先级 | yangtingkun on RAC全局死锁检测时间
- ORA-600(krbounotread_noctx)错误 | yangtingkun on ORA-600(krboReadBitmap_badbitmap)错误
Archives
- December 2020
- February 2019
- December 2018
- November 2018
- October 2018
- July 2018
- June 2018
- May 2018
- July 2016
- July 2013
- June 2013
- November 2012
- October 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
Categories
Meta
Tag Archives: vip
数据库VIP地址无法访问(二)
客户的数据库出现VIP地址无法访问的情况。 这一篇描述问题的解决。 数据库VIP地址无法访问(一):https://yangtingkun.net/?p=798 上一篇通过诊断找到了问题的原因,由于VIP绑定网卡的错误,导致VIP可能漂移到PRIVATE网卡上,从而导致VIP地址对于外部服务器不可见。 找到原因后,解决其实很简单,只需要改正VIP错误的配置即可,简单的代码类似下面的示例: oracle@racdb1 $ srvctl config nodeapps -n racdb1 –a VIP EXISTS.: /racdb1-vip/10.8.60.201/255.255.255.0/aggr1:aggr2 oracle@racdb1 $ srvctl config nodeapps -n racdb2 –a VIP EXISTS.: /racdb2-vip/10.8.60.202/255.255.255.0/aggr1:aggr2oracle@racdb1 $ srvctl config nodeapps -n racdb1 –a VIP exists.: /racdb1-vip/10.8.60.201/255.255.255.0/aggr1:aggr2 oracle@racdb1 $ srvctl … Continue reading
数据库VIP地址无法访问(一)
客户的数据库出现VIP地址无法访问的情况。 这一篇描述问题的诊断。 客户的RAC环境重建后,发现两个节点的VIP都无法访问,开始认为是网络问题,但是随后发现整个RAC重启后,其中一个节点的VIP可以访问,而另一个节点的VIP仍然无法访问,因此判断可能是RAC本身的问题。 听到问题描述后,第一个判断是否VIP没有启动,登录数据库服务器后进行了检查: oracle@racdb1 $ lsnrctl STATUS LSNRCTL FOR Solaris: Version 10.2.0.4.0 – Production ON 18-APR-2012 10:22:02 Copyright (c) 1991, 2007, Oracle. ALL rights reserved. Connecting TO (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521)) STATUS OF the LISTENER ———————— Alias LISTENER_RACDB1 Version TNSLSNR FOR Solaris: … Continue reading
RAC环境关闭CLUSTER后导致连接缓慢
客户的四节点RAC在停掉三个后,发现连接RAC明显变慢。 数据库环境是4节点的10.2 RAC for Linux X86-64。由于心跳存在问题,目前将三个节点上的CLUSTER关闭,但是随后不久,客户反应数据库访问变慢。 虽然本来4个节点繁忙程度都不高,但是将4个实例上的压力集中到1个实例上,那么性能有所下降也是正常的。不过检查数据库的工作状态,并未发现异常,无论是从后台cpu忙闲程度,还是从awr报告中查看,似乎并没有太大的压力。 询问客户是查询变慢还是登录变慢,客户也搞不清其中的差别,于是在尝试连接数据库,结果发现,无论是tnsping还是sqlplus登录,有时登录很快,有时要经历3秒到6秒的等待,这应该就是客户反应慢的原因。 检查登录数据库的TNSNAMES.ORA中的配置,客户默认4个节点作为LOAD BALANCE和静态FAILOVER,这种配置方式在节点关闭后并不会导致错误,但是有可能由于需要等待超时而经受性能问题。 检查服务器上CLUSTER的状态,发现4个节点上,有两个VIP的服务都停掉了,应该是用户关闭整个CLUSTER服务是导致的。在此情况下,静态FAILOVER发挥作用,但是会引入超时的问题。而由于配置了LOAD_BALANCE,Oracle会轮训4个VIP地址,这就导致了有时候连接很快完成,而有时连接需要等待3秒以上。 由于存在众多的客户端,无法一一修改客户端使用的TNS配置,那么最简单的解决办法就是将CLUSTER启动,只是关闭其他三个节点的数据库,这样所有的VIP都处于启动状态,即使连接到没有提供的服务的节点,也可以快速的重新启动到启动节点上。 将其他两个VIP关闭的CLUSTER启动,保持DB关闭状态,数据库连接缓慢的问题就此解决。