Planning and SmartView query

If we import forms from Planning application on SmartView, can we do ad-hoc analyses on it?
I imported Planning formas an alternative to F.Reporting failure but am unable to do member selections on the imported form, etc. Is there a work around for this?
ALSO,
When I build SmartView reports, it gives me No Data whereas data does exist as it shows up on the forms. Where is the problem here? Is there a data mismatch somewhere? There is data on the forms in Planning but it shows no data on the report. I did refresh it but it still shows No Data (#Missing).
How do I get the data to show up on SmartView connected with Planning?

Thanks Amol. Appreciate it.
By the way, do you think you could help me with the question that I posted on another thread - data forms available but not showing on Financial Reporting?
This is a tricky one and I have been real busy with it

Similar Messages

Hyperion Planning and Smartview : Build function HS Description

Dear all,
I am currently using Hyperion planning 11.1.2.2, I would like to display in excel adhoc reports the description of some dimension members via smartview.
To this end I used the "build function" functionality:
I selected an empty cell and call the functionality, a window appears with two parameters :
1-connection : this field is automatically filed (WSFN|HP|pc|Planning|Plan1)
2-Member List : I would like to fil it manually ex : "Account#100"
I click on validate : the following message appears : Selected connection does not support this function.select new connection.
I would like to know what is meant by connection? what is the syntax of the connection string? could you please provide an example?
Thank you
Best regards.
Toufik
Edited by: user11081975 on May 12, 2013 12:55 PM

Hsdescription is not supported by Planning connection.
You can use that with Essbase connection.
Read http://docs.oracle.com/cd/E17236_01/epm.1112/sv_user/ch17s01s08s15.html
It talks about what are shared and private connections.
Regards
Celvin
http://www.orahyplabs.com

Hyperion Planning and Smartview Free form

Hi All,
I am currently using Hyperion planning 11.1.2.2, after a successful application creation, data load via EAS, Reports/Forms are working perfectly in smartview.
Now I would like to go beyond Adhoc Analysis, I would like to know if it is possible to use Free Forms with Planning?
when I try to create a free form with this connection profile" http://server:19000/HyperionPlanning/SmartView" it doesn't work. I cannot add label columns outside the borders of the form/Reports (blue cells).
I checked on the web and it seems that free form is only possible with essbase aps ?
please help.
Regards.

Hi Toufik,
Are the lines you want to add just labels for your own use? You should be able to open a form in Ad-Hoc analysis, then add a new row (using standard excel functionality) and add a label in this line. You can still change dimension members using the drill functionality and by over-typing Dimension member cells and refresh the sheet with your label in place.
I've just tested this on 11.1.2.2 as I was doubting myself and it definitley works connecting to Planning. Is the above what you're trying to achieve?
Regards
Ed

Error Message While Running Sequence from Planning and/or SmartView

Following error is thrown while running a sequence from either planning or smartview at a higher level.
"*An error occurred while running the specified calc script. Check the log for details*"
This is very weird because it does not happened with any of the following:
1. Running same sequence from AAS at higher level
2. Running at lower level entity either planning or smartview
3. Running from Planning or smartview with split sequence at higher level
4. Running each rule within the sequence from Planning or smartview
What have we done?
1. Checked every log file, Essbase, Planning, HBR - no error message is logged despite above statement.
2. Recycled environment
3. Stopped and restated DB and APP
Other info:
1. DB.log file is 1.2gb
2. No meta data changes
3. We could not able to replicate same in Q and Dev
4. Looked at cache setting
5. Sequence does not fail at the same place
6. Recently updated calclockblockhigh to 15000 (restarted environment)
Environment:
Planning suite: 9.3.0.1 with 9.3.1 APS.
We are going nuts and any feedback is greatly appreciated!
Thanks!
Edited by: venuramini on Jul 9, 2009 3:50 PM
Added environment section.

Hi,
To start Planning as a foreground app, stop the Planning service and then go to Start - Programs - Hyperion Solutions - Hyperion Planning - Start Planning (Apache Tomcat).
Thats if you are using Tomcat of course. A DOS window should then pop.
What value did you enter for the HBR properties? Have you tried 960000 for both? Remember you need to restart the Planning services for changes to take effect.
Have you tried increasing some of the properties in the HBRServer.properties under Hyperion\AnalyticAdministrationServices such as:
HBR.timeout
Try setting it to 30000
The restart the AAS service for the changes to take effect.
Hope this helps.
Seb

Effect of RLS policy (VPD) on execution plan of a query

Hi
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Regards,
Amardeep Sidhu

Amardeep Sidhu wrote:
I have been working on tuning of few queries. A RLS policy is defined on most of the tables which appends an extra where condition (something like AREA_CODE=1). I am not able to understand the effect of this extra where clause on the execution plan of the query. In the execution plan there is no mention of the clause added by VPD. In 10046 trace it does show the policy function being executed but nothing after that.
VPD is supposed to be invisible - which is why you get minimal information about security predicates in the standard trace file. However, if you reference a table with a security preidcate in your query, the table is effectively replaced by an inline view of the form: "select * from original_table where {security_predicate}", and the result is then optimised. So the effects of the security predicate is just the same as you writing the predicate into the query.
Apart from your use of v$sql_plan to show the change in plan and the new predicates, you can see the effects of the predicates by setting event 10730 with 10046. In current versions of Oracle this causes the substitute view being printed in the trace file.
Bear in mind that security predicates can be very complex - including subqueries - so the effect isn't just that of including the selectivity of "another simple predicate".
Can someone shed some light on the issue that has VPD any effect on the execution plan of the query ? Also would it matter whether the column on which VPD is applied, was indexed or non-indexed ?
Think of the effect of changing the SQL by hand - and how you would need to optimise the resultant query. Sometimes you do need to modify your indexing to help the security predicates, sometimes it won't make enough difference to matter.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan
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.

Query plan changes when query is used in CREATE TABLE AS

We've puzzled by the fact that EXPLAIN PLAN gives a much different output for a SELECT statement than it does when the same statement is used for CREATE TABLE . . . AS SELECT.
The bad part is that the CREATE TABLE version performs very badly, and that's what we want the query for.
Why does this happen? Is there a difference (from the database's point of view) between retrieving a set of rows to display to the user and putting that same set into a new table? Doesn't this make it harder to diagnose and fix query performance problems?
Here's our query:
create table query_test AS
select term, parentTerm, apidb.tab_to_string(cast(collect(trim(to_char(internal)))
                   as apidb.varchartab), ', ') as internal
             from (
                 select distinct ga.organism as term,
                                 ga.species as parentTerm,
                                 tn.taxon_id as internal
                 from apidb.GeneAttributes ga, SRES.TaxonName tn, sres.Taxon t,
                      dots.AaSequence aas, dots.SecondaryStructure ss
                 where ga.organism = tn.name
           and tn.taxon_id = t.taxon_id
                   and t.taxon_id = aas.taxon_id
   and aas.aa_sequence_id = ss.aa_sequence_id
           and t.rank != 'species'
           union
                 select distinct ga.species as term,
                   '' as parentTerm,
                                 ts.taxon_id as internal
                 from apidb.GeneAttributes ga, SRES.TaxonName tn, apidb.taxonSpecies ts,
                      dots.aasequence aas, dots.SecondaryStructure ss
                 where ga.organism = tn.name
                  and tn.taxon_id = ts.taxon_id
                  and ts.taxon_id = aas.taxon_id
                 and aas.aa_sequence_id = ss.aa_sequence_id
   group by term,parentTerm;Without the CREATE TABLE, the plan looks like this:
| Id | Operation                             | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | CREATE TABLE STATEMENT                |                           | 2911 | 5986K|       | 18840   (1)| 00:03:47 |
|   1 | LOAD AS SELECT                       | QUERY_TEST                |       |       |       |            |          |
|   2 |   VIEW                                |                           | 2911 | 5986K|       | 18669   (1)| 00:03:45 |
|   3 |    SORT GROUP BY                      |                           | 2911 |   332K|       | 18660   (1)| 00:03:44 |
|   4 |     VIEW                              |                           | 2911 |   332K|       | 18659   (1)| 00:03:44 |
|   5 |      SORT UNIQUE                      |                           | 2911 |   292K|       | 18659   (6)| 00:03:44 |
|   6 |       UNION-ALL                       |                           |       |       |       |            |          |
|* 7 |        HASH JOIN                      |                           | 2907 |   292K| 2160K| 17762   (1)| 00:03:34 |
|   8 |         TABLE ACCESS FULL             | GENEATTRIBUTES10650       | 40957 | 1679K|       |   795   (1)| 00:00:10 |
|* 9 |         HASH JOIN                     |                           | 53794 | 3204K| 1552K| 16675   (1)| 00:03:21 |
|* 10 |          HASH JOIN                    |                           | 37802 | 1107K|       | 12326   (1)| 00:02:28 |
|* 11 |           HASH JOIN                   |                           | 37945 |   629K|       | 10874   (1)| 00:02:11 |
| 12 |            INDEX FAST FULL SCAN       | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|       |    33   (0)| 00:00:01 |
| 13 |            INDEX FAST FULL SCAN       | AASEQUENCEIMP_REVIX6      | 7886K|    82M|       | 10816   (1)| 00:02:10 |
|* 14 |           TABLE ACCESS FULL           | TAXON                     |   514K| 6530K|       | 1450   (1)| 00:00:18 |
| 15 |          TABLE ACCESS FULL            | TAXONNAME                 |   760K|    22M|       | 2721   (1)| 00:00:33 |
|* 16 |        HASH JOIN                      |                           |     4 |   380 |       |   886   (1)| 00:00:11 |
| 17 |         NESTED LOOPS                  |                           |   730 | 64970 |       |   852   (1)| 00:00:11 |
|* 18 |          HASH JOIN                    |                           |     1 |    78 |       |   847   (1)| 00:00:11 |
| 19 |           NESTED LOOPS                |                           |       |       |       |            |          |
| 20 |            NESTED LOOPS               |                           |    17 |   612 |       |    51   (0)| 00:00:01 |
| 21 |             TABLE ACCESS FULL         | TAXONSPECIES10646         |    12 |    60 |       |     3   (0)| 00:00:01 |
|* 22 |             INDEX RANGE SCAN          | TAXONNAME_IND01           |     1 |       |       |     2   (0)| 00:00:01 |
| 23 |            TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |       |     4   (0)| 00:00:01 |
| 24 |           TABLE ACCESS FULL           | GENEATTRIBUTES10650       | 40957 | 1679K|       |   795   (1)| 00:00:10 |
|* 25 |          INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |   768 | 8448 |       |     5   (0)| 00:00:01 |
| 26 |         INDEX FAST FULL SCAN          | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|       |    33   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   7 - access("GA"."ORGANISM"="TN"."NAME")
   9 - access("TN"."TAXON_ID"="T"."TAXON_ID")
10 - access("T"."TAXON_ID"="TAXON_ID")
11 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
14 - filter("T"."RANK"<>'species')
16 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
18 - access("GA"."ORGANISM"="TN"."NAME")
22 - access("TN"."TAXON_ID"="TS"."TAXON_ID")
25 - access("TS"."TAXON_ID"="TAXON_ID")
46 rows selected.With the CREATE TABLE, the plan for the SELECT alone looks like this:
| Id | Operation                           | Name                      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                           |     2 |   234 | 1786   (1)| 00:00:22 |
|   1 | SORT GROUP BY                      |                           |     2 |   234 | 1786   (1)| 00:00:22 |
|   2 |   VIEW                              |                           |     2 |   234 | 1785   (1)| 00:00:22 |
|   3 |    SORT UNIQUE                      |                           |     2 |   198 | 1785 (48)| 00:00:22 |
|   4 |     UNION-ALL                       |                           |       |       |            |          |
|* 5 |      HASH JOIN                      |                           |     1 |   103 |   949   (1)| 00:00:12 |
|   6 |       NESTED LOOPS                  |                           |   199 | 19303 |   915   (1)| 00:00:11 |
|   7 |        NESTED LOOPS                 |                           |    13 | 1118 |   850   (1)| 00:00:11 |
|   8 |         NESTED LOOPS                |                           |    13 |   949 |   824   (1)| 00:00:10 |
|   9 |          VIEW                       | VW_DTP_E387155E           |    13 |   546 |   797   (1)| 00:00:10 |
| 10 |           HASH UNIQUE               |                           |    13 |   546 |   797   (1)| 00:00:10 |
| 11 |            TABLE ACCESS FULL        | GENEATTRIBUTES10650       | 40957 | 1679K|   795   (1)| 00:00:10 |
| 12 |          TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |     3   (0)| 00:00:01 |
|* 13 |           INDEX RANGE SCAN          | TAXONNAME_IND02           |     1 |       |     2   (0)| 00:00:01 |
|* 14 |         TABLE ACCESS BY INDEX ROWID | TAXON                     |     1 |    13 |     2   (0)| 00:00:01 |
|* 15 |          INDEX UNIQUE SCAN          | PK_TAXON                  |     1 |       |     1   (0)| 00:00:01 |
|* 16 |        INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |    15 |   165 |     5   (0)| 00:00:01 |
| 17 |       INDEX FAST FULL SCAN          | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|    33   (0)| 00:00:01 |
| 18 |      NESTED LOOPS                   |                           |     1 |    95 |   834   (1)| 00:00:11 |
| 19 |       NESTED LOOPS                  |                           |     1 |    89 |   833   (1)| 00:00:10 |
|* 20 |        HASH JOIN                    |                           |     1 |    78 |   828   (1)| 00:00:10 |
| 21 |         NESTED LOOPS                |                           |       |       |            |          |
| 22 |          NESTED LOOPS               |                           |    13 |   949 |   824   (1)| 00:00:10 |
| 23 |           VIEW                      | VW_DTP_2AAE9FCE           |    13 |   546 |   797   (1)| 00:00:10 |
| 24 |            HASH UNIQUE              |                           |    13 |   546 |   797   (1)| 00:00:10 |
| 25 |             TABLE ACCESS FULL       | GENEATTRIBUTES10650       | 40957 | 1679K|   795   (1)| 00:00:10 |
|* 26 |           INDEX RANGE SCAN          | TAXONNAME_IND02           |     1 |       |     2   (0)| 00:00:01 |
| 27 |          TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |     3   (0)| 00:00:01 |
| 28 |         TABLE ACCESS FULL           | TAXONSPECIES10646         |    12 |    60 |     3   (0)| 00:00:01 |
|* 29 |        INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |   768 | 8448 |     5   (0)| 00:00:01 |
|* 30 |       INDEX RANGE SCAN              | SECONDARYSTRUCTURE_REVIX9 |     1 |     6 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   5 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
13 - access("ITEM_1"="TN"."NAME")
14 - filter("T"."RANK"<>'species')
15 - access("TN"."TAXON_ID"="T"."TAXON_ID")
16 - access("T"."TAXON_ID"="TAXON_ID")
20 - access("TN"."TAXON_ID"="TS"."TAXON_ID")
26 - access("ITEM_1"="TN"."NAME")
29 - access("TS"."TAXON_ID"="TAXON_ID")
30 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
50 rows selected.Edited by: JohnI on Jul 18, 2011 2:19 PM
Edited by: JohnI on Jul 18, 2011 2:28 PM

Charles Hooper wrote a series of blog entries on a similar topic some time ago: http://hoopercharles.wordpress.com/2010/12/15/select-statement-is-fast-insert-into-using-the-select-statement-is-brutally-slow-1/ (including a lot of useful comments) and two following articles. I have to confess that I did not read the posts again - but I think you will find some good ideas how to analyze the problem.
Regards
Martin Preiss

BI Integerated planning and SEM-BPS ???

Hi all ,
I am new to SEM.
Could you tell me
1) if there's any difference between Bi integeraed planning and SEM-BPS ?
2) if so, what are those differences ? & which one is better suited to planning needs ?.
3) also can we use planning areas developed in bw-bps ???
Friends if you have any documentation for the practical part of SEM-bps
could you please send it to [email protected]
thanks in advance
Nidhi Dashora

