A Closer Look at Parsing:

Possible Application Optimizations Mark J. Bobak Michigan Oracle Users Summit, 9/24/09

PGA
FixedPGA CGA UGA Private SQL area U G A Fixe Fixe Runtime area PGA PGA Work area UGA-1

PGA

MTS uga

PGA

Server 1

PGA1

Server 2

PGA2

SGA

Shared pool

Log buffer

Java pool

large pool

streams pool

Buffer cache

Introduction
Working as Oracle DBA since 2000 Employed by ProQuest Company, Ann Arbor, MI, since 1997 Frequent presenter at national and international conferences; Hotsos, UKOUG, Oracle OpenWorld Member of Southeast Michigan Oracle Professionals Member of the OakTable Network since December, 2002

Objectives
A closer look at parsing
Hard parse/Soft parse/Cursor cache hit Parameters which affect parsing?
cursor_sharing/session_cached_cursors/cursor_space_for_time

Application design considerations

How can better parsing practices improve scalability? What changes can be implemented at application level?

Disclaimer
At least one statement in this presentation is incorrect, but it may be this one.

What is Parsing?
According to Wikipedia:
In computer science and linguistics, parsing, or, more formally, syntactic analysis, is the process of analyzing a text, made of a sequence of tokens (for example, words), to determine its grammatical structure with respect to a given (more or less) formal grammar.

Four Types of Parse

Hard Parse Cursor Authentication Soft Parse Session Cursor Cache Hit

Hard Parse
Most expensive
Shared pool latch
Allocate memory from shared pool

Library cache latch

Define parent and child cursor areas

Syntax check Semantic check

Object resolution Permissions

Execution plan generation

Cursor Authentication
Most expensive
Shared pool latch
Allocate memory from shared pool

Library cache latch

Define parent and child cursor area

Syntax check Semantic check

Object resolution Permissions

Execution plan generation

Soft Parse
Most expensive
Shared pool latch
Allocate memory from shared pool

Library cache latch

Define parent and child cursor areas

Syntax check Semantic check

Object resolution Permissions

Execution plan generation

Session Cursor Cache Hit

Most expensive
Shared pool latch
Allocate memory from shared pool

Library cache latch

Define parent and child cursor areas

Syntax check Semantic check

Object resolution Permissions

Execution plan generation

Whats the difference?

How Do Soft Parse and Session Cursor Cache Hit differ? In the event of a session cursor cache hit, the session cursor cache has cached the library cache lock structure, so your session does not need to re-create it. In the case of a soft parse, the library cache lock object (your sessions handle to the SQL statement) needs to be created.

session_cached_cursors
This parameter should be set to a positive integer, and defines the size of the session cursor cache. In recent versions of Oracle, the default is 50. The session cursor cache allows your session to cache the library cache lock object for any SQL statement that has been executed three times. This allows for the users session to avoid searching the library cache for frequently parsed SQL.

cursor_space_for_time
cursor_space_for_time is a boolean, defaults to false. If you do not have a well-controlled, well-defined set of SQL, do NOT set this parameter to true. Setting this parameter to true caches the library cache pin structure. This effectively prevents any cursor from being aged out of the cache, as long as an application is holding the cursor open.

Shareable SQL
SQL with literal values cannot share parent cursor SQL whose text matches exactly can share parent cursor, but may not be able to share child cursor (execution plan) There are lots of reasons why Oracle may decide not to share a child cursor Complete list is visible in V$SQL_SHARED_CURSOR

cursor_sharing
When you have a poorly designed application, that uses lots of literals, you may consider setting cursor_sharing. Three possible values: exact : SQL must be an exact text match to be shared. This is the default. force : SQL which is similar, except for literal values is shared and so is the execution plan. There is a potential for degraded execution plans. similar : SQL which is similar, except for literal values is shared, but allows for differing execution plans.

Parsing and Scalability

Every application will fall into one of three broad categories, with respect to parsing and the level of scalability. Category 1 Literal SQL, no bind variables, one hard parse per execution Category 2 Bind variables, one soft parse per execution Category 3 Bind variables, one parse, many executions

Category 1
Is characterized by lack of bind variables One hard parse per execution Every SQL statement is unique and must be hard parsed Inherently non-scalable cursor_sharing may be helpful cursor_sharing is a band aid not a panacea. Fix the application!

Exceptions to the Rule

Data Warehouse Decision Support Systems Other systems where the query execution time far exceeds the parse time. In this case, it may be more beneficial for the database to have access to the literal values.

Category 2
No literal values, bind variables are in use Still one parse per execution, but since bind variables are in use, parses are soft Many applications fall into this category

Category 3
Parse once, execute many times This is the holy grail Highly scalable, CPU efficient Dont change a thing!

Which parameters apply?

For category 1 (SQL w/ literal values), cursor_sharing may help. (Not a panacea, at best, its a band aid.) Also, some benefit from session_cached_cursors. For category 2, session_cached_cursors, will be a benefit, possibly cursor_space_for_time (only if app is well-behaved) For category 3, no need to do anything, life is good!

How to reduce parse calls?

Only one way to reduce the number of parse calls. That is to reduce the number of PARSE db calls All the server side tuning in the world (fiddling with system parameters, changing size of shared pool, etc) will NEVER reduce the number of parse calls. May be able to minimize the impact of a parse call, but only application code changes can reduce the number of parse calls.

Conclusion
Weve covered some basic concepts of parsing in Oracle Discussed the system parameters that may have an effect on the parse load on your system Covered the basics of application design considerations that will improve both system scalability and parse performance.

References
Designing applications for performance and scalability Oracle Whitepaper by Bjorn Engsig, Lex De Haan, Graham Wood and John Rees (available on OTN) Oracle Database Reference Manual for description of statistics Oracle Database Performance Tuning Guide

Q/A?
Questions? Comments? Complaints?