Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Data Warehouse upgrade fails from 3.0.1.3 to 4.0

Using sandbox environment to test upgrade of CLM applications all residing on one server

Windows Server 2008 R2 Enterprise 64 bit
Database: Oracle 10g Enterprise R2

Step 2 of JTS upgrade script fails
repotools-jts -upgradeWarehouse returns error CRJAZ1728E An unexpected error has been detected. See the log file "INSTALLDIR\server\repotools-jts_upgradeWarehouse.log" for more details.

LOG DETAILS
2012-08-28 12:24:53,972 CREATE TABLE RIODS.EXECRESULT_CATEGORY_LOOKUP(EXECUTION_RESULT_ID INTEGER NOT NULL, TEST_CATEGORY_ID INTEGER NOT NULL) TABLESPACE VNF_32K
com.ibm.team.repository.common.TeamRepositoryException: CREATE TABLE RIODS.EXECRESULT_CATEGORY_LOOKUP(EXECUTION_RESULT_ID INTEGER NOT NULL, TEST_CATEGORY_ID INTEGER NOT NULL) TABLESPACE VNF_32K
    at com.ibm.team.datawarehouse.service.AbstractDataWarehouseDbProvider.internalExecuteSql(AbstractDataWarehouseDbProvider.java:247)
    at com.ibm.team.datawarehouse.service.AbstractDataWarehouseDbProvider.executeSqlIgnoringGrantAndUserErrors(AbstractDataWarehouseDbProvider.java:123)
    at com.ibm.team.datawarehouse.service.oracle.internal.OracleDataWarehouseDbProvider.migrateDataWarehouseCoreTables(OracleDataWarehouseDbProvider.java:90)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:600)
    at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(ExportProxyServiceRecord.java:361)
    at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(ExportProxyServiceRecord.java:347)
    at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(ExportProxyServiceRecord.java:56)
    at $Proxy433.migrateDataWarehouseCoreTables(Unknown Source)
    at com.ibm.team.datawarehouse.service.internal.RemoteDatabaseService$2.run(RemoteDatabaseService.java:180)
    at com.ibm.team.datawarehouse.service.internal.RemoteDatabaseService$5.run(RemoteDatabaseService.java:254)
    at com.ibm.team.repository.service.internal.rdb.ConnectionPoolService.withCurrentConnection(ConnectionPoolService.java:381)
    at com.ibm.team.datawarehouse.service.internal.RemoteDatabaseService.write(RemoteDatabaseService.java:244)
    at com.ibm.team.datawarehouse.service.internal.RemoteDatabaseService.upgradeRemoteSchemas(RemoteDatabaseService.java:164)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:600)
    at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.invoke(ExportProxyServiceRecord.java:361)
    at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord.access$0(ExportProxyServiceRecord.java:347)
    at org.eclipse.soda.sat.core.internal.record.ExportProxyServiceRecord$ExportedServiceInvocationHandler.invoke(ExportProxyServiceRecord.java:56)
    at $Proxy408.upgradeRemoteSchemas(Unknown Source)
    at com.ibm.team.datawarehouse.service.internal.UpgradeDataWarehouseCommand.execute(UpgradeDataWarehouseCommand.java:19)
    at com.ibm.team.repotools.command.AbstractCommand.execute(AbstractCommand.java:66)
    at com.ibm.team.repotools.rcp.internal.RepositoryToolsApplication.run(RepositoryToolsApplication.java:768)
    at com.ibm.team.repotools.rcp.internal.RepositoryToolsApplication.start(RepositoryToolsApplication.java:843)
    at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
    at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369)
    at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:600)
    at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:620)
    at org.eclipse.equinox.launcher.Main.basicRun(Main.java:575)
    at org.eclipse.equinox.launcher.Main.run(Main.java:1408)
    at org.eclipse.equinox.launcher.Main.main(Main.java:1384)
