Troubleshooting Concepts

Oracle Utilities Application Framework

April 2020| Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates
Confidential: Public
PURPOSE STATEMENT
This document provides an overview of troubleshooting series for Oracle Utilities Application Framework based products by
introducing concepts.

DISCLAIMER
This document in any form, software or printed matter, contains proprietary information that is the exclusive property of
Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle software
license and service agreement, which has been executed and with which you agree to comply. This document and
information contained herein may not be disclosed, copied, reproduced or distributed to anyone outside Oracle without
prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any
contractual agreement with Oracle or its subsidiaries or affiliates.
This document is for informational purposes only and is intended solely to assist you in planning for the implementation
and upgrade of the product features described. It is not a commitment to deliver any material, code, or functionality, and
should not be relied upon in making purchasing decisions. The development, release, and timing of any features or
functionality described in this document remains at the sole discretion of Oracle.
Due to the nature of the product architecture, it may not be possible to safely include all features described in this document
without risking significant destabilization of the code.

1 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
TABLE OF CONTENTS
Purpose Statement 1
Disclaimer 1
Introduction 3
Related Material 3

Performance Troubleshooting Concepts 3

Caveat 3
What is a Performance Issue? 4
How do I set Service Levels? 4

The Nature Of Performance 5

Troubleshooting Process 6
Scoping the problem 7
Determining the best collection points 7
Collection of performance data 9
Recreating The Problem 9
Using Debug Mode 9
Analysis of the collected data 10
Determine the suspects 10
What Am I Exactly Looking For? 11
Deep Analysis 11
Determine cause and action plan 11
Making the changes 12
Recording a defect with Oracle Support 13
Verify the problem has been resolved 13

Appendices 13
Scoping Checklist 13

2 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
INTRODUCTION
When products utilizing the Oracle Utilities Application Framework are installed and configured, monitoring needs to be
performed and performance problems dealt with in a rapid way to maintain desired levels of performance. Knowing where
performance problems are registered, how to track them down and ultimately address them is key to continued success.

Related Material
The following articles are recommended reading for this topic:
 How to Use My Oracle Support Video (603505.1)
 My Oracle Support Resource Center (873313.1)
 Getting Started with My Oracle Support (1959163.1)
 How to Create Service Requests in My Oracle Support (1496117.1)
 Collecting Diagnostic Data to Troubleshoot Oracle Utilities Framework Based Functional Issues (2057204.1)
 Collecting Diagnostic Data to Troubleshoot Oracle Utilities Framework Based Products (2064324.1)
 Details Required when Logging an Oracle Utilities Framework Based Product Service Request (1905747.1)
 Collecting Diagnostic Data to Troubleshoot Oracle Utilities Framework Based Products - Batch Issues (2064310.1)
 Collecting Diagnostic Data to Troubleshoot Oracle Utilities Framework Based Patch Installation Issues (2064389.1)
 Collecting Diagnostic Data to Troubleshoot Oracle Utilities Framework Based Installation Issues (2058433.1)
 Oracle Utilities Framework Support Utility (1079640.1)
 Configuration And Log Files Checklist For Oracle Utilities Application Framework Based Products (797594.1)
 How to Capture Fiddler Logs in Oracle Utilities Application Framework Based Products (1293483.1)

PERFORMANCE TROUBLESHOOTING CONCEPTS

Performance of any implementation is critical to meeting critical service levels and meeting the objectives of the business
using the products. Prevention, diagnosis and resolution of performance issues is therefore imperative to maintaining
acceptable performance.
Performance Troubleshooting is a collection of concepts, techniques, capabilities and metrics to help detect and address
performance issues in the architecture. The Oracle Utilities Application Framework is a collection of technology and with a
potentially complex architecture a complex set of ways of collecting information to diagnose and address performance
issues. This series of whitepapers attempts to address this by:
 Explaining the areas of the product that are available for obtaining performance and troubleshooting information.
 Outlining a basic troubleshooting methodology, which can be used to help isolate a problem into the appropriate
