HR BADI query

Hi All ,
In tcode pa30 we are creating a custom infotype and a subtype . When i do a F4 on the subtype the FM called is HR_F4_GET_SUBTYPE.
This FM checks for a badi using code
CALL FUNCTION 'HR_GET_BUSINESS_ADD_IN'
    EXPORTING
      exit_name      = 'HR_F4_GET_SUBTYPE'
      flt_val        = infty
    IMPORTING
      is_implemented = is_implemented
    CHANGING
      instance       = exit_obj.
This FM checks if any BADI is activated exit_name = HR_F4_GET_SUBTYPE.
I want to write some custom code and check if i can use this badi for my work.
I have created an implementation ZHR_F4_GET_SUBTYPE. WRitten a small code in one of the methods ..
BADI is activated . however when i debug pa30 and it comes to this code which checks whether badi is active .. it returns a sy-subrc 4.
Could you please guide me where am i going wrong .. do i need to do some settings to activate the badi ?

Thanks for replying,
Ramesh - Yes both method and implementation is active .
Satish - I have not written any code in the method. I am presently checking if the badi can be used for my purpose.

Similar Messages

Bad query performance - how to analyze it?

Hi all,
since 8 weeks we locate a bad query performance (round about 30% worse than before) in our BW system. At the moment we use a BIA on revision 49 with 4 blades (16GB).
I have already read note 1318214 and analyzed that the most time is spend on the virtual provider(over 80%!).
I´ve seen that a lot of time is spend on the "Datamanager":
For example: It takes 0,76s to select 3.5million items in the relative provider and 78s!!! to select 0 items in the virtual provider.
information from RSDDSTATTREXSERV:
RFC Server BIA client BIA Kernel ABAP RFC
497 464 450 619
So it seems to be a problem an the BW site, what can we do to improve the performance or analyse the query performance better.
Best Regards,
Jens

