How to change VIP interface in 10g cluster

1 Comment

凌晨2点出发到客户处加班，加班的目的是由于改动网卡而重新配置VIP资源。

IBM AIX5L的系统，安装的是10gR2 RAC，在最开始安装的时候，客户配置了HACMP，并且设置了Primary网卡和Standby网卡，同时HACMP还会管理这两块网卡，当Public网卡出现问题的时候IP会切换到Standby网卡，但是10g Cluster的VIP却无法应对这种情况，当发生IP切换，VIP就down了。本来客户如此考虑是为了避免网卡的单点故障，但是通过HACMP这样管理的方法却仍然无法避免VIP的单点故障，因此客户决定今天晚上重新设置网卡，将原本的Primary和Standby网卡bunddle成一块Public网卡，这样网卡的Interface Name就会发生改变，所以VIP资源就需要重新配置。

修改VIP资源的步骤大体如下。

1. 停止数据库，CRS

$ srvctl stop database -d grid 
$ srvctl stop nodeapps -n node1
$ srvctl stop nodeapps -n node2

2. 修改OCR中的信息
删除原先的信息

$ORA_CRS_HOME/bin/oifcfg delif -global eth1

添加新的信息

$ORA_CRS_HOME/bin/oifcfg setif –global eth0/192.168.2.0:public

检查是否添加成功

$ORA_CRS_HOME/bin/oifcfg getif

3. 用root用户修改nodeapps
因为修改必须在 Oracle Clusterware stack启动状态下进行，因此上面一步要用srvctl stop nodeapps来停止资源而不要使用crsctl stop crs来停掉整个Clusterware。

# srvctl modify nodeapps -n node1 -A 192.168.2.125/255.255.255.0/eth0
# srvctl modify nodeapps -n node2 -A 192.168.2.126/255.255.255.0/eth0

检查是否修改成功

# srvctl config nodeapps -n  -a

4. 重新启动nodeapps和数据库

$ srvctl start nodeapps -n node1
$ srvctl start nodeapps -n node2
$ srvctl start database -d grid

渴望没有发票的世界！

17 Comments

忍无可忍，从下午4点开始填报销，贴发票，一直到现在，临晨1点多，我只完成了所有工作量的2/3，还有一万三千多的发票没有贴起来！
每次出差之后贴发票报销的工作简直是让人抓狂的事情。

幻想有一天，所有的消费都可以通过信用卡完成，而所有的刷卡记录都可以自动提交到各个公司的财务部门网络中，不再有纸质的发票，不再有繁琐的表格，不再有农民一样的贴票工作，这样的世界何时才能到来？

10gRAC培训 – 2 and last

16 Comments

为期4天的10g RAC培训结束了，必须承认这4天的收获非常大，解答了很多我以前一直迷惑的地方，并且获得了大量诊断和调优RAC系统的经验。Su和Roy的技术实在让人佩服。

对于AWR报告中RAC部分的表述，对于RAC每个重要等待事件的含义，对于Cache Fusion的每一步动作，对于CRS相关的log和trace，对于Load Balance的处理，对于Dynamic Resource Management的机制，这些都是我以前感到疑惑的地方，在这次培训中都得到了几乎完美的解答。

举一个简单的例子，如果有人问我，“RAC环境中如果一个实例在自己的Cache中找不到需求的block，那么它就会请求从另外一个实例中获得这个block，那么如果有更多的节点，这样的请求过程会很消耗资源吗？8个节点下的这种情况会比2个节点更消耗资源吗？”在这次培训之前，我无法回答，甚至我会说，恩，也许是的吧。但是，现在我可以很清楚地回答，NO！因为在一次gc block request中最多只会有3个block参与到其中，而不管环境中有多少个节点，这就是master block的作用，每次request的过程是requester -> master -> holder。

其实并不局限在RAC部分，纯RDBMS的知识也得到了完善，再举一个例子。对于性能报告中CPU Time这个等待事件我一直感到疑惑，这到底表示了什么？CPU Time位于Top 5 wait event中表示了什么？我还在网上跟Fenng聊过这个问题，也仍然抱有疑惑。然而，现在我知道，我们忽略Top 5中的CPU Time并不是因为它是Idle wait也不是因为我们要从其它的等待中判断CPU Time等待，我们忽略它是因为CPU Time就是说明系统在利用CPU干活，实际上这不是一个等待事件，CPU Time高表示系统在干活，而这是个好的现象，因为系统并没有把时间耗费在Wait上。Elapsed Time = CPU Time + Wait Time，所以甚至我们可以说CPU Time越高越好。

有太多的资料和学习笔记需要整理，今后应该会陆续把Topic写成文章的，不过不会很快，因为之后几天我得休息一下，然后把报销搞定，还有琢磨一下新入手的Nokia N95。

BTW: RAC Pack的宗旨是高举Oracle的三个代表 － CRS, ASM, RAC。

Update@2011-1-9
今天再回顾3年前的这段话，发现当时自己对于CPU Time在数据库整体等待事件中的含义还是不太清晰的，应该说piner当时的话更符合我现在的理解。在一个正常的系统中，虽然仍然不需要特别去关注CPU Time，但是如果在AWR报告中看到CPU Time占据了80%甚至90%的DB Time，那么如果不是这个系统确实很闲那就是这个系统有某些问题。因为数据库在正常承载应用的时候，如果绝大多数时间都是CPU在运算，那么就意味着I/O时间很小，这在大多数环境中是不正常的。
一些概念在DB time VS. DB CPU中进一步清晰。

BTW：3年前还是Nokia鼎盛的时期，那时候正入手Nokia N95，然而到了2010年，Nokia在Apple iPhone和Google Android的强大攻势下，已经面临再不转身就会被抛下的局面，真是一朝天子一朝臣。