Different execution of a Workbook

Hi all,
I'm facing a strange problem: on a 3.0b BW System I created a Workbook with 3 queries and some VBA. If I execute the workbook via User Menu it seems that the VBA doesn't work; if I execute the Workbook via Analyzer (via Business Explorer menu in "Start -> Programs -> Business Explorer...") it works with non problem. Does anybody face the same problem? Is there a solution? I tryied with some GUIs: only 6.20 GUIs have no problem!!!!
Please help,
Thanks,
M.

Hi,
Check how and where you are calling your VBA code, for example if you are calling VBA code on BEx on refresh, then probably when you are opening from Menu this function is not triggered and not calling VBA code.
Regards,
Kams

Similar Messages

Initial execution of a workbook/query runs without ending

Hi, Experts,
I encountered a very strange behavior of Bex tool. Sometimes, Initial execution of a workbook/query runs without ending at u2018Waiting for reply from BW Serveru2019 state, then I cancel the report and run it again and it would return results within minutes. Itu2019s like it forgot to return results.
The basis team looked at the queries in the database, and said that there were actually a number of different queries being executed by my Bex query, but each individual query runs fairly quickly. The basis person pulled the statements out and ran them directly against the database and they returned result in sub seconds.
Any thoughts? Possible solution?
Thanks
Chimei

Hi,
Could u let us know what is the GUI frontend patch version you are on. Also, are there any AddOn's Installed.
What version of Excel are you using. Also just for a check, run sapbexc.xla on your local machine and check the output.
Regards,
Sree.

Same query at same time, but different execution plans from two schemas

Hi!
We just had some performance problems in our production system and I would like to ask for some advice from you.
We had a select-query that was run from USER1 on SCHEMA1, and it ran a table scan on a huge table.
Using session browser in TOAD I copied the Sql-statement, logged on SCHEMA1 and ran the same query. I got a different execution plan where I avoided the table scan.
So my question is:
How is it possible that the same query get different execution plans when running in two different schemas at the same time.
Some more information:
The user USER1 runs "alter session set current_schema=SCHEMA1;" when it logs on. Besides that it doesn't do anything so session parameter values are the same for USER1 and SCHEMA1.
SCHEMA1 is the schema owning the tables.
ALL_ROWS is used for both USER1 and SCHEMA1
Our database:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
PL/SQL Release 9.2.0.8.0 - Production
CORE 9.2.0.8.0 Production
TNS for Linux: Version 9.2.0.8.0 - Production
NLSRTL Version 9.2.0.8.0 - Production
Anybody has some suggestions to why I experience different execution plan for the same query, run at the same time, but from different users?

Thanks for clarification of the schema structure.
What happens if instead of setting the current session schema to SCHEMA1, if you simply add the schema name to alle tables, views and other objects inside your select statement?
As in select * from schema1.dual;I know that this is not what you want eventually, but it might help to find any misleading objects.
Furthermore it is not clear what you meant with: "avoided a table scan".
Did you avoid a full table scan (FTS) or was the table completely removed from the execution plan?
Can you post both plans?
Edited by: Sven W. on Mar 30, 2010 5:27 PM

Same sqlID with different execution plan and Elapsed Time (s), Executions time

Hello All,
The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
17th Oct 18th Oct
221,808,602
21
2tc2d3u52rppt
213,170,100
72,495,618
9c8wqzz7kyf37
209,239,059
71,477,888
9c8wqzz7kyf37
139,331,777
1
7b0kzmf0pfpzn
144,813,295
1
0cqc3bxxd1yqy
102,045,818
1
8vp1ap3af0ma5
128,892,787
16,673,829
84cqfur5na6fg
89,485,065
1
5kk8nd3uzkw13
127,467,250
16,642,939
1uz87xssm312g
67,520,695
8,058,820
a9n705a9gfb71
104,490,582
12,443,376
a9n705a9gfb71
62,627,205
1
ctwjy8cs6vng2
101,677,382
15,147,771
3p8q3q0scmr2k
57,965,892
268,353
akp7vwtyfmuas
98,000,414
1
0ybdwg85v9v6m
57,519,802
53
1kn9bv63xvjtc
87,293,909
1
5kk8nd3uzkw13
52,690,398
0
9btkg0axsk114
77,786,274
74
1kn9bv63xvjtc
34,767,882
1,003
bdgma0tn8ajz9
Not only queries are different but also the number of blocks read by top 10 queries are much higher on 17th than 18th.
The other big difference is the average read time on two days
Tablespace IO Stats
17th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
947,766
59
4.24
4.86
185,084
11
2,887
6.42
UNDOTBS2
517,609
32
4.27
1.00
112,070
7
108
11.85
INDUS_MST_DATA01
288,994
18
8.63
8.38
52,541
3
23,490
7.45
INDUS_TRN_INDX01
223,581
14
11.50
2.03
59,882
4
533
4.26
TEMP
198,936
12
2.77
17.88
11,179
1
732
2.13
INDUS_LOG_DATA01
45,838
3
4.81
14.36
348
0
1
0.00
INDUS_TMP_DATA01
44,020
3
4.41
16.55
244
0
1,587
4.79
SYSAUX
19,373
1
19.81
1.05
14,489
1
0
0.00
INDUS_LOG_INDX01
17,559
1
4.75
1.96
2,837
0
2
0.00
SYSTEM
7,881
0
12.15
1.04
1,361
0
109
7.71
INDUS_TMP_INDX01
1,873
0
11.48
13.62
231
0
0
0.00
INDUS_MST_INDX01
256
0
13.09
1.04
194
0
2
10.00
UNDOTBS1
70
0
1.86
1.00
60
0
0
0.00
STG_DATA01
63
0
1.27
1.00
60
0
0
0.00
USERS
63
0
0.32
1.00
60
0
0
0.00
INDUS_LOB_DATA01
62
0
0.32
1.00
60
0
0
0.00
TS_AUDIT
62
0
0.48
1.00
60
0
0
0.00
18th Oct
Tablespace
Reads
Av Reads/s
Av Rd(ms)
Av Blks/Rd
Writes
Av Writes/s
Buffer Waits
Av Buf Wt(ms)
INDUS_TRN_DATA01
980,283
91
1.40
4.74

The AWR reports for two days with same sqlID with different execution plan and Elapsed Time (s), Executions time please help me to find out what is reason for this change.
Please find the below detail 17th day my process are very slow as compare to 18th
You wrote with different execution plan, I think, you saw plans. It is very difficult, you get old plan.
I think Execution plans is not changed in different days, if you not added index or ...
What say ADDM report about this script?
As you know, It is normally, different Elapsed Time for same statement in different day.
It is depend your database workload.
It think you must use SQL Access and SQl Tuning advisor for this script.
You can get solution for slow running problem.
Regards
Mahir M. Quluzade

Different execution times for back ground jobs - why?

We have few jobs scheduled and each time they run, we see a different execution times. Some times, it increases and some times it decreases steeply . What could be the reasons?
Note:
1. We have the same load of jobs on the system in all the cases.
2. We haven't changed any settings at system level.
3. Data is more or less at the same range in all the executions.
4. We mainly run these jobs
Thanks,
Kiran
Edited by: kiran dasari on Mar 29, 2010 7:12 PM

Thank you Sandra.
We have no RFC calls or other instances. Ours is a very simple system. We have two monster jobs, the first one for HR dataand second an extract program to update a Z table for BW loads.
Our basis and admin confirmed that there are no network issues
Note: We are executing these jobs over the weekend nights.
Thanks,
Kiran

Same Query returning different result (Different execution plan)

Hi all,
To day i have discovered a strange thing: a query that return a different result when using a different execution plan.
The query :
SELECT *
FROM schema.table@database a
WHERE     column1 IN ('3')
       AND column2 = '101'
       AND EXISTS
              (SELECT null
                 FROM schema.table2 c
                WHERE a.column3 = SUBSTR (c.column1, 2, 12));where schema.table@database is a remote table.
when executed with the hint /*+ ordered use_nl(a c) */ these query return no result and its execution plan is :
Rows     Row Source Operation
      0 NESTED LOOPS (cr=31 r=0 w=0 time=4894659 us)
   4323   SORT UNIQUE (cr=31 r=0 w=0 time=50835 us)
   4336    TABLE ACCESS FULL TABLE2 (cr=31 r=0 w=0 time=7607 us)
      0   REMOTE (cr=0 r=0 w=0 time=130536 us)When i changed the execution plan with the hint /*+ use_hash(c a) */
Rows     Row Source Operation
   3702 HASH JOIN SEMI (cr=35 r=0 w=0 time=497839 us)
22556   REMOTE (cr=0 r=0 w=0 time=401176 us)
   4336   TABLE ACCESS FULL TABLE2 (cr=35 r=0 w=0 time=7709 us)It seem that when the execution plan have changed the remote query return no result.
It'is a bug or i have missed somthing ?
PS: The two table are no subject to insert or update statement.
Oracle version : 9.2.0.2.0
System version : HP-UX v1
Thanks.

H.Mahmoud wrote:
Oracle version : 9.2.0.2.0
System version : HP-UX v1Hard to say. You're using a very old and deprecated version of the database, and one that was known to contain bugs.
9.2.0.7 was really the lowest version of 9i that was considered to be 'stable', but even so, it's old and lacking in many ways.
Consider upgrading to the latest database version at your earliest opportunity. (or at least apply patches up to the latest 9i version before querying if there is bugs in your really low buggy version)

Problem with different execution paths in hierarchical query

