There's a script called debugzope, that sounds like a debugger. But in real life you can examine the whole ZODB with it. You can even make changes to the ZODB or ZEO. All in all quite handy if you have to correct a few objects in the database, also on a live system.

$ bin/debugzope

Now the variable root becomes your DB's root. All configuration should be taken from the live system in which context it was started.

>>> root
zope.app.folder.folder.Folder object at 0x01C31C70

You can do any changes (and anything) using the usual python commands. The whole Zope infrastructure is in place.

Don't forget to commit when you are ready:

>>> import transaction
>>> transaction.commit()

Otherwise all changes will be reverted on exit!

debugzope(.bat) is usually available if you use the old zopeskel style deployment. The next task is to figure out how to do this with a buildout based deployment.

Sometimes happens that you put a security proxied object into a persistent object's property. Then on transaction commit you get the error:
UnpickleableError: Cannot pickle objects
Now you can search al your code and guess where you set that property.
That can be solved much simpler:
modify ZODB/serialize.py temporarly as follows:

def _dump(self, classmeta, state):
# To reuse the existing cStringIO object, we must reset
# the file position to 0 and truncate the file after the
# new pickle is written.
self._file.seek(0)
self._p.clear_memo()
self._p.dump(classmeta)
try:
self._p.dump(state)
except:
#your favorite debugger's break command

self._file.truncate()
return self._file.getvalue()

And voila, classmeta is the class concerned, state is a dict holding the state. From these values it's piece of cake.

The questions "how-to check the structure of ZODB", "what is stored in the ZODB" pops up here and there.
The answer is: http://svn.zope.org/z3c.zodbbrowser/
This is a wxPython package running independently of the Z3 app server. In fact shut it down before trying to start the ZODB debugger.