area.
 Outlining common advice and common problems and some suggestion possible solutions. This section will not be
the end all discussion about performance but will cover the basic common problems.

Caveat

3 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
While all care has been taken in providing this information, performance troubleshooting may be complicated. The advice in
this document may or may not apply to the performance problems you may be experiencing. The examples and general
advice should be taken as suggestions only.
It is recommended that each technique outlined in this series of documents be examined considering your organizational
policies and use of the product at your site. If the technique is deemed appropriate to your site, then consider implementing
it. If the technique is not appropriate (e.g. contravenes site policy and other reasons), then it should not be used.
Scripts and command in this series are provided as is and should be considered as a starting point for any utilities or
facilities you wish to implement.

Note: For publishing purposes, the word "product" will be used to be denote all Oracle Utilities Application Framework based
products.
Note: Advice in this document is primarily applicable to the latest version of the Oracle Utilities Application Framework at
time of publication. Some of this advice may apply to other versions of the Oracle Utilities Application Framework and may be
applied at site discretion.
Note: In some sections of this document the environment variable $SPLEBASE (or %SPLEBASE%) is used. This denotes the
root location of the product install. Substitute the appropriate value for the environment used at your site.

What is a Performance Issue?

Whilst the term performance issue seems simple to interpret, it can be clouded in respect to perception versus reality.
Performance is subjective and is open to individual interpretation in terms of perspective.
Business users are driven by targets, both defined and implied, in terms of individual throughput. The success of the
business is driven by getting the right information at the right times in a timely manner. Whilst this can be expressed in
terms of tangible targets, it can also easily become perception. For example, the passage of time can be perceived differently
across users. This factors into what is perceived as a performance issue.
To focus the discussion around performance and reduce perceptions, it is recommended to view performance issues using
the following definition:

A performance issue is an issue where the performance of a function or capability has exceeded an
agreed and documented tolerance or service level.

This ensures that a target service level is agreed and that the performance issue is directly associated with that target service
level. This attempts to solidify the idea of performance adversely effecting a business goal rather than a general feeling of
performance issues. The goal is to set an agreed set of service levels that can be tracked against to recognize performance
issues.
An old saying in performance engineering is if you set no targets then you can shoot the arrow anywhere and that becomes
the target. Setting no targets sets the perceptions taking over the reality.

How do I set Service Levels?

Businesses run on targets to operate within acceptable tolerances. This is no financial targets generally associated with any
business but throughout targets to maintain a level of service to their end customers.
When setting service level targets for performance the following guidelines should be used:
 Translate Business Targets into Service Levels. Ask the business for their targets and translate those into
technical service levels. In the utilities sector, the following table outlines some examples of typical business targets.
Example Targets

TARGET COMMENTS

Call Center Volume Call centers need to process volumes of calls per period at peak times (hour, day etc)
to justify the service. This can be translated down to volume to support for peak
volume metrics.

4 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
 TARGET COMMENTS

Time On Calls While volume gives you an idea of the size of the performance pool, the time a call
center representative spends on an individual call drives the business. The lower the
time the better. This needs to be analyzed to isolate individual transactions or
business processes for tracking.

Batch Throughput To make targets for time, background processes need to start, finish or process a
target amount of records per period.

Batch Window Batch processing includes when the batch needs to be executed in a business day
and/or when key business processes need to complete. For example, printing of
physical bills may need to be available to pass to a third party at a time.

Note: The above list is not exhaustive, it is provided to illustrate the potential areas of concern for setting service
levels.

 Agree Service Levels for Each Target. Once the targets metrics are established then a target tolerance value
should be agreed. This needs to be stated and avoid the as fast as possible target that is sometimes perceived. This
value is the value tolerated by the business not necessarily the desired value. It is also recommended to set an
additional target to help proactively identify problems. This is typically known as a warning value. It helps detect
when problems are starting to occur before the service level tolerance is triggered.
 Set Those Targets. Using capabilities within the architecture you may be able to express those targets in the