Hi Jens,
A few checks you may consider doing.
BIA Availability : Check the BI connection with BIA.
Check if you need to rebuild BIA indices again. SAP recommends to do this often, to repair the degenerate indices or delete the indice which are not referenced any more.(eg data in the cube was compressed/deleted and the indices are no more needed.)
Check the if BIA reorganization is required - This is done to see the indices are evenly distribueded areoss the BIA Landscape.
Try to find from BI Admin if major administration work was done within these 8 weeks.eg: Copy cube, dimension restructureing, copying data to some copy cube, archiving etc.
You can use the BIA monitor to peform checks/monitor alerts from BIA servers
[ BIA monitor|http://help.sap.com/saphelp_nw70/helpdata/en/43/7719d270d81a6ee10000000a11466f/content.htm]
This link would tell you on the overall status of the BIA and any actions if required.
Also it has sublinks to other important transaction of BIA monitoring and maintainnance.
To go to BIA monitor : RSA!---> BIA monitor icon.
Is your virtual provider reading data from R/3 or BW.
Generally virtual providers are used to read data from other systems , so it woulfd not have an indices in BIA, I believe if this is the case. except for some applications like BCS wher eyou may be reading data from BW itself.
Hope this helps
Bext regards,
Sunmit.

Question about bad query

Hi all ,
I have small question related to bad query .
what is the affecting happens to database if there is lot of bad query , i know the performance issue is there what's other things .like archive log generated database time , IO , TMP tablespace , please give me information about it's .
thanks & regards.

user11969912 wrote:
I have small question related to bad query . What do you consider a bad query? A bad query can be the result of poorly written and illogical SQL. It can be due to not using bind variables. It can be due to a on-optimal execution plan generated by the CBO. It can be due to poorly designed code that uses what seems to be a "good query", badly and in the wrong way (using bulk collection when a native SQL alone suffices, or hitting the very same data multiple times, etc).
what is the affecting happens to database if there is lot of bad query Each of these have a different impact on the database. A "bad query" can cause a snapshot-too-old error. A deadlock error. A shared pool memory allocation error. Can cause no error and simple increase I/O. Or increase CPU. Etc.
It is a lot more complex than what you seem to think, given your question.

Bad query plan for self-referencing CTE view query and variable in WHERE clause. Is there way out or this is SQL Server defect?

Please help. Thank you for your time and expertise.
Prerequisites: sql query needs to be a view. Real view is more than recursion. It computes location path, is used in JOINs and returns this path.
Problem: no matter what I tried, sql server does not produce 'index seek' when using variable but does with literal.
See full reproduction code below.
I expect that query SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID will seek UNIQUE index but it does not.
I tried these:
1. Changing UX and/or PK to be CLUSTERED.
2. query OPTION(RECOMPILE)
3. FORCESEEK on view
4. SQL Server 2012/2014
5. Wrap it into function and CROSS APPLY. On large outer number of rows this just dies, no solution
but to no avail. This smells like a bug in SQL Server. I am seeking your confirmation.
I am thinking it is a bug as variable value is high-cardinality, 1, and query is against unique key. This must produce single seek, depending if clustered or nonclustred index is unique
Thanks
Vladimir
use tempdb
BEGIN TRAN
-- setup definition
CREATE TABLE dbo.LocationHierarchy(
lcID int NOT NULL ,
lcHID hierarchyid NOT NULL,
lcCode nvarchar(25) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
lcHIDParent AS lcHID.GetAncestor(1) PERSISTED,
CONSTRAINT PK_LocationHierarchy_lcID PRIMARY KEY NONCLUSTERED (lcID ASC),
CONSTRAINT UX_LocationHierarchy_pltID_lcHID UNIQUE CLUSTERED (lcHID ASC)
-- add some data
INSERT INTO dbo.LocationHierarchy
VALUES
(1, '/', 'A')
,(2, '/1/', 'B')
,(3, '/1/1/', 'C')
,(4, '/1/1/1/', 'D')
--DROP VIEW dbo.vwLocationCodes
GO
CREATE VIEW dbo.vwLocationCodes
AS
WITH ru AS
SELECT
lh.lcID
,lh.lcCode
,lh.lcHID
,CAST('/' + lh.lcCode + '/' as varchar(8000)) as LocationPath
-- to support recursion
,lh.lcHIDParent
FROM dbo.LocationHierarchy lh
UNION ALL
SELECT
ru.lcID
,ru.lcCode
,ru.lcHID
,CAST('/' + lh.lcCode + ru.LocationPath as varchar(8000)) as LocationPath
,lh.lcHIDParent
FROM dbo.LocationHierarchy lh
JOIN ru ON ru.lcHIDParent = lh.lcHID
SELECT
lh.lcID
,lh.lcCode
,lh.LocationPath
,lh.lcHID
FROM ru lh
WHERE lh.lcHIDParent IS NULL
GO
-- get data via view
SELECT
CONCAT(SPACE(l.lcHID.GetLevel() * 4), lcCode) as LocationIndented
FROM dbo.vwLocationCodes l
ORDER BY lcHID
GO
SET SHOWPLAN_XML ON
GO
DECLARE @lcID int = 2
-- I believe this produces bad plan and is defect in SQL Server optimizer.
-- variable value cardinality is 1 and SQL Server should know that. Optiomal plan is to do index seek with key lookup.
-- This does not happen.
SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID -- bad plan
-- this is a plan I expect.
SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = 2 -- good plan
-- I reviewed these but I need a view here, can't be SP
-- http://sqlblogcasts.com/blogs/tonyrogerson/archive/2008/05/17/non-recursive-common-table-expressions-performance-sucks-1-cte-self-join-cte-sub-query-inline-expansion.aspx
-- http://social.msdn.microsoft.com/Forums/sqlserver/en-US/22d2d580-0ff8-4a9b-b0d0-e6a8345062df/issue-with-select-using-a-recursive-cte-and-parameterizing-the-query?forum=transactsql
GO
SET SHOWPLAN_XML OFF
GO
ROLLBACK
Vladimir Moldovanenko

Here is more... note that I am creating table Items and these can be in Locations.
I am trying LEFT JOIN and OUTER APLLY to 'bend' query into NESTED LOOP and SEEK. There has to be nested loop, 2 rows against 4. But SQL Server fails to generate optimal plan with SEEK. Even RECOMPILE does not help
use tempdb
BEGIN TRAN
-- setup definition
CREATE TABLE dbo.LocationHierarchy(
lcID int NOT NULL ,
lcHID hierarchyid NOT NULL,
lcCode nvarchar(25) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
lcHIDParent AS lcHID.GetAncestor(1) PERSISTED,
CONSTRAINT PK_LocationHierarchy_lcID PRIMARY KEY NONCLUSTERED (lcID ASC),
CONSTRAINT UX_LocationHierarchy_pltID_lcHID UNIQUE CLUSTERED (lcHID ASC)
-- add some data
INSERT INTO dbo.LocationHierarchy
VALUES
(1, '/', 'A')
,(2, '/1/', 'B')
,(3, '/1/1/', 'C')
,(4, '/1/1/1/', 'D')
--DROP VIEW dbo.vwLocationCodes
GO
--DECLARE @Count int = 10;
--WITH L0 AS (SELECT N FROM (VALUES(1),(1),(1),(1),(1),(1),(1),(1),(1),(1)) N (N))-- 10 rows
--,L1 AS (SELECT n1.N FROM L0 n1 CROSS JOIN L0 n2) -- 100 rows
--,L2 AS (SELECT n1.N FROM L1 n1 CROSS JOIN L1 n2) -- 10,000 rows
--,L3 AS (SELECT n1.N FROM L2 n1 CROSS JOIN L2 n2) -- 100,000,000 rows
--,x AS
-- SELECT TOP (ISNULL(@Count, 0))
-- ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) as Number
-- FROM L3 n1
--SELECT Number as itmID, NTILE(4)OVER(ORDER BY Number) as lcID
--INTO dbo.Items
--FROM x
----ORDER BY n1.N
--ALTER TABLE dbo.Items ALTER COLUMN itmID INT NOT NULL
--ALTER TABLE dbo.Items ADD CONSTRAINT PK PRIMARY KEY CLUSTERED (itmID)
CREATE TABLE dbo.Items (itmID int NOT NULL PRIMARY KEY, lcID int NOT NULL)
INSERT INTO dbo.items
VALUES(1, 1)
,(2, 3)
GO
CREATE VIEW dbo.vwLocationCodes
AS
WITH ru AS
SELECT
lh.lcID
,lh.lcCode
,lh.lcHID
,CAST('/' + lh.lcCode + '/' as varchar(8000)) as LocationPath
-- to support recursion
,lh.lcHIDParent
FROM dbo.LocationHierarchy lh
UNION ALL
SELECT
ru.lcID
,ru.lcCode
,ru.lcHID
,CAST('/' + lh.lcCode + ru.LocationPath as varchar(8000)) as LocationPath
,lh.lcHIDParent
FROM dbo.LocationHierarchy lh
JOIN ru ON ru.lcHIDParent = lh.lcHID
SELECT
lh.lcID
,lh.lcCode
,lh.LocationPath
,lh.lcHID
FROM ru lh
WHERE lh.lcHIDParent IS NULL
GO
-- get data via view
SELECT
CONCAT(SPACE(l.lcHID.GetLevel() * 4), lcCode) as LocationIndented
FROM dbo.vwLocationCodes l
ORDER BY lcHID
GO
--SET SHOWPLAN_XML ON
GO
DECLARE @lcID int = 2
-- I believe this produces bad plan and is defect in SQL Server optimizer.
-- variable value cardinality is 1 and SQL Server should know that. Optiomal plan is to do index seek with key lookup.
-- This does not happen.
SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID-- OPTION(RECOMPILE) -- bad plan
-- this is a plan I expect.
SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = 2 -- good plan
SELECT *
FROM dbo.Items itm
LEFT JOIN dbo.vwLocationCodes l ON l.lcID = itm.lcID
OPTION(RECOMPILE)
SELECT *
FROM dbo.Items itm
OUTER APPLY
SELECT *
FROM dbo.vwLocationCodes l
WHERE l.lcID = itm.lcID
) l
-- I reviewed these but I need a view here, can't be SP
-- http://sqlblogcasts.com/blogs/tonyrogerson/archive/2008/05/17/non-recursive-common-table-expressions-performance-sucks-1-cte-self-join-cte-sub-query-inline-expansion.aspx
-- http://social.msdn.microsoft.com/Forums/sqlserver/en-US/22d2d580-0ff8-4a9b-b0d0-e6a8345062df/issue-with-select-using-a-recursive-cte-and-parameterizing-the-query?forum=transactsql
GO
--SET SHOWPLAN_XML OFF
GO
ROLLBACK
Vladimir Moldovanenko

Join hint ignored - very bad query plan results

I'm trying to get a query that's being generated by SSAS to perform acceptably. Because this query is (at least partially) generated by SSAS, I don't have complete control over the query text.
The problem - The query looks roughly like this:
select
-- a bunch of columns
from
T1 -- table with ~40,000,000 rows
inner loop join T2 on T2.t2id = T1.t2id -- table with ~16,000 rows
inner loop join T3 on T3.t3id = T1.t3id -- table with ~200,000 rows inner loop join T4 on T4.t4id = T1.t4id -- table with ~200,000 rows
left loop join T5 on T5.t3id = T1.t3id and T5.t6id = T4.t6id -- table with 0 rows
where
-- some uninteresting conditions
T1 is a Fact (or Measure) table, T2, T3 and T4 are Dimension tables, T5 and T6 are involved in the filtering of the query. Every row of T1 WILL match exactly one row in each of T1, T2 and T3.
You'll note that I've hinted all of the joins - according to the documentation, using join hints forces join order (which is consistent with the plan that's produced). There's no mention that join hints can be transparently ignored by the optimizer,
but that seems to be precisely what's happening.
In the plan that results, the join to T4 is done as a hash join, with T1*T2*T3 (40,000,000 rows) on the "top", so it ends up trying to build a hash table with 40,000,000 rows, resulting in very high tempdb activity and very poor performance (I
don't know how poor - I've never let it finish).
I can see part of the reason why it's making this join choice - the estimate of T1*T2*T3 is only 35,000 rows, even though T1 has 40,000,000 rows and the join will hit on every row.
Questions:
1. What can I do to the query or the database to improve the estimate on the join to T3?
2. What can I do to the query to force the optimizer to use a loop join like I asked?
Version is SQL Server 2008 R2 SP2 Developer Edition X64.
OS is Windows 2008 R2
Machine is dual-quad-hyper-threaded CPU with 96Gb of RAM and several Tb of disk spread over 8 spindles and SSDs.
I've seen this query perform well before - I've been tuning this query for going on 7 years now and I've never seen it perform this badly that I can recall. Not sure if it's something that's changed in SP2, or something about the distribution
of data in this particular database that's changed, but something's sure changed.
-cd Mark the best replies as answers!

That would indicate that there are no foreign-key constraints, or if they, they are not trusted. (Assuming here that there WHERE clause includes no filter on T1.)
That, or the statistics on T1 are giving a completely wrong estimates for the number of NULL values in t2id and t3id.
Erland Sommarskog, SQL Server MVP, [email protected]
Thanks, Erland.
There are foreign key constraints, but they're NOCHECK. I've tried creating and updating statistics on various columns of the tables involved - I'll re-check that I've got up to date statistics on all of the columns involved in these joins.
What about the join-hint being ignored? Is there anything I can do, or has something changed here recently? Interestingly, when I run this query from SSMS, I get loop-joins all around, but when SSAS runs the query, the one join always comes out
a hash join. Before I added the hints, all joins were hash joins - the hints worked on all joins but the one.
-cd Mark the best replies as answers!

Bad Query Performance in Oracle Text

Hello everyone, I have the following problem:
I have a table, TABLE_A from now on, a table of more or less 1,000.000 rows, with a CONTEXT index, using FILE_DATASTORE, CTXSYS.DEFAULT_STORAGE, CTXSYS.NULL_FILTER, CTXSYS.BASIC_LEXER and querying the index in the following way:
SELECT /*+FIRST_ROWS*/ A.ID, B.ID2, SCORE(1) FROM TABLE_A A, TABLE_B WHERE A.ID = B.ID AND CONTAINS(A.PATH, '<SOME KW>', 1) > 0 ORDER BY SCORE(1) DESC
where TABLE_B has another 1,000.000 rows.
The problem is that the query response time is much higher after some time of inactivity regarding those tables. How can I avoid this behavior?. The fact is that those inactivity times (not more than 20min) are core to my application, so I always get long long response times for my queries.
Is there any cache or cache time parameter that affects this behavior? I have checked the Oracle Text documentation without finding anything about that...
More data: I am using Oracle 9.2.0.1, but I have tested with the latest patches an the behavior is the same...
Thank you very much in advance.

Pablo,
This appears to be a generic database or OS issue, not a Text specific issue. It really depends on what your application is doing.
If your application is doing some other database activity such as queries or DMLs on other non-text tables, chances are Oracle Text related data blocks are being aged out of cache. You can either increase the db_cache_size init
parmater or try to keep the text tables and index tables blocks in cache using ALTER TABLE commands.
If your app is doing NON-database activity, then chances are your application is taking up much of the machine's physical memory such that OS is swapping ORACLE out of the memory. In which case, you may want to consider to add more memory to the machine or have ORACLE run on a separate machine by itself.

Bad Query Performance

Hi Experts,
I have a Query which was built on a multiprovider,Which has a slow preformance.
I think the main problem comes from selecting to many records from
I think it selects 1,1 million rows to display about 500 rows in the result.
Another point could be that the complicated restricted and calculated keyfigures, especially might spend a lot of time in the OLAP processor.
Here are the Statistics of the Query.
OLAP Initialization      : 3,186906
Wait Time, User         :   56,971169
OLAP: Settings               0,983193
Read Cache                     0,015642
Delete Cache                   0,019030
Write Cache                    0,087655
Data Manager                   462,039167
OLAP: Data Selection      0,671566
OLAP: Data Transfer       1,257884.
ST03 Stat:
%OLAP       :22,74
%DB           :77,18
OLAP Time :29,2
DBTime        :99,1
It seems that the maximum time is consuming in the Database
Any suggestion to speed up this Query response time would be great.
Thanks in advance.
BR
Srini.

Hi,
You need to have standard Query performance tuning done for the underlying cubes like better design, aggregates, etc
Improve Performance of Queries/Reports on Multi Cubes
Refer SAP Note Number: 869487
Performance optimization for MultiCubes
How to Create Efficient Multi-Provider Queries
Please see the How to Guide "How to Create Efficient MultiProvider Queries" at http://service.sap.com/bi > SAP NetWeaver 2004 - Release-Specific Information > How-to Guides > Business Intelligence
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/library/biw/how%20to%20create%20efficient%20multiprovider%20queries.pdf
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/3f66ba90-0201-0010-ac8d-b61d8fd9abe9
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/afbad390-0201-0010-daa4-9ef0168d41b6
Performance of MultiProviders
Multiprovider performance / aggregate question
Query Performance
Multicube performances
Create Efficient MultiProvider Queries
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/b03b7f4c-c270-2910-a8b8-91e0f6d77096
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/751be690-0201-0010-5e80-f4f92fb4e4ab
Also try
Achieving BI Query Performance Building Business Intelligence
http://www.dmreview.com/issues/20051001/1038109-1.html
tuning, short dumps
Performance tuning in BW:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/afbad390-0201-0010-daa4-9ef0168d41b6
Also notes
0000903559 MultiProvider optimization is only partially active
0000825396 Performance in reports with many selections
multiprovider explanation i need
Note 629541 - Multiprovider: Parallel Processing
Thanks,
JituK

How can this bad query be improved?

Db:11.2.0.3
We have a 3rd party app and the web app runs very slow. We want to make the 3rd party to fix the issue. for the
app login process, I did an AWR , found the problem query it runs 10 mins. Then I did the sqltrace
here is it:
select clndr_id , count(*)
from
task where (clndr_id = :"SYS_B_0") group by clndr_id union select clndr_id ,
count(*) from project where (clndr_id = :"SYS_B_1") group by clndr_id
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.01       0.00          0          0          0           0
Execute      1      0.01       0.00          0          0          0           0
Fetch        2     53.32     612.03      81650      58920          0           2
total        4     53.34     612.04      81650      58920          0           2
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 34 (PX)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         2          2          2 SORT UNIQUE (cr=58923 pr=81650 pw=22868 time=113329109 us cost=58277 size=24 card=2)
         2          2          2   UNION-ALL (cr=58923 pr=81650 pw=22868 time=113329001 us)
         1          1          1    SORT GROUP BY NOSORT (cr=58330 pr=81070 pw=22868 time=104312437 us cost=58128 size=7 card=1)
   5589739    5589739    5589739     VIEW index$_join$_003 (cr=58330 pr=81070 pw=22868 time=619784236 us cost=57240 size=38875249 card=5553607)
   5589739    5589739    5589739      HASH JOIN (cr=58330 pr=81070 pw=22868 time=617373467 us)
   5590158    5590158    5590158       INDEX RANGE SCAN NDX_TASK_CALENDAR (cr=21676 pr=21676 pw=0 time=113637058 us cost=11057 size=38875249 card=5553607)(object id 24749)
   6673774    6673774    6673774       INDEX FAST FULL SCAN NDX_TASK_PROJ_RSRC (cr=36651 pr=36526 pw=0 time=213370625 us cost=21921 size=38875249 card=5553607)(object id 217274)
         1          1          1    SORT GROUP BY NOSORT (cr=593 pr=580 pw=0 time=9016527 us cost=149 size=17 card=1)
    136390     136390     136390     INDEX FAST FULL SCAN NDX_PROJECT_CALENDAR (cr=593 pr=580 pw=0 time=165434 us cost=132 size=2315876 card=136228)(object id 154409)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      2   SORT (UNIQUE)
      2    UNION-ALL
      1     SORT (GROUP BY NOSORT)
5589739      TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF 'TASK'
                 (TABLE)
5589739       INDEX   MODE: ANALYZED (RANGE SCAN) OF
                  'NDX_TASK_CALENDAR' (INDEX)
5590158     SORT (GROUP BY NOSORT)
6673774      INDEX   MODE: ANALYZED (RANGE SCAN) OF
                 'NDX_PROJECT_CALENDAR' (INDEX)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       2        0.00          0.00
Disk file operations I/O                        2        0.00          0.00
db file sequential read                     22235        1.61        138.66
direct path write                            1620        3.25        177.42
db file scattered read                       2313        1.89        238.98
direct path read                              385        1.72         19.52
SQL*Net message from client                     2        0.11          0.21Please make your comments.
Thanks in Advance.

Salman Qureshi wrote:
Hi,
It looks to me that end result will give you distinct values because of distinct clndr_id. If my thinking is correct, can you use UNION ALL istead of UNION? This will reduce your query execution time by not spending time on removing duplication of results (UNION removes duplication).
Do you have fresh statistics on the tables/indexes involved in this query?
SalmanIt is a 3rd party app, not sure the query is exactly doing for, a good input though,
I have given a try as comparison.
Found
$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
UNION
select clndr_id , count(*)
from
task where (clndr_id = :"SYS_B_0") group by clndr_id union select clndr_id ,
count(*) from project where (clndr_id = :"SYS_B_1") group by clndr_id
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2     31.18      70.39      25288      58920          0           2
total        4     31.18      70.39      25288      58920          0           2
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 34 (PX)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         2          2          2 SORT UNIQUE (cr=58923 pr=25288 pw=25284 time=70390927 us cost=58277 size=24 card=2)
         2          2          2   UNION-ALL (cr=58923 pr=25288 pw=25284 time=70390652 us)
         1          1          1    SORT GROUP BY NOSORT (cr=58330 pr=25288 pw=25284 time=70309151 us cost=58128 size=7 card=1)
   5589739    5589739    5589739     VIEW index$_join$_003 (cr=58330 pr=25288 pw=25284 time=70027453 us cost=57240 size=38875249 card=5553607)
   5589739    5589739    5589739      HASH JOIN (cr=58330 pr=25288 pw=25284 time=68083254 us)
   5590158    5590158    5590158       INDEX RANGE SCAN NDX_TASK_CALENDAR (cr=21676 pr=0 pw=0 time=2449897 us cost=11057 size=38875249 card=5553607)(object id 24749)
   6673774    6673774    6673774       INDEX FAST FULL SCAN NDX_TASK_PROJ_RSRC (cr=36651 pr=0 pw=0 time=3097204 us cost=21921 size=38875249 card=5553607)(object id 217274)
         1          1          1    SORT GROUP BY NOSORT (cr=593 pr=0 pw=0 time=81462 us cost=149 size=17 card=1)
    136390     136390     136390     INDEX FAST FULL SCAN NDX_PROJECT_CALENDAR (cr=593 pr=0 pw=0 time=68732 us cost=132 size=2315876 card=136228)(object id 154409)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      2   SORT (UNIQUE)
      2    UNION-ALL
      1     SORT (GROUP BY NOSORT)
5589739      TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF 'TASK'
                 (TABLE)
5589739       INDEX   MODE: ANALYZED (RANGE SCAN) OF
                  'NDX_TASK_CALENDAR' (INDEX)
5590158     SORT (GROUP BY NOSORT)
6673774      INDEX   MODE: ANALYZED (RANGE SCAN) OF
                 'NDX_PROJECT_CALENDAR' (INDEX)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       2        0.00          0.00
direct path write                            3347        1.59         43.26
direct path read                              130        0.20          0.32
SQL*Net message from client                     2        0.23          0.27
********************************************************************************$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
UNION ALL
SQL ID: d6z3ag876m67h Plan Hash: 4277397671
select clndr_id , count(*)
from
task where (clndr_id = :"SYS_B_0") group by clndr_id union all select
clndr_id , count(*) from project where (clndr_id = :"SYS_B_1") group by
clndr_id
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.01       0.00          0          0          0           0
Fetch        2     31.77      89.93      22886      58920          0           2
total        4     31.78      89.94      22886      58920          0           2
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 34 (PX)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
         2          2          2 UNION-ALL (cr=58932 pr=22887 pw=22868 time=89865448 us)
         1          1          1   SORT GROUP BY NOSORT (cr=58339 pr=22887 pw=22868 time=89865428 us cost=57240 size=7 card=1)
   5589739    5589739    5589739    VIEW index$_join$_003 (cr=58339 pr=22887 pw=22868 time=302390812 us cost=57240 size=38875249 card=5553607)
   5589739    5589739    5589739     HASH JOIN (cr=58339 pr=22887 pw=22868 time=300505731 us)
   5590158    5590158    5590158      INDEX RANGE SCAN NDX_TASK_CALENDAR (cr=21676 pr=0 pw=0 time=2275780 us cost=11057 size=38875249 card=5553607)(object id 24749)
   6673774    6673774    6673774      INDEX FAST FULL SCAN NDX_TASK_PROJ_RSRC (cr=36651 pr=18 pw=0 time=3233656 us cost=21921 size=38875249 card=5553607)(object id 217274)
         1          1          1   SORT GROUP BY NOSORT (cr=593 pr=0 pw=0 time=77989 us cost=132 size=17 card=1)
    136390     136390     136390    INDEX FAST FULL SCAN NDX_PROJECT_CALENDAR (cr=593 pr=0 pw=0 time=55006 us cost=132 size=2315876 card=136228)(object id 154409)
Rows     Execution Plan
      0 SELECT STATEMENT   MODE: ALL_ROWS
      2   UNION-ALL
      1    SORT (GROUP BY NOSORT)
5589739     TABLE ACCESS   MODE: ANALYZED (BY INDEX ROWID) OF 'TASK'
                (TABLE)
5589739      INDEX   MODE: ANALYZED (RANGE SCAN) OF 'NDX_TASK_CALENDAR'
                 (INDEX)
5590158    SORT (GROUP BY NOSORT)
6673774     INDEX   MODE: ANALYZED (RANGE SCAN) OF
                'NDX_PROJECT_CALENDAR' (INDEX)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       2        0.00          0.00
Disk file operations I/O                        2        0.00          0.00
direct path write                            2069        3.12         58.90
db file sequential read                        18        0.78          4.35
direct path read                               22        0.12          0.15
SQL*Net message from client                     2        0.46          0.71
********************************************************************************found union all used 90s vs union 70s, and the logic and the physical reads are about the same.
Notice that we now have it ran less that 2 mins for the query vs 10 mins before.
The before was at the peak hrs and now it is off the peak. the disk read from peak's 81650 reduced to 22886.
that was the cause of slow -- I/O contentions at peak hrs.
How can we improve the query performance by increasing disk throughput?
SQL> show parameter mem
NAME                                 TYPE        VALUE
hi_shared_memory_address             integer     0
memory_max_target                    big integer 4000M
memory_target                        big integer 3600M
shared_memory_address                integer     0
SQL> show parameter db_b
NAME                                 TYPE        VALUE
db_block_buffers                     integer     0
db_block_checking                    string      FALSE
db_block_checksum                    string      TYPICAL
db_block_size                        integer     8192
SQL>

Re-write a bad query

This query works fine for me but it's not a good query it might have performance issues.
select count(*) from EMP.PENSIONS
where FAILURE_ID = (SELECT max(FAILURE_ID) FROM EMP.PENSIONS ) and PERIOD = (select max(PERIOD) from EMP.PENSIONS )
Can someone let me know the best way to re-write it ?

Tuning form questions should include more info but I see one point that may help you.
if you change it like this you will have to query the PENTIONS table only once and if you have an index on (FAILURE_ID, PERIOD ) that should be good for performance.
select count(*) from EMP.PENSIONS
where (FAILURE_ID, PERIOD ) IN (SELECT max(PERIOD) , max(FAILURE_ID) FROM EMP.PENSIONS )

ME_PROCESS_PO_CUST BADI Query

Hi,
I am trying to implement ME_PROCESS_PO_CUST BADI.
My requirement is to diable the NETPR field in ME21N and ME22N Tcodes when the PO is created with ref to an RFQ or Contract.
To achieve this I am implementing the FIELDSELECTION_ITEM method to edit the properties of NETPR field.
TYPE-POOLS: mmmfd.
DATA : po_item TYPE mepoitem.
FIELD-SYMBOLS: <fs> LIKE LINE OF ch_fieldselection.
po_item = im_item->get_data( ).
IF po_item IS NOT INITIAL.
    IF po_item-konnr IS NOT INITIAL.
      READ TABLE ch_fieldselection ASSIGNING <fs> WITH TABLE KEY metafield = mmmfd_out_netpr.
      IF sy-subrc IS INITIAL.
        <fs>-fieldstatus = '*'. " Display
      ENDIF.
    ELSEIF po_item-anfnr IS NOT INITIAL.
      READ TABLE ch_fieldselection ASSIGNING <fs> WITH TABLE KEY metafield = mmmfd_out_netpr.
      IF sy-subrc IS INITIAL.
        <fs>-fieldstatus = '*'. " Display
      ENDIF.
    ENDIF.
ENDIF.
The implementation is active. But still it is not entering this methos. I tried to put a breakpoint also but it didn't stop there.
What can be the possible reason for this? Please suggest...
Edited by: Anup Deshmukh on Aug 3, 2011 12:47 PM

Hi Anup,
find the BADI implementation in SE19, edit, deactivate, activate (Menu Implemention deactivate/activate) or use buttons.
You may reduce the code
    IF po_item-konnr IS NOT INITIAL OR
      ( po_item-konnr IS INITIAL and po_item-anfnr IS NOT INITIAL ).
      READ TABLE ch_fieldselection ASSIGNING <fs> WITH TABLE KEY metafield = mmmfd_out_netpr.
      IF sy-subrc IS INITIAL.
        <fs>-fieldstatus = '*'. " Display
      ENDIF.
    ENDIF.
Regards
Clemens
Edited by: Clemens Li on Aug 3, 2011 2:15 PM

Physical query generation: unneeded dimension tables get joined to the fact

Hi there!
The setup is the following:
There is a logical fact table which is joined to 7 logical dimensions, it has 4 table sources which correspond to different time dimension levels (all other dimensions are mapped to Detail level).
Time dimension logical table also has 4 different table sources (for days, months, quarters, and years).
The data source is an Oracle Database 11gR2.
The problem is:
No matter what the logical query is, in the physical query all 7 joins are performed, even if the resulting data is then simply discarded. This results in very bad query performance.
I feel that it is somehow related to the level-based fragmentation (since, for instance, inclusion of time dimension columns in SELECT list (not in WHERE) seems to affect physical queries), but lack sufficient knowledge to solve this problem or put up with it.
My questions are the following:
1) Have you ever encountered such a situation?
2) Can unneeded joins be eliminated?
2.1) If yes, how?
2.2) If not, then why are they needed?
Thanks in advance!

