Limited concerns exist in the sizing of the ServiceDesk database. Most customers even with large environments seldom see database file sizes grow much larger than 20-40 GB. The average database size ranges from 4-15GB.
Allow between 750KB and 1 MB of space in the database for every 1,000 service tickets. This sizing does not account for database fragmentation beyond initial creation. The database maintenance strategy that you use also influences your database size.
Autogrow is a SQL Server setting you can use to help with unexpected data growth. However, do not rely on autogrow to manage your database file sizes. As with any key application, you must monitor the database and have proper maintenance tasks in place.
To choose your autogrow setting, estimate the expected maximum sizes of the data file and the transaction log file. To estimate this size you can monitor the growth of these files in a pre-production environment. Set the autogrow increment for your data file and transaction log files to 10 to 20 percent higher than your initial estimate.
Do not use the autoshrink feature with ServiceDesk. Auto shrink runs periodically in the background. It consumes CPU and I/O cycles, which can cause unexpected performance degradation. Autoshrink can continually shrink and re-grow the data files. This process causes fragmentation of the database file. This fragmentation may degrade both sequential transfers and random accesses. If Autoshrink is required in your environment, please schedule it to run only after normal work hours.
To further improve performance, you should defragment and re-index the database after its initial installation.
The Process Manager SQL Server should not host additional third-party database applications. For best performance, Symantec recommends that the Process Manager SQL Server not host any additional databases. The load and I/O traffic of ServiceDesk are sufficient to require a dedicated SQL Server. You can have a single SQL instance that shares a single TempDB database, or multiple database instances can each have a dedicated TempDB database. Multiple database instances minimize risk for potential contention but require more disk arrays.
You may require the individual Process Manager databases of each ServiceDesk server to exist on a separate instance. They may need to be separate instances to avoid TempDB database contention.