product or the monitoring infrastructure to detect the tolerances and report them. The capabilities of the product to
set these targets will be discussed in the relevant parts of this series.
 Define Business Periods. Factor in that targets may change over different business periods. If it is applicable,
define peak periods or times of day that define the period of the service. This allows some flexibility in setting
targets. For example, during peak business times, online targets are far more important than perhaps in non-peak
times. If there is a difference, include definitions of those periods in your consideration for monitoring purposes.

THE NATURE OF PERFORMANCE

Troubleshooting performance is not an exact science. It is detective work at best. You need to get all the suspects in, and by
examining the evidence and clues, determine the culprit. Like a mystery novel, the culprit may have accomplices or in fact all
the suspects may be the culprits.
During your investigations expect the following:
 Performance is somewhat subjective. Perception of individuals may play into it. The key is to gather evidence
(through analysis or good old-fashioned observation) to turn perception into fact. Gathering evidence may suggest
there is in fact no problem at all.
 The product interface will be blamed for every problem and will become the target of accusation on
performance. Typically, the product will be blamed as external causes of bad performance can affect the front end
and users only see the front end. This is akin to health problems and trying to be the doctor diagnosing the
problem to suggest a remedy. What you see, typically, are symptoms of a problem and those symptoms are
exposed to the front end.
 Performance of other systems at the site is within acceptable limits. Sites typically will point to other
applications on their site having no issue. This may be true (not always) but those applications may not have the
same usage profile that product typically has. Not even another similar system at a site can be compared to the
product, as unless they have the same usage profile, they will have vastly different performance and capacity
profiles.
 The factors that contribute to performance are varied. Performance at a site is a function of the following factors:
− Configuration of the Product (technical and functional). The technical configuration settings and the
control data that controls the behavior of the code affect the performance of a system.
− Usage Patterns. The frequency, volume and types of transactions dictate performance characteristics.
− Resource available. The amount of network, disk, memory and CPU on the client and server are a major
factor in the performance of a system.

5 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
This series attempts to arm you, the detective, with the tools of the trade, to help you determine which of the suspects (or
group of them) the culprits in a performance problem are.

TROUBLESHOOTING PROCESS
Typically, when Oracle Support or performance experts, are called to perform performance analysis on a product site a
problem-solving methodology is used to gather information about the problem, assess the evidence and come up with an
action plan to address the problem. This document and the rest of the documents in this series will outline the process, the
statistics to collect and the problem-solving techniques used to resolve performance problems.
The figure below summarizes the performance troubleshooting methodology typically used for products utilizing Oracle
Utilities Application Framework:

Figure 1. Overview of the performance troubleshooting process

The steps are summarized as follows:

 Scope Problem. The performance problem is scoped to determine the appropriate collection points and the likely
causes of the problem. This is a preliminary and attempts to take advantage of any evidence of the problem
gathered at the time of the problem.
 Determine Collection Points. From the rough scope of the problem, a set of collection points are queried, within
the application framework architecture, to gather performance and analytical data used for identification of the
problem.
 Collect Data. Data from the collection point within the application framework’s architecture is extracted for
analysis. This activity is in accordance to the policies and tools used on the site.
 Analyze Data. Data is collated and analyzed for common trends and problems.
 Determine Suspects. From the analysis a subset of possible suspects is compiled. Deep diving analysis may be
necessary to isolate the cause.
 Determine Cause & Action Plan. Each suspect is examined against expectations and the cause of the problem is
determined and an appropriate action plan is formulated.
 Register Defect. If the problem is a defect with the product, then the problem and relevant evidence should be
registered with Oracle Support. A single fix or a configuration suggestion will be passed back for implementation
through the sites change management process.

6 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
  Change. If the action plan recommends a change must be implemented, then the relevant changes will be subject
