ID duplicate in RAM db
We got the follow exception in the RAM:
00000050 SystemOut O CRRAM0001E 554520453 ERROR ws com.ibm.ram.repository.web.ws.core.RAM1Impl - One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "3" constrains table "RAMSCHEMA.REPOSITORYMETRIC" from having duplicate values for the index key.
com.ibm.ram.repository.core.IRepositoryAccess$RepositoryException: One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "3" constrains table "RAMSCHEMA.REPOSITORYMETRIC" from having duplicate values for the index key.
at com.ibm.ram.repository.core.sdo.BaseRAMSchemaAccess.addMetric(BaseRAMSchemaAccess.java:10640)
at com.ibm.ram.repository.core.sdo.BaseRAMSchemaAccess.addMetric(BaseRAMSchemaAcce
We checked this table schema and run this SQL on it:
SELECT INDNAME, INDSCHEMA
FROM SYSCAT.INDEXES
WHERE IID = 3
AND TABSCHEMA = 'RAMSCHEMA'
AND TABNAME = 'REPOSITORYMETRIC'
It shows INDNAME: C4752929, that means the PK "ID' is not duplicate.
This "ID" seems controlled by RAM application, it is not using auto create base on database control.
Should we stop all RAM application and restart Db to resolve this problem?
00000050 SystemOut O CRRAM0001E 554520453 ERROR ws com.ibm.ram.repository.web.ws.core.RAM1Impl - One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "3" constrains table "RAMSCHEMA.REPOSITORYMETRIC" from having duplicate values for the index key.
com.ibm.ram.repository.core.IRepositoryAccess$RepositoryException: One or more values in the INSERT statement, UPDATE statement, or foreign key update caused by a DELETE statement are not valid because the primary key, unique constraint or unique index identified by "3" constrains table "RAMSCHEMA.REPOSITORYMETRIC" from having duplicate values for the index key.
at com.ibm.ram.repository.core.sdo.BaseRAMSchemaAccess.addMetric(BaseRAMSchemaAccess.java:10640)
at com.ibm.ram.repository.core.sdo.BaseRAMSchemaAccess.addMetric(BaseRAMSchemaAcce
We checked this table schema and run this SQL on it:
SELECT INDNAME, INDSCHEMA
FROM SYSCAT.INDEXES
WHERE IID = 3
AND TABSCHEMA = 'RAMSCHEMA'
AND TABNAME = 'REPOSITORYMETRIC'
It shows INDNAME: C4752929, that means the PK "ID' is not duplicate.
This "ID" seems controlled by RAM application, it is not using auto create base on database control.
Should we stop all RAM application and restart Db to resolve this problem?
6 answers
Hi,
This happens because the AUTOKEYGEN table, NEXT_METRICS column is not
greater than all of the ID's in the metrics table.
The usual way this occurs is because there are two separate instances of
RAM that are using the same physical database and the instances are not
part of a RAM cluster.
Another way is that the database was somehow updated/manipulated outside
of RAM, such as someone running an SQL script against it.
Or what version of RAM do you have? There was a bug in this area in a
really, really old early version of RAM.
--
Rich Kulp
Rational Asset Manager developer
This happens because the AUTOKEYGEN table, NEXT_METRICS column is not
greater than all of the ID's in the metrics table.
The usual way this occurs is because there are two separate instances of
RAM that are using the same physical database and the instances are not
part of a RAM cluster.
Another way is that the database was somehow updated/manipulated outside
of RAM, such as someone running an SQL script against it.
Or what version of RAM do you have? There was a bug in this area in a
really, really old early version of RAM.
--
Rich Kulp
Rational Asset Manager developer
Hi,
I don't know what 7.2.5 is. We never released a 7.2.5.
But when I said old, I meant back in 7.0 and early 7.1 days.
The doesn't happen in normal processing. But the fix is to find the
highest ID in the RepositoryMetrics table and then update the
AutoKeyGen.Next_Metrics column to be one more than that.
--
Rich Kulp
Rational Asset Manager developer
I don't know what 7.2.5 is. We never released a 7.2.5.
But when I said old, I meant back in 7.0 and early 7.1 days.
The doesn't happen in normal processing. But the fix is to find the
highest ID in the RepositoryMetrics table and then update the
AutoKeyGen.Next_Metrics column to be one more than that.
--
Rich Kulp
Rational Asset Manager developer