1 Introduction

Availability Metrics

Oracle Pulse presents the latest representation of availability for your organization's Managed Cloud 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 Managed Cloud Services follows 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 instances, 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 instances, where the outage occurs at an agreed date and time due to regular maintenance or a customer request for change.

If isolated business transactions cannot be completed in your production instances, 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.

The Availability Dashboard at Customer Level summarizes information about the availability of your organization's production instances for the specified period of time. For more information, see the Viewing Customer Availability in Chapter 5, "Viewing Key Indicators for a Customer".

The Availability Dashboard at Service Level summarizes information about the availability of the selected service for the specified period of time. For more information, see the Viewing Service Availability section in Chapter 6, "Viewing Key Indicators for a Service".

The Availability Dashboard at Environment Level shows the list of records for unplanned outages and service interruptions for the selected environment over a specified period of time. For more information, see the Viewing Environment Availability section in Chapter 7, "Viewing Key Indicators for an Environment".

Limitations of Oracle Pulse Availability Metrics

Availability data in Oracle Pulse represents the best estimate using current Oracle systems and methodologies. Data is calculated using outage information entered manually into Oracle Managed Cloud Services' internal tracking system. Outages are usually identified through automatic monitoring or when initiated by a customer or an Oracle employee in a service request (SR).

However, some outages are resolved directly without customer or Oracle involvement. Outages may also be attributed to the wrong fault category initially - for example, a technology stack outage may have actually been caused by a hardware failure. Therefore, availability data should always be considered to be the most accurate at the time of calculation and may be revised subsequently.

Storage Metrics

Oracle Pulse provides storage metrics for all your organization's Managed Cloud 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 Managed Cloud 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 Managed Cloud Services Data Centers, excluding any servers that your organization owns. Oracle Technology Cloud storage is a special category of Oracle-owned storage, showing data only for your organization's Oracle Technology Cloud instances.

Consumed storage includes the amount of commercial storage allocated for your organization's Managed Cloud Services on Oracle-owned storage. Commercial storage usually includes all storage used by applications such as 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.

The Storage Dashboard at Customer Level covers storage usage across all your organization's Managed Cloud Services and associated environments. For more information, see the Viewing Customer Storage section in Chapter 5, "Viewing Key Indicators for a Customer".

The StorageDashboard at Service Level shows storage metrics for the selected service. For more information, see the Viewing Service Storage section in Chapter 6, "Viewing Key Indicators for a Service".

The StorageDashboard at Environment Level shows storage metrics for the corresponding environment. For more information, see the Viewing Environment Storage section in Chapter 7, "Viewing Key Indicators for an Environment".

Incident Metrics

Oracle Pulse tracks all production and nonproduction service requests - termed incidents - associated with your organization's Managed Cloud 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 instances for a period of 3 complete months. A high number of Severity 1 service requests created on your production instances can merit further analysis.

Service request metrics for your production and nonproduction instances are listed on the Incidents functionality at Customer, Service, and Environment Level.

Similarly, the service request resolution rates, service request backlogs, and service request volumes by product line and severity over the time interval for an individual service are available on the Incidents functionality at Service Level. For more information, see the Viewing Service Incidents section in Chapter 6, "Viewing Key Indicators for a Service". The same metrics for an environment are available on the Incidents functionality at the relevant Environment Level, as described in the Viewing Environment Incidents section in Chapter 7, "Viewing Key Indicators for an Environment".

However, customer-level incident reports account for service requests that may have been created without a reference to a particular environment or service.

Change Metrics

Change requests are tracked in Oracle Pulse using information drawn from My Oracle Support. Available at Customer, Service, and Environment Levels, 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 Managed Cloud 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.

Change metrics are also listed on the Changes functionality at the Customer and Service Level. For more information, see the Viewing Customer Changes section in Chapter 5, "Viewing Key Indicators for a Customer" and the Viewing Service Changes section in Chapter 6, "Viewing Key Indicators for a Service".

The Environment Level provides the same change request metrics for each individual environment. For more information, see the Viewing Environment Changes section in Chapter 7, "Viewing Key Indicators for an Environment".

The Changes functionality at Customer, Service and Environment Level also allows you to see details about the open change requests created for your organization's Managed Cloud Services, as well as to search for and filter the existing change requests. For more information, see the Viewing Customer Changes section in Chapter 5, "Viewing Key Indicators for a Customer" and the Viewing Service Changes section in Chapter 6, "Viewing Key Indicators for a Service".

Business Transaction 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 Release 17.1.2 provides users with separate reports for E-Business Suite and PeopleSoft batch jobs, while continuing to support user interactions.

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 EBSO instances 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 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 Managed Cloud Services, providing separate reports for User Experience by Location, 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 at Environment Level 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 instance's start message is observed until its end message is observed. This is the response time for the concurrent request.

To help you evaluate the performance of batch job transactions, Oracle Pulse collects both the max run time and the avg run time for the batch job transaction for all collected data from E-Business Suite or PeopleSoft. The max run time is the maximum time taken to run the batch job transaction from all runs recorded. The avg run time 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 run time, or if the average run time 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 E-Business Suite or PeopleSoft job systems - that is, the E-Business Suite or PeopleSoft instance running the batch jobs. Such information include the longest running concurrent requests currently running in the 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 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 selected 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 run time issues with monitored 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 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 run time. This value is the running average of all run times recorded for the 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 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 the 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.

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 to the capacity or performance of the production environment.

Host and Database Metrics

Host and database metrics are tracked in Oracle Pulse using information drawn from Oracle^® Enterprise Manager. Available at Environment 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 Environment 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 instance used

• the total number of processes currently running on the system

The database metrics table on the Performance Dashboard at Environment 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