Red Hat Bugzilla – Bug 748484
Make dbupgrade sequence id cache size configurable
Last modified: 2013-08-31 06:08:32 EDT
+++ This bug was initially created as a clone of Bug #748483 +++
+++ This bug was initially created as a clone of Bug #728547 +++
currently dbssetup and dbupgrade both hardcode the cache size to 10, e.g.:
CREATE SEQUENCE SEQ_FOO
START WITH 10001
We should make this a configurable option and increase the value for most of our tables.
--- Additional comment from firstname.lastname@example.org on 2011-10-20 08:42:02 EDT ---
For stuff that rarely changes (think e.g. resources / resource types / ..) 10 is probably good so that we don't have huge holes in sequences when RHQ is restarted inbetween; or perhaps 20 .. 50 for other things (call time data or events ?) where larger values would sure be beneficial.
--- Additional comment from email@example.com on 2011-10-24 10:34:41 EDT ---
When there is a mistake as in this:
You will get this sort of error:
/home/rbuck/dev/sandboxes/rhq/modules/core/dbutils/src/main/scripts/dbupgrade/db-upgrade.xml:27: Failed to upgrade - error in spec version [2.115]. Cause: Error executing the task [org.rhq.core.db.ant.dbupgrade.SST_CreateSequence] in schema spec version [2.115]. Cause: Database SEQID Cache Size is not an integer: WOOF
To specify NOCACHE:
N.B. that for some open-source databases NOCACHE means "1", which effectively means they really don't support NOCACHE in the true sense of the word.
If the CACHE size specified is identical to the factory defaults, no CACHE terms will be applied to the generated SQL.
All negative values are mapped to the mode of using factory defaults, whatever they may be.
We need to have someone test MS Sql Server; here are the steps to test:
1. Change db-upgrade.xml:
2. Change POM.xml:
--- Additional comment from firstname.lastname@example.org on 2011-10-24 11:02:02 EDT ---
Author: Robert Buck <email@example.com>
Date: 2011-10-24 11:00:54 -0400
[BZ 728547] Make SEQID cache sizes configurable; the new solution supports NOCACHE and CACHE semantics, it supports factory default sizes; for cases where factory default sizes are larger than the previous default value of 10, we opt for the factory default sizes.
being backed out of jon 3 branch. see https://bugzilla.redhat.com/show_bug.cgi?id=752408
ms sql server is out of scope.
upgrade testing on oracle and postgres completed
Bulk close of old bugs in VERIFIED state.