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 probab

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_ADJparameter 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

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 11g, 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

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

FIGURE 8-6. AWR reports available for viewing in OEM

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

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

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

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

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

Can select without fromclause

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

If this, then

this …

Set operators EXISTSand NOT

EXISTS

INTERSECTand 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 SELECTstatement

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