Hello together,
BI-IP is under contruction and wil be replaced later instead of BW-BPS. For the mean time BW-BPS will exist parallel.
Further details see here: https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/b87271fb-0701-0010-00bd-b03502b8c011
This is the theorie. In the praxis there are big differences and BI-IP is in a "very eraly stage", you should have at least SP 10, better wait for 12 to able to have at least the most important functionalities in BI-IP.
e. g. you can not plan on hierarchy nodes (e. g. you dont have standard distribute function to distribute from # in a query). This is available from SP12. And so on....
regards
Eckhard Lewin

How to proceed further once the explain plan and trace files are generated?

Hi Friends,
I need to improve the performance of on of the views that i am working on.
As suggested in the thread - http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0 , i gave generated the explain plan and the trace file.
From the explain plan, we can see the expensive operations for the query.
Can any one please tell, how to proceed further from here on i.e. how to make this expensive operations less expensive?
For ex: FULL TABLE SCAN might be an expensive operation when the table has indexes.In such cases, how can we avoid such operations to make query faster?
Regards,
Sreekanth Munagala.

Hi Veena,
An earlier post by you regarding P45 is as below
Starter report P45(3) / P46 efiling for UK
from my understanding though i have not worked on GB Payroll you have said that you deleted IT 65 details of leaver,however there must be clusters generated in system from where the earlier data needs to be deleted and may be that is why you are facing the issue.
In Indian payroll when we execute text file for efiling of tax after challan mapping all the data compiles and sits in PCL cluster and therefore we are unable to generate form 16 with proper output,here we delete the clusters and rerun again the mappings and then check form 16.
Hope this might help you,Experts have suggested you earlier also,they may correct me for this.
Salil

Different query plans for same query on same DB

Hi,
HP-Ux
Oracle Database 10.2.0.4
We are experiencing a strange issue. One of our night batch process is taking invariably more time to execute. The process does not consume time at 1 particular query. Everyday we find a new query taking more time than previous execution.
Now, when we see the explain plan while the query is executing, we see NESTED LOOP SEMI (with improper index being used). At the same time if we take the query and see the explain plan seperately, we get HASH JOIN SEMI (with proper index being used). Also, if we execute this query with the values as in procedure, it finishes within mili seconds (as it should).
The tables and indexes are analyzed everyday before the process starts.
Can anybody explain, why the same query shows two different plans at the same time ?
Thanks a lot in advance :)

