SlideShare a Scribd company logo
1 of 13
Download to read offline
Oracle Diagnostics
Hemant K Chitale
Hemant K Chitale
• whoami ?
• Oracle 5 to Oracle 10gR2 : DOS, Xenix,8
flavours of Unix, Linux, Windows
• Financial Services, Govt/Not-for-Profit, ERP,
Custom
• Production Support, Consulting, Development
• A DBA, not a Developer
• My Oracle Blog http://hemantoracledba.blogspot.com
Oracle Diagnostics – Joins (1)
• For “Explain Plans” see my earlier presentation
OracleDiagnostics_Explain_Plans__simple (or
at WizIQ)
• This presentation is based on the case study
Nested Loops and Consistent Gets
A Nested Loop join
• In a Nested Loop join, Oracle uses the rowset
retrieved from the “outer” (driving) table to query
the “inner” (driven) table
• The Optimizer would choose a Nested Loop join
if it expects to be able to retrieve the rowset of
the outer table very quickly *and* expects that
the size would be small enough to not require
querying the inner table too frequently
Given this query :
SQL> explain plan for
2 select product_desc, txn_id, transaction_amt
3 from transactions t, product_table p
4 where txn_date between to_date('01-FEB-2011','DD-MON-YYYY')
and to_date('28-FEB-2011','DD-MON-YYYY')
5 and txn_id between 155000 and 156000
6 and country_cd = 'IN'
7 and t.product_cd=p.product_cd
8 /
We expect a Join between TRANSACTIONS and PRODUCT_TABLE
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------
----------------------
Plan hash value: 1299935411
--------------------------------------------------------------------------------------------------------------
-----------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
Pstart| Pstop |
--------------------------------------------------------------------------------------------------------------
-----------
| 0 | SELECT STATEMENT | | 1 | 63 | 25 (0)| 00:00:01 |
| |
| 1 | NESTED LOOPS | | | | | |
| |
| 2 | NESTED LOOPS | | 1 | 63 | 25 (0)| 00:00:01 |
| |
| 3 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 |
2 | 2 |
|* 4 | TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTIONS | 1 | 51 | 24 (0)| 00:00:01 |
2 | 2 |
|* 5 | INDEX RANGE SCAN | TRANSACTIONS_NDX | 252 | | 4 (0)| 00:00:01 |
2 | 2 |
|* 6 | INDEX UNIQUE SCAN | SYS_C0016611 | 1 | | 0 (0)| 00:00:01 |
| |
| 7 | TABLE ACCESS BY INDEX ROWID | PRODUCT_TABLE | 1 | 12 | 1 (0)| 00:00:01 |
| |
-------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - filter("TXN_DATE"<=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
5 - access("COUNTRY_CD"='IN' AND "TXN_ID">=155000 AND "TXN_ID"<=156000)
6 - access("T"."PRODUCT_CD"="P"."PRODUCT_CD")
SQL>
.
Here :
| 3 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01
| 2 | 2 |
|* 4 | TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTIONS | 1 | 51 | 24 (0)| 00:00:01
| 2 | 2 |
|* 5 | INDEX RANGE SCAN | TRANSACTIONS_NDX | 252 | | 4 (0)| 00:00:01
| 2 | 2 |
Predicate Information :
4 - filter("TXN_DATE"<=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
5 - access("COUNTRY_CD"='IN' AND "TXN_ID">=155000 AND "TXN_ID"<=156000)
The execution is done in this sequence :
Step 1 : Operation 5 : Index Range Scan (expected to retrieve 252 rowids),
accessing the TRANSACTIONS_NDX index by COUNTRY_CD = ‘IN’ and
TXN_ID between 155000 and 156000
Step 2 : Operation 4 : Table Access of TRANSACTIONS, using the RowIDs
fetched from Operation 5. For every row fetched by RowID, filter for
TXN_DATE less than 28-Feb-11. Expect to return only 1 single row after
the filter for TXN_DATE (note : This is key to the optimizer’s choice of a Nested
Loop join)
Parent Step 3 : Operation 3 : Determine that this is a Range Scan within
Partition 2 (Start and Stop Partition IDs being “2” and “2”). This range scan will
return the single row from Operation 4.
Continuing with the other operations :
| 2 | NESTED LOOPS | | 1 | 63 | 25 (0)| 00:00:01
| | |
| 3 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01
| 2 | 2 |
|* 6 | INDEX UNIQUE SCAN | SYS_C0016611 | 1 | | 0 (0)| 00:00:01
| | |
Predicate Information :
6 - access("T"."PRODUCT_CD"="P"."PRODUCT_CD")
Step 4 Operation 2 : For the expected single row returned from the Partition
Range (in Operation 3), call Operation 6 to scan the Unique Index
SYS_C0016611. The Index Unique Scan is expected to be executed once
only (as Operation 3 returns 1 row) and, in-turn, expected to return a single
RowID (being a Unique Index scan)
This Index is the Primary Key index for PRODUCT_TABLE. The Index Scan is
for the PRODUCT_CD retrieved the previous step.
| 1 | NESTED LOOPS | | | | |
| | |
| 7 | TABLE ACCESS BY INDEX ROWID | PRODUCT_TABLE | 1 | 12 | 1 (0)| 00:00:01
| | |
Step 6 Operation 1 : For the single RowID expected from Operation 6, access
the PRODUCT_TABLE. (Since the previous step expects to return a single
RowID, this step, too, expects to read a single row from the table).
Hash Join
• This is a demonstration of a Hash Join from the
same case study
• In a Hash Join, Oracle attempts to retrieve all
the join column values from the first table,
compute “hash” values and place them in
memory
• It then expects to probe the second table and
compare the values with the in-memory hash
table. A match is a “join”
• Performance of a Hash Join depends on the size
of the join key and the available memory for the
in-memory Hash Table
For this query :
SQL> explain plan for
2 select /*+ USE_HASH (t p) */ product_desc, txn_id,
transaction_amt
3 from transactions t, product_table p
4 where txn_date between to_date('01-FEB-2011','DD-MON-YYYY')
and to_date('28-FEB-2011','DD-MON-YYYY')
5 and txn_id between 155000 and 156000
6 and country_cd = 'IN'
7 and t.product_cd=p.product_cd
8 /
We have explicitly provided a Hint (directive) to Oracle to execute a Hash Join
between the two tables
It is
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------
------------------------
Plan hash value: 971735053
------------------------------------------------------------------------------------------------------------
------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
Pstart| Pstop |
------------------------------------------------------------------------------------------------------------
------------
| 0 | SELECT STATEMENT | | 1 | 63 | 28 (4)| 00:00:01 |
| |
|* 1 | HASH JOIN | | 1 | 63 | 28 (4)| 00:00:01 |
| |
| 2 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 |
2 | 2 |
|* 3 | TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTIONS | 1 | 51 | 24 (0)| 00:00:01 |
2 | 2 |
|* 4 | INDEX RANGE SCAN | TRANSACTIONS_NDX | 252 | | 4 (0)| 00:00:01 |
2 | 2 |
| 5 | TABLE ACCESS FULL | PRODUCT_TABLE | 14 | 168 | 3 (0)| 00:00:01 |
| |
------------------------------------------------------------------------------------------------------------
------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("T"."PRODUCT_CD"="P"."PRODUCT_CD")
3 - filter("TXN_DATE"<=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
4 - access("COUNTRY_CD"='IN' AND "TXN_ID">=155000 AND "TXN_ID"<=156000)
SQL>
Here :
| 2 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 |
2 | 2 |
|* 3 | TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTIONS | 1 | 51 | 24 (0)| 00:00:01 |
2 | 2 |
|* 4 | INDEX RANGE SCAN | TRANSACTIONS_NDX | 252 | | 4 (0)| 00:00:01 |
2 | 2 |
Predicate Information :
3 - filter("TXN_DATE"<=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
4 - access("COUNTRY_CD"='IN' AND "TXN_ID">=155000 AND "TXN_ID"<=156000)
Step 1 : Operation 4 : Retrieve 252 RowIDs from the TRANSACTIONS_NDX
Step 2 : Operation 3 : Use the 252 RowIDs to lookup the TRANSACTIONS table
and filter to TXN_DATE. Expect to return a single row
Parent Step 3 : Confirm that these steps are executed against a single Partition
Here :
|* 1 | HASH JOIN | | 1 | 63 | 28 (4)| 00:00:01 |
| |
| 2 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 |
2 | 2 |
| 5 | TABLE ACCESS FULL | PRODUCT_TABLE | 14 | 168 | 3 (0)| 00:00:01 |
| |
Predicate Information :
1 - access("T"."PRODUCT_CD"="P"."PRODUCT_CD")
Step 4 Operation 1: For the single row returned from the Partition Range
Scan,execute a Hash Join. The hashed value(s) for this row are stored in an
in-memory hash area
Step 5 : Operation 5 : Probe the PRODUCT_TABLE (via a FullTableScan) to
read 14 rows. Place the values in memory and attempt a join on PRODUCT_CD.

More Related Content

What's hot

Metadata Matters
Metadata MattersMetadata Matters
Metadata Matters
afa reg
 
Oracle Diagnostics : Explain Plans (Simple)
Oracle Diagnostics : Explain Plans (Simple)Oracle Diagnostics : Explain Plans (Simple)
Oracle Diagnostics : Explain Plans (Simple)
Hemant K Chitale
 
Adaptive Query Optimization in 12c
Adaptive Query Optimization in 12cAdaptive Query Optimization in 12c
Adaptive Query Optimization in 12c
Anju Garg
 
Indexes: Structure, Splits and Free Space Management Internals
Indexes: Structure, Splits and Free Space Management InternalsIndexes: Structure, Splits and Free Space Management Internals
Indexes: Structure, Splits and Free Space Management Internals
Christian Antognini
 

What's hot (20)

SQL Plan Directives explained
SQL Plan Directives explainedSQL Plan Directives explained
SQL Plan Directives explained
 
Full Table Scan: friend or foe
Full Table Scan: friend or foeFull Table Scan: friend or foe
Full Table Scan: friend or foe
 
Managing Statistics for Optimal Query Performance
Managing Statistics for Optimal Query PerformanceManaging Statistics for Optimal Query Performance
Managing Statistics for Optimal Query Performance
 
Metadata Matters
Metadata MattersMetadata Matters
Metadata Matters
 
SQL Tuning, takes 3 to tango
SQL Tuning, takes 3 to tangoSQL Tuning, takes 3 to tango
SQL Tuning, takes 3 to tango
 
Do You Know The 11g Plan?
Do You Know The 11g Plan?Do You Know The 11g Plan?
Do You Know The 11g Plan?
 
Checking clustering factor to detect row migration
Checking clustering factor to detect row migrationChecking clustering factor to detect row migration
Checking clustering factor to detect row migration
 
Oracle Diagnostics : Explain Plans (Simple)
Oracle Diagnostics : Explain Plans (Simple)Oracle Diagnostics : Explain Plans (Simple)
Oracle Diagnostics : Explain Plans (Simple)
 
Adaptive Query Optimization in 12c
Adaptive Query Optimization in 12cAdaptive Query Optimization in 12c
Adaptive Query Optimization in 12c
 
Oracle sql high performance tuning
Oracle sql high performance tuningOracle sql high performance tuning
Oracle sql high performance tuning
 
Sql and PL/SQL Best Practices I
Sql and PL/SQL Best Practices ISql and PL/SQL Best Practices I
Sql and PL/SQL Best Practices I
 
An Approach to Sql tuning - Part 1
An Approach to Sql tuning - Part 1An Approach to Sql tuning - Part 1
An Approach to Sql tuning - Part 1
 
A few things about the Oracle optimizer - 2013
A few things about the Oracle optimizer - 2013A few things about the Oracle optimizer - 2013
A few things about the Oracle optimizer - 2013
 
Character Encoding - MySQL DevRoom - FOSDEM 2015
Character Encoding - MySQL DevRoom - FOSDEM 2015Character Encoding - MySQL DevRoom - FOSDEM 2015
Character Encoding - MySQL DevRoom - FOSDEM 2015
 
Optimizer features in recent releases of other databases
Optimizer features in recent releases of other databasesOptimizer features in recent releases of other databases
Optimizer features in recent releases of other databases
 
Indexes: Structure, Splits and Free Space Management Internals
Indexes: Structure, Splits and Free Space Management InternalsIndexes: Structure, Splits and Free Space Management Internals
Indexes: Structure, Splits and Free Space Management Internals
 
MariaDB: Engine Independent Table Statistics, including histograms
MariaDB: Engine Independent Table Statistics, including histogramsMariaDB: Engine Independent Table Statistics, including histograms
MariaDB: Engine Independent Table Statistics, including histograms
 
MySQL Query tuning 101
MySQL Query tuning 101MySQL Query tuning 101
MySQL Query tuning 101
 
Basic MySQL Troubleshooting for Oracle Database Administrators
Basic MySQL Troubleshooting for Oracle Database AdministratorsBasic MySQL Troubleshooting for Oracle Database Administrators
Basic MySQL Troubleshooting for Oracle Database Administrators
 
5 Cool Things About SQL
5 Cool Things About SQL5 Cool Things About SQL
5 Cool Things About SQL
 

Similar to Oracle Diagnostics : Joins - 1

Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Understanding Query Optimization with ‘regular’ and ‘Exadata’ OracleUnderstanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Guatemala User Group
 
Writing efficient sql
Writing efficient sqlWriting efficient sql
Writing efficient sql
j9soto
 
Database & Technology 1 _ Tom Kyte _ SQL Techniques.pdf
Database & Technology 1 _ Tom Kyte _ SQL Techniques.pdfDatabase & Technology 1 _ Tom Kyte _ SQL Techniques.pdf
Database & Technology 1 _ Tom Kyte _ SQL Techniques.pdf
InSync2011
 
Scaling MySQL Strategies for Developers
Scaling MySQL Strategies for DevelopersScaling MySQL Strategies for Developers
Scaling MySQL Strategies for Developers
Jonathan Levin
 
15 protips for mysql users pfz
15 protips for mysql users   pfz15 protips for mysql users   pfz
15 protips for mysql users pfz
Joshua Thijssen
 

Similar to Oracle Diagnostics : Joins - 1 (20)

Oracle 122 partitioning_in_action_slide_share
Oracle 122 partitioning_in_action_slide_shareOracle 122 partitioning_in_action_slide_share
Oracle 122 partitioning_in_action_slide_share
 
Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Understanding Query Optimization with ‘regular’ and ‘Exadata’ OracleUnderstanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle
 
Writing efficient sql
Writing efficient sqlWriting efficient sql
Writing efficient sql
 
Top 10 tips for Oracle performance
Top 10 tips for Oracle performanceTop 10 tips for Oracle performance
Top 10 tips for Oracle performance
 
Performance Schema for MySQL Troubleshooting
Performance Schema for MySQL TroubleshootingPerformance Schema for MySQL Troubleshooting
Performance Schema for MySQL Troubleshooting
 
Understand the Query Plan to Optimize Performance with EXPLAIN and EXPLAIN AN...
Understand the Query Plan to Optimize Performance with EXPLAIN and EXPLAIN AN...Understand the Query Plan to Optimize Performance with EXPLAIN and EXPLAIN AN...
Understand the Query Plan to Optimize Performance with EXPLAIN and EXPLAIN AN...
 
MySQL 8.0 EXPLAIN ANALYZE
MySQL 8.0 EXPLAIN ANALYZEMySQL 8.0 EXPLAIN ANALYZE
MySQL 8.0 EXPLAIN ANALYZE
 
Dbms plan - A swiss army knife for performance engineers
Dbms plan - A swiss army knife for performance engineersDbms plan - A swiss army knife for performance engineers
Dbms plan - A swiss army knife for performance engineers
 
MySQL 8 -- A new beginning : Sunshine PHP/PHP UK (updated)
MySQL 8 -- A new beginning : Sunshine PHP/PHP UK (updated)MySQL 8 -- A new beginning : Sunshine PHP/PHP UK (updated)
MySQL 8 -- A new beginning : Sunshine PHP/PHP UK (updated)
 
MySQL 8.0 New Features -- September 27th presentation for Open Source Summit
MySQL 8.0 New Features -- September 27th presentation for Open Source SummitMySQL 8.0 New Features -- September 27th presentation for Open Source Summit
MySQL 8.0 New Features -- September 27th presentation for Open Source Summit
 
Oracle 11g caracteristicas poco documentadas 3 en 1
Oracle 11g caracteristicas poco documentadas 3 en 1Oracle 11g caracteristicas poco documentadas 3 en 1
Oracle 11g caracteristicas poco documentadas 3 en 1
 
Noinject
NoinjectNoinject
Noinject
 
Introduction into MySQL Query Tuning
Introduction into MySQL Query TuningIntroduction into MySQL Query Tuning
Introduction into MySQL Query Tuning
 
Top 10 Oracle SQL tuning tips
Top 10 Oracle SQL tuning tipsTop 10 Oracle SQL tuning tips
Top 10 Oracle SQL tuning tips
 
Quick Wins
Quick WinsQuick Wins
Quick Wins
 
Indexes From the Concept to Internals
Indexes From the Concept to InternalsIndexes From the Concept to Internals
Indexes From the Concept to Internals
 
Database & Technology 1 _ Tom Kyte _ SQL Techniques.pdf
Database & Technology 1 _ Tom Kyte _ SQL Techniques.pdfDatabase & Technology 1 _ Tom Kyte _ SQL Techniques.pdf
Database & Technology 1 _ Tom Kyte _ SQL Techniques.pdf
 
Scaling MySQL Strategies for Developers
Scaling MySQL Strategies for DevelopersScaling MySQL Strategies for Developers
Scaling MySQL Strategies for Developers
 
Beyond php - it's not (just) about the code
Beyond php - it's not (just) about the codeBeyond php - it's not (just) about the code
Beyond php - it's not (just) about the code
 
15 protips for mysql users pfz
15 protips for mysql users   pfz15 protips for mysql users   pfz
15 protips for mysql users pfz
 

More from Hemant K Chitale (8)

SQL Tracing
SQL TracingSQL Tracing
SQL Tracing
 
Oracle : Monitoring and Diagnostics without OEM
Oracle : Monitoring and Diagnostics without OEMOracle : Monitoring and Diagnostics without OEM
Oracle : Monitoring and Diagnostics without OEM
 
Oracle Diagnostics : Latches and Enqueues
Oracle Diagnostics : Latches and EnqueuesOracle Diagnostics : Latches and Enqueues
Oracle Diagnostics : Latches and Enqueues
 
Oracle Diagnostics : Locks and Lock Trees
Oracle Diagnostics :  Locks and Lock TreesOracle Diagnostics :  Locks and Lock Trees
Oracle Diagnostics : Locks and Lock Trees
 
Partitioning Tables and Indexing Them --- Article
Partitioning Tables and Indexing Them --- ArticlePartitioning Tables and Indexing Them --- Article
Partitioning Tables and Indexing Them --- Article
 
Oracle database performance diagnostics - before your begin
Oracle database performance diagnostics  - before your beginOracle database performance diagnostics  - before your begin
Oracle database performance diagnostics - before your begin
 
The role of the dba
The role of the dba The role of the dba
The role of the dba
 
Partitioning tables and indexing them
Partitioning tables and indexing them Partitioning tables and indexing them
Partitioning tables and indexing them
 

Recently uploaded

Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
VictoriaMetrics
 
%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...
%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...
%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...
masabamasaba
 
%+27788225528 love spells in Toronto Psychic Readings, Attraction spells,Brin...
%+27788225528 love spells in Toronto Psychic Readings, Attraction spells,Brin...%+27788225528 love spells in Toronto Psychic Readings, Attraction spells,Brin...
%+27788225528 love spells in Toronto Psychic Readings, Attraction spells,Brin...
masabamasaba
 
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
masabamasaba
 

Recently uploaded (20)

%in Hazyview+277-882-255-28 abortion pills for sale in Hazyview
%in Hazyview+277-882-255-28 abortion pills for sale in Hazyview%in Hazyview+277-882-255-28 abortion pills for sale in Hazyview
%in Hazyview+277-882-255-28 abortion pills for sale in Hazyview
 
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital TransformationWSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
 
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
%in Stilfontein+277-882-255-28 abortion pills for sale in Stilfontein
 
WSO2Con204 - Hard Rock Presentation - Keynote
WSO2Con204 - Hard Rock Presentation - KeynoteWSO2Con204 - Hard Rock Presentation - Keynote
WSO2Con204 - Hard Rock Presentation - Keynote
 
WSO2CON 2024 - How to Run a Security Program
WSO2CON 2024 - How to Run a Security ProgramWSO2CON 2024 - How to Run a Security Program
WSO2CON 2024 - How to Run a Security Program
 
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
 
WSO2CON 2024 - WSO2's Digital Transformation Journey with Choreo: A Platforml...
WSO2CON 2024 - WSO2's Digital Transformation Journey with Choreo: A Platforml...WSO2CON 2024 - WSO2's Digital Transformation Journey with Choreo: A Platforml...
WSO2CON 2024 - WSO2's Digital Transformation Journey with Choreo: A Platforml...
 
%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...
%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...
%+27788225528 love spells in Knoxville Psychic Readings, Attraction spells,Br...
 
WSO2CON 2024 - Building the API First Enterprise – Running an API Program, fr...
WSO2CON 2024 - Building the API First Enterprise – Running an API Program, fr...WSO2CON 2024 - Building the API First Enterprise – Running an API Program, fr...
WSO2CON 2024 - Building the API First Enterprise – Running an API Program, fr...
 
Direct Style Effect Systems - The Print[A] Example - A Comprehension Aid
Direct Style Effect Systems -The Print[A] Example- A Comprehension AidDirect Style Effect Systems -The Print[A] Example- A Comprehension Aid
Direct Style Effect Systems - The Print[A] Example - A Comprehension Aid
 
WSO2CON 2024 - Freedom First—Unleashing Developer Potential with Open Source
WSO2CON 2024 - Freedom First—Unleashing Developer Potential with Open SourceWSO2CON 2024 - Freedom First—Unleashing Developer Potential with Open Source
WSO2CON 2024 - Freedom First—Unleashing Developer Potential with Open Source
 
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
OpenChain - The Ramifications of ISO/IEC 5230 and ISO/IEC 18974 for Legal Pro...
 
%in Benoni+277-882-255-28 abortion pills for sale in Benoni
%in Benoni+277-882-255-28 abortion pills for sale in Benoni%in Benoni+277-882-255-28 abortion pills for sale in Benoni
%in Benoni+277-882-255-28 abortion pills for sale in Benoni
 
%+27788225528 love spells in Toronto Psychic Readings, Attraction spells,Brin...
%+27788225528 love spells in Toronto Psychic Readings, Attraction spells,Brin...%+27788225528 love spells in Toronto Psychic Readings, Attraction spells,Brin...
%+27788225528 love spells in Toronto Psychic Readings, Attraction spells,Brin...
 
VTU technical seminar 8Th Sem on Scikit-learn
VTU technical seminar 8Th Sem on Scikit-learnVTU technical seminar 8Th Sem on Scikit-learn
VTU technical seminar 8Th Sem on Scikit-learn
 
%in kempton park+277-882-255-28 abortion pills for sale in kempton park
%in kempton park+277-882-255-28 abortion pills for sale in kempton park %in kempton park+277-882-255-28 abortion pills for sale in kempton park
%in kempton park+277-882-255-28 abortion pills for sale in kempton park
 
WSO2Con2024 - From Code To Cloud: Fast Track Your Cloud Native Journey with C...
WSO2Con2024 - From Code To Cloud: Fast Track Your Cloud Native Journey with C...WSO2Con2024 - From Code To Cloud: Fast Track Your Cloud Native Journey with C...
WSO2Con2024 - From Code To Cloud: Fast Track Your Cloud Native Journey with C...
 
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
 
%in Soweto+277-882-255-28 abortion pills for sale in soweto
%in Soweto+277-882-255-28 abortion pills for sale in soweto%in Soweto+277-882-255-28 abortion pills for sale in soweto
%in Soweto+277-882-255-28 abortion pills for sale in soweto
 
WSO2CON 2024 - API Management Usage at La Poste and Its Impact on Business an...
WSO2CON 2024 - API Management Usage at La Poste and Its Impact on Business an...WSO2CON 2024 - API Management Usage at La Poste and Its Impact on Business an...
WSO2CON 2024 - API Management Usage at La Poste and Its Impact on Business an...
 

Oracle Diagnostics : Joins - 1

  • 2. Hemant K Chitale • whoami ? • Oracle 5 to Oracle 10gR2 : DOS, Xenix,8 flavours of Unix, Linux, Windows • Financial Services, Govt/Not-for-Profit, ERP, Custom • Production Support, Consulting, Development • A DBA, not a Developer • My Oracle Blog http://hemantoracledba.blogspot.com
  • 3. Oracle Diagnostics – Joins (1) • For “Explain Plans” see my earlier presentation OracleDiagnostics_Explain_Plans__simple (or at WizIQ) • This presentation is based on the case study Nested Loops and Consistent Gets
  • 4. A Nested Loop join • In a Nested Loop join, Oracle uses the rowset retrieved from the “outer” (driving) table to query the “inner” (driven) table • The Optimizer would choose a Nested Loop join if it expects to be able to retrieve the rowset of the outer table very quickly *and* expects that the size would be small enough to not require querying the inner table too frequently
  • 5. Given this query : SQL> explain plan for 2 select product_desc, txn_id, transaction_amt 3 from transactions t, product_table p 4 where txn_date between to_date('01-FEB-2011','DD-MON-YYYY') and to_date('28-FEB-2011','DD-MON-YYYY') 5 and txn_id between 155000 and 156000 6 and country_cd = 'IN' 7 and t.product_cd=p.product_cd 8 / We expect a Join between TRANSACTIONS and PRODUCT_TABLE
  • 6. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------------- ---------------------- Plan hash value: 1299935411 -------------------------------------------------------------------------------------------------------------- ----------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | -------------------------------------------------------------------------------------------------------------- ----------- | 0 | SELECT STATEMENT | | 1 | 63 | 25 (0)| 00:00:01 | | | | 1 | NESTED LOOPS | | | | | | | | | 2 | NESTED LOOPS | | 1 | 63 | 25 (0)| 00:00:01 | | | | 3 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 4 | TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTIONS | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 5 | INDEX RANGE SCAN | TRANSACTIONS_NDX | 252 | | 4 (0)| 00:00:01 | 2 | 2 | |* 6 | INDEX UNIQUE SCAN | SYS_C0016611 | 1 | | 0 (0)| 00:00:01 | | | | 7 | TABLE ACCESS BY INDEX ROWID | PRODUCT_TABLE | 1 | 12 | 1 (0)| 00:00:01 | | | ------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 4 - filter("TXN_DATE"<=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) 5 - access("COUNTRY_CD"='IN' AND "TXN_ID">=155000 AND "TXN_ID"<=156000) 6 - access("T"."PRODUCT_CD"="P"."PRODUCT_CD") SQL>
  • 7. . Here : | 3 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 4 | TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTIONS | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 5 | INDEX RANGE SCAN | TRANSACTIONS_NDX | 252 | | 4 (0)| 00:00:01 | 2 | 2 | Predicate Information : 4 - filter("TXN_DATE"<=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) 5 - access("COUNTRY_CD"='IN' AND "TXN_ID">=155000 AND "TXN_ID"<=156000) The execution is done in this sequence : Step 1 : Operation 5 : Index Range Scan (expected to retrieve 252 rowids), accessing the TRANSACTIONS_NDX index by COUNTRY_CD = ‘IN’ and TXN_ID between 155000 and 156000 Step 2 : Operation 4 : Table Access of TRANSACTIONS, using the RowIDs fetched from Operation 5. For every row fetched by RowID, filter for TXN_DATE less than 28-Feb-11. Expect to return only 1 single row after the filter for TXN_DATE (note : This is key to the optimizer’s choice of a Nested Loop join) Parent Step 3 : Operation 3 : Determine that this is a Range Scan within Partition 2 (Start and Stop Partition IDs being “2” and “2”). This range scan will return the single row from Operation 4.
  • 8. Continuing with the other operations : | 2 | NESTED LOOPS | | 1 | 63 | 25 (0)| 00:00:01 | | | | 3 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 6 | INDEX UNIQUE SCAN | SYS_C0016611 | 1 | | 0 (0)| 00:00:01 | | | Predicate Information : 6 - access("T"."PRODUCT_CD"="P"."PRODUCT_CD") Step 4 Operation 2 : For the expected single row returned from the Partition Range (in Operation 3), call Operation 6 to scan the Unique Index SYS_C0016611. The Index Unique Scan is expected to be executed once only (as Operation 3 returns 1 row) and, in-turn, expected to return a single RowID (being a Unique Index scan) This Index is the Primary Key index for PRODUCT_TABLE. The Index Scan is for the PRODUCT_CD retrieved the previous step. | 1 | NESTED LOOPS | | | | | | | | | 7 | TABLE ACCESS BY INDEX ROWID | PRODUCT_TABLE | 1 | 12 | 1 (0)| 00:00:01 | | | Step 6 Operation 1 : For the single RowID expected from Operation 6, access the PRODUCT_TABLE. (Since the previous step expects to return a single RowID, this step, too, expects to read a single row from the table).
  • 9. Hash Join • This is a demonstration of a Hash Join from the same case study • In a Hash Join, Oracle attempts to retrieve all the join column values from the first table, compute “hash” values and place them in memory • It then expects to probe the second table and compare the values with the in-memory hash table. A match is a “join” • Performance of a Hash Join depends on the size of the join key and the available memory for the in-memory Hash Table
  • 10. For this query : SQL> explain plan for 2 select /*+ USE_HASH (t p) */ product_desc, txn_id, transaction_amt 3 from transactions t, product_table p 4 where txn_date between to_date('01-FEB-2011','DD-MON-YYYY') and to_date('28-FEB-2011','DD-MON-YYYY') 5 and txn_id between 155000 and 156000 6 and country_cd = 'IN' 7 and t.product_cd=p.product_cd 8 / We have explicitly provided a Hint (directive) to Oracle to execute a Hash Join between the two tables
  • 11. It is SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------ ------------------------ Plan hash value: 971735053 ------------------------------------------------------------------------------------------------------------ ------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | ------------------------------------------------------------------------------------------------------------ ------------ | 0 | SELECT STATEMENT | | 1 | 63 | 28 (4)| 00:00:01 | | | |* 1 | HASH JOIN | | 1 | 63 | 28 (4)| 00:00:01 | | | | 2 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 3 | TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTIONS | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 4 | INDEX RANGE SCAN | TRANSACTIONS_NDX | 252 | | 4 (0)| 00:00:01 | 2 | 2 | | 5 | TABLE ACCESS FULL | PRODUCT_TABLE | 14 | 168 | 3 (0)| 00:00:01 | | | ------------------------------------------------------------------------------------------------------------ ------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("T"."PRODUCT_CD"="P"."PRODUCT_CD") 3 - filter("TXN_DATE"<=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) 4 - access("COUNTRY_CD"='IN' AND "TXN_ID">=155000 AND "TXN_ID"<=156000) SQL>
  • 12. Here : | 2 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 3 | TABLE ACCESS BY LOCAL INDEX ROWID| TRANSACTIONS | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | |* 4 | INDEX RANGE SCAN | TRANSACTIONS_NDX | 252 | | 4 (0)| 00:00:01 | 2 | 2 | Predicate Information : 3 - filter("TXN_DATE"<=TO_DATE(' 2011-02-28 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) 4 - access("COUNTRY_CD"='IN' AND "TXN_ID">=155000 AND "TXN_ID"<=156000) Step 1 : Operation 4 : Retrieve 252 RowIDs from the TRANSACTIONS_NDX Step 2 : Operation 3 : Use the 252 RowIDs to lookup the TRANSACTIONS table and filter to TXN_DATE. Expect to return a single row Parent Step 3 : Confirm that these steps are executed against a single Partition
  • 13. Here : |* 1 | HASH JOIN | | 1 | 63 | 28 (4)| 00:00:01 | | | | 2 | PARTITION RANGE SINGLE | | 1 | 51 | 24 (0)| 00:00:01 | 2 | 2 | | 5 | TABLE ACCESS FULL | PRODUCT_TABLE | 14 | 168 | 3 (0)| 00:00:01 | | | Predicate Information : 1 - access("T"."PRODUCT_CD"="P"."PRODUCT_CD") Step 4 Operation 1: For the single row returned from the Partition Range Scan,execute a Hash Join. The hashed value(s) for this row are stored in an in-memory hash area Step 5 : Operation 5 : Probe the PRODUCT_TABLE (via a FullTableScan) to read 14 rows. Place the values in memory and attempt a join on PRODUCT_CD.