Printable View
We have a standby databse that graps archive redo logs from the live server and applies them. The problem is sometimes that logs get corrupted in transfer.
Does any of you know of a way to check whether a log has been corrupted and then request the archive redo log again.
What might be happening is that the standby is grabbing the archivelog while it is still being written. If you use Oracle's method whereby the files are SENT by the prod machine this will not occur (need to look in the Friendly Manual for that).
You don't say what OS you're running. Under NT, I also have the standby PULL the files from prod:
On prod server:
- periodically MOVE archlogs to another directory - this fails due to OS locking if the archlog is not completely written (apparently this does not provide protection under UNIX). Any missed files are moved in the next cycle.
- zip the archlogs (this saves a factor of 5 in size - less network load)
On Standby:
- periodically "grab" the zipped files, unzip and apply. The unzipping will fail if there has been corruption in network transfer (never happened yet).
gopi, how did you get on doing this under UNIX?
I wrote a shell one script (UNIX):
1. tnsping to make certain the standby is alive - end script if dB is unreachable.
2. gzip all archive logs that currently are not zipped (minus 1 - the latest)
3. scp (secure copy) all archives.gz to standby box
4. remote shell pri --> sec (ssh standby.k): issuing the gunzip command
5. remote shell pri --> sec (ssh standby.k): enter sqlplus on the standby box, recover the log file.
6. sleep 60
7 go to 1
Additional Notes: I have received a memo of an undocumented feature in 9.2 where we can tunnel ssh and therefore, compress the archive logs under the auspices of Data Guard. This will be documented under 10i. I will read the doc and finally go with Data Guard after I test it out.
### One iteration of the loop
###################
## 1. zip the log #
###################
gzip $file
ls -l $file* | awk '{print $5 " " $6 " " $7 " " $8 " " $9}'
echo `date` "zip done..now send to oracle@${STANDBY_BOX}:${STANDBY_DIR}/."
####################
## 2. send the log #
####################
scp -rp $file.gz oracle@${STANDBY_BOX}:${STANDBY_DIR}/.
echo `date` "send done.... "
########################################################
## 3-4. unzip the log at the remote site and recover ##
########################################################
echo "the target box: " $STANDBY_BOX
$BIN/ssh -l oracle drdb "/d01/oracle/admin/scripts/standby.k"
echo `date` "$i End: $file "
echo "----------------------------------------------------------"
You guys lost me on this one.
Why are you manually moving archived redo logs??
Why are you not using Standby redo logs?
We're doing it the steam-powered way to have the opportunity to zip/compress the logs. gopi says that Oracle won't do it for us until 10i or 9.2 perhaps.
Thanks for the explanation Dapi.
You guys aleady know about the potential for data loss when using ARCH and archive logs vs LGWR and SRLs right?
Yes....the potential for data loss must be tolerated. In my case, It is one archived log (the most recent) plus whatever is in the on-line log plus any log that may be archived during the 1 minute of sleep.Quote:
Originally posted by BJE_DBA
You guys aleady know about the potential for data loss when using ARCH and archive logs vs LGWR and SRLs right?
Since I need compression and a manual process, my company must either increase the speed of the network so I don't need compression OR tolerate the loss.
I need to read and learn about current undocumented compression (mentioned in my last post) with the Data Guard product. It will be well documented in 10i.
I think corruption is happening in the process of the way you are moving logs and appying to standby. If you tweak into this process and give litle time delay for generation of logs and movement and application, there will not be any issues.Quote:
Originally posted by gerpat
We have a standby databse that graps archive redo logs from the live server and applies them. The problem is sometimes that logs get corrupted in transfer.
Does any of you know of a way to check whether a log has been corrupted and then request the archive redo log again.
You can fix the problem at root rather find a way to test your logs frequently which is tedious effort.
Six months too late, I found this:
http://metalink.oracle.com/metalink/...G&p_id=2665536
. . . of course! We should check V$ARCHIVED_LOG . . . .
Never too late for an interesting topic and a find from MetaLink.
Yeah, V$ARCHIVED_LOG is a good idea and so is writing in PERL so that the 'agent' can be platform independant.
thnx
Agree about the Perl bit too (don't let Jeff know) - started using it last Monday and I'm sold. (Only prob I have is that the doc is written for people with a background in Unix and who know C already - no mention of 360/OS Control Blocks anywhere.)
Thanks Jeff! I think? Not sure about the Dummies bit . . .
. . . could it be a technical term for some one who uses a Win32 version?