Re: [bdbxml] Recovering/Verifying a Container

Andrew,

First, thank you for the compliments.
Let me describe what I think happened.

Berkeley DB, underneath BDB XML, does not flush
all data to disk until either
1.  a transaction is committed
or
2.  the database(s) involved are closed.

I have to assume that you were not using transactions
when you created the index.  on account.  This means
that when you hit ^C by accident, the index was not really
written.

This explains its absence.  It also explains why recovery
doesn't help, because recovery is there for transacted applications.

The reason that you can even get very far on the re-opened
container is that, until you go to access the specific decimal
index database, you are still working with good data.

So, how do you get out of this mess?
Obviously you can re-create the container.
I'm not 100% positive, but I believe that you
should be able to dump/load it using
dbxml_dump and dbxml_load.

The reason is that dbxml_dump does not dump
index databases, which is where your corruption lies.
dbxml_load reindexes the content.

Give that a try, and let me know how it goes.

Regards,

George


> Hello
>
> I'm in a bit of a bind.  I created a few containers for DBXML for
> testing some aspects of the performance of DBXML (which is pretty
> amazing I might add) which involved adding indexes and running some
> tests on various containers driven from some PHP webservices.
>
> Anyways, I think I bunged one of the containers and I'm not quite sure
> how.  I added an index on a container with 10^7 pretty straightforward
> XML documents and was doing a quick check on the container with the
> dbxml shell:
>
> dbxml> listIndexes
> Index: node-element-equality-decimal for node {}:account
> Index: unique-node-metadata-equality-string for node
> {http://www.sleepycat.com/2002/dbxml}:name
> 2 indexes found.
>
> dbxml>
>
> It's about here that I make a typo and mean to hit Control-W to
> correct it when I actually hit Control-C and kill the dbxml shell by
> accident. D'oh.  So I rerun the dbxml shell and do a listIndexes to
> make sure my Index still exists:
>
> dbxml> openContainer sunnyvale_10000000.dbxml
>
> dbxml> listIndexes
> Index: unique-node-metadata-equality-string for node
> {http://www.sleepycat.com/2002/dbxml}:name
> 1 indexes found.
>
> Sweet merciful crap. Where did the index on the account element go? I
> try adding the index again:
>
> dbxml> addIndex "" account node-element-equality-decimal
> Adding index type: node-element-equality-decimal to node: {}:account
> page 0: illegal page type or format
> PANIC: Invalid argument
> stdin:3: addIndex failed, Error: Db::get: DB_RUNRECOVERY: Fatal error,
> run database recovery
>
> Uh-oh. So I run the db_verify command:
>
> awood@shuttle:/usr/local/xmldata/containers$ /dbxml/bin/db_verify
> sunnyvale_10000000.dbxml
> db_verify: Page 6014185: invalid prev_pgno 6128356
> db_verify: Page 6026338: invalid next_pgno 6128344
> db_verify: Page 6079578: invalid next_pgno 6128355
> db_verify: sunnyvale_10000000.dbxml: DB_VERIFY_BAD: Database  
> verification failed
> awood@shuttle:/usr/local/xmldata/containers$
>
> In summary I've tried to run db_recover to no avail.  Is this a case
> where I just have to suck it up and recreate this giant container and
> re-add the index?
>
> I guess I just don't get why hitting Control-C after adding the index
> messed up the dbxml container.  Is this a known behaviour and simply
> idiocy on my part?
>
>
> Thanks for a great tool regardless :)
>
>
>
> awood@shuttle:~$ /dbxml/bin/dbxml -V ; /dbxml/bin/db_verify -V ;
> /dbxml/bin/db_recover -V ; uname -a
> Sleepycat Software: Berkeley DB XML 2.1.8: (May 24, 2005)
> Sleepycat Software: Berkeley DB 4.3.28: (April 22, 2005)
> Sleepycat Software: Berkeley DB 4.3.28: (April 22, 2005)
> Sleepycat Software: Berkeley DB 4.3.28: (April 22, 2005)
> Linux shuttle 2.4.29 #6 Thu Jan 20 16:30:37 PST 2005 i686 unknown
> unknown GNU/Linux
>
> -- 
> -Andrew
>


------------------------------------------
To remove yourself from this list, send an
email to [email protected]