|
We have a central database which uses the GLOBAL AUTOINCREMENT way to generate primary keys in a sqlremote environment. So far this works fine and the keys are just as they need to be. We have defined an event which assigns a new global_data_id when the available range is near the end of the range and RemainingValues < 50000 Most of the time this event works fine, but every 1-2 months the DB gets stuck for many minutes before the new global id is assigned, which then raises I. 05/11 13:13:44. Finished checkpoint of "xxx" (xxx.db) at Mon May 11 2020 13:13 I. 05/11 13:28:27. Setting new dbID with [set option public.global_database_id = 357] I. 05/11 13:28:27. Setting new dbID with [set option public.global_database_id = 357] I. 05/11 13:37:47. Setting new dbID with [set option public.global_database_id = 358] I. 05/11 13:46:29. Setting new dbID with [set option public.global_database_id = 357] I. 05/11 13:46:29. Setting new dbID with [set option public.global_database_id = 357] I. 05/11 13:55:05. Setting new dbID with [set option public.global_database_id = 358] I. 05/11 14:03:45. Setting new dbID with [set option public.global_database_id = 357] I. 05/11 14:13:07. Setting new dbID with [set option public.global_database_id = 358] I. 05/11 14:13:36. Starting checkpoint of "xxx" (xxx.db) at Mon May 11 2020 14:13 What is the clean way to increment the global database id when the db is under heavy load? |
|
Is it possible that this event runs with more than one instance now and then, trying to increase the GlobalDatabaseID in parallel? If so, adding a condition within the handler code such as ...
IF EVENT_PARAMETER('NumActive') = 1 THEN
... -- set the option
END IF;
...
might help. |
FWIW, it this somewhat related to this much older question?
Yes, I think it's the very same problem. I have implemented the numActive test, let's see if it helps
The difference is, until one month ago we had ASA 10.x in use, now we are at 17.0.10.6041 and that the load is much higher now