Physical level:
D01-D06 - ordinary physical tables.
D_DATES - all time levels from dates to years, D_MONTHS - time levels from months to years, also D_QUARTERS and D_YEARS.
F_DAILY - fact table joined to all of the D01-D06 and to D_DATES, F_MONTHLY - joined to D01-D06 and D_MONTHS, also F_QUARTERLY and F_YEARLY. All measure columns are the same.
Logical level:
D01-D06 correspond to ordinary logical tables with a single table source. Logical dimensions are created.
D_TIME is a logical time dimension with four levels (dates, months, quarters, and years) and four table sources ( D_DATES, D_MONTHS, D_QUARTERS, and D_YEARS ).
F is a fact table with four logical table sources ( F_DAILY, F_MONTHLY, F_QUARTERLY, and F_YEARLY ) with aggregation content levels set correspondingly.
OBIEE correctly picks physical table sources for different time levels, but generates extremely inefficient SQL (joining all dimension sources in a WITH-subquery, doing ROW_NUMBER over a result set, and then discarding half the columns, which were not needed to start with).

SQL Query re-write assistance requested

I am needing to know the best way to go about re-writing a bad query at my workplace that needs to run at TOP performance due to very large amounts of data that will be run through it.
I have simplified the data and table to the following mock example:
ID SEQ_N IND
1 1 Y
1 2 N
2 1 N
2 2 N
3 1 N
I need a query that returns each ID, as well as the maximum SEQ_N for each ID. The tricky part is that if there is a "Y" in the indicator (IND) column, then use the maximum SEQ_N for those. If there is no "Y" indicator, then use the maximum SEQ_N for the "N" indicator column. So given the above example data, the query executed would return the following results:
ID MAX(SEQ_N)
1 1
2 2
3 1
I hope that makes sense.. The query we have running currently creates a string and gets the maximum from that. The inner part of the query looks like the following:
select id, max(decode(IND,'Y','1',0') || to_char(SEQ_N, '0000000009')) from table
And the outer query selects from this (using a substring and to_number) to get the sequence number back.. So we have a decode, to_char, substr, and to_number in order to get the job done - this is very expensive; there must be a better way!
Thanks in advance!

Or:
SQL> with t as (select 1 as id, 1 as seq_n, 'Y' ind from dual union all
2    select 1 as id, 2 as seq_n, 'N' as ind from dual union all
3    select 2 as id, 1 as seq_n, 'N' as ind from dual union all
4    select 2 as id, 2 as seq_n, 'N' as ind from dual union all
5    select 3 as id, 2 as seq_n, 'N'from dual)
6 select id,max(seq_n) keep(dense_rank first order by ind desc,seq_n desc) seq_n
7 from t
8 group by id;
        ID      SEQ_N
         1          1
         2          2
         3          2

Query running extremely slow.

Hi All,
I am sitting on 10.2.0.4.0 on linux box. I've got one complain from the application folks regarding the query the slow query , it's running quite long time. I extracted out the explain plan and commulative wait events for sessions and system and found db file sequenciial read caused us the most waits. the same query was running fine a day before. not sure , where to focus ??
++ Query ++
SELECT A.ITEM, A.LOC, MAX(CO1.AFFBILLPR) AFFBILLPR, MAX(CO1.UNIT_COST) UNIT_COST FROM INVOPT_STG.TMP_COST_OCS CO1,
(SELECT SS.LOC, SS.MANUF_LOC, SS.ITEM, MAX(CO.ITEM_10D) ITEM_10D, COUNTRY_CD FROM INVOPT_STG.STG_LOC SL, TMP_COST_OCS CO, STG_SKU SS WHERE
CASE WHEN SL.COUNTRY_CD_COST = CO.COUNTRY_CD THEN SL.COUNTRY_CD_COST
WHEN SL.COUNTRY_CD_COST != NVL((SELECT DISTINCT CO3.COUNTRY_CD FROM INVOPT_STG.TMP_COST_OCS
CO3 WHERE CO3.ITEM_10D = CO.ITEM_10D AND CO3.FYEAR = CO.FYEAR AND CO3.COUNTRY_CD = SL.COUNTRY_CD_COST),' ')
AND SL.COUNTRY_CD_COST= 'US' THEN 'CAN' WHEN SL.COUNTRY_CD_COST != NVL((SELECT DISTINCT CO3.COUNTRY_CD
FROM INVOPT_STG.TMP_COST_OCS CO3 WHERE CO3.ITEM_10D = CO.
ITEM_10D AND CO3.FYEAR = CO.FYEAR AND CO3.COUNTRY_CD = SL.COUNTRY_CD_COST),' ')
AND SL.COUNTRY_CD_COST = 'CAN' THEN 'US' ELSE SL.COUNTRY_CD_COST END = CO.COUNTRY_CD AND CO.COST_TYPE IN ('F') AND CO.ITEM_10D !=
SS.ITEM_10D AND CO.ITEM_10D < SS.ITEM_10D AND
SUBSTR(CO.ITEM_10D,1,9) = SUBSTR(SS.ITEM_10D,1,9)
AND SUBSTR(SL.LOC,1,3) = SS.MANUF_LOC GROUP BY SS.LOC, SS.MANUF_LOC, SS.ITEM,
CO.COUNTRY_CD) A WHERE CO1.ITEM_10D = A.ITEM_10D AND CO1.FYEAR =
(SELECT MAX(CO2.FYEAR) FROM INVOPT_STG.TMP_COST_OCS CO2 WHERE CO2.ITEM_10D
= A.ITEM_10D AND CO2.COST_TYPE = 'F' AND CO2.COUNTRY_CD = A.COUNTRY_CD)
AND CO1.COST_TYPE = 'F' AND CO1.COUNTRY_CD = A.COUNTRY_CD GROUP BY A.ITEM, A.LOC
------ Eplain plan generated from shared pool +++++++++++
| Id | Operation                             | Name            | E-Rows | OMem | 1Mem | Used-Mem | Used-Tmp|
|   1 | HASH GROUP BY                        |                 |      1 |    11M| 2139K| 3095K (1)|    8192 |
|* 2 |   FILTER                              |                 |        |       |       |          |         |
|* 3 |    TABLE ACCESS BY INDEX ROWID        | TMP_COST_OCS    |      1 |       |       |          |         |
|   4 |     NESTED LOOPS                      |                 |      1 |       |       |          |         |
|   5 |      VIEW                             |                 |      1 |       |       |          |         |
|   6 |       HASH GROUP BY                   |                 |      1 |    22M| 4334K| 3898K (1)|   17408 |
|* 7 |        FILTER                         |                 |        |       |       |          |         |
|* 8 |         TABLE ACCESS BY INDEX ROWID   | TMP_COST_OCS    |      1 |       |       |          |         |
|   9 |          NESTED LOOPS                 |                 |      1 |       |       |          |         |
|* 10 |           HASH JOIN                   |                 |      1 | 1179K| 1179K| 1210K (0)|         |
| 11 |            TABLE ACCESS FULL          | STG_LOC         |    155 |       |       |          |         |
| 12 |            TABLE ACCESS FULL          | STG_SKU         |   1738K|       |       |          |         |
|* 13 |           INDEX RANGE SCAN            | TMP_COST_OCS_01 |      1 |       |       |          |         |
| 14 |         SORT UNIQUE NOSORT            |                 |      1 |       |       |          |         |
|* 15 |          TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS    |      1 |       |       |          |         |
|* 16 |           INDEX RANGE SCAN            | TMP_COST_OCS_01 |      3 |       |       |          |         |
| 17 |           SORT UNIQUE NOSORT          |                 |      1 |       |       |          |         |
|* 18 |            TABLE ACCESS BY INDEX ROWID| TMP_COST_OCS    |      1 |       |       |          |         |
|* 19 |             INDEX RANGE SCAN          | TMP_COST_OCS_01 |      3 |       |       |          |         |
|* 20 |      INDEX RANGE SCAN                 | TMP_COST_OCS_01 |      3 |       |       |          |         |
| 21 |    SORT AGGREGATE                     |                 |      1 |       |       |          |         |
|* 22 |     TABLE ACCESS BY INDEX ROWID       | TMP_COST_OCS    |      1 |       |       |          |         |
|* 23 |      INDEX RANGE SCAN                 | TMP_COST_OCS_01 |      3 |       |       |          |         |
Predicate Information (identified by operation id):
   2 - filter("CO1"."FYEAR"=)
   3 - filter(("CO1"."COST_TYPE"='F' AND "CO1"."COUNTRY_CD"="A"."COUNTRY_CD"))
   7 - filter("CO"."COUNTRY_CD"=CASE WHEN ("SL"."COUNTRY_CD_COST"="CO"."COUNTRY_CD") THEN
              "SL"."COUNTRY_CD_COST" WHEN (("SL"."COUNTRY_CD_COST"<>NVL(,' ')) AND ("SL"."COUNTRY_CD_COST"='US'))
              THEN 'CAN' WHEN (("SL"."COUNTRY_CD_COST"<>NVL(,' ')) AND ("SL"."COUNTRY_CD_COST"='CAN')) THEN 'US'
              ELSE "SL"."COUNTRY_CD_COST" END )
   8 - filter("CO"."COST_TYPE"='F')
10 - access("SS"."MANUF_LOC"=SUBSTR("SL"."LOC",1,3))
13 - access("CO"."ITEM_10D"<"SS"."ITEM_10D")
       filter(("CO"."ITEM_10D"<>"SS"."ITEM_10D" AND
              SUBSTR("CO"."ITEM_10D",1,9)=SUBSTR("SS"."ITEM_10D",1,9)))
15 - filter(("CO3"."COUNTRY_CD"=:B1 AND "CO3"."FYEAR"=:B2))
16 - access("CO3"."ITEM_10D"=:B1)
18 - filter(("CO3"."COUNTRY_CD"=:B1 AND "CO3"."FYEAR"=:B2))
19 - access("CO3"."ITEM_10D"=:B1)
20 - access("CO1"."ITEM_10D"="A"."ITEM_10D")
22 - filter(("CO2"."COUNTRY_CD"=:B1 AND "CO2"."COST_TYPE"='F'))
23 - access("CO2"."ITEM_10D"=:B1)
Note
   - Warning: basic plan statistics not available. These are only collected when:
       * hint 'gather_plan_statistics' is used for the statement or
       * parameter 'statistics_level' is set to 'ALL', at session or system level
+++++ System Waits ++++++++
EVENT                                                            TOTAL_WAITS TIME_WAITED AVERAGE_WAIT
db file sequential read                                             11887758     3643542          .31
jobq slave wait                                                         4434     1297399        292.6
db file scattered read                                               3821415      615568          .16
log file parallel write                                               778118      476860          .61
db file parallel write                                                652969      456530           .7
SQL*Net more data to client                                         93400714      364435            0
PX Idle Wait                                                            1078      208509       193.42
control file parallel write                                           141212       62082          .44
log file switch (checkpoint incomplete)                                  323       22567        69.87
log buffer space                                                         786       10051        12.79
log file sync                                                          17816        7988          .45
db file single write                                                   42869        5994          .14
read by other session                                                  13713        5051          .37
log file switch completion                                              1125        4963         4.41
db file parallel read                                                    756        3951         5.23
Data file init write                                                   18444        3569          .19
cursor: pin S wait on X                                                 3280        3409         1.04
os thread startup                                                        452        2250         4.98
direct path read                                                     4438445        1629            0
SQL*Net more data from client                                          73118        1613          .02
control file sequential read                                          291106        1523          .01
local write wait                                                        4707        1169          .25
latch: shared pool                                                       166         954         5.75
direct path read temp                                                4657234         921            0
library cache load lock                                                  313         753         2.41
enq: KO - fast object checkpoint                                        5286         734          .14
PL/SQL lock timer                                                          7         682        97.43
latch: library cache                                                     501         614         1.23
+++ commulative events for session +++
EVENT                                                            TOTAL_WAITS TIME_WAITED AVERAGE_WAIT
db file sequential read                                                 6224        1978          .32
SQL*Net message from client                                               20           2          .09
SQL*Net message to client                                                 20           0            0
log file sync                                                              1           0          .17Edited by: user11983993 on May 18, 2012 11:12 AM

All,
Thanks all of you for your inputs. Well, 2 days back, i logged in as a user , who ran the application query and enabled the level 12 trace and discovered the query never going to complete and press the control-c after 10 min or so and I was left with broken trace file. however , I tkprof'd it and found the "Row Source Operation" and other stuff. now , when I ran the same query it ran in no time and I was start getting the rows in 15 sec of time. I was just unable to figure out ,what had fixed this ? I am also going to past below the comparison stats and hope you guys will able to identify the cause of this behaviour. I tried to do it by comparing the execution plan , but could not able to arrive on any thought. one thing , i would like you to bring into your notice about the fact that while , the bad query were executing (2 days before) , I tried to find out the session waits and discovered , for intiial 5 minutes , it was "SQL*Net message to client ,SQL*Net message from client" and after that it was only "cache buffer chain lru" wait event till i press control-c.
once agian , thanks a lot !!
---bad query explian plan ----
| Id | Operation                             | Name            | E-Rows | OMem | 1Mem | Used-Mem | Used-Tmp|
|   1 | HASH GROUP BY                        |                 |      1 |    11M| 2139K| 3095K (1)|    8192 |
|* 2 |   FILTER                              |                 |        |       |       |          |         |
|* 3 |    TABLE ACCESS BY INDEX ROWID        | TMP_COST_OCS    |      1 |       |       |          |         |
|   4 |     NESTED LOOPS                      |                 |      1 |       |       |          |         |
|   5 |      VIEW                             |                 |      1 |       |       |          |         |
|   6 |       HASH GROUP BY                   |                 |      1 |    22M| 4334K| 3898K (1)|   17408 |
|* 7 |        FILTER                         |                 |        |       |       |          |         |
|* 8 |         TABLE ACCESS BY INDEX ROWID   | TMP_COST_OCS    |      1 |       |       |          |         |
|   9 |          NESTED LOOPS                 |                 |      1 |       |       |          |         |
|* 10 |           HASH JOIN                   |                 |      1 | 1179K| 1179K| 1210K (0)|         |
| 11 |            TABLE ACCESS FULL          | STG_LOC         |    155 |       |       |          |         |
| 12 |            TABLE ACCESS FULL          | STG_SKU         |   1738K|       |       |          |         |
|* 13 |           INDEX RANGE SCAN            | TMP_COST_OCS_01 |      1 |       |       |          |         |
| 14 |         SORT UNIQUE NOSORT            |                 |      1 |       |       |          |         |
|* 15 |          TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS    |      1 |       |       |          |         |
|* 16 |           INDEX RANGE SCAN            | TMP_COST_OCS_01 |      3 |       |       |          |         |
| 17 |           SORT UNIQUE NOSORT          |                 |      1 |       |       |          |         |
|* 18 |            TABLE ACCESS BY INDEX ROWID| TMP_COST_OCS    |      1 |       |       |          |         |
|* 19 |             INDEX RANGE SCAN          | TMP_COST_OCS_01 |      3 |       |       |          |         |
|* 20 |      INDEX RANGE SCAN                 | TMP_COST_OCS_01 |      3 |       |       |          |         |
| 21 |    SORT AGGREGATE                     |                 |      1 |       |       |          |         |
|* 22 |     TABLE ACCESS BY INDEX ROWID       | TMP_COST_OCS    |      1 |       |       |          |         |
|* 23 |      INDEX RANGE SCAN                 | TMP_COST_OCS_01 |      3 |       |       |          |         |
---- good query explain plan ------
| Id | Operation                            | Name            | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                     |                 | 5451K|   493M|       |   632K (6)| 02:06:27 |
|   1 | HASH GROUP BY                       |                 | 5451K|   493M| 1183M|   632K (6)| 02:06:27 |
|* 2 |   HASH JOIN                          |                 | 5451K|   493M|    26M|   512K (7)| 01:42:36 |
|* 3 |    TABLE ACCESS FULL                 | TMP_COST_OCS    |   649K|    18M|       |   779   (4)| 00:00:10 |
|* 4 |    HASH JOIN                         |                 |    16M| 1037M|    24M|   449K (8)| 01:29:55 |
|   5 |     VIEW                             | VW_SQ_1         |   649K|    17M|       | 6865   (2)| 00:01:23 |
|   6 |      HASH GROUP BY                   |                 |   649K|    21M|    64M| 6865   (2)| 00:01:23 |
|* 7 |       TABLE ACCESS FULL              | TMP_COST_OCS    |   649K|    21M|       |   779   (4)| 00:00:10 |
|   8 |     VIEW                             |                 |    27M|   974M|       |   376K (9)| 01:15:22 |
|   9 |      HASH GROUP BY                   |                 |    27M| 1290M| 3397M|   376K (9)| 01:15:22 |
|* 10 |       FILTER                         |                 |       |       |       |            |          |
|* 11 |        HASH JOIN                     |                 |    27M| 1290M|    14M| 38992 (71)| 00:07:48 |
|* 12 |         HASH JOIN                    |                 |   361K|     9M|       | 9151   (3)| 00:01:50 |
| 13 |          TABLE ACCESS FULL           | STG_LOC         |   155 | 1085 |       |     3   (0)| 00:00:01 |
| 14 |          TABLE ACCESS FULL           | STG_SKU         | 1738K|    36M|       | 9127   (3)| 00:01:50 |
|* 15 |         TABLE ACCESS FULL            | TMP_COST_OCS    |   649K|    12M|       |   779   (4)| 00:00:10 |
| 16 |        SORT UNIQUE NOSORT            |                 |     1 |    18 |       |     2 (50)| 00:00:01 |
|* 17 |         TABLE ACCESS BY INDEX ROWID | TMP_COST_OCS    |     1 |    18 |       |     1   (0)| 00:00:01 |
|* 18 |          INDEX RANGE SCAN            | TMP_COST_OCS_01 |     3 |       |       |     1   (0)| 00:00:01 |
| 19 |          SORT UNIQUE NOSORT          |                 |     1 |    18 |       |     2 (50)| 00:00:01 |
|* 20 |           TABLE ACCESS BY INDEX ROWID| TMP_COST_OCS    |     1 |    18 |       |     1   (0)| 00:00:01 |
|* 21 |            INDEX RANGE SCAN          | TMP_COST_OCS_01 |     3 |       |       |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("CO1"."ITEM_10D"="A"."ITEM_10D" AND "CO1"."FYEAR"="VW_COL_1" AND
              "CO1"."COUNTRY_CD"="A"."COUNTRY_CD")
   3 - filter("CO1"."COST_TYPE"='F')
   4 - access("ITEM_10D"="A"."ITEM_10D" AND "COUNTRY_CD"="A"."COUNTRY_CD")
   7 - filter("CO2"."COST_TYPE"='F')
10 - filter("CO"."COUNTRY_CD"=CASE WHEN ("SL"."COUNTRY_CD_COST"="CO"."COUNTRY_CD") THEN
              "SL"."COUNTRY_CD_COST" WHEN (("SL"."COUNTRY_CD_COST"<>NVL( (SELECT DISTINCT "CO3"."COUNTRY_CD" FROM
              "INVOPT_STG"."TMP_COST_OCS" "CO3" WHERE "CO3"."ITEM_10D"=:B1 AND "CO3"."COUNTRY_CD"=:B2 AND
              "CO3"."FYEAR"=:B3),' ')) AND ("SL"."COUNTRY_CD_COST"='US')) THEN 'CAN' WHEN
              (("SL"."COUNTRY_CD_COST"<>NVL( (SELECT DISTINCT "CO3"."COUNTRY_CD" FROM "INVOPT_STG"."TMP_COST_OCS"
              "CO3" WHERE "CO3"."ITEM_10D"=:B4 AND "CO3"."COUNTRY_CD"=:B5 AND "CO3"."FYEAR"=:B6),' ')) AND
              ("SL"."COUNTRY_CD_COST"='CAN')) THEN 'US' ELSE "SL"."COUNTRY_CD_COST" END )
11 - access(SUBSTR("CO"."ITEM_10D",1,9)=SUBSTR("SS"."ITEM_10D",1,9))
       filter("CO"."ITEM_10D"<>"SS"."ITEM_10D" AND "CO"."ITEM_10D"<"SS"."ITEM_10D")
12 - access("SS"."MANUF_LOC"=SUBSTR("SL"."LOC",1,3))
15 - filter("CO"."COST_TYPE"='F')
17 - filter("CO3"."COUNTRY_CD"=:B1 AND "CO3"."FYEAR"=:B2)
18 - access("CO3"."ITEM_10D"=:B1)
20 - filter("CO3"."COUNTRY_CD"=:B1 AND "CO3"."FYEAR"=:B2)
21 - access("CO3"."ITEM_10D"=:B1)
-------- bad query's tkprof stuff , which was cancel in the middle of query execution ++++
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.01          0          0          0           0
Execute      1      0.00       0.01          0          0          0           0
Fetch        1   2996.84    2926.75          0   38309573          0           0
total        3   2996.85    2926.78          0   38309573          0           0
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 66
Rows     Row Source Operation
      0 HASH GROUP BY (cr=0 pr=0 pw=0 time=139 us)
      0   FILTER (cr=0 pr=0 pw=0 time=86 us)
      0    TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=0 pr=0 pw=0 time=77 us)
      1     NESTED LOOPS (cr=0 pr=0 pw=0 time=66 us)
      0      VIEW (cr=0 pr=0 pw=0 time=59 us)
      0       HASH GROUP BY (cr=0 pr=0 pw=0 time=55 us)
38000        FILTER (cr=38309122 pr=0 pw=0 time=2955467939 us)
329898         TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=34815004 pr=0 pw=0 time=3206861519 us)
357855          NESTED LOOPS (cr=34485441 pr=0 pw=0 time=2877866697 us)
27718           HASH JOIN (cr=2390 pr=0 pw=0 time=307908 us)
    157            TABLE ACCESS FULL STG_LOC (cr=7 pr=0 pw=0 time=361 us)
