如果Oracle数据库运行在archivelog模式,当发生日志切换时,online redo log
files将被归档。确保磁盘对archive files有足够的空间是非常重要的,否则,ARCHn进程不能write就会造成crash。
首先,需要确定系统发生log switch的次数,可以使用下面的查询脚本进行查看,注意要将替换为redo log files的实际值(MB)。
使用该查询可以获得online redo log
files的大小:
SQL> select
distinct(to_char((bytes/1024/1024),'9990.999')) size_mb from v$log;
SIZE_MB
---------
10.000
50.000
注意:
在极少数情况下,会出现一个以上的值,就像上面我的查询。这是因为有不同size的redo log,为redo log设置不同size不能获得益处,我这里只是测试环境。
脚本:
column ord
noprint
column date_
heading 'Date' format A15
column no
heading '#Arch files' format
9999999
column no_size heading 'Size Mb' format 9999999
compute avg of no on report
compute avg of no_size on report
break on report
select MAX(first_time) ord,
to_char(first_time,'DD-MON-YYYY') date_, count(recid) no, count(recid) * no_size
from v$log_history
group by to_char(first_time,'DD-MON-YYYY')
order by ord
/
clear breaks
clear computes
clear columns
注意:
从Oracle8开始,增加了视图v$archived_log,该视图记录被归档的日志文件,这里也可以使用v$archived_log视图替代v$log_history。
该脚本的输出内容显示系统上每天log switch的文件数量和大小。如果某天没有发生log switch,则没有相应的记录。
首先需要确定的是每天的log switch数量是否稳定,是否每天差别很大。如果是稳定的,则计算平均数就是每天所需要的磁盘空间。如果变换很大,例如实例每周做一次批量upload,则这必须被考虑进来。
可以分析log switches的数量和相应的磁盘空间大小,是否随时间增加,这将决定是否要预留更多磁盘空间来满足将来archive files的增加。
示例一:
数据库每三天做一次冷备份,备份不包含archive files,但是要保留上一次备份后的archive files。数据库活动几乎稳定,redo log files的大小为5MB。
脚本输出内容如下:
Date
#Arch files Size Mb
--------------- ----------- --------
...
10-11月-2013 5 25
11-11月-2013 4 20
12-11月-2013 7 35
14-11月-2013 3 15
15-11月-2013 5 25
16-11月-2013 2 10
17-11月-2013 6 30
18-11月-2013 5 25
...
----------- --------
5 25
由于log switch数量是稳定的,因此可以用平均数计算:
25MB * 3
days = 75MB
20% = 15MB
------
90MB
额外附加的20%是允许一个安全限度。
因为我们也要保留上次备份后的archive files,所以:
90MB * 2 = 180MB
示例二:
每周日冷备份数据库,包括archive logs。每周一有一个批量作业执行大量upload。周二到周五数据库正常活动,周六几乎没有活动。redo log files的大小为1MB。
脚本输出内容如下:
Date
#Arch files Size Mb
--------------- ----------- --------
...
13-12月-2013 15 15
15-12月-2013 12 12
16-12月-2013 275 275
17-12月-2013 13 13
18-12月-2013 12 12
19-12月-2013 11 11
20-12月-2013 14 14
21-12月-2013 1 1
22-12月-2013 11 11
...
----------- --------
43 43
由于在一周之内archived files数量是不稳定的,所以这次就不能使用平均数计算。没有一个准确的公式可以计算,但是我们可以把一周的值全部加起来,再加上20%,就可以大致计算出结果。
sum =
338MB
20% =
68MB
------
406MB
整理自My Oracle Support,原文链接: