9i execution path

Hi,
I upgraded oracle to 10g and want to use the 9i execution plan for my query, can anyone tell me how to set this in the database level and how to do it in the session level?
Thanks,
GK

Hi,
Take a look at OPTIMIZER_FEATURES_ENABLE db parameter.
Regards,
Andrew Velitchko
BrainBench MVP for Developer/2000
http://www.brainbench.com

Similar Messages

Inline subquery cardinality wrong, execution path not correct

hi:
i have a simple query , I just can not get the execution path correct. please advice .
SELECT *
FROM fcst_budget a,
SELECT *
FROM fcst_root_facility_all
WHERE salesman IN (200)
) b
WHERE a.ci=b.ci AND a.facility=b.facility
Plan
SELECT STATEMENT ALL_ROWSCost: 2,276 Bytes: 1,317,411 Cardinality: 1,593
3 HASH JOIN Cost: 2,276 Bytes: 1,317,411 Cardinality: 1,593
1 INDEX FAST FULL SCAN INDEX (UNIQUE) SALES.FCST_ROOT_FACILITY_ALL_PK Cost: 1,466 Bytes: 331,660 Cardinality: 515
2 TABLE ACCESS FULL TABLE SALES.FCST_BUDGET Cost: 807 Bytes: 27,628,425 Cardinality: 150,975
fcst_root_facility_all has 50K records, with index on salesman, pk = ci,facility
fcst_budget has 150K records, pk= ci,facility,yr_prd
the problem is it is always doing full table scan for fcst_budget, which is not what I am looking for.
the inline subquery output is only 80 records with unique ci and facility and the desired execution plan will be using inline
subquery as driving table to nested loop join the fcst_budget table, the pk for fcst_budget should be used.
Somehow, this just does not happen.
I tried to create a intermediate temp table to stage teh inline subquery result, and the result is good.
DROP TABLE aaa
CREATE TABLE aaa
AS
SELECT *
FROM fcst_root_facility_all
WHERE salesman IN (200)
SELECT *
FROM fcst_budget a,
aaa b
WHERE a.ci=b.ci AND a.facility=b.facility
Plan
SELECT STATEMENT ALL_ROWSCost: 193 Bytes: 937,890 Cardinality: 102
4 NESTED LOOPS Cost: 193 Bytes: 937,890 Cardinality: 102
1 TABLE ACCESS FULL TABLE SALES.AAA Cost: 4 Bytes: 720,960 Cardinality: 80
3 TABLE ACCESS BY INDEX ROWID TABLE SALES.FCST_BUDGET Cost: 3 Bytes: 183 Cardinality: 1
2 INDEX RANGE SCAN INDEX (UNIQUE) SALES.FCST_BUDGET_PK Cost: 2 Cardinality: 1
comparing two plans, you can see the first plan step1, the cardinality=515, which is actually should be 80 in this case.
Any body can help me tune this query to make Oracle optimizer pickup the correct plan?
I do not like the temp table solution case it decreases the scalability.
thanks

SamB:
Neither the /*+ cardinality (c 80) */ nor the USE_NL works.
I also regenerated historgrams, that did not help either.
Oracle is so persistent to use its own decision no matter what I tell it to do.
The amazing thing I found today after tried your hint is:
I re-analyze the fcst_root_facility_all table using DBMS_STATS.GATHER_TABLE_STATS
function, and magically, it worked.
I used to use analyze command to analyze table, seems there is some important accuracy difference between the two.
although still can not understand why some many hint does not work, I am OK for now.
thanks

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

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

How do I set execution path in VAPI-XP-TEST?

Hi,
I have created a VAPI-XP-TEST which calls my project's executable from it's Debug folder.
I am setting the path of the executable via Parameters.
My project has a configuration file which reads from some input files. I have given the relative path of the files in the configuration.
The relative path reads as ..//..//Input
So, the test needs to go 2 levels back from the "Debug" folder and get the contents of the "Input" folder.
My project runs fine as is.
However, when I hook up this exe to a VAPI-XP-TEST, the relative path accesses the install location of ALM instead of my Project's debug folder. Hence, the test fails as it is unable to find the Input folder.
How can I specify in my test script or through a setting, to take the path as my project's debug folder?
I have tried the following command just before I trigger the XTools.Run command, but it did not work.
Directory.SetCurrentDirectory(path) - where path is the path to my project's Debug folder.
Please help!

No, that's not quite what our friend Apple Certified was saying. In summary (from someone who has ballsed this exercise up a few times now):
1. Move your apple loops folder to the external drive. You'll then need to open logic and drag the loops folder on to the loops browser to make it re-index them.
2. You can move the EXS samples to the ext drive as suggested via the use of aliases. Do NOT move the sample instruments folder.
3. You can move the projects and related audio files to an external hard drive if you wish.
4. Be careful moving garage band instruments. You can move them in the same way you moved the EXS sounds, except for the Hybrid synthesizers. If you move them you'll have trouble later.
I'm sure someone will correct me if I've mis-stated anything, but from my experience those are the main points to focus on. Hope that helps.

Oracle taking a strange query execution path

I have a query which is admittedly a bit unconventional but Oracle is really doing something strange with it...
SELECT   GROUP_CODE, STATUS, COL3, COL4, ETC...
FROM MAIN_TABLE A
WHERE A.STATUS = 'COMPLETE' -- ONLY GET COMPLETE RECORDS...
    -- AND ONLY FOR THOSE WHERE THERE ARE NO INCOMPLETE RECORDS IN THE SAME GROUP
    AND (SELECT COUNT(*) FROM MAIN_TABLE B WHERE B.GROUP_CODE = A.GROUP_CODE AND B.STATUS != 'COMPLETE') = 0
ORDER BY GROUP_CODE
[\CODE]
This query is done on a table of ~100k records, and the result should only return about 100 or so records.
The only index in the table is on GROUP_CODE, and statistics are up-to-date.
The strange part is that the query takes over an hour to complete, UNLESS I take out the ORDER BY, then it takes only a few seconds!!! The difference is that with the ORDER BY, it is using the GROUP_CODE index (even with a */*+ NO_INDEX(MAIN_TABLE) */* hint in the query).
How can I either reorganize this query or prevent Oracle from taking the "incorrect" path?
Edited by: xaeryan on May 20, 2011 3:01 PM
Edited by: xaeryan on May 20, 2011 3:02 PM

try something as below..
select *
from
     select GROUP_CODE, STATUS, COL3, COL4, ETC...,
     max(case when STATUS != 'COMPLETE' then 1 ELSE 0 END) over( partition by GROUP_CODE) as mx
     from
     MAIN_TABLE
)X
where mx= 0 HTH...

Complete forms execution path plz help URGENT

Hi all,
How can i know the entire path of my current form being executed.
I want a complete path of my form eg:
c:\abc\form.fmx or d:\abc\form.fmx and so on.
whether the form is being executed from hard disk,floppy or cd.
I am using forms 5.0
Can anyone give me an idea plz.
navneet jain
[email protected]

use:
Get_application_property(current_form) for this
Good luck,
J

Complete execution path of current form plz help

Hi all,
How can i know the entire path of my current running form.
I want a complete path of my form eg:
c:\abc\form.fmx or d:\abc\form.fmx and so on.
whether the form is being executed from hard disk,floppy or cd.
I am using forms 5.0
Can anyone give me an idea plz.
navneet jain
[email protected]

Yes, when I looked through the triggers I made sure to look for go_block and go_item calls as well as any calls to leave the form.

Execution path of an file at runtime

I have dir stucture like this
D:\first;
D:\first\second;
both of these are included in my classpath.
I have a package structre as
com.myName.MyPack
The above package is stored in both the structures mentioned above.
FileName.class is a file inside the package, and hence can have two absolute paths
D:\first\com\myName\MyPack\FileName.class
D:\first\second\com\myName\MyPack\FileName.class
The Command
java com.myName.MyPack.FileName
is given form the D: itself.
Now I need to know which class is called (it might be any of the two as the classpath is set in the users system).
I need to get the absolute path of the class which is loaded by the classLoader how do I do it.
Is there any api or method to know the above

Double-posted here: http://forum.java.sun.com/thread.jsp?thread=416540&forum=31&message=1840525

Issue in execution flow in a package

Hi All,
When there are more than 1 steps merging to one command in package, the execution path becomes totally unpredictable.
For example, take the path mentioned below, as i can't attach the image, i am mentioning the flow below:
Counter (Evaluate Variable) OK> FileName OK> LoadSalesFiles OK> Counter (Increment) OK> EndLoop
KO> Counter(Increment) OK> EndLoop
Two commands, FileName and LoadSalesFiles merge into the command Counter(Increment).
Scenario 1 : The command 'Counter' gets executed based on these results (a) successful execution of command 'LoadSalesFiles' OR (b) Failure of command 'FileName'. All these are encapsulated in a package P1 and is executed. The result is highly unpredictable since sometimes the execution path is 'FileName' --> 'Counter' and sometimes 'LoadSalesFiles' --> Counter and sometimes even weird 'FileName' --> 'EndLoop'-->'Counter'. We executed the package several times and each time the execution path and the result was different which is not what we expect.
Scenario 2 : We removed the command link from 'FileName' to 'Counter'. With this the package ran fine giving the expected result.
The modified command is:
Counter (Evaluate Variable) OK> FileName OK> LoadSalesFiles OK> Counter (Increment) OK> EndLoop
Any help on this would be much appreciated.
Thanks,
Nithesh B

Can you upload the image to some free service like picasa ?
That would help us in understanding more quickly.

How to change the order of execution

How to make a table driving table in the list of joining tables in the from clause?
for
select count(1)
from
table_a a , table_b b , table_c c
where a.col1=b.col1
and b.col2 = c.col2
I know that we can use ordered hint to make oracle the use the ordered mentioned in the from clause.
How about joinng order in the where clause.
Do I need to give any extra hints.
I understand a bit of checking oracle execution path.
Is there any material which can give me insight of the same.
thanks in advance

Hi,
hints should be used when there is no way to obtain a correcte execution path having objects analyzed and properly setup.
In that case, the /*+ ORDERED */ hint after the SELECT clause forces the execution plan to follow the execution order based on the FROM clause.
Be aware that, if if You have more than 2 tables in the from clause, You can have a Cartesian Product if the from clause is not properly set.
Hope this helps
Max

Oracle 10g Diff in execution plan query with binding var Vs without

We recently did 10g upgrade. In 10g, execution plan differs for query with binding var(thru jdbc etc) Vs without it as given below. For query with binding var,
it chooses poor execution plan(no index is used, full scan is done etc). everything worked fine in 9i. To rectify the problem, we have to hint query with right index,join etc. but i dont like this solution.
I would rather prefer to correct database to choose right execution path instead of eacy query level. but not sure what causes the issue.
Does anybody came across this issue? if so, Please share your experiences. Thanks for the help. Do let me know if you need more info.
1. Query without binding bar:
select * from test where col1 = :1 and col2 = :2
1. Query without binding bar:
select * from test where col1 = 'foo' and col2= 'bar'

I am not an expert but in my humble opinion it is the developer's responsability to ensure the correct explain plan is used before deploying code to production, if the explain plan returned by the DB is bad, then the use of a hint is perfectly acceptable.
Check this out: http://lcgapp.cern.ch/project/CondDB/snapshot/performance.html
Excerpt:
Bind variable peeking. If an SQL query contains bind variables, the optimal execution plan may depend on the values of those variables. When the Oracle query optimizer chooses the execution plan for such a query, it may indeed look at the values of all bind variables involved: this is known as "bind variable peeking".
In summary, the execution plan used for a given SQL query cannot be predicted a priori because it depends on the presence and quality of statistics and on the values of bind variables used at the time the query was first executed (hard-parsed). As a consequence of this instability of execution plans, very different performances may be observed for the same SQL query. In COOL, this issue is addressed by adding Oracle hints to the queries, to make sure that the same (good) plan is used in all cases, even with unreliable statistics or unfavourable bind variables.
Edited by: Rodolfo Ferrari on Jun 3, 2009 9:40 PM

