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

CRJAZ1791E, "Unknown page format" in "repotools-ccm.sh -addTables"

Questions
Tags
Users
Badges
Dmitry A. Lesin
(248●2●69●96) edited
Apr 27 '15, 1:48 p.m.
Hello!
I have got some problems upgrading CCM from v4.0.7 to v5.0.2. The problem occured when executing step:

repotools-ccm.sh -addTables

Log:

2015-04-19 13:49:04,260 Status: 1,100 of 1,160 processed (94% complete).  Estimated completion time:  4/19/15 1:49 PM.
2015-04-19 13:49:04,492 Status: 1,160 of 1,160 processed (100% complete).  Estimated completion time:  4/19/15 1:49 PM.
2015-04-19 13:49:04,519 CRJAZ2691I No more items to process.
2015-04-19 13:49:04,571 CRJAZ2739I No state migration failures occurred during online migration.
2015-04-19 13:49:04,572 CRJAZ2687I Online migration finished.
2015-04-19 13:49:04,573 CRJAZ2696I Starting post-online-migration tasks.
2015-04-19 13:49:04,573 CRJAZ2684I Cleaning table ITEM_STATES.
2015-04-19 13:49:11,878 The user "ADMIN" has logged out of the database "/home/admin/IBM/JazzTeamServer/server/conf/ccm/derby/repositoryDB".
2015-04-19 13:49:11,878 Unknown page format at page Page(11441,Container(0, 6912)), page dump follows: Hex dump:
00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
00007fe0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00007ff0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

    at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
    at org.apache.derby.impl.store.raw.data.CachedPage.changeInstanceTo(Unknown Source)
    at org.apache.derby.impl.store.raw.data.CachedPage.setIdentity(Unknown Source)
    at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown Source)
    at org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(Unknown Source)

The script can not be completed because the errors are found. As far I can see from the log, the problem occurs when cleaning ITEM_STATES table. I tried reproduce this situation directly in the Derby database with Squirrel SQL Client, and I have caught the same error (squirrel_error_cleaning_itemstates.jpg).



It must be mentioned that a similar operation when cleaning the table ITEM.TYPES was successful at all. Based on it, I can conclude that the problem is rather in a single table ITEM_STATES.
May be the problem is in big volume of data in ITEM_STATES? For example, I executed:

select count(*) from "REPOSITORY"."ITEM_STATES"

and response was:

127411

Is it permitted for Derby database under control of Jazz CLM?

I will appreciate for any advices which could help me successfully complete the upgrading procedure! Thank you very much in advance!

1

0 votes

1 answer
7,236 views
0 votes

One answer

Permanent link
Donald Nong
(14.5k●6●14) Apr 19 '15, 8:32 p.m.
Reading similar cases in the past, this "unknown page format" error indicates that your database is corrupted. The only reliable way to recover is restore from a backup. I do hope that you have a backup of the Derby database.
It is not a production environment, is it? Derby is supported "for evaluation purpose only".

1 vote

Comments
Dmitry A. Lesin
Apr 22 '15, 7:04 a.m.
Thank you! I saw these topics. Unfortunately, it's a production environment. As a matter of fact, we have got a problem only in the way of updating RTC. So, we can freeze the old repository and do it for read only access starting new updated repository from scratch. But I'd like try to restore the database at the nearest time. I have some ideas but I'm not confident in the final success! Anyway, I will add some info here in case of success!

Albert Yao
Apr 23 '15, 12:22 p.m.
Hi, Donald, What is the root cause for this problem? My customer uses Oracle as the back-end database, but encountered similar problem.

Donald Nong
Apr 23 '15, 8:05 p.m.
Albert, this has to be investigated in a case-by-case basis. In Dmitry's case, the database is indeed Derby and it was corrupted. No Oracle database was involved.

Dmitry A. Lesin
Jan 20 '16, 9:02 a.m.
Hello, guys! I have some addition because our specialist spent some time trying to fix the problem. He found out that problem can relate to inconsistencies in table REPOSITORY.ITEM_STATES. The matter is that there is a lot of duplicated values for KEY_UUID field (which is PRIMARY KEY). As well, he found errors like this one: Statement: 52433 error = A string constant starting with 'X'1f8b0800000000000000bcbdc96e6b59962538cef80a83cde9c6cb9e0e&' is too long. When we deleted the duplicates and some other errors (directly, with SQL commands), the database began operate as expected (no errors from mentioned above). But the problem is not fixed finally, because now CCM server is offline (may be important data deleted). We now suspect that the problem is concerned to some failures in the work of RTC but not in the database itself. We think that the problem can take place in any RDBMS (Derby, Oracle, DB2, etc). Can somebody make clear what the purpose of the table "REPOSITORY.ITEM_STATES" is. Which conditions must be observed while deleting the records in it? Thank you very much in advance!

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.

Ask a question
Guidelines
FAQ
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
× 2,382
× 343
× 11

Question asked: Apr 19 '15, 9:49 a.m.

Question was seen: 7,236 times

Last updated: Jan 20 '16, 9:02 a.m.

Confirmation Cancel Confirm