Caused by: java.sql.SQLException: ORA-00955: name is already used by an existing object

    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:440)
    at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:396)
    at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:837)
    at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:445)
    at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:191)
    at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:523)
    at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:193)
    at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:999)
    at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1315)
    at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1890)
    at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1855)
    at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:304)
    at com.ibm.team.repository.service.internal.db.jdbcwrappers.stat.StatementStatWrapper.execute(StatementStatWrapper.java:178)
    at com.ibm.team.repository.service.internal.db.jdbcwrappers.errlog.StatementErrLogWrapper.execute(StatementErrLogWrapper.java:169)
    at com.ibm.team.repository.service.internal.db.jdbcwrappers.leak.StatementLeakWrapper.execute(StatementLeakWrapper.java:70)
    at com.ibm.team.datawarehouse.service.AbstractDataWarehouseDbProvider.executeStatement(AbstractDataWarehouseDbProvider.java:108)
    at com.ibm.team.datawarehouse.service.AbstractDataWarehouseDbProvider.internalExecuteSql(AbstractDataWarehouseDbProvider.java:227)
    ... 40 more

Any idea what the problem is and and how to fix it

Thanks in advance

Pierre

0 votes

Comments

I investigated further and found the solution to my problem. Since I was not able to update the warehouse from v.3.0.1.3 to v.4.0 using the repotools-jts -upgradeWarehouse, I decided to drop the existing DB users and tablespaces as per the following instructions

https://jazz.net/wiki/bin/view/Main/MoreControlOverTheOracleDataWarehouseSetup?

Once the data warehouse was dropped, I manually invoked the command repotools-jts -createWarehouse

The warehouse was then create successfully

I ran all data warehouse collection jobs for all applications

Data warehouse jobs were successful.

Server ETL logs did not generate any errors.

Having resolved my issue, it would still be good to find out why this specific error occurred for future reference.

Thanks again, Pierre

Pierre, by dropping your data warehouse you lost all your historical trending data. This operation is a lossy one in that you do lose the data collected by the STAR ETLs. I guess that you must not have been using the data warehouse all that much.

Also, in order to investigate any issues you need to open a defect. In the future, you are also welcome to search our work items for similar issues.


Accepted answer

Permanent link
 This issue was resolved by dropping the data warehouse instead of upgrading it.  I advised Pierre to open a work item so that the issue can be reported to development
Pierre Friend selected this answer as the correct answer

0 votes

Comments

Rosa, the data warehouse was rarely used because of a previous QM ETL defect discovered in v.3.0.1 which was eventually fixed with the v.3.0.1.3 release. Now, since the data warehouse upgrade from 3.01.3 to 4.0 happened in our sandbox environment, I was not worried about losing the historical data. The upgrade was simply an exercise to see how the refreshed PROD data would react to the v.4.0 upgrade scripts. I obviously got the answer when the DW upgrade failed. I will recreate the sandbox environment and run the upgrade again. if the data warehouse from 3.0.1.3 to 4.0 fails, I will open a defect with your development team to investigate.

According to the release notes for version 4.0.1 and technote 1611832  http://www-01.ibm.com/support/docview.wss?uid=swg21611832, the data warehouse upgrade failure is caused by a defect. After installing v.4.0.1, the upgrade of the data warehouse was successful. My sandbox CLM upgrade from 3.0.1.3 to 4.0.1 was completed with no other errors or issues.

Thanks,
Pierre

Pierre
Thanks for the update. I appreciate hearing good news like this.


One other answer

Permanent link
Pierre, Were you able to revert all the previous reports, after creating new DW database & running the data warehouse collection jobs ? Do you see any change in Execution Trend S curve ? Especially, the vertical bar's in the graph for the test plan "completed and attempted" status are visible ??

0 votes

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 7,620
× 268

Question asked: Aug 28 '12, 2:09 p.m.

Question was seen: 7,319 times

Last updated: Dec 11 '12, 12:22 p.m.

Confirmation Cancel Confirm