85765            TABLE ACCESS FULL STG_SKU (cr=2383 pr=0 pw=0 time=171835 us)
330137           INDEX RANGE SCAN TMP_COST_OCS_01 (cr=34483052 pr=0 pw=0 time=2912095494 us)(object id 306305)
46627         SORT UNIQUE NOSORT (cr=1930740 pr=0 pw=0 time=6990387 us)
46738          TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=1930740 pr=0 pw=0 time=5650002 us)
1538792           INDEX RANGE SCAN TMP_COST_OCS_01 (cr=391948 pr=0 pw=0 time=3003592 us)(object id 306305)
45806         SORT UNIQUE NOSORT (cr=1563378 pr=0 pw=0 time=4985698 us)
45911          TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=1563378 pr=0 pw=0 time=4041604 us)
1245053           INDEX RANGE SCAN TMP_COST_OCS_01 (cr=318325 pr=0 pw=0 time=2173830 us)(object id 306305)
      0      INDEX RANGE SCAN TMP_COST_OCS_01 (cr=0 pr=0 pw=0 time=0 us)(object id 306305)
      0    SORT AGGREGATE (cr=0 pr=0 pw=0 time=0 us)
      0     TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=0 pr=0 pw=0 time=0 us)
      0      INDEX RANGE SCAN TMP_COST_OCS_01 (cr=0 pr=0 pw=0 time=0 us)(object id 306305)
