Dec DTM / RMS - aij file filling up disk space

[TMcB]

Hi
We are using Dec DTM and RMS, and have a problem where the recrms_server process appears to be quickly filling up 2 aij files until the disk runs out of space.

Does anyone know how we can find out what is causing the aij files to fill up.

Any help is much appreciated
Thanks

[Hein van den Heuvel]

RMS AIJ journal filed are supposed to fill up the disk! They record all changed buckets. An application using them is supposed to have a procedure in place to deal with that. Just about the only thing you can do to control this is to pick the smallest possible bucket size which still gives acceptable performance.
And using the Norm's Journal snap tool ( http://h71000.www7.hp.com/freeware/freeware40/rmsjnl/ ) you can move away the data and reset the file 'online'.

Now you mention the recovery server triggering the writes? So the application also have RU journalling on some/many files and transaction need to be undone all the time? If the files involved are marked for AIJ, then that could require AIJ writes.

Is this a new behaviour for the application or has it always been like this?
Has it slowly been getting worse? More load?

Hope this help some,
Regards,
Hein van den Heuvel
HvdH Performance Consulting.

[TMcB]

Hello Hein

This has just started happening.
We have quickly had to get a workaround by keeping journalling off for now.

But when we start DTM - the rms rec process appears and the 2 files start growing enormously.
The only errors i can see are in operator.log :
%RMSREC-F-OPRSERVER, error occurred during detached recovery unit recovery; process ID (PID) 4DA3BA5D
which is followed by a device full message. 

Also, how can I find out what our 'bucket' size is?

Thanks

[Wim Van den Wyngaert]

Is this your problem ?
http://h71000.www7.hp.com/DOC/72final/4454/4454pro_011.html

Wim

[Hein van den Heuvel · Accepted solution]

>> This has just started happening.

Ok. So something broke.
What changed recently?
Nodename?

>> We have quickly had to get a workaround by keeping journalling off for now.

You know you will have to re-backup marked for journal to eventually restart right?

>> But when we start DTM - the rms rec process appears and the 2 files start growing enormously.

So does DecDTM start at all?
And now that the files are no longer marked for AIJ, does the recovery server behave?
Does a simple test work?

The Recovery server takes cares of RU Journalling, is rather independend of AIJ journalling.

Are transactions going wild, for example locking too many records, dying and the subsequent rollback caused too much AIJ?
Over tiem transaction growth could make this appear as a sudden change.

Check ACCOUNTING for application abends.

>> The only errors i can see are in operator.log :
%RMSREC-F-OPRSERVER, error occurred during detached recovery unit recovery; process ID (PID) 4DA3BA5D
which is followed by a device full message.Ã

That looks like an effect, not a cause.

>> Also, how can I find out what our 'bucket' size is?

Oops... slowly step back from that computer, do not touch anything else, call support!
:-)

Seriously if you do not know what a bucket is, then you are probably not the right person to try to deal with this problem.

A bucket is a unit of transfer for an RMS indexed file. Changing the size is a major decision and involves file converts.

Regards,
Hein.

[TMcB]

good reply -
Please excuse my ignorance. I'm not an rms person - I look after VMS. I would not even attempt to modify the application.

The problem, it turns out, was caused by the application people making changes they didnt think were important enough to mention.

[Hein van den Heuvel]

>> good reply -

Thanks! One tries.

>> Please excuse my ignorance. I'm not an rms person - I look after VMS. I would not even attempt to modify the application.

No problemo. However... IMHO... you can not be an effective VMS system manager without knowing the basics of RMS and indexed files in particular. Start with understanding SYSUAF, MAIL.MAI and the likes to stay in your own area. Once you know the basics start lookign aroufn in application space: ANAL/RMS (or my TUNE_CHECK), CONVERT and so on.

I'm not talking about changing the
application, just about understanding what it does to the OS, how resources are consumed, and over time how to improve it all.

>> The problem, it turns out, was caused by the application people making changes they didnt think were important enough to mention.

Excellent! The old 'what did you not change' question huh?
Did they manage to somehow blame you anyway? :-).

Regards,
Hein van den Heuvel
HvdH Performance Consulting.

[Ian Miller.]

"The problem, it turns out, was caused by the application people making changes they didnt think were important enough to mention."

I didn't do anything. Well, all I did was....

How many support calls proceed like this - too many :-(

[Jan van den Ende]

Hein wrote:


No problemo. However... IMHO... you can not be an effective VMS system manager without knowing the basics of RMS and indexed files in particular.
Start with understanding SYSUAF, MAIL.MAI and the likes to stay in your own area. Once you know the basics start lookign aroufn in application space: ANAL/RMS (or my TUNE_CHECK), CONVERT and so on.


How true!
I prided myself to have some VMS knowledge.
Last Bootcamp I attended Hein's lecture on RMS performance.

Last summer I was to implement an update to an application that uses RMS files.

Now knowing somewhat more about the stuff, I looked trough the FDL files, and thought they were "less than optimal".
I contacted the (external) app suppliers, they admitted to noyt having anyone to give it any intention, as "it does the job".
They were however interested if I would be able to realise significant gains.

Applying Hein's guidelines, I modified the FDL files.

Soon after the upgrade, I got a call from a surprised and slightly worried application manager.
Some weekluy batch, which was usually running 45 - 50 minutes, had finished after 5. But any checks seemed to show it had run correctly.
And after a few days, several application users actually had reported the (interactive part of) the app "running so smoothly".

So: system managers knowing about RMS? _DEFINITELY_ a bonus!

(the FDLs have been supplied to the app maintainers, with instructions how to adapt them to use and file sizes).

Hein, thanks in the name of our users!

May many of us make this effort! (but I cannot guarantee such big gains, they require the app to be seriously mis-tuned before!)

hth

Proost.

Have one on me.

jpe