translated version of opdt

7/27/2019 Translated Version of OPDT

1/41

Translated version of OPDT.pdfPage 1

Oracle Performance Diagnostics & Tuning9iR1 to 11gR2

1Ricardo Portilho [email protected] work is licensed under a licenseCreative Commons Attribution 3.0 Brazil-SemDerivados.To view a copy of this license, visithttp://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 effectside, it would have enabled.
mailto:[email protected]:[email protected]:[email protected]


2/41

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

increasingcomplexity.Learn Diser "No".Learn to say "I do not know."2My approach

Page 3

Performance Diagnostics & Tuning3

Page 4

4

Mystification

Page 5

Older methods

5

Page 6

ExperienceIntuitionInaccuracyTimeLuckMeans6Requirements


3/41

Page 7

7TOP Tuning Check largest consumer of CPU; Check the SQL aggressor; Change the SQL and expect performance improves; Add indexes and expectedperformance 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 parametersRelated


4/41

If performance does not improve, return to the beginning.8Tuning 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.

9Ratios 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.10KIWI Tuning


5/41

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.11Tuning Manager

Page 12

What is wrong?

12

Page 13

13Paradigm

Page 14

14Legends 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.


6/41

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 readsNot 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.


7/41


8/41


9/41

28Birth of OWI

Page 29

Version 7.0.12: 104 Wait EventsVersion 8: 140 Wait EventsVersion 8i: Wait Events 220Version 9i: 400 Waits EventsVersion 10gR1:> 800 Wait Events

Version 11gR2:> Wait Events 110029Evolution of OWI

Page 30

30Enterprise Manager

Page 31

Basics31

Page 32

32Oracle Architecture

Page 33

db_block_sizedb_file_multiblock_read_countmemory_max_targetMEMORY_TARGET


10/41

SGA_MAX_SIZESGA_TARGET

pga_aggregate_targetdb_cache_size (db_2k_cache_size, db_4k_cache_size, db_8k_cache_size ...)buffer_pool_keep, buffer_pool_recycleshared_pool_size, shared_pool_reserved_sizeLARGE_POOL_SIZEjava_pool_sizestreams_pool_sizeresult_cache_max_result, result_cache_max_size, result_cache_modelog_bufferfast_start_mttr_target

LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT33Parameters elementary

Page 34

Hands ON!Parameters elementary34

Page 35Check the parameters in their elementary database.Change the parameter to 0 memory_max_target; Change parameterMEMORY_TARGETto 0;


11/41

Change parameterSGA_MAX_SIZEto half the RAM of the machine;Change the parameterSGA_TARGETto 0;

Change parameterdb_cache_size for halfSGA_MAX_SIZE.Change parametershared_pool_size for halfdb_cache_size.Change parameterpga_aggregated_targetto 100M;35Lab 1.1: Parameters elementary

Page 36

SQL StatementSessionInstance36Granularities Analysis

Page 37

37Scenarios AnalysisAre slow nowWe slowness house that pushes

Page 38

Dynamic Performance Views

Extended SQL Trace (Event 10046)Statspack / AWR38Analysis Tools


12/41

Page 39

Administrative Application Cluster Commit Concurrency Configuration Idle Network Other QueueingScheduler System I / O User I / O

39Wait Classes

Page 40

Limitations of OWI40

Page 41

There is a monitoring End-to-End

No data CPU consumptionNo consumption data memoryBugsInaccuracies41Limitations: OWI

Page 42

No history42Limitations: Views


13/41

Page 43

Many dataVery high granularityPerformanceCorrelation of informationSessions PARALLELSessions SHARED SERVER

Waits only available in> = 9iR1Official support only> 10gR143Limitations: Extended SQL Trace

Page 44

Grained

Only history44Limitations: Statspack / AWR

Page 45

Hands ON!Dynamic Performance Views45

Page 46

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


14/41

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

Page 47

Events most common Wait47

Page 48

buffer busy

free bufferread by oher sessioncontrol file single write / control file parallel write / control file sequential readdb file single write / db file parallel read / db file parallel writedb file scatteread read / db file sequential read

direct path read / write direct pathenqueuefree bufferfree latch / latch: library cache / latch: cache buffers chainslibrary cache pin / library cache lock

