great figures,  aren’t they?

Ref:

————————————–

About Tokutek
Tokutek’s founders developed Fractal Tree technology at MIT, Rutgers, and Stony Brook and started the company in 2006. As early
members of the teams at Google and Akamai, they bring significant industry and academic experience in developing innovative
algorithms for large scale, high performance systems.
Tokutek maintains offices in Boston and New York.
For more information on how TokuDB can help you to cost effectively meet your data scalability and performance challenges, blah blah blah … google by urself.

Table of contents

A0 How to begin and what you need to know before you start?
A1 When to tune PL/SQL code
A2 Identifying PL/SQL performance problems
A3 Turning PL/SQL by changing the oracle physical environment
A4 Turning PL/SQL algorithms, make loops as efficient as possible
A5 Using BULK COLLECT and FORALL in PL/SQL
A6 Other turnings on PL/SQL

—

…

– give one part I like the most here –>

….

“Oracle Corporation talks a good talk about how tightly integrated PL/SQL is with the SQL engine, but the integration is some ways only skin deep. From PL/SQL to SQL engine of some DML operations, many context switches with row-by-row SQL processing make the application inefficient.  So in Oracle8i, Oracle introduced BULK COLLECT and FORALL, which in essence implement array processing for SQL operations in PL/SQL.

When we use BULK COLLECT, we request multiple rows of data in a single request (context switch) to the Oracle database. The SQL engine processes this request and returns all the data together (one context switch) to the PL/SQL engine, which deposits the data into one or more collections.

For DML operations, we load into collections all the data we want to push back to our tables, and then FORALL batches up all the DML statements that need to be run to cover all the data in the collections. These statements are transferred over to the SQL engine in a single context switch.”

…

….

To do FORALL statement with BULT COLLECT statement, we rewrite the custorders procedure as Proc_FORALL.sql,

drop table tmptb;

create table tmptb(

o_orderkey NUMBER(12));

firstly we create a temp table for insert purpose.

Then rewrite the procedure CustOrders.

create or replace Procedure CustOrders(name_In VARCHAR2)

Is

cursor Order_Curr Is

     Select o_orderkey from orders join customer on o_custkey=c_custkey

     where c_name=name_In;

     –define a table type

Type orderType is table of Order_Curr%RowType index by pls_integer;

n_myOrders orderType;

Begin

     open Order_Curr;

     Loop

          – retrieve 1000 rows at a time with fatch

          FETCH Order_Curr BULK COLLECT into n_myOrders LIMIT 1000;    

          EXIT when n_myOrders.COUNT=0;

          – FORALL process the result data into temp table

          FORALL i IN 1..n_myOrders.COUNT

          INSERT INTO tmptb VALUES n_myOrders(i);

     END LOOP;

end CustOrders;

/

Finally to verify the temp table we created has those correct data.

– select the results for verification.

select * from tmptb;

Although the code above seems wordy and complex, by using Bulk Collect and FORALL could easily speed up the performance of your PL/SQL code. 

– Anyone who is interested in this collection plz feel free to send me email.

Wenzheng,

SET ECHO        OFF
SET VERIFY         OFF
SET LINESIZE         100
SET PAGESIZE         300
ACCEPT UNAME         CHAR PROMPT ‘User name>’
ACCEPT PWD             CHAR PROMPT ‘Password>’

Create user &UNAME identified by &PWD
Default tablespace USERS
Temporary tablespace TEMP;

GRANT RESOURCE, CONNECT,CREATE SESSION,CREATE TABLE TO &UNAME;

PROMPT Done.

CSCI317/MCS9317 Database Performance Tuning, Spring’2008

Experimented and described by: Wenzheng Chen, SITACS, 3.210 ext.4339, wchen@uow.edu.au,

Experiment 4.5

How to use Automatic Workload Repository (AWR) ?

Turn the system on (if it is off) and logon as XP user. Download and uncompress SQL scripts used in this experiment.

The Automatic Workload Repository (AWR) collects, processes, and maintains the performance statistics for problem detection and self-tuning purposes. This data is stored both in transient memory and in the database. The gathered data can be displayed in both reports and views.

