Restrict by scanning
It would be good that you can restrict either horizontal or vertical (or both) swiping. Sometimes I want that people slide down, but require them to return to the content if, for example, they reach the end of a vertical set of pages, rather than then dragging to the left or to the right and go to a page where I don't want them to go. I hope it's something that can be introduced in the DPS version 2015?
(Moved to the Digital Publishing Solution forum)
It is already supported in DPS2015. At the collection level, you can specify if horizontal scans must be enabled. Just change the properties of the collection and turn off the horizontal scans.
Neil
Tags: Experience Manager Mobile
Similar Questions
-
When Oracle make Index Fast full Scan?
Hi all
In this case, Oracle index full scan. Please give the solution with at least two example.
Thank you
Oops,
Spleen it was INDEX FAST FULL SCAN. Then index must be greater:
SQL > create table tbl in select * from dba_objects;
Table created.
SQL > alter table tbl
2 edit object_name not null;Modified table.
SQL > create index tbl_idx1 on tbl (object_name);
The index is created.
SQL > explain the plan for
2. Select object_name in tbl;He explained.
SQL > select * from table (dbms_xplan.display);
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------
Hash value of plan: 2675010997---------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
---------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 69022 | 4448K | 109 (1) | 00:00:02 |
| 1. FULL RESTRICTED INDEX SCAN FAST | TBL_IDX1 | 69022 | 4448K | 109 (1) | 00:00:02 |
---------------------------------------------------------------------------------Note
-----PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------
-dynamic sample used for this survey (level = 2)12 selected lines.
SQL >
SY.
-
Hello experts,
I am on 11g R2 RHEL5, I have a general question here, oracle said complete random for table scan reads are slower sequential reading, as far as my knowledge a sequential read is a monobloc read into the buffer cache, and read a straggling is a multiblock read that can occur for a full restricted index scan or a full table scan. My question is what is a shuffle? and how it is different from the sequential reading? on the technical side... Please put some light on these technical terms, so that I can work on the setting. There is also a warrant RANDOM i/o.In a very brief way, the scan would be something like, you ask for the first time for employees starting with the name 'Aman' (wasn't there a lot with this name) to access using an index be a better choice (perhaps not a good example of a column containing names in real time. Example is just for the sake of discussion) then asking with the name of 'John '.
Aman...
-
index_join by the rowid of the table?
Let's say you have a table like
(t)
int ID1,
ID2 int,
varchar (4000) textColumn1,.
varchar (4000) textColumn2,.
varchar (4000) textColumn3
)
And you have the index of individual columns on ID1 and ID2; composite index. In my situation, I can't create an index composite (ID1, ID2). But if I understand correctly, internally that both indices ID1 and ID2 are arranged as:
Id1.1 rowid.3
Id1.2 rowid.2
Id1.3 rowid.4
Id1.4 rowid.1
Id2.1 rowid.1
Id2.2 rowid.2
Id2.3 rowid.3
Id2.4 rowid.4
So, if you did
Select ID1 in t
where ID2 > 2;
A theoretically possible implementation plan would be to open the index the ID2 and ID1, find the ROWID for ID2, coincide with those against the ROWID in ID1, then pull the ID1 values directly from the index. But any advice I launch in, (as index_join(), index(), opt_param ('_index_join_enabled', true) opt_param('optimizer_index_cost_adj',1), etc., he don't y no plan that never presented that does not open the table.) And that's a problem because the table is actually quite massive and full of large columns. So do a scatter read through the massive tablespace for this table is so much more expensive that just read the two indexes, even in their entirety.
So is there a restriction that prevents pull the index values ID1, that has something to do with the insulation or missing/transaction null values or something? Did I miss an optimization to make it work, or Oracle (11.2.0.4, I think) ever implementation of an index_join across two indexes to single column?
It works for me in 12.1.0.2 if I do the column you want to select NOT NULL. This makes sense because otherwise the rowid would not appear in the index (although I don't see why that just cannot be interpreted as NULL). This also works if you filter nulls.
SQL > create table t_1 (id1 number, id2 number, colonne_1 varchar2 (4000));
Table created.
SQL > create index t_1_idx_01 on t_1 (id1);
The index is created.
SQL > create index t_1_idx_02 on t_1 (id2);
The index is created.
SQL > explain the plan for
2 Select / * + INDEX_JOIN (t t_1_idx_01) INDEX_JOIN (t_1_idx_02 t) * / id2 t_1 t where id1 =: X;He explained.
SQL > @x
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
Hash value of plan: 4181077581--------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 26. 1 (0) | 00:00:01 |
| 1. TABLE ACCESS BY ROWID INDEX BATCH | T_1 | 1. 26. 1 (0) | 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_1_IDX_01 | 1. | 1 (0) | 00:00:01 |
--------------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------2 - access ('ID1' = TO_NUMBER (:X))
Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)18 selected lines.
SQL > alter table t_1 change id2 not null;
Modified table.
SQL > explain the plan for
2 Select / * + INDEX_JOIN (t t_1_idx_01) INDEX_JOIN (t_1_idx_02 t) * / id2 t_1 t where id1 =: X;He explained.
SQL > @x
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1085250311-------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 26. 2 (0) | 00:00:01 |
|* 1 | VIEW | the index $ _join$ _001. 1. 26. 2 (0) | 00:00:01 |
|* 2 | HASH JOIN | | | | | |
|* 3 | INDEX RANGE SCAN | T_1_IDX_01 | 1. 26. 1 (0) | 00:00:01 |
| 4. FULL RESTRICTED INDEX SCAN FAST | T_1_IDX_02 | 1. 26. 1 (0) | 00:00:01 |
-------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------1 Filter ('ID1' = TO_NUMBER (:X))
2 - access (ROWID = ROWID)
3 - access ('ID1' = TO_NUMBER (:X))Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)22 selected lines.
SQL > alter table t_1 change id2 null;
Modified table.
SQL > explain the plan for
2 Select / * + INDEX_JOIN (t t_1_idx_01) INDEX_JOIN (t_1_idx_02 t) * / id2 t_1 t where id1 =: X and id2 is not null;He explained.
SQL > @x
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1085250311-------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 26. 2 (0) | 00:00:01 |
|* 1 | VIEW | the index $ _join$ _001. 1. 26. 2 (0) | 00:00:01 |
|* 2 | HASH JOIN | | | | | |
|* 3 | INDEX RANGE SCAN | T_1_IDX_01 | 1. 26. 1 (0) | 00:00:01 |
|* 4 | FULL RESTRICTED INDEX SCAN FAST | T_1_IDX_02 | 1. 26. 1 (0) | 00:00:01 |
-------------------------------------------------------------------------------------------Information of predicates (identified by the operation identity card):
---------------------------------------------------1 Filter ('ID1' = TO_NUMBER (:X))
2 - access (ROWID = ROWID)
3 - access ('ID1' = TO_NUMBER (:X))
4 - filter ("ID2" IS NOT NULL)Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)23 selected lines.
Your columns of text are very large, what is your block size? Under the value by default 8 k blocks, if your lines are completely filled while they are chained, and readings by rowid will be additional i/o. Consider measures to avoid migration of line and row chaining. In my view, this could be the reason for your index access is so slow.
Have a read of https://docs.oracle.com/database/121/TGDBA/pfgrf_instance_tune.htm#TGDBA024 10.2.4.3 Table Fetch by row continues to see the impact and ways to circumvent migrated/chained rows.
If you select a large number of rows in the table the issue would become so what do you intend to do with so many? Is it possible that you could reduce the number of lines you choose?
-
Hello world
I have a little a problem of performance on 12 c that gives me a little trouble at the head. I moved from 11 to 12 databases and no amendment of the application have been made. Our requests are generated somewhat dynamically, so that they are the same thing every time.
Let's start with the execution plan I get:
SQL > select * from table (dbms_xplan.display ());
PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 3567104424
-----------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | TQ | IN-OUT | PQ Distrib.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 55. 7095 | 3764 (1) | 00:00:01 | | | |
| 1. COORDINATOR OF PX | | | | | | | | |
| 2. PX SEND QC (ORDER). : TQ10006 | 55. 7095 | 3764 (1) | 00:00:01 | Q1, 06 | P > S | QC (ORDER).
| 3. SORT ORDER BY | | 55. 7095 | 3764 (1) | 00:00:01 | Q1, 06 | SVCP | |
| 4. PX RECEIVE | | 55. 7095 | 3763 (1) | 00:00:01 | Q1, 06 | SVCP | |
| 5. RANGE OF SEND PX | : TQ10005 | 55. 7095 | 3763 (1) | 00:00:01 | Q1, 05 | P > P | RANGE |
| 6. UNIQUE FATE | | 55. 7095 | 3763 (1) | 00:00:01 | Q1, 05 | SVCP | |
|* 7 | HASH JOIN | | 55. 7095 | 3762 (1) | 00:00:01 | Q1, 05 | SVCP | |
| 8. PX RECEIVE | | 801 | 50463 | 3696 (1) | 00:00:01 | Q1, 05 | SVCP | |
| 9. PX SEND HASH | : TQ10003 | 801 | 50463 | 3696 (1) | 00:00:01 | Q1, 03 | P > P | HASH |
| * 10 | HASH JOIN | | 801 | 50463 | 3696 (1) | 00:00:01 | Q1, 03 | SVCP | |
| 11. RECEIVE PX | | 801 | 40851 | 2333 (1) | 00:00:01 | Q1, 03 | SVCP | |
| 12. PX SEND BROADCAST | : TQ10002 | 801 | 40851 | 2333 (1) | 00:00:01 | Q1, 02 | P > P | BROADCAST |
| 13. NESTED LOOPS | | 801 | 40851 | 2333 (1) | 00:00:01 | Q1, 02 | SVCP | |
| 14. KIND OF BUFFER. | | | | | Q1, 02 | ISSUE | |
| 15. RECEIVE PX | | | | | | Q1, 02 | SVCP | |
| 16. PX SEND HASH | : TQ10000 | | | | | | S > P | HASH |
| 17. NESTED LOOPS | | 823. 31274 | 1509 (1) | 00:00:01 | | | |
| * 18. TABLE ACCESS BY ROWID INDEX BATCH | PAGED_LOOKUP_PKS | 500 | 9500 | 3 (0) | 00:00:01 | | | |
| * 19. INDEX RANGE SCAN | PAGED_LOOKUP_PKS_IDX2 | 1. | 2 (0) | 00:00:01 | | | |
| 20. TABLE ACCESS BY ROWID INDEX BATCH | BILL_ITEM | 2. 38. 4 (0) | 00:00:01 | | | |
| * 21. INDEX RANGE SCAN | BILL_ITEM_FK2 | 4. | 2 (0) | 00:00:01 | | | |
| * 22. INDEX UNIQUE SCAN | PK_INSERTION | 1. 13. 1 (0) | 00:00:01 | Q1, 02 | SVCP | |
| 23. ITERATOR BLOCK PX | | 1548K | 17 M | 1353 (2) | 00:00:01 | Q1, 03 | ISSUE | |
| 24. FULL RESTRICTED INDEX SCAN FAST | BOOKING_ACCOUNT_1 | 1548K | 17 M | 1353 (2) | 00:00:01 | Q1, 03 | SVCP | |
| 25. PX RECEIVE | | 22037 | 1420K | 65 (2) | 00:00:01 | Q1, 05 | SVCP | |
| 26. PX SEND HASH | : TQ10004 | 22037 | 1420K | 65 (2) | 00:00:01 | Q1, 04 | S > P | HASH |
| 27. SELECTOR PX | | | | | | Q1, 04 | SCWC | |
| 28. TABLE ACCESS FULL | CONTACT | 22037 | 1420K | 65 (2) | 00:00:01 | Q1, 04 | SCWP | |
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
7 - access ("ACCOUNT_ID" ="ACCOUNT_ID")
10 - access ("BOOKING" ="BOOKING")
18 - filter("T1".") SEQUENCE_NO' < 501 AND "T1". ("' SEQUENCE_NO" > = 1).
19 - access("T1".") SESSION_ID '= 123456 AND 'T1'.' SEARCH_ID "= 25)
21 - access("T1".") N1 "=" BILL_ID")
22 - access ("BOOKING" = "BOOKING" AND "INSERTION_SET" = "INSERTION_SET" AND "INSERT"="INSERT")
Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)
-This is an adaptation plan
-2 directives Plan Sql used for this statement
51 selected lines.
Elapsed time: 00:00:00.15
SQL > spool off
OK, now let's go through the problem:
- It's a development running on a virtual server, and which hosts a few other databases, so the parallel execution is not a good thing. parallel_degree_policy is set to MANUAL, parallel_max_servers and all other parallel_ limits are set to 1 and tables have been changed with the settings of NOPARALLEL. So why is the execution plan always generated with all stages of parallel execution? I don't seem to get rid of in 12 c
- Next mystery is that the said plan of the explain command is an adaptation plan, and yet I put the true optimizer_adaptive_reproting_only
- Now to the problem of effective enforcement, so I'm playing around with all these settings. The query runs for 3-4 seconds, returning around about 500 cases. However, in some cases this same query with the same input variable races for hours and if I can believe the AWR and ASH reports, read a good 180 GB of data. The main wait event is direct path read temp temp and writing.
This is not isolated to that one query. I have a few queries now that all display the same behavior, one of them running overnight. I don't seem to get to a standard nested loop execution plans.
The entire base is a database plug-in and I don't know I just missed something in the new features Guide.
Would appreciate some ideas.
Thank you
If you want to disable parallel execution, you must set parallel_max_servers to zero. Maybe the optimizer thinks he can use a parallel plan because parallel_max_servers is non-zero (even though the number of slaves available means that it will be serialized to a parallel plan).
Note that you have a ticket saying dynamic stats have been used. Maybe you have a 11 for optimizer_dynamic_sampling setting, and allowing Oracle to be very inventive with collection of samples and parallelism.
You have also 2 SQL instructions in game. These are the things that get associated with objects rather than the instructions, then perhaps someone has been playing with parallelism and managed to associate the parallelism with one of the tables in your query (I am not sure 100% that it is possible, just throw a suggestion). Take a look at the SQL used for education guidelines.
To give us a little more information, you can:
Shoot memory execution plan dbms_xplan.display_cursor ({sql_id}, {number of children}, 'ALL'));
We show all the parallel settings (see setting the parallel)
Pull on the parameters of the optimizer for query memory (select name, value of V$ sql_optimizer_env where sql_id = {your sql identifier} and child_number = {your child number})
Concerning
Jonathan Lewis
-
Need help and suggestions for partitioned tables
Hello
We have a table and it is partitioned and partitioned with datetime column, IE... partition by range.
I tried to run the query in the form below and it runs 1 HR and did not get the result and I kill the query.
Select min (datetime) max (datetime) < big_table > maxdate, mindate; -2203M data in this table
index also in place on these columns as a composite index (code, datetime, status, po_num)
< big_table > - having columns like code, datetime, status, po_num, creation_date
Here is the plan of the explain command:
Hash value of plan: 228211001
------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 8. 4009K (2) | 04:41:57 | | |
| 1. GLOBAL TRI | | 1. 8. | | | |
| 2. RANGE OF PARTITION ALL THE | | 2163M | 16G | 4009K (2) | 04:41:57 | 1. 1048575.
| 3. FULL RESTRICTED INDEX SCAN FAST | POSTATUSINDEX | 2163M | 16G | 4009K (2) | 04:41:57 | 1. 1048575.
------------------------------------------------------------------------------------------------------------
Please give me any suggestions how to get the query faster.
THX in advance
You need to know which column mainly used in queries?
If most of the request uses ID column, then partition of hash on ID will be beneficial.
-
explain query plan uses no unique index with where condition
Hi all
I use in the 10.2.0.5 oracle database Enterprise edition 64-bit on 64-bit windows server 2008.
I'm following this tutorial on my own table
Guide to understanding Oracle QUERY PLAN - 10 minutes
my questions are below
Analyze table LIB_CLASSIFICATIONS compute statistics; explain plan for SELECT class_id FROM lib_classifications WHERE class_no = '538' ; select * from table(dbms_xplan.display);
the result is less than
Hash value of plan: 3022072076
-----------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 10. 5 (0) | 00:00:01 |
|* 1 | TABLE ACCESS FULL | LIB_CLASSIFICATIONS | 1. 10. 5 (0) | 00:00:01 |
-----------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - filter ("CLASS_NO" = '538')
DESC LIB_CLASSIFICATIONS
Name of Type Null
----------------- -------- -------------
CLASS_ID NOT NULL NUMBER (10)
CLASS_DESC VARCHAR2 (50)
REMARKS VARCHAR2 (250)
CLASS_NO VARCHAR2 (20)
CLASS_TYPE VARCHAR2 (10)
CREATE_USER VARCHAR2 (10)
MODIFY_USER VARCHAR2 (10)
CREATE_DATE DATE
MODIFY_DATE DATE
CLASS_CATEGORY_ID VARCHAR2 (10)
class_id has a primary key.
now when I remove the condition where the query, the result is lower;
Analyze table LIB_CLASSIFICATIONS compute statistics; explain plan for SELECT class_id FROM lib_classifications ; select * from table(dbms_xplan.display);
the result is less than
Hash value of plan: 262704430
------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1558. 6232. 2 (0) | 00:00:01 |
| 1. FULL RESTRICTED INDEX SCAN FAST | SYS_C005653 | 1558. 6232. 2 (0) | 00:00:01 |
------------------------------------------------------------------------------------
now it's using indexes with INDEX FAST FULL SCAN.
I need the index using the WHERE condition as well.
How to do this?
Thank you.
you have indexes on the column class_id not on class_no column how u would expect index to use when there is no index on the column class_no
-
Hint USE_HASH involving subqueries
Hello
We request that deals with millions of lines through sequential readings, index analysis xtable_id_IDX is the treatment of about 20 million, ytable_pk index records fewer lines of treatment.
I think as first rowsource treats a wide range of data, nested loop is more expensive, so wanted to try to use hint USE_HASH to force the ytable smaller that build table and xtable as probe, but the optimizer table is recovering not the USE_HASH hint, do not know if it is due to not in / of a subquery.
Could you please help if I can force the optimizer to use hash join with ytable (ytable_pk rowsource) as array of generation and to probe the other's.
It is fine if we use full scan tips complete the two tables instead of the index, I just wanted to see if we can force HASH join in the case.
PS: Change the names of tables, real plan
UPDATE t SET xtable_id = X Xtable
WHERE (xtable_id) NOT IN (SELECT xtable_id FROM ytable)
------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
------------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT. | 1. 20. 1 (0) | 00:00:01 |
| 1. UPDATE | XTABLE. | | | |
| 2. ANTI NESTED LOOPS. | 1. 20. 1 (0) | 00:00:01 |
| 3. INDEX SCAN FULL | xtable_id_IDX | 1. 13. 0 (0) | 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | ytable_PK | 1. 7. 1 (0) | 00:00:01 |
------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
4 - access ("xtable_id"="ytable_id")
Thanks for your time.
It seems that the plan you want is probably
----------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time |
----------------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT. | 17 M | 230 M | | 4552K (1) | 15:10:26 |
| 1. UPDATE | XTABLE. | | | | |
| 2. HASH JOIN ANTI RIGHT | | 17 M | 230 M | | 4552K (1) | 15:10:26 |
| 5. FULL RESTRICTED INDEX SCAN FAST | YTABLE_ID_IDX | 46 M | 312 M | | 26472 (1) | 00:05:18 |
| 3. FULL RESTRICTED INDEX SCAN FAST | XTABLE_PK | 1728M | 11G | | 4364K (1) | 14:32:57 |
----------------------------------------------------------------------------------------------------
To do this, you must refer to something like:
Update
/*+
qb_name (main)
UNNEST (@subq)
attack (t2@main t1@subq)
USE_HASH (T1@subq)
swap_join_inputs (T1@subq)
index_ffs (T1@subq)
index_ffs (T2@main)
*/
XTABLE t2
Set t2.xtable_id = X
where t2.xtable_id not in)
Select / * + qb_name (subq) * / ytable t1 t1.n1
)
/
Whatever you do, it's going to be pretty nasty because of the magnitude of the problem - just hope that you update a large number of lines - and one of the problems is that you will update the index you use pilot request, so that you're going to do nasty things to read-consistency to your own update.
I think the trick (as suggested above) HASH_AJ may have been deprecated in 10g, is said by the way.
Concerning
Jonathan Lewis
-
The adaptation and Pl/SQL cursor sharing
Hello
I have this database:
NLSRTL 11.2.0.1.0 Production Oracle Database 11g Enterprise Edition 11.2.0.1.0 64 bit Production PL/SQL 11.2.0.1.0 Production AMT for Solaris: 11.2.0.1.0 Production I'm testing the queries and adaptive cursor sharing. I have a table T1 that is created by selecting all object. It has additional is NOT NULL ID of the column that is PK and is filled through sequence. It has a regular index (OBJECT_TYPE, OBJECT_NAME). Statistics are collected on the T1 table and its indexes.
Total of T1 lines and are 1065951.
I have run this test in SqlPlus:
ID of the VARIABLE NUMBER;
EXECUTE: id: = 10;
SELECT COUNT (*) FROM t1 WHERE id <: id;
So I check the instruction in v$ sql and the execution plan and I can see that the plan is:
SQL_ID, 3m2qaytqgk9jt, number of children 0
-------------------------------------
Select COUNT (*) from t1 where id <: id
Hash value of plan: 212448250
---------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 193 (100) | |
| 1. GLOBAL TRI | | 1. 6. | |
|* 2 | INDEX RANGE SCAN | PK_T1 | 99999. 585K | 193 (1) | 00:00:03 |
---------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 - access("ID"<:ID))
Second test:
ID of the VARIABLE NUMBER;
EXECUTE: id: = 1000000.
SELECT COUNT (*) FROM t1 WHERE id <: id;
Execution plan:
SQL_ID, 3m2qaytqgk9jt, number of children 1
-------------------------------------
Select COUNT (*) from t1 where id <: id
Hash value of plan: 1953966236
-------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 559 (100) | |
| 1. GLOBAL TRI | | 1. 6. | |
|* 2 | FULL RESTRICTED INDEX SCAN FAST | PK_T1 | 1000K | 5859K | 559 (2) | 00:00:07 |
-------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 - filter("ID"<:ID))
Output:
SQL > SELECT sql_id, child_number, executions, 'IS_BIND_SENSITIVE', 'IS_BIND_AWARE', 'IS_SHAREABLE' OF V$ SQL WHERE SQL_ID = "3m2qaytqgk9jt";
THE EXECUTIONS OF CHILD_NUMBER SQL_ID I I I
------------- ------------ ---------- - - -
3m2qaytqgk9jt 0 2 O N N
1 3 3m2qaytqgk9jt Y Y Y
As we can see it Adaptive cursor sharing has been used and in both cases the appropriate execution plan has been used.
When I run test with PL/SQL block, however, I don't see the use of extended cursor sharing. Could you please help understand why?
The test is (I used deliberately < = in order to create the new parent cursor):
DECLARE
PID NUMBER;
CNT PLS_INTEGER;
BEGIN
BECAUSE me in 1... 10 LOOP
IF i IN (2, 4, 6, 10) THEN
PID: = round (dbms_random.value (1, 5000));
ON THE OTHER
PID: = round ((100000, 1600000) dbms_random.value);
END IF;
dbms_output.put_line ('ID: ' | pid);
COUNT (*) of SELECT INTO cnt FROM t1 WHERE id < = pid;
END LOOP;
END;
/
Output of this is:
ID: 396582
ID: 2584
ID: 560405
ID: 3275
ID: 827442
ID: 4515
ID: 167771
ID: 652411
ID: 512147
ID: 230
As we can see some ID values are good candidates for INDEX BEACH, others are for the INDEX FAST FULL SCAN. However, I am only a child cursor for my parents:
SQL > SELECT sql_id, child_number, executions, 'IS_BIND_SENSITIVE', 'IS_BIND_AWARE', 'IS_SHAREABLE' OF V$ SQL WHERE SQL_ID = "6xh03mm87nmu3";
THE EXECUTIONS OF CHILD_NUMBER SQL_ID I I I
------------- ------------ ---------- - - -
0 10 6xh03mm87nmu3 Y N Y
SQL >
Please pay attention to the value for IS_BIND_AWARE, who is with my first child 0. So no other children were created. Why in PL/SQL, it behaves differently and how can we enjoy the cursor of adaptation in this context?
Thank you!
My immediate thoughts were under cover PLSQL optimizations.
PLSQL_OPTIMIZE_LEVEL has no effect.
To run I had to Board BIND_AWARE and SESSION_CACHED_CURSORS value 0.
Subsequently found Randolf Geist post in the same direction:
-
Indexing of binary XML data exposed by using a relational view
Hello
I would like a forefinger XMLType columns. 11 GR 2, it is possible, but in paragraph 12.1?
I give you my script to test.
Thanks in advance
-Server Oracle 12 c Enterprise Edition Release 12.1.0.1.0 - 64 bit Production
CREATE TABLE t_col_xml
(nom_doc VARCHAR2 (30) PRIMARY KEY, col_xml XMLType)
XMLTYPE AS XML BINARY col_xml STORE;
INSERT INTO t_col_xml (nom_doc, col_xml) VALUES
("compagnie.xml",
((XMLType.CREATEXML)
' <? XML version = "1.0" encoding = "UTF-8"? >
< date_crea = "2010-08-30" company >
< comp > AB < / comp >
< driver >
< patent pilot = "PL - 1" >
< name > Benoit < / name >
< name > Sarda < / name >
< salary > 4000.20 < / salary >
< / driver >
< patent pilot = "PL2" >
< name > Romaric < / name >
< name > Benech < / name >
< salary > 5000.40 < / salary >
< / driver >
< / drivers >
Air Blagnac < nomComp > < / nomComp >
(((< / company > ')));
CREATE or replace VIEW comp_detail_vue AS
SELECT a.comp, b.*
OF t_col_xml.
XMLTABLE ('/ company ' ADOPTION col_xml)
Comp VARCHAR2 COLUMNS (6) PATH "comp."
PILS XMLType PATH ' pilot/pilot'),
XMLTABLE ('pilot' ADOPTION a.pils
Patent of VARCHAR2 COLUMNS (6) "@brevet."
prepil PATH VARCHAR2 (20) "first name",
nompil PATH VARCHAR2 (20) "name."
b salary NUMBER PATH "wages");
Col nompil FORMAT A12
ALTER SESSION SET nls_numeric_characters = ".";
SELECT * FROM comp_detail_vue;
/*
MODEL OF PATENT PREPIL NOMPIL SALARY
------ ------ -------------------- ------------ ----------
AB-1 PL Benoit Sarda 4000.2
AB PL2 Romaric Benech 5000.4
*/
-That is the problem
SELECT DBMS_XMLSTORAGE_MANAGE.getSIDXDefFromView ('COMP_DETAIL_VUE')
FROM DUAL;
/*
ERROR:
ORA-06502: PL/SQL: error Numurique or error on a value: to wildcard cha¯ne pad printing too
small
ORA-06512: O "XDB. DBMS_XMLSTORAGE_MANAGE', line 2667
ORA-06512: O "XDB. DBMS_XMLSTORAGE_MANAGE', line 2969
*/
Hmm..., same result in 12.1.0.2.0. Overall it seems to be a bug although I have only seen 'getSIDXDefFromView', although always in the XMLDB Developer's Guide, eliminated in the packages (http://docs.oracle.com/database/121/ARPLS/d_xmlstorage_man.htm#ARPLS73588) reference.
That said perhaps what follows is to help you to do it manually:
DROP TABLE t_col_xml is serving;
CREATE TABLE t_col_xml
(nom_doc VARCHAR2 (30) PRIMARY KEY, col_xml XMLType)
XMLTYPE AS XML BINARY col_xml STORE;
INSERT INTO t_col_xml (nom_doc, col_xml) VALUES
("compagnie.xml",
((XMLType.CREATEXML)
'
AB Benoit SARDA 4000.20 Romaric Benech 5000.40 Air Blagnac ') ) );
CREATE or replace VIEW comp_detail_vue AS
SELECT a.comp, b.brevet, b.prepil, b.nompil, b.salaire
OF t_col_xml.
XMLTABLE ('/ company ' ADOPTION col_xml)
Comp VARCHAR2 COLUMNS (6) PATH "comp."
PILS XMLType PATH ' pilot/pilot'),
XMLTABLE ('pilot' ADOPTION a.pils
Patent of VARCHAR2 COLUMNS (6) "@brevet."
prepil PATH VARCHAR2 (20) "first name",
nompil PATH VARCHAR2 (20) "name."
b salary NUMBER PATH "wages");
Col nompil FORMAT A12
the value of 10000 long
' ALTER SESSION SET nls_numeric_characters =".";
SELECT * FROM comp_detail_vue;
SELECT DBMS_XMLSTORAGE_MANAGE.getSIDXDefFromView ('COMP_DETAIL_VUE')
FROM DUAL;
/*
CALL DBMS_XMLINDEX.dropParameter ('company');
CALL DBMS_XMLINDEX.registerParameter)
'company. '
DBMS_XMLSTORAGE_MANAGE.getSIDXDefFromView ('COMP_DETAIL_VUE'));
*/
CREATE INDEX i_col_xml
ON t_col_xml (col_xml)
INDEXTYPE IS "XDB". "" XMLINDEX.
PARAMETERS ('GROUP compagnie_group
XMLTABLE comp_sxi
(tablespace users)
"/ company"
COLUMNS
model VARCHAR2 (6) PATH "mock-up",.
PILS XMLType "drivers/driver" VIRTUAL PATH
XMLTABLE comp_pils_sxi
(tablespace users)
"pilot" PASSER-BY pils
COLUMNS
patent VARCHAR2 (6) PATH "@brevet".
prepil VARCHAR2 (20) PATH "first name",
nompil VARCHAR2 (20) PATH "name",
salary NUMBER PATH 'salary'
');
explain plan for
SELECT * FROM comp_detail_vue;
SELECT * FROM TABLE (dbms_xplan.display);
--------------------
OUTPUT
--------------------
table deleted T_COL_XML.
table created T_COL_XML.
1 inserted rows.
view COMP_DETAIL_VUE created.
session the changed VALUE.
MODEL OF PATENT PREPIL NOMPIL SALARY
------ ------ -------------------- ------------ ----------
AB-1 PL Benoit Sarda 4000.2
AB PL2 Romaric Benech 5000.4
Error at startup to the line: 48 in command.
SELECT DBMS_XMLSTORAGE_MANAGE.getSIDXDefFromView ('COMP_DETAIL_VUE')
OF THE DOUBLE
Error report-
SQL error: ORA-06502: PL/SQL: digital or value error: character string buffer too small
ORA-06512: at "XDB". DBMS_XMLSTORAGE_MANAGE', line 2667
ORA-06512: at "XDB". DBMS_XMLSTORAGE_MANAGE', line 2969
06502 00000 - "PL/SQL: digital error or the value of %s.
* Cause:
* Action:
index created I_COL_XML.
plan FOR successful.
PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------
Hash value of plan: 2425154757
-----------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-----------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 1075 | 2 (0) | 00:00:01 |
| 1. NESTED LOOPS | | 1. 1075 | 2 (0) | 00:00:01 |
| 2. NESTED LOOPS | | 2. 1075 | 2 (0) | 00:00:01 |
| 3. NESTED LOOPS | | 1. 531. 2 (0) | 00:00:01 |
| 4. FULL RESTRICTED INDEX SCAN FAST | SYS_C009751 | 1. 12. 2 (0) | 00:00:01 |
| 5. TABLE ACCESS BY ROWID INDEX BATCH | COMP_SXI | 1. 519. 0 (0) | 00:00:01 |
|* 6 | INDEX RANGE SCAN | SYS91605_91606_RID_IDX | 1. | 0 (0) | 00:00:01 |
|* 7 | INDEX RANGE SCAN | SYS91605_91609_PKY_IDX | 2. | 0 (0) | 00:00:01 |
| 8. TABLE ACCESS BY INDEX ROWID | COMP_PILS_SXI | 2. 1088. 0 (0) | 00:00:01 |
-----------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
6 - access ("T_COL_XML". ROWID = "SYS_SXI_2." ("' RID ')
7 - access("SYS_SXI_2".") KEY '= 'SYS_SXI_3'.' PKEY")
Note
-----
-the dynamic statistics used: dynamic sampling (level = 2)
25 selected lines
-
Update statement is a coherent lof 'Get '.
Hello
When I run this update statement, it generates a lot of 'get in line ':
UPDATE PFA_FUSIONFACC WAS
SET (COD_FACTURA, TOT_CARGO_DB, TOT_CARGO_FB) =
(SELECT THE NPC. COD_FACTUcaRA AS COD_FACTURA, NPC. TOT_BASEIMPO_E AS TOT_BASEIMPO, NPC. TOT_IMPEMI AS TOT_IMPEMI
OF NPC, CTA AUX_CTAFACTU PFA_NPCOFACTMES
where LTC. CTA_FACTURAC = WAS. CTA_FACTURAC
AND NPC.cod_postal = CTA.cod_postal
AND NPC.cta_facturac = CTA.cta_facturac)
where FUS.rowid in
(SELECT WAS.) ROWID
NPC PFA_NPCOFACTMES, CTA AUX_CTAFACTU, WAS PFA_FUSIONFACC
where LTC. CTA_FACTURAC = WAS. CTA_FACTURAC
AND NPC.cod_postal = CTA.cod_postal
AND NPC.cta_facturac = CTA.cta_facturac
AND ROWNUM < 10000);
9999 filas actualizadas.
Passed: 01:38:15.47
Run plan
----------------------------------------------------------
Hash value of plan: 2048200947
----------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time | Pstart. Pstop |
----------------------------------------------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT. | 1. 62. | 117 KB (4) | 00:23:27 | | |
| 1. UPDATE | PFA_FUSIONFACC | | | | | | | |
| 2. NESTED LOOPS | | 1. 62. | 117 KB (4) | 00:23:27 | | |
| 3. VIEW | VW_NSO_1 | 9999 | 117 KB | | 117 KB (4) | 00:23:27 | | |
| 4. UNIQUE FATE | | 1. 478K | | | | | |
|* 5 | COUNT STOPKEY | | | | | | | | |
|* 6 | HASH JOIN | | 774K | 36 M | 86 M | 117 KB (4) | 00:23:27 | | |
| 7. NESTED LOOPS | | 2258K | 60 M | | 101K (4) | 00:20:16 | | |
| 8. RANGE OF PARTITION ALL THE | | 2258K | 32 M | | 2554 (2) | 00:00:31 | 1. 338.
| 9. FULL RESTRICTED INDEX SCAN FAST | PFA_NPCOFACTMES_103 | 2258K | 32 M | | 2554 (2) | 00:00:31 | 1. 338.
| * 10 | INDEX UNIQUE SCAN | PK_AUX_CTAFACTU | 1. 13. | 2 (0) | 00:00:01 | | |
| 11. FULL RESTRICTED INDEX SCAN FAST | PFA_FUSIONFACC_I01 | 3923K | 78 M | | 5358 (2) | 00:01:05 | | |
| 12. TABLE ACCESS BY ROWID USER | PFA_FUSIONFACC | 1. 50. | 1 (0) | 00:00:01 | | |
| 13. TABLE ACCESS BY LOCAL INDEX ROWID | PFA_NPCOFACTMES | 1. 56. | 2 (0) | 00:00:01 | 1. 1.
| 14. NESTED LOOPS | | 1. 69. | 49 (0) | 00:00:01 | | |
| * 15 | INDEX SKIP SCAN | PK_AUX_CTAFACTU | 1. 13. | 47 (0) | 00:00:01 | | |
| 16. RANGE OF PARTITION ITERATOR. | 1. | | 1 (0) | 00:00:01 | KEY | KEY |
| * 17. INDEX RANGE SCAN | PFA_NPCOFACTMES_103 | 1. | | 1 (0) | 00:00:01 | KEY | KEY |
----------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
5 - filter(ROWNUM<10000)
6 - access("CTA".") CTA_FACTURAC "=" WAS ". ("' CTA_FACTURAC")
10 - access("NPC".") COD_POSTAL "=" CTA ". "" COD_POSTAL "AND"NPC ". "" CTA_FACTURAC "=" CTA ". ("' CTA_FACTURAC")
15 - access("CTA".") CTA_FACTURAC "(=:B1)"
filter ("CTA". "CTA_FACTURAC"(=:B1) "
17 - access("NPC".") COD_POSTAL "=" CTA ". "" COD_POSTAL "AND"NPC ". "CTA_FACTURAC"(=:B1) "
filter ("NPC". "" CTA_FACTURAC "=" CTA ". ("' CTA_FACTURAC")
And statistics
----------------------------------------------------------
1 recursive calls
13252 db block Gets
200711795 compatible Gets
407276 physical reads
Redo 3550216 size
837 bytes sent via SQL * Net to client
1320 bytes received via SQL * Net from client
3 SQL * Net back and forth to and from the client
2 sorts (memory)
0 sorts (disk)
9999 rows processed
Rollback Terminado.
But the query used by the update is much less "gets":
SQL > SELECT WAS. ROWID
NPC PFA_NPCOFACTMES, CTA AUX_CTAFACTU, WAS PFA_FUSIONFACC
2 where 3 DEC. CTA_FACTURAC = WAS. CTA_FACTURAC
AND NPC.cod_postal = CTA.cod_postal
4 5 AND NPC.cta_facturac = CTA.cta_facturac
AND ROWNUM < 10000 6;
9999 filas seleccionadas.
Passed: 00:00:20.57
Run plan
----------------------------------------------------------
Hash value of plan: 20234272
-----------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time | Pstart. Pstop |
-----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 9999 | 937K | | 29298 (2) | 00:05:52 | | |
|* 1 | COUNT STOPKEY | | | | | | | | |
|* 2 | HASH JOIN | | 774K | 70 M | 58 M | 29298 (2) | 00:05:52 | | |
| 3. RANGE OF PARTITION ALL THE | | 2258K | 32 M | | 2554 (2) | 00:00:31 | 1. 338.
| 4. FULL RESTRICTED INDEX SCAN FAST | PFA_NPCOFACTMES_103 | 2258K | 32 M | | 2554 (2) | 00:00:31 | 1. 338.
|* 5 | HASH JOIN | | 3906K | 175 M | 123 M | 12842 (2) | 00:02:35 | | |
| 6. FULL RESTRICTED INDEX SCAN FAST | PFA_FUSIONFACC_I01 | 3923K | 78 M | | 5358 (2) | 00:01:05 | | |
| 7. FULL RESTRICTED INDEX SCAN FAST | PK_AUX_CTAFACTU | 147K | 1869K | | 1120 (1) | 00:00:14 | | |
-----------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - filter(ROWNUM<10000)
2 - access("NPC".") COD_POSTAL "=" CTA ". "" COD_POSTAL "AND"NPC ". "" CTA_FACTURAC "=" CTA ". ("' CTA_FACTURAC")
5 - access("CTA".") CTA_FACTURAC "=" WAS ". ("' CTA_FACTURAC")
And statistics
----------------------------------------------------------
1 recursive calls
0 db block Gets
54736 compatible Gets
53070 physical readings
0 redo size
304491 bytes sent via SQL * Net to client
7814 bytes received via SQL * Net from client
668 SQL * Net back and forth to and from the client
0 sorts (memory)
0 sorts (disk)
9999 rows processed
The "PFA_NPCOFACTMES_103" index is partitioned. I don't know if it's related to this issue:
SQL > select table_name, uniqueness, separated from all_indexes where index-name = "PFA_NPCOFACTMES_103";
TABLE_NAME UNIQUENES BY
------------------------------ --------- ---
PFA_NPCOFACTMES NON-UNIQUE YES
SQL > select TABLE_NAME, COLUMN_NAME, position_colonne from all_ind_columns where index-name = "PFA_NPCOFACTMES_103";
TABLE_NAME COLUMN_NAME POSITION_COLONNE
------------------------------ ------------------------------ ---------------
PFA_NPCOFACTMES CTA_FACTURAC 2
PFA_NPCOFACTMES COD_POSTAL 1
Why the update does not generate as much "becomes"?
Thanks in advance,
Jose Luis
I don't know the reason why at first sight, but it is obvious that the inner nested loop was doing a lot of work (full index scan).
My first thought was to rewrite the query in a merge statement.
Perhaps leads to a more effective plan and so no need to delve deeper into the issues you have raised ;-)
merge into FUS PFA_FUSIONFACC
a_l'_aide_de)
SELECT
NPC. COD_FACTUcaRA AS COD_FACTURA
NPC. TOT_BASEIMPO_E AS TOT_BASEIMPO
NPC. TOT_IMPEMI AS TOT_IMPEMI
OF NPC, CTA AUX_CTAFACTU PFA_NPCOFACTMES
where
NPC.cod_postal = CTA.cod_postal
AND NPC.cta_facturac = CTA.cta_facturac
) cta
(TBT. CTA_FACTURAC = WAS. CTA_FACTURAC)
When matched then update
Was SET. COD_FACTURA = cta. COD_FACTURA
was. TOT_CARGO_DB = cta. TOT_BASEIMPO
was. TOT_CARGO_FB) = cta. TOT_IMPEMI
where ROWNUM<>
-
Hello
Given this SQL sentence;
SQL > select A.COD_APLICACION, A.COD_PLANFACT, A.TIP_CONFACTU
PFA_SERVCONFACTU a, pgsm_confactu B
WHERE B.TIP_CONFACTU = A.TIP_CONFACTU
ORDER BY A.COD_PLANFACT, A.COD_APLICACION, A.TIP_CONFACTU;
2 3 4
Execution plan
----------------------------------------------------------
Hash value of plan: 811803481
---------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time |
---------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 25 M | 442 M | | 153K (5) | 00:30:41 |
| 1. SORT ORDER BY | | 25 M | 442 M | 1384M | 153K (5) | 00:30:41 |
|* 2 | HASH JOIN | | 25 M | 442 M | | 1732 (29) | 00:00:21 |
| 3. FULL RESTRICTED INDEX SCAN FAST | PGSM_CONFACTU_I2 | 8136 | 40680 | | 6 (0). 00:00:01 |
| 4. FULL RESTRICTED INDEX SCAN FAST | PK_SERVCONFACTU | 706KO | 8964K | | 1251 (2) | 00:00:16 |
---------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 - access("B".") TIP_CONFACTU '= 'A'.' TIP_CONFACTU')
SQL > r
1 * select COLUMN_NAME INDEX_NAME, position_colonne from all_ind_columns where index-name = 'PK_SERVCONFACTU' order by 2
INDEX_NAME POSITION_COLONNE COLUMN_NAME
------------------------------ --------------- ------------------------------
PK_SERVCONFACTU 1 COD_PLANFACT
PK_SERVCONFACTU 2 COD_APLICACION
PK_SERVCONFACTU 3 TIP_CONFACTU
SQL > select table_name, iot_type from all_tables where table_name = 'PFA_SERVCONFACTU_1 ';
TABLE-NAME IOT_TYPE
------------------------------ ------------
PFA_SERVCONFACTU_1 ITO
----------------------------------------------------------------------------------------------------------------------------------
Why the optimizer does not PK_SERVCONFACTU index instead of the 'SORT ORDER BY' operation?
Thanks in advance,
Jose Luis
Jose, given that the optimizer chose Full index scan (view second table is not available) and the data set finds the results aren't in order, so must be ordered by a sort of hash join. The other choice would be to drive on a table and use an index to retrieve the lines of the other table. Depending on which table was the driver that some kind might still be necessary. Choice CBO statistics by car so that's what statistics says Oracle should do. It may or may not be correct according to you didn't post such as tests of real time to plans for information.
- -
HTH - Mark D Powell.
-
Hi Experts,
I have this request below. I was wondering - w/o parallel hint, how you naturally to run in parallel.
Select * from SC
where
There are)
Select 1
STI
where
STC. LNO = sti.lno and
STI.act_id = 1 and
STI.codec in ('2697', '6697', '2737', '6737', '3886', '7886', '2692',' 6692',
'3483 ', '7483', '500', '800', '501', '801' ', 3888',' 7888 ', ' 3887',
"7887 ', '3946', '7946', '3945', '7945' ', 3944',' 7944 ', ' 3953',
"7953 ', '3954', '7954', '3955', '7955' ', 3481',' 3482 ', ' 7481',
"7482 ', '3960', '7960', '4072', '8072' ', 4284',' 8284 ', ' 4343',
"8343 ', '4499', '8499', '10038', '14038' ', 3959',' 11482 ', ' 11483',
"11484 ', '11485', '11486', '11487' ', 11488',' 11489 ', ' 11490',
"11491 ', '11492', '11493', '11494' ', 11495',' 11496 ', ' 11510',
"11560 ', '11561', '11562', '11563' ', 11564',' 11565 ', ' 11566',
"7959 ', '15482', '15483', '15484' ', 15485',' 15486 ', ' 15487',
"15488 ', '15489', '15490', '15491' ', 15492',' 15493 ', ' 15494',
"15495 ', '15496', '15510', '15560' ', 15561',' 15562 ', ' 15563',
"15564 ', '15565', '15566', '11588', '15588',' 12096 ', ' 16096')
);
PLAN_TABLE_OUTPUT
Hash value of plan: 347973291
----------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | TQ | IN-OUT | PQ Distrib.
----------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 86 M | 6992M | 2901K (1) | 09:40:22 | | | |
| 1. COORDINATOR OF PX | | | | | | | | |
| 2. PX SEND QC (RANDOM). : TQ10002 | 86 M | 6992M | 2901K (1) | 09:40:22 | Q1, 02 | P > S | QC (RAND) |
|* 3 | HASH JOIN RIGHT SEMI | | 86 M | 6992M | 2901K (1) | 09:40:22 | Q1, 02 | SVCP | |
| 4. RECEIVE PX | | 263K | 4887K | 5456 (14) | 00:01:06 | Q1, 02 | SVCP | |
| 5. PX SEND HASH | : TQ10001 | 263K | 4887K | 5456 (14) | 00:01:06 | Q1, 01 | P > P | HASH |
| 6. ITERATOR BLOCK PX | | 263K | 4887K | 5456 (14) | 00:01:06 | Q1, 01 | ISSUE | |
|* 7 | FULL RESTRICTED INDEX SCAN FAST | STI__IDX | 263K | 4887K | 5456 (14) | 00:01:06 | Q1, 01 | SVCP | |
| 8. KIND OF BUFFER. | | | | | Q1, 02 | ISSUE | |
| 9. RECEIVE PX | | 1087M | 66G | 2891K (1) | 09:38:14 | Q1, 02 | SVCP | |
| 10. PX SEND HASH | : TQ10000 | 1087M | 66G | 2891K (1) | 09:38:14 | | S > P | HASH |
| 11. TABLE ACCESS FULL | STC | 1087M | 66G | 2891K (1) | 09:38:14 | | | |
----------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
3 - access("STC".") LOANNUMBER "=" STI ". ("' LOANNUMBER")
7 - filter("STI".") ACTIVEIV «= 1 AND ("STI".» Codec "= ' 10038"OR "STI" "codec"="11482' OR
"STI". "codec"= "11483" OR "STI". "codec"= "11484" OR "STI". "codec '=" 11485' OR
"STI". "codec"= "11486" OR "STI". "codec"= "11487" OR "STI". "codec '=" 11488' OR
"STI". "codec"= "11489" OR "STI". ' Codec '= ' 11490 "OR"STI". "codec '=" 11491' OR
"STI". "codec"= "11492" OR "STI". "codec"= "11493" OR "STI". "codec '=" 11494' OR
"STI". "codec"= "11495" OR "STI". "codec"= "11496" OR "STI". "codec" = '11510' OR "
"STI". "codec"= "11560" OR "STI". "codec"= "11561" OR "STI". "codec '=" 11562' OR
"STI". "codec"= "11563" OR "STI". "codec"= "11564" OR "STI". "codec '=" 11565' OR
"STI". "codec"= "11566" OR "STI". "codec"= "11588" OR "STI". "codec '=" 12096' OR
"STI". "codec"= "14038" OR "STI". "codec"= "15482" OR "STI". "codec '=" 15483' OR
"STI". "codec"= "15484" OR "STI". "codec"= "15485" OR "STI". "codec '=" 15486' OR
"STI". "codec"= "15487" OR "STI". "codec"= "15488" OR "STI". "codec '=" 15489' OR
"STI". "codec"= "15490" OR "STI". "codec"= "15491" OR "STI". "codec '=" 15492' OR
"STI". "codec"= "15493" OR "STI". "codec"= "15494" OR "STI". "codec '=" 15495' OR
"STI". "codec"= "15496" OR "STI". "codec"= "15510" OR "STI". "codec '=" 15560' OR
"STI". "codec"= "15561" OR "STI". "codec"= "15562" OR "STI". "codec '=" 15563' OR
"STI". "codec"= "15564" OR "STI". "codec"= "15565" OR "STI". "codec '=" 15566' OR
"STI". "codec"= "15588" OR "STI". "codec"= "16096" OR "STI". "codec"="2692" OR
"STI". "codec"= "2697" OR "STI". "codec"= "2737" OR "STI". "codec '=" 3481' OR
"STI". "codec"= "3482" OR "STI". "codec"= "3483" OR "STI". "codec" = '3886' OR "
"STI". "codec"= "3887" OR "STI". "codec": "3888" OR "STI". "codec '=" 3944' OR
"STI". "codec"= "3945" OR "STI". "codec"= "3946" OR "STI". "codec"="3953" OR "
"STI". "codec"= "3954" OR "STI". "codec"= "3955" OR "STI". "codec '=" 3959' OR
"STI". "codec"= "3960" OR "STI". «Codec ' = ' 4072 "OR"STI".» "codec '=" 4284' OR
"STI". "codec": "4343" OR "STI". "codec"= "4499" OR "STI". "codec"="500" OR "
"STI". "codec"= "501" OR "STI". "codec"= "6692" OR "STI". "codec '=" 6697' OR
"STI". "codec": "6737" OR "STI". "codec"= "7481" OR "STI". "codec '=" 7482' OR
"STI". "codec": "7483" OR "STI". "codec"= "7886" OR "STI". "codec '=" 7887' OR
"STI". "codec": "7888" OR "STI". "codec"= "7944" OR "STI". "codec '=" 7945' OR
"STI". "codec"= "7946" OR "STI". "codec"= "7953" OR "STI". "codec '=" 7954' OR
"STI". "codec"=, "7955" OR "STI". "codec"= "7959" OR "STI". "codec '=" 7960' OR
"STI". "codec"= "800" OR "STI". ' Codec '= ' 801 "OR"STI". "codec '=" 8072' OR
(("STI"."codec"= "8284" OR "STI"."codec"= "8343" OR "STI"."codec"="8499'))What could be the possible reason?
No matter what level setting of session as "ENABLE PARALLEL" or something.
Please tell us in this regard.
Thank you and best regards,
-Nordine
(on Oracle 11.2.0.3.0)
nordine B wrote:
Thanks Hoek. Learned something new.
BTW, I checked the DOF in this table and there is no PARALLELism present.
Any other pointer why this could happen?
You have probably checked the parallelism of the * index * STI__IDX - that's probably the problem no. 1 with reconstructions of index in parallel to speed up the reconstruction process and oblivion reset the level again to 1. This change in 12 c, incidentally, where reconstructions of index and table move is no longer change / persist the degree of the operation in the dictionary of the object reconstruction / moved.
Randolf
-
Hi all
It is the plan of the explanation of my request:
{code}
Hash value of 1 plan: 1914807434
2
3 --------------------------------------------------------------------------------------------------------------------------------------
4 | ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time |
5 --------------------------------------------------------------------------------------------------------------------------------------
6 | 0 | SELECT STATEMENT | | 3753. 747K | | 3771 (2) | 00:00:29 |
7 | 1. SORT ORDER BY | | 3753. 747K | 1016K | 3771 (2) | 00:00:29 |
8 | 2. HASH GROUP BY. | 3753. 747K | 1016K | 3771 (2) | 00:00:29 |
9 | 3. VIEW | | 3753. 747K | | 3432 (2) | 00:00:27 |
10. 4. KIND OF WINDOW. | 3753. 1491K | 1592K | 3432 (2) | 00:00:27 |
11. * 5 | OUTER HASH JOIN | | 3753. 1491K | 1488K | 3103 (2) | 00:00:24 |
12. 6. VIEW | | 3753. 1436K | | 927 (2) | 00:00:08 |
13. * 7 | HASH JOIN | | 3753. 1513K | | 927 (2) | 00:00:08 |
14. * 8 | FULL RESTRICTED INDEX SCAN FAST | PK_REQUIREMENT_YEAR | 942. 7536 | | 3 (0) | 00:00:01 |
15. 9. VIEW | | 580. 229K | | 924 (2) | 00:00:08 |
16. 10. HASH GROUP BY. | 580. 99K | | 924 (2) | 00:00:08 |
17. * 11 | OUTER HASH JOIN | | 580. 99K | | 923 (1) | 00:00:08 |
18. 12. VIEW | | 580. 93380 | | 558 (1) | 00:00:05 |
19. 13. NESTED LOOPS | | 580. 105K | | 558 (1) | 00:00:05 |
20. 14. NESTED LOOPS | | 580. 105K | | 558 (1) | 00:00:05 |
21. * 15 | OUTER HASH JOIN | | 131. 22532 | | 165 (2) | 00:00:02 |
22. * 16. HASH JOIN | | 131. 20043 | | 65 (2) | 00:00:01 |
23. 17. VIEW | the index $ _join$ _010 | 116. 1276 | | 2 (0) | 00:00:01 |
24. * 18. HASH JOIN | | | | | | |
25. 19. FULL RESTRICTED INDEX SCAN FAST | IDX_AVAILABILITY_TYPE | 116. 1276 | | 1 (0) | 00:00:01 |
26. 20. FULL RESTRICTED INDEX SCAN FAST | PK_AVAILABILITY_TYPE | 116. 1276 | | 1 (0) | 00:00:01 |
27. * 21. HASH JOIN | | 131. 18602 | | 63 (2) | 00:00:01 |
28. 22. TABLE ACCESS FULL | PE | 23. 276. | 3 (0) | 00:00:01 |
29. * 23. HASH JOIN | | 131. 17030. | 60 (2) | 00:00:01 |
30. * 24. TABLE ACCESS BY INDEX ROWID | SHIP_SHEETS | 131. 9956. | 50 (0) | 00:00:01 |
31. * 25. INDEX RANGE SCAN | NIDX_REQ_ID | 1597. | | 7 (0) | 00:00:01 |
32. * 26. HASH JOIN | | 422. 22788 | | 10 (10) | 00:00:01 |
33. 27. THE MERGE JOIN. | 46. 1058. | 5 (20) | 00:00:01 |
34. 28. TABLE ACCESS BY INDEX ROWID | COMPANY | 5. 35. | 2 (0) | 00:00:01 |
35. 29. INDEX SCAN FULL | PK_ENTERPRISE | 5. | | 1 (0) | 00:00:01 |
36. * 30 | JOIN TYPE. | 46. 736. | 3 (34) | 00:00:01 |
37. 31. VIEW | the index $ _join$ _006 | 46. 736. | 2 (0) | 00:00:01 |
38. * 32 | HASH JOIN | | | | | | |
39. 33. FULL RESTRICTED INDEX SCAN FAST | IDX_HULLCLASS_ENT | 46. 736. | 1 (0) | 00:00:01 |
40. 34. FULL RESTRICTED INDEX SCAN FAST | IDX_HULLCLASS | 46. 736. | 1 (0) | 00:00:01 |
41. 35. TABLE ACCESS FULL | HULL | 422. 13082. | 5 (0) | 00:00:01 |
42. 36. TABLE ACCESS FULL | TRAVEL | 53461 | 991K | | 99 (2) | 00:00:01 |
43. * 37 | INDEX RANGE SCAN | PK_SHIPSHEET_ANNUAL_PHASING | 4. | | 2 (0) | 00:00:01 |
44. 38. TABLE ACCESS BY INDEX ROWID | SHIP_SHEET_ANNUAL_PHASING | 4. 60. | 3 (0) | 00:00:01 |
45. 39. TABLE ACCESS FULL | TRAVEL_OVERTIME | 245K | 3596K | | 363 (2) | 00:00:03 |
46. * 40 | TABLE ACCESS FULL | SHIP_SHEET_ANNUAL_PHASING | 500K | 7327K | | 1458 (2) | 00:00:12 |
47 --------------------------------------------------------------------------------------------------------------------------------------
48
Predicate information 49 (identified by the operation identity card):
50 ---------------------------------------------------
51
5 52 - access ("P". "FISCAL YEAR" (+) = "RY" "." " THE EXERCISE' AND 'P '. "' SHIP_SHEETS_ID ' (+) ="SQ ". ("' SHIP_SHEETS_ID")
7 53 - access ("RY". "" REQ_ID '=' SQ. ("' REQ_ID")
54 8 - filter ("RY". "FY" > = 2014 AND 'RY' "." " (FY' < = 2020)
55-11 - access ("TRO". "FISCAL YEAR" (+) = "P1" "." " THE EXERCISE"AND"TRO ". "' TRAVEL_ID ' (+) ="T ". ("' TRAVEL_ID")
56 15 - access ("T". "' SHIP_SHEETS_ID ' (+) ="SS ". ("' SHIP_SHEETS_ID")
57 16 - access ("SS". "AVAILABILITY_TYPE_ID"= 'A'." AVAILABILITY_TYPE_ID')
58 18 - access (ROWID = ROWID)
59 21 - access ("SS". "PE_ID"="P" "." PE_ID')
60 23 - access ("SS". "HULL_ID"="H" "." HULL_ID')
61 24 - filter ("SS". ("NSA_WORKSITE_ID" = 11)
62 25 - access ("SS". ("REQ_ID" = 248)
63 26 - access ('H'. "" HULL_CLASS_ID "=" HC ". ("' HULL_CLASS_ID")
64 30 - access ("HC". "ENT_ID"="E" "." " ENT_ID')
filter 65 ("HC". "ENT_ID"="E" "." " ENT_ID')
66 32 - access (ROWID = ROWID)
67 37 - access ("P1". "SHIP_SHEETS_ID"="SS" "." " SHIP_SHEETS_ID')
68 40 - filters ("P". "FY" (+) > = 2014 AND 'P '. "FY" (+) (< = 2020) "
{code}
I see several FULL ACCESS TABLE, I want to improve the speed of this query because the running business manager pays 47% activity.
Can anyone guide my thru?
Thank you!
If the query takes 2 seconds to finish? How many times is the executed query? Do you think that 2 seconds too for this operation?
The query plan does not show errors in the optimizers cardinality estimates. Maybe the COMPLETE TABLE SCANs of 39 and 40 step could be avoided (and corresponding HASH joins replaced by NESTED LOOPS) if there were signs of adjustment - but this does not mean that a NL join with access index would provide a large performance gain.
Without the request, it is difficult to say but I think that access on SHIP_SHEET_ANNUAL_PHASING could use an index on SHIP_SHEET_ANNUAL_PHASING (SHIP_SHEETS_ID, FY) and access on TRAVEL_OVERTIME use an index on TRAVEL_OVERTIME (TRAVEL_ID, FY). So the first question is: these indices exist? The second question is: you can create additional indexes? (In view of the fact that these indices could influence other queries - and not necessarily in a positive way - and they will have a negative impact on DDL operations on the table)
Perhaps the first question is rather: do you need to improve performance at all? The other questions are 2. and 3.
-
Hello
Is possible do this merger with an update without using rowid statement?
merge with e pfa_pcobcapemes
(
Select e.rowid as
aux_abonos_cont a, pfa_pcobfactmes d, pga_tarmensu f, aux_contcape g, pfa_pcobcapemes e
where ind_baja = 'F' and fec_baja is not null
and d.cta_facturac = a.cta_facturac and a.cod_postal = d.cod_postal
and d.num_abonados > 1
and e.cod_factura = d.cod_factura
and e.num_telefono = a.num_telefono
and trunc (e.fec_hasta) = trunc (a.fec_baja)
and f.cod_plantari = a.cod_plantari and f.cod_confactu = e.cod_confactu and ((f.tipo_pr = serait "et f.p_calc='C") or f.tipo_pr = 'V') and f.cod_servunic = g.cod_servunic
and f.fec_efectivi in
(
Select max (fec_efectivi) from pga_tarmensu where cod_plantari = f.cod_plantari and cod_servunic = f.cod_servunic
)
and g.cod_postal = d.cod_postal and g.cta_facturac = d.cta_facturac and g.num_telefono = a.num_telefono
) a
on
(
e.ROWID =
)
When matched then
update set e.fec_hasta = e.fec_hasta - 1
-------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time | Pstart. Pstop |
-------------------------------------------------------------------------------------------------------------------------------------------
| 0 | MERGE STATEMENT | | 1. 17. | 1513 (2) | 00:00:19 | | |
| 1. MERGE | PFA_PCOBCAPEMES | | | | | | | |
| 2. VIEW | | | | | | | | |
|* 3 | HASH JOIN | | 1. 261. | 1513 (2) | 00:00:19 | | |
|* 4 | TABLE ACCESS BY INDEX ROWID | PGA_TARMENSU_1 | 1. 25. | 3 (0) | 00:00:01 | | |
| 5. NESTED LOOPS | | 1. 236. | 510 (2) | 00:00:07 | | |
| 6. NESTED LOOPS | | 1. 211 | | 507 (2) | 00:00:07 | | |
| 7. NESTED LOOPS | | 1. 181. | 505 (2) | 00:00:07 | | |
| 8. NESTED LOOPS | | 1. 116. | 504 (2) | 00:00:07 | | |
| 9. NESTED LOOPS | | 2. 134. | 501 (2) | 00:00:07 | | |
| * 10 | FULL RESTRICTED INDEX SCAN FAST | PK_AUX_ABONOS | 48. 1584. | 405 (2) | 00:00:05 | | |
| 11. RANGE OF PARTITION ITERATOR. | 1. 34. | 2 (0) | 00:00:01 | KEY | KEY |
| * 12 | TABLE ACCESS BY LOCAL INDEX ROWID | PFA_PCOBFACTMES | 1. 34. | 2 (0) | 00:00:01 | KEY | KEY |
| * 13 | INDEX RANGE SCAN | PFA_PCOBFACTMES_I03 | 1. | | 1 (0) | 00:00:01 | KEY | KEY |
| 14. RANGE OF PARTITION ITERATOR. | 1. 49. | 2 (0) | 00:00:01 | KEY | KEY |
| * 15 | TABLE ACCESS FULL | PFA_PCOBCAPEMES | 1. 49. | 2 (0) | 00:00:01 | KEY | KEY |
| 16. TABLE ACCESS BY ROWID USER | PFA_PCOBCAPEMES | 1. 65. | 1 (0) | 00:00:01 | ROWID | ROWID |
| * 17. INDEX RANGE SCAN | PK_AUX_CONTCAPE | 1. 30. | 2 (0) | 00:00:01 | | |
| * 18. INDEX RANGE SCAN | PK_TARMENSU | 1. | | 2 (0) | 00:00:01 | | |
| 19. VIEW | VW_SQ_2 | 188K | 4608K | | 999 (1) | 00:00:12 | | |
| 20. GROUP SORT BY | | 188K | 3133K | 10 M | 999 (1) | 00:00:12 | | |
| 21. INDEX SCAN FULL | PK_TARMENSU | 188K | 3133K | | 999 (1) | 00:00:12 | | |
-------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
3 - access("F".") FEC_EFECTIVI "="VW_COL_1"AND"COD_PLANTARI "=" F"." COD_PLANTARI' AND 'COD_SERVUNIC '=' F '. ("' COD_SERVUNIC")
4 filter (("F". "P_CALC"= 'C' AND 'F'." TIPO_PR "= A"OR "F".» TIPO_PR "=" V") AND"F ". "' COD_CONFACTU '=' E '. ("' COD_CONFACTU")
10 - filter ("FEC_BAJA" IS NOT NULL AND "IND_BAJA" = 'F')
12 - filter("D".") NUM_ABONADOS"> 1)
13 - access("A".") COD_POSTAL "=" D ". "" COD_POSTAL "AND"D ". ' CTA_FACTURAC '= 'A'. ("' CTA_FACTURAC")
15 - filter("E".") COD_FACTURA "=" D ". "' COD_FACTURA ' AND 'E '. ' NUM_TELEFONO '= 'A'. "" NUM_TELEFONO "AND
TRUNC (INTERNAL_FUNCTION ("E". "FEC_HASTA")) = TRUNC (INTERNAL_FUNCTION ("A". " FEC_BAJA')))
17 - access("G".") COD_POSTAL "=" D ". "' COD_POSTAL ' AND 'G '. "" CTA_FACTURAC "=" D ". "" CTA_FACTURAC "AND
"G"." NUM_TELEFONO '= 'A'.' NUM_TELEFONO')
18 - access("F".") COD_PLANTARI '= 'A'.' COD_PLANTARI' AND 'F' "" COD_SERVUNIC "=" G ". ("' COD_SERVUNIC")
Thanks in advance.
Kind regards
Jose Luis
Yes you can. But an update might be more expensive that you will need to use the EXISTS clause to check for the existence of the record before the update. Not sure what is the purpose of this request. In any case it is here.
Update pfa_pcobfactmes d
Set d.fec_hasta =
(
Select d.fec_hasta - 1
of aux_abonos_cont one
pga_tarmensu f
aux_contcape g
e pfa_pcobcapemes
where ind_baja = 'F'
and d.cta_facturac = a.cta_facturac
and a.cod_postal = d.cod_postal
and d.num_abonados > 1
and e.cod_factura = d.cod_factura
and e.num_telefono = a.num_telefono
and trunc (e.fec_hasta) = trunc (a.fec_baja)
and f.cod_plantari = a.cod_plantari
and f.cod_confactu = e.cod_confactu
and f.cod_servunic = g.cod_servunic
and g.cod_postal = d.cod_postal
and g.cta_facturac = d.cta_facturac
and g.num_telefono = a.num_telefono
and fec_baja is not null
and)
(f.tipo_pr = ' and f.p_calc ='C ') or
f.tipo_pr = 'V'
)
and f.fec_efectivi in
(
Select max (fec_efectivi)
of pga_tarmensu
where cod_plantari = f.cod_plantari
and cod_servunic = f.cod_servunic
)
)
where
There are)
Select null
of aux_abonos_cont one
pga_tarmensu f
aux_contcape g
e pfa_pcobcapemes
where ind_baja = 'F'
and d.cta_facturac = a.cta_facturac
and a.cod_postal = d.cod_postal
and d.num_abonados > 1
and e.cod_factura = d.cod_factura
and e.num_telefono = a.num_telefono
and trunc (e.fec_hasta) = trunc (a.fec_baja)
and f.cod_plantari = a.cod_plantari
and f.cod_confactu = e.cod_confactu
and f.cod_servunic = g.cod_servunic
and g.cod_postal = d.cod_postal
and g.cta_facturac = d.cta_facturac
and g.num_telefono = a.num_telefono
and fec_baja is not null
and)
(f.tipo_pr = ' and f.p_calc ='C ') or
f.tipo_pr = 'V'
)
and f.fec_efectivi in
(
Select max (fec_efectivi)
of pga_tarmensu
where cod_plantari = f.cod_plantari
and cod_servunic = f.cod_servunic
)
)
Maybe you are looking for
-
How can I get into the bios in an hp touchscreen computer.
-
My T2i has a turn to blue which can be corrected in photoshop. No cause. How can it be solved?
Just came out not the case. He could have progressive but not sure. The camera was droped two days before it happened. Nithing else wrong with the camera. I learned that it is the sensor or the Board of Directors. But not sure, it can be a solid stat
-
Cannot print on HP3510. Printer says it all is OK. Printer set default on computer, bur documsnt sitin what. Using Vista.
-
What is error in system memory dump files and is it ok to delete
can someone tell me what are the system error memory dump files and mini dump files and is it OK to remove them to give me more memory hard drive
-
Driver Geforce 5470 Vostro 740 M in Windows 8.1 issues 64-bit
Hello After a catastrophic clean install of Windows 10, where I had to make sure wouldn't it have the version of the Intel Management Engine 9.5 driver, or my laptop not properly closed; and get Intel Graphics display driver with the Windows display