Oracle Cloud Infrastructure Documentation

Key Concepts

Review key concepts of Oracle Pulse.

The analytics reports and historical data in Oracle Pulse are based on business metrics and key performance indicators (KPIs) from different areas of service delivery, as follows:

  • Business metrics are measurements that allow you to analyze business performance. Typically they are numeric values, as simple as the sum of values in a fact column or a complex calculation involving mathematical operators.

  • Key performance indicators (KPIs) are specific measurements to define and track objectives. KPIs have measurable values that usually vary with time, and can be compared over time for trending and performance patterns. KPI evaluation is determined by comparing the actual value against a defined threshold.

Oracle Pulse covers six important areas of service delivery: availability, storage, incidents, changes, and (where enabled) Business Transaction Monitoring and Business Insight. Oracle Pulse also covers host and database metrics. This chapter explains the conceptual basis for Oracle Pulse business metrics and key performance indicators in each area, as explained in the following sections:

Availability Metrics

Oracle Pulse presents the latest representation of availability for your organization's services at the time of calculation. This section defines how Oracle calculates these metrics, and highlights any assumptions underlying the values presented in Oracle Pulse.

Availability is a defining principle of ITIL service delivery, and Oracle services follow ITIL principles for calculating availability. Following these principles, availability is the percentage of time when a production service is operating as expected. In practice, this means that end users can log in and perform all business transactions.

Availability calculations take into account only unplanned complete outages for your production environments, for which Oracle is responsible. Such outages mean that end users experience total loss of service - they cannot log in or perform any business transactions. Users logged in when the outage starts cannot complete current actions. If the customer organization is responsible for restoring service - for example, carrying out necessary repairs - the outage is not included in availability calculations.

These calculations also exclude planned maintenance outages for your production environments, where the outage occurs at an agreed date and time due to regular maintenance or a customer change request.

If isolated business transactions cannot be completed in your production environments, but other service transactions can be performed, this is considered a service interruption and does not affect availability calculations.

The Pulse Dashboard summarizes information about the uptime and the count of unplanned outages that occurred in your production environments, as well as information about the total duration of unplanned complete outages, service interruptions and planned production maintenance outages for the current month or for the month indicated. For more information, see the Analyzing Systems' Availability section in Checking the Performance of Your Services.

The Availability dashboard at Customer and Service Level summarizes information about the availability of your organization's production environments for the specified time interval, allowing you to:

Storage Metrics

Oracle Pulse provides storage metrics for all your organization's services. Storage usage metrics can be useful in detecting unusual storage consumption, pinpointing the source of each anomaly, and understanding when your storage usage is approaching current entitlement. For example, this can be useful in identifying services that consume a disproportionate amount of storage.

Your storage entitlement is the amount of storage included within the services contract for the service or set of services that your organization has purchased. This includes a base entitlement, and any additional storage purchased either initially or through additions to the contract. Your organization's entitlement is tracked manually by your Oracle customer management team.

Using Oracle Pulse, you can monitor both your organization's storage entitlement and the amount of storage your organization consumes. Storage resources can be located @customer or @partner, termed customer-owned storage. Customer-owned storage includes all storage located in your organization's data centers and those belonging to partner organizations. It also includes any Oracle Exadata and Exalogic servers that your organization owns in Oracle data centers. Oracle-owned storage covers all storage used in Oracle services Data Centers, excluding any servers that your organization owns.

Consumed storage includes the amount of commercial storage allocated for your organization's services on Oracle-owned storage. Commercial storage usually includes all storage used by applications such as Oracle® E-Business Suite and the tools needed to run those applications. Tools could include Oracle Database storage or Database and application software. Commercial storage excludes mirrored file systems, backups, and other items that are considered non-commercial storage.

Consumed storage is deducted from your running storage entitlement. The consumed storage value also includes non-commercial storage consumption and usage of your organization's own storage resources. This makes consumed storage an important tool for managing your storage and forecasting future use.

The Pulse Dashboard summarizes storage usage against entitlement, and shows any changes in recent storage activity. Significant changes in either measure warrant immediate investigation. For more information, see the Analyzing Storage section in Checking the Performance of Your Services.

The Storage dashboard at Customer and Service Level covers storage usage across all your organization's services and associated environments, allowing you to:

Incident Metrics

Oracle Pulse tracks all production and nonproduction service requests - termed incidents - associated with your organization's services, using information drawn from My Oracle Support.

On the Pulse Dashboard, you can see a summary of open Severity 1 service requests and any service requests awaiting your review, as well as a comparison between the number of created service requests and the number of closed service requests for your production environments for a period of 3 complete months. A high number of Severity 1 service requests created on your production environments can merit further analysis. For more information, see the Analyzing Incidents section in Checking the Performance of Your Services.

Service request metrics for your production and nonproduction environments are listed on the Incidents menu at Customer and Service Level, allowing you to:

Note

To see service request information in Oracle Pulse, you must have the required service request privileges in My Oracle Support. For more information, see the Requirements section in Overview of Oracle Pulse.

Change Metrics

Change requests are tracked in Oracle Pulse using information drawn from My Oracle Support. Available at Customer and Service Level, as well as for individual environments, these metrics show the types of changes that have been requested, rejected, scheduled, or completed or are being worked on for all your organization's services down to the level of changes scheduled for individual environments and hosts.

The Pulse Dashboard summarizes all change requests that have been scheduled between the current day and the next 30 days and all change requests requiring customer intervention. For more information, see the Analyzing Changes section in Checking the Performance of Your Services.

Change metrics are also listed on the Changes menu at the Customer and Service Level, allowing you to:

Note

To see change request information in Oracle Pulse, you must have the required RFC privileges in My Oracle Support. For more information, see the Requirements section in Using the Change Management Reports.

Self Healing Metrics

Oracle Pulse provides self healing metrics, represented by corrective actions performed on your organization's services. This section defines how Oracle calculates these metrics, and highlights any assumptions underlying the values presented in Oracle Pulse.

Self healing calculations take into account only the completed corrective actions performed on your environments. The Pulse Dashboard summarizes information about the count of corrective actions run on your production and non-production environments, information about their execution time, types and trends, as well as details for each corrective action. For more information, see Analyzing Production vs Non Production Corrective Actions, Analyzing Corrective Actions By Trend, Analyzing Corrective Actions by Type, and Viewing Corrective Actions Details sections in Using the Self Healing Reports.

The Self Healing dashboard enables you to:

Business Transaction Monitoring Metrics

BTM helps you understand and manage the performance of your transaction processing system. Transaction response times give a sense of the performance of your services and environments, and can indicate potential or actual issues. BTM can help you profile use, identify issues related to performance, and investigate the cause of failing components in a business process.

Transactions are typically business functions, such as running the monthly payroll for a company. Each transaction is a sequence of operations that you want to monitor as a single unit. Where the user completes some or all of these operations, the transaction is a user interaction. Where all operations are completed without user input, the transaction is a batch job. Oracle Pulse provides users with separate reports for Oracle® E-Business Suite and PeopleSoft batch jobs, while continuing to support user interactions. Moreover, Oracle Pulse analyzes and monitors the status and health of the targets the Oracle Service-Oriented Architecture (SOA) suite runs on.

Note

The Transactions dashboard is displayed in the navigation menu only for services where BTM has been enabled.

If BTM has not been enabled, the Transactions dashboard is hidden at the Customer and Service levels.

BTM metrics are sourced from Oracle® Enterprise Manager, which, in turn, interrogates the supported Oracle applications. BTM supports Oracle® E-Business Suite and PeopleSoft batch jobs, which are taken from Oracle® E-Business Suite and PeopleSoft.

Oracle Pulse can be configured to report on specific targets that Oracle® Enterprise Manager monitors. Your Oracle Service Delivery Manager (SDM) can work with you to set up and identify your key business transactions for monitoring.

About Transaction Metrics in Oracle Pulse

The Pulse Dashboard provides an overview of the stability and performance metrics for all your organization's services at application, data center (both local and remote), batch and customer center level.

Stability metrics are calculated based on the most recent capture of the concurrent manager metrics for the customer's Oracle® E-Business Suite environments or for any of the PeopleSoft schedulers that manage jobs monitored by Oracle Pulse. Stability uses the last execution of the BTM login transaction successfully executed to completion to indicate whether the service application is available to the users. For batch transactions, stability indicates if the concurrent manager(s) and/or processor monitor(s) are running as expected and within the defined thresholds.

Performance metrics for Oracle® E-Business Suite concurrent managers and PeopleSoft schedulers are calculated based on the two most recent data captures for any job monitored by Oracle Pulse. Performance indicates if the transactions executed for the service from the selected beacon execute within the tolerance of the BTM defined metrics (i.e., median value) or within the defined warning thresholds for batch transactions. The indicator for performance alters once two concurrent transactions executions both exceed the transaction median value.

The Transactions dashboard at Customer Level shows all the transactions for your organization's services, providing separate reports for User Experience by Location, Oracle® E-Business Suite and PeopleSoft. You can filter the transactions displayed by transaction type: EBiz Suite batch job, PeopleSoft batch job, or user interaction. Each transaction record links to more detailed reports of recent and historical metrics.