Hello,
I have problems with the following query:
SELECT DISTINCT P.ID FROM PRODUCTELEMENTIMPL P WHERE ( ( LABEL = 'SomeLabel' AND PRODUCTELEMENTTYPE = 'SomeText' AND ( STATE = 'created' OR STATE = 'stored' OR STATE = 'archived' OR STATE = 'archivedRestored' ) ) ) START WITH P.ID = 42 CONNECT BY PRIOR P.ID = P.PARENT
We have two databases (an Oracle 10g XE and Oracle10g Enterprise). In the XE Database the query is executed very fast, but in the main installation it takes minutes. If I "explain" the query I get two different execution paths:
The fast:
ID      PARENT_ID      LEVEL      SQL      Kosten      Anzahl Zeilen
0      -      1      SELECT STATEMENT      20      49
1      0      2      HASH UNIQUE      20      49
2      1      3      FILTER      -      -
3      2      4      CONNECT BY WITH FILTERING      -      -
4      3      5      TABLE ACCESS BY INDEX ROWID PRODUCTELEMENTIMPL (TABLE)      -      -
5      4      6      INDEX UNIQUE SCAN SYS_C0072201 (INDEX (UNIQUE))      2      1
6      3      5      NESTED LOOPS      -      -
7      6      6      BUFFER SORT      -      -
8      7      7      CONNECT BY PUMP      -      -
9      6      6      TABLE ACCESS BY INDEX ROWID PRODUCTELEMENTIMPL (TABLE)      19      49
10      9      7      INDEX RANGE SCAN PRODUCTELEMENTIMPL_IDX1 (INDEX)      3      49
11      3      5      TABLE ACCESS FULL PRODUCTELEMENTIMPL (TABLE)      19      49
Slow:
ID PARENT_ID LEVEL SQL Kosten Anzahl Zeilen
0 1 SELECT STATEMENT 1 1
1 0 2 HASH UNIQUE 1 1
2 1 3 FILTER
3 2 4 CONNECT BY WITHOUT FILTERING
4 3 5 TABLE ACCESS BY INDEX ROW 3 1
ID PRODUCTELEMENTIMPL (TABLE)
5 4 6 INDEX UNIQUE SCAN SYS_C0 2 1
020528 (INDEX (UNIQUE))
6 3 5 TABLE ACCESS FULL PRODUCT 6628 1100613
ELEMENTIMPL (TABLE)
Any ideas how to avoid this full table scan?
bye
Roland Spatzenegger

Hello,
thank you for your replies. The indices and table schemas are the "same", but only the content for the tables was mirrored.
We made some tests with dropping and/or analyzing the tables, but it didn't change anything.
The main problem is that the query takes 33s in the productive environment for searching in a couple of rows. At the moment it's faster to make
SELECT DISTINCT P.ID, P.STATE FROM PRODUCTELEMENTIMPL P WHERE ( ( LABEL = 'SomeLabel' AND PRODUCTELEMENTTYPE = 'SomeText' ) ) START WITH P.ID = 42 CONNECT BY PRIOR P.ID = P.PARENT
and to test in the application if the state-values match ;-)
If I add the hint /*+ no_filtering */ in the test environment, I get the same "slow" execution path as in the production environment. So the question is, what prevents the filtering in "connect by"?
(I think in the fast version it filters only the results of the hierarchical query, in the slow version it first filters the whole table and joins/merge it with the hierachical result).
bye
Roland Spatzenegger

Populate Result of query in Different worksheets of One Workbook in Excel.

I want to get output of different queries to be populated in Different Sheets of a workbook of Excel in Unix/Linux Environment.

