Translated version of OPDT.

pdf
Page 1

Oracle Performance Diagnostics & Tuning 9iR1 to 11gR2 1 Ricardo Portilho Proni ricardo@nervinformatica.com.br This work is licensed under a license Creative Commons Attribution 3.0 Brazil-SemDerivados. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/3.0/br/.
Page 2

Performance Computing Systems can only be measured in TIME. Performance Tuning should be reactive. Performance Tuning should ROI. Only the biggest bottlenecks must be addressed. The process should be Diagnostics, Tuning and then. High CPU consumption is not a problem. The user does not execute a SQL for pleasure. The developer should not know how to make a good SQL (COBOL?). Graphical Tools / Enterprise Manager / Wizards / Automation are good helpers. Banks with good performance must be observed. Meet other RDBMSs: IT is no place for passions. Do not believe in anything (separate tables and indexes?). Test. If there was a parameter that always leave the Oracle faster, with no effect side, it would have enabled.

Develop a method of convincing management. Why call yourself something Storage, does not mean he has no problems. Kiss (keep it simple, stupid): the probability of failure increases linearly with increasing complexity. Learn Diser "No". Learn to say "I do not know." 2 My approach
Page 3

Performance Diagnostics & Tuning 3

Page 4

4 Mystification
Page 5

Older methods 5
Page 6

Experience Intuition Inaccuracy Time Luck Means 6 Requirements

Page 7

7 TOP Tuning Check largest consumer of CPU; Check the SQL aggressor; Change the SQL and expect performance improves; Add indexes and expected performance improves; If no improvement, kill the session. If performance does not improve, return to the beginning.
Page 8

Verify Operating System (free / taskmgr / Performance Monitor); Verify Operating System (vmstat / taskmgr / Performance Monitor); Verify Operating System (iostat / taskmgr / Performance Monitor); Check EMS; Check PGA; Check statistics collection; Check Parameters for Oracle; Check fragmentation of tables; Check Locks; Check SQLs that consume more resources; ... Build a theory based on observed data; Change something and expect performance improves; If the customer does not like the theory, just cite and change some parameters Related

 If performance does not improve, return to the beginning. 8 Tuning Checklist

Page 9

Check Buffer Cache Hit Ratio; Check Data Dictionary Hit Ratio; Check SQL Cache Hit Ratio; Check Library Cache Hit Ratio; ... Construct a theory based on observed data; Change something (usually increase) and expect that performance improves; If performance does not improve, return to the beginning. 9 Ratios Tuning
Page 10

KIWI = Kill It With Iron; Add RAM; Add CPUs; Improve I / O; Migrate to a larger server; Migrating to RAC; We add the RAC; ... Pay the bill, and expect the performance improves. If performance does not improve, return to the beginning. 10 KIWI Tuning

Page 11

Bank migrating to another server; Run Upgrade Database; Run the Upgrade Application; Run Middleware Upgrade; Add Application and Database; Separating Application and Database; Back Backups; ... If performance does not improve, try something else, even improve. 11 Tuning Manager
Page 12

What is wrong? 12
Page 13

13 Paradigm
Page 14

14 Legends of Oracle
Page 15

All your SELECT statement must use an index, so that it is fast. You will have an area of SWAP with double your RAM.

Utilizars not more than 50% of your RAM to SGA. Utilizars Hints for thou art wiser than Oracle. Not coletars statistics from the data dictionary. You should separate your data and indexes. You should separate your data in different tablespaces. Your datafiles should have a maximum 2GB / 10GB / xgb. Not habilitars AUTOEXTEND ON. You should run COMMIT every N lines. Utilizars RAID 5 because it is faster for reads Not suffer more than a SWITCH every 20 minutes. But you will not have big REDO logs. Executars REBUILD index regularly. Executars MOVE tables regularly. If the large table become the particionars. If you want more speed, you'll use RAC. The more CPUs, the faster your database will be. If your RATIOS are high, your users will be happy. Whenever possible, your aumentars DB_CACHE_SIZE and SHARED_POOL. Desabilitars AWR because it causes slowness. Not utilizars automatic memory. Thou art wiser than Oracle. Use, Wilt thou refuse to SGA_TARGET slightly smaller than the SGA_MAX_SIZE.

 AUTOMATIC SQL TUNING is one of the horsemen of the apocalypse. 15 Legends of Oracle
Page 16

His son takes 2 hours to buy milk at the bakery, car. How to improve this time? You need a car faster? You need two cars? It is necessary to make the road wider? It is best to only buy 1 liter of milk at a time? You must use a bakery that has only one type of milk? The garage door should always be open? 16 The car and milk
Page 17

The Rio needs to wake up at 03:30 to arrive in SP 09:00. How to improve this time? But Use a Concorde? Fly lower to the ground? Make the plane lighter, less transporting people and luggage? 17 Air bridge
Page 18

18 The head and the delay

Page 19

19

How to know who wins?

Page 20

The Correct Method 20

Page 21

21 The Black Death

Page 22

22 Time
Page 23

Computational time 23 R=S+W OR Service Response Time = Time + Wait Time

Page 24

24 Instrumentation: Mainframe
Page 25

25 Instrumentation: Solaris
Page 26

Oracle Wait Interface 26

Page 27

27 Oracle Wait Interface

Page 28

Benchmark 7.0.12: Juan Loainza Yapp Paper: Anjo Kolk

28 Birth of OWI
Page 29

Version 7.0.12: 104 Wait Events Version 8: 140 Wait Events Version 8i: Wait Events 220 Version 9i: 400 Waits Events Version 10gR1:> 800 Wait Events Version 11gR2:> Wait Events 1100 29 Evolution of OWI
Page 30

30 Enterprise Manager
Page 31

Basics 31
Page 32

32 Oracle Architecture
Page 33

db_block_size db_file_multiblock_read_count memory_max_target MEMORY_TARGET

 SGA_MAX_SIZE SGA_TARGET pga_aggregate_target db_cache_size (db_2k_cache_size, db_4k_cache_size, db_8k_cache_size ...) buffer_pool_keep, buffer_pool_recycle shared_pool_size, shared_pool_reserved_size LARGE_POOL_SIZE java_pool_size streams_pool_size result_cache_max_result, result_cache_max_size, result_cache_mode log_buffer fast_start_mttr_target LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT 33 Parameters elementary
Page 34

Hands ON! Parameters elementary 34

Page 35

Check the parameters in their elementary database. Change the parameter to 0 memory_max_target; Change parameter MEMORY_TARGET to 0;

 Change parameter SGA_MAX_SIZE to half the RAM of the machine; Change the parameter SGA_TARGET to 0; Change parameter db_cache_size for half SGA_MAX_SIZE. Change parameter shared_pool_size for half db_cache_size. Change parameter pga_aggregated_target to 100M; 35 Lab 1.1: Parameters elementary
Page 36

SQL Statement Session Instance 36 Granularities Analysis

Page 37

37 Scenarios Analysis Are slow now We slowness house that pushes

Page 38

Dynamic Performance Views Extended SQL Trace (Event 10046) Statspack / AWR 38 Analysis Tools

Page 39

Administrative Application Cluster Commit Concurrency Configuration Idle Network Other Queueing Scheduler System I / O User I / O 39 Wait Classes
Page 40

Limitations of OWI 40
Page 41

There is a monitoring End-to-End No data CPU consumption No consumption data memory Bugs Inaccuracies 41 Limitations: OWI
Page 42

No history 42 Limitations: Views

Page 43

Many data Very high granularity Performance Correlation of information Sessions PARALLEL Sessions SHARED SERVER Waits only available in> = 9iR1 Official support only> 10gR1 43 Limitations: Extended SQL Trace
Page 44

Grained Only history 44 Limitations: Statspack / AWR

Page 45

Hands ON! Dynamic Performance Views 45

Page 46

V $ SYSTEM_EVENT V $ session_event V $ SESSION_WAIT Check the Dynamic Performance Views OWI in your database. What are your most important columns?

 Waits that you have in your database? Become familiar with its contents. 46 Lab 2.1: Views
Page 47

Events most common Wait 47

Page 48

buffer busy free buffer read by oher session control file single write / control file parallel write / control file sequential read db file single write / db file parallel read / db file parallel write db file scatteread read / db file sequential read direct path read / write direct path enqueue free buffer free latch / latch: library cache / latch: cache buffers chains library cache pin / library cache lock log buffer space log file parallel write / log file single write / read log file sequential log file switch (archiving needed)

log file switch (checkpoint incomplete) / log file switch completion log file sync SQL * Net message from client / SQL * Net message to client SQL * Net more data from client / SQL * Net more data to client SQL * Net break / reset from client / SQL * Net break / reset to client 48 Events most common Wait
Page 49

Hands ON! Simulating Wait Events Recordings 49

Page 50

Enable the user SCOTT. SQL> ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY TIGER; SQL> GRANT SELECT ANY DICTIONARY TO SCOTT; Open a session with the SET TIMING ON SCOTT. SQL> CONN SCOTT / TIGER SQL> SET TIMING ON In another session, with SYS, check (again and again) content the V $ SESSION_WAIT during the execution of commands SCOTT follow. With the user SCOTT, create a large table, with at least 4GB. SQL> CREATE TABLE T AS SELECT * FROM ALL_OBJECTS; SQL> INSERT INTO T SELECT * FROM T; SQL> INSERT INTO T SELECT * FROM T; SQL> ... SQL> INSERT INTO T SELECT * FROM T; SQL> COMMIT; 50 Lab 3.1: Recordings
Page 51

Close and open the session with the SET TIMING ON SCOTT SQL> CONN SCOTT / TIGER

SQL> SET TIMING ON In another session, with SYS, check the contents of the V $ session_event related session of SCOTT. SQL> SELECT SID FROM V $ SESSION WHERE USERNAME = 'SCOTT'; SQL> SELECT EVENT, total_waits, TOTAL_TIMEOUTS, AVERAGE_WAIT FROM V $ session_event WHERE SID = 17 ORDER BY 4; With the user SCOTT, duplicate the big table. SQL> CREATE TABLE T2 AS SELECT * FROM T; In the session of SYS, after cloning the table, recheck contents of the V $ session_event related to session SCOTT Remove the table T2, close and open the session with Scott, and repeat operation. During the repetition of the operation, check the changes contents of the V $ session_event related to session SCOTT. 51 Lab 3.2: Recordings
Page 52

Answer the following questions: - Where was spending more time in this session? - The greatest referred to Wait Events? - What the biggest Wait Events can be reduced? - The deletion of a Wait Event that may be reduced to cause an improvement in how long? - How to reduce this Wait Event? Correct the cause of this Wait Event. Remove the table T2, close and open the session with Scott, and repeat. 52 Lab 3.3: Recordings
Page 53

Answer the following questions: - Where was spending more time in this session? - The greatest referred to Wait Events? - What the biggest Wait Events can be reduced? - The deletion of a Wait Event that may be reduced to cause an improvement in how long? - How to reduce this Wait Event? Correct the cause of this Wait Event. Remove the table T2, close and open the session with Scott, and repeat. 53 Lab 3.4: Recordings

Page 54

Verify the Dynamic Performance Views for your servers. Bring your questions to class. 54 Homework
Page 55

Extended SQL Trace 55

Page 56

0 = Standard Trace 4 = Bind Variables 8 = Wait States Bind Variables + 12 = Wait States 56 Levels Extended SQL Trace
Page 57

In any instance In his session In another session 57 Activate Extended SQL Trace
Page 58

58 Details Extended SQL Trace 2010-03-22 11:43:12.276 *** WAIT # 9: nam = 'db file scattered read' it = 183330 file # = 4 block # = 9124 blocks = 26 obj # = 74574

WAIT # 9: nam = 'db file scattered read' it = 2528 file # = 4 block # = 9150 blocks = 26 obj # = 74574 WAIT # 9: nam = 'db file scattered read' it = 170358 file # = 4 block # = 9176 blocks = 26 obj # = 74574 WAIT # 9: nam = 'db file scattered read' it = 96261 file # = 4 block # = 9202 blocks = 26 obj # = 74574 WAIT # 9: nam = 'db file scattered read' it = 1669 file # = 4 block # = 9228 blocks = 26 obj # = 74574 WAIT # 9: nam = 'db file scattered read' it = 26055 file # = 4 block # = 9254 blocks = 26 obj # = 74574 WAIT # 9: nam = 'db file scattered read' it = 4760 file # = 4 block # = 9280 blocks = 26 obj # = 74574 WAIT # 9: nam = 'db file scattered read' it = 108 783 file # = 4 block # = 9306 blocks = 26 obj # = 74574 tim = 1269268992840594 =====================
Page 59

59 tkprof
Page 60

There is a monitoring End-to-End No data CPU consumption No consumption data memory Bugs Inaccuracies Many data Very high granularity Performance Correlation of information

Sessions PARALLEL Sessions SHARED SERVER Waits only available in> = 9iR1 Official support only> 10gR1 60 Limitations: Extended Trace
Page 61

Hands ON! Extended SQL Trace Full Table Scan 61

Page 62

Close and open the session with the SET TIMING ON SCOTT SQL> EXIT $ Sqlplus SCOTT / TIGER SQL> SET TIMING ON With the SYS user, enable the Extended Trace session to SCOTT: SQL> SELECT S.USERNAME, P.SPID OS_PROCESS_ID, P.PID ORACLE_PROCESS_ID FROM V $ SESSION S, V $ PROCESS P WHERE S.PADDR = P.ADDR AND S.USERNAME = 'SCOTT'; SQL> oradebug setospid 8708; SQL> oradebug tracefile_name; SQL> oradebug unlimit; SQL> oradebug event 10046 trace name context forever, level 12; In another terminal, check the contents of the Trace. $ Tail-f / u01/app/oracle/diag/rdbms/test11gr2/TEST11GR2/trace/TEST11GR2_ora_8708.trc 62 Lab 4.1: Extended SQL Trace
Page 63

With the user SCOTT, delete the contents of the large table, change the value db_file_multiblock_read_count parameter (only in the session) and reinsert data.

SQL> TRUNCATE TABLE T2; SQL> ALTER SESSION SET db_file_multiblock_read_count = 8; SQL> INSERT INTO T2 SELECT * FROM T; SQL> COMMIT; Keep checking the contents of the Trace during execution of the operation. At the end of the run, check the values of the V $ session_event session of SCOTT. Keep this outcome. Run tkprof the trace generated. $ Tkprof / u01/app/oracle/diag/rdbms/test11gr2/TEST11GR2/trace/TEST11GR2_ora_8708.trc Review the report generated by tkprof. Repeat, but with db_file_multiblock_read_count 50 and 1000. 63 Lab 4.2: Extended SQL Trace
Page 64

Wait Events - Details 64

Page 65

65 Teaching to Fish
Page 66

66 Reference
Page 67

67 Performance Tuning Guide

Page 68

68 MOS
Page 69

Explanation: The requested block is in use, because another session is loading block to DB_CACHE_SIZE, or other session is using the block DB_CACHE_SIZE in a manner inconsistent. Cause: DB_CACHE_SIZE insufficient or inefficient SQL.

Correction: Increase DB_CACHE_SIZE or change the SQL. P1: Number of DATAFILE. P2: Block number. P3: id - the request comes from different places of the session. 69 buffer busy
Page 70

70 buffer busy
Page 71

Explanation: The RDBMS waits DB_CACHE_SIZE free blocks. Cause: Insufficient DB_CACHE_SIZE. Correction: Increase DB_CACHE_SIZE. P1: Number of DATAFILE. P2: Block number. 71 free buffer
Page 72

Explanation: The requested block is in use, because another session is loading block to DB_CACHE_SIZE, or other session is using the block DB_CACHE_SIZE in a manner inconsistent. Cause: DB_CACHE_SIZE insufficient or inefficient SQL. Correction: Increase DB_CACHE_SIZE or change the SQL. P1: Number of DATAFILE. P2: Block number. P3: Reason (<10g). P3: Wait Class (> = 10g). 72 read by other session
Page 73

Explanation: Waiting for I / O to write to CONTROLFILEs. Cause: Excess recording in CONTROLFILEs or I / O inefficient. Correction: Minimize the recordings in CONTROLFILEs or improve the mechanism I/O P1: Quntidade of CONTROLFILEs. P2: Number of blocks. P3: Number of requests for I / O.

73 control file parallel write

Page 74

Explanation: Waiting for I / O to write to CONTROLFILEs. Cause: Excess recording in CONTROLFILEs or I / O inefficient. Correction: Minimize the recordings in CONTROLFILEs or improve the mechanism I/O P1: Number CONTROLFILE. P2: Block number. P3: Number of blocks. 74 control file single write
Page 75

Explanation: Waiting for I / O to read the CONTROLFILEs. Cause: Too much reading in CONTROLFILEs or I / O inefficient. Correction: Minimize the readings in CONTROLFILEs or enhance the mechanism I/O P1: Number CONTROLFILE. P2: Block number. P3: Number of blocks. 75 control file sequential read
Page 76

Explanation: Writes data in datafiles waiting for I / O. Cause: Excess recordings or slow I / O. Correction: Minimize the recordings or improve the mechanism of I / O. P1: Number of requests. P2: Interrupt. P3: Timeout. 76 db file parallel write
Page 77

Explanation: A record in the HEADER DATAFILE waiting for I / O. Cause: Too many datafiles of recordings in HEADER or slow I / O. Correction: Minimize the recordings in the HEADER datafiles or improve engine I / O. P1: Number of requests.

P2: Interrupt. P3: Timeout. 77 db file single write

Page 78

Explanation: During RECOVER or during prefetching, readings Datafiles waiting for I / O. Cause: RECOVER too long, excessive prefetching, or slow I / O. Correction: Accelerate RECOVER, minimize prefetching, and improves the engine I / O. P1: Number of datafiles. P2: Number of blocks. P3: Number of requests. 78 db file parallel read
Page 79

79 User I / O
Page 80

CURSOR_SHARING Db_file_multiblock_read_count OPTIMIZER_INDEX_CACHING OPTIMIZER_INDEX_COST_ADJ Optimizer_mode PGA_AGGREGATE_TARGET STAR_TRANSFORMATION_ENABLED 80 Influencing the Optimizer
Page 81

Explanation: During FTS, readings DataFiles waiting for I / O.

Cause: Insufficient DB_CACHE_SIZE, FTS unnecessary or slow I / O Correction: Increase DB_CACHE_SIZE, delete the FTS, or improve engine I / O. P1: Number of DATAFILE. P2: First block. P3: Number of blocks. 81 db file scattered read
Page 82

Explanation: While reading a block, waiting for readings Datafiles engine I / O. Cause: Insufficient DB_CACHE_SIZE, reading unnecessary or slow I / O Correction: Increase DB_CACHE_SIZE, eliminate unnecessary reading or improve engine I / O. P1: Number of DATAFILE. P2: First block. P3: Number of blocks. 82 db file sequential read
Page 83

Explanation: Read / write between datafiles / tempfiles and PGA. Cause: PGA insufficient or slow I / O. Correction: Increase the PGA, or improve the mechanism of I / O. P1: File number (DATAFILE or tempfile). P2: First block. P3: Number of blocks. 83 direct path read / write direct path
Page 84