to your sites change management procedures.
 Verify. Once the change has been implemented, some performance data collection may be necessary to verify that
the problem has been addressed.
The subsequent sections of this document will outline the process for each of the steps.

Scoping the problem

The first part of any performance troubleshooting process is to scope the extent of the performance problem. Once the
scope of the problem is appreciated then the correct method of analysis can be chosen.
In scoping the problem, the following questions need to be answered:
 Is the problem wide spread or isolated? Is the problem across the board (all users and all functions), specific users
and functions or somewhere in between? This has a huge bearing on where you start collecting evidence and
isolating suspects. We will discuss the various techniques as part of the other steps.
 Can the problem be recreated easily? The problem must be re-creatable at some level else it may be just a one-
off occurrence, and this may be more difficult to solve.
 Has the problem just starting to occur, or has it been there a occurring for a while? This may not seem an
obvious question to ask, as most customers should jump on performance problems as soon as they occur, but this
is not always the case. The longer the time to start addressing the problem the harder it is to solve the problem. The
evidence may be difficult to source.
 What major business and technical events have happened on the system before and after the performance
problems have occurred? Typically, performance related problems happen after some event has happened (a
marketing campaign, large influx of customers, installation of new hardware, new application added to network
etc). You are just trying to see if an event triggered the problem. If a change happened and the performance
problem occurred immediately after the implementation of the change, it is likely the change is the culprit.
Reversing out the change (if possible) may remedy the situation.
 What has been done so far to address the performance problem? This is just a history check to see what has
been tried already to solve the problem. This may prevent suggesting solutions that have been tried or reinforcing
the change.
 What else is running on that system other than the product online and background? Does the product have
exclusive access to the resources on the machine? The answer needs to check if Ad-hoc SQL is allowed on the
database, reporting or other processes are running on the system at the same time as the product front end and
background processes. This needs to include any housekeeping activities that the IT group does on the machine
(e.g. backups) and major interface timings.
A scoping checklist is provided in the appendices of this document that assist in answering these questions.

Determining the best collection points

The product has several collection points within the architecture that can be used to collate data from the product to aid in
tracking and solving performance and other problems.
The figure below summarizes each point in the architecture and the where the groups of collection points exist within the
architecture:

7 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Figure 2. Scope of the individual collection areas

The key is to determine which points to collect for your problem. It can be excessive to collect all the data from all the
collection points for all problems (though this is possible). Being able to focus the data collection on specific areas will
reduce resolution time. The table below is a guide to help you decide which collection areas:
Performance Troubleshooting Areas

AREA SCOPE WHEN TO COLLECT

Client PC or browser issues Problem is with one client machine only

Web Application Server Web Application Server and Java issues Global online problems or specific online
transactions

Server CPU, Memory and Disk issues Global problems or specific transactions

Batch Background Processing Global batch problems or specific batch jobs

Network Network across all tiers Global online problems or specific online
transactions

Database Database issues Global issues or specific transactions

If this table is not helpful for your problem, then consider collecting data from all relevant areas. The Area column of the
table highlights the document in this series that focuses on the collection points, what data is available to collect and some
basic guidelines on how to collect it.

8 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Collection of performance data
The collection point documented in the documents of this series can be accessed several different ways depending on your
site's preference. Each the of the documents in the rest of this series will outline the collection points for the relevant
collection area, the statistics that are available from those points and the basic ways that they can be collected.
While the documents, will outline the basic methods there are always alternative methods and tools available to collect
information for analysis. Your site may have a set of tools already to collect this information on a regular basis. The
documents do not specify the exact method of extract that should be used, just a method that may be used. It is up to your
sites practices and site chosen tools to collate that information.
For example, your site may already have a tool to monitor the operating system of the server. The Server Troubleshooting
document will outline what information out of that tool is relevant to products using the application framework.

Recreating The Problem

