no more lock?
Posted in 2000
Topics: Data Types & Schema Design, Triggers, Constraints & Referential Integrity
I tried to execute some SQL statements like
SELECT UNIQUE id FROM aTable;or
DELETE FROM aTable WHERE theTime < TODAY-10;
where that data type for column theTime is timestamp.
I got "no more lock" error message. Is because I use buffered log?
Should I make my database to unbuffered log or no log?
Or something else?
We insert a row to aTable every 15 minute for more than 8,000 IDs.
The column id is not a primary nor unique key, it is foreign key.
I can do
DELETE FROM aTable WHERE id = '12345678' AND theTime < TODAY-10;
that's OK, but I need to get the unique id number without "no more lock"
error message.
How can I avoid that?
--
Why we want to teach our babies to talk and walk,
then later we tell them "sit down!", "be quiet!" ?
Democracy is not a better way for a solution,
it is just another way to spread the blames.
--Raymond
Raymond Chui wrote:
>
> I tried to execute some SQL statements like
>
> SELECT UNIQUE id FROM aTable;> or
> DELETE FROM aTable WHERE theTime < TODAY-10;>
> where that data type for column theTime is timestamp.
>
> I got "no more lock" error message. Is because I use buffered log?
> Should I make my database to unbuffered log or no log?
> Or something else?
The ONCONFIG parameter LOCKS controls how many locks are configured at
startup. You have to edit the ONCONFIG file and shutdown and restart the
server to increase this value. Alternatively look at my utility dbdelete
which performs large deletes be breaking them up into smaller transactions
to avoid running out of locks or creating a long transaction. Dbdelete is
part of the package utils2_ak in the IIUG Software Repository.
> We insert a row to aTable every 15 minute for more than 8,000 IDs.
> The column id is not a primary nor unique key, it is foreign key.
>
> I can do
>
> DELETE FROM aTable WHERE id = '12345678' AND theTime < TODAY-10;>
> that's OK, but I need to get the unique id number without "no more lock"
>
> error message.
> How can I avoid that?
See above.
Art S. Kagel