©OraPub, Inc.

Essential Performance Forecasting

(What you need to get started...)

Latest version available at http://www.orapub.com

Essential Performance Forecasting

 ©OraPub, Inc. 2

This page has been intentionally left blank.

Essential Performance Forecasting

 ©OraPub, Inc. 3

Table of Contents

1. Introduction. 4

2. Foundational Concepts Using the CPU Subsystem 4

3. Forecasting IO Performance. 8

4. Managing Risk Through Forecasting Performance. 12

5. Developing Risk Mitigating Strategies. 13

6. Conclusion . 15

7. About The Author. 16

8. Inquires. 16

9. References 16

Essential Performance Forecasting

 ©OraPub, Inc. 4

Essential Performance
Forecasting

Craig A. Shallahamer (craig@orapub.com)

Original March 5, 2006

Version 1a March 5, 2006

Introduction
At a basic level, forecasting Oracle performance is absolutely essential for every DBA to
understand and perform. When performance begins to degrade, it’s the DBA who hears
about it, and it’s the DBA who’s supposed to fix it. It’s the DBA who has the most intimate
knowledge of the database server, so shouldn’t they be able to forecast performance? When
a bunch of new users are going be added to a system, it’s the DBA who is quickly asked,
“That’s not going to be a problem, is it?” So DBAs need the ability to quickly forecast
performance. Low precision forecasting can be done very quickly and it is a great way to get
started forecasting Oracle performance.

This paper is a very brief introduction to forecasting Oracle performance. There is much
more I could write about performance forecasting. (That’s why I am writing a book entitled
Forecasting Oracle Performance due in early 2007.) Understanding the essentials of performance
forecasting will allow any DBA to quickly and confidently perform low precision forecasts.

In the first part of this paper, I’ll lay the foundational groundwork. I’ll then concentrate on
the CPU subsystem, then the IO subsystem. Finally, I’ll bring everything together and
discuss developing risk mitigating strategies and managing service levels. So here we go...

Foundational Concepts Using the CPU Subsystem

Computing systems are not simple. Our systems are multi-facetted; multi-threaded, multi-
tiered, multi-vendor, multi-system, and the list goes on and on. But to manage a system, one
must be able to embrace and manage that complexity and make it behave! We must find
ways to simplify without loosing the essence of the system.

While there are many metrics used when forecasting, when boiled down to the essentials,
there are only a few. The key metrics we want to forecast are utilization, queue length, and
response time. With only these three metrics, as a DBA you can perform all sorts of low
precision what-if scenarios.

Essential Performance Forecasting

 ©OraPub, Inc. 5

To derive the values, you essentially need 3 things:

• A few simple formulas
• Some basic operating system statistics
• Some basic Oracle statistics
Before you are inundated with the formulas, it’s important to understand some definitions
and recognize their symbols.

λ : Workload arrival rate. This is how many transactions enter the system per unit of time.
For example, 150 transactions each second or 150 trx/sec. When working with Oracle, there
are many possible statistics that can be used for the “transaction” arrival rate. Common
statistics gathered from v$sysstat are logical reads, block changes, physical writes, user calls, logons,
executes, user commits, and user rollbacks. You can also mix and match as your experience
increases. For this paper, we will simply use user calls.
S : Time to service one workload unit. This is known as the service time or service demand. It is
how long it takes the CPU to service a single transaction. For example, 1.5 seconds per
transaction or 1.5 sec/trx. The best way to get the value for Oracle systems is to simply
derive it.
U : Utilization or CPU busyness. It’s commonly displayed as a percentage and that’s how it
works in our formulas. For example, in the formula it should be something like 75% or 0.75,
but not 75. A simple way to gather CPU utilization is simply run sar –u 60 1. This will give
you the average CPU utilization over a 60 second period.
Q : Queue length. This is the number of transactions waiting to be serviced. This excludes
the number of transactions currently being serviced. (Most Unix systems report queue
length as the number of transactions waiting to be served plus the transactions currently
being serviced.) We will derive this value.
M : Number of CPUs. You can get this from the instance parameter cpu_count.

The CPU formulas for calculating averages, in MS-Excel format, are as follows:

