1. INTRODUCTION TO ORACLE Lynnwood Brown System Managers LLC Performance And Tuning – Lecture 7 Copyright System Managers LLC 2007 all rights reserved.

2. PERFORMANCE and TUNING It is useful to subdivide RDBMS performance analysis and tuning into two subcategories: System analysis and tuning SQL statement tuning System analysis and tuning can be divided into three subcategories: Memory CPU IO

3. SYSTEM PERFORMANCE ANALYSIS On Windows machines use Task Manager to investigate CPU and memory usage: Memory usage should be less then 90%. CPU usage should be less then 90%.

4. SYSTEM PERFORMANCE ANALYSIS On UNIX machines use the OS utilities such as TOP or SAR to get CPU utilization statistics: oracle% sar -u 09:30:53 %usr %sys %wio %idle 09:30:58 60 10 8 22 CPU statistics - %SYS greater then 20% is bad Disk IO statistics - %WIO greater then 15% is bad Copyright System Managers LLC 2007 all rights reserved.

5. SYSTEM PERFORMANCE ANALYSIS Useful UNIX Commands: swap - Will provide us with the usage of swap space including the RAM. sar - Will provide CPU usage and system idle time information. top - Will provide information about top CPU consuming processes vmstat - Will provide information about process paging and swapping Copyright System Managers LLC 2007 all rights reserved.

6. SYSTEM PERFORMANCE ANALYSIS File placement rules Make sure that log files and archived log files are NOT on the same disk as data files. Place UNDO and System Tablespace data files on the same disks, Index and Data files on their own disk, and TEMP (sorting) data files on its own disk. Consider using RAID level 5 disk striping to stripe your data files across multiple disks Copyright System Managers LLC 2007 all rights reserved.

7. SYSTEM PERFORMANCE ANALYSIS Memory management tuning – How well is Oracle managing the memory that is allocated to it. The DBA should compute the following memory management statistics: Database buffer cache hit ratio greater then 95% Redo log buffer waits equal to 0 Data dictionary cache less then 10% Library cache between 1% and 3% Sort area ratio – Sorts performed in memory versus. sorts performed on the disk should be around 10%

8. SYSTEM PERFORMANCE ANALYSIS Dynamic Performance Views The Oracle RDBMS places system performance information in its dynamic performance views: Database buffer cache hit ratio – V$SYSSTAT Redo log buffer waits – V$SYSSTAT Data dictionary cache – V$ROWCACHE Library cache – V$LIBRARYCACHE Sort area ratio – V$SYSSTAT Copyright System Managers LLC 2007 all rights reserved.

9. SYSTEM PERFORMANCE ANALYSIS Oracle database tuning parameters are located in the init.ora file. These parameters control the size of the Oracle SGA. The parameters include: DB_BLOCK_BUFFERS - Database buffer cache SHARED_POOL_SIZE – The library cache plus the data dictionary cache are called the shared pool LOG_BUFFERS - Redo log buffer SORT_AREA_SIZE – Sort buffer

10. System Performance:Table Fragmentation Fragmentation occurs: Over time as rows get deleted, updated or inserted. A segment is fragmented when some free space exists in the blocks but not sufficient space in any of them for Oracle to be able to insert a new one. When a row that originally fitted into one data block is updated so that the overall row length increases, and the block's free space is already completely filled, Oracle migrates the data for the row to a new data block: but Oracle must scan more than one data block to retrieve the information for that row.

11. System Performance:Table Fragmentation SQL> analyze table scott, BIG1 compute statistics; SQL> select table_name,round((blocks*8),2)||'kb' "size"2 from user_tables3 where table_name = 'BIG1'; TABLE_NAME size BIG1 72952kb SQL> select table_name,round((num_rows*avg_row_len/1024),2 )||'kb' "size"2 from user_tables3 where table_name = 'BIG1'; TABLE_NAME size BIG1 30604.2kb Wasted space in table = 72952 - 30604 = 42348 Kb

12. System Performance:Table Fragmentation SQL> alter table BIG1 move; SQL> analyze table scott, BIG1 compute statistics; SQL> select table_name,round((blocks*8),2)||'kb' "size"2 from user_tables3 where table_name = 'BIG1'; TABLE_NAME size BIG1 38224kb SQL> select table_name,round((num_rows*avg_row_len/1024),2 )||'kb' "size"2 from user_tables3 where table_name = 'BIG1'; TABLE_NAME size BIG1 30727.37kb Wasted space in table = 38224 - 30727.37 = 7497Kb

13. System Performance:Table Fragmentation By following a simple set of rules, fragmentation at the extent level can be eliminated: Rule1: All the segments in a tablespace should have exactly the same extent size. This ensures that any free extent in a tablespace can always be used for any segment in the tablespace. Rule2: All segments should inherit the storage values from the storage clause of the tablespace. Rule3: Very large segments (bigger that 4G) should be should be placed their own tablespaces that do not contain any other data.

14. System Performance:Table Fragmentation It is worthwhile to rebuild a table if the tables HWM does not change after data has been deleted from the table : SQL > select (blocks - empty_blocks -1) “HWM” from dba_tables; The data dictionary view DBA_TABLES provides fragmentation statistics after “ANALYZE” or “DBMS_STATS” has been run. Fragmentation Columns in DBA_TABLES: CHAIN_CNT is increasing due to migrated rows AVG_SPACE is increasing because of deletes

15. SQL STATEMENT TUNING Table Access Full Table Scan - In a FTS operation, the entire table is read up to the high water mark (HWM). –The HWM marks the last block in the table that has ever had data written to it. Index lookup - Data is accessed by looking up key values in an index and returning rowids. –A rowid uniquely identifies an individual row.

16. SQL STATEMENT TUNING Query processing can be divided into 7 phases: Syntactic - checks the syntax of the query Semantic - checks that all objects exist and are accessible View Merging - rewrites query as join on base tables Statement Transformation - rewrites query transforming complex constructs into simpler ones Copyright System Managers LLC 2007 all rights reserved.

17. SQL STATEMENT TUNING Optimization - Determines the optimal access path for the query to take (init.ora parameter: OPTIMIZER_GOAL=RULE/CHOOSE). –Rule Based Optimizer (RBO) - Uses a set of heuristics to determine the objects access path –. Cost Based Optimizer (CBO) - Uses table statistics to analyze the relative costs of accessing objects. Query/Explain Evaluation Plan Generation Query/Explain Evaluation Plan Execution

18. SQL STATEMENT TUNING An explain plan is a representation of the access path that is taken when a query is executed Example FTS explain/query plan for: SQL> select * from dual; Query Plan SELECT STATEMENT [CHOOSE] Cost= TABLE ACCESS FULL DUAL Copyright System Managers LLC 2007 all rights reserved.

19. SQL STATEMENT TUNING Example of an index lookup explain plan for: SQL > select empno,ename from emp where empno=10; Query Plan SELECT STATEMENT [CHOOSE] Cost=TABLE ACCESS BY ROWID EMP [ANALYZED] INDEX UNIQUE SCAN EMP_I1 Copyright System Managers LLC 2007 all rights reserved.

20. SQL STATEMENT TUNING Is a view being accessed? Get the view text from DBA_VIEWS and tune the SQL that the view is based on. SQL > select text from dba_views where view_name = ‘MY_VIEW’; Copyright System Managers LLC 2007 all rights reserved.

21. SQL STATEMENT TUNING Indexes are optional database structures associated with tables and are created to speed access to data within a table. B-TREE most common index type used in OLTP applications Bit Mapped - Specifically designed to improve performance of queries in data warehouse (OLAP) applications Creating a B-Tree index: Create index I_my_index on table_name(column_name);

22. SQL STATEMENT TUNING Index Rules Index columns that are used in WHERE clauses Do not index small tables Index columns that are used in “JOIN” clauses Only index columns with good selectivity. The query should return no more then 25 – 30 % of the data in the table Columns that are frequently modified should not be indexed Columns that only appear in WHERE clauses with functions or operators should not be indexed.

23. SQL STATEMENT TUNING SQL statement tuning can be accomplished using the SQL*PLUS feature AUTOTRACE. This will display a short version of the EXPLAIN plan on the screen after the SQL statement is executed. To turn on AUTOTRACE SQL> set autotrace traceonly explain Copyright System Managers LLC 2007 all rights reserved.

24. SQL STATEMENT TUNING A file containing the SQL trace information can be created by altering the end user SQL*PLUS session. The trace information will be written into the trace file (.trc file extension) directory. This directory is pointed to by the init.ora parameter USER_DUMP_DEST. SQL > ALTER SESSION SET SQL_TRACE = TRUE; TKPROF is an Oracle supplied OS level utility that is used to format the SQL trace file. C:> TKPROF.trc sql_results.sav SORT=(EXECPU,FCHCPU) EXPLAIN= user_ID/passwd