Aalap Sharma wrote:
HP-Ux
Oracle Database 10.2.0.4
We are experiencing a strange issue. One of our night batch process is taking invariably more time to execute. The process does not consume time at 1 particular query. Everyday we find a new query taking more time than previous execution.
Now, when we see the explain plan while the query is executing, we see NESTED LOOP SEMI (with improper index being used). At the same time if we take the query and see the explain plan seperately, we get HASH JOIN SEMI (with proper index being used). Also, if we execute this query with the values as in procedure, it finishes within mili seconds (as it should).
The tables and indexes are analyzed everyday before the process starts.
Can anybody explain, why the same query shows two different plans at the same time ?As already mentioned, you might hit typical issues in 10.2: The column workload based SIZE AUTO statistics gathering feature and/or bind variable peeking.
How do you analyze the tables and indexes before the process starts? Can you share the exact call with parameters?
Some ideas:
1. If your process is "new", then the column workload monitoring of the database might recognize the column usage pattern and generate histograms on some of your columns. It might take a while until the workload has been established so that all columns got histograms according to the workload (It needs a certain number of usages/executions before the workload is registered as relevant). Until then you might get different execution plans each time the statistics are refreshed due to new histograms being added.
2. If the default 10g statistics gathering job is active, it might gather different statistics during the night than your individual job that runs prior to the processing. This could be one possible explanation why you get different plans on the next day.
3. "Bind Variable Peeking" is possibly another issue you might run into. How do you test the query so that you get a different, well performing plan? Does your original statement use bind variables? Do you use literals to reproduce? Note that using EXPLAIN PLAN on statements involving bind variables can lie, since it doesn't perform bind variable peeking by default.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/