log buffer spacelog file parallel write / log file single write / read log file sequentiallog file switch (archiving needed)


15/41

log file switch (checkpoint incomplete) / log file switch completionlog file syncSQL * Net message from client / SQL * Net message to client

SQL * Net more data from client / SQL * Net more data to clientSQL * Net break / reset from client / SQL * Net break / reset to client48Events most common Wait

Page 49

Hands ON!

Simulating Wait EventsRecordings49

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 ONIn another session, with SYS, check (again and again) contentthe V $ SESSION_WAIT during the execution of commands SCOTTfollow.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;50Lab 3.1: Recordings

Page 51

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


16/41

SQL> SET TIMING ONIn another session, with SYS, check the contents of the V $ session_eventrelated 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, recheckcontents of the V $ session_event related to session SCOTTRemove the table T2, close and open the session with Scott, and repeatoperation.During the repetition of the operation, check the changescontents of the V $ session_event related to session SCOTT.51Lab 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 howlong?- 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.52Lab 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 howlong?- 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


17/41


18/41

WAIT # 9: nam = 'db file scattered read' it = 2528 file # = 4 block # = 9150 blocks =26 obj # = 74574WAIT # 9: nam = 'db file scattered read' it = 170358 file # = 4 block # = 9176 blocks= 26 obj # = 74574WAIT # 9: nam = 'db file scattered read' it = 96261 file # = 4 block # = 9202 blocks =

26 obj # = 74574WAIT # 9: nam = 'db file scattered read' it = 1669 file # = 4 block # = 9228 blocks =26 obj # = 74574WAIT # 9: nam = 'db file scattered read' it = 26055 file # = 4 block # = 9254 blocks =26 obj # = 74574WAIT # 9: nam = 'db file scattered read' it = 4760 file # = 4 block # = 9280 blocks =26 obj # = 74574WAIT # 9: nam = 'db file scattered read' it = 108 783 file # = 4 block # = 9306 blocks= 26 obj # = 74574tim = 1269268992840594=====================

Page 59

59tkprof

Page 60

There is a monitoring End-to-End

No data CPU consumptionNo consumption data memoryBugsInaccuraciesMany data

Very high granularityPerformanceCorrelation of information


19/41

Sessions PARALLELSessions SHARED SERVERWaits only available in> = 9iR1

Official support only> 10gR160Limitations: Extended Trace

Page 61

Hands ON!Extended SQL TraceFul l Table Scan

61

Page 62

Close and open the session with the SET TIMING ON SCOTTSQL> EXIT$ Sqlplus SCOTT / TIGERSQL> SET TIMING ONWith the SYS user, enable the Extended Trace session to SCOTT:SQL> SELECT S.USERNAME, P.SPID OS_PROCESS_ID, P.PIDORACLE_PROCESS_ID

FROM V $ SESSION S, V $ PROCESS P WHERE S.PADDR = P.ADDR ANDS.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

62Lab 4.1: Extended SQL Trace

Page 63

With the user SCOTT, delete the contents of the large table, change the valuedb_file_multiblock_read_count parameter (only in the session) and reinsertdata.


20/41

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_eventsession of SCOTT.Keep this outcome.Run tkprof the trace generated.$ Tkprof /u01/app/oracle/diag/rdbms/test11gr2/TEST11GR2/trace/TEST11GR2_ora_8708.trcReview 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 - Details64

Page 65

65Teaching to Fish

Page 66

66Reference

Page 67

67Performance Tuning Guide

Page 68

68

MOS

Page 69

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


21/41

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.69buffer busy

Page 70

70buffer 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 loadingblock to DB_CACHE_SIZE, or other session is using the blockDB_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).72read 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 mechanismI / OP1: Quntidade of CONTROLFILEs.P2: Number of blocks.P3: Number of requests for I / O.


22/41


23/41

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

Page 78

Explanation: During RECOVER or during prefetching, readingsDatafiles waiting for I / O.Cause: RECOVER too long, excessive prefetching, or slow I / O.Correction: Accelerate RECOVER, minimize prefetching, and improves theengine I / O.P1: Number of datafiles.P2: Number of blocks.P3: Number of requests.

