Script - Demo - Using Oracle EM Express for

Performance Tuning

Hi everyone and welcome to this lecture. This lecture is not a

concepts lecture. It is not a practice lecture either. This lecture is a
demonstration lecture.

In this lecture we will demonstrate Using Oracle EM Express for

Performance Tuning.

In my case, I opened the EM Express from the Internet browser.

Alternatively, you can open it form the FireFox browser installed in
the VM appliance.

[next]

We have a SQL*Plus session connected to the database as soe

[next]

We also have Swingbench sessions running with 10 users.

[next]

In the home page of the EM Express, most of the sections and

graphs are related to performance tuning.

By default, the data within those sections get refreshed once every
one minute. You can control the refresh frequency period from the
drop list in the upper right corner of the EM Express window.

[next after finishing from selecting from the drop list]

Let's go through each section and have a look at their contents.

[zoom]

Status section displays general information about the database

system. Like up time, database name and version, platform name,
and whether the archiving log is enabled or not.

Nothing special over here... just general information about the

database.

[zoom]

The next section is the performance section. It has two tabs

"Activity Class" and "Services".

Each tab contains a chart. In all the charts of the EM express, they
present their statistics using Stacked Column charts.

With this type of charts, the values are represented using attached
colored bars. Each bar is read by its thinkness. The thicker the
bar, the more is its value.

We mean by the thickness the distance between the graph top

level and its bottom level. It is the bottom level of the graph, not
the time Axe.

Unfortunately, the charts in the performance section are not really

self-descriptive. Please pay your attention with me over here
because it really needs some concentration to understand how to
read the charts.
The chart vertical axe is about the CPUs in the system. When the
database is under slight workload, the maximum value of that axe
is the total number of CPUs in the system. In my case, I have two
CPUs, therefore, the maximum value of the vertical axe is 2.

There is always a red line at that limit. As the workload increases

at the database, the maximum number of the vertical axe may
increase, but the red line always points at the maximum number
of the available CPUs.

The horizontal axe is a time axe for the past hour. So, this chart
displays the activity workload for only the past one hour. If you
need to analyze performance data that is older than one hour ago,
you need to change this view. You will see how later.

Now, let's have a look at the graphs within this chart.

[shift]

This chart has basically three graphs: the green graph, which
represents the CPU consumption from all the sessions...

the blue graph, which represent the I/O activities from all the
sessions...

and the brown graph, which represents the total wait time by all
the sessions.

The total of the CPU consumption, I/O processing, and wait time
levels represent the entire processing time... which means the
total of their percentage values is one hundred.

The CPU consumption graph represents the amount of CPU

consumption time per minute. This means this graph will never
exceed the red line. And this goes along with our understanding on
the database CPU consumption. DB CPU never exceeds the total
number of CPUs and CPU cores.

The blue graph is the I/O activity. In my case, the blue graph
height is very tiny compared to the CPU height... which means it
represents a small fraction of the total database activity. I will
show you soon how to precisely measure its overhead level.

The third graph is the total wait graph. So, in my case, the wait
activity is nearly the same or slightly more than the CPU activity.

When the system is heavily loaded, the total wait time per minute
may become more than the CPU load. In this case, the wait graph
may exceed the red line... and in this case, the maximum value of
the vertical axe increases accordingly.

So, in conclusion, what we get from this chart is the total database
CPU load and the total database wait time per minute in the past
hour.

This is similar to what we get from the Time Model. Over there, the
total DB time is the summation of the DB CPU and the total Wait
time. What is added over here is the total I/O activity time.

Let's see how we can precisely measure those activities.

[after zoom out]

Let me allow the load to progress a little bit.

[after zoom in]

Move the mouse cursor close to the edge of a graph at the
required point in time...

[cursor on the graph edge]

a tooltip box appears with the measure of that graph.

In my case, at 10:44 pm, the total CPU load is 0.43 seconds. This
represents 52.13% of the total DB time.

[cursor moved to wait graph]

When I moved the cursor to the top of the wait time graph, it
reported that the total wait time is 0.30 seconds, which represents
46.78% of the total DB time.

Now, if I add the total CPU percentage to the total wait time
percentage, the result will be 99%. The remaining 1% must be the
total I/O processing time at that specific time.

[zoom out and stop]

Let's stop Swingbench and start it again with 50 users.

[after going through shading]

The wait graph rapidly increased.. and because it reached to a

level higher than the maximum number of CPUs, the vertical axe
scale changed as well... so that it can display the total wait time.

[cursor on the graph]

At the moment, the wait time is 7.51 seconds...

[cursor on the graph]

and the CPU time is 1.58 seconds. Obviously this is not a very
healthy situation.