U=(Sλ)/M (1)
R = S / (1 - U^M) (2)
Q = ( MU / (1 - U^M) ) – M (3)
R = S+ W (4)

Before we dive into real-life examples, let’s check these formulas out by doing some thought
experiments.
• Thought experiment 1. Using formula (1), if the utilization was 50% with 1 CPU, it
should be 25% with 2 CPUs. And that’s what the formula says. As you probably already
figured out, scalability is not taken into consideration.

Essential Performance Forecasting

 ©OraPub, Inc. 6

• Thought experiment 2. Using formula (1), if we increased the arrival rate, CPU
utilization would also increase.
• Thought experiment 3. Using formula (1), if we used faster CPUs, the service time
would decrease, then the utilization would also decrease.
• Thought experiment 4. Using formula (2), if the utilization increased, the
denominator would decrease, which would cause the response time to increase!
• Thought experiment 5. This one’s tricky, so take your time. Using formula (2), if the
number of CPUs increased, the denominator would increase, which would cause the
response time to decrease.
• Thought experiment 6. Using formula (3), if the utilization increased, the
denominator would decrease and the numerator would increase, which would cause the
queue length to increase.

Now that you have a feel and some trust in the formulas, let’s take a look at a real life
example.

Example 1
Let’s say for the last 60 seconds you gathered the average CPU utilization and the number of
user calls from a two CPU Linux box. You found the average utilization was 65% and
Oracle processed 750 user calls. The number of user calls each second is then 12.5 (i.e.,
750/60 = 12.5).

Therefore,

S = 0.104 sec/call ; U = ( S λ ) / M ; 0.650 = ( S * 12.500 ) / 2

R = 0.180 sec/call ; R = S / (1 - U^M); R = 0.104 / ( 1 – 0.65^2 )
Q = 0.251 calls ; Q = ( MU / (1 - U^M) ) – M ; Q = ( 2*0.65/(1-0.65^2) ) – 2

The only number that is immediately useful to us is the queue length. There is, on average,
less than one process waiting for CPU cycles. That’s OK for performance and for our users.
But there is some queuing occurring, so now would be a good idea to plan for the future!

The response time and service time calculations will become more useful when we
recalculate them using a different configuration or workload scenario. For example, let’s say
your workload is expected to increase 15% each quarter. How many quarters do we have
until response time significantly increases? For Example 2, we will see this demonstrated.

Example 2
Let’s suppose performance is currently acceptable, but the DBA has no idea how long the
situation is going to last. Assuming the worst case, workload will increase each quarter by
15%. Using the system configuration described in Example 1 and using our three basic
formulas, here is the situation quarter by quarter.

Essential Performance Forecasting

 ©OraPub, Inc. 7

Inputs Forecasts
Arrival Response Queue
Date Utilization
Rate Time Length

Current 12.50 0.65 0.18 0.25

+1 QTR 14.38 0.75 0.24 1.39
+2 QTR 16.53 0.86 0.40 4.59
+3 QTR 19.01 0.99 4.58 84.98
+4 QTR 21.86 1.14 -0.36 -9.78

Instantly, we recognize the utilization is forecasted to exceed 100% by the fourth quarter
(i.e., 114%). This results in an unstable system because the queue length will always increase.
The response goes negative, also indicating an unstable system.

The answer to the question, “When will the system run out of gas?” is something like,
“Sometime between the first and second quarter.” The answer is not the third quarter and
probably not even the second quarter! While the system is technically stable in the second
and third quarters, the response time has massively increased and by the third quarter there
are typically 85 processes waiting for CPU power! Let’s dig a little deeper.

Performance degradation occurs way before utilization reaches 100%. Our simple example
shows that at 75% utilization, response time has increased by 33% and there is usually over
one process waiting for CPU power. So while the system will technically function into the
3rd quarter, practically speaking it will not come close to meeting users expectations.
Based upon the above table, users are probably OK with the current performance. If you
have done a good job setting expectations, they may be OK with performance into the first
quarter. But once you get into the second quarter, with the utilization at 86%, the response
time more than doubling, and over four processes waiting for CPU power, not matter what
you do, your uses will be very, very unhappy.

