I do not know a way to query  all sites. The most likely reason  you had
to create  another content  database is that the original site  backed up
still existed, perhaps under a different name. Each Site Collection is
assigned a unique ID (guid) and two Site Collections with the same guid
cannot exist in the same content database.

This might help?

Sorry if I wasn't clear in my question. I knew why I had
to create  the new content  DB what I dont get is the growth. Why
would the new content DB, and the log  files, be larger than the
original? And not just a little bit. I'm talking a LOT larger.

Since I didnt see a way to edit my original post let me use this to
add that I do understand why I had to create  the 2nd content  DB. We
didn't delete the old site  and you can't have duplicate IDs. What I
dont understand is why the new content DB and related  log file  are
larger than the old ones and not just by a little....

Repeat after me, "Transaction log size  has NOTHING to do with database size."

The second transaction log  is probably so large  because it has all the
transaction from the STSADM restore  in it. Back it up, then shrink it if you're
concerned about size. If you never, ever, ever, plan on doing point  in time
restores of your data set your database recovery mode to Simple, then shrink the
Transaction log.

Out of curiosity, do you see any value in keeping the Config DB's in Full
recovery mode or would it be just as good to set those to Simple?

It depends on what your recovery metrics are. We're currently comfortable with
being limited to the last backup, so Simple Mode works for us. I don't have a
good idea of how large  the transaction logs can get for the config logs, so I
can't really make much in the way of recommendations.