In summary, this chart provides a quick way to judge the entire

database performance. It is very similar to the time model. The
only difference is that it includes the I/O time in its calculation.

I will stop the Swingbench load and restart it using 10 users.

[EM home page]

The next section is the "Incidents" section. It displays the incidents

reported in the database in the past 24 hours.

You may need to have a look at this section when you're

diagnosing a performance issue... it might be linked to a recent
incident.

“Running Jobs” section displays the currently running jobs in the

database. This also could be useful in troubleshooting performance
issues. Sometimes, the system is slow because of a running
background job that consumes much of the system resource.

The next section is titled as “resources”. This section displays the

system resources... which are the CPU, memory and Data Storage.
It also displays an Active Sessions summary graph.

The CPU graph displays the percentage of CPU time used by the
database instance and other processes during the last minute.
If you hover the mouse cursor to the top of the graph...

[next]

... it will display the value of the bar... and how the total CPU
consumption is divided by the foreground and background
processes.

In my case, the total CPU load is 15%

Let's run a piece of code that consumes a lot of CPU power and
see how it may affect the graph.

[next after displaying SQL*Plus code]

This code purely consumes CPU processing because it only

performs mathematical operations.. no I/O in it.

declare

[next when displaying the EM home page]

I will wait for a couple of minutes to see the code impact on the
graph.

[after going through shade]

In my case, after running that code, the bar jumped to nearly

60%. It also affected the Activity Class chart. The CPU graph
increased without increasing the total wait time. This is expected
because our code is purely a CPU processing.
The next chart is the "Active Sessions" chart. This chart displays
the average number of active sessions during the last minute,
broken out by wait, user I/O, and CPU.

Just to refresh your memory, an active session is a session that is

waiting for an event that does not belong to the Idle wait class.

If you examine this chart, it is actually the same as the last

reading of the "Activity Class" chart.

Let's check the chart's readings now.

If you hover the mouse cursor on the top of the CPU graph in the
“Active Sessions” chart...

[next]

... the CPU value is 1.19. This is 67.61% of the total processing
time in this chart. Now, hover the mouse cursor in the last reading
of the CPU graph in the Activity Class chart.

[next]

It has the same value... which is 1.19. The percentage is slightly

different in this chart because IO is taken into its consideration.

In conclusion, the "Active Sessions" chart displays the last reading

of the activity class chart.

[next after leaving the chart]

The next char is the Memory chart. This chart tells about itself. It
displays the size of each memory component in the SGA. If you
hover the mouse pointer on any graph bar, it displays the size of
that component.

[ hover the mouse pointer on all the parts]

You can also hover the mouse pointer on the legend boxes as well.

[ hover the mouse pointer on all the legend boxes ]

The next chart displays the database data file types and their
sizes. Again, if you hover the mouse pointer on any graph bar, the
size of the file type is displayed.

The last chart in the EM Express home page is the SQL Monitor
chart. This section displays up to maximum 20 monitored SQL
statements.

As we learnt in the “Monitoring SQL in real time” lecture, Oracle by

default automatically monitors any SQL statement that consumes
5 seconds or more of the CPU processing time or I/O activities.

The chart displays for each monitored statement the duration of

executing the statement, the statement ID and the distribution of
its activities on the DB time parts.
As we saw, from the EM Express home page, we can measure the
performance stress on the entire database.

If we need to go deeper into the system performance statistics, we

should go to the Performance Hub page.

To go to it, click on the Performance menu and from there select

Performance Hub menu item.

[next]

In the Performance Hub page, you can view performance data for
a specified time period.

From this page, you can select from viewing real-time data or
historical data.

In real-time mode, which is the default mode, performance data is

retrieved from in-memory views and for the last hour.

In historical mode, data can be retrieved for the period that is

older than one hour ago. Performance historical data is retrieved
from the AWR snapshots.

Because real-time data is obtained from the memory V$ views, the

real-time data is generally more accurate than the data retrieved
from the AWR views.

In the timeline bar, we can see the timepicker. Use it to select any
time range from within this time line. The default selection is the
past 5 minutes.
Click on the middle of the window and pull the window over to an
interesting time period of activity.

[next]

Use the handles on the left and right edges of the timepicker
window to change the window time period length.

[next]

Notice the grayed areas change in the charts to match the window
slider.

Let's have a deeper look into the the performance hub page
components.

In the performance hub page we've got 5 tabs, named as

Summary, Activity, Workload, Monitored SQL, and ADDM.

The summary tab has four charts... they are named as Host
Runnable Processes, Memory, Active Sessions, and I/O.