One of the important techniques used by the Oracle support personnel is the ability to recreate the problem. The ability
allows additional information to be captured to help solve the problem and assure that the problem is not a once off
problem. This technique applies to all types of problems, not just performance related ones.
As part of the scoping exercise, you determined the extent of the problem (local or global) and the circumstances under
which it occurs. You should be able to recreate the problem before doing further analysis. This may provide further insight
into the issue and give some clues as to the underlying cause.
One of the tools available within the application framework is debug mode. It provides internal trace information about the
transaction that can be used to diagnose the problem.

Using Debug Mode

When you recreate a problem, a technique to gather additional helpful information is to enable Debug mode within the
application framework. The idea is that when debug mode is enabled, additional performance and internal information is
written to various places that may provide helpful clues to the location of the problem.
Typically, Oracle Support will request that the problem be recreated with Debug mode switched on and then the associated
logs provided with the problem definition to assist in the resolution of the problem. There are several ways to turn on debug:
 To provide debug information for background processes, you must enable the debug parameters for the program
at submission time. The debug parameters are part of the standard set provided with all background processes.
Running the background process with debug on will write the debug information to the stdout files for the
background process. The specification of the debug switches varies with the method used for submission. For
example, if the online submission screen is used, then the switches are indicated on the submission screen itself:

Figure 3. Tracing options for background processes

Note: For Oracle Utilities Application Framework V4 and above, the trace options are also available to be defaulted on the
Batch Control as well as supported by the submission methods. Refer to the Batch Best Practices (Doc Id: 836362.1) available
from My Oracle Support for more information.

 To provide debug information online processes, you must add the ?debug=true option to the end of URL to enable
the debug option. This will ensure that the Global debug toggle will be displayed:

Figure 4. Debug Mode for online transactions

Note: If Oracle Utilities Application Framework V4 and above, the use of debug mode is restricted to authorized users only.
Refer to the Server Administration Guide with your product for more details.

9 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
To debug, you must navigate to the page that you want to trace, then enable the Global debug toggle and execute the
transaction. After the transaction is complete (or failed) then switch off debug by unselecting Global debug. All debug
information is written to the server logs.

Analysis of the collected data

Once the data is collected in various formats, it is a good idea to collate the data in such a way that can make it be able to be
analyzed. This allows the data to be summarized, presented and correlated in such a way that can benefit analysis. The other
documents in this series will discuss the various ways specific data can be analyzed, so that the benefit of the data for
performance resolution is maximized.
There are a few techniques that can be used to collate the information:
 Monitoring tools will hold a repository of the information so that it can be reported in various formats.
 Individual tools used in the architecture have monitoring capability that can be viewed natively or loaded into a
database after manipulation.
 The data that is collected should have the following information included:
− Date and Time of the recording. This is helpful for correlation.
− Identifying information. Identification of the transaction, person who ran it or both.
− Indication of the data used in the transaction (optional). It may be possible to identify the key data used in
the transaction (this only possible for some of the collection points).
Note: Ensure compliance with local privacy law is adhered to when dealing with production data.

 Statistics collected. Some statistic or derived value that you can use to assess the performance of the transaction.
This can be a calculated elapsed time, a rate or even a status value.

Determine the suspects

One the data is collated and analyzed the suspects can be determined. At each point in the architecture you will examine
the data and see if anything is indicating where the problem is. If the data collected for that point in the architecture
indicates that, all is within acceptable tolerances at that level, you can discard that point as a suspect. At this point there are
two approaches to determine the suspects that can be utilized.
 Top Down. If the problem is specific to a user, then you will examine the collection points in the architecture in a
top down fashion. This means you will start analyzing from the top of the architecture and work your way down the
architecture.
 Bottom Up. The most common technique for general problems is to examine performance information from the
points of the architecture from the bottom of the architecture (the database server) and work all your way up the
points of the architecture.
The figure below summarizes the two approaches and the order at which you will examine the points in the architecture:

Figure 5. Approaches to Performance Troubleshooting