Similarly, the Transactions dashboard at Service Level provides both summaries and detailed metrics reports for all batch jobs and user interactions associated with the service. Finally, the Transactions dashboard summarizes all transaction information for the selected environment.

About Batch Jobs

Processed as a series of concurrent programs, batch jobs are data-intensive and long running. They are typically run asynchronously, when users are least active on the system. Each request to run an immediate or scheduled batch job transaction as a concurrent program is known as a concurrent request. The request usually includes start and end dates, and the frequency of resubmission if the request is recurring. For each concurrent request, BTM measures the time from when the environment's start message is observed until its end message is observed. This is the response time for the concurrent request.

Note

The terms batch job and concurrent program are used interchangeably in Oracle Pulse.

To help you evaluate the performance of batch job transactions, Oracle Pulse collects both the max runtime and the avg runtime for the batch job transaction for all collected data from Oracle® E-Business Suite or PeopleSoft. The max runtime is the maximum time taken to run the batch job transaction from all runs recorded. The avg runtime is the mean time the batch job took to complete. All completed requests are counted in the response time, regardless of whether condition alerts occurred. If the batch job response approaches or exceeds the maximum runtime, or if the average runtime is higher than expected, further investigation is needed.

You can use Oracle Pulse to identify anomalies in concurrent program runs, and when and why these anomalies occurred. Open the detailed reports to review information about the Oracle® E-Business Suite or PeopleSoft job systems - that is, the Oracle® E-Business Suite or PeopleSoft environment running the batch jobs. Such information include the longest running concurrent requests currently running in the Oracle® E-Business Suite job system, the jobs in alert state at a particular point in time, and the jobs in alert state within the 7 days preceding the last data collection for your PeopleSoft job system, as well as the jobs currently queued in the PeopleSoft job system.

Historical reports for the Oracle® E-Business Suite job systems show the longest running concurrent programs or the concurrent program with the highest count of requests, during any 24-hour interval from the specified date, while historical reports for the PeopleSoft job systems show the number of job requests of various statuses within the last 24 hours.

BTM also tracks the phase and status of all ongoing and historical monitored concurrent requests, helping you identify performance or runtime issues with monitored Oracle® E-Business Suite or PeopleSoft batch job requests that are running or were run over the reported interval (the last hour, the last 24 hours, or the last 31 days).

Historical reports for the Oracle® E-Business Suite jobs can be filtered to show concurrent request behavior for any 24-hour interval. You can open a list of all monitored concurrent requests, of the requests that completed with errors (Requests Completed with Error filter) or warnings (Requests Completed with Warning filter), of the requests that were in pending phase (Pending Requests filter) or that spent longer than expected in pending state (Long Pending Requests filter), or you can review all requests that completed successfully (Requests Completed Successfully filter).

About User Interactions

In contrast, user interaction transactions are evaluated on performance time only. BTM records the time that the last set of operations comprising the user interaction takes to complete. This is the last response time for the transaction.

For user interaction transactions, BTM compares the last response time with the 30-day average runtime. This value is the running average of all runtimes recorded for an user interaction over the preceding 30 days. All completed runs are counted in the response time. BTM also shows the difference between the transaction's last response time and the agreed threshold. The threshold is the longest acceptable response time for the user interaction. It is defined in Oracle® Enterprise Manager in consultation with your Oracle SDM.

To analyse the performance of any user interaction, open the detailed report. The performance chart compares the response time for an user interaction against both the threshold and the historical median. The historical median is the value lying at the midpoint of the range of response times measured. Flip to the table view to see the values underlying the chart.

The details in the Sustained Stress tab assist the user in identifying impactful performance degradation on key business transactions, and identify the possible causes of that degradation, enabling faster resolution times. The chart in this tab highlights periods of performance degradation where the response times of the transaction are trending significantly above or below the normal response times for that transaction over a sustained period. These periods of sustained stress are correlated with events (including change requests, service requests, and functional events) that have occurred around and during the identified stress period, as these are possible contributors to the performance degradation itself.

About LTM Transactions

Login Transaction Management (LTM) transactions are now part of the core Oracle services monitoring setup for production applications. The goal of LTM transactions is to detect application access issues that may arise in relation to infrastructure components, capacity, performance, and access.

Using a restricted-access user account, an LTM transaction simply logs into the application home page and immediately logs out - this simple action allows the LTM transaction to track the aforementioned issues. LTM transactions are expected to have no impact on the capacity or performance of the production environment. For more information on LTM transactions, please contact your Service Delivery Manager.

About SOA Services