In all the charts in this tab, you cannot drill down into their details.
This tab displays only summary statistics. They help you to know if
there is an issue that requires diagnosis.
The Host Runnable Processes chart displays the Load Average
and the CPU processing.

In the home page, we've seen the total instance CPU overload...
over here, the CPU load is divided by the process types:
foreground CPU, background CPU, and other host CPU.

[next]

The green graph shows the Foreground CPU usage per second.

[next]

The orange line is the total number of CPU cores in the system.

[next]

The red graph represents the total Load Average. This represents
everything: the DB CPU and the Wait time. I am not sure if the I/O
processing is counted in this graph or not.

[next when the cursor disappears]

The next chart is the memory chart. It displays the SGA

components in the database and their sizes. The vertical axe is
scaled up to the maximum database SGA size.

[next]

If you mark the check box "Show host memory", the chart axe will
be scaled up to the maximum memory size in the host machine.

The nice thing about this chart, it shows the history of SGA
component sizes along the past one hour period. If you notice a
large jump in one area, it may trigger you to perform more
investigation.

The next chart is the Active Sessions chart. This chart is similar
to the Active Sessions chart that we saw in the home page. It
displays the current load on the database and how it is distributed
between the activity types and waits.

However, this chart provides more details that the one in the home
page. This chart allows us to apply a simple filter.

[next]

The first drop list allows you to change the view of the graph to
show the activity type or the services.

[next]

The second drop list allows you to display the statistics for the
foreground processes or foreground and background processes.

The load is divided on activity types. If the value of an activity

type is very small or zero along the entire graph time period, it
doesn't appear in the chart and not in the legend either.

[next leave the drop list]

The next chart displays statistics about I/O activities. This chart is
useful to measure the load and efficiency of the database storage
system.
By default, it displays its figures by the number of requests per
second. You can change this measurement unit using the first drop
list in the chart.

[next]

You can make the measurement unit to throughput or latency.

Throughput is measured in MB/s. Latency is measured in ms.

[next]

The breakdown drop list can be changed to i/o type, i/o function or
i/o consumer group.

[change the second drop list to the other two options]

Let’s go to the Activity tab now.

[click on activity tab]

This tab has three charts. The first chart is similar to the active
sessions chart in the summary tab.

By default, the other two charts display the top SQL statements
and the top sessions respectively for the selected time period.

But for all those three charts, you can change the chart breakdown
data. This can be done by the drop list that is associated with each
chart.

Use the first chart to figure out which area requires your attention.
Use the other two charts to obtain more details about the area that
you're troubleshooting.
[click on the first drop list and select Top Dimensions]

I can change the chart to display the top specific dimensions. You
can select from the following dimensions: Wait Class, Wait event,
Instances, services, modules, actions, user sessions, and SQL ID.

For example, I will change the data of the top chart to wait events.
It’s common to look at the top wait events in performance
troubleshooting investigations.

[next]

Now I will change the second graph to display the top PL/SQL,,
probably because I know the culprit code is a PL/SQL code.

[next]

The top PL/SQL executions are listed now.

[next]

Let me set it back to SQL again.

[next]

If you hover the mouse pointer on a SQL ID, it displays a tooltip of

the SQL statement of the highlighted SQL ID.

If you click on the SQL ID link,....

[next]
... you will see a page that provides full details and statistics about
the selected SQL statement. Including the execution plans used to
execute the statements.

Observe that you cannot delete the SQL ID filter. This is because
all the tabs now describe activity for that specific SQL ID.

[click on the activity tab]

This is the same charts as the ones you see in the Performance
Hub page.. but their contents are filtered by only the select
statement.

[click on the Execution Statistics tab]

Over here, you see the execution plan of the selected statement.
The execution plan is displayed in a graphical layout... which
makes it easy for you to read its operations. Viewing SQL
statement execution plans in this view is much easier than viewing
them using the command line SQL*plus utility.

[click on the Monitored SQL tab]

If the filtered statement is monitored, you will see it displayed in

this table.
[click on the Plan Control tab]

Under the Plan Control tab, you will see the components that are
related to the optimizer execution plans... like SQL Profiles and
Patches and SQL Plan Baselines. Those components are part of
SQL tuning topic.

Let's go back to the performance hub page.