10 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Some of the architecture is repeated as at each tier of the architecture there are common components. For example, the
components all should run on an operating system and a network (even it is the same operating system and an internal
network).

What Am I Exactly Looking For?

At each point, there are specific conditions that you are trying to detect to either, identify the point as a potential suspect of
the problem or discount it altogether from your investigations. The list below is the typical conditions you are trying to
detect in the data collected to conclude whether the point is a suspect in the problem:
 Is any statistic indicating that the point in the architecture is behaving outside normal tolerances? Normal
tolerances will be explained in the relevant documents of this series for each point in the architecture.
 Is this first place the problem is experienced? For example, is this where the error message is displayed? This is not
always a symptom as sometimes the point is really the problem started.
 Is there any unusual activity detected?
The answer to these questions will indicate if the point is a suspect or not. If all looks acceptable at the point, then it may be
discounted as a suspect but if there is any doubt then include in your suspect list. The next pass in the analysis is called a
deep pass where you will examine all the collection statistics available at that point in detail and see if further evidence can
be found.

Deep Analysis
The next step is known as deep analysis. When you first perform analysis, it is usually glancing over the data to see if
anything stands out. In some performance troubleshooting circumstances that is enough to detect the suspects, but if it is
not clear deeper analysis is required.
Deep Analysis involves taking a closer look at all available statistics and performing additional analysis to find correlating
events and flow on from performance problems. The concept of flow on is that a performance problem in one area will be
seen in another area. A common example of flow on is the browser user interface. All online performance problems will be
experienced using the browser user interface, but it may not be caused by the browser front end at all but is a result of a flow
on effect from another component.
In deep analysis the following additional analysis is required:
 Data from one performance problem will be correlated by data from several points in the architecture. If this is not
the case, then it should be easier to spot the prime suspect as it will be the only point with the problem data.
 In the bottom up approach, the first place where the problem surfaces (progressively looking from the bottom of
the architecture to the top) is the prime suspect. Looking for flow on effects from that point and above in the
architecture can further prove this.
Look at all the statistics and look for any unusual activity that can assist.

Determine cause and action plan

Once the prime suspects have been identified the next step is to try and determine the cause of the problem and document
an action plan.
The other documents in this series will outline the common problems that can occur at each point in the architecture and
some sample action plans. Refer to these documents on specific causes of problems at that point of the architecture.
In documenting the action plans you should consider the following:
 The actions that are necessary for the resolution of the problem are documented at a level so that the person
responsible for implementing the change will be able to understand the actions. Expect the lowest common
denominator to pitch the level of the action plans. It might be that you might be even documenting step by step
what should be done. Work with the people responsible to determine what they need.
 If there are several actions or several problems to address, then consider adding a matrix at the end of the plan to
clarify the relative priorities of the individual actions. In the matrix include information about the action, which
person (or group) is responsible for the action, the potential effect of making the change on the problem and some
ideal of the effort required for the change.
For example:

11 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
Sample Action Plan

ACTION RESPONSIBILITY POTENTIAL EFFECT POTENTIAL EFFORT

… … High Low

… … Low Loe

Potential Effect Legend

EFFECT COMMENTS

Low There is little effort on performance but may benefit in operational or administration
aspects of the site.

Medium Implementation of these changes may provide some performance benefit.

High Implementation of these changes can have a profound effect on performance.

Potential Effort Legend

EFFECT COMMENTS

Low The effort is minimal to implement this change, usually a configuration file change.

Medium Medium The effort to implement this change is not minimal but requires some planning.

High Effort to implement this change includes testing and verification activities.

Note: One of the techniques used by some implementation is to use icons rather than text such as the the traffic light
standard or a Confluence status widget.

 If there are references to any product or external documentation, refer to them in the action plans. This may assist
in the implementation of the change.
 Typically actions in the plan fall into several categories:
