I was going through the steps of deleting content db using stsadm (as you know it does not delete the content database from SQL Server, but just removes the reference from SharePoint perspective) and using stsadm –o addcontentdb to attach a content database from production to development server for testing purposes. Once the stsadm –o adcontentdb operation was completed successfully, I went into Manage Content Databases section and noticed the Current Number of Sites was set to 0.

 

To confirm that the content database had some valid entries for webs and sites, I queried the following tables

select * from Sites with (nolock)

and then the webs table

select * from webs with (nolock)

 

The query results showed entries existed in the sites table as well as the relevant webs table. After further troubleshooting, the issue was caused by GUID conflicts in SQL Server. I had restored the same content database from production to development server few months back for some other testing purpose to a different web application. Although this was a brand new web application that I had created, the GUID conflict still occurred and that is the reason the number of sites was set to 0. So, to ensure that the restore process was clean, I started the restore process again on SQL Server, executed stsadm –o deletecontentdb for the new web application I had created followed by stsadm –o addcontentdb pointing to the new database restored.

Now, if you have a question, so how do I maintain 2 copies of the same content database in production in this scenario without GUID conflicts? You can use stsadm backup and restore (or) content deployment. I did try with stsadm backup and restore and the process was successful.

Hopefully, this post will save you some time next time you encounter a similar situation.