on 2020 May 11 11:23 AM
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
67 | |
10 | |
10 | |
10 | |
10 | |
8 | |
8 | |
6 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.