原先的report在Production DB上跑,已经使得其不堪重负。User多次反映有时速度很慢,影响工作效率。
[@more@]
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上的信息不能同步。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10856805/viewspace-998093/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/10856805/viewspace-998093/