Mining Information from the listener Log

Mining Information from the Listener Log

An Oracle database infrastructure has several components — the database, the listener, and the clustering components (CRS, CSS, ONS, and so on, if it’s a RAC database). All these components produce extensive logs to let you know what’s happening behind the scenes. These logs show information vital to understanding the working of the database. Perhaps the most popular and most commonly used is the database alert log, which offers a running commentary on the operation of the database. You may find many utilities and tools, including the Grid Control and Database Console interfaces from Oracle itself, to parse the alert log and reveal valuable information.

However, a very useful source of information is often overlooked — the listener log. The listener log shows some information that is not available anywhere else (for example, the service names used by the clients). Some of the information can also be obtained by other means, such as via the IP address of the clients recorded in audit trails.
But even in such cases, the listener log provides a non-intrusive source for which you don’t have to place instrumentation inside the database, as you must do when turning on auditing. In addition, listener logs also record the listener operations, both successful and unsuccessful, which can show attacks against the listener. Since listener is usually the target of many database attacks, this information can reveal valuable clues and help you build better defenses. In summary, listener logs provide far too much valuable information to be ignored.

Part 1
Part 2
Part 3

Diagnosing Oracle® Database Performance on AIX®

For Oracle Database environments, ongoing performance monitoring and tuning activities are essential to getting the most of your systems investment. In order to be most effective, monitoring and tuning must be performed at multiple levels of the solution stack. This includes the hardware, Operating System, Database and Application levels.

This paper discusses two commonly available performance monitoring tools – Oracle Statspack and IBM NMON – and how they can be used to monitor and analyze possible performance issues for Oracle Database applications running in an AIX/System p™ server environment. In Oracle10g environments, Automatic Workload Repository (AWR) reports can be used in place of Statspack. A number of real-world examples of Statspack and NMON data are provided.

This paper assumes that the reader is familiar with Oracle Database as well as the AIX/System p-server environment.