What causes ad-hoc to run with bad plan and its resolution

One of our Company Application funcnalities uses the ad-hoc query that returns top first row from the result sets .There has been several times since this ad-hoc query ran with a bad
execution in last 8 months .There is no specifice time and date or day when this query run with bad execution plan ,however whenever this query ran with a bad execution plan on SQL ,that happed always early in the morning , before 6am .The setting of database
parameterization is set to forced .There is SQL maintenance reindexing job that runs each night at 2am that changes the recovedry model of our production database from Full to simple and changing back from simple to full after the reindexing operation .That
causes the SQL plans to flush each night .The next day morning , when the application ad-hoc query runs on SQL first time , SQL generates a new plan for that query . Some strange reason , SQL genarates a good plan for that ad-hoc query most of the times ,but
sometime this query picks up a bad plan .Whenever it happen,the application function becomes exetremly slow and it seems that the rest of the fuctionalities work fine meantime .
Our application vender is aware of this issue and this issue will be fixed in the application next release .Developer is converting the ad-hoc query into stored procedure to fix this
issue .Application new relase will not available for next 2-3 months ,meantime we still have to deal with the ad-hoc query bad execution plan issue . Usually ,when the ad-hoc query run with the bad execution plan , I retrieve the query bad plan and just remove
the plan for that particular query from cache .Once the bad plan is removed from cache , the perfomance gets back to normal .
As my understanding, this issue is related to parameter sniffing .but anyone thinks there are other factors responsible for this issue such as the network problem , the resource intensive
report ran or something else .
Has anyone have step by step troubleshooting steps that could help me with my investigation and what areas
do I need to look into in order to investigate what could caused the ad-hoc query to pick up bad plan ?
Any help will be apprecited .
Daizy

When we upgraded our Production Database to SQL server 2008R2 enterprise Edition. We ran into the transaction log file to grow too large during the reindexing job activities at night .To prevent the transaction log file to grow big , we had decided to change
the recovery model of database from FULL to Simple before the reindexing job starts and the recovery model of Database is changed from Simple to Full after the reindexing job finishes . We also have the differential backup job setup right after the recovery
model change back to full so the transaction log backup chain does not break.
The transaction log chain breaks when you set the recovery to simple.
Yes, if you take a diff backup, you can apply transaction logs from that point
if the diff backup is good. If the diff backup is bad, you will lose all updates after you set recovery to simple. And, yes, when you hardware starts to deteoriate, you should not be surprise that the last backup is not good.
Again, please stop setting recovery to simple, unless you have a very relaxed RPO in your SLA. Use bulk-logged recovery instead.
By the way, you do take a t-log backup before you change the recovery mode, don't you?
Changing the database recovery model does flush the SQL plans for specific Database. Please review this linkhttp://sqlblogcasts.com/blogs/steveh/archive/2010/09/02/changing-recovery-model-removes-plans-from-procedure-cache-for-a-database.aspx
Hmmm. I don't have the time to verify this right now. Anyway, reindexing is good enough to flush the cache of most plans.
I have pretty much all required info regarding this query , but what other areas or investigation do I need to do for the query parameter sniffing issue ?
Have you researched what values the initial plan is sniffed for?
As Erland said adding space in query ,I don?t know adding space means just add additional space in the query so it hashes a different values .Please advice .
Obviously, you need access to the application code. The other alternative is to set up an early morning job that runs after this first execution and which forces a recompilation; either by evicting this specific plan or more brutally runs sp_recompile on
one of the tables in the query.
Erland Sommarskog, SQL Server MVP, [email protected]

Explain Plan and COST

Hi,
Is there any relationship between the cost factor in the explain plan and query execution time. I have come across situations in both ways, i.e. high cost and low execution time, low cost and high execution time. What parameters do we need to consider in tuning a query high cost or low cost?So my assumption is that the lower cost does not guarantee faster response time. Again i have have seen many people try to reduce the cost first.Can anyone help me on this issue please.
Thanks-Bhaskar

Cost is a metric that Oracle uses to estimate the runtime of a query. However, it is not something that you probably ought to pay a lot of attention to. If you are looking at the performance of a query, you are presumably operating on the assumption that the optimizer may have chosen an incorrect plan. If the optimizer chose an incorrect plan then by definition the cost is incorrect. If the cost is correct then, by definition, Oracle chose the correct plan.
It makes much more sense to focus on things like the cardinality of each step (the number of rows each step in the plan is expected to return). If the cardinality estimates are correct (or reasonably close), then the optimizer probably chose the correct plan. If the cardinality estimates are way off, the optimizer probably chose a less than optimal plan. And when you find the first step where the cardinality estimates are wildly incorrect, you'll know where you need to start focusing your tuning efforts.
Justin

Efficient way to read through big explain plan and genterate html explain plan for sql id's executed in past

Hi,
I have a sql which is recently having a performance problems in Production. I have generated a explain plan for it trying to find out what it is doing but plan itself is close to 1000 lines. I want to check if there is any efficient way to go through big plan like this one and quickly find the damaging areas..
2) I also wanted to know if there is way to generate explain plans in HTML format which executed in past and have entry in dba_hist_sqltext.
3) I also have two sql_monitor reports which I want to compare. is there any efficient way to do it as well?
Please share your thoughts!
Thanks in advance!
Regards,
Suman-

Hi,
I suggest you can try running sql advisor on the query maybe something fruitful comes up
http://www.oracle-base.com/articles/11g/sql-access-advisor-11gr1.php
I am not sure about the explain plan being printed in html format but
You may also want to try the sqlhistory.sql query from below page
http://evdbt.com/scripts/
I have used it many times to check on executions and explain plans which may have changed over the period
I have faced it many times , the query picks up a bad explain plan and performs poorly

How to skip existing execution plan for a query

Hi,
I want to skip existng execution plan for a query which I am executing often. I dont want it to use the same execution plan everytime. Please let me know if any method is there skip the existing execution plan.
Thanks in advance.......
Edited by: 900105 on Dec 1, 2011 4:52 AM

Change the query so it is syntactically different, but has the same semantics (meaning). That way CBO will reparse it and you might get a new execution plan.
One simple way to do that is to add a dummy predicate ( 45=45) to the where clause. The predicate must be changed every time the query is executed ( 46=46 , 47=47 ,… ).
Iordan Iotzov
http://iiotzov.wordpress.com/

Differenet Explain Plan for Same Query

DB Version : 11.2.0.3
OS Version : AIX 6
I have two Queries ( The Difference between Them Only 940 and 584 ) When I Generate Explain Plan Different Output Why ? Why CPU time is Different Each Time
First Query Statement :
INSERT INTO TempSearchResult (t_aid,
                              t_umidl,
                              t_umidh,
                              X_CREA_DATE_TIME_MESG)
   SELECT z.aid,
          z.mesg_s_umidl,
          z.mesg_s_umidh,
          z.mesg_crea_date_time
     FROM ( SELECT m.aid,
                    m.mesg_s_umidl,
                    m.mesg_s_umidh,
                    m.mesg_crea_date_time
               FROM RSMESG_ESIDE m
              WHERE 1 = 1
                    AND m.mesg_crea_date_time BETWEEN TO_DATE (
                                                         '20120131 10:00:00',
                                                         'YYYYMMDD HH24:MI:SS')
                                                  AND TO_DATE (
                                                         '20120131 13:00:00',
                                                         'YYYYMMDD HH24:MI:SS')
                    AND m.mesg_frmt_name = 'Swift'
                    AND m.mesg_sender_x1 = 'SOGEFRPPXXX'
                    AND m.mesg_nature = 'FINANCIAL_MSG'
                    AND m.mesg_type LIKE '950'
           ORDER BY mesg_crea_date_time) z
    WHERE ROWNUM <= 5000