Oracle Service-Oriented Architecture (SOA) services provide connectivity between applications deployed in a service-oriented architecture. Connectivity between these services is essential for a business to continue to run effectively and support its goals.

Composite applications, also referred to as composites, are software applications built by combining multiple existing functions into a new application. The composite target is made up of building blocks that you use to construct a SOA composite application, called service components (BPEL process, business rule, human task, spring, and mediator).

Use Oracle Pulse to analyze the status of the targets the SOA suite runs on, and to pro-actively monitor the health of composites (status, usage and other metrics), which plays an important part in foreseeing and understanding the growth and impact of composites on performance and storage. Moreover, Oracle Pulse can also report on the status of SOA composites, which further allows you to maintain data synchronization and minimize any potential delta between the systems. For example, for intensively used composites, when a high level of audit logging is set for a set of composites in order to maintain error, warning and other details, this may mean that a high volume of data is kept in the database. Insufficient log purging activity can cause major performance issues and storage space issues, affecting further activities in the service.

SOA composites can be deployed into separate sections of the SOA infrastructure, known as partitions. Deploying to partitions enables you to logically group SOA composites and perform bulk lifecycle management tasks on all SOA composite applications within a specific partition.The smooth and timely interaction between integration points in a SOA service is critical to the success of overall business process flows. The BTM functionality in Oracle Pulse provides the ability to:

  • view SOA composite health and diagnostic information

  • get early visibility to allow the timely resolution of incidents

  • understand trend data related to SOA interfaces, which ensures better insight into the overall business process volumetrics, and provides data insights into areas that are performing outside expected norms

Business Insight Metrics

The Business Insight functionality in Oracle Pulse uses two categories of metrics:

  • Key Performance Indicators (KPI) metrics provide high-level insight into a critical business measurement, such as inventory levels or accounts status. KPI metrics can be tracked visually via a Business Insight chart. In addition, thresholds and alerting can be configured for these KPI charts, assisting proactive tracking.

  • Detailed metrics are metrics associated with the KPI metric which provide further insight into any issues identified in the KPI chart. These metrics are visible via the table view. For example, if the KPI chart indicates that the percentage of accounts with the Open status is too high ahead of your Period-Close event, the table view can provide complementary data highlighting the name of the accounts, which geographical region they belong to, or who is a contact point in that region. Together, the KPI chart and the table view facilitate you in proactively tracking your key business objectives, and provide you with further insight to interpret the KPI measurements and to take data-driven action.

The Business Insight widget on the Pulse Dashboard provides a high-level summary view of provisioned Business Insight reports. For more information, see the Business Insight Widget section in Checking the Performance of Your Services.

The Business Insight dashboard summarizes information about the metrics that you requested to include in your Business Insight report, allowing you to monitor your metrics of interest. For more information, see the Monitoring Business Insight Metrics section in Using the Business Insight Reports.

Host and Database Metrics

Host and database metrics are tracked in Oracle Pulse using information drawn from Oracle® Enterprise Manager. Available at Customer Level, these metrics allow you to see the load on different hosts and databases at a particular point in time.

The host metrics table on the Performance dashboard at Customer Level allows you to check:

  • the average number of jobs waiting for I/O in the last interval

  • the amount of CPU being used in SYSTEM mode as a percentage of the total CPU processing power or the percentage of time the process threads spent executing code in privileged mode

  • the amount of CPU being used in USER mode as a percentage of the total CPU processing power or the percentage of time the processor spends in USER mode

  • the amount of CPU utilization as a percentage of the total CPU processing power available or the percentage of time the CPU spends to execute a non-idle thread

  • the amount of used memory as a percentage of the total memory

  • the number of pages paged in (read from disk to resolve fault memory references) per second or the rate at which pages are read from disk to resolve hard page faults

  • the number of pages written out (per second) by the virtual memory manager or the rate at which pages are written to disk to free up space in physical memory

  • the average number of processes in memory and subject to be run in the last interval

  • the percentage of swapped memory in use for the last interval or the percentage of page file environment used

  • the total number of processes currently running on the system

For more information, see the Using Host Metrics section in Using the Performance Reports.

The database metrics table on the Performance dashboard at Customer Level allows you to check:

  • the current number of logons

  • the average time that the current request (CR) block was received, measured in 100ths of a second

  • the total number of bytes sent and received through the SQL Net layer to and from the database

  • the number of data blocks written to the disk per second during this sample period

  • the utilization of the process resource against the values (percentage) specified by the threshold arguments

  • the utilization of the session resource against the values (percentage) specified by the threshold arguments

  • the number of logical reads per second during the sample period

  • the total amount of memory used, in MB

For more information, see the Using Database Metrics section in Using the Performance Reports.