开了归档效率真下降这么多吗?

openit_2004

我遇到的现象是
四节点的RAC系统，每个节点归档到本机，（本机是RAID1，双硬盘）。但是每个归档都占用CPU99％多。
会不会和RAC的GCS/GES有关系呢？
例如rmem/wmem？
不知道cluster_Interconnects是干吗用的？

wlidflower

每个归档都占用CPU99％
这是什么意思呢?

husthxd

最初由 openit_2004 发布
[B]我遇到的现象是
四节点的RAC系统，每个节点归档到本机，（本机是RAID1，双硬盘）。但是每个归档都占用CPU99％多。
会不会和RAC的GCS/GES有关系呢？
例如rmem/wmem？
不知道cluster_Interconnects是干吗用的？ [/B]

数据库版本?
但是每个归档都占用CPU99％多-->看不明白.

Oracle9i Information
•        Note: Default values and ranges may differ from those shown here due to variations between releases..
Parameter type         String
Syntax         CLUSTER_INTERCONNECTS = ifn [: ifn ... ]
Default value         There is no default value.
Parameter class         Static
Range of values         One or more IP addresses, separated by colons

•        CLUSTER_INTERCONNECTS provides Oracle with information about additional cluster interconnects available for use in Oracle9i Real Application Clusters environments.
•        Oracle uses information from this parameter to distribute traffic among the various interfaces. You should set a value for CLUSTER_INTERCONNECTS when a single interconnect is insufficient to meet the bandwidth requirements of large cluster databases.
•        CLUSTER_INTERCONNECTS is an optional parameter. If you do not set it, Oracle preserves the current semantics that determine the appropriate interconnect for Oracle9i Real Application Clusters inter-node communication.

Note:
When you set CLUSTER_INTERCONNECTS in Solaris configurations, the interconnect High Availability features are not available. In other words, an interconnect failure that is normally unnoticeable would instead cause an Oracle cluster failure.  

如果是9206,CLUSTER_INTERCONNECTS 参数不起作用,需要打一个patch.

openit_2004

谢谢husthxd※wlidflower
RAC环境：RH AS21＋Oracle9204＋四台IA Server＋SAN；

开始设置了打开了两个归档进程。系统调试初始有大量的数据导入操作，因此两个归档一定时间后都启动起来。每个归档都占用一颗CPU的99％多。

后来干脆干掉了归档。
另外在系统调试的过程中，出现了很多性能的问题，因此调整了SGA、AIO、rmem、wmem。
但是归档的问题一直没有时间去仔细研究。

另外，我们的系统在安装过程中，开始是安装后，建立不了应用程序库，重新安装时，又反复出现分发安装到99％的时候挂起（perfoming remote operation的时候），后来我们是分别安装再合并到一块的。

wlidflower

最初由 openit_2004 发布
[B]谢谢husthxd※wlidflower
RAC环境：RH AS21＋Oracle9204＋四台IA Server＋SAN；

开始设置了打开了两个归档进程。系统调试初始有大量的数据导入操作，因此两个归档一定时间后都启动起来。每个归档都占用一颗CPU的99％多。

后来干脆干掉了归档。
另外在系统调试的过程中，出现了很多性能的问题，因此调整了SGA、AIO、rmem、wmem。
但是归档的问题一直没有时间去仔细研究。

另外，我们的系统在安装过程中，开始是安装后，建立不了应用程序库，重新安装时，又反复出现分发安装到99％的时候挂起（perfoming remote operation的时候），后来我们是分别安装再合并到一块的。 [/B]

归档开启与关闭时候做个分析对比看看
我做测试没发现归档进程占用很高的CPU

rollingpig

最初由 wlidflower 发布
[B]

那我做RMAN的时候比较慢可能也是这个原因了
呵呵
感谢大家！ [/B]

看你的意思好像是做RMAN backup写到raid 5 的阵列?