The forecast precision using the method described above is very low. This is because of a
few reasons, some of which are; only one data sample was gathered, the forecasts were not
validated, the workload was not carefully characterized, and our model only considered the
CPU subsystem. When a more precise and robust forecast is required, a product like
HoriZone (horizone.orapub.com) is required. But many times a quick and low precision
forecast is all that is necessary. When this is the case, you can get a general idea of the
sizing, risk, and service level situation using the formulas outlined above.

Essential Performance Forecasting

 ©OraPub, Inc. 8

Forecasting IO Performance
Now that the foundation has been set, we are ready to consider the IO subsystem. Modern
IO subsystems can be extremely difficult to forecast. Just as with Oracle, there is batching,
caching, and a host of complex algorithms centered around optimizing performance and
increasing availability. While these features are great for performance, they make intricate
forecast models very complex. This may seem like a problem, but actually it’s not. I have
found that by keeping the level of detail and complexity at a consistently lower level (i.e., less
detail), overall system IO forecasts are typically more than adequate.

At a very basic level, an IO subsystem is modeled differently than a CPU subsystem. A CPU
subsystem routes all transactions into a single queue. All CPUs feed off of this single queue.
This is why, with a mature operating system, any one CPU should be just as busy as the next.
If you have had IO performance problems you know the situation is very different.

In contrast to a CPU subsystem, each IO device has its own queue. A transaction cannot
simply be routed to any IO device. It must go specifically where the data it needs resides or
where it has been told to write a specific piece of data. This is why each device needs its
own queue and why some IO queues are longer than others. This is also why balancing IO
between devices is still the number one IO subsystem bottleneck solution.

Today an IO device can mean just about anything. It could be a single physical disk, a disk
partition, a raid array, or some combination of these. The key when forecasting IO is
whatever you call a “device” is a device throughout the entire forecast. If a device is a 5 disk
raid array, then make sure whenever, for example, two devices are referenced, everyone
involved understands the two devices are actually two raid arrays, each with five physical
disks. If your device definition is consistent, you’ll avoid many problems.

The forecasting formulas we’ll use below assume the IO load is perfectly distributed across
all devices. While today’s IO subsystems do a fantastic job at distributing IO activity, many
DBAs do not. I have found that while an array’s disk activity is nearly perfectly balanced, the
activity from one array to the next may not be very well balanced. Hint: If an IO device is
not very active (utilization less than 5%), do not count it as a device. It is better to be
conservative then aggressive when forecasting.

Before you are inundated with formulas, it’s important to understand some definitions and
recognize their symbols as they relate to the IO subsystem.

λ : Workload arrival rate. This is how many transactions enter the system per unit of time.
For example, 150 transactions each second or 150 trx/sec. When working with Oracle, there
are many possible statistics that can be used for the “transaction” arrival rate. For simplicity
sake, this value will be derived and will refer to the general workload.

Essential Performance Forecasting

 ©OraPub, Inc. 9

S : Time to service one workload unit. This is known as the service time or service demand. It is
how long it takes a device to service a single transaction. For example, 1.5 milliseconds per
transaction or 1.5 ms/trx. For simplicity sake, this value will be derived.
U : Utilization or device busyness. Commonly shown as a percentage and that’s how it
works in our formulas. For example, in the formula it should be something like 75% or 0.75,
but not 75. This value can be gathered from both sar or iostat.
M : Number of devices. You can get this from the sar or iostat report. Be careful not to
count both a disk and a disk’s partitions, resulting in a double count. For example, if your
sar or iostat report devices, /dev/sda, /dev/sda2, and /dev/sda3, you actually have only
one device, not three. The single device, /dev/sda just has two partitions defined.
W : Wait time or more commonly called queue time. This is how long a transaction must
wait before it begins to be serviced. For simplicity sake, this value will be derived.
R : Response time. This is how long it takes for a single transaction to complete. This
includes both the service time and any queue/wait time. This will be gathered from the sar
and iostat command (details below).

The IO formulas for calculating averages are as follows:

U=(Sλ)/M (1)
R = S / (1 - U) (2)
R=S+W (3)