+++++ good query's tkprof stuuf ++++
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch     7501     15.96      15.85          0    2276084          0      112498
total     7503     15.96      15.85          0    2276084          0      112498
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 66
Rows     Row Source Operation
112498 HASH GROUP BY (cr=2276084 pr=0 pw=0 time=15772334 us)
116586   HASH JOIN (cr=2276084 pr=0 pw=0 time=16810414 us)
646757    TABLE ACCESS FULL TMP_COST_OCS (cr=3847 pr=0 pw=0 time=646966 us)
116586    HASH JOIN (cr=2272237 pr=0 pw=0 time=15790569 us)
346815     VIEW VW_SQ_1 (cr=3847 pr=0 pw=0 time=1533825 us)
346815      HASH GROUP BY (cr=3847 pr=0 pw=0 time=840189 us)
646757       TABLE ACCESS FULL TMP_COST_OCS (cr=3847 pr=0 pw=0 time=646848 us)
116586     VIEW (cr=2268390 pr=0 pw=0 time=14541517 us)
116586      HASH GROUP BY (cr=2268390 pr=0 pw=0 time=14308341 us)
464160       FILTER (cr=2268390 pr=0 pw=0 time=5393370 us)
3839448        HASH JOIN (cr=49577 pr=0 pw=0 time=8893424 us)
484783         HASH JOIN (cr=45730 pr=0 pw=0 time=1454928 us)
    157          TABLE ACCESS FULL STG_LOC (cr=7 pr=0 pw=0 time=217 us)
