|
Measures reported by OraListenerLgTest
The listener is a separate process that runs on the database server computer. It receives incoming client connection requests and manages the traffic of these requests to the database server.
If listener logging is enabled, then the listener log file will log audit trail information that will enable you to gather and analyze network usage statistics, as well as information indicating the following:
In addition, the log file will log the following:
Service-registration related events; Direct hand-off events; Messages indicating the failure of the listener's subscription to the Oracle Notification Service (ONS) node down event Messages indicating that the listener successfully notified CRS (Cluster Ready Service) that its libraries were installed
One problem that happens in very active databases is that the listener.log file can get very large. If this growth is not controlled soon, then the directory storing the log file may run out of space, thereby rendering the log file incapable of capturing new messages.
Using this test, you can not only determine whether listener logging is enabled or not, but also continuously track the usage of space by the listener log file, so that you can detect any rapid growth in log file size early and take adequate measures to curb the growth.
The measures made by this test are as follows:
| Measurement |
Description |
Measurement Unit |
Interpretation |
| File_Sizes |
Indicates the current size of the listener log file. |
MB |
A high value for this measure or a consistent increase in its value indicates that the listener log is rapidly growing and may end up occupying too much space on the volume.
Often people may overlook the growth in the log file size until they stop getting new log messages or the volume/filing system holding the log file is running out of space.
Remember that on most 32bit operating systems, there is usually a 2 GB file size limit.
On most 64bit OS's the file can grow a lot larger, often 1TB for a single file. Sometimes this can be the cause of using all the available space on a volume.
You may notice that even after you delete the file, the space does not come back as being usable.
Specifically, on Unix/Linux - If you delete a file that is open for writing, the space doesn't get freed up until the process that is writing the file terminates.
Normally if you rename or delete the listener.log file it will create a new file, but it won't free up the space taken by the old file. This is because the file is open for writing the whole time by the listener.
If you can stop the listener, then rename the file and then restart it, so that the space is freed. |
| Status |
Indicates whether listener logging is enabled or not. |
|
The values that this measure reports and their corresponding numeric values are as follows:
| Measure Value |
Numeric Value |
| On |
100 |
| Off |
0 |
Note:
By default, this measure reports the Measure Values displayed in the table above to indicate the listener log status. In the graph of the measure however, the status is represented using the corresponding numeric equivalents - i.e., 0 and 100. |
| Lsnr_availability |
Indicate whether the listener is currently available or not. |
|
The values that this measure reports and their corresponding numeric values are as follows:
| Measure Value |
Numeric Value |
| Up |
100 |
| Down |
0 |
Note:
By default, this measure reports the Measure Values displayed in the table above to indicatus the listener status. In the graph of the measure however, the status is represented using the corresponding numeric equivalents - i.e., 0 and 100. |
| Lsnr_uptime |
Indicates how long since the last measurement period, the listener has been up and running. |
|
This measure displays the number of years, months, days, hours, minutes and seconds since the last reboot. A high value is typically desired for the measure. A low value indicates that the listener process rebooted recently. |
|