Index is not used, although suspicion.
DBVersion: 10.2.0.3 CREATE TABLE "ESW"."DURCHLAUFZEIT_SONDER_AG"
( "AG" NUMBER(3,0) DEFAULT 0 NOT NULL ENABLE,
"TAGE" NUMBER(5,0) DEFAULT 0 NOT NULL ENABLE,
"ABTEILUNG" VARCHAR2(20 BYTE),
Content of this table
AG TAGE ABTEILUNG
910 1 EAV
133 1 TG
743 2 TM
719 2 TM
706 2 TM
979 10 TMselect /*+ index(apl(arbeitsgang_nr))*/
/*+ index(w2 WALZE_IND1)*/
SUM (dsa.tage) tage,
w2.walzen_nr walzen_nr,
w2.walzen_ng walzen_ng
from durchlaufzeit_sonder_ag dsa,
auftrag_arbeitsplan apl,
walze w2
where apl.arbeitsgang_nr in
( select dsa1.ag ag
from durchlaufzeit_sonder_ag dsa1
where dsa1.abteilung = 'TM' )*and apl.auftr_nr = w2.auftr_nr
and apl.auftr_jj = w2.auftr_jj
and apl.auftr_pos = w2.auftr_pos
and apl.auftr_los = w2.auftr_los
and dsa.abteilung = 'TM'
and dsa.ag = apl.arbeitsgang_nr
GROUP BY w2.walzen_nr,
w2.walzen_ng;
--------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
--------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 21 | 1155 | 4927 |
| 1 | SORT GROUP BY | | 21 | 1155 | 4927 |
|* 2 | HASH JOIN | | 21 | 1155 | 4922 |
| 3 | NESTED LOOPS | | 333 | 11655 | 4682 |
| 4 | NESTED LOOPS | | 16215 | 427K| 4682 |
| 5 | TABLE ACCESS BY INDEX ROWID| DURCHLAUFZEIT_SONDER_AG | 4 | 40 | 2 |
|* 6 | INDEX RANGE SCAN | DURCHLAUFZEIT_SONDER_AG_INDEX1 | 4 | | 1 |
| 7 | TABLE ACCESS BY INDEX ROWID| AUFTRAG_ARBEITSPLAN | 4054 | 68918 | 1170 |
|* 8 | INDEX RANGE SCAN | AUFTRAG_ARBEITSPLAN_IND3 | 4054 | | 7 |
|* 9 | INDEX RANGE SCAN | DURCHLAUFZEIT_SONDER_AG_INDEX2 | 1 | 8 | |
| 10 | *TABLE ACCESS FULL* | WALZE | 75432 | 1473K| 239 |
--------------------------------------------------------------------------------------------------select /*+ index(apl(arbeitsgang_nr))*/
/*+ index(w2 WALZE_IND1)*/
SUM (dsa.tage) tage,
w2.walzen_nr walzen_nr,
w2.walzen_ng walzen_ng
from durchlaufzeit_sonder_ag dsa,
auftrag_arbeitsplan apl,
walze w2
where apl.arbeitsgang_nr in
( 743, 719, 706, 979 )
and apl.auftr_nr = w2.auftr_nr
and apl.auftr_jj = w2.auftr_jj
and apl.auftr_pos = w2.auftr_pos
and apl.auftr_los = w2.auftr_los
and dsa.abteilung = 'TM'
and dsa.ag = apl.arbeitsgang_nr
GROUP BY w2.walzen_nr,
w2.walzen_ng;
---------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
---------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 94 | 1161 |
| 1 | SORT GROUP BY | | 2 | 94 | 1161 |
| 2 | TABLE ACCESS BY INDEX ROWID | WALZE | 1 | 20 | 2 |
| 3 | NESTED LOOPS | | 2 | 94 | 1156 |
|* 4 | HASH JOIN | | 31 | 837 | 1094 |
| 5 | INLIST ITERATOR | | | | |
| 6 | TABLE ACCESS BY INDEX ROWID| DURCHLAUFZEIT_SONDER_AG | 3 | 30 | 2 |
|* 7 | INDEX RANGE SCAN | DURCHLAUFZEIT_SONDER_AG_INDEX2 | 3 | | 1 |
| 8 | INLIST ITERATOR | | | | |
| 9 | TABLE ACCESS BY INDEX ROWID| AUFTRAG_ARBEITSPLAN | 2276 | 38692 | 1091 |
|* 10 | INDEX RANGE SCAN | AUFTRAG_ARBEITSPLAN_IND3 | 2276 | | 8 |
|* 11 | INDEX RANGE SCAN | WALZE_IND1 | 1 | | 1 |
---------------------------------------------------------------------------------------------------As far as I know only the first comment of suspicion in a given query block is considered.
So it would be valid (unless hint_one is specified correctly)...
SELECT /*+ hint_one hint_two */
column_name
FROM table_name;
SELECT /*+
hint_one
hint_two
*/
column_name
FROM table_name;
SELECT /*+ hint_one
hint_two */
column_name
FROM table_name;
SELECT --+ hint_one hint_two
column_name
FROM table_name;
But this should not (regardless of if hint_one is specified correctly)...
SELECT /*+ hint_one */
/*+ hint_two */
column_name
FROM table_name;
Also I do not believe your INDEX index specification is correct, a single set of brackets should be used and the alias name and index table must be separated by a space or a comma.
So it would be nice...
SELECT /*+ INDEX (table_alias index_name) */
column_name
FROM table_name;
SELECT /*+ INDEX (table_alias, index_name) */
column_name
FROM table_name;
But it would not...
SELECT /*+ INDEX (table_alias (index_name)) */
column_name
FROM table_name;
Also, you should be aware that an INDEX indicator is only considered provided that supports a given join order.
Tags: Database
Similar Questions
-
Hi forum
Dynamically generated in this query:
SELECT TITULO_MEDIODEPAGO AS TITLE, IDA_MEDIODEPAGO AS IDA, COUNT (DISTINCT VISTA. ID1 | VISTA. ID2. VISTA. ID3) AS AMOUNT
OF MVISTA VISTA
WHERE ((COALESCE (VISTA. FECHAEXPIRACION, TO_DATE (' 01/01/9999 ',' dd/mm/yyyy ""))) > = SYSDATE) AND
((1=1) OR: p_rubro IS NULL) AND ((1=1) OR: p_subrubro IS NULL) AND
(VISTA. TITULO_PROVINCIA =: p_provincia) AND ((1=1) OR: p_ciudad IS NULL) AND
((1=1) OR: p_barrio IS NULL) AND ((1=1) OR: p_mediopago IS NULL) AND
((1=1) OR: p_nrocuotas IS NULL) AND ((1=1) OR: p_porcentaje IS NULL) AND
((1=1) OR: p_dias IS NULL) AND ((1=1) OR: p_textoBusqueda IS NULL)
TITULO_MEDIODEPAGO GROUP, IDA_MEDIODEPAGO
: p_rubro is null
: p_subrubro is null
: p_provincia = "PROV1.
: p_barrio is null
: p_mediopago is null
: p_nrocuotas is null
: p_porcentaje is null
: p_dias is null
: p_textoBusqueda is null
When I inspect the plan to explain it, I could see a full analysis on the materialized view MVISTA operation. I want to avoid this analysis complements the view with 500 k lines:
MAT_VIEW_ACCESS MVISTA Filter predicates
AND NLSSORT (VISTA. TITULO_PROVINCIA, "nls_sort = 'BINART_AI'") = NLSSORT (: P_PROVINCIA "nls_sort =" BINARY_AI"') COALESCE (VISTA. FECHAEXPIRACION, TIMESTAMP'9999-01-01 00:00:00 ') > = SYSDATE @! I add an index to the materialized view 'MVISTA' TITULO_PROVINCIA (CSA) and FECHAEXPIRACION (CSA) fields, but it is not used by the query. Why the index is not used? How to define the index serve him?
Thank you very much
One of the reasons for the index is not used because you apply the function nlssort on a single column.
You must use an index of feature based using this function instead.
In addition, I would rewrtite him coalesce to
(VISTA. FECHAEXPIRACION > = SYSDATE or VISTA. FECHAEXPIRACION is null)
-
Why index is not used on an editable view update?
I need help to understand why Oracle 11.2.0.3 is an index for an editable view. When I refer to the base table, offer$, I access index. When I reference the view, offer, I get a comprehensive analysis of the offer$. There's a trigger on the view instead. Who is factor in there somehow?
> EXPLAIN the PLAN FOR
UPDATE OFFER$ SET PRESENTABLE_FLAG = 'F', ACCEPTED_OFFER_FLAG 'T =' WHERE ASSIGNED_OFFER_ID = (SELECT SOLICITATION_REF_ID FROM TENDER WHERE SOLICITATION_ID =: B1)
plan FOR successful.
> SELECT * FROM TABLE (DBMS_XPLAN. Display (null, NULL, 'ALL'))
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 3047622554
-------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-------------------------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT. | 1. 25. 2 (0) | 00:00:01 |
| 1. UPDATE | OFFER$ | | | | |
| 2. TABLE ACCESS BY INDEX ROWID | OFFER$ | 1. 25. 1 (0) | 00:00:01 |
|* 3 | INDEX UNIQUE SCAN | AK_OFFER_ASSIGNED_OFFER_ID | 1. | 1 (0) | 00:00:01 |
| 4. TABLE ACCESS BY INDEX ROWID | TENDER $ | 1. 20. 1 (0) | 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_SOLICITATION$ | 1. | 1 (0) | 00:00:01 |
-------------------------------------------------------------------------------------------------------------
Name of the query block / Alias object (identified by the operation identity card):
-------------------------------------------------------------
1 UPD$ 1
2 UPD$ 1 / OFFER$@UPD$1
3 UPD$ 1 / OFFER$@UPD$1
4 SALT$ F5BB74E1 / SOLICITATION$@SEL$2
5. SALT$ F5BB74E1 / SOLICITATION$@SEL$2
Information of predicates (identified by the operation identity card):
---------------------------------------------------
3 - access ("ASSIGNED_OFFER_ID" = (SELECT "SOLICITATION_REF_ID" FROM KOHP." "TENDER CALL $ '.
"TENDER CALL $ ' WHERE 'SOLICITATION_ID' = TO_NUMBER (:B1)))
5 - access ('SOLICITATION_ID' = TO_NUMBER (:B1))
Projection of the column information (identified by the operation identity card):
-----------------------------------------------------------
2 - (upd = 4, 6, 7 cmp = 3, 7; cpy = 2, 4, 5) "OFFER$". ROWID [ROWID, 10], "OFFER$". " DECISION_ID '[NUMBER, 22],
"ASSIGNED_OFFER_ID" [VARCHAR2, 255], "ACCEPTED_OFFER_FLAG" [CHARACTER, 1],
"OFFER$". " CURRENT_OFFER_FLAG "[CHARACTER, 1],"PRESENTABLE_FLAG "[CHARACTER, 1],"
"OFFER$". " CHNG_DTTM ' [TIMESTAMP, 11].
3. "OFFER$". ROWID [ROWID, 10], "ASSIGNED_OFFER_ID" [VARCHAR2, 255]
4. "TENDER CALL $ '. ROWID [ROWID, 10], "SOLICITATION_ID" [NO.22].
"SOLICITATION_REF_ID" [VARCHAR2, 50]
5. "TENDER CALL $ '. ROWID [ROWID, 10], "SOLICITATION_ID" [NO.22]
40 selected lines
> EXPLAIN the PLAN FOR
UPDATE OFFER SET PRESENTABLE_FLAG = 'F', ACCEPTED_OFFER_FLAG 'T =' WHERE ASSIGNED_OFFER_ID = (SELECT SOLICITATION_REF_ID FROM TENDER WHERE SOLICITATION_ID =: B1)
plan FOR successful.
> SELECT * FROM TABLE (DBMS_XPLAN. Display (null, NULL, 'ALL'))
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hash value of plan: 1083159671
--------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
--------------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT. | 958K | 987 M | 9182 (1) | 00:01:51 |
| 1. UPDATE | OFFER | | | | |
|* 2 | VIEW | OFFER | 958K | 987 M | 9181 (1) | 00:01:51 |
| 3. TABLE ACCESS FULL | OFFER$ | 958K | 127 M | 9181 (1) | 00:01:51 |
| 4. TABLE ACCESS BY INDEX ROWID | TENDER $ | 1. 20. 1 (0) | 00:00:01 |
|* 5 | INDEX UNIQUE SCAN | PK_SOLICITATION$ | 1. | 1 (0) | 00:00:01 |
--------------------------------------------------------------------------------------------------
Name of the query block / Alias object (identified by the operation identity card):
-------------------------------------------------------------
1 UPD$ 1
2 SALT$ 1 / OFFER@UPD$1
3 SALT$ 1 / OFFER$@SEL$1
4 SALT$ 335DD26A / SOLICITATION$@SEL$3
5. SALT$ 335DD26A / SOLICITATION$@SEL$3
Information of predicates (identified by the operation identity card):
---------------------------------------------------
2 - filter ("ASSIGNED_OFFER_ID" = (SELECT "SOLICITATION_REF_ID" FROM
KOHP. ' ' TENDER $ "" PROMPT$ ' WHERE 'SOLICITATION_ID' = TO_NUMBER (:B1)))
5 - access ('SOLICITATION_ID' = TO_NUMBER (:B1))
Projection of the column information (identified by the operation identity card):
-----------------------------------------------------------
2 - (upd = 13, 45; cmp = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 2
7,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,46,47,48,49,50)
'OFFER '. "OFFER_ID" [NO.22], "PROVIDE" "." " DECISION_ID '[NUMBER, 22],
'OFFER '. "OFFER_TYPE_CD" [NO.22], "PROVIDE" "." " PROMO_ID '[NUMBER, 22],
'OFFER '. "PYMT_METHOD_TYPE_CD" [NO.22], "PROVIDE" "." " CS_RESULT_ID '[NUMBER, 22],
'OFFER '. "CS_RESULT_USAGE_TYPE_CD" [NO.22], "PROVIDE" "." " RATE_INDEX_TYPE_CD '[NUMBER, 22],
'OFFER '. "SUB_PRODUCT_ID" [NO.22], "PROVIDE" "." " CAMPAIGN_ID '[NUMBER, 22],
'OFFER '. "MARKET_CELL_ID" [NO.22], "ASSIGNED_OFFER_ID" [VARCHAR2, 255], "" "
"ACCEPTED_OFFER_FLAG" [CHARACTER, 1], 'OFFER '. "CURRENT_OFFER_FLAG"[CHARACTER, 1],
'OFFER '. "OFFER_GOOD_UNTIL_DATE" [DATE, 7], "PROVIDE" "." " RESCINDABLE_DAYS '[NUMBER, 22],
'OFFER '. "RESCINDED_DATE" [DATE, 7], "PROVIDE" "." " AMOUNT '[NUMBER, 22],
'OFFER '. "MAX_AMOUNT" [NO.22], "PROVIDE" "." " AMOUNT_FINANCED '[NUMBER, 22],
'OFFER '. "DOWN_PYMT" [NO.22], "PROVIDE" "." " RATE "[NO.22],"PROVIDE"". "" TERM_MM '[NUMBER, 22],
'OFFER '. "ORIGINATION_FEE_AMOUNT" [NO.22], "PROVIDE" "." " ORIGINATION_FEE_RATE '[NUMBER, 22],
'OFFER '. "FINANCE_CHARGE" [NO.22], "PROVIDE" "." " NBR_OF_PYMTS '[NUMBER, 22],
'OFFER '. "PYMT" [NO.22], "PROVIDE" "." " TOTAL_PYMTS '[NUMBER, 22],
'OFFER '. "FIRST_PYMT_DATE" [DATE, 7], "PROVIDE" "." " CONTRACT_DATE "[DATE, 7],
'OFFER '. "ACCT_NBR" [VARCHAR2, 20], "PROVIDE" "." " ACCT_NBR_ASSIGNED_DTTM ' [TIMESTAMP, 11],
'OFFER '. "ACCT_EXPIRATION_DTTM" [DATE, 8], "PROVIDE" "." " OFFER_DESC ' [VARCHAR2, 255],
'OFFER '. "TIMEOUTMIN_RATE" [NO.22], "PROVIDE" "." " MAX_RATE '[NUMBER, 22],
'OFFER '. "MIN_AMOUNT" [NO.22], "PROVIDE" "." " ANNUAL_FEE_AMOUNT '[NUMBER, 22],
'OFFER '. "ANNUAL_FEE_WAIVED_MM" [NO.22], "PROVIDE" "." " LATE_FEE_PERCENT '[NUMBER, 22],
'OFFER '. "LATE_FEE_MIN_AMOUNT" [NO.22], "PROVIDE" "." " OFFER_SALES_SCRIPT ' [VARCHAR2, 500],
'OFFER '. "OFFER_ORDER" [NO.22], "PRESENTABLE_FLAG"[CHARACTER, 1], "
'OFFER '. "INDEX_RATE" [NO.22], "PROVIDE" "." " ACTV_FLAG ' [VARCHAR2, 1],
'OFFER '. "CORRELATION_ID" [VARCHAR2, 64], "PROVIDE" "." " OFFER_STATUS_TYPE_CD '[NUMBER, 22],
'OFFER '. "PRESENTATION_INSTRUMENT_NBR" [VARCHAR2, 20].
3. "OFFER_ID" [NO.22], "DECISION_ID" [NO.22], "OFFER_TYPE_CD" [NO.22],
"PROMO_ID" [NO.22], "PYMT_METHOD_TYPE_CD" [NO.22], "CS_RESULT_ID" [NO.22],
"CS_RESULT_USAGE_TYPE_CD" [NO.22], "RATE_INDEX_TYPE_CD" [NO.22],
"SUB_PRODUCT_ID" [NO.22], 'CAMPAIGN_ID' [NO.22], "MARKET_CELL_ID" [NO.22],
"ASSIGNED_OFFER_ID" [VARCHAR2, 255], "ACCEPTED_OFFER_FLAG" [CHARACTER, 1],
"CURRENT_OFFER_FLAG" [CHARACTER, 1], "OFFER_GOOD_UNTIL_DATE" [DATE, 7],.
"RESCINDABLE_DAYS" [NO.22], "RESCINDED_DATE" [DATE, 7], 'COME BACK' [NO.22].
"MAX_AMOUNT" [NO.22], "AMOUNT_FINANCED" [NO.22], "DOWN_PYMT" [NO.22],
'RATE' [NO.22], "TERM_MM" [NO.22], "ORIGINATION_FEE_AMOUNT" [NO.22],
"ORIGINATION_FEE_RATE" [NO.22], "FINANCE_CHARGE" [NO.22],
"NBR_OF_PYMTS" [NO.22], "PYMT" [NO.22], "TOTAL_PYMTS" [NO.22],
"FIRST_PYMT_DATE" [DATE, 7], "CONTRACT_DATE" [DATE, 7], ' ACCT_NBR$ ' [RAW, 40].
"ACCT_NBR_ASSIGNED_DTTM" [TIMESTAMP, 11], ' ACCT_EXPIRATION_DTTM$ ' [RAW, 40].
"OFFER_DESC" [VARCHAR2, 255], "TIMEOUTMIN_RATE" [NO.22], "MAX_RATE" [NO.22].
"MIN_AMOUNT" [NO.22], "ANNUAL_FEE_AMOUNT" [NO.22],
"ANNUAL_FEE_WAIVED_MM" [NO.22], "LATE_FEE_PERCENT" [NO.22],
"LATE_FEE_MIN_AMOUNT" [NO.22], "OFFER_SALES_SCRIPT" [VARCHAR2, 500].
"OFFER_ORDER" [NO.22], "PRESENTABLE_FLAG" [CHARACTER, 1], "INDEX_RATE" [NO.22],
"ACTV_FLAG" [VARCHAR2, 1], "CORRELATION_ID" [VARCHAR2, 64].
"OFFER_STATUS_TYPE_CD" [NO.22], ' PRESENTATION_INSTRUMENT_NBR$ ' [RAW, 40]
4. "TENDER CALL $ '. ROWID [ROWID, 10], "SOLICITATION_ID" [NO.22].
"SOLICITATION_REF_ID" [VARCHAR2, 50]
5. "TENDER CALL $ '. ROWID [ROWID, 10], "SOLICITATION_ID" [NO.22]
82 selected lines
CREATE OR REPLACE FORCE VIEW "OFFER" ("OFFER_ID","DECISION_ID","OFFER_TYPE_CD","PROMO_ID","PYMT_METHOD_TYPE_CD","CS_RESULT_ID","CS_RESULT_USAGE_TYPE_CD","RATE_INDEX_TYPE_CD","SUB_PRODUCT_ID","CAMPAIGN_ID","MARKET_CELL_ID","ASSIGNED_OFFER_ID","ACCEPTED_OFFER_FLAG","CURRENT_OFFER_FLAG","OFFER_GOOD_UNTIL_DATE","RESCINDABLE_DAYS","RESCINDED_DATE","AMOUNT","MAX_AMOUNT","AMOUNT_FINANCED" ,"DOWN_PYMT","RATE","TERM_MM","ORIGINATION_FEE_AMOUNT","ORIGINATION_FEE_RATE","FINANCE_CHARGE","NBR_OF_PYMTS","PYMT","TOTAL_PYMTS","FIRST_PYMT_DATE","CONTRACT_DATE","ACCT_NBR","ACCT_NBR_ASSIGNED_DTTM","ACCT_EXPIRATION_DTTM","OFFER_DESC","MIN_RATE","MAX_RATE","MIN_AMOUNT","ANNUAL_FEE_AMOUNT","ANNUAL_FEE_WAIVED_MM","LATE_FEE_PERCENT","LATE_FEE_MIN_AMOUNT","OFFER_SALES_SCRIPT","OFFER_ORDER","PRESENTABLE_FLAG" « INDEX_RATE » 'INSRT_DTTM', 'INSRT_USR_ID', 'CHNG_DTTM', 'CHNG_USR_ID', 'ACTV_FLAG', 'CORRELATION_ID', 'OFFER_STATUS_TYPE_CD', 'PRESENTATION_INSTRUMENT_NBR')
AS
SELECT
OFFER_ID
DECISION_ID
OFFER_TYPE_CD
PROMO_ID
PYMT_METHOD_TYPE_CD
CS_RESULT_ID
CS_RESULT_USAGE_TYPE_CD
RATE_INDEX_TYPE_CD
SUB_PRODUCT_ID
CAMPAIGN_ID
MARKET_CELL_ID
ASSIGNED_OFFER_ID
ACCEPTED_OFFER_FLAG
CURRENT_OFFER_FLAG
OFFER_GOOD_UNTIL_DATE
RESCINDABLE_DAYS
RESCINDED_DATE
QUANTITY
MAX_AMOUNT
AMOUNT_FINANCED
DOWN_PYMT
RATE
TERM_MM
ORIGINATION_FEE_AMOUNT
ORIGINATION_FEE_RATE
FINANCE_CHARGE
NBR_OF_PYMTS
DATED THE
TOTAL_PYMTS
FIRST_PYMT_DATE
CONTRACT_DATE
, CAST (zcrypto.decrypt (ACCT_NBR$) AS VARCHAR2 (20)) ACCT_NBR
ACCT_NBR_ASSIGNED_DTTM
, ACCT_EXPIRATION_DTTM TO_DATE (zcrypto.decrypt (ACCT_EXPIRATION_DTTM$))
OFFER_DESC
TIMEOUTMIN_RATE
MAX_RATE
MIN_AMOUNT
ANNUAL_FEE_AMOUNT
ANNUAL_FEE_WAIVED_MM
LATE_FEE_PERCENT
LATE_FEE_MIN_AMOUNT
OFFER_SALES_SCRIPT
OFFER_ORDER
PRESENTABLE_FLAG
INDEX_RATE
INSRT_DTTM
INSRT_USR_ID
CHNG_DTTM
CHNG_USR_ID
ACTV_FLAG
CORRELATION_ID
OFFER_STATUS_TYPE_CD
, CAST (zcrypto.decrypt (PRESENTATION_INSTRUMENT_NBR$) AS VARCHAR2 (20)) PRESENTATION_INSTRUMENT_NBR
Of
OFFER$;
CREATE OR REPLACE TRIGGER "OFFER_IO" INSTEAD OF
INSERT OR
UPDATE
THEN OFFER REFERENCING NEW AS NEW AS OF OLD FOR THE BEGINNING OF EACH ROW SO (INSERT)
INSERT
IN
OFFER$
(
OFFER_ID
DECISION_ID
OFFER_TYPE_CD
PROMO_ID
PYMT_METHOD_TYPE_CD
CS_RESULT_ID
CS_RESULT_USAGE_TYPE_CD
RATE_INDEX_TYPE_CD
SUB_PRODUCT_ID
CAMPAIGN_ID
MARKET_CELL_ID
ASSIGNED_OFFER_ID
ACCEPTED_OFFER_FLAG
CURRENT_OFFER_FLAG
OFFER_GOOD_UNTIL_DATE
RESCINDABLE_DAYS
RESCINDED_DATE
QUANTITY
MAX_AMOUNT
AMOUNT_FINANCED
DOWN_PYMT
RATE
TERM_MM
ORIGINATION_FEE_AMOUNT
ORIGINATION_FEE_RATE
FINANCE_CHARGE
NBR_OF_PYMTS
DATED THE
TOTAL_PYMTS
FIRST_PYMT_DATE
CONTRACT_DATE
, ACCT_NBR$
ACCT_NBR_ASSIGNED_DTTM
, ACCT_EXPIRATION_DTTM$
OFFER_DESC
TIMEOUTMIN_RATE
MAX_RATE
MIN_AMOUNT
ANNUAL_FEE_AMOUNT
ANNUAL_FEE_WAIVED_MM
LATE_FEE_PERCENT
LATE_FEE_MIN_AMOUNT
OFFER_SALES_SCRIPT
OFFER_ORDER
PRESENTABLE_FLAG
INDEX_RATE
ACTV_FLAG
CORRELATION_ID
OFFER_STATUS_TYPE_CD
, PRESENTATION_INSTRUMENT_NBR$
)
VALUES
(
: NEW. OFFER_ID
,: NEW. DECISION_ID
,: NEW. OFFER_TYPE_CD
,: NEW. PROMO_ID
,: NEW. PYMT_METHOD_TYPE_CD
,: NEW.CS_RESULT_ID
,: NEW.CS_RESULT_USAGE_TYPE_CD
,: NEW. RATE_INDEX_TYPE_CD
,: NEW. SUB_PRODUCT_ID
,: NEW. CAMPAIGN_ID
,: NEW. MARKET_CELL_ID
,: NEW. ASSIGNED_OFFER_ID
,: NEW. ACCEPTED_OFFER_FLAG
,: NEW. CURRENT_OFFER_FLAG
,: NEW. OFFER_GOOD_UNTIL_DATE
,: NEW. RESCINDABLE_DAYS
,: NEW. RESCINDED_DATE
,: NEW. AMOUNT
,: NEW. MAX_AMOUNT
,: NEW. AMOUNT_FINANCED
,: NEW. DOWN_PYMT
,: NEW. RATE
,: NEW. TERM_MM
,: NEW. ORIGINATION_FEE_AMOUNT
,: NEW. ORIGINATION_FEE_RATE
,: NEW. FINANCE_CHARGE
,: NEW. NBR_OF_PYMTS
,: NEW. DATED THE
,: NEW. TOTAL_PYMTS
,: NEW. FIRST_PYMT_DATE
,: NEW. CONTRACT_DATE
, zcrypto.encrypt (: NEW.) ACCT_NBR)
,: NEW. ACCT_NBR_ASSIGNED_DTTM
, zcrypto.encrypt (: NEW.) ACCT_EXPIRATION_DTTM)
,: NEW. OFFER_DESC
,: NEW. TIMEOUTMIN_RATE
,: NEW. MAX_RATE
,: NEW. MIN_AMOUNT
,: NEW. ANNUAL_FEE_AMOUNT
,: NEW. ANNUAL_FEE_WAIVED_MM
,: NEW. LATE_FEE_PERCENT
,: NEW. LATE_FEE_MIN_AMOUNT
,: NEW. OFFER_SALES_SCRIPT
,: NEW. OFFER_ORDER
,: NEW. PRESENTABLE_FLAG
,: NEW. INDEX_RATE
,: NEW. ACTV_FLAG
,: NEW. CORRELATION_ID
,: NEW. OFFER_STATUS_TYPE_CD
, zcrypto.encrypt (: NEW.) PRESENTATION_INSTRUMENT_NBR)
);
ON THE OTHER
UPDATE
OFFER$
SET
DECISION_ID =: NEW. DECISION_ID
, OFFER_TYPE_CD =: NEW. OFFER_TYPE_CD
, PROMO_ID =: NEW. PROMO_ID
, PYMT_METHOD_TYPE_CD =: NEW. PYMT_METHOD_TYPE_CD
, CS_RESULT_ID =: NEW.CS_RESULT_ID
, CS_RESULT_USAGE_TYPE_CD =: NEW.CS_RESULT_USAGE_TYPE_CD
, RATE_INDEX_TYPE_CD =: NEW. RATE_INDEX_TYPE_CD
, SUB_PRODUCT_ID =: NEW. SUB_PRODUCT_ID
, = CAMPAIGN_ID: NEW. CAMPAIGN_ID
, MARKET_CELL_ID =: NEW. MARKET_CELL_ID
, ASSIGNED_OFFER_ID =: NEW. ASSIGNED_OFFER_ID
, ACCEPTED_OFFER_FLAG =: NEW. ACCEPTED_OFFER_FLAG
, CURRENT_OFFER_FLAG =: NEW. CURRENT_OFFER_FLAG
, OFFER_GOOD_UNTIL_DATE =: NEW. OFFER_GOOD_UNTIL_DATE
, RESCINDABLE_DAYS =: NEW. RESCINDABLE_DAYS
, RESCINDED_DATE =: NEW. RESCINDED_DATE
, QUANTITY =: NEW. AMOUNT
, MAX_AMOUNT =: NEW. MAX_AMOUNT
, AMOUNT_FINANCED =: NEW. AMOUNT_FINANCED
, DOWN_PYMT =: NEW. DOWN_PYMT
,RATE = :NEW. RATE
, TERM_MM =: NEW. TERM_MM
, ORIGINATION_FEE_AMOUNT =: NEW. ORIGINATION_FEE_AMOUNT
, ORIGINATION_FEE_RATE =: NEW. ORIGINATION_FEE_RATE
, FINANCE_CHARGE =: NEW. FINANCE_CHARGE
, NBR_OF_PYMTS =: NEW. NBR_OF_PYMTS
,PYMT = :NEW. DATED THE
, TOTAL_PYMTS =: NEW. TOTAL_PYMTS
, FIRST_PYMT_DATE =: NEW. FIRST_PYMT_DATE
, CONTRACT_DATE =: NEW. CONTRACT_DATE
, ACCT_NBR$ = zcrypto.encrypt (: NEW.) ACCT_NBR)
, ACCT_NBR_ASSIGNED_DTTM =: NEW. ACCT_NBR_ASSIGNED_DTTM
, ACCT_EXPIRATION_DTTM$ = zcrypto.encrypt (: NEW.) ACCT_EXPIRATION_DTTM)
, OFFER_DESC =: NEW. OFFER_DESC
, TIMEOUTMIN_RATE =: NEW. TIMEOUTMIN_RATE
, MAX_RATE =: NEW. MAX_RATE
, MIN_AMOUNT =: NEW. MIN_AMOUNT
, ANNUAL_FEE_AMOUNT =: NEW. ANNUAL_FEE_AMOUNT
, ANNUAL_FEE_WAIVED_MM =: NEW. ANNUAL_FEE_WAIVED_MM
, LATE_FEE_PERCENT =: NEW. LATE_FEE_PERCENT
, LATE_FEE_MIN_AMOUNT =: NEW. LATE_FEE_MIN_AMOUNT
, OFFER_SALES_SCRIPT =: NEW. OFFER_SALES_SCRIPT
, OFFER_ORDER =: NEW. OFFER_ORDER
, PRESENTABLE_FLAG =: NEW. PRESENTABLE_FLAG
, INDEX_RATE =: NEW. INDEX_RATE
, ACTV_FLAG =: NEW. ACTV_FLAG
, CORRELATION_ID =: NEW. CORRELATION_ID
, OFFER_STATUS_TYPE_CD =: NEW. OFFER_STATUS_TYPE_CD
, PRESENTATION_INSTRUMENT_NBR$ = zcrypto.encrypt (: NEW.) PRESENTATION_INSTRUMENT_NBR)
WHERE
OFFER_ID =: NEW. OFFER_ID;
END IF;
END;
/
zsysdba wrote:
I need help to understand why Oracle 11.2.0.3 is an index for an editable view. When I refer to the base table, offer$, I access index. When I reference the view, offer, I get a comprehensive analysis of the offer$. There's a trigger on the view instead. Who is factor in there somehow?
Almost certainly.
Even if the view has not used the calls to the function and the trigger was simply "null;" as the body, the presence of the trigger seems to prevent the optimizer to push the subquery view internal and down to the index (and there is no change in 12 c).
Concerning
Jonathan Lewis
-
tablespace as defined in the model of the index is not used for manually defined indexes
Hello
in the 4.0.1.836 version, I defined under model in Modeler, model, physics, use index of preferences / Data (I use the German version, I hope that I have translated correctly) an index template that contains a value for the attribute tablespace.
For indexes that are generated automatically (as defined in the properties of my model under the generation of index DDL/auto/properties") it works fine. There was a thread on this already . It works very well. However, for indexes that manually in a table there is no tablespace clause in the generated ddl script generated. Is this a bug or am I missing something?
Thanks for your help,
Jochen
Hello Jochen,
Yes. You are right. For manually defined indexes, the Index model is applied when the Index is created in the first place. As these properties are in the physical model, it is only effective if the relevant physical model is open when the Index is created in the first place. The Tablespace defined in the template is applied only if the physical model contains a Tablespace with the same name.
I guess it's a bit inconsistent for the automatically generated index Tablespace clause is generated when the physical model is not open.
David
-
Performance problem - Index is not used when a string of zero padded is queried
Hi all
I have a table T1 that has many columns. One such column C1 is a varchar2 (20). T1 has 10 million rows and there is an index I1 called C1. His stats are updated for tables and indexes. Here are the scenarios:
Is there a reason for this problem of performance? Why the optimizer goes for FTS in scenario 3?Scenario 1 select * from T1 where C1 = '0013206263' --Uses index I1 187 ms Scenario 2 select * from T1 where C1 = '8177341863' --Uses index I1 203 ms *Scenario 3* *select * from T1 where C1 = '0000000945' --Uses Fulll Table Scan --Very Slow* *45 seconds* When I force the sql to use the index through a hint, it is working fine: Scenario 4 select /*+ INDEX (t1 i1) */ * from T1 where C1 = '0013206263' --Uses index I1 123 ms Scenario 5 select /*+ INDEX (t1 i1) */ * from T1 where C1 = '8177341863' --Uses index I1 201 ms *Scenario 6* *select /*+ INDEX (t1 i1) */ * from T1 where C1 = '0000000945' --Uses index I1* *172ms*
Published by: user539954 on May 14, 2009 12:22
Published by: user539954 on May 14, 2009 12:32user539954 wrote:
one) says user_tab_histograms on the histogram on the column
-Online there are about 250 lines for this query (varies from between 0 and 254 endpoint_number)
Select * from user_tab_histograms where column_name like 'C1' and table_name like 'T1 '.It's balanced height histogram - by default in 10g if you do not deliberately block histograms you get histograms.
>
(b) If you "set autotrace traceonly explain' and run the queries a bit do you can predictions of a few lines for most of the values, but the predictions of a large number of lines when the value begins with zero, one or more zeros.
=> working on this now because there is a power outage nowNo need, your response to Justin provided examples which proved the point.
If you expect always a few lines for all values of this column then you must ensure that this histogram does not builds. To avoid histograms in general, you must specify method_opt like 'for all columns size 1' in the call to dbms_stats.gather_table_stats; and don't forget that in 10g, you get an automatic job working at 22:00 that could remember his stats because he thinks that current statistics have gone stale.Concerning
Jonathan Lewis
http://jonathanlewis.WordPress.com
http://www.jlcomp.demon.co.UK"Science is more than a body of knowledge; It's a way of thinking. "
Carl Sagan -
DB worm 11.2.03
We have rebuillt a large table (229,952,143 lines) from a backup in our dev, test environments and living, then the table is about the same in all three. Same structure, indexes and data compression.
However on the issue of the same query in all three envs, in that the index is ignored direct when used in dev and test.
We have compared the structure of the table and the content using Toad and can see no difference.
What do we lack?
Have you checked the statistics on tables and indexes?
-
Why index is not used by the subquery?
Hello
ENV: 11 GR 2 on Linux Oracle 5.8 64 bit on file system,
I have the following query:
Select * to processing_instruction pi where pi.last_updated = (select / * + index (idx_pi_client_merchant_status FT2) * / max (pi2.last_updated))
to processing_instruction FT2
where pi2.client_no = pi.client_no
and pi2.merchant_id = pi.merchant_id
and pi2.status = 'C')
I created an index:
CREATE INDEXES TO PROCESSING_INSTRUCTION IDX_PI_CLIENT_MERCHANT_STATUS
(CLIENT_NO, MERCHANT_ID, STATUS)
Oracle still does a full-table scan on the ' processing_instruction FT2 ' table (subquery) even though I also put the indicator INDEX.» The table has rows '55621245 '. There are several lines for a given client_no, the merchant_id and status 'C '. I want to only choose one that has been updated the last (newest one).
I'm sure there may be a better way to do this, but...
Please notify.
Concerning
the order of the keys, and the columns questions
Try (status, last_updated)
-
Query is not using the index. (Included execution plan. TKPROF output not available)
Hi all
Version of DB: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
Here is the description of the problem:
(The statistics are up to date for all tables).
The query below does not use the index on ACCOUNTS_LIVE (ID). (Unique index)
Line 23 of the query uses accounts_live.id.SQL> explain plan for 2 select txn.account_number,to_number(txn.amount_lcy) txn_amt,to_date(booking_date,'YYYYMMDD') TXN_DATE, 3 sal.latest_sal,sal.sal_date,customer_name,employer_name, 4 decode(COMMUNICATION_TYPE_1,'MOBILE',COMMUNICATION_NO_1, 5 decode(COMMUNICATION_TYPE_2,'MOBILE',COMMUNICATION_NO_2)) mob, 6 txn.CURRENCY, CHEQUE_NUMBER,trans_dets,trans_reference,target,teller_id,acc.category,acc.inactive_marker, 7 acc.posting_restrict,cus.sector,cus.industry 8 from coreadmin.Gtxn_dtl_v1 txn, 9 (select account_number,round(to_number(nvl(amount_lcy,0)),2) latest_sal,TXN_DATE sal_date,rr 10 from 11 (select to_date(booking_date,'YYYYMMDD') TXN_DATE,batch_id,account_number,amount_lcy 12 ,row_number() over (partition by account_number 13 order by to_date(booking_date,'YYYYMMDD') desc NULLS LAST, 14 batch_id desc nulls last) rr, 15 CURRENCY, CHEQUE_NUMBER,trans_dets,trans_reference 16 from coreadmin.Gtxn_dtl_v1 17 where transaction_code in ('204','938') 18 and to_number(amount_lcy) > 0) 19 where rr = 1 20 ) sal,accounts_live acc,customers_live cus 21 where to_date(booking_date,'YYYYMMDD') between to_date('030109','DDMMRR') and to_date('020209','DDMMRR') 22 and txn.account_number = sal.account_number 23 and txn.account_number = acc.id 24 and txn.CUSTOMER_ID = cus.CUSTOMER_number 25 and target in ('30','31','32') 26 / Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------------------------------------ Plan hash value: 920245766 ----------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | ----------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 363M| 121G| | 223K (4)| 00:44:47 | |* 1 | HASH JOIN | | 363M| 121G| 6232K| 223K (4)| 00:44:47 | |* 2 | VIEW | | 34453 | 5820K| | 147K (1)| 00:29:36 | |* 3 | WINDOW SORT PUSHED RANK | | 34453 | 1480K| 4072K| 147K (1)| 00:29:36 | |* 4 | FILTER | | | | | | | | 5 | INLIST ITERATOR | | | | | | | |* 6 | TABLE ACCESS BY INDEX ROWID| GTXN_DTL_V1 | 34453 | 1480K| | 147K (1)| 00:29:31 | |* 7 | INDEX RANGE SCAN | IDX_TXN5 | 707K| | | 1815 (2)| 00:00:22 | |* 8 | HASH JOIN | | 598K| 106M| 20M| 63724 (1)| 00:12:45 | |* 9 | MAT_VIEW ACCESS FULL | CUSTOMERS_LIVE | 227K| 17M| | 2239 (4)| 00:00:27 | |* 10 | HASH JOIN | | 598K| 59M| 9504K| 57157 (1)| 00:11:26 | | 11 | MAT_VIEW ACCESS FULL | ACCOUNTS_LIVE | 249K| 6577K| | 1832 (2)| 00:00:22 | |* 12 | TABLE ACCESS BY INDEX ROWID | GTXN_DTL_V1 | 597K| 43M| | 52319 (1)| 00:10:28 | |* 13 | INDEX RANGE SCAN | IDX_TXN11_V1 | 1204K| | | 3931 (2)| 00:00:48 | ----------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("TXN"."ACCOUNT_NUMBER"="ACCOUNT_NUMBER") 2 - filter("RR"=1) 3 - filter(ROW_NUMBER() OVER ( PARTITION BY "ACCOUNT_NUMBER" ORDER BY TO_DATE("BOOKING_DATE",'YYYYMMDD') DESC NULLS LAST,INTERNAL_FUNCTION("BATCH_ID") DESC NULLS LAST)<=1) 4 - filter(TO_DATE('030109','DDMMRR')<=TO_DATE('020209','DDMMRR')) 6 - filter(TO_NUMBER("AMOUNT_LCY")>0) 7 - access("TRANSACTION_CODE"='204' OR "TRANSACTION_CODE"='938') 8 - access("TXN"."CUSTOMER_ID"="CUS"."CUSTOMER_NUMBER") 9 - filter("TARGET"='30' OR "TARGET"='31' OR "TARGET"='32') 10 - access("TXN"."ACCOUNT_NUMBER"="ACC"."ID") 12 - filter("TXN"."CUSTOMER_ID" IS NOT NULL) 13 - access(TO_DATE("BOOKING_DATE",'YYYYMMDD')>=TO_DATE('030109','DDMMRR') AND TO_DATE("BOOKING_DATE",'YYYYMMDD')<=TO_DATE('020209','DDMMRR')) 38 rows selected. SQL> select index_name 2 from dba_ind_columns 3 where table_name = 'ACCOUNTS_LIVE' 4 and column_name = 'ID'; INDEX_NAME ------------------------------ IDX_ACCLIVE
11 the order ID explain plan shows that the index does not use.
Please suggest.
Thanks in advance,
JacWhat happens when you force the index by using hint and use the hash between txn and acc join?
See you soon
Sarma. -
Structured XMLIndex not used by the query
Hello
We try to use XMLIndexes structured for a query. But they are not used. A sample of similar work is as follows:
-Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit ProductionExample of XML data on the XMLTYPE column is:
<?xml version="1.0" encoding="UTF-8" standalone='yes'?> <abc:tagOne preparationTime="2012-10-17T13:01:23.000Z" schemaVersion="1.3.9.0" xsi:schemaLocation="" xmlns:def="DEF" xmlns:abc="ABC" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <def:tagTwo> <def:tagThree id="Identity1"> <def:Section domain="Domain123">10000</def:Section> </def:tagThree> <def:tagThree id="Identity2"> <def:Section domain="Domain123">20000</def:Section> </def:tagThree> <def:tagThree id="Identity3"> <def:Section domain="Domain123">30000</def:Section> </def:tagThree> <def:tagThree id="Identity4"> <def:Section domain="Domain123">40000</def:Section> </def:tagThree> </def:tagTwo> </abc:tagOne>
Query is like:select XMLAGG(XML_MESSAGE) from INT_PART_TABLE where XMLExists(' declare namespace abc="ABC"; declare namespace def="DEF"; $Message/abc:tagOne/def:tagTwo/def:tagThree[@id="Identity4"][def:Section[@domain="Domain123"] = ("50000", "40000") ]' passing xML_mESSAGE as "Message" )
We try to create indexes structured on the column of xmltype, as defined in the XML example file:CREATE INDEX INT_PART_TABLE_SXI ON INT_PART_TABLE (XML_MESSAGE) INDEXTYPE IS XDB.XMLINDEX PARAMETERS ('XMLTABLE INT_PART_content_table_01 XMLNAMESPACES (''ABC'' AS "abc", ''DEF'' AS "def"), ''/abc:tagOne/def:tagTwo'' COLUMNS xmltagTwo XMLTYPE PATH ''/abc:tagOne/def:tagTwo'' VIRTUAL XMLTABLE INT_PART_content_table_02 XMLNAMESPACES (''DEF'' AS "def"), ''/def:tagTwo'' PASSING xmltagTwo COLUMNS xmltagThree XMLTYPE PATH ''/def:tagThree'' VIRTUAL XMLTABLE INT_PART_content_table_03 XMLNAMESPACES (''DEF'' AS "def"), ''/def:tagThree'' PASSING xmltagThree COLUMNS section number PATH ''def:Section'', domain varchar2(20) PATH ''@domain'', id varchar2(20) PATH ''@id'' ')local;Table structure:
CREATE TABLE INT_PART_TABLE ( DB_ID VARCHAR2 (10 BYTE), xML_mESSAGE SYS.XMLTYPE, LOAD_TIMESTAMP TIMESTAMP (6) ) XMLTYPE xML_mESSAGE STORE AS BINARY XML (ENABLE STORAGE IN ROW CHUNK 16384 RETENTION CACHE READS NOLOGGING) ALLOW NONSCHEMA DISALLOW ANYSCHEMA PCTUSED 0 PCTFREE 10 INITRANS 1 MAXTRANS 255 STORAGE (BUFFER_POOL DEFAULT) PARTITION BY RANGE (LOAD_TIMESTAMP) (PARTITION P_12092012 VALUES LESS THAN (TIMESTAMP ' 2012-09-12 00:00:00') LOGGING NOCOMPRESS PCTFREE 10 INITRANS 1 MAXTRANS 255 STORAGE (INITIAL 512 K NEXT 512 K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0 BUFFER_POOL DEFAULT), PARTITION MAX VALUES LESS THAN (MAXVALUE) LOGGING NOCOMPRESS PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE (INITIAL 128 K NEXT 128 K MINEXTENTS 1 MAXEXTENTS UNLIMITED PCTINCREASE 0 BUFFER_POOL DEFAULT)) PARALLEL (DEGREE 8 INSTANCES 1);
- But the query above does not use the XMLINDEX STRUCTURE and instead turns to FTS INT_PART_TABLE. Please help here.
Is it the wrong way I created structured Index.
(I tried a few other ways where I got-> ORA-19279: XPTY0004 - dynamic XQuery type mismatch: expected - singleton sequence got several sequence element).
S ' Please NOTE that I used two "VIRTUAL" during the creation of the Index as otherwise I was getting the error:
ORA-29958: fatal error occurred in the execution of routine ODCIINDEXCREATE
ORA-30984: the XMLType column must be declared as virtualPlease suggest. Thank you.
Finally some time to watch this...
The following works for me:
Connected to:
Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit Production
With partitioning, OLAP, Data Mining and Real Application Testing options
SQL > create table (int_part_table)
2 db_id varchar2 (10 byte)
3, xml_message xmltype
4, load_timestamp timestamp (6)
5)
store xml_message 6 xmltype to the binary xml format
7 partition by range (load_timestamp)
() 8
9 lower values p_12092012 partition to (to_timestamp ('2012-09-12 00:00:00 ',' YYYY-MM-DD HH24:MI:SS'))))
10, partition p_max values less than (maxvalue)
11)
12 parallel (degree 8 instances 1);
Table created.
SQL > create index int_part_table_sxi on int_part_table (xml_message)
2 indextype is xdb.xmlindex
3 rooms
4 parameters (q'~)
5 XMLTABLE int_part_content_table_01
6 XMLNAMESPACES ('ABC' AS 'abc', 'DEF' AS 'def'),
7 ' / abc: Tallet / def:tagTwo / def:tagThree'
8 COLUMNS
9 article binary_double PATH 'def:Section '.
10, area varchar2 (20) PATH 'def:Section/@domain '.
11, id varchar2 (20) PATH '@id '.
12 ~');
The index is created.
SQL >
SQL >
SQL > insert into int_part_table values)
2 '1'
3, xmltype (')
4
' NS:ABC = 'ABC' xmlns: xsi = "http://www.w3.org/2001/XMLSchema-instance" > ".
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 ')
20, systimestamp
(21);
1 line of creation.
SQL > commit;
Validation complete.
SQL > exec dbms_stats.gather_table_stats (user, 'INT_PART_TABLE');
PL/SQL procedure successfully completed.
SQL >
SQL >
SQL > set autotrace traceonly explain
SQL > set lines 200
SQL > define pages 100
SQL >
SQL > select / * + no_parallel * / xml_message
2 of int_part_table
3 where (XMLExists)
4 ' declare namespace abc = "ABC"; (::)
5 declare def namespace = "DEF"; (::)
/ABC:tagOne/def:tagTwo/def:tagThree[@ID="Identity4 6 '.
7 and def:Section/@domain="Domain123.
8 and (def:Section = 40000
9 or def:Section = 50000)]"
10 passage xml_message
11 ) ;
Execution plan
----------------------------------------------------------
Hash value of plan: 3112612945
---------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
---------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 417. 15 (0) | 00:00:01 | | |
| 1. SEMI NESTED LOOPS. | 1. 417. 15 (0) | 00:00:01 | | |
| 2. RANGE OF PARTITION ALL THE | | 1. 367. 14 (0) | 00:00:01 | 1. 2.
| 3. TABLE ACCESS FULL | INT_PART_TABLE | 1. 367. 14 (0) | 00:00:01 | 1. 2.
| 4. ITERATOR SYSTEM PARTITION. | 1. 50. 1 (0) | 00:00:01 | KEY | KEY |
|* 5 | TABLE ACCESS BY LOCAL INDEX ROWID | INT_PART_CONTENT_TABLE_01 | 1. 50. 1 (0) | 00:00:01 | KEY | KEY |
|* 6 | INDEX RANGE SCAN | SYS78560_78563_RID_IDX | 1. | 0 (0) | 00:00:01 | KEY | KEY |
---------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
5 - filter("SYS_SXI_0".") ID "="Identity4"AND ("SYS_SXI_0"". ")" SECTION "IS 4.0E + 004 D OR 'SYS_SXI_0'." SECTION "(= 5.0E + 004 D) AND"
'SYS_SXI_0 '. ("DOMAIN"="Domain123")
6 - access ("INT_PART_TABLE". ROWID = "SYS_SXI_0." ("' RID ')
filter (TBL$ OR$ IDX$ PART$ NUM ("DEV".) "INT_PART_TABLE", 0,0,0, "INT_PART_TABLE". ROWID) TBL = $ OR$ IDX$ PART$ NUM ("DEV". "INT_PAR
T_CONTENT_TABLE_01", 0,0,0,"SYS_SXI_0. " ROWID))
A few things to know:
-use BINARY_DOUBLE datatype to untyped (i.e. not based on a diagram) the numerical values of the XML index.
-J' developed the sequence iterator predicate you were using for a Boolean expression GOLD. Otherwise, the index is not used as intended.
You can also create a secondary index that satisfies the predicate #5 (see red part above):
SQL > create index int_part_content_table_01_ix1
2 on local int_part_content_table_01 (id, field, section);
The index is created.
SQL >
SQL > select / * + no_parallel * / xml_message
2 of int_part_table
3 where (XMLExists)
4 ' declare namespace abc = "ABC"; (::)
5 declare def namespace = "DEF"; (::)
/ABC:tagOne/def:tagTwo/def:tagThree[@ID="Identity4 6 '.
7 and def:Section/@domain="Domain123.
8 and (def:Section = 40000
9 or def:Section = 50000)]"
10 passage xml_message
11 ) ;
Execution plan
----------------------------------------------------------
Hash value of plan: 3704965392
--------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |
--------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. 417. 4 (25) | 00:00:01 | | |
| 1. NESTED LOOPS | | 1. 417. 4 (25) | 00:00:01 | | |
| 2. UNIQUE FATE | | 2. 100. 2 (0) | 00:00:01 | | |
| 3. SYSTEM PARTITION ALL | | 2. 100. 2 (0) | 00:00:01 | 1. 2.
| 4. TABLE ACCESS BY LOCAL INDEX ROWID | INT_PART_CONTENT_TABLE_01 | 2. 100. 2 (0) | 00:00:01 | 1. 2.
|* 5 | INDEX RANGE SCAN | INT_PART_CONTENT_TABLE_01_IX1 | 1. | 1 (0) | 00:00:01 | 1. 2.
|* 6 | TABLE ACCESS BY ROWID USER | INT_PART_TABLE | 1. 367. 1 (0) | 00:00:01 | ROWID | ROWID |
--------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
5 - access("SYS_SXI_0".") ID '= 'Identity4' AND 'SYS_SXI_0'." DOMAIN "=" Domain123 ")
filter ("SYS_SXI_0". "SECTION"IS 4.0E + 004 D OR 'SYS_SXI_0'." SECTION "(= 5.0E + 004 D)"
6 filter (TBL$ OR$ IDX$ PART$ NUM ("DEV".) "INT_PART_TABLE", 0,0,0, "INT_PART_TABLE". ROWID) TBL = $ OR$ IDX$ PART$ NUM ("DEV". "INT_PART_CON
TENT_TABLE_01", 0,0,0,"SYS_SXI_0. " ROWID))
-
View does not use index Mview underlying but mview uses indexes
Hello
I faced a situation where, while querying data to display based on mview does not use the index, but when we wonder of mview it uses index and produce quick results.
Here are the details:
querying from view: (completes in more than a minute even after passing hint) ================================ explain plan for select /*+ index( ITGI_CREDITOR_LEDGER_CMV ITGI_CREDITOR_LEDGER_INDX) */ * from CR_LEDGER_REP_V where vendor_id='1474911'; Plan hash value: 463951623 --------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 9056K| 5648M| 97644 (1)| 00:00:04 | |* 1 | VIEW | CR_LEDGER_REP_V | 9056K| 5648M| 97644 (1)| 00:00:04 | | 2 | COUNT | | | | | | | 3 | MAT_VIEW ACCESS FULL| ITGI_CREDITOR_LEDGER_CMV | 9056K| 2159M| 97644 (1)| 00:00:04 | --------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("VENDOR_ID"=1474911) Querying from mview: (completes within a second) ============================== explain plan for select /*+ index( ITGI_CREDITOR_LEDGER_CMV ITGI_CREDITOR_LEDGER_INDX) */ * from ITGI_CREDITOR_LEDGER_CMV where vendor_id='1474911'; Plan hash value: 1726512073 -------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 21 | 5880 | 21 (0)| 00:00:01 | | 1 | MAT_VIEW ACCESS BY INDEX ROWID BATCHED| ITGI_CREDITOR_LEDGER_CMV | 21 | 5880 | 21 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | ITGI_CREDITOR_LEDGER_INDX | 22 | | 3 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("VENDOR_ID"=1474911) View DDL ======================== CREATE OR REPLACE FORCE VIEW SANJAY.CR_LEDGER_REP_V ( QRY, SR_NO, VENDOR_ID, VENDOR_TYPE, VENDOR_NUMBER, VENDOR_NAME, VENDOR_SITE_ID, VENDOR_SITE_CODE, GL_DATE, ACCOUNTING_DATE, PO, INVOICE_TYPE, AP_INVOICE_NO, INVOICE_DOC_CAT, AP_INVOICE_DATE, INVOICE_VOUCHER_NO, PAYMENT_VOUCHER_NO, CHQ_NO, DESCRIPTION, PAYMENT_DATE, ACC_CODE, PAYMENT_METHOD, CURR_CODE, DEBIT, CREDIT ) AS SELECT qry, ROWNUM srn, vendor_id, vendor_type_lookup_code, vendor_no, vendor_name, vendor_site_id, vendor_site_code, gl_date, accounting_date, po_distribution_id, invoice_type_lookup_code, invoice_num, doc_category_code, invoice_date, inv_voucher_num, payment_num, check_number, description, pay_accounting_date, account_code, payment_method_code, invoice_currency_code, debit, credit FROM sanjay.itgi_creditor_ledger_cmv;The plan does not change even if I do not use advice.
Although I said developer to use mview directly, but I did not understand this behavior.
DB version: 12.1
OPERATING SYSTEM: AIX 6.1
Kind regards
Gerard
Note that the query on the view plan is only to apply your filter predicates on line 1, rather than against the mview in line 3. Line 2 said you that enforcement must correspond to a kind of County before it can filter which is due to the virtual rownum in your point of view.
You need this column? In my opinion, it's meaningless. Remove the column from the view would mean that the view doesn't have to be assessed in its entirety (if not, how it will calculate rownums?) before allowing you to filter. You asked the developer to implement the work is likely to come with a different value of sr_no (if the developer is even using it?) than what he would have obtained by using the view.
The column tries to catch a unique key for the view? Are you aware that rownum values can and will change between requests to the same table as the order lines are selected is not guaranteed. If the column is actually useful (and it is correct to calculate at this level) you then could it sense it is calculated inside the mview? This means that you can only refresh the mview completely and rownum values can (and will) only change on refresh.
-
NLSSORT function not used with CHAR and VARCHAR2 column index
Hello!
Create a test bench:
Now "explain plan" these 8 select statements in SQL * more:CREATE TABLE scott.nls_demo ( col_varchar varchar2(4), col_char char(4), col_varchar_NLS_GERMAN varchar2(4), col_char_NLS_GERMAN char(4) ); INSERT INTO scott.nls_demo ( col_varchar, col_char, col_varchar_NLS_GERMAN, col_char_NLS_GERMAN ) SELECT substr(object_name,1,4), substr(object_name,1,4), substr(object_name,1,4), substr(object_name,1,4) FROM all_objects where rownum<5000; COMMIT; create index scott.i_varchar on scott.nls_demo (col_varchar); create index scott.i_char on scott.nls_demo (col_char); create index scott.i_varchar_NLS_GERMAN on scott.nls_demo ( NLSSORT(col_varchar_NLS_GERMAN,'nls_sort=''GERMAN_CI''')); create index scott.i_char_NLS_GERMAN on scott.nls_demo ( NLSSORT(col_char_NLS_GERMAN, 'nls_sort=''GERMAN_CI'''));
What I see on 11.2.0.2 is:variable c char(4); variable v varchar2(4); exec :c:= 'abc'; exec :v:= 'abc'; explain plan for SELECT /* 1*/ * FROM scott.nls_demo where col_varchar=:v; SELECT * FROM TABLE(dbms_xplan.display); explain plan for SELECT /* 2*/ * FROM scott.nls_demo where col_char=:c; SELECT * FROM TABLE(dbms_xplan.display); explain plan for SELECT /* 3*/ * FROM scott.nls_demo where col_varchar_NLS_GERMAN=:v; SELECT * FROM TABLE(dbms_xplan.display); explain plan for SELECT /* 4*/ * FROM scott.nls_demo where col_char_NLS_GERMAN=:c; SELECT * FROM TABLE(dbms_xplan.display); ALTER SESSION SET NLS_COMP = linguistic; ALTER SESSION SET NLS_SORT = german_ci; explain plan for SELECT /* 5*/ * FROM scott.nls_demo where col_varchar=:v; SELECT * FROM TABLE(dbms_xplan.display); explain plan for SELECT /* 6*/ * FROM scott.nls_demo where col_char=:c; SELECT * FROM TABLE(dbms_xplan.display); explain plan for SELECT /* 7*/ * FROM scott.nls_demo where col_varchar_NLS_GERMAN=:v; SELECT * FROM TABLE(dbms_xplan.display); explain plan for SELECT /* 8*/ * FROM scott.nls_demo where col_char_NLS_GERMAN=:c; SELECT * FROM TABLE(dbms_xplan.display);
1.) statement 1 would use the I_VARCHAR index, that is what I expected.
2.) statement 2 would use the I_CHAR index, that is what I expected.
3.) no clue used, because none are available right here for you. Understood.
4.) no clue used, because none are available right here for you. Understood.
And when define us NLS_SORT = german_ci:
5.) no clue used, because none are available right here for you. Understood.
6.) no clue used, because none are available right here for you. Understood.
7.) I_VARCHAR_NLS_GERMAN we used. Large.
8.) no index used, although I think that "i_char_NLS_GERMAN" would do the job...
Why the index 'i_char_NLS_GERMAN' is not used with the 8 statement? Jonathan? Someone else?
Thanks for your help!
MarcusNot really a reason to not use TANK - although there are many of them.
More than one reason to not always rely to "explain the plan for?
All the variables passed in EXPLAINING the PLAN for are treated as VARCHAR2.
In addition, there is no point setting the values of the variable because they will not cast a look either with MAP to EXPLAIN.SQL> CREATE TABLE nls_demo 2 ( 3 col_varchar varchar2(4), 4 col_char char(4), 5 col_varchar_NLS_GERMAN varchar2(4), 6 col_char_NLS_GERMAN char(4) 7 ); Table created. SQL> SQL> INSERT INTO nls_demo ( 2 col_varchar, 3 col_char, 4 col_varchar_NLS_GERMAN, 5 col_char_NLS_GERMAN ) 6 SELECT 7 substr(object_name,1,4), 8 substr(object_name,1,4), 9 substr(object_name,1,4), 10 substr(object_name,1,4) 11 FROM all_objects where rownum<5000; 4999 rows created. SQL> SQL> commit; Commit complete. SQL> SQL> create index i_varchar on nls_demo (col_varchar); Index created. SQL> create index i_char on nls_demo (col_char); Index created. SQL> SQL> create index i_varchar_NLS_GERMAN on nls_demo ( NLSSORT(col_varchar_NLS_GERMAN,'nls_sort=''GERM AN_CI''')); Index created. SQL> create index i_char_NLS_GERMAN on nls_demo ( NLSSORT(col_char_NLS_GERMAN, 'nls_sort=''GERM AN_CI''')); Index created. SQL> SQL> variable c char(4); SQL> variable v varchar2(4); SQL> SQL> exec :c:= 'abc'; PL/SQL procedure successfully completed. SQL> exec :v:= 'abc'; PL/SQL procedure successfully completed. SQL> SQL> ALTER SESSION SET NLS_COMP = linguistic; Session altered. SQL> ALTER SESSION SET NLS_SORT = german_ci; Session altered. SQL> SQL> SELECT /* 8*/ * FROM nls_demo where col_char_NLS_GERMAN=:c; no rows selected SQL> SELECT * FROM TABLE(dbms_xplan.display_cursor); PLAN_TABLE_OUTPUT ---------------------------------------------------------------------------------------------------- SQL_ID 9su0j5vzuwzyj, child number 0 ------------------------------------- SELECT /* 8*/ * FROM nls_demo where col_char_NLS_GERMAN=:c Plan hash value: 2830339923 ------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | 3 (100)| | | 1 | TABLE ACCESS BY INDEX ROWID| NLS_DEMO | 50 | 2150 | 3 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | I_CHAR_NLS_GERMAN | 20 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("NLS_DEMO"."SYS_NC00006$"=NLSSORT(:C,'nls_sort=''GERMAN_CI''')) Note ----- - dynamic sampling used for this statement (level=2) 23 rows selected. SQL>Published by: Dom Brooks on February 21, 2011 15:39
-
Why a method to create a constraint would allow the index to be used, but not another.
Hi all
With the help of:
Oracle Database 11 g Enterprise Edition Release 11.2.0.4.0 - 64 bit Production
SQL Developer Version 4.0.2.15
I had to do the following query on a table.
Select distinct chdrnum, tranno
of ractpf_pgr;
I ran the setup of SQL in SQL Developer, who told me that he was doing a full table scan,
(It's what you get using SEPARATE!)
After some research, I discovered that if I put in question on columns not null check constraints
and then recreated the index based on these columns, I'd get a full index scan instead of a table scan.
Good news - off, I went and tried using the following method (I think it's call a constraint of out-of-line)
and created one for each colmn using snytax below.
ALTER table RACTPF_PGR add constraint CS_CHDRNUM_NN check (CHDRNUM is not null) validate;
Ran my SQL Tuning Advisor again - no joy - a full table scan that was happening.
Did some more research and recreated the constraints with the help of an online method
ALTER TABLE RACTPF_PGR CHANGE (CHDRNUM CONSTRAINT CS_CHDRNUM_NN NOT NULL);
My SQL Tuning Advisor is represented - and yes the index was used.
But what I want to know why a method would cause the index to use another does not
Thanks in advance.
The second is a NOT NULL constraint.
The a ('is not null') is technically not a NOT NULL constraint.
Give me a moment to start my database, and I will demonstrate.
Edit: Here's the demo:
SQL> create table x (a number null, b number null); Table created. SQL> alter table x add constraint a_nn check(a is not null) validate; Table altered. SQL> alter table x modify (b constraint b_nn not null); Table altered. SQL> select column_name, nullable 2 from user_tab_cols 3 where table_name = 'X'; COLUMN_NAME ---------------------------------------------------------------------- N - B N A Y
The index does not store registrations for the lines where all components of the index are null, then the optimizer needs to see that the columns are not nullable to be able to use an index scan.
-
How we force a query to use transparently a hint, even if the index is not given in the query as a query rewriting.
For example:
If the user runs a query select deptno, avg (sal) from emp group by deptno;
We want the optimizer to use a hint of result_cache with this request, and it should be transparent to the user.
Query should be rewritten to seamlessly
Select / * + result_cache * / deptno, avg (sal)
WCP
Group of deptno;
How can this feature we make? Please advice.
I checked the possibility of SPM and contours, but it is not clear if this rewrite is possible here.
Thank you and best regards,
Vikas Krishna
Surely dbms_advanced_rewrite is designed for this situation?
-
Setting the query: optimizer does not use the index function
Hello
I have a request written by a developer that I can't change.
It is here that the condition:
OÙ ( UPPER(TRIM (CODFSC)) = UPPER (TRIM ( '01923980500'))
OR UPPER(TRIM (CODUIC)) = UPPER (TRIM ( '01923980500')))
There is an index on CODFSC and on CODUIC1.
the plan is:
Plan
INSTRUCTION SELECT ALL_ROWS cost: 9 194 bytes: 3 206 502 cardinality: 15 054
ACCESS FULL ANAGRAFICA cost TABLE TABLE 1: 9 194 bytes: 3 206 502 cardinality: 15 054
So I created two new index on SUPERIOR (TRIM ()CODFSC)) and SUPERIOR (TRIM ()CODUIC)) but the plan
complete analysis of STIL.
Modifing where condition in:
OÙ ( CODFSC = UPPER (TRIM ( '01923980500'))
OR CODUIC = UPPER (TRIM ( '01923980500')))
the plan is:
SELECT STATEMENT ALL_ROWSCost: 157 bytes: 426 cardinality: 2
CONCATENATION OF 5
TABLE ACCESS BY INDEX ROWID ANAGRAFICA cost TABLE 2: cardinality of 5 bytes: 213: 1
1 INDEX RANGE SCAN INDEX ANAGRAFICA_IDX01 cost: cardinality 3: 1
TABLE ACCESS BY INDEX ROWID ANAGRAFICA cost TABLE 4: cardinality 152 bytes: 213: 1
3 INDEX SKIP SCAN INDEX ANAGRAFICA_IDX02 cost: cardinality 1: 151
Why optimizer not use my funct index?
Thank you.
Franck,
I always forget that the default value for the GOLD expansion depends on a path indexed for each branch.
2 in your use of or_predicates (2) depends on the position of complex predicate which must be expanded. If you change the order of predicate 'State = 0' to display AFTER the complex predicate, you must change the indicator of "or_predicates (1).
Outside of the current state of undocumented indicator, it also introduces the disturbing thought that, for a more complex query, a change in the transformation may result in another set of query blocks generated with a different ranking of the predicates. Yet another case to ensure that if you suggest anything suggest you (or create a SQL database).
Concerning
Jonathan Lewis
-
Query not using Full Scan Index
Hello world
I'm on 11.2.0.3.0 AIX 6.1.
There is a query such as:
Select: sys_b_0 | Count (distinct (column_name)) table;
that goes for the analysis full table. The column was values separate only 104 with not NULL values. To save memory buffer gets, I created an index on the table with the column used in the query (i.e. whose distinct values are recovered).
The problem is that even after the creation of indexes and force the flag index that it does not use the full scan of the index. The provided indication is correct in syntax and was the only clue in the query, so there is no question of conflicts with others.
Can anyone suggest me what I might be missing?
Thank you
It seems to me that if print_branch_code is defined as nullable in the table. If this is the case, the optimizer goes for a sweep of index, even if there is no real NULL values
Maybe you are looking for
-
HDPM 4.5sp2 impossible to clone the image - 14031022
We are running 4.5 SP2 and try to clone a t610 wes7e most recent image (available). We have updated the agent on the TC and it corresponds to the note version 4.5 sp2 release. When we try to clone (using '_Capture image' with ' disable the filter of
-
I ran the system strengthened tool & then got a fix that installed but still, this update will not install, what.
-
Hi people. On my laptop, I have 2 drives, C, and E. both hold 72 GB of memory. Drive C went to the red zone. While my E drive has nothing in it. Drive E data available. Can I transfer stuff in the E drive to free up drive C. Best regards: P
-
"WindowsUpdate_80244019" "WindowsUpdate_dt000" errors and...?
Tried to update my computer (windows 7), but he could not. He gives me these errors: "WindowsUpdate_80244019" "WindowsUpdate_dt000" I tried searching on this Web site and Google it, found many solutions, but none of them worked. I was told to remove
-
The blackBerry Smartphones to app memory device memory
Is it possible to move some memory to memory app?