All, This is one that can have consequences. Here are my words of caution...
Ian Stuart asked: how would this impact on the use of rsync on frequent (every 10 minutes) replication? The proposed snap/rsync cycle for a valid backup: 1) quiesce the database (Functional equivalents UDT DBPAUSE or UV SUSPEND.FILES ON) 1a) the sync call is initiated here to clear the disk buffers and write to the disk subsystem 2) snap of the database (Functional equivalents Flash Copy, BCV, advfs, etc.) 3) resume the database (Functional equivalents UDT DBRESUME or UV SUSPEND.FILES OFF) 4) copy the snapped copy of the database via rsync to a remote system or directory for backup 5) abandon the snapped copy (release the disk space) The above is valid for a replicating on an infrequent basis, say: + once in the evening for a backup and + maybe once in the middle of the day during a super slow time (like lunch) As comparative analysis of other shops, we observe most shops only doing the evening backup snap, and never one in the middle of the day. However, it is NOT RECOMMENDED for short term intervals at all. We do not see shops using it in short intervals. It is atypical for super short intervals for the duration of the quiesce, snap & resume to be 2 seconds or so. It is more common to have timings of 15 seconds to 2 minutes, depending completely on the ability of the disk subsystem to handle the flushing of the disk buffers via the sync command initiated! Most common is over a minute. One shop we are aware of it takes over 10 minutes to flush the disk buffers via a sync. Please note that Tom stated he has a under utilized system, which is atypical. Most of us live with heavily used systems. A sync is a tremendous drain on the system. All writes immediately stop. The sync writes take precedence over every other I/O on the system, including reads! The sensation on the system is like the way my grandmother used to drive her car - with both feet! It is either full on the gas (system running fine) or full brakes (the sync has been started). As if that's not bad enough, the rsync copy can saturate a communications channel (network card) for the duration of the rsync! Yuck! This has had profound adverse impact on web performance at some sites. For applications that are really closely monitored, say a socket, can fail! OK, so you can have a wheel fall off the car when you weren't expecting it. :-) Therefore, we do not recommend the cycle as an alternative to the Transaction Logging capabilities of the Databases (UDT RFS & UV TL), which are designed for much closer intervals, and less drain on resources. It's a great idea that works extremely well for backup scenarios! Other implications preclude it from being used in short time frames. Steve Stephen M. O'Neal Lab Services Sales for U2 IBM SWG Information Management Lab Services ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