Explanation: Mechanism orderly queue RDBMS. Cause: Various, depending on the type of queue. Correction: Various, depending on the type of queue. P1: type or mode of enqueue. P2: ID1 (as in V $ LOCK). P3: ID2 (as in V $ LOCK). Most common problems: TX Transaction

 TM, DML Enqueue HW, High-Water Lock SQ, Sequence Number Enqueue CF controlfile Transaction 84 enqueue
Page 85

Explanation: Mechanism disorderly queue RDBMS. Cause: Various, depending on the type of queue. Correction: Various, depending on the type of queue. P1: Address Latch (as in V $ LATCH). P2: Number Latch (as in V $ LATCH). P3: Number of attempts. Most common problems: shared pool library cache cache buffers lru chain cache buffers chains row cache objects 85 latch free
Page 86

Explanation: Using incompatible object between two sessions. Cause: Use of object that conflicts between two sessions. Correction: End the use of the object by one of the sessions. P1: Address object. P2: Address of the load lock. P3: Mode + Namespace. SQL> SELECT / * + ORDERED * / W1.SID WAITING_SESSION, H1.SID HOLDING_SESSION,

W.KGLLKTYPE LOCK_OR_PIN, W.KGLLKHDL ADDRESS, DECODE (H.KGLLKMOD, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive', 'Unknown') MODE_HELD, DECODE (W.KGLLKREQ, 0, 'None', 1, 'Null', 2, 'Share', 3, 'Exclusive', 'Unknown') MODE_REQUESTED FROM DBA_KGLLOCK W, DBA_KGLLOCK H, W1 V $ SESSION, V $ SESSION WHERE H1 (((H.KGLLKMOD! = 0) AND (H.KGLLKMOD! = 1) AND ((H.KGLLKREQ = 0) OR (H.KGLLKREQ = 1))) AND (((W.KGLLKMOD = 0) OR (W.KGLLKMOD = 1)) AND ((W.KGLLKREQ! = 0) AND (W.KGLLKREQ! = 1)))) AND W.KGLLKTYPE = H.KGLLKTYPE AND W.KGLLKHDL = H.KGLLKHDL AND W.KGLLKUSE = W1.SADDR AND H.KGLLKUSE = H1.SADDR; SQL> SELECT FROM V $ TO_NAME OBJECT_DEPENDENCY WHERE TO_ADDRESS = '0700000010F62750 '; 86 library cache pin / library cache lock
Page 87

Explanation: More space is needed to LOG_BUFFER recordings. Cause: LOG_BUFFER insufficient REDO logs insufficient or slow I / O. Correction: Increase LOG_BUFFER, increase the amount / REDO tamanhode Logs, or improve the mechanism of I / O. P1: Number of REDO logs. P2: Number of blocks of the operating system. P3: Number of requests for I / O. 87 log buffer space
Page 88

Explanation: During recording REDO logs, LGWR wait for I / O. Cause: Too many members in groups REDO logs or slow I / O. Fix: Reduce the amount of members in groups or REDO logs improve engine I / O. P1: Number of REDO logs. P2: Number of blocks operating system. P3: Number of requests for I / O. 88 log file parallel write

Page 89

Explanation: During the recording of a HEADER REDO logs, LGWR waiting for I / O. Cause: Excessive writes to the REDO LOG HEADER or slow I / O. Fix: Reduce the amount of recordings in the REDO LOG HEADER or improve engine I / O. P1: Number REDO LOG. P2: Block number. P3: Number of blocks. 89 log file single write
Page 90

Explanation: During reading REDO logs, LGWR wait for I / O. Cause: Slow I / O. Correction: Improve the mechanism of I / O. P1: Number REDO LOG. P2: Block number. P3: Number of blocks. 90 log file sequential read
Page 91

Explanation: All groups REDO logs were used and are still needed for a possible RECOVER because the ARCn not yet created the ARCHIVED REDO logs and DBWR has not recorded in its content Datafiles. Cause: REDO logs undersized, improperly configured destination ARCHIVED REDO logs or the I / O inefficient. Correction: Increase the REDO logs in quantity and / or size, fix the target configuration of ARCn or improve the mechanism for I / O. P1: Not used. P2: Not used. P3: not used. Variations: log file switch (archiving needed) log file switch (checkpoint incomplete)

log file switch (clearing log file) log file switch (private strand flush incomplete) log file switch completion 91 log file switch
Page 92

Explanation: A CHECKPOINT was executed, and must be recorded in the REDO LOG and LGRW mechanism is waiting for I / O. Cause: COMMIT excessive amount or I / O inefficient. Remedy: Reduce the number of commits or optimize the mechanism of I / O. P1: Number of Log Buffer. P2: Not used. P3: not used. 92 log file sync
Page 93

Explanation: Waiting for network communication with the SQL * Net protocol Cause: Session idle, network latency or client throttling. Correction: Remove the inactive session, minimize latency in the network, or minimize the limitation the client. P1: Driver Network. P2: Number of bytes. P3: not used. Variations SQL * Net message from client SQL * Net message to client SQL * Net more data from client SQL * Net more data to client SQL * Net break / reset to client SQL * Net message from dblink

 SQL * Net message to dblink SQL * Net more data from dblink SQL * Net more data to dblink SQL * Net break / reset to dblink 93 SQL * Net message to / from client
Page 94

Hands ON! Simulating Wait Events DBWR LGWR x 94

Page 95

Close and open the session with the SET TIMING ON SCOTT SQL> CONN SCOTT / TIGER SQL> SET TIMING ON With the user SCOTT, delete the contents of the large table, and reinsert the data. SQL> TRUNCATE TABLE T2; SQL> INSERT INTO T2 SELECT * FROM T; SQL> COMMIT; At the end of the run, check the values of V $ session_event session the SCOTT. Store the result. Change the parameter value to log_buffer 512k, repeat the operation, and compare. Change the parameter value to log_buffer 10m, repeat the operation, and compare. Change the parameter value to log_buffer 100m, repeat the operation, and compare. Keep log_buffer with the most optimized configuration. Change parameter FAST_START_MTTR_TARGET to 1, repeat the operation, and compare. 95 Lab 5.1: x DBWR LGWR

Page 96

Parallel SQL 96
Page 97

Allows Query, DML and DDL. An object can have permanent Parallel, independent of SQL: SQL> ALTER TABLE SCOTT.T PARALLEL DEGREE 4; Parallel SQL can be used directly in SQL: SQL> SELECT / * + PARALLEL (T2, 4) * / COUNT (*) FROM T2; 97 Parallel SQL
Page 98

Parameters: PARALLEL_ADAPTIVE_MULTI_USER = true or false. PARALLEL_AUTOMATIC_TUNING: Deprecated. PARALLEL_DEGREE_LIMIT = CPU, IO or number. PARALLEL_DEGREE_POLICY = MANUAL, AUTO or LIMITED. From PARALLEL_EXECUTION_MESSAGE_SIZE = 2148-32768 PARALLEL_FORCE_LOCAL = true or false. PARALLEL_INSTANCE_GRouP Oracle RAC = service_name or group_name. PARALLEL_IO_CAP_ENABLED = Deprecated. From PARALLEL_MAX_SERVERS = 0-3600. PARALLEL_MIN_PERCENT = From 0 to 100. PARALLEL_MIN_SERVERS = number between 0 and PARALLEL_MAX_SERVERS. PARALLEL_MIN_TIME_THRESHOLD = AUTO | Seconds. PARALLEL_SERVERS_TARGET = number between 0 and PARALLEL_MAX_SERVERS. PARALLEL_THREADS_PER_CPU = any number. 98 Parallel SQL
Page 99

Hands ON! Simulating Wait Events Design Application 99

Page 100

Restart the Instance. Check the contents of the V $ SYSTEM_EVENT. Save this query. Open the session with the SET TIMING ON SCOTT. Then do a SELECT of the whole table. $ Sqlplus SCOTT / TIGER SQL> SET TIMING ON SQL> SELECT COUNT (*) FROM T; At the end of the run, check the values of the V $ session_event session of SCOTT. Store the result. Repeat with PARALLEL and compare. SQL> SELECT / * + PARALLEL (T 4) * / COUNT (*) FROM T; SQL> SELECT / * + PARALLEL (T 20) * / COUNT (*) FROM T; 100 Lab 6.1: Design Application
Page 101

101 Lab 6.2: Design Application Create this table with the user SCOTT: SQL> CREATE TABLE T3 (NUMBER NUMBER); Note the contents of the following Perl scripts, run them, and compare: $ Perl / home / oracle / CommitNOK_BindsNOK.pl $ Perl / home / oracle / CommitNOK_BindsOK.pl $ Perl / home / oracle / CommitOK_BindsNOK.pl $ Perl / home / oracle / CommitOK_BindsOK.pl
Page 102

102 Lab 6.3: Design Application Create a bitmap index on table T3 with the user SCOTT: SQL> CREATE BITMAP INDEX ON IDX_BITMAP_T3 T3 (NUMBER); Execute an INSERT in this table, without running COMMIT or close session.: SQL> INSERT INTO T3 VALUES (1); Open another session with Scott and do another INSERT on table T3: SQL> INSERT INTO T3 VALUES (1); With the SYS user, check the V $ SESSION_WAIT. Repeat the exercise, but using a BTREE index: SQL> DROP INDEX IDX_BITMAP_T3; SQL> CREATE INDEX ON IDX_T3 T3 (NUMBER);

Page 103

103 Lab 6.4: Design Application Open a session with the user SCOTT with SET TIMING ON: Create a BTREE index on the OWNER column of the table T: SQL> CREATE INDEX ON IDX_T T (OWNER); Run this SQL: SQL> SELECT COUNT (*) FROM T T_ALIAS WHERE OBJECT_NAME = 'T'; With the SYS user, check the contents of the V $ session session_event the SCOTT. Store the result. Close and open the session with the SET TIMING ON SCOTT Change the session to use the Rule Based Optimizer: SQL> ALTER SESSION SET optimizer_mode = RULE; Run this SQL: SQL> SELECT / * + INDEX (T_ALIAS, IDX_T) * / COUNT (*) FROM T WHERE T_ALIAS OBJECT_NAME = 'T';
Page 104

Statistics 104
Page 105

Optimizer Statistics Table statistics Number of rows Number of blocks Average row length Column statistics Number of distinct values (NDV) in column Number of nulls in column Data distribution (histogram) Extended statistics Index statistics Number of leaf blocks Levels Clustering factor System Statistics I / O performance and utilization CPU performance and utilization

105 Statistics
Page 106

DBMS_AUTO_TASK_ADMIN.DISABLE DBMS_STATS.GATHER_DATABASE_STATS DBMS_STATS.GATHER_DICTIONARY_STATS DBMS_STATS.GATHER_SCHEMA_STATS DBMS_STATS.GATHER_TABLE_STATS DBMS_STATS.GATHER_INDEX_STATS DBMS_STATS.DELETE_TABLE_STATS DBMS_STATS.LOCK_TABLE_STATS * DBMS_STATS.EXPORT_ _STATS * DBMS_STATS.IMPORT_ _STATS OPTIMIZER_DYNAMIC_SAMPLING DBMS_STATS.GATHER_SYSTEM_STATS 106 Statistics
Page 107

Hands ON! DBMS_SQLTUNE 107

Page 108

108 Lab 7.1: DBMS_SQLTUNE Choose one of SQLs slower in V $ SQL and analysis with DBMS_SQLTUNE. DECLARE RET_VAL VARCHAR2 (4000); BEGIN RET_VAL: = DBMS_SQLTUNE.CREATE_TUNING_TASK (SQL_ID => '12345678910 ', SCOPE => DBMS_SQLTUNE.SCOPE_COMPREHENSIVE, TIME_LIMIT => 60, TASK_NAME => 'Portilho Tuning Task' DESCRIPTION => 'Portilho Tuning Task'); END; / BEGIN DBMS_SQLTUNE.EXECUTE_TUNING_TASK ('Portilho Tuning Task'); END; /

SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK ('Portilho Tuning Task') FROM RECOMMENTATION DUAL; SELECT DBMS_SQLTUNE.SCRIPT_TUNING_TASK ('Portilho Tuning Task') FROM RECOMMENTATION DUAL; BEGIN DBMS_SQLTUNE.DROP_TUNING_TASK ('Portilho Tuning Task'); END; /
Page 109

Fragmentation 109
Page 110

Logically contiguous blocks physically scattered. Free Space TABLESPACE / datafiles. TABLE clear. Free space on INDEX. Row Chaining. Migrated Rows. Extents. 110 Fragmentation
Page 111

111 Fragmentation: COALESCE

Page 112

112 Fragmentation: COALESCE

Page 113

113 Fragmentation: Row Chaining

Page 114

114 Fragmentation: Row Migration

Page 115

Hands ON! DBMS_ADVANCED_REWRITE 115

Page 116

116 Lab 8.1: DBMS_ADVANCED_REWRITE Open a session with the user SCOTT with SET TIMING ON: Change the session to use the Rule Based Optimizer: SQL> ALTER SESSION SET optimizer_mode = RULE; Run this SQL and note its runtime: SQL> SELECT / * + INDEX (T_ALIAS, IDX_T) * / COUNT (*) FROM T WHERE T_ALIAS OBJECT_NAME = 'T'; Run this SQL and note its runtime: SQL> SELECT COUNT (*) FROM T T_ALIAS WHERE OBJECT_NAME = 'T'; With the SYS user, give the necessary permissions for the user SCOTT DBMS_ADVANCED_REWRITE use: $ Sqlplus / AS SYSDBA SQL> GRANT EXECUTE ON DBMS_ADVANCED_REWRITE TO SCOTT; SQL> GRANT CREATE MATERIALIZED VIEW TO SCOTT;
Page 117

117 Lab 8.2: DBMS_ADVANCED_REWRITE SCOTT user's session, run the DBMS_ADVANCE_REWRITE: BEGIN SYS.DBMS_ADVANCED_REWRITE.DECLARE_REWRITE_EQUIVALENCE ( NAME => 'PORTILHO_REWRITE' SOURCE_STMT => 'SELECT / * + INDEX (T_ALIAS, IDX_T) * / COUNT (*) FROM T WHERE T_ALIAS

OBJECT_NAME ='' T'' ' DESTINATION_STMT => 'SELECT COUNT (OBJECT_NAME) FROM T WHERE T_ALIAS OBJECT_NAME ='' T'' ' VALIDATE => FALSE, REWRITE_MODE => 'TEXT_MATCH'); END; / Rerun this SELECT and check its runtime: SQL> SELECT / * + INDEX (T_ALIAS, IDX_T) * / COUNT (*) FROM T T_ALIAS WHERE OBJECT_NAME = 'T'; Remove the REWRITE rerun the SELECT and check your time implementation: SQL> EXEC SYS.DBMS_ADVANCED_REWRITE.DROP_REWRITE_EQUIVALENCE (NAME => 'PORTILHO_REWRITE'); SQL> SELECT / * + INDEX (T_ALIAS, IDX_T) * / COUNT (*) FROM T T_ALIAS WHERE OBJECT_NAME = 'T';
Page 118

The database is slow now. Finding evidence of bottleneck in V $ SESSION_WAIT. Finding the SID in V $ SESSION_WAIT. Find the largest Wait Event in V $ session_event. Correct the largest Wait Event possible. The database was slow yesterday. Finding evidence of bottleneck in V $ SYSTEM_EVENT. Find the largest Wait Event via Statspack / AWR. Correct the largest Wait Event possible.

 This SQL is slow. Run with Extended SQL Trace. Find the largest Wait Event via tkprof. Correct the largest Wait Event possible. 118 Scenarios Analysis
Page 119

Statspack / AWR 119

Page 120

Statspack / SPreport $ Sqlplus / AS SYSDBA SQL> @? / Rdbms / admin / spcreate.sql SQL> @? / Rdbms / admin / spauto.sql SQL> EXECUTE STATSPACK.SNAP; SQL> @? / Rdbms / admin / spreport.sql AWR / ASH Report SQL> EXEC dbms_workload_repository.create_snapshot; SQL> @? / Rdbms / admin / awrrpt.sql 120 Statspack / AWR
Page 121

Hands ON! Statspack / AWR 121

Page 122

Create TABLESPACE called SOE with AUTOEXTEND ON. Take SNAPSHOT loose. $ Sqlplus / AS SYSDBA SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT; Run the schema creation SOE. Swingbench $ cd / bin

. / Oewizard Take another SNAPSHOT loose. $ Sqlplus / AS SYSDBA SQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT; Get a report comparing the two AWR snapshots. SQL> @? / Rdbms / admin / awrrpt.sql Review the AWR report. 122 Lab 9.1: AWR
Page 123

Resource Plan 123

Page 124

Separation of Resources by: Oracle_user SERVICE_NAME CLIENT_OS_USER CLIENT_PROGRAM CLIENT_MACHINE MODULE_NAME MODULE_NAME_ACTION SERVICE_MODULE SERVICE_MODULE_ACTION Control of Resources: CPU Active Sessions Parallelism

 I / O (> = 11gR1) 124 Resource Plan

Page 125

125 Resource Plan

Page 126

Change of plans: ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'peaktime'; ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'OFF-PEAK'; Monitoring: DBA_RSRC_CONSUMER_GROUP_PRIVS DBA_RSRC_PLANS V $ SESSION V $ RSRC_PLAN V $ RSRC_CONSUMER_GROUP V $ RSRC_SESSION_INFO V $ RSRC_PLAN_HISTORY V $ RSRC_CONS_GROUP_HISTORY V $ RSRCMGRMETRIC V $ RSRCMGRMETRIC_HISTORY 126 Resource Plan
Page 127

LAB 11 - Resource Plan Hands On! 127

Page 128

Analyze the code file ResourcePlan.sql. Change the file to meet the needs of three types of use of bank data: User SOE: OLTP, should have a high priority during the day and low at night. User HR: BI should have little pridoridade much during the day and at night. User SCOTT: You can only use CPU that none of the above users are using. Others can only use CPU that none of the above users are using. 128 Lab 10.1 - Resource Plan
Page 129

Review 129
Page 130

The database is slow now: Finding evidence of bottleneck in V $ SYSTEM_EVENT. Finding evidence of bottleneck in V $ SESSION_WAIT. Finding (s) SID (s) in V $ SESSION_WAIT offender. Find the largest Wait this Event (s) SID (s) in V $ session_event. Correct the largest Wait Event possible. If the time this satisfactory, terminate the process. The database was slow yesterday: Finding evidence of bottleneck in V $ SYSTEM_EVENT. Find the largest Wait Event via Statspack / AWR.

 Correct the largest Wait Event possible. If the time this satisfactory, terminate the process. This SQL is slow: Run the SQL command with Extended SQL Trace. Find evidence of the bottleneck when running SQL Trace. Find the largest Wait Event via tkprof. Correct the largest Wait Event possible. If the time this satisfactory, terminate the process. 130 Tuning method