It's all about the answers!

Ask a question

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


0
1
Dmitry A. Lesin (23413166) | asked Apr 19 '15, 9:49 a.m.
edited Apr 27 '15, 1:48 p.m. by Jennifer Cianchetta-Riordan (2512)
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!

One answer



permanent link
Donald Nong (14.4k313) | answered 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".

Comments
Dmitry A. Lesin commented 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 commented Apr 23 '15, 12:21 p.m. | edited 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 commented 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 commented 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 to post your answer.