Results 1 to 2 of 2

Thread: exceeded enqueue quota in batch inserts

  1. #1
    Boaz Newman is offline Support
    Join Date
    Aug 2006
    Rep Power

    exceeded enqueue quota in batch inserts

    An error %RMS-F-EXENQLM, exceeded enqueue quota, is generated upon an insert of large amount of records. Since the insert is done in a write mode and each new RMS record is locked, then a large amount of concurrent locks is used. If the amount of locks needed, is greater then the value that the user is authorized to have in his ENQLM quota, an error is generated.
    A solution to this problem can be achived by using the parameter qpInsertFromSelectCommitRate, it will cause the Attunity RMS driver to work in batches specified by the parameter.
    For example, if an insert of 15,000 records is done in one operation, using qpInsertFromSelectCommitRate=1000, will cause the insert to be done in batches of 1000 and by that, a maximum of 1000 concurrent locks will be used, insted of 15000.
    In the binding environment add a temp feature with the id of qpInsertFromSelectCommitRate and a value of the preferrd number of records.
    Last edited by Boaz Newman; 11-19-2007 at 11:26 AM.
    To Find Out more About Attunity Technology:
    Contact Us

  2. #2
    Hein is offline Senior Member
    Join Date
    Dec 2007
    Nashua, NH - USA.
    Rep Power

    RAB$V_ULK = Manual unlocking

    Thanks for the note Boaz.

    Good warning/workaround.

    This does however suggests that Attunity uses the rms 'ULK', or is using the RMS RUJ (Run Unit Journalling).

    If it was using RUJ then that surely would have been indicated (does Attunity even support RMS RU semantics?)

    If it is using ULK, then I'd like to understand why?
    This is a relativey rarely used option un $PUT.

    It can present semi-transactional semantics, but is that not like being 'a little bit pregnant'?
    Records will be present in the file, but not yet visible to others.
    However, if the process where to die, the records would become real.

    So maybe ULK could (should!) simply be dropped during a $PUT?

    Or... What if you take the EXENQLM as sign to just do the SYS$FLUSH and SYS$FREE call IFF (and only if) there were more than 1 records put?
    That's what will happen if you exit anyway.
    After the $FREE it could try again and continue IFF (and only if) the first put does not again return the error again, suggesting an external cause?

    Hope this helps,
    Hein van den Heuvel
    HvdH Performance Consulting

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts