Removing orphaned block and area content after mass page deletion

I've inherited an extremely slow site which had a very large subsection of the sitemap deprecated and unused (140,000 + pages). After removing these pages, the total number of site pages dropped to about 4,000.

After deleting the pages from the sitemap and reindexing the page search index, there are still a substantial number of rows left in the areas, collectionversionblockpermissions, collectionversionblocks, btcontentlocal, etc tables. Is there a process somewhere in the system designed to permanently purge orphaned areas and blocks from the database? If not, does anyone have a series of queries which would perform the same function?

View Replies:
foster replied on at Permalink Reply
Check out this thread for some ideas:

The problem I was having was deleted blocks were still showing in search results. In the end I ended up having to search through the mysql database file and manually delete the old content. But there might be some other ideas on that page that could work for you.
dimunation replied on at Permalink Reply
Thanks - seems like a related issue, although in this circumstance the page indexing process appears to be running properly. More to the point - I'm not worried about deleted blocks on the active pages so much as blocks that were previously attached to the deleted pages are still in the system. btContentLocal, for example, still contains all of the content blocks associated with the deleted pages (in this case about 3GB worth).

It looks like collectionVersionBlocks ties the collections cID to the block bID, but i'm worried about deleting records from this and the block tables based solely on this relationship in case there are other considerations to take into account (scrapbooks, etc).