The statistics collected and processed by AWR include:

· Object statistics that determine both access and usage statistics of database segments

· Time model statistics based on time usage for activities, displayed in the V$SYS_TIME_MODEL and V$SESS_TIME_MODEL views

· Some of the system and session statistics collected in the V$SYSSTAT and V$SESSTAT views

· SQL statements that are producing the highest load on the system, based on criteria such as elapsed time and CPU time

· Active Session History (ASH) statistics, representing the history of recent sessions activity

The STATISTICS_LEVEL initialization parameter must be set to the TYPICAL or ALL to enable the Automatic Workload Repository. Connect as a user SYSTEM and execute the following statement to find the present value of a parameter STATISTICS_LEVEL.

show parameter STATISTICS_LEVEL

If the value is set to BASIC, then you can manually capture AWR statistics using procedures in the DBMS_WORKLOAD_REPOSITORY package. To change a value of parameter STATISTICS_LEVEL execute the following statements while connected as a user SYSTEM:

ALTER SYSTEM SET STATISTICS_LEVEL = ‘TYPICAL’;

show parameters STATISTICS_LEVEL;

AWR is build-in to Oracle database kernel and does not require any configuration. It is running immediately after you create your database. Even if you do not license it, it is running and consuming resources to gather system statistics once per hour to its internal repository. ADDM as one of the intelligent self-tuning utilities also could be support by using AWR.

STATSPACK (still live in oracle 11g) requires you manually do some configuration like scheduling its STATSPACK.SNAP as a job in order to automate statistic gathering.

The AWR captures more information than STATSPACK including: tablespace usage, filesystem usage and operating system statistics. AWR statistics are accessible to external users, who can build their own performance monitoring tools, routines and scripts.

How to discover the internal structures of AWR?

“The AWR is very comprehensive and there are literally thousands of distinct metrics that can be examined” (by D.Burleson).

Well, AWR actually uses several Oracle internal tables (the families of WRM$_* and WRH$_* tables) to store the collected statistics, which are stored under the SYS schema in the SYSAUX tablespace. Alternatively, you can access those statistics from the dba_hist_* views by joining into the dba_hist_snapshot view (the main anchor for the AWR history views), or by querying some specified V$ views such like V$SYSSTAT or V$SYS_TIME_MODEL with different query purposes. A document awr_wivComponents.pdf present the AWR structures with its related components under Oracle 10g architecture.

AWR contains two types of oracle internal tables:

· Metadata Tables (WRM$_*):

These relational tables are used to control, process, and describe the Workload Repository tables. For example, Oracle uses the metadata tables to determine when to perform snapshots, and what to capture to disk.

· Historical Statistics Tables (WRH$_*):

These relational tables store important historical statistical information about the database in the form of periodic snapshots. Each snapshot is a capture of the in-memory database statistics data (X$) at a certain point in time.

Physically, the AWR statistics can be divided into the following categories of tables:

· Datafile I/O Statistics

· General System Statistics

· Concurrency Statistics

· Instance Tuning Statistics

· SQL Statistics

· Segment Statistics

· Undo Statistics

· Time- Model Statistics

· Recovery Statistics

· RAC Statistics

A2  How to access AWR views ?

When we are talking about the AWR related views, we mostly have to consider which step we probably can go through. The dba_hist_* views provide the source of data and wealth of customizable reports for identification of trends and time-series performance optimization.

Here are the views available for the workload repository:

· V$ACTIVE_SESSION_HISTORY – Displays the active session history (ASH) sampled every second.

· V$METRIC – Displays metric information.

· V$METRICNAME – Displays the metrics associated with each metric group.

· V$METRIC_HISTORY – Displays historical metrics.

· V$METRICGROUP – Displays all metrics groups.

· DBA_HIST_ACTIVE_SESS_HISTORY – Displays the history contents of the active session history.

· DBA_HIST_BASELINE – Displays baseline information.

· DBA_HIST_DATABASE_INSTANCE – Displays database environment information.

· DBA_HIST_SNAPSHOT – Displays snapshot information.

· DBA_HIST_SQL_PLAN – Displays SQL execution plans.