Before we dive into real-life examples, let’s check these formulas out by doing some thought
experiments.
• Thought experiment 1. Using formula (1), if the arrival rate doubles, so will the
utilization.
• Thought experiment 2. Using formula (1), if we used slower disks, the service time
(S) would increase, and therefore the utilization would also increase.
• Thought experiment 3. Using formula (2), if we used faster devices, the service time
would decrease, then the response time would also decrease.
• Thought experiment 4. Using formula (2), if the device utilization decreased, the
denominator would increase, which would cause the response time to decrease.
• Thought experiment 5. Using formula (3), if we used a faster devices, service time
would decrease, then the response time would also decrease.

While gathering IO subsystem data is simple, the actual meaning of the data and how to
apply it to our formulas is not so trivial. One approach, which is fine for low precision
forecasting like this, is to gather only the response time, the utilization, and the number of
devices. From these values, we can derive the arrival rate and service time.

Essential Performance Forecasting

©OraPub, Inc. 10

Gathering device utilization is very simple as both sar –d and iostat clearly label these
columns. However, gathering response time is not that simple. What iostat labels as service
time is more appropriately the response time. Response time from sar –d is what you would
expect, the service time plus the wait time. [For details, see System Performance Tuning by
Musumeci and Loukides]

There are many different ways we can forecast IO subsystem activity. We could forecast at
the device level or perhaps at the summary level. While detail level forecasting provides a
plethora of numerical data, forecasting at the summary level allows us to easily communicate
different configuration scenarios both numerically and graphically. For this paper, I will
present one way to consolidate all devices into a single representative device.

Capacity Planners like to call this process of consolidating or summarizing aggregation. While
there are many ways to aggregate, the better the aggregations, the more precise and reliable
your forecasts will be. For this example, our aggregation objective is to derive a single
service time representing all devices and also the total system arrival rate. The total system
arrival rate is trivial; it’s just the sum of all the arrivals. Based upon the table below, the total
arrival rate is 0.34 trx/ms.

To aggregate the service time, we should weight the average device’s service time by its
arrival rate. But for simplicity and space, we will simply use the standard average service
time across all devices. Based upon the table below, the average service time is 4.84 ms/trx.

Inputs Outputs
Response Service Arrival
Device Utilizaion
Time Time Rate

sd0 5.4 0.15 4.59 0.03

sd1 10.6 0.45 5.83 0.08
sd2 2.1 0.19 1.70 0.11
sd3 8.9 0.25 6.68 0.04
sd4 9.8 0.45 5.39 0.08
4.84 0.34

Armed with the number of devices 5, the average service time 4.84 ms, and the system
arrival rate of 0.34 trx/ms, we are ready to forecast!

Example 1
Let’s say the IO workload is expected to increase 20% each quarter and you need to now
when the IO subsystem will need to be upgraded. To answer the classic question, “When
will we run out of gas?” we will forecast the average queue/wait time, response time, and
utilization. The table below shows the raw forecast values.

Essential Performance Forecasting

©OraPub, Inc. 11

Inputs Forecasts
Arrival Arrival No of Service Response Wait
Utilization
Rate Rate Devices Time Time Time

current 0.34 5 4.84 0.33 7.23 2.40

+20% 0.41 5 4.84 0.40 8.03 3.19
+40% 0.49 5 4.84 0.48 9.25 4.41
+60% 0.59 5 4.84 0.57 11.32 6.48
+80% 0.71 5 4.84 0.69 15.46 10.62
+100% 0.85 5 4.84 0.82 27.57 22.73
+120% 1.02 5 4.84 0.99 457.21 452.37

Here’s an example of the calculations with the arrival rate increased by 80% (arrival rate 0.71
trx/ms).

U = ( S λ ) / M = ( 4.84*0.71 ) / 5 = 0.69
R = S / (1 - U) = 4.84 / ( 1 – 0.69 ) = 15.46
W = R – S = 15.46 – 4.84 = 10.62

So what’s the answer to our question? Technically speaking the system will operate with a
120% workload increase. But stating that in front of management is what I would call a
“career decision.” Looking closely at the forecasted utilization, the wait time, and the
response time, you can see that once the utilization goes over 57%, the wait time skyrockets!
Take a look at the resulting classic response time graph below.

Essential Performance Forecasting

©OraPub, Inc. 12