好像有点不好，backup的东西和被backup的东西不要放一起吧？
不然storage坏了怎办？

Raid5慢归慢，但是冗余功能是raid卡提供的，不涉及主机的CPU啊，等待可以理解，为什么CPU占用率会那么高呢？

不知道楼主如何看CPU占用率/CPU IDLE，就我所知，
如果用的时TOP,显示数值会考虑了IO WAIT在内
如果是vmstat,某些系统可以加上 -w 参数，考虑了IO WAIT在内
或者直接用iostat,也会考虑了IO WAIT在内

所以，有可能所占的CPU和大一部分是IO WAIT.

谢谢各位了
我的这个问题可能暂时不会去实验验证他了
但是大家的假设和各种观点我会在有机会的时候来实验验证

验证并不难，两个10046 ,level 12 的trace + tkprof 基本差不多了。
如果不嫌麻烦，做个statspack,对比一下，也很容易看出差别。

总而言之，因为archive log产生的额外的IO应该就是本例的罪魁祸首。

wlidflower

"验证并不难，两个10046 ,level 12 的trace + tkprof 基本差不多了。
如果不嫌麻烦，做个statspack,对比一下，也很容易看出差别。

总而言之，因为archive log产生的额外的IO应该就是本例的罪魁祸首。"

当然是ARCHIVE搞的鬼
可能我忽略了一个细节,我的是RAC环境,但是我的操作在一个节点上做
不知道是不是RAC环境对这个也有影响,大家不知道发现没有,在RAC环境下,仅仅在一个节点进行操作,另外一个节点的REDO也会发生切换,同时也会生产归档日志,如果节点2没开,那么这些归档日志会写在1这个节点上
我已经发了相关的帖子, WING HONG斑竹也给了点已经,大家可以去关注一下

我的是RAID5,做完RMAN以后拷贝出来进行的备份

wlidflower

最初由 Kamus 发布
[B]

我通览了一遍，没有发现楼主说IO wait很低啊
因为可能有大量的I/O Wait所以导致CPU占用量高，因为CPU一直在等硬盘的操作完成 [/B]

CPU能上去就是个问题啊,在WAIT状态一定会产生高的CPU吗?

wlidflower

RAC下写日志
请参阅http://www.itpub.net/335952.html

husthxd

最初由 wlidflower 发布
[B]"验证并不难，两个10046 ,level 12 的trace + tkprof 基本差不多了。
如果不嫌麻烦，做个statspack,对比一下，也很容易看出差别。

总而言之，因为archive log产生的额外的IO应该就是本例的罪魁祸首。"

当然是ARCHIVE搞的鬼
可能我忽略了一个细节,我的是RAC环境,但是我的操作在一个节点上做
不知道是不是RAC环境对这个也有影响,大家不知道发现没有,在RAC环境下,仅仅在一个节点进行操作,另外一个节点的REDO也会发生切换,同时也会生产归档日志,如果节点2没开,那么这些归档日志会写在1这个节点上
我已经发了相关的帖子, WING HONG斑竹也给了点已经,大家可以去关注一下

我的是RAID5,做完RMAN以后拷贝出来进行的备份 [/B]

Archive logs for an instance may be archived by another active instance in the  
following situations:  
  
1.  The 'alter system archive log all' command was issued manually without            
    specifying the thread parameter. Manual archiving is performed by the user
    process that issues the archiving command; it is not performed by the  
    instance's ARCH process. The redo log files are archived to the destination
    of the instance to which the user is connected.  
  
2.  Parallel server can force a log switch for an instance that fails to        
    archive its online redo log files for some period of time, either because   
    the instance has not generated many redo entries or because the instance     
    has shutdown.  This prevents a thread from remaining unarchived for too      
    long.  After an instance has shutdown, another instance can force a log        
    switch for that instance so that its current redo log can be archived.  
  
Either situation can result in archive logs being written to the destination  
of the active instance.