· DBA_HIST_WR_CONTROL – Displays AWR settings.

Oracle gives users the option of accessing AWR metadata or historical data manually using any ad-hoc query tool like SQL*Plus by performing queries against the following database objects:

· The dba_hist_* dictionary views provide access to historical statistical data stored in the AWR. The AWR stores cumulative values available through dynamic performance views like V$SYSSTAT. Instance restart resets these cumulative values in V$ memory views. However, the AWR keeps cumulative statistics as well as delta values that show the change of statistics over time.

· The v$metric* views provide metric statistics which show users the rate of change of some particular statistic. The metrics in Oracle can be measured against such units as time, transaction number, database or user calls, etc. One specific example would be the parse number per second. The metric views are organized by Oracle in groups as system, session, file, event, tablespace, etc.

· The v$active_session_history view provides access to a sampled data. The sampled data shows the activity status of all active database sessions at the given moment. The content of v$active_session_history view is also preserved by the AWR.

If we would like to get more information then it can be extracted from WRM$_* and WRH$_* tables. We can get all data from WRM$_SNAPSHOT table instead of from dba_hist_snapshot view. Connect as a user SYS (and not as SYSTEM !) and execute the following statements:

desc WRM$_SNAPSHOT

Name Null? Type

—————————————————– ——– ————————————

SNAP_ID NOT NULL NUMBER

DBID NOT NULL NUMBER

INSTANCE_NUMBER NOT NULL NUMBER

STARTUP_TIME NOT NULL TIMESTAMP(3)

BEGIN_INTERVAL_TIME NOT NULL TIMESTAMP(3)

END_INTERVAL_TIME NOT NULL TIMESTAMP(3)

FLUSH_ELAPSED INTERVAL DAY(5) TO SECOND(1)

SNAP_LEVEL NUMBER

STATUS NUMBER

ERROR_COUNT NUMBER

BL_MOVED NUMBER

SNAP_FLAG NUMBER

desc dba_hist_snapshot

Name Null? Type

—————————————————– ——– ————————————

SNAP_ID NOT NULL NUMBER

DBID NOT NULL NUMBER

INSTANCE_NUMBER NOT NULL NUMBER

STARTUP_TIME NOT NULL TIMESTAMP(3)

BEGIN_INTERVAL_TIME NOT NULL TIMESTAMP(3)

END_INTERVAL_TIME NOT NULL TIMESTAMP(3)

FLUSH_ELAPSED INTERVAL DAY(5) TO SECOND(1)

SNAP_LEVEL NUMBER

ERROR_COUNT NUMBER

Another example, the internal creation syntax for the dba_hist_sysstat view is built from wrm$_snapshot,wrh$_sysstat and dba_hist_stat_name.

So, so, so (so what?) …. Exciting? You have one more option to dive into the new AWR tables. Just keep in mind they could be equivalent or you can explore more evidence by yourself.

A3  How to set and how to list AWR parameters ?

To list the available snapshots connect as a user SYSTEM and execute a script file list_awrsnaps.sql. The scripts outputs a long list of snapshots taken automatically every 60 minutes over a period of one week. A default frequency of taking snapshots and snapshot retention period are set at installation of the system. It is possible to adjust the interval, retention, and captured top SQL of snapshot generation. A parameter INTERVAL determines how often the snapshots are automatically taken. A parameter RETENTION determines how long the snapshots are stored in the workload repository. A parameter TOPNSQL setting affects the number of Top SQL to flush for each SQL criteria (Elapsed Time, CPU Time, Parse Calls, Shareable Memory, and Version Count). To adjust the settings, use a procedure MODIFY_SNAPSHOT_SETTINGS. For example, the following execution of the procedure sets a retention period to 43200 minutes (30 days), the interval between each snapshot to 30 minutes, and the number of Top SQL to flush for each SQL criteria to 100. If NULL is specified, the existing value is preserved.

EXECUTE DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(

retention => 43200,

interval => 30,

topnsql => 100 );

The current settings of AWR parameters are included in a view DBA_HIST_WR_CONTROL. While connected as a user SYS execute a script list_awrparameters.sql to list the current values of AWR parameters.

A4  How to take a snapshot ?

Connect as a user SYS and execute a script to list list_awrsnaps.sql the available snapshots. To take a new snapshot execute the following statement:

EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

List all snapshots again. Connect as a user CSCI317 and execute the following statement:

SELECT COUNT(*)

FROM LINEITEM;

Take one more snapshot while connected as a user SYS.

A snapshot is taken by the execution of snap procedure CREATE_SNAPSHOT of DBMS_WORKLOAD_REPOSITORY package. It allows for the snapshots from within the user applications e.g. PL/SQL stored procedures and functions, embedded SQL applications, JDBC applications, and the other applications that allow for execution of SQL statement.

A5 How to generate and how to read AWR reports ?

Without ADDM reports, we can actually generate the more detailed reports by AWR itself. Oracle provides two scripts to produce workload repository reports (awrrpt.sql and awrrpti.sql). They are similar in format to the statspack reports and give the option of HTML or plain text formats. The two reports give essential the same output but the awrrpti.sql allows you to select a single instance. The reports can be generated as follows:

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

@$ORACLE_HOME/rdbms/admin/awrrpti.sql

The scripts prompt you to enter the report format (html or text), the start snapshot id, and the end snapshot id and the report filename. The resulting report can be opened in a browser or text editor accordingly. You can find the sample reports in

AWR_ReportSampleHTML.html or AWR_ReportSampleText.txt.

Connect as a user SYS and execute the scripts on your own and try to generate the reports from the last two snapshots. The scripts will ask you to specify some details such like “Report Type“,”number of days of snapshots“,”the Begin and End Snapshot Ids“,”Report Name” and so on. The scripts have automatically grabbed all information for you to select. Just follow by the script instructions. It is so easy to generate a full detailed AWR report.

A6  How to use AWR to performance tuning ?

In order to adjust the size of data buffer cache to the sizes of relational tables accessed in the script we reduce the size of data buffer cache to 100 Mbytes. Connect as a user SYS and execute a statement:

ALTER SYSTEM SET db_cache_size=100M;

SHOW PARAMETER db_cache_size

We shall apply AWR to the performance tuning of JDBC application included in task7.java. Connect as a user SYS and take a snapshot:

EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

Then, compile and run the application:

javac task7.java

java task7

Next, while connected as a user SYS take the second snapshot and execute a script list_awrsnaps.sql to find the numbers of the last two snapshots. Generate a report in the following way:

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

The report lists a large number of almost identical statements stored in a library cache.

CPU Elapsed CPU per % Total

Time (s) Time (s) Executions Exec (s) DB Time SQL Id

———- ———- ———— ———– ——- ————-

0 0 1 0.0 1.9 d8asj875rzddk

SELECT COUNT(*) FROM PARTSUPP JOIN SUPPLIER ON PS_SUPPKEY = S_SUPPKEY JOIN PART

ON PS_PARTKEY = P_PARTKEY JOIN NATION ON S_NATIONKEY = N_NATIONKEY WHERE N_

NAME IN (‘JAPAN’, ‘PERU’, ‘AUSTRALIA’ ) AND S_SUPPKEY = 81

0 0 1 0.0 1.9 cz9109atqxcsj

SELECT COUNT(*) FROM PARTSUPP JOIN SUPPLIER ON PS_SUPPKEY = S_SUPPKEY JOIN PART

ON PS_PARTKEY = P_PARTKEY JOIN NATION ON S_NATIONKEY = N_NATIONKEY WHERE N_

NAME IN (‘JAPAN’, ‘PERU’, ‘AUSTRALIA’ ) AND S_SUPPKEY = 1

0 0 1 0.0 1.9 gwcd3mcupa9wm

SELECT COUNT(*) FROM PARTSUPP JOIN SUPPLIER ON PS_SUPPKEY = S_SUPPKEY JOIN PART

ON PS_PARTKEY = P_PARTKEY JOIN NATION ON S_NATIONKEY = N_NATIONKEY WHERE N_

NAME IN (‘JAPAN’, ‘PERU’, ‘AUSTRALIA’ ) AND S_SUPPKEY = 177

…                                 …                                 …

SQL parsing parameters included in Instance Activity Stats section of the report reveal a large number of parsing activities performed by the system while processing the application.

Statistic                           Total  per Second    per Trans

——————————— ——— ———— ————-

parse count (failures)              0      0.0           0.0

parse count (hard)                  2      0.0           0.1

parse count (total)                 674    9.7           44.9

parse time cpu                      4      0.1           0.3

parse time elapsed                  4      0.1           0.3

Latch Activity section confirms the intensive activities in Library Cache area (see below).

Get           Get    Slps   Time   NoWait        NoWait

Latch Name                   Requests      Miss   /Miss  (s)    Requests      Miss

————————     ————– —— —— —— —————       ——

library cache                15,337        0.0    N/A    0      0             N/A

library cache lock           6,918         0.0    N/A    0      0             N/A

library cache lock alloc     54            0.0    N/A    0      0             N/A

library cache pin            5,868         0.0    N/A    0      0             N/A

library cache pin alloca     16            0.0    N/A    0      0             N/A

We shall optimize the application to reduce the total number of parsing and optimizations and reduce traffic over Library Cache. The optimized application is included in opttask7.java.

Connect as a user SYS flush shared pool in order to remove the hundreds of almost identical SQL statements.

ALTER SYSTEM FLUSH SHARED_POOL;

Next, while connected as a user SYS take a snapshot:

EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;

Then, compile and run the optimized application:

javac opttask7.java

java opttask7

Next, while connected as a user SYS take the second snapshot and execute a script list_awrsnaps.sql to find the numbers of the last two snapshots. Generate a report in the following way:

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

A large number of almost identical SELECT statements disappeared from a library cache.

CPU Elapsed CPU per % Total

Time (s) Time (s) Executions Exec (s) DB Time SQL Id

———- ———- ———— ———– ——- ————-

1 1 499 0.00 43.0 dzqf50vy745f7

SELECT COUNT(*) FROM PARTSUPP JOIN SUPPLIER ON PS_SUPPKEY = S_SUPPKEY JOIN PART

ON PS_PARTKEY = P_PARTKEY JOIN NATION ON S_NATIONKEY = N_NATIONKEY WHERE N_

NAME IN (‘JAPAN’, ‘PERU’, ‘AUSTRALIA’ ) AND S_SUPPKEY = :1

SQL parsing parameters included in Instance Activity Stats section of the report reveal a significantly small number of parsing done by the system while processing the application.

Statistic Total per Second per Trans

——————————– —————— ————– ————-

parse count (hard) 55 1.7 5.0

parse count (total) 255 7.9 23.2

parse time cpu 5 0.2 0.5

parse time elapsed 7 0.2 0.6

Latch Activity section confirms less intensive activities in Library Cache area (see below).

Get Get Slps Time NoWait NoWait

Latch Name Requests Miss /Miss (s) Requests Miss

———————— ————– —— —— —— ———— ——

library cache 5,952 0.0 0.0 0 0 N/A

library cache load lock 38 0.0 N/A 0 0 N/A

library cache lock 1,696 0.0 N/A 0 0 N/A

library cache lock alloc 54 0.0 N/A 0 0 N/A

library cache pin 2,861 0.0 N/A 0 0 N/A

When finished, reset the size of data buffer cache to its original value:

ALTER SYSTEM SET db_cache_size=332M;

SHOW PARAMETER db_cache_size

A7  How to truncate a range of snapshots ?

While connected as a user SYS execute the script list_awrsnaps.sql to list all snapshots that currently exist in the system.

Then, to remove all snapshots in a range from 165 to 167 (you may have to use different numbers) execute the following statement:

EXECUTE DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE

(165,167)

End of experiment 4.5

References:

“Oracle Tuning: The Definitive Reference” by Donald Keith Burleson

Oracle Official Document.

PROMPT Done.
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */

PROMPT Done.
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */

PROMPT Done.
PROMPT ‘ALTER SYSTEM KILL SESSION ”
/* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ */
/*ALTER SYSTEM KILL SESSION ”;*/