translated version of opdt
TRANSCRIPT
-
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] -
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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.
-
7/27/2019 Translated Version of OPDT
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/27/2019 Translated Version of OPDT
7/41
-
7/27/2019 Translated Version of OPDT
8/41
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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;
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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?
-
7/27/2019 Translated Version of OPDT
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)
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
17/41
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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.
-
7/27/2019 Translated Version of OPDT
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.
-
7/27/2019 Translated Version of OPDT
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.
-
7/27/2019 Translated Version of OPDT
22/41
-
7/27/2019 Translated Version of OPDT
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.
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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,
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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)
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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);
-
7/27/2019 Translated Version of OPDT
32/41
-
7/27/2019 Translated Version of OPDT
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;/
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
35/41
-
7/27/2019 Translated Version of OPDT
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.
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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
-
7/27/2019 Translated Version of OPDT
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.
-
7/27/2019 Translated Version of OPDT
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