Oracle Database Administration for Microsoft SQL Server DBAs part 26 ppsx

Depending on the type of database that is running, several of these
parameters may be useful for tuning, including the following:
■
The STAR_TRANSFORMATION_ENABLED parameter would probably
be set to TRUE if the database has more of a data warehousing
purpose, rather than is just used as a transactional database.
■
The OPTIMIZER_INDEX_COST_ADJ parameter can be adjusted to
make the optimizer more willing to use indexes. The setting is a
percentage to adjust the cost of using indexes in the query plans. For
example, reducing the value of this parameter from 100 to 50 would
cut the cost of using an index in half.
■
The OPTIMIZER_MODE parameter chooses the approach for the
database instance. FIRST_ROWS will find a best plan to return the
first set of rows faster. ALL_ROWS will develop the plan to return all
of the values of the query in the session.
232
Oracle Database Administration for Microsoft SQL Server DBAs
FIGURE 8-5.
Optimizer parameters
Adjusting the parameters can help change how the optimizer behaves,
and can also give the database instance more resources, especially when
increasing the memory parameters to allocate more memory to the system.
Some of the default settings might be valid for simple database environments.
The type of database environment and how it is being used in general should
be considered when adjusting these parameters. Additional information
from the snapshot reports and advisors that run in the database can help
determine the appropriate settings and configurations for some of the
parameters.
Automatic Workload Repository

The Automatic Workload Repository (AWR) contains significant information
that can be helpful when it comes to tuning the database environment. The
database takes regular snapshots to get information about the database
settings and the workload in the environment, and stores them in the AWR
metadata tables (WRM$_) and historical statistics tables (WRH$_).
In Oracle Database 11
g
, these reports and information are part of the
Oracle Diagnostic Pack, which provides automated gathering of the
information and ways to pull the information out of the workload and
history tables for review and evaluation of performance issues. You can also
create baseline templates to be able to compare information. Baselines are
especially useful when you find that the database is not performing as it did
before, and you need to understand what might have changed.
AWR Reports
AWR reports have information about the different waits. The reports list the
top waits, providing a quick way to determine the areas that might be of
interest or where to start looking for bottlenecks.
The AWR reports can be viewed in OEM, as shown in Figure 8-6. The
reports are based on the snapshot times. If different intervals are needed,
different reports can be generated.
In OEM, you can view the details in the list or see the reports in HTML
format. The time period, activity on the server, and some information about
Chapter 8: Performance and Tuning
233
the load on the server are summarized first. Figure 8-7 shows this
information at the top of the report, as well as the wait information, which
appears a bit further down in the report.
The first item listed in the wait information is DB CPU at the top. In the
example in Figure 8-7, no waits are listed; it shows just the percent of the

database time for CPU. I would suspect since there is no waiting for CPU,
the time is just the regular activity against the database and what is needed
for CPU.
As noted earlier in the chapter, the db file scattered read wait event
points to full-table scans being done. If you see these waits, check the top
SQL statements to validate query plans and consider placing indexes on the
appropriate tables.
234
Oracle Database Administration for Microsoft SQL Server DBAs
FIGURE 8-6.
AWR reports available for viewing in OEM
Chapter 8: Performance and Tuning
235
FIGURE 8-7.
An AWR report in OEM
Active Session History View
The Active Session History (ASH) view has information about waits and
events based on the sessions that are occurring in the database. The
following example generates a list of how many sessions had waits for
an event.
SQLPLUS> select session_id||','||session_serial# SID, n.name,
wait_time, time_waited
from v$active_session_history a, v$event_name n
where n.event# = a.event#
SID NAME WAIT_TIME TIME_WAITED

170,3 db file sequential read 0 28852
321,1 reliable message 0 977530
286,33215 db file parallel write 0 1108
240,25727 library cache lock 0 185

…
##plenty more events returned, so just a sampling
The TIME_WAITED column shows the actual time waited for the event,
and will be updated when the event is completed. The WAIT_TIME column
information matches up with the v$session_wait view. When the wait
time is shown as zero, then the session is currently waiting; nonzero values
indicate the session’s last wait time.
The information about events and waits can be overwhelming. In tuning
the database, you should focus on the top wait events, especially if the
information gathered is during a period when performance was an issue.
Getting information about which SQL statements were running and what
Oracle was waiting on will help with this troubleshooting.
Also be aware that some waits are just routine in the system, such as the
reliable message wait listed in the example of the ASH view. This is an idle
wait event, meaning that it is just waiting for work—something to do—and
not waiting on a resource.
Library Cache for SQL Statements
In the wait events listed in the sample AWR report and ASH view, you saw a
couple events pointing to the library cache. The library cache is part of the
shared pool and is the area in memory that handles SQL statements, PL/SQL
packages, and procedures. This can be considered similar to the SQL Server
procedure cache.
236
Oracle Database Administration for Microsoft SQL Server DBAs
Oracle will first look in the library cache for code that is to be executed
against the database, so there is no additional load into memory if the code
is already there. The plans are also available there, so it is beneficial to be
able to reuse SQL that is available in the library cache.
The following wait events appeared in the previous examples:
■