78db file parallel read

Page 79

79User I / O

Page 80

CURSOR_SHARING

Db_file_multiblock_read_countOPTIMIZER_INDEX_CACHINGOPTIMIZER_INDEX_COST_ADJOptimizer_modePGA_AGGREGATE_TARGET

STAR_TRANSFORMATION_ENABLED80Influencing the Optimizer

Page 81

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


24/41

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

Page 82

Explanation: While reading a block, waiting for readings Datafilesengine I / O.Cause: Insufficient DB_CACHE_SIZE, reading unnecessary or slow I / OCorrection: Increase DB_CACHE_SIZE, eliminate unnecessary reading or

improve engine I / O.P1: Number of DATAFILE.P2: First block.P3: Number of blocks.82db 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.83direct 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


25/41

TM, DML EnqueueHW, High-Water Lock

SQ, Sequence Number EnqueueCF controlfile Transaction84enqueue

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 poollibrary cache

cache buffers lru chaincache buffers chainsrow cache objects85latch 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.SIDHOLDING_SESSION,


26/41

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 WHERETO_ADDRESS ='0700000010F62750 ';86library 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 logsimprove 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


27/41

Page 89

Explanation: During the recording of a HEADER REDO logs, LGWRwaiting 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 orimprove engine I / O.P1: Number REDO LOG.P2: Block number.P3: Number of blocks.89log 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.90log file sequential read

Page 91

Explanation: All groups REDO logs were used and are stillneeded for a possible RECOVER because the ARCn not yet created theARCHIVED REDO logs and DBWR has not recorded in its contentDatafiles.Cause: REDO logs undersized, improperly configured destinationARCHIVED REDO logs or the I / O inefficient.Correction: Increase the REDO logs in quantity and / or size, fix thetarget 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)


28/41

log file switch (clearing log file)log file switch (private strand flush incomplete)log file switch completion

91log file switch

Page 92

Explanation: A CHECKPOINT was executed, and must be recorded in the REDOLOG 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.92log file sync

Page 93

Explanation: Waiting for network communication with the SQL * Net protocolCause: Session idle, network latency or client throttling.Correction: Remove the inactive session, minimize latency in the network, orminimize the limitation

the client.P1: Driver Network.P2: Number of bytes.P3: not used.VariationsSQL * Net message from clientSQL * Net message to client

SQL * Net more data from clientSQL * Net more data to clientSQL * Net break / reset to clientSQL * Net message from dblink


29/41

SQL * Net message to dblinkSQL * Net more data from dblink

SQL * Net more data to dblinkSQL * Net break / reset to dblink93SQL * Net message to / from client

Page 94

Hands ON!Simulating Wait Events

DBWR LGWR x94

Page 95

Close and open the session with the SET TIMING ON SCOTTSQL> CONN SCOTT / TIGERSQL> SET TIMING ONWith the user SCOTT, delete the contents of the large table, and reinsert thedata.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 sessionthe 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,

andcompare.95Lab 5.1: x DBWR LGWR


30/41

Page 96

Parallel SQL96

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;97Parallel 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-32768PARALLEL_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 andPARALLEL_MAX_SERVERS.PARALLEL_MIN_TIME_THRESHOLD = AUTO | Seconds.PARALLEL_SERVERS_TARGET = number between 0 andPARALLEL_MAX_SERVERS.PARALLEL_THREADS_PER_CPU = any number.98Parallel SQL

Page 99

Hands ON!Simulating Wait EventsDesign Application99


31/41

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 / TIGERSQL> SET TIMING ONSQL> SELECT COUNT (*) FROM T;At the end of the run, check the values of the V $ session_eventsession 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 ApplicationCreate 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

102Lab 6.3: Design ApplicationCreate 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 closesession.: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);


32/41


33/41

105Statistics

Page 106

DBMS_AUTO_TASK_ADMIN.DISABLEDBMS_STATS.GATHER_DATABASE_STATSDBMS_STATS.GATHER_DICTIONARY_STATSDBMS_STATS.GATHER_SCHEMA_STATSDBMS_STATS.GATHER_TABLE_STATSDBMS_STATS.GATHER_INDEX_STATSDBMS_STATS.DELETE_TABLE_STATSDBMS_STATS.LOCK_TABLE_STATS* DBMS_STATS.EXPORT_ _STATS* DBMS_STATS.IMPORT_ _STATS

