As an integrator there are many things we can do as far as making the install a success, but only a very limited amount we can do to guarantee its continuing success. One of the most often seen issues is the handoff of an installation to the client, in particular the maintenance of the database.
I will talk in particular about installations using Microsoft SQL Server. When the database is created it is more often as not left to us as the integrators to create the database (sometimes even the installation of the MSQL Server instance as well). We will choose the path for the database file groups, and allow the defaults for everything else. For operational purposes of our software this will work, but there should be changes made and additional procedures put in place by the clients DBA to guarantee continued optimal performance of the newly implemented system.
When visiting these systems at a later date we find that log files have not been truncated, leaving to question whether any backups have been done at all. Log files are the record of changes which have taken place since the last log truncation; this allows that the database can be restored to a point in time since the last full backup to reverse an adverse action or system failure.
These log files are often much larger than the data files. In a maintained system a DBA would have established a normal backup strategy which would have backed up the log file at different intervals through the day and truncated the log file after a full database backup.
The other is often finding the file growth setting for the database to be at a preset auto growth amount. These by default are either 10 mb or 10%. When the database was first established an estimate was made to come up with a number which would be used for the initial file size for the database and log files. For databases which have a need for growth these presets can be very inefficient, as among other things they are likely to do their growth during business hours. Take a 200gb database which started at 150 gb, if it grows by only 10 mb every time it needs to grow there will be a large number of inefficient file space allocations to have made up the 50gb of space. If told to grow by 10 percent, then we will have seen 15 gb file allocations taking place but during business hours which can have an impact upon users. One which the maintenance has been taken up by the DBA will have been monitored and auto growth will have been turned off. The DBA would have scheduled the data file growth based upon measurements taken of the databases past growth rate, and most likely the new space allocation will have taken place in off business hours.
There may be a myriad of reasons why this handoff has failed including the lack of a DBA in the organization. I do not purport to know what the answer is, only that when a follow on visit to a client is made, that inspection of the database for these settings would be worthwhile so that they can be brought the clients attention and hopefully then engagement by the IT department for the maintenance needing to take place.
Senior System Architect