Taking Care – Error Handling - Applied SOA Patterns on the Oracle Platform - page 499

What is the role of RDA in this log's life cycle? The last incidents (the last 10 in total by
default in Version 11.1.1.6) will be collected by RDA and incorporated into other informa-
tion gathered using JMX, static, and runtime. Diagnostic Dumps and Incidents (which are
a collection of dumps and are created by DWF, stored in ADR, and aggregated by RDA)
can be:
• Adjusted to be more sensitive to log details, that is, additional details can be col-
lected at a certain level
• Bundled and packaged for uploading to Oracle support
• Purged from time to time after they are uploaded for proper analysis
The preceding points are essential tasks for Log Centralization, and Oracle has two addi-
tional instruments for them. The first one, Selective Tracing, is available in Version
11.1.1.4; it's a response to one of the major requirements: a low monitoring footprint with
an adequate level of tracing. This feature is managed by OEM or, more selectively, by
WLST, and fine-tuned selectivity can be based on any attributes (fields) of ODL.
The last two tasks are covered by Automatic Diagnostic Repository Command Interpreter
(ADRCI). Later OMF versions include the Perl-based utility, the so-called Incident Pack-
aging System (IPS), which is capable of packaging offline RDA bundles for uploading. To
some extent, it competes with the RDA itself.
Everything mentioned in the previous points fit very well to the Log Centralization, incid-
ent management, and SOA governance in general, but RDA, ADRCI, DFW, and even
WLDF are tools too reactive to be truly preventive. Indeed, aftermath dumps will not con-
tribute much to pulse monitoring of a runtime SOA. Yes, it's true, but you as an architect
will be aware that these tools work well in order to advise your ops where to start when it
comes to investigate complex composition errors scenarios (not just bare metal or bare
OFM infrastructure faults). It is also true that for all these tools and instruments, we have
a critical part, which is purely the runtime main diagnostic information provider: Dynamic
Monitoring Service (DMS).
DMS is delivered by default in the form of a servlet web app: <ORACLE_HOME>/mod-
ules/oracle.dms_<your_version>/dms.war . It can be accessed using ht-
tp://telco.ctu.com:7778/dms/Spy (set your host and port accordingly). You
will find a broad range of parameters that are combined in a collection of noun types and
their individual attributes and exposed as MBean instances. DMS presents them at
runtime for monitoring, which is performed through the already mentioned WLDF. This
monitoring is organized in the form of WLDF watches, monitoring particular DMS attrib-