I would second Bill's addition of poorly-architected applications to Richard's list of issues that should be (but are often not) addressed, or even considered. At another customer, we and the customer's sysadmins were bedeviled by a weblog analysis application (which shall remain nameless) that chose to store its data on the filesystem, using the date of the log data as a directory under which the data was stored (as well as the associated reports, I believe). The explanation we were given was that they had chosen to do this for application performance reasons; it was apparently quicker that using a DBMS.
This decision, although it made random access of data quicker, had horrible implications for backup as the log data and reports accumulated over time; recovery was even worse. Aggravating the situation was the insistence by the "application owner" that ALL historical log data absolutely had to be maintained in this inside-out database format. Just getting a count of files and directories on this drive (via selecting Properties from the context menu) took something on the order of 9 hours to complete. The volume of data, in GB, was really not that large - something on the order of 100 GB. All of their problems managing the data stemmed entirely from the large number of files and directories. When the time came to replace the server hardware and upgrade the application, they had extreme difficulty migrating the historical data from the old server to the new. They did finally succeeded in copying the data from the old server to the new, but it took days and days of around-the-clock network traffic to complete. Addressing the ramifications of this type of design decision after the fact is difficult at best. If at all possible, we need to prevent it from occurring in the first place. Ted
