RMS Journaling for a backup site ?

[labadie_1]

Hello

Sorry if this has already been asked.

A site uses no database, but only indexed RMS files.

I was wondering if "After Image" of RMS Journaling could be used to keep a remote and backup site in synch ?

Copy regularly the After Image journal and apply it
rms/recover/forward...

http://h71000.www7.hp.com/doc/72final/4454/4454pro.html#bottom_main

I wonder how the performance will be impacted by RMS journaling ?

Do the file id for the same file has to be the same on the remote and local file ?

Thanks for any hint

[Hein van den Heuvel]

Yes, RMS AI (After Image) Journalling can be used keep backups up to date, remote or not.

That is largely what it was designed to do, except that it was intended for incidental usage on a freshly restored file (with a new file-id). It is not easy to 'switch' a log in order to ship it.

There are ways to 'snarf' the changes from its log for ungoing updates on regular intervals (several minutes).

RMS AI Journalling is BUCKET based. 

This have 2 implications

1 - The backup must be a true copy. The backup timestamp is used to compare.

After a convert on the source, the backup must be refreshed.

2 - If a records changes, not just the record is written out but the whole bucket (up to free byte indicator) and any changed (alternate) index bucket or area descriptor.

That is a lot of overhead disk-space, MB/sec and IO/sec.

CONNX has an interesting Change data capture tool which is checksum based. I don't know enough details but it comes with an infrastructure to cschedule updates and it has the potential to fold multiple updates to the same bucket together. It is failry common for applications to write multipe records to the 'last bucket' in the file or around certain key values.

ATTUNITY, where I work, has the most interesting options I'd like to think.

We offer an intercept based solution where only the changes data records are written to a log.

So the overhead is  1 or less extra IO per RMS actions where that RMS action may be 20+ IOs (read through 2 or 2 indexed, update leaf nodes, update areas).

There is an solid (many years, many sources, many targets) infrastructure to move the changes into an off-box  staging area where they can be consumed by ETL tools to keep other databses in sync near-realime (seconds)

I have created some extra tools to facilitate direct OpenVMS - OpenVMS file updates. Those could work on true copies, on converted files, or even against empty files (just accumulating fresh records). This bolt-on would be used in intervals of a few minutes or hours as needed, or could be volume based. We can request a fresh log any time, and we can request a fresh log when a selected size is exceeded

You know where to reach me!

Hope this helps

Hein van den Heuvel

[labadie_1]

Hein

Thanks for your valuable input.