default behaviour is that data extents are opened in async mode. writes are performed with pwrite() system call. data are flushed at end of checkpoint cycles by using fdatasync().
also, we do write-ahead logging to an undo-redo log, with a buffer management policy of lru, steal, no-force.
What is it you are trying to achieve? It's not clear to me. Also, what OS is the database on? Windows is really bad at updating time stamps on things.
Hi [mention:77cbb45621a246f9a1a1f2f378e535b1:e9ed411860ed4f2ba0265705b8793d05], thanks for your quick reply.
My client are trying out replication using rsync, which only replicate modified files. Their server is running on IBM AIX 5.1 (64-bit).
I was informed that the replication does not reflect with the latest data on their replicated environment, but only if they script to replicate the whole database (with all the .bi, extends, etc) then the replicated environment will have the latest data.
Kindly advise.
Thank you.
Ah yes that makes sense. I'm not sure about AIX as I've never used it, but I'd be surprised if the modified date and time of the extents is updated with every write on the db. I could be wrong of course.
What do they want the replica for? Is it for backup? If they want to have read only access to the data on a replication target then IMO they should look into OE replication.
It is for their disaster recovery site.
The replication destination should be r/w. Do you still think I should look into OE replication?
TIA.
Is there any documentation on how the database writes back to the extends? So I can better inform my client about this.
Thanks.
[quote user="Tai Li"]
My client are trying out replication using rsync, which only replicate modified files. Their server is running on IBM AIX 5.1 (64-bit).
[/quote]
If you're trying to do this with a live database, then stop now - the data rsycnc will get to the target machine will not be in a consistent state, and the resulting set of db files can not be trusted. You _might_ get away with setting a quiet point, copying the db, and then letting the db go, however that would take time, and setting a quiet point will also suspend db (and user) activity. If that's not an option, then do an on-line backup to a target location and then sync that.
OE Replication is the only way to keep a live db up to date with a target database on a DR machine in a reliable fashion.
default behaviour is that data extents are opened in async mode. writes are performed with pwrite() system call. data are flushed at end of checkpoint cycles by using fdatasync().
also, we do write-ahead logging to an undo-redo log, with a buffer management policy of lru, steal, no-force.
Thanks everyone for your suggestions and inputs.
Also, I have found a KB article, "How to use os-copy for recreating a replication target database?" (knowledgebase.progress.com/.../P143492) which method uses PROQUIET and a third party online backup tool.
Hope this helps.
I still recommend probkup.
Thanks [mention:6911e6cc8725416dba58ae08a80faffd:e9ed411860ed4f2ba0265705b8793d05] for your advice, will keep this in mind.
Note that in addition to probkup being supported and not subject to the qualifications and gotchas of os methods, it also is doing a certain amount of checking on the integrity of the database which will provide early detection of some kinds of corruption.