Mark BurgessClearly defining your Oracle database performance problems is one of the most important steps in resolving system performance issues.
With this in mind, how can you help your technical teams resolve issues more quickly and with less risk?
In this post, we’ll look at how to clearly define performance problems and start the process of fixing them in a structured and methodical way.
Oracle Performance Cost
Why is it so important to resolve performance issues that are impacting your business?
A poorly tuned Oracle system is costing you in the following ways:
- Poor indirect stakeholder engagement with corresponding business cost.
- Huge opportunity cost of unrealised potential of analytic systems.
- Excessive cloud subscription costs directly impacting the bottom line.
Read more about the cost of poor Oracle performance here.
Where to begin?
In many cases, system performance problems are defined by acronyms of various technology components. Very often the optimisation process is considered a “black art” to system stakeholders who are most affected by poor performance.
So the first step is to establish a common ground between the users most impacted by performance issues and those responsible for resolving these issues.
You can do this by helping users to clearly and concisely describe the problem and the business impact of the problem.
Without this step, the problem measuring the benefit of any resolution becomes a guess at best. At worst a risk to system performance, stability and at its very worst, a security risk.
Poor Problem Statements
Engineers tasked with resolving system performance issues typically spend the majority of their working hours dealing with structured systems and procedures.
Unfortunately, the typical problem definition for a system performance issue can often be unstructured.
The following are fairly typical when system performance problems are first reported:
“The system is slow.”
“I can’t login.”
“I couldn’t do my XYZ this week”.
When translating a loosely defined problem from a users perspective it can be easy for important details to be missing from the problem statement that helpguide the technical resolution to a problem.
How can you reduce this gap?
The problem definition needs to be well structured and clearly capture the relevant information from the impacted users. This requires standard, repeatable operating procedures along with templates to capture essential problem information.
When users report performance problems, use a standard template to capture the relevant information in non-technical terms.
This serves two benefits:
- The impacted users can define the problem in their language.
- The essential information for the technical team can be captured. Specifically, what happened, when did it happen and what is the expected resolution.
This approach provides your stakeholders with consistency and predictability when dealing with your technical teams and removes a level of user frustration that can arise when ad-hoc approaches are used to capture complex performance problems.
What information are we looking for?
To expand on our “The system is slow” example from above; we would further define the problem with the following template questions:
- What is the process, or function that is slow?
- When does this occur? Start time and end times – to the minute if possible.
- How often does it happen? The same time each day/week/month?
- What is the impact of this XYZ being slow?
The 4 questions above will significantly help define the problem from the user’s perspective; when it happens, how often it happens and what the impact is to them.
Once you have obtained 1 and 2 from above, you’re well on your way to defining the problem from a system’s perspective. Once we know what is slow and when it is slow, we have a large number of resources available to measure and identify exactly what is causing the poor performance.
In the context of solving complex Oracle systems performance problems, the above questions may seem somewhat simplified.
The simplicity of this process is what makes it effective in enabling the problem to be very well defined in scope, duration and cost.
How can you capture this information all the time?
Adopting this approach does require commitment and engagement from both user and technical teams.
For the IT teams, embedding these questions into your IT support systems will provide a consistent process to follow when capturing the correct information.
Most modern support systems (JIRA Service Desk, ServiceNow, AutoTask) allow for templating of service desk requests. Develop a specific request template for performance problems that enable the users reporting the issue to provide the required details.
For system stakeholder teams, highlight the importance of following a defined process to help fix reported problems efficiently.
Ensure that when problems are reported, using a structured approach (as opposed to email, ad-hoc phone calls), to acknowledges the feedback on the issue as soon as possible.
We are not trying to engineer technical solutions with this approach – we are trying to engineer repeatable and predictable behaviour to aid in resolving performance problems as quickly and accurately as possible.
No Guesswork
Fixing complex Oracle Database performance problems is not a black art. It does require thorough analysis, understanding and experience in a structured approach to deliver the best results.
Book a call with us today to discuss how we can help you solve your Oracle performance problems.
