Estimating costs of materialized views
Does anyone know how to estimate the cost of materializing a view? Can you use explain for this?
Hi,
try to alter MV
http://download.oracle.com/docs/cd/B13789_01/server.101/b10759/statements_2001.htm#CCHECCJB
regards, michael
Similar Messages
-
Materialized views performance gain estimation
Hi;
I have to estimate the performance gain of a materialized view for a particular query without creating it.
that means, i have:
- A query with initial execution plan
- A select statement with is considered as a probable MV
i need to show what is the performance gain of creating the MV for the previous Query.
I see the DBMS_MVIEW.EXPLAIN_REWRITE but it shows the performance gain for a yet created MV.
any idea .
ThanksHi Bidi,
- for the first (agregation ones), i don't know how to estimate the performance gain.It's the difference in the elapsed time between the original aggregation and the time required to fetch the pre-computed summary, ususally a single logical I/O (if you index the MV).
i want to determinate the impact of creating materialized views on the performance of a workload of queries. Perfect! Real-world workload tests are always better than contrived test cases!
If you have the SQLAccess advisor, you can define a SQL Tuning Set, and run a representative benchmark with dbms_sqltune:
http://www.dba-oracle.com/t_dbms_sqltune.htm
Hope this helps. . .
Donald K. Burleson
Oracle Press author
Author of "Oracle Tuning: The Definitive Reference":
http://www.dba-oracle.com/bp/s_oracle_tuning_book.htm -
Refresh a materialized view in parallel
Hi,
To improve the refresh performance for a materialized view, I set up it to be refreshed in parallel. The view can be refreshed successfully, however, I did not see the view is refreshed in parallel from session browser, can someone let me know if I miss any steps?
1) In DB A (running 8 CPUs), set up the base table to be parallelized, the base table is called table1
ALTER TABLE A.table1 PARALLEL ( DEGREE Default INSTANCES Default );
2) In Database A, set up the materialized view log
CREATE MATERIALIZED VIEW LOG
ON table1 WITH primary key
INCLUDING NEW VALUES;
3) In Database B (in the same server with Database A), there is an existing table called table1, prebuilt with millions of records in the table. Due to the size of table1, I have to use prebuilt option
Drop MATERIALIZED VIEW table1;
CREATE MATERIALIZED VIEW table1 ON PREBUILT TABLE
REFRESH FAST with primary key
AS
select /*+ PARALLEL(table1, 8) */ *
from table1@A;
4) in Database B, I executed this stored procedure -
EXECUTE DBMS_MVIEW.REFRESH(LIST=>'table1',PARALLELISM=>8, METHOD=>'F');
Thanks in advance!
LizI checked the execution plan when I executed the refresh stored procedure again, Does the plan indicates the parallel execution is working or not?
SELECT STATEMENT REMOTE ALL_ROWSCost: 32,174 Bytes: 775,392 Cardinality: 1,182
13 PX COORDINATOR
12 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10001 :Q1001
11 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1001
9 NESTED LOOPS PARALLEL_COMBINED_WITH_PARENT :Q1001Cost: 32,174 Bytes: 775,392 Cardinality: 1,182
6 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD :Q1001
5 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT :Q1001
4 PX SEND ROUND-ROBIN PARALLEL_FROM_SERIAL SYS.:TQ10000 A
3 VIEW APP_USR. Cost: 12,986 Bytes: 6,070,196 Cardinality: 275,918
2 HASH UNIQUE Cost: 12,986 Bytes: 9,105,294 Cardinality: 275,918
1 TABLE ACCESS FULL TABLE A.MLOG$_TABLE1 A Cost: 10,518 Bytes: 9,105,294 Cardinality: 275,918
8 PARTITION RANGE ITERATOR PARALLEL_COMBINED_WITH_PARENT :Q1001Cost: 0 Cardinality: 1
7 INDEX RANGE SCAN INDEX (UNIQUE) PARALLEL_COMBINED_WITH_PARENT A.PK_TABLE1 :Q1001Cost: 0 Cardinality: 1
10 TABLE ACCESS BY LOCAL INDEX ROWID TABLE PARALLEL_COMBINED_WITH_PARENT A.TABLE1 :Q1001Cost: 0 Bytes: 634 Cardinality: 1 -
Materialized view is not taking the Index
Hi Friends,
I have a materialized View for my Sales Details. I created a view on the Materialized View and using in my report. The Performance is very slow. After little research,
I found that the indexes are not used when the MV is accessed in the SQL. I tried explain plan for a very simple query on the view to prove that.
Here is my simple query.
select month_num ,sum(qty) from v_mv_sales_table
where month_num=201301
by month_num;
When I checked for count() it is considering the index and performance is good.
select month_num ,count(*) from v_mv_sales_table
where month_num=201301
by month_num;
Then I tried using hint for forcing the index. That time also it is working only for count not for SUM.
select /* +INDEX(tr, IDX2_MV_SALES_TABLE) */ month_num,count(*)
v_mv_sales_table tr
month_num=201301
by month_num;
Is there any way , I can force my sql to use the index on the month_num column?.
I have a question about using hint to force the sql.
My Question is I have indexes on my Materialized View. But I am using the hint on my view based on the Mat View.
Will it be okay to use like that?.
You may ask why I am using View instead of using Mat View directly. At later stage we are planning to apply some user level restrictions to the data
by linking the view to some other tables/view. So I am forced to use the View instead of MV.
Any ideas or suggestions will be good
Thanks in advance,
Vimal....here's an example
SQL> set autot off
SQL>
SQL> create table t
2 (dt date)
3 /
Table created.
SQL>
SQL> insert into t
2 select trunc (sysdate) + rownum
3 from all_objects
4 /
25707 rows created.
SQL>
SQL>
SQL> create index tidx on t (trunc (dt))
2 /
Index created.
SQL>
SQL> begin
2 dbms_stats.gather_table_stats (user, 'T');
3 end;
4 /
PL/SQL procedure successfully completed.
SQL>
SQL>
SQL> set autot trace expl
SQL> select *
2 from t
3 where dt = to_date ('24-07-2009', 'dd-mm-yyyy')
4 /
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=1 Bytes=8)
1 0 TABLE ACCESS (FULL) OF 'T' (Cost=6 Card=1 Bytes=8)
SQL>
SQL> select *
2 from t
3 where dt = trunc (sysdate)
4 /
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=6 Card=1 Bytes=8)
1 0 TABLE ACCESS (FULL) OF 'T' (Cost=6 Card=1 Bytes=8)
SQL>
SQL> select *
2 from t
3 where trunc (dt) = trunc (sysdate)
4 /
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=8)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T' (Cost=2 Card=1 Bytes=
8)
2 1 INDEX (RANGE SCAN) OF 'TIDX' (NON-UNIQUE) (Cost=1 Card=1
SQL>
SQL>
SQL> drop table t
2 /
Table dropped.
SQL> -
Need help on tuning materialized view refresh
Hi All,
I am working on materialized view refresh tuning.Initially it was complete refresh and used to take more than 90 mins to complete.
I changed it to fast refresh now it is completing fast. Now i have partitioned the base tables gl_balances and gl_code_combinations of column code_combination_id and created a local index on column code_combination_id then i am trying to partition the materialized on the same column to take advantage of partition change tracking.
Size of gl_balances base tables is 40Gb and all others tables sizes are small. In where clause there all the 4 tables are mapped. If i will create the partition only on code_combination_id will i the materialized will become the candidate for partition change tracking. As i know it will be applicable for PCT. I need expert advice on this.
While doing a fast refresh. the refresh takes less time. when there is a change in gl_balances , gl_code_combinations or gl_periods it completes in 20-30 mins. When there is a change in gl_set_of_books tables. It creates a problem here.DEL query takes more than 48 hours to complete.
CREATE MATERIALIZED VIEW apps.BAL_PART
REFRESH FAST ON DEMAND
ENABLE QUERY REWRITE as
SELECT GL.GL_CODE_COMBINATIONS21.ROWID C1,GL.GL_BALANCES21.ROWID C2, GL.GL_SETS_OF_BOOKS.ROWID C3,
GL.GL_PERIOD.ROWID C4,
"GL"."GL_BALANCES21"."ACTUAL_FLAG" ,
"GL"."GL_BALANCES21"."CURRENCY_CODE" ,
"GL"."GL_BALANCES21"."PERIOD_NUM" ,
"GL"."GL_BALANCES21"."PERIOD_YEAR" ,
"GL"."GL_BALANCES21"."SET_OF_BOOKS_ID" "SOB_ID",
"GL"."GL_CODE_COMBINATIONS21"."CODE_COMBINATION_ID" "CCID",
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT1" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT10" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT11" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT12" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT13" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT14" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT2" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT3" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT4" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT5" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT6" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT7" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT8" ,
"GL"."GL_CODE_COMBINATIONS21"."SEGMENT9" ,
"GL"."GL_PERIODS"."PERIOD_NAME" ,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal_Cr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal_Cr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) Open_Bal_Dr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Close_Bal_Dr,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) Open_Bal,
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_DR", 0) -
NVL("GL"."GL_BALANCES21"."BEGIN_BALANCE_CR", 0) +
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) -
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Close_Bal,
NVL("GL"."GL_BALANCES21"."PERIOD_NET_CR", 0) Period_Cr,
NVL("GL"."GL_BALANCES21"."PERIOD_NET_DR", 0) Period_Dr
FROM GL.GL_CODE_COMBINATIONS21,
GL.GL_BALANCES21,
GL.GL_SETS_OF_BOOKS,
GL.GL_PERIODS
WHERE GL.GL_BALANCES21.CODE_COMBINATION_ID =GL.GL_CODE_COMBINATIONS21.CODE_COMBINATION_ID
AND GL.GL_SETS_OF_BOOKS.SET_OF_BOOKS_ID = GL.GL_BALANCES21.SET_OF_BOOKS_ID
AND GL.GL_PERIODS.PERIOD_NUM = GL.GL_BALANCES21.PERIOD_NUM
AND GL.GL_PERIODS.PERIOD_YEAR = GL.GL_BALANCES21.PERIOD_YEAR
AND GL.GL_PERIODS.PERIOD_TYPE = GL.GL_BALANCES21.PERIOD_TYPE
AND GL.GL_PERIODS.PERIOD_NAME = GL.GL_BALANCES21.PERIOD_NAME
AND GL.GL_PERIODS.PERIOD_SET_NAME = GL.GL_SETS_OF_BOOKS.PERIOD_SET_NAME
and gl.GL_CODE_COMBINATIONS21.summary_flag != 'Y'TRACE 1046 del statement
DELETE FROM "APPS"."apps.BAL_PART" SNA$
WHERE "C3" IN (SELECT /*+ NO_MERGE */ * FROM (SELECT
CHARTOROWID("MAS$"."M_ROW$$") RID$ FROM "GL"."MLOG$_GL_SETS_OF_BOOKS"
"MAS$" WHERE "MAS$".SNAPTIME$$ > :B_ST1 ) AS OF SNAPSHOT(:B_SCN) MAS$)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 17759.00 171782.99 159422121 1267371 2564144739 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 17759.00 171782.99 159422121 1267371 2564144739 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 175 (APPS) (recursive depth: 1)
Rows Row Source Operation
0 DELETE apps.BAL_PART (cr=0 pr=0 pw=0 time=0 us)
193128740 NESTED LOOPS (cr=592437 pr=592422 pw=0 time=945244160 us cost=339302 size=168 card=1)
3 SORT UNIQUE (cr=7 pr=0 pw=0 time=15832 us cost=2 size=138 card=1)
24 TABLE ACCESS FULL MLOG$_GL_SETS_OF_BOOKS (cr=7 pr=0 pw=0 time=19 us cost=2 size=138 card=1)
193128740 INDEX RANGE SCAN C3BOOKS (cr=592430 pr=592422 pw=0 time=789499200 us cost=339299 size=3318314250 card=110610475)(object id 2114736)
error during execute of EXPLAIN PLAN statement
ORA-08187: snapshot expression not allowed here
parse error offset: 314
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 159520897 2.12 144415.96
latch: cache buffers chains 134 0.06 0.68
latch: undo global data 33 0.02 0.15
latch: object queue header operation 521 0.02 0.53
log file switch (private strand flush incomplete)
532 0.31 28.26
resmgr:cpu quantum 155 1.40 13.49
resmgr:internal state change 25 0.11 2.21
latch free 10 0.00 0.00
latch: cache buffers lru chain 4 0.00 0.00
rdbms ipc reply 489 0.02 0.54
reliable message 587 0.00 0.56
latch: row cache objects 3 0.00 0.00
********************************************************************************GL_SETS_OF_BOOKS has only 6 rows. I know there is complete refresh as a option which will again take more than 90 mins.
I want to do the fast refresh. Tables rows details below.
SQL> select count(*) from gl.gl_code_combinations21;
COUNT(*)
3075255
SQL> select count(*) from gl.GL_PERIODS;
COUNT(*)
1160
SQL> select count(*) from gl.gl_balances21;
COUNT(*)
477613527
SQL> select count(*) from gl.gl_sets_of_books;
COUNT(*)
6gl_sets_of_books has less rows. Whenever there is a change then it mapped to huge rows hence during materialized view has delete huge number of rows.
select count(*) from apps.BAL_PART group by C3;
C3 is the rowid which is present in create materialized statement.
COUNT(*)
292927011
210215
69330
184406971
Is there any way to improve the plan. As i created a partition on code_combination_id and local index on code_combination_id which will not help in set_of_books_id case. I dont PCT will help here or not. Is it possible to use PCT refresh by equipartitioning only one column in where clause.
Please assist me in improving refresh of materialized view using fast refresh.
Thanks and Regards,
Edited by: user646034 on Feb 23, 2013 11:13 PM
Edited by: user646034 on Feb 23, 2013 11:19 PM
Edited by: user646034 on Feb 23, 2013 11:46 PM
Edited by: user646034 on Feb 25, 2013 11:46 AMHi
The below explain without index and with index.
/* MV_REFRESH (DEL) */ DELETE FROM "APPS"."BAL_PART
" SNA$ WHERE "C3" IN (SELECT /*+ NO_MERGE */ * FROM (SELECT
CHARTOROWID("MAS$"."M_ROW$$") RID$ FROM
"GL"."MLOG$_GL_SETS_OF_BOOKS" "MAS$" WHERE "MAS$".SNAPTIME$$ > :B_ST1
) AS OF SNAPSHOT(:B_SCN) MAS$)
Plan hash value: 2704021294
| Id | Operation | Name | E-Rows |E-Bytes| Cost (%CPU)| E-Time |
| 0 | DELETE STATEMENT | | | | 339K(100)| |
| 1 | DELETE | BAL_PART | | | | |
| 2 | NESTED LOOPS | | 1 | 168 | 339K (1)|999:59:59 |
| 3 | SORT UNIQUE | | 1 | 138 | 2 (0)| 00:02:31 |
| 4 | TABLE ACCESS FULL| MLOG$_GL_SETS_OF_BOOKS | 1 | 138 | 2 (0)| 00:02:31 |
| 5 | INDEX RANGE SCAN | C3BOOKS | 110M| 3164M| 339K (0)|999:59:59 |
If i will not use the C3 index then the query will use the belolw plan, I guess this will also take same time or more time.
| 0 | DELETE STATEMENT | | | | 9743K(100)| |
| 1 | DELETE | BAL_PART | | | | -
Materialized view takes long to refresh
On Oracle 11g2, I created a materialized view fast refresh on commit CREATE MATERIALIZED VIEW mv_case
PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS
SELECT p.jperson_id,offense_id,CASE_SENTENCE_DATE,court_ref,CASE_COURT_ORI,
c.CASE_VERDICT_DATE,CASE_DOCKET,c.CASE_EXPUNGED,c.jcase_id,cc.CYCLEID_ID,
p.rowid p_rowid,xc.rowid xc_rowid,c.rowid c_rowid,cxo.rowid cxo_rowid,cc.rowid cc_row_id
FROM jperson p,jperson_x_jcase xc,jcase c,jcase_x_offense cxo,jcase_x_cycleid cc
where p.jperson_id = xc.jperson_id(+) and xc.jcase_id = c.jcase_id(+)
and c.jcase_id = cxo.jcase_id(+) and c.jcase_id=cc.jcase_id;
create index idx_mv_case_pid on mv_case(jperson_id);
ALTER TABLE mv_case ADD (CONSTRAINT PK_MV_CASE PRIMARY KEY(jcase_id,offense_id)) ;
create index idx_mv_case_p_rowid on mv_case(p_rowid);
create index idx_mv_case_xc_rowid on mv_case(xc_rowid);
create index idx_mv_case_c_rowid on mv_case(c_rowid);
create index idx_mv_case_cxo_rowid on mv_case(cxo_rowid);
create index idx_mv_case_cc_rowid on mv_case(cc_row_id); I inserted one single row into one of the master table
insert into jcase_x_offense (offense_id,jcase_id) values ('test_row3','test_row3');
commit; The commit tooks a quite long. I looked into the trace file and the actual insert took 0.01 seconds but one of the internel DML took most of time. I copy the relevant TKPROF output for the internal DML belowINSERT INTO QAPF.MV_CASE SELECT /*+ NO_MERGE(JV$) */
MAS$4.JPERSON_ID,JV$.OFFENSE_ID,MAS$2.CASE_SENTENCE_DATE,
MAS$2.COURT_REF,MAS$2.CASE_COURT_ORI,MAS$2.CASE_VERDICT_DATE,
MAS$2.CASE_DOCKET,MAS$2.CASE_EXPUNGED,MAS$2.JCASE_ID,
MAS$0.CYCLEID_ID,MAS$4.ROWID,MAS$3.ROWID,MAS$2.ROWID,JV$.RID$,
MAS$0.ROWID
FROM ( SELECT MAS$.ROWID RID$ , MAS$.* FROM QAPF.JCASE_X_OFFENSE MAS$ WHERE ROWID IN
(SELECT /*+ HASH_SJ */ CHARTOROWID(MAS$.M_ROW$$) RID$
FROM QAPF.MLOG$_JCASE_X_OFFENSE MAS$ WHERE MAS$.XID$$ = :1 )) JV$,
JCASE_X_CYCLEID AS OF SNAPSHOT(:B_SCN) MAS$0, JCASE AS OF SNAPSHOT(:B_SCN) MAS$2,
JPERSON_X_JCASE AS OF SNAPSHOT(:B_SCN) MAS$3, JPERSON AS OF SNAPSHOT(:B_SCN) MAS$4
WHERE (MAS$4.JPERSON_ID=MAS$3.JPERSON_ID(+)
AND MAS$3.JCASE_ID=MAS$2.JCASE_ID(+)
AND MAS$2.JCASE_ID=JV$.JCASE_ID(+)
AND MAS$2.JCASE_ID=MAS$0.JCASE_ID)
AND NOT EXISTS (
SELECT 1 FROM QAPF.MV_CASE SNA2$
WHERE (SNA2$.P_ROWID = MAS$4.ROWID)
AND (SNA2$.XC_ROWID = MAS$3.ROWID OR MAS$3.ROWID IS NULL )
AND (SNA2$.C_ROWID = MAS$2.ROWID OR MAS$2.ROWID IS NULL )
AND (SNA2$.CC_ROW_ID = MAS$0.ROWID OR MAS$0.ROWID IS NULL )
AND JV$.RID$ IS NULL)
AND NOT EXISTS (
SELECT 1 FROM JCASE_X_OFFENSE MAS_INNER$, JCASE AS OF SNAPSHOT(:B_SCN) MAS_OUTER$
WHERE MAS$2.ROWID = MAS_OUTER$.ROWID AND JV$.RID$ IS NULL
AND MAS_OUTER$.JCASE_ID=MAS_INNER$.JCASE_ID)
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 99.51 364.87 377012 17412972 1 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 99.51 364.87 377012 17412972 1 0
Rows Row Source Operation
0 LOAD TABLE CONVENTIONAL (cr=17412968 pr=377012 pw=120527 time=0 us)
0 FILTER (cr=17412968 pr=377012 pw=120527 time=0 us)
3363837 HASH JOIN RIGHT OUTER (cr=264914 pr=280254 pw=120527 time=35845080 us cost=299444 size=1029332286 card=3363831)
1 VIEW (cr=112490 pr=180864 pw=119722 time=0 us cost=30743 size=78 card=1)
1 HASH JOIN SEMI (cr=112490 pr=180864 pw=119722 time=0 us cost=72627 size=208 card=1)
11354346 TABLE ACCESS FULL JCASE_X_OFFENSE (cr=112488 pr=112447 pw=0 time=4814838 us cost=30703 size=749386770 card=11354345)
1 TABLE ACCESS BY INDEX ROWID MLOG$_JCASE_X_OFFENSE (cr=2 pr=0 pw=0 time=0 us cost=1 size=142 card=1)
1 INDEX RANGE SCAN IDX_MLOG$_XID_JCASE_X_OFFENSE (cr=1 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 98375)
3363837 HASH JOIN (cr=152424 pr=99390 pw=805 time=29973970 us cost=268690 size=766953468 card=3363831)
2994042 INDEX FAST FULL SCAN JPERSON_I0 (cr=18134 pr=0 pw=0 time=772990 us cost=17450 size=134731845 card=2994041)(object id 83738)
3363837 HASH JOIN (cr=134290 pr=99390 pw=805 time=25292580 us cost=212128 size=615581073 card=3363831)
3363837 HASH JOIN (cr=69008 pr=34127 pw=805 time=4750330 us cost=101637 size=393568929 card=3363837)
3363837 TABLE ACCESS FULL JCASE_X_CYCLEID (cr=33337 pr=33322 pw=0 time=2942460 us cost=33569 size=222013242 card=3363837)
6586646 TABLE ACCESS FULL JCASE (cr=35671 pr=0 pw=0 time=1584102 us cost=35988 size=335918895 card=6586645)
6586635 TABLE ACCESS FULL JPERSON_X_JCASE (cr=65282 pr=65263 pw=0 time=5446686 us cost=65632 size=434717844 card=6586634)
3363837 FILTER (cr=17148054 pr=96758 pw=0 time=0 us)
3363837 MAT_VIEW ACCESS BY INDEX ROWID MV_CASE (cr=17148054 pr=96758 pw=0 time=0 us cost=7 size=40 card=1)
32464070 INDEX RANGE SCAN IDX_MV_CASE_P_ROWID (cr=4489770 pr=15250 pw=0 time=19576798 us cost=3 size=0 card=7)(object id 98467)
0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us cost=4 size=78 card=1)
0 TABLE ACCESS BY USER ROWID JCASE (cr=0 pr=0 pw=0 time=0 us cost=1 size=45 card=1)
0 INDEX RANGE SCAN JCASE_X_OFFENSE_I0 (cr=0 pr=0 pw=0 time=0 us cost=3 size=33 card=1)(object id 83623)Questions:
1) what are the objects like JCASE AS OF SNAPSHOT(:B_SCN) ? Can I index them? I tried access it but got error
select * from JCASE AS OF SNAPSHOT(:B_SCN) ;
ORA-08187: snapshot expression not allowed here
08187. 00000 - "snapshot expression not allowed here"
*Cause: A snapshot expression using AS OF was specified when not allowed.
*Action: Do not use the AS OF clause
2) In the inline view following the firs FROM, it used ROWID in where clause. I tried create an index on ROWID, and error
create index idx_jcase_offense_rid on JCASE_X_OFFENSE(rowid)
ERROR at line 1:
ORA-00904: : invalid identifier
Note: I checked that I have indexes all fields in all where clauses in the DML except rowid.
Thanks for help.sybrand_b wrote:
1 Apparently Oracle is using Flashback technology when no materialized view logs have been set up
As your MV is a complex MV it is not a candidate for FAST REFRESH ON COMMIT.
I haven't looked closely at how 11.2 has changed the "fast refresh on commit" - but I would have expected it to raise an Oracle error when the OP tried to create the materialized view with that option if it were not possible.
I think your first comment is probably the more important one - if the user sets up suitable materialized view logs on all the tables in the outer join then it's possible that the fast refresh could work properly.
This is pure speculation, of course, based on the absence of an error message.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"Science is more than a body of knowledge; it is a way of thinking"+
+Carl Sagan+ -
Materialized view to be optimized!!
The following materialized view is taking more than 1.5 hours. Any alternate suggestion/advise would be appreciated. Thanks in advance .
SELECT e.emp_key, trim(e.gid) gid, pcm.check_id, pcm.end_date, pcm.g_amt, pcm.net_amt, pedt.ded_amt, pedt.tax, pdm.ded_cd, trim(pdm.ded) ded, pcm.check_date
FROM employee e, check_mstr pcm, deduction_mstr pdm, deduction_tkn pedt, sys_parms sp
WHERE e.time_key = time_pkg.fx_time_key
AND e.emp_num = pcm.emp_num
AND pcm.LOAD_KEY = pedt.load_key
AND pcm.emp_num = pedt.emp_num
AND pcm.check_id = pedt.check_id
AND pdm.time_key = pedt.load_key
AND pdm.ded_key = pedt.ded_key
AND TO_CHAR(pcm.end_date, 'YYYY') = sp.run_year
--------------------------------------------------------------------------------------------------------------When was the last time that statistics were computed
for these tables? Are you inadvertently missing a
join condition? Can you post an explain plan to see
if there are any bottlenecks?
HTH!Operation Object Name Rows Bytes Cost
SELECT STATEMENT Optimizer Mode=CHOOSE 1 3696
TABLE ACCESS BY INDEX ROWID EMPLOYEE 1 26 103
NESTED LOOPS 1 224 3696
HASH JOIN 1 198 3593
NESTED LOOPS 1 195 3590
HASH JOIN 3 357 3587
TABLE ACCESS FULL DEDUCTION_MSTR 271 K 12 M 322
TABLE ACCESS FULL DEDUCTION_TKN 887 K 60 M 1046
TABLE ACCESS BY INDEX ROWID CHECK_MSTR 1 76 1
INDEX UNIQUE SCAN CHECK_MSTR 1
TABLE ACCESS FULL SYS_PARMS 1 3 2
INDEX RANGE SCAN EMP_UIDX 1 102
---------------------------------------------------------------------------------------------------------------------- -
Peformance of a Materialized view
Hi,
I have created materialized view the below
CREATE MATERIALIZED VIEW SUMMARY.V_OSFI_FEED_CORE_DATA_ADJ
TABLESPACE RCDW_CAD_SUM_1M_DAT01
PCTUSED 0
PCTFREE 0
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64K
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOCACHE
LOGGING
NOCOMPRESS
NOPARALLEL
BUILD DEFERRED
REFRESH FORCE ON DEMAND
WITH PRIMARY KEY
AS
/* Formatted on 2010/01/27 14:49 (Formatter Plus v4.8.8) */
SELECT orgn.month_end_date month_end_date,
orgn.ntrl_k_odc_instrument ntrl_k_odc_instrument,
orgn.processing_system processing_system,
orgn.source_system source_system,
DECODE (UPPER (adjstd.ssb_type_indicator),
'NULL', NULL,
NVL (adjstd.ssb_type_indicator, orgn.ssb_type_indicator)
) ssb_type_indicator,
DECODE (UPPER (adjstd.basel_exposure_class),
'NULL', NULL,
NVL (adjstd.basel_exposure_class, orgn.basel_exposure_class)
) basel_exposure_class,
DECODE (UPPER (adjstd.basel_exposure_subclass),
'NULL', NULL,
NVL (adjstd.basel_exposure_subclass,
orgn.basel_exposure_subclass
) basel_exposure_subclass,
DECODE (UPPER (TRIM (adjstd.ccis_product_code)),
'NULL', NULL,
NVL (adjstd.ccis_product_code, orgn.ccis_product_code)
) ccis_product_code,
orgn.warehouse_instrument_key warehouse_instrument_key,
DECODE (UPPER (adjstd.instrument_status),
'NULL', NULL,
NVL (adjstd.instrument_status, orgn.instrument_status)
) instrument_status,
DECODE (UPPER (adjstd.instrument_open_flag),
'NULL', NULL,
NVL (adjstd.instrument_open_flag, orgn.instrument_open_flag)
) instrument_open_flag,
DECODE (UPPER (adjstd.instrument_dwo_flag),
'NULL', NULL,
NVL (adjstd.instrument_dwo_flag, orgn.instrument_dwo_flag)
) instrument_dwo_flag,
DECODE (UPPER (adjstd.instrument_closed_flag),
'NULL', NULL,
NVL (adjstd.instrument_closed_flag,
orgn.instrument_closed_flag)
) instrument_closed_flag,
DECODE (UPPER (adjstd.instrument_arrears_flag),
'NULL', NULL,
NVL (adjstd.instrument_arrears_flag,
orgn.instrument_arrears_flag
) instrument_arrears_flag,
DECODE (UPPER (adjstd.instrument_npna_flag),
'NULL', NULL,
NVL (adjstd.instrument_npna_flag, orgn.instrument_npna_flag)
) instrument_npna_flag,
DECODE (UPPER (adjstd.account_open_dt),
'NULL', TO_DATE (NULL),
NULL, orgn.account_open_dt,
TO_DATE (adjstd.account_open_dt, 'dd-MON-YYYY')
) account_open_dt,
DECODE (UPPER (adjstd.account_close_dt),
'NULL', TO_DATE (NULL),
NULL, orgn.account_close_dt,
TO_DATE (adjstd.account_close_dt, 'dd-MON-YYYY')
) account_close_dt,
DECODE (UPPER (adjstd.instrument_insured_ind),
'NULL', NULL,
NVL (adjstd.instrument_insured_ind,
orgn.instrument_insured_ind)
) instrument_insured_ind,
DECODE
(UPPER (adjstd.instrument_securitized_ind),
'NULL', NULL,
NVL (adjstd.instrument_securitized_ind,
orgn.instrument_securitized_ind
) instrument_securitized_ind,
DECODE (UPPER (adjstd.country_code),
'NULL', NULL,
NVL (adjstd.country_code, orgn.country_code)
) country_code,
DECODE (UPPER (TRIM (adjstd.province)),
'NULL', NULL,
NVL (adjstd.province, orgn.province)
) province,
COALESCE (adjstd.presec_outstanding_bal,
orgn.presec_outstanding_bal,
NULL
) presec_outstanding_bal,
COALESCE (adjstd.postsec_outstanding_bal,
orgn.postsec_outstanding_bal,
NULL
) postsec_outstanding_bal,
COALESCE (adjstd.presec_authorized_limit,
orgn.presec_authorized_limit,
NULL
) presec_authorized_limit,
DECODE (UPPER (adjstd.interest_rate_type),
'NULL', NULL,
NVL (adjstd.interest_rate_type, orgn.interest_rate_type)
) interest_rate_type,
COALESCE (adjstd.ltv, orgn.ltv, NULL) ltv,
DECODE (UPPER (adjstd.arrears_cycle_type),
'NULL', NULL,
NVL (adjstd.arrears_cycle_type, orgn.arrears_cycle_type)
) arrears_cycle_type,
COALESCE (adjstd.recovery_amt, orgn.recovery_amt, NULL) recovery_amt,
COALESCE (adjstd.wrtoff_amt, orgn.wrtoff_amt, NULL) wrtoff_amt,
COALESCE (adjstd.utilization_rate,
orgn.utilization_rate,
NULL
) utilization_rate,
DECODE (UPPER (adjstd.pd_pool),
'NULL', NULL,
NVL (adjstd.pd_pool, orgn.pd_pool)
) pd_pool,
COALESCE (adjstd.pd_value_pct, orgn.pd_value_pct, NULL) pd_value_pct,
DECODE (UPPER (adjstd.lgd_pool),
'NULL', NULL,
NVL (adjstd.lgd_pool, orgn.lgd_pool)
) lgd_pool,
COALESCE (adjstd.lgd_value_pct, orgn.lgd_value_pct,
NULL) lgd_value_pct,
DECODE (UPPER (adjstd.ead_pool),
'NULL', NULL,
NVL (adjstd.ead_pool, orgn.ead_pool)
) ead_pool,
COALESCE (adjstd.presec_precrm_ead,
orgn.presec_precrm_ead,
NULL
) presec_precrm_ead,
COALESCE (adjstd.postsec_precrm_ead,
orgn.postsec_precrm_ead,
NULL
) postsec_precrm_ead,
COALESCE (adjstd.postsec_postcrm_ead,
orgn.postsec_postcrm_ead,
NULL
) postsec_postcrm_ead,
COALESCE (adjstd.expected_loss_amt,
orgn.expected_loss_amt,
NULL
) expected_loss_amt,
COALESCE (adjstd.postsec_rwa, orgn.postsec_rwa, NULL) postsec_rwa,
DECODE (UPPER (adjstd.risk_rating_system),
'NULL', NULL,
NVL (adjstd.risk_rating_system, orgn.risk_rating_system)
) risk_rating_system,
DECODE (UPPER (adjstd.default_ind),
'NULL', NULL,
NVL (adjstd.default_ind, orgn.default_ind)
) default_ind,
DECODE (UPPER (adjstd.LOB),
'NULL', NULL,
NVL (adjstd.LOB, orgn.LOB)
) LOB,
DECODE (UPPER (adjstd.row_source),
'NULL', NULL,
NVL (adjstd.row_source, orgn.row_source)
) row_source,
COALESCE (adjstd.postsec_authorized_limit,
orgn.postsec_authorized_limit,
NULL
) postsec_authorized_limit,
COALESCE (adjstd.recovery_amt_calc,
orgn.recovery_amt_calc,
NULL
) recovery_amt_calc,
adjstd.adj_cycle_id adj_cycle_id,
orgn.curr_warehouse_inst_key curr_warehouse_inst_key,
orgn.curr_ccis_prod curr_ccis_prod, adjstd.load_time load_time,
adjstd.update_time update_time
FROM summary.osfi_feed_core_data orgn, summary.ncr_adj_data adjstd
WHERE orgn.ntrl_k_odc_instrument = adjstd.ntrl_k_odc_instrument
UNION ALL
SELECT orgn.month_end_date, orgn.ntrl_k_odc_instrument,
orgn.processing_system, orgn.source_system, orgn.ssb_type_indicator,
orgn.basel_exposure_class, orgn.basel_exposure_subclass,
orgn.ccis_product_code, orgn.warehouse_instrument_key,
orgn.instrument_status, orgn.instrument_open_flag,
orgn.instrument_dwo_flag, orgn.instrument_closed_flag,
orgn.instrument_arrears_flag, orgn.instrument_npna_flag,
orgn.account_open_dt, orgn.account_close_dt,
orgn.instrument_insured_ind, orgn.instrument_securitized_ind,
orgn.country_code, orgn.province, orgn.presec_outstanding_bal,
orgn.postsec_outstanding_bal, orgn.presec_authorized_limit,
orgn.interest_rate_type, orgn.ltv, orgn.arrears_cycle_type,
orgn.recovery_amt, orgn.wrtoff_amt, orgn.utilization_rate,
orgn.pd_pool, orgn.pd_value_pct, orgn.lgd_pool, orgn.lgd_value_pct,
orgn.ead_pool, orgn.presec_precrm_ead, orgn.postsec_precrm_ead,
orgn.postsec_postcrm_ead, orgn.expected_loss_amt, orgn.postsec_rwa,
orgn.risk_rating_system, orgn.default_ind, orgn.LOB, orgn.row_source,
orgn.postsec_authorized_limit, orgn.recovery_amt_calc, 0,
orgn.curr_warehouse_inst_key curr_warehouse_inst_key,
orgn.curr_ccis_prod curr_ccis_prod, SYSDATE, SYSDATE
FROM osfi_feed_core_data orgn
WHERE NOT EXISTS (SELECT ntrl_k_odc_instrument
FROM ncr_adj_data
WHERE ntrl_k_odc_instrument = orgn.ntrl_k_odc_instrument);When i refresh the materialized view its taking 5 to 6 mins. I have used DBMS_ADVISOR.TUNE_MVIEW to tune the query, but it raised error as
ORA-13600: error encountered in Advisor
QSM-03113: Cannot tune the MATERIALIZED VIEW statement
QSM-02091: mv references a non-repeatable or session-sensitive expression
QSM-02164: the materialized view is BUILD DEFERRED
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 86
ORA-06512: at "SYS.PRVT_ACCESS_ADVISOR", line 202
ORA-06512: at "SYS.PRVT_TUNE_MVIEW", line 1232
ORA-06512: at "SYS.DBMS_ADVISOR", line 753
ORA-06512: at line 221
Can anyone suggest some methods to increase the peformance of the view.Hi,
Here is the explain plan of the query,
Plan
SELECT STATEMENT ALL_ROWSCost: 626 Bytes: 35,803,043 Cardinality: 144,937
18 PX COORDINATOR
17 PX SEND QC (RANDOM) PARALLEL_TO_SERIAL SYS.:TQ10002
16 BUFFER SORT PARALLEL_COMBINED_WITH_PARENT Cost: 626 Bytes: 35,803,043 Cardinality: 144,937
15 UNION-ALL PARALLEL_COMBINED_WITH_PARENT
7 HASH JOIN PARALLEL_COMBINED_WITH_PARENT Cost: 314 Bytes: 7,803 Cardinality: 17
4 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
3 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 3 Bytes: 3,859 Cardinality: 17
2 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10000 Cost: 3 Bytes: 3,859 Cardinality: 17
1 TABLE ACCESS FULL TABLE SUMMARY.NCR_ADJ_DATA Cost: 3 Bytes: 3,859 Cardinality: 17
6 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 310 Bytes: 33,625,384 Cardinality: 144,937
5 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT SUMMARY.OSFI_FEED_CORE_DATA Cost: 310 Bytes: 33,625,384 Cardinality: 144,937
14 HASH JOIN RIGHT ANTI PARALLEL_COMBINED_WITH_PARENT Cost: 312 Bytes: 35,795,240 Cardinality: 144,920
11 BUFFER SORT PARALLEL_COMBINED_WITH_CHILD
10 PX RECEIVE PARALLEL_COMBINED_WITH_PARENT Cost: 1 Bytes: 255 Cardinality: 17
9 PX SEND BROADCAST PARALLEL_FROM_SERIAL SYS.:TQ10001 Cost: 1 Bytes: 255 Cardinality: 17
8 INDEX FULL SCAN INDEX SUMMARY.INDEX_2 Cost: 1 Bytes: 255 Cardinality: 17
13 PX BLOCK ITERATOR PARALLEL_COMBINED_WITH_CHILD Cost: 310 Bytes: 33,625,384 Cardinality: 144,937
12 TABLE ACCESS FULL TABLE PARALLEL_COMBINED_WITH_PARENT SUMMARY.OSFI_FEED_CORE_DATA Cost: 310 Bytes: 33,625,384 Cardinality: 144,937 There is no index on the tables and it contains lakhs of records. -
The master table of a materialized view
Hi Everybody,
I have in my database a snapshot created on multiple tables, like this:
create materialized view <some_name>
as select <some_fields>
from a,b, c
where <some_join_conditions>
Questions:
1. What "algorithm" uses Oracle to determine the master table of the snapshot? The master table visible in USER_SNAPSHOTS?
2. How can I change the master table chosed by Oracle with the table I want? I tried using some tuning hints (for example "leading table") but it is not working.
The table I want to force as master table is a remote one accessed by dblink. Does this change anything?
Thank you very much.
DanielaWe had issue with similar probelm and found that driving table is becoming master table, which was last table on your from clause (c).
However the Query Optimizer is COST based, and we are not sure this holds true forever.
We are looking at these answers too. -
Please help with the query creating Materialized View
Hi,
We are using the below query to create a Materialized View but it has been running since 3 hours. It is an Oracle 9i database running in HP-UX.The quey is as follows,
(SELECT
/*+ use_nl(A) parallel (A,4)*/
A.ICD_CODE AS ICD_CODE,
A.ICD_DESC AS ICD_DESC,
A.PROC_GROUP as PROC_GROUP,
B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
C.PROC_TYPE AS PROC_TYPE ,
C.I_O_IND AS I_O_IND,
C.DISC_MON AS QUARTER ,
B.PAT_KEY AS PAT_KEY ,
D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
C.PROV_ID AS PROV_ID ,
A.SPECIALTY AS SPECIALTY
FROM
EES_ICD_9_CODE A ,
EES_CLINICAL_COMPL_DATA B,
EES_CLINICAL_DATA C,
EES_CLINCL_COMPL_ICD D
WHERE A.ICD_CODE= B.ICD_CODE
AND B.ICD_CODE= C.ICD_CODE
AND B.COMPL_ICD_CODE=D.ICD_9_CD
AND B.PAT_KEY=C.PAT_KEY
AND B.COMPL_ICD_CODEB.ICD_CODE
AND C.PROC_TYPE 'L'
AND B.COMPL_GRP_TXT'Reoperations'
AND D.COMPL_TYPE_TXT'Intra-operative Misadventure'
AND C.DISC_MON>='2003101'
AND A.SPECIALTY='Colo-Rectal')
union
(SELECT
/*+ use_nl(A) parallel (A,4)*/
A.ICD_CODE AS ICD_CODE,
A.ICD_DESC AS ICD_DESC,
A.PROC_GROUP as PROC_GROUP,
B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
C.PROC_TYPE AS PROC_TYPE ,
C.I_O_IND AS I_O_IND,
C.DISC_MON AS QUARTER ,
B.PAT_KEY AS PAT_KEY ,
D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
C.PROV_ID AS PROV_ID ,
A.SPECIALTY AS SPECIALTY
FROM
EES_ICD_9_CODE A ,
EES_CLINICAL_COMPL_DATA B,
EES_CLINICAL_DATA C,
EES_CLINCL_COMPL_ICD D
WHERE A.ICD_CODE= B.ICD_CODE
AND B.ICD_CODE= C.ICD_CODE
AND B.COMPL_ICD_CODE=D.ICD_9_CD
AND B.PAT_KEY=C.PAT_KEY
AND B.COMPL_ICD_CODEB.ICD_CODE
AND C.PROC_TYPE 'L'
--AND B.COMPL_GRP_TXT'Reoperations'
AND D.COMPL_TYPE_TXT='Intra-operative Misadventure'
AND B.PROC_DAY=C.PROC_DAY
AND C.DISC_MON>='2003101'
AND A.SPECIALTY='Colo-Rectal')
union
(SELECT
/*+ use_nl(A) parallel (A,4)*/
A.ICD_CODE AS ICD_CODE,
A.ICD_DESC AS ICD_DESC,
A.PROC_GROUP as PROC_GROUP,
B.COMPL_ICD_CODE AS COMPL_ICD_CODE,
B.COMPL_GRP_TXT AS COMPL_GRP_TXT,
C.PROC_TYPE AS PROC_TYPE ,
C.I_O_IND AS I_O_IND,
C.DISC_MON AS QUARTER ,
B.PAT_KEY AS PAT_KEY ,
D.COMPL_TYPE_TXT AS COMPL_TYPE_TXT ,
C.PROV_ID AS PROV_ID ,
A.SPECIALTY AS SPECIALTY
FROM
EES_ICD_9_CODE A ,
EES_CLINICAL_COMPL_DATA B,
EES_CLINICAL_DATA C,
EES_CLINCL_COMPL_ICD D
WHERE A.ICD_CODE= B.ICD_CODE
AND B.ICD_CODE= C.ICD_CODE
AND B.COMPL_ICD_CODE=D.ICD_9_CD
AND B.PAT_KEY=C.PAT_KEY
AND B.COMPL_ICD_CODEB.ICD_CODE
AND C.PROC_TYPE 'L'
AND B.COMPL_GRP_TXT='Reoperations'
--AND D.COMPL_TYPE_TXT='Intra-operative Misadventure'
AND B.PROC_DAY>C.PROC_DAY
AND C.DISC_MON>='2003101'
AND A.SPECIALTY='Colo-Rectal')
The explain plan is as follows,
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 46935 | 6716K| | 10648 | | | |
| 1 | SORT UNIQUE | | 46935 | 6716K| 14M| 10648 | 45,14 | P->S | QC (RAND) |
| 2 | UNION-ALL | | | | | | 45,13 | P->P | HASH |
|* 3 | HASH JOIN | | 42801 | 6102K| | 4640 | 45,13 | PCWP | |
|* 4 | TABLE ACCESS FULL | EES_CLINCL_COMPL_ICD | 875 | 18375 | | 2 | 45,02
|* 5 | HASH JOIN | | 41552 | 5072K| 14M| 4638 | 45,13 | PCWP | |
|* 6 | TABLE ACCESS FULL | EES_CLINICAL_DATA | 1430K| 40M| | 2855 | 45,03
|* 7 | HASH JOIN | | 628K| 56M| | 494 | 45,10 | P->P | HASH |
|* 8 | TABLE ACCESS FULL | EES_ICD_9_CODE | 37 | 2183 | | 1 | 45,08
|* 9 | TABLE ACCESS BY INDEX ROWID | EES_CLINICAL_COMPL_DATA | 2090K| 71M| | 49
| 10 | BITMAP CONVERSION TO ROWIDS | | | | | | |
|* 11 | BITMAP INDEX FULL SCAN | INX_COMPL_GRP | | | | | |
|* 12 | TABLE ACCESS BY INDEX ROWID | EES_CLINICAL_DATA | 1 | 33 | | 1
| 13 | NESTED LOOPS | | 1327 | 196K| | 947 | 45,13 | PCWP | |
|* 14 | HASH JOIN | | 60205 | 6996K| | 495 | 45,13 | PCWP | |
| 15 | TABLE ACCESS BY INDEX ROWID | EES_CLINCL_COMPL_ICD | 36 | 756 | |
|* 16 | INDEX RANGE SCAN | COMPL_TYPE_TXT_3 | 1 | | | 1 |
|* 17 | HASH JOIN | | 1420K| 132M| | 494 | 45,13 | PCWP | |
|* 18 | TABLE ACCESS FULL | EES_ICD_9_CODE | 37 | 2183 | | 1 | 45,11
|* 19 | TABLE ACCESS BY INDEX ROWID | EES_CLINICAL_COMPL_DATA | 4722K| 175M| | 49
| 20 | BITMAP CONVERSION TO ROWIDS| | | | | | | |
| 21 | BITMAP INDEX FULL SCAN | INX_COMPL_GRP | | | | | |
|* 22 | INDEX RANGE SCAN | EES_CLINICAL_DATA_IND1 | 1 | | | 2 | 45,13
|* 23 | HASH JOIN | | 2807 | 416K| | 4695 | 45,13 | PCWP | |
| 24 | TABLE ACCESS FULL | EES_CLINCL_COMPL_ICD | 911 | 19131 | | 2 | 45,06
|* 25 | HASH JOIN | | 2617 | 334K| 15M| 4693 | 45,13 | PCWP | |
|* 26 | TABLE ACCESS FULL | EES_CLINICAL_DATA | 1430K| 45M| | 2855 | 45,07
|* 27 | HASH JOIN | | 791K| 74M| | 305 | 45,12 | P->P | HASH |
|* 28 | TABLE ACCESS FULL | EES_ICD_9_CODE | 37 | 2183 | | 1 | 45,09
|* 29 | TABLE ACCESS BY INDEX ROWID | EES_CLINICAL_COMPL_DATA | 2632K| 97M| | 30
| 30 | BITMAP CONVERSION TO ROWIDS | | | | | | |
|* 31 | BITMAP INDEX SINGLE VALUE | INX_COMPL_GRP | | | | | |
Predicate Information (identified by operation id):
3 - access("B"."COMPL_ICD_CODE"="D"."ICD_9_CD")
4 - filter("D"."COMPL_TYPE_TXT"'Intra-operative Misadventure')
5 - access("B"."ICD_CODE"="C"."ICD_CODE" AND "B"."PAT_KEY"="C"."PAT_KEY")
6 - filter("C"."PROC_TYPE"'L' AND "C"."DISC_MON">=2003101)
7 - access("A"."ICD_CODE"="B"."ICD_CODE")
8 - filter("A"."SPECIALTY"='Colo-Rectal')
9 - filter("B"."COMPL_ICD_CODE""B"."ICD_CODE")
11 - filter("B"."COMPL_GRP_TXT"'Reoperations')
12 - filter("B"."ICD_CODE"="C"."ICD_CODE" AND "C"."PROC_TYPE"'L' AND "B"."PROC_DAY"="C"."PROC_DA
14 - access("B"."COMPL_ICD_CODE"="D"."ICD_9_CD")
16 - access("D"."COMPL_TYPE_TXT"='Intra-operative Misadventure')
17 - access("A"."ICD_CODE"="B"."ICD_CODE")
18 - filter("A"."SPECIALTY"='Colo-Rectal')
19 - filter("B"."COMPL_ICD_CODE""B"."ICD_CODE")
22 - access("B"."PAT_KEY"="C"."PAT_KEY")
23 - access("B"."COMPL_ICD_CODE"="D"."ICD_9_CD")
25 - access("B"."ICD_CODE"="C"."ICD_CODE" AND "B"."PAT_KEY"="C"."PAT_KEY")
filter("B"."PROC_DAY">"C"."PROC_DAY")
26 - filter("C"."PROC_TYPE"'L' AND "C"."DISC_MON">=2003101)
27 - access("A"."ICD_CODE"="B"."ICD_CODE")
28 - filter("A"."SPECIALTY"='Colo-Rectal')
29 - filter("B"."COMPL_ICD_CODE""B"."ICD_CODE")
31 - access("B"."COMPL_GRP_TXT"='Reoperations')
Note: cpu costing is offPlease help.Try removing the hints.
Is 47,000 a reasonable estimate of how many rows you expect in the results?
See these posts for other information that you should supply.
HOW TO: Post a SQL statement tuning request
HOW TO: Post a SQL statement tuning request - template posting
When your query takes too long
When your query takes too long ... -
Logical Standby Database - Materialized Views
Hi,
Are materialized views applied from the primary to the standby? They are not mentioned in the 9i documentation as being excluded, but I cannot get a simple one to apply. The standby database log file claims that it is running the DDL, but I do not see the MV. In previous tests, both table and view create statements have worked along with various DML statements.The output is as follows .
SQL> SELECT APPLIED_SCN, NEWEST_SCN, READ_SCN, NEWEST_SCN-APPLIED_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN READ_SCN NEWEST_SCN-APPLIED_SCN
179493 194423 179497 14930
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
no rows selected
SQL> select operation, options, object_name, cost
2 from v$sql_plan, v$session, v$logstdby
3 where v$sql_plan.hash_value = v$session.sql_hash_value
4 and v$session.serial# = v$logstdby.serial#
5 and v$logstdby.status_code=16113;
no rows selected -
Query performance on materialized view vs master tables
Hi,
I am afraid of strange behavior in db, on my master tables UDBMOVEMENT_ORIG(26mil.rows) and UDBIDENTDATA_ORIG(18mil.rows) is created materialized view TMP_MS_UDB_MV (UDBMOVEMENT is synonym to this object) which meets some default conditions and join condition on these master tables. MV got about 12milions rows. I created MV to query not so huge objects, MV got 3GB, master tables toghether 12GB. But I don't understand that even physical reads and consistent gets are less on MV than on master tables, the final execution time is shorter on master tables. See my log below.
Why?
Thanks for answers.
SQL> set echo on
SQL> @flush
SQL> alter system flush buffer_cache;
System altered.
Elapsed: 00:00:00.20
SQL> alter system flush shared_pool;
System altered.
Elapsed: 00:00:00.65
SQL> SELECT
2 UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBIdentData.sCardSubType, UDBIdentData.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBIdentData.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBIdentData.tTarifTimeStart, UDBIdentData.tTarifTimeEnd, UDBIdentData.cLicensePlate, UDBIdentData.lMoneyValue, UDBIdentData.lPointValue, UDBIdentData.lTimeValue, UDBIdentData.tProdTime, UDBIdentData.tExpireDate
3 FROM UDBMOVEMENT_orig UDBMovement, Udbidentdata_orig UDBIdentData
4 WHERE
5 UDBMovement.lGlobalId = UDBIdentData.lGlobalRef(+) AND UDBMovement.sComputer = UDBIdentData.sComputer(+)
6 AND UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBIdentData.sCardType IN (2) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
7 AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25 AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
8 ORDER BY tActionTime, lBlock, lSequenz;
4947 rows selected.
Elapsed: 00:00:15.84
Execution Plan
Plan hash value: 1768406139
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 7166 | 1238K| | 20670 (1)| 00:04:09 |
| 1 | SORT ORDER BY | | 7166 | 1238K| 1480K| 20670 (1)| 00:04:09 |
| 2 | NESTED LOOPS | | | | | | |
| 3 | NESTED LOOPS | | 7166 | 1238K| | 20388 (1)| 00:04:05 |
|* 4 | TABLE ACCESS BY INDEX ROWID| UDBMOVEMENT_ORIG | 7142 | 809K| | 7056 (1)| 00:01:25 |
|* 5 | INDEX RANGE SCAN | IDX_UDBMOVARTICLE | 10709 | | | 61 (0)| 00:00:01 |
|* 6 | INDEX UNIQUE SCAN | UDBIDENTDATA_PRIM | 1 | | | 1 (0)| 00:00:01 |
|* 7 | TABLE ACCESS BY INDEX ROWID | UDBIDENTDATA_ORIG | 1 | 61 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("UDBMOVEMENT"."STRANSTYPE">0 AND "UDBMOVEMENT"."SDEVICE"<1000 AND
BITAND("SSALEFLAG",1)=0 AND "UDBMOVEMENT"."SDEVICE">=0 AND BITAND("UDBMOVEMENT"."SSALEFLAG",4)=0)
5 - access("UDBMOVEMENT"."TACTIONTIME">=TO_DATE(' 2011-05-05 06:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "UDBMOVEMENT"."TACTIONTIME"<TO_DATE(' 2011-05-05 12:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "UDBMOVEMENT"."SARTCLASSREF"<100)
filter("UDBMOVEMENT"."SARTCLASSREF"<100)
6 - access("UDBMOVEMENT"."LGLOBALID"="UDBIDENTDATA"."LGLOBALREF" AND
"UDBMOVEMENT"."SCOMPUTER"="UDBIDENTDATA"."SCOMPUTER")
7 - filter("UDBIDENTDATA"."SCARDTYPE"=2)
Statistics
543 recursive calls
0 db block gets
84383 consistent gets
4485 physical reads
0 redo size
533990 bytes sent via SQL*Net to client
3953 bytes received via SQL*Net from client
331 SQL*Net roundtrips to/from client
86 sorts (memory)
0 sorts (disk)
4947 rows processed
SQL> @flush
SQL> alter system flush buffer_cache;
System altered.
Elapsed: 00:00:00.12
SQL> alter system flush shared_pool;
System altered.
Elapsed: 00:00:00.74
SQL> SELECT UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBMovement.sCardSubType, UDBMovement.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBMovement.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBMovement.tTarifTimeStart, UDBMovement.tTarifTimeEnd, UDBMovement.cLicensePlate, UDBMovement.lMoneyValue, UDBMovement.lPointValue, UDBMovement.lTimeValue, UDBMovement.tProdTime
2 FROM UDBMOVEMENT WHERE
3 UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBMovement.sCardType IN (2) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
4 AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
5 AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5 ORDER BY tActionTime, lBlock, lSequenz;
4947 rows selected.
Elapsed: 00:00:26.46
Execution Plan
Plan hash value: 3648898312
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2720 | 443K| 2812 (1)| 00:00:34 |
| 1 | SORT ORDER BY | | 2720 | 443K| 2812 (1)| 00:00:34 |
|* 2 | MAT_VIEW ACCESS BY INDEX ROWID| TMP_MS_UDB_MV | 2720 | 443K| 2811 (1)| 00:00:34 |
|* 3 | INDEX RANGE SCAN | EEETMP_MS_ACTTIMEDEVICE | 2732 | | 89 (0)| 00:00:02 |
Predicate Information (identified by operation id):
2 - filter("UDBMOVEMENT"."STRANSTYPE">0 AND BITAND("UDBMOVEMENT"."SSALEFLAG",4)=0 AND
BITAND("SSALEFLAG",1)=0 AND "UDBMOVEMENT"."SARTCLASSREF"<100)
3 - access("UDBMOVEMENT"."TACTIONTIME">=TO_DATE(' 2011-05-05 06:00:00', 'syyyy-mm-dd
hh24:mi:ss') AND "UDBMOVEMENT"."SDEVICE">=0 AND "UDBMOVEMENT"."SCARDTYPE"=2 AND
"UDBMOVEMENT"."TACTIONTIME"<TO_DATE(' 2011-05-05 12:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"UDBMOVEMENT"."SDEVICE"<1000)
filter("UDBMOVEMENT"."SCARDTYPE"=2 AND "UDBMOVEMENT"."SDEVICE"<1000 AND
"UDBMOVEMENT"."SDEVICE">=0)
Statistics
449 recursive calls
0 db block gets
6090 consistent gets
2837 physical reads
0 redo size
531987 bytes sent via SQL*Net to client
3953 bytes received via SQL*Net from client
331 SQL*Net roundtrips to/from client
168 sorts (memory)
0 sorts (disk)
4947 rows processed
SQL> spool off
Edited by: MattSk on Feb 4, 2013 2:20 PMI have added some tkprof outputs on MV and master tables:
SELECT tmp_ms_udb_mv.zIdDevice, tmp_ms_udb_mv.sDevice, tmp_ms_udb_mv.zIdLocal, tmp_ms_udb_mv.sComputer, tmp_ms_udb_mv.tActionTime, tmp_ms_udb_mv.sCardSubType, tmp_ms_udb_mv.sCardType, tmp_ms_udb_mv.cEpan, tmp_ms_udb_mv.cText, tmp_ms_udb_mv.lArtRef, tmp_ms_udb_mv.sArtClassRef, tmp_ms_udb_mv.lSequenz, tmp_ms_udb_mv.sTransMark, tmp_ms_udb_mv.lBlock, tmp_ms_udb_mv.sTransType, tmp_ms_udb_mv.lGlobalID, tmp_ms_udb_mv.sFacility, tmp_ms_udb_mv.sCardClass, tmp_ms_udb_mv.lSingleAmount, tmp_ms_udb_mv.sVAT, tmp_ms_udb_mv.lVATTot, tmp_ms_udb_mv.tTarifTimeStart, tmp_ms_udb_mv.tTarifTimeEnd, tmp_ms_udb_mv.cLicensePlate, tmp_ms_udb_mv.lMoneyValue, tmp_ms_udb_mv.lPointValue, tmp_ms_udb_mv.lTimeValue, tmp_ms_udb_mv.tProdTime
FROM tmp_ms_udb_mv WHERE
tmp_ms_udb_mv.sTransType > 0 AND tmp_ms_udb_mv.sDevice < 1000 AND tmp_ms_udb_mv.sDevice>= 0 AND tmp_ms_udb_mv.sCardType IN (1) AND (bitand(tmp_ms_udb_mv.sSaleFlag,1) = 0 AND bitand(tmp_ms_udb_mv.sSaleFlag,4) = 0) AND tmp_ms_udb_mv.sArtClassRef < 100
AND tmp_ms_udb_mv.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
AND tmp_ms_udb_mv.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
ORDER BY tActionTime, lBlock, lSequenz
call count cpu elapsed disk query current rows
Parse 1 0.04 0.10 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 596 0.17 27.07 2874 8894 0 8925
total 598 0.21 27.18 2874 8894 0 8925
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 60
Rows Row Source Operation
8925 SORT ORDER BY (cr=8894 pr=2874 pw=0 time=27071773 us)
8925 MAT_VIEW ACCESS BY INDEX ROWID TMP_MS_UDB_MV (cr=8894 pr=2874 pw=0 time=31458291 us)
8925 INDEX RANGE SCAN EEETMP_MS_ACTTIMEDEVICE (cr=68 pr=68 pw=0 time=161347 us)(object id 149251)
SELECT
UDBMovement.zIdDevice, UDBMovement.sDevice, UDBMovement.zIdLocal, UDBMovement.sComputer, UDBMovement.tActionTime, UDBIdentData.sCardSubType, UDBIdentData.sCardType, UDBMovement.cEpan, UDBMovement.cText, UDBMovement.lArtRef, UDBMovement.sArtClassRef, UDBMovement.lSequenz, UDBMovement.sTransMark, UDBMovement.lBlock, UDBMovement.sTransType, UDBMovement.lGlobalID, UDBMovement.sFacility, UDBIdentData.sCardClass, UDBMovement.lSingleAmount, UDBMovement.sVAT, UDBMovement.lVATTot, UDBIdentData.tTarifTimeStart, UDBIdentData.tTarifTimeEnd, UDBIdentData.cLicensePlate, UDBIdentData.lMoneyValue, UDBIdentData.lPointValue, UDBIdentData.lTimeValue, UDBIdentData.tProdTime, UDBIdentData.tExpireDate
FROM UDBMOVEMENT_orig UDBMovement, Udbidentdata_orig UDBIdentData
WHERE
UDBMovement.lGlobalId = UDBIdentData.lGlobalRef(+) AND UDBMovement.sComputer = UDBIdentData.sComputer(+)
AND UDBMovement.sTransType > 0 AND UDBMovement.sDevice < 1000 AND UDBMovement.sDevice>= 0 AND UDBIdentData.sCardType IN (1) AND (bitand(UDBMovement.sSaleFlag,1) = 0 AND bitand(UDBMovement.sSaleFlag,4) = 0) AND UDBMovement.sArtClassRef < 100
AND UDBMovement.tActionTime >= TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.25
AND UDBMovement.tActionTime < TO_DATE('05/05/2011 00:00:00', 'dd/mm/yyyy hh24:mi:ss') + 0.5
ORDER BY tActionTime, lBlock, lSequenz
call count cpu elapsed disk query current rows
Parse 1 0.03 0.06 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 596 0.76 16.94 3278 85529 0 8925
total 598 0.79 17.01 3278 85529 0 8925
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 60
Rows Row Source Operation
8925 SORT ORDER BY (cr=85529 pr=3278 pw=0 time=16942799 us)
8925 NESTED LOOPS (cr=85529 pr=3278 pw=0 time=15017857 us)
22567 TABLE ACCESS BY INDEX ROWID UDBMOVEMENT_ORIG (cr=17826 pr=1659 pw=0 time=7273473 us)
22570 INDEX RANGE SCAN IDX_UDBMOVARTICLE (cr=111 pr=111 pw=0 time=112351 us)(object id 143693)
8925 TABLE ACCESS BY INDEX ROWID UDBIDENTDATA_ORIG (cr=67703 pr=1619 pw=0 time=8154915 us)
22567 INDEX UNIQUE SCAN UDBIDENTDATA_PRIM (cr=45136 pr=841 pw=0 time=3731470 us)(object id 108324) -
Materialized Views with Query Rewrite is not getting re-written
I have tried everything that has been mentioned in all the forums here and on metalink to fix this issue, has any smart APEX user found a solution?
The issue is the MV with Query rewrite capability is not being re-written.
Things I have tried
1) give all Query Rewrite privileges to all 3 APEx schemas and parsing schema;
2) check trace files with tkprof;
3) dynamically printed explain plan from v$_SQL on the page while executing the query;
4) to test in a different environment i created an another DAD using the pl/sql webtool kit and tried the same thing and rewrite works like a charm...
whats the issue here...why are apex schemas not re-writing the queries????
appreciate any help...thanksJes, per your request
--create materialized view
CREATE MATERIALIZED VIEW "RPLANSWEB"."MV_FCG_ALL_SUMMARY_TAB"
ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 81920 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "RPLANSWEB"
BUILD IMMEDIATE
USING INDEX
REFRESH FORCE ON DEMAND
USING DEFAULT LOCAL ROLLBACK SEGMENT
ENABLE QUERY REWRITE
AS SELECT fcg, year, fcg_desc,
fac, efr, fac_desc, efr_desc,
ums_round, fcg_allow_drillable allow_drillable,
MAX(category_code_um1) category_code_um1,
SUM(perm_asset) perm_asset,
SUM(temp_asset) temp_asset,
SUM(semi_asset) semi_asset,
SUM(lease_asset) lease_asset,
SUM(planned_constr) planned_constr,
SUM(all_perm_asset) all_perm_asset,
SUM(total_asset) total_asset,
SUM(allow) allow, SUM(rqmt) rqmt,
SUM(perm_planned_constr) perm_planned_constr,
SUM(perm_planned_constr_rqmt_delta) perm_planned_constr_rqmt_delta,
ROUND(DECODE(SUM(rqmt), 0, 0, SUM(all_perm_asset)/SUM(rqmt)*100)) perm_rqmt_pctsat,
ROUND(DECODE(SUM(allow), 0, 0, SUM(all_perm_asset)/SUM(allow)*100)) perm_allw_pctsat,
ROUND(DECODE(SUM(rqmt), 0, 0, SUM(total_asset)/SUM(rqmt)*100)) total_rqmt_pctsat,
ROUND(DECODE(SUM(allow), 0, 0, SUM(total_asset)/SUM(allow)*100)) total_allw_pctsat,
ROUND(DECODE(SUM(all_perm_asset), 0, 0, SUM(rqmt)/SUM(all_perm_asset)*100)) perm_rqmt_pctutl,
ROUND(DECODE(SUM(all_perm_asset), 0, 0, SUM(allow)/SUM(all_perm_asset)*100)) perm_allw_pctutl,
ROUND(DECODE(SUM(total_asset), 0, 0, SUM(rqmt)/SUM(total_asset)*100)) total_rqmt_pctutl,
ROUND(DECODE(SUM(total_asset), 0, 0, SUM(allow)/SUM(total_asset)*100)) total_allw_pctutl,
SUM(coarse_screen_asset) coarse_screen_asset,
SUM(total_excess) total_excess,
SUM(total_deficit) total_deficit,
SUM(perm_excess) perm_excess,
SUM(perm_deficit) perm_deficit,
SUM(all_perm_excess) all_perm_excess,
SUM(all_perm_deficit) all_perm_deficit,
SUM(temp_excess) temp_excess,
SUM(satisfy_rqmt) satisfy_rqmt
FROM summary_tab_dd
GROUP BY fcg, year, fcg_desc,
fac, efr, fac_desc, efr_desc,
ums_round, fcg_allow_drillable;
sql plus> log in as parsing schema user (not APEX_PUBLIC_USER)
sql plus> SELECT fcg, year, fcg_desc,
SUM(perm_asset) perm_asset,
SUM(perm_excess) perm_excess,
SUM(perm_deficit) perm_deficit,
SUM(all_perm_excess) all_perm_excess,
SUM(all_perm_deficit) all_perm_deficit,
SUM(temp_excess) temp_excess,
SUM(satisfy_rqmt) satisfy_rqmt
FROM summary_tab_dd
where year=2007
GROUP BY fcg, year, fcg_desc;
--execution plan
SELECT STATEMENT ALL_ROWS 12 291 17460
HASH(GROUP BY) 12 291 17460
MAT_VIEW REWRITE ACCESS(FULL) RPLANSWEB.MV_FCG_ALL_SUMMARY_TAB ANALYZED 11 291 17460 "MV_FCG_ALL_SUMMARY_TAB"."YEAR"=2007
--execution plan from sql workshop (application express)
SELECT STATEMENT 42,341 55 3,882 1,990,027
HASH GROUP BY 42,341 55 3,882 1,990,027
TABLE ACCESS FULL SUMMARY_TAB_DD 109,158 47 3,329 5,130,426 "YEAR" = 2007
--execution plan from an APEX page (displayed from v$sql and V$SQL_PLAN)
OPERATION: SELECT STATEMENT OPTIONS: OBJECT_NAME: OBJECT_ALIAS: OBJECT_TYPE: OPTIMIZER: ALL_ROWS SEARCH_COLUMNS: 0 COST: 4600 CARDINALITY: BYTES: CPU_COST: IO_COST: ACCESS_PREDICATES: FILTER_PREDICATES: PROJECTION:
OPERATION: HASH OPTIONS: GROUP BY OBJECT_NAME: OBJECT_ALIAS: OBJECT_TYPE: OPTIMIZER: SEARCH_COLUMNS: 0 COST: 4600 CARDINALITY: 109158 BYTES: 8732640 CPU_COST: 549150132 IO_COST: 4569 ACCESS_PREDICATES: FILTER_PREDICATES: PROJECTION: "FCG"[VARCHAR2,6], "FCG_DESC"[VARCHAR2,15], SUM("PERM_DEFICIT")[22], SUM("PERM_EXCESS")[22], SUM("SATISFY_RQMT")[22], SUM("TEMP_EXCESS")[22], SUM("ALL_PERM_EXCESS")[22], SUM("ALL_PERM_DEFICIT")[22], SUM("PERM_ASSET")[22]
OPERATION: TABLE ACCESS OPTIONS: FULL OBJECT_NAME: SUMMARY_TAB_DD OBJECT_ALIAS: SUMMARY_TAB_DD@SEL$1 OBJECT_TYPE: TABLE OPTIMIZER: SEARCH_COLUMNS: 0 COST: 3329
as you can see while executing the script in sql developer the optimizer is finding the relevant materialized view, not in the case of APEX's SQL Workshop or Page.
appreciate your time -
Equivalent of Materialized Views in SQL Server
Hi
we are migrating Oracle Database to SQL Server 2012 and is looking for solution, equivalent to Materialized Views in Oracle.
we had tried to implement indexed View, but that was not possible, because the MVs have outer joins, subqueries, aggregate functions and also there is no column in it which can act as a Primary Key.
Please Help to get a solution for this issue.
Regards
Joyasree Mondal>use tempdb
>drop table t
>go
>create table t(id int, constraint pk_t primary key (id))
>
>go
>insert into t(id)
>select top 1000 cast( cast( newid() as binary(4) ) as int)
>from sys.objects o, sys.columns c
>go 100
>
>
>select id
>from t with (index=pk_t, tablockx)
>
>
>select id
>from t with (index=pk_t, nolock)
Still the same order.
>> No, its always in the key order like I've shown here.
> You are extrapolating from a single example.
Actually, this information doesn't even come from my exampleS (there were quite a few so far). Its written in the article you posted here. My examples are meant to confirm that and explain why the ORDER BY clause is redundant in some cases.
> I have. ORDER BY in a view used to always return ordered results. Then it didn't.
Examples? References?
>GROUP BY without an ORDER BY used to always return ordered results. Then it didn't. Many queries have >change the result ordering when you get a parallel plan.
Now you finally admit ordered results would always be returned, even without an order by clause. We are in the right track it appears. The reason for this change of behavior is a variation in the logical operator used by the query optimizer, and not the
way the engine reads pages from disk.
In the beginning of times there was stream aggregate, an operator that would require its input to be sorted. And this is how a GROUP BY clause would ensure results were always ordered.
But then his ugly cousin came and messed things up. He doesnt need an ordered input so yeah, order would be random. AGAIN, there are still ways of enforcing order here, through query hints, without requiring an order by clause, so this changes nothing.
You have confirmed that for a given operator, results will always be ordered. Your own argument has, once again, proven my point.
> Right. But there are different _kinds_ of scans. An ordered scan, where SQL Server reads rows based on the logical order of the index is just one kind.
It only won't scan in key order (by scheduling reads) if you change the transaction isolation level and hope for the worse. Because the key order scan is the best performing way of reading pages, this behavior (although possible) wasan't even observed in
the example with NOLOCK/TABLOCK (known to cause allocation-order scans in larger tables) you posted above.
> Other kinds include the parallel scan, the reverse scan,
References?
> the merry-go-round scan,
Only applies to table scans, not indexes.
http://technet.microsoft.com/en-us/library/ms191475%28v=SQL.105%29.aspx
> And the allocation-order (or unordered) scan.
Only if you specify TABLOCK or NOLOCK query hints, which I haven't done. This is something that goes without saying, it's irrelevant to an indexed view scenario such as this one.
Some people have also said it will perform an allocation-order scan if the index is too fragmented in SQL Server 2005, but as of 2012 it (probably) won't, as I have shown here. There is also no document anywhere in the internet (you are free to search for
it), that would point us otherwise. If you have access to additional information, I would be more than happy if you could share it with us.
Reference: http://sqlmag.com/database-development/quaere-verum-clustered-index-scans-part-iii
> And don't take my word for it. Take Conor Cunningham's:
>If you need order in your query results, put in an ORDER BY. It's that simple. Anything else is like >riding in a car without a seatbelt.
>No Seatbelt - Expecting Order without ORDER BY
Again, with all due respect, did you read your own article? Did you read what I said earlier about having multiple I/O threads as a whole other situation? If you add new variables, OF COURSE the results will be different. Parallelism was disabled in the
server I performed these tests on, but still you can control this by query hints, and you can enforce execution plans by using plan gudes.
Its like I always say - it's always about the 0.001% of situations, the exceptions, rather than the general rule.
Tell Mr Connor to add MAXDOP 1 to his querys OPTION clause and see if results are still unordered lol
References:
http://msdn.microsoft.com/en-us/library/ms190417.aspx
http://msdn.microsoft.com/en-us/library/ms181714.aspx
http://technet.microsoft.com/en-us/library/ms188611%28v=sql.105%29.aspx
http://blogs.msdn.com/b/conor_cunningham_msft/archive/2008/08/27/no-seatbelt-expecting-order-without-order-by.aspx
Imagining uncontrollable factors that would get an ordered input to be retrieved in an unordered manner is one of SQL Server's myths. There are a whole other people around who think the same way because of some experiences they had when they didn't know
how to control the execution plan, and adding an order by clause is a very popular and easy shortcut to a complex problem. "In the worst cases it will just be redundant", they say. What they like to forget is that sorting has an often high cost,
and it can be avoided by taking advantage of indexes. -
Advantage of Materialized view on prebuilt table
Could someone tell me the advantage of Materialized view on prebuilt table?. I'm unable to understand the concept from the Oracle documentation. I need to know the answers for following questions.
1) Is the data stored in table and MV same?. Does the query retrive data from table or MV?. The query internally uses either table or a view as the names of both are same.
2) Our DSS application is generating complicated queries and executing for long time. Is there any way I can optimize those queries using MV without rewriting the code in the application.It's a roughly analgous problem to figuring out what set of indexes to create to improve the performance of an application-- you need to understand the various queries, how the application is accessing data, and you need to balance a variety of competing needs in order to come up with a reasonable set of indexes.
Fundamentally, Oracle can only use a materialized view to satisfy a query if a human could use just the data in the materialized view to answer the question. That generally means that the materialized view is going to have to be aggregated at a lower level or at the same level as the query. A materialized view that aggregates sales by day can be used for queries by year but a materialized view that aggregates sales by year cannot be used for queries that get sales by day. A materiailized view that aggregates sales by vendor and product can be used for queries that aggregate by vendor or by product, but a materialized view that aggregates by product cannot be used in a query that aggregates by product for a particular vendor.
You'll have to balance what materialized views are ideal for a particular query, what materialized views are sufficient for a particular set of queries, and how to balance the space, managability, and refresh performance requirements between creating lots of somewhat redundant materialized views that provide optimal query performance at the cost of a lot of disk and a large refresh window vs creating fewer, more general materialized views that consume less disk and can be refreshed faster but that provide less query performance boosts.
Justin
Maybe you are looking for
-
Is Photoshop 7.0 compatible with Windows 8.1?
Is Photoshop 7.0 compatible with Windows 8.1?
-
Sync User with Shared Services
I noticed that if I provision a user in shared services the user can not log into planning until I restart planning. Is there a way to do this without restarting planning? This also seems to happen with EPM. I know this happens with essbase but you c
-
Can I use excel type functions embedded into an online pdf form, ie Qty x Price= total $
Can I use excel type functions embedded into an online pdf form, ie Qty x Price= total $
-
Assignment of company code to the Equipment.
Hi All, I am new-able in sap pm please guide me. During creation of Equipment why we are assigning the Company Code, if plant is already assign. What is the need of company code. Thanks & Regards, B.K.Pathak.
-
I dont have InDesign installed but CC shows I did the update?
I have a huge problem, I'll explain everything step by step before I'll ask my question: A few months ago I installed CC Photoshop, Illustrator and Indesign (just the "testversion") and as I wasnt able to pay the whole thing I tried to delete it, so