Oracle Enterprise Manager Cloud Control Getting Started with Oracle Fusion Middleware Management, 12c Release 1 (12.1.0.2)

12c Release 1 (12.1.0.2)

E24215-02

Contents

Title and Copyright Information

Preface

- Audience

- Documentation Accessibility

- Related Documents

- Terminology

- Conventions

Part I Managing Oracle Fusion Middleware

1 Introduction to Middleware Management

- 1.1 Middleware Management with Enterprise Manager Cloud Control

- 1.2 Fusion Middleware Control Versus Cloud Control

- 1.2.1 Managing Fusion Middleware with Fusion Middleware Control

- 1.2.2 Key Oracle Fusion Middleware Management Features

2 Discovering Middleware Targets

- 2.1 Enabling Automatic Discovery of Fusion Middleware Targets

- 2.2 Discovering Targets Manually

- 2.2.1 Discovering a WebLogic 9.x or 10.x Domain Using Cloud Control

- 2.2.2 Discovering Multiple WebLogic Domains Via EM CLI

- 2.3 Discovering New or Modified Domain Members

- 2.3.1 Enabling Automatic Discovery of New Domain Members

- 2.3.2 Manually Checking for New or Modified Domain Members

3 Monitoring Middleware Targets

- 3.1 Monitoring Middleware Targets in Enterprise Manager

- 3.1.1 Oracle Fusion Middleware Components

- 3.1.2 Oracle Application Server Components

- 3.1.3 Non-Oracle Middleware Components

- 3.2 Out-of-Box Monitoring of Middleware Targets

- 3.2.1 Target Home Page

- 3.2.2 Out-of-box Metrics

- 3.2.3 Analyzing Historical Performance

- 3.2.4 Setting Metric Thresholds for Alert Notifications

- 3.2.5 Monitoring Templates

- 3.2.6 Managing and Creating Blackouts

- 3.2.7 Extend Monitoring for Applications Deployed to WebLogic Server

- 3.2.8 Request Monitoring

- 3.2.8.1 Defining and Managing Transactions Being Monitored

- 3.3 Diagnosing Performance Problems

- 3.3.1 Using Home Pages to Diagnose Performance Issues

- 3.3.2 Middleware Diagnostics Advisor

- 3.3.3 Diagnostics Snapshots

- 3.4 Administering Middleware Targets

- 3.4.1 Process Control

- 3.5 Lifecycle Management

- 3.5.1 Managing Configurations

- 3.5.2 Compliance Management

- 3.5.3 Patch Management

- 3.5.4 Provisioning

- 3.5.4.1 Cloning from Test to Production Environments

- 3.5.4.2 Scaling Out Domains

- 3.5.4.3 Deploying / Undeploying Java EE Applications

- 3.6 Managing Service Levels

- 3.7 Job System

- 3.7.1 Log File Rotation

- 3.8 Topology Viewer

- 3.9 Support Workbench

4 Testing Application Load and Performance

- 4.1 Introduction to Application Replay

- 4.2 Testing Against Real-World Application Workloads

- 4.3 Capturing Application Workload Using RUEI

- 4.4 Synchronized vs. Non-Synchronized Replay

- 4.5 Prerequisites and Considerations

- 4.5.1 Using RUEI to Capture Application Workloads

- 4.5.2 Configuring Required User Privileges in Enterprise Manager

- 4.5.3 Using Synchronization

- 4.5.4 Setting up the Test System Database

- 4.5.5 Restarting the Database and Application Stack

- 4.5.6 Setting up the Capture Directory

- 4.6 Understanding the Capture and Replay Process

- 4.7 Creating Application Workload Captures

- 4.8 Monitoring the Capture Process

- 4.9 Replaying Application Workload Captures

- 4.9.1 Preparing to Replay Workload Captures

- 4.9.2 Understanding Replays and Replay Tasks

- 4.9.3 Resolving References to External Systems

- 4.9.4 Remapping URLs

- 4.9.5 Substituting Sensitive Data

- 4.9.6 Replaying Workload Captures

- 4.9.7 Analyzing Replay Results

- 4.10 Troubleshooting Application Replay

Part II Managing Oracle SOA

5 Overview of Oracle SOA Management

6 Discovering and Monitoring Oracle BPEL Process Manager

- 6.1 Supported Versions

- 6.2 Understanding the Discovery Mechanism

- 6.3 Understanding the Discovery Process

- 6.4 Setting Up Oracle Software Library

- 6.5 Discovering BPEL Process Manager

- 6.5.1 Deployed to Oracle Application Server

- 6.5.2 Deployed to Oracle WebLogic Managed Server

- 6.5.2.1 Discovering Oracle WebLogic Managed Server

- 6.5.2.2 Deployed to Oracle WebLogic Managed Server

- 6.5.3 Deployed to IBM WebSphere Application Server

- 6.5.3.1 Discovering IBM WebSphere Application Server

- 6.5.3.2 Deployed to IBM WebSphere Application Server

- 6.6 Configuring BPEL Process Manager

- 6.6.1 Specifying Details for Monitoring BPEL Process Manager

- 6.6.2 Registering BPEL Process Manager Credentials and Host Credentials

- 6.7 Troubleshooting BPEL Process Managers

- 6.7.1 Discovery Errors on Target Details Page

- 6.7.2 Discovery Errors on Review Page

- 6.7.3 Discovery Errors on Review Page

- 6.7.4 Display Errors on Processes Page

- 6.7.4.1 No Credentials Specified for Monitoring BPEL Process Manager

- 6.7.5 Retrieving the OPMN Port

- 6.7.6 javax.naming.NameNotFoundException Error

- 6.7.7 javax.naming.NamingException Error

- 6.7.8 javax.naming.NoInitialContextException Error

- 6.7.9 Error While Creating BPEL Infrastructure Services

- 6.7.10 Metric Collection Errors for BPEL Process Manager Partner Link Metrics

- 6.7.11 Agent Monitoring Metric Errors

7 Discovering and Monitoring Oracle Service Bus

- 7.1 Supported Versions

- 7.2 Understanding the Discovery Mechanism

- 7.3 Understanding the Discovery Process

- 7.4 Downloading One-Off Patches

- 7.5 Discovering Oracle Service Bus

- 7.5.1 Discovering OSB Deployed to WLS Not Monitored by Enterprise Manager

- 7.5.2 Discovering OSB Deployed to WLS Monitored by Enterprise Manager

- 7.6 Enabling Management Packs

- 7.7 Troubleshooting Oracle Service Bus

- 7.7.1 Required Patches Missing

- 7.7.2 System and Service

- 7.7.3 SOAP Test

8 Discovering and Monitoring the SOA Suite

- 8.1 New Features in This Release

- 8.2 Supported Versions

- 8.3 Understanding the Discovery Process

- 8.4 Discovering the SOA Suite

- 8.4.1 Discovering the SOA Suite Using a Remote Agent

- 8.5 Post Discovery Steps

- 8.5.1 Configuring Instance Tracing

- 8.5.2 Viewing Application Dependency and Performance (ADP) Metrics

- 8.6 Setting Up and Using SOA Instance Tracing

- 8.7 Creating Reports

- 8.8 Dehydration Store Monitoring

- 8.8.1 Enabling Monitoring of the SOA Dehydration Store

- 8.8.2 Viewing the SOA Dehydration Store Data

- 8.9 Service Topology

- 8.10 UDDI Publishing

- 8.11 Provisioning SOA Artifacts and Composites

- 8.12 Troubleshooting

- 8.12.1 Discovery

- 8.12.2 Monitoring

- 8.12.3 Instance Tracing

- 8.12.4 Faults

- 8.12.5 Application Dependency and Performance Integration

- 8.12.6 Reports

- 8.12.7 Systems and Services

- 8.12.8 BPEL Recovery

- 8.12.9 SOA License Issue

- 8.12.10 Dehydration Store Issue

Part III Using JVM Diagnostics

9 Introduction to JVM Diagnostics

- 9.1 Overview

- 9.1.1 Java Activity Monitoring and Diagnostics with Low Overhead

- 9.1.2 In-depth Visibility of JVM Activity

- 9.1.3 Real Time Transaction Tracing

- 9.1.4 Cross-Tier Correlation with Oracle Databases

- 9.1.5 Memory Leak Detection and Analysis

- 9.1.6 JVM Pooling

- 9.1.7 Real-time and Historical Diagnostics

- 9.2 New Features in this Release

- 9.3 Supported Platforms and JVMs

- 9.4 User Roles

10 Using JVM Diagnostics

- 10.1 Installing JVM Diagnostics

- 10.1.1 Monitoring a Standalone JVM

- 10.2 Setting Up JVM Diagnostics

- 10.2.1 Viewing Registered JVMs and Managers

- 10.2.2 Configuring JVM Pools

- 10.2.2.1 Updating Pool Thresholds

- 10.2.3 Setting the Monitoring Status

- 10.2.4 Downloading the JVM Diagnostics Components

- 10.2.5 Registering the Database Target

- 10.3 Accessing the JVM Diagnostics Pages

- 10.4 Managing JVM Pools

- 10.4.1 Viewing the JVM Pool Home Page

- 10.4.2 Viewing the JVM Pool Performance Diagnostics Page

- 10.4.3 Viewing the JVM Pool Live Thread Analysis Page

- 10.5 Managing JVMs

- 10.5.1 Viewing the JVM Home Page

- 10.5.2 Viewing the JVM Performance Diagnostics Page

- 10.5.3 Viewing the JVM Diagnostics Performance Summary

- 10.5.4 Viewing the JVM Live Time Thread Analysis Page

- 10.5.4.1 Cross Tier Analysis

- 10.5.4.2 JVM Diagnostics - Oracle Real Application Cluster Drill-Down

- 10.5.5 Viewing the JVM Live Heap Analysis Page

- 10.6 Viewing the Thread Snapshots

- 10.6.1 Uploading Thread Snapshots

- 10.7 Analyzing Heap Snapshots

- 10.7.1 Viewing the Available Heap Snapshots

- 10.7.1.1 Viewing Heap Usage by Roots

- 10.7.1.2 Top 40 Objects

- 10.7.1.3 Heap Object Information

- 10.7.1.4 Comparing Heap Snapshots

- 10.7.2 Taking a Heap Snapshot

- 10.7.2.1 Taking A Heap Snapshot Only

- 10.7.2.2 Taking a Heap Snapshot And Loading Into Repository

- 10.8 Tracing Active Threads

- 10.9 Uploading Trace Diagnostics Images

- 10.10 Viewing the Available Traces

- 10.11 Analyzing Trace Diagnostic Images

- 10.12 JVM Offline Diagnostics

- 10.12.1 Creating a Diagnostic Snapshot

- 10.12.2 Using the Diagnostic Snapshots Page

- 10.12.3 Analyzing a Diagnostic Snapshot

- 10.12.4 Viewing a Diagnostic Snapshot

- 10.13 Viewing JVM Diagnostics Threshold Violations

11 Troubleshooting JVM Diagnostics

- 11.1 Cross Tier Functionality Errors

- 11.2 Trace Errors

- 11.3 Deployment Script Execution Errors

- 11.4 LoadHeap Errors

- 11.5 Errors on JVM Diagnostics UI Pages

- 11.6 Frequently Asked Questions

- 11.6.1 Location of the JVM Diagnostics Logs

- 11.6.2 JVM Diagnostics Manager Status

- 11.6.3 JVM Diagnostics Agent Status

- 11.6.4 Monitoring Status

- 11.6.5 Running the create_jvm_diagnostic_db_user.sh Script

- 11.6.6 Usage of the Try Changing Threads Parameter

- 11.6.7 Significance of Optimization Levels

- 11.6.8 Custom Provisioning Agent Deployment

- 11.6.9 Log Manager Level

- 11.6.10 Repository Space Requirements

Part IV Managing Oracle Coherence

12 Getting Started with the Oracle Coherence Management Pack

- 12.1 New Features in this Release

- 12.2 Supported Versions

- 12.3 Understanding the Discovery Mechanism

- 12.3.1 Configuring and Starting a Standalone Management Node

- 12.3.2 Configuring and Starting a Management Node in WebLogic Server

- 12.3.3 Starting the Coherence Management Node with Security Credentials

- 12.3.4 Configuring and Starting a Node With the JVM Diagnostics Agent

- 12.3.5 Discovering Coherence Targets

- 12.3.6 Corrective Actions

- 12.3.7 Refreshing a Cluster

- 12.4 Enabling the Management Pack

13 Monitoring a Coherence Cluster

- 13.1 Cluster Level Pages

- 13.1.1 Cluster Level Home Page

- 13.1.1.1 General

- 13.1.1.2 Graphs

- 13.1.1.3 Cluster Management

- 13.1.1.4 Services

- 13.1.1.5 Applications

- 13.1.1.6 Metric and Host Alerts

- 13.1.1.7 Cluster Level Operations

- 13.1.2 Cluster Level Node Performance Page

- 13.1.3 Cluster Level Cache Performance Page

- 13.1.4 Cluster Level Connection Performance Page

- 13.1.5 Cluster Level Administration Page

- 13.2 Detailed Pages

- 13.2.1 Node Home Page

- 13.2.2 Cache Home Page

- 13.2.3 Connection Manager Home Page

- 13.3 Performance Pages

- 13.3.1 Node Performance Page

- 13.3.1.1 Cache Performance Details Page

- 13.3.2 Administration Pages

- 13.3.2.1 Compare Configurations

- 13.3.2.2 Change Configuration

- 13.4 Log File Monitoring

- 13.5 Cache Data Management

- 13.6 Reap Session Support

- 13.7 Push Replication Pattern

- 13.8 Transactional Cache Support

- 13.9 Integration with JVM Diagnostics

- 13.9.1 Deploying on Standalone Coherence

- 13.9.2 Deploying on CoherenceWeb

- 13.10 Viewing Performance Summary

- 13.11 Viewing Configuration Topology

- 13.12 Troubleshooting Coherence

Part V Using Application Dependency and Performance

14 Introduction to Application Dependency and Performance

- 14.1 Overview

- 14.1.1 Managing Complex Java EE, SOA, and Portal Applications

- 14.1.2 Delivering a Service-Oriented View Across Environments

- 14.1.3 Avoiding Involvement from Java EE, SOA, Portal, and Application Experts

- 14.1.4 Eliminating Repetitive Do-It-Yourself (DIY) Manual Processes

- 14.1.5 ADP Solution

- 14.2 Architecture

- 14.2.1 ADP Java Agents

- 14.2.2 ADP Manager

- 14.2.2.1 ADP Manager and High Availability

- 14.2.3 ADP Database

- 14.2.4 ADP User Interface

15 Exploring Application Dependency and Performance

- 15.1 Exploring the User Interface

- 15.1.1 Accessing ADP

- 15.1.2 General ADP UI Elements

- 15.1.3 Drill Down in Operational Dashboard

- 15.1.4 Time Frame

- 15.1.5 Display Interval

- 15.1.5.1 Time Frame

- 15.1.5.2 Interval Context

- 15.1.5.3 Turning Off Time Frame Limitation

- 15.1.6 Graphs and Data Items

- 15.1.7 Right-Click Operations on Tables and Graphs

- 15.1.8 Comparative View

- 15.1.9 Save as PDF

- 15.1.10 Easy Scroller

- 15.1.11 Zoom In and Zoom Out Toolbar

- 15.1.12 Custom Metrics

- 15.1.13 Functional View

- 15.1.14 Topology View

- 15.1.15 Architecture View

- 15.1.15.1 Accessing the Architecture View

- 15.1.16 Metric Types

- 15.2 Exploring the Monitoring Tab

- 15.2.1 Monitoring ADP Entities

- 15.2.1.1 Monitoring SOA Suite 11g Performance

- 15.2.1.2 Monitoring OSB Performance

- 15.2.1.3 Monitoring Java EE Application Performance

- 15.2.1.4 Monitoring ADF Application Performance

- 15.2.2 WebLogic

- 15.2.2.1 Monitoring WebLogic Portal Performance

- 15.2.2.2 Adding WebLogic Domain To Be Monitored By Existing ADP Manager

- 15.2.2.3 Removing a WebLogic Domain From Monitoring

- 15.2.3 Oracle WebLogic Portals

- 15.2.3.1 Desktops

- 15.2.3.2 Portlet Drill Down

- 15.2.3.3 Pageflow Viewer

- 15.2.3.4 Books

- 15.2.3.5 Pages

- 15.2.3.6 Portlets

- 15.2.4 WebSphere Portals

- 15.2.4.1 Virtual Portals

- 15.2.4.2 Pages

- 15.2.4.3 Portlets

- 15.2.5 Oracle BPEL Processes

- 15.2.5.1 Delay Analysis View

- 15.2.5.2 Metadata View

- 15.2.5.3 Partner Links View

- 15.2.5.4 Partner Link Type Role View

- 15.2.5.5 Partner Link Bindings View

- 15.2.5.6 Modeled Entities View

- 15.2.5.7 Topology View

- 15.2.5.8 Node Hierarchy

- 15.2.6 Oracle ESB

- 15.2.6.1 Service Details View

- 15.2.6.2 Service Parent Details View

- 15.2.6.3 Service Definition View

- 15.2.6.4 Service Operations View

- 15.2.6.5 Operation Routing Rules View

- 15.2.7 Oracle WebCenter

- 15.2.7.1 ADF Task Flows

- 15.2.7.2 JSF Pages

- 15.2.7.3 Portlets

- 15.2.7.4 Monitoring WebCenter Performance

- 15.2.8 Processes

- 15.2.8.1 Node Hierarchy

- 15.2.8.2 Persistent Containers

- 15.2.8.3 Instrumentation

- 15.2.9 Web Services

- 15.2.10 Pageflows

- 15.2.11 Services

- 15.2.11.1 HTTP

- 15.2.11.2 EJBs

- 15.2.11.3 JDBCs

- 15.2.12 WSRP Producers

- 15.2.12.1 WSRP Summary

- 15.2.12.2 WSRP Topology

- 15.2.12.3 Display Portal Desktop

- 15.2.13 Integration

- 15.2.13.1 Health

- 15.2.13.2 Performance

- 15.2.13.3 Channels

- 15.2.13.4 Subscribers

- 15.2.14 Applications

- 15.2.14.1 Services

- 15.2.14.2 Dependencies

- 15.2.14.3 Deployments

- 15.2.14.4 Workshop Projects

- 15.2.14.5 Web Applications

- 15.2.14.6 Stateless Beans

- 15.2.14.7 Stateful Beans

- 15.2.14.8 Entity Beans

- 15.2.14.9 Message Driven Beans

- 15.2.15 Oracle WebLogic Resources

- 15.2.16 WebSphere Resources

- 15.2.17 Oracle Resources

- 15.2.18 Custom Metrics

- 15.2.19 ADP Node

- 15.2.20 Service Component Architecture (SCA)

- 15.2.20.1 Components

- 15.3 Exploring the Configuration Tab

- 15.3.1 Database Configuration

- 15.3.2 Resource Configuration

- 15.3.3 Service Level Objective Configuration

- 15.3.3.1 Creating a New SLO

- 15.3.3.2 Defining SLO Parameters

- 15.3.3.3 SLO Blackout Configuration

- 15.3.3.4 Creating and Maintaining SLO Blackouts

- 15.3.3.5 Propagating Threshold Violation Events

- 15.3.4 Action Configuration

- 15.3.5 Custom Metric Configuration

- 15.4 Exploring the Registration Tab

- 15.4.1 Using RMI Configuration for Managers

- 15.4.2 Adding a New Manager (RMI Configuration)

- 15.4.3 Editing a Previously Configured Manager (RMI Configuration)

- 15.4.4 Removing or Disabling a Previously Configured Manager

16 Exporting Data

- 16.1 Data Export Modes

- 16.1.1 Export to File

- 16.1.2 Export to Database

- 16.1.3 Aggregation Export to File

- 16.2 ADP Export Configuration

- 16.2.1 ADP Periodic Export Configuration

- 16.2.2 Manual Execution of Metric Export

- 16.2.3 export.xml File

- 16.3 Example of Exported Data for WebLogic

17 ADP Methodology

- 17.1 ADP Methodology Activities

- 17.1.1 Mapping Business SLAs to Performance SLOs

- 17.1.2 Specifying Target Performance Characteristics

- 17.1.3 Improving Performance

- 17.1.3.1 Characterizing Baseline Performance

- 17.1.3.2 Identifying Performance Bottlenecks

- 17.1.3.3 Removing Performance Bottlenecks

- 17.1.3.4 Setting SLOs on Key Metrics

- 17.2 Mapping Business SLAs to Performance SLOs

- 17.3 Characterizing Baseline Performance

- 17.4 Identifying Performance Bottlenecks

- 17.4.1 Determining System Level Performance

- 17.5 Setting SLOs on Key Metrics

- 17.6 Conclusion

18 Troubleshooting Application Dependency and Performance

- 18.1 Can I Erase the darchive Directory?

- 18.2 How Do I Undeploy the Agent?

A ADP Configuration Directories and Files

- A.1 Configuration Directories

- A.1.1 Directory Structure

- A.1.2 Config Directory

- A.1.3 Deploy Directory

- A.2 Acsera.properties File

- A.2.1 Log Files Management

- A.2.2 Multi-Domain Monitoring Configuration

- A.2.3 ADP RMI Port Assignment

- A.2.4 ADP Aggregation and Data Life Time Configuration

- A.2.5 Aggregating Incoming Metrics On the Fly

- A.2.6 Listing Applications to Be Monitored or Excluded From Monitoring

- A.2.7 Firewall Mitigation (for Internal RMI Ports)

- A.2.8 SLO Dampening

- A.3 UrlMap.properties

B Support Matrix for Application Dependency and Performance

- B.1 ADP Manager Platform Support

Index

Oracle® Enterprise Manager

Cloud Control Getting Started with Oracle Fusion Middleware Management

12c Release 1 (12.1.0.2)

E24215-02

February 2012

Oracle Enterprise Manager Cloud Control Getting Started with Oracle Fusion Middleware Management, 12c Release 1 (12.1.0.2)

E24215-02

Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved.

Contributor: Venkat Audinarayan, Neelima Bawa, Paul Coghlan, Jacqueline Gosselin, Dan Hynes, Maheshwari Hatte, Glen Hawkins, Arivalagan Kaliyaperumal, Shiraz Kanga, James Kao, Pushpa Raghavachar, Rishi Saraswat, Karthik Somasundaram

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.

Preface

This guide introduces you to managing Oracle Fusion Middleware with Oracle Enterprise Manager Cloud Control 12c Release 1.

The preface covers the following:

- Audience

- Documentation Accessibility

- Related Documents

- Terminology

- Conventions

Audience

This document is intended for users who want to discover and monitor Oracle Fusion Middleware products such as Oracle WebLogic Server and Oracle SOA components, as well as deployed Java EE applications. It is also intended for users of JVM Diagnostics and Application Dependency and Performance.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.

Related Documents

For more information, see the following documents in the Enterprise Manager Cloud Control documentation library:

- Oracle Enterprise Manager Cloud Control Introduction

- Oracle Enterprise Manager Cloud Control Basic Installation Guide

- Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide

For the latest releases of these and other Oracle documentation, check the Oracle Technology Network at:

http://www.oracle.com/technetwork/documentation/index.html#em

Oracle Enterprise Manager also provides extensive online Help. Click Help at the top of any Enterprise Manager page to display the online help window.

Terminology

The following terminology is used throughout this manual.

Term

Definition

ASM

Application Service Management

APM

Application Performance Management

DIY

Do-It-Yourself

ISV

Independent Software Vendor

Request Trace

A single thread executing a request. Shows as a bar in the hierarchy view (Application Dependency and Performance).

Request Trace Events

The nodes in the left pane (Application Dependency and Performance)

Request Trace Event View

Transaction event view (Application Dependency and Performance)

SLA

Service Level Agreement

SLO

Service Level Objective

SOA

Service-Oriented Architecture

Transaction Analysis

Transaction tracing (Application Dependency and Performance)

Transaction Hierarchy View

The Transaction Hierarchy View displays a complete transaction hierarchy in a Gantt chart representation showing the execution of each transaction on an absolute time line.

UI

User Interface

WSRP

Web Services Remote Portlets

WSDL

Web Services Description Language

Conventions

The following text conventions are used in this document:

Convention

Meaning

boldface

Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary.

italic

Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values.

monospace

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter.

Part I

Managing Oracle Fusion Middleware

The chapters in this part describe how you can discover and monitor Oracle Fusion Middleware targets, including Oracle WebLogic Server and deployed Java EE applications.

The chapters are:

- Chapter 1, "Introduction to Middleware Management"

- Chapter 2, "Discovering Middleware Targets"

- Chapter 3, "Monitoring Middleware Targets"

- Chapter 4, "Testing Application Load and Performance"

1 Introduction to Middleware Management

This chapter provides an introduction to how you can use Oracle Enterprise Manager Cloud Control to monitor and manage middleware software, including Oracle Fusion Middleware and Oracle WebLogic Server.

This chapter covers the following:

- Middleware Management with Enterprise Manager Cloud Control

- Fusion Middleware Control Versus Cloud Control

1.1 Middleware Management with Enterprise Manager Cloud Control

Middleware is the software that enables your enterprise applications to run. Managing the underlying middleware technology can be difficult, and IT organizations often have to rely on a variety of specialized tools. This can lead to inefficiency and may introduce complexities and risks.

Enterprise Manager Cloud Control is the definitive tool for middleware management and allows you to manage both Oracle applications and custom Java EE applications that run on a combination of Oracle Fusion Middleware as well as non-Oracle middleware software.

Oracle Enterprise Manager Cloud Control is a Web browser-based, graphical user interface that you can use to monitor multiple Oracle Fusion Middleware Farms and Oracle WebLogic Server Domains. In fact, Cloud Control provides deep management solutions for Oracle technologies including Oracle packaged applications, Oracle Database and Oracle VM.

Enterprise Manager Cloud Control supports the discovery, monitoring and central management of the entire family of Oracle Fusion Middleware components, including:

- Oracle WebLogic Server farms, domains, clusters and single server instances

- Clustered and standalone Java EE applications

- Web tier components, including Oracle HTTP Server and Oracle Web Cache

- Service-Oriented Architecture (SOA) components

- Oracle Identity Management

- Metadata Services repositories

- Oracle WebCenter

- Oracle Portal

- Oracle Business Intelligence Discoverer

- Oracle Forms Services

- Oracle Reports

- Directory Server Enterprise Edition

- Oracle Coherence

- Oracle Exalogic Elastic Cloud

Cloud Control also offers extensive support for non-Oracle technologies through more than two dozen heterogeneous management plug-ins and connectors including Microsoft MOM, IBM WebSphere Application Server, JBoss Application Server, EMC storage, F5 BIG IP, Check Point Firewall, and BMC Remedy.

A key benefit of Enterprise Manager Cloud Control is that unlike other Fusion Middleware management utilities - such as Fusion Middleware Control and the WebLogic Server Administration Console - you can monitor and manage multiple middleware targets, such as all of your WebLogic Server domains, from a single console.

You can also view real time as well as historic performance metrics collected from middleware targets. This enables you to monitor the availability and performance of Oracle Fusion Middleware software both in real time and from a historical perspective for trend analysis and diagnosing availability and performance problems.

Enterprise Manager Cloud Control also enables you to manage the infrastructure upon which the middle tier depends. You can manage underlying operating systems and hosts on which the middleware software is installed. You can also monitor the databases used by deployed applications, enabling you to diagnose application performance problems and identify the true root cause of the problem and the tier (middleware, database) on which it occurs.

The built-in topology viewer allows you to visualize and monitor your entire Oracle Fusion Middleware environment in a graphical display. Topologies can be viewed for a single SOA composite, an Oracle WebLogic Domain, or across multiple Oracle WebLogic Domains.

Management of Service-Oriented Architecture (SOA) components such as BPEL processes and infrastructure components such as Oracle Service Bus, is also supported. The infrastructure provides monitoring, fault management, configuration management, deployment and dependency views of wiring between components.

1.2 Fusion Middleware Control Versus Cloud Control

This section compares the Oracle Fusion Middleware management capabilities of Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control) and Oracle Enterprise Manager Cloud Control.

1.2.1 Managing Fusion Middleware with Fusion Middleware Control

Fusion Middleware Control organizes a wide variety of performance data and administrative functions into distinct, Web-based home pages for the farm, cluster, domain, servers, components, and applications. The Fusion Middleware Control home pages make it easy to locate the most important monitoring data and the most commonly used administrative functions all from your Web browser.

Fusion Middleware Control is a part of the Oracle Fusion Middleware installation. With Fusion Middleware Control, you can:

- Manage a single Oracle Fusion Middleware Farm and a single WebLogic Domain.

- Monitor the availability and performance of Fusion Middleware software in real time mode.

- Perform routine administration tasks such as deploying applications, configuring parameters etc.

For more details, see the Oracle Fusion Middleware 11g Administrator's Guide.

1.2.2 Key Oracle Fusion Middleware Management Features

Cloud Control provides full historical monitoring across the middleware tier, from WebLogic Server instance and the Java virtual machine (JVM) it runs within to the Oracle Fusion Middleware components running on the application server. It also provides full configuration and lifecycle management of middleware components, while the product's extensive performance monitoring and diagnostics capabilities enable troubleshooting issues anywhere within the middleware tier.

With Oracle Enterprise Manager Cloud Control, you can:

- Centrally manage multiple Oracle Fusion Middleware Farms and WebLogic Domains.

- Manage third party products such as IBM WebSphere Application Server, JBoss Application Server, Apache Tomcat and the Microsoft .NET Framework.

- Manage non-middleware software such as underlying operating systems and hardware on which the middleware software is installed. This allows administrators to correlate middleware performance with its underlying host performance.

- Manage database software and diagnose application performance problems and identify the true root cause of the problem and the tier (middleware, database) on which it occurs.

- Monitor the availability and performance of Oracle Fusion Middleware software in real time and from a historical perspective for trend analysis.

- Diagnose availability and performance problems.

- Monitor and trace important end-user requests from the client to the service endpoint across all the servers and applications associated with each transaction.

- Use Application Dependency and Performance (ADP) to analyze Java EE and SOA applications.

- Monitor Java applications and diagnose performance problems in production using JVM Diagnostics.

- Define Service Level Objectives (SLOs) in terms of out-of-box system-level metrics as well as end user experience metrics to accurately monitor and report on Service Level Agreement (SLA) compliance.

- Perform several critical tasks like:

- Setting thresholds on performance metrics. When these thresholds are violated, e-mail and page notifications are sent.

- Tracking configuration changes and compare configurations between example test environment and production environment.

2 Discovering Middleware Targets

In order to manage and monitor Oracle Fusion Middleware components such as WebLogic Server instances and clusters, as well as the Java EE applications that depend on them, Enterprise Manager Cloud Control must first "discover" the Fusion Middleware Domain containing these components.

Once discovered, the domain and the components within it can be promoted to "managed target" status. In this process, Management Agents are assigned to each target, enabling Enterprise Manager Cloud Control to collect the data needed to monitor the target.

This chapter contains the following sections:

- Enabling Automatic Discovery of Fusion Middleware Targets

- Discovering Targets Manually

- Discovering New or Modified Domain Members

2.1 Enabling Automatic Discovery of Fusion Middleware Targets

Cloud Control provides the ability to automatically search for potential Oracle Fusion Middleware targets on host machines that are already being managed by Cloud Control. You can configure automatic discovery to run on a regular schedule, such as every 2 days. Discovery is run every 24 hours by default.

Once automatic discovery has been configured, you can check the Auto Discovery Results page to see what new Oracle Fusion Middleware targets have been discovered. You can then promote targets to managed target status by assigning a Management Agent to monitor and manage the target.

The following describes the process for configuring automatic discovery of Oracle Fusion Middleware targets only. However, Cloud Control actually enables you to configure discovery of a variety of Oracle target types.

Note that the automatic discovery feature is not supported for Oracle WebLogic Server versions 7.x or 8.x.

1. From the Setup menu, select Add Target, then select Configure Auto Discovery.

2. Set the schedule at which the discovery job will be run, in days. This schedule will be applied to all selected hosts. By default the job will run every 24 hours.

3. Click Add Host. Select the host machine(s) you want to include in the discovery.

4. Select a host in the table, then click Edit Parameters to specify the Middleware Homes to search for targets. The Middleware Home is the top-level directory for all Oracle Fusion Middleware products, created when Oracle WebLogic Server is installed.
Enter * to search all Middleware Homes, or specify the path to one or more Middleware Homes on the host, each separated by a comma.

5. Click OK. At this point, automatic discovery has been enabled, and the discovery job will run at the scheduled frequency.

6. Once automatic discovery has been enabled, you should check Cloud Control regularly to view the list of discovered targets. From the Setup menu, select Add Target, then select Auto Discovery Results.

7. Click the Non-Host Targets tab to view the discovered Oracle Fusion Middleware targets.

8. Select a target, then click Promote.
If multiple targets of various types are listed, you can expand Search, then select the Target Type you are looking for (such as Oracle WebLogic Domain). Click Search to display the selected discovered target types.

9. Supply or accept values for the following parameters:

- The host name for the WebLogic Administration Server for the domain in the Administration Server Host field. For example: myhost06.example.com

- The WebLogic Administration Server port.

- If the WebLogic Administration Server is secured using the Secure Sockets Layer (SSL) protocol, specify the location of the trusted keystore file. The keystore is a protected database that holds keys and certificates for an enterprise.
For additional details on discovering a domain secured with SSL, see section "C" in My Oracle Support Note 1093655.1. You can access My Oracle Support at the following URL:

https://support.oracle.com/CSP/ui/flash.html

- The WebLogic Administration Server user name and password.

- A Unique Domain Identifier. This value is used as a prefix to ensure farm names are unique in environments with the same domain name. By default, Enterprise Manager will assign the name "Farm", followed by a two-digit number, such as "Farm01".

- The host name for a Management Agent that will be used to discover the Fusion Middleware targets.
If a Management Agent exists on the WebLogic Administration Server host, the host name for this Management Agent will be supplied by default. However, you can specify any Management Agent on any host that is managed by Cloud Control to perform the discovery.

10. Click Continue. Enterprise Manager will discover all Fusion Middleware targets within the domain.

11. Click Close in the Finding Targets dialog to automatically assign Management Agents to the discovered targets.
The Assign Agents page lists each Fusion Middleware target discovered and the Management Agent assigned to each. Agents are automatically assigned as follows:

- If a local Management Agent is installed on the discovered target host, that Agent will be assigned.

- If a local Management Agent cannot be found on the host, the Agent specified in the Targets page will be assigned.

Note that you can also manually assign Management Agents to specific targets, if desired.

12. Click Add Targets to assign Management Agents as listed in the Assign Agents page.
The Saving Target to Agent processing window appears, indicating how many total targets have been added and successfully saved. It will also indicate the number of targets that were unsuccessfully added.

13. Click Close in the processing window when finished. The Results page displays the targets and Agent assignments.

14. Click OK when finished. There may be a delay before these targets are visible and monitored. All the agents used for monitoring the targets must be up

2.2 Discovering Targets Manually

This section covers the following:

- Discovering a WebLogic 9.x or 10.x Domain Using Cloud Control

- Discovering Multiple WebLogic Domains Via EM CLI

2.2.1 Discovering a WebLogic 9.x or 10.x Domain Using Cloud Control

Oracle WebLogic Server release 9.x and 10.x domains and their respective components can be discovered via Enterprise Manager Cloud Control. A wizard guides you through the discovery process.

1. From the Setup menu, select Add Target, then select Configure Auto Discovery.

2. Select the Add Non-Host Targets by Specifying Target Monitoring Properties option.

3. Select Oracle Fusion Middleware as the target type.

4. Click Add Using Guided Discovery.

5. Enter the host name for the WebLogic Administration Server for the domain in the Administration Server Host field. For example: myhost06.example.com

6. Enter the WebLogic Administration Server port. The default value is 7001.

7. Enter the WebLogic Administration Server user name and password.
If you want to discover the target only for monitoring purposes, then it is sufficient to provide a user name that has monitoring role. If you want to monitor the target and also perform start/stop operations, then ensure that you provide a user name that has either an operator role or an administrator role.

8. Supply or accept values for the following parameters:

- The host name for the WebLogic Administration Server for the domain in the Administration Server Host field.

- The WebLogic Administration Server port.

- If the WebLogic Administration Server is secured using the Secure Sockets Layer (SSL) protocol, specify the location of the trusted keystore file. The keystore is a protected database that holds keys and certificates for an enterprise.
For additional details on discovering a domain secured with SSL, see section "C" in My Oracle Support Note 1093655.1. You can access My Oracle Support at the following URL:

https://support.oracle.com/CSP/ui/flash.html

- The WebLogic Administration Server user name and password.

- A Unique Domain Identifier. This value is used as a prefix to ensure farm names are unique in environments with the same domain name. By default, Enterprise Manager will name the farm "Farm", followed by a two-digit number, such as, "Farm01".

- The host name for a Management Agent that will be used to discover the Fusion Middleware targets.
If a Management Agent exists on the WebLogic Administration Server host, the host name for this Management Agent will be supplied by default. However, you can specify any Management Agent on any host that is managed by Cloud Control to perform the discovery.

9. Specify a Unique Domain Identifier. This value is used as a prefix to ensure farm names are unique in environments with the same domain name. By default, Enterprise Manager will pre-pend the name with "Farm", followed by a two-digit number, such as, "Farm01".

10. If the target domain is secured, expand the Advanced node to specify the protocol to use in the Protocol field. The default value is t3.
For additional details on discovering a domain secured using the Secure Sockets Layer (SSL) protocol, see section "C" in My Oracle Support Note 1093655.1. You can access My Oracle Support at the following URL:

https://support.oracle.com/CSP/ui/flash.html

11. Optionally supply the Java Management Extensions (JMX) Service URL that will be used to establish a JMX connection to the WebLogic Administration Server. For example:
service:jmx:t3://server.example.com:5555/jndi/weblogic.management.mbeanservers.domainruntime

If you do not supply a value, Enterprise Manager will provide the Service URL based on the host port and protocol.

12. Optionally enter any system properties to be used by the Java process to connect to the WebLogic Administration Server in the Parameters field.
Supply space-separated name/value pairs. Preface each parameter with -D. For example:

-Dparam1=xxx -Dparam2=yyy -Dparam3=zzz

13. Click Continue. Enterprise Manager will discover all Fusion Middleware targets within the domain.

14. Click Close in the Finding Targets dialog to automatically assign Management Agents to the discovered targets.
The Assign Agents page lists each Fusion Middleware target discovered and the Management Agent assigned to each. Agents are automatically assigned as follows:

- If a local Management Agent is installed on the discovered target host, that Agent will be assigned.

- If a local Management Agent cannot be found on the host, the Agent specified in the Targets page will be assigned.

Note that you can also manually assign Management Agents to specific targets, if desired.

15. Click Add Targets to assign Management Agents as listed in the Assign Agents page.
The Saving Target to Agent processing window appears, indicating how many total targets have been added and successfully saved. It will also indicate the number of targets that were unsuccessfully added.

16. Click Close in the processing window when finished. The Results page displays the targets and Agent assignments.

17. Click OK when finished. There may be a delay before these targets are visible and monitored. All the agents used for monitoring the targets must be up

2.2.2 Discovering Multiple WebLogic Domains Via EM CLI

If you have multiple WebLogic domains that you want to manage through Enterprise Manager Cloud Control, you can use the Enterprise Manager Command Line Interface (EM CLI) discover_wls verb to discover them all at once, rather than discovering them one at a time using the discovery wizards.

The discover_wls verb can be used to discover WebLogic Server versions 7.x, 8.x, 9.x, and 10.x domains. The verb reads a file named domain_discovery_file that contains the information required to discover each domain.

See the Enterprise Manager Command Line Interface book for instructions on using the discover_wls verb.

2.3 Discovering New or Modified Domain Members

In the typical enterprise, Oracle WebLogic domains do not remain static. Instead, membership in the domain changes regularly: New Java EE applications are deployed, WebLogic Server instances are created or removed, clusters are added, and so on.

By default, Enterprise Manger Cloud Control is not automatically aware of changes made to Oracle WebLogic domains that have been configured as managed targets. However the application does provide the ability to discover and uptake new or modified domain members.

This section covers the following:

- Enabling Automatic Discovery of New Domain Members

- Manually Checking for New or Modified Domain Members

2.3.1 Enabling Automatic Discovery of New Domain Members

You can enable a pre-defined Cloud Control job named "WebLogic Domain Refresh" to automatically discover new domain members and add them as managed targets.

1. From the Targets menu, select Middleware.

2. Click on the WebLogic Domain you want to enable the job for in the Middleware home page.

3. In the General region of the page, click the timestamp link next to the WebLogic Domain Refreshed property. The Refresh WebLogic Domain dialog opens.

4. Check the Enable Automatic Refresh box in the Refresh WebLogic Domain dialog, then click OK.

Once enabled, the job will check for new domain members once every 24 hours by default. To change the job settings, including the frequency at which it is run:

1. Click the Jobs tab.

2. Click the job title in the Job Activity page.

3. Click Edit.

2.3.2 Manually Checking for New or Modified Domain Members

You can use Cloud Control to check a domain for new or modified members on a periodic basis.

1. From the Targets menu, select Middleware.

2. Click on the WebLogic Domain you want to enable the job for in the Middleware home page.

3. From either the Farm or WebLogic Domain menu, select Refresh WebLogic Domain. The Refresh WebLogic Domain dialog opens.

4. Click Continue. Cloud Control will search the domain for new and modified targets.

5. The Assign Agents page displays the Fusion Middleware targets discovered and the Management Agent assigned to each. Click Add Targets to assign Management Agents as listed in the Assign Agents page.
Agents are automatically assigned as follows:

- If a local Agent can be found on the target host, that Agent will be assigned.

- If a local Agent cannot be found on the host, the Agent specified in the Targets page will be assigned.

Note that you can also manually assign Agents to specific targets, if desired.

6. The Saving Target to Agent processing window appears, indicating how many total targets have been added and successfully saved. It will also indicate the number of targets that were unsuccessfully added.

7. Click Close in the processing window when finished. The Results page displays the targets and Agent assignments.

8. Click OK when finished. There may be a delay before these targets are visible and monitored. All the agents used for monitoring the targets must be up.

3 Monitoring Middleware Targets

This chapter describes how you can use Enterprise Manager to monitor Middleware software.

This chapter covers the following:

- Monitoring Middleware Targets in Enterprise Manager

- Out-of-Box Monitoring of Middleware Targets

- Diagnosing Performance Problems

- Administering Middleware Targets

- Lifecycle Management

- Managing Service Levels

- Job System

- Topology Viewer

- Support Workbench

3.1 Monitoring Middleware Targets in Enterprise Manager

To add Middleware related targets (e.g. Oracle Fusion Middleware 11g, Oracle WebLogic Domain, Oracle Application Server 10g, JBoss Application Server) to Enterprise Manager, follow these steps:

After you have added the target, you can view general information about the targets including their status and availability on the Middleware page. You can drill down into each target to get further details like how the target is performing, where it is deployed, the version, location of its home directory, and so on.

You can also view the number of critical, warning, and error alerts generated for the past 24 hours. These alerts indicate that a particular metric condition has been encountered. For example, an alert is triggered when a metric threshold is reached. Using these details, you can drill down to investigate the target and the problem that triggered the alert.

You can monitor the following components using Oracle Enterprise Manager Cloud Control:

- Oracle Fusion Middleware Components

- Oracle Application Server Components

- Non-Oracle Middleware Components

3.1.1 Oracle Fusion Middleware Components

A farm is a collection of components managed by Fusion Middleware Control. It can contain Oracle WebLogic Server domains, one Administration Server, one or more Managed Servers, and the Oracle Fusion Middleware components that are installed, configured, and running in the domain. You can monitor the following Oracle Fusion Middleware components using Enterprise Manager:

- Oracle WebLogic Server Domains, Clusters, and Managed Servers: A WebLogic Server domain is a logically related group of WebLogic Server resources that you manage as a unit. A domain includes one or more WebLogic Servers and may also include WebLogic Server clusters. Clusters are groups of WebLogic Servers instances that work together to provide scalability and high-availability for applications. With Oracle Enterprise Manager, you can monitor and manage the farm, domains, clusters, servers, and deployed applications.

- Oracle SOA Suite: The Oracle SOA Suite enables services to be created, managed, and orchestrated into SOA composite applications. Composite applications enable you to easily assemble multiple technology components into one SOA composite application. Oracle SOA Suite plugs into heterogeneous infrastructures and enables enterprises to incrementally adopt SOA. You can:

- Automatically discover and model SOA components such as BPEL Process Manager, Oracle Service Bus, Service Engines etc.

- Monitor the health and performance of the SOA components.

- Trace the flow of an instance across all SOA Infrastructure applications.

- Create systems, services, and aggregate services.

- Oracle WebCenter: The Oracle WebCenter is an integrated set of components with which you can create social applications, enterprise portals, collaborative communities, and composite applications, built on a standards-based, service-oriented architecture. It combines dynamic user interface technologies with which to develop rich internet applications, the flexibility and power of an integrated, multichannel portal framework, and a set of horizontal Enterprise 2.0 capabilities delivered as services that provide content, collaboration, presence, and social networking capabilities. Based on these components, Oracle WebCenter also provides an out-of-the-box, enterprise-ready customizable application, WebCenter Spaces, with a configurable work environment that enables individuals and groups to work and collaborate more effectively.

- Oracle Web Tier: This consists of:

- Oracle HTTP Server: Oracle HTTP Server (OHS) is the underlying deployment platform for all programming languages and technologies that Oracle Fusion Middleware supports. It provides a Web listener and the framework for hosting static and dynamic pages and applications over the Web. Based on the proven technology of the Apache 2.2.10 infrastructure, OHS includes significant enhancements that facilitate load balancing, administration, and configuration. It also includes a number of enhanced modules, or mods, which are extensions to the HTTP server that extend its functionality for other enterprise applications and services. You can:

- Automatically discover and monitor Oracle HTTP Servers running within the application servers.

- View a list of metrics to gauge the server performance and virtual host performance.

- View the top URLs being accessed.

- Perform the enterprise configuration management tasks like viewing, comparing, and searching configuration information.

- Oracle Web Cache: Oracle Web Cache is a content-aware server accelerator, or reverse proxy, for the Web tier that improves the performance, scalability, and availability of Web sites that run on any Web server or application server, such as Oracle HTTP Server and Oracle WebLogic Server. Oracle Web Cache is the primary caching mechanism provided with Oracle Fusion Middleware. Caching improves the performance, scalability, and availability of Web sites that run on Oracle Fusion Middleware by storing frequently accessed URLs in memory. You can:

- Automatically discover and monitor OracleAS Web Cache instances running within application servers.

- View the metrics associated with this target to analyze their performance.

- Perform enterprise configuration tasks like viewing, comparing, and searching configuration information.

- Oracle Identity Management: This is an enterprise identity management system that automatically manages users' access privileges within the resources of an enterprise. The architecture of Oracle Identity Management works with the most demanding business requirements without requiring changes to existing infrastructure, policies, or procedures. It provides a shared infrastructure for all Oracle applications. It also provides services and interfaces that facilitate third-party enterprise application development. These interfaces are useful for application developers who need to incorporate identity management into their applications.

- Oracle Portal: This is a Web-based tool for building and deploying e-business portals. It provides a secure, manageable environment for accessing and interacting with enterprise software services and information resources. A portal page makes data from multiple sources accessible from a single location.

- Oracle Forms Services is a middle-tier application framework for deploying complex, transactional forms applications to a network such as an Intranet or the Internet. With Oracle Forms Services, business application developers can quickly build comprehensive Java client applications that are optimized for the Internet without writing any Java code, and that meet (and exceed) the requirements of professional user communities. These Java client applications are Web-deployed applications available on demand for rapid processing of large amounts of data and rapid completion of complex calculations, analysis, and transactions.

- Oracle Coherence is a component of Oracle Fusion Middleware that enables organizations to predictably scale mission-critical applications by providing fast and reliable access to frequently used data. By automatically and dynamically partitioning data in memory across multiple servers, Oracle Coherence enables continuous data availability and transactional integrity, even in the event of a server failure. As a shared infrastructure, Oracle Coherence combines data locality with local processing power to perform real-time data analysis, in-memory grid computations, and parallel transaction and event processing. Oracle Coherence comes in three editions. You can:

- Discover and manage a Coherence cluster and its various entities.

- Monitor and configure various components such as nodes, caches, services, connections, and connection manager instances of a Coherence cluster.

- Deploy and install a Coherence node based on the Provisioning Advisory framework.

- Oracle Business Intelligence is a complete, integrated solution that addresses business intelligence requirements. Oracle Business Intelligence includes Oracle Business Intelligence Reporting and Publishing, Oracle Business Intelligence Discoverer, and Oracle Business Intelligence Publisher. You can:

- Manually discover Oracle BI Suite EE targets, and monitor their overall health.

- Diagnose, notify, and correct performance and availability problems in Oracle BI Suite EE targets.

- Access current and historical performance information using graphs and reports.

- Perform enterprise configuration management tasks like viewing, comparing, and searching configuration information.

- Oracle Universal Content Management System provides a unified application for several different kinds of content management. It is an enterprise content management platform that enables you to leverage document management, Web content management, digital asset management, and records retention functionality to build and complement your business applications. Building a strategic enterprise content management infrastructure for content and applications helps you to reduce costs, easily share content across the enterprise, minimize risk, automate expensive, time-intensive and manual processes, and consolidate multiple Web sites onto a single platform for centralized management. Through user-friendly interfaces, roles-based authentication and security models, Oracle Universal Content Management empowers users throughout the enterprise to view, collaborate on or retire content, ensuring that all accessible distributed or published information is secure, accurate and up-to-date.

3.1.2 Oracle Application Server Components

You can monitor Oracle Application Server 10g components like Oracle Application Server Farms, Oracle Application Server Clusters, Oracle Application Servers, OC4J, Oracle HTTP Servers, Oracle Web Cache, Oracle Portal, Oracle Wireless, Oracle Forms Services, Oracle Reports Services, Oracle Business Intelligence, and Oracle Identity Management.

3.1.3 Non-Oracle Middleware Components

In addition to monitoring Oracle Middleware components, Enterprise Manager can also be used to monitor non-Oracle Middleware software. The third-party Middleware software that can be monitored includes the following:

- WebSphere Application Server

- WebSphere MQ

- JBoss Application Server

- Apache Tomcat

- Apache HTTP Server

- Microsoft Exchange Server

- Microsoft Internet Information Services

- Microsoft Active Directory

- Microsoft Commerce Server

- Microsoft BizTalk Server

- Microsoft Internet Security and Acceleration

- Microsoft .NET Framework

3.2 Out-of-Box Monitoring of Middleware Targets

Enterprise Manager organizes a wide variety of performance data and administrative functions into distinct, Web-based home pages for the farm, domain, servers, components, and applications.

3.2.1 Target Home Page

Enterprise Manager provides centralized monitoring across domains, configuration management, provisioning, real time and historical performance analysis. You need to drill down to Oracle Fusion Middleware Control to perform administrative tasks and manage components in your farm.

The Home pages make it easy to locate the most important monitoring data and the most commonly used administrative functions—all from your Web browser.

When you login into Enterprise Manager and select a Middleware target, the Home page for the target is displayed. For example, when you click on a WebLogic Server target in the Middleware page, the following screen is displayed.

Figure 3-1 WebLogic Server Home Page

This figure shows the target navigation pane on the left and the content page on the right. From the target navigation pane, you can expand the tree and select a component or an application. When you select a target, the target's home page is displayed in the content pane and that target's menu is displayed at the top of the page, in the context pane. You can also view the menu for a target by right-clicking the target in the navigation pane.

In the preceding figure, the following items are called out:

- Target Navigation Pane lists all of the targets in a navigation tree

- Content Pane shows the current page for the target. When you first select a target, that target's home page is displayed.

- Dynamic Target Menu provides a list of operations that you can perform on the currently selected target. The menu that is displayed depends on the target you select. The menu for a specific target contains the same operations as those in the Right-Click Target Menu.

- Right-Click Target Menu provides a list of operations that you can perform on the currently selected target. The menu is displayed when you right-click the target name in the target navigation pane. In the figure, even though the WebLogic Server is selected and its home page is displayed, the right-click target menu displays the operations for the selected target.

- Target Name is the name of the currently selected target.

- Context Pane provides the host name, the time of the last page refresh, the Refresh icon, and the Personalize Page icon.

- View: You can select options to Expand All / Collapse All, Scroll First, and Scroll Last in the navigation tree.

- Refresh icon indicates when the page is being refreshed. Click it to refresh a page with new data. (Refreshing the browser window refreshes the page but does not retrieve new data.)

From the Home page, you can also access the Fusion Middleware Control and WebLogic Server Administration Console by clicking on the appropriate link or selecting the appropriate menu item on the page.

3.2.2 Out-of-box Metrics

Enterprise Manager provides a set of pre-defined performance metrics for each Middleware target. These metrics are available for domains, cluster, server, applications, web services, resources etc. The metric data is collected and stored in the Management Repository. For more details on the pre-defined metrics, see the Oracle Fusion Middleware Metric Reference Guide.

For example, Enterprise Manager can automatically monitor:

- The CPU or memory consumption of the application server, including detailed monitoring of individual Java Virtual Machines (JVMs) being run by Oracle WebLogic servers.

- Java EE application responsiveness from the application down through individual servlets and Enterprise JavaBeans (EJBs)

- Oracle HTTP Server session volumes, connection duration, and error rates

- Oracle Web Cache hit rates and volumes

- Top servlets based on number of requests, maximum processing time, and highest average processing time

The performance metrics provide details about the metric as a current real time value (30 seconds, 1 minute, or 5 minutes) or a previous value (past 24 hours, 7 days, or 31 days). The historical information is displayed as graphs and a table. By using graphs, you can easily watch for trends, and by using tables, you can examine details of past metric severity history. The out-of-metrics can be viewed from the performance summary pages as shown below:

Figure 3-2 Performance Summary Page

You can change which charts are displayed on the performance page and then save the changes on a per-user, per-target-type basis. You can also save multiple customized versions of a performance page, giving each version a name. This will save time by allowing quick access to previously created version of the page. The Performance Summary feature allows you to create named chart views. The generic performance page is always shown in the context of one primary target. However, the performance of that target may be dependent on, or affect the performance of other targets. To explore these relationships you can chart metrics for multiple related targets on one performance page. The Performance Summary feature allows you to chart metrics for multiple related targets.

3.2.3 Analyzing Historical Performance

Enterprise Manager allows you to analyze historic metric data and perform trend analysis. In Fusion Middleware Control, you cannot analyze historical metric data and the real-time analysis is limited to a single domain. But in Enterprise Manager, the metrics are collected and stored in the Management Repository, so you can analyze the data well after the situation has changed. For example, you can use historical data and diagnostic reports to research an application performance problem that occurred days or even weeks ago.

You can even provide a customized time period for which the data should be retrieved from the Management Repository. You can customize the time period for:

- Pre-defined range of the last 24 hours, last 7 days, or last 31 days

- Customized range of any number of days, weeks, months, or years

- Any start date and end date (such that the duration is not greater than 99 years)

Note:
You can analyze historical metric data with Enterprise Manager only. You cannot use Fusion Middleware Control to analyze historic performance.

3.2.4 Setting Metric Thresholds for Alert Notifications

Metric snapshots are named snapshots of a target's past performance. You can use metric snapshots to calculate thresholds based on deviations from this past performance. Thresholds are boundary values against which monitored metric values are compared. You can specify a threshold such that, when a monitored metric value crosses that threshold, an alert is generated. You can get critical alerts when a monitored metric has crossed its critical threshold or warning alerts when a monitored metric has crossed its warning threshold.

Enterprise Manager provides a comprehensive set of features that facilitates automated monitoring and generation of alerts. You can gather and evaluate diagnostic information for targets distributed across the enterprise, and an extensive array of Middleware performance metrics are automatically monitored against predefined thresholds. By selecting a metric, you can determine whether the thresholds have been defined for a particular metric. These thresholds are used as a mechanism to generate alerts. These alerts in turn are used to notify you whether a target is up or down, the response time is slow, and so on. Thus, you can monitor their overall performance.

You can set up corrective actions to automatically resolve an alert condition. These corrective actions ensure that routine responses to alerts are automatically executed, thereby saving you time and ensuring that problems are dealt with before they noticeably impact the users.

3.2.5 Monitoring Templates

You can also use monitoring templates to simplify the task of standardizing monitoring settings across your enterprise. You can specify the monitoring settings once and apply them to all Oracle Fusion Middleware targets. A Monitoring template defines all the parameters you would normally set to monitor Middleware target, such as:

- Target type to which the template applies

- Metrics (including user-defined metrics), thresholds, metric collection schedules, and corrective actions

When a change is made to a template, you can reapply the template across the affected targets in order to propagate the new changes. You can reapply monitoring templates as often as needed.

3.2.6 Managing and Creating Blackouts

Enterprise Manager comes with a bundle of performance and health metrics that enable automated monitoring of application targets in your environment. When a metric reaches the predefined warning or critical threshold, an alert is generated and the administrator is notified.

However, there are occasions when you want to perform maintenance work on your Middleware targets, and not want any alerts to be generated while you are bringing them down. In this case, you can schedule a blackout and suspend monitoring of the Middleware targets.

Blackouts allow you to suspend any data collection activity on one or more monitored targets, thus allowing you to perform scheduled maintenance on targets. If you continue monitoring during these periods, the collected data will show trends and other monitoring information that are not the result of normal day-to-day operations. To get a more accurate, long-term picture of a target's performance, you can use blackouts to exclude these special-case situations from data analysis. Enterprise Manager allows you to define new blackouts; view the status of existing blackouts; and edit, stop, and delete blackouts that are not required.

3.2.7 Extend Monitoring for Applications Deployed to WebLogic Server

Many administrators often require custom logic to be written to check for conditions specific to their application environments. Enterprise Manager allows integration of application instrumentation in the Enterprise Manager event monitoring infrastructure. If application developers expose application instrumentation using standards like JMX or Web Services operations, then you can build management plug-ins for the instrumentation using easy-to-use command line tools, and leverage the Enterprise Manager event monitoring system to monitor it. You do not have to edit any XML files or write any integration code to integrate such instrumentation. Follow these procedures to integrate application-defined instrumentation:

- Use Command Line Interfaces that analyze MBean interfaces for JMX and WSDL for Web Services and create management plug-ins

- Import Management Plug-in Archive in Enterprise Manager

- Deploy Management Plug-in to Management Agents

- Create Target-type instances for the target types defined in Management Plug-in Archive

- Leverage the Enterprise Manager event monitoring system including monitoring templates, corrective actions, historical and real time metric views, alerts, customization of notification rules, and methods on events generated from application instrumentation metrics.

Administrators are able to add performance metrics beyond those available out-of-box for JMX-instrumented applications deployed on Oracle WebLogic Server. Administrators can additionally monitor JMX-enabled applications by defining new target type that can be monitored via management plug-ins, and then use a command line tool emjmxcli to automate the generation of the target metadata and collection files.All JMX-enabled applications deployed to the WebLogic Server can be consolidated and monitored by a single management tool, Enterprise Manager.

3.2.8 Request Monitoring

Request Monitoring provides end-to-end visibility into requests and helps localize end-user performance problems based on the deployment model. You can monitor, understand, and visualize how servers interact with each other to deliver business end-user services requests. You can trace important end-user requests from the client to the service endpoint across all the servers and applications associated with each transaction. The trace data is used to model the call-path for these requests where call-paths represent the inter-server relationship and performance metrics for these requests. You can only monitor synchronous transactions running on WebLogic servers. With Request Monitoring, you can:

- Trace end-user transactions and capture the complete call-path of important requests.

- Reduce problem localization by diagnosing poorly performing requests and identifying the servers whose behavior (service time) deviates most from the norm.

- Reduce fault discovery time and set performance level objectives on request response times.

- Reduce fault-reason identification time by allowing the user to launch into Oracle Enterprise Manager JVM Diagnostics feature. This allows performance diagnostics to be done within the context of the problem experienced as well as historical statistics of the system when it was behaving normally.

3.2.8.1 Defining and Managing Transactions Being Monitored

A request is a server entry-point that can be invoked by a Web Browser or an application. A group of request instances related to each other by some common attributes is known as a request. A collection of requests is known as a transaction group. A transaction can belong to one or more transaction groups. Violations occur when the critical and warning thresholds are exceeded. The administrator can mark one or more important requests as key requests. Alerts are generated for key requests only.

You can define requests that need to be monitored and tracked and group them for reporting purposes. A set of pre-defined requests and request groups are provided by default. You can create a new request, edit or delete an existing transaction. To define a request:

1. From the Targets menu, select Middleware.

2. From the Middleware Features menu, select Request Monitoring.

3. Click Request Performance to view the performance of the request during a specific time period.

Figure 3-3 Request Performance Page

4. Click on a request to drill down to the Performance tab. The performance charts show the volume of requests over a time period and the average response time of all requests during this period. Two performance charts are displayed for the current and the comparison period. The charts provide a historic response time analysis of the request over the selected period of time.

5. Click on the Topology tab. The following screen is displayed.

Figure 3-4 Topology Page

The topology chart shows the aggregate server level call paths of the request. The chart shows the calls made between the clients and the clusters or servers. Click on the icon on a cluster to view all the servers that are part of the cluster. Place the cursor on a cluster or server to view the following details:

- Response Time: The average response time taken by the server to process all the calls for the selected period.

- Count: The total number of calls that have been made to the server.

- Current Alerts: These alerts show the status of the server or cluster and indicate whether it is up or down, blacked out, or unreachable.

6. Click on the Server Usage tab. The following screen is displayed.

Figure 3-5 Server Usage Page

These charts show the workload distribution for the selected request in each server. The charts display the average of the percentage contribution of each server or cluster in the selected time period. You can see the workload distribution for good requests, requests that have violated the warning thresholds, and requests that have violated the critical thresholds.

3.3 Diagnosing Performance Problems

This section describes the methods and tools used to diagnose performance problems. You can:

- View the list of most active Servlets and JSPs and identify the ones that are causing the bottleneck.

- Analyze Java EE and SOA applications using Application Dependency and Performance.

- Use Java Diagnostics to diagnose performance problems in production.

3.3.1 Using Home Pages to Diagnose Performance Issues

When you are troubleshooting performance problems, it can be helpful to know which servlets or JSPs are the most active. By viewing the Most Requested section on the WebLogic Server Home page, you can identify the most active Java servlets, JSPs, Web Services, or Java EE Services running on the WebLogic Server instance.

When you receive an alert notification, Enterprise Manager makes it easy for you to investigate the problem and take corrective actions wherever required. For example, notification of excessive CPU consumption by WebLogic Server may lead to investigation of the applications running on that instance. By using the Servlets and JSPs tab in the Most Requested section of the WebLogic Server Home page, you can quickly identify the highest volume or least responsive application. You can then drill down and diagnose application's servlets, Java Server Pages (JSPs), or EJBs to identify the bottleneck.

Figure 3-6 WebLogic Server Home Page

3.3.2 Middleware Diagnostics Advisor

The Middleware Diagnostics Advisor analyzes the entire stack and provides diagnostic findings by identifying the root cause of a problem. It correlates and analyzes the input and offers advice on how to resolve the problem. For example, it can help you identify that slow SQL statements or a JDBC connection pool is causing a performance bottleneck.

You can view the diagnostic findings for one or more servers in a WebLogic Domain if the Middleware Diagnostics Advisor has been enabled.

To view the diagnostic findings, navigate to the Home page of the WebLogic Domain and from the WebLogic Domain menu, select Diagnostics, then select Middleware Diagnostics Advisor. The Performance Findings chart shows a window in time for the last analysis period that contains one or more findings. For details on enabling the Middleware Diagnostics Advisor and viewing the performance findings, see the Enterprise Manager Online Help.

3.3.3 Diagnostics Snapshots

A diagnostic snapshot consists of all the necessary data to diagnose an issue. The actual diagnostic snapshot data depends on what targets are included in generating the diagnostic snapshot. It also provides a collective snapshot of both JVM and WebLogic Server diagnostics and log data that can be exported or imported into other Cloud Control systems for analysis at a later date. This allows administrators to determine the root cause of problems and ensure that they do not occur again. These snapshots supplement the Fusion Middleware Support Workbench feature.

A diagnostic snapshot can be generated in the context of an Enterprise Manager target such as a Fusion Middleware Farm. If the diagnostic snapshot needs to be created in the context of multiple farms, then this can be done by generating the diagnostic snapshot in the context of a group target that includes multiple Fusion Middleware farms, or you can begin from one Fusion Middleware farm and subsequently add targets from other Fusion Middleware Farms.When generating the diagnostic snapshot, you can name the diagnostic snapshot, select the targets that should be used for generating the diagnostic snapshot, select the duration during which the data will be collected for the snapshot and also select an option to either import the generated diagnostic snapshot data into the same Enterprise Manager instance or export the generated diagnostic snapshot data into single or multiple files that can then be imported back into another Enterprise Manager instance (or the same Enterprise Manager instance) later.

3.4 Administering Middleware Targets

Enterprise Manager allows you to monitor multiple domains and provides configuration management, diagnostics, automation, and historical performance analysis. From Enterprise Manager, you can drill down to Oracle Fusion Middleware Control or Oracle WebLogic Administration Console to monitor and administer your Oracle Fusion Middleware environment

- Oracle Fusion Middleware Control: Fusion Middleware Control is a Web browser-based, graphical user interface that you can use to monitor and administer a farm. Fusion Middleware Control organizes a wide variety of performance data and administrative functions into distinct, Web-based home pages for the farm, domain, servers, components, and applications. With Fusion Middleware Control, you can perform various tasks like managing the SOA environment, deploying ADF applications, managing Fusion Middleware components, etc.

- Oracle WebLogic Server Administration Console: Oracle WebLogic Server Administration Console is a Web browser-based, graphical user interface that you use to manage a WebLogic Server domain. It is accessible from any supported Web browser with network access to the Administration Server. With the WebLogic Server Administration Console, you can perform various tasks like managing the WebLogic Server, managing data sources, JMS resources, etc.

3.4.1 Process Control

Enterprise Manager allows you to perform process control tasks such as starting, stopping, or restarting Middleware targets. You can perform these tasks by selecting the Control option in the menu from the Home page of a target. You can also schedule a job to perform these operations. For example, for a WebLogic Server Domain, you can create a job to automatically start, stop, or restart the servers in the domain. You can also view details about the jobs that are scheduled, running, suspended, or the ones that have a problem.

3.5 Lifecycle Management

Enterprise Manager Cloud Control offers lifecycle management solutions that help you meet all lifecycle management challenges easily by automating time-consuming tasks related to discovery, initial provisioning and cloning, patching, configuration management, ongoing change management, and compliance management.

3.5.1 Managing Configurations

Enterprise Manager provides a suite of configuration management functions that can be performed on Middleware targets.

Oracle Management Agent collects configuration information about Oracle Fusion Middleware targets from their respective configuration files, and communicates this information over HTTP/HTTPS to Oracle Management Service, which stores it in the Management Repository. This information is periodically collected and updated while maintaining the audit of changes. The Enterprise Manager configuration management capabilities efficiently guide the users to desired configuration data in a particular component.

You can compare these configuration details and view the differences and similarities between the two instances of a Middleware target. You have the flexibility to compare two last collected configurations or two saved configuration files. You can also compare one configuration with multiple configurations or one configuration in the Management Repository with a saved configuration file.

You can also compare configurations by using the default comparison templates. A comparison template is associated with a specific target type that determines the configuration item type and property that is to be compared. A template can specify rules or expressions that enable you parse comparison data and fine-tune comparisons. For example, you can specify rules that indicate which differences must trigger an alert and which differences must be ignored when the configuration is compared.

Using Enterprise Manager, you can search configurations across Middleware targets and find configuration anomalies - whether they are a mismatch of an install/patch version of Oracle Fusion Middleware software, or they are a mismatch of the software configuration data. You can perform more intelligent searches to identify all the components hosting a particular application or other resources.

In addition, for BPEL Process Manager targets, you can view the BPEL Processes, its different versions, and the suitcase files associated with each version. You can also compare the BPEL Process suitcase files of different versions and track the changes that were made to a version. shows you how the versions can be selected and compared. This allows you to identify the cause for improved or deteriorated performance due to a change in the BPEL Process suitcase file.

3.5.2 Compliance Management

Enterprise Manager Cloud Control offers the following compliance management solutions:

- The compliance results capability enables you to evaluate the compliance of Middleware targets and systems as they relate to your business best practices for configuration, security, and storage. In addition, compliance results provide advice of how to change configuration to bring your Middleware targets and systems into compliance.

- Using the compliance library, you can define, customize, and manage:

- Compliance frameworks

- Compliance standards

- Compliance standard rules

By using these self-defined entities, you can test your environment against the criteria defined for your company or regulatory bodies.

3.5.3 Patch Management

Patching is one of the critical phases of the software lifecycle that helps you maintain the software over a period of time and keep it updated with bug fixes and latest features offered by the software vendor.However, in today's world, with numerous software deployments across your enterprise, patching becomes very complex and virtually impossible to manage. Considering these challenges, Enterprise Manager Cloud Control provides an integrated My Oracle Support Patches and Updates functionality that not only simplifies the patch operation but also offers timely and easy access to patch and support information during the patch planning phase. This helps you utilize the wealth of information from My Oracle Support to implement the best possible patch rollout for your organization.Enterprise Manager Cloud Control introduces a new concept called Patch Plans that enables you to create a collection of patches you want to apply to one or more targets. Each target can have a separate group of patches. In addition, you can save the deployment options of a patch plan as a patch template, and have new patch plans created out of the patch template.

3.5.4 Provisioning

Rather than spend resources on manually installing and configuring Oracle Fusion Middleware software, administrators would rather spend time and money on more strategic initiatives. To help achieve this, Enterprise Manager has automated common provisioning operations such as cloning Oracle SOA Suite 12c and scaling out an Oracle WebLogic Domain. Making such critical datacenter operations easy, efficient and scalable results in lower operational risk and lower cost of ownership. To access these provisioning operations, navigate to the Patching and Provisioning page in Enterprise Manager and click Middleware Provisioning and select either of the following:

- Fusion Middleware Provisioning: You can automate the cloning of WebLogic Domains and / or Middleware Homes either from a reference installation or from a profile present in the software library.

- Fusion Middleware Domain Scale Up: You can automate the scaling up or scaling out of a domain or cluster by adding a new managed server to an existing cluster or by cloning a managed server.

For more details on using these procedures, see the Enterprise Manager Lifecycle Management Guide.

3.5.4.1 Cloning from Test to Production Environments

Typically, creating a new environment to support SOA applications entails several manual, error prone installation and configuration steps. With Oracle Enterprise Manager this can be accomplished with very little effort and time via a predefined, customizable deployment procedure. This deployment procedure clones an existing SOA Suite environment to a new set of hardware per a hierarchical series of steps. These predefined steps can be edited or disabled and new steps or custom scripts can be added to the deployment procedure to satisfy unique business needs.

The deployment procedure also supports secure host authentication using super user do (sudo) or pluggable authentication modules (PAM). While running the deployment procedure, administrators can specify configuration settings such as the domain name, credentials for the administration console, port values, and JDBC data resources. After the procedure completes, the newly created SOA environment is discovered and automatically added to the console for centralized management and monitoring.

3.5.4.2 Scaling Out Domains

To address growing business demands, modern data centers must augment and relocate resources quickly. Using Oracle Enterprise Manager, administrators can rapidly scale out a WebLogic Domain and Cluster with additional managed servers to accommodate an increase in application load.

3.5.4.3 Deploying / Undeploying Java EE Applications

You can deploy, undeploy, and redeploy Java EE applications (.war and .ear files) on a WebLogic Server. You can create a Java EE Application component in the Software Library and deploy multiple versions of an application, or roll-back to a previous version.

3.6 Managing Service Levels

Enterprise Manager allows you to create infrastructure services for Middleware targets such as Oracle BPEL Process Manager targets, Oracle Service Bus targets and Oracle SOA Composite and SOA Infrastructure instances.

An infrastructure service is a dependency service that is created to identify the infrastructure components on which the Middleware target depends. Here, the infrastructure components refer to hosts, databases, application servers, and so on that work together to host the Middleware target.

You can either create an infrastructure service with a new system or an existing system, or simply refresh an existing infrastructure service, if there is already one existing. By creating infrastructure services and systems, you can better manage your Middleware targets and also the components on which the Middleware targets depend.

Figure 3-7 Create Service for SOA Infrastructure

For example, once you create an infrastructure service for an Oracle SOA Infrastructure target, Enterprise Manager allows you to create an aggregate service for every process within that SOA Infrastructure target. An aggregate service is a logical grouping of services, in this case, infrastructure services and availability services. Aggregate Services give you a bird's-eye view of the services that have been created for the SOA Infrastructure target and helps you monitor their availability, performance, and usage. Service availability can be composed of both metrics on the underlying target and service test results from period synthetic transaction execution.

You can define service level (measure of service quality) for a service. A service level is defined as the percentage of time during business hours a service meets specified availability, performance and business criteria.

A Service Level specifies the percentage of time a service meets the performance and availability criteria as defined in the Service Level Rule. By default, a service is expected to meet the specified criteria 85% of the time during defined business hours. You may raise or lower this percentage level according to service expectations. A service level measures service quality using two parameters: Expected and Actual Service Levels.

- Expected Service Level: A Service Level specifies the percentage of time a service meets the performance and availability criteria as defined in the Service Level Rule. By default, a service is expected to meet the specified criteria 85% of the time during defined business hours. You may raise or lower this percentage level according to service expectations.

- Actual Service Level: The Actual Service Level defines the baseline criteria used to define service quality.

3.7 Job System

You can use Enterprise Manager job system to schedule tasks you want to automate. You can schedule a job for a target by selecting the Control menu option on the Home page. For example, for an Oracle WebLogic Server Domain, you can create a job to automatically start, stop, or restart the servers in the domain. You can view details about the jobs that are scheduled, running, suspended, or the ones that have a problem. You can also use jobs to automate the execution of the WLST (WebLogic Scripting Tool) scripts.

3.7.1 Log File Rotation

Oracle Application Server components generate log files containing messages that record all types of events, including startup and shutdown information, errors, warning messages, access information on HTTP requests, and additional information.

However, the information recorded in log files is voluminous, thus making it difficult to track what update was made at what time. Also because of the huge quantity of information updated periodically, the log files grow in size and occupy more space on the system over a period of time. The only way to manage these log files is to manually archive the contents to another file and store them in a different location.

Considering these impediments, Enterprise Manager has been enhanced with a log rotation feature that helps you manage the logs of Oracle Application Server components more effectively. In particular, you can use Enterprise Manager to:

- Schedule a job that automatically rotates a log at the scheduled date and time

- Manage space on your system by storing the rotated log files in a different directory

Enterprise Manager allows you to view the logs of a particular Oracle Application Server component type and select the ones that need to be rotated. Note that a log rotation job can also be part of a multi-task job.

When a log rotation job is executed, Enterprise Manager automatically stops the component whose logs have to be rotated. After it is stopped, the content from its existing log file is moved to another file that is distinguished with the timestamp when it was actually rotated. The original log file is kept empty for new log details to be populated. Once this is done, Enterprise Manager restarts the component.

Note:
The log rotation feature cannot be used with the WebLogic Server.

3.8 Topology Viewer

Enterprise Manager provides a Topology Viewer which is a graphical representation of routing relationships across targets, components and elements. You can easily determine how requests are routed across components. For example, you can see how requests are routed from Oracle Web Cache, to Oracle HTTP Server, to a Managed Server, to a data source.

The Topology Viewer provides the basic navigation applications, such as zoom, pan, and fit-to-contents. You can change the source of data being viewed, the layout mode, and the flow direction between objects. Filters allow you to alter global properties of the topology diagram, such as the visibility of link labels or altering the link style. It enables you to easily monitor your environment. You can see which entities are up and which are down. You can also print the topology or save it to a .gif file. For more details, see the Enterprise Manager Online Help.

3.9 Support Workbench

Enterprise Manager Support Workbench enables you to investigate, report, and, in some cases, repair problems (critical errors). You can gather first-failure diagnostic data, obtain a support request number, and upload diagnostic data to Oracle Support. The Support Workbench also recommends and provides easy access to Oracle advisors that help you repair SQL-related problems, data corruption problems, and more. You can use Support Workbench within Fusion Applications to:

- View a Fusion Aggregated Diagnostic Summary: Fusion applications are deployed across multiple systems, and incidents are therefore recorded in multiple Automatic Diagnostic Repository homes. You can get a quick summary of diagnostic data across all targets and Automatic Diagnostic Repository homes aggregated by the instance, product family, or cluster application.

- Execute Tests to Diagnose a Problem: You can link to Oracle Application Diagnostics Testing for a given Fusion Application, where you can execute additional tests to help diagnose the problem.

- Create a Package and Upload it to Oracle Support: You can create a package, add additional diagnostics and files, upload the package to Oracle Support, and then create a Service Request.

Note:
You need to discover and promote the Fusion Database targets before you can use Enterprise Manager Support Workbench for the Fusion Repository target.

4 Testing Application Load and Performance

This chapter describes how you can perform load and performance testing of applications with real-world production workloads using the Application Replay feature of Enterprise Manager. With Application Replay you can capture application workloads on production systems, and then replay them against test systems while maintaining the precise timing, concurrency, and transaction order of the workload.

This chapter covers the following:

- Introduction to Application Replay

- Testing Against Real-World Application Workloads

- Capturing Application Workload Using RUEI

- Synchronized vs. Non-Synchronized Replay

- Prerequisites and Considerations

- Understanding the Capture and Replay Process

- Creating Application Workload Captures

- Monitoring the Capture Process

- Replaying Application Workload Captures

- Troubleshooting Application Replay

4.1 Introduction to Application Replay

Application Replay enables realistic testing of planned changes to any part of the application stack from application server down to disk, by re-creating the production workload on a test system. Using Application Replay, you can capture a workload on the production system and replay it on a test system with the exact timing, concurrency, and transaction characteristics of the original workload. This enables you to fully assess the impact of the change, including undesired results, new contention points, or plan regressions. In addition, extensive analysis and reporting is provided to help identify any potential problems, such as new errors encountered and performance divergence. Types of changes that can be tested with Application Replay include application server upgrades, hardware updates, O/S changes, configuration changes, and so on.Capturing real-world production workload eliminates the need to develop simulation workloads or scripts, resulting in significant cost reduction and time savings. By using Application Replay, realistic testing of complex applications that previously took months using load simulation tools can now be completed in days. As a result, you can rapidly test planned changes and adopt new technologies with a higher degree of confidence and at lower risk.

4.2 Testing Against Real-World Application Workloads

Today's enterprise application deployments are highly complex and, therefore, challenging to manage. They comprise multiple tiers, such as Web servers, application servers, and databases, running on multiple hosts. Their software architecture combines multiple independent components, such as client-side user interfaces, business logic and data access mechanisms, in addition to stateful client-server protocols typically built over HTTP.

Due to the complexity of these structures, predicting the behavior of the entire stack in a production environment is extremely difficult. Given the complexity of these deployments, and the absence of system-wide verification techniques, effective testing is critical to ensuring successful deployment after an infrastructure change.

The Application Replay feature provides a testing structure that works by first capturing the entire workload relevant to an application (as generated by the application's Web interface) at the production site.

The captured application workload is then moved to the test environment, where the replay driver infrastructure on one or more hosts, reproduce the captured workload, preserving its original properties, such as concurrency and request timings.

Finally, extensive performance and correctness data from all layers of the stack is collected and reported. This enables you to compare the replay with the original captured workload. In this way, any issues resulting from infrastructure changes that occurred during the replay can be identified, and appropriate troubleshooting action undertaken to prevent them from occurring in production. Moreover, it increases your confidence in a successful deployment.

Benefits

The use of real workloads offers a number of significant advantages over testing techniques based on synthetic workloads. In particular:

- It provides a system-wide perspective starting from the user's activity. This is in contrast to the traditional piecemeal testing of individual components that provides little information on their combined behavior and performance under a realistic workload.

- Rather than relying on pre-determined scenarios, the use of real workloads provides comprehensive testing, subjecting the system to real users operations. For Web applications, this not only means exploring all possible ways a user interacts with the system, but also all possible load conditions. This is necessary because systems behave quite differently under different workload characteristics (for example, the number of concurrent users).

- Far greater insight is obtained into possible errors. Test results include data for every layer of the stack, and these can be correlated across different layers. Besides performance, it also provides a means to verify correct execution, by checking for errors or unexpected server responses.

4.3 Capturing Application Workload Using RUEI

In order to capture Web application workloads, Application Replay uses Oracle Real User Experience Insight (RUEI). This is a Web-based utility to report on real-user traffic requested by, and generated from, your Web infrastructure. It measures the response times of pages and user flows at the most critical points in your network infrastructure. It provides you with powerful analysis of your network and business infrastructure, while an insightful diagnostics facility allows application managers and IT technical staff to perform root-cause analysis.

Typically, RUEI is installed before the Web servers, behind a firewall in the DMZ. The data collection method is based on Network Protocol Analysis (NPA) technology. This data collection method is shown in Figure 4-1.

Figure 4-1 How RUEI Collects Data

Description of "Figure 4-1 How RUEI Collects Data"

When an object is requested by a visitor, RUEI sees the request and starts measuring the time the Web server requires to present the visitor with the requested object. At this point, RUEI knows who requested the page (IP client), which object was requested, and from which server the object was requested (IP server).

When the Web server responds and sends the object to the visitor, RUEI sees that response, and stops timing the server response time. At this stage, RUEI can see whether there is a response from the server, whether this response is correct, how much time the Web server required to generate the requested object, and the size of the object.

RUEI is also able to see whether the object was completely received by the visitor, or if the visitor aborted the download (proof of delivery). Therefore, RUEI can determine the time it took for the object to traverse the Internet to the visitor, and can calculate the Internet throughput between the visitor and the server (connection speed of the visitor).

Further information about RUEI is available from the following location:

http://www.oracle.com/us/products/enterprise-manager/index.html

4.4 Synchronized vs. Non-Synchronized Replay

Application Replay supports the use of synchronization. This ensures that each replayed request sees exactly the same database state it saw during the capture process. In this way, the responses generated during capture and replay can be directly compared. In addition, data divergence between capture and replay is minimized. This is explained at greater length in Section 4.9.7, "Analyzing Replay Results".

While the use of synchronized workload captures is clearly preferable, it is important to understand that:

- The use of the synchronization facility places additional requirements on your production and test environments. These are explained in Section 4.5.3, "Using Synchronization".

- Non-synchronized workload captures require considerably less disk space. This is because information about the current database state does not need to be retained. Therefore, their use is recommended in test scenarios where differences between the responses generated in the capture and replay environments is not an issue. For example, in loading and stress testing.

4.5 Prerequisites and Considerations

This section describes the requirements that must be met, and the issues that should be considered, in order to use the Application Replay facility for workload capture and replay. It is strongly recommended that you carefully review this information before proceeding with a workload capture.

Important:
It is strongly recommended that you review the Oracle Support Web site to obtain up-to-date information about supported RUEI, application server, and database versions, as well as patches, configurations, known issues, and workarounds.

This section covers the following:

- Using RUEI to Capture Application Workloads

- Configuring Required User Privileges in Enterprise Manager

- Using Synchronization

- Setting up the Test System Database

- Restarting the Database and Application Stack

- Setting up the Capture Directory

4.5.1 Using RUEI to Capture Application Workloads

In order to use RUEI to capture your application workloads, you must ensure that:

- RUEI version 12.1 (or higher) has been configured to monitor the required applications. See the Oracle Support Web site (http://www.oracle.com/support/contact.html) for information about required releases and hot fixes. Information about deployment options and requirements is available from the Oracle Real User Experience Insight Installation Guide.

- You have a valid user name and password combination. If necessary, contact your RUEI Administrator. Note that the user account must have Security Officer permission. For further information about roles and permissions, see the Oracle Real User Experience Insight User's Guide.

- You have the URL used to access the RUEI installation. If necessary, contact your RUEI Administrator.

- The configured RUEI logging and masking policies are consistent with the use of Application Replay. This is described in the following section.

RUEI Configuration for Application Replay

As mentioned above, you must ensure that the RUEI logging and masking policies are configured as follows:

1. Select Configuration, Security, Replay logging policy, and click the Default replay action setting. This must be set to "Complete logging".

2. Select Configuration, Security, Masking, URL prefix masking, and click the Default masking action setting. This must be set to "Logging".

3. Note that if you expect a high level of traffic during the workload capture, it is recommended that you select Configuration, Security, Collector data retention policy, and ensure that sufficient storage has been assigned for each application that is planned to be captured.

For further information on these configuration procedures, see Chapter 13 "Managing Security-Related Information" of the Oracle Real User Experience Insight User's Guide.

4.5.2 Configuring Required User Privileges in Enterprise Manager

The following Enterprise Manager privileges must be assigned to users of the Application Replay facility:

- ASREPLAY_VIEWER in order to view captures, replays, and replay tasks.

- ASREPLAY_OPERATOR in order to create, modify, or submit captures, replays, and replay tasks.

In addition to the above, users must also be assigned the PERFORM_OPERATION_ANYWHERE privilege.

4.5.3 Using Synchronization

In order to make use of the synchronization functionality within Application Replay, you must ensure that:

- Oracle Fusion Middleware has been installed and configured. See the Oracle Support Web site (http://www.oracle.com/support/contact.html) for information about required releases and patch sets. For further information, see the Oracle Fusion Middleware Installation Planning Guide available at the following location:

http://download.oracle.com/docs/cd/E14571_01/install.1111/b32474/start.htm

- Oracle Database has been installed and configured. See the Oracle Support Web site (http://www.oracle.com/support/contact.html) for information about required releases and patch sets. For further information, see the relevant Database Installation Guide available at the following location:

http://www.oracle.com/pls/db112/portal.portal_db?selected=11&frame=

- The database user needs to be assigned the privileges described in the Oracle Database Security Guide available at the following location:

http://download.oracle.com/docs/cd/B19306_01/network.102/b14266/admusers.htm

- The user capturing and replaying application workloads has access to the host directory used to store capture files.

- The database user has EXECUTE privilege on DBMS_WORKLOAD_REPLAY.

- The files used during replay are on a shared file location that is accessible by all Replay Client systems using the same directory path. If synchronization has been enabled, this is also required for the appropriate database systems.

- It is recommended that the time zone and time settings for all host systems (such as RUEI, Oracle Fusion Middleware, and Oracle database) used during capture and replay should be the same to prevent clock skew.

Note that if you are using the database synchronization facility, be aware that only one database capture can be generated against a production environment at given time.

4.5.4 Setting up the Test System Database

Before a workload can be replayed, the logical state of the application data on the replay system should be similar to that of the capture system when replay begins. Therefore, you should have a strategy in place to restore the application server and database state on the test system. To restore the application server state, you should consult your application administrator. To restore the database state, consider using one of the following methods:

- Recovery Manager (RMAN) DUPLICATE command. For further information, see the Oracle Database Backup and Recovery User's Guide.

- Snapshot standby. For further information, see the Oracle Data Guard Concepts and Administration.

- Data Pump Import and Export. For further information, see the Oracle Database Utilities.

4.5.5 Restarting the Database and Application Stack

This step is not required, although restarting the database and application server components before starting capture ensures that ongoing and dependent transactions are allowed to be completed or rolled back before the capture begins. This minimizes divergence during replay, which is always desirable. On the other hand, if the database is not restarted before the capture begins, transactions that are in progress, or have yet to be committed, may not be fully captured in the workload. Therefore, ongoing transactions may not be replayed properly, because only the part of the transaction whose calls were captured will be replayed, resulting in data divergence. Moreover, any subsequent transactions with dependencies on the incomplete transactions may also generate errors during replay.Before restarting the database and application server components, determine an appropriate time to shut down the production database before the workload capture when it is the least disruptive. For example, you may want to capture a workload that begins at 8:00 a.m. However, to avoid service interruption during normal business hours, you may not want to restart the database during this time. In this case, you should consider starting the workload capture at an earlier time, so that the database can be restarted at a time that is less disruptive.Once the application is restarted, it is important to start the capture before any user sessions reconnect and start issuing any workload. Otherwise, transactions performed by these user sessions will not be replayed properly in subsequent replays, because only the part of the transaction whose calls were executed after the workload capture is started will be replayed.

4.5.6 Setting up the Capture Directory

Determine and set up the directory where the captured workload will be stored. Before starting the capture, ensure that the directory is empty and has sufficient disk space to store the workload. If the directory runs out of disk space during a capture, the capture will be terminated.

To estimate the required disk space, it is recommended that you run a test capture on your workload for a short duration (typically, a few minutes), and then use this to extrapolate the space required for a full capture. To avoid potential performance issues, you should also ensure that the target replay directory is mounted on a separate file system.

4.6 Understanding the Capture and Replay Process

Figure 4-2 shows the architecture of the Application Replay facility.

Figure 4-2 Application Capture and Replay Architecture

Description of "Figure 4-2 Application Capture and Replay Architecture"

The capture part of Application Replay operates within the context of a production environment. This deployment comprises Web and application servers, and a database. The Web-tier capture mechanism is provided by RUEI. It writes information about the monitored traffic to capture files. These contain HTTP requests, responses, and timings, along with all other data necessary to accurately reproduce the production workload against a test system. Once the capture is complete, the generated files constitute a complete representation of the entire production workload. In addition, the synchronization facility also captures the corresponding database workload for both capture analysis.

The replay part of Application Replay operates within the context of a test system. This comprises an application stack that runs the system configuration under test. One or more Replay Clients reproduce the captured workload, preserving its original properties, such as concurrency and request timings. Further, the Application Replay facility uses synchronization to ensure that each replayed request sees the exact application state it saw during capture so that the responses are directly comparable. Finally, it collects a wealth of performance and verification data from all layers of the stack, and allows you to compare the replay with the original capture upon which it is based.

Depending on the volume and concurrency of the workload capture, it may be necessary to deploy multiple Replay Clients, each assigned a portion of the workload. Recommendations about required Replay Clients based on the captured workload is available when scheduling a replay.

4.7 Creating Application Workload Captures

To create an application workload capture:

1. From the Enterprise menu, select Quality Management, then select Application Replay.

2. Click Captures. The currently defined captures are listed. An example is shown in Figure 4-3.

Figure 4-3 Application Replay Page

Description of "Figure 4-3 Application Replay Page"

3. Click Create or Create Like. The page shown in Figure 4-4 appears.

Figure 4-4 Create Capture (Overview) Page

Description of "Figure 4-4 Create Capture (Overview) Page"

4. Specify a unique name for the new capture. Optionally, specify a brief description for the traffic to be captured. It is recommended that you include an indication of the purpose and scope of the capture. Carefully review the prerequisite information, and click the acknowledgement check boxes to indicate that they have been met. When ready, click Next. The page shown in Figure 4-5 appears.

Figure 4-5 Create Capture (System) Page

Description of "Figure 4-5 Create Capture (System) Page"

5. Click the Select System icon, and select the target that represents the applications for which traffic is to be captured. It is recommended that you review the status of the selected component, and ensure that it will be available throughout the planned capture. Note that if the selected target does not include supported versions of Oracle Fusion Middleware and Oracle Database components, the Create Capture (Database) Page (shown in Figure 4-7) is not available, and is skipped. When ready, click Next. The page shown in Figure 4-6 appears.

Figure 4-6 Create Capture (RUEI Application) Page

Description of "Figure 4-6 Create Capture (RUEI Application) Page"

6. Specify the URL used to access the RUEI installation. This must be based on a secure (HTTPS) connection. Specify a valid user name and password combination. The specified user must have Security Officer permission. If necessary, contact your RUEI Administrator for this information.
Click Show Applications to view the applications currently being monitored by the specified RUEI deployment. Note that you can use the traffic information available for each application to determine its suitability for capture. In particular, when selecting the applications to be included in the capture, you should ensure that the applications are running, and traffic volumes and error levels are within acceptable bounds. When ready, click Next. The page shown in Figure 4-7 appears.

Figure 4-7 Create Capture (Database) Page

Description of "Figure 4-7 Create Capture (Database) Page"

7. Specify whether database capture should be enabled during application capture. This is required for synchronized replay. If enabled, specify the necessary database and host credentials, the file system location on the database host system used for intermediate capture storage, and whether Automatic Workload Repository (AWR) data should be exported. Note that if AWR export is enabled, you need to specify when exporting should begin. By default, it is performed immediately after capture is completed. When ready, click Next. The page shown in Figure 4-8 appears.

Figure 4-8 Create Capture (Storage) Page

Description of "Figure 4-8 Create Capture (Storage) Page"

8. Specify the host and file system location where the capture data should be stored. Note that this includes not only the capture files themselves, but also the storage of the RUEI files from which they are derived, as well as any data synchronization information.

Important:
Capture files can require large amounts of disk space. Therefore, it is recommended that you perform a short capture, and then use that as the basis for calculating the required disk space for the planned capture. In addition, be aware that the generated capture files are in a proprietary format, and should not be modified.

Click the Select Target icon. A new window opens that allows you to view the available targets. Click a target to select it. Note that only one host target can be selected. You can use the Target Type menu to restrict the listing of targets to specific types. Note that it is also recommended that you review the status of the selected targets, and ensure that they will be available throughout the planned capture. Specify the credentials of the selected storage host. When ready, click Next. The page shown in Figure 4-9 appears.

Figure 4-9 Create Capture (Schedule) Page

Description of "Figure 4-9 Create Capture (Schedule) Page"

9. Specify the start and stop times for the planned capture. By default, capture starts immediately. Note that, by default, the capture will run for the next 15 minutes. It is strongly recommended that you carefully consider the capture's duration and, if scheduled to run indefinitely, regularly review the capture process to prevent the creation of excessively large capture files. When ready, click Next. The page shown in Figure 4-10 appears.

Important:
If the capture is configured to run indefinitely, it must be stopped manually from the Capture Page. It is strongly recommended you regularly check the size of the created capture to prevent running out of storage space.

Figure 4-10 Create Capture (Review) Page

Description of "Figure 4-10 Create Capture (Review) Page"

10. Review the planned capture's properties before launching it. If necessary, use the Back and Next buttons to amend the capture's properties. When ready to launch the new capture, click Submit.

4.8 Monitoring the Capture Process

Once a capture has been started, you can monitor the capture process to ensure that the intended traffic is being correctly captured, and that the application system is working under normal conditions. An example of a capture progress report is shown in Figure 4-11.

Figure 4-11 Capture Page

Description of "Figure 4-11 Capture Page"

Be aware that there is a lead time of appropriately 10 minutes after the start of a capture before progress information about it becomes available. This is available from the Application Replay page (Figure 4-3). In either case, the characteristics of the capture is detailed in terms of its volume, performance, and errors. In this way, you can assess the quality of the capture, and its usefulness for testing purposes.

Note that the number of requests monitored during the capture process is particularly useful for assessing the capture's progress. In the event of an unusually high level of errors, you can use the Job page (available by clicking the RUEI Capture Job setting) to drill-down into specific errors.

4.9 Replaying Application Workload Captures

You can replay a workload capture against a test system. Besides issuing identical HTTP requests, the replay mechanism also mimics the characteristics of the capture in terms of concurrency and timing. This section provides information about the following parts of the replay process:

- Preparing to Replay Workload Captures

- Understanding Replays and Replay Tasks

- Resolving References to External Systems

- Remapping URLs

- Substituting Sensitive Data

- Replaying Workload Captures

- Analyzing Replay Results

4.9.1 Preparing to Replay Workload Captures

Proper planning of the workload replay ensures that the replay will be accurate. Replaying a workload capture requires the following steps:

- Ensure that the application data state on the test system is logically equivalent to that of the capture system at the start time of workload capture. This is described in Section 4.5.4, "Setting up the Test System Database".

- All references to external systems have been resolved. This is explained in Section 4.9.3, "Resolving References to External Systems".

4.9.2 Understanding Replays and Replay Tasks

It is important to understand that a replay is an execution (playback) of a workload capture. A replay task is a group of replays based on the same capture. After a replay is completed, you can view a replay report and compare the replay with the initial capture, or create another replay within the same replay task. Typically, the replays within a replay task perform the same purposes. For example, a database or host system configuration with multiple parameter changes.

It is recommended that replays are grouped into the same replay task in order to facilitate comparison. For example, those that relate to the testing of the same database upgrade patch.

4.9.3 Resolving References to External Systems

A captured workload may contain references to external systems, such as database links or external tables. It is critical that you reconfigure these external interactions to avoid impacting other production systems during replay. Typical external references that need to be resolved before replaying a workload are shown in Table 4-1.

Table 4-1 References to External Systems

Type

Description

Database links

Typically, it is not desirable for the replay system to interact with other databases. Therefore, you should reconfigure all database links to point to an appropriate database that contains the data needed for replay.

External tables

All external files specified using directory objects referenced by external tables need to be available to the database and application server during replay. The content of these files should be the same as during capture, and the filenames and directory objects used to define external tables should also be valid.

Directory objects

You should reconfigure any references to directories on the production system by appropriately redefining the directory objects present in the replay system after restoring the database.

URLs

URLs/URIs that are stored in the database and application server need to be configured so that Web services accessed during the capture will point to the appropriate URLs during replay. If the workload refers to URLs that are stored in the production system, you should isolate the test system network during replay.

E-mails

To avoid resending E-mail notifications during replay, any E-mail server accessible to the replay system should be configured to ignore requests for outgoing E-mails.

Important:
To avoid impacting other production systems during replay, it is strongly recommended that you run the replay within an isolated private network that does not have access to the production environment hosts.

4.9.4 Remapping URLs

URLs in the workload capture files need to be remapped to different values before replay within the test environment. For example, the Web application URL in every request needs to be remapped to that of the test system.

Note that wildcard characters are not supported within remapped URLs. All required domain and port numbers must be fully specified.

4.9.5 Substituting Sensitive Data

The RUEI installation monitoring your network traffic can be configured to omit the logging of sensitive information. This is called masking, and prevents passwords and other sensitive information from being recorded on disk. Further information on the use of this facility is available from the Oracle Real User Experience Insight User's Guide.

It is important to understand that Application Replay only supports the substitution of one value for each masked field. For example, if an application logon password field is masked, you will need to set up one common alternative logon password for all user accounts in the test system.

4.9.6 Replaying Workload Captures

To replay a workload capture using Enterprise Manager:

1. From the Enterprise menu, select Quality Management, then select Application Replay. The page shown in Figure 4-3 appears.

2. From the Replay Tasks section, click Create or Create Like. The page shown in Figure 4-12 appears.

Figure 4-12 Create Replay Task Page

Description of "Figure 4-12 Create Replay Task Page"

3. Click the Select Capture icon. A new window opens that allows you to select the capture upon which the replay task should be based. Specify a unique name for the new replay task. Optionally, specify a brief description. It is recommended that you include an indication of the replay task's purpose and scope. When ready, click OK. You are returned to the page shown in Figure 4-3.

4. Click the newly created replay task. The page shown in Figure 4-13 appears.

Figure 4-13 Create Replay (Overview) Page

Description of "Figure 4-13 Create Replay (Overview) Page"

5. Specify a name for the replay. It must be unique among the selected replay task. Optionally, specify a brief description for the traffic to be replayed. It is recommended that you include an indication of the purpose and scope of the replay. Carefully review the perquisite information, and click the acknowledgement check boxes to indicate that they have been met. When ready, click System. The page shown in Figure 4-14 appears.

Figure 4-14 Create Replay (System) Page

Description of "Figure 4-14 Create Replay (System) Page"

6. Click the Select System icon, and select the targets that represent the test environment against which the capture should be replayed. It is recommended that you review the status of the selected components, and ensure that they will be available throughout the planned replay. When ready, click Capture Storage Credential. The page shown in Figure 4-15 appears.

Figure 4-15 Create Replay (Capture Storage Credential) Page

Description of "Figure 4-15 Create Replay (Capture Storage Credential) Page"

7. Specify the credentials of the selected storage host. When ready, click Replay Clients. The page shown in Figure 4-16 appears.

Figure 4-16 Create Replay (Replay Clients) Page

Description of "Figure 4-16 Create Replay (Replay Clients) Page"

8. Specify the Replay Clients that will be used to generate the workload on the test system. Note that the provided estimate should be used as a basis for scaling the planned replay. Specify the file system location to be used for storing the capture files and replay results. This location must be on a shared file system and accessible from the Replay Client hosts and database hosts (if synchronization is enabled) via exactly the same file directory path. When ready, click Synchronization. The page shown in Figure 4-17 appears.

Figure 4-17 Create Replay (Synchronization) Page

Description of "Figure 4-17 Create Replay (Synchronization) Page"

9. Specify whether database synchronization should be enabled during the replay. Note that, if enabled, you will need to provide relevant database and host credentials. When ready, click URL Mappings. The page shown in Figure 4-18 appears.

Figure 4-18 Create Replay (URL Mappings) Page

Description of "Figure 4-18 Create Replay (URL Mappings) Page"

10. Specify the URL mappings that should be used during the replay. That is, how the URLs encountered during capture should be substituted when replayed within the test environment. When ready, click Masked Data Substitution. The page shown in Figure 4-19 appears.

Figure 4-19 Create Replay (Masked Data Substitution) Page

Description of "Figure 4-19 Create Replay (Masked Data Substitution) Page"

11. RUEI can be configured to omit the logging of sensitive information (such as passwords, credit card details, and so on) from being recorded on disk. Because the values of these fields is not recorded, they need to be explicitly specified for replay. When ready, click Additional Replay Parameters. The page shown in Figure 4-20 appears.

Figure 4-20 Create Replay (Additional Replay Parameters) Page

Description of "Figure 4-20 Create Replay (Additional Replay Parameters) Page"

12. Specify whether the replay should progress at the same rate as in the original capture or at an alternative rate. In the case of the latter, you need to specify the appropriate session start time scale, think time scale, and whether the request rate should be maintained at the original rate. Expand the Advanced Replay Parameters section to specify whether the standard advanced settings should have their standard values or custom values. When ready, click Schedule. The page shown in Figure 4-21 appears.

Figure 4-21 Create Replay (Schedule) Page

Description of "Figure 4-21 Create Replay (Schedule) Page"

13. Specify when the replay should start. When ready, click Review.

14. A summary of the planned replay is displayed. If necessary, use the Back and Next buttons to move between sections. When ready, click Submit to launch the replay.

4.9.7 Analyzing Replay Results

Detailed information about a selected replay is available by clicking it within the Application Replay Page. An example of a replay overview is shown in Figure 4-22.

Figure 4-22 Example Replay Summary

Description of "Figure 4-22 Example Replay Summary"

It consists of three parts:

- Home: provides a overview of the replay, its associated replay task, and the capture upon which it based. The progress of the replay, and a comparison with the original capture, is also provided.

- Results: provides more detailed information about the request divergence. This includes a comparison of page performance during the original capture and the replay, and the application pages that experienced the highest level of divergence. An example is shown in Figure 4-23.
Within this section, the Page Analysis section allows you to an analysis of each application page across selected metrics. The Divergences section allows you to view information restricted to specific divergence types (such as access, content, and so on). The Charts section allows you to view detailed replay information across specific metrics (such as average page load time).

- Review: provides information about the replay environment (such as the credentials, host, and replay clients), as well as the URL mappings and masked data substitutions used during the replay.

Figure 4-23 Example Replay Results Summary

Description of "Figure 4-23 Example Replay Results Summary"

4.10 Troubleshooting Application Replay

This section provides guidance on dealing with the most common problems encountered when capturing and replaying workloads. In addition, it is recommended that you review the Oracle Support Web site for information about known issues and workarounds. It is available at the following location:

https://support.oracle.com

RUEI Installation

Ensure that the RUEI installation used to monitor the applications in the workload capture meets the following requirements:

- Check the Oracle Support Web site for information about supported versions and required hot fixes.

- RUEI has been configured to monitor the required applications. Information about deployment options and requirements is available from the Oracle Real User Experience Insight Installation Guide.

- You have a valid user name and password combination. If necessary, contact your RUEI Administrator. Note that the user account must have Security Officer permission. For further information about roles and permissions, see the Oracle Real User Experience Insight User's Guide.

- Full-Session Replay (FSR) has been enabled, and sufficient storage has been assigned, for each application that is planned to be captured. In addition, you should ensure that each application's data replay logging and masking settings are compatible with the use of FSR. For information, see the Oracle Real User Experience Insight User's Guide.

- Ensure that your Web server has been configured to use static SSL certificates. This is necessary because RUEI does not support dynamic SSL certificates.

- If your application make use of jumbo frames, increase the RUEI capture length from its default 2kb to 64kb by issuing the following command on the RUEI Reporter system as the root user:

execsql config_set_profile_value wg System config CaptureLength replace 65536

Synchronization

If you are using synchronization replay, ensure that your capture and replay environments meet the requirements described in Section 4.5.3, "Using Synchronization".

Capture Checklist

In addition to the requirements indicated above, you should also ensure that:

- RUEI is correctly capturing all required traffic using the appropriate logging and masking policies. For information on verifying its configuration, see the Oracle Real User Experience Insight User's Guide available at the following location:

http://www.oracle.com/technetwork/documentation/realuserei-091455.html

- The database host user ID belongs to the same group as the Enterprise Manager Agent user account.

Replay Checklist

In addition to the requirements indicated above, you should also ensure that:

- All required URLs have been correctly remapped, as described in Section 4.9.4, "Remapping URLs". Check whether the test system has been configured as HTTP or HTTPS, the domain name of the Web server, and the relevant port number. In addition, verify that the full domain name is specified in the URL, and not just the host name.

- It is strongly recommended that you do not replay a captured workload in a production environment.

- Ensure that you have provided a substitute value for all sensitive data fields that were masked during capture. This is described in Section 4.9.5, "Substituting Sensitive Data".

Part II

Managing Oracle SOA

The chapters in this part describe how you can discover and monitor Oracle BPEL Process Manager, Oracle Service Bus, and Oracle SOA Suite 11g.

The chapters are:

- Chapter 5, "Overview of Oracle SOA Management"

- Chapter 6, "Discovering and Monitoring Oracle BPEL Process Manager"

- Chapter 7, "Discovering and Monitoring Oracle Service Bus"

- Chapter 8, "Discovering and Monitoring the SOA Suite"

5 Overview of Oracle SOA Management

This chapter provides an overview of Oracle SOA Management Pack Enterprise Edition and describes how you can enable this pack and monitor SOA products such as Oracle BPEL Process Manager (BPEL Process Manager), Oracle Service Bus, Oracle SOA Suite 11g, and so on using Enterprise Manager Cloud Control.

The Oracle SOA Management Pack Enterprise Edition delivers comprehensive management capabilities for a Service-Oriented Architecture-based (SOA) environment. By combining SOA runtime governance, business-IT alignment, and SOA infrastructure management with Oracle's rich and comprehensive system management solution, Enterprise Manager Cloud Control significantly reduces the cost and complexity of managing SOA-based environments.

Table 5-1 Highlights of Oracle SOA Management Pack Enterprise Edition

Feature

Benefit

Centralized management console

Provides administrators managing SOA environments with a consolidated browser-based view of the entire enterprise, thereby enabling them to monitor and manage all of their components from a central location.

Discovery and service modeling

Provides discovery of the following:

- Oracle SOA Infrastructure deployed to the WebLogic Server.

- Oracle SOA Composite applications deployed to the SOA Infrastructure.

- Oracle BPEL processes deployed to the Oracle BPEL Process Manager (BPEL Process Manager) server and the dependent partner links.

- Oracle Service Bus-based business and proxy services.

- Service modeling offers out-of-the-box automated system modeling capabilities for the SOA infrastructure.

Runtime governance

Defines SOAP tests to measure and record availability and performance of partner links (or any Web service) and business/proxy services for historical trending, troubleshooting, and root cause analysis purposes. Also provides an error hospital of process instances with drill-downs into instance details.

Infrastructure management

Monitors the availability and performance of the SOA infrastructure components. Both current and historic availability of targets (such as BPEL Process Manager or Oracle Service Bus) are recorded for troubleshooting and root cause analysis.

Configuration management

Collects configuration information for the BPEL Process Manager server/domains/processes and Oracle Service Bus. The parameters can be refreshed, saved, or compared with another target. Different versions of the same target can also be compared.

Deployment automation

Automates the deployment of the following:

- SOA Artifacts Provisioning: This includes provisioning of SOA Composites, Oracle WebLogic Server Policies, Assertion Templates, and JPS Policy and Credential Stores.

- BPEL processes on BPEL Process Managers

- Oracle Service Bus resources from a source OSB domain to a target OSB domain.

For detailed information on the provisioning procedures, see Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching.

Adapter metrics

Provides throughput and error metrics for different adapters in graphical format.

Business-IT alignment

Enables you to consolidate their IT and business management tools into a unified system. BAM-EM integration unites business KPIs and system metrics in one system for correlation and trending.

Service level management

Enables you to monitor services from the end-user's perspective using service tests or synthetic transactions, model relationships between services and underlying IT components, and report on achieved service levels.

Application Dependency and Performance

Enables you to manage your SOA solutions by leveraging a model-driven top-down approach within your development, quality assurance (QA), staging, and production environments. Business application owners and operational staff can automatically discover your BPEL workflows and correlate them with the underlying Web services; Enterprise Service Buses (ESBs); and back-end Java 2 Platform, Enterprise Edition (Java EE) resources through detailed modeling and drill-down directly into the performance metrics at the component level.

For more information, see Chapter 14, "Introduction to Application Dependency and Performance"

Historical analysis and reporting

Store the collected metric and configuration data in a central repository, thereby enabling administrators to analyze metrics through various historical views and facilitate strategic trend analysis and reporting.

Instance Tracing

Allows you to trace the message flow across SOA Composites and SOA Infrastructure instances monitored by Enterprise Manager Cloud Control.

Business Transaction Management

Provides monitoring of business transactions as they flow across tiers and continuous discovery of components, transaction flow, service dependencies and relationships.

Dehydration Store

Shows the performance of the database that is used by the SOA Infrastructure. Using this data, the SOA administrator can identify problems that are causing the performance bottleneck.

6 Discovering and Monitoring Oracle BPEL Process Manager

This chapter describes how you can discover and monitor Oracle BPEL Process Manager (BPEL Process Manager) using Enterprise Manager Cloud Control.

In particular, this document covers the following:

- Supported Versions

- Understanding the Discovery Mechanism

- Understanding the Discovery Process

- Setting Up Oracle Software Library

- Discovering BPEL Process Manager

- Configuring BPEL Process Manager

- Troubleshooting BPEL Process Managers

6.1 Supported Versions

The following are the versions of BPEL Process Manager that are supported for monitoring in Enterprise Manager Cloud Control.

Table 6-1 Supported Versions

Supported BPEL Process Manager Version

Application Server Deployed To

Supported in Enterprise Manager

Oracle BPEL Process Manager 10.1.2

Oracle Application Server 10g Release 1 (10.1.2)

Enterprise Manager 10g Release 4 (10.2.0.4) or higher

Enterprise Manager 11g

Enterprise Manager 12c

Oracle BPEL Process Manager 10.1.3.1 and 10.1.3.3

(Part of Oracle SOA Suite 10.1.3.1 and 10.1.3.3)

Oracle Application Server 10g Release 1 (10.1.3.1) and (10.1.3.3)

Enterprise Manager 10g Release 3 (10.2.0.3) or higher

Enterprise Manager 11g

Enterprise Manager 12c

Oracle BPEL Process Manager 10.1.3.1 and 10.1.3.3

(Part of Oracle SOA Suite 10.1.3.1 and 10.1.3.3)

Oracle WebLogic Managed Server 9.2

Enterprise Manager 10g Release 5 (10.2.0.5) or higher

Enterprise Manager 10 g Release 4 (10.2.0.4) with one-off patches applied. For details, see Section 6.3, "Understanding the Discovery Process".

Enterprise Manager 11g

Enterprise Manager 12c

Oracle BPEL Process Manager 10.1.3.1 and 10.1.3.3

(Part of Oracle SOA Suite 10.1.3.1 and 10.1.3.3)

IBM WebSphere Application Server 6.1

Enterprise Manager 10g Release 5 (10.2.0.5) or higher

Enterprise Manager 10g Release 4 (10.2.0.4) with one-off patches applied. For details, see Section 6.3, "Understanding the Discovery Process".

Enterprise Manager 11g

Enterprise Manager 12c

Oracle BPEL Process Manager 10.1.3.4

(Part of Oracle SOA Suite 10.1.3.4)

Oracle Application Server 10g Release 1 (10.1.3.1) and (10.1.3.3)

Enterprise Manager 10g Release 5 (10.2.0.5) or higher

Enterprise Manager 11g Release 1 (11.1.0.1)

Enterprise Manager 12c

Oracle BPEL Process Manager 10.1.3.4

(Part of Oracle SOA Suite 10.1.3.4)

Oracle WebLogic Managed Server 9.2

Enterprise Manager 10g Release 5 (10.2.0.5) or higher

Enterprise Manager 11g

Enterprise Manager 12c

Oracle BPEL Process Manager 10.1.3.4

(Part of Oracle SOA Suite 10.1.3.4)

IBM WebSphere Application Server 6.1

Enterprise Manager 10g Release 5 (10.2.0.5) or higher

Enterprise Manager 11g

Enterprise Manager 12c

6.2 Understanding the Discovery Mechanism

The following describes the mechanism followed for discovering BPEL Process Managers in Enterprise Manager Cloud Control.

Table 6-2 Mechanism for Discovering BPEL Process Managers

BPEL Process Manager Version

Application Server Deployed To

Discovery Mechanism

Process

Oracle BPEL Process Manager 10.1.2

Oracle Application Server 10g Release 1 (10.1.2)

Manual/Automatic Discovery

- If the Management Agent is installed before Oracle Application Server and BPEL Process Manager are installed, then you must manually discover that Oracle Application Server and BPEL Process Manager in Enterprise Manager Cloud Control.

- If the Management Agent is installed after Oracle Application Server and BPEL Process Manager are installed, then Enterprise Manager Cloud Control automatically discovers that Oracle Application Server and BPEL Process Manager
The Management Agent can be installed along with Enterprise Manager Cloud Control or separately as a standalone product.

For discovery procedures, see Section 6.5.1, "Deployed to Oracle Application Server".

Oracle BPEL Process Manager 10.1.3.1, 10.1.3.3, 10.1.3.4

(Part of Oracle SOA Suite 10.1.3.1, 10.1.3.3, 10.1.3.4)

Oracle Application Server 10g Release 1 (10.1.3.1) and (10.1.3.3)

Manual/Automatic Discovery

- If the Management Agent is installed before Oracle Application Server and BPEL Process Manager are installed, then you must manually discover that Oracle Application Server and BPEL Process Manager in Enterprise Manager Cloud Control.

- If the Management Agent is installed after Oracle Application Server and BPEL Process Manager are installed, then Enterprise Manager Cloud Control automatically discovers that Oracle Application Server and BPEL Process Manager
The Management Agent can be installed along with Enterprise Manager Cloud Control or separately as a standalone product.

For discovery procedures, see Section 6.5.1, "Deployed to Oracle Application Server".

Oracle BPEL Process Manager 10.1.3.1, 10.1.3.3, 10.1.3.4

(Part of Oracle SOA Suite 10.1.3.1, 10.1.3.3, 10.1.3.4)

Oracle WebLogic Managed Server 9.2

Manual Discovery

First, manually discover Oracle WebLogic Managed Server. For procedures, see Section 6.5.2.1, "Discovering Oracle WebLogic Managed Server".

Then, manually discover BPEL Process Manager. For procedures, see Section 6.5.2.2, "Deployed to Oracle WebLogic Managed Server".

Oracle BPEL Process Manager 10.1.3.1, 10.1.3.3, 10.1.3.4

(Part of Oracle SOA Suite 10.1.3.1, 10.1.3.3, 10.1.3.4)

IBM WebSphere Application Server 6.1

Manual Discovery

First, manually discover IBM WebSphere Application Server. For procedures, see Section 6.5.3.1, "Discovering IBM WebSphere Application Server".

Then, manually discover BPEL Process Manager. For procedures, see Section 6.5.3.2, "Deployed to IBM WebSphere Application Server".

Oracle BPEL Process Manager 10.1.3.5

Oracle WebLogic Managed Server 10.x

Manual Discovery

First, manually discover Oracle WebLogic Managed Server. For procedures, see Section 6.5.2.1, "Discovering Oracle WebLogic Managed Server".

Then, manually discover BPEL Process Manager. For procedures, see Section 6.5.2.2, "Deployed to Oracle WebLogic Managed Server".

6.3 Understanding the Discovery Process

The following describes the overall process involved in discovering and monitoring BPEL Process Manager in Enterprise Manager Cloud Control. Follow the instructions outlined against each step in this process to successfully discover and monitor your BPEL Process Manager.

Table 6-3 Discovery Process

Step

Requirement

Description

1

BPEL Process Manager

Install the BPEL Process Manager software in one of the following ways:

- For Oracle middleware, download and install the BPEL Process Manager using Oracle BPEL Process Manager 10.1.2, Oracle SOA Suite 10.1.3.1, 10.1.3.3, or 10.1.3.4 from the following URL:
http://www.oracle.com/technology/software/tech/soa/index.html

- For non-Oracle middleware, download and install the BPEL Process Manager from the following URL:
http://www.oracle.com/technology/software/products/ias/bpel/index.html

2

Enterprise Manager Cloud Control

To monitor BPEL Process Manager 10.x, install Enterprise Manager Cloud Control 12c. For information about installing the base release of Enterprise Manager Cloud Control, see the Enterprise Manager Cloud Control Installation and Basic Configuration Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Oracle recommends that you install the Enterprise Manager Cloud Control components on a host that is different from the host where the BPEL Process Manager is installed. For example, if the BPEL Process Manager is installed on host1.xyz.com, then install and configure Oracle Management Service (OMS) and the Management Repository on host2.xyz.com.

3

Oracle Management Agent

(Management Agent)

Install Oracle Management Agent 12c or higher on every host where BPEL Process Manager is installed.

If Oracle Application Server/BPEL Process Manager and Enterprise Manager Cloud Control are all on the same host, then you do not have to install a separate Management Agent. The Management Agent that comes with Enterprise Manager Cloud Control is sufficient. However, if they are different hosts, then you must install a separate Management Agent on every host where BPEL Process Manager is installed.

You can install the Management Agent in one of the following ways:

- Invoke the installer provided with Enterprise Manager 10g Cloud Control Release 3 (10.2.0.3) or higher, and select the installation type Additional Management Agent.

- Use the Agent Deploy application within the Cloud Control console.

- Use the full agent kit that is available at:
http://www.oracle.com/technology/software/products/oem/htdocs/agentsoft.html

For information about installing the Management Agent, see the Enterprise Manager Cloud Control Installation and Basic Configuration Guide available at:

http://www.oracle.com/technology/documentation/oem.html

4

Discovery in Enterprise Manager Cloud Control

BPEL Process Managers deployed to Oracle Application Servers are automatically discovered in Enterprise Manager Cloud Control.

BPEL Process Managers deployed to Oracle WebLogic Managed Servers and IBM WebSphere Application Servers must be manually discovered in Enterprise Manager Cloud Control. For procedures to discover them, see Section 6.5, "Discovering BPEL Process Manager".

6.4 Setting Up Oracle Software Library

If you are using Enterprise Manager 12c to discover and monitor the BPEL Process Manager deployed to Oracle WebLogic Managed Server 9.2 and IBM WebSphere Application Server 6.1, you must set up Oracle Software Library (Software Library) as described below:

To set up the Software Library:

1. From the Enterprise menu, select Provisioning and Patching, then select Software Library.

2. From the Actions menu, select Administration.

3. In the Software Library: Administration page, select the Storage Type and click Add from the Actions menu.

4. In the Add Software Library Location window, specify a valid directory path where you want to store the raw data for the components, and click OK.

Note:
For more information about setting up the Software Library, see the Enterprise Manager Advanced Installation and Configuration Guide available at the following URL:
http://www.oracle.com/technology/documentation/oem.html

6.5 Discovering BPEL Process Manager

This section describes the procedures for discovering BPEL Process Managers. In particular, this section covers the following:

- Deployed to Oracle Application Server

- Deployed to Oracle WebLogic Managed Server

- Deployed to IBM WebSphere Application Server

6.5.1 Deployed to Oracle Application Server

A BPEL Process Manager deployed to Oracle Application Server is manually or automatically discovered in Enterprise Manager Cloud Control depending on when the Management Agent is installed.

- If the Management Agent is installed before Oracle Application Server and BPEL Process Manager are installed, then you must manually discover that Oracle Application Server and BPEL Process Manager in Enterprise Manager Cloud Control.

- If the Management Agent is installed after Oracle Application Server and BPEL Process Manager are installed, then Enterprise Manager Cloud Control automatically discovers that Oracle Application Server and BPEL Process Manager.

Note:
You must install a Management Agent on every host where BPEL Process Manager is installed. If Oracle Application Server/BPEL Process Manager and Enterprise Manager Cloud Control are all on the same host, then you need not install a separate Management Agent. The Management Agent that comes with Enterprise Manager Cloud Control is sufficient. However, if they are different hosts, then you must install a separate Management Agent on every host where BPEL Process Manager is installed. The Management Agent can be installed along with Enterprise Manager Cloud Control or separately as a standalone product.

Also note that if you have added a new BPEL Process Manager to an Oracle Application Server that is already discovered and monitored in Enterprise Manager Cloud Control, then you must manually rediscover that Oracle Application Server.

To manually discover or rediscover Oracle Application Server:

1. From the Targets menu, select Middleware.
The Middleware page that lists all the middleware targets being monitored is displayed. In Enterprise Manager 10g Cloud Control Release 4 (10.2.0.4) or lower, the Middleware tab is Application Servers.

2. (Only for Rediscovering) In the Middleware page, select the Oracle Application Server that you want to rediscover and click Remove.

3. In the Middleware page, from the Add list, select Oracle Application Server and click Go. The Add Oracle Application Server Target: Specify Host page is displayed.

4. Enter the name of the host where that Oracle Application Server is running, and click Continue.
Enterprise Manager Cloud Control rediscovers that Oracle Application Server along with its core components and the newly added BPEL Process Manager.

6.5.2 Deployed to Oracle WebLogic Managed Server

To discover the BPEL Process Manager deployed to Oracle WebLogic Managed Server, you have to first discover and add Oracle WebLogic Managed Server to Enterprise Manager Cloud Control.

This section describes the procedures for the following:

- Discovering Oracle WebLogic Managed Server

- Deployed to Oracle WebLogic Managed Server

6.5.2.1 Discovering Oracle WebLogic Managed Server

To discover and add Oracle WebLogic Managed Server to Enterprise Manager Cloud Control:

1. From the Targets menu, select Middleware.
Enterprise Manager Cloud Control displays the Middleware page that lists all the middleware targets being monitored. In Enterprise Manager 10g Cloud Control Release 4 (10.2.0.4) or lower, the Middleware tab is Application Servers

2. In the Middleware page, from the Add list, select Oracle Fusion Middleware / WebLogic Server Domain, and click Go.
Enterprise Manager Cloud Control displays the Add Oracle Fusion Middleware / WebLogic Server Domain wizard that captures the details of the Oracle WebLogic Server Domain to be discovered and monitored.

3. In the wizard, specify the required details and click Next on each page to reach the end of the wizard.
For information about the details to be provided for each page of the wizard, click Help on each page.

4. In the last page of the wizard, click Finish to complete the discovery process and add the target to Cloud Control for monitoring purposes.
Enterprise Manager Cloud Control displays the Middleware page with a confirmation message that confirms that the Oracle WebLogic Manager Server has been successfully added to Cloud Control. In the Middleware page that shows all the middleware targets being monitored, you can see the Oracle WebLogic Managed Server you just added.

6.5.2.2 Deployed to Oracle WebLogic Managed Server

To discover and add the BPEL Process Manager deployed to Oracle WebLogic Managed Server:

1. From the Setup menu, select Add Targets, then select Add Targets Manually. Now select the Add Non-Host Targets by Specifying Target Monitoring Properties option.

2. Select the target type from the drop-down list and click the torch icon to select a Monitoring Agent. Click Add Manually. The Select Application Server page of the Add BPEL Process Manager wizard is displayed.

1. In the Select Application Server page, provide the following details and click Next.

Table 6-4 Select Application Server Page - Element Description

UI Page Element

Description

Application Server Type

Select the type of application server where the BPEL Process Manager to be discovered is running.

Application Server Name

Specify the name of the application server where the BPEL Process Manager to be discovered is running. If you are not sure about the name, click the each icon (torch icon) to view a list of application servers and select the appropriate one. The application server name must be suffixed with oracleBPELServer.

2. In the Target Details page, provide the following details and click Next.

Table 6-5 Target Details Page - Element Description

UI Page Element

Description

Oracle Home

Specify the full path to the Oracle Application Server home directory where the BPEL Process Manager is installed. For example, /opt/app/orabpel/product/10.1.3.1/OracleAS.

Application Server Home

Specify the full path to the directory where Oracle WebLogic Managed Server (to which the BPEL target is deployed) is running. For example, /opt/wls9.2/weblogic9.2.

Note:

- Enterprise Manager Cloud Control checks the configuration settings of the associated application server and prefills the values for fields such as BPEL Process Manager Name, Display Name, Context Provider URL, and Oracle BPEL PM Console URL.

- At this point, if you encounter a discovery failure error, then follow the workaround steps given in Table 6-9 to resolve the issue.

3. In the Host Credentials page, specify the operating system credentials of the host where BPEL Process Manager is running. By default, the fields are prefilled with preferred credentials that are stored in the Management Repository for the selected host. You can either use these prefilled values or edit them to override the preferred credentials with your new credentials.

4. In the Review page, review the details and click Finish to complete the discovery process and add the target to Enterprise Manager Cloud Control.
Enterprise Manager Cloud Control displays the Agent home page with a confirmation message that confirms that the BPEL Process Manager has been successfully added for monitoring.

3. To verify whether the BPEL Process Manager has been added, click Targets and then Middleware.
Enterprise Manager Cloud Control displays the Middleware page that shows all the middleware targets being monitored, including the Oracle WebLogic Managed Server and the BPEL Process Manager you just added.

6.5.3 Deployed to IBM WebSphere Application Server

To discover the BPEL Process Manager deployed to IBM WebSphere Application Server, you have to first discover and add IBM WebSphere Application Server to Enterprise Manager Cloud Control.

This section describes the procedures for the following:

- Discovering IBM WebSphere Application Server

- Deployed to IBM WebSphere Application Server

6.5.3.1 Discovering IBM WebSphere Application Server

To discover and add IBM WebSphere Application Server to Enterprise Manager Cloud Control:

1. From the Targets menu, select Middleware.
Enterprise Manager Cloud Control displays the Middleware page that lists all the middleware targets being monitored.

2. In the Middleware page, select IBM WebSphere Application Server from the Add drop-down list and click Go.
Enterprise Manager Cloud Control displays the Add IBM WebSphere Application Server wizard that captures the details of the IBM WebSphere Application Server to be discovered and monitored.

3. In the Add IBM WebSphere Application Server wizard, specify the required details and click Next on each page to reach the end of the wizard.
For information about the details to be provided for each page of the wizard, click Help on each page.

4. In the last page of the Add IBM WebSphere Application Server wizard, click Finish to complete the discovery process and add the target to Enterprise Manager Cloud Control for monitoring purposes.
Enterprise Manager Cloud Control displays the Middleware page with a confirmation message that confirms that the IBM WebSphere Application Server has been successfully added for monitoring. In the Middleware page that shows all the application server being monitored, you can see the IBM WebSphere Application Server you just added.

6.5.3.2 Deployed to IBM WebSphere Application Server

To discover and add the BPEL Process Manager deployed to IBM WebSphere Application Server:

1. From the Setup menu, select Add Targets, then select Add Targets Manually. Now select the Add Non-Host Targets by Specifying Target Monitoring Properties option.

2. Select the target type from the drop-down list and click the torch icon to select a Monitoring Agent. Click Add Manually. The Select Application Server page of the Add BPEL Process Manager wizard is displayed.

1. In the Select Application Server page, provide the following details and click Next.

Table 6-6 Select Application Server Page - Element Description

UI Page Element

Description

Application Server Type

Select IBM WebSphere Application Server from the list.

Application Server Name

Specify the name of IBM WebSphere Application Server where the BPEL Process Manager to be discovered is running. If you are not sure about the name, click the search icon (torch icon) to view a list of application servers and select the appropriate one. The application server name must be suffixed with oracleBPELServer.

2. In the Target Details page, provide the following details and click Next.

Table 6-7 Target Details Page - Element Description

UI Page Element

Description

Oracle Home

Specify the full path to the Oracle Application Server home directory where the BPEL Process Manager is installed. For example, /opt/app/orabpel/product/10.1.3.1/OracleAS.

Application Server Home

Specify the full path to the directory where IBM WebSphere Application Server (to which the BPEL target is deployed) is running.

BPEL Application Installation Location

Specify the full path to the installation directory where the BPEL application is installed.For example, if the BPEL application is installed in <$WEBSPHERE_HOME>/profiles/AppSrv01/installedApps/sta00114Cell01/CollaxaWebApplications-sta00114Node01.ear, then specify the path as <$WEBSPHERE_HOME>/profiles/AppSrv01/installedApps. Here, replace $WEBSPHERE_HOME with the full path of the application home location.

Note:
Enterprise Manager Cloud Control checks the configuration settings of the associated application server and prefills the values for fields such as BPEL Process Manager Name, Display Name, Context Provider URL, and Oracle BPEL PM Console URL.

3. In the Host Credentials page, specify the operating system credentials of the host where BPEL Process Manager is running. By default, the fields are prefilled with preferred credentials that are stored in the Management Repository for the selected host. You can either use these prefilled values or edit them to override the preferred credentials with your new credentials.

4. In the Review page, review the details and click Finish to complete the discovery process and add the target to Enterprise Manager Cloud Control.
Enterprise Manager Cloud Control displays the Agent home page with a confirmation message that confirms that the BPEL Process Manager has been successfully added for monitoring.

Note:
At this point, if you encounter a discovery failure error, then follow the workaround steps given in Table 6-10 and resolve the issue.

3. To verify whether the BPEL Process Manager has been added, select Middleware from the Targets menu. /
Enterprise Manager Cloud Control displays the Middleware page that shows all the middleware targets being monitored, including the IBM WebSphere Application Server and the BPEL Process Manager you just added.

6.6 Configuring BPEL Process Manager

After discovering BPEL Process Manager, you must perform the following configuration steps:

- Specifying Details for Monitoring BPEL Process Manager

- Registering BPEL Process Manager Credentials and Host Credentials

6.6.1 Specifying Details for Monitoring BPEL Process Manager

Follow these steps to specify the details required for monitoring BPEL Process Managers. If the values are prefilled, then validate them.

1. In the BPEL Process Manager Home page, select Target Setup, then select Monitoring Configuration from the BPEL Process Manager menu.

2. In the Monitoring Configuration page, specify the following details. If these values are prefilled, then validate them.

- BPEL Admin Username - Specify the BPEL administrator user ID.

- BPEL Password - Specify the BPEL admin password.
When adding the credentials, validate the following two criteria:

- BPEL Admin User ID and password should have BPEL Admin role

- The same credentials should succeed for the BPEL console login operation

- Initial Context Factory - Specify the initial context factor. You can copy the following string value:
com.evermind.server.rmi.RMIInitialContextFactory

- Context Provider URL - Specify the context provider URL. You can copy the following string value:
opmn:ormi://<host>:<opmn_port>:home/orabpel

Note:
Replace the <host>,<opmn port> with the correct host address and opmn port number details for the Oracle Application Server where the BPEL Process Manager is deployed.
To retrieve SOA Applications Server OPMN PORT details, follow these steps:

1. Open the configuration file $SOA_ORACLE_HOME/opmn/conf/opmn.xml. $SOA_ORACLE_HOME corresponds to SOA Application server home location.

2. Identify the value of the request port attribute in the configuration file.

- BPEL Repository Host Name - Specify the BPEL Dehydration store (database) host name.

- BPEL Repository Port - Specify the BPEL Dehydration store (database) port.

- BPEL Repository SID - Specify the BPEL Dehydration store (database) SID.

- BPEL Repository User Name - Specify the BPEL Dehydration store (database) user name. By default, the user name is orabpel.

- BPEL Repository Password - Specify the BPEL Dehydration store (database) password. By default, the password is welcome1.

- Recoverable Instances Time Threshold (Days) - Specify the number of days for which the retryable instances must be shown.

- Process Aggregate State - Specify 5, a numeric value that signifies the constant state of the BPEL target.

3. Click OK to save the settings.

6.6.2 Registering BPEL Process Manager Credentials and Host Credentials

Follow these steps to register the credentials of the BPEL Process Manager, and the credentials of the host where BPEL Process Manager is running.

1. From the Setup menu, select Security, then select Preferred Credentials.

2. Select the Host target type and click Manage Preferred Credentials.

3. Select Normal Host Credentials in the Credential Set column in the Default Preferred Credentials section and click Set.

4. In the Select Named Credential window, enter the user name and password and click Save to return to the Preferred Credentials page.

5. Select Oracle BPEL Process Manager target type and click Manage Preferred Credentials.

6. Select Monitoring Administrator Credentials in the Credential Set column in the Default Preferred Credentials section and click Set.

7. In the Select Named Credential window, enter the user name and password and click Save.

6.7 Troubleshooting BPEL Process Managers

This section describes the errors you might encounter while discovering BPEL Process Managers, and the workaround steps you can follow to resolve each of them.

This section covers the following:

- Discovery Errors on Target Details Page

- Discovery Errors on Review Page

- Discovery Errors on Review Page

6.7.1 Discovery Errors on Target Details Page

The following error occurs in the Target Details page of the Add BPEL Process Manager wizard where you provide details about the BPEL Process Manager installed on Oracle WebLogic Managed Server.

Table 6-8 Errors on Target Details Page While Adding BPEL Process Manager Deployed to Oracle WebLogic Managed Server

Error Message

Workaround Steps

Oracle BPEL Process Manager not found
in the selected Application Server.
Select another Application Server.

This error may occur if BPEL is not deployed on the selected Application Server or if the configuration data has not been collected.

To resolve this issue:

1. Select another Application Server.

2. Navigate to the Application Server Home page and select Configuration, then select Last Collected from the Application Server target menu.

6.7.2 Discovery Errors on Review Page

The following errors occur in the Review page of the Add BPEL Process Manager wizard when you are about to add a BPEL Process Manager installed on Oracle WebLogic Managed Server, to Enterprise Manager Cloud Control for monitoring purposes.

Table 6-9 Errors on Review Page While Adding BPEL Process Manager Deployed to Oracle WebLogic Managed Server

Error Message

Workaround Steps

Discovery Failure - Oracle BPEL
Process Manager target discovery
failed due to incorrect host
credentials.

1. In the last page of the Add BPEL Process Manager wizard where you see this error message, click Previous to reach the Host Credentials page.

2. In the Host Credentials page, specify the correct host credentials or set the preferred credentials for the specific host. Ensure that these are Agent user credentials.

Oracle BPEL Proess Manager Discovery
Failed - Unable to connect to Oracle
BPEL Process Manager. The possible
reasons can be incorrect path or
insufficient permission to access
Oracle BPEL Process Manager home
location or inaccessible Oracle BPEL
Process Manager home location. Review
the specified value.

1. In the last page of the Add BPEL Process Manager wizard, click Previous repeatedly to reach the Target Details page.

2. In the Target Details page, verify the Oracle home location of the BPEL Process Manager.

3. In the Target Details page, verify the installation location of the associated application server.

Oracle BPEL Proess Manager Discovery
Failed - Unable to connect to Oracle
BPEL Process Manager. The possible
reasons can be incorrect path or
insufficient permission to access
Oracle BPEL Process Manager home
location or inaccessible Oracle BPEL
Process Manager home location. Review
the specified value.

Ensure that the BPEL directories have read permission for the Agent user.

6.7.3 Discovery Errors on Review Page

The following errors occur in the Review page of the Add BPEL Process Manager wizard when you are about to add a BPEL Process Manager installed on IBM WebSphere Application Server, to Enterprise Manager Cloud Control for monitoring purposes.

Table 6-10 Error on Review Page While Adding BPEL Process Manager Deployed to IBM WebSphere Application Server

Error Message

Workaround Steps

Discovery Failure - Oracle BPEL
Process Manager target discovery
failed due to incorrect host
credentials.

1. In the last page of the Add BPEL Process Manager wizard where you see this error message, click Previous to reach the Host Credentials page.

2. In the Host Credentials page, specify the correct host credentials or set the preferred credentials for the specific host. Ensure that these are Agent user credentials.

Oracle BPEL Proess Manager Discovery
Failed - Unable to connect to Oracle
BPEL Process Manager. The possible
reasons can be incorrect path or
insufficient permission to access
Oracle BPEL Process Manager home
location or inaccessible Oracle BPEL
Process Manager home location. Review
the specified value.

1. In the last page of the Add BPEL Process Manager wizard where you see this error message, click Previous repeatedly to reach the Target Details page.

2. In the Target Details page, verify the BPEL application installation location.
For example, the BPEL application may be installed at the following location:

<$WEBSPHERE_HOME>/profiles/AppSrv01/installedApps/sta00114Cell01/CollaxaWebApplications-sta00114Node01.ear

In this case, the path you specify must look like this:

<$WEBSPHERE_HOME>/profiles/AppSrv01/installedApps

Note: Replace $WEBSPHERE_HOME with the absolute application home location.

3. In the Target Details page, verify the application server home location of the associated application server.

4. In the Target Details page, verify the Oracle home location of the BPEL Process Manager.

6.7.4 Display Errors on Processes Page

Sometimes, after the discovery of a BPEL Process Manager, the BPEL process may occasionally not be listed in the BPEL Process Manager Processes page in Enterprise Manager Cloud Control.

There are two causes for this and two ways to ensure they display on the Processes page. The sections below discuss these causes and workaround steps to fix them.

6.7.4.1 No Credentials Specified for Monitoring BPEL Process Manager

You may not have specified the credentials required for monitoring BPEL Process Managers. To address this, do the following:

1. In the BPEL Process Manager Home page, select Target Setup, then select Monitoring Configuration from the BPEL Process Manager menu.

2. In the Monitoring Configuration page, check the following fields:

- BPEL Admin Username - Provide the BPEL administrator user ID.

- BPEL Password - Provide the BPEL admin password.
When adding the credentials validate the following two criteria:

- BPEL Admin User ID and password should have BPEL Admin role

- The same credentials should succeed for the BPEL console login operation

- Initial Context Factory - In case this field is empty, copy the following string value:
com.evermind.server.rmi.RMIInitialContextFactory

- Context Provider URL - In case this field is empty, copy the following highlighted string value:
opmn:ormi://<host>:<opmn_port>:home/orabpel

Note:
Replace the <host>,<opmn port> with the correct host address and opmn port number details for the Oracle Application Server where the BPEL Process Manager is deployed.

3. Click OK to save the settings.

6.7.5 Retrieving the OPMN Port

To retrieve SOA Applications Server OPMN PORT details, follow these steps.

1. Open the configuration file $SOA_ORACLE_HOME/opmn/conf/opmn.xml. $SOA_ORACLE_HOME corresponds to SOA Application server home location.

2. Identify the value of the request port attribute in the configuration file.

6.7.6 javax.naming.NameNotFoundException Error

The following error occurs in the error details page when incorrect provider URL is specified.

Table 6-11 javax.naming.NameNotFoundException Error - Workaround Steps

Error Message

Workaround Steps

oracle.sysman.emSDK.emd.fetchlet.Fetchl
etException: java.lang.Exception:
Failed to create
"ejb/collaxa/system/ServerBean" bean;
exception reported is:
"javax.naming.NameNotFoundException:...

(See Figure 6-1)

1. Validate the format of the string.

2. Verify if the OPMN port is correct.

3. Verify if the <oc4j_instance> name is properly substituted with the correct value, that is, the OC4J name value. The format must be like this:
opmn:ormi://<host>:<opmn_port>:home/orabpel

Figure 6-1 javax.naming.NameNotFoundException Error

6.7.7 javax.naming.NamingException Error

The following error occurs in the error details page when incorrect password is specified.

Table 6-12 javax.naming.NamingExceptionError - Workaround Steps

Error Message

Workaround Steps

oracle.sysman.emSDK.emd.fetchlet.Fetch
letException: java.lang.Exception: Failed
to create "ejb/collaxa/system/ServerBean" bean;
exception reported is:
"javax.naming.NamingException: Lookup
error:...

(See Figure 6-2)

1. Validate the values specified for BPEL Admin username and BPEL Password fields in the Monitoring Configuration page. (Confirm the validity of credentials by using the same credentials to log in to the BPELConsole).

Figure 6-2 javax.naming.NamingException Error

6.7.8 javax.naming.NoInitialContextException Error

The following error occurs in the error details page when incorrect Initial Context Factory value is specified.

Table 6-13 javax.naming.NoInitialContextException Error - Workaround Steps

Error Message

Workaround Steps

oracle.sysman.emSDK.emd.fetchlet.Fetchl
etException: java.lang.Exception:
Failed to create
"ejb/collaxa/system/ServerBean" bean;
exception reported is:
"javax.naming.NoInitialContextException
: Cannot instantiate class:...

(See Figure 6-3)

1. Provide the following value for the Initial Context Factory field in the Monitoring Configuration page:
com.evermind.server.rmi.RMIInitialContextFactory

Figure 6-3 javax.naming.NoInitialContextException Error

6.7.9 Error While Creating BPEL Infrastructure Services

The following error occurs when you are creating a new BPEL infrastructure service.

Table 6-14 javax.naming.NoInitialContextException Error - Workaround Steps

Error Message

Workaround Steps

An error encountered while
discovering the dependencies. Please
try again.

1. Apply patch 10849036 on the OMS and try creating the BPEL infrastructure service again:
com.evermind.server.rmi.RMIInitialContextFactory

6.7.10 Metric Collection Errors for BPEL Process Manager Partner Link Metrics

The following metric collection error appears on the home page when you monitor BPEL 10.1.3.3 or 10.1.3.4 using Oracle Management Agent 12c:

Table 6-15 Metric Collection Errors for BPEL Process Manager Partner Link Metrics - Workaround Steps

Error Message

Workaround Steps

java.rmi.UnmarshalException: Error deserializing
return-value: java.io.InvalidClassException:
javax.xml.namespace.QName; local class incompatible:
stream classdesc serialVersionUID =
-916876369326528164, local class serialVersionUID =
-9120448754896609940 at
com.oracle.bpel.client.util.ExceptionUtils.handleServer
Exception(ExceptionUtils.java:82) at
com.oracle.bpel.client.BPELProcessHandle.getDescriptor
(BPELProcessHandle.java:207) at
oracle.sysman.emd.fetchlets.BPELPMFetchlet.getPartner
LinkMetrics(BPELPMFetchlet.java:873) at
oracle.sysman.emd.fetchlets.BPELPMFetchlet.getMetric
(BELPMFetchlet.java:235) at
oracle.sysman.emd.fetchlets.FetchletWrapper.getMetric
(FetchletWrapper.java:382)

Follow the workaround described in the My Oracle Support Note 735128.1. You can access My Oracle Support at the following URL:

https://support.oracle.com/CSP/ui/flash.html

6.7.11 Agent Monitoring Metric Errors

This error occurs if the same Agent is used to monitor the BPEL 10g and OSB, and BPEL 10g and SOA 11g targets.

Table 6-16 Metric Errors During Agent Monitoring

Error Message

Workaround

The following exception has occurred:

Exception at getPartnerLinkMetrics: java.lang.NoClassDefFoundError: Could not initialize class javax.rmi.PortableRemoteObject

The same Management must not be used to monitor BPEL 10g and OSB, and BPEL 10g and SOA 11g targets.

7 Discovering and Monitoring Oracle Service Bus

This chapter describes how you can discover and monitor Oracle Service Bus (OSB) using Enterprise Manager Cloud Control.

In particular, this document covers the following:

- Supported Versions

- Understanding the Discovery Mechanism

- Understanding the Discovery Process

- Downloading One-Off Patches

- Discovering Oracle Service Bus

- Enabling Management Packs

- Troubleshooting Oracle Service Bus

7.1 Supported Versions

The following are the versions of OSB that are supported for monitoring in Enterprise Manager Cloud Control.

Table 7-1 Supported Versions

Supported OSB Version

Oracle WebLogic Managed Server Deployed To

Supported Enterprise Manager Cloud Control

Aqualogic Service Bus 2.6, 3.0, and Oracle Service Bus 10gR3, Oracle Service Bus 11.1.1.2.0, 11.1.1.3.0, and 11.1.1.4.0

Oracle WebLogic Server 9.2, 10, 10.3

Enterprise Manager 10g Release 5 (10.2.0.5) or higher

Enterprise Manager 11g

Enterprise Manager 12c

7.2 Understanding the Discovery Mechanism

The OSB deployed to Oracle WebLogic Managed Server is automatically discovered in Enterprise Manager Cloud Control when that Oracle WebLogic Managed Server is discovered and added to Enterprise Manager Cloud Control.

So, the discovery of OSB depends on the whether the Oracle WebLogic Managed Server is already being monitored in Enterprise Manager Cloud Control.

- If Oracle WebLogic Managed Server is not being monitored in Cloud Control, then first discover and add it to Cloud Control; this will automatically discover the OSB that is deployed to it.

- If Oracle WebLogic Managed Server is already being monitored in Cloud Control, then refresh the membership of the Oracle WebLogic Server Domain to which the Oracle WebLogic Managed Server belongs. This will automatically discover the OSB that is deployed to it.

For instructions to discover OSB, see Section 7.5, "Discovering Oracle Service Bus".

7.3 Understanding the Discovery Process

The following describes the overall process involved in discovering and monitoring OSB in Enterprise Manager Cloud Control. Follow the instructions outlined against each step in this process to successfully discover and monitor your OSB.

Table 7-2 Discovery Process

Step

Requirement

Description

1

Oracle Service Bus

Install the OSB software.

Note: Before you launch the OSB Deployment Procedure, ensure that Sun JDK has been installed.

2

Enterprise Manager Cloud Control

Install Enterprise Manager 12c.

For information about installing the base release of Enterprise Manager Cloud Control, see the Enterprise Manager Cloud Control Basic Installation and Configuration Guide available at:

http://www.oracle.com/technology/documentation/oem.html

Oracle recommends that you install the Enterprise Manager Cloud Control components on a host that is different from the host where OSB is installed. For example, if OSB is installed on host1.xyz.com, then install and configure Oracle Management Service (OMS) and the Management Repository on host2.xyz.com.

3

Oracle Management Agent

(Management Agent)

Install Oracle Management Agent 12c on the host where OSB is installed.

If OSB and Enterprise Manager Cloud Control are on the same host, then you do not have to install a separate Management Agent. The Management Agent that comes with Enterprise Manager Cloud Control is sufficient. However, if they are different hosts, then you must install a separate Management Agent on the host where OSB is installed. Alternatively, the Management Agent can also be installed on a different host and made to remotely monitor the OSB target on another host.

You can install the Management Agent in one of the following ways:

- Invoke the installer provided with Enterprise Manager 12c, and select the installation type Additional Management Agent. Then apply the 10.2.0.5 Agent patch on it.

- Use the Agent Deploy application within the Enterprise Manager 12c.

- Use the full agent kit that is available at:
http://www.oracle.com/technology/software/products/oem/htdocs/agentsoft.html

For information about installing the Management Agent, see the Enterprise Manager Cloud Control Basic Installation and Configuration Guide available at:

http://www.oracle.com/technology/documentation/oem.html

4

One-Off Patches

The support for discovering and monitoring of OSB is enabled only when the one-off patches as described in Section 7.4, "Downloading One-Off Patches" are applied to the WebLogic Server Home where OSB is running.

5

Discovery in Enterprise Manager Cloud Control

OSB is automatically discovered when the Oracle WebLogic Server Domain to which it is deployed is discovered and added to Enterprise Manager Cloud Control.

7.4 Downloading One-Off Patches

To view OSB services in Enterprise Manager Cloud Control, you must apply the following patches to your OSB servers.

Table 7-3 One-Off Patches

Oracle Service Bus Version

ID

Password

Oracle Service Bus 2.6

EMMU

83XNT2D4

Oracle Service Bus 2.6.1

9NAF

TLZE4IPI

Oracle Service Bus 3.0

RPCD

JJEC2EY2

Oracle Service Bus 10.3.0

9HPA

FFLQHDHP

Oracle Service Bus 10.3.1

No Patch Required

Oracle Service Bus 11.1.1.3.0 and 11.1.1.4.0

No Patch Required

You can apply the patches in one of the following ways:

- Online mode - Using the SmartUpdate tool available with Oracle WebLogic Managed Server

- Offline mode - Manually copying the JAR files and classes to the OSB directories

For information about downloading these patches and applying them in either offline or online mode, see My Oracle Support Note 804148.1. You can access My Oracle Support at:

https://support.oracle.com/CSP/ui/flash.html

Note:
After applying the patches, restart the WebLogic domain and all of the management agents monitoring the domain.

7.5 Discovering Oracle Service Bus

The OSB deployed to Oracle WebLogic Managed Server is automatically discovered in Enterprise Manager Cloud Control when that Oracle WebLogic Managed Server is discovered and added to Enterprise Manager.

So, before discovering OSB, identify whether the Oracle WebLogic Managed Server is already being monitored in Enterprise Manager.

- If Oracle WebLogic Managed Server is not being monitored in Enterprise Manager, then first discover and add it to Enterprise Manager Cloud Control; this will automatically discover the OSB that is deployed to it.

- If Oracle WebLogic Managed Server is already being monitored in Enterprise Manager, then refresh the membership of the Oracle WebLogic Server Domain to which the Oracle WebLogic Managed Server belongs. This will automatically discover the OSB that is deployed to it.

This section outlines the instructions for discovering OSB for the cases described above. In particular, this section covers the following:

- Discovering OSB Deployed to WLS Not Monitored by Enterprise Manager

- Discovering OSB Deployed to WLS Monitored by Enterprise Manager

7.5.1 Discovering OSB Deployed to WLS Not Monitored by Enterprise Manager

To discover OSB deployed to Oracle WebLogic Manager Server that is not monitored in Cloud Control, first discover that Oracle WebLogic Manager Server in Enterprise Manager Cloud Control; this will automatically discover the OSB that is deployed to it. To discover Oracle WebLogic Manager Server, follow these steps:

1. From the Targets menu, select Middleware.
Enterprise Manager Cloud Control displays the Middleware page that lists all the middleware targets being monitored.

2. In the Middleware page, select Oracle Fusion Middleware/WebLogic Server Domain from the Add drop-down list and click Go.
Enterprise Manager Cloud Control displays the Add Oracle Fusion Middleware / WebLogic Server Domain wizard that captures the details of the Oracle WebLogic Server Domain to be discovered and monitored.

3. In the Add Oracle Fusion Middleware / WebLogic Server Domain wizard, specify the required details and click Next on each page to reach the end of the wizard.
For information about the details to be provided for each page of the wizard, click Help on each page.

4. In the last page of the Add Oracle Fusion Middleware / WebLogic Server Domain wizard, click Finish to complete the discovery process and add the target to Cloud Control for monitoring purposes.
Enterprise Manager displays the Middleware page with a confirmation message that confirms that the Oracle WebLogic Manager Server has been successfully added to Cloud Control.

In the Middleware page that shows all the middleware targets being monitored, you can see the Oracle WebLogic Managed Server and the OSB you just added. Note that, at this point, OSB will be the last target listed in the table. To see it nested under its Oracle WebLogic Managed Server, click Refresh on this page. Alternatively, navigate to another tab or page, and then return to the Middleware page.

Note:

- After discovering and adding OSB to Enterprise Manager Cloud Control, you can monitor its status from the OSB Home page. You can use the Services page to view a list of services.
For the first collection that happens, you will see the value "0" for all the metrics. This is an expected behavior. From the second collection onwards, you should see the actual metric values. However, if you still see the value "0", then perhaps the service monitoring is turned off. To resolve this issue, on the Services page, click Launch Console to access the OSB Console, and turn on the service monitoring and set the level to "pipeline" or "action"

- In the case of clustered OSB domain, the Management Agent installed on Admin Server host should be used to discover the entire domain.

7.5.2 Discovering OSB Deployed to WLS Monitored by Enterprise Manager

To discover OSB deployed to Oracle WebLogic Managed Server that is already being monitored in Cloud Control, refresh the membership of the Oracle WebLogic Server Domain to which the Oracle WebLogic Managed Server belongs. This will automatically discover the OSB that is deployed to it.

To refresh the membership of the Oracle WebLogic Server Domain to which the Oracle WebLogic Managed Server belongs, follow these steps:

1. From the Targets menu, select Middleware.

2. On the Middleware page, select the Oracle WebLogic Server Domain target from the list of Middleware targets being monitored.

3. On the Oracle WebLogic Server Domain Home page, in the General section, click Refresh Domain. Enterprise Manager Cloud Control displays the membership page that lists the OSB that is currently not being monitored. Click OK.
Enterprise Manager Cloud Control refreshes the membership and returns to the Oracle WebLogic Server Domain Home page.

Note:
On the Oracle WebLogic Server Domain Home page, in the Status section, the legend of the status pie chart may not show an increased count to indicate the newly added OSB target. This is an expected behavior because Enterprise Manager Cloud Control takes a few seconds to reflect the membership details in this section.

4. Click the Members tab and verify whether the OSB has been added.

7.6 Enabling Management Packs

Besides monitoring the status of OSB, if you want to gain access to additional value-added features, then you must enable the Management Pack for SOA.

To enable the Management Pack for SOA:

1. From the Setup menu, select Management Packs, then select Management Pack Access.
Enterprise Manager Cloud Control displays the Management Pack Access page.

2. In the Management Pack Access page, from the Search list, select Oracle Service Bus.
Enterprise Manager Cloud Control lists all the Oracle Service Bus targets being monitored.

3. From the table, for the Oracle Service Bus target you are interested in, enable the SOA Management Pack Enterprise Edition and click Apply.

7.7 Troubleshooting Oracle Service Bus

This section describes the errors you might encounter while discovering OSB, and the workaround steps you can follow to resolve each of them.

7.7.1 Required Patches Missing

The following error occurs when you try to discover OSB from an Oracle WebLogic Admin Server that has not been patched with the required one-off patches.

Table 7-4 oracle.sysman.emSDK.emd.fetchlet.FetchletException Error - Workaround Steps

Error Message

Workaround Steps

oracle.sysman.emSDK.emd.fetchlet.FetchletException:
The MBean is not available on the OSB instance. The
required EM plug in patch should be missing on OSB
instance.

Apply the one-off patches as described in Section 7.4, "Downloading One-Off Patches".

7.7.2 System and Service

The following error occurs if configuration information has not been collected for the selected Application Server.

Table 7-5 Create System and Service Error - Workaround Steps

Error Message

Workaround Steps

An error encountered while discovering the
dependencies. This may occur if some configuration
information is missing. Check whether the
configuration information was collected for the
dependent targets and then try again.

Collect the latest configuration data by navigating to the Application Server Home page and clicking Configuration and then select Last Collected from the Application Server menu.

7.7.3 SOAP Test

The following error occurs when the Management Agent is upgraded to Enterprise Manager 12c with OMS 10.2.0.5.

Table 7-6 SOAP Test Error - Workaround Steps

Error Message

Workaround Steps

Add SOAP Test failed. The selected service
has an invalid or incorrect WSDL URL. Check
whether the Oracle Service Bus Target URL
value is valid in the Monitoring
Configuration page of the selected target.
To access the Monitoring Configuration
page, go to the Oracle Service Bus Homepage
and from the Related Links section, select
Monitoring Configuration.

If the Management Agent has been upgraded to 12c with OMS 10.2.0.5, the following workaround must be applied to support the SOAP test.

In the Monitoring Configuration page for the OSB target, set the Server URL to Access Proxy Services property to the URL for the specific WebLogic Server target. The URL must be in the format: http://<host>:<port>/. For example, http://stade61.us.oracle.com:7001/

8 Discovering and Monitoring the SOA Suite

This chapter describes how you can discover and configure the components of the SOA Suite 11g using Enterprise Manager Cloud Control.

In particular, this document covers the following:

- New Features in This Release

- Supported Versions

- Understanding the Discovery Process

- Discovering the SOA Suite

- Post Discovery Steps

- Creating Reports

- Provisioning SOA Artifacts and Composites

- Troubleshooting

8.1 New Features in This Release

The new features that have been introduced in the 12c version of the SOA Suite are:

- Dehydration Store: You can view the performance of the database relevant to the SOA engine. You can review the general health of the database engine and identify problems that are causing a performance bottleneck.

- Service Topology: You can see a graphical end to end view of the composite applications. It depicts the various application components and their interactions happening at runtime.

- SOA Partition: You can deploy SOA composite applications into separate sections of the SOA Infrastructure known as partitions.

- Instance Tracing Enhancements: Instance tracing can now be performed at the component level and you can view the audit trail for individual component instances.

- UDDI Publishing: Publishing a service to UDDI is now supported.

8.2 Supported Versions

The following are the versions of the SOA Suite 11g that are supported in Enterprise Manager Cloud Control 12c:

- 11.1.1.2.0 (PS1)

- 11.1.1.3.0 (PS2)

- 11.1.1.4.0 (PS3)

- 11.1.1.5.0 (PS4)

8.3 Understanding the Discovery Process

The following describes the overall process involved in discovering and monitoring SOA Suite 11g in Enterprise Manager Cloud Control. Follow the instructions outlined against each step in this process to successfully discover and monitor the SOA Suite.

Table 8-1 Understanding the Discovery Process

Oracle SOA Suite Version

Application Server Deployed To

Discovery Mechanism

Process

Oracle SOA Suite 11.1 PS2

Oracle WebLogic Managed Server

Manual Discovery

1. First, manually discover Oracle WebLogic Managed Server. For procedures, see Section 6.5.2.1, "Discovering Oracle WebLogic Managed Server".

2. To monitor the SOA Suite, you can use an agent running locally on the Administration Server of the WebLogic domain or a remote management agent running on another host that is not part of the WebLogic domain.
Note: If you use a remote agent to monitor the SOA Suite, the Instance Tracing and View Recoverable Instances features are not supported.

3. To ensure the all the metric data is collected, add the soa-infra-mgmt.jar and the oracle-soa-client-api.jar files to the $AGENT_HOME/plugins/oracle.sysman.emas.agent.plugin_12.1.0.0.0/archives/jlib/ (the Agent Home directory). If the extjlib directory does not exist, it can be created under $FMW_PLUGIN_HOME/archives/jlib. This step is required only if you are using a remote agent to monitor the SOA Suite.
Note: For SOA PS3 and higher, the jrf-api.jar file must also be present in the Agent Home directory.

8.4 Discovering the SOA Suite

This section describes the procedure for discovering the SOA Suite 11g. You can use a local or a remote Management Agent to perform the discovery process. In the case of discovery using a local agent, you need to use a Management Agent that is running on the same host as the Administration Server.

1. From the Targets menu, select Middleware.
Oracle Enterprise Manager Cloud Control displays the Middleware page that lists all the middleware targets being monitored.

2. In the Middleware page, from the Add list, select Oracle Fusion Middleware / WebLogic Domain and click Go. Specify the Administration Server Host, Port, User Name, Password, Agent (local or remote) and the JMX Protocol and click Continue.

3. You will return to the Middleware page. You will see the SOA instances under the WebLogic Domain.

Note:
New SOA Composites are not displayed by default. To display all the SOA Composites, navigate to the Home page of the WebLogic Server target and select the Refresh Domain option from the menu.

8.4.1 Discovering the SOA Suite Using a Remote Agent

You can discover the SOA Suite 11g using a remote agent which may be running on a host that is different from the host on which the Administration Server is running. In this case, you may not be able to perform certain operations like instance tracing and viewing recoverable instances.

To ensure the all the metric data is collected, add the soa-infra-mgmt.jar and the oracle-soa-client-api.jar files to the $AGENT_HOME/plugins/oracle.sysman.emas.agent.plugin_12.1.0.0.0/archives/jlib/ (the Agent Home directory). If the extjlib directory does not exist, it can be created. This step is required only if you are using a remote agent to monitor the SOA Suite.

Note:
For SOA PS3 and higher, the jrf-api.jar file must also be present in the Agent Home directory.

8.5 Post Discovery Steps

After discovering the SOA Suite 11g, you must perform the following additional configuration steps:

1. Set the instance state in the Common Properties page:

1. Click Fusion Middleware Control on the SOA Infrastructure Home Page.

2. Navigate to the Home page of the SOA Infrastructure target.

3. Select Common Properties from the SOA-Infra drop-down menu.

4. On the Common Properties page, select the Capture Composite Instance State check box.

2. Set the SOA database details like the host name, port, and credentials.

1. Navigate to the Middleware page in Enterprise Manager Cloud Control.

2. Select a SOA Infrastructure home from the list and click Configure.

3. The SOA Infrastructure Home page is displayed. Click Monitoring Configuration from the SOA-Infra drop-down menu.

4. Set the SOA database details in the Monitoring Configuration page.

3. Set preferred credentials for the WebLogic Domain.

1. From the Setup menu, select Security, then select Preferred Credentials.

2. Select the Oracle WebLogic Domain target and click Managed Preferred Credentials.

3. Select WebLogic Administrator Credentials in the Target Preferred Credentials and click Set.

4. Enter the user name and password in the Select Named Credentials window and click Save.

8.5.1 Configuring Instance Tracing

To enable Instance Tracing for any SOA Infrastructure instances involved in executing composite instances:

1. Follow the sequence listed under Step 3 of the Section 8.5, "Post Discovery Steps" section.

2. To view the state of the listed instances, enable the Capture Composite State flag by following the sequence listed Step 1 of the Section 8.5, "Post Discovery Steps" section.

8.5.2 Viewing Application Dependency and Performance (ADP) Metrics

If the SOA instance is being monitored by the ADP Manager, additional metrics such as Arrival Rate, Minimum, Maximum, and Average Response Time will be collected.

Tip:
The ADP Manager must be registered before it can collect the metric data. For details on registering the ADP Manager, see Oracle Enterprise Manager Cloud Control Advanced Installation and Configuration Guide.

8.6 Setting Up and Using SOA Instance Tracing

To configure and trace a SOA Composite instance, follow these steps:

1. Login to Enterprise Manager and navigate to the SOA Composite Home page of the instance to be traced.

2. From the SOA Composite menu, select Trace Instance.

3. Find the instance you want to trace by specifying search criteria such as Instance ID, Instance Creation Time Window, Instance Count, Sensor Values and so on. Click Search.

Note:
You must set the Preferred Credentials must be set for the WebLogic Domain and the Monitoring Agent Host to retrieve search data.

- WebLogic Domain: To set the Administrator Credentials for the WebLogic Domain (SOA Domain Target), select Security, then select Preferred Credentials from the Setup menu. Select Oracle WebLogic Domain as the Target Type and click Manage Preferred Credentials. Specify the WebLogic Administrator credentials and click OK.

- Monitoring Agent Host: To set the Preferred Credentials for the host on which the Management Agent has been installed, select Security, then select Preferred Credentials from the Setup menu. Select Host as the Target Type and click Manage Preferred Credentials. Specify the Normal Host Credentials for the host and click OK.

4. The list of instances that match the search criteria is displayed. Select the instance you want to trace and click Trace.

5. In the Select SOA Infrastructure window, select one or more SOA Infrastructure targets for which the trace information is to be gathered. Specify the WebLogic Administration and Host Credentials for these targets and click OK.

6. A trace job is submitted to collect the instance trace data from the selected targets and the flow trace for the instance is generated.

7. When the job has been completed, click Job Status to view the flow trace data. Click the Log Viewer link to access the log messages related to the instance.

8. Click the Component Instance to drill down to the component instance audit trail which shows the activity level execution details.

8.7 Creating Reports

This section describe the procedure to create SOA Reports.

1. From the Enterprise menu, select Reports, then select Information Publisher reports.

2. In the Target Type drop-down list, select the SOA Composite target type, and click Go.
The out-of-box SOA reports are displayed under the SOA Performance Reports section.

3. Select a report from the section (for example, you can select Pending Instance Statistics) and click Create Like. The Create Report Definition page is displayed.

4. In the General page, enter the following details:

1. Enter the BPEL Process Name as the title.

2. Click the Set Time Period to set the time interval for the report.

3. Click the Run report using target privileges of the Report Owner (SYSMAN) check box in the Privileges section.

5. Click the Elements tab and click the Set Parameters icon for the Pending Instance Statistics Element in the table.

6. In the Set Parameters page, click the torch icon to select a Composite Name. The Result Set Size with default values for the Pending Instance Statistics report is displayed.

7. Select a Component Name from the list, enter the Result Set Size and click Continue to return to the Elements page.

8. The selected target name is displayed in the Elements table.

9. To schedule periodic report generation, click the Schedule tab.

10. Specify the schedule type and other details and click OK.

11. You will return to the Report Home page where the newly scheduled report is displayed in the table. Click the report name to view the details.

8.8 Dehydration Store Monitoring

The Dehydration Store Diagnostics feature provides a dedicated view that allows you to analyze the behavior of the SOA Dehydration database. You can monitor SQL performance metrics and table growth specifically in the context of the SOA Suite's use of the database. The view displays both throughput and wait bottleneck data which allows you to monitor the general health of the target database instance. Using Active Session History, you can track usage data and display it as a table space chart, a growth rate chart, or an execution chart.

8.8.1 Enabling Monitoring of the SOA Dehydration Store

To configure and enable monitoring of the SOA Dehydration Store, follow these steps:

1. From the Targets menu, select Databases to check if the database target representing the SOA Dehydration Store has been discovered in Enterprise Manager.

2. Check if at least one configuration for the SOA Infrastructure and WebLogic Server targets is available.

3. On the monitoring configuration for the SOA Infrastructure target, the following fields related to SOA Repository must be configured:

- SOA Repository Connection Descriptor: The connection URL string specified for the JDBC data source on the WebLogic server. This configuration is collected as part of the configuration collection mechanism for the SOA Server instance. For example: jdbc.oracle.thin@host:port/sid (or service_name).

- SOA Repository Host Name: The database listener host for the SOA database instance. This is optional if the connection string has already been configured.

- SOA Repository Port: - The database listener port for the SOA database instance. This is optional if the connection string has already been configured.

- SOA Repository Schema Name: The schema name configured for SOA Dehydration Store.

- SOA Repository User Name: The schema name configured for SOA Dehydration Store.

- SOA Repository Password: The password for the SOA schema user.SOA Repository SID: The SID for the SOA database instance.

If you do not see data after these configuration details have been specified, you must wait for the next collection interval.

8.8.2 Viewing the SOA Dehydration Store Data

To view the dehydration diagnostics data, follow these steps:

1. From the Targets menu, select Middleware, then click on a SOA Infrastructure target.

2. In the SOA Infrastructure Home page, click the Dehydration Store tab.

3. The following details area displayed:

- Throughput indicators that provide details of the general health of the database instance.

- Wait bottleneck issues related to the CPU, I/O, and Wait events.

- Tablespace utilization for the SOA schema.

- Performance data recorded by the ASH.

- Key SOA tables and tablespace details related to the SOA schema.

8.9 Service Topology

The Service Topology provides a graphical end to end view of the composite applications. It depicts the various application components and their interactions happening at runtime. It allows you to view the service level dependencies among the components and provides key performance statistics and incidents information for them.Composite applications are distributed in nature and this view helps you quickly visualize the structure, status, availability, dependencies, configuration changes, and performance of business-critical distributed applications from one place and easily identify any availability or performance issues.

The Service Topology Viewer shows the following:

- Service to Service Calls: It allows you to view the Service to Service calls between any two SOA entities (Composites/J2EE Applications/OSB/BPEL 10g instances) by clicking the link between the entities.

- Dependency Highlighting: It allows you to view the dependencies for any service. If you click on a service, all the services that it is dependent on and vice versa are highlighted.

- Database Associations: Shows all the databases used by the SOA Composites, BPEL 10g instance and J2EE applications.

- External Services: Shows the services that are used by a SOA Composite application but are external to it or not managed by Enterprise Manager Cloud Control.

For more details, refer to the Enterprise Manager Online Help.

8.10 UDDI Publishing

To publish a service to UDDI, navigate to the Services and References Home page, select a service from the table and click Publish to UDDI from the menu. The Publish Service to UDDI window is displayed with the following fields:

- Service Name: The name of Web Service to be published to the UDDI Registry. This is a Read Only field.

- Service Description: The description of the selected Web Service.

- Service Definition Location: The URL location of the Service Definition. This is a Read Only field.

- UDDI Source: A logical name for an external UDDI registry source. Select the UDDI Source from the drop-down list.

- Business Name: The name of the data structure in the UDDI registry. Select a Business Name that has been registered with the UDDI from the list.

Click OK to start the process that publishes the web service to UDDI or click Cancel to cancel publishing the service.

8.11 Provisioning SOA Artifacts and Composites

The SOA Artifacts Deployment Procedure allows you to:

- Provision SOA Artifacts from a reference installation or from a gold image

- Create a gold image of the SOA Artifacts

- Provision SOA Composites either from the Software Library or from another accessible location.

For more details on the SOA Artifacts Deployment Procedure, see the Enterprise Manager Administrator's Guide for Software and Server Provisioning and Patching.

8.12 Troubleshooting

This section describes the errors you might encounter while discovering the SOA Suite 11g and the workaround steps you can follow to resolve each of them.

This section covers the following:

- Discovery

- Monitoring

- Instance Tracing

- Faults

- Application Dependency and Performance Integration

- Reports

- Systems and Services

- BPEL Recovery

- SOA License Issue

- Dehydration Store Issue

8.12.1 Discovery

The following error occurs when the SOA instances are being discovered.

Table 8-2 Error Message:

Error Message

Workaround Steps

New SOA Composite deployed on the SOA
Server from JDeveloper are not
displayed automatically in Enterprise
Manager Cloud Control.

To discover the newly deployed SOA Composites in Enterprise Manager Cloud Control, you must run the Refresh Farm menu option for the associated WebLogic Domain.

8.12.2 Monitoring

The following error occurs when the collection frequency causes a delay in the collection of configuration data.

Table 8-3 Error Description

Error Description

Workaround Steps

All metrics are not displayed.

Enterprise Manager Cloud Control uses the Management Agent to collect metric data. For the first collection, the agent may need 15 minutes to upload the metric data.

8.12.3 Instance Tracing

The following error occurs when the instance is traced.

Instance Search Fails - Same reason as BPEL first column. If Management Agent is down or unreachable.

Table 8-4 Error Message:

Error Message

Workaround Steps

Instance Tracing Job Fails

1. Navigate to the Jobs page and locate the Instance Tracing job (Composite Name + Instance ID + Timestamp in ms) and view the output to identify the step that has failed.

2. Resolve the issue and run the job again by clicking Retry on the Jobs page.

3. Navigate to the Instance Tracing page to view the trace results. You can also submit a new job by running the Trace Instance option on the Instance Tracing page.

8.12.4 Faults

The following errors occur when:

- All instances with faults are not displayed as only the last 10 values are collected.

- The most recently collected fault instances do not appear in the Faults and Messages page.

Table 8-5 Error:

Error Description

Workaround Steps

All instances with faults are not
populated in Enterprise Manager Cloud
Control.

By default, you can only view the latest 10 faults collected during the last 15 minutes. To view additional faults, navigate to Fusion Middleware by clicking the link in the General section on the target Home page.

8.12.5 Application Dependency and Performance Integration

When you click on the Application Dependency and Performance link in the SOA Instance Home page, you may see a blank page. This error may occur if:

- Application Dependency and Performance is not being used to monitor the SOA instance.

- Application Dependency and Performance has not been registered in Enterprise Manager Cloud Control.

Table 8-6 Error Message:

Error Message

Workaround Steps

Missing ADP Data - Add the metrics -
and add one for blank page.

To monitor data collected using ADP, the ADP Manager must be registered and configured.

8.12.6 Reports

This section lists report related errors.

Table 8-7 Error Message:

Error Description

Workaround Steps

Report generation fails due to invalid
database details.

1. Navigate to the All Targets page.

2. Select the SOA Infrastructure target on which the specific SOA Composite has been deployed and click Configure.

3. In the Monitoring Configuration page, specify the database connection details and the credentials and click OK.

No targets found message for Oracle
SOA Composite Reports.

You cannot use the out-of-box reports directly. You must use the Create Like option to generate custom reports based on the SOA Composite Target type.

Report generation fails due to invalid host details.

Set valid credentials for the host target on which the SOA Infrastructure instance is running.

8.12.7 Systems and Services

The following error occur when you try to refresh a service that has not been created.

Table 8-8 Error Message:

Error Message

Workaround Steps

Create Service option does not work.

System and service creation depends on the configuration collection of the SOA Infrastructure and related targets. Check the log file for details.

Refresh Service option does not work.

The Refresh Service function works for an existing Infrastructure service. In case the service does not exist, it should be created using the Create Service menu option.

8.12.8 BPEL Recovery

The following error occurs when invalid credentials are provided.

Table 8-9 Error Message:

Error Message

Workaround Steps

Invalid Host and WebLogic Domain Credentials

For the BPEL Recovery functionality to work, the host credentials and WebLogic Domain credentials must to be available in the preferred credential store. Set the valid credentials and try again.

8.12.9 SOA License Issue

The following error occurs if the SOA Management Pack EE has not been enabled.

Table 8-10 Error Message

Error Message

Workaround Steps

The page requested is part of the SOA Management Pack EE.

The SOA Management Pack EE must be enabled for the specific SOA Infrastructure target. To enable the license, follow these steps:

1. From the Setup menu, select Management Packs, then select Management Pack Access.

2. Select SOA Infrastructure in the Target Type drop-down box.

3. Uncheck and check the SOA Management Pack EE.

4. Click Apply and navigate to the SOA Composite page.

8.12.10 Dehydration Store Issue

Data is not displayed on the Dehydration Store page.

Table 8-11 Error Message

Error Message

Workaround Steps

Data is not displayed in the Dehydration Store page.

This error may occur if there is a data mismatch between the values specified for the database target and the WebLogic Server Datasource. To resolve this issue, follow these steps:

1. Compare the Database Host and SID value of the database target with the value collected for the WebLogic Server JDBC Datasource configuration.

2. If the values are different, select Services from the Targets menu. Select DataSources, then select SOALocalTxtSource, then click Connection Pool to update the Datasource Connection URL

Part III

Using JVM Diagnostics

The chapters in this part provide information regarding JVM Diagnostics. The chapters are:

- Chapter 9, "Introduction to JVM Diagnostics"

- Chapter 10, "Using JVM Diagnostics"

- Chapter 11, "Troubleshooting JVM Diagnostics"

9 Introduction to JVM Diagnostics

This chapter provides an overview of JVM Diagnostics. It contains the following sections:

- Overview

- New Features in this Release

- Supported Platforms and JVMs

- User Roles

9.1 Overview

Mission critical Java applications often suffer from availability and performance problems. Developers and IT administrators spend a lot of time diagnosing the root cause of these problems. Many times, the problems occurring in production environments either cannot be reproduced or may take too long to reproduce in other environments. This can cause severe impact on the business.

Oracle Enterprise Manager Cloud Control 12c's JVM Diagnostics enables administrators to diagnose performance problems in Java application in the production environment. By eliminating the need to reproduce problems, it reduces the time required to resolve these problems. This improves application availability and performance. Using JVM Diagnostics, administrators will be able identify the root cause of performance problems in the production environment without having to reproduce them in the test or development environment. It does not require complex instrumentation or restarting of the application to get in-depth application details. Application administrators will be able to identify Java problems or Database issues that are causing application downtime without any detailed application knowledge. The key features of JVM Diagnostics are:

- Java Activity Monitoring and Diagnostics with Low Overhead

- In-depth Visibility of JVM Activity

- Real Time Transaction Tracing

- Cross-Tier Correlation with Oracle Databases

- Memory Leak Detection and Analysis

- JVM Pooling

- Real-time and Historical Diagnostics

9.1.1 Java Activity Monitoring and Diagnostics with Low Overhead

JVM Diagnostics provides in-depth monitoring of Java applications without slowing them down. It helps you to identify the slowest requests, slowest methods, requests waiting on I/O, requests using a lot of CPU cycles, and requests waiting on database calls. It also identifies the end-user requests that have been impacted by resource bottlenecks. Application resources that are causing the performance bottleneck are also visible.

9.1.2 In-depth Visibility of JVM Activity

JVM Diagnostics provides immediate visibility into the Java stack. You can monitor thread states and Java method/line numbers in real time and you can proactively identify issues rather than diagnosing issues like application crashes, memory leaks, and application hangs after they occur.

9.1.3 Real Time Transaction Tracing

If a particular request is hanging or if the entire application is slow, administrators can perform a real-time transaction trace to view current Java application activity. You can see the offending threads and their execution call stacks. You can also analyze various bottleneck resources such as how much time a thread spent in waiting for a database lock. Complex problems such as activity in one thread (or request) affecting the activity in the other thread or rest of the JVM can be found very quickly.

Sometimes the monitoring interval (default 2 seconds) that is in use is too coarse grained. The Java thread of interest may be too short lived or the amount of monitoring data collected may be insufficient. In such cases, you can run a JVM Trace to get fine-grained details of the JVM activity. This feature allows you to monitor your Java application at a very high frequency (default of once every 50ms) for a short period of time. This allows you to identify interdependency of threads, bottleneck resources (DB, I/O, CPU, Locks, Network) & top methods.

9.1.4 Cross-Tier Correlation with Oracle Databases

JVM Diagnostics facilitates tracing of Java requests to the associated database sessions and vice-versa enabling rapid resolution of problems that span different tiers. Administrators can drill down from a JVM Thread in a DB Wait State to the associated Oracle database session. Additionally, they can now drill up from the SQL query to the associated JVM and related WebLogic Server targets (this is applicable only if the database and JVM are being monitored by Enterprise Manager.

This feature highlights the slowest SQL queries and helps administrators to tune SQL and the database to improve the performance application. This facilitates smooth communication between the database administrators and application administrators by isolating the problems to the database or the application tier.

9.1.5 Memory Leak Detection and Analysis

Memory leaks lead to application slowdowns and eventually cause applications to crash. JVM Diagnostics alerts administrators on abnormalities in Java memory consumption. Administrators can use JVM Diagnostics and take heap dumps in production applications without disturbing the application. They can take multiple heap dumps over a period of time, analyze the differences between the heap dumps and identify the object causing the memory leak. Heap analysis can be performed even across different application versions. Differential Heap Analysis with multiple heap dumps makes it easy to identify memory leaks.

9.1.6 JVM Pooling

JVM Diagnostics allows administrators to group sets of JVMs together into JVM pools. This provides the console user with a single view across all related JVMs. Hence all JVM's that make up a single application or a single cluster may be grouped together in an application. This allows administrators to visualize problems naturally and intuitively.

9.1.7 Real-time and Historical Diagnostics

With JVM Diagnostics, you can perform real-time and historical diagnostics on your Java applications. This provides you with detailed insight on the root causes of production problems without having to reproduce the same problem in a Test or QA environment. You can play back transactions interactively from the browser and view the time spent in the network and the server.

Apart from the real-time data, you can also analyze historical data to diagnose problems that occurred in the past. You can view historical data that shows the time taken by end-user requests and the breakdown by Servlet, JSP, EJB, JDBC, and SQL layers.

9.2 New Features in this Release

This section lists some of the new JVM Diagnostics features in Oracle Enterprise Manager Cloud Control 12c:

- Automated JVM Diagnostics Manager and Agent Deployment Procedure.

- Customer provisioning scripts for deploying JVMD agent in production environment.

- New home pages available for JVM Pool and JVM targets.

- Top databases chart added to the JVM and JVM Pool target pages.

- Metric Palette for JVMs and JVM Pools is now available and associated with WebLogic Server targets.

- JVM Diagnostics integrated with the Middleware Diagnostics Advisor.

- Automatic correlation between JVM and WebLogic Server targets.

- JVM Diagnostics region is now included in Composite and Fusion Applications.

- JVM threshold violations are now integrated with the Event subsystem.

- Heap snapshots can be taken in HPROF format for external analysis. Heap snapshots can now be imported.

- Performance Diagnostics and Live Thread Analysis pages can be directly accessed from the JVM target page.

- Bi-directional integration between JVM threads and database sessions through Live Thread Analysis.

- Thread State Transition charts and class histograms are now available.

- RMI Thread State is now supported.

- Wait Time on SQL (DB Wait), Thread Stack Local Objects Browser, Depth and number of locks are now displayed in the Live Thread Analysis page.

- Sample analyzer can be accessed from the Thread State Transition Chart.

- Windows 64, WLS Virtual Edition, Solaris x86-64 and AIX 64 platforms are now supported.

- JVMD Manager is now supported for all OMS platforms.

- The DB Agent is not required for cross tier correlation if you are using Oracle Database 11gR2 or later versions.

- You can drill down to JVM Diagnostics from RUEI and ESS.

- Integration between JVM Diagnostics and Coherence, JVMD and ECM is now available.

- The performance of the JVMTI engine has improved.

9.3 Supported Platforms and JVMs

The JVM Diagnostics Manager is supported on all platforms on which the Oracle Management Service has been certified.

For the latest certification information, refer to My Oracle Support Note 1265738.1. You can access My Oracle Support at the following URL:

https://support.oracle.com/CSP/ui/flash.html

9.4 User Roles

To use JVM Diagnostics, you must have either of the following Enterprise Manager system privileges:

- JVM Diagnostics User: Allows you to view JVM Diagnostics data.

- JVM Diagnostics Administrator: Allows you to manage JVM Diagnostics operations.

You can define these privileges in the Setup pages. For more details on defining these privileges, see the Enterprise Manager Security chapter in the Administration Guide.

10 Using JVM Diagnostics

This chapter describes the various tasks you can perform using JVM Diagnostics. In particular, it contains the following:

- Installing JVM Diagnostics

- Setting Up JVM Diagnostics

- Accessing the JVM Diagnostics Pages

- Managing JVM Pools

- Managing JVMs

- Viewing the Thread Snapshots

- Analyzing Heap Snapshots

- Tracing Active Threads

- Uploading Trace Diagnostics Images

- Viewing the Available Traces

- Analyzing Trace Diagnostic Images

- JVM Offline Diagnostics

- Viewing JVM Diagnostics Threshold Violations

10.1 Installing JVM Diagnostics

The JVMD Manager runs as an Enterprise JavaBeans (EJB) Technology on a WebLogic Server. The JVMD Agent is deployed on the targeted JVM (the one running a production WebLogic Server). It collects real-time data and transmits it to the JVM Diagnostics Manager. This data is stored in the Management Repository, and the collected information is displayed on Enterprise Manager Cloud Control console for monitoring purposes. The communication between the JVMD Manager and the JVMD Agent can be a secure (SSL) or non-secure connection.

The Middleware Diagnostics Page is a GUI based screen that enables you to deploy JVMD Manager, and monitor the health of the JVMD Manager application in a reliable and an efficient manner. Using Middleware Diagnostics Page, you can achieve the following:

- Deploy JVM Diagnostics Manager

- Monitor the availability of all the JVMD Managers

- Access information about the JVMD Managers like hosts to which managers are deployed, the current status, the port on which they are running, version, and so on.

For more details on installing JVM Diagnostics, see Enterprise Manager Cloud Control Basic Installation Guide.

10.1.1 Monitoring a Standalone JVM

If you need to monitor a standalone JVM, you can manually deploy the JVM Diagnostics Agent by following these steps:

1. From the Setup menu, select Middleware Diagnostics, then click Deploy Diagnostics Manager in the Middleware Diagnostics page. Check if the JVM Diagnostics Manager has been enabled. You do not need the ADP Manager as the JVMD Manager is independent and will run in a WLS target in the same domain as the Cloud Control OMS server that is already running. This is essentially another WLS container in the same domain and is very lightweight, so it can run well on the same server as the Cloud Control OMS instances.

2. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Middleware Diagnostics page. Click the JVMs and Pools tab and click Downloads to download the jamagent.war file.

3. Add the jamagent.war to the CLASSPATH as follows:
CLASSPATH=$CLASSPATH:/scratch/ssmith/jvmd/jamagent.war

export CLASSPATH

4. Start JVM Diagnostics with the JVM Diagnostics Agent as follows:
$JAVA_HOME/bin/java -cp $CLASSPATH $JVM_OPT $SYS_OPT jamagent.jamrun [$JAMAGENT_PARAMS_LIST] $TARGET_CLASS $TARGET_CLASS_PARAMS

where [$JAMAGENT_PARAMS_LIST] refers to the JVM Diagnostics Agent parameters. The mandatory parameters are:

- jamconshost = JVM Diagnostics Manager Host

- jamconsport = Listening port of JVM Diagnostics Manager

- oracle.ad4j.groupidprop = [UniqueJVMPoolName]/[UniqueJVMName]

An example is given below:

CLASSPATH="$CLASSPATH:/scratch/ssmith/jamagent.war"
$JAVA_HOME/bin/java -cp $CLASSPATH $JVM_OPT $SYS_OPT jamagent.jamrun
jamconshost=10.229.187.109 jamconsport=3800
oracle.ad4j.groupidprop= MyJVMPool1/JVM50

10.2 Setting Up JVM Diagnostics

Follow these steps to set up and configure JVM Diagnostics:

1. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Diagnostics Managers page.

2. In the JVMD Manager Parameters page, enter the following details:

- JVMD Manager Log Level: The log level for console diagnostics messages. Log levels 1 to 5 are supported where:

- 1 = Error

- 2 = Warning

- 3 = Info

- 4 = Debug

- 5 = Trace

The default log level is 3.

- Cross Tier Log Level: The log level for cross-tier diagnostic messages. Log levels 1 to 5 are supported where:

- 1 = Error

- 2 = Warning

- 3 = Info

- 4 = Debug

- 5 = Trace

The default log level is 3.

- Agent Request Timeout: The number of seconds that the JVMD Manager waits for the JVMD Agent to respond. You can increase this value if the monitored JVMs are extremely busy and the console times out and disconnects while waiting for a response.

- Agent Loop Request Timeout: The number of seconds that the JVMD Agent waits before it makes the next attempt to communicate to the JVMD Manager.

- Monitoring Aggregation Interval: The frequency at which the detailed monitoring samples should be aggregated into summary data.

- System Sample Interval: The frequency at which system details (cumulative CPU counters, heap size, number of GCs) should be collected in monitoring.

- Purge Data Older Than: The period for which the detailed monitoring samples should be retained.

- Enable Monitoring: Select this check box to start or stop monitoring.

- Retry Changing Threads: If a thread stack changes during a sample (this can happen when a thread is using CPU), JVM Diagnostics will skip that thread for that sample. If you find missing samples, use this feature to retrace the changed stacks. This will retry (up to 5 times) threads with changing stacks. It will also make system calls to get the stack if possible.

Note:
This field is not applicable to the JVMTI (level 0) optimization.

3. Click Save to save the parameters.

10.2.1 Viewing Registered JVMs and Managers

Follow these steps to view a list of registered JVMs and JVM Managers:

1. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Middleware Diagnostics page.

2. The following tables are displayed:

- Registered Managers: The following details are displayed:

- Manager ID: The unique ID assigned to the JVM Manager. This ID identifies the JVM Manager in all the processes.

- Host: The machine on which the JVM Manager has been deployed.

- Port: The port of the machine on which the JVM Manager has been deployed.

- SSL Port: The SSL Port of the machine on which the JVM Manager has been deployed.

- Build Version: The build version of this JVM Manager.Status: The status of the JVM Manager (Active/Inactive)

- Registered JVMs: The following details are displayed:

- Manager ID: The ID of the Manager to which this JVM is connected.

- JVM ID: This is a unique ID given to the Agent and is used to identify the Agent in all the processes.

- Pool: The JVM Pool with which the JVM is associated.

- Host: The Host on which the JVM is running.

- JVM Name: The name given to the JVM for identification. The basic format of the JVM Name is <HOST>_<PORT>_jvm or <EMFarm>/<Domain>/<Server>_jvm.

- CPUs: The number of CPUs.

- ID: The port on which the JVM is running. (Default: 5555)

- Heap Size (Kb): The total Heap Size used.

- Heap Dump Dir: The location of the directory in which the heap snapshots are temporarily stored.

- Log Level: The log level of the JVM.

- Status: The status of the JVM (active or inactive).

Check the Select check box and click the Edit icon to edit the JVM. In the Edit JVM Information page, you can select a different JVM Pool, modify the JVM Name, Heap Dump Dir, and Log Level. Click Save to save the changes or Reset to restore the previous values.

- Registered DB Agents: The following details are displayed:

- Manager ID: The ID of the Manager to which this DB Agent is connected.

- DB ID: This is a unique ID given to the DB Agent and is used to identify the DB Agent in all the processes.

- Host: The host on which the DB Agent is running.

- CPUs: The number of CPUs.

- OS User: The user who started the DB Agent.

- ID: The port on which the DB Agent is running (Default is 5555).

- Log Level: The log level of the DB Agent.

- Status: The status of the DB Agent (active or inactive)

Check the Select check box and click the Edit icon to edit the DB Agent.

10.2.2 Configuring JVM Pools

You can group sets of JVMs into JVM pools that provide monitoring information across all related JVMs in a single view. You can view all the JVM pools in the WebLogic Domain, create a new JVM pool, and edit existing JVM pools.

1. From the Setup menu, select Middleware Diagnostics and click Setup JVM Diagnostics in the Middleware Diagnostics page.

2. Click the Pools tab. The list of all available JVM pools is displayed. For each pool, you can view the polling interval, whether polling is enabled, and the e-mail notification recipient. If the Polling Enabled flag is set to Y, JVMs belonging to this pool will be polled for active requests periodically based on the Poll Interval.

3. Click New Pool to create a new pool.

1. In the Add JVM Pool Information page, enter the name and description of the JVM pool.

2. In the Poll Interval field, specify the sample interval for JVMs belonging to this pool when monitoring (polling) is enabled.

3. Check the Poll Enabled check box to poll the JVMs belonging to this pool.

4. Click Save to save the JVM Pool information.

4. To delete a pool, check the select check box and click the Delete icon. You cannot delete the Default and Other pools.

5. Click the Edit icon to edit an existing JVM pool.

1. Modify the JVM pool details and click Save to save the changes.

2. To modify the pool thresholds, click Set Thresholds. See Section 10.2.2.1, "Updating Pool Thresholds" for details.

10.2.2.1 Updating Pool Thresholds

Follow these steps to edit the pool thresholds:

1. From the Setup menu, select Middleware Diagnostics and click Setup JVM Diagnostics in the Middleware Diagnostics page.

2. Click the Pools tab to view the Show JVM Pools page.

3. Click the Edit icon of the JVM pool you want to edit.

4. In the Edit JVM Pool Information page, click Set Thresholds.

5. In the Edit Thresholds for JVM Pool page, the following details are displayed:

- Level: Thresholds violations can have a level of R (red) or Y (yellow).

- Metric: The attribute or metric that is being monitored.

- Threshold: The value against which the metric is being compared. A violation occurs when the threshold is exceeded after a minimum number of samples have been monitored.

- Action URL: The URL to be invoked when a threshold violation occurs. This includes internal URLs into the JVMD Console and external URLs. The Action URL can be used to trace a particular thread, all active threads, or dump a heap in response to a threshold violation. The Action URL can be any valid URL on a remote system. It can also accept URLs on the local JVMD Console. The Action URL should be a valid URL as called from a browser. If not specified, default parameters for the traceThread and heapdump will be added to the URL.

6. Click Save to save the threshold values.

10.2.3 Setting the Monitoring Status

After the JVM pools have set up and configured correctly, you must enable monitoring so that the JVMs in the pool can be monitored. Follow these steps to enable monitoring for a JVM pool:

1. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Middleware Diagnostics page.

2. Click the Monitoring tab to view the monitoring status of the JVM pools.

3. Click the Edit icon to enable or disable monitoring of pools or change their polling intervals by updating the pool properties.

4. You can mark a thread as idle by adding it to an Idle Thread Rule. All threads that have been marked as idle will not be monitored. Click New Rule to create a new Idle Thread Rule.

- Rule Type: The Rule Type can be:

- Monitor (Waiting on Lock): Select this type if you want to ignore threads that are locked with a lock of the specified nameCurrent Call: Select this type if you want to ignore all threads that are making a call to the selected function.

- Rule Value: The Rule Value should contain the class name, method, followed by class+method. An example of a Current Call is weblogic.socket.PosixSocketMuxer->processSockets. An example of a Monitor (Waiting on Lock) is weblogic.socket.PosiSocketMuxer$1.

All threads that meet the criteria specified in the Idle Thread Rule will not appear in the View Active Threads screen.

10.2.4 Downloading the JVM Diagnostics Components

You can manually download the various binaries such as JVM Diagnostics Agent, JVM Diagnostics Manager, Database Agent, Load Heap, and deploy them.

Follow these steps to download the binaries:

1. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Middleware Diagnostics page.

2. Click the Downloads tab. The list of JVM Diagnostics components that can be downloaded is displayed.

3. Click on the download icon for the component to be downloaded. You can download:

- JVM Diagnostics Agent WAR File: The JVM Diagnostics Agent Parameters web.xml Parameters window is displayed. From the Available Managers drop-down, you can select entries that are in the format <host>:<port> - for normal communication, <host>:<port>(secure communication) for communication over the SSL Port or you can select Other. If you select Other, you need to specify the Manager IP Address and the Manager Port to which the JVM Diagnostics Agent is connecting to. While downloading the Agent, you can modify the following parameters:

- Tuning Timeouts Parameters: You can modify the Connection Retry Time, GC Wait Timeout, Long Request Timeout, and Idle Agent Timeout.

- Target Association Parameters: If you select WebLogic Server, you can specify the Target Name, and Pool Name. If you select Other Server, you can specify the Group ID Property and Pool Name.

- Logging Parameters: You can modify the Agent Log Level.

- Optimization Level: You can modify the Optimization Level.

- JVM Diagnostics Manager EAR File: You can open the jammanager.ear file or save it to a specified location.

- Load Heap: The loadheap.zip is saved to a specified location.

10.2.5 Registering the Database Target

Follow these steps to register the database:

1. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Middleware Diagnostics page.

2. Click the Register Database tab.

3. The list of registered databases are displayed. The database name, host, Oracle SID for the monitored database, and listener port number is displayed. You will also see a flag indicating whether the database agent is required.

4. You can do the following:

- Add a Database Instance: From the Add menu, select Database Instance to register an Enterprise Manager database target.

- Add a Custom Database: From the Add menu, select Custom Database to register an external database target. Specify the Name, Host, Port, SID, Instance ID, Username, and Password and click Test Connection to validate the database details. After the validation, click OK to register the database.

- Remove: Select a database from list and click Remove to remove a registered database.

- Edit: You cannot edit a Database Instance. Only custom databases can be edited. Select a custom database from the list and click Edit.

5. Note:

- The OS User you specify here must be the same OS User running the database agent. This user must have full database privileges and appropriate environment settings using the SID and path binaries.

- The DB User must the same as the user running the application is being monitored.

- Multiple registrations may be necessary for a single database agent if different database users are running multiple applications.

- For Oracle RAC databases, each node must be registered.

6. After the database has been registered, the JVM Diagnostics Manager will start monitoring the cross-tier JVM calls between applications being monitored for a particular JVM and the underlying database.

10.3 Accessing the JVM Diagnostics Pages

After you have deployed the JVM Diagnostics Manager and configured JVM Diagnostics, you can start using the features. Navigate to the Middleware tab in Enterprise Manager and click on a JVM Pool, Java Virtual Machine, WebLogic Server, WebLogic Domain or Cluster target. The Home page for the target is displayed.

Figure 10-1 JVM Pool Home Page

To start using JVM Diagnostics, select the JVM Diagnostics option from the JVM Pool drop-down menu and choose the appropriate option.

10.4 Managing JVM Pools

You can group sets of JVMs into JVM pools that provide monitoring information across all related JVMs in a single view. You can monitor all the JVMs in a pool, view historical and real time data for the JVM pool, manage threads and heap snapshots, create a new pool, and edit an existing JVM pool. JVMs and JVM Pools are now targets in Enterprise Manager. You can do the following:

- View the JVM Pool Home Page

- View JVM Pool Performance Diagnostics

- View the JVM Pool Live Thread Analysis

- Manage Thread Snapshots

- Manage Heap Snapshots

- Setup JVM Diagnostics

10.4.1 Viewing the JVM Pool Home Page

The JVM Pool Home page shows the details of all JVMs in the pool.

Figure 10-2 JVM Pool Home Page

It shows the following details:

- Summary: Shows whether poll is enabled and the Polling Interval.

- Availability: This region shows the availability status of the members in the JVM Pool. Click on a Member link to drill down JVM Home Page.

- Incident: This region shows any open incidents that have occurred, the type, and category of the incident. Click the Summary link to drill down to the Incident Details page.

- Realtime Thread States: This region shows the realtime thread status for each JVM in the pool. The current activity of the JVM including CPU usage, memory, number of threads waiting for a database response, number of threads waiting for synchronization lock, and other details are displayed. Click on the JVM link to drill down to the JVM Performance Diagnostics page.

10.4.2 Viewing the JVM Pool Performance Diagnostics Page

You can view the summary and detailed information of the selected JVM Pool on this page. You can also compare the JVM pool data across two specific time periods. To view this page, select Middleware from the Targets menu and click on a JVM Pool target. Select the JVM Performance Diagnostics option from the Java Virtual Machine Pool menu.

Figure 10-3 JVM Pool Performance Diagnostics Page

This page shows the summary details of the JVM pools which include the Server State Charts, and a list of Top Methods and Top Requests. You can view the Server State Charts, list of Top Methods, Top Requests, Top DBStates, and Top SQLs. You can filter the data that is displayed by specifying various criteria such as Method Name, JVM Name, Thread State, DBState, and so on. The list of all JVMs in the pool and the server state charts for each JVM is displayed. Click the link to drill down to the Java Virtual Machine Home page.

10.4.3 Viewing the JVM Pool Live Thread Analysis Page

This page shows the real-time data for all the JVMs in the selected pool. This data is useful in analyzing the various active and idle threads on the JVM. During analysis you can drill down from the thread level to methods used in the thread to local variables that are part of the method. To view this page, select Middleware from the Targets menu and click on a Java Virtual Machine Pool target. Select the Live Thread Analysis option from the Java Virtual Machine Pool menu.

Figure 10-4 JVM Pool Live Thread Analysis Page

This page shows the following:

- JVMs: This table shows the list of JVMs and the current status of each JVM. The current activity of the JVM including CPU usage, memory, number of threads waiting for a database response, number of threads waiting for synchronization lock, and other details are displayed

- Threads for JVM: This t able shows a list of all the threads running in the JVM. For each thread, the Thread Name, Request, Age, OS PID, Current Call, File Name, Line, State, Waiting On, Wait Time, Lock Held, ECID. If the thread is in the DB Wait State, click on the link to drill down to the Database Home page. See Section 10.5.4.1, "Cross Tier Analysis" for more details.
If the ADP Agent is running, the Request Name and Request Age is displayed. If a thread is in the DB Wait State, the Waiting On column displays the name of the database the thread is waiting on, and the time the thread has to wait is displayed in the Wait Time column.

You can also see two charts, the first one displays the active threads in the JVM, the second one displays the heap status for the JVM.

10.5 Managing JVMs

You can monitor a specific JVM in a pool, view historical and real time data, and so on. You can do the following:

- View the JVM Home Page

- View JVM Performance Diagnostics

- View JVM Performance Summary

- View the Live Thread Analysis Page

- View the Live Heap Analysis Page

- Manage Thread Snapshots

- Manage Heap Snapshots

- Setup JVM Properties

10.5.1 Viewing the JVM Home Page

The JVM Home page shows the summary and configuration information of all the JVMs in the JVM pool. Follow these steps to view the JVM Home page:

1. From the Targets menu, select Middleware, then click on a Java Virtual Machine target.

2. The JVM Home page with the following details is displayed.

- Summary: Shows details of the JVM such as the JVM Pool it belongs to, the host, Agent Optimization Level, Agent Log Level, JVM Version, and vendor details.

- Incident: Shows the thresholds and alerts if any for this JVM.

- Availability: The availability status of the JVM.

- Active Threads: The number of active threads in the JVM in the last 24 hours.

- Realtime Thread States: Shows the state of the various threads in the JVM in the color coded columns. Click on a JVM to view the list of threads in the JVM and the details of each thread.

10.5.2 Viewing the JVM Performance Diagnostics Page

This page shows the summary and detailed information for a specific JVM. To view this page, select Middleware from the Targets menu and click on a Java Virtual Machine target. Select the JVM Performance Diagnostics option from the Java Virtual Machine menu.

Figure 10-5 JVM Performance Diagnostics Page

This page shows the summary details of the JVM which include the Server State Charts, Active Threads by State, Top Methods, Top Requests, Top DBWait Events, Top SQLs, and Top Databases. You can filter the data that is displayed by specifying various criteria such as Method Name, JVM Name, Thread State, DBState, and so on.

Click on the Threads tab to view the Thread State Transition chart. This chart shows how the threads have transitioned from one state to the other in the selected period. You can change the time interval and move it to a different time period by using the quick time selection control at the top of the page. You can hover over the colored bars to see the transition changes from one state to the other, for example from Runnable to Not Active or to Runnable.

Figure 10-6 Thread State Transition

Click on a bar graph in the State column to view a detailed analysis on the state of the thread. This feature allows you to analyze each sample (JVM snapshot at a specific time) in the monitored data.

Click the Create Diagnostics Snapshot link to collect diagnostic data for the JVM target for a specific period and analyze this data in an offline mode. For more details, see Section 10.12, "JVM Offline Diagnostics"

10.5.3 Viewing the JVM Diagnostics Performance Summary

You can view the performance metrics (system and active threads) for a JVM target on the Performance Summary page. A set of charts are displayed on this page for the JVM target. To view the JVM performance metrics, follow these steps:

1. From the Targets menu, select Middleware, then click on a Java Virtual Machine target.

2. Select the Performance Summary option from the Java Virtual Machine menu.

3. A set of default charts that show the values of the JVM performance metrics over a period of time are displayed. Click the Show Metric Palette button.

4. The metric palette has a folder for the current target (JVM) and the related targets. You can add or remove metric charts. Leaf nodes act as check boxes. Clicking a leaf node on causes a chart to be added. Clicking it off removes the metric. Dragging a leaf node from the palette to a chart or legend adds the metric to that chart.

10.5.4 Viewing the JVM Live Time Thread Analysis Page

This page shows the real-time data for a selected JVM. This data is useful in analyzing the various active and idle threads on the JVM. During analysis you can drill down from the thread level to methods used in the thread to local variables that are part of the method. To view this page, select Middleware from the Targets menu and click on a Java Virtual Machine target. Select the Live Thread Analysis option from the Java Virtual Machine menu.

Figure 10-7 JVM Live Thread Analysis Page

This page shows the following:

- JVM Threads: This table shows a list of all the threads running in the JVM. Click on a thread to view the thread details in the Thread Info table. For each thread, the Thread Name, Request, Age, OS PID, Current Call, File Name, Line, State, Waiting On, Wait Time, Lock Held, ECID.
If the ADP Agent is running, the Request Name and Request Age is displayed. If a thread is in the DB Wait State, the Waiting On column displays the name of the database the thread is waiting on, and the time the thread has to wait is displayed in the Wait Time column.

You can perform the following actions:

- Take Snapshot of a Selected Thread or Active Threads: Select a thread from the list and choose the Take Snapshot of a Selected Thread option from the Actions menu. The Thread Snapshot page is displayed where you take a snapshot. If you select the Take Snapshot of Active Threads option, you can take a snapshot of all active threads running on this JVM. You can specify the following parameters for each snapshot:

- Poll Interval: Interval after which snapshot should be repeated.

- Poll Duration: Duration for which the snapshot should be taken.

- Thread Details: You can specify if the thread details need be included in the snapshot.

- Try Changing Threads: Sometimes the stack associated with the thread may change rapidly which makes taking the snapshot difficult. If you select this parameter, you can suspend the thread and take the snapshot.

- Include Network Waits: Specify if network wait threads need to be included in the snapshot.

- All Threads: Specify if all threads (active and idle) must be included in the snapshot.

- Allow Trace Interrupt: Indicate whether the trace process can be interrupted.

- Mark Idle: Select a thread from the list and click Actions > Mark Idle to mark a thread as idle.

- Mark Active: If you selected the Show Idle Threads check box, a list of idle threads are displayed. Select a thread and click Actions > Mark Active to mark it as an active thread.

- Show Idle Threads: Select this check box to list only the idle threads in the JVM Threads table.

- Export: Click Export to export the thread details to an Excel file.

- Thread Info: This section shows the detailed information for a selected thread. Details of thread including Current Call, Request, ECID, State, Waiting On, and Wait Request are displayed. If the thread is in the DB Wait State, click on the link to drill down to the Database Home page. See Section 10.5.4.1, "Cross Tier Analysis" for more details.

- Thread Stack: The Thread Stack table shows the details of the selected thread such as the depth of the thread, methods used in the thread, file where the method is used, and the line number. You can drill down from the method level to a lower level. Select a method from the table and click Browse Local Objects. A popup window is displayed which shows the local variables, objects, their classes, and values.You can export these details to a file by clicking Export. You are prompted to specify the directory in which the file is to be stored. Enter the path and click Save to save file in .csv format.

10.5.4.1 Cross Tier Analysis

You can trace any JVM activity from the JVM thread to the database. You can view cross tier correlation for live threads and historical monitored data.

Before you establish cross tier correlation, ensure that the database is an Enterprise Manager target and has been registered with JVM Diagnostics. To register the database, select the Middleware Diagnostics option from the Setup menu, then click Setup JVM Diagnostics in the Middleware Diagnostics page. Click on the Register Databases tab. The list of registered database targets are displayed.

Figure 10-8 JVM Diagnostics Setup

If the JVMD Agent Required field has a No value, you can proceed with the cross tier analysis. If the field has an Yes value, you must ensure that the root user or the same OS user who started the database must be running the JVM Diagnostics Database Agent on the target database machine. If the JVMD Agent Required field has a Status Unavailable value, you cannot perform cross tier analysis as the JDBC connection to the database cannot be established.

To view the cross tier correlation for live threads, follow these steps:

1. From the Targets menu, select Middleware, then click on a Java Virtual Machine target. Select the Live Thread Analysis option from the Java Virtual Machine menu. See Figure 10-4.

2. In the JVM Threads column, select a thread with a DB Wait State.

3. The thread details are displayed in the Thread Info section. If cross tier correlation has been established, you can see SID=<value>"SERIALNUM=<value> when you hover over the State field. Click the DB Wait link.

4. The Database Details popup is displayed which shows the host, port, SID, user, and JDBC URL for the target database. Click the Register All DB Targets link to register all database targets with JVM Diagnostics and refresh the Live Thread Analysis page.
Oracle Database 11g Release 2 supports special cross tier requirements for JVM Diagnostics and cross tier correlation is automatically established when you click the Register All DB Targets link. If you are using an earlier Oracle Database version, the registration process prompts you to run the JVM Diagnostics Agent on the host machine.

5. Click View Register Databases to navigate to the Registered Databases page where you can manually register the database target with JVM Diagnostics and check the value in the DB Agent Required column. Click Add, to add a database instance or a custom database. If you register a database as a custom database, the DB Name is displayed in the Waiting field in the Threads Info section but the cross tier correlation cannot be established.

To view the cross tier correlation for historical monitored data, follow these steps:

1. From the Targets menu, select Middleware, then click on a Java Virtual Machine target. Select the JVM Performance Diagnostics option from the Java Virtual Machine menu.

2. The three tables Top Databases, Top SQLS, and Top DBWait Events related to the cross tier are displayed. The Top Databases table shows the top databases in which JVM or JVMs in the pool have activities. The Top DBWait Events table shows the top DB Wait events caused by the JVM threads in the database. The Top SQLs table shows the top SQLs executed by the JVM threads in the database. Click the top field of a table to launch a popup which shows the names of the database on which activity was performed.

3. Click the Database Name link to drill down to the Database Diagnostics page which shows the corresponding database activity.

4. Click the Top SQLs and Top DBWait Events links to navigate to the SQL Details page and the ASH Viewer page of database diagnostics.

If cross tier correlation has been established, you can view JVM Diagnostics activities for a database (drilling up from Database Diagnostics to JVM Diagnostics). Click the JVM Diagnostics link in the Performance page to drill up to the JVM Performance Diagnostics page. Data relevant to the time interval, database and other filters is displayed.

10.5.4.2 JVM Diagnostics - Oracle Real Application Cluster Drill-Down

Oracle Real Application Cluster (Oracle RAC) databases have a complex configuration of database instances and listeners. User applications use Oracle RAC services to connect to the database instead of SIDs that are used for single instance databases. User applications connect to Oracle RAC listeners that are listening on different machines than the actual database instances. In JVM Diagnostics, cross tier correlation is established automatically for Oracle RAC databases.

Cross tier correlation cannot be established if the listener is not registered in Enterprise Manager. In this scenario, you can establish cross tier correlation by using either of the following options:

- If you know the database instance that which your application is being connected, add the details of the listener as a property for any database instance in that Oracle RAC. Before you add the listener, you must ensure that it is registered in JVM Diagnostics. For example, to add the jvmd_db_listeners_additional_info property to the database instance, follow these steps:

- Insert into mgmt_target_properties (TARGET_GUID, PROPERTY_NAME, PROPERTY_VALUE) values ((select target_guid from mgmt_targets where target_name='<DB Instance Name>'), jvmd_db_listeners_additional_info','LISTENER_adc2110865.us.oracle.com:adc2110865-v.us.oracle.com:10.232.132.249:1521')

- Remove the database instance target (DB_INSTANCE_NAME) that was specified in the query.

- Ensure that there are no custom databases registered for any of the database target instances which are in Oracle RAC.

- Register a custom database with the same name and SID as the Database Instance. The host, port and service must be the same as the one used in the connect string.

10.5.5 Viewing the JVM Live Heap Analysis Page

This page shows the real time organization of all objects in the JVM Heap. To view this page, select Middleware from the Targets menu and click on a JVM Pool target. Select the Live Heap Analysis option from the Java Virtual Machine menu.

If the JVM is running at Optimization Level 0, the following details are displayed:

- Pie Charts and Bar Charts that show the percentage utilization of the entire heap (free versus used)

- Major and Minor Garbage Collections Count

- Options to take snapshots of active threads or a specific thread.

- JVM Class Details table that displays all the classes in the JVM Heap in decreasing order of their size (in KB). You can export this data to an .xls file using the Export option.

Note:
For JVMs running at optimization level, the following details are displayed:

- JVM Heap Memory Usage table where the usage (in KB) in various heap spaces.

- JVM Heap Number of Objects table which displays the number of objects in various heap spaces.

Figure 10-9 JVM Live Heap Analysis Page

The following details are displayed:

- Garbage Collections: The number of objects that have been added to the garbage collection. The type of garbage collection i.e. minor or major, and the number of garbage collections of a particular type is displayed.

- JVM Class Details: This table provides a summary of the heap usage by different types of objects in the heap.

- Space name: The name of the space within the JVM heap.

- Class: The memory usage by classes in a heap space (in KB).

- Instance: The number of heap objects for number of instances of classes in a heap space.

- Size: The size of the JVM heap.

Click Create Heap Snapshot to take a heap snapshot. See Section 10.7.2, "Taking a Heap Snapshot" for details. Click Export to Excel to export the live heap data an Excel file.

10.6 Viewing the Thread Snapshots

This page lists all the traces that have been loaded into the repository using the Trace Active Threads option. The Thread column indicates if all active threads or a specific thread has been traced. The number of samples taken during the trace are displayed. Select a thread and click the Details link to drill down to the Diagnostic Image Analysis page. Click the Upload link to take a thread snapshot of active threads.

10.6.1 Uploading Thread Snapshots

You can upload thread snapshots to a file and view the data at a later date. You can upload a thread snapshot from the client machine to the OMS. Click the Thread Snapshots link from the JVM Pool menu. Click the Upload link in the Thread Snapshots page. The Uploading Thread Snapshots page is displayed.

Figure 10-10 Uploading Thread Snapshots

When you run the Trace Threads option, you can save the trace file in your local machine or on the OMS. To upload the trace file from the:

- Thread Snapshot Path: Click Modify and specify the location of the diagnostic snapshots on the OMS.

- Thread Snapshot File: Click Browse to select the Trace Diagnostic Image File and click Start Upload.

The list of thread snapshots is displayed. Select a file and click the Load icon to load the thread snapshot to the database. A message indicating that the trace file has been loaded successfully is displayed. Click the Loaded Successfully, Goto Saved Trace link to view the Diagnostic Image Analysis page.

10.7 Analyzing Heap Snapshots

The JVM Diagnostics memory analysis feature allows you to not only find the objects responsible for the growth but also track their reachability from the root-set. With this feature, you can find the dangling reference responsible for memory leaks.To find a memory leak, you take snapshots of the JVM heap at different points in time. Between the snapshots, your JVM and Java applications continue running at full speed with zero overhead.

A heap snapshot is a snapshot of JVM memory. Each snapshot stores information about the objects in the heap, their relationships and root-set reachability. You can load the snapshots into the repository, and compare them to see where the memory growth has occurred. Click Heap Snapshots from the menu in the JVM Pool or JVM Home page.

Figure 10-11 Available Heap Snapshots

The list of available heaps is displayed with the following details:

- Date: The date on which the heap snapshot was taken.

- JVM Name: The server on which the JVM is running.

- Vendor: The name of the JVM Vendor.

- Size: The total size of the Java heap. An adequate heap size helps improve the performance of the application.

- Used: The amount of heap that has already been used.

- %: The percentage of heap used.

Select a heap from the list and click Details. The Heap Root and Usage page is displayed.

10.7.1 Viewing the Available Heap Snapshots

The JVM Diagnostics memory analysis feature allows you to not only find the objects responsible for the growth but also track their reachability from the root-set. With this feature, you can find the dangling reference responsible for memory leaks.To find a memory leak, you take snapshots of the JVM heap at different points in time. Between the snapshots, your JVM and Java applications continue running at full speed with zero overhead.A heap snapshot is a snapshot of JVM memory. Each snapshot stores information about the objects in the heap, their relationships and root-set reachability. You can load the snapshots into the repository, and compare them to see where the memory growth has occurred.

To view and analyze the heap usage, click the Heap Snapshots option from the JVM Pool menu. The list of available heaps with the JVM Name, vendor, size and other details is displayed.

Figure 10-12 Available Heap Snapshots

Select a heap snapshot and click the Detail link to drill down to the Roots page.

10.7.1.1 Viewing Heap Usage by Roots

To view the heap usage by each class of root, follow these steps:

1. From the Targets menu, select Middleware, then click on a Java Virtual Machine or a Java Virtual Machine Pool target.

2. Select Heap Snapshots option from the Java Virtual Machine or Java Virtual Machine Pool target.

3. The list of available heaps is displayed.

Figure 10-13 Heap Usage

Click on the Heap Details tab to view the number of objects and memory reachable from each root. Click on the Root link to view the objects directly reachable from the root. The following details are displayed:

- Root: The name of the root is displayed here. Click on the name to drill down to the Top 40 Objects page.

- Object: The total number of objects reachable from this root.

- KB: The total amount of memory reachable from this root.

- Adj: The adjusted memory reachable from this root. This parameter is useful in tracking the memory leak hot-spots.

10.7.1.2 Top 40 Objects

This page shows the top 40 objects reachable from a root. The objects are sorted in descending order by the ascending memory reachable from the object (or the difference of the adjusted memory reachable when comparing two heaps). This view provides a lot of rich detailed information like the amount of memory used by an object, amount of memory reachable by an object (total memory used by all the children), and number of objects reachable from a given object.

Figure 10-14 Top 40 Objects

The following details are displayed:

- Signature: The signature of the object. Click on the link to drill down to the Details page.

- Root: This is the internal root identifier.

- Type: The type of the object which can be Klass, Instance, Method, and so on.

- Space: The heap space in which the object is present.

- Bytes: The amount of space used by the object.

- Len: If the object is an array, the length of the array is displayed here.

- Children: The number of descendants reachable from the object.

- Adj: Adjusted memory reachable from this object.

- Depth: Indicates how far this object is from the root.

10.7.1.3 Heap Object Information

This page shows information about a specific object in the heap snapshot. The following details are displayed:

Figure 10-15 Heap Object Information

- Heap Object Information

- Gar: Indicates whether this object is garbage or reachable from the root.

- Space: The heap space in which the object is present.

- Type: The type of the object which can be Klass, Instance, Method, and so on.

- Signature: The signature of the object.

- Bytes: The amount of space used by the object.

- Len: If the object is an array, the length of the array is displayed here.

- Children: The number of descendants reachable from the object.

- Adj: Adjusted memory reachable from this object.

- Depth: Indicates how far this object is from the root.

- Roots

- Type: The type of root which can be Klass, Instance, Method, and so on.

- Field: If the root is a local thread, this field contains information about the thread and method.

- Object Children

- Gar: Indicates whether this child is garbage or reachable from the root.

- Space: The heap space in which the child is present.

- Type: The type of the child which can be Klass, Instance, Method, and so on.

- Signature: The signature of the child. Click on the link to drill down to the Details page.

- Bytes: The amount of space used by the child.

- Len: If the child is an array, the length of the array is displayed here.

- Children: The number of descendants reachable from the child.

- Adj: Adjusted memory reachable from this child.

- Depth: Indicates how far this child is from the root.

- Object Parents

- Gar: Indicates whether this parent is garbage or reachable from the root.

- Space: The heap space in which the parent is present.

- Type: The type of the parent which can be Klass, Instance, Method, and so on.

- Signature: The signature of the parent. Click on the link to drill down to the Details page.

- Bytes: The amount of space used by the parent.

- Len: If the parent is an array, the length of the array is displayed here.

- Children: The number of descendants reachable from the parent.

- Adj: Adjusted memory reachable from this parent.

- Depth: Indicates how far this parent is from the root.

10.7.1.4 Comparing Heap Snapshots

To find a memory leak, you can take snapshots of the JVM Heap at different points in time. Each snapshot stores information about the objects in the heap, their relationships and root-set reachability. You can compare two heap snapshots to see where the memory growth has occurred.

1. From the Targets menu, select Middleware, then click on a JVM or JVM Pool target.

2. Select Heap Snapshots option from the Java Virtual Machine or Java Virtual Machine Pool menu.

3. The list of available heaps is displayed. Click the Compare Heaps tab. The first heap in the list is selected for comparison and you are prompted to select the second heap.

4. The two heaps are compared and a comparison table is displayed in the Diff Heaps page. The details of each heap with the following details are displayed:

- Objects: The total number of objects reachable from the root.

- KB: The total amount of memory reachable from the root.

- Adj: The adjusted memory reachable from this root. This parameter is useful in tracking the memory leak hot-spots. It provides a better representation of the memory used by an object by ignoring backwards pointing references from child objects to their respective parent object.

- Delta: The difference in the total memory and adjusted reachable memory of the two heaps that are being compared.

5. Click on the root-set with the most growth to diagnose the memory leak.

6. Click the View Summary button to see a bottom up view of memory reachable by class of objects.

10.7.2 Taking a Heap Snapshot

A heap snapshot is a snapshot of JVM memory. It shows a view of all objects in the JVM along with the references between those objects. It can be used to study memory usage patterns and detect possible memory leaks. To take a heap snapshot, follow these steps:

1. From the Targets menu, select Middleware, then click on a JVM target. The JVM Home page is displayed.

2. Select the Heap Snapshots option from the Java Virtual Machine menu.

3. The list of available heaps is displayed. Click Create in the Available Heaps page.

4. The Heap Snapshot page is displayed.

Figure 10-16 Heap Snapshot Page

You can use the following options to take a heap snapshot:

- Taking A Heap Snapshot Only: Choose this option to take a heap snapshot and load it manually to repository using the loadheap script.

- Taking a Heap Snapshot And Loading Into Repository: Choose this option to take a snapshot and automatically load it to the repository.

10.7.2.1 Taking A Heap Snapshot Only

To take a heap snapshot and load it manually into the repository using the loadheap script, follow these steps:

1. Select the Heap Snapshot Only option.

2. Select the Heap Snapshot Type which can either of the following:

- JVMD Format (txt) for analysis in JVMD

- HPROF Forma (binary) for analysis with external tools

3. Click Take Snapshot. The heap snapshot is generated and the file name in which it is stored is displayed. You can upload the heap snapshot and analyze it using appropriate options from the Heap Snapshots menu.

10.7.2.2 Taking a Heap Snapshot And Loading Into Repository

Select this option to take a heap snapshot and automatically load it into the repository.

Prerequisites

- The Management Agent must be deployed on the host machine on which the JVM target is running.

- The Heap Loader Host is a standalone machine (with high CPU and Memory) on which the Management Agent has been deployed.

- DB Client Home which is the location of ORACLE_HOME where sqlldr & sqllplus are present.

- There should be sufficient disk space in the system temp directory.

- A JVM Diagnostics DB User must have been created using the create_jvm_diagnostic_db_user script.

To take a heap snapshot and load it into the repository, follow these steps:

1. Select the Heap Snapshot and Load Into Repository option. You can select this option if the Management Agent is running on the JVM Diagnostics Agent and the Heap Loader Host.

2. If the Heap Loader Host has not been configured, click Add. Specify the Heap Loader Name, DB Client Home (the ORACLE_HOME (full absolute path) on the Heap Loader Host where sqlldr and sqlplus are present), and the Heap Loader Host and click Save.

3. If the Heap Loader Host has already been configured, the Available Heap Loaders are displayed. Select a heap loader from the list and enter the Host, DB User, and JVM Diagnostics Agent credentials.

Note:

- If preferred credentials for JVM Target & Heap Loader host are set, then the Enter Credentials region will not be displayed.

- If the Named Credentials for the JVM Diagnostics DB User is set, the Enter Credentials region will not be displayed.

4. Enter the schedule for the heap snapshot and click Take Snapshot. The heap snapshot is generated and loaded into the repository.

10.8 Tracing Active Threads

If a particular request is slow or hanging or if the entire application is slow, you can run the real-time transaction trace to view current Java application activity. You can look at the offending threads and their execution stack and analyze how much time a thread spent in waiting for DB wait or wait on a lock. Complex problems such as activity in one thread (or request) affecting the activity in the other thread or rest of the JVM can be found very quickly.

You can trace all active threads and generate a trace file which contains details such as resource usage, thread states, call stack information etc. During tracing, the state and stack of the target thread is sampled at set intervals for the desired duration. Follow these steps to trace active threads:

1. From the Targets menu, select Middleware, then select a Java Virtual Machine target.

2. Select the Thread Snapshots option from the Java Virtual Machine menu, then click Create.

3. In the Trace Active Threads page, specify the time interval between successive samples and the duration of the trace. Optionally, you can select the following parameters:

- Trace Thread Details: If this box is unchecked, only the last user call for the active thread will be stored. If the box is checked, all calls for the active thread will be stored, so you can view the call stack. Checking the box increases the overhead and space requirements

- Try Changing Threads: If a thread stack changes during a sample (this can happen when a thread is using CPU), JVM Diagnostics will skip that thread for that sample. If you find missing samples, use this feature to retrace the changed stacks. This will retry (up to 5 times) threads with changing stacks. It will also make system calls to get the stack if possible.

- Include Network Waits: Most JVMs have large number of idle threads waiting for network events. If you leave this check box unchecked, idle threads will not be included in the trace. Checking this box increases the overhead and space requirements.

- Trace All Threads: Check this box if both idle and active threads will be included in the trace.

- Allow Trace Interrupt: Allows you to interrupt the trace process.

4. Click Start Trace to generate the trace file. When the trace has been completed successfully, click Goto Saved Trace link to view the trace data. The Diagnostic Image Analysis page has the following details:

- JVM Trace Results: This table provides information about when and where the trace was run. It also shows any filters which have been applied to the results of tracing. Most of the filters are applied by clicking the appropriate link from the tables below. The only exception is the JVM State filter which is applied from here by selecting from the drop-down.

- Resource Usage: This section shows the system activities such as CPU utilization, heap usage, and garbage collection during tracing.

- Top States: This chart shows the JVM Trace Analysis for the duration of the trace. Click DB Wait to view the DB activity.

- Top Methods: This section shows a pie-chart of the top methods for the duration of the trace. It shows the name of the method and the number of samples.

- Threads by State: This table shows the state time line for each thread colored by the state activity. It shows the number of samples in each state for each thread. Click on a thread to drill down to the Thread Details page.

- Requests by State: This table shows the number of samples in each state for each request. Click on a request to view activity only for that request

- Methods by State: This table shows number of samples in each state for each method. Click on a method to view activity only for that method.

10.9 Uploading Trace Diagnostics Images

You can upload trace data and heap data to a file and view it at a later date.

Uploading Trace Data

This file can be uploaded and stored on the OMS or on the database. To upload trace data (trace diagnostic image), follow these steps:

1. From the Targets menu, select Middleware, then click on a Java Virtual Machine Pool or a Java Virtual Machine target.

2. Select the Thread Snapshots option from the Java Virtual Machine Pool or Java Virtual Machine menu. The list of available thread snapshots is displayed.

3. Click Upload. The Upload Trace Diagnostic Images page is displayed.

4. When you run the Trace Threads option, the trace file is saved on your local machine or on the OMS. To upload the trace file:

- Thread Snapshot Path: Click Modify and specify the location of the diagnostic snapshots on the OMS.

- Thread Snapshot File: Click Browse to select the Trace Diagnostic Image File and click Start Upload.

5. The list of trace files present on the specified location on the OMS are displayed. Select a file and click the Load icon to load the trace file to the database.

6. A message indicating that the trace file has been loaded successfully is displayed. Click the Loaded Successfully, Goto Saved Trace link to view the Diagnostic Image Analysis page or click Ignore to remain on the same page.

Uploading Heap Data

A heap snapshot is a snapshot of JVM memory. It shows a view of all objects in the JVM along with the references between those objects. You can upload these heap snapshots into the repository and analyze them to detect memory leaks. To upload a heap snapshot, follow these steps:

1. From the Targets menu, select Middleware, then click on a Java Virtual Machine target.

2. Select the Heap Snapshots option from the Java Virtual Machine menu. The list of available heap snapshots is displayed.

3. Click Upload. The Upload Trace Diagnostic Image page is displayed.

4. When you run the Take Heap Snapshot option, the heap snapshot is saved on your local machine or on the OMS. To upload the heap snapshot:

- Thread Snapshot Path: Click Modify and specify the location of the diagnostic snapshots on the OMS.

- Thread Snapshot File: Click Browse to select the Trace Diagnostic Image File and click Start Upload.

5. The list of heap snapshots present on the specified location on the OMS are displayed. Select a file and click the Load icon to load the heap snapshot to the database.

6. A message indicating that the heap snapshot has been loaded successfully is displayed. Click the Loaded Successfully, Goto Saved Snapshot link or click Ignore to remain on the same page.

7. The Diagnostic Image Analysis page is displayed. Click Description to view details of the heap snapshot being analyzed. The following Server State charts are displayed:
The following details are displayed:

- Garbage Collections: The number of objects that have been added to the garbage collection.

- JVM Heap Memory Usage: This table provides a summary of the heap usage by different types of objects in the heap.

- JVM Heap No of Objects: This table provides details of all the objects in the heap.

8. Click Change / Manage Heap Snapshots. A list of available heap snapshots for the JVM is displayed.

9. Select a heap snapshot file and click Analyze to view the Diagnostic Image Analysis page.

10.10 Viewing the Available Traces

This page lists all the traces that have been loaded into the repository. To view a list of all the available traces, follow these steps:

1. From the Targets menu, select Middleware, then click on a Java Virtual Machine Pool or Java Virtual Machine target. The Home page for the target is displayed.

2. Select the Thread Snapshots option from the Java Virtual Machine Pool or Java Virtual Machine menu.

3. The list of traces that have been loaded are displayed. The Trace ID, the date, the JVM Name is displayed. The Thread column indicates if all threads or only active threads have been traced.

4. Select a thread from the list and click Details. The Diagnostic Image Analysis page with the detailed analysis of the trace file is displayed.

10.11 Analyzing Trace Diagnostic Images

A trace diagnostic image contains details such as resource usage, thread states, call stack information etc. The trace diagnostic image captures thread data at short intervals. If an application is hanging or is slow, you can analyze these threads and find out the application tier that causing the delay.

On the Diagnostic Image Analysis page, you can:

- Click Description to view details of the thread snapshot being analyzed. The following Server State charts are displayed:

- Active Threads by State: This chart shows the status of all threads in the JVM. The threads can be in different states like RMI, IO, NET, DB, CPU, and LOCK.

- CPU Utilization by JVM: This chart shows the CPU utilization in the JVM.

- Heap Utilization by JVM: This chart shows the heap utilization in the JVM.

- You can filter the data that is displayed by specifying various criteria such as Method Name, JVM Name, Thread State, DBState, and so on. Check the Ignore Filters check box if you want to ignore the specified filters. The Active Threads by State, Top Requests, Top Methods, Top SQLs, Top DBWait Events, and Top Databases charts are displayed.

- Click on the Threads tab to view the Thread State Transition, Metric By Active States, and Method data.

- Click Change / Manage Traces. A list of available trace files for the JVM Pool is displayed in the List of Traces Loaded page. The following details are displayed:

- Trace ID: The port number for the JVM.

- Date: The date and time the trace was run.

- JVM Name: The name of the host on which the JVM is running.

- Thread: Indicates whether the trace was run for a specific thread or all active threads.

- Seconds: The trace duration in seconds.

- Samples: The number of samples in the trace.

- Select a trace file and click Analyze. The trace details are displayed in the Diagnostic Image Analysis page.

- Click Offline Diagnostics to create a diagnostic snapshot.

10.12 JVM Offline Diagnostics

Diagnostic data for one or JVM targets can be collected for a specific period and analyzed in an offline mode. This section describes the various options that are available to collect live JVM data and analyze it in offline mode. It contains the following sections:

- Creating a Diagnostic Snapshot

- Using the Diagnostics Snapshot Page

- Analyzing a Diagnostics Snapshot

- Viewing a Diagnostics Snapshot

10.12.1 Creating a Diagnostic Snapshot

You can create diagnostic snapshots for one or more JVM targets for a specified period. To create a diagnostic snapshot, specify the following:

1. From the Targets menu, select Middleware.

2. Select the Manage Diagnostic Snapshots option from the Middleware Features menu.
The Create Diagnostic Snapshot option is also available in the JVM Performance Diagnostics page. Navigate the Performance Diagnostics page for a JVM, specify the time range for which you want to create the collection and click Create Diagnostic Snapshot.

3. Click Create in the Diagnostic Snapshots page. You can navigate to this page by clicking Offline Diagnostics on the Diagnostic Image Analysis page.

4. Enter a name and description for the diagnostic snapshot.

5. Specify the duration for the diagnostic snapshot.

6. Click Add. Select one or more JVM targets for which the diagnostic data is to be collected.

Note:
The JVM targets that you select must belong to the same JVM Pool.

7. Select the diagnostic types for the selected target and click OK. You will see a pop-up window that indicates that the diagnostic snapshot is being created. Click Close after the diagnostic snapshot has been created. You will return to the Diagnostic Snapshots page.

10.12.2 Using the Diagnostic Snapshots Page

You can collect diagnostic data for one or more JVM targets and analyze them in an offline mode. This page shows the list of diagnostic snapshots that have been created. You can specify search criteria to retrieve a specific snapshot. You can do the following:

- Create: Click Create to create diagnostic snapshots for one or more JVMs. The Create Diagnostic Snapshot page is displayed.

- Export: Select a file and click Export to export the diagnostic data to a file. Enter the location in which the file is to be stored. You can review and analyze the saved file in an offline mode on the same or a different host machine.

- Import: Click Import to import an exported file with diagnostic data for a particular collection object. Specify the name of the file and upload the file from your system. You can analyze the exported file and view a summary of the diagnostic snapshot.

- Analyze: Select a file and click Analyze. The Analyze Diagnostic Snapshot page is displayed.

- Delete: Select a diagnostic snapshot from the list and click Delete. A confirmation message is displayed. Click OK to delete the diagnostic snapshot.

- View: Select a file and click View. The View Diagnostic Snapshot page is displayed.

10.12.3 Analyzing a Diagnostic Snapshot

This page displays the summary details of the diagnostic snapshot and a summary of all the diagnostic types of the diagnostic snapshot. You can view the thread stack, thread states, CPU Utilization, Heap Utilization, Active Threads Graphs, and Garbage Collections.

To analyze a diagnostic snapshot, follow these steps:

1. From the Targets menu, select Middleware.

2. Select the Manage Diagnostic Snapshots option from the Middleware Features menu.

3. In the Diagnostic Snapshots page, select a snapshot from the list and click Analyze.

4. You can analyze details for each JVM for the specified time interval. Click More Details to view detailed diagnostics information for the JVM. The Diagnostic Image Analysis page is displayed.

10.12.4 Viewing a Diagnostic Snapshot

This page displays the summary of the targets, target types and the diagnostic information collected.

1. From the Targets menu, select Middleware.

2. Select the Manage Diagnostic Snapshots option from the Middleware Features menu.

3. In the Diagnostic Snapshots page, select a snapshot from the list and click View.

4. The summary details for the selected JVM target, target types, and the diagnostic information collected for the JVM is displayed.

10.13 Viewing JVM Diagnostics Threshold Violations

An event is a discrete occurrence detected by Enterprise Manager related to one or more managed entities at a particular point in time which may indicate normal or problematic behavior. Examples of events include: a database target going down, performance threshold violation, change in application configuration files, successful completion of job execution, or job failure.

JVM Diagnostics threshold violations are now integrated with the Enterprise Manager Event subsystem. When a threshold violation occurs, an Enterprise Manager event is generated. To view the event, follow these steps:

1. From the Enterprise menu, select Monitoring, then select Incident Manager.

2. In the View panel, click Events without Incidents. The JVM Diagnostics events are displayed if there are any outstanding JVMD threshold violations.

Figure 10-17 Incident Manager: Events without Incidents

3. Click on the link in the Target Name column of a JVM Diagnostics Event.
The JVMD threshold violations will show up in the Incidents table of the JVM or JVM Pool Home page only if the events have been promoted to incidents. For more information on promoting events to incidents, see the Enterprise Manager Administration Guide.

11 Troubleshooting JVM Diagnostics

This chapter describes the errors you may encounter while deploying and using JVM Diagnostics and the workaround steps you can follow to resolve each of them. It contains the following sections:

- Cross Tier Functionality Errors

- Trace Errors

- Deployment Script Execution Errors

- LoadHeap Errors

- Errors on JVM Diagnostics UI Pages

- Frequently Asked Questions

11.1 Cross Tier Functionality Errors

This section lists the errors that show the status of the JVM Diagnostics Manager.

Table 11-1 Cross Tier Functionality Errors

Error Message

Workaround Steps

DBWait link not displayed on JVM Threads Real
Time Analysis page.

No data displayed in Top DBStates / SQLs tables.

Cross tier functionality errors may occur due the following:

- Incorrect database credentials

- Database Agent errors

If the database credentials are incorrect:

- From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Middleware Diagnostics page. Click on the Register Databases tab and verify the credentials for the registered database to be monitored.

- Enter the id of user who has installed the database in the OS User field.

- Specify the database application user credentials in the DB User field.

- Specify the database system user credentials in the DB User (Explain Plan) field.

If database agent errors occur, ensure that the database agent is running on a machine on which the database is installed with the correct IP address and port number.

- Select the Live Thread Analysis option from the Java Virtual Machine menu. If you see a thread that is in the DB Wait state, it should be a hyperlink. Click on the hyperlink to drill down to the database details and view the database session information including the SQL statements executed.

- If the DB Wait state is not a hyperlink, from the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Middleware Diagnostics page. Set the Cross Tier Log Level to 6 and send JVMD Manager logs report issue.

11.2 Trace Errors

This section lists errors that occur during tracing.

Table 11-2 Trace Errors

Error Message

Workaround Steps

weblogic.transaction.internal.TimedOutException:
Transaction timed out after 30 seconds

This error occurs if the Poll Duration has a large value and results in a timeout.

This error does not affect the Trace functionality and can be ignored.

11.3 Deployment Script Execution Errors

This section lists the errors that occur when you run the deployment script.

Table 11-3 Script Execution Errors

Error Message

Workaround Steps

ScriptException: Error occured while performing
deploy: The action you performed timed out after
600,000 milliseconds

This error occurs when you are deploying the JVM Diagnostics Agent. To resolve this issue, check if the lock for the target WebLogic domain Administration Console has already been acquired. If it has been acquired, release it and run the script again.

- Login to the WebLogic Administration Console: http://<machine address>:<webogic port>/console.

- If you see the Activate Changes and Undo All Changes buttons in the left pane, click on these buttons to clear them. If the buttons are not cleared, click Undo All Changes and run the script again.

11.4 LoadHeap Errors

This section lists loadheap errors.

Table 11-4 LoadHeap Errors

Error Message

Workaround Steps

glibc detected * free(): invalid next size
(fast): 0x0965d090" ./loadheap.sh: line 237:
32357 Aborted ./bin/${bindir}/processlog
in=$infile hdr=${sumdata} obj=${objdata}
rel=${reldata} root=${rootdata}
osum=${objsumdata} rrel=${rootrel} heap=${heap
_id} skip=$skipgarbage db=$dbtype $*
Error processing file /tmp/heapdump6.txt

Check if the heapdump operation has been successfully completed. Open the heapdump6.txt file and check if there is a heapdump finished string at the end of the file. If you see this string, load the finished dump file.

Heapdump already in progress, cannot take another
heapdump

Check if the heapdump operation has been successfully completed. Open the heapdump6.txt file and check if there is a heapdump finished string at the end of the file.

loadheap.sh created unusable unique indexes.

Run the loadheap/sql/cleanup.sql shipped with loadheap.zip to fix the unique indexes.

11.5 Errors on JVM Diagnostics UI Pages

This section lists the user interface errors.

Table 11-5 JVM Diagnostics UI Page Errors

Error Message

Workaround Steps

JAM Console: Socket timed out after recv --
client adc2100083.us.oracle.com:7001 is not
Active [0] secs JAM Console jamlooptimeout =
[3]JAM CONSOLE: JVM 1 is not active JAM Cons Err
Processing Request: 128 JVM 1 is not active
jamDAL: jamreq returned 128 return status < 0
from jamDalInst.processRequest

To resolve this error, increase the Agent Request Timeout (secs) and Agent Loop Request Timeout (secs)

Agent is up and running but is not displayed in
the real time pages.

If the log file shows JAMMANAGER: OLD AGENT or NULL POOl or wrong jamoptimization level, this indicates that the old jamagent/Dbagent is being used.

To resolve this issue, download the latest jamagent from Setup > Download page.

You do not have the necessary privileges to view
this page

Ensure that you have the required JVM Diagnostics Administrator or User privileges to view the JVM Diagnostics data.

11.6 Frequently Asked Questions

This section lists some of the questions you may have while using JVM Diagnostics. It includes the following:

- Location of the JVM Diagnostics Logs

- JVM Diagnostics Manager Status

- JVM Diagnostics Agent Status

- Monitoring Status

- Creating Less Privileged Users

- Usage of Try Changing Threads Parameter

- Significance of Optimization Levels

- Manually Deploying the JVM Diagnostics Agent

- Log Manager Level

- Repository Space Requirements

11.6.1 Location of the JVM Diagnostics Logs

You can find the JVM Diagnostics logs in the following locations:

- The JVM Diagnostics Manager Log file is located at $EMGC_JVMDMANAGER1/logs/EMGC_JVMDMANAGER1.out

- UI related errors are logged in:

- $T_WORK/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.out

- $T_WORK/gc_inst/user_projects/domains/GCDomain/servers/EMGC_OMS1/logs/EMGC_OMS1.log

- Communication errors between the JVM Diagnostics Manager and the Console are logged in $T_WORK/gc_inst/em/EMGC_OMS1/sysman/log/emoms.log

11.6.2 JVM Diagnostics Manager Status

To check the status of the JVM Diagnostics Manager:

- From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics.

- Check the JVM Diagnostics Agent log file to verify the connection between Agent and the Manager. If you see an error - JAM Agent ERROR: Cannot connect to Console:Connection refused, this indicates that the JVM Diagnostics Manager is not running.

- Check if the message JAM Console: Agent connection from:[Hostname] is present in the JVM Diagnostics Manager log file. If this message appears, it indicates that the JVM Diagnostics Manager is running and is connected to the Agent.

11.6.3 JVM Diagnostics Agent Status

To check the status of the JVM Diagnostics Agent:

- From the Targets menu, select Middleware, then click on a Java Virtual Machine target. Select the Live Thread Analysis option from the Java Virtual Machine menu. Check the JVM Status in the Connected JVMs table.

- If the status is Not Active, this indicates that the Agent is not connected to the Manager. Check the agent logs to verify if it is running and the IP address and port number of the Manager is correct.

- If the status is No AD4J Agent Deployed, the JVM Diagnostics Agent must be deployed on that JVM.

- If the JVM Diagnostics Agent is running, the active threads data must be visible. If the JVM Diagnostics Agent is not running, you will see a message - JVM is inactive, Please try again after some time.

11.6.4 Monitoring Status

To verify if the JVM Diagnostics Manager is monitoring the data:

1. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics in the Middleware Diagnostics page. In the JVMD Configuration page, verify that the Enable Monitoring check box is checked.

2. Navigate to the Monitoring page under Setup and check if monitoring status is On for the Pool to which the JVM being monitored belongs.

3. Navigate to the JVM Pools page under Setup and verify if the Poll Enabled check box has been checked for the Pool to which the JVM being monitored belongs. Monitoring should now be enabled.

11.6.5 Running the create_jvm_diagnostic_db_user.sh Script

You can run the create_jvm_diagnostic_db_user.sh script if you want to create less privileged users who can only load heaps using the loadHeap script.

11.6.6 Usage of the Try Changing Threads Parameter

This parameter should be used only when the JVM is highly active.

11.6.7 Significance of Optimization Levels

The JVM Diagnostics Agent supports three optimization levels:

- Level 0 indicates that the JVM Diagnostics Agent is using a JVMTI based engine. This level is supported for JDK 6 series on almost all supported platforms.

- Level 1 is a hybrid between level 0 and level 2. It is supported only for very few JDKs on selected platforms.

- Level 2 uses Runtime Object Analysis technique for monitoring as it is efficient at run time.

11.6.8 Custom Provisioning Agent Deployment

You can customize the JVMD Agent deployment in the production environment by running custom provisioning scripts.

After the OMS has been installed, the jvmd.zip file can be found in the plugins/oracle.sysman.emas.oms.plugin_12.1.0.0.0 directory in the Middleware installation directory. The zip file contains a set of scripts in the customprov directory. Details on using these scripts are described in the README.TXT present in the same directory. To use the custom provisioning scripts, follow these steps:

1. From the Setup menu, select Middleware Diagnostics, then click the Setup JVM Diagnostics in the Middleware Diagnostics page. Click the Register Databases tab and download the jamagent.war file

2. Make a copy of the deployment profile that includes the location of the downloaded jamagent.war, domains, and server details.

3. Run the Perl script on the deployment profile which will deploy the JVMD Agent to all the specified servers.

11.6.9 Log Manager Level

The default log manager level is 3. You can temporarily increase this to a higher level if you encounter some issues. Log levels 1 to 5 are supported where:

- 1 - Error

- 2 - Warning

- 3 - Info

- 4 - Debug

- 5 - Trace

11.6.10 Repository Space Requirements

For monitoring data, Oracle recommends 50 MB per JVM per day with the default setting of a 24 hour purge interval. This amount can vary based upon runtime factors (e.g depth of call stacks, etc.) within your environment. Hence, you must check the tablespace growth periodically and if required, you may need to change the space requirements. This will ensure that database growth due to standard monitoring will occur smoothly without sudden spikes. Tablespace sizing can be affected by the following:

- Heap Dumps: Analyzing heaps requires a large amount of tablespace. As a standard practice, we recommend that you must have 5 times the size of heap dump file being loaded in your tablespace. Since you know the size of your dump file, make sure that there is adequate space to accommodate the dump file before it is loaded into the database.

- Thread Traces: While these are smaller than heaps. they are loaded into the database automatically when a user initiates a trace at the console. The size of these threads can vary dramatically depending on the number of active threads during the trace, the duration of the trace, and the sample interval of the trace. This should usually be under 100MB but if several thread traces have been initiated, it could fill up the database quickly. Before initiating the traces, you must ensure that there is adequate space in the database.

Part IV

Managing Oracle Coherence

The chapters in this part contain information on discovering and monitoring a Coherence cluster. It contains the following chapters:

- Chapter 12, "Getting Started with the Oracle Coherence Management Pack"

- Chapter 13, "Monitoring a Coherence Cluster"

12 Getting Started with the Oracle Coherence Management Pack

This chapter describes the procedure to discover and monitor a Coherence cluster using Oracle Enterprise Manager Cloud Control 12c. The following sections are covered in this chapter:

- New Features in this Release

- Supported Versions

- Understanding the Discovery Mechanism

- Enabling the Management Pack

12.1 New Features in this Release

This section lists the new features in Oracle Enterprise Manager Cloud Control 12c. The new features are:

- Cache Data Management: You can view, export, import, insert, update, purge, add, and remove indexes. See Section 13.5, "Cache Data Management" for details.

- Enhanced Target Discovery: You can add clusters, nodes, and cache targets. See Section 12.3.5, "Discovering Coherence Targets" for details.

- Target Deletion: You can now delete specific nodes and caches. The cluster deletion feature has been enhanced. When you delete a cluster, all its associated nodes and caches targets will also be deleted.

- Topology Viewer: You can view the top-down hierarchy of the Coherence nodes, caches, clusters, and their related targets in the Topology Viewer. See Section 13.11, "Viewing Configuration Topology" for details.

- Configuration Metrics Support: You can store Coherence configuration metrics and perform operations like compare configurations, view last collected configurations, search for configuration data, view saved configurations, view configuration history, and the configuration topology. See Section 13.11, "Viewing Configuration Topology" for details.

- Performance Summary and Metric Palette Integration: You can plot charts for critical Coherence cluster component metrics such as node metrics, cache metrics, service metrics, and host metrics. See Section 13.10, "Viewing Performance Summary" for details.

- JVM Diagnostics Support: You can drill down to a Coherence node's JVM to identify the method or thread that is causing a delay. See Section 13.9, "Integration with JVM Diagnostics" for details.

- Log File Alerts: You can set up alerts based on a pattern in a log file. Log files are periodically scanned for the occurrence of desired patterns and an alert is raised when the pattern occurs during a given scan. See Section 13.4, "Log File Monitoring" for details.

- Push Replication: If a push replication enabled cache is present in your cluster, you can now view the Publisher and Subscriber tables. See Section 13.7, "Push Replication Pattern" for details.

- Transaction Cache Support: You can now view specialized distributed caches or transactional caches in a service. See Section 13.8, "Transactional Cache Support" for details.

- Reap Session Support: You can now view then reap session metrics in the Application Home page. See Section 13.6, "Reap Session Support" for support.

- Coherence Provisioning Enhancements: In this release, the Well Known Address and the Update Nodes feature is now available. For more details, see the Enterprise Manager Guide for Provisioning and Patching.

12.2 Supported Versions

Versions 3.4.x, 3.5.x, 3.6.x, and 3.7.0 of Coherence are supported in this release.

12.3 Understanding the Discovery Mechanism

Coherence clusters usually have a large number of nodes that run on multiple hosts. There are several types of nodes such as storage nodes, proxy nodes and management nodes. Each node runs on a JVM process. The management node hosts a JMX MBeanServer and this node is used by Enterprise Manager for discovering and monitoring the coherence cluster. The Oracle Management Agent communicates with the management node to collect metrics and propagate runtime configuration changes.

Note:
The Management Agent can be present either on the same machine on which the coherence management node is running or on a remote machine.

You have to start the management node by setting the following system properties on the storage, proxy, and application nodes:

- -Dtangosol.coherence.management=all

- -Dtangosol.coherence.management.remote=true (If this property is not to set to true, the node cannot be monitored).

For more details on enabling JMX for a Coherence cluster, refer to the Oracle® Coherence Developer's Guide for Oracle Coherence.

12.3.1 Configuring and Starting a Standalone Management Node

You can configure and start the standalone management node in two ways:

- EMIntegration Server: To start the standalone management node, you must start. the oracle.sysman.integration.coherence.EMIntegrationServer. This creates a new management node with a MBeanServer and also registers our bulk operation MBean in this MBeanServer. You can use this approach if you want to dedicate a specific node as a management node and use this exclusively for management. Before you start the EMIntegrationServer, ensure that the coherenceIntg.jar and bulkoperationsmbean.jar files are present in the classpath of the management node. These jar files are located in the AGENT PLUGIN ROOT/archives/coherence/ directory of the Management Agent. For example: emagent/plugins/oracle.sysman.emas.agent.plugin_12.1.0.0.0/archives/coherence/.
Note: These jar files are present only if the Fusion Middleware Monitoring plug-in has been deployed to the Management Agent. See the Fusion Middleware Documentation for details.

You must also set the tangosol.coherence.distributed.localstorage parameter to false so that this management node will not be used for storage. If your Management Agent is on a remote location, you must copy the following files to the machine from which the management node will be started.

$ORACLE_HOME/sysman/jlib/coherenceIntg.jar
$ORACLE_HOME/modules/bulkoperationsmbean.jar

A sample script used to start the management node using the Bulk MBeans is shown below.

CLASSPATH=$COHERENCE_HOME/coherence/lib/coherence.jar
CLASSPATH=$CLASSPATH:coherenceEMIntg.jar:bulkoperationsmbean.jar
$JAVA_HOME/bin/java -cp $CLASSPATH $JVM_OPT $SYS_OPT
oracle.sysman.integration.coherence.EMIntegrationServer >
$COHERENCE_HOME/mgmtnode.log >> $COHERENCE_HOME/mgmtnode.err &

To enable the connection between the Management Agent and the JMX server, you must specify the JMX port by setting the com.sun.management.jmxremote.port=portNum system property while starting the management node of the Coherence cluster.

- Custom-MBeans.XML: If you do not want to dedicate a specific node for management, you can use the custom-mbeans.xml to define the mbeans that need to be registered in the Coherence MBeanServer. The custom-mbeans.xml, the coherenceEMIntg.jar and the bulkoperationsmbean.jar must be present in the classpath of the management node.
Note: This approach works only with Coherence 3.7.0.

A sample xml file is shown here:

<mbeans>
<mbean id="100">
<mbean-class>oracle.sysman.integration.coherence.CacheDataManager
</mbean-class>
<mbean-name>type=Custom,name=CacheDataManager
</mbean-name>
<enabled>true</enabled>
</mbean>
<mbean id="110">
<mbean-class>oracle.as.jmx.framework.bulkoperations.BulkOperationsMBeanImpl
</mbean-class>
<mbean-name>type=BulkOperations</mbean-name>
<enabled>true</enabled>
</mbean>
</mbeans>

12.3.2 Configuring and Starting a Management Node in WebLogic Server

If you are using Coherence Web, Coherence nodes are started when the WebLogic Server is started. To configure and start a management node in WebLogic Server, you must ensure that the Coherence node start options are part of the WLS start script. The values you specify for tangosol.coherence.management and com.sun.management.jmxremote.port parameters are used to identify the location of the CoherenceMBeanServer and how these MBeans can be accessed. You must specify the following options in the WLS start script:

- JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.management=all and JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.management.jmxremote.port=9937
If this option is specified, the Coherence MBeanServer will be started in this node with an explicit port 9937. A separate MBeanServer is then created at this port and all the MBeans will be registered.

- JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.management=all and no explicit value specified for the com.sun.management.jmxremote.port parameter
In this case, if the WebLogic Server is a WLS Administration Server, all Coherence MBeans will be registered in the WLS Domain Runtime MBeanServer. If the WLS Server is a managed server, the Runtime MBeanServer of this server will be used to register all Coherence MBeans. While discovering this Coherence Cluster, you need to specify the correct host, port, or service URL for the MBeanServer.

- JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.management=none
If this option is specified, the MBeanServer will not be started in this node. You can start a standalone management node outside the WebLogic Server.

12.3.3 Starting the Coherence Management Node with Security Credentials

If you use the -Dcom.sun.management.jmxremote.authenticate=true option to start the management node, you must set the User Name and Password in the jmxremote.password file and the Role in the jmxremote.access file.

- Specify the User Name and Password in the $JDK_HOME/jre/lib/management/jmxremote.password file. For example:

Column 1

Column 2

username1

coherence1

username2

coherence2

where Column 1 indicates the User Name and the Column 2 indicates the Password.

- Specify the role of each user in the $JDK_HOME/jre/lib/management/jmxremote.access file. For example:

Column 1

Column 2

username1

read-only

username2

read-write (you must specify this role for the Coherence Management Node.)

where Column 1 indicates the User Name and Column 2 indicates the Role.

Note:
To disable password authentication and SSL, start the JVM with the following properties:
com.sun.management.jmxremote.authenticate=false

com.sun.management.jmxremote.ssl=false

12.3.4 Configuring and Starting a Node With the JVM Diagnostics Agent

JVM Diagnostics allows administrators to identify the root cause of performance problems in the production environment without having to reproduce them in the test or development environment. You can view the JVM Diagnostics data if the JVM Diagnostics Manager and JVM Diagnostics Agent have been deployed on the host machine on which the OMS running. For more details on starting a node with the JVM Diagnostics Agent, see Section 13.9, "Integration with JVM Diagnostics".

12.3.5 Discovering Coherence Targets

To discover a Coherence target, follow these steps:

1. Login to Enterprise Manager as an administrator with the Add Target privilege.

2. From the Targets menu, select Middleware. You will see a list of Middleware targets.

Note:
Alternatively, you can add a Coherence target from the Setup menu. From the Setup menu, select Add Target, then select Add Targets Manually. In the Add Targets Manually page, select the Add Non-Host Targets Using Guided Process option. Follow the steps in the wizard to add the Coherence target.

3. Select Oracle Coherence in the Add drop-down box and click Go. The Oracle Coherence Cluster: Discover Cluster, Node, and Cache Targets page is displayed.

Figure 12-1 Add Coherence Target

4. On this page, you can add a Coherence cluster, a node, or a cache from the specified MBean Server node. You can select either of the following options to provide MBean Server details:

- Host, Port, and Service: Enter the following details:

- Select the host on which the Management Node is running.

- The port used for the JMX RMI connection. If you are using the MBean connector for Coherence MBeans, specify the tangosol.coherence.management.remote.connectionport property. If you are using the platform MBean Server for registering Coherence Mbeans, use the com.sun.management.jmxremote.port property.

- The service name used for the connection. The default is jmxrmi.

- Service URL that will be used for the connection. You may need to specify the Service URL only in complex cases like when the RMI registry and the MBean Server ports are different. In most other cases, the Machine Name and Port are used for the connection.

5. Select the Management Agent that will be used to monitor the Coherence target and click Continue.

6. The details of the discovered targets are displayed. Click Add Targets to add these targets to Enterprise Manager.

Note:
If you are adding a new node or cache target after the cluster has been discovered, you must configure the following corrective actions in the Metric and Collection Settings page:

- Discover New Oracle Coherence Nodes on the Change Number of Nodes metric.

- Discover New Oracle Coherence Caches on the Change Number of Caches metric.

For more details, refer to the Corrective Actions section.

12.3.6 Corrective Actions

Corrective Actions allow administrators to specify automated responses to alerts or policy violations. Corrective Actions ensure that routine responses to alerts or policy violations are automatically executed, thereby saving administrator time and ensuring problems are dealt with before they noticeably impact end users.

If you add a node or a cache after the cluster has been discovered, you must setup the Discover New Oracle Coherence Nodes and Discover New Oracle Coherence Caches corrective actions to add the node and cache as Enterprise Manager Targets. To setup the corrective actions, follow these steps:

1. From the Targets menu, select Middleware, then click on a Coherence Cluster target.

2. The Cluster Home page is displayed. From the Oracle Coherence Cluster menu, select Monitoring, then select Metric and Collection Settings from the Oracle Coherence Cluster menu. The Metric and Collection Settings page is displayed.

Figure 12-2 Metric and Collection Settings

3. Click the Edit icon for the Change Number of Nodes metric. The Edit Advanced Settings page is displayed.l

Figure 12-3 Edit Advanced Settings

4. Under the Corrective Actions section, click Add for the metric severity (Warning or Critical) for which a corrective action is to be associated.

5. Click Continue. The Add Corrective Action page is displayed.

Figure 12-4 Add Corrective Action

6. Select the Discover New Coherence Nodes corrective action from the list and click Continue.

7. In the Create Corrective Action page, enter the name and description of the corrective action and click Continue. You are returned to the Edit Advanced Settings page with the corrective action set for the metric Warning and/or Critical metric thresholds.

8. Follow this process to set the corrective action for the Change Number of Caches metric.

12.3.7 Refreshing a Cluster

You can manually synchronize the cluster targets with the running Coherence cluster. Click Refresh Cluster from the Oracle Coherence Cluster menu. A message indicating that new Coherence nodes and caches that have been discovered will be added as Enterprise Manager targets is displayed. Nodes are updated if there are any changes to their attributes. Click Continue to refresh the cluster.

Note:
Decommissioned nodes and caches will not be removed during the Refresh process. You must remove them manually.

12.4 Enabling the Management Pack

You must enable the Management Pack for Oracle Coherence if you want to access additional features beyond Coherence cluster monitoring. To enable the Management Pack, do the following:

1. From the Setup menu, select Management Packs, then select Management Pack Access.

2. Select Oracle Coherence in the Search drop-down list and click Go.

3. All the Coherence targets being monitored are displayed. Check the Pack Access Agreed check box for the Coherence target and click Apply to enable the Management Pack.

13 Monitoring a Coherence Cluster

After you have discovered the Coherence target and enabled the Management Pack Access, you can start monitoring the health and performance of the cluster. You can monitor the entire cluster or drill down to the various entities of the cluster like nodes, caches, services, connection managers, and connections.

This chapter contains the following sections:

- Cluster Level Pages

- Detailed Pages

- Performance Pages

- Log File Monitoring

- Cache Data Management

- Reap Session Support

- Push Replication Pattern

- Transactional Cache Support

- Integration with JVM Diagnostics

- Viewing Performance Summary

- Viewing Configuration Topology

- Troubleshooting Coherence

13.1 Cluster Level Pages

At the cluster level, you can view the Home page for the cluster, view the performance of all nodes, caches, and connections in the cluster, and perform administrative tasks (compare and change configuration) for the different entities in the cluster.

13.1.1 Cluster Level Home Page

You can get a global view of the cluster from the Home page by following these steps:

1. From the Targets menu, select Middleware, then click on a Coherence Cluster target. The Coherence Cluster Home page is displayed.

2. Figure 13-1 Cluster Home Page

3. This page contains the following sections:

- General

- Graphs

- Cluster Management

- Service

- Applications

- Metric and Host Alerts

13.1.1.1 General

This section contains the following details:

- Name and status of the cluster.

- Availability%: This is really the availability of the cluster management node over the last 24 hours.

- Number of Up Nodes: The number of nodes that are Up. Click on the link to drill down to the Selected Nodes Performance page.

- Number of Down Nodes: The number of nodes that are Down. Click on the link to drill down to the Down Nodes page.

- Number of Departed Nodes: The number of nodes that have departed from the cluster.

- Storage Enabled Nodes: Indicates the number of nodes that are storage enabled.

- Number of Weak Nodes: The number of nodes that are weak and have communication and performance issues. Click on the link to drill down to the Node Performance page.

- Weakest Node: The weakest node in the cluster. Click on the link to drill down to the Node Home page.

- Node with Max Queue Size: Indicates the node with the maximum queue size value in the cluster.

- Node with Minimum Memory: Indicates the node with the minimum available memory in the cluster.

- Number of Caches and Objects: The number of caches in the cluster and the number of objects stored in all caches in the cluster. Click on the Number of Caches link to drill down to the Cache Performance page.

- Publisher and Receiver Success Rates: The Publisher and Receiver success rate for this cluster node since the node statistics were last reset.

- Management Bean Server Node: This is the management node that contains the Coherence MBeanServer. Click on the link to drill down to the Node Home page.

- Monitoring Agent: The Oracle Management Agent monitoring the cluster.

- MBean Server Host: The host on which the management node is running. If the node on the MBean Server Host is not accessible, the monitoring capability of the entire cluster will be affected. To avoid this, we recommend that at least two management nodes are running on the cluster. If a management node departs from the cluster, you must update the host and port target properties to point to the host with the running management node.

- License Mode: The license mode that this cluster is using. Possible values are Evaluation, Development or Production.

- Product Edition: The product edition that this cluster is running on. Possible values are: Standard Edition (SE), Enterprise Edition (EE), Grid Edition (GE).

13.1.1.2 Graphs

Graphs indicating the health of the cluster are displayed here. The following graphs are displayed:

- Nodes Uptime: This graph displays groups of nodes according to their uptime. The Node Uptime is calculated as the difference between the Current Time and the Node Timestamp. Nodes that have an uptime of less than a minute are displayed in the seconds bar, nodes with an uptime of less than a hour are displayed in the minutes bar and so on.

- Caches with Lowest Hits to Gets Ratio: This graph shows caches (up to a maximum of 5) that have lowest Hits to Gets ratio. Click on the cache name in the legend section to drill down in to the Cache Details page to further investigate the reasons for the low hits to gets ratio.

Note:
The data in the General and Graphs section will be refreshed after one collection interval (from 5 to 15 minutes).

13.1.1.3 Cluster Management

In this section, you can start and stop one or more nodes, or stop a cluster with the default start script that is located in the emas/scripts/coherence directory of the Monitoring Agent.

You can do the following:

- Start New Nodes: You can start one or more nodes based on an existing node. The new node will have the same configuration as the existing node.

- Stop Nodes: You can stop all the nodes on a specific host.

- Stop Cluster: You can stop an entire cluster if all the hosts are managed by Enterprise Manager Cloud Control.

Note:
You can set up a corrective action to start departed Coherence Nodes automatically. Before you define the corrective actions, you must set up preferred credentials on the hosts on which the departed nodes need to be restarted.
When a node departs, this corrective action is launched within 30 seconds and the new node is automatically started on the same host if the following variables have been defined:

- oracle.coherence.startscript: The absolute path to the start script needed to bring up a Coherence node. All customizations needed for starting this node should be in this script.

- oracle.coherence.home: The absolute path to the location in which the coherence folder is present which is $INSTALL_DIR/coherence. This folder contains Coherence binaries and libraries.

13.1.1.4 Services

This section shows all the services in the cluster. You can view the type of service (Cluster Service, Distributed Cache Service, Invocation Service, and Replicated Cache Service), status of the service (Machine-Safe, Node-Safe, and Endangered), the number of nodes in the service, storage enabled nodes, endangered nodes, and active transactions.

13.1.1.5 Applications

This section shows the applications that use this Coherence cluster to cache their HTTPSession Objects. You can view details of the Local Cache, Overflow Cache, and Servlet Context Cache.

13.1.1.6 Metric and Host Alerts

This section lists the alerts from all types of entities in the cluster; nodes, caches, services, connections and connection managers, along with their severity and the date on which the alert was triggered. The alerts are generated based on the thresholds defined in the Metrics Collection file. To configure these threshold values, select the Monitoring menu option from the Oracle Coherence Cluster and select the Metric and Collection Settings submenu.Refer to the Enterprise Manager Online Help for detailed information on the parameters displayed in the screen.

13.1.1.7 Cluster Level Operations

From the Cluster Home page, you can several other operations such as:

- Viewing The Performance Summary: From the Oracle Coherence Cluster menu, select Monitoring, then select Performance Summary from the Oracle Coherence Cluster menu. You can view the performance of the cluster on this page.

- Metric and Collection Settings: From the Oracle Coherence Cluster menu, select Monitoring, then select Metric and Collection Settings from the Oracle Coherence Cluster menu. You can set up corrective actions to add nodes and caches as Enterprise Manager targets.

- Refreshing Cluster: From the Oracle Coherence Cluster menu, select Refresh Cluster. You can refresh a cluster to add newly discovered nodes and caches as Enterprise Manager targets or update any nodes whose attributes have been changed.

- Coherence Node Provisioning: From the Oracle Coherence Cluster menu, select Coherence Node Provisioning. You can deploy a Coherence node across multiple targets in a farm.

- Last Collected Configuration: From the Oracle Coherence Cluster menu, select Configuration, then select Last Collected. You can view the latest or saved configuration data for the Coherence cluster.

- Topology: From the Oracle Coherence Cluster menu, select Configuration, then select Topology. The Configuration Topology Viewer provides a visual layout of the relationship of the Coherence cluster with other targets.

13.1.2 Cluster Level Node Performance Page

The Node Performance page displays a historical view of the metric data as it is stored in the repository. Click the Node Performance tab to view this page.

Figure 13-2 Coherence Node Performance Page

This page displays the performance of all the nodes in the cluster over a specified period of time. You can see charts showing the top nodes with lowest available memory, maximum send queue size, maximum puts, and maximum gets. By default, you can see the average performance metrics for the last 24 hours in all the Performance pages. If a target has been recently added, you can view real time data after one collection interval (between 5 to 15 minutes) since the 24 hour performance metrics will not be available. To view the real time charts, select one of the Real Time options in the View Data drop-down list in any of Performance pages. Using the View Data options, you can also view the average performance metrics for the last 7 or 31 days.The Node Performance page tab shows the performance of all nodes in this cluster. If you click on a link that shows multiple nodes like weak nodes, storage nodes, etc., the performance of the selected nodes will be displayed on this page. You can toggle between the two modes to see the performance of the selected nodes or all the nodes.

13.1.3 Cluster Level Cache Performance Page

This page displays the cache related performance over a specified period of time. You can view the performance of the top caches or all the caches.

Figure 13-3 Cluster Level Cache Performance

Select the All Caches option from the drop-down list to view the performance of all the caches in the cluster. If you select the All Caches option, you can see the total and average metric values over the selected period of time.

13.1.4 Cluster Level Connection Performance Page

This page shows the performance of all connection managers and connections in the cluster. The following Connection Manager graphs are displayed:

- Top Connection Managers with Most Bytes Sent since the connection manager was last started.

- Top Connection Managers with Most Bytes Received since the connection manager was last started.

A table with the list of Connection Managers is displayed with the following details:

- Connection Manager: This is the name of the connection manager. It indicates the Service Name and the Node ID where the Service Name is the name of the service used by this Connection Manager. Click on the link to drill down to the Connection Manager Home page.

- Service: The name of the service. Click on the link to drill down to the Service Home page.

- Node ID: An ID is automatically assigned to any node that is part of the cluster.

- Bytes Sent: The number of bytes sent per minute.

- Bytes Received: The number of bytes received per minute.

- Outgoing Buffer Pool Capacity: The maximum size of the outgoing buffer pool.

- Outgoing Buffer Pool Size: The currently used value of the outgoing buffer pool.

- Outgoing Message Backlog: The number of outgoing messages in the backlog

- Outgoing Byte Backlog: The number of outgoing bytes in the backlog.

The following Connection related graphs are displayed:

- Top Connections with Most Bytes Sent since the connection was last started.

- Top Connections with Most Bytes Received since the connection was last started.

A table with the list of connections is displayed. Click on the link to drill down to the Details page.

- Remote Client: The host on which this connection exists.

- Up Since: The date and time from which this connection is running.

- Connection Manager: This is the name of the connection manager. Click on the link to drill down to the Connection Manager Home page.

- Service: The name of the service. Click on the link to drill down to the Service Home page.

- Node ID: An ID is automatically assigned to any node that is part of the cluster.

- Bytes Sent: The number of bytes sent per minute.

- Bytes Received: The number of bytes received per minute.

- Connection Time: The connection time in minutes.

- Outgoing Message Backlog: The number of outgoing messages in the backlog.

- Outgoing Byte Backlog: The number of outgoing bytes in the backlog.

13.1.5 Cluster Level Administration Page

This page allows you to compare configurations of nodes, caches, and services.

Figure 13-4 Cluster Level Administration Page

On this page, you can do the following:

- Change Configuration: Select an entity (node, cache, connection manager, connection, or service) for which the configuration needs to be modified and click Go. The Change Configuration page is displayed. Enter the new values and click Update to save the values and return to the Coherence Node Administration page.

- Compare Two Entities: To compare two entities (node, cache, connection managers, connections, and services), select the first entity from the first drop-down list, the second entity from the second drop-down list and click Go. You will see the Details page where the details of the selected entities are shown side by side in a two column table.

13.2 Detailed Pages

From the cluster level pages, you can click on any hyperlink and drill down to the detailed home pages of each entity in the cluster. Hyperlinks from one entity allow you to go to another entity. For example, you can view all the nodes of a cache in the Cache Detailed page, identify the node that is not contributing well for this cache, click on the node hyperlink and drill down to the Node Detailed page for further investigation. You can compare that node configuration with other nodes and change its runtime configuration if required.

- Viewing The Performance Summary: From the Oracle Coherence Cluster menu, select Monitoring, then select Performance Summary. You can view the performance of the node or cache on this page.

- Metric and Collection Settings: From the Oracle Coherence Cluster menu, select Monitoring, then select Metric and Collection Settings. You can set up corrective actions to add nodes and caches as Enterprise Manager targets.

- Last Collected Configuration: From the Oracle Coherence Cluster menu, select Configuration, then select Last Collected. You can view the latest or saved configuration data for the Coherence cluster.

- Topology: From the Oracle Coherence Cluster menu, select Configuration, then select Topology. The Configuration Topology Viewer provides a visual layout of the relationship of the Coherence cluster with other targets.

13.2.1 Node Home Page

This page shows the details and controls of a specific selected node in the Coherence cluster.

Figure 13-5 Node Home Page

This page contains the following sections:

- General

- Node ID: When a node becomes part of a cluster, an ID is automatically assigned to the node. This ID can be a new number or the number that was assigned to a Departed Node.

- Machine Name: The name of the machine on which the node is running.
Note: You must set the machine name property when a node is started. To set the machine name, set the -Dtangosol.coherence.machine=HOST_NAME flag in the start coherence script. The HOST_NAME is the complete name of the machine on which the node is running. This allows you to associate the machine name with the Host Details page. See the Coherence documentation for more details on setting this flag.

- Role Name: The role could be storage/data, application/process, proxy or management node.

- Site Name: This indicates the location of the coherence node.

- Rack Name: Name of the rack where the machine is located.

- Member Name: The unique name assigned to the Member.

- Process Name: Indicates the name of the process on which the node is hosted.

- Up Since: The date and time from this node has been up and running.
Note: If a node has dropped out the cluster and rejoined the cluster, the period from which it last joined the cluster is displayed

- Product Edition: The product edition this Member is running. Possible values are: Standard Edition (SE), Enterprise Edition (EE), Grid Edition (GE).

- Memory Usage: The maximum memory and the available memory on this node are displayed as line graphs.

- Node Management: In this section, you can click Stop Node to stop this node and click Reset Statistics to reset all the statistics for this node.

- Components: The list of components and the type of each component in the cluster are displayed here. Click on the link to drill down to the Component Home page.

- Metric Alerts: This table shows a list of all the metric alerts specific to this node.

- Host Alerts: This table shows a list of alerts from the host on which this node is running.

13.2.2 Cache Home Page

This page shows the details of the specific selected cache in the Coherence cluster.

Figure 13-6 Cache Home Page

This page contains the following sections:

- General

- Status: Indicates the status of the cache.

- Availability: The percentage of time that the management agent was able to communicate with the cache. Click the percentage link to view the availability details for the past 24 hours.

- Name: The unique name assigned to the cache.

- Coherence Cluster: The name of the cluster. Click on the link to drill down to the Cluster Home page.

- Number of Nodes: The number of nodes on which the cache is running. Click on the link to drill down to the Node Home page.

- Service Name: The name of the service used by this cache.

- Number of Objects: Shows the number of objects in the cache.

- Memory Consumed: The amount of memory used by the cache in units.

- Queue Size: The size of the write-behind queue size. Applicable only for WRITE-BEHIND persistence type.

- Cache Hits and Misses: This graph displays the total cache hits and misses per minute. Click on the graph to drill down to the Cache Hits Delta Sum metric page.

- Nodes: This section lists all the nodes supporting this cache.

- Node ID: The ID number assigned to the node. Click on the link to drill down to the Node Home page.

- Persistence Type: The persistence type for this cache. Possible values include: NONE, READ-ONLY, WRITE-THROUGH, WRITE-BEHIND.

- Metric Alerts: This table shows a list of all the metric alerts specific to this cache.

- Host Alerts: This table shows a list of alerts from the host on which this cache is running.

- Push Replication Tables: If a push replication enabled cache is present in your cluster, you can see the Publisher and Subscriber tables.

13.2.3 Connection Manager Home Page

Use this page to view the details and controls of a Connection Manager instance in the Coherence cluster.

Figure 13-7 Connection Manager Home Page

This page contains the following sections:

- General

- Service Name: The unique name assigned to the service.

- Node ID: An ID is automatically assigned to any node that is part of the cluster. This can be a new number or a number that belongs to a Departed node.

- Connection Count: The number of connections associated with the connection manager instance.

- Host IP: The IP address of the host machine.

- Refresh Time: The date and time on which the connection manager instance was last refreshed.

- Bytes Sent and Received: This graph displays the number of bytes that were sent and received per minute. Click on the graph to drill down to the Bytes Sent Metric page.

- Connections

- Remote Client: A unique hexadecimal number assigned to each connection.

- Service Name: The unique name assigned to the service.

- Node ID: An ID is automatically assigned to any node that is part of the cluster. This can be a new number or a number that belongs to a Departed node.

- Outgoing Byte Backlog: The number of outgoing bytes in the backlog.

- Outgoing Message Backlog: The number of outgoing messages in the backlog.

- Up Since: The date and time from which the connection manager instance is up.

- Bytes Received: The number of bytes received per minute.

- Bytes Sent: The number of bytes sent per minute.

- Metric Alerts: This table shows a list of all the metric alerts specific to this connection manager.

- Host Alerts: This table shows a list of alerts from the host on which this connection manager instance is running.

13.3 Performance Pages

Entity level performance pages give detailed views of the performance of this particular entity. For nodes and caches, there are two views - Charts and Metrics. You can select the option from the View drop-down list.

13.3.1 Node Performance Page

This page displays the performance of a specific node over a specified period of time. You can view either the charts or the actual metrics by selecting the appropriate option from the View drop-down list. If you select Charts option, you can see the average gets, puts, memory available, send queue size, and publisher and receiver success rates over the selected period of time. If you select the Metrics option, you can see the total and average metric values over the selected period of time.

Figure 13-8 Selected Node Performance Page

This page shows the following details:

- Charts: The following line graphs are displayed for the selected nodes on this page.

- Puts: This graph shows the average number of put() operations per minute. Click on the graph to drill down to the Puts Sum Delta metric page.

- Gets: This graph shows the average number of get() operations per minute. Click on the graph to drill down to the Gets Sum Delta metric page.

- Memory Usage: This graph shows available memory for the node over a period of time. You can use this graph to view trends by setting different real time and historical time options. Click on the graph to drill down to the Memory Available (MB metric page).

- Send Queue Size: This graph shows the Send Queue Size for this node. The Send Queue Size indicates the number of packets that are scheduled for delivery. This includes both packets that are to be sent immediately and packets that have already been sent but are waiting for acknowledgement. Click on the graph to drill down to the Send Queue Size metric page.

- Publisher and Receiver Success Rates: This graph shows the Publisher and Receiver success rate percentage. Click on the graph to drill down to the corresponding metric pages.

- Metrics: The metric values for the selected period are displayed.

- Cache: This section shows the total and average metrics values for all the caches running on this node.

- Name: Name of the cache.

- Tier: Indicates whether it is the front or back tier.

- Loader: Responsible for reading/writing data from the underlying database.

- Number of Objects: Shows the number of objects in the cache.

- Memory Consumed: The amount of memory used by the cache in units.

- Cache Hits: The average number of cache hits in the last 24 hours. A cache hit is a read or a get() operation.

- Cache Misses: The average number of cache misses in the last 24 hours.

- Gets: The average number of get() operations in the last 24 hours.

- Puts: The average number of put() operations that have occurred during the specified period.

- Service: This section shows the average values for all the services running on this node.

- Name: The unique name assigned to the service.

- Partitions Endangered: The total number of partitions that have not been currently backed up.

- Status HA: The high availability status of the service. This can be Machine-Safe, Node-Safe, or Endangered.

- Thread Count: The number of threads in the service thread pool.

- Task Count: The average number of tasks that have been executed in the specified period.

- Storage Manager: This section shows all the storage manager instances running on this node.

- Service Name: The unique name assigned to the service.

- Cache Name: The name of the cache.

- Events Dispatched: The total number of events dispatched by the Storage Manager per minute.

- Eviction Count: The number of evictions from the backing map managed by this Storage Manager caused by entries expiry or insert operations that would make the underlying backing map to reach its configured size limit.

- Index Info: An array of information for each index applied to the portion of the partitioned cache managed by the Storage Manager. Each element is a string value that includes a Value Extractor description, ordered flag (true to indicate that the contents of the index are ordered; false otherwise), and cardinality (number of unique values indexed).

- Insert Count: The number of inserts into the backing map managed by this Storage Manager. In addition to standard inserts caused by put and invoke operations or synthetic inserts caused by get operations with read-through backing map topology, this counter is incremented when distribution transfers move resources `into` the underlying backing map and is decremented when distribution transfers move data `out`

- Remove Count: The number of removes from the backing map managed by this Storage Manager caused by operations such as clear, remove or invoke.

- System: This section shows the system information for this node.

- Maximum Memory (MB): The maximum amount of memory that the JVM will attempt to use in MB.

- Memory Available (MB): The total amount of memory in the JVM available for new objects in MB.

- CPU Count: The number of CPU cores for the machine on which this Member is running.

- Input Arguments: The Input Arguments provide information about system parameters with which a Coherence node JVM is started. These are stored as configuration metrics in Repository and can be used to compare two different nodes. They also play an important role in stopping and restarting the node.

- Operating System

- Committed Virtual Memory Size: The amount of virtual memory that is guaranteed to be available to the running process in bytes.

- Free Physical Memory Size: The amount of free physical memory available.

- Free Swap Space: The amount of free swap space available.

- Total Physical Memory Size: The total amount of physical memory available.

- Total Swap Space Size: The total amount of swap space size available.

- Operating System Name: The name of the operating system being used.

- Architecture: The architecture of the operating system.

- Operating System Version: The version of the operating system being used.

- Available Processors: The number of processors available to the Java Virtual Machine.

- Max File Descriptor Count: The maximum number of file descriptors present.

- Open File Descriptor Count: The number of open file descriptors available.

- Process CPU Time: The CPU time used by the process on which the Java virtual machine is running.

- Platform Memory

- Heap Memory: The runtime data area from which memory for all class instances and arrays are allocated.

- Non Heap Memory: The Java virtual machine has a method area that is shared among all threads. The method area belongs to non-heap memory. It stores per-class structures such as a runtime constant pool, field and method data, and the code for methods and constructors.

- Platform Memory:

- Thread Count: The current number of live threads including both daemon and non-daemon threads.

- Peak Thread Count: The peak live thread count since the Java virtual machine started or peak was reset.

- Platform Thread

- Garbage Collector Name: The name of the Garbage Collector.

- Collection Count: The total number of collections that have occurred.

- Collection Time Count: The approximate accumulated collection elapsed time in seconds.

- Time Taken: The elapsed time of this garbage collection in milliseconds.

- Platform Garbage Collector

- Garbage Collector Name: The name of the Garbage Collector.

- Collection Count: The total number of collections that have occurred.

- Collection Time Count: The approximate accumulated collection elapsed time in seconds.

- Time Taken: The elapsed time of this garbage collection in milliseconds.

- Connection

- Multicast Address: The IP address of the Member's Multicast Socket for group communication.

- Multicast Enabled: Specifies whether this Member uses multicast for group communication.

- Multicast Port: The port of the Member's Multicast Socket for group communication.

- Multicast TTL: The time-to-live for multicast packets sent out on this Member`s Multicast Socket.

- Multicast Threshold: The percentage (0 to 100) of the servers in the cluster that a packet will be sent to, above which the packet will be multicasted and below which it will be unicasted.

- Flow Control Enabled: Indicates whether Flow Control has been enabled.

- Burst Count: The maximum number of packets that can be sent without pausing. Anything less than one (e.g. zero) means no limit.

- Buffer Publish Size: The buffer size of the unicast datagram socket used by the Publisher, measured in the number of packets.

- Buffer Receive Size: The buffer size of the unicast datagram socket used by the Receiver, measured in the number of packets.

- Burst Delay: The number of milliseconds to pause between bursts. Anything less than one (e.g. zero) is treated as one millisecond.

- Unicast Address: The IP address of the Member's Datagram Socket for point-to-point communication.

- Unicast Port: The port of the Member's Datagram Socket for point-to-point communication.

- Network

- Packet Delivery Efficiency: The efficiency of packet loss detection and retransmission. A low efficiency is an indication that there is a high rate of unnecessary packet retransmissions.

- Packets Bundled: The total number of packets which were bundled prior to transmission. The total number of network transmissions is equal to (Packets Sent - Packets Bundled).

- Packets Received: The number of packets received per minute.

- Packets Repeated: The number of duplicate packets received per minute.

- Packets Resent: The number of packets resent per minute. A packet is resent when there is no ACK received within a timeout period.

- Packets Resent Early: The total number of packets resent ahead of schedule. A packet is resent ahead of schedule when there is a NACK indicating that the packet has not been received.

- Packets Resent Excess: The total number of packet retransmissions that were later proven unnecessary.

- Packets Sent: The number of packets sent per minute.

- Resend Delay: The minimum number of milliseconds that a packet will remain queued in the Publisher's re-send queue before it is resent to the recipient(s) if the packet has not been acknowledged.

- Send Queue Size: The number of packets currently scheduled for delivery. This number includes both packets that are to be sent immediately and packets that have already been sent and awaiting for acknowledgment. Packets that do not receive an acknowledgment within Resend Delay interval will be automatically resent.

- Traffic Jam Count: The maximum total number of packets in the send and resend queues that forces the Publisher to pause client threads. Zero means no limit.

- Traffic Jam Delay: The number of milliseconds to pause client threads when a traffic jam condition has been reached. Anything less than one (e.g. zero) is treated as one millisecond.

- Weakest Channel: The ID of the cluster node to which this node is having the most difficulty communicating, or -1 if none is found. A channel is considered to be weak if either the point-to-point publisher or receiver success rates are below 1.0.

- Receiver Packet Utilization: The receiver packet utilization for this cluster node since the socket was last reopened. This value is a ratio of the number of bytes received to the number that would have been received had all packets been full. A low utilization indicates that data is not being sent in large enough chunks to make efficient use of the network.

- TCPRing Failures: The number of recovered TCP Ring disconnects per minute. A recoverable disconnect is an abnormal event that is registered when the TCP Ring peer drops the TCP connection, but recovers after no more then maximum configured number of attempts.

- TCPRing Timeouts: The number of TCP Ring Timeouts per minute.

13.3.1.1 Cache Performance Details Page

This page displays the performance of a specific cache over a specific period of time. You can view charts showing the number of cache hits, misses, store reads, and store writes. You can also see the aggregated totals and average metric values over the selected period of time.

Figure 13-9 Cache Performance Details Page

The following graphs are displayed:

- Number of Objects: This graph shows the number of objects in the cache.

- Memory Consumed (Units): This graph shows the amount of memory consumed by the cache per minute.

- Hits: This graph shows the number of cache hits per minute.

- Misses: This graph shows the number of cache misses per minute.

- Puts: This graph shows the total number of put() operations per minute.

- Gets: This graph shows the total number of get() operations per minute.

- Store Reads: This graph shows the total number of load operations per minute.

- Store Writes: This graph shows the total number of store and erase operations per minute.

Metrics: Select the Metrics option in the View By drop-down list to view the totals and averages for the cache.

- Totals / Averages: The aggregated total and average values across all nodes and per node total / average values for the cache during the selected period are displayed.

- Hits: The number of successful fetches of the cached objects per minute.

- Misses: The number of failed fetches of the cached objects per minute.

- Puts: The number of addition of objects to a cache per minute.

- Gets: The number of retrieval of objects from a cache per minute.

- Prunes: The number of prune operations on the cache per minute. A prune operation occurs every time the cache reaches its high watermark.

- Store Reads: The number of reads from a data store per minute.

- Store Writes: The number of writes to a data store per minute.

- Number of Objects: The number of objects in the cache.

- Memory Consumed (Units): The amount of memory used by the cache in units.

- Average Time (ms): The average execution time for each operation (hits, misses, puts, gets, store reads, and store writes) are displayed. The values since the last collection divided by the time taken by the operations are displayed. For example, if there are 100 Hits and these 100 Hits took 20 milliseconds since last collection, this value is calculated as 100/20 = 5.

- Storage Manager

- Events Dispatched: The total number of events dispatched by the Storage Manager per minute.

- Eviction Count: The number of evictions from the backing map managed by this Storage Manager caused by entries expiry or insert operations that would make the underlying backing map to reach its configured size limit.

- Insert Count: The number of inserts into the backing map managed by this Storage Manager. In addition to standard inserts caused by put and invoke operations or synthetic inserts caused by get operations with read-through backing map topology, this counter is incremented when distribution transfers move resources into the underlying backing map and is decremented when distribution transfers move data out.

- Remove Count: The number of removes from the backing map managed by this Storage Manager caused by operations such as clear, remove or invoke.

- Listener Filter Count: The number of listener filters.

- Listener Key Count: The number of listener keys.

- Listener Registrations: The number of listener registrations.

- Locks Granted: The number of locks granted.

- Locks Pending: The number of locks pending.

Apart from these pages, the detailed pages for the following entities are also available:

- Service Performance Details Page: This page displays the performance of the selected service over a specific period of time. The Request Average Duration and the Request Max Duration charts are displayed. You can also see the average metric values over the selected period of time.

- Connection Manager and Connection Performance Details Page: These pages displays the performance of the selected connection or connection manager.

13.3.2 Administration Pages

You can drill down to the Administration page for a specific node, cache, connection, or connection manager. You can change configuration for a specific entity, or compare configurations for two entities in the cluster.

13.3.2.1 Compare Configurations

You can compare the configurations for a node, cache, service, or connection manager target. The comparison details between the two selected entities are shown in a four column table. The first column shows the comparison result. The second column shows the attribute being compared and the values of the attribute being compared are displayed in the last two columns. When an attribute value is the same for both the entities, you would see an “=” in Result column. Otherwise, you would see a non-equal sign in Result column. The figure below shows the Compare Nodes page.

Figure 13-10 Compare Nodes Page

13.3.2.2 Change Configuration

You can change the configuration of a node, cache, or a service in the cluster.

13.4 Log File Monitoring

Enterprise Manager monitors log files for the occurrence of user specified patterns to check for abnormal conditions. Log files are periodically scanned for occurrence of one or more perl patterns and an alert is raised when the pattern occurs during a given scan.

You can set up each Coherence node to log all messages into a log file on the host on which the node is running. You must use a specific naming pattern in the log file name to ensure that it is monitored. To configure the log file monitoring criteria, follow these steps:

1. From the Targets menu, select Middleware, then click on a Coherence cluster target.

2. Navigate to the Administration page of the node for which the Log file alerts need to be configured.

Figure 13-11 Node Administration Page

3. Click the Log Alert Setup link. The Metric and Policy Settings page of the host on which the Coherence node is running is displayed.

4. Select Metric with Thresholds in the View drop-down box and search for the Log File Pattern Matched Line Count metric.

5. Click the pencil icon in this row to navigate to the Edit Advanced Settings: Log File Pattern Matched Line Count page.

Figure 13-12 Log File Pattern Matched Line Count Page

6. Click Add to add a row to the Monitored Objects table.

7. In the Log File Name field, specify the name in the format <coherence_cluster_target_name>_<Node_name>_<....any other optional names>.log.

8. Specify the pattern to be matched for or ignored in the Match Pattern in Perl and Ignore Pattern in Perl fields. Lines matching the ignore pattern will be ignored first, then lines matching specified match patterns will result in one record being uploaded to the repository for each pattern.

9. Enter the Critical and Warning thresholds for this metric and click Continue. You will return to the Metrics and Collection Settings page. Click OK to update the metric.

10. Any alerts generated will be displayed in the Coherence Log Alerts section in the Cluster Home page.

Figure 13-13 Cluster Home Page - Coherence Log Alerts

13.5 Cache Data Management

The Cache Data Management feature allows you to define indexes and perform queries against currently cached data that meets a specified set of criteria.

Note:
This feature is available to users with Administration privileges only if the Cache Data Management MBean has been registered in the Coherence Cluster.

To perform cache data management operations, navigate to the Cache Administration page and click Go in the Cache Data Management section. In the Cache Data Management page, you can select an operation and a query to perform a data management operation on the cache. You can perform the following operations:

- Add Indexes: To create an index, select the Add Index option in the Operation field. In the Value Extractor List field, specify a comma separated list of expressions that identify the index, and enter the Host Credentials. The Value Extractor is used to extract an attribute from a given object for indexing.

- Remove Indexes: To remove an index, select the Remove Index option in the Operation field and specify the Value Extractor List that identifies the index. Specify the Host Credentials and click Execute to remove the index from the cache.

- Export: You can export the queried data onto a file. Select a query from the Query section or click Create to create a new query. Select the Export option in the Operation field and enter the absolute path to the file. This file can be saved on the host machine on which the management node is running.

- Import: You can import queried data from a file. This file should be present on the host machine on which the management node is running. Select the Import option in the operation field and enter the absolute path to the file.

- Insert: Select the Insert option in the Operation field and specify an unique (key value) pair. This key value pair will be inserted into the cache and can be provided from:7

- UI Table on this Page: Select the Type of Keys and Type of Values and the Host Credentials.

- Text File on Management Host: If the queries are stored in a text file, select this option and specify the location of the file.

- Database Table: If the queries are stored in a database table, specify the Database URL, Credentials, the SQL Query Statement and Properties.

- Purge: Select Purge from the Operation drop-down list. Data matching the selected query will be deleted from the cache

- View: Select View from the Operation drop-down list and specify the number of key-value pairs to be displayed on each page. Data matching the criteria will be displayed.

- Update: Select Update from the Operation drop-down list. Specify the credentials for the host. Select a query from the Query table or create a new query to update the data in the cache.

13.6 Reap Session Support

HTTPSession Objects for one or more Java EE applications deployed on Application Servers can be cached in the Coherence cluster. These HTTP sessions are cleaned by the Session Reaper and the associated memory is freed up. The Session Reaper is responsible for destroying any sessions that are no longer used, which is determined when the session has timed out. It is configured to scan the entire set of sessions over a certain period of time, called the reaping cycle. The Session Reaper scans for sessions that have expired, and when it finds expired sessions it cleans them up.

To view the reap session metrics, click the Application link in the Applications table in the Cluster Home page. The following reap session metrics and graphs are displayed in the Application Home page.

- Reap Duration: This graph shows the average reap duration in minutes.

- Reaped Sessions: This graph shows the average number of reaped sessions in a reap cycle.

- Reaped Sessions (24 Hour Averages): This table shows the average reap session data over the last 24 hours. The following details are displayed:

- Module Name: The name of the Coherence cluster on which the HTTP sessions have been cached.

- Node ID: When a node becomes part of a cluster, an ID is automatically assigned to the node. Click on the link to drill down to the Node Home page.

- Average Reap Duration: The average reap duration since the statistics were last reset.

- Average Reaped Sessions: The average number of reap sessions since the statistics were last reset.

- Total Reaped Sessions: The total number of expired sessions that have been reaped since the statistics were last reset.

13.7 Push Replication Pattern

The Push Replication Pattern provides extensible, flexible, high-performance, highly available, and scalable infrastructure to support the replication of EntryOperations occurring in one Coherence Cluster to one or more globally distributed Coherence clusters. The Push Replication Pattern advocates that:

- Operations (such as insert, update and delete) occurring on data in one Site should be pushed using one or more Publishers to an associated device.

- A Publisher is responsible for optimistically replicating operations (in the order in which the said Operations originally occurred) on or with the associated device.

- If a device is unavailable for some reason, the operations to be replicated using the associated Publisher will be queued and executed (in the original order) at a later point in time.

Implementation of the Push Replication Pattern additionally advocates that:

- The data on which operations occur are standard Coherence cache entries.

- Operations replicated include inserts, updates, and deletes of cache entries. This includes NamedCache put and remove, as well as updates that are artifacts of invoking AbstractProcessor.

- The operations that are enqueued for replication are called EntryOperations. They contain key and value pairs of updated cache entries in Binary form.

- A Site is a Coherence Cluster.

- A Site may act as both a sender of Operations and receiver of Operations. That is, multi-way multi-site push replication is permitted.

- A Device may be any of the following; a local cluster, a remote cluster, a file system, a database, an i/o stream, a logging system etc.

After the EntryOperations are captured, they are sent to the messaging layer, for distribution to the Subscribers. The Publishers then publish the currently queued EntryOperations.

The Publisher and Subscriber tables lists all the publishers and subscribers and displays the data used by them. You can Suspend, Drain, or Resume publishing operations on a specific Publisher.

13.8 Transactional Cache Support

Transactional caches are specialized distributed caches that provide transactional guarantees. Transactional caches are required whenever performing a transaction using the Transaction Framework API. Transactional caches cannot interoperate with non-transactional caches.

The CacheMBean managed resource provides attributes and operations for all caches, including transactional caches. Many of the MBeans attributes are not applicable to transactional cache; invoking such attributes simply returns a -1 value. A cluster node may have zero or more instances of cache managed beans for transactional caches. The object name uses the form:

type=Cache, service=service name, name=cache name, nodeId=cluster node's id

The following list describes the CacheMBean attributes that are supported for transactional caches.

- AverageGetMillis: The average number of milliseconds per get() invocation.

- AveragePutMillis: The average number of milliseconds per put() invocation since the cache statistics were last reset.

- HighUnits: The limit of the cache size measured in units. The cache will prune itself automatically once it reaches its maximum unit level. This is often referred to as the high water mark of the cache.

- Size: The number of entries in the current data set.

- TotalGets: The total number of get() operations since the cache statistics were last reset.

- TotalGetsMillis: The total number of milliseconds spent on get() operations since the cache statistics were last reset.

- TotalPuts: The total number of put() operations since the cache statistics were last reset.

- TotalPutsMillis: The total number of milliseconds spent on put() operations since the cache statistics were last reset.

13.9 Integration with JVM Diagnostics

JVM Diagnostics allows administrators to identify the root cause of performance problems in the production environment without having to reproduce them in the test or development environment. JVM Diagnostics is a part of WLS Management Pack EE.

You can drill down to a Coherence node's JVM to identify the method or thread that is causing a delay. This feature allows you to trace live threads, identify resource contention related to locks, and trace the Java session to the database.

You can view the JVM Diagnostics data if the JVM Diagnostics Manager and JVM Diagnostics Agent have been deployed on the host machine on which the OMS running. You can deploy the JVM Diagnostics Manager and JVM Diagnostics Agent on:

- Standalone Coherence

- CoherenceWeb

After the JVM Diagnostics Manager and Agent have been deployed, navigate to the Node Home page and select JVM Diagnostics from the Node menu. For more details on the JVM Diagnostics Manager and Agent installation, see Oracle Enterprise Manager Cloud Control Basic Installation Guide.

13.9.1 Deploying on Standalone Coherence

To deploy the JVM Diagnostics Manager and the JVM Diagnostics Agent, follow these steps:

1. Follow the steps listed in the Oracle Enterprise Manager Cloud Control Basic Installation Guide to deploy the JVM Diagnostics Manager and the JVM Diagnostics Agent.

2. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics on the Middleware Diagnostics page. Click the JVMs and Pools tab and click Download, and download the jamagent.war.

3. Start Coherence with the JVM Diagnostics Agent.

1. Specify the value for the SYS_OPT parameter as: -SYS_OPT = "$SYS_OPT -Doracle.coherence.jamjvmid=[CoherenceClusterName]/[NodeName]"

2. Add the jamagent.war to the CLASSPATH as follows:
CLASSPATH="$CLASSPATH:/scratch/ssmith/jvmd/jamagent.war"

export CLASSPATH

3. Start Coherence with the JVM Diagnostics Agent as follows:
$JAVA_HOME/bin/java -cp $CLASSPATH $JVM_OPT $SYS_OPT jamagent.jamrun [$JAMAGENT_PARAMS_LIST] $TARGET_CLASS $TARGET_CLASS_PARAMS

where [$JAMAGENT_PARAMS_LIST] refers to the JVM Diagnostics Agent parameters. The mandatory parameters are:

jamconshost = JVM Diagnostics Manager Host

jamconsport = Listening port of JVM Diagnostics Manager

oracle.ad4j.groupidprop = [CoherenceClusterName]/[NodeName]

jamjvmid=MyCluster1/Node50

Note:
the value of the -Doracle.coherence.jamjvmid parameter must be the same as the value of the oracle.ad4j.groupidprop in the $JAMAGENT_PARAMS_LIST.

An example is given below:

SYS_OPT="$SYS_OPT -Doracle.coherence.jamjvmid=MyCluster1/Node50"

CLASSPATH="$CLASSPATH:/scratch/xiawu/jvmd/jamagent.war"

$JAVA_HOME/bin/java -cp $CLASSPATH $JVM_OPT $SYS_OPT jamagent.jamrun
jamconshost=10.229.187.109 jamconsport=3800
oracle.ad4j.groupidprop=MyCluster1/Node50
oracle.sysman.integration.coherence.EMIntegrationServer

13.9.2 Deploying on CoherenceWeb

To deploy the JVM Diagnostics Manager and the JVM Diagnostics Agent, follow these steps:

1. Follow the steps listed in the Oracle Enterprise Manager Cloud Control Basic Installation Guide to deploy the JVM Diagnostics Manager and the JVM Diagnostics Agent.

2. From the Setup menu, select Middleware Diagnostics, then click Setup JVM Diagnostics on the Middleware Diagnostics page. Click the JVMs and Pools tab and click Download, and download the JVM Diagnostics Agent WAR or Database Agent War (jamagent.war).

3. Update the web.xml file with the proper JVM Diagnostics Agent properties as follows:

<?xml version="1.0" ?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application
2.3//EN""http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<servlet>
<servlet-name>jamagent</servlet-name>
<servlet-class>jamagent.jaminit</servlet-class>
<init-param>
<param-name>jamconshost</param-name>
<param-value>localhost</param-value>
<description>Default Jam Console host</description>
</init-param>
<init-param>
<param-name>jamconsport</param-name>
<param-value>3800</param-value>
<description>Jam console port</description>
</init-param>
.....
</servlet>
</web-app>

4. Deploy the jamagent.war on the WebLogic Server.

1. In the WebLogic Server Start scripts (startManagedWebLogic.sh or startWebLogic.sh), add the following JAVA_OPTIONS and restart the server.
JAVA_OPTIONS="$JAVA_OPTIONS -Doracle.coherence.wlsserver=[DomainName]/[WLSServerName]

2. To view the association between Coherence node and WebLogic Server (the WebLogic Server node on which the Coherence node has been deployed), modify the -Doracle.coherence.wlsserver option as follows and restart the server
JAVA_OPTIONS="$JAVA_OPTIONS -Doracle.coherence.wlsserver=[DomainName]/[WLSServerName]/WLSListenPort/WLSSSLListenPort

13.10 Viewing Performance Summary

You can use the Performance Summary page to monitor the performance of the cluster, a node, or a cache. From the Oracle Coherence Cluster (Node or Cache) menu, select Monitoring, then select Performance Summary.

A set of default performance charts that shows the values of specific performance metrics over time are displayed. You can customize these charts to help you isolate potential performance issues. You can also view a series of regions specific to the cluster, node, or cache target. For more details, see the Performance Summary Online Help.

13.11 Viewing Configuration Topology

The Configuration Topology Viewer provides a visual layout of the relationship of the Coherence target with other targets. From the Oracle Coherence Cluster (Node or Cache) menu, select Configuration, then select Topology. A topology graph for the Coherence target is displayed. You can determine the source of its health problem and its impact on other targets. You can also view the members of the cluster and its relationships. For more details, see the Configuration Topology Viewer Online Help.

13.12 Troubleshooting Coherence

If you cannot collect metric data for any of the Coherence targets, check the following to ensure that the steps involved in discovering the target have been followed correctly.

- Make sure that the management node has been successfully started and the host on which the management node is running is accessible from the Agent host.

- Specify the appropriate User Name and Password if password authentication is enabled.

- If you are not using SSL to start the management node, make sure that you have started the JVM using the com.sun.management.jmxremote.ssl=false option.

- If you did not use the bulk operation MBean JAR to start the management node, you must leave the Bulk Operations Mbean field blank during discovery.

Part V

Using Application Dependency and Performance

The chapters and appendixes in this part provide information regarding the usage of Application Dependency and Performance (ADP).

The chapters and appendixes are:

- Chapter 14, "Introduction to Application Dependency and Performance"

- Chapter 15, "Exploring Application Dependency and Performance"

- Chapter 16, "Exporting Data"

- Chapter 17, "ADP Methodology"

- Chapter 18, "Troubleshooting Application Dependency and Performance"

- Appendix A, "ADP Configuration Directories and Files"

- Appendix B, "Support Matrix for Application Dependency and Performance"

14 Introduction to Application Dependency and Performance

The Application Dependency and Performance (ADP) pages within Enterprise Manager Cloud Control analyze Java EE, SOA, and Portal applications to capture the complex relationships among various application building blocks in its Application Schema model - the core of the Oracle intelligent platform.

Using ADP you can:

- Monitor performance of the following applications:

- Oracle SOA Suite 11g

- Oracle Service Bus

- Java EE

- Oracle WebLogic Portal

- Oracle WebCenter

- Have visibility into components defined by way of metadata within a framework (for example, components within a composite) with deep dive visibility, where available

- View static relationships defined between components and services, such as OSB business and proxy services, and SOA services and references

This chapter includes the following:

- Overview

- Architecture

14.1 Overview

Using the insights stored in Application Schema, ADP is able to deliver an Application Service Management (ASM) environment that self-customizes out-of-the-box, evolves with change, minimizes expert involvement, and delivers a holistic, service-oriented view across heterogeneous environments. ADP enables an enterprise to more efficiently manage distributed applications, attain management agility, and lower total cost of ownership.

See the following sections:

- Managing Complex Java EE, SOA, and Portal Applications

- Delivering a Service-Oriented View Across Environments

- Avoiding Involvement from Java EE, SOA, Portal, and Application Experts

- Eliminating Repetitive Do-It-Yourself (DIY) Manual Processes

- ADP Solution

14.1.1 Managing Complex Java EE, SOA, and Portal Applications

Today's Java EE, SOA, and Portal applications enable enterprises to deliver mission-critical business functions to key constituencies - most often their customers, partners, and employees. These composite applications are assembled from many different Java EE components and exposed services distributed across a heterogeneous environment.

To be effective at managing today's complex, distributed Java EE, SOA, and Portal applications across a heterogeneous environment, enterprises must adopt an intelligent ASM platform with the following characteristics:

- Provides holistic, service-oriented views across heterogeneous environments
An intelligent ASM platform must provide high-level service-oriented metrics that map to low-level technology-centric metrics. These measurements must be organized in a service-oriented fashion to deliver a unified, holistic view of the numerous interconnected application components deployed across heterogeneous environments.

- Requires minimal Java EE, SOA, Portal, and application expertise
An intelligent ASM platform must have the ability to capture complex relationships among various interconnected components of today's Java EE, SOA, and Portal applications. This ability can help minimize reliance on Java EE, SOA, Portal, and application experts for setting up and maintaining effective APM environments.

- Eliminates repetitive DIY manual processes
An intelligent ASM platform must eliminate repetitive DIY manual processes by delivering the ability to self-customize out-of-the-box and evolve with change. Elimination of these repetitive DIY manual processes is the only way to deal with rising complexity and rapid rate of change with ease.

14.1.2 Delivering a Service-Oriented View Across Environments

Today's mission-critical business functions are powered by Java EE, SOA, and Portal applications that comprise numerous interconnected components deployed across highly distributed environments. To manage these applications effectively, enterprises must first gain an understanding of the complex relationships among the business functions, associated interconnected components, and the underlying runtime environments. To enable clear and accurate understanding, IT organizations need holistic, service-oriented views that span across heterogeneous environments.

Furthermore, appropriate rendering of these views enables users at different levels of the organization to collaborate with each other and do their respective jobs more efficiently.

Figure 14-1 Application Dependency and Performance Topology View in Enterprise Manager Cloud Control

Application Schema Navigation provides efficient ways for you to access relevant information using techniques like hierarchical traversal, architecture model navigation, string queries, drill down, drill out and more.

14.1.3 Avoiding Involvement from Java EE, SOA, Portal, and Application Experts

To manage Java EE, SOA, and Portal performance effectively, IT organizations must adopt an intelligent platform like ADP that requires minimal expertise to set up and maintain. Unlike conventional APM toolkits, ADP does not rely on human expertise to set up and maintain customized APM environments. Instead, ADP uses a unique model-driven approach that leverages the information stored in its Application Schema model to keep the involvement of experts to the minimum. ADP's unique ability to self-customize out-of-the-box and evolve with change makes it the perfect solution for managing not only custom enterprise applications, but also applications developed by external parties.

14.1.4 Eliminating Repetitive Do-It-Yourself (DIY) Manual Processes

Based on a unique model-driven approach, ADP eliminates repetitive DIY manual processes. To achieve this level of self-customization and continuous change adoption, ADP uses its AppsSchema modeling technology to perform the critical task of analyzing application structure and infrastructure configuration. After capturing these insights in the Application Schema model, ADP leverages this information to establish a fully customized ASM environment. To keep this environment up-to-date, ADP continuously updates the Application Schema model as new applications are deployed and changes are applied. ADP's unique ability to self-customize out-of-the-box and evolve with change enables fast time-to-value, low total-cost-of-ownership (TCO), and maximal return-on-investment (ROI).

14.1.5 ADP Solution

Oracle provides the industry's first intelligent ASM platform for Java EE, SOA, and Portal. Unlike conventional APM toolkits, ADP analyzes these applications and captures complex relationships among various application building blocks in its Application Schema model - the brain of this intelligent ASM platform.

Using the insights stored in the Application Schema model, ADP is able to deliver an ASM solution that self-customizes out-of-the-box, evolves with change, minimizes expert involvement, and delivers a holistic, service-oriented view across heterogeneous environments. Adopting an intelligent platform such as Oracle will enable the enterprise to more efficiently manage distributed applications, attain management agility, and lower total cost of ownership.

14.2 Architecture

ADP employs a multi-tier, fully distributed, configurable architecture to provide the scalability and flexibility to meet the changing needs of enterprise deployments.

ADP operates as a service on the machine and automatically begins running when the machine first boots, and remains on perpetually. ADP is typically installed on its own machine and dedicated to monitor a group of managed application servers.

To allow remote access to ADP through a browser, a web container is installed. This web container provisions the ADP UI applets to the browser and maintains communication with these applets. See Figure 14-2.

Note:
By default, the browser functionality is turned off. To turn on the browser functionality, set the Tomcat properties to true in the ADP_HOME/config/Acsera.properties file.

Figure 14-2 ADP Topology

The following core components are deployed to form the ADP ASM system.

14.2.1 ADP Java Agents

ADP Java Agents are the data collectors of the ADP ASM system. ADP Java Agents are deployed to all managed application servers to perform a series of tasks including collecting performance managements, tracking contextual relationships, and summarizing data in real-time while introducing as little overhead as possible. At the expiration of the predefined aggregation interval, these agents forward the summarized data to ADP for additional analysis. For various Java EE platforms such as Oracle SOA Suite, Oracle WebLogic, and IBM WebSphere, ADP leverages their deployment infrastructures to quickly deploy the ADP Java Agents to all application servers.

14.2.2 ADP Manager

ADP Manager is the core analytical engine of the ADP ASM system. In real-time, ADP Manager performs complex mathematical modeling and statistical calculations with summarized data from all ADP Java Agents. ADP Manager can be configured with a backup to provide higher level of availability.

ADP Manager can also be configured without the UI component, also known as headless configuration.

14.2.2.1 ADP Manager and High Availability

Although the ADP Manager does not have high availability (HA) built into it, administrators can have a backup ADP Manager installed on a separate machine; this backup ADP Manager points to the same database but is disabled. If the production ADP Manager fails, the backup ADP Manager can then be enabled against the same database. The backup ADP Manager then rediscovers the application after the agent is redeployed from the backup ADP Manager, to the managed resources in order to synchronize them. All metrics are preserved, assuming the model does not change in the short time frame it takes to bring the backup ADP Manager online.

The key with this backup procedure is to backup the database that ADP uses as its repository in order to preserve the historical data. On the modeling side, the backup ADP Manager has to rediscover the application which should happen automatically, as long as the resources are configured and the new agent has been deployed.

If historical data preservation is not a necessity, users can simply have another ADP Manager and database and swap agents reducing the backup effort considerably.

14.2.3 ADP Database

ADP stores its analyzed data and application models in the Management Repository. There is a separate schema for ADP in the Management Repository and this schema is external to the ADP installation.

14.2.4 ADP User Interface

The ADP User Interface (ADP UI) is the primary user interface for ADP users. Users can use ADP UI to set Service Level Objectives (SLOs), define actions, analyze monitoring data, and more. The ADP UI is fully configurable. To access ADP:

1. From the Targets menu, select Middleware.

2. On the Middleware page, click the target in which you are interested. In the tree view, select a target under Application Dependency and Performance.

3. In the right pane, expand the Application Deployment menu, select Monitoring, and then select Application Dependency and Performance.

15 Exploring Application Dependency and Performance

This chapter examines the following:

- Exploring the User Interface

- Exploring the Monitoring Tab

- Exploring the Configuration Tab

- Exploring the Registration Tab

15.1 Exploring the User Interface

This section explores the ADP User Interface. Topics include:

- Accessing ADP

- General ADP UI Elements

- Drill Down in Operational Dashboard

- Time Frame

- Display Interval

- Graphs and Data Items

- Right-Click Operations on Tables and Graphs

- Comparative View

- Save as PDF

- Easy Scroller

- Zoom In and Zoom Out Toolbar

- Custom Metrics

- Functional View

- Topology View

- Architecture View

- Metric Types

15.1.1 Accessing ADP

To access the Enterprise Manager Application Dependency and Performance (ADP) feature, do the following:

1. From the Targets menu, select Middleware.

2. On the Middleware page, click the target in which you are interested. In the tree view, select a target under Application Deployments.

3. In the right pane, expand the Application Dependency and Performance menu, select Monitoring, and then select Application Dependency and Performance.

15.1.2 General ADP UI Elements

ADP UI consists of the following core components:

- Navigation Pane (left)
There are three types of workspaces in the ADP navigation pane: Monitoring, Configuration, and Registration. In the Monitoring workspace, you can navigate the managed environment and monitored applications in a tree.

- Use the Monitoring workspace to traverse the ADP tree model and identify abnormal activities.

- Use the Configuration workspace to create, modify, and review various configuration settings for ADP.

- Use the Registration workspace to register a Remote Method Invocation (RMI) manager.

- Main Display Window (right)
As you navigate through the ADP tree model and configuration categories, detailed performance information and configuration settings are displayed in the Main Display Window. You can refresh the Main Display Window at anytime by clicking the Refresh icon.

15.1.3 Drill Down in Operational Dashboard

The Operational Dashboard displays the health indicators for various key entities in the managed environment. ADP uses traditional traffic light colors to represent the health of these various key entities.

For each component, ADP uses the following health indicators to provide a comprehensive view. These health indicators are:

- Performance
The performance health indicator depicts the relative responsiveness of the monitored entity to the configured threshold.

- Availability
The availability health indicator informs you to what extent a particular entity is available to service requests.

- Errors
The errors health indicator informs you if the number of errors and exceptions encountered by this entity are approaching or violating the configured threshold.

- Load
The load health indicator depicts how many operations have been performed and requests have been served by a particular entity.

ADP is aware of clusters. As such, these indicators display overall health of a particular entity across the entire cluster.

15.1.4 Time Frame

In ADP, you can specify the length of the time the window information is to be displayed. To specify the length of this time window, select the appropriate length in the Time Frame list. The following Time Frame values are available:

- 1 hour

- 2 hours

- 4 hours

- 8 hours

- 12 hours

- 24 hours

Note:
The ADP default data collection interval is 60 seconds. As you adjust the data collection interval, ADP automatically adjusts the display time frames.

ADP automatically adjusts information displayed to fit the specified time window. You can drill down to see detailed performance information for a specific range of time.

For example, visualize the drill down process with two screen shots of the same graph with different Time Frames of the average response time for Portal campaign. The first graph has a Time Frame of 24 hours. The second graph has a Time Frame of 1 hour. By increasing the granularity of the Time Frame, you are performing a drill down operation.

For example, an IT Operations staff noticed abnormally high response time with Portal campaign subsystem. The person decided to investigate further to evaluate the extent of the problem. By changing the Time Frame from 24 hours to 1 hour, this user is able to see that between 14:17 and 14:18, the Portal campaign response time jumped from an average of 1000 milliseconds to 5000 milliseconds. While the problem did not persist, it may warrant additional investigation.

15.1.5 Display Interval

Display Interval, located above the Main Display window, indicates the start and end time for the data displayed in the Main Display Window. Display Intervals change as you change the following settings:

- Time Frame

- Interval Context

- Turning Off Time Frame Limitation

15.1.5.1 Time Frame

When you select a new Time Frame, the Display Interval automatically changes to fit the selected Time Frame. For example, if you were to change the Time Frame from 1 hour to 2 hours, the Start value of the Display Interval changes.

15.1.5.2 Interval Context

Display Interval can also be changed by setting the Interval Context. The settings for the Interval Context are:

- End Time Is Current System Time
The default Interval Context for ADP is to use the current system time as End value for the Display Interval. In this default setting, you have a sliding Display Interval and can see the latest performance information in the Main Display Window.

- End Time Is Fixed
You can also change the Interval Context setting to use a fixed time as the End value for the Display Interval. By selecting the fixed Interval Context, you can create a fixed time window to display performance data. The fixed time window is particularly useful for performing analytical tasks.

- Date/Time Selector
When you select to fix the End time for the Interval Context, the ADP UI enables a pair of Date/Time Selectors to allow you to set Start or End values for the Display Interval. Click the icon next to the Start and End times to open up the Date/Time Selector.

The Date/Time Selector allows you to set a specific Display Interval to fit your needs. Additionally, the Date/Time Selector enables ADP to compare current performance trends with historical data.

Note:
Changing the start and end time do conceptually different things. Users are advised to always change their time frame by modifying the end time first, and then the start time. Changing the end time moves the window in time, whereas changing the start time increases/decreases the size of the window.

15.1.5.3 Turning Off Time Frame Limitation

To support the display of data for more than twenty four hours, ADP allows you to specify your own time frame for data display. To enable this feature, set Interval Context to End time is fixed and make sure the Use time frame: check box is unchecked. Turning off time frame limitation allows ADP to display eight days worth of data.

For example, when you specify the time frame to be eight days by adjusting the start and end times through the Date/Time Selector, ADP then adjusts its view to display eight days worth of data in a single graph. This feature allows you to perform trending analysis over time.

15.1.6 Graphs and Data Items

ADP displays performance information in various formats. Most commonly used display formats in ADP are tables and graphs.

- On graphs, you can gain more information about a data item by pointing the mouse over the interested item.

- Minimum and maximum response time measurements are stored in their database in addition to average response time measurements. The min and max metrics, if present, are displayed visually in the UI.

- For tables, you can perform a table sort by clicking the blue up/down arrow located in the column headings.

- On some screens, you can define the zoom in area using a click and drag operation. To zoom in, click and drag the mouse to the right. To zoom out, click and drag the mouse to the left.

Tip:
For graphs with extreme outliers, graph details are lost due to automatic graph scaling. To work around this problem, you can use the graph zoom in feature to review these details. This feature is only available on some screens.

15.1.7 Right-Click Operations on Tables and Graphs

There are several simple operations you can perform on various tables and graphs in ADP. The following is a list of the right-click operations associated with tables and graphs.

Table 15-1 Right-click on Tables and Graphs

Right-Click Operation

Description

Copy cell value

The right-click operation is available for tables only. This operation copies the cell value to enable common copy/paste operation (table only).

Export as CSV...

This right-click operation is available for both tables and graphs. This operation saves all the values in the table or graph as a comma separated value (CSV) file. The CSV file can later be imported into other applications such as Microsoft Excel.

Count number of rows

This right-click operation is available for tables only. This operation returns a count for the number of rows in the selected table (table only).

Fit to View

Make the table or graph file the entire pane.

Restore View

Restore the layout to the default state

Show/Hide Table Columns

Remove or un-remove columns from a table (table only)

Enable/Disable Series

Remove or un-remove a line from a graph (graphs only)

For example, you can use the Count number of rows right-click operation to get a total row count for any table.

15.1.8 Comparative View

ADP provides a number of analytical tools to enable performance analysis. One of these tools is the Comparative View. To access Comparative View, right-click the ADP Main Display Window and select Create Comparative View.

After the Comparative View window appears, you can use the Date / Time Selector to specify start and end times for each of the two windows in the Comparative View. You can use this tool to compare performance statistics of two different time frames.

Tip:
You can use comparative views to determine if current performance of a specific application or component differs greatly from historical performance or baseline performance captured previously.

Comparative views are useful to evaluate current performance characteristics against historical performance characteristics.

15.1.9 Save as PDF

To improve collaboration among those who work on application performance issues, ADP provides the ability to save any view as a PDF file. To save a specific view as a PDF file, right-click on the ADP Main Display Window and select Save this view as a PDF file.

15.1.10 Easy Scroller

Easy Scroller is a feature to help you navigate different views in ADP. To bring up Easy Scroller, right-click on a view in the Main Display pane and select the Easy Scroller option. Drag the box within Easy Scroller to navigate.

15.1.11 Zoom In and Zoom Out Toolbar

For some of the views, ADP provides the zooming ability. This capability enables you to zoom into diagrams for more fine-grain details and zoom out for more coarse-grain structure.

On the Zoom In/Zoom Out Toolbar, the icon zooms in on the view by 10%, the icon zooms out on the view by 10%, and the icon returns the view back to normal size (100%). You can use the drop-down box to quickly zoom in or zoom out of the view.

15.1.12 Custom Metrics

While ADP intelligently selects relevant performance metrics based on its Application Schema model, you can further customize the monitoring environment by configuring additional custom metrics. In addition, you can use custom metrics in problem diagnostic situations where additional visibility is needed to pinpoint problem root cause.

To configure a new custom metric:

1. Click Custom Metric Configuration on the Configuration tab

2. Click the Create Custom Metric button.

3. On the Custom Metric File page, either choose an existing custom metric file or provide the name of a new custom metric file. Click Continue. ADP walks you through the configuration process.

Custom Metric Configuration page includes the following fields, see Table 15-2.

Table 15-2 Custom Metric Configuration Page

Field

Description

Name

This text field is for defining the display name for the custom metric.

Resource Name

This list is for defining the resource where the custom metric will be collected.

Class Name

This text field is for defining the fully qualified class name (package + class) associated with the custom metric.

Method Name

This optional text field is for defining the method name associated with the custom metric.

Usage:

1. Type in * - ADP will instrument all methods.

2. Provide comma separated list of methods with no wildcards - ADP will create method entities and only instruments these methods in the agent.

3. Provide comma separated list of methods with wildcard prefixes or suffixes - ADP will instruct the agent to instrument the methods specified along with the wildcards.

4. Provide 1) or 2) preceded by "!" to create an excluded list - ADP will instruct the agent to instrument all methods in the class not defined in the exclude list.

Method field examples:

1. methodA,methodB,methodC

2. ejb*,*context,methodA

3. !ejb*,*context,methodA

After you define the custom metrics, restart the application server instances associated with these customizations. The new custom metrics will be listed under the Custom Metrics node in the ADP navigation tree.

The newly configured custom metric provides class level performance data, for example invocation count and response time.

15.1.13 Functional View

Functional View is a type of Application Schema Visualization - a visual way for ADP to represent the information stored in its Application Schema model. This view is designed to help you understand how business functions are assembled with various functional building blocks. Table 15-3 provides a list of functional views currently available in ADP.

Table 15-3 Functional View

Entity Type

Function View

Description

Process

Process Workflow View

This functional view depicts the workflow associated with the selected WLI and Oracle BPEL business process. It shows all the process nodes and the relationships among them.

Pageflow

Pageflow Functional View

This functional view depicts the logical flow associated with a JPS or Struts pageflow. It shows all the pages in a pageflow and the relationships among them.

OSB Proxy Service

Proxy Service Functional View

This functional view depicts the pipeline and stage flow associated with an OSB Proxy Service.

Depending on the type of entity selected, ADP displays different functional views. Right-click and select Display Functional View to bring up the relevant Functional View associated with the selected entity.

15.1.14 Topology View

Topology View is another type of Application Schema Visualization - a visual way for ADP to represent the information stored in its Application Schema model. This view is designed to help you understand how application environments are assembled with various applications, application server instances, and shared resources. This information helps you map composite applications and their building blocks to application server instances and share resources.

The highest level topology view graphically depicts domains, external resources, and shared database resources. The applications used in the following examples are CSS and MedRec demos.

For example, you can have a topology with two ADP managed resources, CSS Domain and MedRec Domain, two external resources, and a shared database resource. The lines connecting various entities in the Topology Views depict calls made from one entity to another. You can get more information about a specific call by pointing the mouse over a specific line.

It is possible to hide different types of lines in the Topology View. To the line types, right-click the Topology View and highlight the Edge types option to reveal a list of different edge (arrow) types associated with the current Topology View.

15.1.15 Architecture View

Architecture View is another type of Application Schema Visualization; a visual way for ADP to represent the information stored in its Application Schema model. This view is designed to help you understand the structure and behaviors of Java EE, SOA, and Portal applications at the module and component level. Some Architecture Views also include built-in delay analysis to help identify potential bottlenecks in a given call path.

The Architecture View in ADP is capable of showing application structure and component relationships at two levels: module and component levels. At each level, ADP can show both active and potential call paths. Table 15-4 describes various types of Architecture Views.

Drill down on a specific application to launch into the Architecture View. This action demonstrates the logical progression of drilling from high level resource-centric topology view, down through application-centric topology view, to module-centric architecture view. Using this logical drill down, you can understand the structure of your application runtime environments and diagnose problems.

Table 15-4 Various Types of Architecture View

Tab Name

Description

Module Level Execution

This is the default Architecture View at the module level. The Module Level Execution view shows the active calling relationships among various Java EE modules (EAR, WAR, JAR, and so on). Shared resources are also included.

Module Level

The Module Level view shows the potential calling relationships among various Java EE modules. Shared resources are also included. It should also be noted that any object that is not connected within the static view will not be included at this level and if there are no static connections at all between objects, every potential object relationship will be displayed. By default, the Module Level view is not enabled.

Component Level Execution

This is the default Architecture View at the component level. The Component Level Execution view shows the active calling relationships among different Java EE components (EJB, servlet, JSP, and so on). Shared resources are also included.

Component Level

The Component Level view shows the potential calling relationships among various Java EE components. Shared resources are also included. Similar to the module level, any object that is not connected within the static view will not be included at this level and if there are no static connections at all between objects, every potential object relationship will be displayed. By default, the Component Level view is not enabled.

These various types of architecture views are color coded in order to provide additional information. Table 15-5 lists color codes and their meanings.

Table 15-5 Architecture View Color Codes

Background Color

Description

Orange

The orange background color represents entry points into the application or module. The orange color also represents that these entities belong to the same application or module currently selected (in context).

Green

The green background color represents entry points into the application or module. The green color also represents that these entities belong to other applications or modules (out of context). The green color is also used to represent share resources.

White

The white background color represents that these entities belong to the same application and module currently selected (in context).

Blue

The blue background color represents that these entities belong to other applications and modules (out of context). The blue color also represents shared resources.

ADP graphically depicts active calling relationships among various Java EE modules and shared resources.

15.1.15.1 Accessing the Architecture View

There are several ways to access the Architecture View. One way is through the Deployments node associated with a specific application under the Application Node. Application specific Architecture View can be accessed using the Deployments node on the Oracle Tree.

The last way to access the Architecture View is by right-clicking a managed entity and selecting the Architecture View. Right-click and select Architecture View to start the drill down process.

15.1.15.1.1 Arrows in Architecture Views

The arrows connecting various entities in the Architecture Views depict calls made from one entity to another. You can get more information about a specific call by pointing the mouse over a specific arrow. Mousing over arrows shows the details of a specific call in Architecture View

It is possible to hide different types of arrows in the Architecture View. To do this, right-click on the Architecture View and highlight the Edge types option to reveal a list of different edge (arrow) types associated with current Architecture View. Unchecking a specific edge type hides all lines of that type in the Architecture View. Checking a specific edge type makes these lines appear.

To hide all lines not connected with a specific entity, select a monitored entity in the Architecture View, right-click and select Hide other edges. Highlight an entity and select Hide other edges to hide all arrows not connected to the managed entity.

15.1.15.1.2 Architecture View Summary

The Architecture View Summary provides the delay analysis associated with the active call path displayed. The table and pie chart displayed in the right pane guides you to leading delay contributors in the displayed call path. Selecting a specific component in the call path brings up component specific information. You will see the following tabs:

- Summary tab first which includes high-level delay data for both inbound and outbound calls.

- The Instrumentation tab shows detailed method level performance data associated with the selected component. Click the Instrumentation tab to see detailed performance measurements and information at the method level.

- The Errors/Exceptions tab shows the errors metrics associated with the selected portal or BPEL process.

- The SQL Statement tab shows SQL statements and their performance data associated with the selected component.

- The Transactions tab shows the transaction events associated with the selected portal and children below. By default, the Transactions tab is not enabled.

15.1.16 Metric Types

Table 15-6 describes various types of metrics provided by ADP.

Table 15-6 Metric Types

Examples

Metric Type

Metric Description

Active Sessions

Completions

Pending Requests

Running Instances

Max Capacity

Messages High

Snapshot Count

A count of the monitored entity at a point in time. ADP plots these snapshot counts in trend graphs.

Requests Serviced

Total Sessions

[Processes] Aborted

[Processes] Terminated

[Method] Invocation Count

Bytes Received

Aggregated Count

A count of the monitored entity incrementally aggregated from the beginning of display time window. ADP shows these aggregated counts in summary tables.

Response Time

Elapse Time

Connection Delay

Average Timing

Calculated every sampling period (default 60 seconds), the average timing is calculated by dividing the total amount of time needed to complete the monitored business unit of work by the number of completed business units of work.

ADP uses this data in the following two ways:

1. Plot the average timings in trend graphs.

2. Calculate average timing of this business unit of work for the display time window and display in a summary table.

Min/Max

Minimum and Maximum Response Time Measurement

Minimum and maximum response time measurements found per collection sampling intervals. These are stored in their embedded database in addition to average response time measurements. The default is 60 seconds.

15.2 Exploring the Monitoring Tab

When ADP is pointed to a Oracle WebLogic domain, IBM WebSphere cell, or an Oracle SOA Suite cluster, it automatically discovers information about this particular domain including all deployed applications, configuration, resources, and others. ADP displays this information in the Monitoring tab under Oracle Enterprise Manager.

Each node represents a construct in the platforms monitored by ADP. Each construct is described in this section.

This section includes the following topics:

- Monitoring ADP Entities

- WebLogic

- Oracle WebLogic Portals

- WebSphere Portals

- Oracle BPEL Processes

- Oracle ESB

- Oracle WebCenter

- Processes

- Web Services

- Pageflows

- Services

- WSRP Producers

- Integration

- Applications

- Oracle WebLogic Resources

- WebSphere Resources

- Oracle Resources

- Custom Metrics

- ADP Node

- Service Component Architecture (SCA)

15.2.1 Monitoring ADP Entities

Performance can be monitored for the ADP entities:

- SOA Suite 11g

- OSB Applications

- Java EE Applications

- ADF Applications

15.2.1.1 Monitoring SOA Suite 11g Performance

To monitor the performance of service-oriented architecture applications (SOA), perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the SOA Infrastructure target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.

2. Click the Monitoring tab.

3. ADP discovers all the deployed Composites on the configured Oracle WebLogic Domain.

4. A Composite node appears under the configured ADP Manager (for example, select Oracle Enterprise Manager, select SOAServer, then select Composites).
Under the Composites node, the following nodes appear:

- SCA Partition

- Composite

- Services

- Components

- References

- Wires

The performance metrics are displayed on the right-hand side panel when the respective node is selected.

15.2.1.2 Monitoring OSB Performance

To monitor the performance of Oracle Service Bus (OSB) applications, perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the OSB target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.

2. Click the Monitoring tab, then select OSB in the tree.

3. ADP discovers all the deployed OSB proxy and business services on the configured Oracle WebLogic Domain.

4. An OSB node appears under the configured ADP Manager (for example, select Oracle Enterprise Manager, select servicbusServer, then select OSB).
Under the OSB node, the following nodes appear:

- Business Services

- Proxy Services

- Pipeline

- References

The performance metrics are displayed on the right-hand side panel when the respective node is selected.

15.2.1.3 Monitoring Java EE Application Performance

To monitor the performance of Java EE applications, perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the Java EE Application target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.

2. Click the Monitoring tab, then select the application in the tree.

3. ADP discovers Java EE artifacts like Servlet/JSPs, EJBs, and Web services.

4. You can find Java EE Application related data under following nodes:

- Applications

- Web Services

- Services

The performance metrics for related components are displayed on the right-hand side panel when the respective component is selected.

15.2.1.4 Monitoring ADF Application Performance

To monitor the performance of Application Development Framework (ADF) applications, perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the ADF target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.

2. Click the Monitoring tab, then select the application in the tree.

3. ADP discovers all the deployed ADF artifacts on the configured Oracle WebLogic Domain release 11gR1.

4. An ADF node appears under the configured ADP Manager (for example, Oracle Enterprise Manager, select Server, then select ADF ). The ADF node contains the following:

- ADF taskflows

- JSF Pages

- Managed Beans

- Business Components

The performance metrics for related components are displayed on the right-hand side panel when the respective component is selected.

15.2.2 WebLogic

You can perform the following on WebLogic using Application Dependency and Performance.

- Monitor a WebLogic portal

- Add a WebLogic domain to be monitored by an existing ADP manager

- Remove a WebLogic Domain from monitoring

15.2.2.1 Monitoring WebLogic Portal Performance

Perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. In the Related Links section, click Application Dependency and Performance link.

2. Click the Monitoring tab, then select the application in the tree.

3. ADP discovers portal on the configured Oracle WebLogic Domain.

4. A Portals node appears under the configured ADP Manager (for example, Oracle Enterprise Manager, select PortalServer, then select Portals ). The Portals node contains the following:

- Portal Desktop, which is made up of Books, which are in turn made up of Pages, which in turn are made up of Portlets

The performance metrics for related components are displayed on the right-hand side panel when the respective component is selected.

15.2.2.2 Adding WebLogic Domain To Be Monitored By Existing ADP Manager

To add a WebLogic domain to be monitored by an existing ADP manager, perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the WebLogic target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.

2. Click the Configuration tab and expand the Configuration (Manager Name). Click Resource Configuration and provide the details.

15.2.2.3 Removing a WebLogic Domain From Monitoring

To remove a WebLogic domain from being monitored, perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. In the Related Links section, click Application Dependency and Performance.

2. Click the Configuration tab and expand the Configuration (Manager Name). Click Resource Configuration, choose the resource, and click Delete Resource.

15.2.3 Oracle WebLogic Portals

The Portals node under Oracle Enterprise Manager contains information about all deployed WebLogic Portal applications in the managed domains. The Portals node is organized hierarchically using the same framework developers use to build these Portal applications. The minimum and maximum response time measurements are stored in the database in addition to the average response time measurements. These metrics, if present, display visually in the Main Display Window on the right.

For WebLogic Portal, this hierarchy contains the following (Table 15-7):

Table 15-7 WebLogic Portal Hierarchy

Component

Description

Portals

The Portal is the logical containment unit for a Portal application. A typical Portal can contain a few desktops, several books, tens of pages, and hundreds of portlets.

Desktops

The desktop is the top-level container for the portal components included in that specific view of the portal.

Portal administrators can create new desktops beyond what portal developers create in WebLogic Workshop.

Books

The top-level book contains all sub-books, pages, and portlets. The top-level book defines the initial menu navigation style used for the desktop. For each sub-book you add to a desktop you can select a different navigation style.

Pages

Pages and sub-books are the navigable containers used for organizing portlets.

Portlets

Portlets are the containers that surface Web content and applications in your desktops.

When you click the Portals node under Oracle Enterprise Manager, ADP displays summary information on active portal applications. This summary includes the following (Table 15-8):

Table 15-8 Tree Summary

Metric

Description

Portal web application activity

A summary of user sessions for a specific portal application

Portal completions

Total number of requests fulfilled by a specific portal application

Portal response time (ms)

Average response time for a specific portal application

Portal entitlement response time

Average response time of WebLogic Portal entitlement subsystem for a specific portal application

Portal campaign response time

Average response time of WebLogic Portal campaign subsystem for a specific portal application

For Portal web application activity and Portal performance, ADP displays information in both table and graph formats. For the other metrics, ADP shows the information in graph format. When you click the plus (+) icon next to the Portals node, ADP expands the tree to show all managed portal applications currently deployed on the WebLogic domain.

You can also see information specific to a particular portal application. By selecting a specific portal application, all information displayed in the Main Display Window changes to only show data relevant to this new context. For example, when a user selects a particular portal application under the Portals node, the Main Display Window only shows information specific to that portal application.

At the Portal level, you can navigate to different levels of the portal application by using different tabs. Use the tabs available to quickly access lower level components. Table 15-9 provides a list of the tabs available for portal level nodes and their descriptions.

Table 15-9 Portal Level Tab Description

Tab

Description

Summary

Performance summary specific to the selected portal.

Desktops

Performance summary for all the desktops associated with the selected portal.

Headers

Performance summary for all the headers associated with the selected portal.

Books

Performance summary for all the books associated with the selected portal.

Pages

Performance summary for all the pages associated with the selected portal.

Portlets

Performance summary for all the portlets associated with the selected portal.

Footers

Performance summary for all the footers associated with the selected portal.

WSRP Topology

View WSRP consumer-producer relationships and WSRP deployment topology.

Analysis

Two performance analytics - Multi-Point Regression Analysis performed at the portal level and Entity Performance Ranking performed at the portlet level.

Events

SLO violation events associated with the selected portal.

Errors/Exceptions

Errors metrics associated with the selected portal.

Transactions

Transaction events associated with the selected portal and children below. Be default, the Transactions tab is not enabled. To enable the Transactions tab, enable the UIProvider.Modes=product,trace property in the Acsera.properties file before starting the manager.

15.2.3.1 Desktops

Expand a particular portal application further to reach the Desktops node. By selecting the Desktops node, ADP provides a list of currently active desktops associated with that portal application.

This Desktop Summary includes the following metrics:

Table 15-10 Desktop Summary Metrics

Metrics

Description

Desktop arrivals

Total number of requests for a specific desktop

Desktop completions

Total number of requests fulfilled by a specific desktop

Desktop response time (ms)

Average response time for a specific desktop.

Note:
Portal desktops are end-user facing entities. Metrics such as Desktop hits and response time represents request arrival rate and application performance respectively. Violations in thresholds set on these metrics would indicate unacceptable end-user experience.

ADP displays these metrics in both table and graph formats.

For example, when you have two active desktops, you can drill down further to a specific desktop by expanding the Desktops node. Again, clicking on the plus (+) icon expands the tree view for you.

When you select a node in the expanded tree to get more information specific for that desktop, ADP changes information in the Main Display Window to reflect the new context.

ADP not only shows the performance metrics associated with a specific node, but it also displays other relevant settings for that node. For example, there can be pre-configured Service Level Objectives (SLOs). These SLOs are displayed in the graphs as red lines.

Expand the desktop node to see Header, Footer, and Books. You can see detailed information for these components by clicking on the appropriate nodes.

15.2.3.1.1 Display Portal Desktop - Desktop Structure Viewer

One of the unique capabilities of ADP is its automatic discovery and modeling of deployed applications. The Desktop Structure Viewer provides visibility into how a portal desktop is organized. To activate the Desktop Structure Viewer, right-click on a specific desktop. Select the Display Portal Desktop menu option to access the Desktop Structure Viewer.

After the Desktop Structure Viewer appears, you can navigate through the portal desktop structure by clicking on the appropriate book, page, or portlet. The ability to see portal desktop structure using the same perspective as portal end-users is a unique value especially for the IT support staff.

With the Desktop Structure Viewer, the IT support staff can speak the same language with end-users while at the same time looking at performance oriented information for a specific component. The IT support staff can also use the Desktop Structure Viewer to isolate a particular performance problem. By drilling down from the top-level desktop to individual portlets, the IT support staff can get more insight into which components are having performance problems.

The Desktop Structure Viewer consists of two main panes. The pane on the left is the Desktop Structure pane. This pane allows you to graphically navigate the portal desktop. The pane on the right is called the Main Display Window. The Main Display window displays performance information in the context of the selected component in the Desktop Structure pane. As you navigate through the portal desktop and click different components, the Main Display Window provides information relevant for that selected context.

The Main Display Window shows relevant performance metrics for different portal desktop components - desktop, books, pages, and portlets.

Since ADP understands the WebLogic Portal framework and knows that a pageflow can be associated with a portlet, it is designed to allow easy access to the Pageflow Viewer from the Desktop Structure Viewer.

To activate the Pageflow Viewer, double-click the interesting portlet. In turn you can double-click the portlet in the Desktop Structure pane to open the appropriate pageflow in the Pageflow Viewer.

15.2.3.2 Portlet Drill Down

You can drill down on a portlet in the portal desktop view to activate the Display Architecture View.

1. Select a portlet under a node.

2. Double-click on a name to see the Portal Desktop Status page.

3. In the Portal Desktop Status window, right-click on a service box to select Display Architecture View.

15.2.3.3 Pageflow Viewer

The Pageflow Viewer has two panes. The pane on the right is the Main Display Window. The Main Display Window shows information corresponding to the item selected in the left pane. The left pane shows either the Flow View or the Component View. You can choose to see either the Flow View or the Component View by selecting the appropriate tab.

The Main Display Window changes to show information relevant to the selected item in either the Flow View or the Component View.

15.2.3.4 Books

Expand a particular portal desktop further to see the Books node. By selecting the Books node, ADP provides a list of currently active books associated with the specific desktop.

This Books Summary includes the following metrics (Table 15-11):

Table 15-11 Book Summary Metrics

Metrics

Description

Book completions

Total number of requests fulfilled by a specific book

Book response time (ms)

Average response time for a specific book

ADP displays these metrics in both table and graph formats. For example, you can have two active books for the portal desktop. These active books are listed in the table and plotted in the graphs.

You can drill down further to a specific book by expanding its node. Click the plus (+) icon to expand the tree view. Expand the Books node to see a list of specific books configured.

When you select a particular active book, the Main Display Window shows the relevant information in that context.

15.2.3.5 Pages

Expand a particular book to see the Pages node. By selecting the Pages node, ADP provides a list of currently active pages associated with the specific book.

This Pages Summary includes the following metrics (Table 15-12):

Table 15-12 Pages Summary Metrics

Metrics

Description

Page completions

Total number of requests fulfilled by a specific page

Page response time (ms)

Average response time for a specific page

ADP displays these metrics in both table and graph formats. For example, you can have one active page for a book. The active page is listed in the table and plotted in the graphs.

You can drill down further to a specific page by expanding the Pages node. Click the plus (+) icon to expand the tree view. This reveals the next level of components - Portlets.

15.2.3.6 Portlets

Expand a particular page to see the Portlets node. Select a Portlets node to view a list of currently active portlets associated with the specific page.

This Portlets Summary includes the following metrics (Table 15-19):

Table 15-13 Portlet Metrics

Metrics

Description

Portlet completions

Total number of requests fulfilled by a specific portlet.

Portlet response time (ms)

Average response time for a specific portlet.

ADP displays these metrics in both table and graph formats. For example, you can have four active portlets for a particular page. These active portlets are listed in the table and plotted in the graphs.

Drill down further to a specific page by expanding the Portlets node. Click the (plus) + icon to expand the tree view. This provides additional information about the page.

15.2.4 WebSphere Portals

The Portals node under Oracle Enterprise Manager contains information about all deployed WebSphere Portal applications in the managed cells. The Portals node is organized hierarchically using the same framework developers use to build these Portal applications. The minimum and maximum response time measurements are stored in the database in addition to the average response time measurements. These metrics, if present, display visually in the window on the right pane.

For WebSphere Portal, this hierarchy contains the following (Table 15-14):

Table 15-14 WebSphere Portal Hierarchy

Component

Description

Portals

The Portal is the logical containment unit for a Portal application. A typical Portal can contain a few desktops, several of books, tens of pages, and hundreds of portlets.

WebSphere

The WebSphere is the top-level container for the portal components included in that specific view of the portal.

Portal administrators can create new desktops beyond what portal developers create in WebLogic Workshop.

Virtual Portals

The top-level book contains all sub-books, pages, and portlets. The top-level book defines the initial menu navigation style used for the desktop. For each sub-book you add to a desktop you can select a different navigation style.

Content Root

Pages and sub-books are the navigable containers used for organizing portlets.

Header

Portlets are the containers that surface Web content and applications in your desktops.

Pages

Pages are containers within virtual portals, books, and sub-books. Pages often contain labels and portlets.

Labels

Labels are markers defining content within page containers.

When you click the Portals node under Oracle Enterprise Manager, ADP displays summary information on active portal applications. This summary includes the following (Table 15-15):

Table 15-15 WebSphere Tree Summary

Metrics

Description

Portal web application activity

A summary of user sessions for a specific portal application.

Portal completions

Total number of requests fulfilled by a specific portal application.

Portal response time (ms)

Average response time for a specific portal application.

For Portal web application activity and Portal performance, ADP displays information in both table and graph formats. For the other metrics, ADP shows the information in graph format.

When you click the plus (+) icon next to the Portals node, ADP expands the tree to show all managed portal applications currently deployed on the WebLogic domain.

You can also see information specific to a particular portal application. By selecting a specific portal application, all information displayed in the Main Display Window changes to only show data relevant to this new context. For example, when a user selects the WebSphere portal application under the Portals node, the Main Display Window only shows information specific to WebSphere portal application.

At the Portal level, you can navigate to different levels of the portal application by using different tabs. Use the tabs available to quickly access lower level components.

The following is a list of the tabs available for portal level nodes and their descriptions (Table 15-16).

Table 15-16 Portal Level Tab Descriptions

Tab

Description

Summary

Performance summary specific to the selected portal

Analysis

Two performance analytics - Multi-Point Regression Analysis performed at the portal level and Entity Performance Ranking performed at the portlet level

Events

SLO violation events associated with the selected portal

WSRP Topology

View WSRP consumer-producer relationships and WSRP deployment topology

Errors/Exceptions

Errors metrics associated with the selected portal

Instrumentation

Includes performance data by different types of instrumentation probe points. There are different tabs available: Class, Method, Errors/Exceptions and Transactions. Each tab includes basic information such as Probe Point Name, Invocation Count, and Response Time. This detailed performance data can help you identify low-level bottlenecks. Refer to Section 15.2.8.3, "Instrumentation" for more details.

15.2.4.1 Virtual Portals

To reach the Virtual Portals node, further expand a particular portal application. By selecting this node, ADP provides a list of currently active portals associated with that portal application. See to view the Summary for the WebSphere portal application.

This Summary includes the following metrics (Table 15-17):

Table 15-17 Virtual Portals Summary Metrics

Metrics

Description

Virtual Portal Completions

Total number of requests fulfilled by a specific portal.

Virtual Portal Response Time (ms)

Average response time for a specific portal.

ADP displays these metrics in both table and graph formats. For example, you can have one active portal for the WebSphere portal application. The Content Root is listed in the table and Plotted in the graphs.

You can drill down further to specific portlets by expanding the Content Root node. Again, clicking on the plus (+) icon expands the tree view for you. ADP changes information in the Main Display Window to reflect new context - portlet.

ADP not only shows the performance metrics associated with a specific node, but it also displays other relevant settings for that node.

15.2.4.1.1 Display Virtual Portal - Structure Viewer

One of the unique capabilities of ADP is its automatic discovery and modeling of deployed applications. The Structure Viewer provides visibility into how a portal desktop is organized. To activate the Virtual Portal Viewer, right-click on a specific portal. Select the Display Virtual Portal menu option to access the viewer.

After the Structure Viewer appears, you can navigate through the portal structure by clicking the appropriate header. The ability to see the portal structure using the same perspective as portal end-users is a unique value especially for the IT support staff.

With the Structure Viewer, the IT support staff can speak the same language with end-users while at the same time looking at performance oriented information for a specific component. The IT support staff can also use the Structure Viewer to isolate a particular performance problem. By drilling down from the top-level desktop to individual portlets, the IT support staff can get more insight into which components are having performance problems.

The Structure Viewer consists of two main panes. The pane on the left is the Structure Viewer pane. This pane allows you to graphically navigate the portal desktop. The pane on the right is called the Main Display Window. The Main Display window displays performance information in the context of the selected component in the Desktop Structure pane. As you navigate through the portal desktop and click different components, the Main Display Window provides information relevant for that selected context.

The Main Display Window shows relevant performance metrics for different portal components.

15.2.4.2 Pages

Expand a particular portal to see the Pages node. By selecting the Pages node, ADP provides a list of currently active pages associated with the specific book.

This Pages Summary includes the following metrics (Table 15-18):

Table 15-18 Pages Summary Metrics

Metrics

Description

Page Completions

Total number of requests fulfilled by a specific page

Page Response Time (ms)

Average response time for a specific page

ADP displays these metrics in both table and graph formats.

15.2.4.3 Portlets

Expand a particular page to see the Portlets node. Select a Portlets node to view a list of currently active portlets associated with the specific page.

This Portlets Summary includes the following metrics (Table 15-19):

Table 15-19 Portlet Metrics

Metrics

Description

Portlet Completions

Total number of requests fulfilled by a specific portlet

Portlet Response Time (ms)

Average response time for a specific portlet

ADP displays these metrics in both table and graph formats. For example, you can have four active portlets for the Content Root page. These active portlets are listed in the table and plotted in the graphs.

Drill down further to a specific page by expanding the Portlets node. Click the plus (+) icon to expand the tree view.

15.2.5 Oracle BPEL Processes

The BPEL Processes node in the navigation tree contains information about all deployed Oracle BPEL processes within the managed domain. ADP organizes information for various process nodes into domains.

In the right-hand pane, you can view the minimum and maximum response time measurements stored in the database in addition to the average response time, arrivals, errors, and completions measurements. These metrics, if present, display visually in the window on the right pane.

When you select the root of the BPEL Processes tree, ADP displays the BPEL Processes Summary in the Main Display Window.

The BPEL Process Summary includes the following (Table 15-20):

Table 15-20 BPEL Process Summary Metrics

Metrics

Description

Domain

Name of the OC4J domain container

Process

Name of the BPEL process

Arrivals

Total number of currently running instances for a specific BPEL process

Response Time (ms)

Average response time in milliseconds for a specific BPEL process

Completions

Total number of fulfilled requests for a specific BPEL process. A Completed status represents a BPEL process instance that has finished normally.

Errors

Total number of aborted instances of a specific BPEL process

Min Response Time (ms)

Minimum average response time in milliseconds for a specific BPEL process

Max Response Time (ms)

Maximum average response time in milliseconds for a specific BPEL process

ADP presents these metrics in a table format in the Main Display Window when you select the BPEL Processes node. Graphical representations of two metrics, Arrivals and Completions, are displayed below the table.

When you click the plus (+) icon next to the domains sub-node under the main BPEL Processes node, ADP expands the tree to show all managed BPEL domains currently deployed on that particular Oracle SOA Suite instance.

You can see information specific to a particular process. By selecting a specific process, all information displayed in the Main Display Window changes to only show data relevant to this new context.

To see the BPEL process work flow associated with a BPEL process, select the node, right-click and select the Display Functional View option. ADP displays the appropriate functional work flow diagram and associated performance data in a new pop-up window.

See Table 15-21 for BPEL Functional View summary.

Table 15-21 BPEL Functional View Summary

Column/Metric

Description

Activity

Name of a specific activity in the BPEL process

Type

Control Type for a specific node

Arrivals

Number of requests that have arrived for a specific node

Response Time (ms)

Average response time for a specific node

Completions

Number of completed requests for a specific node

Errors

Number of aborted instances for a specific node

Response Time Min (ms)

Minimum response time for a specific node

Response Time Max (ms)

Maximum response time for a specific node

By looking at this summary table, you can determine which BPEL process node is running slowly and whether there are errors.

In addition to the summary, the following views are available for a node:

- Delay Analysis view

- Metadata view

- Partner Links view

- Partner Link Type Role view

- Partner Link Bindings view

- Modeled Entities view

- Topology view

You can get to these views by selecting the appropriate tab.

15.2.5.1 Delay Analysis View

Delay Analysis gives you a bird's eye view of a specific BPEL process. You can see what nodes in the BPEL process are taking up a majority of the average elapsed time. The red bar indicates the slowest BPEL process group or BPEL process node. The blue represents the time spent for the particular nodes.

15.2.5.2 Metadata View

The Metadata view displays the tables containing specific metadata associated with the selected active BPEL process being displayed in the left-hand pane. Information provided in this view includes caller and called class metadata information as well as general summarized metadata in relation to the BPEL process and the associated web services. Table 15-22 explains the metadata.

Table 15-22 Metadata View Summary

Column/Metric

Description

SummaryTable -Process

Name of the BPEL process node

SummaryTable -Web Service

Name of the web service being called from the BPEL process

SummaryTable -Version

Version of the web service being called from the BPEL process

SummaryTable -Location

Location of the web service being called from the BPEL process

Caller Table - Caller Class

Class name for the caller class that is calling the BPEL process

Caller Table - Caller Method

Class method for the caller class that is calling the BPEL process

Caller Table -Target Host

Target host that the caller class targeted to instantiate the BPEL process

Caller Table -Target Port

Target port that the caller class targeted to instantiate the BPEL process

Caller Table -Target URL

Target URL that the call class targeted to instantiate the BPEL process

Caller Table - Invocation Count

Number of invocations of the BPEL process instantiated by the caller class

Caller Table - Response Time

Average response time of the BPEL process instantiated by the caller class

Called Clients Table - Called Class

Class name of the class that was called by the BPEL process

Called Clients Table - Target URL

Target URL of the class that was called by the BPEL process

Called Clients Table - Invocation Count

Number of invocations made from the BPEL Process to the called class.

Called Clients Table - Response Time

Response time of the called class

15.2.5.3 Partner Links View

The partner links view provides detailed information on the various roles related to how and why the partner link service is being utilized. The information provided includes both the caller and callee roles, as well as the partner link type. See Table 15-23.

Table 15-23 Partner Links View Summary

Column/Metric

Description

Partner Link

Name of the partner link

My Role

Role in regards to the BPEL process calling the partner link service

Partner Role

Role of the partner link service

Partner Link Type

Partner link category (type) of the service being called

15.2.5.4 Partner Link Type Role View

See Table 15-24 describes the columns in the Partner Link Type Role view.

Table 15-24 Partner Link Type Role View Summary

Column/Metric

Description

Name

Name of the partner link

Link Type Name

Category (type) of the partner link

Port Type

Partner link service URL

15.2.5.5 Partner Link Bindings View

The Partner Link Bindings view provides insight into the actual roles and types of the partner link instances which represent web services that have been bound by the BPEL process. See Table 15-25.

Table 15-25 Partner Link Bindings View Summary

Column/Metric

Description

Partner Link Role

Defines the web service role that the BPEL process will communicate with

Partner Link Type

Defines the web service type that the BPEL process will communicate with

WebService PortType

Name of the web service

WebService Port Namespace ID

URL of the webservice instance

15.2.5.6 Modeled Entities View

The modeled entities view consist of a list and count of the general entities as catalogued during the discovery phase of the resource configuration. The tables contain both a total entity count as well as a breakdown of the entity count by entity type. See Table 15-26.

Table 15-26 Modeled Entities Summary

Column/Metric

Description

Total Entities Modeled Table - Total

Total entities (static label)

Total Entities Modeled Table - Count

Total number of entities catalogued during the discovery phase of the BPEL process

Modeled Entities Table - Entity Type

Entity type being catalogued as part of the discovery phase of the BPEL process

Modeled Entities Table - Count

Total number of entities catalogued during the discovery phase of the BPEL process for a particular entity type

15.2.5.7 Topology View

The Topology View utilizes the modeled entities that were captured during the discovery process to provide a bird's eye view of all of the various high-level relationships between BPEL processes, web services, and business services. You can toggle between static and dynamic relationship views using the tabs at the top of the Topology pane.

15.2.5.8 Node Hierarchy

Expanding a particular BPEL process further, the first item you see is the Node Hierarchy node. By selecting the Node Hierarchy node, ADP provides a list of nodes associated with the specific process.

When you click the plus (+) icon next to a specific Node Hierarchy node, ADP expands the tree to show BPEL process nodes in the Node Hierarchy. Click an individual BPEL process node to see the load and performance of the selected node in the Main Display Window.

The BPEL process node information also includes the name of the method invoked. This information is displayed as part of the summary table at the top of the main view window.

15.2.6 Oracle ESB

The Oracle ESB node under Oracle Enterprise Manager contains information about all of the deployed Oracle ESB servers running in the managed domain. ADP organizes the information for various Oracle ESB nodes into various categories.

When you select the root of the ESB tree, ADP displays the ESB Summary in the Main Display Window.

The ESB Summary includes the following (Table 15-27):

Table 15-27 ESB Summary Metrics

Metric

Description

ESB System

Name of ESB System

ESB Service

Name of the ESB Service identifier

Arrivals

Total number of ESB service instance arrivals

Completions

Total number of ESB service instance completions

Response Time

Total number of completed instances for a specific BPEL process. A Completed status represents a BPEL process instance that has finished normally.

ADP presents these metrics in a table format in the Main Display Window when you select the ESB node. When you click the plus (+) icon next to the ESB Systems sub-node under the main ESB node, ADP expands the tree to show all managed ESB Systems currently deployed on that particular Oracle SOA Suite instance.

You can see information specific to a particular ESB System. By selecting a specific ESB System, all information displayed in the Main Display Window changes to only show data and the topology relevant to this new context.

By looking at the summary table, you can find out which ESB node is running slowly and whether there are errors.

Besides the summary, the following views are available for the Node Hierarchy node:

- Service Details view

- Service Parent Details view

- Service Definition view

- Service Operations view

- Operation Routing Rules view

- Topology view

You can get to these views by selecting the appropriate tab.

15.2.6.1 Service Details View

The Service Details view provides specific information related to the details of the bound service process instances. Instance IDs and other descriptive details are included as part of this view. See Table 15-28.

Table 15-28 Service Details View Summary

Column/Metric

Description

Service Name

Name of the ESB service

GUID

GUID of the ESB service

Qname

Canonical qualified name for the bound ESB service

Description

Description of the ESB service

15.2.6.2 Service Parent Details View

The Parent Service Details view provides specific information related to the details of the parent of the bound service process instances. Instance IDs, roles, and other descriptive details are included as part of this view. See Table 15-29.

Table 15-29 Service Parent Details View Summary

Column/Metric

Description

Service Name

Name of the parent ESB service

ParentGUID

GUID of the parent ESB service

ParentQname

Canonical qualified name for the parent of the bound ESB service

ParentType

Parent type of the parent ESB service

MyRole

Role of the caller of the parent ESB service instance

ParentRole

Role of the callee of the parent ESB service instance

15.2.6.3 Service Definition View

The Service Definition view contains information regarding the bound ESB service including the Business Service (ESB) WSDL and Port Type as well as the associated URLs. See Table 15-30.

Table 15-30 Service Definition View Summary

Column/Metric

Description

Service Name

Name of the ESB service

BusinessServiceWSDL

URL of the Business Service WSDL

BusinessServicePortType

Port type of the Business Service

ConcreteServiceWSDL

URL of the Concrete Service WSFL

ConcreteServiceURI

URI for the concrete service

15.2.6.4 Service Operations View

The Service Operations views provides details regarding the various method operations being executed. All information is provided in regards to the metadata associated with a specific business service instance. See Table 15-31.

Table 15-31 Service Operations View Summary

Column/Metric

Description

Service Name

Name of the ESB service

Name

Service operation name being executed

GUID

GUID of the ESB service

Qname

Canonical qualified name for the bound ESB service

Element

Associated element within the ESB Service

SchemaLocation

Schema location for the associated ESB service

Type

Type of ESB service operation

15.2.6.5 Operation Routing Rules View

The Operation Routing Rules view provides various details regarding the operation routing rules for Business Service operations. This includes the specific instance business service names being utilized for operations. See Table 15-32.

Table 15-32 Operation Routing Rules View Summary

Column/Metric

Description

Service Name

Name of the ESB service

Name

Instance name ID of the ESB service instance

GUID

GUID of the ESB service instance

15.2.7 Oracle WebCenter

Oracle WebCenter provides a set of features and services (for example, portlets, customization, and content integration) that simplify the process of reaching a solution with JSF applications. This solution brings information from multiple sources into a single interface, simplifying transactions and providing everything users need to support a given task within the application itself.

Table 15-33 WebCenter Tree Summary

Component

Description

ADF Business Components

ADF business component

ADF Data Controls

ADF data controls

ADF Taskflows

ADF task flows provide a modular approach for defining control flow in an application. See Section 15.2.7.1, "ADF Task Flows".

JSF Pages

JSF page definition files define the binding objects that populate the data in UI components at runtime. See Section 15.2.7.2, "JSF Pages".

Portlets

Portlets are the containers that surface Web content and applications on desktops. See Section 15.2.7.3, "Portlets".

15.2.7.1 ADF Task Flows

Instead of representing an application as a single large JSF page flow, you can break it up into a collection of reusable task flows. Each task flow contains a portion of the application's navigational graph. The nodes in the task flows are activities. An activity node represents a simple logical operation such as displaying a view, executing application logic, or calling another task flow. The transactions between the activities are called control flow cases. A task flow consists of activities and control flow cases that define the transitions between activities.

15.2.7.1.1 User-Defined Taskflows

The following taskflows are available in WebCenter.

Table 15-34 Taskflow Activities

Activity Name

Description

Managed Beans

A backing bean that is managed by the JSF framework and used during the JSF page lifecycle.

Taskflow Method Calls

Invokes a method, typically a method on a managed bean.

Taskflow Views

Displays a JSF page or page fragment. Multiple view activities can represent the same page or same page fragment.

Taskflow URL Views

Redirects the root view port (for example, a browserpage) to any URL-addressable resource, even from within the context of an ADF region.

Taskflow Calls

Calls an ADF bounded task flow from an ADFunbounded task flow or another bounded task flow

Routers

Evaluates an EL expression and returns an outcome based on the value of the expression. For example, a router in a credit check task flow might evaluate the return value from a previous method call and generate success, failure, or retry outcomes based on various cases. These outcomes can then be used to route control to other activities in the task flow.

15.2.7.1.2 Web 2.0 Service

Oracle WebCenter provides a wide range of Web 2.0 capabilities, including discussion forums, wikis, blogs, content services, RSS, presence, instant messaging, linking, tagging, and search. Both developers and business users can easily add these services to their pages to maximize productivity.

Table 15-35 Taskflow Activities

Activity Name

Description

Managed Beans

A backing bean that is managed by the JSF framework and used during the JSF page lifecycle.

Taskflow Method Calls

Invokes a method, typically a method on a managed bean.

Taskflow Views

Displays a JSF page or page fragment. Multiple view activities can represent the same page or same page fragment.

Taskflow URL Views

Redirects the root view port (for example, a browserpage) to any URL-addressable resource, even from within the context of an ADF region.

Taskflow Calls

Calls an ADF bounded task flow from an ADFunbounded task flow or another bounded task flow

Routers

Evaluates an EL expression and returns an outcome based on the value of the expression. For example, a router in a credit check task flow might evaluate the return value from a previous method call and generate success, failure, or retry outcomes based on various cases. These outcomes can then be used to route control to other activities in the task flow.

15.2.7.2 JSF Pages

A typical JSF application couples a backing bean with each page in the application. The backing bean defines properties and methods that are associated with the UI components used on the page. The UI component's value is bound to the bean's property.

A Managed Bean is a backing bean that is managed by the JSF framework and used during the JSF page lifecycle.

15.2.7.3 Portlets

Portlets can display excerpts of other Web sites, generate summaries of key information, perform searches, and access assembled collections of information from a variety of data sources. You can use the portlets that Oracle or third parties provide, or create your own programmatically. Oracle WebCenter supports WSRP 1.0, WSRP 2.0, JSR 168, and Oracle PDK-Java. You can include any portlets adhering to those standards in your WebCenter applications.

15.2.7.4 Monitoring WebCenter Performance

Perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the WebCenter target. On the Home tab, select the Summary region and click the Application Dependency and Performance link.

2. Click the Monitoring tab, then select the application in the tree.

3. ADP discovers the deployed WebCenter ADF artifacts on the configured Oracle WebLogic Domain.

4. A WebCenter node appears under the configured ADP Manager (for example, Oracle Enterprise Manager, select Server, then select WebCenter ). The WebCenter node contains the ADF Application Name and the following subnodes:

- ADF Taskflows

- JSF Pages

- Managed Beans

The performance metrics for related components are displayed on the right-hand side panel when the respective component is selected.

15.2.8 Processes

The Processes node under Oracle Enterprise Manager contains information about all deployed WebLogic business processes in the managed domain. ADP organizes information for various process nodes into the following major categories:

- Node Hierarchy

- Persistent Containers

- Instrumentation

The minimum and maximum response time measurements are stored in the database in addition to the average response time measurements. These metrics, if present, display visually in the window on the right pane.

When you select the root of the Processes tree, ADP displays the Processes Summary in the Main Display Window. See Table 15-36.

Table 15-36 Process Summary Metrics

Metrics

Description

Process

Name of process

Running

Total number of currently running instances for a specific process

Suspended

Total number of suspended instances for a specific process. A Suspended request from a user is a common cause for a process instance to go into a Suspended state.

Frozen

Total number of frozen instances for a specific process

Completed

Total number of completed instances for a specific process. A Completed status represents a process instance that has finished normally.

Aborted

Total number of aborted instances for a specific process

Terminated

Total number of terminated instances for a specific process. An external Terminate request would terminate a process instance.

Average Execution Time (ms)

Average execution completion time for a specific process

Tip:
Statistics on the number of process instances with Terminated, Aborted, and Frozen states can indicate abnormal operation of the WebLogic Integration application or container. It is possible to unfreeze Frozen process instances from WLI Console.

ADP presents these metrics in a table format in the Main Display Window when you select the Processes node. Graphical representations of two metrics, Running Instances and Average Execution Time, are displayed below the table.

When you click the plus (+) icon next to the Processes node, ADP expands the tree to show all managed processes currently deployed on the WebLogic domain.

You can see information specific to a particular process by selecting a specific process. All information displayed in the Main Display Window changes to only show data relevant to this new context.

To see the process work flow associated with a particular process, select the process node, right-click and select the Display Functional View option. ADP displays the appropriate functional work flow diagram and associated performance data in a new pop-up window.

15.2.8.1 Node Hierarchy

When expanding a particular process further, the first item you see is the Node Hierarchy node. By selecting the Node Hierarchy node, ADP provides a list of nodes associated with the specific process. See Table 15-37.

Table 15-37 Node Hierarchy Summary

Column/Metric

Description

Node

Name of a specific node

ID

Process Node ID for a specific node

Type

Control Type for a specific node

Method

Node Method Name for a specific node

Arrivals

Number of Requests Arrived for a specific node

Active

Number of Active Instances for a specific node

Elapsed Time (ms)

Average Time Elapsed to Complete an Instance for a specific node

Completions

Number of Completed Instances for a specific node

Aborts

Number of Aborted Instances for a specific node

Exceptions

Number of Exception Encountered for a specific nod.

By looking at this summary table, you can determine which process node is running slowly and whether there are aborts or exceptions.

The following additional views are available for the Node Hierarchy node:

- Delay Analysis view

- Events view

You can get to these views by selecting the appropriate tab.

15.2.8.1.1 Delay Analysis View

Delay Analysis gives you a bird's eye view of a specific process. You can see what nodes in the process are taking up a majority of the average elapsed time. The red bar indicates the slowest process group or process node. The blue represents the time spent for the particular nodes.

15.2.8.1.2 Events View

The Events view shows a list of SLO violations events relevant to this process in a table format. The Events view table includes the following information (Table 15-38):

Table 15-38 Events View Summary

Column/Metric

Description

Start Time

Start time for the process instance that violated a SLO

Entity Name

Name of the process node that violated a SLO

SLO Name

Name of the violated SLO

Service URI

URI of the process that violated a SLO

Application

Name of the application that violated a SLO

Event Type

Violation type (violation or cautionary)

Entity Type

Violation Metric type

SLO Threshold

Type of threshold (high or low)

SLO Trigger Value

Value that triggered a SLO violation

When you click the plus (+) icon next to a specific Node Hierarchy node, ADP expands the tree to show process nodes in the Node Hierarchy. Click an individual process node to see the load and performance of the selected node in the Main Display Window.

The process node information also includes the name of the method invoked. This information is displayed as part of the summary table at the top of the main view window.

15.2.8.2 Persistent Containers

When you expand a particular process further, the Persistent Containers node is included. By selecting the Persistent Containers node, ADP provides a list of persistence performance statistics relevant to the selected process.

As you select the root of the Persistent Containers tree, a summary of all Persistent Containers relevant to the selected process is presented. For example, a summary can contain the following high level items:

- Container persistence invocations

- Container persistence response time (milliseconds)

- Entity EJB activity

- Entity EJB cache

- Entity EJB transactions

- Entity EJB locking

These items are displayed in both table and graph formats.

The Persistent Containers Summary includes different tables:

- Entity EJB Activity

- Entity EJB Cache

- Entity EJB Transactions

- Entity EJB Locking

15.2.8.2.1 Entity EJB Activity Table

Entity EJB Activity table (Table 15-39) includes the following information:

Table 15-39 Entity EJB Activity Table

Metrics

Description

EJB

Name of the Entity EJB

In Use

Number of instances for a specific Entity EJB currently being used from the free pool. [Snapshot Count]

Idle

Number of instances for a specific Entity EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count]

Waits

Number of Threads currently waiting for a specific Entity EJB bean instance from the free pool [Snapshot Count]

Timeouts

Total number of Threads that have timed out waiting for an available bean instance from the free pool [Aggregated Count]

Tip:
Pay attention to Waits and Timeouts metrics. Activities in the Waits metric and increasing count in the Timeouts metric are signs that requests waiting to be serviced by the EJB container. Ideally, 0 should be indicated for these metrics.

15.2.8.2.2 Entity EJB Cache Table

Entity EJB Cache table (Table 15-40) includes the following information:

Table 15-40 Entity EJB Cache Table

Metrics

Description

EJB

Name of the Entity EJB

Hits

Total number of times an attempt to access the Entity EJB instance from the cache succeeded [Aggregated Count]

Accesses

Total number of attempts to access the Entity EJB instance from the cache [Aggregated Count]

Size

Number of beans instances from this EJB Home currently in the EJB cache [Snapshot Count]

Activations

Total number of beans from this EJB Home that have been activated [Aggregated Count]

Passivations

Total number of beans from this EJB Home that have been passivated [Aggregated Count]

Tip:
Passivation (serializing EJB state information to disk) and activation (reconstituting EJB state information from disk) are resource intensive operations. Ideally, it is preferable to see low level of activity in these metrics.

15.2.8.2.3 Entity EJB Transactions Table

Entity EJB Transactions table (Table 15-41) includes the following information:

Table 15-41 Entity EJB Transactions Table

Metrics

Description

EJB

Name of the Entity EJB

Commits

Total number of transactions that have been committed for this EJB. [Aggregated Count]

Rollbacks

Total number of transactions that have been rolled back for this EJB. [Aggregated Count]

Timeouts

Total number of transactions that have timed out for this EJB. [Aggregated Count]

Tip:
High number of EJB Transaction Rollbacks may indicate problems with the data used - for some reason the target database is unable to commit the change. High number of EJB Transaction Timeouts may indicate problems accessing the database including network outage, database lock contention, database outage, and more.

15.2.8.2.4 Entity EJB Locking Table

Entity EJB Locking table (Table 15-42) includes the following information:

Table 15-42 Entity EJB Locking Table

Metrics

Description

EJB

Name of the Entity EJB

Entries

Number of Entity EJB instances currently locked [Snapshot Count]

Lock Accesses

Total number of attempts to obtain a lock on an Entity EJB instance [Aggregated Count]

Current Waiters

Number of Threads that currently waiting for a lock on an Entity EJB instance [Snapshot Count]

Total Waiters

Total number Threads that have waited for a lock on an Entity EJB instance [Aggregated Count]

Timeouts

Total number Threads that have timed out waiting for a lock on an Entity EJB instance [Aggregated Count]

Tip:
Pay attention to Current Waiters and Timeouts. These metrics can indicate possible performance problems caused by EJB Locking. Ideally, 0s should be displayed for these metrics.

By looking at the activities related to Persistence Containers, you can determine if EJB persistence calls are causing performance problems.

15.2.8.3 Instrumentation

When expanding a particular process further, the last item you see is the Instrumentation node. Click the plus (+) icon next to Instrumentation to expand the tree to reveal the following categories of instrumentation:

- Class

- Methods

- Errors/Exceptions

- Transactions

The Class node in the Instrumentation tree provides the following information (Table 15-43):

Table 15-43 Class Node

Column/Metric

Description

Probe Point

Class name in which instrumentation probe point is inserted

Response Time (ms)

Average response time for a specific class

Invocation Count

Number of times a specific class is called

The Method node in the Instrumentation tree provides the following information (Table 15-44):

Table 15-44 Method Node

Column/Metric

Description

Probe Point

Method name in which instrumentation probe point is inserted

Response Time (ms)

Average response time for a specific method

Invocation Count

Number of times a specific method is called

The Errors/Exceptions and Transactions are described in Section 15.1.15, "Architecture View".

15.2.9 Web Services

The Web Services node in the navigation tree contains information about all deployed Web Services in the managed domain. By selecting the Web Services node under Oracle Enterprise Manager, ADP shows the Web Services Summary in the Main Display Window.

This summary view lists all discovered web services and their associated URL entry points. Below this list, ADP lists out all active web services and their performance data (invocation count and response time).

When you click the plus (+) icon next to the Web Services node, ADP expands the tree to show all monitored web services currently deployed on the WebLogic domain.

When you select a specific web service, ADP displays performance data associated with the selected web service. Click the plus (+) icon next to a specific web service to expand the tree to show all public operations associated with that web service.

The Operations table provides the following information (Table 15-45):

Table 15-45 Operations Table

Column/Metric

Description

Operation

Name of the web service operation

Invocation Count

Number of times the operation is called

Response Time (ms)

Average response time for the operation in milliseconds

Delay (ms)

Overall delay contributed by the operation in milliseconds

15.2.10 Pageflows

The Pageflows node in the navigation tree contains information about all deployed pageflows in the managed domain. By selecting the Pageflows node under Oracle Enterprise Manager, ADP shows the Pageflows Summary in the Main Display Window.

15.2.11 Services

The Services node in the navigation tree contains information about all external entry points into the managed domain. ADP currently monitors the following types of services:

- HTTP

- EJBs

- JDBC

Selecting each service type reveals service summary in the Main Display Window.

The minimum and maximum response time measurements are stored in the database in addition to the average response time measurements. These metrics, if present, display visually in the window in the right pane.

ADP displays entry point activity summary associated with the selected EJB service.

Tip:
Setting thresholds at some of these entry points enables ADP to monitor the performance of key business services. When a violation event occurs, you can begin investigating from the Service node.

15.2.11.1 HTTP

Expanding the HTTP node under the Services node reveals a list of discovered HTTP based entry points into the managed domain. HTTP service end points include JSPs, struts actions, and servlet mappings. These discovered HTTP entry points are listed by their root context. When you select a specific HTTP entry point, ADP displays the associated summary in the Main Display Window.

When a specific file is selected, ADP displays more detailed performance data.

Method level performance data is displayed when you select a specific HTTP service entry point.

Table 15-46 HTTP Performance Summary

Column/Metric

Description

Servlet

Name of the servlet associated with the selected service

Method

Name of the method invoked by external call

Arrivals

Total number of requests received by this method

Invocation Count

Total number of method invocations

Response Time (ms)

Average method response time in milliseconds

15.2.11.2 EJBs

To view the performance summary for EJBs invoked from outside the JVM, click the EJBs node.

Table 15-47 EJB Performance Summary

Column/Metric

Description

EJB

Name of the EJB

Invocation Count

Number of times the EJB is called

Response Time (ms)

Average response time for the EJB in milliseconds

Delay (ms)

Overall delay contributed by the EJB in milliseconds

Tip:
As a general rule, external calls that terminate in EJBs are RMI calls. Web services calls that ultimately terminate in EJBs use SOAP and enter the application server via HTTP.

15.2.11.3 JDBCs

To bring up the performance summary for JDBC operations invoked from outside of the JVM, click the JDBC node.

Table 15-48 JDBC Performance Summary

Column/Metric

Description

SQL Statement

Generalized SQL Statement executed by the JDBC operation

Class

Name of the class used in the JDBC operation

Method

Name of the method used in the JDBC operation

Invocation Count

Number of times the JDBC operation is called

Response Time (ms)

Average response time for the JDBC operation in millisecond

Delay (ms)

Overall delay contributed by the JDBC operation in milliseconds

15.2.12 WSRP Producers

The Web Services Remote Portlet (WSRP) Producers node in the navigation tree contains information about the WebLogic WSRP consumer - producer relationships in the managed domain. By selecting an entity in the WSRP node, ADP displays the performance measurements for the associated WSRP consumer or producer.

WebLogic Portal can act as either a WSRP remote producer or as a consumer. When acting as a consumer, WebLogic Portal's remote--or proxy--portlets are WSRP-compliant. These portlets present content that is collected from WSRP-compliant producers, allowing you to use external sources for portlet content, rather than having to create its content or its structure yourself.

The following types of portlets can be exposed with WSRP inside a WebLogic portal:

- Page flow portlets

- JavaServer Pages (JSP) portlets

- Struts portlets

- Java portlets (JSR168; supported only for complex producers)

- JavaServer Faces (JSF) portlets

The minimum and maximum response time measurements are captured in addition to the average response time measurements. These metrics, if present, display visually in the window in the right pane.

15.2.12.1 WSRP Summary

To view the WSRP Producers Summary:

1. Select the WSRP Producers node to show the WSRP Producers Summary tab.
The WSRP Producers summary includes the following table (Table 15-49):

Table 15-49 WSRP Producers Summary

Column

Description

WSRP Producer

Name of the producer portlet

WSDL URL

URL of the WSD.

2. To view the portlet details, click the Consumer Portlets node under the WSRP Producers.
The following tables are in this view:

- WSRP Producer Information

- WSRP Consumer Portlet Performance
Select the portlet name and right click. Select Open to drill down to more detailed view.

- WSRP Producer Portlets
Select the portlet name and right click. Select Open to drill down to more detailed view.

Table 15-50 WSRP Producers Information

Column

Description

TestPortlets

Defined by the user for the Producer, for example description, handle, and more

URL

Lists the details of each item under the TestPortlet column

Table 15-51 WSRP Consumer Portlet Performance

Column

Description

Portal

The Portal is the logical containment unit for a Portal application. A typical Portal can contain a few desktops, several of books, tens of pages, and hundreds of portlets.

Desktop

The desktop is the top-level container for the portal components included in that specific view of the portal.

Portal administrators can create new desktops beyond what portal developers create in WebLogic Workshop.

Book

The top-level book contains all sub-books, pages, and portlets. The top-level book defines the initial menu navigation style used for the desktop. For each sub-book, you add to a desktop you can select a different navigation style.

Page

Pages and sub-books are the navigable containers used for organizing portlets.

Portlet

Portlets are the containers that surface Web content and applications in your desktops.

Response Time (ms)

Average response time in milliseconds.

Completions

Number of Completed Instances for a specific node.

Response Time Min (ms)

Minimum response time in milliseconds.

Response Time Max (ms)

Maximum response time in milliseconds.

Table 15-52 WSRP Producer Portlets

Column

Description

Producer Portlet

Name of the producer portlet

Producer

Name of the producer

3. Click a portlet name in the tree view to see the performances associated with the consumer and producer portlets.

15.2.12.2 WSRP Topology

Use this option to visually explore WSRP consumer - producer relationships and the WSRP deployment topology.

To view the WSRP Topology:

1. Select the WSRP Producers node to show the WSRP Topology tab.

2. Click the WSRP Topology tab to view the details.

15.2.12.3 Display Portal Desktop

The portal desktop is described in Section 15.2.3.1.1, "Display Portal Desktop - Desktop Structure Viewer".

Access the Architecture View:

1. To view the portal desktop for a specific portlet, right-click the portlet name under the Consumer Portlet node.

2. Select Display Portal Desktop.

3. You can drill down to view the Architecture View from this view. See the instructions in Section 15.2.3.2, "Portlet Drill Down".

15.2.13 Integration

The Integration node under Oracle Enterprise Manager contains information about the WebLogic Integration resources in the managed domain. By selecting the Integration node under Oracle Enterprise Manager, ADP displays the Integration Summary.

The Integration Summary includes the following (Table 15-53):

Table 15-53 Integration Summary

Metric

Description

Process

Name of process

Running

Total number of currently running instances for a specific process

Suspended

Total number of suspended instances for a specific process

Frozen

Total number of frozen instances for a specific process

Completed

Total number of completed instances for a specific process

Aborted

Total number of aborted instances for a specific process

Terminated

Total number of terminated instances for a specific process

Average Execution Time

Average execution completion time for a specific process

Tip:
Statistics on the number of process instances with Terminated, Abort, and Frozen states can indicate abnormal operation of WebLogic Integration application or container. It is possible to unfreeze Frozen process instances from WLI Console.

ADP presents these metrics in a table format in the Main Display Window when you select the Integration node. Graphical representations of these metrics, Running Instances, Completed Instances, and Average Execution Time, are displayed below the table.

Expand the Integration tree by clicking on the plus (+) icon next to Integration node.

The expanded Integration tree allows you to look at various components of WebLogic Integration and help identify performance bottlenecks. This section explains the nodes under the Integration Tree.

15.2.13.1 Health

In the expanded Integration tree, the first node you see is the Health node. Under the Health node, ADP lists various subsystems in WebLogic Integration. By expanding the Health node, you can see the following:

- Execute Queues

- Async Dispatchers

- Sync Dispatchers

- JMS Destinations

- Stateless Containers

- Persistent Containers

You can get to the health information specific to each of these subsystems by clicking the appropriate node. Also, you can get to a particular instance of a subsystem.

15.2.13.1.1 Execute Queues

In the Execute Queues node, ADP provides operational statistics of each execute queues configured for WebLogic Integration. Select the Execute Queues node in the Monitor Workspace to display the Execute Queues Summary in the Main Display Window.

The Execute Queues Summary provides the following information (Table 15-54):

Table 15-54 Execute Queues Summary

Metric

Description

Execute Queue

Execute Queue ID

Aggregated Execute Queue

Aggregated execute queue statistics per resource

Idle Threads

Current number of idle threads in a specific Execute Queue

Pending Threads

Current number of pending threads in a specific Execute Queue

Requests

Total number of requests serviced for a specific Execute Queue

Total Threads

Total number of threads configured in a specific Execute Queue

Tip:
Pay attention to Idle Threads and Pending Threads counts. Rapidly decreasing Idle Threads count combined with rapidly increasing Pending Threads count can indicate a backup in the Execute Queue.

Use the following guidelines to adjust the Execute Queue Thread Count (Table 15-55):

Table 15-55 Guidelines to Adjust the Execute Queue Thread Count

Execute Queue Is Backed Up?

Application Is CPU Bound?

Adjustment Guideline

Yes

No

Increase execute queue thread count.

Yes

Yes

Decrease thread count and explore JVM or application issues that may be causing high CPU utilization.

ADP presents these metrics in a table format in the Main Display Window when you select the Health node. Graphical representations of these metrics, Idle Treads, Pending Threads, and Requests, are displayed below the table.

Expand the Health tree by clicking on the plus (+) icon next to Health node. You can get the same summary as previously described for a specific execute queue.

15.2.13.1.2 Async Dispatchers

In the Async Dispatcher node, ADP provides operational statistics of each of the Async Dispatchers configured in WebLogic Integration. Select the Async Dispatchers node in the Monitor Workspace to show the Async Dispatchers Summary in the Main Display Window.

The Async Dispatcher Summary includes the following information (Table 15-56):

Table 15-56 Async Dispatcher Summary

Metric

Description

EJB

Name of the Message Driven EJB

In Use

Number of instances for a specific Message Driven EJB currently in use

Idle

Number of instances for a specific Message Driven EJB currently in the idle state

Waits

Number of instances for a specific Message Driven EJB currently in the wait state

Timeouts

Number of instances for a specific Message Driven EJB currently in the timeout state

Commits (Transaction)

Total number of commits performed for a specific Message Driven EJB

Rollbacks (Transaction)

Total number of transaction rollbacks performed for a specific Message Driven EJB

Timeouts (Transaction)

Total number of transaction timeouts performed for a specific Message Driven EJB

Tip:
Rapidly increasing counts in MDB Waits and Timeouts metrics may indicate a tuning opportunity for the MBD container. Furthermore, increasing numbers in the Transaction Rollbacks and Timeouts metrics may indicate issues interacting with the database. Ideally, these metrics should not increase rapidly.

ADP presents these metrics in a table format in the Main Display Window when you select the Async Dispatchers node. Graphical representation of one metrics, Message Driven EJB in use, is displayed below the table.

Expand the Async Dispatchers tree by clicking the plus (+) icon next to Async Dispatchers node. You can get the same summary as previously described for a specific async dispatcher.

15.2.13.1.3 Sync Dispatchers

In the Sync Dispatchers node, ADP provides operational statistics of each of the Sync Dispatchers used by WebLogic Integration. Select the Sync Dispatchers node in the Monitor Workspace to show the Sync Dispatchers Summary in the Main Display Window.

The Sync Dispatcher Summary includes the following information (Table 15-57):

Table 15-57 Sync Dispatcher Summary

Metric

Description

EJB

Name of the Stateless EJB

In Use

Number of instances for a specific Stateless EJB currently in use

Idle

Number of instances for a specific Stateless EJB currently in the idle state

Waits

Number of instances for a specific Stateless EJB currently in the waits state

Timeouts

Number of instances for a specific Stateless EJB currently in the timeouts state

Tip:
Rapidly increasing counts in Stateless EJB Waits and Timeouts metrics may indicate performance issues and a tuning opportunity for the EJB container. Ideally, these metrics should not increase at a rapid pace.

ADP presents these metrics in a table format in the Main Display Window when you select the Sync Dispatchers node. Graphical representation of one metrics, Stateless EJB in use, is displayed below the table.

Expand the Sync Dispatchers tree by clicking on the plus (+) icon next to Sync Dispatchers node. You can get the same summary as previously described for a specific sync dispatcher.

15.2.13.1.4 JMS Destinations

In the JMS Destination node, ADP provides operational statistics of each of the JMS Destinations used by WebLogic Integration. Select the JMS Destinations node in the Monitor Workspace to show the JMS Destinations Summary in the Main Display Window.

JMS Destination Summary includes the following tables: JMS destination message statistics and JMS destination byte statistics. The JMS destination message statistics table includes the following information (Table 15-58).

Table 15-58 JMS Destination Message Statistics

Column/Metric

Description

JMS Destination

Name of the JMS destination

Message Current

Number of JMS messages currently at a specific JMS destination

Message High

Maximum number of JMS messages at a specific JMS destination

Message Pending

Number of JMS messages pending to be delivered to a specific JMS destination

Message Received

Total number of JMS messages at a specific JSM destination

Tip:
Pay attention to Message Pending metric. Too many pending messages in a specific JMS destination could result in a performance slowdown. Rapidly increasing count for the Message Pending metric may indicate a performance problem and a JMS destination tuning opportunity.

The JMS destination byte statistics table includes the following information (Table 15-59).

Table 15-59 JMS Destination Byte Statistics

Column/Metric

Description

JMS Destination

Name of the JMS destination

Byte Current

Byte count of JMS messages currently at a specific JMS destination

Byte High

Maximum byte count of JMS messages at a specific JMS destination

Byte Pending

Byte count of JMS messages pending to be delivered to a specific JMS destination

Byte Received

Total Byte count of JMS messages at a specific JMS destination

ADP presents these metrics in table format in the Main Display Window when you select the JMS Destinations node. Graphical representations of the following metrics, Message pending and Byte pending, are displayed below the table.

Expand the JMS Destinations tree by clicking on the plus (+) icon next to JMS Destinations node. You can get the same summary as described above for a specific JMS destination.

15.2.13.1.5 Stateless Containers

In the Stateless Containers node, ADP provides operational statistics of each of the Stateless Containers used by WebLogic Integration. Select the Stateless Containers node in the Monitor Workspace to show the Stateless Containers Summary in the Main Display Window.

The Stateless Containers Summary includes the following information (Table 15-60):

Table 15-60 Stateless Containers Summary

Metric

Description

EJB

Name of the Stateless EJB

Stateless EJB Transactions

Runtime statistics. You can monitor stateless session EJBs using the metrics in this table.

In Use

Number of instances for a specific Stateless EJB currently being used from the free pool [Snapshot Count]

Idle

Number of instances for a specific Stateless EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count]

Waits

Number of Threads currently waiting for a specific Stateless EJB instance from the free pool [Snapshot Count]

Timeouts

Total number of Threads that have timed out waiting for an available bean instance from the free pool [Aggregated Count]

ADP presents these metrics in a table format in the Main Display Window when you select the Stateless Containers node. Graphical representation of one metrics, Stateless EJB in use, is displayed below the table.

Expand the Stateless Containers tree by clicking on the plus (+) icon next to Stateless Containers node. You can get the same summary as previously described for a specific stateless container.

15.2.13.1.6 Persistent Containers

In the Persistent Containers node, ADP provides operational statistics of each of the Persistent Containers used by WebLogic Integration. Select the Persistent Containers node in the Monitor Workspace to show the Persistent Containers Summary in the Main Display Window.

The Persistent Containers Summary includes the following tables:

- Entity EJB Activity

- Entity EJB Cache

- Entity EJB Transactions

- Entity EJB Locking

Entity EJB Activity table includes the following information (Table 15-61):

Table 15-61 Entity EJB Activity

Metrics

Description

EJB

Name of the Entity EJB

In Use

Number of instances for a specific Entity EJB currently being used from the free pool [Snapshot Count]

Idle

Number of instances for a specific Entity EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count]

Waits

Number of Threads currently waiting for a specific Entity EJB bean instance from the free pool [Snapshot Count]

Timeouts

Total number of Threads that have timed out waiting for an available bean instance from the free pool [Aggregated Count]

Tip:
Pay attention to Waits and Timeouts metrics. Activities in the Waits metric and increasing count in the Timeouts metric are signs that requests waiting to be serviced by the EJB container. Ideally, 0 should be indicated for these metrics.

Entity EJB Cache table includes the following information (Table 15-62):

Table 15-62 Entity EJB Cache

Metrics

Description

EJB

Name of the Entity EJB

Hits

Total number of times an attempt to access the Entity EJB instance from the cache succeeded [Aggregated Count]

Accesses

Total number of attempts to access the Entity EJB instance from the cache [Aggregated Count]

Size

Number of beans instances from this EJB Home currently in the EJB cache [Snapshot Count]

Activations

Total number of beans from this EJB Home that have been activated [Aggregated Count]

Passivations

Total number of beans from this EJB Home that have been passivated [Aggregated Count]

Tip:
Passivation (serializing EJB state information to disk) and activation (reconstitute EJB state information from disk) are resource intensive operations. Ideally, Oracle recommends low level of activity in these metrics.

Entity EJB Transactions table includes the following information (Table 15-63):

Table 15-63 Entity EJB Transactions

Metric

Description

EJB

Name of the Entity EJB

Commits

Total number of transactions that have been committed for this EJB [Aggregated Count]

Rollbacks

Total number of transactions that have been rolled back for this EJB [Aggregated Count]

Timeouts

Total number of transactions that have timed out for this EJB [Aggregated Count]

Tip:
High number of EJB Transaction Rollbacks may indicate problems with the data used - for some reason the target database is unable to commit the change. High number of EJB Transaction Timeouts may indicate problems accessing the database including network outage, database lock contention, database outage, and more.

Entity EJB Locking table includes the following information (Table 15-64):

Table 15-64 Entity EJB Locking

Metric

Description

EJB

Name of the Entity EJB

Entries

Number of Entity EJB instances currently locked [Snapshot Count]

Lock Accesses

Total number of attempts to obtain a lock on an Entity EJB instance [Aggregated Count]

Current Waiters

Number of Threads that currently waiting for a lock on an Entity EJB instance [Snapshot Count]

Total Waiters

Total number Threads that have waited for a lock on an Entity EJB instance [Aggregated Count]

Timeouts

Total number Threads that have timed out waiting for a lock on an Entity EJB instance [Aggregated Count]

Tip:
Pay attention to Current Waiters and Timeouts. These metrics can indicate possible performance problems caused by EJB Locking. Ideally, 0s should be displayed for these metrics.

ADP presents these metrics in a table format in the Main Display Window when you select the Persistent Containers node. Graphical representations of three metrics, Entity EJB in use, Entity EJB cache access, and Entity EJB lock access, are displayed below the table.

Expand the Persistent Containers tree by clicking on the plus (+) icon next to Persistent Containers node. You can get the same summary as previously described for a specific persistent container.

15.2.13.2 Performance

In the expanded Integration tree, the second node you see is the Performance node. ADP provides the Performance Summary for WebLogic Integration in the Main Display Window when the Performance node is selected.

The Performance Summary includes the following tables: Process Node and Events. The Process Node table provides performance information for various process nodes running in WebLogic Integration. It includes the following information (Table 15-65):

Table 15-65 Performance - Process Node Summary

Column/Metric

Description

Node

Name of a specific node

ID

Process Node ID for a specific node

Type

Control Type for a specific node

Method

Node Method Name for a specific node

Arrival

Number of Requests Arrived for a specific node

Active

Number of Active Instances for a specific node

Elapsed Time

Average Time Elapsed to Complete an Instance for a specific node

Completions

Number of Completed Instances for a specific node

Aborts

Number of Aborted Instances for a specific nod.

Exceptions

Number of Exception Encountered for a specific node

Tip:
You can use Arrivals and Elapsed Time data collected by ADP to characterize the performance of your installation. Since ADP measures performance at cluster level, you are capturing the actual performance of your configuration. You can also perform simple capacity planning analysis by plotting Arrivals versus Elapsed Time (arrival rate versus response time). Ask your Oracle consultant for more information.

The Events table provides a list of SLO violations triggered relevant to WebLogic Integration. It includes the following information (Table 15-66):

Table 15-66 Performance - Events Node Summary

Column/Metric

Description

Start Time

Start time for the process instance that violated a SLO

Entity Name

Name of the process node that violated a SLO

SLO Name

Name of the violated SLO

Service URI

URI of the process that violated a SLO

Application

Name of the application that violated a SLO

Event Type

Violation type (violation or cautionary)

Entity Type

Violation Metric type

SLO Threshold

Type of threshold (high or low)

SLO Trigger Value

Value that triggered a SLO violation

15.2.13.3 Channels

In the expanded Integration tree, the third node you see is the Channels node. ADP shows the Channels Summary for various channels configured for WebLogic Integration.

The Channels Summary includes the following information (Table 15-67):

Table 15-67 Channels Summary

Column/Metric

Description

Channel

Name of channel

Type

Channel type

Message Count

Total number of messages processed for a specific channel

Dead Message Count

Total number of dead messages for a specific channel

Tip:
Increasing count in the Dead Message Count metric may indicate a configuration issue. When the Message Broker is unable to determine the URI to send a message to, the message is sent to the appropriate deadletter channel. Ensure the URI configured for the channel is reachable.

Expand the Channels tree by clicking the plus (+) icon next to Channels node. You can get the same health summary as previously described for a specific channel.

15.2.13.4 Subscribers

In the expanded Integration tree, the fourth node you see is the Subscribers node. ADP shows the Subscribers Summary for various subscribers configured for WebLogic Integration.

Expand the Subscribers tree by clicking the plus (+) icon next to Subscribers node. You can get specific information about an individual subscriber.

15.2.14 Applications

The Applications node in the navigation tree contains information about all deployed applications in the managed domain. By selecting the Applications node, ADP displays the Applications Summary.

The Applications Summary includes the following information (Table 15-68, "Applications Summary"):

Table 15-68 Applications Summary

Column/Metric

Description

Application

Name of application

Status

Operations status for a specific application

Response Time (ms)

Average response time in milliseconds for a specific application. This is the average of response times of all JSPs and servlets contained in the deployment archive.

Invocation Count

Total number of invocations for a specific application. This is the total invocation count of all JSPs and servlets contained in the deployment archive.

Tip:
Application is a packaging unit in Java EE. Each EAR, WAR, and JAR files deployed to the application server is considered an individual application. These metrics track performance and arrival rate of these entities.

ADP presents these metrics in a table format in the Main Display Window when you select the Applications node. Graphical representations of the following metrics, Response Time, Invocation Count, and Active Sessions, are displayed below the table.

Expand the Applications tree by clicking the plus (+) icon next to Applications node. You can get more information about a specific application.

ADP displays performance summary for the selected application in the Main Display Window. You can obtain additional performance data by clicking different tabs in the Main Display Window.

The Applications Summary includes the following tabs (Table 15-69):

Table 15-69 Applications Summary Tabs

Tab Name

Description

Summary

Includes performance data at the application level including time-based trend graphs of Application Response Time, Application Invocation Count, and Application Active Sessions. The invocation count and response time for the top 10 slowest servlets, the usual application entry points, are also included.

Response Times

Includes time-based trend graphs of component response times. Graphs include Servlet Response Time, EJB Response Time, and JDBC Response Time.

Invocations

Includes time-based trend graphs of component invocation counts. Graphs include Servlet Invocation Count, EJB Invocation Count, and JDBC Invocation Count.

Errors/Exceptions

Errors metrics associated with the selected portal.

Transactions

Transaction events associated with the selected portal and children below.By default, the Transactions tab is not enabled.

Modeled Entities

Includes a catalog of entities modeled by ADP. Only the modeled entities associated with the selected application are included.

Instrumentation

Includes performance data by different types of instrumentation probe points. There are different tabs available: Class, Method, and SQL. Each tab includes basic information such as Probe Point Name, Invocation Count, and Response Time. This detailed performance data can help you identify low-level bottlenecks.

Topology

Includes the topology view associated with the selected application.

Under each named application node, ADP displays performance and other relevant information specific to that application. For example, by clicking the children nodes, the relevant data is displayed in the Main Display Window. Application response time and invocations measurements can be reached by clicking the panes in the Main Display Window.

In this section, we will further expand on the following nodes:

- Services

- Dependencies

- Deployments

- Workshop Projects

- Web Applications

- Stateless Beans

- Stateful Beans

- Entity Beans

- Message Driven Beans

Note:
The number of children nodes available under each application node depends solely on the complexity of the selected application. Simple Java EE web applications will not have nodes like Workshop Projects, Stateless Beans, Stateful Beans, Entity Beans, and Message Driven Beans.

15.2.14.1 Services

The Services node includes all the external entry points associated with the selected application. When this node is selected, ADP displays a summary view in the Main Display Window. ADP displays the performance data associated with various entry points associated with the selected application.

Tip:
The children nodes under the Services node include entry point specific performance data.

15.2.14.2 Dependencies

The Dependencies node shows a list of internal and external components and share resources that a specific application depends on for its normal operation. When the Dependencies node is selected, ADP displays all external references made by the application in the Main Display Window. The following is a list of columns and their descriptions (Table 15-70):

Table 15-70 Dependencies Column Descriptions

Column/Metric

Description

Name

Display name of the component or resource used by the application. If this is undefined in the Deployment Descriptor, the reference name for the component is used.

Reference

Reference name of the component or resource used by the application.

Reference Type

Component or resource type.

Referer Component

Name of the component that is part of the application which obtained the reference to external component or resource.

Referer Module

Name of the module that is part of the application which obtained the reference to external component or resource.

ADP displays all the references associated with components in the selected application.

The Dependencies node can be further expanded by clicking the plus (+) icon. The children nodes of the Dependencies node are organized by type. Here are the list of dependency types and their descriptions (Table 15-71):

Table 15-71 Dependency Types

Dependency Type

Description

Data Sources

All shared data sources used by the application

Entity Beans

All entity beans used by the application

Session Beans

All session beans used by the application

JMS Queues

All JMS queues used by the application for publishing JMS messages

JMS Topics

All JMS topics subscribed by the application

Web Services

All web services used by the application

When a specific node is selected, ADP displays relevant performance summary. These nodes can also be expanded by clicking the plus (+) icons. The expanded tree includes specific components and share resources used by the application.

The Performance summary view associated with the Data Sources node under Dependencies provides information on both connection pools and SQL statements.

For more information on the metric description, refer to Section 15.1.16, "Metric Types".

15.2.14.3 Deployments

The Deployments node shows the architecture of the deployed application. When this node is selected, ADP shows all the modules deployed as part of this application. The default view in the Main Display Window shows the active module-level call path. Table 15-72 lists the tabs available as part of this summary view and their descriptions.

Table 15-72 Deployment Tabs

Tab Name

Description

Module Level Execution

Shows the active calling relationships among various Java EE modules (EAR, WAR, JAR, and more). Shared resources are also included. This is the default Architecture View at the module level.

Module Level

Shows the potential calling relationships among various Java EE modules. Shared resources are also included. By default, the Module Level tab is not enabled.

Instrumentation

Includes detailed performance data at the method level. The table includes caller components, caller method, callee (target) component, callee module, invocation count, and response time.

SQL Statement

Includes all SQL statements executed as part of this application. It also includes performance information such as invocation count and response time.

Active module-level call path is displayed as the default view for the Deployments node of a selected application.

Double-click a specific module to trigger ADP to display the architecture of the selected module.

Expand the Deployments node by clicking the plus (+) icon to reveal all the deployed modules in this application. Further expanding the nodes at the module level reveals components associated with the selected module. Further expanding the nodes at the component level reveals methods associated with the selected component.

When you select one of these children nodes (module, component, and method levels), ADP displays associated tabs for active call path diagram, static call path diagram, instrumentation and SQL statements.

Tip:
Use the active call path diagram as a guide to identify entities with performance data. If an entity does not have performance data, ADP displays No data available for the selected time frame in the Main Display Window.

15.2.14.4 Workshop Projects

The Workshop Projects node includes performance information about modules and components created using the Oracle WebLogic Workshop. These modules and components include WebLogic Integration processes, WebLogic Integration web services, and WebLogic Portal pageflows.

Workshop Project node and its children nodes provide performance data associated with WLI processes, web services, and WLP pageflows.

When you select a specific children node, ADP displays detailed performance information.

15.2.14.5 Web Applications

The Web Applications node includes performance information related to the Web Applications modules and components associated with the selected application. Click the Web Applications node to reveal a performance summary in the Main Display Window. Click the plus (+) icon to expand the Web Applications node to reveal various web modules deployed as part of this application.

Click the plus (+) icon to expand on a specific web module and reveal different groupings for web components, for example, Pageflows, Struts Modules and Servlets. Clicking one of these nodes triggers ADP to display rolled up performance summary for the entire grouping. You can further expand these nodes by clicking the plus (+) icon to reveal more detailed information. Fully expanded Web Applications node contains all web modules organized by type.

Detailed performance information at the individual pageflow, struts action, and servlet levels will be displayed when you click the lowest level nodes.

15.2.14.6 Stateless Beans

The Stateless Beans node includes activity information related to the stateless EJB components associated with the selected application. Click the Stateless Beans node to reveal an activity summary in the Main Display Window. Click the plus (+) icon to expand the Stateless Beans node to reveal various stateless EJBs deployed as part of this application.

You can further select individual nodes to obtain detailed activity information. Selecting a specific Stateless Bean node triggers ADP to display detailed activity metrics.

The detailed view contains the following activity metrics (Table 15-73):

Table 15-73 Stateless Beans Detail View

Column/Metric

Description

EJB

Name of the stateless EJB.

In Use

Number of instances for a specific stateless EJB currently being used from the free pool. [Snapshot Count]

Idle

Number of instances for a specific stateless EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count]

Waits

Number of threads currently waiting for a specific stateless EJB bean instance from the free pool. [Snapshot Count]

Timeouts

Total number of threads that have timed out waiting for an available bean instance from the free pool. [Aggregated Count]

Note:
The metrics reported in the Stateless Beans node are reported by the MBean (Management Bean) of the EJB container. These activity metrics can be used for checking the overall health of the EJB container. When the EJB container is restarted, these metrics are reset.

15.2.14.7 Stateful Beans

The Stateful Beans node includes activity information related to the stateful EJB components associated with the selected application. Click the Stateful Beans node to reveal an activity summary in the Main Display Window. Click the plus (+) icon to expand the Stateful Beans node to reveal various stateful EJBs deployed as part of this application.

You can further select individual nodes to obtain detailed activity information.

The Stateful EJB Summary includes the following tables:

- Stateful EJB Cache

- Stateful EJB Transactions

- Stateful EJB Locking

15.2.14.7.1 Stateful EJB Cache

Stateful EJB Cache table includes the following information (Table 15-74):

Table 15-74 Stateful EJB Cache

Metrics

Description

EJB

Name of the Stateful EJB

Hits

Total number of times an attempt to access the Stateful EJB instance from the cache succeeded [Aggregated Count]

Accesses

Total number of attempts to access the Stateful EJB instance from the cache [Aggregated Count]

Size

Number of beans instances from this Stateful Home currently in the EJB cache [Snapshot Count]

Activations

Total number of beans from this Stateful Home that have been activated [Aggregated Count]

Passivations

Total number of beans from this Stateful Home that have been passivated [Aggregated Count]

Tip:
Passivation (serializing EJB state information to disk) and activation (reconstitute EJB state information from disk) are resource intensive operations. Ideally, Oracle recommends low level of activity in these metrics.

15.2.14.7.2 Stateful EJB Transactions

Stateful EJB Transactions table includes the following information (Table 15-75):

Table 15-75 Stateful EJB Transactions

Metrics

Description

EJB

Name of the Stateful EJB

Commits

Total number of transactions that have been committed for this Stateful [Aggregated Count]

Rollbacks

Total number of transactions that have been rolled back for this Stateful [Aggregated Count]

Timeouts

Total number of transactions that have timed out for this EJB [Aggregated Count]

Tip:
High number of EJB Transaction Rollbacks may indicate problems with the data used; for some reason the target database is unable to commit the change. High number of EJB Transaction Time-outs may indicate problems accessing the database including network outage, database lock contention, and database outage.

15.2.14.7.3 Stateful EJB Locking

Stateful EJB Locking table includes the following information (Table 15-76):

Table 15-76 Stateful EJB Locking

Metric

Description

EJB

Name of the Stateful EJB

Entries

Number of Stateful EJB instances currently locked [Snapshot Count]

Lock Accesses

Total number of attempts to obtain a lock on an Stateful EJB instance [Aggregated Count]

Current Waiters

Number of Threads that currently waiting for a lock on an Stateful EJB instance [Snapshot Count]

Total Waiters

Total number Threads that have waited for a lock on an Stateful EJB instance [Aggregated Count]

Timeouts

Total number Threads that have timed out waiting for a lock on an Stateful EJB instance [Aggregated Count]

Tip:
Pay attention to Current Waiters and Time-outs. These metrics can indicate possible performance problems caused by EJB Locking. Ideally, 0s should be displayed for these metrics.

ADP presents these metrics in a table format in the Main Display Window when you select the Stateful Beans node. Graphical representations of two metrics, Stateful EJB cache access, and Stateful EJB lock access, are displayed below the table.

By looking at the activities related to Stateful EJBs, you can determine if there any abnormal activities associated with Stateful EJBs.

Note:
The metrics reported in the Stateful Beans node are reported by the MBean (Management Bean) of the EJB container. These activity metrics can be used for checking the overall health of the EJB container. When the EJB container is restarted, these metrics are reset.

15.2.14.8 Entity Beans

The Entity Beans node includes activity information related to the Entity EJB components associated with the selected application. Click the Entity Beans node to reveal an activity summary in the Main Display Window. Click the plus (+) icon to expand the Entity Beans node to reveal various Entity EJBs deployed as part of this application.

You can further select individual nodes to obtained detailed activity information. Selecting a specific Entity Bean node triggers ADP to display detailed activity metrics.

The Entity EJB Summary includes the following tables:

- Entity EJB Activity

- Entity EJB Cache

- Entity EJB Transactions

- Entity EJB Locking

15.2.14.8.1 Entity EJB Activity

Entity EJB Activity table includes the following information (Table 15-77):

Table 15-77 Entity EJB Activity

Metrics

Description

EJB

Name of the Entity EJB.

In Use

Number of instances for a specific Entity EJB currently being used from the free pool. [Snapshot Count]

Idle

Number of instances for a specific Entity EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count]

Waits

Number of Threads currently waiting for a specific Entity EJB instance from the free pool. [Snapshot Count]

Timeouts

Total number of Threads that have timed out waiting for an available bean instance from the free pool. [Aggregated Count]

Tip:
Pay attention to Waits and Timeouts metrics. Activities in the Waits metric and increasing count in the Timeouts metric are signs that requests are waiting to be serviced by the EJB container. Ideally, 0 should be indicated for these metrics.

15.2.14.8.2 Entity EJB Cache

Entity EJB Cache table includes the following information (Table 15-78):

Table 15-78 Entity EJB Cache

Metrics

Description

EJB

Name of the Entity EJB

Hits

Total number of times an attempt to access the Entity EJB instance from the cache succeeded [Aggregated Count]

Accesses

Total number of attempts to access the Entity EJB instance from the cache [Aggregated Count]

Size

Number of beans instances from this EJB Home currently in the EJB cache [Snapshot Count]

Activations

Total number of beans from this EJB Home that have been activated [Aggregated Count]

Passivations

Total number of beans from this EJB Home that have been passivated [Aggregated Count]

Tip:
Passivation (serializing EJB state information to disk) and activation (reconstituting EJB state information from disk) are resource intensive operations. Ideally, Oracle recommends a low level of activity in these metrics.

15.2.14.8.3 Entity EJB Transactions

Entity EJB Transactions table includes the following information (Table 15-79):

Table 15-79 Entity EJB Transactions

Metric

Description

EJB

Name of the Entity EJB

Commits

Total number of transactions that have been committed for this EJB [Aggregated Count]

Rollbacks

Total number of transactions that have been rolled back for this EJB [Aggregated Count]

Timeouts

Total number of transactions that have timed out for this EJB [Aggregated Count]

Tip:
High numbers of EJB Transaction Rollbacks may indicate problems with the data used; for some reason the target database is unable to commit the change. High numbers of EJB Transaction Timeouts may indicate problems accessing the database including network outage, database lock contention, database outage, and more.

15.2.14.8.4 Entity EJB Locking

Entity EJB Locking table includes the following information (Table 15-80):

Table 15-80 Entity EJB Locking

Metric

Description

EJB

Name of the Entity EJB

Entries

Number of Entity EJB instances currently locked [Snapshot Count]

Lock Accesses

Total number of attempts to obtain a lock on an Entity EJB instance [Aggregated Count]

Current Waiters

Number of Threads that currently waiting for a lock on an Entity EJB instance [Snapshot Count]

Total Waiters

Total number Threads that have waited for a lock on an Entity EJB instance [Aggregated Count]

Timeouts

Total number Threads that have timed out waiting for a lock on an Entity EJB instance [Aggregated Count]

Tip:
Pay attention to Current Waiters and Timeouts. These metrics can indicate possible performance problems caused by EJB Locking. Ideally, 0s should be displayed for these metrics.

When you select the Entity Beans node, ADP presents these metrics in a table format in the Main Display Window. Graphical representations of the following metrics, Entity EJB in use, Entity EJB cache access, and Entity EJB lock access, are displayed below the table.

Expand the Entity Beans tree by clicking the plus (+) icon next to Entity Beans node. You can get the same summary as previously described for a specific Entity EJB.

By looking at the activities related to Entity EJBs, you can determine if there any abnormal activities associated with Entity EJBs.

Note:
The metrics reported in the Entity Beans node are reported by the MBean (Management Bean) of the EJB container. These activity metrics can be used for checking the overall health of the EJB container. When the EJB container is restarted, these metrics are reset.

15.2.14.9 Message Driven Beans

The Message Driven Beans node includes activity information related to the message driven EJB components associated with the selected application. Click the Message Driven Beans node reveals an activity summary in the Main Display Window. Click the plus (+) icon to expand the Message Driven Beans node to reveal various message driven EJBs deployed as part of this application.

You can further select individual nodes to obtained detailed activity information.

The Message Driven EJB Summary includes the following tables:

- Message Driven EJB Activity

- Message Driven EJB Transactions

15.2.14.9.1 Message Driven EJB Activity

Message Driven EJB Activity table includes the following information (Table 15-81):

Table 15-81 Message Driven EJB Activity

Metric

Description

EJB

Name of the Message Driven EJB.

In Use

Number of instances for a specific Message Driven EJB currently being used from the free pool. [Snapshot Count]

Idle

Number of instances for a specific Message Driven EJB currently in the idle state in the free pool. These bean instances are available for use. [Snapshot Count]

Waits

Number of Threads currently waiting for a specific Message Driven EJB instance from the free pool. [Snapshot Count]

Timeouts

Total number of Threads that have timed out waiting for an available bean instance from the free pool. [Aggregated Count]

Tip:
Pay attention to Waits and Timeouts metrics. Activities in the Waits metric and increasing count in the Timeouts metric are signs that requests are waiting to be serviced by the EJB container. Ideally, 0 should be indicated for these metrics.

15.2.14.9.2 Message Driven EJB Transactions

Message Driven EJB Transactions table includes the following information (Table 15-82):

Table 15-82 Message Driven EJB Transactions

Metric

Description

EJB

Name of the Message Driven EJB

Commits

Total number of transactions that have been committed for this EJB [Aggregated Count]

Rollbacks

Total number of transactions that have been rolled back for this EJB [Aggregated Count]

Timeouts

Total number of transactions that have timed out for this EJB [Aggregated Count]

Tip:
High numbers of EJB Transaction Rollbacks may indicate problems with the data used; for some reason the target database is unable to commit the change. High numbers of EJB Transaction Timeouts may indicate problems accessing the database including network outage, database lock contention, database outage, and more.

ADP presents these metrics in a table format in the Main Display Window when you select the Message Driven Beans node. Graphical representation of the Message Driven EJB in use metric is displayed below the table.

By looking at the activities related to Message Driven EJBs, you can determine if there are any abnormal activities associated with Message Driven EJBs.

Note:
The metrics reported in the Message Driven Beans node are reported by the MBean (Management Bean) of the EJB container. These activity metrics can be used for checking the overall health of the EJB container. When the EJB container is restarted, these metrics are reset.

15.2.15 Oracle WebLogic Resources

The Resources node under Oracle Enterprise Manager contains information for the managed domain organized by logical clusters, machines, servers, and more. You can look for low-level technology metrics organized by technology subsystems for a specific WebLogic Server.

The Resources tree includes the following nodes (Table 15-83):

Table 15-83 WebLogic Resources Tree

Example Node

Description

CSS Domain

Name of the WebLogic Domain configured

b-15/192.168.128.15

ID of the physical machine

cgServer

Name of the WebLogic Server configured

Applications

Performance measurements of all deployed applications running on this server

JDBC

Information of all configured JDBC resources for this server

JMS Servers

Information of all JMS destinations configuration for this server

Execute Queues

Information of all Execute Queues configured for this server

JVM

JVM information including Heap Size for this server

JRockit

JRockit information including Heap Size for this server

Modeling Status

Entities modeled by ADP for this server

ADP Modules

Status of the ADP Java Agent Module for this server

Expand these nodes by clicking the plus (+) icon next to the node name to get more information.

If the ADP OS Agent is deployed on the machine, clicking on the physical machine ID would show OS metrics collected by the OS Agent. These OS metrics include CPU Usage, Disk Usage, and Physical Memory Usage.

15.2.16 WebSphere Resources

The Resources node under Oracle Enterprise Manager contains information for the managed domain organized by logical clusters, machines, servers, and more. You can look for low-level technology metrics organized by technology subsystems for a specific WebSphere Server.

The Resources tree includes the following nodes (Table 15-84):

Table 15-84 WebSphere Resources Tree

Example Node

Description

WPSSUn

Resource name, for example, WPSUn

WebSphere Portal

Machine name, for example, WebSphere_Portal

WebSphere Portal

Server name, for example, WebSphere_Portal

Applications

Performance measurements of all deployed applications running on this server

JDBC

Information of all configured JDBC resources for this server

JMS Servers

Information of all JMS destinations configuration for this server

Thread Pools

Performance information about all threads used by the container to process request

JVM

JVM information including Heap Size for this server

WebServices

Performance measurements about web services deployed in the container

Sessions

Information about active HTTP sessions

Transactions

Information about transactions performance

Cache

Information about cache performance

ORB

Information about ORB performance

Modeling Status

Modeled entities for the container

ADP Modules

Status of the ADP Java Agent Module for this server

Applications

Performance information about the applications deployed in the container

Expand these nodes by clicking the plus (+) icon next to the node name to get more information.

Clicking on the physical machine ID would show OS metrics. These OS metrics include CPU Usage, Disk Usage, and Physical Memory Usage.

15.2.17 Oracle Resources

The Resources node under Oracle Enterprise Manager contains information for the managed domain organized by logical clusters, machines, servers, and more. You can look for low-level technology metrics organized by technology subsystems for a specific Oracle AS Server.

The Resources tree includes the following nodes (Table 15-85):

Table 15-85 Oracle Resources Tree

Example Node

Description

Managed System Resource Name

Top-level Resource name, for example, oc4j_soa

Oracle AS Server

Machine name which can be navigated to both within or outside a cluster, for example, oc4j_soa@192.168.1.119 which includes both the server name and the host server IP address

Applications

Performance measurements of all deployed applications running on this server

JDBC

Information of all configured JDBC resources for this server

JMS Servers

Information of all JMS destinations configuration for this server

Thread Pools

Performance information about all threads used by the container to process requests

JVM

JVM information including Heap Size for this server

BPEL Processes

Performance measurements about BPEL Processes deployed in the container

ESB

Performance measurements about ESB services deployed in the container

Modeling Status

Modeled entities for the container

ADP Modules

Status of the ADP Java Agent Module for this server

Applications

Performance information about the applications deployed in the container

Clicking the physical machine ID would show OS metrics. These OS metrics include CPU Usage, Disk Usage, and Physical Memory Usage.

15.2.18 Custom Metrics

The Custom Metrics node under Oracle Enterprise Manager contains all the custom metrics you defined. Currently ADP supports custom metrics for Java classes. When Custom Metrics node is selected, ADP displays various summaries. You can select individual entities to get more detailed performance information.

Expanding the Custom Metrics node reveals a list of Java classes with custom metrics configured.

The following is a list of columns in the Custom Class Performance table and their descriptions (Table 15-86):

Table 15-86 Custom Class Performance

Column/Metric

Description

Caller Class

Fully qualified name of the class that is making the inbound call

Caller Method

Method name in the class that is making the inbound call

Class

Fully qualified name of the class that is the destination of the inbound call

Invocation Count

Total number of times the inbound call is made

Response Time (ms)

Average response time of the inbound call in milliseconds

15.2.19 ADP Node

The ADP node in the navigation tree contains information for the ADP environment for the monitored WebLogic domain, WebSphere cell, or Oracle AS cluster. Select the ADP node to see the ADP Java Agent status for the WebLogic domain.

The ADP Java Agent status includes the following (Table 15-87):

Table 15-87 ADP Java Agent Status

Column/Metric

Description

Server

Name of the WebLogic server, WebSphere cell, or Oracle AS cluster

Container Status

Operational status of the WebLogic, WebSphere, or Oracle AS server (running or not)

Agent In Sync

Version synchronization between ADP and ADP Agent status (true or false)

EJB Installed

ADP EJB installation status (true or false)

Agent Installed

ADP Java Agent installation status

Agent Activated

ADP Java Agent activation status

Agent Status

ADP Java Agent operational status

Server Type

Identifies server as administration, individual, or clustered server

Admin URI

Location of the domain admin server

Manager RMI Registry Host

Host name of the ADP RMI registry

Manager RMI Registry Port

Port number of the ADP RMI registry

EJB Major Version

ADP EJB major version

EJB Minor Version

ADP EJB minor version

EJB Build ID

ADP EJB build number - for version synchronization check

Agent Major Version

ADP Java Agent major version

Agent Minor Version

ADP Java Agent minor version

Agent Build ID

ADP Java Agent build number - for version synchronization check

Click the Modeling Status node under ADP node to see a table of all modeled entities in the managed domain. This table shows all the managed clusters, servers, and applications in the ADP environment. Mismatches between the Modeling Status table and your environment are indications of configuration problems.

You can use this information to debug and resolve ADP configuration issues.

15.2.20 Service Component Architecture (SCA)

Service Component Architecture (SCA) provides a set of features and services that simplify the process of detecting the presence of Service-Oriented Architecture (SOA) components.

Table 15-88 SCA Composites

Composite

Description

Services

Metrics related to Services defined on the SOA composite.

Wires

Metadata related to Wires defined in the SOA composite

References

Metrics related to References defined in the SOA composite

Components

Metrics related to Components within the SOA composite

15.2.20.1 Components

The following components make up the Service Component Architecture:

Table 15-89 Components in SCA

Component

Description

Decision Services

Metrics related to components in the Decision Services engine

Mediators

Metrics related to components in the Mediator engine

Human Workflows

Metrics related to components in the Human Workflow engine

BPEL

Metrics related to components in the BPEL engine

15.3 Exploring the Configuration Tab

Using the Configuration tab you can set up the resources you want to monitor using ADP.

The configurations explained in this section are:

- Database Configuration

- Resource Configuration

- Service Level Objective Configuration

- Action Configuration

- Custom Metric Configuration

A running ADP manager must be registered in Enterprise Manager. After the registration, Enterprise Manager continues to keep the manager as a valid manager even if it is down. When this occurs, the Enterprise Manager UI displays the ADP manager as Unreachable.

15.3.1 Database Configuration

The Database Configuration page lists the databases accessible to ADP which you want to monitor. You can configure a database to be used by ADP, edit an existing database configuration, delete a database configuration, and enable a configuration.

15.3.2 Resource Configuration

The Resource Configuration node in the Configuration tree enables you to create resources (for example, target application server domains) that can be monitored by ADP.

15.3.3 Service Level Objective Configuration

In ADP, thresholds configured for various measurements are called Service Level Objectives (SLOs). A service level objective is a measurable attribute, for example, availability. Service Level Agreements (SLA) are made up of SLOs.

Configuring SLOs is a key activity for establishing and maintaining an effective performance monitoring system. To configure a SLO, click the Configuration tab and select the Service Level Objective Configuration option.

ADP categorizes SLOs into the following types:

- Performance
Depicts the relative responsiveness of the monitored entity to the configured threshold.

- Availability
Informs you to what extent a particular entity is available to service requests.

- Errors
Informs you if the number of errors and exceptions encountered by this entity are approaching or violating the configured threshold.

- Load
Depicts how many operations have been performed and requests have been served by a particular entity.

ADP is aware of clusters. As such, these indicators display overall health of a particular entity across the entire cluster.

To configure a SLO, perform the following steps:

1. From the Targets menu, select Middleware. On the Middleware page, select Application Dependency and Performance from the Middleware Features menu. Ensure the Configuration tab is highlighted.

2. Select SLO Blackout Configuration.

3. You can view any existing SLO blackout.

4. Use this window to create, delete, or view the details of existing blackouts.

15.3.3.1 Creating a New SLO

When you select Service Level Objectives Configuration, ADP displays the Service Level Objective Configuration window. This window allows you to apply existing SLOs or create new ones. When you click Create New SLO, ADP guides you through the process of setting up a new SLO.

The steps for SLO creation are as follow:

1. Either select a SLO file or create a new SLO file. ADP can store SLO configurations in different files to improve configuration portability.

2. Define the SLO Entity Type. ADP automatically selects the appropriate entity type for you based on the selected monitoring element. For example, if you want to set a SLO on a Portal Desktop element, ADP automatically sets the Entity Type for you.

3. Other information is filled in by default. Normally, there is no need to modify the SLO Entity values.

4. When you are done setting the SLO Entity Type values, click Create New SLO to go to the second step of the SLO creation process, Defining the SLO Parameters. Note: The (*) character means Select All. It is recommended that you do not use the (*) character.

Note: SLOs are hierarchical which allows you to set service levels at any level within the modeled hierarchy of an application.

15.3.3.2 Defining SLO Parameters

Follow these steps to define the SLO parameters:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the target of choice. On the Home tab, select the Summary region and click the Application Dependency and Performance link.

2. Expand the Configuration tab. Select Service Level Objective Configuration.

3. Either create a new SLO or edit an existing SLO.

4. Select the performance metric.

5. Define the monitoring window size, which determines how long the condition must persist before generating an alert.

6. Set threshold values for the SLO.

7. Select what actions to take when a trigger is fired. A list of preconfigured actions is available in the view pane.

8. Add new actions by going to the Action Configuration node in the Configuration Workspace.

9. Click Save to set the SLO for this monitored element.

10. You can delete unwanted SLOs for any element from this window.

Types of SLOs

ADP categorizes SLOs as Performance, Availability, Error, and Load.

SLO Events Viewer

Right-click on any tree node and select View Service Level Objective Events to open a new window. You can see all the SLO violation events triggered for the selected entity. ADP automatically applies a filter to show only relevant events.

Once new SLOs are added, ADP updates the relevant graphs to visually display these new thresholds. Table 15-90 explains the different line types.

Table 15-90 SLO Line Types

Line Description

Description

Solid Red Line

A violation threshold that triggers on high.

Solid Yellow Line

A cautionary threshold that triggers on high.

Dashed Red Line

A violation threshold that triggers on low.

Dashed Yellow Line

A cautionary threshold that triggers on low.

15.3.3.3 SLO Blackout Configuration

You can prevent having unwanted alerts being fired during planned or unplanned down time. The SLO Blackout Configuration node in the Configuration tree enables you to create time periods when information will not be monitored for a specific SLO. You can define blackouts by a SLO file, an individual SLO, or by entity.

15.3.3.4 Creating and Maintaining SLO Blackouts

You can prevent having unwanted alerts being fired during planned or unplanned down time. SLO Blackout Configuration enables you to create time periods when information will not be monitored for a specific SLO. You can define blackouts by a SLO file, an individual SLO, or by entity.

To create and maintain SLO blackouts, perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. On the Middleware page, click the target of choice. Select Application Dependency and Performance from the Middleware Features menu.

2. Expand the Configuration tab. Select SLO Blackout Configuration.

3. You can view any existing SLO blackout.

4. Use this window to create, delete, or view the details of existing blackouts.

Creating SLO Blackout

1. Click Create SLO Blackout to view the detail window.

2. On the SLO Blackout File page, type the name of the blackout in the New SLO Blackout File field. Click Continue.

3. On the SLO Blackout Configuration page, fill in the fields. Refer to Table 15-91 for details.

Table 15-91 SLO Blackout Configuration

Column/Metric

Description

Blackout Name

Type in the name.

Description

Type in the description of the SLO you are creating.

Blackout By SLO File

Use to blackout at the file level. The SLO files display in a list where you can select them or cancel out of the window.

This option restricts the blackout to the SLO file name.

Blackout By SLOs

Use to blackout at the SLO level. The SLOs display in a list where you can select them or cancel out of the window.

This option restricts the blackout to the SLO name.

Blackout By Entity

Use to blackout at the entity type level. Click the Blockout by Entity: button to view the list of entity types. Select the entity.

This option restricts the blackout to the entity type selected.

year, month, date, hour, minute, duration

Use the guidelines to the right of these columns to enter the appropriate information.

recurring

Select how often you would like to run this blackout event from the list.

Viewing SLO Blackout Summary List

1. Click SLO Blackout Summary List.

2. View the details on the existing SLO Blackout events.

3. Click Show SLO Blackout List to return to the previous window.

Deleting SLO Blackout

1. Select an existing event on the list.

2. Click Delete SLO Blackout.

3. Confirm that you want to delete the entry and click Yes.

15.3.3.5 Propagating Threshold Violation Events

ADP is designed to propagate threshold violation events up the hierarchy. Therefore, when a SLO is set on a lower level metric, the higher level health indicator light becomes activated. Additionally, the health indicator light for the application server that hosts this component also becomes active. Oracle calls this containment approach to SLO event propagation. When a lower level SLO is violated, the violation event propagates all the way up the hierarchy and changes the status of all containers for this event.

15.3.4 Action Configuration

Action Configuration node in the Configuration tree allows you to manage actions for ADP. Actions are triggered by a SLO violation event. ADP supports the following actions:

- Issue a SMNP trap

- Send an e-mail

- Execute a script

- Log to a file

In the Action Configurations window you can:

- Click Create Action to create a specific type of action.

In the Action Configuration window, double-click on a specific action to see its configuration information. You can edit and copy edit selected action. ADP automatically enforces referential integrity during the deletion process.

Note:
You can include a set of SLO variables into e-mail, script, and log actions. This feature significantly increases the value of these actions by using real-time performance data. See Table 15-92 for a list of SLO variables.

Table 15-92 List of SLO Variables

SLO Variable

Description

Example Value

$EventType

SLO event type (Violation or Cautionary)

Event.SLO.Cautionary

$EventAttributes.SLOName

Name of the SLO fired

CSR Portal Desktop Response Time Violation

$Event.Attributes.SLOType

Metric where SLO violation was observed

Metrics.J2EE.JVM.HeapFree

$EventAttributes.TriggerValue

Value of metric when SLO threshold was exceeded

35001

$EventAttributes.TriggerThreshold

Threshold type (High or Low)

High

$Entity.InfrastructureID

Name of the platform

WebLogic

$Entity.NodeID

Server node where SLO violation was observed

B93/192.168.3.93

$Entity.DomainID

Domain in which SLO violation was observed

mydomain

$Entity.ResourceID

Cluster in which SLO violation was observed

my_cluster

$Entity.EntityTypeID

Type of the entity in which the SLO violation was observed

J2EE.JVM

$StartTime

Start time of the SLO violation

1112322030000

$EndTime

Stop time of the SLO violation

1112322045000

Tip:
Customize your alert using SLO variables. The following is an example of a customized message for a Mail Action:
SLO Event:
SLO Name = $EventAttributes.SLOName;
Event Type = $EventType;
Trigger Domain = $Entity.DomainID;
Trigger Application = $Entity.ApplicationID;
Trigger SLO Type = $EventAttributes.SLOType;
Trigger Value = $EventAttributes.TriggerValue;
Trigger Threshold = $EventAttributes.TriggerThreshold;
Trigger Element = $Entity.ElementID;
Event ID = $EventID;

15.3.5 Custom Metric Configuration

There are cases where additional instrumentation is needed based on your specialized requirements. Custom metrics allow you to instrument a class or method of your choice and receive performance metrics collected by the ADP agent.

To create a metric configuration, do the following:

1. From the Targets menu, select Middleware. In the Related Links sections, select Application Dependency and Performance.

2. Click the Configuration tab, choose the configuration in which you are interested. Click Custom Metric Configuration.

3. In the right pane, click the Create Custom Metric button.

4. On the Custom Metric File page, choose whether to use an existing .xml file or a new file. If you choose a new file, the ADP Manager will create the new .xml file. Click Continue.

5. On the Custom Metric Configuration page, provide the following information:

- Resource name is a monitored WebLogic domain or Oracle Application Server or WebSphere cell.
You created a name when you configured ADP to monitor. The same name is used here during custom metric configuration.

- Class name is the name of the implementation class in the code. You are required to enter a fully qualified class name.

- Method name is the name of the implementation method in the code.

After you define the custom metrics, restart the application server instances associated with these customizations. The new custom metrics will be listed under the Custom Metrics node in the ADP navigation tree.

The newly configured custom metric provides class level performance data, for example, invocation count and response time.

15.4 Exploring the Registration Tab

The managers perform complex mathematical modeling and statistical calculations with summarized data from all Java Agents.

Using the Registration tab, you can add, edit, and remove Managers configured to Enterprise Manager. By accessing ADP through Remote Method Invocation (RMI), you can manipulate all the managers configured to Enterprise Manager through a secured protocol.

15.4.1 Using RMI Configuration for Managers

In ADP, the Configuration tab lists all the managers currently configured to Enterprise Manager. By using the Configuration for Managers feature, you can access Application Dependency and Performance through Remote Method Invocation (RMI). You can then manipulate all the managers configured to Enterprise Manager through a secured protocol. The following sections provide additional information.

- Adding a New Manager (RMI Configuration)

- Editing a Previously Configured Manager (RMI Configuration)

- Removing or Disabling a Previously Configured Manager

The Configuration tab displays only if the Enterprise Manager user is an Administrator as defined by examining the user's role.

15.4.2 Adding a New Manager (RMI Configuration)

The first time the Registration tab displays there are no managers in the Managers tree. To add a new manager, perform the following steps:

1. Navigate to the Application Dependency and Performance feature.
From the Targets menu, select Middleware. In the Related Links section, click Application Dependency and Performance.

2. In the Registration tab, click the Managers node in the tree.

3. Type the new manager information in the Main Display window.

4. Decide whether this manager should be monitored.
Request monitoring provides end-to-end visibility into requests, localizes end-user performance problems to specific application deployments, and provides a platform for context-based drill down diagnostics.

When you select Enable Request Monitoring, ADP creates and sets up targets for collecting request performance data. If you do not select Enable Request Monitoring, the ADP manager is only registered in Enterprise Manager.

Note:
The grayed out information represents configuration data for connecting to the ADP manager by way of a secure protocol, for example Key Store, Trust Store, and passwords. This information is extracted from the ADP manager by way of the RMI call.

5. If you enable request monitoring on an existing manager, click Upload to populate the manager configuration properties to the ADP target in Request Monitoring.

6. Click Test Connect to test the connection to the new manager. Should the test connection fail, this may be because the manager is not running or the manager is not yet installed.

7. Click Add.

Once the manager is added, the name of the manager will display in the Configuration tab under the Managers node in the tree.

15.4.3 Editing a Previously Configured Manager (RMI Configuration)

To add a previously configured manager, perform the following steps:

1. Click + (plus sign) next to the Managers node in the tree, then select the subnode for the manager you want to edit.

2. After you make changes to the manager information, click Update. This results in the manager entries in the Enterprise Manager repository to be updated with the new values.

If a manager is configured before using this Enterprise Manager configuration page, Enterprise Manager continues to keep the manager as a valid manager even though the manager may be down or permanently removed.

The list of managers is not refreshed.

15.4.4 Removing or Disabling a Previously Configured Manager

To remove a configured manager, perform the following steps:

1. Navigate to Application Dependency and Performance.
From the Targets menu, select Middleware. In the Related Links section, click Application Dependency and Performance.

2. Click the Registration tab.

3. Click + (plus sign) next to the Managers node in the tree, then select the subnode for the manager you want to remove.

4. Click Remove in the main pane.
Deleting a manager from Enterprise Manager does not uninstall and remove the manager from the remote host where the manager is located and may be running. Remove only deletes the manager entry from the Enterprise Manager repository.

To shut down the manager after the Remove operation, execute the acshut.sh/.bat command from the command line.

To disable a configured manager:

1. Click + (plus sign) next to the Managers node in the tree, then select the subnode for the manager you want to disable.

2. Deselect Enable Request Monitoring.

3. Click Update.

When you deselect the Enable Request Monitoring option, the manager settings are preserved. The UI displays these managers as disabled. There will not be any further information under the disabled manager in the tree.

16 Exporting Data

This chapter includes the following export features:

- Data Export Modes

- ADP Export Configuration

- Example of Exported Data for WebLogic

16.1 Data Export Modes

There are three different modes to export performance data collected by ADP to external databases and other persistence formats. These modes give you flexibility to choose the best way to extract performance data from ADP.

- Export to File

- Export to Database

- Aggregation Export to File

16.1.1 Export to File

In this mode, ADP exports its raw performance data as several CSV (comma separated value) files.

16.1.2 Export to Database

In this mode, ADP exports its raw performance data as several ANSI SQL statements. These SQL statements allow you to create tables and insert data.

16.1.3 Aggregation Export to File

In this mode, ADP exports its aggregated performance data after it's daily aggregation operation as several CSV files.

16.2 ADP Export Configuration

The following sections describe ADP export configuration:

- ADP Periodic Export Configuration

- Manual Execution of Metric Export

- export.xml File

16.2.1 ADP Periodic Export Configuration

ADP stores real-time performance metrics in its internal data repository (Oracle database). If you want to store this data in your historical data repository, ADP provides automatic means for performance data export. You can control the frequency of export runs, the time when the export should run, and the time range of export data within a day.

Example 16-1 ADP Export Configuration

# Setting for integrated export
AggregationManager.IntegratedExport = false
AggregationManager.ExportDataStartHour = 0
AggregationManager.ExportDataEndHour = 0
AggregationManager.ExportDataSetRangeInHour = 4
AggregationManager.ExportDataSetIntervalInHour = 1
AggregationManager.ExportDataSetDelay = 10000
AggregationManager.ExportStartTime = 0
AggregationManager.ExportEndTime = 0
AggregationManager.ExportFilePurgeTime = 10d

By default, automatic data export feature is disabled. To enable it, set AggregationManager.IntegratedExport parameter to true. A pair of parameters, AggregationManager.ExportDataStartHour and AggregationManager.ExportDataEndHour, indicates the time range within a day of the export performance data in which you are interested. By default it is 24 hours.

Parameter AggregationManager.ExportDataSetRangeInHour shows how much data is stored in each export file. By default it is 4 hours worth of data. This means that ADP will create multiple export data files with 4 hours worth of data.

To minimize export query impact on normal ADP performance data collection functionality, spread out lengthy data exporting queries. This is achieved by setting AggregationManager.ExportDataSetIntervalInHour parameter. By default it is 1 hour. This means that export query thread will be running every hour.

AggregationManager.ExportDataSetDelay defines cool down time for consecutive export queries. By default it is 10 seconds. This means that the next export query will happen not earlier than 10 seconds after the previous one.

AggregationManager.ExportFilePurgeTime indicates how many days the export data file will be available before ADP deletes it. By default it is 10 days. Current default values are optimal and this section should not be changed except from enabling the automatic export feature.

Automatic export function relies on the definition of the data to be exported by looking into $GCDomain/EMGC_ADPMANAGER1/ADPManager.ear/ADPManager.war/config/export.xml file and exports performance data based on the rules defined in this file.

The output directory is specified in export.xml and will be overwritten on each export interval.

16.2.2 Manual Execution of Metric Export

The bin directory on the ADP manager contains scripts called runExportMetric.sh/bat and runExportEvent.sh/bat that export metrics and events (such as alerts) to CSV files, respectively.

Run runExportMetric.sh like:

./runExportMetric.sh <path to export.xml configuration> <start time> <end time>

For example:

C:\oracle\em11g\bin\runExportMetric.bat c:\oracle\em11g\config\export.xml
"4/1/09 16:06:00" "4/1/09 16:36:00"

The start time and end time are in the machine's local time zone. The output exported csv files' timestamps will be in UTC/GMT.

16.2.3 export.xml File

The export.xml file contains all the directives and filters required to export performance metrics and events. This file is used by the ADP Integrated Automatic export feature as well as manual export scripts.

Example 16-2 Contents of export.xml File

<?xml version="1.0" encoding="UTF-8"?>
<export xmlns="http://www.acsera.com/ns/export" verbose="true" exportMetric="true"
exportEvent="true" metricDataGrain="180s" exportFullMetric="true">
<!--
<output type="jdbc" convertTimeFormat="true"
arguments="access,metric,sun.jdbc.odbc.JdbcOdbcDriver,jdbc:odbc:acsera"/>
-->
<output type="file" convertTimeFormat="false"
arguments="/home/acsera/acsera/export,metric"/>
<entityTypes exportAllTypes="false">
<entityType name="BEA.ProcessNode"/>
<entityType name="J2EE.Dispatcher"/>
<entityType name="J2EE.JDBC.ConnectionPool"/>
<entityType name="J2EE.JVM"/>
</entityTypes>
<!--extra filter -->
<!--
<filters>
<filter key="containerID" values="cgServer"/>
</filters>
-->
<!-- don't modify this -->
<columns>
<column header="Timestamp" type="Timestamp"/>
<column header="EntityID" type="EntityID"/>
<column header="Application" type="Entity" key="applicationID" default=""/>
</columns>
</export>

The following tables explain the various attributes.

Table 16-1 Attributes on <export>

Attribute

Description

exportMetric

true/false, whether to export performance metrics

exportEvent

true/false, whether to export SLO events

metricDataGrain

60s, 180s, or 1800s, the metric aggregation tier to export. Note that the population of the 180s tier will be delayed by 1.25 hours and the 1800s tier will be delayed by 7 hours compared to the 60s tier.

exportFullMetric

true/false, whether to include sum, count, min, and max metrics or not.

Table 16-2 Attributes on <output>

Attribute

Description

type

file/jdbc, whether to output to csv files or to write data to another database using JDBC. In the case of JDBC output, the necessary tables will be created automatically by the export mechanism.

convertTimeFormat

true/false, whether to convert the metric timestamp to human readable format (in UTC/GMT). If false, the timestamp will be a long integer. Provide the arguments (jdbc) in a comma separated list.

arguments

See Table 16-3 and Table 16-4 for details.

Table 16-3 Value of the "arguments" Attribute of the <output> Element When the "type" Attribute Is "JDBC"

Attribute

Description

First Parameter

Database type, an arbitrary string

Second Parameter

Table prefix name, should always be metric

Third Parameter

Fully qualified JDBC driver class

Fourth Parameter

JDBC URL

Table 16-4 Value of the "arguments" Attribute of the <output> Element When the "type" Is "file"

Argument

Description

First Parameter

CSV file output directory (this directory will be created, existing files will be overwritten)

Second Parameter

Table prefix name, should always be metric

Table 16-5 Attribute of the <entityTypes> Element

Attribute

Description

exportAllTypes

true/false, whether to output all entity types or only the ones specified in <entityType> elements.

Table 16-6 Attribute of the <entityType> Element

Attribute

Description

name

Name of the entityType to include in the export if exportAllTypes is set to false

16.3 Example of Exported Data for WebLogic

The tables in this section describe the fields in the various export files.

- Export File Name: metricBEA_ChannelInstance.csv

- Export File Name: metricBEA_ProcessType.csv

- Export File Name: metricBEA_TimerEventGenerator.csv

- Export File Name: metricJ2EE_Dispatcher.csv

- Export File Name: metricJ2EE_EJB_Entity.csv

- Export File Name: metricJ2EE_EJB_Stateless.csv

- Export File Name: metricJ2EE_JDBC_ConnectionPool.csv

- Export File Name: metricJ2EE_JMS_Destination.csv

- Export File Name: metricJ2EE_JMS_Service.csv

- Export File Name: metricJ2EE_JVM.csv

- Export File Name: metricJ2EE_Server.csv

- Export File Name: metricJ2EE_Servlet.csv

Table 16-7 Export File Name: metricBEA_ChannelInstance.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Fully qualified name of the channel

channelID

Fully qualified name of the channel

serviceID

URL of the service / JPD

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

containerID

Name of the Oracle WebLogic Server instance

nodeID

Name of the physical machine

domainID

Name of the Oracle WebLogic domain

displayNameID

Display name

resourceID

Name of the monitored resource as configured by the user

entityTypeID

Type of the monitored entity

Metric.J2EE.ChannelInstance.MessageCount

JMX metric

Metric.J2EE.ChannelInstance.DeadMessageCount

JMX metric

Table 16-8 Export File Name: metricBEA_ProcessType.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Implementation class name

processID

Display name of the process

serviceID

URL of the service / JPD

projectID

Name of Workshop project / web application module

containerID

Name of the Oracle WebLogic Server instance

nodeID

Name of the physical machine

domainID

Name of the Oracle WebLogic domain

entityTypeID

Type of the monitored entity

applicationID

Name of the Application

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

deploymentID

Unique ID used by Oracle WebLogic to track application deployments

resourceID

Name of the monitored resource as configured by the user

displayNameID

Display name

controlContainerID

Implementation class name of the process

Metric.J2EE.ProcessType.Arrivals

Instrumentation metric -- number of arrivals

Metric.J2EE.ProcessType.Aborts

Instrumentation metric -- number of aborts

Metric.J2EE.ProcessType.ElapsedTime

Instrumentation metric -- average elapsed time

Metric.J2EE.ProcessType.Active

Instrumentation metric -- number of active requests

Metric.J2EE.ProcessType.VisitCount

Instrumentation metric -- number of completed requests

Metric.J2EE.ProcessType.Exceptions

Instrumentation metric -- number of exceptions

Table 16-9 Export File Name: metricBEA_TimerEventGenerator.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Fully qualified name of the channel

channelID

Fully qualified name of the channel

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

channelTxID

Fully qualified name of the channel

domainID

Name of the Oracle WebLogic domain

displayNameID

Display name

resourceID

Name of the monitored resource as configured by the user

entityTypeID

Type of the monitored entity

Metric.J2EE.TimerEventGenerator.MessageCount

JMX metric

Metric.J2EE.TimerEventGenerator.ErrorCount

JMX metric

Table 16-10 Export File Name: metricJ2EE_Dispatcher.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Fully qualified name of the Execute Queue

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

containerID

Name of the Oracle WebLogic Server instance

nodeID

Name of the physical machine

domainID

Name of the Oracle WebLogic domain

executeQueueID

Name of the Execute Queue as configured by user

displayNameID

Display name

resourceID

Name of the monitored resource as configured by the user

entityTypeID

Type of the monitored entity

Metric.J2EE.Dispatcher.ServicedRequestsTotalCount

JMX metric

Metric.J2EE.Dispatcher.IdleThreads

JMX metric

Metric.J2EE.Dispatcher.PendingRequests

JMX metric

Table 16-11 Export File Name: metricJ2EE_EJB_Entity.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

methodID

Name of the EJB method executed

domainID

Name of the Oracle WebLogic domain

entityTypeID

Type of the monitored entity

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

ejbID

Name of the EJB

webApplicationID

Name of the web module

displayNameID

Display name

controlContainerTypeID

Identifies type of control

elementID

Implementation class name

processID

Display name of the process

serviceID

URL of the service / JPD

projectID

Name of Workshop project / web application module

containerID

Name of the Oracle WebLogic Server instance

nodeID

Name of the physical machine

ejbComponentID

Name of Java EE component that contains this EJB

applicationID

Name of the Application

resourceID

Name of the monitored resource as configured by the user

controlContainerID

Implementation class name of the process

Metric.J2EE.EJB.Entity.Locking.LockManagerAccessCount

JMX metric

Metric.J2EE.EJB.Entity.ResponseTime

Instrumentation metric -- response time

Metric.J2EE.EJB.Entity.Cache.BeansCurrentCount

JMX metric

Metric.J2EE.EJB.Entity.Cache.AccessCount

JMX metric

Metric.J2EE.EJB.Entity.Pool.WaiterCurrentCount

JMX metric

Metric.J2EE.EJB.Entity.Transaction.CommittedTotalCount

JMX metric

Metric.J2EE.EJB.Entity.Locking.WaiterTotalCount

JMX metric

Metric.J2EE.EJB.Entity.Transaction.TimedOutTotalCount

JMX metric

Metric.J2EE.EJB.Entity.Cache.HitCount

JMX metric

Metric.J2EE.EJB.Entity.Locking.WaiterCurrentCount

JMX metric

Metric.J2EE.EJB.Entity.Pool.IdleCount

JMX metric

Metric.J2EE.EJB.Entity.Locking.EntriesCurrentCount

JMX metric

Metric.J2EE.EJB.Entity.VisitCount

Instrumentation metric -- invocation count

Metric.J2EE.EJB.Entity.Locking.TimeoutTotalCount

JMX metric

Metric.J2EE.EJB.Entity.Pool.InUseCount

JMX metric

Metric.J2EE.EJB.Entity.Pool.WaiterTotalCount

JMX metric

Metric.J2EE.EJB.Entity.Pool.TimeoutTotalCount

JMX metric

Metric.J2EE.EJB.Entity.Transaction.RolledBackTotalCount

JMX metric

Metric.J2EE.EJB.Entity.Cache.ActivationCount

JMX metric

Metric.J2EE.EJB.Entity.Cache.PassivationCount

JMX metric

Table 16-12 Export File Name: metricJ2EE_EJB_Stateless.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Implementation class name

projectID

Name of Workshop project / web application module

nodeID

Name of the physical machine

containerID

Name of the Oracle WebLogic Server instance

domainID

Name of the Oracle WebLogic domain

ejbComponentID

Name of Java EE component that contains this EJB

entityTypeID

Type of the monitored entity

applicationID

Name of the Application

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

ejbID

Name of the EJB

resourceID

Name of the monitored resource as configured by the user

displayNameID

Display name

Metric.J2EE.EJB.Stateless.Transaction.TimedOutTotalCount

JMX metric

Metric.J2EE.EJB.Stateless.Pool.WaiterTotalCount

JMX metric

Metric.J2EE.EJB.Stateless.Pool.InUseCount

JMX metric

Metric.J2EE.EJB.Stateless.Transaction.CommittedTotalCount

JMX metric

Metric.J2EE.EJB.Stateless.Transaction.RolledBackTotalCount

JMX metric

Metric.J2EE.EJB.Stateless.Pool.IdleCount

JMX metric

Metric.J2EE.EJB.Stateless.Pool.TimeoutTotalCount

JMX metric

Table 16-13 Export File Name: metricJ2EE_JDBC_ConnectionPool.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Name of JDBC connection pool

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

containerID

Name of the Oracle WebLogic Server instance

nodeID

Name of the physical machine

domainID

Name of the Oracle WebLogic domain

displayNameID

Display name

resourceID

Name of the monitored resource as configured by the user

entityTypeID

Type of the monitored entity

Metric.J2EE.JDBC.ConnectionPool.WaitingForConnectionCurrentCount

JMX metric

Metric.J2EE.JDBC.ConnectionPool.WaitingForConnectionHighCount

JMX metric

Metric.J2EE.JDBC.ConnectionPool.ActiveConnectionsHighCount

JMX metric

Metric.J2EE.JDBC.ConnectionPool.ActiveConnectionsCurrentCount

JMX metric

Metric.J2EE.JDBC.ConnectionPool.FailuresToReconnectCount

JMX metric

Metric.J2EE.JDBC.ConnectionPool.WaitSecondsHighCount

JMX metric

Metric.J2EE.JDBC.ConnectionPool.ConnectionDelayTime

JMX metric

Table 16-14 Export File Name: metricJ2EE_JMS_Destination.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Name of JMS destination

nodeID

Name of the physical machine

containerID

Name of the Oracle WebLogic Server instance

jmsServerRuntimeID

Name of the JMS server

domainID

Name of the Oracle WebLogic domain

jmsDistributedQueueMemberID

Name of the JMS distributed queue member

entityTypeID

Type of the monitored entity

jmsQueueID

Name of the JMS queue

jmsRuntimeID

Name of the JMS service

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

jmsDistributedQueueID

Name of the JMS distributed queue

resourceID

Name of the monitored resource as configured by the user.

displayNameID

Display name

Metric.J2EE.JMS.Destination.ConsumersCurrentCount

JMX metric

Metric.J2EE.JMS.Destination.BytesCurrentCount

JMX metric

Metric.J2EE.JMS.Destination.MessagesPendingCount

JMX metric

Metric.J2EE.JMS.Destination.BytesThresholdTime

JMX metric

Metric.J2EE.JMS.Destination.MessagesHighCount

JMX metric

Metric.J2EE.JMS.Destination.BytesReceivedCount

JMX metric

Metric.J2EE.JMS.Destination.MessagesReceivedCount

JMX metric

Metric.J2EE.JMS.Destination.BytesHighCount

JMX metric

Metric.J2EE.JMS.Destination.MessagesCurrentCount

JMX metric

Metric.J2EE.JMS.Destination.ConsumersTotalCount

JMX metric

Metric.J2EE.JMS.Destination.ConsumersHighCount

JMX metric

Metric.J2EE.JMS.Destination.BytesPendingCount

JMX metric

Table 16-15 Export File Name: metricJ2EE_JMS_Service.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Name of the JMS service

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

containerID

Name of the Oracle WebLogic Server instance

nodeID

Name of the physical machine

domainID

Name of the Oracle WebLogic domain

displayNameID

Display name

resourceID

Name of the monitored resource as configured by the user

entityTypeID

Type of the monitored entity

jmsRuntimeID

Name of the JMS service

Metric.J2EE.JMS.Service.ConnectionsHighCount

JMX metric

Metric.J2EE.JMS.Service.ConnectionsCurrentCount

JMX metric

Metric.J2EE.JMS.Service.JMSServersCurrentCount

JMX metric

Metric.J2EE.JMS.Service.JMSServersHighCount

JMX metric

Metric.J2EE.JMS.Service.ConnectionsTotalCount

JMX metric

Metric.J2EE.JMS.Service.JMSServersTotalCount

JMX metric

Table 16-16 Export File Name: metricJ2EE_JVM.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Name of the JVM

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

containerID

Name of the Oracle WebLogic Server instance

nodeID

Name of the physical machine

domainID

Name of the Oracle WebLogic domain

displayNameID

Display name

resourceID

Name of the monitored resource as configured by the user

entityTypeID

Type of the monitored entity

Metric.J2EE.JVM.JRockit.HeapSizeCurrent

JMX metric

Metric.J2EE.JVM.JRockit.HeapFreeCurrent

JMX metric

Metric.J2EE.JVM.JRockit.PhysMemTotal

JMX metric

Metric.J2EE.JVM.JRockit.PhysMemUsed

JMX metric

Metric.J2EE.JVM.JRockit.GarbageCollectionCountTotal

JMX metric

Metric.J2EE.JVM.JRockit.GarbageCollectionTimeTotal

JMX metric

Metric.J2EE.JVM.HeapFreeCurrent

JMX metric

Metric.J2EE.JVM.JRockit.PhysMemFree

JMX metric

Metric.J2EE.JVM.JRockit.NursurySizeTotal

JMX metric

Metric.J2EE.JVM.JRockit.ActiveDaemonThreads

JMX metric

Metric.J2EE.JVM.JRockit.ActiveThreads

JMX metric

Metric.J2EE.JVM.HeapSizeCurrent

JMX metric

Metric.J2EE.JVM.JRockit.HeapUsedCurrent

JMX metric

Table 16-17 Export File Name: metricJ2EE_Server.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Name of the Java EE server instance

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

containerID

Name of the Java EE server instance

nodeID

Name of the physical machine

domainID

Name of the Oracle WebLogic domain

displayNameID

Display name

resourceID

Name of the monitored resource as configured by the user

entityTypeID

Type of the monitored entity

Metric.J2EE.Server.RestartsTotalCount

JMX metric

Table 16-18 Export File Name: metricJ2EE_Servlet.csv

Field

Description

StartTime

Clock time (long) at data insertion

EntityID

ADP unique identifier for the monitored entity

elementID

Name of the servlet implementation class

applicationID

Name of the Application

infrastructureID

ID of the monitoring infrastructure. Oracle is the only value at this time.

containerID

Name of the Oracle WebLogic Server instance

nodeID

Name of the physical machine

domainID

Name of the Oracle WebLogic domain

servletID

Name of the servlet

webApplicationID

Name of the web module

displayNameID

Display name

resourceID

Name of the monitored resource as configured by the user

entityTypeID

Type of the monitored entity

Metric.J2EE.Servlet.InvocationTotalCount

JMX metric

Metric.J2EE.Servlet.ExecutionTimeAverage

JMX metric

17 ADP Methodology

The Enterprise Manager Application Dependency and Performance (ADP) capabilities automatically select performance metrics and track contextual relationships for various applications. The methodology focuses on other important activities to allow you to setup and maintain an effective application performance monitoring environment.

These activities include the following:

Figure 17-1 Steps of ADP Methodology

This methodology describes a series of steps for users to establish and maintain a proactive application performance monitoring environment leveraging the Enterprise Manager Application Dependency and Performance capabilities. Figure 17-1 illustrates these steps in a sequential order.

Methodology steps:

1. Map business Service Level Agreements (SLAs) to performance Service Level Objectives (SLOs).
The process of using agreed business SLAs to determine the value of performance SLOs.

2. Specify target performance characteristics.
Specify the ideal application performance characteristics using performance SLOs identified in step 1.

3. Characterize baseline performance.

4. Identify performance bottlenecks.

5. Remove performance bottlenecks.
Steps 3, 4, and 5 should be grouped together to form a process of incremental performance improvement. Iterations of this process may be required to improve the application performance to meet the performance target as specified in step 2.

6. Set SLOs on key metrics.

Once application performance reaches the targeted goal, you need to set performance SLOs on key metrics to establish a proactive monitoring environment. This environment provides you with warnings when key performance metrics start to report abnormalities. These warnings enable you to proactively solve potential problems before they begin to impact business.

This chapter explains the following activities in more detail:

- ADP Methodology Activities

- Mapping Business SLAs to Performance SLOs

- Characterizing Baseline Performance

- Identifying Performance Bottlenecks

- Setting SLOs on Key Metrics

17.1 ADP Methodology Activities

The ADP methodology activities include the following:

- Mapping Business SLAs to Performance SLOs

- Specifying Target Performance Characteristics

- Improving Performance

17.1.1 Mapping Business SLAs to Performance SLOs

To successfully setup a proactive application performance monitoring environment, the first step is to map a set of business objectives to a set of performance thresholds for you to monitor. These business objectives are often referred to as business service level agreements (SLAs). These business SLAs provide the basic application performance requirements at a high level. As such, mapping these high level SLAs to low level performance thresholds is often a very difficult activity to do well.

Using tools that only measure performance at technology levels (EJB, JSP, servlet, portlet, SQL calls, and so on) to perform this type of activity continues to be very difficult as the correlations between low-level metrics and high-level objectives are often fuzzy at best. Consequently, the mapping activity is considered by many as an art rather than a science.

By measuring performance at both technology and functional levels, Enterprise Manager makes this mapping activity significantly less complicated. Since functional metrics measure performance for high level constructs such as business processes or portal desktops, mapping business SLAs directly to performance SLOs (Service Level Objectives) is straightforward.

17.1.2 Specifying Target Performance Characteristics

Defining the target performance characteristics for the monitored applications is the next step after mapping business SLAs to performance SLOs. Since these SLOs represent absolute minimal performance requirements for these applications, using these violation thresholds as target performance characteristics makes little sense. Instead, you need to define what performance range is acceptable for normal operation and when to send out cautionary alerts for abnormal activities.

For some applications, it may be sufficient to just specify a set of cautionary performance thresholds. Application performance monitoring tools, such as ADP, will send out cautionary alerts if these thresholds have been breached. Since these thresholds are cautionary, it may be acceptable to have a few violations before an alert is sent out. By defining the minimal violation duration, you can minimize the number of duplicate alerts generated. Figure 17-2 illustrates this concept.

Figure 17-2 Control Number of Alerts

In Figure 17-2, the minimal violation duration is defined to be 15 seconds. So if the cautionary state does not persist for more than 15 seconds, no cautionary alert would be fired.

For other applications, it is necessary to define both a high and low performance thresholds. Having both thresholds would effectively define a normal range of operation for these applications. With ADP, both high and low triggers can be set for any SLO.

With a set of clearly defined target performance characteristics, you are able to determine how much performance tuning is needed to achieve the ideal performance range. You will also have a set of cautionary performance thresholds to enable a proactive application performance monitoring environment to be established.

17.1.3 Improving Performance

The activities explained in this section should be grouped together as a single performance improvement process. This process would start with characterizing the baseline performance of our application, move on to identifying performance bottlenecks, and finish with removing performance bottlenecks. We would continue to perform these activities in iterations until the performance of our application meets the target characteristics.

17.1.3.1 Characterizing Baseline Performance

Once the specification of the target performance characteristics is completed, the next activity is to capture the performance baseline for our application. The performance baseline will be compared with the set of target performance characteristics to determine if further performance improvement is needed. If so, you will improve application performance iteratively through the next two steps until the performance meets the target characteristics.

17.1.3.2 Identifying Performance Bottlenecks

To identify performance bottlenecks, you must first isolate performance abnormalities in your performance baseline. Once you isolate a performance abnormality, you need to determine if this issue is a localized occurrence or a systematic problem. By using monitoring and diagnostic tools available to you, you can perform the analysis needed to identify the cause of the performance bottleneck.

17.1.3.3 Removing Performance Bottlenecks

Once these performance bottlenecks are identified, you need to determine how to remove them. The strategies for bottleneck removal vary by cause. A few examples follow:

- If the cause of the bottleneck is an application defect, the strategy would involve the application development team.

- If the bottleneck is caused by a configuration problem, you would request assistance from system administrators.

- If the bottleneck is in the application server or framework, you would seek help from those vendors.

The following is a list of possible bottleneck removal activities:

- Change application code to fix defects

- Modify environment setting to fix configuration problem

- Install patches to fix software defects

- Replace defective hardware

- Upgrade network infrastructure

- Add computing resources

- Remove resource hogging programs

- Tune back-end connectivity and response time

As you can see from the list, the Remove Performance Bottlenecks activity varies widely by cause. Correctly and quickly finding the appropriate groups to help resolve performance bottlenecks is the key for success for this activity. Once the performance bottleneck removal is completed, you must redo the Characterize Baseline Performance activity to confirm the fix implemented indeed improved performance.

17.1.3.4 Setting SLOs on Key Metrics

In addition to setting application specific performance thresholds, it is also important to set performance thresholds on key system metrics and on some selective component metrics. Setting these thresholds will help you establish an early warning system and alert you to smaller issues before they manifest into big production problems.

Setting SLOs on key system metrics involves some basic understanding of how the system behaves under load. If the system becomes unstable or performs poorly when it runs out of free JDBC connections or idle ExecuteQueue threads, these system metrics should be monitored.

To determine which system metrics to monitor, it is critical to figure out the correlations between overall system performance and specific system metrics. You would use this information to decide which of the system metrics to monitor. Once appropriate system metrics are identified, you will then determine the performance range for normal operation and figure out the cautionary as well as violation thresholds.

While it is fairly straightforward to determine which system metrics to monitor and what system metric performance thresholds to set, setting SLOs on key component metrics is significantly more difficult. In theory, you can assume performance degradation at the component level would negatively impact application level performance. However, this assumption may not accurately reflect reality.

To predict application performance by monitoring component level performance metrics, there must be a very strong correlation between the performance of a specific component and that of the application. Sometimes, a drop in performance in one component is compensated by a jump in performance in another. These performance changes in opposite directions at the component level would essentially result in little change at the application level. Therefore, you must be careful not to draw conclusions by monitoring the performance of a few components unless there are strong correlations.

The last task to perform is to associate various actions and responses for various threshold violations. Once these associations are completed, you can begin to use your proactive application performance monitoring environment.

17.2 Mapping Business SLAs to Performance SLOs

One of the primary reasons companies purchase solutions to establish proactive application performance monitoring is the demand to meet business SLAs. Business SLAs for enterprise applications are a set of service level expectations defined by internal or external customers. In most cases, these business SLAs are defined at such a high level, they are not useful for setting thresholds in application performance monitoring tools.

As a result, the process of mapping business SLAs to performance SLOs is extremely important for companies to meet the service requirements set forth by their customers. Since Enterprise Manager monitors performance at both functional and technology levels, it is easy to perform this mapping exercise.

In this section, our example explains how to use the Enterprise Manager Application Dependency and Performance features to determine the proper performance threshold values for a set of business SLAs.

In the example, we were given the following high-level business SLAs:

Table 17-1 Example - Guidelines for Business SLAs

Business SLA

SLA Requirement

Fast customer self-service portal.

On average, pages in customer self-service portal should load within 2 seconds. This SLA must be fulfilled 99% of the time.

Customer service representative portal must be as fast as mainframe system.

All pages in customer service rep. portal must load within 6 seconds. This SLA must be fulfilled 99.9% of the time.

Fast to schedule a service call.

On average, scheduling a service call should take less than 30 seconds. This SLA must be fulfilled 99.99% of the time.

Let's map the first business SLA to a performance SLO. This SLA requirement states that the average response time for customer self-service portal (desktop) should be less than 2 seconds. In Enterprise Manager, we would set a high-level performance SLO at the desktop. Using the hierarchy in the ADP UI, you would select the customer desktop and right-click to set the SLO.

Because ADP monitors performance at both functional and technology levels, you can directly translate business SLAs to SLOs on functional metrics. In our example, it is the response time for portal desktop customer. For our example, we would proceed to set a violation SLO and a warning SLO.

We can calculate how often violations occur to figure out whether or not our current system is able to meet the SLA requirement 99% of the time. With Enterprise Manager, we can see whether there are any obvious violations. If there are any violations or close calls, we should confirm by examining actual data. If we have data for at least 24 hours, we would use the export capability within Enterprise Manager Application Dependency and Performance to prepare raw data for this calculation.

For the other two business SLAs, we would set performance SLOs on the appropriate metrics.

17.3 Characterizing Baseline Performance

Also known as performance base-lining, characterize baseline performance involves a set of activities to capture the baseline performance of a system under specific level of load. For example, you can measure the baseline performance of a portal application deployed to a WebLogic cluster.

For example, you can display the performance data during the first four hours of a load test. The number of active sessions grows at a steady pace for the first ninety minutes. Eventually, the number of active sessions stays at approximately seven hundred as the number of new and expiring sessions reach an equilibrium.

Visualize the portal performance following a typical pattern of slow performance initially and gradually reaching a steady state. The initial slow performance is expected as the application server load components into memory and populates data into its caching mechanism. The performance improves gradually and reaches a steady state after approximately thirty minutes. The performance pattern during this initial thirty-minute period can be characterized as startup performance during increasing load. After thirty minutes, performance of the portal application stabilizes.

Enterprise Manager's ability to quickly establish an application performance monitoring environment allows you to carry out characterize baseline performance painlessly. Because Enterprise Manager is able to monitor at cluster level as well as at individual server level, it can characterize performance for the entire cluster or individual servers.

By verifying that a less loaded server has lower resource utilization and faster performance, you can draw the following observations about the performance characteristics of a portal application running on this environment:

- Since Server A's resource utilization is near maximum, we can use the load on that server as the maximum limit for individual servers. We can calculate individual server maximum load limit by using the load metric provided by the Enterprise Manager Application Dependency and Performance features.

- We should examine the load balancing algorithm and the configuration of the load balancer.

Comparing load and resource usage of two servers in a cluster confirms resource usage is inversely correlated to the load.

Note:
This is a very basic performance characterization of an individual server. Performance of a multi-server cluster cannot be calculated by multiplying performance characteristics of individual servers because of the overhead involved with a clustered configuration. True cluster level performance must be measured with application performance monitoring tools like Enterprise Manager.

17.4 Identifying Performance Bottlenecks

Enterprise Manager can also be used to quickly identify performance bottlenecks in QA, staging, and production settings. You can use the hierarchical model within the Enterprise Manager Application Dependency and Performance feature to identify an application performance bottleneck. Furthermore, you can use Enterprise Manager to track down an application performance problem caused by resource starvation.

17.4.1 Determining System Level Performance

Since the performance problem seems to affect all components in the same way, we should suspect there is some type of performance degradation at the system level. To view system level performance data, we would look under the Resources hierarchy. Performance metrics under the Resources hierarchy provides the raw data for us to perform correlation analysis. This type of analysis is needed to determine whether resource starvation is the cause of the performance slowdown.

Graphs can reveal some interesting patterns.

- OS Agent Abnormalities
We noticed a sudden drop in CPU utilization and a sudden increase in disk utilization during the time period in question. This pattern indicates a large amount of virtual memory paging activities on this machine. Memory paging to disk is extremely expensive and slows down request processing as indicated by lowered CPU utilization. To understand why page is occurring, we will take a look at performance metrics on the JVM.

- JVM Heap Size
We noticed that for the initial twelve hours of this example, both total JVM heap size and free JVM heap size grew at a steady pace. The growth of the total JVM heap size stopped at 512 MB - an expected behavior since we configured WebLogic to have a maximum heap size of 512 MB. While we expect the free JVM heap size to stop growing after total heap size reached 512 MB, the free JVM heap size actually starts to drop. Combining this information with some previously obtained information such as no sudden increase in load, we can conclude that there is a high likelihood of a memory leak.

This abnormal consumption of memory caused the total JVM heap to reach its pre-defined maximum. It is also very likely this memory leak caused the increase in virtual memory paging activities and corresponding reduction in CPU utilization. This reduction in CPU utilization impacts the response time for all components running in this machine including JDBC Connections.

- Memory Leak
We were able to identify a memory leak in the WebLogic JVM gradually caused resource starvation and eventually impacts application performance. In order to further diagnose this problem, a deep-level memory profiling tool is required to understand memory usage of the JVM.

17.5 Setting SLOs on Key Metrics

This step in the Oracle Methodology allows you to proactively monitor key system metrics to avoid catastrophic failures such as server hangs (non-responsive), server crashes, cluster hangs, and more. The ability to recognize signs leading up to these catastrophic failures is a must to maintain quality of service for your WebLogic infrastructure.

You can proactively set thresholds and actions for key WebLogic system metrics. Table 17-2 lists the key system metrics for the WebLogic Platform:

Table 17-2 List of Key System Metrics for WebLogic

Key System Metric

Reason to Monitor

ExecuteQueue Idle Thread Count

Running out of ExecuteQueue threads is often a precursor to application server hangs (non-responsive). In some severe cases, when the application server runs out of ExecuteQueue threads, all of its operations would stop working.

ExecuteQueue Pending Request Count

A steady increase in the number of ExecuteQueue pending requests is also a precursor to server hangs. This metric is inversely correlated with the ExecuteQueue Idle Thread Count metric.

Total JVM Heap Size

There are two reasons to monitor this metric:

1. If total JVM heap size grows to predefined maximum, a cautionary event should be fired notifying the administrator.

2. If total JVM heap size suddenly drops to 0, this may be an indication of a JVM crash or a non-operational application server.

Free JVM Heap Size

A steady decrease in the free JVM heap size is an indicator of either a memory leak or misconfigured application server. A JVM running out of heap will experience instability and performance degradation as garbage collector and JVM competes for resources to perform cleanup and object creation respectively.

Open Sessions Count

If open session count drops to 0 and remains at 0 for a period of time, some investigation is warranted. Often this pattern indicates a network or load balancing problem.

Application Invocation Count

If application invocation count drops to 0 and remains at 0 for a period of time, some investigation is warranted. While this pattern often indicates a network or load balancing problem, it could also be a symptom of a hanged server.

Understanding these key WebLogic system metrics, setting the SLO thresholds and assigning appropriate responses are critical to establishing a proactive monitoring. In this example, we will configure SLOs and actions with ADP.

The first task is to set a cautionary and a violation SLO for ExecuteQueue Idle Thread Count metric so the appropriate person can be alerted when available ExecuteQueue is running low. To configure SLOs, right-click on the Execute Queues metric and select Configure service level objects. In this example, we will create the following SLOs for ExecuteQueue Idle Threads:

Table 17-3 SLOs for ExecuteQueue Idle Threads

SLO Name

Metric

Threshold Type

Threshold Value

Trigger On

Low ExecuteQueue Idle Threads

Metric.J2EE.Dispatcher.IdleThreads

Cautionary

3

Low

ExecuteQueue Idle Threads Exhaustion

Metric.J2EE.Dispatcher.IdleThreads

Violation

0

Low

When SLO trigger is set to Low, ADP will fire an alert when current measurement reaches the threshold value AND the previous measurement has a higher value than the threshold.

For example, we would create the following actions for the SLOs previously configured:

Table 17-4 Action for SLO

SLO Name

Action Name

Action Type

Low ExecuteQueue Idle Threads

Enter Low ExecuteQueue Idle Threads event into server log

Log

ExecuteQueue Idle Threads Exhaustion

Email ExecuteQueue Idle Threads Exhaustion alert

Email

ExecuteQueue Idle Threads Exhaustion

Send ExecuteQueue Idle Threads Exhaustion SNMP trap to HP Overview

SNMP

ExecuteQueue Idle Threads Exhaustion

Enter ExecuteQueue Idle Threads Exhaustion event into server log

Log

After configuring these SLOs and actions, we now have a proactive monitoring environment to detect ExecuteQueue resource starvation related problems before a catastrophic event occurs. We would use this approach to establish proactive monitoring for other key WebLogic system metrics.

The following is the Oracle recommendation:

Table 17-5 ExecuteQueue Pending Requests

SLO Name

Metric

Threshold Type

Threshold Value

Trigger On

ExecuteQueue Pending Request Warning

Metric.J2EE.Dispatcher.PendingRequests

Cautionary

5 ~ 10Foot 1

High

ExecuteQueue Pending Request Violation

Metric.J2EE.Dispatcher.PendingRequests

Violation

10 ~ 20

High

Footnote 1 Threshold values for these SLOs vary by environment. Figuring out what threshold values to use is an iterative process. Users should gather information about the performance characteristic of their WebLogic environment as the first step. Based on this information, users can set SLOs accordingly. As users continue to improve the performance of their WebLogic environment, they should re-evaluate these threshold values and change them as needed.

When SLO trigger is set to High, ADP will trigger an alert when current measurement hits the threshold value.

Table 17-6 Total JVM Heap Size

SLO Name

Metric

Threshold Type

Threshold Value

Trigger On

JVM Heap Reached Max

Metric.J2EE.JVM.HeapSizeCurrent

Cautionary

512 MBFoot 1

High

JVM Heap Reached 0

Metric.J2EE.JVM.HeapSizeCurrent

Violation

0 MB

Low

Footnote 1 Threshold value for this SLO varies by environment. Users would set this value to the maximum heap size specified in the WebLogic configuration file.

Table 17-7 Free JVM Heap Size

SLO Name

Metric

Threshold Type

Threshold Value

Trigger On

Low JVM Free Heap Warning

Metric.J2EE.JVM.HeapFreeCurrent

Cautionary

72 MB

Low

Low JVM Free Heap Violation

Metric.J2EE.JVM.HeapFreeCurrent

Violation

24 MB

Low

Table 17-8 Open Session Count

SLO Name

Metric

Threshold Type

Threshold Value

Trigger On

No user session in system for 5 minutes

Metric.J2EE.WebApplication. OpenSessionCurrentCount

Cautionary

0Foot 1

Low

Footnote 1 In the example, this SLO would have a measurement window of 5 minutes. By setting the measurement window to 5 minutes, ADP will fire an alert only if this condition persists for at least 5 minutes.

Table 17-9 Application Invocation Count

SLO Name

Metric

Threshold Type

Threshold Value

Trigger On

No application invocation in system for 5 minutes

Metric.J2EE.Servlet.InvocationTotalCount

Cautionary

0

Low

Setting these SLOs and corresponding actions establishes a proactive monitoring environment for your WebLogic deployment. This proactive monitoring approach allows you to identify problems leading up to catastrophic problems before they impact your system's performance and availability.

17.6 Conclusion

The ADP Methodology is a critical aspect of your application performance management strategy. By following this methodology carefully, you will be able to use ADP to improve your ability to proactively monitor the performance and availability of your deployed applications and WebLogic infrastructure. ADP's automation reduces time, effort, and errors associated with manual processes. This allows ADP users to focus on other crucial activities such as the ones listed in the Oracle Methodology.

18 Troubleshooting Application Dependency and Performance

This chapter describes the errors you may encounter while using Application Dependency and Performance, as well as answer frequently asked questions.

This chapter includes the following sections:

- Can I Erase the darchive Directory?

- How Do I Undeploy the Agent?

18.1 Can I Erase the darchive Directory?

In general, you should not erase the darchive directory while the ADP manager is running. If you erase the darchive directory after shutting down the ADP manager, the darchive directory will be re-populated when the ADP manager next restarts.

If the size of the darchive directory is of concern, determine which subdirectories are occupying the most space. If there are large directories that do not contain Java class files (for example ., .., or wlserver10.3), modify the Acsera.properties file to exclude them. Search for Model.StaticAnalysis.ExcludeClassPaths and add the path to the list, separated by comma.

The darchive directory is located under $ACSERA_HOME:

$GCDomain/EMGC_ADPMANAGER1/ADPManager.ear/ADPManager.war

18.2 How Do I Undeploy the Agent?

There is a drop-down menu in the last step in the deployment process that, by default, is set to deploy. Change it to disable to remove the agent startup arguments from the application servers, and to remove to erase the agent files from the application servers.

To undeploy the agent, follow these steps:

1. From the Targets menu, select Middleware, then select Middleware Features (drop-down list). Select Application Dependency and Performance .

2. Click the Configuration tab.

A ADP Configuration Directories and Files

This appendix lists and defines the files and directories available in ADP. Topics include:

- Configuration Directories

- Acsera.properties File

- UrlMap.properties

A.1 Configuration Directories

After ADP is installed, all the components of the application package are located in the EMGC_ADPMANAGER1 directory. This directory is in the GC domain home, for example:

/net/abcdef1234/scratch/jdoe/view_storage/jdoe_aug21/work/user_projects/domains/EMGC_DOMAIN/EMGC_ADPMANAGER1

A.1.1 Directory Structure

The path where the ADP Manager is installed is similar to:

/scratch/Middleware0712/gc_inst/user_projects/domains/GCDomain/EMGC_ADPMANAGER1

where domain.home=/scratch/Middleware0712/gc_inst/user_projects/domains/GCDomain
and ORACLE_HOME=/scratch/Middleware0712/oms

The directory structure is as follows:

ADPManager.ear/
ADPManager.ear/APP-INF/
ADPManager.ear/APP-INF/lib/
ADPManager.ear/META-INF/
ADPManager.ear/ADPManager.war/
ADPManager.ear/ADPManager.war/bin/
ADPManager.ear/ADPManager.war/config/
ADPManager.ear/ADPManager.war/mcconfig/
ADPManager.ear/ADPManager.war/deploy/
ADPManager.ear/ADPManager.war/lib/
ADPManager.ear/ADPManager.war/lib/bea/
ADPManager.ear/ADPManager.war/lib/oracle/
ADPManager.ear/ADPManager.war/META-INF/
ADPManager.ear/ADPManager.war/WEB-INF/

Table A-1 ADP Manager Directories

Directory

Description

bin

Contains all the executable files to start and stop ADP, run deployer for Agent and ADP EJB, run export utility.

config

Contains all the ADP runtime configuration parameters that control execution logic, ADP schemas enablement, ADP GUI functionality, Service Level Objectives definition, export logic and many more.

deploy

Contains agent libraries and configuration files, as well as ADP EJB and ADP Admin Web Application. These components are deployed on the remote host (Web or Application servers) using deployer utility found in bin directory of ADP package.

lib

Has all the libraries required for ADP's proper functionality

mcconfig

Contains internal base instrumentation configuration. Do not modify these files.

A.1.2 Config Directory

Config directory has many files that potentially can be configured and make ADP to run in a particular way. Any changes applied to files in this directory require restarting ADP server.

Most of the files never get touched directly by user. The following are the main three files which can be configured manually to achieve desired effect:

File

Description

Acsera.properties

This file is the main ADP configuration file customization of which helps to tune up ADP.

configuration.xml

In this file you define location of Administration Server and credentials to access it. Usually you do not touch this file. The entire configuration is done through ADP GUI.

dbconfig.xml

This file contains database configuration information for the ADP metric repository.

export.xml

This file contains information that drives proper data export logic. It is used for manual and automatic export of performance metric and events data from the ADP Data Repository.

UrlMap.properties

This file is used to map server addresses to load balancer addresses. By default, this file is not available; it must be created by the user.

It is worth mentioning that Service Level Objective definitions and Actions associated with the SLOs are described in slo.xml and event.xml respectively. The content of these files is completely controlled by definitions applied from ADP GUI (configuration tab).

A.1.3 Deploy Directory

The /deploy directory contains the ADP Java Agent distributable, including configuration files as well as corresponding libraries. These files are copied to the target systems hosting the Managed Servers when running the deployer utility. Rarely one needs to modify configuration files in this directory. Remember though if you modify the files they will be distributed to ALL targets within single server/cluster.

A.2 Acsera.properties File

The acsera.properties file contains global configuration parameters that define the operation of the ADP Manager.

A.2.1 Log Files Management

This section of Acsera.properties file defines log rotation policies. Log.MaxFiles indicates max number of log files available at any given moment, whereas the Log.MaxFileSizeMB indicates maximum size of the log file.

Example A-1 Log Files Management Section

Log.CopyOut = false
Log.MaxFiles = 10
Log.MaxFileSizeMB = 30
Log.MergeLogs = true

Debug.CopyOut = false
Debug.LogLevel = all
Debug.MaxFiles = 10
Debug.MaxFileSizeMB = 30

Log files are stored in the log directory.

A.2.2 Multi-Domain Monitoring Configuration

One can limit number of domains to be monitored by setting resource limit parameter: ConfigurationManager.ResourceLimit=4

Example A-2 Multi-Domain Monitoring Configuration

ConfigurationManager.ResourceLimit=4

A.2.3 ADP RMI Port Assignment

ADP uses RMI ports for communication with the agents and collects incoming performance metrics from a particular RMI port. By default, the RMI port is set on the same machine that hosts ADP. RMI.Registry.Host needs to be un-commented and have a value other than localhost if the host is multi-homed (such as, many network interfaces or has any ipv6 addresses) and you need to make sure that ADP listens to the incoming traffic on the particular interface.

You may need to change RMI.Registry.Port value in case the default 51099 port number has been allocated to an other application. Also if ADP is running in multi-instance mode, the port number will be different from instance to instance.

Example A-3 ADP RMI Port Assignment

#RMI.Registry.Host = localhost
RMI.Registry.Port = 51099

A.2.4 ADP Aggregation and Data Life Time Configuration

ADP has sophisticated multi-tiered logic for aggregation (or compression) of performance data. This helps to optimize performance of interaction with the internal data repository both when querying data for presentation or inserting new performance metrics.

Users who want to store longer term data should look for this section in Acsera.properties:

#########################
# Production setting
# NOTE: use Model.GlobalSamplingRateSecs to configure Metric.Grain.0
#########################
Metric.Grain.0 0s
Metric.TableInterval.0 = 4h
Metric.DataLife.0 = 2d

Metric.Grain.1 = 3m
Metric.TableInterval.1 =1d
Metric.DataLife.1 = 8d

#Metric.Grain.2 = 30m
#Metric.TableInterval.2 = 7d
#Metric.DataLife.2 = 420d

and uncomment the last 3 lines for the Metric.*.2 properties

A.2.5 Aggregating Incoming Metrics On the Fly

ADP by default aggregates data coming from multiple cluster members by application thus minimizing rate of insertion in to the data repository. This greatly improves performance of ADP in heavily loaded environments.

As a side effect of this approach though, the user is unable to see metrics from instrumentation (processes and portals) on per server level. If you need to enable this then set the JavaMIP.AggregateInserts to false.

A.2.6 Listing Applications to Be Monitored or Excluded From Monitoring

To avoid overhead of unnecessary monitoring of certain applications, you can explicitly state which applications to monitor, or which applications to exclude from monitoring.

Users should append the name of their application to the property ComponentProvider.Application.Exclude.

Example A-4 Specifying Which Applications to Monitor

# Control which applications to analyze
#
ComponentProvider.Application.Exclude=WLI System EJBs,WLI-AI
Design-time,B2BDefaultWebAppApplication,WLI
Worklist,JWSQueueTransport,Deployer,BEA_WLS_DBMS_ADK,
Acsera,ClearApp,HttpDeployer,ServiceBus_Console,em

A.2.7 Firewall Mitigation (for Internal RMI Ports)

If there is a firewall between the ADP Manager and the monitored application servers, ports need to be opened between them especially in the case where multiple resources are configured. For example, if two resources are configured and the first one uses 55006 as the port, then the next resource must use 55007 as the port. Each additional resource increments the port by 1.

In addition to the application server's JMX access ports, the following two properties in Acsera.properties indicate the ports used specifically by ADP:

- RMI.Registry.Port (51099 by default)

- RMI.JavaProvider.ServerPort (55003 by default)

A.2.8 SLO Dampening

There are times when you deliberately want to cut down on the number of repeated notifications should SLO violation persist for a given period of time. To suppress notifications of the same violation in a short period of time, ADP provides the SLO Dampening feature. Once enabled, should a SLO violation occur and be repeated several times in a short period, ADP will not fire the SLO violation notification for the time period defined in SLO.RearmDelay. To disable this feature, set the value of this parameter to 0.

SLO.SuppressDelayedAsserts indicates that if the violation still persists upon time period expiry ADP, should fire the SLO notification. By default it is false, for example, fire the notification.

Example A-5 SLO Dampening

# The following property is specified in units of
# minutes (m), hours (h) or days (d)
SLO.RearmDelay = 15m
SLO.SuppressDelayedAsserts = false

A.3 UrlMap.properties

The UrlMap.properties file should be created in the ADP Manager's config directory and used to provide address mappings between load balancers and application servers. The format of this file is:

# Format:
#    $app_server_ip = $load_balancer_id
# E.g:
#    http\://localhost\:7001 = http\://localhost\:7005
#
# Note: ":" character need to be escaped with "\"
#
http\://192.168.128.53\:7002 = http\://192.168.3.187\:80
http\://192.168.128.53\:7003 = http\://192.168.3.187\:80
http\://192.168.128.54\:7005 = http\://192.168.128.54\:7011
http\://192.168.128.54\:7006 = http\://192.168.128.54\:7011

B Support Matrix for Application Dependency and Performance

This appendix provides the support matrix information for Oracle Enterprise Manager Cloud Control for Application Dependency and Performance (ADP) release 12.1.0.

Refer to Oracle Enterprise Manager Cloud Control Basic Installation Guide for a complete list of supported platforms.

B.1 ADP Manager Platform Support

This section lists the platforms supported by ADP.

Table B-1 Operation System Information

Operating System

Version

Chip Architecture

Windows Server 2003

Data Center Edition

Enterprise Edition

IA32

Windows XP

Professional SP1+

Windows 2000

Professional SP2+

Server SP2+

Advanced Server SP2+

Datacenter Server SP2+

Oracle and Red Hat Enterprise Linux

2.x

3.x

4.x

5.x

IA32

IA32

IA32

IA32/IA64

Sun Solaris

8

9

10

SPARC 64

IBM AIX

5.2+

PowerPC_Power 5 64-bit

HP UX

11i

IA64/PA-RISC

Note: For IA64 use JDK 1.5.x.

Table B-2 Repository Information

Repository Database

Version

Oracle Database

10g, 11g

Table B-3 Managed Server Platforms

Managed Server Platforms

Version

Oracle WebLogic Server

8.1 SP3

8.1 SP4

8.1 SP5

8.1 SP6

9.1.x

9.2.x

10.0.x

10.1.x

10.2.x

10.3.x

11g, 11g PS1 (10.3.3, 10.3.4, 10.3.5)

Oracle WebLogic Integration

8.1 SP2

8.1 SP3

8.1 SP4

Oracle WebLogic Portal

8.1 SP2

8.1 SP3

8.1 SP4

8.1 SP5

8.1 SP6

9.2.x

10.0.x

10.1.x

10.2.x

10.3.x

Oracle WebCenter Suite

11gR1, 11gR1 PS1 - PS4

Oracle Application Server

10.1.3.x

Oracle SOA Suite

10.1.3.x

11gR1, 11gR1 PS1 - PS4

Oracle Service Bus

(formerly Aqualogic Service Bus)

2.6

2.6.1

3

10gR3, 11gR1 PS1 - PS4

Oracle Application Integration Architecture (AIA)

2.2.1

2.3

IBM WebSphere Portal

5.1

6

IBM WebSphere AppServer

5.0.2 (JMX Only)

5.1

6.0.2

6.1

Index

A  B  C  D  E  F  G  H  I  J  L  M  N  O  P  R  S  T  U  V  W  Z

A

accessing architecture view, 15.1.15.1

acsera.properties file, A.2

action configuration, 15.3.4

activity

entity EJB, 15.2.13.1.6

ADF task flows

Oracle WebCenter, 15.2.7.1

ADP

architecture, 14.2

database, 14.2.3

how to use, 17

Java agents, 14.2.1

manager, 14.2.2

node, 15.2.19

starting, 15.1.1

user interface, 14.2.4

aggregated count

metric type, 15.1.16

aggregating

incoming metrics, A.2.5

performance data, A.2.4

aggregation data

export to file, 16.1.3

Application Replay

analyzing replay results, 4.9.7

creating captures, 4.7

introduction, 4

monitoring capture process, 4.8

prerequisites, 4.5

replaying captures, 4.9

restarting database, 4.5.5

synchronized vs non-synchronized replay, 4.4

testing against real workloads, 4.2

troubleshooting, 4.10

Application Schema model

functional view, 15.1.13

Application Server

extensible monitoring, 3.2.7

managing configurations, 3.5.1

applications, 15.2.14

Web, 15.2.14.5

architecture

ADP, 14.2

architecture view, 15.1.15

accessing, 15.1.15.1

summary, 15.1.15.1.2

types of, 15.1.15

arguments

export.xml file, 16.2.3, 16.2.3, 16.2.3, 16.2.3

async dispatchers, 15.2.13.1.2 attributes

export.xml file, 16.2.3, 16.2.3

automatic domain member discovery, 2.3 automatic target discovery, 2.1

changes in domain, 2.3.1

average timing

metric type, 15.1.16

B

baseline performance, 17.1.3.1, 17.3

beans

entity, 15.2.14.8

message driven, 15.2.14.9

stateful, 15.2.14.7

stateless, 15.2.14.6

blackouts

configuring for Service Level Objectives, 15.3.3.4

creating for Service Level Objectives, 15.3.3.4

deleting Service Level Objectives, 15.3.3.4

Service Level Objectives summary list, 15.3.3.4

books

Oracle WebLogic portal, 15.2.3.4

bottlenecks

identifying performance, 17.1.3.2, 17.4

removing performance, 17.1.3.3

BPEL Process Manager

Configuring, 6.6

Discovery, 6.2, 6.3, 6.5

Software Library, 6.4

Supported Versions, 6.1

Troubleshooting, 6.7

business SLAs guidelines, 17.2 byte statistics, JMS destinations, 15.2.13.1.4

C

cache

entity EJB, 15.2.13.1.6

stateful EJB, 15.2.14.7.1

channels node, 15.2.13.3 class node

in processes, 15.2.8.3

Coherence

Discovery, 12.3

Configure Management Node (WLS), 12.3.1, 12.3.2

Configure Node (JVMD Agent), 12.3.4

Configure Standalone Management Node, 12.3.1

Corrective Actions, 12.3.6

Refresh Cluster, 12.3.7

Enable Management Pack, 12.4 JVM Diagnostics Integration, 13.9 Monitor

Administration, 13.3.2, 13.3.2.1, 13.5

Cluster, 13.1.1, 13.1.2, 13.1.3, 13.1.4, 13.1.5

Configuration Topology, 13.11

Detail, 13.2.1, 13.2.2, 13.2.3

Performance, 13.3, 13.3.1

Performance Summary, 13.10

Push Replication Pattern, 13.7

Reap Session, 13.6

Transactional Cache, 13.8

New Features, 12.1 Supported Versions, 12.2 Troubleshooting, 13.12 comparative view

performance analysis, 15.1.8

component level

architecture view, 15.1.15

component level execution

architecture view, 15.1.15

config directory, A.1.2 configuration

action, 15.3.4

data life time, A.2.4

directories and files, A

export, 16.2

multi-domain monitoring, A.2.2

periodic export, 16.2.1

configurations

managing, 3.5.1

configuring

list of applications excluded from monitoring, A.2.6

list of applications to be monitored, A.2.6

containers

persistent, 15.2.13.1.6

persistent in processes, 15.2.8.2

stateless, 15.2.13.1.5

creating

Service Level Objectives, 15.3.3.1

Service Level Objectives blackouts, 15.3.3.4

custom metrics, 15.2.18

monitoring environment, 15.1.12

D

dashboards

health indicators, 15.1.3

data

example of exported for WebLogic, 16.3

export modes, 16.1

performance graphs and data items, 15.1.6

data displayed

display interval, 15.1.5

time frame, 15.1.4

data items

performance data, 15.1.6

data life time configuration, A.2.4 database

ADP, 14.2.3

export data to, 16.1.2

date, exporting, 16 delay analysis

view

in processes, 15.2.8.1.1

Oracle BPEL processes, 15.2.5.1

dependency

node, 15.2.14.2

types, 15.2.14.2, 15.2.14.2

deploy directory, A.1.3 deployments nodes, 15.2.14.3 desktops

displaying portal, 15.2.12.3

Oracle WebLogic portal, 15.2.3.1

destinations

JMS, 15.2.13.1.4

directory

config, A.1.2

configuration, A.1

deploy, A.1.3

structure, A.1.1

dispatchers

async, 15.2.13.1.2

sync, 15.2.13.1.3

display interval

context, 15.1.5.2

data displayed, 15.1.5

time frame, 15.1.5.1

do-it-yourself manual processes, avoiding, 14.1.4

E

easy scroller, 15.1.10

EJB

activity, 15.2.13.1.6

activity table in processes, 15.2.8.2.1

cache table in processes, 15.2.8.2.2

entity cache, 15.2.13.1.6, 15.2.14.8.2

entity locking, 15.2.13.1.6, 15.2.14.8.4

entity transactions, 15.2.13.1.6, 15.2.14.8.3

entity transactions table in processes, 15.2.8.2.3

locking table in processes, 15.2.8.2.4

message driven activity, 15.2.14.9.1

message driven transactions, 15.2.14.9.2

services, 15.2.11.2

stateful cache, 15.2.14.7.1

stateful locking, 15.2.14.7.3

stateful transactions, 15.2.14.7.2

entity

beans, 15.2.14.8

EJB activity, 15.2.13.1.6

EJB activity table in processes, 15.2.8.2.1

EJB cache, 15.2.13.1.6, 15.2.14.8.2

EJB cache table in processes, 15.2.8.2.2

EJB locking, 15.2.13.1.6, 15.2.14.8.4

EJB locking table in processes, 15.2.8.2.4

EJB transactions, 15.2.13.1.6, 15.2.14.8.3

EJB transactions table in processes, 15.2.8.2.3

environments

service-oriented views, 14.1.2

events

node performance, 15.2.13.2

view in processes, 15.2.8.1.2

execute queues

health, 15.2.13.1.1

execute thread

thread count, 15.2.13.1.1

export

configuration, 16.2

manual execution of metric, 16.2.2

export modes

data, 16.1

exporting data, 16 export.xml file, 16.2.3 extensible monitoring, 3.2.7

F

file

export data to, 16.1.1

firewall mitigation, A.2.7 functional view of Application Schema model, 15.1.13

G

graphs

performance data, 15.1.6

right-click operations, 15.1.7

guidelines

business SLAs, 17.2

H

health

integration, 15.2.13.1

health indicators

dashboard, 15.1.3

how to use ADP, 17 HTTP services, 15.2.11.1

I

improving performance, 17.1.3

instrumentation in processes, 15.2.8.3

integration, 15.2.13

interval context

display interval, 15.1.5.2

J

Java agents

ADP, 14.2.1

Java EE application

managing, 14.1.1

Java EE application responsiveness, monitoring, 3.2.2 JDBCs services, 15.2.11.3 JMS destinations, 15.2.13.1.4 JSF pages

Oracle WebCenter, 15.2.7.2

JVM Diagnostics

Features

Cross-Tier Correlation, 9.1.4

In-depth Visibility, 9.1.2

JVM Pooling, 9.1.6

Low Overhead, 9.1.1

Memory Leak Detection, 9.1.5

New Features, 9.2

Real Time and Historical Diagnostics, 9.1.7

Real Time Transaction Tracing, 9.1.3

Supported Platforms and JVMs, 9.3

User Roles, 9.4

Heap Snapshots, 10.7

Available Heap Snapshots, 10.7.1

Compare, 10.7.1.4

Create, 10.7.2

Heap Object Information, 10.7.1.3

Heap Usage by Roots, 10.7.1.1

Top 40 Objects, 10.7.1.2

Upload Trace Diagnostics Images, 10.9

Installing, 10.1 Manage JVMs

Offline Diagnostics, 10.12, 10.12.1, 10.12.3

Managing JVM Pools, 10.2

JVM Pool Home Page, 10.4.1

Live Thread Analysis, 10.4.3

Performance Diagnostics, 10.4.2

Managing JVMs, 10.5

JVM Home Page, 10.5.1

Live Heap Analysis, 10.5.5

Live Time Thread Analysis, 10.5.4

Performance Diagnostics, 10.5.2

Performance Summary, 10.5.3

Overview, 9.1 Setting Up, 10.2 Thread Snapshots, 10.6

Analyze Trace Diagnostic Images, 10.11

Trace Active Threads, 10.8

Upload, 10.6.1

Threshold Violations, 10.13 Troubleshooting

Cross Tier Functionality Errors, 11.1

Deployment Script Execution Errors, 11.3

FAQ, 11.6

LoadHeap Errors, 11.4

Trace Errors, 11.2

User Interface Errors, 11.5

L

locking

entity EJB, 15.2.13.1.6

stateful EJB, 15.2.14.7.3

log files management

acsera.properties file, A.2.1

M

managing

configurations, 3.5.1

manual domain member discovery, 2.3.2 mapping

SLAs to SLOs, 17.1.1, 17.2

maximum response time measurement

metric type, 15.1.16

message driven

beans, 15.2.14.9

EJB activity, 15.2.14.9.1

EJB transactions, 15.2.14.9.2

message statistics

JMS destinations, 15.2.13.1.4

metadata view

Oracle BPEL processes, 15.2.5.2

method node

in processes, 15.2.8.3

methodology, ADP, 17 metric export

manual execution, 16.2.2

metrics

aggregating incoming, A.2.5

custom, 15.2.18

customizing for monitoring, 15.1.12

setting Service Level Objectives on, 17.1.3.4

setting SLOs on, 17.5

types, 15.1.16

WebLogic, 17.5

Middleware

management, 1, 3

minimum response time measurement

metric type, 15.1.16

modeled entities view

Oracle BPEL processes, 15.2.5.6

modes

data export, 16.1

module level

architecture view, 15.1.15

module level execution

architecture view, 15.1.15

Monitor

Job System, 3.7

Lifecycle Management, 3.5

Compliance Management, 3.5.2

Manage Configurations, 3.5.1

Patch Management, 3.5.3

Provisioning, 3.5.4

Manage Service Levels, 3.6 Support Workbench, 3.9 Topology Viewer, 3.8 Monitoring

Administer, 3.4

Process Control, 3.4.1

Middleware Targets, 3.1 Non-Oracle Middleware Components, 3.1.3 Oracle Application Server Components, 3.1.2 Out-of-Box Monitoring, 3.2

Blackouts, 3.2.6

Extending, 3.2.7

Historical Performance, 3.2.3

Metric Thresholds, 3.2.4

Monitoring Templates, 3.2.5

Out-of-box Metrics, 3.2.2

Request Monitoring, 3.2.8

Performance Problems, 3.3

Diagnostics Snapshots, 3.3.3

Home Page, 3.3.1

Middleware Diagnostics Advisor, 3.3.2

monitoring

configuring custom metrics, 15.1.12

extensible, Application Server, 3.2.7

multi-domain configuration, A.2.2

N

navigation

easy scroller, 15.1.10

node

hierarchy in processes, 15.2.8.1

method in processes, 15.2.8.3

nodes

ADP, 15.2.19

class in processes, 15.2.8.3

dependencies, 15.2.14.2

deployments, 15.2.14.3

hierarchy in Oracle BPEL processes, 15.2.5.8

pageflows, 15.2.10

services, 15.2.14.1

O

operation routing rules view

Oracle ESB, 15.2.6.5

Oracle

Application Server

Web Cache, 3.2.2

Oracle BPEL Processes, 15.2.5 Oracle ESB, 15.2.6 Oracle Fusion Middleware Components, 3.1.1

Oracle Business Intelligence, 3.1.1

Oracle Coherence, 3.1.1

Oracle Forms Services, 3.1.1

Oracle Identity Management, 3.1.1

Oracle Portal, 3.1.1

Oracle SOA Suite, 3.1.1

Oracle Web Tier, 3.1.1

Oracle WebCenter, 3.1.1

Oracle WebLogic Server Domains, Clusters, and Managed Servers, 3.1.1

Oracle HTTP Server session volumes, 3.2.2 Oracle resources, 15.2.17 Oracle Service Bus

Discovery, 7.2, 7.3, 7.5

Enabling Management Packs, 7.6

Supported Versions, 7.1

Troubleshooting, 7.7

Oracle WebCenter, 15.2.7 Oracle WebLogic

portals, 15.2.3

resources, 15.2.15

P

pageflow viewer

Oracle WebLogic portal, 15.2.3.3

pageflows node, 15.2.10 pages

JSF in Oracle WebCenter, 15.2.7.2

Oracle WebLogic portal, 15.2.3.5

WebSphere portals, 15.2.4.2

parameters

defining Service Level Objectives, 15.3.3.2

partner link bindings view

Oracle BPEL processes, 15.2.5.5

partner link type role view

Oracle BPEL processes, 15.2.5.4

partner links view

Oracle BPEL processes, 15.2.5.3

PDF

saving view as, 15.1.9

performance

baseline, 17.1.3.1, 17.3

characteristics of target, 17.1.2

comparative view analysis, 15.1.8

graphs and data items, 15.1.6

identifying bottlenecks, 17.1.3.2, 17.4

improvement process, 17.1.3

node, 15.2.13.2

removing bottlenecks, 17.1.3.3

system level, 17.4.1

periodic export configuration, 16.2.1 persistent containers, 15.2.13.1.6

in processes, 15.2.8.2

platform

intelligent, 14.1.3

port assignment

RMI, A.2.3

portal desktop

displaying, 15.2.12.3

portal hierarchy

Oracle WebLogic portal, 15.2.3

WebSphere portals, 15.2.4

portals

Oracle WebLogic, 15.2.3

WebSphere virtual, 15.2.4.1

portlet drill down

Oracle WebLogic portal, 15.2.3.2

portlet performance

Web Services Remote Portlet producers, 15.2.12.1

portlets

Oracle WebCenter, 15.2.7.3

Oracle WebLogic portal, 15.2.3.6

Web Services Remote Portlet producer, 15.2.12.1

WebSphere portals, 15.2.4.3

process nodes

performance, 15.2.13.2

processes, 15.2.8

deployed WebLogic, 15.2.8

node hierarchy, 15.2.8.1

properties file

acsera.properties, A.2

UrlMap.properties, A.3

R

refresh WebLogic Domain targets, 2.3.2

resources

Oracle, 15.2.17

Oracle WebLogic, 15.2.15

WebSphere, 15.2.16

right-click operations

tables and graphs, 15.1.7

RMI port assignment, A.2.3 RMI ports

firewall mitigation, A.2.7

S

saving

view as PDF, 15.1.9

SCA See Service Component Architecture scroller

easy navigation, 15.1.10

Service Component Architecture, 15.2.20 service definition view

Oracle ESB, 15.2.6.3

service details view

Oracle ESB, 15.2.6.1

Service Level Objectives

blackouts summary list, 15.3.3.4

configuring blackouts, 15.3.3.4

creating, 15.3.3.1

creating blackouts, 15.3.3.4

defining parameters for, 15.3.3.2

deleting blackouts, 15.3.3.4

setting on key metrics, 17.1.3.4

variables, 15.3.4

service mode

ADP topology, 14.2

service operations view

Oracle ESB, 15.2.6.4

service parent details view

Oracle ESB, 15.2.6.2

service-oriented views, 14.1.2 services, 15.2.11 services node

applications, 15.2.14.1

setting

Service Level Objectives on key metrics, 17.1.3.4

SLOs on key metrics, 17.5

SLO dampening, A.2.8 snapshot count

metric type, 15.1.16

SOA application

monitoring, 14.1.1

SOA Management Pack Enterprise Edition, 5

BPEL Process Manager, 5

Central Management Console, 5

Service Bus, 5

SOA Composite, 5

SOA Infrastructure, 5

SOA Suite

Creating Reports, 8.7

Dehydration Store, 8.8

Discovery, 8.3, 8.4

New Features, 8.1

Post Discovery, 8.5

Service Topology, 8.9

SOA Artifacts and Composites, 8.11

SOA Instance Tracing, 8.6

Supported Versions, 8.2

Troubleshooting, 8.12

UDDI Publishing, 8.10

starting ADP, 15.1.1 stateful

beans, 15.2.14.7

EJB cache, 15.2.14.7.1

EJB locking, 15.2.14.7.3

EJB transactions, 15.2.14.7.2

stateless

beans, 15.2.14.6

containers, 15.2.13.1.5

steps in using ADP, 17 subscribers node, 15.2.13.4 sync dispatchers, 15.2.13.1.3 system level performance, 17.4.1

T

tab descriptions

Oracle WebLogic portal level, 15.2.3

WebSphere portal level, 15.2.4

tables

right-click operations, 15.1.7

target

performance characteristics, 17.1.2

target discovery

automatic, 2.1

using EMCLI, 2.2.2

WebLogic 10.x, 2.2.1

WebLogic 9.x, 2.2.1

task flows

ADF in Oracle WebCenter, 15.2.7.1

user-defined in Oracle WebCenter, 15.2.7.1.1

terminology, Preface time frame

data displayed, 15.1.4

display interval, 15.1.5.1

specifying, 15.1.5.3

topology

service mode, 14.2

Web Services Remote Portlet, 15.2.12.2

topology view, 15.1.14

Oracle BPEL processes, 15.2.5.7

transactions

entity EJB, 15.2.13.1.6

stateful EJB, 15.2.14.7.2

tree summary

Oracle WebLogic portal, 15.2.3

WebSphere portals, 15.2.4

types

dependency, 15.2.14.2, 15.2.14.2

metric, 15.1.16

U

UrlMap.properties file, A.3

user

interface in ADP, 14.2.4

user-defined task flows

Oracle WebCenter, 15.2.7.1.1

V

view

architecture, 15.1.15

comparative, 15.1.8

delay analysis in Oracle BPEL processes, 15.2.5.1

delay analysis in processes, 15.2.8.1.1

events in processes, 15.2.8.1.2

functional of Application Schema model, 15.1.13

metadata in Oracle BPEL processes, 15.2.5.2

operation routing rules in Oracle ESB, 15.2.6.5

partner link bindings in Oracle BPEL processes, 15.2.5.5

partner link type role in Oracle BPEL processes, 15.2.5.4

partner links in Oracle BPEL processes, 15.2.5.3

saving as PDF, 15.1.9

service definition view in Oracle ESB, 15.2.6.3

service details in Oracle ESB, 15.2.6.1

service operations in Oracle ESB, 15.2.6.4

service parent details in Oracle ESB, 15.2.6.2

topology, 15.1.14

topology of Oracle BPEL processes, 15.2.5.7

view modeled entities in Oracle BPEL processes, 15.2.5.6 viewers

pageflow for Oracle WebLogic portal, 15.2.3.3

views

zooming in and out, 15.1.11

W

Web 2.0 service

Oracle WebCenter, 15.2.7.1.2

Web applications, 15.2.14.5 Web Services, 15.2.9 WebLogic

example of exported data, 16.3

key metrics, 17.5

WebLogic Domain Refresh job, 2.3 WebSphere

portals, 15.2.4

resources, 15.2.16

workshop projects, 15.2.14.4 WSRP producers, 15.2.12

Z

zooming in and out for views, 15.1.11

Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved.