www.eygle.com

---

June 26, 2009

恩墨科技成功签约北京资和信集团

作者:eygle

出处:http://blog.eygle.com

2009年6月，恩墨科技成功签约北京资和信集团，为该集团提供金牌数据库支持与咨询服务,这是恩墨科技成立以来签下的又一重要企业客户。

北京资和信集团是一家服务于金融与零售领域的大型集团公司，主要从事业务包括：卡业务、担保业务、资和信百货及其他业务。

资和信集团的主营卡业务，占据了北京购物卡市场的绝对领导地位。北京商业服务业通用积分卡（商通卡）由北京资和信担保集团旗下北京商服通网络科技有限公司管理，北京资和信通联科技有限公司提供技术服务。作为首家运营通用 积分卡的公司，经过近十年的锤炼，商通卡无论是在便利性、安全性还是服务方面都得到客户与商户的广泛认可，无论从交易额、客户数量与层次、商户规模与数量 上与其他同行业企业相比，都保持着较大的优势。客户方面，持卡人众多，并与许多大型知名团体客户建立了长期的服务关系；商户方面，行业涉及百货、超市、旅 游、餐饮、医疗、健身、娱乐等众多领域。

资和信集团由于承载着大量消费卡的管理、消费记录、结算等重要业务，对于数据库的高可用性、稳定性及性能都有很高的要求。基于双方长期的合作、了解与信任，北京资和信集团选择了恩墨科技作为数据库服务提供商，为其提供全面的数据库技术支持与顾问咨询服务。

感谢客户长期以来的信赖与支持，我们将一如既往的加深理解与沟通，全力为客户提供高品质的数据库服务，保障和满足客户的业务需求。

Posted by eygle at 5:20 PM | Comments (6)

---

IPC Send Timeout和ORA-29740 Instance Evicted

作者:eygle

出处:http://blog.eygle.com

IPC Send timeout 是 Oracle10g Rac中非常让人头痛的一个问题，在资源紧张、网络拥堵等情况下，就有可能发生IPC超时的问题，而RAC随后就会将问题节点驱逐，引发一轮重新配置。

可喜的是Metalink上针对10.2.0.3有了一个Patch可以修正，而且在10.2.0.4中彻底修正了该问题。
常见的错误提示是这样的：

Thu Nov 27 11:32:05 2008
IPC Send timeout detected. Receiver ospid 4001974
Thu Nov 27 11:33:08 2008
Trace dumping is performing id=[cdmp_20081127113236]
Thu Nov 27 11:34:37 2008
Errors in file /oracle/app/product/admin/srs/bdump/srs1_lms1_4001974.trc:
Thu Nov 27 11:34:38 2008
Errors in file /oracle/app/product/admin/srs/bdump/srs1_lmon_3977348.trc:
ORA-29740: evicted by member 1, group incarnation 32
Thu Nov 27 11:34:38 2008
LMON: terminating instance due to error 29740

这个BUG号是Bug 5190596 。

在我的印象里10.2.0.3的确常有这个问题，而10.2.0.4却很少看到。

Posted by eygle at 4:40 PM | Comments (1)

---

IBM 的 clverify 与 Oracle 的 cluvfy

作者:eygle

出处:http://blog.eygle.com

昨晚在客户Oracle数据库系统上应用一个Patch时，遇到了一幢惊心动魄的事情。

当我们刚刚应用完Patch之后，系统上就出现了一条广播消息，提示：

Broadcast message from root@p570 (tty) at 00:00:19 ...

clverify has detected cluster configuration errors on node p570. Detailed clverify output is available in standard clverify log on node p570.

提示说clverify检查到Cluster错误，因为应用的一个Patch和CRS有点关系，但是第一感觉是：难道CRS除了问题？
而且直接把clverify误判成了Oracle的Cluvfy，汗！
Oracle的cluvfy是用来验证Oracle集群的一致性的，我用cluvfy检查一下也没有发现问题

[oracle@dbrac1 oracle]$ cluvfy


USAGE:
cluvfy [ -help ]
cluvfy stage { -list | -help }
cluvfy stage {-pre|-post} <stage-name> <stage-specific options>  [-verbose]
cluvfy comp  { -list | -help }
cluvfy comp  <component-name> <component-specific options>  [-verbose]

再仔细看提示才发现此clverify不是cluvfy：

在HACMP 5.1中，包括集群校验程序(clverify)和新的集群通信后台(clcomdES)都需要/var文件系统下附加的空间。

要得到详细的消息和附加的调试信息，在每个节点的/var下需要满足：

Ø        20M仅一次，包括：

-          /var/HACMP/clcomd/clcomd.log  2M

-          /var/HACMP/clcomd/clcomddiag.log  18M

Ø        在/var/HACMP/odmcache目录下附加的（1M*集群中的节点数）空间。

Ø        4M每个节点集群的效验数据。

Ø        2M的集群效验log（clverify.log[0-9]）。

在集群的每个节点中，效验工具在需要/var下4M的空间，clverify可以在同一时间最多保持四份节点效验数据的拷贝(节点初始化和同步时)。

/var/HACMP/clverify/current//*包含当前执行的效验的日志。

/var/HACMP/clverify/pass//*包含最后通过的效验的日志。

/var/HACMP/clverify/pass。prev/ /*包含倒数第二次通过效验的日志。

/var/HACMP/clverify/fail//*包含最后一次失败的效验日志。

同时，/var/HACMP/clverify/clverify.log和它的拷贝消耗1-2M的磁盘空间。

再来检查HACMP的日志，发现的确是系统Cluster因为两台主机的时间不一致发出了一个警告，和数据库无关。

ERROR: The HACMP timestamp file for shared volume group: oraclevg is inconsistent
with the time stamp in the VGDA for the following nodes: p1 p2

重启数据库，一切是正常的。

这个故事说明，DBA不仅要心理素质好，眼神也要好！

-The End-

Posted by eygle at 10:18 AM | Comments (4)

---