Oracle Point, Oracle Life.

Recently, Oracle released a new diagnostics tool, Oracle Application Diagnostics For Java, which act as standalone utility in family of Oracle Enterprise Manager.

According to Oracle Application Diagnostics for Java - Usage Scenarios, this utility can perform following major java diagnostics.

1. Examining JVM activity
2. Elapsed Time Analysis (Thread Trace)
3. Track Database bottlenecks to Java
4. JVM Memory Usage Summary

As OEM does, installation of Oracle Application Diagnostics For Java (Oracle AD4J) contains two parts:

1. Console Installation for Oracle Application Diagnostics For Java
2. Oracle AD4J Agent Installation

And, a repository database is required to store data collected by agent. For Oracle AD4J, PostgreSQL is one option besides Oracle. This non-oracle exclusive offering is very welcomed. Oracle AD4J can be implemented to collect and diagnose the following application platforms via agent:

1. Oracle Application Server
2. Oracle Weblogic
3. Apache Jserv
4. IBM WebSphere
5. Oracle Database
6. Standalone Java

Among above, the first four are dominate java-based application server and I’m thinking Oracle AD4J is good to diagnose not only application server itself, but java application running on top. Oracle Database is the one which is supported absolutely by Oracle AD4J. Comparing to them, I’m highly interested in the offering to support “Standalone Java”. It might be possible for me to use Oracle AD4J instead in my endeavor on Java project diagnostics.

Popularity: 21% [?]

Today, I spent 30 minutes to re-read the Oracle official doc “Redo Logs and Recovery” and got my knowledge newly refreshed about this key concept with Oracle. Most importantly, I got the chance to know deeper about that.

I’m writing several points below for my own reference.

Point 1: Data in Redo Log Buffer was written to redo log file even though it’s not committed, at some circumstances.

Point 2: A checkpoint necessarily happens while redo log switch to performs the following three operations:

1. Every dirty block in the buffer cache is written to the data files. That is, it synchronizes the data blocks in the buffer cache with the datafiles on disk.
   It’s the DBWR that writes all modified database blocks back to the datafiles.
2. The latest SCN is written (updated) into the datafile header.
3. The latest SCN is also written to the control files.

Point 3: Beginning with 9i, new mechanism is implemented to improve performance while recovery.

In summary, that’s a real good official article to learn deeper internals of Redo Log and Recovery.

Popularity: 16% [?]