[ Performance hub page

Let's go again to the Activity tab

[ Activity tab ]

Let's select the top session that was responsible for the load in the
selected period.

[next]

A page is displayed with the details of the selected session.

You will see sections that describe the connection to server, client
process, activity, and monitored SQL statement that is being
executed by the session.
[click on activity tab]

Under the activity tab, you will see the same charts that you saw
in the Performance Hub page... but their contents are filtered by
only the selected session.

[click on Metrics]

Under the Metrics tab, you will see metrics figures for the selected
sessions.

Over here, we see the metrics on CPU, memory, I/O throughput,

and I/O requests.

Let's go back to the performance hub page.

[ Performance hub pag ]

Let's go to the Workload tab

[workload tab]

As its name indicated, this tab displays statistics that describe the
workload on the database.

[click on the first drop list just to display its contents]

The first chart in the page displays workload profile. This chart
could display the workload statistics for the User Calls, Parse calls,
Redo Size, and SQL*Net.
Under the "user calls", you can get important performance metrics
like the number of user calls per second, number of executions per
second, and number of transactions per second.

[next hover on the graph]

As is the case with all the charts in EM Express, if you hover the
mouse pointer on the graph line, it displays its value at that point.

Observe those figures are not absolute statistics since last instance
startup. They are metrics... which mean specific statistics per
second.

[display the second drop list contents]

The second chart allows you to display three statistics: logon rate,
current logons, Open Cursors.

Logon Rate displays how many logons to the database occurred

per second in the last minute.

[select Current Logons from the drop list]

Current Logons chart displays the total number of sessions

connected to the database... including the Oracle background
processes.

[select Open Cursors from the drop list]

Open Cursors chart displays the total number of open cursors in

the database in the last minute.
Allow me to move the time picker back to the load period.

[next]

Now let’s have a look at the monitored SQL statements.

[next]

Over here, you will see a list of the monitored SQL statements. We
have seen in an earlier lecture how to navigate into the monitored
SQL statements in EM Express. Allow yourself to refresh your
memory about it, if you want to.

[time picker is moved and ADDM appears]

The last tab in the Performance Hub page is the ADDM.

Again, we have seen in an earlier lecture how to navigate into the

ADDM from EM Express. We have used EM Express to list the
ADDM findings and recommendations.

So far, we've seen how the EM Express displays the performance

statistics for the last hour.

Let's see how EM Express presents the history performance

statistics that are older than one hour ago.

These statistics are obtained from the AWR data dictionary views,
not from the V$ views. That's why the view is a little bit different
from the real time panels that we've seen so far.

To see the performance statistics history, click on the "Select Time

Period" button [do it]. Select "Historical - All"
[do it].

Observe that the Time Picker ribbon scale has changed. You can go
through the history of the performance statistics.

In addition to that, observe that the tabs have changed. We can

see more tabs in the page than the tabs that we've seen when the
real time statistics were displayed. We have over here Resources
and System Statistics tabs.

[next click on summary]

Moreover, the Summary tab displays different charts. There is a

chart that displays wait event statistics.

Again, as you move the time picker along the time scale, the
charts are automatically updated.

[do it]

[select from Wait Event drop list]

The "Wait Events" chart allows to select which Wait Class you want
to display in the chart.

In addition to that, you can select which metrics the chart should
display.

[do it]

[click on the Activity tab]

The Activity tab contains charts that are similar to the charts in the
Activity tab when displaying real-time statistics.
[click on the first drop list -> Top Dimensions]

Again, you can modify the chart to display the top list of
dimensions based on your requirement.

[click on Workload tab]

The Workload tab contains the same charts: Workload Profile,

Sessions, and Top SQL.

[click on Monitored SQL tab]

Monitored SQL tab contains list of the monitored SQL statements,

if there is any.

[click on Database Time tab]

Database Time tab displays the Time Model chart. You can select
to display the percentage DB Time values of the absolute DB Time
values.

From this chart, we can know the changes on the time model
across the AWR time history.

[click on Resources Tab]

Resources Tab contains two charts. The first one allows you to
display the per cent CPU or the Load. Per cent CPU values are
broken down to System CPU, W I O, and User CPU.

The other chart displays the I/O statistics.

[click on System Statistics tab]

System Statistics tab displays tow charts. Each chart can be set to
display specific system statistics.

[display the first drop list in the first chart]

You can select from the wide range of system statistics. To me,
this is more convenient that listing those statistics from the V$
view because the statistics are grouped by their functions.

[when the list is left]

The second chart allows you to display from the same list of
statistics.

Having two charts that are configurable to display system statistics

allows you to compare between two specific system statistics, if
you want to.

When the history performance statistics are displayed, you can

generate an AWR report between the last two snapshots.

And that's it for demonstrating the Performance tuning capabilities

in the EM Express.

As we saw, EM Express provides to us most of the database

performance tuning tools under one user friendly umbrella.

I urge you to get yourself familiar with it. Try to apply some
testing stress on the VM database: CPU stress, I/O stress, blocking
sessions, SQL statement bottlenecks, latches and so on. Then try
troubleshooting the bottleneck using EM Express.

Thanks guys for staying with me. See you in the next lecture.