Again, what’s the answer to our question? Without considering the users current
performance experience (which should always be considered) and without an understanding
of the impact of poor performance (Will the business significantly suffer?), performance
will significantly degrade when the workload increase hits around 60% (arrival rate 0.59 trx/
ms). Since the workload increases around 20% each quarter, the system will probably not
provide satisfactory performance nine months from now…unless something changes.

Managing Risk Through Forecasting Performance

Suppose you identified there exists significant risk in one of your production systems. What
would management say if that’s all you told them? You identified risk exists, you identified it
is the CPU subsystem, but you offered no solution. That’s another one of those career
decisions I mentioned earlier. When you develop possible solutions to expected risk, you are
developing risk mitigating strategies and are helping to meet service levels. And that is when the
real value of forecasting becomes apparent.

If management knows there exists significant risk, where the risk exists, when the risk will
occur, and is provided with multiple ways to mitigate the risk, then wow!, you have earned
your money that day. Management loves this stuff because they care about risk and meeting
service levels!

Risk: A Four Letter Word

Living on the technological edge is something most DBAs (especially the younger ones)
crave. And it’s also what most managers (especially the older ones) relentlessly manage. Risk
is one of those four letter words we don’t talk about much in front of management. Why?
Because we know they will, they must, they absolutely must understand; if there is risk, if it
is significant, where is resides, when it will occur, and what can be done about it. If a
manager doesn’t care about this stuff, they won’t last long.

While forecasting performance can be a lot of fun, if it is to have any company value, it is in
managing risk and meeting service levels. Managing risk is serious business and management
loves to understand risk and mitigate it. To managers, it’s the natural high. While DBAs get
their kicks by improving performance through really cool technology and techniques, strong
managers want a better understanding of risk.

If you can convince your management that forecasting performance will help them better
manage risk and meet service levels, you’ve got a great career ahead of you.

Risk Flavors
Like ice-cream, risk comes in different flavors. Fortunately, we can boil it down to only two
flavors; the likelihood of the risk event occurring and the impact of that risk event. The real
or true “risk” is the product of the two.

For example, the likelihood of a Windows system freezing within the next 30 days is highly
likely, say 90%. But the impact of the system freezing is not a big deal because you just

Essential Performance Forecasting

©OraPub, Inc. 13

reboot the box. So I would rate the risk impact at, say 25%. Therefore, the real risk of a
windows system can be measured as 2.25%. Getting significantly more serious, the
likelihood of a bridge breaking apart is say 0.5%, but the impact of this event is say, 90%.
So the real risk if 45%! Just because something is risky, or more accurately more likely to
happen, doesn’t mean its a big deal and requires our attention.

Hitting a little closer to home, if the key production system is down, not only are you in
trouble, but so is your company. So even though it is unlikely, the real risk is something we
must understand. Managers are trained and compensated by dealing with risk effectively.
Once you understand that forecasting performance meets a significant management need,
your whole approach to forecasting will change forever. It’s not just a game or an intellectual
challenge, it’s meeting a deep need that your company desperately must satisfy if it is to exist.

Developing Risk Mitigating Strategies

So how do you develop these risk mitigating strategies? Honestly, it’s more than this paper
can provide and it’s also a combination of science, art, experience, and understanding your
environment. Keep in mind; it’s typically not our decision to pick the final solution. There
are many factors and constraints we, either intentionally or unintentionally, may not be aware
of. Besides the obvious budget constraint, there could be timing, availability, political,
purchasing, legal, upgrades, patches, and expected new hardware. The list goes on and on.
So unless you are tasked with specifying the best answer, don’t. Providing your management
with choices and explaining the costs and benefits of those choices from your perspective, is
extremely valuable to your company.

To get started, first identify that significant risk exists, where that risk resides, and when it is
likely to occur. Suppose during the next quarter close the system workload is expected to
increase 30%. Using the CPU and the IO subsystems mentioned above, there exists
significant risk of very poor response time. More specifically, it’s the CPU subsystem that’s
at risk. At a 40% workload increase, the IO subsystem is only averaging 48% utilization and
response time is fairly steady. But the CPU subsystem, with a 30% workload increase (+2
QTR in the table), is forecasted to average 86% utilization, with an average queue length of
4.6, and the change in response time nearly doubled. So obviously significant risk exists, it’s
the CPU subsystem, and it will occur during the quarter-end close.

