It's all about the answers!

Ask a question

SCM Database corrupt after synch with ClearCase


Lars Ohlén (511133) | asked Jan 09 '08, 3:38 a.m.
Hi,

After a synchronization with ClearCase last night the SCM
database the SCM database seems to be corrupted. The user, items,
planning etc seems to be intact.

Please find attached error log.

I tryed to create a new repository workspace, but I get a long SQL error
stacktrace (that is not logged into Eclipse error log so please find a
screen dump attached)


The synchronization is set-up with text mode transpartent
-Dcom.ibm.rational.wvcm.ct.TEXT_MODE=transparent


Yesterday we added more Eclipse project to the synchronziation, during
our trials we have started out with just a few, but we have now added
all our projects to be synched (~60).

I'm pretty sure that everything is intact in ClearCase, so it seems like
the initial synchronisation has failed.

How to proceed???? Possiblity to do some kind of repair

BR

Lars

8 answers



permanent link
Steven Wasleski (17633) | answered Jan 09 '08, 9:08 a.m.
JAZZ DEVELOPER
Lars,

It appears from your attachments that you are using a Derby database (I
see the derby JDBC driver in the stack trace), is that correct? Also,
how much SCM data are we talking about here?

Geoff,

From the stack trace, it appears the database connection is lost in the
middle of the sync (see my attachment). Could we just be trying to throw
too much data at Derby at once.

Steve

permanent link
Geoffrey Clemm (30.1k33035) | answered Jan 09 '08, 9:08 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note: This issue is being tracked in workitem 40866.

Cheers,
Geoff

Geoffrey Clemm wrote:
The ClearCase synchronizer uses only the TeamConcert client library to
write to the server, so it is unlikely that it could create an invalid
checksum in the database. The use of TEXT_MODE=transparent only affects
the content that you write to the database, so I can't imagine that
causing a low-level problem like this.

I'll open a defect for the repository team, to see if they can give us
some guidance here.

Were you doing anything else with the database (upgrading it, whatever)
around the time you saw the corruption, or were you only using it for
importing ClearCase data?

While we're waiting for advice from the repo team, one thing to try is
to create a second ClearCase workspace (on the same stream/branch as the
first one), and start adding the roots to that second workspace (start
by adding one at a time, and then synchronizing), to see if the problem
is in a particular project. In particular, I'd first add the first
project you added to the first CC Workspace (since that one should be
OK), and then add the last root you added (in case it was the last one
that had a problem).

Cheers,
Geoff

permanent link
Steven Wasleski (17633) | answered Jan 09 '08, 9:18 a.m.
JAZZ DEVELOPER
Lars,

One more question. I believe I shared with you a while back a script to
do database backups that involved stopping the server and database,
backing up and then restarting. Could the run of these two tasks be
overlapping with the backup pulling the database out from under the sync?

Steve

permanent link
Lars Ohlén (511133) | answered Jan 09 '08, 9:28 a.m.
Hi,

You are right we are using a scheduled job to stop sever, backup and
start server again (much like the script you shared with us)

The process overlapping thing was one of my orignal thoughts, but I did
some calculations and it should not be the case.

Thy synch started around 16:00 and backup routine occurs 22:15
According to the last line in the Ant script it terminated after 239
minutes (~4 hours).

But I agree it seems to be a logical explanation. Should I try to set-up
the synch again (with backup stopped) and see if the problems still exists?

BR

Lars



Steve Wasleski skrev:


Lars,

One more question. I believe I shared with you a while back a script to
do database backups that involved stopping the server and database,
backing up and then restarting. Could the run of these two tasks be
overlapping with the backup pulling the database out from under the sync?

Steve

permanent link
Lars Ohlén (511133) | answered Jan 09 '08, 9:48 a.m.
Steve Wasleski skrev:

Yes we are using Derby.

The avreage project size is very small, but there is one or two projects
that contains jar files that togheter is quite big (MB)

Total size is less 25 MB


/Lars







Lars,

It appears from your attachments that you are using a Derby database (I
see the derby JDBC driver in the stack trace), is that correct? Also,
how much SCM data are we talking about here?

Geoff,

From the stack trace, it appears the database connection is lost in the
middle of the sync (see my attachment). Could we just be trying to throw
too much data at Derby at once.

Steve


------------------------------------------------------------------------

