原先的report在Production DB上跑，已经使得其不堪重负。User多次反映有时速度很慢，影响工作效率。

Standby Database for report。

原先的report在Production DB上跑，已经使得其不堪重负。User多次反映有时速度很慢，影响工作效率。

RHEL4 + 9IR2

目前已经有一台Physical Standby Database，但主要目的是备援，不适合用来做Report DB。

因此需要另外再搭建一台standby database for report.

详细搭建不多说，这台Report DB的LOG传输和LOG apply完全靠OS上的机制。

9ir2的Standby database本可以从另一个standby DB上接收Archived log,这个称作cascaded redo log destinations。这种机制依赖于LGWR transport method，这对于Server负载本已经很高的Production DB来说，依然是负担。

所以还是依靠CRON & shell来实现从现有的standby DB上拉回Archived log。

首先要和应用人员确定可以用来Apply Archived log的时间段，然后再确定一次Apply需要多久的时间。

以上确定好之后，便可以确定CRON中Job的时间设定。

由于一天产生的Archived log数量众多，因此会分时先将Archived log通过SCP先Copy过来。

COPY的shell:

#!/bin/sh

if [ ! ${#} -eq "3" ]; then

echo "Usage is "

echo $0 '"a trusted host" "archived log dest" "time range"'

exit 1

fi

copyfile='/tmp/ready_to_copy.lst'

export copyfile

ssh $1 "/usr/bin/find $2/*.arc -mmin -$3" > $copyfile

cat $copyfile | while read FILENAME

do

scp $1:$FILENAME $2

done

然后在每天的特定时间段便可Apply log。

主要还是调用这样一段SQL:

host echo "Shutdown Database!!"

shutdown immediate;

host echo "Sleep 35 secs"

host sleep 35;

host echo "Start Database Mount!!"

startup nomount;

host echo "Alter database mount standby database;"

alter database mount standby database;

host echo "Recover standby database automatically"

recover automatic standby database;

host echo "Alter database open read only"

alter database open read only;

目前运行一周多正常。只是在Report DB的V$archived_log上的信息不能同步。