[Zope-dev] Re: [ZODB-Dev] Recovering Corrupt Database part2

[tomasz]

Hello zope-dev, as a suggestion from another mailing list user i have 
forwarded my current problem to this list. To summarize it seems that due 
to some hard drive corruption my zopedb has been left open with a 
lot of open transactions. When i try to clean the db with fsrecover i get 
numerous version lock errors and the db wont load. I have included my 
email to ZobDB-dev as a more thorought explanation.


--tomasz 

On Mon, 4 Nov 2002, Jeremy Hylton wrote:

> >>>>> "TZ" == tomasz  <tomasz@pucky.ods.org> writes:
> 
>   TZ> This is a follow up email that was sent out a week ago by my
>   TZ> partner Cody Smith. it can be found at.
> 
>   TZ> http://lists.zope.org/pipermail/zodb-dev/2002-October/003476.html
> 
>   TZ> After multiple suggestions to upgrade to Zope-2.6 from
>   TZ> Zope-2.3.2 we did so. We retrieved our backups and ran them
>   TZ> through the fsrecover script with a "-p" and without it.
> 
>   TZ> When the script runs it throws multiple Version lock error.
> 
> The error is because of a Zope/ZODB version.  Zope is complaining that
> it can't modify an object, because it is modified in a version.  Once
> an object has been modified in a version, it can't be modified by
> non-version users until the version is aborted or committed.
> 
> > ZODB.POSException.VersionLockError: 
> > ("'\\x00\\x00\\x00\\x00\\x00\\x00\\x01\\x83'", 'content_cntrl')
> 
> This error shows the oid of the object that is locked and the name of
> the version.  Does the name 'content_cntrl' sound familiar to you?
> It was picked by a user of the site :-).
> 
> You may want to ask on zope-dev what else you can do.  It sounds like
> the right thing to do is to abort the particular version, but I'm not
> sure how to do that from Zope or how to get Zope to start while this
> object is locked.
> 
> Maybe you could open the database and try this:
> 
> >>> db = ZODB.DB(fs)
> >>> db.abortVersion('content_cntrl')
> >>> get_transaction().commit()
> >>> db.close()
> 
> I also wonder if you should worry about the drop in database size.  It
> might be interesting to run fsrefs.py over the new database and see if
> you've lost any objects.
> 
> Jeremy
> 
>