The next step is to develop multiple strategies to mitigate the identified risk. I have found
that by framing strategies around three basic options/strategies, I’m able to better
communicate my findings. The three basic options are; tune, buy, and balance. For our
example, that would be tune the application and Oracle, buy more CPU capacity, and better
balance the existing workload. We’ll take a look at all three.

Tuning the Application and Oracle

When tuning occurs, the workload applied to the operating system is effectively reduced. So
while the original workload may increase by 30%, if we tune our application by 15%, the net
result is only a 15% workload increase. In our example, that would reduce the forecasted
CPU utilization down to around 75%. So while the system will be busy, it should be OK.

Essential Performance Forecasting

©OraPub, Inc. 14

One benefit with reducing the workload by tuning is the performance gain typically lasts
much longer in contrast to increasing the CPU capacity.

Buy More CPU Capacity

This option has three flavors; more CPUs, faster CPUs, or more and faster CPUs. The
discussion of which flavor is better, while fascinating, is out of scope for this paper. I’ll just
say that generally, either faster or more is better. And of course, more faster CPUs is
fantastic! Let’s take a look at both the more and the faster situations.

Suppose the vendor is pitching new CPUs which are 20% faster. Increasing CPU speed
reduces CPU service time, so the service time will be reduced by 20%. The number of
CPUs remains the same and the workload is set to the expected 30% increase. The math
looks like this:

M = 2 CPUs
λ = 12.50 * ( 1 + 0.30) = 16.25 trx/sec
S = 0.104 * (1 - 0.20) = 0.0832 sec/trx
U = ( S λ ) / M ; 0.676 = ( 0.0832 * 16.25 ) / 2
R = 0.153 sec/call ; R = S / (1 - U^M); R = 0.0832 / ( 1 – 0.676^2 )

Switching the old CPUs out and replacing them with the new faster CPUs along with the
expected workload increase, our forecast predicts the utilization will only slightly increase to
68% (from 65%) and the response time will actually decrease to 0.153 sec/call (from 0.180).
That’s good news as we have just discovered a risk mitigating strategy. Management may not
like this solution for any number of reasons, but it is a valid strategy and should be
presented.

Now let’s take a look at increasing the number of CPUs from two to four. The same CPUs
are used, so their service time does not change. The workload is set to the 30% increase.
The math looks like this:

M = 4 CPUs
λ = 12.50 * ( 1 + 0.30) = 16.25 trx/sec
S = 0.104 sec/trx
U = ( S λ ) / M ; 0.4225 = ( 0.104 * 16.25 ) / 4
R = 0.1074 sec/call ; R = S / (1 - U^M); R = 0.104 / ( 1 – 0.4225^4 )

Essential Performance Forecasting

©OraPub, Inc. 15

Using four CPUs instead of two along with the expected workload increase, the forecast
predicts the utilization will significantly drop to 42% and the response time will decrease to
0.1074 sec/call. So again, we have discovered a risk mitigating strategy.

So how about using more faster CPUs? I’ll leave that as “an exercise for the reader.” But
which of the two options presented are better? It depends on many factors, cost just being
one of them. Unless you are privy to much more information and are expected to make a
single recommendation, my advice is to propose multiple solutions. Increasing CPU power
by using faster or more CPUs are examples of two general solutions.

Balancing Existing Workload

I’ve never been to a client where their workload was perfectly balanced. There are always
peaks and valleys. The valleys, represent an opportunity. While this may not be viewed as
capacity planning, in my mind, when you’re in a situation like this, you must mention this
option.

Most large Oracle systems push a tremendous amount of batch work through there system.
Very carefully scheduling and prioritizing typically yields a massive workload decrease during
peak processing time. To get started, determine what batch processes are running during the
peak time. In our example, that would be quarter end processing. Work with the application
system administrators and the department heads (e.g., GL, AP, etc.) and try to spread out or
reduce the activity during those peak hours. Perhaps there is also an Adhoc reporting system.
Can that be disabled just during peak quarter end processing? Using our example, if you can
reduce the batch workload by 30% during during quarter end processing, you have
effectively neutralized the expected workload increase! And without spending time tuning
SQL or Oracle, and without any additional hardware costs (and let’s not forget about
Oracle’s CPU based pricing...).

