Oracle7 Getting Started for Windows NT Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index



Go to previous file in sequence Go to next file in sequence

Monitoring a Database



Database Monitoring Overview

The following tools and procedures enable you to monitor and manipulate your server.

This Tool/Procedure Enables You To...
Performance Monitor

Monitor and optimize database performance.

Event Viewer

Display warnings and errors about database functionality.

Trace Files

Record occurrences and exceptions of database operations.

Alert Files

Record important messages about error messages and exceptions during database operations.

Error Message Logging

Redirect Oracle7 Utility error messages to a file.

Each tool and procedure is described in the following sections.

Additional Information
See Oracle7 Server Tuning, Release 7.3.3 for general tuning information and your operating system documentation for additional information on Windows NT Performance Monitor results and optimizing database performance.

Using Performance Monitor

To use the Performance Monitor to monitor and analyze Oracle7 Server for Windows NT database performance, you must first install the Oracle7 Performance Utility. The Oracle7 Performance Utility enables Database Administrators to monitor local and remote database performance through the Performance Monitor.

Accessing the Performance Monitor

If Using... Then...
Windows NT 3.51

Choose the Performance Monitor icon from the Accessories Group in Program Manager.

Windows NT 4.0

Go to Start->Programs->Administrative Tools (Common)-> Performance Monitor.

Follow these procedures to access the Performance Monitor.

Monitoring Oracle7 Objects

When you monitor the database, you are essentially monitoring the behavior of its objects. In Windows NT, an object is a mechanism for identifying and using a system resource. Oracle7 objects represent sections of shared memory, tuning I/O, and tuning contention. Each Oracle7 object has a set of counters that produce statistical information. The following table shows the Oracle7 objects and their associated counters. For additional information on these objects, refer to Oracle7 Server Tuning, Release 7.3.3

Object Counter Description
Oracle7 Library Cache

Reloads/Pins %

The percentage of SQL statements, PL/SQL blocks, and object definitions that required re-parsing. Total Reloads must be near 0. If the ratio of Reloads to Pins is greater than 1%, then reduce the library cache misses.

This value is not time-derived.

Oracle7 Data Dictionary Cache

Get Misses/Gets %

The value of this counter must be less than 10 or 15% for frequently accessed data dictionary caches. If the ratio continues to increase above this threshold while your application is running, increase the amount of memory available to the data dictionary cache.

This value is not time-derived.

Oracle7 Redo Log Buffer

Redo Log Space Request

The value of this counter must be near 0. If this value increments consistently, processes have had to wait for space in the redo log buffer. In this case, it may be necessary to increase the size of the redo log buffer.

Oracle7 Buffer Cache

Phyrds/Gets %

The percentage of Phyrds/Gets is calculated as a Miss ratio. If the Miss counter is higher than 30% to 40%, increase the number of buffers in the buffer cache to improve performance. To make the buffer cache larger, increase the value of the DB_BLOCK_BUFFERS initialization parameter.

This value is not time-derived.

Oracle7 Data Files

Phyrds/Sec

Phywrts/Sec

Disk contention occurs when multiple processes try to access the same disk simultaneously. There are many ways of reducing disk contention, depending on the results from monitoring disk activity. Some corrective actions include:

These values are time-derived.

Oracle7 Dynamic Space Management

Recursive/Calls Per Second

Dynamic extension causes Oracle7 to execute SQL statements in addition to those SQL statements issued by user processes. These SQL statements are called recursive calls. If Oracle7 makes excessive recursive calls while an application is running, it may be necessary to determine the cause. Examine the recursive calls statistic through the dynamic performance table V$SYSSTAT.

Oracle7 Tuning Sorts

Sorts in Memory/Sec

Sorts on Disk/Sec

The default sort area size is adequate to hold all the data for most sorts. However, if your application often performs large sorts on data that does not fit into the sort area, then you may want to increase the sort area size.

Oracle7 Free Lists

FreelistWaits/ Requests %

Contention for free lists is reflected by contention for free data blocks in the buffer cache. You can determine if contention for free lists is reducing performance by querying V$WAITSTAT.

If the number of freelist waits for free blocks is greater than 1% of the total number of requests, consider adding more free lists to reduce contention.

.

Oracle7 Specific Information

The following list describes information specific to Oracle7 when you use the Windows NT Performance Monitor.

Modifying Values

Modify only the last three items in the table (Hostname, Username, and Password). They can point to any Oracle database (local or remote). You must have read access to any tables from which you want to retrieve data.

These values are located in the Windows NT Registry. Follow the procedures below to edit these values:

  1. Run REGEDT32 (Windows 3.51) or REGEDIT (Windows 4.0) from the command. For example, for Windows NT 3.51, enter:

    C:\> REGEDT32
    The Windows NT Registry opens.

  2. Double-click \\HKEY_LOCAL_MACHINE.

  3. Double-click SYSTEM.

  4. Double-click CurrentControlSet.

  5. Double-click Services.

  6. Double-click Oracle73.

  7. Double-click Performance.

    The Performance values display on the right side of the screen.

  8. Double-click on the Hostname, Username, or Password entry.

  9. Make appropriate changes.

  10. Exit the Windows NT Registry when done.

    Note:
    You can only monitor one instance at a time using Performance Monitor on a given machine.

Using Event Viewer

The Windows NT Event Viewer displays warnings and errors about the functioning of the Oracle7 database

As with other events displayed in the Event Viewer, you can double-click on them to display more detailed error information.

Note:
The Windows NT Event Viewer displays information similar to that contained in ALERT.LOG. In addition, the Oracle7 Server operating system audit trail also gets output to the Event Viewer.

Additional Information
See your operating system documentation for more information on using the Windows NT Event Viewer.

Using Trace and Alert Files

Trace Files

Oracle7 Server for Windows NT background threads use trace files to record occurrences and exceptions of database operations, as well as errors. Background thread trace files are created regardless of whether the BACKGROUND_DUMP_DEST parameter is set in the initialization parameter file. If BACKGROUND_DUMP_DEST is set, the trace files are stored in the directory specified. If the parameter is not set, the trace files are stored in the ORANT\RDBMS73\TRACE directory.

Oracle7 Server for Windows NT creates a different trace file for each background thread. The name of the trace file contains the name of the background thread, followed by the extension .TRC. Sample trace file syntax includes:

where sid represents the name of the instance (the value of the ORACLE_SID configuration parameter).

Trace files are also created for user threads if the USER_DUMP_DEST parameter is set in the initialization parameter file. The trace files for the user threads have the form ORAxxxxx.TRC, where xxxxx is a 5-digit number indicating the Windows NT thread ID.

Alert Files

The alert file contains important information about error messages and exceptions that occur during database operations. Each Oracle7 Server for Windows NT instance has one alert file; information is appended to the file each time you start the instance. All threads are able to write to the alert file.

For example, when automatic archiving of redo logs is halted because no disk space is available, a message is placed in the alert file. The alert file is the first place you should check if something goes wrong with the database and the cause is not immediately obvious.

The alert file is named sidALRT.LOG and is found in the directory specified by the BACKGROUND_DUMP_DEST parameter in the initialization parameter file. If the BACKGROUND_DUMP_DEST parameter is not set, the sidALRT.LOG file is generated in ORANT\RDBMS73\TRACE.



Go to previous file in sequence Go to next file in sequence
Prev Next
Oracle
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Library
Go to books for this product
Product
Go to Contents for this book
Contents
Go to Index
Index