This Slideshare presentation is a partial preview of the full business document. To view and download the full document, please go here:
http://flevy.com/browse/business-document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
Part 12 of a multi-part series of presentations on the management discipline of database administration. This installment extends the coverage of managing database performance to examine database coding methods for achieving high performance. The entire series can be used to implement an efficient and effective database administration function at your organization. This part covers the following areas:
- Defining Applications for Relational Access
- Relational Optimization
- Additional Optimization Considerations
- Reviewing Access Paths
- SQL Coding and Tuning for Efficiency
2. Designing Applications
for Relational Access
Design issues to examine when application performance suffers:
• Type of SQL. Is the correct type of SQL (planned or unplanned, dynamic or
static, embedded or stand-alone) being used for this particular application?
• Programming language. Is the programming language capable of achieving
the required performance, and is the language optimized for database access?
• Transaction design and processing. Are the transactions within the program
properly designed to assure ACID properties, and does the program use the
transaction processor of choice appropriately and efficiently?
• Locking strategy. Does the application hold the wrong type of locks, or does it
hold the correct type of locks for too long?
• COMMIT strategy. Does each application program issue SQL COMMIT
statements to minimize the impact of locking?
• Batch processing. Are batch programs designed appropriately to take
advantage of the sequential processing features of the DBMS?
• Online processing. Are online applications designed to return useful
information and to minimize the amount of information returned to the user’s
screen for a single invocation of the program?
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
3. Physical Data Independence
• Relational optimization allows queries to adapt to
a changing database environment.
• The optimizer can react to changes by
formulating new access paths without requiring
application coding changes to be implemented.
– The application can therefore be flexible as tables
expand or contract in size, as indexes are added or
removed, and as the database becomes disorganized
or reorganized.
• This separation of access criteria from physical
storage characteristics is called physical data
independence.
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
4. Test vs. Production Statistics
• When testing applications against test
databases there will be less data
– So statistics will not match production
• You can copy production statistics and
populate them into the test
system to simulate production
access paths, thoughThis document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
5. Access Path Choices
• Table Scans
• Indexed Access
– Direct index lookup
– Matching index scan
– Non-matching index scan
– Index screening
– Index only access
– Using indexes to avoid sorting
• Hashed Access
• Parallel Access
– I/O, CPU, system
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
6. Rule-Based Optimization
• Most relational optimizers are cost based,
meaning they formulate access paths based
on an estimation of costs.
– Lower-cost favored over costlier access paths.
• Some DBMSs support a optimization based on
heuristics, or rules.
– Oracle provides both cost-based and rule-based
optimization.
• But Oracle is phasing out the rules-based optimizer.
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
7. Visual Explain Tools
• Instead of interpreting coded values in a Plan Table, a Visual
Explain tool diagrams access paths pictorially.
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
8. SQL Coding and Tuning for Efficiency
1. Identify the business data requirements
2. Ensure that the required data is available within existing
databases
3. Translate the business requirements into SQL
4. Test the SQL for accuracy and results
5. Review the access paths for performance
6. Tweak the SQL for better access paths
7. Code optimization hints
8. Repeat steps 4 through 7 until performance is acceptable.
9. Repeat step 8 whenever performance problems arise or a
new DBMS version is installed
10. Repeat entire process whenever business needs change
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
9. Be Careful What You Ask For
• The arrangement of elements within a query
can change query performance.
• Place the most restrictive predicate where the
optimizer can read it first.
– Enables the optimizer to
narrow down the first set
of results before proceeding
to the next predicateThis document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
10. Avoid Cartesian Products
• Cartesian Product -> every row in one table is
joined to every row in another table with no
join criteria.
– The results of a Cartesian product are difficult to
interpret.
• Always provide join predicates.
• Failure to do so will result in severe
performance degradation and possibly
incorrect results.
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
11. Avoid Sorts When Possible
• When performance is important, remember to
look for sorts and find ways to eliminate them.
• You can use indexes to avoid sorts for certain SQL
constructs in most relational DBMSs:
– ORDER BY
– GROUP BY
– DISTINCT
– UNION
– INTERSECT
– EXCEPT
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
12. Beware of Code Generators
• Application code generators and similar tools that
automatically create SQL can create “bad” SQL… and
usually do.
– Keep an eye on the SQL generated by such tools and re-
write poorly written SQL before it reaches production.
• Some of these tools use gateways that require each
SQL statement to be recompiled and optimized each
time it is requested.
• Utilize the gateway’s a caching mechanism to store
compiled and optimized SQL on the server.
– Such a cache can be help to improve performance for
frequently recurring SQL statements.
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
13. Indentifying Poorly Performing SQL
• A large part of the task of tuning SQL is
identifying the offending code.
• Acquire and use a SQL performance monitor
to constantly monitor the DBMS for sub-
optimal SQL statements.
• Identify the worst SQL and fix.
This document is a partial preview. Full document download can be found on Flevy:
http://flevy.com/browse/document/the-complete-guide-to-dba-practices-and-procedures-application-performance-part-12-583
14. 1
Flevy (www.flevy.com) is the marketplace
for premium documents. These
documents can range from Business
Frameworks to Financial Models to
PowerPoint Templates.
Flevy was founded under the principle that
companies waste a lot of time and money
recreating the same foundational business
documents. Our vision is for Flevy to
become a comprehensive knowledge base
of business documents. All organizations,
from startups to large enterprises, can use
Flevy— whether it's to jumpstart projects, to
find reference or comparison materials, or
just to learn.
Contact Us
Please contact us with any questions you may have
about our company.
• General Inquiries
support@flevy.com
• Media/PR
press@flevy.com
• Billing
billing@flevy.com