Explain Plan and Execution Plan in 10gR2.

Hi,
Version 10.2.0.1.0.
I have two questions:
1) If the explain plan differs from the execution path in this version, then, is it safe to assume that the statistics are stale (or not gathered at all) on the underlying tables?
2) Can you in any way make a query use RBO instead of CBO? (I know it doesn't make any sense since CBO is lot smarter, but, for purely academic reasons).
Thank you,
Rahul.

The rule based optimizer is most definitely present in 10gR2. It might not be in the documentation, but it is still there.
C:\sql>sqlplus test/test
SQL*Plus: Release 10.2.0.2.0 - Production on Tue Oct 10 15:43:34 2006
Copyright (c) 1982, 2005, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production
With the Partitioning, OLAP and Data Mining options
test@SVTEST> set autotrace traceonly
test@SVTEST> alter session set optimizer_mode=rule;
Session altered.
Elapsed: 00:00:00.01
test@SVTEST> select * from dual;
Elapsed: 00:00:00.03
Execution Plan
Plan hash value: 272002086
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | TABLE ACCESS FULL| DUAL |
Note
- rule based optimizer used (consider using cbo)
Statistics
1 recursive calls
0 db block gets
3 consistent gets
2 physical reads
0 redo size
407 bytes sent via SQL*Net to client
381 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
test@SVTEST>

Direct Path Reads instead of Sequential Reads for index range scan

Database is 11.2. I have two development schemas, with the same table loaded in each schema - a 5 million row table. The execution path for the sql statement is the same against both tables; it's doing an index range scan.
But it would appear Oracle performs a direct path read against one schema, and performs sequential reads against the other schema. I don't understand why I'm seeing different behavior when the execution plan is the same. Any ideas? These are two different schemas in the same database.

There is not enough information.So you even these tables located same database and you gathered statistics it is not mean both run time wait event statistics must be same.Really they are different tables.If both query use INDEX RANGE SCAN the it is not mean these plans are same.What about table and their index statistics? are they same? for example num_row or num_blocks of both tables are same? also about indexes.In additionally if you want to get exact reason you can enable sql trace(using dbms_monitor or setting sql_trace parameter to true according session) and need analyze result trace file using tkprof utility.In additionally in 11g here when query execution time oracle automatically choose direct read path(serial) based on size of tables and size of buffer cache(also here is available some hidden parameter to controlling this behavior).

Re: setting path

Grettings, I have a simple question.
I have several java programs that I have written and that work successfully. My problem is that I am running these codes on numerous files located in several places. I would like to set the execution path rather than copying the files (code) to oodles of locations and then executing them from there. Perhaps I am not using the correct terminology, for most of my searches have led me towards j2sdk1.4.1 and classpaths. As always, any constructive critisms are warmly appreciated.

Fair question. I have several java files that I am using. I will list the simpliest one below.
// simple program for creating empty text files
import java.io.*;
import javax.swing.*;
public class addText
     public static void main(String args[]) throws Exception
          String fNumber;
          int numOfFiles;
          fNumber = JOptionPane.showInputDialog("Enter number of files");
          numOfFiles = Integer.parseInt(fNumber);
          String file;
          int fileName;
          file = JOptionPane.showInputDialog("Enter name/number of first file");
          fileName = Integer.parseInt(file);
          for (int iterator = fileName; iterator <= numOfFiles + fileName - 1; iterator++)
               Integer.toString(iterator); //converts integer to a string
               File f = new File(iterator + ".txt"); //using the string "integer" to name a file
               f.createNewFile();      // creates the file
}So, I have several directories containing subdirectories. I need to execute the above program in files located in all the the dir/subdirectories. Up to this point I have been coping the above code to each folder in the dir/subdirectories and then compiling/executing the code. It is time consuming to copy the code to each location, and heaven forbid I need alter the code at some point. I would need to change (or copy) the code in each location. I hope that is a bit clearer.

9i execution path

Similar Messages

Maybe you are looking for