Well it does have zdb. The problem is that because of auto import, if there is a pool that results in panic, you are in trouble as soon as it is plugged in. The work around, as you know, is to change the partition type in the gpt using /usr/sbin/gpt or gdisk, which will prevent ZEVO from autoimporting. Then, you can use zdb. Depending on what you want to do with zdb, you will either be running the command against a disk or a pool. If you are running it against a pool, and the pool is exported--as would be the case when you're dealing with a pool that causes panic on import--you tell zdb that the pool is exported with the "-e" option, and you tell zdb the path(s) to the pool's disks with the "-p" option (similar to the "-d" option used with zpool import). So you would zdb -e -p /dev [other options] MyPoolName.
In maxijazz's particular circumstances, the most straightforward path, assuming he has sufficient disk space available, is to use the send/receive method to generate a replacement pool. Alternatively, he could go down the path of using "debug" code (i.e., zdb) and trying some things there. Unfortunately, ZEVO and OS X have no equivalent to mdb, and the aok and zfs_recover options, so there is a limit to how much repair you can accomplish with ZEVO without triggering panic in the process. For an example of the use of mdb, aok, and zfs_recover, see the following:
https://blogs.oracle.com/middleview/ent ... s_disasterI have not looked into it, but I assume the illumos distributions (e.g., OpenIndiana) have mdb, aok, and zfs_recover, since these are things which date back to the days of OpenSolaris. Since ZEVO has pool version 28, one can of course use Oracle Solaris 11 to do repairs which require mdb, aok, and zfs_recover.