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

biti_rainy

如果是使用 raw  device ,由于通常数据文件没什么 file  system  cache ,所以内存free也多一些，swap比较少一些

而归档文件由于是文件系统，则可能影响到内存的使用，导致 file  system  cache 使用的增加进而可能影响到 free and  swap .在不少系统上，需要调低文件系统缓存占用内存的比例。

d.c.b.a

CHECKPOINT过于频繁，导至IO过多，也会是问题。

小新

呵呵，大家继续找找可能引起io得其他问题。

full table scan

biti_rainy

最初由 d.c.b.a 发布
[B]CHECKPOINT过于频繁，导至IO过多，也会是问题。 [/B]

这句话本身没问题，但是和这个主题有点不符合了

归档并不会导致检查点过于频繁
频繁地commit也不会导致检查点过于频繁


可能由于归档，一方面影响了IO,另一方面，这一点IO，由于是需要读联机日志文件和写归档日志文件，正好可能和LGWR的IO有冲突，则可能降低  commit 时候lgwr写日志文件的速度，从而延缓了事务的进行。  但或许在整体上来看，io和cpu表现不是很明显，只是在局部存在问题。


在同样是频繁地提交的情况下，观察该session在两种方式下，等待事件以及等待时间可能有细小的变化。

d.c.b.a

CHECKPOINT也可能和Archive Log的性能有关

Hi!

1) Oracle recommend to run both the instances in archievelog mode.

2) Tune the archieve as follow:


a) evaluate the number and size of the online redo logs.
Most often, increasing the size and the number of online redo log
groups will give archiver more time to catch up.
Adding more online logs does not help a situation where the archiver
cannot keep up with LGWR. It can help if there are bursts of redo
generation since it gives ARCH more time to average its processing
rate over time.

b) evaluate checkpoint interval and frequency
There are several possible actions include adding DBWR processes,
increasing db_block_checkpoint_batch, reducing db_block_buffers.
Turning on or allowing async IO capabilities definitely helps
alleviate most DBWR inefficiencies.

The LOG_CHECKPOINT_INTERVAL init.ora parameter controls how often a checkpoint
operation will be performed based upon the number of operating system blocks
that have been written to the redo log. If this value is larger than the size
of the redo log, then the checkpoint will only occur when Oracle performs a
log switch from one group to another, which is preferred.

The LOG_CHECKPOINT_TIMEOUT init.ora parameter controls how often a checkpoint
will be performed based on the number of seconds that have passed since the
last checkpoint. Checkpoint frequency impacts the time required for the
database to recover from an unexpected failure. Longer intervals between
checkpoints mean that more time will be required during database recovery.

c) consider adding multiple archiver processes

If LOG_ARCHIVE_START is set to true, Oracle starts up a single archiver
process names ARC0. Subsequently if the parameter is changed using the ALTER
SYSTEM command it will start the specified number of archive processes. For
example:

SVRMGRL>alter system set LOG_ARCHIVE_MAX_PROCESSES=4;

will invoke additional processes ARC1 , ARC2 and ARC3.

d) tune archiver process
change log_archive_buffer_size (max 128 in some ports)
change log_archive_buffer (max 8 in some ports)


Thanks & Regards,
Mala
@OSS

biti_rainy

归档当然会影响 检查点，这是因为 IO 方面的问题

但是楼主的问题，并没有增加检查点的频率，也没有增加日志的生成量，所以你的  "过于频繁的检查点"   这句话没有依据，对于楼主来说是一个不当的假设。

wlidflower

最初由 biti_rainy 发布
[B]归档当然会影响 检查点，这是因为 IO 方面的问题

但是楼主的问题，并没有增加检查点的频率，也没有增加日志的生成量，所以你的  "过于频繁的检查点"   这句话没有依据，对于楼主来说是一个不当的假设。 [/B]

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

jametong

最初由 biti_rainy 发布
[B]

这句话本身没问题，但是和这个主题有点不符合了

归档并不会导致检查点过于频繁
频繁地commit也不会导致检查点过于频繁

频繁的commit, 自然会导致redo log日志量的大量增长. 特别是造成大量的redo wastage,  redo的量也会增长比较快, 相应的检查点也会更加频繁

可能由于归档，一方面影响了IO,另一方面，这一点IO，由于是需要读联机日志文件和写归档日志文件，正好可能和LGWR的IO有冲突，则可能降低  commit 时候lgwr写日志文件的速度，从而延缓了事务的进行。  但或许在整体上来看，io和cpu表现不是很明显，只是在局部存在问题。


在同样是频繁地提交的情况下，观察该session在两种方式下，等待事件以及等待时间可能有细小的变化。 [/B]

biti_rainy

最初由 jametong 发布
[B] [/B]

你这个和楼主的不是同一个疑惑的问题，离题了

频繁的commit和批量的提交的差异，这个不需要争论,肯定是批量提交好。很多人做了理论和实验的说明，tom更是在expert  one  on  one中做了很详细的说明。


但是人家的目的是为了证明 归档和不归档的情况下的 事务处理能力，一方面未必能做到批量提交（兴许根本是不同的任务），另一方面，他是在大量提交的情况下比较归档和非归档的差异，如果给出一个 批量提交的建议恐怕是不大妥当的。你这个说法虽然是正确的，但是，依然和楼主的本意有差异。


另外，我们来考究频繁的提交，也许1万个提交，假定多1万个日志block，大约是 512*10k =  5M  。 若100M的日志，则20万个提交可能导致多一个日志切换，按照通常的参数设置，也就是说多一个 检查点的产生（实际上对于增量检查点来说检查点的增多并一定就很大地影响了性能），当然日志的增多，当覆盖一圈日志后将要被覆盖的日志对应的dirty buffe还没有写入数据文件则数据库会hang住等待dbwr的写。频繁的提交，当然也增加了进程间的通信量，增多了等待的成本（ log file  sync  ）,日志产生的过多，则可能存在lgwr在io上的等候（log  file  parallel  write）。
(如果楼主在归档和非 归档下对比一下 log  file  sync  和 log  file  parallel  write 的等待差异，也许能看出差异，有了归档，可能log  file  parallel  write 会增加，当然log  file  sync 也会增加。)


如果你可以定义  20万个提交多产生一个检查点  为 频繁的检查点发生，那也可以，虽然这依然和楼主的本意不符合。你举批量和频繁提交之间的差异，不能解释他的同是 频繁提交下   归档和非归档的差异。

披发头陀

最初由 jametong 发布
[B]

RAID5 写数据的时候是非常慢的,

对于写道磁盘的数据都要进行奇偶校验, 速度会比raid0+1要慢好几倍呢

http://www.baarf.com/

[/B]

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