[Next] Oracle High Performance Tuning for 9i and 10g ISBN:1555583059 by Gavin Powell Digital Press © 2004 (738 pages) This text covers the three parts of tuning an Oracle database: data modeling, SQL code tuning, and physical database configuration, and explains both problem detection and resolution Table of Contents Oracle High Performance Tuning for 9i and 10g Preface Introduction Part I - Data Model Tuning Chapter 1 - The Relational Database Model Chapter 2 - Tuning the Relational Database Model Different Forms of the Relational Chapter 3 Database Model Chapter 4 - A Brief History of Data Modeling Part II - SQL Code Tuning Chapter 5 - What is SQL? Chapter 6 - The Basics of Efficient SQL Chapter 7 - Common Sense Indexing Chapter 8 - Making SQL Efficient in Oracle Database Chapter 9 - How to Find Problem Queries Tuning SQL with Oracle Enterprise Chapter 10 Manager Part III - Physical and Configuration Tuning Installing Oracle and Creating a Database Chapter 12 - Tuning Oracle Database File Structures Chapter 13 - Object Tuning Chapter 14 - Low-Level Physical Tuning Chapter 15 - Hardware Resource Usage Tuning Chapter 16 - Tuning Network Usage Chapter 17 - Oracle Partitioning and Parallelism Chapter 18 - Ratios: Possible Symptoms of Problems Chapter 19 - Wait Events Chapter 20 - Latches Chapter 21 - Tools and Utilities Tuning with the Wait Event Interface and Chapter 22 STATSPACK Appendix A - Sample Databases Appendix B - Sample Scripts Appendix C - Sources of Information Index List of Figures Chapter 11 - Oracle High Performance Tuning for 9i and 10g Gavin Powell Digital Press is an imprint of Elsevier 200 Wheeler Road, Burlington, MA 01803, USA Linacre House, Jordan Hill, Oxford OX2 8DP, UK Copyright © 2004, Elsevier Inc All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher Permissions may be sought directly from Elsevier's Science & Technology Rights Department in Oxford, UK: phone: (+44) 1865 843830, fax: (+44) 1865 853333, e-mail: permissions@elsevier.com.uk You may also complete your request on-line via the Elsevier homepage (http://elsevier.com), by selecting "Customer Support" and then "Obtaining Permissions." Recognizing the importance of preserving what has been written, Elsevier prints its books on acid-free paper whenever possible Library of Congress Cataloging-in-Publication Data British Library Cataloguing-in-Publication Data A catalogue record for this book is available from the British Library ISBN: 1-55558-305-9 For information on all Digital Press publications visit our website at www.digitalpress.com and www.bh.com/digitalpress 03 04 05 06 07 08 10 There are three parts to tuning an Oracle database: data modeling, SQL code tuning followed by physical and configuration tuning A data model contains tables and relationships between tables Tuning a data model involves Normalization and Denormalization Different approaches are required depending on the application, such as for an Internet OLTP or data warehouse database Inappropriate database design can make SQL code impossible to tune Poor data modeling can have a most profound effect on data base performance since all SQL code is constructed from the data model Changes to the data model are often the most difficult and expensive changes to implement Poorly written SQL code is often a culprit of performance prob lems and is expensive to rectify However, tuning of SQL code is gen erally cheaper than changing the data model SQL code tends to be contained inside independent blocks within applications or stored procedures Physical database tuning involves hardware resource usage, net working, and various other facets of Oracle such as configuration and file distribution Inappropriate physical and configuration set tings are often a culprit of poor performance where Oracle is installed with defaults, and never altered by an expert Preface This book is about tuning Oracle databases Three areas of Oracle Database tuning are data model tuning, SQL code tuning plus physical, and configuration tuning The author began his career as an applications developer and not a systems or network administrator As a result this book is written from an applications rather than an operating system perspective The objective of this book is to cover all three areas of Oracle Database tuning Currently there is no title on the market completely covering all of these This book will cover all three by explaining both problem detection and resolution The approach in this book is to present something which appears to be immensely complex in a simplistic and easy-to-understand manner Both reference material and examples are utilized appropriately in order to expedite understanding for the reader Reference material is not overused Oracle software has been in general use commercially for many years and is intended to provide for a very large and diverse customer base Features are often not removed from Oracle software between versions and new features are continuously being added The result is that Oracle software contains a plethora of available options and features Using only reference information to explain Oracle Database tuning would therefore be difficult to read, contrary to the approach of this book and would not provide the reader with much practical advice This book contains a lot of examples, with realistic databases and data; sometimes even very large amounts of data After all, if your production database needs tuning, you probably have more data than you first expected This book is written from not only an applications perspective but from the expert knowledge of the author, both in development and database administration roles A broad-based tutorial on the subject of tuning Oracle Database is much needed Most database administrators have operating system administration experience and little SQL code or data-modeling experience On the other hand, developers have the opposite This book will target both developers and database administrators since it includes all three areas essential to tuning Oracle installations effectively The important factor is that all tuning skills are required for best performance, both administration and development skills sets Being a broad-based tutorial this title is written to reach the widest possible audience, including data modelers, developers, database administrators, and system administrators Each of these audiences is very specialized, but all are related and interdependent There are no existing titles including tuning for data models, tuning of SQL code plus physical and configuration tuning, all in one book People who would benefit from reading this book would be database administrators, developers, data modelers, systems or network administrators and technical managers Technical people with these different skills are often ignorant of the skills of each other This is a great pity because all skill sets are very much dependent on each other for well-constructed databases and applications Let's take a common example situation Developers cannot simply hand off SQL code tuning to database administrators when application coding is complete Database administrators more often than not know absolutely nothing about SQL code tuning The result is no SQL code tuning is ever done and too much time is spent squeezing out an extra 10% of performance, with the database administrator doing physical and configuration tuning Targeting a few hard- hitting SQL statements will probably result in much more than a 10% performance improvement, which is much more productive What is in this book? Data Model Tuning What is the data model? The data model is the table structure and the relationships between those tables Tuning the data model for performance involves Normalization and Denormalization Different approaches are required depending on the type of database installation such as OLTP or data warehouse type databases Inappropriate database design can make SQL code impossible to tune If the data model is poor, changing the data model can have the most profound effect on database performance All SQL code is constructed from the underlying tables The big problem is that altering the data model after completion of development is expensive since application code may require extensive rework Tip OLTP refers to Online Transaction Processing OLTP generally implies the Internet Within the scope of this book OLTP is used to represent both OLTP architectures and perhaps Client-Server architectures as well What in the data model causes problems and what is data model tuning? Data model tuning is most effectively performed by a combination of both database administrators and developers It is seldom the case that both skill sets are involved The result is that table structures are often either development centric (top-down) or administration centric (bottom-up) designed Java development is often top-down and attempts to impose an object structure over a relational framework Bottom-up design often results in over-Normalization and too much granularity People with different skills should be working together What are the benefits of data model tuning? Tuning the data model can often provide performance improvements in excess of 100% but it is expensive because application code can be drastically affected SQL Code Tuning What is SQL code? SQL code is the code directly accessing the database, either embedded in applications or in stored procedures Sometimes generic SQL code is used, which is SQL code generated by an application on an ad hoc basis Generic SQL code can cause serious performance issues What causes SQL code performance problems and what is SQL code tuning? As with data modeling it is often confusing which personnel skill sets are responsible for SQL code tuning This is one of the causes of poorly performing SQL code Performance is served most effectively when developers and database administrators work together to a certain extent Poorly written SQL code is often the biggest culprit of performance problems; it is expensive to rectify but cheaper than changing the data model SQL code tends to be contained inside independent blocks within applications or stored procedures This containment is commonly known as embedded SQL code Tuning SQL code is in general a two-step process Isolation and recoding of the worst-performing SQL statements, perhaps the slowest-performing 10% of SQL code General tuning of SQL code involving changes to SQL statements throughout applications and the database, plus adjustments to alternate (secondary) indexing Alternate indexing is not specifically part of the steps of Normalization and Denormalization but can be designated as data modeling or SQL code tuning It is important that database administrators have some involvement with respect to alternate indexing, in the very least in an advisory capacity Too many or inappropriately constructed alternate indexes can completely destroy performance What are the benefits of SQL code tuning? SQL code tuning can increase performance between 25% and 100%, sometimes much more In rare situations I have seen enormous performance improvements when tuning SQL code One or two projects I have worked on in the past have been sped up 30 to 500 times, for both individual SQL code statements and sometimes even the applications in general Additionally SQL code is often embedded in applications in such a way that changing the SQL code does not affect application functionality Physical Database and Configuration Tuning What is physical and configuration tuning? Physical database tuning involves hardware resource usage, networking, and various other administration tasks such as configuration and file distribution What causes physical and configuration performance problems and what is physical and configuration tuning? Physical configuration is usually a culprit of poor performance where Oracle software is installed with defaults and never altered by an expert Quite often developers build table structures and SQL code In this case physical tuning is relied upon to solve performance problems This is usually a mistake since physical configuration tuning usually only provides at most 10-20% performance improvement What are the benefits of physical and configuration tuning? Physical and configuration tuning usually only results in at most a 25% performance improvement, and usually a lot less The relative cost of using physical and configuration tuning only is usually not cost effective Chapter 6: The Basics of Efficient SQL Figure 6.1: Row Counts of Accounts Schema Tables Chapter 7: Common Sense Indexing Figure 7.1: An Oracle Database BTree Index Figure 7.2: A Bitmap Index Figure 7.3: A Skewed BTree Index Figure 7.4: A Reverse Key Index Figure 7.5: A Compressed Composite-Column Index Figure 7.6: A Function-Based Index Chapter 8: Making SQL Efficient in Oracle Database Figure 8.1: An Example Histogram Figure 8.2: A Skewed BTree Index Figure 8.3: Passing a ROWID Pointer from an Index to a Table Chapter 10: Tuning SQL with Oracle Enterprise Manager Figure 10.1: The Index Tuning Wizard Figure 10.2: Select the Application Type Figure 10.3: Select Schemas to Analyze Figure 10.4: The Index Tuning Wizard Makes Suggestions Figure 10.5: SQL Analyze and the Analysis Stage Figure 10.6: SQL Analyze Single SQL Statement Assessment and Testing Figure 10.7: SQL Analyze SQL Text Display Figure 10.8: SQL Analyze Query Plan Figure 10.9: SQL Analyze Index Recommendations Figure 10.10: SQL Analyze Query Plan Assessment Figure 10.11: SQL Analyze Virtual Indexing, Hints, and Tuning Figure 10.12: Comparing Different Versions of an SQL Statement Figure 10.13: An ALL_ROWS Optimizer Query Plan Figure 10.14: A FIRST_ROWS Optimizer Query Plan Figure 10.15: Oracle Expert Recommendations for the Accounts Schema Chapter 11: Installing Oracle and Creating a Database Figure 11.1: Dedicated and Shared Servers Architecture Figure 11.2: Choosing the Appropriate Database Template Figure 11.3: Options and Examples when Creating a Database Figure 11.4: More Optional Database Features Figure 11.5: Choosing Dedicated or Shared Servers Figure 11.6: Oracle Database Memory Buffer Parameters Figure 11.7: The Sort Buffer Figure 11.8: Creation of Tablespaces and Datafiles Figure 11.9: Creation of Redo Logs Figure 11.10: Physical Datafile Default Structure Chapter 12: Tuning Oracle Database File Structures Figure 12.1: Oracle Instance Memory Cache Buffers Figure 12.2: Oracle Instance Process and Memory Layers Figure 12.3: The Oracle Database and the Oracle Instance Figure 12.4: Relationships Between Oracle Database Files Figure 12.5: Oracle Database Physical and Logical Structure Chapter 13: Object Tuning Figure 13.1: Nonparallel Versus Parallel Processing Chapter 14: Low-Level Physical Tuning Figure 14.1: Block Fixed Header Figure 14.2: Block Table Directory Figure 14.3: Block Row Directory Figure 14.4: Block Free Space Figure 14.5: Block Row Data Figure 14.6: Accounts Schema Current Row and Block Numbers Figure 14.7: Changes to Block Structure Space Usage Figure 14.8: Changes to Block Structure Concurrency Chapter 16: Tuning Network Usage Figure 16.1: Dedicated Versus Shared Servers Chapter 17: Oracle Partitioning and Parallelism Figure 17.1: Physical Partitioning Chapter 21: Tools and Utilities Figure 21.1: Defining Events for Detection and Resolution Figure 21.2: Monitoring and Managing Locking Figure 21.3: TopSessions Monitoring in a Specified Order Figure 21.4: TopSQL Statements Figure 21.5: The Performance Overview Tool Figure 21.6: The Performance Manager Main Screen Figure 21.7: Latch Get/Miss Rates Drilldown Figure 21.8: Latch Analysis Figure 21.9: After Execution of Tablespace Analysis Figure 21.10: What Should be Reorganized and Why Figure 21.11: After Reorganization and Coalescence on the INDX Tablespace Figure 21.12: Spotlight on Oracle Main Monitoring Screen Figure 21.13: Spotlight SGA View Figure 21.14: Various Spotlight Views Figure 21.15: The Windows Performance Monitor Figure 21.16: This is a Very Busy Server Chapter 22: Tuning with the Wait Event Interface and STATSPACK Figure 22.1: Tools for Drilling into the Oracle Database Wait Event Interface Figure 22.2: The System Aggregation Layer of the Oracle Database Wait Event Interface Figure 22.3: Isolating Segments using Event Parameters Figure 22.4: Session-Level Event and Wait Views Figure 22.5: Hooking Wait Events to Sessions Figure 22.6: Find SQL Code for Sessions Figure 22.7: Drilling Down into Latches Figure 22.8: Database Health Overview Chart– Database Memory Portion Figure 22.9: Database Health Overview Chart–Database Memory Portion Figure 22.10: Top Objects and TopSQL Appendix A: Sample Databases Figure A.1: Employees Schema ERD Version One Figure A.2: Employees Schema ERD Version Two Figure A.3: Accounts Schema ERD Denormalized Version Figure A.4: Accounts Schema ERD Normalized Version Back Cover Master the three parts of tuning an Oracle database: data modeling, SQL code tuning and physical database configuration A data model contains tables and relationships between tables Tuning a data model involves nNormalization and dDe-normalization Different approaches are required depending on the application, such as OLTP or a Data Warehouse Inappropriate database design can make SQL code impossible to tune Poor data modeling can have a most profound effect on database performance since all SQL code is constructed from the data model Poorly written SQL code is often a culprit in performance problems and is expensive to rectify However, tuning of SQL code is generally cheaper than changing the data model SQL code tend to be contained inside independent blocks within applications or stored procedures Physical database tuning involves hardware resource usage, networking and various other Oracle components such as configuration and file distribution Physical configuration is often a culprit of poor performance where Oracle is installed with defaults, and never altered by an expert Includes all three aspects of Oracle database tuning: data model tuning, SQL & PL/SQL code tuning, physical plus configuration tuning Contains experienced guidance and real-world examples using large datasets Emphasizes development as opposed to operating system perspective About the Author Gavin Powell BSc., Comp.Sci., OCP has fifteen years of diverse experience in database administration and database development in both relational and object databases His applications development experience is procedural and object-oriented and he also has some systems administration experience He consults for software vendors, Internet COMs (some of which unfortunately have met with their demise), accounting, banking, and financial services, the travel industry, construction, retail, mining, shipping, education and in a general advisory capacity .. .Oracle High Performance Tuning for 9i and 10g ISBN: 1555583059 by Gavin Powell Digital Press © 2004 (738 pages) This text covers the three parts of tuning an Oracle database: data modeling,... database: data modeling, SQL code tuning, and physical database configuration, and explains both problem detection and resolution Table of Contents Oracle High Performance Tuning for 9i and 10g Preface Introduction... Chapter 11 - Oracle High Performance Tuning for 9i and 10g Gavin Powell Digital Press is an imprint of Elsevier 200 Wheeler Road, Burlington, MA 01803, USA Linacre House, Jordan Hill, Oxford OX2 8DP, UK