The problem here is that the database is using Omnidex keys. Omnidex
internally uses the transaction manager while updating the Omnidex indexes
and under certain conditions it can create a huge transaction and create the
"STALLED TRANSACTION" condition.
This will particularly happen right after you delete a large number of
entries in a dataset indexed by Omnidex (particularly using the multiple key
option that indexes key words in a field) and then start doing DBPUT's to add
new entries to the dataset. When you start doing PUT's omnidex tries to
clean up the tree structure and overflows the transaction manager. In our
particular installation our DBDELETE's are isolated within one job. After
this job completes we use ADAGER to repack the offending dataset and this has
eliminated the problem. This solution may not work if you are not as
fortunate to have the DBDELETE's convienently isolated so that you can do a
repack immediately afterwards.
In article <[log in to unmask]>,
Larry Boyd <[log in to unmask]> wrote:
>
> On Thursday, March 26, 1998 11:26 PM, emania [SMTP:[log in to unmask]] wrote:
> > I work for an unamed software company supporting programs written on
> > HP3000. We have never utilized HP logging correctly from what I have
> > heard. We have been noticing that we are getting alot of calls
> > regarding the TRANSACTION MANAGER. Actual message reads:
> > STALLED TRANSACTIONS.....log is full....or something to that nature.
> > Because we use a Third Party Index in addition to our Image indexes
> > the normal practice would be either one of two things:
> >
> > a.) Turn off Transaction Manager for the OMNIDEX keys and re-index
> > them.
> >
> > b.) RELOAD the affected datasets and then re-index them leaving XM on.
> >
> > Is there a way to avoid these errors, and is there a better way to
> > deal with thm?
> >
>
> As I understand the problem, "Stalled Transactions" occurs when you write
"too
> many" transactions within a single XM transaction. With TPI, this does not
> normally occur unless you are using DBX... for logical transaction
integrity.
> If you are not using DBX... calls, you problem have a very large IMAGE
record
> with several indexes. If this is the case, about the only workaround is to
> remove some of the indexes.
>
> If you are using DBX... calls, you might try to adjust the IMAGE calls, so
the
> actual XM transaction is smaller. This is not always possible, since you
may
> not be able to adjust the definition of a logical transaction.
>
> Generally, XM with IMAGE and TPI works like this with DBX... calls.
>
> DBXBEGIN A begin transaction record is written to XM.
> DBupdate calls A transaction record for the IMAGE update
> (DBPUT,DBDELETE, is written to XM. Additionally, since
> DBUPDATE) you have TPI on the data set, a
> transaction record is written for each
> TPI update.
> (Of course, you probably have *many* IMAGE
> calls within this DBX transaction)
> DBXEND An end transaction record is written to XM.
> (DBUNDO will roll back the transactions in XM to the DBXBEGIN)
>
> If you do not use DBX... calls, a begin transaction record is written just
> prior to the IMAGE update transaction, and an end transaction record is
written
> just after the last TPI transaction.
>
> Hope this helps.
>
> LB
>
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
|
