Explain plan going in Billions
Dear All,
We are having a huge table of data and when I am running explain plan for the table I am getting the below plan from ORACLE.
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 4149 | 129K| 1692 | | |
| 1 | SORT GROUP BY NOSORT | | 4149 | 129K| 1692 | | |
| 2 | VIEW | | 4149 | 129K| 1692 | | |
| 3 | SORT GROUP BY | | 4149 | 717K| 1692 | | |
| 4 | FILTER | | | | | | |
| 5 | HASH JOIN | | 4149 | 717K| 1691 | | |
| 6 | TABLE ACCESS FULL | R_CFG_CATEGORY_MAS | 103 | 4429 | 3 | | |
| 7 | HASH JOIN | | 4149 | 542K| 1687 | | |
| 8 | PARTITION RANGE ITERATOR | | 4149 | 287K| 21687 | KEY | KEY |
| 9 | PARTITION HASH SINGLE | | 4149 | 287K| 21687 | KEY | KEY |
| 10 | TABLE ACCESS FULL | R_CFG_WH_EXCEP | 4149 | 287K| 21687 | | |
| 11 | MERGE JOIN CARTESIAN | | 2105K| 126M| *18E*| | |
| 12 | VIEW | | 475 | 10925 | 3 | | |
| 13 | CONNECT BY WITH FILTERING | | | | | | |
| 14 | TABLE ACCESS BY INDEX ROWID| R_CFG_CAT_HIERARCHY_MAS | | | | | |
| 15 | NESTED LOOPS | | 19 | 247 | 3 | | |
| 16 | TABLE ACCESS FULL | R_CFG_CAT_HIERARCHY_MAS | 19 | 171 | 3 | | |
| 17 | INDEX UNIQUE SCAN | PK_RCCHM_CAT_REGID_PK | 1 | 4 | 0 | | |
| 18 | HASH JOIN | | | | | | |
| 19 | CONNECT BY PUMP | | | | | | |
| 20 | TABLE ACCESS FULL | R_CFG_CAT_HIERARCHY_MAS | 475 | 5225 | 3 | | |
| 21 | TABLE ACCESS FULL | R_CFG_CAT_HIERARCHY_MAS | 475 | 5225 | 3 | | |
| 22 | BUFFER SORT | | 4432 | 173K| *18E*| | |
| 23 | TABLE ACCESS BY INDEX ROWID | R_DEVICE_INFO | 4432 | 173K| *18E*| | |
| 24 | BITMAP CONVERSION TO ROWIDS| | | | | | |
| 25 | BITMAP INDEX SINGLE VALUE | R_DEVICE_INFO_CPYKEY | | | | | |
Note
- 'PLAN_TABLE' is old version
I can see cost in 18E which is huge and ridiculous.
I can explain points that I noted on this table.
This table is having more than 1 BILLIION RECORDS AND I am querying for a user which has got 5 MILLION RECORDS.
This table is properly partitioned and is having proper indexes.
We got some BITMAP indexes on this table also.
This table has got proper partitioned indexes also. (But the indexes and the table are in the same tablespace).
Can Anyone give me some sugessitions on how to reduce the overall cost.
Appreciate your response on this one.
Thanks,
Madhu K.
569725 wrote:
I can see cost in 18E which is huge and ridiculous.For a cartesian merge join... Cartesian joins are notoriously expensive.
This table is having more than 1 BILLIION RECORDS AND I am querying for a user which has got 5 MILLION RECORDS.Does not matter. The number of rows (note we store rows in tables, not records) does not matter. It is about how much I/O is needed to process that amount of data.
And this is what invariably we design for.. using relational design, using indexes, using partitioning, using clustering, etc. All these are techniques to reduce I/O. From eliminating duplication of data to providing optimal I/O paths to the data.
A real world example:
SQL> set timing on
SQL> select count(*) from daily_xxxxx;
COUNT(*)
2160339906
Elapsed: 00:00:10.09
SQL>
SQL> select count(*) from all_objects;
COUNT(*)
51255
Elapsed: 00:01:43.60So despite "+processing+" over 2 billion rows, the count is significantly faster than the count of the very much smaller ALL_OBJECTS view.
Why? Because it took less I/O to count those 2 billion rows (using a single index) than the nearly 52 thousand objects in the data dictionary (using several indexes and tables).
The rules that governs performance do not change with the number of rows in a table. The same rules and principles apply. What does change is the "+error margin+" - you are going to see a performance problem quite a lot sooner on a large table than a very small table. You may not notice that a 1ms overhead per row is a performance problem on a 100 row table. You will definitely notice it on a million row table.
So forget about the number of rows in these tables. Make sure that the SQL is designed logically correctly. Make sure that the table/db design provides optimal I/O paths for that SQL.
And catersian merge joins, nested loops with full table scans and so on.. that points to both these as being potential problems. SQL designed incorrectly (like forgetting join criteria). Table design lacking (requiring nested loop full table scans as oppose to index range scans or hash joins).
Oh yeah - and as already mentioned, forget the cost that the execution plan shows. Unless you know what unit that cost is expressed in and how to interpret it?
Similar Messages
-
Weird explain plan on multi-level structured XmlType column
Hello,
am running an explain on the follwing query on 11.2.0.2:
SELECT
T1.EVENT_ID,
ACTION_SUB_ID,
PARAM_KEY,
PARAM_VALUE,
TO_DATE('2013-12-10', 'YYYY-MM-DD')
FROM T_C_RMP_MNTRNG_XML_FULL_IL ,
XMLTABLE('/monitoring' PASSING XML_CONTENT COLUMNS
EVENT_ID VARCHAR2(4000) PATH 'eventId',
ACTIONS XMLTYPE PATH 'action'
) T1,
XMLTABLE('/action' PASSING T1.ACTIONS COLUMNS
ACTION_SUB_ID NUMBER(10,0) PATH 'actionSubId',
PARAMS xmltype PATH 'param'
) T2,
XMLTABLE('/param' PASSING T2.params columns
PARAM_KEY VARCHAR2(4000) PATH 'key',
PARAM_VALUE VARCHAR2(1000) PATH 'value'
) T3
WHERE MESSAGE_ID = 4972102 ;
Although MESSAGE_ID is the primary key of T_C_RMP_MNTRNG_XML_FULL_IL and thus there is only one record matching the condition, I get an explain plan with huge costs, 500MB of data and an estimated 10 hour runtime:
PLAN_TABLE_OUTPUT
Plan hash value: 4011854835
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 223K| 489M| 3111K (1)| 10:22:17 |
| 1 | NESTED LOOPS | | | | | |
| 2 | NESTED LOOPS | | 223K| 489M| 3111K (1)| 10:22:17 |
| 3 | NESTED LOOPS | | 140K| 11M| 1678 (1)| 00:00:21 |
|* 4 | INDEX RANGE SCAN | X1B | 1 | 53 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS BY INDEX ROWID| T_OR_MON_ACTION | 140K| 4542K| 1675 (1)| 00:00:21 |
PLAN_TABLE_OUTPUT
|* 6 | INDEX RANGE SCAN | X3 | 140K| | 4 (25)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | X4G | 4083 | | 22 (0)| 00:00:01 |
| 8 | TABLE ACCESS BY INDEX ROWID | T_OR_MON_ACTION_PARAM | 2 | 4428 | 52 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - access("MESSAGE_ID"=4972102)
6 - access("SYS_ALIAS_0"."NESTED_TABLE_ID"="T_C_RMP_MNTRNG_XML_FULL_IL"."SYS_NC0001200013$")
7 - access("NESTED_TABLE_ID"="SYS_ALIAS_0"."SYS_NC0000500006$")
PLAN_TABLE_OUTPUT
Note
- dynamic sampling used for this statement (level=2)
When I run the query, the result comes back within 0.3 seconds.
Why is the explain plan off like that?
Is this just the way it is, or is there something going wrong here?This is my table create statement:
CREATE TABLE QQRCSBI0.T_C_RMP_MNTRNG_XML_FULL_IL (
MESSAGE_ID NUMBER(22,0) NOT NULL ENABLE,
XML_EVAL_ID NUMBER(22,0),
VIN7 VARCHAR2(7 BYTE),
FLEET_ID VARCHAR2(50 BYTE),
CSC_SW_VERSION VARCHAR2(100 BYTE),
RECEIVED DATE,
XML_CONTENT SYS.XMLTYPE ,
DWH_LM_TS_UTC DATE NOT NULL ENABLE,
CONSTRAINT PK_C_RMP_MNTRNG_XML_FULL_IL5 PRIMARY KEY (MESSAGE_ID)
) NOLOGGING TABLESPACE CATALOG
VARRAY "XML_CONTENT"."XMLDATA"."ACTION" STORE AS TABLE "T_OR_MON_ACTION" (
NOLOGGING TABLESPACE "CATALOG"
VARRAY "PARAM" STORE AS TABLE "T_OR_MON_ACTION_PARAM" (
NOLOGGING TABLESPACE "CATALOG"
) RETURN AS LOCATOR
) RETURN AS LOCATOR
XMLTYPE XML_CONTENT STORE AS OBJECT RELATIONAL XMLSCHEMA "http://mydomain.com/csc_monitoring_session.xsd" ELEMENT "monitoring";
I set all default table names in the schema to blank and registered the schema with genTables=false.
I am still running into problems retrieving the 3rd level T_OR_MON_ACTION_PARAM data. The query just crashes after a while because it is running out of either TEMP space or UNDO space (it keeps changing). I'll take a step back to re-evaluate and post another thread about that in a bit I guess...
You said "SQL*Plus explain plan, goes most of the time bananas" - is there a difference in what client (SqlPlus or SqlDeveloper) I use to get the explain plan? I thought the plan was generated by the DB and the clients just display the result, and the only difference is the way the clients display the plan?! -
Hello
I've a problem with a sql. On the production database the explain plan goes over the index, an that's not so fast. on the test system the explain plan makes a bitmap conversion from rowids, that's faster. What can I do, that the explain plan goes also over the bitmap conversion from rowids?
Thanks.
rogerSelect:
select * from info a
where datum = '19-Jan-2011'
and gruppen = 90
and dokument = 90
and Nummer not in (select nummer from info b
where b.datum = '19-Jan-2011'
and b.gruppen = 3
and b.dokument = 1)
Test-System:
Plan
SELECT STATEMENT ALL_ROWSCost: 342 Bytes: 340 Cardinality: 1
15 HASH JOIN ANTI Cost: 342 Bytes: 340 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID TABLE INFO Cost: 150 Bytes: 318 Cardinality: 1
6 BITMAP CONVERSION TO ROWIDS
5 BITMAP AND
2 BITMAP CONVERSION FROM ROWIDS
1 INDEX RANGE SCAN INDEX INFO_PERDATUM-IDX Cost: 11 Cardinality: 3.151
4 BITMAP CONVERSION FROM ROWIDS
3 INDEX RANGE SCAN INDEX INFO_DOKUMENT_IDX Cost: 134 Cardinality: 3.151
14 TABLE ACCESS BY INDEX ROWID TABLE INFO Cost: 192 Bytes: 22 Cardinality: 1
13 BITMAP CONVERSION TO ROWIDS
12 BITMAP AND
9 BITMAP CONVERSION FROM ROWIDS
8 INDEX RANGE SCAN INDEX INFO_PERDATUM-IDX Cost: 11 Cardinality: 3.151
11 BITMAP CONVERSION FROM ROWIDS
10 INDEX RANGE SCAN INDEX INFO_DOKUMENT_IDX Cost: 175 Cardinality: 3.151
Prod-System:
Plan
SELECT STATEMENT ALL_ROWSCost: 7.436 Bytes: 339 Cardinality: 1
5 HASH JOIN RIGHT ANTI Cost: 7.436 Bytes: 339 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE INFO Cost: 3.718 Bytes: 1.056 Cardinality: 48
1 INDEX RANGE SCAN INDEX INFO_PERDATUM-IDX Cost: 775 Cardinality: 3.801
4 TABLE ACCESS BY INDEX ROWID TABLE INFO Cost: 3.718 Bytes: 15.216 Cardinality: 48
3 INDEX RANGE SCAN INDEX INFO_PERDATUM-IDX Cost: 775 Cardinality: 3.801 -
How to improve the query performance or tune query from Explain Plan
Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
21 FILTER
16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
243 bytes sent via SQL*Net to client
349 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
SID
310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
VALUE
163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID CHILD_NUMBER
04mpgrzhsv72w 0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
Please verify value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
PM: PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
: call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Explain Plan changed using "IN"
Hi ,
I am using one of the query as below
select a.x, b.y, c.z from a,b,c
where
a.x in ( select x from temp where col=b.y)
i checked explain plan this query is going to access full table x
i have index on x for temp table.
i need to check b.y in subquery as parameter and that subquery result i have to use as first main query's where criteria.
using function i can get only one record at time.
if anyone have any idea how to solve.
TIAwhen i use = instead of "IN" below is the explain plan from TOAD
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=RULE
SORT UNIQUE
CONCATENATION
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID JOB_DETAIL_LINES
INDEX UNIQUE SCAN PK_JOT
TABLE ACCESS BY INDEX ROWID BULK_BOL
INDEX RANGE SCAN BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID BULK_SKID
INDEX RANGE SCAN BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN DVD_DISC_PRINT_SUPPLY_PK
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID JOB_DETAIL_LINES
INDEX UNIQUE SCAN PK_JOT
TABLE ACCESS BY INDEX ROWID BULK_BOL
INDEX RANGE SCAN BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID BULK_SKID
INDEX RANGE SCAN BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN DVD_DISC_PRINT_SUPPLY_PK
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID JOB_DETAIL_LINES
INDEX UNIQUE SCAN PK_JOT
TABLE ACCESS BY INDEX ROWID BULK_BOL
INDEX RANGE SCAN BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID BULK_SKID
INDEX RANGE SCAN BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN DVD_DISC_PRINT_SUPPLY_PK
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS BY INDEX ROWID BULK_BOL
INDEX RANGE SCAN BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID BULK_SKID
INDEX RANGE SCAN BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN DVD_DISC_PRINT_SUPPLY_PK
TABLE ACCESS BY INDEX ROWID JOB_DETAIL_LINES
INDEX UNIQUE SCAN PK_JOT
when i use "IN" below is the explain plan from TOAD
Operation Object Name Rows Bytes Cost Object Node In/Out PStart PStop
SELECT STATEMENT Optimizer Mode=RULE
SORT UNIQUE
FILTER
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS FULL JOB_DETAIL_LINES
TABLE ACCESS BY INDEX ROWID BULK_BOL
INDEX RANGE SCAN BULK_BOL_N1
TABLE ACCESS BY INDEX ROWID BULK_SKID
INDEX RANGE SCAN BULK_SKID_N1
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_CARTON
INDEX RANGE SCAN DVD_DISC_PRINT_CARTON_N2
TABLE ACCESS BY INDEX ROWID DVD_DISC_PRINT_SUPPLY
INDEX UNIQUE SCAN DVD_DISC_PRINT_SUPPLY_PK
INDEX UNIQUE SCAN PK_JOT -
Oracle not using its own explain plan
When I run a simple select query on an indexed column on a large (30 million records) table oracle creates a plan using the indexed column and at a cost of 4. However, what it actually does is do a table scan (I can see this in the 'Long Operations' tab in OEM).
The funny thing is that I have the same query in a ADO application and when the query is run from there, the same plan is created but no table scan is done - and the query returns in less than a second. However, with the table scan it is over a minute.
When run through SQL plus Oracle creates a plan including the table scan at a cost of 19030.
In another (dot net) application I used the: "Alter session set optimizer_index_caching=100" and "Alter session set optimizer_index_cost_adj=10" to try to force the optimizer to use the index. It creates the expected plan, but still does the table scan.
The query is in the form of:
"Select * from tab where indexedcol = something"
Im using Oracle 9i 9.2.0.1.0
Any ideas as I'm completely at a loss?Hello
It sounds to me like this has something to do with bind variable peeking which was introduced in 9i. If the predicate is
indexedcolumn = :bind_variablethe first time the query is parsed by oracle, it will "peek" at the value in the bind variable and see what it is and will generate an execution plan based on this. That same plan will be used for matching SQL.
If you use a litteral, it will generate the plan based on that, and will generate a separate plan for each litteral you use (depending on the value of the cursor_sharing initialisation parameter).
This can cause there to be a difference between the execution plan seen when issuing EXPLAIN PLAN FOR, and the actual exectuion plan used when the query is run.
Have a look at the following example:
tylerd@DEV2> CREATE TABLE dt_test_bvpeek(id number, col1 number)
2 /
Table created.
Elapsed: 00:00:00.14
tylerd@DEV2> INSERT
2 INTO
3 dt_test_bvpeek
4 SELECT
5 rownum,
6 CASE
7 WHEN MOD(rownum, 5) IN (0,1,2,3) THEN
8 1
9 ELSE
10 MOD(rownum, 5)
11 END
12 END
13 FROM
14 dual
15 CONNECT BY
16 LEVEL <= 100000
17 /
100000 rows created.
Elapsed: 00:00:00.81
tylerd@DEV2> select count(*), col1 from dt_test_bvpeek group by col1
2 /
COUNT(*) COL1
80000 1
20000 4
2 rows selected.
Elapsed: 00:00:00.09
tylerd@DEV2> CREATE INDEX dt_test_bvpeek_i1 ON dt_test_bvpeek(col1)
2 /
Index created.
Elapsed: 00:00:00.40
tylerd@DEV2> EXEC dbms_stats.gather_table_stats( ownname=>USER,-
tabname=>'DT_TEST_BVPEEK',-
method_opt=>'FOR ALL INDEXED COLUMNS SIZE 254',-
cascade=>TRUE -
);PL/SQL procedure successfully completed.
Elapsed: 00:00:00.73
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = 1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 78728 | 538K| 82 (52)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 78728 | 538K| 82 (52)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=1)
13 rows selected.
Elapsed: 00:00:00.06The execution plan for col1=1 was chosen because oracle was able to see that based on the statistics, col1=1 would result in most of the rows from the table being returned.
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = 4
8 /
Explained.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 3223879139
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 21027 | 143K| 74 (21)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| DT_TEST_BVPEEK | 21027 | 143K| 74 (21)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | DT_TEST_BVPEEK_I1 | 21077 | | 29 (28)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("COL1"=4)
14 rows selected.
Elapsed: 00:00:00.04This time, the optimiser was able to see that col1=4 would result in far fewer rows so it chose to use an index. Look what happens however when we use a bind variable with EXPLAIN PLAN FOR - especially the number of rows the optimiser estimates to be returned from the table
tylerd@DEV2> var an_col1 NUMBER
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 49882 | 340K| 100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 | 340K| 100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.04
tylerd@DEV2>
tylerd@DEV2> exec :an_col1:=4;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.01
tylerd@DEV2>
tylerd@DEV2> EXPLAIN PLAN FOR
2 SELECT
3 *
4 FROM
5 dt_test_bvpeek
6 WHERE
7 col1 = :an_col1
8 /
Explained.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT * FROM TABLE(DBMS_XPLAN.display)
2 /
PLAN_TABLE_OUTPUT
Plan hash value: 2611346395
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 49882 | 340K| 100 (60)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| DT_TEST_BVPEEK | 49882 | 340K| 100 (60)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("COL1"=TO_NUMBER(:AN_COL1))
13 rows selected.
Elapsed: 00:00:00.07For both values of the bind variable, the optimiser has no idea what the value will be so it has to make a calculation based on a formula which results in it estimating that the query will return roughly half of the rows in the table, and so it chooses a full scan.
Now when we actually run the query, the optimiser can take advantage of bind variable peeking and have a look at the value the first time round and base the execution plan on that:
tylerd@DEV2> exec :an_col1:=1;
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 *
3 FROM
4 dt_test_bvpeek
5 WHERE
6 col1 = :an_col1
7 /
80000 rows selected.
Elapsed: 00:00:10.98
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '9t52uyyq67211'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS FULL DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.03It saw that the bind variable value was 1 and that this would return most of the rows in the table so it chose a full scan.
tylerd@DEV2> exec :an_col1:=4
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 *
3 FROM
4 dt_test_bvpeek
5 WHERE
6 col1 = :an_col1
7 /
20000 rows selected.
Elapsed: 00:00:03.50
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
9t52uyyq67211
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '9t52uyyq67211'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS FULL DT_TEST_BVPEEK
2 rows selected.
Elapsed: 00:00:00.01Even though the value of the bind variable changed, the optimiser saw that it already had a cached version of the sql statement along with an execution plan, so it used that rather than regenerating the plan. We can check the reverse of this by causing the statement to be invalidated and re-parsed - there's lots of ways, but I'm just going to rename the table:
Elapsed: 00:00:00.03
tylerd@DEV2> alter table dt_test_bvpeek rename to dt_test_bvpeek1
2 /
Table altered.
Elapsed: 00:00:00.01
tylerd@DEV2>
20000 rows selected.
Elapsed: 00:00:04.81
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.00
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID DT_TEST_BVPEEK1
INDEX RANGE SCAN DT_TEST_BVPEEK_I1
3 rows selected.
80000 rows selected.
Elapsed: 00:00:10.61
tylerd@DEV2> SELECT prev_sql_id FROM v$session WHERE audsid=SYS_CONTEXT('USERENV','SESSIONID')
2 /
PREV_SQL_ID
6ztnn4fyt6y5h
1 row selected.
Elapsed: 00:00:00.01
tylerd@DEV2> SELECT
2 operation,
3 options,
4 object_name
5 FROM
6 v$sql_plan
7 WHERE
8 sql_id = '6ztnn4fyt6y5h'
9 /
OPERATION OPTIONS OBJECT_NAME
SELECT STATEMENT
TABLE ACCESS BY INDEX ROWID DT_TEST_BVPEEK1
INDEX RANGE SCAN DT_TEST_BVPEEK_I1
3 rows selected.This time round, the optimiser peeked at the bind variable the first time the statement was exectued and found it to be 4, so it based the execution plan on that and chose an index range scan. When the statement was executed again, it used the plan it had already executed.
HTH
David -
Hi,
I was trying to get an explain plan for below query. (Refer - A)
BILL_DETAIL table have index of ZONECODE,MRNO,AREACODE,WCNO but still it's
showing 'TABLE ACCESS FULL in BILL_DETAIL'
If i select only first 4 column, it is going by index. (REFER - B)
As per my knowledge index will consider only where clause conditions
but here I couldn't understand why this considering select output columns.
First time I am trying sql explain plan statement, Please help me to correct
this query.
REFER - A
EXPLAIN PLAN FOR
SELECT B.ZONECODE ZONECODE, B.MRNO MRNO, B.AREACODE AREACODE, B.WCNO WCNO,
B.BILLNO BILLNO,B.BILLDT BILLDT,B.FROMDT FROMDT,B.TODT TODT,B.TOBEPAID TOBEPAID,
B.PREVUNPAID PREVUNPAID,B.DUEDT DUEDT
FROM BILL_DETAIL B, CONSUMER_MASTER C
WHERE B.ZONECODE = C.ZONECODE
AND B.MRNO = C.MRNO
AND B.AREACODE = C.AREACODE
AND B.WCNO = C.WCNO
AND UPPER(B.ZONECODE)=UPPER('SZ-4')
AND UPPER(B.MRNO)=UPPER('347')
AND UPPER(B.AREACODE)=UPPER('18')
AND UPPER(B.WCNO)=UPPER('30910')
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 71 | 9 (0)|
| 1 | NESTED LOOPS | | 1 | 71 | 9 (0)|
|* 2 | TABLE ACCESS FULL| BILL_DETAIL | 1 | 52 | 9 (0)|
|* 3 | INDEX UNIQUE SCAN| SYS_C008803 | 1 | 19 | 0 (0)|
Predicate Information (identified by operation id):
2 - filter(UPPER("B"."ZONECODE")='SZ-4' AND UPPER("B"."MRNO")='347'
AND UPPER("B"."AREACODE")='18' AND UPPER("B"."WCNO")='30910')
3 - access("B"."ZONECODE"="C"."ZONECODE" AND "B"."MRNO"="C"."MRNO"
AND "B"."AREACODE"="C"."AREACODE" AND "B"."WCNO"="C"."WCNO")
REFER - B
EXPLAIN PLAN FOR
SELECT B.ZONECODE ZONECODE, B.MRNO MRNO, B.AREACODE AREACODE, B.WCNO WCNO
FROM BILL_DETAIL B, CONSUMER_MASTER C
WHERE B.ZONECODE = C.ZONECODE
AND B.MRNO = C.MRNO
AND B.AREACODE = C.AREACODE
AND B.WCNO = C.WCNO
AND UPPER(B.ZONECODE)=UPPER('SZ-4')
AND UPPER(B.MRNO)=UPPER('347')
AND UPPER(B.AREACODE)=UPPER('18')
AND UPPER(B.WCNO)=UPPER('30910')
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT | | 1 | 34 | 4 (0)|
| 1 | NESTED LOOPS | | 1 | 34 | 4 (0)|
|* 2 | INDEX FAST FULL SCAN| SYS_C008798 | 1 | 15 | 4 (0)|
|* 3 | INDEX UNIQUE SCAN | SYS_C008803 | 1 | 19 | 0 (0)|
Predicate Information (identified by operation id):
2 - filter(UPPER("B"."ZONECODE")='SZ-4' AND UPPER("B"."MRNO")='347'
AND UPPER("B"."AREACODE")='18' AND UPPER("B"."WCNO")='30910')
3 - access("B"."ZONECODE"="C"."ZONECODE" AND "B"."MRNO"="C"."MRNO"
AND "B"."AREACODE"="C"."AREACODE" AND "B"."WCNO"="C"."WCNO")
Note
- 'PLAN_TABLE' is old versionWelcome to the forums!
user13295080 wrote:
I was trying to get an explain plan for below query. (Refer - A)
BILL_DETAIL table have index of ZONECODE,MRNO,AREACODE,WCNO but still it's
showing 'TABLE ACCESS FULL in BILL_DETAIL'
If i select only first 4 column, it is going by index. (REFER - B)
As per my knowledge index will consider only where clause conditions
but here I couldn't understand why this considering select output columns.This is because Oracle is smart enough to know that the entire query can be satisfied by using the index without hitting the table. However, once you add a column that doesn't exist in the index Oracle has decided it is more efficient to use the full table scan.
I also noticed that all the row estimates are 1 in the execution plans. Is this expected? If not, have statistics on the relevant objects been gathered?
Generally speaking, when you have a query tuning question providing information in these threads is extremely helpful:
{message:id=1812597}
{thread:id=863295}
Additionally, when posting query plans, queries, or any code please use \ tags to preserve formatting.
Your code here!\ -
Oem explain plan produced doesn't correspond to explain plan with tkprof
Hello all,
I am running OEM on a 10.2.0.3 database and I have a very slow query with cognos 8 BI on my data warehouse.
I went to the dbconsole through OEM and connected to target database I went to look at the query execution and then got an explain plan.
Then I did a trace file and ran it throught tkprof.
When I look at both produced explain plan, I can see the tree looks the same exept the corresponding values. In OEM, it says I am going throug 18000 rows and in the tkprof result it says more like millions of records.
As anybody had these kind of results?
Shall I have more confidence in TKprof then OEM?
It is very important to me since I am being chalanged by an external DBA.I would recommend you to get Christian Antogini´s book "Troublshooting Oracle Performance", (http://www.antognini.ch/top/) which explains everything you need to know when analyzing Oracle SQL Performance and Explain Plans.
If you properly trace your SQL Statement, you will get "STAT" lines in the trace file. These stat lines show you the actual number of rows processed per row source operation. Explain plan per default does only show you the "estimated" row counts for the row source operations no matter whether you use "explain=" in the tkprof call or OEM to get the explain plan. Tkprof reads the STAT lines from the trace and outputs a section which is similar to an execution plan but contains the "real" number of rows.
However, if you want to troubleshoot Oracle Performance, I would recommend you to run the statement with the hint /*+ GATHER_PLAN_STATISTICS */ or set statistics_level=ALL in your session (not database-wide!).
If you do, you can get an excellent execution plan with DBMS_XPLAN.DISPLAY_CURSOR containing both estimated rows as well as actual rows combined with the "number of starts" for e.g. nested loop joins.
Get the book, read it, and you will be able to discuss this issue with your external dba in a professional way. ;-)
Regards,
Martin
www.ora-solutions.net -
Help in interpreting the output of explain plan
Hi,
I have written a query in two different ways and then run an explain plan on both of them. Both these queries give same result. I want to know which one will be more efficient. I am giving the output of explain plan for both the queries:
The second plan has a lower cost but has much higher consistent gets !!
Please advise.
Plan 1:
Execution Plan
0 SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=8637 Card= 1 Bytes=10132)
1 0 SORT (ORDER BY) (Cost=8637 Card=1 Bytes=10132)
2 1 WINDOW (SORT) (Cost=8637 Card=1 Bytes=10132)
3 2 COUNT (STOPKEY)
4 3 VIEW (Cost=8635 Card=1 Bytes=10132)
5 4 SORT (ORDER BY) (Cost=8635 Card=1 Bytes=862)
6 5 WINDOW (SORT) (Cost=8635 Card=1 Bytes=862)
7 6 MAT_VIEW ACCESS (FULL) OF 'PRD_SEARCH_MVW' (MAT_VIEW) (Cost=8633 Card=1 Bytes=862)
Statistics
577 recursive calls
0 db block gets
39202 consistent gets
34798 physical reads
0 redo size
72348 bytes sent via SQL*Net to client
4295 bytes received via SQL*Net from client
9 SQL*Net roundtrips to/from client
10 sorts (memory)
0 sorts (disk)
100 rows processed
Plan-2
Execution Plan
0 SELECT STATEMENT Optimizer=HINT: FIRST_ROWS (Cost=982 Card=1 Bytes=10145)
1 0 SORT (ORDER BY) (Cost=982 Card=1 Bytes=10145)
2 1 WINDOW (SORT) (Cost=982 Card=1 Bytes=10145)
3 2 COUNT (STOPKEY)
4 3 VIEW (Cost=980 Card=1 Bytes=10145)
5 4 SORT (ORDER BY) (Cost=980 Card=1 Bytes=10132)
6 5 WINDOW (SORT) (Cost=980 Card=1 Bytes=10132)
7 6 WINDOW (SORT) (Cost=980 Card=1 Bytes=10132)
8 7 VIEW (Cost=977 Card=1 Bytes=10132)
9 8 WINDOW (SORT PUSHED RANK) (Cost=977 Card=1 Bytes=889)
10 9 NESTED LOOPS (Cost=976 Card=1 Bytes=889)
11 10 HASH JOIN (Cost=305 Card=670 Bytes=18090)
12 11 HASH JOIN (Cost=23 Card=140 Bytes=2240)
13 12 INDEX (FAST FULL SCAN) OF 'GLCAT_GRP_TO_CAT_PK' (INDEX (UNIQUE)) (Cost=2 Card=52 Bytes=364)
14 12 MAT_VIEW ACCESS (FULL) OF 'GLCAT_CAT_TO_MCAT' (MAT_VIEW) (Cost=20 Card=1039 Bytes=9351)
15 11 INDEX (FAST FULL SCAN) OF 'PCITEM2GLCATMCAT_FK_IDS' (INDEX) (Cost=281 Card=16903 Bytes=185933)
16 10 MAT_VIEW ACCESS (BY INDEX ROWID) OF 'PRD_SEARCH_MVW' (MAT_VIEW) (Cost=1 Card=1 Bytes=862)
17 16 INDEX (UNIQUE SCAN) OF 'PK_PRD_SEARCH_ID' (INDEX (UNIQUE)) (Cost=0 Card=1)
Statistics
481 recursive calls
2 db block gets
195742 consistent gets
7516 physical reads
0 redo size
71567 bytes sent via SQL*Net to client
6629 bytes received via SQL*Net from client
9 SQL*Net roundtrips to/from client
15 sorts (memory)
1 sorts (disk)
100 rows processedRegards
Madhup
Message was edited by:
MadhupThanks a lot for you input. I am posting both the queries below. My requirements are following:
1) I have a products table
2) I have Created grouping hierarchy - Groups, Categories and then Micro-categories - and have setup a separate table for each of them in my database
3) Then I have mapping tables, i.e. a table that stores group to category mapping, another table that stores category to micro-category mapping.
4) Products are mapped directly to micro-categories and one product could be mapped to multiple micro-categories.
5) I have created a materialized view on product and store the mappings as comma separated list of IDs - I have three fields there, on to store comma separated group id, second to store comma separated category ids and third to store the comma separated micro category ids to which the product is mapped.
Now I want to write a query that will return a specified number of matches from this table based on user defined criterion. There are few other filter cirterion apart from Group/Category and Microcategory. These are Company Name, Country, Type of company etc.
This query when run on production will be accessed very frequently - I expect the access to be in the tune of around 5-10 times per second.
There are 50 records in the group table
There are 500 categories
There are 20000 micro-categories
Group to category mapping table has around 1000 records
Category to microcategory table has around 25000 records
The product table has around 100,000 products.
Product to microcategory mapping table has 350000 records
The product mview has the same number of records as that in products table.
The first query uses the single materialized view to access data, however, it always does a full table scan and does not use any index.
When I noticed this in the explain plan, then I tried to write the second query which is using JOINs to arrive at the same output.
The explain plan now says that it is using Index scans.
I did a sample run of both the queries on my production system and I had to withdraw both of them as both brought my system to grinding halt within few minutes of going live.
My system at present receives around 3000 requests per hour during peak load and around 600 requests per hour during off-peak hours.
And I was testing these queries in Off-peak hours !!
Here are the two sql queries just for reference - there are several variables plugged in where clause which are the key drivers of the query:
SQL-1
SELECT DECODE(:OPT,2,A.SC,(MAX(A.SC) OVER (PARTITION BY A.PRD_SEARCH_COMPANY))) AS SO,
A.SC, A.PRD_SEARCH_ID,
A.PRD_SEARCH_COMPANY_ID, A.PRD_SEARCH_COMPANY, A.PRD_SEARCH_COMPANYID_ENCRYPTED,
A.PRD_SEARCH_PCID, A.PRD_SEARCH_URL, A.PRD_SEARCH_PC_CLNT_HOME,
A.PRD_SEARCH_CLNT_ENABLED, A.PRD_SEARCH_CODE, A.PRD_SEARCH_NAME,
A.PRD_SEARCH_DESC_SMALL, A.PRD_SEARCH_DESC_DETAILED, A.PRD_SEARCH_DESC_HTML,
A.PRD_SEARCH_IMG_SMALL, A.PRD_SEARCH_IMG_LARGE, A.PRD_SEARCH_WEIGHT_ITEM,
A.PRD_SEARCH_MODIFIEDDATE, A.PRD_SEARCH_SIZE, A.PRD_SEARCH_LABEL1,
A.PRD_SEARCH_LABEL1_VALUE, A.PRD_SEARCH_LABEL2, A.PRD_SEARCH_LABEL2_VALUE,
A.PRD_SEARCH_LABEL3, A.PRD_SEARCH_LABEL3_VALUE, A.PRD_SEARCH_LABEL4,
A.PRD_SEARCH_LABEL4_VALUE, A.PRD_SEARCH_LABEL5, A.PRD_SEARCH_LABEL5_VALUE,
A.PRD_SEARCH_LABEL6, A.PRD_SEARCH_LABEL6_VALUE, A.PRD_SEARCH_CAT_ID,
A.PRD_SEARCH_CAT_NAME, A.PRD_SEARCH_CAT_FLNAME, A.PRD_SEARCH_NAVIGATION_TREE,
A.PRD_SEARCH_NAVIGATION_TREE_ID,A.PRD_SEARCH_CITY, A.PRD_SEARCH_STATE,
A.PRD_SEARCH_COUNTRY, A.PRD_SEARCH_PRICE_SALE, A.PRD_SEARCH_PC_CLNT_TYPE,
A.PRD_SEARCH_PC_CLNT_TYPE_DESC,
A.PRD_SEARCH_COMPANY_PHONE, A.PRD_SEARCH_COMPANY_MOBILE, A.PRD_SEARCH_COMPANY_FAX,
A.PRD_SEARCH_COMPANY_EMAIL, A.PRD_SEARCH_GLCAT_MCAT_ID_LIST, A.PRD_SEARCH_GLCAT_CAT_ID_LIST,
A.PRD_SEARCH_GLCAT_GRP_ID_LIST, A.PRD_SEARCH_GL_COUNTRY_ISO, A.PRD_SEARCH_GLUSR_USR_ID,
A.PRD_SEARCH_TRUSTSEAL_CODE, A.PRD_SEARCH_CUSTTYPE_ID, A.PRD_SEARCH_CUSTTYPE_NAME,
A.PRD_SEARCH_CUSTTYPE_WEIGHT, A.PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, A.PRD_SEARCH_CUSTTYPE_RANK,
A.PRD_SEARCH_PC_ITEM_HOTNEW, A.RK
FROM
(SELECT /*+ FIRST_ROWS (500) */ DECODE(:S_MODE,2,1,3,to_number(to_char(PRD_SEARCH_MODIFIEDDATE,'yyyymmdd')),1) AS SC,
PRD_SEARCH_ID,
PRD_SEARCH_COMPANY_ID, PRD_SEARCH_COMPANY, PRD_SEARCH_COMPANYID_ENCRYPTED,
PRD_SEARCH_PCID, PRD_SEARCH_URL, PRD_SEARCH_PC_CLNT_HOME,
PRD_SEARCH_CLNT_ENABLED, PRD_SEARCH_CODE, PRD_SEARCH_NAME,
PRD_SEARCH_DESC_SMALL, PRD_SEARCH_DESC_DETAILED, PRD_SEARCH_DESC_HTML,
PRD_SEARCH_IMG_SMALL, PRD_SEARCH_IMG_LARGE, PRD_SEARCH_WEIGHT_ITEM,
PRD_SEARCH_MODIFIEDDATE, PRD_SEARCH_SIZE, PRD_SEARCH_LABEL1,
PRD_SEARCH_LABEL1_VALUE, PRD_SEARCH_LABEL2, PRD_SEARCH_LABEL2_VALUE,
PRD_SEARCH_LABEL3, PRD_SEARCH_LABEL3_VALUE, PRD_SEARCH_LABEL4,
PRD_SEARCH_LABEL4_VALUE, PRD_SEARCH_LABEL5, PRD_SEARCH_LABEL5_VALUE,
PRD_SEARCH_LABEL6, PRD_SEARCH_LABEL6_VALUE, PRD_SEARCH_CAT_ID,
PRD_SEARCH_CAT_NAME, PRD_SEARCH_CAT_FLNAME, PRD_SEARCH_NAVIGATION_TREE,
PRD_SEARCH_NAVIGATION_TREE_ID,PRD_SEARCH_CITY, PRD_SEARCH_STATE,
PRD_SEARCH_COUNTRY, PRD_SEARCH_PRICE_SALE, PRD_SEARCH_PC_CLNT_TYPE,
PRD_SEARCH_PC_CLNT_TYPE_DESC,
PRD_SEARCH_COMPANY_PHONE, PRD_SEARCH_COMPANY_MOBILE, PRD_SEARCH_COMPANY_FAX,
PRD_SEARCH_COMPANY_EMAIL, PRD_SEARCH_GLCAT_MCAT_ID_LIST, PRD_SEARCH_GLCAT_CAT_ID_LIST,
PRD_SEARCH_GLCAT_GRP_ID_LIST, PRD_SEARCH_GL_COUNTRY_ISO, PRD_SEARCH_GLUSR_USR_ID,
PRD_SEARCH_TRUSTSEAL_CODE, PRD_SEARCH_CUSTTYPE_ID, PRD_SEARCH_CUSTTYPE_NAME,
PRD_SEARCH_CUSTTYPE_WEIGHT, PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, PRD_SEARCH_CUSTTYPE_RANK,
PRD_SEARCH_PC_ITEM_HOTNEW,
ROW_NUMBER() OVER (PARTITION BY PRD_SEARCH_COMPANY_ID
ORDER BY DECODE(:S_MODE,2,1,3,to_number(to_char(PRD_SEARCH_MODIFIEDDATE,'yyyymmdd')),1) DESC) AS RK
FROM PRD_SEARCH
WHERE DECODE(:GRP_ID_STR,NULL,1,REGEXP_INSTR(','||REPLACE(PRD_SEARCH_GLCAT_GRP_ID_LIST,' ','')||',',:MYGRP_ID_STR)) > 0
AND DECODE(:CAT_ID_STR,NULL,1,REGEXP_INSTR(','||REPLACE(PRD_SEARCH_GLCAT_CAT_ID_LIST,' ','')||',',:MYCAT_ID_STR)) > 0
AND DECODE(:MCAT_ID_STR,NULL,1,REGEXP_INSTR(','||REPLACE(PRD_SEARCH_GLCAT_MCAT_ID_LIST,' ','')||',',:MYMCAT_ID_STR)) > 0
AND DECODE(:ITEM_ID_STR,NULL,1,REGEXP_INSTR(','||PRD_SEARCH_ID||',',:MYITEM_ID_STR)) > 0
AND DECODE(:COUNTRY_ISO,NULL,1,REGEXP_INSTR(','||PRD_SEARCH_GL_COUNTRY_ISO||',',:COUNTRY_ISO)) > 0
AND DECODE(nvl(NULL,0),0,1,PRD_SEARCH_COMPANY_ID) = DECODE(nvl(NULL,0),0,1,NULL)
AND DECODE(nvl(NULL,0),0,1,PRD_SEARCH_GLUSR_USR_ID) = DECODE(nvl(NULL,0),0,1,NULL)
AND PRD_SEARCH_CLNT_ENABLED >= nvl(:LIST_TYPE,0)
AND NVL(Length(PRD_SEARCH_TRUSTSEAL_CODE),0) >= :TSONLY
ORDER BY SC DESC, PRD_SEARCH_CUSTTYPE_WEIGHT ASC, DBMS_RANDOM.RANDOM
) A
WHERE A.RK <= :MY_PRD_PER_COMP
AND ROWNUM <= :MYMAXREC
ORDER BY SO DESC, DECODE(:OPT,2,'1',A.PRD_SEARCH_COMPANY), A.RK ASC, DBMS_RANDOM.RANDOM
SQL-2
SELECT
DECODE(:OPT,2,SC,(MAX(SC) OVER (PARTITION BY PRD_SEARCH_COMPANY))) AS SO,
SC, PRD_SEARCH_ID,
PRD_SEARCH_COMPANY_ID, PRD_SEARCH_COMPANY, PRD_SEARCH_COMPANYID_ENCRYPTED,
PRD_SEARCH_PCID, PRD_SEARCH_URL, PRD_SEARCH_PC_CLNT_HOME,
PRD_SEARCH_CLNT_ENABLED, PRD_SEARCH_CODE, PRD_SEARCH_NAME,
PRD_SEARCH_DESC_SMALL, PRD_SEARCH_DESC_DETAILED, PRD_SEARCH_DESC_HTML,
PRD_SEARCH_IMG_SMALL, PRD_SEARCH_IMG_LARGE, PRD_SEARCH_WEIGHT_ITEM,
PRD_SEARCH_MODIFIEDDATE, PRD_SEARCH_SIZE, PRD_SEARCH_LABEL1,
PRD_SEARCH_LABEL1_VALUE, PRD_SEARCH_LABEL2, PRD_SEARCH_LABEL2_VALUE,
PRD_SEARCH_LABEL3, PRD_SEARCH_LABEL3_VALUE, PRD_SEARCH_LABEL4,
PRD_SEARCH_LABEL4_VALUE, PRD_SEARCH_LABEL5, PRD_SEARCH_LABEL5_VALUE,
PRD_SEARCH_LABEL6, PRD_SEARCH_LABEL6_VALUE, PRD_SEARCH_CAT_ID,
PRD_SEARCH_CAT_NAME, PRD_SEARCH_CAT_FLNAME, PRD_SEARCH_NAVIGATION_TREE,
PRD_SEARCH_NAVIGATION_TREE_ID,PRD_SEARCH_CITY, PRD_SEARCH_STATE,
PRD_SEARCH_COUNTRY, PRD_SEARCH_PRICE_SALE, PRD_SEARCH_PC_CLNT_TYPE,
PRD_SEARCH_PC_CLNT_TYPE_DESC,
PRD_SEARCH_COMPANY_PHONE, PRD_SEARCH_COMPANY_MOBILE, PRD_SEARCH_COMPANY_FAX,
PRD_SEARCH_COMPANY_EMAIL, PRD_SEARCH_GLCAT_MCAT_ID_LIST, PRD_SEARCH_GLCAT_CAT_ID_LIST,
PRD_SEARCH_GLCAT_GRP_ID_LIST, PRD_SEARCH_GL_COUNTRY_ISO, PRD_SEARCH_GLUSR_USR_ID,
PRD_SEARCH_TRUSTSEAL_CODE, PRD_SEARCH_CUSTTYPE_ID, PRD_SEARCH_CUSTTYPE_NAME,
PRD_SEARCH_CUSTTYPE_WEIGHT, PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, PRD_SEARCH_CUSTTYPE_RANK,
PRD_SEARCH_PC_ITEM_HOTNEW, RK
FROM
SELECT
/*+ FIRST_ROWS (500) */ DECODE(:OPT,2,SC,(MAX(SC) OVER (PARTITION BY PRD_SEARCH_COMPANY))) AS SO,
SC,PRD_SEARCH_ID,
PRD_SEARCH_COMPANY_ID, PRD_SEARCH_COMPANY, PRD_SEARCH_COMPANYID_ENCRYPTED,
PRD_SEARCH_PCID, PRD_SEARCH_URL, PRD_SEARCH_PC_CLNT_HOME,
PRD_SEARCH_CLNT_ENABLED, PRD_SEARCH_CODE, PRD_SEARCH_NAME,
PRD_SEARCH_DESC_SMALL, PRD_SEARCH_DESC_DETAILED, PRD_SEARCH_DESC_HTML,
PRD_SEARCH_IMG_SMALL, PRD_SEARCH_IMG_LARGE, PRD_SEARCH_WEIGHT_ITEM,
PRD_SEARCH_MODIFIEDDATE, PRD_SEARCH_SIZE, PRD_SEARCH_LABEL1,
PRD_SEARCH_LABEL1_VALUE, PRD_SEARCH_LABEL2, PRD_SEARCH_LABEL2_VALUE,
PRD_SEARCH_LABEL3, PRD_SEARCH_LABEL3_VALUE, PRD_SEARCH_LABEL4,
PRD_SEARCH_LABEL4_VALUE, PRD_SEARCH_LABEL5, PRD_SEARCH_LABEL5_VALUE,
PRD_SEARCH_LABEL6, PRD_SEARCH_LABEL6_VALUE, PRD_SEARCH_CAT_ID,
PRD_SEARCH_CAT_NAME, PRD_SEARCH_CAT_FLNAME, PRD_SEARCH_NAVIGATION_TREE,
PRD_SEARCH_NAVIGATION_TREE_ID,PRD_SEARCH_CITY, PRD_SEARCH_STATE,
PRD_SEARCH_COUNTRY, PRD_SEARCH_PRICE_SALE, PRD_SEARCH_PC_CLNT_TYPE,
PRD_SEARCH_PC_CLNT_TYPE_DESC,
PRD_SEARCH_COMPANY_PHONE, PRD_SEARCH_COMPANY_MOBILE, PRD_SEARCH_COMPANY_FAX,
PRD_SEARCH_COMPANY_EMAIL, PRD_SEARCH_GLCAT_MCAT_ID_LIST, PRD_SEARCH_GLCAT_CAT_ID_LIST,
PRD_SEARCH_GLCAT_GRP_ID_LIST, PRD_SEARCH_GL_COUNTRY_ISO, PRD_SEARCH_GLUSR_USR_ID,
PRD_SEARCH_TRUSTSEAL_CODE, PRD_SEARCH_CUSTTYPE_ID, PRD_SEARCH_CUSTTYPE_NAME,
PRD_SEARCH_CUSTTYPE_WEIGHT, PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, PRD_SEARCH_CUSTTYPE_RANK,
PRD_SEARCH_PC_ITEM_HOTNEW,
ROW_NUMBER() OVER (PARTITION BY PRD_SEARCH_COMPANY_ID
ORDER BY DECODE(:S_MODE,2,1,3,TO_NUMBER(TO_CHAR(PRD_SEARCH_MODIFIEDDATE,'YYYYMMDD')),1) DESC) AS RK
FROM
SELECT
DECODE(:S_MODE,2,1,3,TO_NUMBER(TO_CHAR(PRD_SEARCH_MODIFIEDDATE,'YYYYMMDD')),1) AS SC,
PRD_SEARCH_ID,
PRD_SEARCH_COMPANY_ID, PRD_SEARCH_COMPANY, PRD_SEARCH_COMPANYID_ENCRYPTED,
PRD_SEARCH_PCID, PRD_SEARCH_URL, PRD_SEARCH_PC_CLNT_HOME,
PRD_SEARCH_CLNT_ENABLED, PRD_SEARCH_CODE, PRD_SEARCH_NAME,
PRD_SEARCH_DESC_SMALL, PRD_SEARCH_DESC_DETAILED, PRD_SEARCH_DESC_HTML,
PRD_SEARCH_IMG_SMALL, PRD_SEARCH_IMG_LARGE, PRD_SEARCH_WEIGHT_ITEM,
PRD_SEARCH_MODIFIEDDATE, PRD_SEARCH_SIZE, PRD_SEARCH_LABEL1,
PRD_SEARCH_LABEL1_VALUE, PRD_SEARCH_LABEL2, PRD_SEARCH_LABEL2_VALUE,
PRD_SEARCH_LABEL3, PRD_SEARCH_LABEL3_VALUE, PRD_SEARCH_LABEL4,
PRD_SEARCH_LABEL4_VALUE, PRD_SEARCH_LABEL5, PRD_SEARCH_LABEL5_VALUE,
PRD_SEARCH_LABEL6, PRD_SEARCH_LABEL6_VALUE, PRD_SEARCH_CAT_ID,
PRD_SEARCH_CAT_NAME, PRD_SEARCH_CAT_FLNAME, PRD_SEARCH_NAVIGATION_TREE,
PRD_SEARCH_NAVIGATION_TREE_ID,PRD_SEARCH_CITY, PRD_SEARCH_STATE,
PRD_SEARCH_COUNTRY, PRD_SEARCH_PRICE_SALE, PRD_SEARCH_PC_CLNT_TYPE,
PRD_SEARCH_PC_CLNT_TYPE_DESC,
PRD_SEARCH_COMPANY_PHONE, PRD_SEARCH_COMPANY_MOBILE, PRD_SEARCH_COMPANY_FAX,
PRD_SEARCH_COMPANY_EMAIL, PRD_SEARCH_GLCAT_MCAT_ID_LIST, PRD_SEARCH_GLCAT_CAT_ID_LIST,
PRD_SEARCH_GLCAT_GRP_ID_LIST, PRD_SEARCH_GL_COUNTRY_ISO, PRD_SEARCH_GLUSR_USR_ID,
PRD_SEARCH_TRUSTSEAL_CODE, PRD_SEARCH_CUSTTYPE_ID, PRD_SEARCH_CUSTTYPE_NAME,
PRD_SEARCH_CUSTTYPE_WEIGHT, PRD_SEARCH_CUSTTYPE_WEIGHT_TZ, PRD_SEARCH_CUSTTYPE_RANK,
PRD_SEARCH_PC_ITEM_HOTNEW,
ROW_NUMBER() OVER (PARTITION BY P.PRD_SEARCH_ID ORDER BY P.PRD_SEARCH_ID) RK1
FROM
GLCAT_GRP_TO_CAT G2C, GLCAT_CAT_TO_MCAT C2M, PC_ITEM_TO_GLCAT_MCAT M, PRD_SEARCH P
WHERE
G2C.FK_GLCAT_CAT_ID = C2M.FK_GLCAT_CAT_ID
AND C2M.FK_GLCAT_MCAT_ID = M.FK_GLCAT_MCAT_ID
AND M.FK_PC_ITEM_ID = P.PRD_SEARCH_ID
AND DECODE(:MCAT_ID_STR, NULL, 1, INSTR(','||:MCAT_ID_STR||',',','||M.FK_GLCAT_MCAT_ID||',',1))> 0
AND DECODE(:CAT_ID_STR, NULL, 1, INSTR(','||:CAT_ID_STR||',',','||C2M.FK_GLCAT_CAT_ID||',',1)) > 0
AND DECODE(:GRP_ID_STR, NULL, 1, INSTR(','||:GRP_ID_STR||',',','||G2C.FK_GLCAT_GRP_ID||',',1)) > 0
AND DECODE(:ITEM_ID_STR,NULL,1,INSTR(','||:ITEM_ID_STR||',' , ','||P.PRD_SEARCH_ID||',')) > 0
AND DECODE(:COUNTRY_ISO,NULL,1,INSTR(','||:COUNTRY_ISO||',', ','||P.PRD_SEARCH_GL_COUNTRY_ISO||',')) > 0
AND DECODE(NVL(:COMPANY_ID,0),0,1,P.PRD_SEARCH_COMPANY_ID) = DECODE(NVL(:COMPANY_ID,0),0,1,:COMPANY_ID)
AND DECODE(NVL(:GLUSR_ID,0),0,1,P.PRD_SEARCH_GLUSR_USR_ID) = DECODE(NVL(:GLUSR_ID,0),0,1,:GLUSR_ID)
AND P.PRD_SEARCH_CLNT_ENABLED >= NVL(:LIST_TYPE,0)
AND NVL(LENGTH(P.PRD_SEARCH_TRUSTSEAL_CODE),0) >= :TSONLY
WHERE RK1=1
ORDER BY SC DESC, PRD_SEARCH_CUSTTYPE_WEIGHT ASC, DBMS_RANDOM.RANDOM
) A
WHERE A.RK <= :MY_PRD_PER_COMP
AND ROWNUM <= :MYMAXREC
ORDER BY A.SO DESC, DECODE(:OPT,2,'1', A.PRD_SEARCH_COMPANY), A.RK ASC, DBMS_RANDOM.RANDOMRegards
Madhup -
I like the explain plan functionality - it is good for doing spot checks on execution plans. Unfortunately, I cannot copy the plan once it is produced, so if I need to send someone a copy of the plan, I revert to producing the execution plan in TOAD.
Yes ..
I too feel same.
I right-click explain plan in TOAD and then paste it in excel.
It goes there row by row...Useful Feature.
--Sanjeev -
EXPLAIN PLAN estimate is WAY off!
I used Explain Plan to estimate the time it will take to run a SQL query.
This is the query:
select to_char (a.calldate,'yyyy')as "date", a.CALL_TYPE_ABBR_NAME, b.name, sum(a.call_price) as "monthly revenue"
from allcalls a, call_types b
where a.CALL_TYPE_ABBR_NAME= b.code
group by to_char (a.calldate,'yyyy'), a.CALL_TYPE_ABBR_NAME, b.name
order by to_char (a.calldate,'yyyy'),a.CALL_TYPE_ABBR_NAME, b.name;
allcalls table has 12,669,348 records and call_types has only 3.
Both tables have been analyzed.
The query actually takes only 2 minutes and 21 seconds to complete execution.
But according to EXPLAIN PLAN and SELECT plan_table_output FROM table(dbms_xplan.display) it will take 2 hours. The output of the table(dbms_xplan.display) is:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD></HEAD>
<BODY><!--StartFragment--><TABLE>
<TBODY>
<TR bgcolor=#afafaf>
<TD><B>PLAN_TABLE_OUTPUT</B></TD></TR><TR>
<TD>Plan hash value: 3083213950</TD>
</TR>
<TR>
<TD> </TD>
</TR>
<TR>
<TD>------------------------------------------------------------------------------------------</TD>
</TR>
<TR>
<TD>| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |</TD>
</TR>
<TR>
<TD>------------------------------------------------------------------------------------------</TD>
</TR>
<TR>
<TD>| 0 | SELECT STATEMENT | | 12M| 241M| | 215K (1)| 00:43:05 |</TD>
</TR>
<TR>
<TD>| 1 | SORT GROUP BY | | 12M| 241M| 776M| 215K (1)| 00:43:05 |</TD>
</TR>
<TR>
<TD>|* 2 | HASH JOIN | | 12M| 241M| | 138K (1)| 00:27:40 |</TD>
</TR>
<TR>
<TD>| 3 | TABLE ACCESS FULL| CALL_TYPES | 3 | 30 | | 3 (0)| 00:00:01 |</TD>
</TR>
<TR>
<TD>| 4 | TABLE ACCESS FULL| ALLCALLS | 12M| 120M| | 138K (1)| 00:27:39 |</TD>
</TR>
<TR>
<TD>------------------------------------------------------------------------------------------</TD>
</TR>
<TR>
<TD> </TD>
</TR>
<TR>
<TD>Predicate Information (identified by operation id):</TD>
</TR>
<TR>
<TD>---------------------------------------------------</TD>
</TR>
<TR>
<TD> </TD>
</TR>
<TR>
<TD> 2 - access("A"."CALL_TYPE_ABBR_NAME"="B"."CODE")</TD>
</TR>
</TBODY></TABLE><!--EndFragment--></BODY>
</HTML>
So, it's basically useless to rely on EXPLAIN PLAIN to estimate the time it will take to run a query? Or is there something else we can do to get the estimate better?Hello Channa,
You are really going about this thing the wrong way... but... you have amused a few :)
As you've been told (a number of times and, a number of different ways :) ) any attempt at pegging the execution time of a SQL statement is quite futile and rather irrelevant to boot.
This is what I suggest you do:
1. Whatever application you are selling, it must handle a certain volume of data. Since I don't know anything about the application you're selling, I'm going to give you an example while pulling numbers out of my magic hat ;) . Let's presume that your application should handle reasonably well 12,000,000 rows spread across 100 tables and, that there are a number of reports that are run with greater frequency than others. (since you know your application, you'll need to adjust these numbers for whatever are representative numbers for your app).
1.1 As an aside, I would not tell a prospective customer that you've tested the system using 14 rows. That could turn a few of them off ;) In other words, would you buy a database product from anyone that told you "Oh yeah! we tested it with 14 rows, it did great! ... runs like champ!" ? probably not. That's why you need larger numbers as pointed out in 1. above.
2. Once you have a setup with a reasonable number of rows ;) you run whatever reports are important to your customers and you time them. The timings don't have to be exact, they'll vary but, everything being kept equal, the variation won't be as dramatic as using 14 rows ;)
2.1 Given a reasonable test sample - meaning: more rows than there are donuts in a cop's car at 7:00 a.m - you customarily throw away the best and worst run times because those are often not representative.
2.2 You compute an average and a standard deviation (this is not hard to do)
2.3 You tell your customers that in order to get similar results to what you've presented they need xyz hardware configuration. In other words, you qualify the environment in which those results can be obtained.
If someone asks for an exact figure, you tell them that there are refreshments on the table ;) or, if you are so inclined, you explain that exact is not possible.
HTH,
John. -
Hello everyone,
I'm trying to understand the difference between those two, I'm relying on the following Tom Kyte article :
http://tkyte.blogspot.com/2007/04/when-explanation-doesn-sound-quite.html
In my following example I didn't use TKPROF as he did but AUTOTRACE / V$SQL_PLAN instead (since EXPLAIN PLAN shows a theoretical plan that can be used if this statement were to be executed and V$SQL_PLAN contains the actual plan used)
That's my code :
>
HR> ALTER SYSTEM FLUSH shared_pool ;
HR>
HR> create table test
2 as
3 select a.*, 1 id
4 from all_objects a
5 where rownum = 1;
Table created.
HR>
HR> create index t_idx on test(id);
Index created.
HR>
HR> -- AUTOTRACE vs V$SQL round 1 ...
HR> ---------------------------------
HR>
HR> SET AUTOTRACE ON EXPLAIN
HR>
HR> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ICOL$
Execution Plan
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 30 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 30 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=2)
HR>
HR> SET AUTOTRACE OFF
HR>
HR>
HR> select operation, options, object_name, cost
2 from v$sql_plan
3 where hash_value= ( SELECT hash_value
4 FROM v$sqlarea
5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
6 AND sql_text NOT LIKE '%v_sql%');
OPERATION OPTIONS OBJECT_NAME COST
SELECT STATEMENT 2
TABLE ACCESS BY INDEX ROWID TEST 2
INDEX RANGE SCAN T_IDX 1
>
Ok so in round 1, the optimizer decided to get the 1 row back using Index Range Scan both in "theory" and in "reality", it make sense.
Now its time for round 2 ... :)
>
HR> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
1000 rows created.
HR>
HR> commit ;
Commit complete.
HR>
HR>
HR> -- AUTOTRACE vs V$SQL round 2 ...
HR> ---------------------------------
HR>
HR> SET AUTOTRACE ON EXPLAIN
HR>
HR> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ICOL$
1 I_VIEWTRCOL1
1001 rows selected.
Execution Plan
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1001 | 30030 | 6 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1001 | 30030 | 6 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1001 | | 5 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=2)
HR>
HR> select operation, options, object_name, cost
2 from v$sql_plan
3 where hash_value= ( SELECT hash_value
4 FROM v$sqlarea
5 WHERE sql_text LIKE 'select id, object_name from test where id = 1'
6 AND sql_text NOT LIKE '%v_sql%');
OPERATION OPTIONS OBJECT_NAME COST
SELECT STATEMENT 2
TABLE ACCESS BY INDEX ROWID TEST 2
INDEX RANGE SCAN T_IDX 1
HR>
>
since explain plan is using always Hard Parse (and it used dynamic sampling) I would expect to see FTS in "theory"
can anyone explain me why in round 2 they both presented Index Range Scan.
Thanks ! :)Explain plan can lie, autotrace - which just does an explain plan - can lie.
See:
http://oracle-randolf.blogspot.com/2012/01/autotrace-polluting-shared-pool.html
http://kerryosborne.oracle-guy.com/2010/02/autotrace-lies/
http://hoopercharles.wordpress.com/2010/01/11/explain-plan-lies-autotrace-lies-tkprof-lies-what-is-the-plan/
V$SQL_PLAN is the truth.
You didn't mention version but DBMS_XPLAN is the most convenient way to get your plan.
If the plan is cached, inserting 1000 rows is not going to change the plan.
SQL> create table test
2 as
3 select a.*, 1 id
4 from all_objects a
5 where rownum = 1;
Table created.
SQL>
SQL> create index t_idx on test(id);
Index created.
SQL>
SQL> select id, object_name from test where id = 1;
ID OBJECT_NAME
1 ORA$BASE
SQL>
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
SQL_ID 3qan6s0j3uab5, child number 0
select id, object_name from test where id = 1
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 2 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 30 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=4)
23 rows selected.
SQL> insert into test select a.*, 1 from all_objects a where rownum < 1001 ;
1000 rows created.
SQL> commit;
Commit complete.
SQL> select id, object_name from test where id = 1;
SQL> select * from table(dbms_xplan.display_cursor);
PLAN_TABLE_OUTPUT
SQL_ID 3qan6s0j3uab5, child number 0
select id, object_name from test where id = 1
Plan hash value: 2783519773
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 2 (100)| |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 30 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("ID"=1)
Note
- dynamic sampling used for this statement (level=4)
23 rows selected.
SQL> -
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bi
PL/SQL Release 10.2.0.2.0 - Production
CORE 10.2.0.2.0 Production
TNS for Linux: Version 10.2.0.2.0 - Production
NLSRTL Version 10.2.0.2.0 - ProductionExplain plan
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 7134K| 1238M| | 448K (2)| 01:29:39 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 7134K| 1238M| | 448K (2)| 01:29:39 | | | Q1,03 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 7134K| 1238M| 2858M| 448K (2)| 01:29:39 | | | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 7134K| 1238M| | 408K (2)| 01:21:42 | | | Q1,03 | PCWP | |
| 5 | PX SEND HASH | :TQ10002 | 7134K| 1238M| | 408K (2)| 01:21:42 | | | Q1,02 | P->P | HASH |
|* 6 | HASH JOIN BUFFERED | | 7134K| 1238M| 1873M| 408K (2)| 01:21:42 | | | Q1,02 | PCWP | |
| 7 | PX RECEIVE | | 137M| 13G| | 97898 (3)| 00:19:35 | | | Q1,02 | PCWP | |
| 8 | PX SEND HASH | :TQ10000 | 137M| 13G| | 97898 (3)| 00:19:35 | | | Q1,00 | P->P | HASH |
| 9 | PX BLOCK ITERATOR | | 137M| 13G| | 97898 (3)| 00:19:35 | 1 | 4 | Q1,00 | PCWC | |
|* 10 | TABLE ACCESS FULL | ORII | 137M| 13G| | 97898 (3)| 00:19:35 | 189 | 192 | Q1,00 | PCWP | |
| 11 | PX RECEIVE | | 466 | 28426 | | 5 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 12 | PX SEND HASH | :TQ10001 | 466 | 28426 | | 5 (0)| 00:00:01 | | | Q1,01 | P->P | HASH |
|* 13 | TABLE ACCESS BY GLOBAL INDEX ROWID| MII | 466 | 28426 | | 5 (0)| 00:00:01 | ROWID | ROWID | Q1,01 | PCWC | |
| 14 | NESTED LOOPS | | 177M| 13G| | 119K (1)| 00:23:58 | | | Q1,01 | PCWP | |
| 15 | PX BLOCK ITERATOR | | 381K| 7073K| | 24376 (3)| 00:04:53 | 1 | 126 | Q1,01 | PCWC | |
|* 16 | TABLE ACCESS FULL | DI | 381K| 7073K| | 24376 (3)| 00:04:53 | 1 | 126 | Q1,01 | PCWP | |
|* 17 | INDEX RANGE SCAN | IDX_MII | 482 | | | 0 (0)| 00:00:01 | | | Q1,01 | PCWP | |
Predicate Information (identified by operation id):
6 - access("RNII"."LEGAL_ENTITY_ID"="MII"."LEGAL_ENTITY_ID" AND "RNII"."ORDER_ID"="MII"."DISTRIBUTOR_ORDER_ID" AND
"RNII"."SHIPMENT_ID"="MII"."DISTRIBUTOR_SHIPMENT_ID" AND "RNII"."ASIN"="MII"."ASIN")
10 - filter("RNII"."RNII_SOURCE_NAME"='distributor_shipment_item' AND "RNII"."SNAPSHOT_DAY"=TO_DATE('2010-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
"RNII"."LEGAL_ENTITY_ID"=101)
13 - filter("MII"."LEGAL_ENTITY_ID"=101)
16 - filter("DI"."GL_DATE">=TO_DATE('2009-12-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "DI"."INVOICE_STATUS"='4' AND "DI"."LEGAL_ENTITY_ID"=101 AND
"DI"."GL_DATE"<TO_DATE('2010-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
17 - access("MII"."INVOICE_ID"="DI"."INVOICE_ID")Below are my questions:
Q1-Which operation should start first. Is that Nested Loop between di and mii tables or creating HASH table for rnii. When i monitored SQL execution in V$SQL_WORKAREA_ACTIVE, it was doing HASH JOIN operation (Operation ID=6) first. Query started executing with 16 parallel slaves (DOP for di=1,mii=1 and rnii=8 at table level). 8 slaves were doing HASH JOIN while remaining 8 were sitting idle. I want to understand why slaves were sitting idle and not doing NL? Each slave has used 1.59 GB (total ~12.5GB) on TEMP, which goes with CBO's assumption to use 13 GB TEMP.
Once HASH JOIN (operation 6) is done, i have seen that 4 slaves were scanning mii table using 'db file sequential wait''. Which made me realize that RNII table was the driving and NL's join row source were acting as probing table. I am not sure whether my thinking is right or not? This query took 9 min to retrun 4.2 Million rows.
Username QC/Slav SlaveSet SID QC SID Slave INST STATE WAIT_EVENT QC INST Req. DOP Actual DOP
DBA QC 471 471 1 WAIT PX Deq: Execute Reply
- p005 (Slave) 1 217 1 NOT WAIT 1 8 8
- p004 (Slave) 1 442 1 NOT WAIT 1 8 8
- p003 (Slave) 1 482 1 NOT WAIT 1 8 8
- p001 (Slave) 1 394 1 NOT WAIT 1 8 8
- p000 (Slave) 1 493 1 NOT WAIT 1 8 8
- p007 (Slave) 1 353 1 NOT WAIT 1 8 8
- p006 (Slave) 1 477 1 NOT WAIT 1 8 8
- p002 (Slave) 1 313 1 NOT WAIT 1 8 8
- p015 (Slave) 2 306 1 WAIT PX Deq: Table Q Normal 1 8 8
- p014 (Slave) 2 432 1 WAIT PX Deq: Table Q Normal 1 8 8
- p013 (Slave) 2 333 1 WAIT PX Deq: Table Q Normal 1 8 8
- p012 (Slave) 2 476 1 WAIT PX Deq: Table Q Normal 1 8 8
- p011 (Slave) 2 418 1 WAIT PX Deq: Table Q Normal 1 8 8
- p010 (Slave) 2 275 1 WAIT PX Deq: Table Q Normal 1 8 8
- p009 (Slave) 2 328 1 WAIT PX Deq: Table Q Normal 1 8 8
- p008 (Slave) 2 510 1 WAIT PX Deq: Table Q Normal 1 8 8
SID SQL_HASH_VALUE QCSID OPERATION_ID TYPE POLICY WSIZE_MB EXP_SIZE_MB ACT_SIZE_MB MAX_SIZE_MB PASSES TEMP
328 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1596
333 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
275 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1596
432 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
510 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
306 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
418 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1597
476 4177171096 471 6 HASH-JOIN AUTO 63.36 63.36 55.07 55.07 1 1596Index on mii table is a GLOBAL non-partitioned index. Which made me think, why scanning of mii table were going in parallel with 'db file sequential wait'?
When i use NO_SWAP_JOIN_INPUTS(rnii) hint in query, i got below Explain plan:
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 7134K| 1238M| | 448K (2)| 01:29:38 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 7134K| 1238M| | 448K (2)| 01:29:38 | | | Q1,03 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 7134K| 1238M| 2858M| 448K (2)| 01:29:38 | | | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 7134K| 1238M| | 408K (2)| 01:21:42 | | | Q1,03 | PCWP | |
| 5 | PX SEND HASH | :TQ10002 | 7134K| 1238M| | 408K (2)| 01:21:42 | | | Q1,02 | P->P | HASH |
|* 6 | HASH JOIN BUFFERED | | 7134K| 1238M| 1948M| 408K (2)| 01:21:42 | | | Q1,02 | PCWP | |
| 7 | PX RECEIVE | | 466 | 28426 | | 5 (0)| 00:00:01 | | | Q1,02 | PCWP | |
| 8 | PX SEND HASH | :TQ10000 | 466 | 28426 | | 5 (0)| 00:00:01 | | | Q1,00 | P->P | HASH |
|* 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| MATCHED_INVOICE_ITEMS | 466 | 28426 | | 5 (0)| 00:00:01 | ROWID | ROWID | Q1,00 | PCWC | |
| 10 | NESTED LOOPS | | 177M| 13G| | 119K (1)| 00:23:58 | | | Q1,00 | PCWP | |
| 11 | PX BLOCK ITERATOR | | 381K| 7073K| | 24376 (3)| 00:04:53 | 1 | 126 | Q1,00 | PCWC | |
|* 12 | TABLE ACCESS FULL | DISTRIBUTOR_INVOICES | 381K| 7073K| | 24376 (3)| 00:04:53 | 1 | 126 | Q1,00 | PCWP | |
|* 13 | INDEX RANGE SCAN | I_MII_INVOICE_ID_ITEM_ID | 482 | | | 0 (0)| 00:00:01 | | | Q1,00 | PCWP | |
| 14 | PX RECEIVE | | 137M| 13G| | 97898 (3)| 00:19:35 | | | Q1,02 | PCWP | |
| 15 | PX SEND HASH | :TQ10001 | 137M| 13G| | 97898 (3)| 00:19:35 | | | Q1,01 | P->P | HASH |
| 16 | PX BLOCK ITERATOR | | 137M| 13G| | 97898 (3)| 00:19:35 | 1 | 4 | Q1,01 | PCWC | |
|* 17 | TABLE ACCESS FULL | O_RECEIVED_NOT_INVOICED_ITEMS | 137M| 13G| | 97898 (3)| 00:19:35 | 189 | 192 | Q1,01 | PCWP | |
Predicate Information (identified by operation id):
6 - access("RNII"."LEGAL_ENTITY_ID"="MII"."LEGAL_ENTITY_ID" AND "RNII"."ORDER_ID"="MII"."DISTRIBUTOR_ORDER_ID" AND
"RNII"."SHIPMENT_ID"="MII"."DISTRIBUTOR_SHIPMENT_ID" AND "RNII"."ASIN"="MII"."ASIN")
9 - filter("MII"."LEGAL_ENTITY_ID"=101)
12 - filter("DI"."GL_DATE">=TO_DATE('2009-12-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "DI"."INVOICE_STATUS"='4' AND "DI"."LEGAL_ENTITY_ID"=101 AND
"DI"."GL_DATE"<TO_DATE('2010-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
13 - access("MII"."INVOICE_ID"="DI"."INVOICE_ID")
17 - filter("RNII"."RNII_SOURCE_NAME"='distributor_shipment_item' AND "RNII"."SNAPSHOT_DAY"=TO_DATE('2010-01-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND
"RNII"."LEGAL_ENTITY_ID"=101)When i use above hint, query took 5 min only. During its execution, i have monitored that NL HASH JOIN (rnii) were happening in parallel using 8 slaves. Below is snippet of that:
Username QC/Slav SlaveSet SID QC SID Slave INST STATE WAIT_EVENT QC INST Req. DOP Actual DOP
DBA QC 471 471 1 WAIT PX Deq: Execute Reply
- p005 (Slave) 1 275 1 WAIT db file sequential read 1 8 8
- p004 (Slave) 1 328 1 NOT WAIT 1 8 8
- p003 (Slave) 1 432 1 WAIT db file sequential read 1 8 8
- p001 (Slave) 1 394 1 NOT WAIT 1 8 8
- p000 (Slave) 1 477 1 WAIT db file parallel read 1 8 8
- p007 (Slave) 1 493 1 NOT WAIT 1 8 8
- p006 (Slave) 1 482 1 WAIT db file sequential read 1 8 8
- p002 (Slave) 1 333 1 WAIT db file parallel read 1 8 8
- p015 (Slave) 2 442 1 WAIT PX Deq: Table Q Normal 1 8 8
- p014 (Slave) 2 353 1 WAIT PX Deq: Table Q Normal 1 8 8
- p013 (Slave) 2 510 1 WAIT PX Deq: Table Q Normal 1 8 8
- p012 (Slave) 2 217 1 WAIT PX Deq: Table Q Normal 1 8 8
- p011 (Slave) 2 476 1 WAIT PX Deq: Table Q Normal 1 8 8
- p010 (Slave) 2 306 1 WAIT PX Deq: Table Q Normal 1 8 8
- p009 (Slave) 2 313 1 WAIT PX Deq: Table Q Normal 1 8 8
- p008 (Slave) 2 418 1 WAIT PX Deq: Table Q Normal 1 8 8
SID SQL_HASH_VALUE QCSID OPERATION_ID TYPE POLICY WSIZE_MB EXP_SIZE_MB ACT_SIZE_MB MAX_SIZE_MB PASSES TEMP
510 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
442 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
306 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
217 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
418 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
313 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
353 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
476 2547930387 471 6 HASH-JOIN AUTO 83.45 83.44 89.03 89.03 0 71
I believe 'db file parallel read' is due to TABLE PRE-FETCH (mii). My P_A_T is 4 GB.
I wanted to understand what factor should i consider to decide which table should be the driving and which should be the probe?
Thanks beforehand.OraDBA02 wrote:
1) Why 8 slaves were sitting idle while other 8 slaves were busy building HASH table from rnii in first execution plan?I don't see why do you think that 8 slaves were idle and 8 were busy. This output:
Username QC/Slav SlaveSet SID QC SID Slave INST STATE WAIT_EVENT QC INST Req. DOP Actual DOP
DBA QC 471 471 1 WAIT PX Deq: Execute Reply
- p005 (Slave) 1 217 1 NOT WAIT 1 8 8
- p004 (Slave) 1 442 1 NOT WAIT 1 8 8
- p003 (Slave) 1 482 1 NOT WAIT 1 8 8
- p001 (Slave) 1 394 1 NOT WAIT 1 8 8
- p000 (Slave) 1 493 1 NOT WAIT 1 8 8
- p007 (Slave) 1 353 1 NOT WAIT 1 8 8
- p006 (Slave) 1 477 1 NOT WAIT 1 8 8
- p002 (Slave) 1 313 1 NOT WAIT 1 8 8
- p015 (Slave) 2 306 1 WAIT PX Deq: Table Q Normal 1 8 8
- p014 (Slave) 2 432 1 WAIT PX Deq: Table Q Normal 1 8 8
- p013 (Slave) 2 333 1 WAIT PX Deq: Table Q Normal 1 8 8
- p012 (Slave) 2 476 1 WAIT PX Deq: Table Q Normal 1 8 8
- p011 (Slave) 2 418 1 WAIT PX Deq: Table Q Normal 1 8 8
- p010 (Slave) 2 275 1 WAIT PX Deq: Table Q Normal 1 8 8
- p009 (Slave) 2 328 1 WAIT PX Deq: Table Q Normal 1 8 8
- p008 (Slave) 2 510 1 WAIT PX Deq: Table Q Normal 1 8 8tells nothing about idleness, since this is just a snapshot.
2) If you look at both execution plans everything (row source,bytes,IN-OUT,TEMP columns) is same,except the Join order.
In first execution plan, join order is something like HASH (rnii, NL (di,mii)) while in second, it is HASH ((NL(di,mii),rnii).Read this blog post.
I think, long elapsed time of first plan is due to IDLE status of 8 slaves while HASH table is getting build up.Don't think, just get the execution profile using extended SQL trace.
3) Third question is regarding Index access in PARALLEL. (?). If you look at second plan, there are 2 px doing 'db file sequential read' on mii table and 2 px were doing 'db file parallel read'. The later is TABLE PRE-FETCH. I wanted to understand, how come index access (index on mii) got parallelised ? Is that Index leaf block scan in parallel or Table block access (from index rowid) in parallel ?Each slave performs IRS - it scans a part of driving table and performs NL join as usual for that part. That's it. -
Explain plan does not say anything about partition
Hello,
We have Oracle 11g database. And we have range partitioned a table. Now when I see explain plans for queries sometimes it says PARTITION RANGE ALL (when no filter), Some times PARTITION RANGE ITERATOR or PARTITION RANGE SINGLE or PARTITION RANGE JOIN FILTER etc. But sometimes it does not say any thing about partition.
Is the partition pruning being used? Since my understanding is that table is no more a monolithic sort of, but sort of table now has many tables for each partition.
So option is either scan all partition i.e display PARTITION RANGE ALL or scan some partitions, and display it in explain plan.
Am I thinking in wrong direction?
Please let me know.
Thank you,The only thing to do that makes sense is to back up all your data, erase the boot drive, reinstall and update the OS, then restore only your documents from backup and reinstall your third-party software from known-good copies.
Sadly, this is not practical at the current time. She is away from home, in a place with modem-speed internet access, without access to install media or her backups (which are on a hard drive at home.) I was able to operate on her machine by sshing in, and I did the best I could to remove the crap. The rest will have to wait until she gets back.
Here is something I found by googling:
http://nnrpanel.com/offlineAU.htm
Thank you, I will try them. I doubt they will know anything (since there are no Mac instructions on that page) but maybe they can at least send me to the US center. I have tried the US Nielsen Ratings contact form, three times now, but it appears that either they don't read it or they don't respond to it. It also has a maximum message size of about 250 characters.
I wonder if it may be related to one of those make money at home - be a secret shopper - review products at your leaisure and make a ton of moneydeals.
I would tend to doubt it, if only because they are clearly quite effective (or nobody would be running those ads) and yet nobody has reported this anywhere else that I can find.
I'm going to send some emails and see if I can find someone who knows something. -
Explain plan cardinallity is way off compared to actual rows being returned
Database version 11.2.0.3
We have a small but rapidly growing datawarehouse which has OBIEE as its front end reporting tool. Our DBA has set up a automatic stats gathering method in OEM and we can see that it run and gathers stats on stale objects on a regular basis. So we know the statistics are upto date.
In checking some slow queries I can see that the cardinality being reported in explain plans is way off compared to what is actually being returned.
For example the actual number of rows returned are 8000 but the cardinality estimate is > 300,000.
Now as per an Oracle White paper(The Oracle Optimizer Explain the Explain Plan) having "multiple single column predicates on a single table" can affect cardinality estimates and in case of our query that is true. Here is the "WHERE Clause section" of the query
SQL> select D1.c1 as c1,
2 D1.c2 as c2,
3 D1.c3 as c3,
4 D1.c4 as c4,
5 D1.c5 as c5,
6 D1.c6 as c6,
7 D1.c7 as c7,
8 D1.c8 as c8,
9 D1.c9 as c9,
10 D1.c10 as c10,
11 D1.c11 as c11,
12 D1.c12 as c12,
13 D1.c13 as c13,
14 D1.c14 as c14,
15 D1.c15 as c15,
16 D1.c16 as c16
17 from (select D1.c4 as c1,
18 D1.c5 as c2,
19 D1.c3 as c3,
20 D1.c1 as c4,
21 D1.c6 as c5,
22 D1.c7 as c6,
23 D1.c2 as c7,
24 D1.c8 as c8,
25 D1.c9 as c9,
26 D1.c10 as c10,
27 D1.c9 as c11,
28 D1.c11 as c12,
29 D1.c2 as c13,
30 D1.c2 as c14,
31 D1.c12 as c15,
32 'XYZ' as c16,
33 ROW_NUMBER() OVER(PARTITION BY D1.c2, D1.c3, D1.c4, D1.c5, D1.c6, D1.c7, D1.c8, D1.c9, D1.c10, D1.c11, D1.c12 ORDER BY D1.c2 ASC, D1.c3 ASC, D1.c4 ASC, D1.c5 ASC, D1.c6 ASC, D1.c
ASC, D1.c8 ASC, D1.c9 ASC, D1.c10 ASC, D1.c11 ASC, D1.c12 ASC) as c17
34 from (select distinct D1.c1 as c1,
35 D1.c2 as c2,
36 'CHANNEL1' as c3,
37 D1.c3 as c4,
38 D1.c4 as c5,
39 D1.c5 as c6,
40 D1.c6 as c7,
41 D1.c7 as c8,
42 D1.c8 as c9,
43 D1.c9 as c10,
44 D1.c10 as c11,
45 D1.c11 as c12
46 from (select sum(T610543.GLOBAL1_EXCHANGE_RATE * case
47 when T610543.X_ZEB_SYNC_EBS_FLG = 'Y' then
48 T610543.X_ZEB_AIA_U_REVN_AMT
49 else
50 0
51 end) as c1,
52 T536086.X_ZEBRA_TERRITORY as c2,
53 T526821.LEVEL9_NAME as c3,
54 T526821.LEVEL1_NAME as c4,
55 T577698.PER_NAME_FSCL_YEAR as c5,
56 T577698.FSCL_QTR as c6,
57 T31796.X_ZEBRA_TERRITORY as c7,
58 T31796.X_OU_NUM as c8,
59 T664055.TERRITORY as c9,
60 T536086.X_OU_NUM as c10,
61 T526821.LEVEL4_NAME as c11
62 from W_INT_ORG_D T613144 /* Dim_ZEB_W_INT_ORG_D_POS_Client_Attr_Direct */,
63 W_ZEBRA_REGION_D T664055 /* Dim_ZEB_W_ZEBRA_REGION_D_POS_Client_Direct */,
64 W_DAY_D T577698 /* Dim_ZEB_W_DAY_D_Order_Invoice_Date */,
65 WC_PRODUCT_HIER_DH T526821 /* Dim_WC_PRODUCT_HIER_DH */,
66 W_PRODUCT_D T32069 /* Dim_W_PRODUCT_D */,
67 W_ORG_D T31796,
68 W_ORG_D T536086 /* Dim_ZEB_W_ORG_D_Reseller */,
69 W_ORDERITEM_TMP_F T610543 /* Fact_ZEB_W_ORDERITEM_F_Direct */
70 where (T610543.PR_OWNER_BU_WID = T613144.ROW_WID and
71 T577698.ROW_WID =
72 T610543.X_ZEB_AIA_TRXN_DT_WID and
73 T32069.ROW_WID = T526821.PROD_WID and
74 T32069.ROW_WID = T610543.ROOT_LN_PROD_WID and
75 T536086.ROW_WID = T610543.ACCNT_WID and
76 T31796.DATASOURCE_NUM_ID =
77 T610543.DATASOURCE_NUM_ID and
78 T31796.INTEGRATION_ID = T610543.VIS_PR_BU_ID and
79 T536086.DELETE_FLG = 'N' and
80 T610543.X_ZEB_DELETE_FLG = 'N' and
81 T613144.X_ZEB_REGION_WID = T664055.ROW_WID and
82 T577698.FSCL_DAY_OF_YEAR < 97 and
83 '2006' < T577698.PER_NAME_FSCL_YEAR and
84 T536086.X_OU_NUM <> '11073' and
85 T536086.X_ZEBRA_TERRITORY !=
86 'XX23' and
87 T536086.X_OU_NUM != '56791647728774' and
88 T536086.X_OU_NUM != '245395890' and
89 T536086.X_ZEBRA_TERRITORY !=
90 'STRATEGIC ACCTS 2' and
91 T526821.LEVEL2_NAME != 'Charges' and
92 T526821.LEVEL9_NAME != 'Unspecified' and
93 T536086.X_ZEBRA_TERRITORY !=
94 'XX1' and T536086.X_ZEBRA_TERRITORY !=
95 'XX2' and T536086.X_ZEBRA_TERRITORY !=
96 'XX3' and T536086.X_ZEBRA_TERRITORY !=
97 'XX4' and
98 (T536086.X_ZEBRA_TERRITORY in
99 ( ... In List of 22 values )) and
125 T32069.X_ZEB_EBS_PRODUCT_TYPE is null)
126 group by T31796.X_ZEBRA_TERRITORY,
127 T31796.X_OU_NUM,
128 T526821.LEVEL1_NAME,
129 T526821.LEVEL4_NAME,
130 T526821.LEVEL9_NAME,
131 T536086.X_OU_NUM,
132 T536086.X_ZEBRA_TERRITORY,
133 T577698.FSCL_QTR,
134 T577698.PER_NAME_FSCL_YEAR,
135 T664055.TERRITORY) D1) D1) D1
136 where (D1.c17 = 1)
137 /
Elapsed: 00:00:35.19
Execution Plan
Plan hash value: 3285002974
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 2145M| 2123G| | 612K (1)| 03:03:47 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10012 | 2145M| 2123G| | 612K (1)| 03:03:47 | | | Q1,12 | P->S | QC (RAND) |
|* 3 | VIEW | | 2145M| 2123G| | 612K (1)| 03:03:47 | | | Q1,12 | PCWP | |
|* 4 | WINDOW NOSORT | | 2145M| 421G| | 612K (1)| 03:03:47 | | | Q1,12 | PCWP | |
| 5 | SORT GROUP BY | | 2145M| 421G| 448G| 612K (1)| 03:03:47 | | | Q1,12 | PCWP | |
| 6 | PX RECEIVE | | 2145M| 421G| | 1740 (11)| 00:00:32 | | | Q1,12 | PCWP | |
| 7 | PX SEND HASH | :TQ10011 | 2145M| 421G| | 1740 (11)| 00:00:32 | | | Q1,11 | P->P | HASH |
|* 8 | HASH JOIN BUFFERED | | 2145M| 421G| | 1740 (11)| 00:00:32 | | | Q1,11 | PCWP | |
| 9 | PX RECEIVE | | 268K| 7864K| | 93 (2)| 00:00:02 | | | Q1,11 | PCWP | |
| 10 | PX SEND HASH | :TQ10009 | 268K| 7864K| | 93 (2)| 00:00:02 | | | Q1,09 | P->P | HASH |
| 11 | PX BLOCK ITERATOR | | 268K| 7864K| | 93 (2)| 00:00:02 | | | Q1,09 | PCWC | |
| 12 | TABLE ACCESS FULL | W_ORG_D | 268K| 7864K| | 93 (2)| 00:00:02 | | | Q1,09 | PCWP | |
| 13 | PX RECEIVE | | 345K| 59M| | 1491 (2)| 00:00:27 | | | Q1,11 | PCWP | |
| 14 | PX SEND HASH | :TQ10010 | 345K| 59M| | 1491 (2)| 00:00:27 | | | Q1,10 | P->P | HASH |
|* 15 | HASH JOIN BUFFERED | | 345K| 59M| | 1491 (2)| 00:00:27 | | | Q1,10 | PCWP | |
| 16 | PX RECEIVE | | 1321 | 30383 | | 2 (0)| 00:00:01 | | | Q1,10 | PCWP | |
| 17 | PX SEND BROADCAST | :TQ10006 | 1321 | 30383 | | 2 (0)| 00:00:01 | | | Q1,06 | P->P | BROADCAST |
| 18 | PX BLOCK ITERATOR | | 1321 | 30383 | | 2 (0)| 00:00:01 | | | Q1,06 | PCWC | |
| 19 | TABLE ACCESS FULL | W_ZEBRA_REGION_D | 1321 | 30383 | | 2 (0)| 00:00:01 | | | Q1,06 | PCWP | |
|* 20 | HASH JOIN | | 345K| 52M| | 1488 (2)| 00:00:27 | | | Q1,10 | PCWP | |
| 21 | JOIN FILTER CREATE | :BF0000 | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,10 | PCWP | |
| 22 | PX RECEIVE | | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,10 | PCWP | |
| 23 | PX SEND HASH | :TQ10007 | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,07 | P->P | HASH |
| 24 | PX BLOCK ITERATOR | | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,07 | PCWC | |
| 25 | TABLE ACCESS FULL | W_INT_ORG_D | 9740 | 114K| | 2 (0)| 00:00:01 | | | Q1,07 | PCWP | |
| 26 | PX RECEIVE | | 344K| 47M| | 1486 (2)| 00:00:27 | | | Q1,10 | PCWP | |
| 27 | PX SEND HASH | :TQ10008 | 344K| 47M| | 1486 (2)| 00:00:27 | | | Q1,08 | P->P | HASH |
| 28 | JOIN FILTER USE | :BF0000 | 344K| 47M| | 1486 (2)| 00:00:27 | | | Q1,08 | PCWP | |
|* 29 | HASH JOIN BUFFERED | | 344K| 47M| | 1486 (2)| 00:00:27 | | | Q1,08 | PCWP | |
| 30 | JOIN FILTER CREATE | :BF0001 | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,08 | PCWP | |
| 31 | PX RECEIVE | | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,08 | PCWP | |
| 32 | PX SEND HASH | :TQ10004 | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,04 | P->P | HASH |
| 33 | PX BLOCK ITERATOR | | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,04 | PCWC | |
|* 34 | TABLE ACCESS FULL | W_ORG_D | 35290 | 964K| | 93 (2)| 00:00:02 | | | Q1,04 | PCWP | |
| 35 | PX RECEIVE | | 344K| 38M| | 1392 (2)| 00:00:26 | | | Q1,08 | PCWP | |
| 36 | PX SEND HASH | :TQ10005 | 344K| 38M| | 1392 (2)| 00:00:26 | | | Q1,05 | P->P | HASH |
| 37 | JOIN FILTER USE | :BF0001 | 344K| 38M| | 1392 (2)| 00:00:26 | | | Q1,05 | PCWP | |
|* 38 | HASH JOIN BUFFERED | | 344K| 38M| | 1392 (2)| 00:00:26 | | | Q1,05 | PCWP | |
| 39 | PX RECEIVE | | 93791 | 4671K| | 7 (0)| 00:00:01 | | | Q1,05 | PCWP | |
| 40 | PX SEND HASH | :TQ10001 | 93791 | 4671K| | 7 (0)| 00:00:01 | | | Q1,01 | P->P | HASH |
| 41 | PX BLOCK ITERATOR | | 93791 | 4671K| | 7 (0)| 00:00:01 | | | Q1,01 | PCWC | |
|* 42 | TABLE ACCESS FULL | WC_PRODUCT_HIER_DH | 93791 | 4671K| | 7 (0)| 00:00:01 | | | Q1,01 | PCWP | |
|* 43 | HASH JOIN | | 894K| 57M| | 1384 (2)| 00:00:25 | | | Q1,05 | PCWP | |
| 44 | JOIN FILTER CREATE | :BF0002 | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,05 | PCWP | |
| 45 | PX RECEIVE | | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,05 | PCWP | |
| 46 | PX SEND HASH | :TQ10002 | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,02 | P->P | HASH |
| 47 | PX BLOCK ITERATOR | | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,02 | PCWC | |
|* 48 | TABLE ACCESS FULL | W_PRODUCT_D | 243K| 1904K| | 48 (3)| 00:00:01 | | | Q1,02 | PCWP | |
| 49 | PX RECEIVE | | 894K| 50M| | 1336 (2)| 00:00:25 | | | Q1,05 | PCWP | |
| 50 | PX SEND HASH | :TQ10003 | 894K| 50M| | 1336 (2)| 00:00:25 | | | Q1,03 | P->P | HASH |
| 51 | JOIN FILTER USE | :BF0002 | 894K| 50M| | 1336 (2)| 00:00:25 | | | Q1,03 | PCWP | |
|* 52 | HASH JOIN | | 894K| 50M| | 1336 (2)| 00:00:25 | | | Q1,03 | PCWP | |
| 53 | PX RECEIVE | | 292 | 3504 | | 136 (0)| 00:00:03 | | | Q1,03 | PCWP | |
| 54 | PX SEND BROADCAST LOCAL| :TQ10000 | 292 | 3504 | | 136 (0)| 00:00:03 | | | Q1,00 | P->P | BCST LOCAL |
| 55 | PX BLOCK ITERATOR | | 292 | 3504 | | 136 (0)| 00:00:03 | | | Q1,00 | PCWC | |
|* 56 | TABLE ACCESS FULL | W_DAY_D | 292 | 3504 | | 136 (0)| 00:00:03 | | | Q1,00 | PCWP | |
| 57 | PX BLOCK ITERATOR | | 4801K| 215M| | 1199 (2)| 00:00:22 | 1 | 11 | Q1,03 | PCWC | |
|* 58 | TABLE ACCESS FULL | W_ORDERITEM_TMP_F | 4801K| 215M| | 1199 (2)| 00:00:22 | 1 | 44 | Q1,03 | PCWP | |
Note
- dynamic sampling used for this statement (level=5)
Statistics
498 recursive calls
2046 db block gets
1193630 consistent gets
74398 physical reads
0 redo size
655170 bytes sent via SQL*Net to client
11761 bytes received via SQL*Net from client
541 SQL*Net roundtrips to/from client
64 sorts (memory)
0 sorts (disk)
8090 rows processed
SQL>So my question is if, cardinality estimates are way off, is that an indicator that the explain plans being generated are sub-optimal?
Can you provide me with some tips or links to blog post or books on how I approach tuning such queries where cardinalities are not good?
Edited by: qqq on Apr 7, 2013 2:27 PMAs already asked in your other thread:
Please see the FAQ for how to post a tuning request and the information that you need to provide.
Part of that information is:
1. DDL for the table and indexes
2. The query being used
3. row counts for the table and for the predicates used in the query
4. info about stats. You did update the table and index stats didn't you?
5. The 'actual' execution plans.
An explain plan just shows what Oracle 'thinks' it is going to do. The actual plans show what Oracle actually 'did' do. Just because Oracle expected to save doesn't mean the savings were actually achieved.
When you post the plans use on the line before and on the line after to preserve formatting.
Your partial code is virtually unusable because of the missing conditions in the predicates. You need to use '!=' for 'not equals' if that's what those missing conditions are.
Please edit your post to use code tags, add the missing conditions and provide the other information needed for a tuning request.
Maybe you are looking for
-
Mail wont let me open new message window
Hello, So lately I have noticed a bug, I believe, in mail. At random times when I click on the new message icon nothing happens. However, if I close mail completely and reopen it, the new message window shows up. Any idea why this is happening? Thank
-
Is it possible to change the transfer mode at runtime?
I was building a WCF service using BasicHttpBinding which typically transmits small messages, but I can not know in advance what will be the maximum size of transmitted files. For these reasons, currently I set Streamed as transfer mode, using Stream
-
I ask this because I'm looking to erase my phone and start it over completely as new, I want to know by me doing that does that automatically erase my backed up memory or does it just keep it?
-
Deactivate default PO price from Info Record
Dear all, Would someone enlighten me how to deactivate PO price from Info Record. PO condition is setup as not control at plant level. Regards, Peck Har
-
Is there a trade-in program for iPad 2?
I'm a professional photographer and finding that 32GB is really not enough space for me. A total of 64GB would be close to perfect. So I'm wondering if I can simply trade my current one in. It's in perfect conditiion.