Before Image and VST

[Jens]

Hello,

does anyone know how to read the Before Image Threshold (-bithold) from VST?

Also: where do I find the current size of the bi-file, should I look up the right file in _fileList or is there any other way? There's is a _DbStatus._DbStatus-BiSize and these it doesn't seem to be the same as _fileList._fileList-size.

I'm using 9.1D.

Regards Jens

 

[Norman Biggar]

I use the following on 9.1C. The "Primary Recovery Area" is your before image extent

DEF VAR fPercent_Full AS DEC NO-UNDO.
FOR EACH _AreaStatus NO-LOCK:
  ASSIGN fPercent_Full = _AreaStatus-HiWater
                       / _AreaStatus-TotBlocks
                       * 100.
  DISPLAY  _AreaStatus-AreaName    LABEL "Area Name"
           _AreaStatus-TotBlocks   LABEL "Total Blocks"
           _AreaStatus-HiWater     LABEL "Used Blocks"
           fPercent_Full           LABEL "Percent Full".
END.

 

[Jens]

Thanks,

anyone who knows how to get the bithold, before image threshold, parameter from VST? What I really want to do is keep track of the bi-usage and the threshold so I can avoid a stall.

Regards
Jens

 

[toby.Harman]

Turn off bithold and manage the same effect through a monitoring program. This could issue a proquiet on the database (same effect as a bithold) and everything else.

Then when you have to grow the .bi file it can check a table entry to determine the current limit.

bithold shouldn't be that necessary for you on 9.1D since the .bi file can grow. If you want to force the issue - give the database as much bi space as you can possibly manage in fixed extent .bi files.

Second thing - Find the wretch who is writing code which creates transactions and waits and explain what a bad idea this is. Be foreceful! A good rule is "A Transaction should NEVER span a user interaction". Or in other words the user should never be able to press a key while a transaction is active. This should include exclusive locks (use no-wait) as well as messages (alert box or otherwise). In other words, validate all the data that you want before you start the transaction and then start the transaction.

Having worked on a v8.2 site that averaged one bi blow-up every 6 months on databases up to 220GB (total data under management = 2TB) I can assure you that this rule will save you in more ways than 1!

 

[CtL]

I agree totally with Toby about not worrying about the bithold anymore, and about using a club on developers who invoke these huge transactions, and users who leave them open. There are ways to detect long open transactions using VSTs.

BUt to answer your original question: I don't see a way of getting that info out of the VST tables. I didn't check everything, just a cursory look, and that info did not seem available.

You could issue an automated promon call and scrape the value out of it. Under v8 I had to do that to get total requests.

Good luck!