− Configuration Change. This type of change involves changes to the configuration files (technical) or
configuration data (both functional/technical) to influence the change. Changing a tolerance or changing
the size of a connection pool are examples of configuration file changes. This is the most common of the
types of changes that are performed.
− Patches. Patches from any of the components (including product and custom code) may have to be
implemented.
− Reorganization. Unusual data growth can sometimes require reorganization of the data for optimization.
− Business Process changes. Sometimes the answer to the problem is not technical but simply a change to
a business process or business rule. For example, instructing users to avoid wildcards for searches is an
example of a business process change.

Making the changes

Implementation of any change needs to be considered carefully in overall scheme of things. Suggesting an action plan does
not automatically solve the problem. Typically, the following additional steps need to be considered in the implementation
any plan:

12 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
  The plan should be assessed against the site's standards. If you suggest something that contravenes a site policy,
then an alternative approach in the plan may need to be considered. Make sure you take organization policies for
the site will be considered when you write the plan. Check with those responsible to assist in identifying any policies
that may impact your action plan.
 The plan should be assessed against maintenance schedules as well as any service level agreements. All actions will
have to fit into resource and maintenance plans that the site uses.
 There may be a separate change management process the plan has to be submitted to so that it can be approved
and then actually worked on. Make sure there is enough information in the plan to assist in gaining approval in
change management.
 Include a fallback plan or alternative approaches as these may need to be considered when the work is carried out.
 You might want to add any expected results when the change is implemented. This is not always possible but if it
can be outlined this may assist in change management and any follow-up.
Making the change is not as straightforward as Just Do It as it may be major and require change management with the site.
Planning for getting the right information to the right people to perform the change is important.

Recording a defect with Oracle Support

If the problem is a problem with an Oracle product, then you must register the problem with Oracle support using the
process outlined by the Support group. All the data collected as evidence should be provided as part of the process to get
the problem resolved as quickly as possible.

Note: Refer to the Related Material in this whitepaper for additional advice on efficiently raising service requests.

When the change is available you will have to repeat step 7, as the change needs to be implemented.

Verify the problem has been resolved

Once the change has been performed, the impact of the change needs to be assessed to see if the change was successful in
addressing the problem. Using the same tools, you used to find the problem, can be used to find evidence that the problem
has been resolved or that the suspect was in fact the wrong one and that further investigation is needed
You should inform the parties involved with the change if the change was successful or not.

APPENDICES

Scoping Checklist
Checklist Items

CHECK COMMENTS

Is the problem wide spread or isolated? Detail whether it a single function or a single user. Detail if it
is widespread, what functions are adversely affected?

Has the problem just starting to occur or has it been there a What was the first reported incident of the problem? Do you
while? have enough details of the problem to recreate it if it was a
while ago?

Can the problem be recreated? Take a note of the conditions where the problem occurred
and even the data that caused the problem. In some cases,
it has been known that the data used can cause
performance issues.

What major business and technical events have happened List all the events that occurred just prior to the first
on the system before and after the performance problems occurrence of the problem. This includes business as well as
have occurred? any technical events.

13 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
 CHECK COMMENTS

What has been done so far to address the performance List all the actions that have been taken to address the
problem? problem up until the current time. Compile the evidence
gathered so far.

What else is running on that system other than the product List what was running at the time of the problem. Include
online and background? the online as well as batch and network.

14 WHITEPAPER | Troubleshooting Concepts | Version 4.4.0.2.1

Copyright © 2020, Oracle and/or its affiliates | Confidential: Public
CONNECT WITH US
Call +1.800.ORACLE1 or visit oracle.com.
Outside North America, find your local office at oracle.com/contact.

blogs.oracle.com/theshortenspot linkedin.com/in/theshortenspot twitter.com/theshortenspot

Copyright © 2020, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without
notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties
and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed
either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without
our prior written permission.

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. 0120

Troubleshooting Concepts
April, 2020
Author: Anthony Shorten, Senior Principal Product Manager, Enterprise Applications - Technology
Document Identifier: 560382.1