Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Copyright © 2005, Oracle. All rights reserved. Following a Tuning Methodology.

Similar presentations


Presentation on theme: "1 Copyright © 2005, Oracle. All rights reserved. Following a Tuning Methodology."— Presentation transcript:

1 1 Copyright © 2005, Oracle. All rights reserved. Following a Tuning Methodology

2 1-2 Copyright © 2005, Oracle. All rights reserved. Objectives After completing this lesson, you should be able to do the following: State the procedural steps in managing performance Describe the causes of performance problems Identify the main system areas that you can address by using the tuning process Describe the tuning methodology Explain the advantage of following the steps of the tuning methodology in their proper sequence List the tuning steps that are the responsibility of the application developer Describe an overview of SQL tuning

3 1-3 Copyright © 2005, Oracle. All rights reserved. Managing Performance Start early. Set objectives. Tune and monitor compliance. Work together. Handle exceptions and changes.

4 1-4 Copyright © 2005, Oracle. All rights reserved. Full Notes Page

5 1-5 Copyright © 2005, Oracle. All rights reserved. Factors to Be Managed Schema –Data design –Indexes Application –SQL statements –Procedural code Instance Database User expectations Hardware or network tuning

6 1-6 Copyright © 2005, Oracle. All rights reserved. Full Notes Page

7 1-7 Copyright © 2005, Oracle. All rights reserved. Performance Problems Inadequate consumable resources –CPU –I/O –Memory (may be detected as an I/O problem) –Data communications resources Design limitations Locking

8 1-8 Copyright © 2005, Oracle. All rights reserved. Critical Resource Performance depends on the following: –How many clients need the resource –How long they must wait for it –How long they hold it Consider limiting demand to maintain acceptable response times. Time to service completion Response time Demand rate Acceptable response time

9 1-9 Copyright © 2005, Oracle. All rights reserved. Excessive Demand Greatly increases response time and reduces throughput Should be prevented as much as possible by limiting demand to a level that still allows reasonable throughput

10 1-10 Copyright © 2005, Oracle. All rights reserved. Understanding Scalability Scalability is: A system’s ability to process more workload, with a proportional increase in system resource use Tuned by application designers and performance specialists Poor scalability leads to system resource exhaustion to the extent that additional throughput is impossible when the system’s workload is increased.

11 1-11 Copyright © 2005, Oracle. All rights reserved. Scalability: Resource Exhaustion Resource exhaustion can result from: Hardware exhaustion Table scans in high-volume transactions, causing inevitable disk I/O shortages Excessive network requests, resulting in network and scheduling bottlenecks Memory allocation, causing paging and swapping Excessive process and thread allocation, causing operating system thrashing

12 1-12 Copyright © 2005, Oracle. All rights reserved. Internet Scalability Characteristics of Internet applications: Availability 24 hours a day, 365 days a year An unpredictable and imprecise number of concurrent users Difficulty in capacity planning Availability for any type of query Multitier architectures Stateless middleware Short development time frames Minimal time for testing

13 1-13 Copyright © 2005, Oracle. All rights reserved. Scalability with Application Design, Implementation, and Configuration Applications have a large impact on scalability. Poor schema design can cause expensive SQL that does not scale. Poor transaction design can cause locking and serialization problems. Poor connection management can cause poor response times and unreliable systems.

14 1-14 Copyright © 2005, Oracle. All rights reserved. Tuning Methodology 1.Tune business function. 2.Tune data design. 3.Tune process design. 4.Tune SQL statements. 5.Tune physical structure. 6.Tune memory allocation. 7.Tune I/O. 8.Tune memory contention. 9.Tune operating system. 10.Networking issues

15 1-15 Copyright © 2005, Oracle. All rights reserved. Tuning Roles Business analyst Application developer Database administrator Operating system administrator 1. Tune business function. 2. Tune data design. 3. Tune process design. 4. Tune SQL statements. 5. Tune physical structure. 6. Tune memory allocation. 7. Tune I/O. 8. Tune memory contention. 9. Tune operating system. 10. Networking issues Designer Network administrator

16 1-16 Copyright © 2005, Oracle. All rights reserved. Applying a Tuning Methodology Be proactive: Work from the top down. If you must be reactive, work from the bottom up, using these guidelines: –Establish quantifiable objectives. –Create a minimum repeatable test. –Ask questions of affected users and avoid preconceptions. –Test hypotheses and keep notes. –Stop when you meet the target.

17 1-17 Copyright © 2005, Oracle. All rights reserved. Overview of SQL Statement Tuning Identify problematic SQL. Verify optimizer statistics. Review execution plans. Restructure SQL statements. Restructure indexes. Maintain execution plans.

18 1-18 Copyright © 2005, Oracle. All rights reserved. Identifying Problematic SQL Identify slow programs. Look at SQL in the program. Use SQL_Trace and TKPROF.

19 1-19 Copyright © 2005, Oracle. All rights reserved. Verifying Optimizer Statistics Gather statistics for all tables. Gather new statistics when existing statistics become stale.

20 1-20 Copyright © 2005, Oracle. All rights reserved. The driving table has the best filter. The fewest number of rows are being returned to the next step. The join method is appropriate for the number of rows being returned. Views are used efficiently. There are no unintentional Cartesian products. Each table is being accessed efficiently. Examine predicates in the SQL statement and the number of rows in the table. A full table scan does not mean inefficiency. Reviewing the Execution Plan

21 1-21 Copyright © 2005, Oracle. All rights reserved. Full Notes Page

22 1-22 Copyright © 2005, Oracle. All rights reserved. Compose predicates by using AND and =. Avoid transformed columns in the WHERE clause. Avoid mixed-mode expressions and beware of implicit type conversions. Write separate SQL statements for specific tasks. Use EXISTS rather than IN for subqueries. Control the access path and join order with hints. Restructuring the SQL Statements

23 1-23 Copyright © 2005, Oracle. All rights reserved. Full Notes Page

24 1-24 Copyright © 2005, Oracle. All rights reserved. Restructuring the Indexes Remove nonselective indexes to speed up the DML. Index performance-critical access paths. Reorder columns in existing concatenated indexes. Add columns to the index to improve selectivity. Consider index-organized tables.

25 1-25 Copyright © 2005, Oracle. All rights reserved. Maintaining Execution Plans over Time Stored outlines Stored statistics

26 1-26 Copyright © 2005, Oracle. All rights reserved. Summary In this lesson, you should have learned how to: Manage performance –Start early; be proactive. –Set measurable objectives. –Monitor requirements compliance. –Handle exceptions and changes. Identify performance problems –Inadequate consumable resources –Inadequate design resources –Critical resources –Excessive demand

27 1-27 Copyright © 2005, Oracle. All rights reserved. Summary Tune SQL statements –Manage user expectations. –Analyze the results at each step. –Tune the physical schema. –Choose when to use SQL. –Reuse SQL statements when possible. –Design and tune the SQL statement. –Get maximum performance with the optimizer.

28 1-28 Copyright © 2005, Oracle. All rights reserved.


Download ppt "1 Copyright © 2005, Oracle. All rights reserved. Following a Tuning Methodology."

Similar presentations


Ads by Google