The library cache lock event is when two users want to compile the
same piece of code.
■
The library cache load lock event is a wait for the lock to be able to
load an object into the library cache.
The AWR reports show a library cache hit ratio to indicate how much of
the code is found in the cache and available for reuse.
One reason for not finding code in the library cache is that the cache is
too small to hold all of the statements; if there are a lot of ad hoc statements,
it might be hard to hold all of the statements. Another reason could be due
to the use of literal values instead of bind variables in the code.
SQLPLUS> select …
… where employee_name='George';
SQLPLUS> select …
… where employee_name=:empname;
The code with the variable will be getting the information passed in from
a variable in the package instead of just using the string value that is passed
in. Using bind variables is good practice and will help with management of
the library cache.
There is also a parameter that can help make code seem similar enough
that it can be reused: CURSOR_SHARING. This parameter can be set to one
of the following:
■
EXACT This makes the code match exactly. Using this value will
result in either a large library cache/shared pool or a very low hit
ratio of the library cache if literal values are used in the code and
can’t be matched up.
■
FORCE This will force a substitute of a literal into a bind variable to
reuse the code.

■
SIMILAR This will allow Oracle to decide what to bind, so that
code can be reused.
Chapter 8: Performance and Tuning
237
Other memory areas should also be examined for tuning and performance,
but the library cache is important because it is related to the code running on
the database. If you are able to design this code to use bind variables, or know
how to take advantage of some other parameters to force it to behave in a more
efficient manner, the database will perform better.
Summary
Tuning the performance of the database is a multiple-step process. First,
you’ll need to ask questions to figure out where the performance issue is
and what the issue actually means. Several Oracle tools allow you to gather
information and see history and current statistics, giving you more details
regarding what is running and how the server is behaving.
The areas to check first in an Oracle database are different from those in
a SQL Server database. Since locks and blocking are handled differently in
Oracle, this area is further down on the list that it is in SQL Server. Indexes,
statistics, and waits are the top areas to look at in an Oracle system to validate
that the database has what it needs as input to create good execution plans
and that it is not waiting on resources while the code is running.
Oracle provides several different index types. You may be able to make
code that may be less than optimal more efficient and access data faster,
such as through function-based indexes. Also, indexes that can skip the first
column may allow for fewer indexes to be created and maintained, which
might benefit data change performance. Since the Oracle CBO takes into
account the different costs of the indexes available and statistical information,
it is important to have good indexes and up-to-date statistics on the tables
and indexes.

The system views that provide session and wait information are valuable
in the tuning process, and the summary reports from the AWR provide a
quick glance at the information. Using these tools, you can drill down into
an issue to see if there are bottlenecks or code that needs to be tuned.
238
Oracle Database Administration for Microsoft SQL Server DBAs
CHAPTER
9
PL/SQL
T
he extended programming language for SQL Server is Transact-
SQL (T-SQL). For Oracle, the programming language is PL/SQL.
These programming languages provide additional capabilities
beyond those available with standard SQL. They are used to
develop applications and a way of accessing data. However,
using the database programming languages is not just for developers. Besides
doing code reviews, there are plenty of times for DBAs to use these languages
to write procedures for monitoring databases, performing maintenance, and
moving or loading data.
The database programming languages have some similar characteristics,
but each takes advantage of some features that are platform-specific. For
both, you define the variables and code to be executed, as well as pass in
values and return values. They both provide ways to handle errors and
process standard SQL statements. You can create triggers, stored procedures,
and functions. Oracle also has packages that group functions and procedures
together.
In previous chapters, you have seen several examples of SQL statements
to look at the data in an Oracle database or change it in some way, as well
as examples to execute PL/SQL system-supplied packages and procedures,
such as DBMS_STATS and DBMS_SCHEDULER. This chapter provides more

details about using PL/SQL. If you’re migrating from SQL Server to Oracle,
you’ll probably need to spend some time converting the T-SQL procedures
to PL/SQL procedures.
Database Coding Practices
PL/SQL is a programming language with close integration to the Oracle
database. Some of the standard coding practices used with T-SQL don’t
translate to PL/SQL, and might even seem backward. However, some of the
concepts correspond, although the coding will not be exactly the same. For
example, the concept of SQL Server INSTEAD OF triggers are found in
Oracle’s BEFORE triggers. Table 9-1 shows some examples of commonly
used programming tools in SQL Server and Oracle. As we look at PL/SQL
examples throughout this chapter, you will see how these are used in blocks
of code.
240
Oracle Database Administration for Microsoft SQL Server DBAs
Chapter 9: PL/SQL
241
Usage SQL Server Tool Oracle Tool
Data type
association
User-defined types %TYPE or %ROWTYPE allows for
using a column or row to have the
variable be the same type
Select SELECT 'test'
Can select without
from clause
SELECT 'test' FROM dual;
Dummy table to use with FROM
Row ID Can generate an ID
column on select

using functions
Row ID is automatically created as
a pseudo column
Unique
identifier
Identity Sequences
If this, then
this …
CASE DECODE or CASE
Set operators EXISTS and NOT
EXISTS
INTERSECT and MINUS
Cursors For looking at one row
at a time; tend to be
slower way to process
Implicit cursors used for data
processing; explicit use of cursors
to manipulate the data of a
SELECT statement
Delimiters Statements continue
when previous
statement is completed
without specific
delimiter
Use of ; to delimit statements
Create If exists, drop, then
create
Create or replace
Alter Alters stored
procedure code if

exists
Create or replace
TABLE 9-1.
Common Code Usage in SQL Server and Oracle