OPTIMIZER_DYNAMIC_SAMPLINGDBMS_STATS.GATHER_SYSTEM_STATS106Statistics

Page 107

Hands ON!DBMS_SQLTUNE107

Page 108108Lab 7.1: DBMS_SQLTUNEChoose one of SQLs slower in V $ SQL and analysis with DBMS_SQLTUNE.DECLARE RET_VAL VARCHAR2 (4000);BEGINRET_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;/


34/41

SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK ('Portilho Tuning Task')FROM RECOMMENTATIONDUAL;SELECT DBMS_SQLTUNE.SCRIPT_TUNING_TASK ('Portilho Tuning Task')FROM RECOMMENTATION

DUAL;BEGIN DBMS_SQLTUNE.DROP_TUNING_TASK ('Portilho Tuning Task'); END;/

Page 109

Fragmentation109

Page 110

Logically contiguous blocks physically scattered.Free Space TABLESPACE / datafiles.TABLE clear.Free space on INDEX.Row Chaining.

Migrated Rows.Extents.110Fragmentation

Page 111

111Fragmentation: COALESCE

Page 112

112Fragmentation: COALESCE

Page 113


35/41


36/41

OBJECT_NAME ='' T'' 'DESTINATION_STMT => 'SELECT COUNT (OBJECT_NAME) FROM TWHERE T_ALIASOBJECT_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 TT_ALIAS WHERE OBJECT_NAME = 'T';

Remove the REWRITE rerun the SELECT and check your timeimplementation:SQL> EXECSYS.DBMS_ADVANCED_REWRITE.DROP_REWRITE_EQUIVALENCE(NAME =>'PORTILHO_REWRITE');SQL> SELECT / * + INDEX (T_ALIAS, IDX_T) * / COUNT (*) FROM TT_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.


37/41

This SQL is slow.Run with Extended SQL Trace.

Find the largest Wait Event via tkprof.Correct the largest Wait Event possible.118Scenarios Analysis

Page 119

Statspack / AWR119

Page 120

Statspack / SPreport$ Sqlplus / AS SYSDBASQL> @? / Rdbms / admin / spcreate.sqlSQL> @? / Rdbms / admin / spauto.sqlSQL> EXECUTE STATSPACK.SNAP;SQL> @? / Rdbms / admin / spreport.sqlAWR / ASH Report

SQL> EXEC dbms_workload_repository.create_snapshot; SQL> @? / Rdbms / admin / awrrpt.sql120Statspack / AWR

Page 121

Hands ON!Statspack / AWR121

Page 122

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


38/41

. / OewizardTake another SNAPSHOT loose.$ Sqlplus / AS SYSDBASQL> EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT;Get a report comparing the two AWR snapshots.SQL> @? / Rdbms / admin / awrrpt.sqlReview the AWR report.122Lab 9.1: AWR

Page 123

Resource Plan123

Page 124Separation of Resources by:Oracle_userSERVICE_NAMECLIENT_OS_USERCLIENT_PROGRAM

CLIENT_MACHINEMODULE_NAMEMODULE_NAME_ACTIONSERVICE_MODULESERVICE_MODULE_ACTION

Control of Resources:CPUActive SessionsParallelism


39/41

I / O (> = 11gR1)124Resource 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_PRIVSDBA_RSRC_PLANSV $ SESSIONV $ RSRC_PLANV $ RSRC_CONSUMER_GROUP

V $ RSRC_SESSION_INFOV $ RSRC_PLAN_HISTORYV $ RSRC_CONS_GROUP_HISTORYV $ RSRCMGRMETRICV $ RSRCMGRMETRIC_HISTORY

126Resource Plan

Page 127

LAB 11 - Resource PlanHands On!127


40/41

Page 128

Analyze the code file ResourcePlan.sql.Change the file to meet the needs of three types of use of bankdata: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

Review129

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.


41/41

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.130Tuning method

translated version of opdt

Documents