Explain Plan for First Query :
PLAN_TABLE_OUTPUT
Plan hash value: 3901722890
| Id | Operation                                 | Name              | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | INSERT STATEMENT                          |                   | 2866 |   134K|   197   (3)| 00:00:03 |       |       |
|   1 | LOAD TABLE CONVENTIONAL                  | TEMPSEARCHRESULT |       |       |            |          |       |       |
|* 2 |   COUNT STOPKEY                           |                   |       |       |            |          |       |       |
|   3 |    VIEW                                   |                   | 2866 |   134K|   197   (3)| 00:00:03 |       |       |
|* 4 |     SORT ORDER BY STOPKEY                 |                   | 2866 |   333K|   197   (3)| 00:00:03 |       |       |
|   5 |      NESTED LOOPS                         |                   | 2866 |   333K|   196   (2)| 00:00:03 |       |       |
PLAN_TABLE_OUTPUT
|   6 |       NESTED LOOPS                        |                   | 1419 |   148K|   196   (2)| 00:00:03 |       |       |
|* 7 |        HASH JOIN                          |                   | 1419 |   141K|   196   (2)| 00:00:03 |       |       |
|   8 |         NESTED LOOPS                      |                   |    91 | 1911 |     2   (0)| 00:00:01 |       |       |
|   9 |          TABLE ACCESS BY INDEX ROWID      | SUSER             |     1 |    10 |     1   (0)| 00:00:01 |       |       |
|* 10 |           INDEX UNIQUE SCAN               | IX_SUSER          |     1 |       |     0   (0)| 00:00:01 |       |       |
|* 11 |          INDEX FULL SCAN                  | PK_SUNITUSERGROUP |    91 | 1001 |     1   (0)| 00:00:01 |       |       |
| 12 |         PARTITION RANGE SINGLE            |                   | 1450 |   114K|   193   (2)| 00:00:03 |     2 |     2 |
|* 13 |          TABLE ACCESS BY LOCAL INDEX ROWID| RMESG             | 1450 |   114K|   193   (2)| 00:00:03 |     2 |     2 |
|* 14 |           INDEX SKIP SCAN                 | IX_RMESG          |   415 |       |    14 (15)| 00:00:01 |     2 |     2 |
|* 15 |        INDEX UNIQUE SCAN                  | PK_SMSGUSERGROUP |     1 |     5 |     0   (0)| 00:00:01 |       |       |
|* 16 |       INDEX UNIQUE SCAN                   | PK_SBICUSERGROUP |     2 |    24 |     0   (0)| 00:00:01 |       |       |
PLAN_TABLE_OUTPUT
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
   2 - filter(ROWNUM<=5000)
   4 - filter(ROWNUM<=5000)
   7 - access("X_INST0_UNIT_NAME"="UNIT")
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
11 - access("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
       filter("SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
13 - filter("RMESG"."MESG_SENDER_X1"='SOGEFRPPXXX' AND "RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND
              "RMESG"."MESG_FRMT_NAME"='Swift')
14 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-31 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "RMESG"."MESG_TYPE"='950' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-31 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter("RMESG"."MESG_TYPE"='950')
15 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
16 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
40 rows selected.
Second query
INSERT INTO TempSearchResult (t_aid,
                              t_umidl,
                              t_umidh,
                              X_CREA_DATE_TIME_MESG)
   SELECT z.aid,
          z.mesg_s_umidl,
          z.mesg_s_umidh,
          z.mesg_crea_date_time
     FROM ( SELECT m.aid,
                    m.mesg_s_umidl,
                    m.mesg_s_umidh,
                    m.mesg_crea_date_time
               FROM RSMESG_ESIDE m
              WHERE 1 = 1
                    AND m.mesg_crea_date_time BETWEEN TO_DATE (
                                                         '20120117 10:00:00',
                                                         'YYYYMMDD HH24:MI:SS')
                                                  AND TO_DATE (
                                                         '20120117 13:00:00',
                                                         'YYYYMMDD HH24:MI:SS')
                    AND m.mesg_frmt_name = 'Swift'
                    AND m.mesg_sender_x1 = 'SOGEFRPPGSS'
                    AND m.mesg_nature = 'FINANCIAL_MSG'
                    AND m.mesg_type LIKE '548'
           ORDER BY mesg_crea_date_time) z
    WHERE ROWNUM <= 5000
Explain Plan For Second Query :
PLAN_TABLE_OUTPUT
Plan hash value: 4106071428
| Id | Operation                                  | Name              | Rows | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | INSERT STATEMENT                           |                   | 1073 | 51504 |       | 2622   (1)| 00:00:32 |       |       |
|   1 | LOAD TABLE CONVENTIONAL                   | TEMPSEARCHRESULT |       |       |       |            |          |       |       |
|* 2 |   COUNT STOPKEY                            |                   |       |       |       |            |          |       |       |
|   3 |    VIEW                                    |                   | 1073 | 51504 |       | 2622   (1)| 00:00:32 |       |       |
|* 4 |     SORT ORDER BY STOPKEY                  |                   | 1073 |   124K|       | 2622   (1)| 00:00:32 |       |       |
|   5 |      NESTED LOOPS                          |                   | 1073 |   124K|       | 2621   (1)| 00:00:32 |       |       |
PLAN_TABLE_OUTPUT
|   6 |       NESTED LOOPS                         |                   |   531 | 56817 |       | 2621   (1)| 00:00:32 |       |       |
|   7 |        NESTED LOOPS                        |                   |   531 | 54162 |       | 2621   (1)| 00:00:32 |       |       |
|   8 |         NESTED LOOPS                       |                   |   543 | 49413 |       | 2621   (1)| 00:00:32 |       |       |
|   9 |          TABLE ACCESS BY INDEX ROWID       | SUSER             |     1 |    10 |       |     1   (0)| 00:00:01 |       |       |
|* 10 |           INDEX UNIQUE SCAN                | IX_SUSER          |     1 |       |       |     0   (0)| 00:00:01 |       |       |
| 11 |          PARTITION RANGE SINGLE            |                   |   543 | 43983 |       | 2621   (1)| 00:00:32 |     2 |     2 |
|* 12 |           TABLE ACCESS BY LOCAL INDEX ROWID| RMESG             |   543 | 43983 |       | 2621   (1)| 00:00:32 |     2 |     2 |
| 13 |            BITMAP CONVERSION TO ROWIDS     |                   |       |       |       |            |          |       |       |
| 14 |             BITMAP AND                     |                   |       |       |       |            |          |       |       |
| 15 |              BITMAP CONVERSION FROM ROWIDS |                   |       |       |       |            |          |       |       |
|* 16 |               INDEX RANGE SCAN             | IX_SENDER         | 25070 |       |       |   894   (1)| 00:00:11 |     2 |     2 |
PLAN_TABLE_OUTPUT
| 17 |              BITMAP CONVERSION FROM ROWIDS |                   |       |       |       |            |          |       |       |
| 18 |               SORT ORDER BY                |                   |       |       |   408K|            |          |       |       |
|* 19 |                INDEX RANGE SCAN            | IX_RMESG          | 25070 |       |       | 1405   (1)| 00:00:17 |     2 |     2 |
|* 20 |         INDEX UNIQUE SCAN                  | PK_SUNITUSERGROUP |     1 |    11 |       |     0   (0)| 00:00:01 |       |       |
|* 21 |        INDEX UNIQUE SCAN                   | PK_SMSGUSERGROUP |     1 |     5 |       |     0   (0)| 00:00:01 |       |       |
|* 22 |       INDEX UNIQUE SCAN                    | PK_SBICUSERGROUP |     2 |    24 |       |     0   (0)| 00:00:01 |       |       |
Predicate Information (identified by operation id):
PLAN_TABLE_OUTPUT
   2 - filter(ROWNUM<=5000)
   4 - filter(ROWNUM<=5000)
10 - access("SUSER"."USERNAME"="SIDE"."GETMYUSER"())
12 - filter("RMESG"."MESG_NATURE"='FINANCIAL_MSG' AND "RMESG"."MESG_FRMT_NAME"='Swift')
16 - access("RMESG"."MESG_SENDER_X1"='SOGEFRPPGSS')
19 - access("RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter("RMESG"."MESG_TYPE"='548' AND "RMESG"."MESG_CREA_DATE_TIME"<=TO_DATE(' 2012-01-17 13:00:00', 'syyyy-mm-dd
              hh24:mi:ss') AND "RMESG"."MESG_CREA_DATE_TIME">=TO_DATE(' 2012-01-17 10:00:00', 'syyyy-mm-dd hh24:mi:ss'))
20 - access("X_INST0_UNIT_NAME"="UNIT" AND "SUSER"."GROUPID"="SUNITUSERGROUP"."GROUPID")
21 - access("X_CATEGORY"="CATEGORY" AND "SUSER"."GROUPID"="SMSGUSERGROUP"."GROUPID")
PLAN_TABLE_OUTPUT
22 - access("X_OWN_LT"="BICCODE" AND "SUSER"."GROUPID"="SBICUSERGROUP"."GROUPID")
45 rows selected.
Table Structure TEMPSEARCHRESULT
CREATE GLOBAL TEMPORARY TABLE TEMPSEARCHRESULT
T_AID                  NUMBER(3),
T_UMIDL                NUMBER(10),
T_UMIDH                NUMBER(10),
X_CREA_DATE_TIME_MESG DATE
ON COMMIT PRESERVE ROWS
NOCACHE;
CREATE INDEX SIDE.TEMP_SEARCH_INDEX ON SIDE.TEMPSEARCHRESULT
(T_AID, T_UMIDL, T_UMIDH, X_CREA_DATE_TIME_MESG);

Again Thank you For your amazing Answer.
For indexes it's a balance. Check this query which is Simple
Select * from RMESGI generated Explain Plan for it to see effect of indexes .
PLAN_TABLE_OUTPUT
Plan hash value: 1686435785
| Id | Operation           | Name | Rows | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
|   0 | SELECT STATEMENT    |       |    11M| 8920M|   376K (1)| 01:15:20 |      |        |
|   1 | PARTITION RANGE ALL|       |    11M| 8920M|   376K (1)| 01:15:20 |    1 |     12 |
|   2 |   TABLE ACCESS FULL | RMESG |    11M| 8920M|   376K (1)| 01:15:20 |    1 |     12 |
---------------------------------------------------------------------------------------------1:15:20 For table access and Full Scan Also , I generate new Indexes on the table like the following
CREATE TABLE RMESG(
        aid NUMBER(3) NOT NULL,
        mesg_s_umidl NUMBER(10) NOT NULL,
        mesg_s_umidh NUMBER(10) NOT NULL,
        mesg_validation_requested CHAR(18) NOT NULL,
        mesg_validation_passed CHAR(18) NOT NULL,
        mesg_class CHAR(16) NOT NULL,
        mesg_is_text_readonly NUMBER(1) NOT NULL,
        mesg_is_delete_inhibited NUMBER(1) NOT NULL,
        mesg_is_text_modified NUMBER(1) NOT NULL,
        mesg_is_partial NUMBER(1) NOT NULL,
        mesg_crea_mpfn_name CHAR(24) NOT NULL,
        mesg_crea_rp_name CHAR(24) NOT NULL,
        mesg_crea_oper_nickname CHAR(151) NOT NULL,
        mesg_crea_date_time DATE NOT NULL,
        mesg_mod_oper_nickname CHAR(151) NOT NULL,
        mesg_mod_date_time DATE NOT NULL,
        mesg_frmt_name VARCHAR2(17) NOT NULL,
        mesg_nature CHAR(14) NOT NULL,
        mesg_sender_x1 CHAR(11) NOT NULL,
        mesg_sender_corr_type VARCHAR2(24) NOT NULL,
        mesg_uumid VARCHAR2(50) NOT NULL,
        mesg_uumid_suffix NUMBER(10) NOT NULL,
        x_own_lt CHAR(8) NOT NULL,
        x_inst0_unit_name VARCHAR2(32) default 'NONE' NOT NULL,
        x_category CHAR(1) NOT NULL,
        archived NUMBER(1) NOT NULL,
        restored NUMBER(1) NOT NULL,
        mesg_related_s_umid CHAR(16) NULL,
        mesg_status CHAR(12) NULL,
        mesg_crea_appl_serv_name CHAR(24) NULL,
        mesg_verf_oper_nickname CHAR(151) NULL,
        mesg_data_last NUMBER(10) NULL,
        mesg_token NUMBER(10) NULL,
        mesg_batch_reference VARCHAR2(46) NULL,
        mesg_cas_sender_reference VARCHAR2(40) NULL,
        mesg_cas_target_rp_name VARCHAR2(20) NULL,
        mesg_ccy_amount VARCHAR2(501) NULL,
        mesg_copy_service_id VARCHAR2(4) NULL,
        mesg_data_keyword1 VARCHAR2(80) NULL,
        mesg_data_keyword2 VARCHAR2(80) NULL,
        mesg_data_keyword3 VARCHAR2(80) NULL,
        mesg_delv_overdue_warn_req NUMBER(1) NULL,
        mesg_fin_ccy_amount VARCHAR2(24) NULL,
        mesg_fin_value_date CHAR(6) NULL,
        mesg_is_live NUMBER(1) NULL,
        mesg_is_retrieved NUMBER(1) NULL,
        mesg_mesg_user_group VARCHAR2(24) NULL,
        mesg_network_appl_ind CHAR(3) NULL,
        mesg_network_delv_notif_req NUMBER(1) NULL,
        mesg_network_obso_period NUMBER(10) NULL,
        mesg_network_priority CHAR(12) NULL,
        mesg_possible_dup_creation VARCHAR2(8) NULL,
        mesg_receiver_alia_name VARCHAR2(32) NULL,
        mesg_receiver_swift_address CHAR(12) NULL,
        mesg_recovery_accept_info VARCHAR2(80) NULL,
        mesg_rel_trn_ref VARCHAR2(80) NULL,
        mesg_release_info VARCHAR2(32) NULL,
        mesg_security_iapp_name VARCHAR2(80) NULL,
        mesg_security_required NUMBER(1) NULL,
        mesg_sender_x2 VARCHAR2(21) NULL,
        mesg_sender_x3 VARCHAR2(21) NULL,
        mesg_sender_x4 VARCHAR2(21) NULL,
        mesg_sender_branch_info VARCHAR2(71) NULL,
        mesg_sender_city_name VARCHAR2(36) NULL,
        mesg_sender_ctry_code VARCHAR2(3) NULL,
        mesg_sender_ctry_name VARCHAR2(71) NULL,
        mesg_sender_institution_name VARCHAR2(106) NULL,
        mesg_sender_location VARCHAR2(106) NULL,
        mesg_sender_swift_address CHAR(12) NULL,
        mesg_sub_format VARCHAR2(6) NULL,
        mesg_syntax_table_ver VARCHAR2(8) NULL,
        mesg_template_name VARCHAR2(32) NULL,
        mesg_trn_ref VARCHAR2(16) NULL,
        mesg_type CHAR(3) NULL,
        mesg_user_issued_as_pde NUMBER(1) NULL,
        mesg_user_priority_code CHAR(4) NULL,
        mesg_user_reference_text VARCHAR2(30) NULL,
        mesg_zz41_is_possible_dup NUMBER(1) NULL,
        x_fin_ccy CHAR(3) NULL,
        x_fin_amount NUMBER(21,4) NULL,
        x_fin_value_date DATE NULL,
        x_fin_ocmt_ccy CHAR(3) NULL,
        x_fin_ocmt_amount NUMBER(21,4) NULL,
        x_receiver_x1 CHAR(11) NULL,
        x_receiver_x2 VARCHAR2(21) NULL,
        x_receiver_x3 VARCHAR2(21) NULL,
        x_receiver_x4 VARCHAR2(21) NULL,
        last_update DATE NULL,
        set_id NUMBER(10) NULL,
        mesg_requestor_dn VARCHAR2(101) NULL,
        mesg_service VARCHAR2(31) NULL,
        mesg_request_type VARCHAR2(31) NULL,
        mesg_identifier VARCHAR2(31) NULL,
        mesg_xml_query_ref1 VARCHAR2(101) NULL,
        mesg_xml_query_ref2 VARCHAR2(101) NULL,
        mesg_xml_query_ref3 VARCHAR2(101) NULL,
        mesg_appl_sender_reference VARCHAR2(51) NULL,
        mesg_payload_type VARCHAR2(31) NULL,
        mesg_sign_digest_reference VARCHAR2(41) NULL,
        mesg_sign_digest_value VARCHAR2(51) NULL,
        mesg_use_pki_signature NUMBER(1) NULL
PARTITION BY RANGE(MESG_CREA_DATE_TIME) (
    PARTITION SIDE_MIN VALUES LESS THAN (TO_DATE(20000101, 'YYYYMMDD')) TABLESPACE TBS_SIDEDB_DA_01);
CREATE UNIQUE INDEX SIDE.IX_PK_RMESG on SIDE.RMESG (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) LOCAL;
ALTER TABLE SIDE.RMESG ADD CONSTRAINT IX_PK_RMESG PRIMARY KEY (AID, MESG_S_UMIDH, MESG_S_UMIDL, MESG_CREA_DATE_TIME) USING INDEX SIDE.IX_PK_RMESG;
CREATE INDEX SIDE.ix_rmesg_cassender ON SIDE.rmesg (MESG_CAS_SENDER_REFERENCE) LOCAL;
CREATE INDEX SIDE.ix_rmesg_creationdate ON SIDE.rmesg (MESG_CREA_DATE_TIME) LOCAL;
CREATE INDEX SIDE.ix_rmesg_trnref ON SIDE.rmesg (MESG_TRN_REF) LOCAL;
CREATE INDEX SIDE.ix_rmesg_uumid ON SIDE.rmesg (MESG_UUMID, MESG_UUMID_SUFFIX) LOCAL;
CREATE INDEX SIDE.IX_UNIT_NAME_RMESG on RMESG(mesg_crea_date_time,X_INST0_UNIT_NAME) LOCAL;
CREATE INDEX SIDE.IX_RMESG on RMESG(mesg_crea_date_time ,mesg_type,x_fin_ccy) LOCAL;
CREATE INDEX SIDE.IX_NAME_FORMAT_TYPE_RMESG on RMESG(mesg_frmt_name,mesg_sub_format,mesg_type,mesg_crea_date_time ) LOCAL;same Explain Plan Same Result .
I always remember TOM Quote "full scans are not evil, indexes are not good"
Which Mean Something Wrong Goes with Indexes , the partition depend on MESG_CREA_DATE_TIME Column I create Index for this column but same explain plan Appear every time. With Same Time.
Thank you
Osama

Query on a table runs more than 45mins(after stats) and same query runs 19secs(before stats - rebuild)

Query on a table runs more than 45mins(after stats) and same query runs 19secs(before stats - rebuild) - Not sure what the cause is.
- Analysed the explain the plan
- different explain plan used afterr stats gather.
Any idea what could be the cause with this kind of difference.
Thank you!

What is the difference you see in the explain plan ? Where it spends most time. All these needs to be analysed.

Planning and SmartView query

Similar Messages

Maybe you are looking for