Here is an example perl script using the Spreadsheet::WriteExcel CPAN module that might help:
===#!/usr/bin/perl
use strict;
use DBI;
use Spreadsheet::WriteExcel;
my ($toc,$data_sheet,$f,%data,$workbook) = ();
my ($workbook_filename) = "mytest.xls";
$workbook = Spreadsheet::WriteExcel->new($workbook_filename);
sub build_excel_workbook {
$workbook->compatibility_mode();
$f = \%{$data{excel_format}};
$$f{bold} = $workbook->add_format();
$$f{bold}->set_bold();
$$f{right_align} = $workbook->add_format();
$$f{right_align}->set_align("right");
$toc = \%{$data{excel_table_of_contents}};
$$toc{tab} = $workbook->add_worksheet("Table of Contents");
$$toc{tab}->freeze_panes(1,0);
$$toc{tab}->set_column(0,1,20);
$$toc{tab}->write(0,0,"WorkSheet Name",$$f{bold});
$$toc{tab}->write(0,1,"Comments",$$f{bold});
$data_sheet = \%{$data{excel_data_sheet}};
$$data_sheet{tab} = $workbook->add_worksheet("EMP table");
$$data_sheet{current_row} = 0;
$$toc{tab}->write(1,0,"EMP table");
$$toc{tab}->write(1,1,"Example WorkSheet containing EMP sample data");
build_excel_workbook();
my $db = DBI->connect( "dbi:Oracle:Local", "scott", "tiger" )
    || die( $DBI::errstr . "\n" );
$db->{AutoCommit}    = 0;
$db->{RaiseError}    = 1;
$db->{ora_check_sql} = 0;
$db->{RowCacheSize} = 16;
my $SEL = "SELECT * FROM EMP";
my $sth = $db->prepare($SEL);
$sth->execute();
while ( my @row = $sth->fetchrow_array() ) {
    for (my $i = 0; $i <= $#row; $i++) {
        $$data_sheet{tab}->write($$data_sheet{current_row},$i,$row[$i]);
    $$data_sheet{current_row}++;
END { $db->disconnect if defined($db); }
#end_script===
Best Regards,
Bryan Wood
Edited by: BryanWood on Jan 26, 2012 4:07 PM
Edited by: BryanWood on Jan 26, 2012 4:10 PM

Problem with optimiser choosing different execution path to that expected!

We have a sql statement that uses sub-query factoring, and a materialize hint in one of the sub-queries. The query runs fine for me when I do the query manually - it does the Temp Table Transformation as I expect it to (due to the materialize hint). The query runs in under 2 mins, and the explain plan says a cost of 154.
Take away the materialize hint, and I get an execution path with a cost of 149, and the query runs in just under 2 hours (!). The explain plan then contains two filter steps, listing the predicates (not exists).
The problem we're seeing is that when we run the overall process that runs the sql statement and outputs the results to file, instead of it using the materialized explain plan, it appears to be using the non-materialized explain plan, but the predicates bit just says "IS NULL". It has a cost of 149.
I suspect that the optimiser has somehow worked out that the sub-query in question actually returns no rows, and has therefore worked out a "cheaper" method of getting the results. Thing is, I run the exact same (unfortunately, not bound) query manually and it uses the materialized explain plan!
The process does run the sub-query in question on it's own, but without the materialized hint. I've done similar manually, just in case this affects things by having the results in memory, but it didn't alter the fact that I still got the materialized plan.
I'm at a loss as to how it knows that the sub-query returns no rows, and as to why the same query is effectively giving two different execution paths under the same circumstances.
Can anyone give me their thoughts as to what might be happening with the predicates bit, or any pointers as to where to look next, please?
TIA

Yes, it's the same database, so same data, same statistics, same user, etc.
This is with the materialized hint:
Time     IO Cost     CPU Cost     Cardinality     Bytes     Cost     Plan
1     110     2,349,615     1     316     154     SELECT STATEMENT ALL_ROWS
24      24      24      24      24      24           24 TEMP TABLE TRANSFORMATION
6      6      6      6      6      6                6 LOAD AS SELECT BROIL_FEED.DIM_CURVE_MAPPING
5      5      5      5      5      5                     5 FILTER Filter Predicates: NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM1" WHERE "CM1"."TRADE_NAME"=:B1 AND "CM1"."RISK_TYPE"='TVReport' AND "CM1"."RUN_ID"=:B2) OR NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM2" WHERE "CM2"."TRADE_NAME"=:B3 AND "CM2"."RISK_TYPE"='Delta' AND "CM2"."RUN_ID"=:B4) OR NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM3" WHERE "CM3"."TRADE_NAME"=:B5 AND "CM3"."RISK_TYPE"='Issuer' AND "CM3"."RUN_ID"=:B6)
1 1     1 4     1 28,686     1 1     1 19     1 5                         1 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "RUN_ID"=207270
2 1     2 4     2 28,686     2 1     2 29     2 5                         2 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM1"."RUN_ID"=:B1 AND "CM1"."RISK_TYPE"='TVReport' AND "CM1"."TRADE_NAME"=:B2
3 1     3 4     3 29,086     3 2     3 58     3 5                         3 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM2"."RUN_ID"=:B1 AND "CM2"."RISK_TYPE"='Delta' AND "CM2"."TRADE_NAME"=:B2
4 1     4 4     4 29,086     4 2     4 58     4 5                         4 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM3"."RUN_ID"=:B1 AND "CM3"."RISK_TYPE"='Issuer' AND "CM3"."TRADE_NAME"=:B2
23 1     23 106     23 2,320,930     23 1     23 316     23 149               23 WINDOW SORT
22      22      22      22      22      22                     22 FILTER Filter Predicates: NOT EXISTS (SELECT /*+ */ 0 FROM (SELECT /*+ CACHE_TEMP_TABLE ("T1") */ "C0" "TRADENAME" FROM "SYS"."SYS_TEMP_0FD9D6638_7866E0A0" "T1") "ERRORED_TRADES" WHERE LNNVL("TRADENAME"<>:B1))
19 1     19 101     19 2,313,658     19 2     19 632     19 144                         19 HASH JOIN OUTER Access Predicates: "THEDATA"."BUCKET"="TENOR"(+)
17 1     17 12     17 252,229     17 2     17 598     17 17                              17 NESTED LOOPS OUTER
14 1     14 10     14 233,806     14 2     14 442     14 14                                   14 VIEW BROIL_FEED.
13 1     13 5     13 90,069     13 2     13 174     13 14                                        13 SORT UNIQUE
12      12      12      12      12      12                                              12 UNION-ALL
8 1     8 5     8 36,349     8 1     8 89     8 6                                                  8 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.CREDIT_MRCDATA Filter Predicates: "CM"."RISK_TYPE"='Delta' OR "CM"."RISK_TYPE"='TVReport' OR "CM"."RISK_TYPE"='Issuer' AND "CM"."SHOCK"=0
7 1     7 4     7 28,686     7 1     7      7 5                                                       7 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM"."RUN_ID"=207270
11 1     11 5     11 143,737     11 1     11 85     11 8                                                  11 HASH GROUP BY
10 1     10 5     10 36,297     10 1     10 85     10 6                                                       10 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.CREDIT_MRCDATA
9 1     9 4     9 28,686     9 1     9      9 5                                                            9 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "RUN_ID"=207270 AND "RISK_TYPE"='Delta'
16 1     16 1     16 9,211     16 1     16 78     16 1                                   16 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.DIM_CURVE_MAPPING
15 1     15 0     15 1,900     15 1     15      15 0                                        15 INDEX UNIQUE SCAN INDEX (UNIQUE) BROIL_FEED.DIM_RISK_CURVENAME Access Predicates: "THEDATA"."RISK_CURVE_NAME"="DIM_CURVE_MAPPING"."RISK_CURVE_NAME"(+)
18 1     18 89     18 1,450,669     18 5,836     18 99,212     18 116                              18 TABLE ACCESS FULL TABLE BROIL_FEED.DIM_TENOR
21 1     21 5     21 7,271     21 1     21 77     21 5                         21 VIEW BROIL_FEED. Filter Predicates: LNNVL("TRADENAME"<>:B1)
20 1     20 5     20 7,271     20 1     20 14     20 5                              20 TABLE ACCESS FULL TABLE (TEMP) SYS.SYS_TEMP_0FD9D6638_7866E0A0                This is the explain plan for the query without the materialized hint:
Time     IO Cost     CPU Cost     Cardinality     Bytes     Cost     Plan
1     105     2,342,394     1     316     149     SELECT STATEMENT ALL_ROWS
20 1     20 105     20 2,342,394     20 1     20 316     20 149          20 WINDOW SORT
19      19      19      19      19      19                19 FILTER Filter Predicates: NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "SYS_ALIAS_6" WHERE ( NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM1" WHERE "CM1"."TRADE_NAME"=:B1 AND "CM1"."RISK_TYPE"='TVReport' AND "CM1"."RUN_ID"=:B2) OR NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM2" WHERE "CM2"."TRADE_NAME"=:B3 AND "CM2"."RISK_TYPE"='Delta' AND "CM2"."RUN_ID"=:B4) OR NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM3" WHERE "CM3"."TRADE_NAME"=:B5 AND "CM3"."RISK_TYPE"='Issuer' AND "CM3"."RUN_ID"=:B6)) AND "RUN_ID"=207270 AND LNNVL("TRADE_NAME"<>:B7))
13 1     13 101     13 2,313,658     13 2     13 632     13 144                    13 HASH JOIN OUTER Access Predicates: "THEDATA"."BUCKET"="TENOR"(+)
11 1     11 12     11 252,229     11 2     11 598     11 17                         11 NESTED LOOPS OUTER
8 1     8 10     8 233,806     8 2     8 442     8 14                              8 VIEW BROIL_FEED.
7 1     7 5     7 90,069     7 2     7 174     7 14                                   7 SORT UNIQUE
6      6      6      6      6      6                                         6 UNION-ALL
2 1     2 5     2 36,349     2 1     2 89     2 6                                             2 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.CREDIT_MRCDATA Filter Predicates: "CM"."RISK_TYPE"='Delta' OR "CM"."RISK_TYPE"='TVReport' OR "CM"."RISK_TYPE"='Issuer' AND "CM"."SHOCK"=0
1 1     1 4     1 28,686     1 1     1      1 5                                                  1 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM"."RUN_ID"=207270
5 1     5 5     5 143,737     5 1     5 85     5 8                                             5 HASH GROUP BY
4 1     4 5     4 36,297     4 1     4 85     4 6                                                  4 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.CREDIT_MRCDATA
3 1     3 4     3 28,686     3 1     3      3 5                                                       3 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "RUN_ID"=207270 AND "RISK_TYPE"='Delta'
10 1     10 1     10 9,211     10 1     10 78     10 1                              10 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.DIM_CURVE_MAPPING
9 1     9 0     9 1,900     9 1     9      9 0                                   9 INDEX UNIQUE SCAN INDEX (UNIQUE) BROIL_FEED.DIM_RISK_CURVENAME Access Predicates: "THEDATA"."RISK_CURVE_NAME"="DIM_CURVE_MAPPING"."RISK_CURVE_NAME"(+)
12 1     12 89     12 1,450,669     12 5,836     12 99,212     12 116                         12 TABLE ACCESS FULL TABLE BROIL_FEED.DIM_TENOR
18      18      18      18      18      18                     18 FILTER Filter Predicates: NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM1" WHERE "CM1"."TRADE_NAME"=:B1 AND "CM1"."RISK_TYPE"='TVReport' AND "CM1"."RUN_ID"=:B2) OR NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM2" WHERE "CM2"."TRADE_NAME"=:B3 AND "CM2"."RISK_TYPE"='Delta' AND "CM2"."RUN_ID"=:B4) OR NOT EXISTS (SELECT /*+ */ 0 FROM "CREDIT_MRCDATA" "CM3" WHERE "CM3"."TRADE_NAME"=:B5 AND "CM3"."RISK_TYPE"='Issuer' AND "CM3"."RUN_ID"=:B6)
14 1     14 4     14 28,736     14 1     14 19     14 5                         14 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "RUN_ID"=207270 Filter Predicates: LNNVL("TRADE_NAME"<>:B1)
15 1     15 4     15 28,686     15 1     15 29     15 5                         15 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM1"."RUN_ID"=:B1 AND "CM1"."RISK_TYPE"='TVReport' AND "CM1"."TRADE_NAME"=:B2
16 1     16 4     16 29,086     16 2     16 58     16 5                         16 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM2"."RUN_ID"=:B1 AND "CM2"."RISK_TYPE"='Delta' AND "CM2"."TRADE_NAME"=:B2
17 1     17 4     17 29,086     17 2     17 58     17 5                         17 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM3"."RUN_ID"=:B1 AND "CM3"."RISK_TYPE"='Issuer' AND "CM3"."TRADE_NAME"=:B2      And this is what the process is running:
Time     IO Cost     CPU Cost     Cardinality     Bytes     Cost     Plan
                         149     SELECT STATEMENT ALL_ROWS
20 1     20 105     20 2,342,394     20 1     20 316     20 149          20 WINDOW SORT
19      19      19      19      19      19                19 FILTER Filter Predicates: IS NULL
13 1     13 101     13 2,313,658     13 2     13 632     13 144                    13 HASH JOIN OUTER Access Predicates: "THEDATA"."BUCKET"="TENOR"
11 1     11 12     11 252,229     11 2     11 598     11 17                         11 NESTED LOOPS OUTER
8 1     8 10     8 233,806     8 2     8 442     8 14                              8 VIEW
7 1     7 5     7 90,069     7 2     7 174     7 14                                   7 SORT UNIQUE
6      6      6      6      6      6                                         6 UNION-ALL
2 1     2 5     2 36,349     2 1     2 89     2 6                                             2 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.CREDIT_MRCDATA Filter Predicates: (INTERNAL_FUNCTION("CM"."RISK_TYPE") OR ("CM"."RISK_TYPE"='Issuer' AND "CM"."SHOCK"=0))
1 1     1 4     1 28,686     1 1     1      1 5                                                  1 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM"."RUN_ID"=207268
5 1     5 5     5 143,737     5 1     5 85     5 8                                             5 HASH GROUP BY
4 1     4 5     4 36,297     4 1     4 85     4 6                                                  4 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.CREDIT_MRCDATA
3 1     3 4     3 28,686     3 1     3      3 5                                                       3 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "RUN_ID"=207268 AND "RISK_TYPE"='Delta'
10 1     10 1     10 9,211     10 1     10 78     10 1                              10 TABLE ACCESS BY INDEX ROWID TABLE BROIL_FEED.DIM_CURVE_MAPPING
9      9 0     9 1,900     9 1     9      9 0                                   9 INDEX UNIQUE SCAN INDEX (UNIQUE) BROIL_FEED.DIM_RISK_CURVENAME Access Predicates: "THEDATA"."RISK_CURVE_NAME"="DIM_CURVE_MAPPING"."RISK_CURVE_NAME"
12 1     12 89     12 1,450,669     12 5,836     12 99,212     12 116                         12 TABLE ACCESS FULL TABLE BROIL_FEED.DIM_TENOR
18      18      18      18      18      18                     18 FILTER Filter Predicates: ( IS NULL OR IS NULL OR IS NULL)
14 1     14 4     14 28,736     14 1     14 19     14 5                         14 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "RUN_ID"=207268 Filter Predicates: LNNVL("TRADE_NAME"<>:B1)
15 1     15 4     15 28,686     15 1     15 29     15 5                         15 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM1"."RUN_ID"=:B1 AND "CM1"."RISK_TYPE"='TVReport' AND "CM1"."TRADE_NAME"=:B2
16 1     16 4     16 29,086     16 2     16 58     16 5                         16 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM2"."RUN_ID"=:B1 AND "CM2"."RISK_TYPE"='Delta' AND "CM2"."TRADE_NAME"=:B2
17 1     17 4     17 29,086     17 2     17 58     17 5                         17 INDEX RANGE SCAN INDEX BROIL_FEED.CREDIT_MRCDATA_IDX Access Predicates: "CM3"."RUN_ID"=:B1 AND "CM3"."RISK_TYPE"='Issuer' AND "CM3"."TRADE_NAME"=:B2      P.S., Forgot to mention - my database is 10.2.0.2.
Message was edited by:
Boneist

Same query with different execution plan

Hello All,
I wonder why does sql server create different execution plan for these below queries ?
Thanks.

You can look at the expected query plan. Either visually in SSMS, or alternatively, you can run the query after the instruction SET SHOWPLAN_TEXT ON.
The Optimizer is the component of SQL Server that determines how the query is executed. It is cost based. It will assess different execution plans, estimate the cost of each of them and then select the cheapest. In this context, cheapest means the one with
the shortest runtime.
In your particular case, the estimation for the second query is, that scanning just a small part of the nonclustered index and then looking up the table data of the qualifying rows is the cheapest approach, because the estimated number of qualifying rows
is low.
In the first query, it estimated that looking up the many qualifying rows there would be too expensive, and that it would be cheaper to simply scan the entire clustered index, and simply filter out all unwanted rows. Note that the clustered index includes
the actual table data.
Gert-Jan

Different execution time

Hello, when i run the bellow code more than one time i am getting different execution time("Total time taken"),
Ex. when i run first time it prints Total time taken 47
second time it prints Total time taken 16
thrid time Total time taken 78 ,why its vary,
Please solve my question
long l = System.currentTimeMillis();
System.out.println(l);
     for(int i=0; i <88; i++){
          System.out.print("Hello ");
     System.out.println("\n"+" Total time taken "+(System.currentTimeMillis() - l));

Its worth noting that the application is IO bound (due to printing to a device/console)
So you are really testing the performance of your IDE/console.
public static void main(String... args) throws IOException {
    int count = 100 * 1000;
    long start = 0;
    for (int i = -count / 10; i < count; i++) {
        if (i == 0)
            start = System.nanoTime();
        System.out.print("Hello ");
    long time = System.nanoTime() - start;
    System.out.printf("%nTotal time taken %,5d micro-seconds per call%n", time / count);
}

Need Different Selection screen for different Queries in a Workbook

Hi,
I have created a workbook with Multiple tabs in BI 7.0. Each Tab has different Queries and each query has different Selection screens (Variable Selections).
When i open the workbook and refresh it, the selection screen is appearing only for one query. All the queries are refreshed by this single selection screen, though each query has different Variable selections. What i need is a seperate selection screen i.e seperate Variable selection appearing for each queries, when i refresh each one of them.
Is it possible to do this? If anybody has tried this, help me in solving this issue. Thanks for ur time.
Regards,
Murali

Murali,
If you un-check the 'Display Duplicate Variables Only Once' this WILL solve your problem.
When you Refresh, you should be presented with a single variable selection dialog box, but it should contain an area for each Query (DataProvider) that is embedded in the Workbook.
This is the case if the queries are all on the same tab, or on different tabs.
However, if you have multiple tabs each with a query on it, each query must have it's own DataProvider. If all queries are based on the same DataProvider, it will not work as the Workbook only 'sees' one Query for which it needs variable input.
If you REALLY want multiple variable selection dialog boxes, then maybe the best way to do this is to have the queries in separate Workbooks.
If you don't want the User to have to open 5 queries manually, you could use a Macro in each Workbook that runs on opening, to open the next Workbook in the sequence.
I hope this makes sense!
Regards
Steve

Different 'execution plans' for same sql in 10R2

DB=10.2.0.5
OS=RHEL 3
Im not sure of this, but seeing different plans for same SQL.
select sql_text from v$sqlarea where sql_id='92mb4z83fg4st'; <---TOP SQL from AWR
SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","LOGINSUCCESSFLG",
"ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE"
FROM "BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY";
SQL> set autotrace traceonly
SQL> SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","LOGINSUCCESSFLG",
"ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE"
FROM "BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY"; 2 3
1822203 rows selected.
Execution Plan
Plan hash value: 568996432
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1803K| 75M| 2919 (2)| 00:00:36 |
| 1 | TABLE ACCESS FULL| ENDUSERLOGINATTEMPTHISTORY | 1803K| 75M| 2919 (2)| 00:00:36 |
Statistics
0 recursive calls
0 db block gets
133793 consistent gets
0 physical reads
0 redo size
76637183 bytes sent via SQL*Net to client
1336772 bytes received via SQL*Net from client
121482 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1822203 rows processed
===================================== another plan ===============
SQL> select * from TABLE(dbms_xplan.display_awr('92mb4z83fg4st'));
15 rows selected.
Execution Plan
Plan hash value: 3015018810
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY_AWR |
Note
- rule based optimizer used (consider using cbo)
Statistics
24 recursive calls
24 db block gets
49 consistent gets
0 physical reads
0 redo size
1529 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
15 rows processed
=========second one shows only 15 rows...
Which one is correct ?

Understood, second plan is for self 'dbms_xplan'.
Anyhow I opened a new session where I did NOT on 'auto-trace'. but plan is somewhat than the original.
SQL> /
PLAN_TABLE_OUTPUT
SQL_ID 92mb4z83fg4st
SELECT /*+ OPAQUE_TRANSFORM */ "ENDUSERID","LASTLOGINATTEMPTTIMESTAMP","LOGINSOURCECD","
LOGINSUCCESSFLG","ENDUSERLOGINATTEMPTHISTORYID","VERSION_NUM","CREATEDATE" FROM
"BOMB"."ENDUSERLOGINATTEMPTHISTORY" "ENDUSERLOGINATTEMPTHISTORY"
Plan hash value: 568996432
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | | | 2919 (100)| |
| 1 | TABLE ACCESS FULL| ENDUSERLOGINATTEMPTHISTORY | 1803K| 75M| 2919 (2)| 00:00:36 |
15 rows selected.
I am just wondering, which plan is the accurate and which I need to believe ?

Different execution plan in ApEx and SQL/PLUS

Hi
I have weird problem with sql query exectuion plans.
DB version: 10.2.0.1
ApEx version: 3.1.2
I have workspace parsed as SCHEMA1.
I have a view under different schema - SCHEMA2.view1 and a function SCHEMA2.func1.
I have a query like SELECT * from SCHEMA2.view1 WHERE col1 = SCHEMA2.func1(:bind1)
"col1" is a indexed column.
When I execute this query in SQL/PLUS under user SCHEMA1 with the same bind value, then index is used perfectly.
When I execute this query in ApEx report then index is not used, full scan is performed and hash join is done between the tables used in the view and explain plan shows that a view is formed during execution.
What can be the reason for such a different behaviour.
Statistics are freshly calculated, FIRST_ROWS hint doesn't help, using the INDEX hint results only index full scan.
This happens only if I use a view and pl/sql function together in the query. If I use view with Oracle built in function like NVL instead then it works perfectly. Also when I access directly the same tabels with the same PL/SQL function then the execution plan is perfect. Only if the view and pl/sql function is used together in the query then execution plan is bad.
It is not a problem of this specific query but, many different other queries with same pattern also. I have tried ApEx versions 3.0, 3.1.1 and 3.1.2.
At the same time the exectuion plan is good in SQL/PLUS and TOAD.
Any ideas?
Best regards,
jan

I didn't help. But I rewrote the queries so that there is no database view and PL/SQL function used in the same query. I still don't know the reason for such different behavior, but I just try to accept it and keep in mind for future :)
Thanks anyway!
jan

How to fix different execution plan for different bind variable values?

Please find the below query. The execution plan is fine. The problem That I am facing is in some cases for different bind variable values execution plan gets changed and degrades performance. I have used 6 tables here and all of the tables have histogram on all columns. Database version is Oracle 10g and the value of method_opt is 'For all columns size auto'
SELECT l.LineNumber INTO :b0
FROM Lines l ,LineVersions lv ,Statuses s
WHERE (((((((((((l.serviceContractId=:b1 AND l.LineId<>:b2)
AND lv.LineId=l.LineId) AND lv.StatusId=s.StatusId)
AND s.Code IN ('EPR','ERE','EEP','ERP','PRP','PRD','AAC'))
AND NOT (s.CODE='AAC' AND lv.activeto<TO_DATE(:b3,:b4)))
AND lv.EquipmentDetailId=:b5) AND lv.RouteDetailId=:b6)
AND (lv.cargoDetailId=:b7 OR lv.cargoDetailId IN
(SELECT i_cd1.cargoDetailId
FROM CargoDetails i_cd1 ,CargoDetails i_cd2 ,CargoCommodities i_cc1 ,
CargoCommodities i_cc2 WHERE
((((((i_cd2.cargoDetailId=:b7 AND i_cd1.cargoDetailId<>:b7)
AND i_cd1.ServiceContractId=:b1) AND i_cd1.cargoTypeId=i_cd2.cargoTypeId)
AND i_cc1.cargoDetailId=i_cd1.cargoDetailId)
AND i_cc2.cargoDetailId=i_cd2.cargoDetailId)
AND i_cc1.commodityId=i_cc2.commodityId))))
AND ((lv.customerGroupId IS NULL AND :b11=0) OR lv.customerGroupId IN
(SELECT cgm1.customerGroupId
FROM CustomerGroupMembers cgm1 ,CustomerGroupMembers cgm2 ,CustomerGroups cg1
WHERE (((cgm2.customerGroupId=:b11 AND cgm1.customerNoId=cgm2.customerNoId)
AND cg1.CustomerGroupId=cgm1.CustomerGroupId)
AND cg1.ServiceContractId=l.ServiceContractId)))) AND lv.linetype='C')
AND ROWNUM=1)
After searching in several blogs I have found the below solutions. Please see it and let me know it is correct or not
Solution 1:-Get rid of histogram that does nothing but messes up execution plan by giving below command
exec dbms_stats.gather_table_stats(owner, tablename, method_opt => 'for all columns size 1', cascade => true);
As 6 tables are there I need to execute above command 6 times.
Solution 2:- Use stored outline. Not sure how to get the best execution plan.
I am looking for answers ASAP. Thanks in advance

As you have probably read, bind variables and histograms do not mix well.
Histograms suggest that you have skew in your data such that different values should get different plans
Bind variables exist so that SQL with different supplied values can be shared.
Mix the two together and at parse time with bind variable peeking you get plans for specific values shared for all values.
The solutions you have mentioned are the common approaches, together with a third - use literals not binds if you've got data skew (i.e. your histograms are justified) and don't want shared SQL.
I would have thought that getting rid of some of these histograms may be the right approach if you're none of your application SQL is using literals to benefit from them.
Can you confirm your version of Oracle.
Further reading:
http://jonathanlewis.wordpress.com/2009/05/06/philosophy-1/
http://structureddata.org/2008/03/26/choosing-an-optimal-stats-gathering-strategy/
http://richardfoote.wordpress.com/2008/01/04/dbms_stats-method_opt-default-behaviour-changed-in-10g-be-careful/

Different execution of a Workbook

Similar Messages

Maybe you are looking for