Caused by: java.sql.SQLException: No current connection.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(null)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(null)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(null)
at org.apache.derby.impl.jdbc.Util.noCurrentConnection(null)
at org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(null)
at org.apache.derby.impl.jdbc.EmbedConnection.clearWarnings(null)
at com.ibm.team.repository.service.internal.db.jdbcwrappers.ConnectionStatWrapper.clearWarnings(ConnectionStatWrapper.java:117)
at com.ibm.team.repository.service.internal.db.jdbcwrappers.errlog.ConnectionErrLogWrapper.clearWarnings(ConnectionErrLogWrapper.java:73)
at com.ibm.team.repository.service.internal.db.jdbcwrappers.ConnectionLeakWrapper.clearWarnings(ConnectionLeakWrapper.java:114)
at com.ibm.team.repository.service.internal.rdb.RepositoryDatabase$Transaction.startTransaction(RepositoryDatabase.java:426)
... 111 more
com.ibm.team.repository.common.TeamRepositoryException: Failed to prepare the txn mode
at com.ibm.team.repository.service.internal.rdb.RepositoryDatabase$Transaction.startTransaction(RepositoryDatabase.java:431)
at com.ibm.team.repository.service.internal.rdb.RepositoryDatabase.runTransaction(RepositoryDatabase.java:262)
at com.ibm.team.repository.service.internal.rdb.RepositoryDatabase.runInTransaction(RepositoryDatabase.java:218)
at com.ibm.team.repository.service.internal.TransactionService.runInTransaction(TransactionService.java:77)
at sun.reflect.GeneratedMethodAccessor77.invoke(null)

permanent link
Geoffrey Clemm (30.1k33035) | answered Jan 09 '08, 9:58 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
There are two interesting experiments:
- Try the sync again, against the current state of the repository.
- Restore the database to the last backup before you started the sync
that failed, and then try the sync again.

Cheers,
Geoff

Lars Ohln wrote:

Hi,

You are right we are using a scheduled job to stop sever, backup and
start server again (much like the script you shared with us)

The process overlapping thing was one of my orignal thoughts, but I did
some calculations and it should not be the case.

Thy synch started around 16:00 and backup routine occurs 22:15
According to the last line in the Ant script it terminated after 239
minutes (~4 hours).

But I agree it seems to be a logical explanation. Should I try to set-up
the synch again (with backup stopped) and see if the problems still exists?

BR

Lars



Steve Wasleski skrev:


Lars,

One more question. I believe I shared with you a while back a script
to do database backups that involved stopping the server and database,
backing up and then restarting. Could the run of these two tasks be
overlapping with the backup pulling the database out from under the sync?

Steve

permanent link
Lars Ohlén (511133) | answered Jan 09 '08, 11:48 a.m.
Hi,

I tryed to do the synch again, but it failed directly. The synch
software failed after a few momemts saying "Failed to prepare the txn
mode" (can't find any log files)

I will restore the database to the state before the crash.

/Lars








Geoffrey Clemm skrev:



There are two interesting experiments:
- Try the sync again, against the current state of the repository.
- Restore the database to the last backup before you started the sync
that failed, and then try the sync again.

Cheers,
Geoff

Lars Ohln wrote:

Hi,

You are right we are using a scheduled job to stop sever, backup and
start server again (much like the script you shared with us)

The process overlapping thing was one of my orignal thoughts, but I
did some calculations and it should not be the case.

Thy synch started around 16:00 and backup routine occurs 22:15
According to the last line in the Ant script it terminated after 239
minutes (~4 hours).

But I agree it seems to be a logical explanation. Should I try to
set-up the synch again (with backup stopped) and see if the problems
still exists?

BR

Lars



Steve Wasleski skrev:


Lars,

One more question. I believe I shared with you a while back a script
to do database backups that involved stopping the server and
database, backing up and then restarting. Could the run of these two
tasks be overlapping with the backup pulling the database out from
under the sync?

Steve

permanent link
Christophe Elek (2.9k13021) | answered Jan 16 '08, 5:26 a.m.
JAZZ DEVELOPER
Lars Ohln <lars.ohlen@tietoenator.com> wrote in news:fm2tdt$h9o$1
@localhost.localdomain:

Failed to prepare the txn
mode" (can't find any log files)


created work item 41342 to improve error message

--
Christophe Elek
Serviceability Architect
IBM Software Group - Rational

Your answer


Register or 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.