1738212          TABLE ACCESS FULL STG_SKU (cr=45723 pr=0 pw=0 time=1738234 us)
646757         TABLE ACCESS FULL TMP_COST_OCS (cr=3847 pr=0 pw=0 time=648498 us)
38587        SORT UNIQUE NOSORT (cr=1312207 pr=0 pw=0 time=4759042 us)
38924         TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=1312207 pr=0 pw=0 time=3864377 us)
1017138          INDEX RANGE SCAN TMP_COST_OCS_01 (cr=295069 pr=0 pw=0 time=1974848 us)(object id 306305)
36877        SORT UNIQUE NOSORT (cr=906606 pr=0 pw=0 time=3136870 us)
37214         TABLE ACCESS BY INDEX ROWID TMP_COST_OCS (cr=906606 pr=0 pw=0 time=2506882 us)
701899          INDEX RANGE SCAN TMP_COST_OCS_01 (cr=204707 pr=0 pw=0 time=1305913 us)(object id 306305)
+++++++

Use plan from stored_outlines from query with different syntax?

Hello,
I'd like to know is there any ability to use via stored_outlines plan from query with different syntax?
Database version - 11.1.06
If yes, maybe you'll take a look at steps (based on Metalink 726802.1), what I tried to do to make it work (with no success):
alter session set create_stored_outlines=good;
run good query
create private outline good from SYS_OUTLINE_0... -< GOOD
alter session set create_stored_outlines=bad;
run bad query
create private outline good from SYS_OUTLINE_0... -< BAD
update ol$ set sql_text, textlen, signature, hash_value, hash_value2 from BAD to GOOD records
leave ol$hintcount for GOOD untouched
delete ol$ where ol_name='BAD';
delete ol$hints where ol_name='BAD';
delete ol$nodes where ol_name='BAD';
execute dbms_outln_edit.refresh_private_outline('GOOD');
alter session set sql_trace=true;
alter session set use_private_outlines=true;
run bad query
examine trace file and find that it use execution plan different from both bad and good queries
PS: Originally bad query is posted already Re: Poor performance while join of 2 comprehensive large views and small table
PPS: Also I review thread CBO not picking correct indexes or doing Full Scans
Thanks,
Sergiy
Edited by: kiberpress on Sep 30, 2009 6:59 AM

