Consider the following factors when planning your QDB configuration:
The number of events you expect to generate
The number of data points you intend to collect and save for historical reporting or trend analysis
Because this information is difficult to estimate before you install AppManager, and changes as you expand and refine your deployment strategy, NetIQ Corporation recommends the following process as a starting point to size the QDB data and log files.
To estimate the initial size of the QDB data and log files:
Determine the number of agent computers you plan to monitor and multiply that number by 1/3 MB to account for the events and data each will generate, then multiply the result by the number of days you intend to keep data in the QDB. For example:
Number of agent computers = 180 X 1/3 MB = 60 MB
Number of days to retain data = 30
Estimated QDB data file size = 60 MB X 30 = 1800 MB (1.8 GB)
Set the initial log file size to 512 MB, which is the default installation value.
Sizing the initial data and log files along these guidelines is a good starting point in most environments. It is roughly one-third of the size for a full deployment. Keep the data file and the log file on separate devices.
For more information about determining the number of QDBs for your environment, see Section 2.9, Implementation Guidelines.
The default size for the QDB data file is 2048 MB. This size is adequate for a small network with moderate monitoring activities. Larger AppManager deployments will need additional space.
Setting the initial size to about a third of what you think you will need avoids reserving space you will not use during the early stages of deployment, when you are unlikely to run a full set of Knowledge Script jobs or collect all the data you will eventually want to use. Instead, you will probably increase the number of agent computers and the number of jobs you run over time. In addition, maintenance operations, such as backup and restore, are easier if you create smaller data files and plan for growth rather than sizing the data file at the onset to handle your eventual database requirements.
Although SQL Server can dynamically increase the size of database files and memory, this is not a reliable method for managing database growth. The default setting for the size increase is only 1 MB, which can lead to multiple size increases and corresponding disk fragmentation. Letting the database grow dynamically can also cause fragmentation of the SQL space, which can severely impede performance. Instead, plan for periodic QDB maintenance. Plan to monitor the size of the QDB by running AppManager Knowledge Script jobs to check the size at regular intervals.
To estimate the potential growth of your QDB, assume it will grow at a rate of about 2 MB per server, per day, assuming 20 to 30 jobs running at 15 minute intervals and collecting data. NetIQ Corporation recommends installing NetIQ Analysis Center to manage and report on your data if you need to keep data for longer than 90 days. Typically, AppManager performance will start to deteriorate as the QDB surpasses 50 GB in size. If QDB size exceeds 100 GB, its impact on performance might be severe.
AppManager provides many options for managing the QDB and keeping it healthy. For example, you can configure the QDB to consolidate older data into daily, weekly, and monthly averages. For more information about managing QDBs, see the Administrator Guide for AppManager, available on the AppManager Documentation page.
To achieve optimal SQL Server and AppManager performance, place the data and transaction logs on separate physical drives. You can select the locations of these logs during QDB installation.
As you increase the amount of data you store, you might also need to increase the size of the temp database to handle queries that require temporary space. By default, the database is 8 MB. The more data you store and access, and the more you plan to use AppManager reporting capabilities, the more space you should set aside for the temp database.
You typically do not need to change the size of the other databases, such as the master database.