Management needs to know more than the existence of risk. They need to know what is at
risk, when the risk will occur, and what can be done about the risk. What is needed are
multiple solutions to eradicate the identified problem. Presenting one solution or strategy is
typically not good enough. Management wants multiple options and needs to understand
the aspects of each. Developing risk-mitigating strategies will provide management with
part of what they need to make better decisions.

Conclusion
Most DBAs are shocked by how easy it can be to forecast Oracle performance. But what
people tend to forget is that while it can be easy, the precision is very low. To produce a high
precision forecast requires a lot of work; automation, detailed and volumes of workload
gathered and characterized, strong forecast models, and the ability to very easily develop
complex scenarios. That’s hard work, but then that’s why there are products to help you in
this process. But remember, many times a low precision forecast is all that’s needed. It
would be foolish to spend thousands of dollars in time and/or products if you just needed a
low precision forecast.

Essential Performance Forecasting

©OraPub, Inc. 16

So when your boss just happens to stop by at 4:30pm on Friday and says, “Hey ah... We’re
going to need to add all the users from that new acquisition to our existing system on
Monday. That’s not going to be a problem is it?” you can say, “Just give me a few minutes
and I’ll let you know if we’re at risk.” ...a career opportunity snagged!

About The Author

As a recognized Oracle server authority and quoted as being "An Oracle performance
philosopher who has a special place in history of Oracle performance management," Mr.
Shallahamer brings his unique experiences to many as a keynote speaker, a sought after
teacher, a researcher and publisher for improving Oracle performance management, and also
the founder of the grid computing company, BigBlueRiver.

Mr. Shallahamer spent nine years at Oracle Corporation personally impacting literally
hundreds of consultants, companies, database administrators, performance specialists, and
capacity planners throughout the world. He left Oracle in 1998 to start OraPub, Inc. a
company focusing on "Doing and helping others Do" both reactive and proactive Oracle
performance management. He has personally trained over 1000 DBAs on five continents in
thirteen countries. Mr. Shallahamer is also the key designer and engineer behind HoriZone,
OraPub’s performance forecasting product.

When Mr. Shallahamer is not working on Oracle performance management, he is fly fishing,
praying, backpacking, playing guitar, or just relaxing around a fire.

Inquires
To inquire about OraPub’s Forecasting Oracle Performance class, please visit http://
www.orapub.com/fop .
To inquire about speaking engagements, please visit http://resources.orapub.com/
RequestSpeaker.asp .
To inquire about OraPub’s performance forecasting product, HoriZone, please visit http://
www.horizone.orapub.com .

References
[BBR] BigBlueRiver, Inc., Massive Grid Computing Power—For the Rest of Us., http://
www.bigblueriver.com
[HZ] HoriZone: Managing Risk Through Forecasting Oracle Performance (product). OraPub, Inc.,
http://www.horizone.orapub.com
[FOP] “Forecasting Oracle Performance” Training Class (1998-). OraPub, Inc., http://
www.orapub.com/fop
[OSM] “OraPub System Monitor (OSM)” tool kit (1998-). OraPub, Inc., http://
www.orapub.com

Essential Performance Forecasting

©OraPub, Inc. 17

[RATIO] The Ratio Modeling Technique – Quickly Performing Low Precision Forecasts, (2003).
OraPub, Inc., http://www.orapub.com
[RESP] Responsibly Forecasting Oracle Performance, (2003) OraPub, Inc. http://www.orapub.com
[RPM] “Advanced Reactive Performance Management For Oracle Based Systems” Training
Class (1998-). OraPub, Inc., http://www.orapub.com/rpm[TRIAGE] Shallahamer, C.;
Oracle Performance Triage: Stop the Bleeding! OraPub, Inc. 2000. http://
www.orapub.com
[WEA] Shallahamer, C.; Direct Contention Identification Using Oracle’s Session Wait
Event Views. OraPub, Inc. 1997-. http://www.orapub.com

Essential Performance Forecasting