A query with different syntax would result in a different hash value.
Stored outlines work based on hash value.
Your question is probably answered now.
Sybrand Bakker
Senior Oracle DBA

Sort GridControl modeled with parameterized query (bug?)

I am using JDev 3.2.3. I created a ViewObject in expert mode which contained a parameterized query:
select emp_name, salary
from employees
where
dept_no = :1
Then, through a few workarounds, I managed to create a BC4J data form containing a GridControl linked to the ViewObject.
Cleared the associated empsRowSetInfo.queryOnOpen(false).
Created a button with action event:
empsRowSetInfo.setQueryConditionParams(new Object[] {
deptId
empsRowSetInfo.executeQuery();
This all works fine.
***The problem***
If you press on a header to re-sort the grid, a bad sql query error is thrown and details shows the following bad query:
select * from (
select emp_name, salary
from employees
where
dept_no = :1)
order by asc emp_name
ORA-00904: invalid column name
The GridControl headers appear to be getting their own copy of the ViewObject's query, then misinterpretting it. This works fine for non-parameterized queries since the column names are explicit. However :1 is not a column name but a place holder in my parameterized query.
Shouldn't the headers be using the same mechanism to sort the grid as used to populate the grid model originally?
Any suggestions for a workaround? Pressing a column header fatally breaks the form. Pressing the button again to re-execute the original query continues to throw the error!
Thanks,

This is clearly a bug.
DAC is in 9.0.2 + replaced by JClient.
It might be hard to get a fix for this problem.
As far as a workaround.
You can provide your own SortDelegate.
Start with diagnosing the problem by extracting the SortDelegate class out of 'dacf-src.zip'.
Change it into a mySortDelegate.java.
Set the sortDelegate property on the gridControl. (use an instance of mySortDelegate).
You should be able to step into your implementation and see what the problem is.
Hopefully you will be able to fix the problem in your sortDelegate class.

HR BADI query

Similar Messages

Maybe you are looking for