To create a new monitor, select New Monitor shortcut menu on the Monitors folder in the Object Explorer. The New Monitor Wizard will be opened.
You can select performance parameters from the following five categories of performance matrixes:
Server-level parameters show you values for the entire database instance, such as READ CACHE %, USER CPU or SHARED MEMORY.
DBSpace-level parameters allow you to set alert conditions for % FREE SPACE for selected or all spaces. When the alert event is triggered for a space-level parameter, it will provide the list of spaces that exceeded the specified threshold value for this parameter.
Chunk-level parameters allow you to measure activity and % FREE SPACE for selected or all chunks. When the alert event is triggered for a chunk-level parameter, it will provide the list of chunk ids that exceeded the specified threshold value for this parameter.
Table/Index-level parameters allow you to record data and set alert conditions for selected set of tables or indexes. For example, you can record BUFREADS parameter values for 3 tables and 5 indexes. When the alert event is triggered for a table-level parameter, it will provide the list of tables/indexes that exceeded the specified threshold value for this parameter.
Session-level parameters allow you to measure activity for selected users, client hosts or user sessions. When the alert event is triggered for a session-level parameter, it will provide the list of sessions/users/hosts that exceeded the specified threshold value for this parameter.
For each parameter, you can define its own refresh interval on which the values are retrieved from the monitored IDS instance. For most of the parameters (excluding percentages and number of connected user sessions) the monitor is actually measures the delta between current value of the parameter and its previous value. So that the parameter's value, which you see in the monitor, represents this parameter's activity occurred during the refresh interval.
Important The absolute value of the parameter activity value depends on the refresh interval. For example, assuming an equal server load over a period of time, it will be 100 disk-read operations during 10 minute refresh interval but 600 hundred disk-read operations during 1 hour refresh interval. Keep it in mind when you enter alert threshold values for these delta parameters. Every time you change the refresh interval for the parameter that has associated alert threshold, that threshold value most probably become invalid and you will have to adjust it. A good practice for selecting threshold values is to run the monitor without the defined alerts for a period of time to learn what values are representative of the normal activity levels for your system (these values will vary from one system to another). Once you know the normal values for particular parameters under specified refresh interval, then you can set alert thresholds for these parameters. It does not apply to percentile and ratiometric parameters, which do not depend on refresh interval, such as CACHE READ% or COMMIT/ROLLBACK ratio.
If you want to apply the same refresh interval for multiple parameters, set it in the Default Refresh Rate field located at the bottom of the Parameters Selection panel. To record values for a selected parameter into historical database, check Save checkbox at the right of this parameter name.
Your monitor definition might include parameters from Table/Index, Space, Chunk and Session categories, for example, DBSPACE FREE SPACE or TABLE BUFFREADS. If this is a case, you have to explicitly specify a list of objects for each category to limit a scope for the monitor actions, such as saving data in a repository and checking alert conditions.
For example, you might have 2000 tables in your database, among which only 100 critical tables require a continuous monitoring. Also you might have some tables in your database that always exceed an alert condition and you want to exclude them from alert checking process but still record their performance parameters into historical database or display them in real-time. It also allows you to avoid an excessive IDS database load when retrieving not needed monitoring information and helps to prevent overloading of the historical repository with a not needed data.
Just to give an idea of the required historical database space, here is a sample calculation of a consumed space per hour if you choose to monitor and save in a database table-level parameters with refresh interval 1 minute for 2000 tables:
2000 (tables) * 350 (bytes)* 60 (minutes) = 42,000,000 (in bytes, or ~40 Mb per hour).
To define a filter for a particular parameter category, switch to this category and press Add button. For Sessions category you should also choose if you want to set filters by specifying particular user session IDs, user login names or client host workstations.
The Monitor Wizard contains the facilities to define alerts that can notify you when the value of a monitored parameter exceeds user-defined threshold level and can trigger an autonomic corrective response to an IDS event by executing a predefined custom job, which can be comprised of user-defined scripts, OS commands, SQL scripts or stored procedure calls. For information on how to define alerts, see "Creating User-Defined Alerts" section of this guide on page 13.
For any monitor parameter you can choose to display its values in a real-time graph within a monitor's panel. The real-time graphs are displayed when a monitor is running and opened in the Server Studio JE UI. Defining real-time graphs is optional for monitor operations. Moreover you can dynamically add and delete real-time graphs to and from the running monitor when its panel is opened in Server Studio JE document area.
You can use real-time graphs to monitor changing parameters in a very dynamic environment or when you want to watch effect of short transactions on the database server. For example, you can configure session level monitor for your SQL Editor session ID, execute SQL statement from this SQL Editor and immediately see impact of this statement on the different server parameters that are graphed in the monitor in real-time without having to record the data into the repository and later switch to the historical data analysis tools to graph them.
For Server-level parameters you just have to specify a parameter, which you want to chart, choose its graph color and the display area where it should be displayed within a monitor panel.
For Table/Index, Space, Chunk and Session parameters, in addition to graph color and display area, you should specify the specific objects, for which you want to display graphs. For example, you can set filter to include 20 tables in the Table/Index category in order to collect data and set alert condition that apply to all of them but for TABLE-BUFFREADS parameter you want to graph only three most critical tables in real-time.
The real-time graphs are displayed in separate tabs located at the bottom of the monitor panel. These tabs are called display areas. You can create as may display area as you need to logically organize your real-time graphs and move graphs between display areas at any time. To create a new display area, just type a new name in the Display Area column in the grid when adding new real-time graph. The display area is automatically removed when there are no graphs left in this area.
To add a real-time graph: