Download Week 1, Lecture 1

Chapter 6
Application Design and
Implementation
1
Application Database Design Goals



2
Reducing volume of requests to database
from the application
Reducing network overhead
Reducing lock contention
SQL Statement Management

Even simple SQL is expensive operation
–
–
–
–
–

Avoid unnecessary requests
–
3
Request transmitted to server
Statement parsed
Statement prepared
Statement executed
Results in I/O before result is returned
–
Having SQL re-parsed
Repeat requests for “static” data
Optimizing Parsing


Try to avoid the “hard parse”
Use bind variables
–
–
–
–

Use CURSOR_SHARING parameter
–

Transparently replaces literals with bind variables
Use FORCE_MATCHING_SIGNATURE column in
V$SQL
–
4
Use the SQL already in the shared pool
Avoids hard parsing
Reduces execution time
Reduces latch or mutex contention (see Ch. 16)
Indicates statements that would be aided by
CURSOR_SHARING
Avoid Unnecessary SQL Executions

YAPP methodology
“The best tuned SQL is the SQL you didn’t
execute.”

5
Tuning SQL can mean eliminating
unnecessary executions within an application
(i.e. avoid redundant SQL)
Avoid Unnecessary SQL Executions
(cont.)

Use Data Caching to reduce executions
–
–

Data Caching considerations
–
–
–
6
Store needed data in application memory (e.g.
PL/SQL collection or array variable)
Ideal for small, frequently accessed tables
Analyze memory needs
Design efficient search mechanisms in application
for larger caches
Complexity increases with frequently updated
tables
Avoid Unnecessary SQL Executions
(cont.)

Using the Result Cache
–
–

Enables use of Data caching within database, rather than
within application itself
Stores recent result sets in memory
Setting the Result Cache
–
–
Set CLIENT_RESULT_CACHE_SIZE to nonzero value
Enable query caching



–
7
Using RESULT_CACHE hint
Set RESULT_CACHE on table (DDL command)
Set RESULT_CACHE_MODE parameter to FORCE
Tune the CLIENT_RESULT_CACHE_LAG as needed over
time to control how long results stay in cache
The Array Interface


Array fetch: retrieving rows in batches
Implementing Array fetch
–
How depends on the language or tool


–
–

Generally can see 10x improvement
Less I/O, in turn - less network traffic
Array insert: performing DML in batches
–
–
8
In PL/SQL, it is the ‘BULK COLLECT INTO’ clause
In Java, it is set by the setFetchSize method
In PL/SQL, it is the FORALL command
In Java, it is the addBatch and executeBatch commands
Transaction Design
“A transaction is a set of of one or more SQL statements that
are logically grouped together and applied to the database in
their entirety or not applied at all.”

Transactions should conform to “ACID” principle
–
–
–
–

9
Atomic – all or no statements are applied to the database
Consistent – database is consistent before and after transaction
Isolated – Multiple transactions are invisible to each other
Durable – Changes to database persist, regardless of circumstances
ACID properties enforced by the DBMS (locking, COMMIT,
ROLLBACK)
Transaction Design (cont.)

Isolation Levels
–
–
–
–
Determines degree of transaction visibility between
sessions
Concurrency – capability of multiple ssessions to
perform transactions at the same time
Consistency – how a session sees data regardless of
transactions on the database
Three types in Oracle


10

READ COMMITTED
READ ONLY
SERIALIZABLE
Transactions and Locks

Typical locking types within a DBMS
–
–
–

Application locking strategies
–
–
11
Table-level locking
Block-level locking
Row-level locking (Oracle)
Pessimistic (assumes multiple updates at the same
time for a row)
Optimistic (assumes one update at a time for a row)
Transactions and Locks (cont.)

Implementing a locking strategy
–
Oracle has features to aid in determining strategy



–
Using application code features to determine strategy

–
–
12
Using ORA_ROWSCN pseudo column to track row changes
Using ROWDEPENDENCIES
Using the above assumes implementing optimistic strategy
Using FOR UPDATE in PL/SQL
Row-level locking (Oracle)
Chosen strategy is trade-off between concurrency and
robustness
Stored Procedures & Network Traffic

Encapulating transactions in stored procedures
–
–
Can help minimize network overhead
Network round trips are reduced


–
13
No need to transfer result sets to application
Can be done on database server
The advantage increases as network latency
increases