Yesterday DT hung at close so I force quit the application. Today when I opened it the application said I needed to a verification and repair. The verification and repair has been running for over 2 hours and with no visiable change on the progress bar and DT getting about 50% of the CPU usage. I’m wondering if the process is hung?
Paul
How large is your database? My Verify and repair takes only about one minute for 300MB + DB.
Yep, it’s hung.
Sounds like time to do system/disk housekeeping, as I’ve found the DT database itself to be very stable.
I would shut down DEVONthink and other open applications, then run basic housekeeping routines such as the cron scripts, permissions repair and perhaps cache cleaning, followed by a restart. (I use C*cktail’s Pilot suite of routines, but several other apps do similar housekeeping chores.) Every two or three weeks I run DiskWarrior 3.01 to repair any disk errors and optimize the directory. OS X DOES require routine maintanence to stay fast and stable.
Then launch DEVONthink and run Verify & Repair. I’ve never had to rebuild the database, and have seen very few errors – all of which have been repaired easily.
I always run Verify & Repair before shutting down DT, and usually run Backup & Optimize after getting a clean bill of health on the database.
My database is 636.6 MB, and Verify & Repair takes only about a minute to run. Haven’t seen even a small error in months.
Well, I ended up using the backup that wasn’t corrupted. My database was only about 74mb. I lost some stuff since I hadn’t backed it up recently. 
But oh well, the stuff I lost I can recreate. Thanks for the responses.
Paul
Without knowing your preferences, the amount of available memory or the load of your system at that moment, it’s possible that DT was updating and/or optimizing the database at that moment and as you’ve interrupted that process, the files were probably incomplete and therefore damaged afterwards.
I V&R at least daily, or always after a lot of changes, and B&O afterwards. But I’m a bit puzzled; I notice that the V&R takes “ages” (perhaps 40-80 seconds) if I haven’t made many changes, but whizzes past in 3 or 4 seconds if I’ve spent the whole day writing and moving stuff. I would have thought it would be the other way round.
Just curious, that’s all.
I’ve wondered why the Verify step at the start of Backup & Optimize happens so quickly in comparison to Verify & Repair, as if it’s not actually verifying anything or just enough to ensure integrity of the backup. Because of that uncertainty I always run V&R before B&O.
The verification on startup just checks the basic file structure and therefore needs almost no time. But "Verify & Repair" checks the consistency of all contents (and there are really many of them in a DT database).
As DT does not load the whole database on startup, "Verify & Repair" (accessing all contents) is of course faster after using the application a lot and slow right after launching the application.
What type of Verify happens before Backup & Optimize (which, btw, could use some indicator that it’s finished besides deselecting any selected items)? Same as at startup? It’s always fast, even immediately after DT is started. Is it best to continue running Verify & Repair beforehand to get a full consistency check? Thanks.
“Backup & Optimize” uses a third verification (also used before flushing contents back to disk) 
This verification just checks the basic structure of the contents already loaded into memory to ensure no bugs of OS X (e.g. the buggy RTFD handling of Panther) or third party extensions etc. have modified DT’s structures (without this check such bugs could corrupt the database).