Performance with Nested Views
Hello everyone, we are having a performance problem with oracle optimizing nested views. Some with outer joins. One of the guys just sent me the following statement and I'm wondering if anyone can tell me if it sounds correct. The query is about 300 lines long so I won't post it here, but hopefully someone can still help with sheding some light on the statement below.
When Oracle executes a view it optimizes the query plan only for the columns of the view which are used and eliminates unnecessary joins, function calls, etc.. In this case the join is a LEFT OUTER i.e. optional and since the columns are not used I would hope Oracle would eliminate this from the plan but… it didn’t.
Thanks for any help,
Michael Cunningham
Depending on the version of Oracle (this was introduced in 10.2), it is possible that Oracle can eliminate a join. The Oracle Optimizer group has a nice blog post that discusses the requirements for join elimination to happen. Basically, Oracle has to be sure that the additional columns aren't being used but also that the join does not change the number of rows that might be returned.
Justin
Similar Messages
-
ABAP Select statement performance (with nested NOT IN selects)
Hi Folks,
I'm working on the ST module and am working with the document flow table VBFA. The query takes a large amount of time, and is timing out in production. I am hoping that someone would be able to give me a few tips to make this run faster. In our test environment, this query take 12+ minutes to process.
SELECT vbfa~vbeln
vbfa~vbelv
Sub~vbelv
Material~matnr
Material~zzactshpdt
Material~werks
Customer~name1
Customer~sortl
FROM vbfa JOIN vbrk AS Parent ON ( Parentvbeln = vbfavbeln )
JOIN vbfa AS Sub ON ( Subvbeln = vbfavbeln )
JOIN vbap AS Material ON ( Materialvbeln = Subvbelv )
JOIN vbak AS Header ON ( Headervbeln = Subvbelv )
JOIN vbpa AS Partner ON ( Partnervbeln = Subvbelv )
JOIN kna1 AS Customer ON ( Customerkunnr = Partnerkunnr )
INTO (WA_Transfers-vbeln,
WA_Transfers-vbelv,
WA_Transfers-order,
WA_Transfers-MATNR,
WA_Transfers-sdate,
WA_Transfers-sfwerks,
WA_Transfers-name1,
WA_Transfers-stwerks)
WHERE vbfa~vbtyp_n = 'M' "Invoice
AND vbfa~fktyp = 'L' "Delivery Related Billing Doc
AND vbfa~vbtyp_v = 'J' "Delivery Doc
AND vbfa~vbelv IN S_VBELV
AND Sub~vbtyp_n = 'M' "Invoice Document Type
AND Sub~vbtyp_v = 'C' "Order Document Type
AND Partner~parvw = 'WE' "Ship To Party(actual desc. is SH)
AND Material~zzactshpdt IN S_SDATE
AND ( Parentfkart = 'ZTRA' OR Parentfkart = 'ZTER' )
AND vbfa~vbelv NOT IN
( SELECT subvbfa~vbelv
FROM vbfa AS subvbfa
WHERE subvbfavbelv = vbfavbelv
AND subvbfa~vbtyp_n = 'V' ) "Purchase Order
AND vbfa~vbelv NOT IN
( SELECT DelList~vbeln
FROM vbfa AS DelList
WHERE DelListvbeln = vbfavbelv
AND DelList~vbtyp_v = 'C' "Order Document Type
AND DelList~vbelv IN "Delivery Doc
( SELECT OrderList~vbelv
FROM vbfa AS OrderList
WHERE OrderList~vbtyp_n = 'H' ) "Return Ord
APPEND WA_Transfers TO ITAB_Transfers.
ENDSELECT.
Cheers,
ChrisI am sending u some of the performance isuues that are to be kept in mind while coding.
1.Donot use Select *...... instead use Select <required list>......
2.Donot fetch data from CLUSTER tables.
3.Donot use Nested Select statements as. U have used nested select which reduces performance to a greater extent.
Instead use views/join .
Also keep in mind that not use join condition for more for more than three tables unless otherwise required.
So split select statements into three or four and use Select ......for all entries....
4.Extract the data from the database atonce consolidated upfront into table.
i.e. use INTO TABLE <ITAB> clause instead of using
Select----
End Select.
5.Never use order by clause in Select ..... statement. instead use SORT<itab>.
6.When ever u need to calculate max,min,avg,sum,count use AGGREGATE FUNCTIONS and GROUP BY clause insted of calculating by userself..
7.Donot use the same table once for Validation and another time for data extraction.select data only once.
8.When the intention is for validation use Select single ....../Select.......up to one rows ......statements.
9.If possible always use array operations to update the database tables.
10.Order of the fields in the where clause select statement must be in the same order in the index of table.
11.Never release the object unless throughly checked by st05/se30/slin.
12.Avoid using identical select statements. -
Hello, I have an extremely complicated query, that has a structure similar to:
Overall Query
---SubQueryA
-------SubQueryB
---SubQueryB
---SubQueryC
-------SubQueryA
The subqueries themselves are slow, and having to run them multiple times is much too slow! Ideally, I would be able to run each subquery once, and then use the results. I cannot use standard oracle tables, and i would need to keep the result of the subqueries in memory.
I was thinking I write a pl/sql script that did the subqueries at the beginning and stored the results in memory. Then in the overall query, I could loop through my results in memory, and join the results of the various subqueries to one another.
some questions:
-what is the best data structure to use? I've been looking around and there are nested arrays, and there's the bulk insert functionality, but I'm not sure what is the best to you
-the advantage of the method I'm suggesting is that I only have to do each subquery once. But, when I start joining the results of the subquery to one another, will I take a performance hit? will Oracle not be able to optimize the joins?
thanks in advance!
CoopI cannot use standard oracle tablesWhat does this mean? If you have subqueries, i assume you have tables to drive them? You're in an Oracle forum, so i assume the tables are Oracle tables.
If so, you can look into the WITH clause, it can 'cache' the query results for you and reuse them multiple times, also helpful in making large queries with many subqueries more readable. -
My left arrow does not work on my macbook pro(model A1226).
I have reset nvram, performed a safe boot, pulled the cache to desktop, replaced .globalpreference.plist, & tested all other keys with "keyboard viewer" (all other keys work except for the arrow).
In addition, I have gone thru all the recommended checks with universal access and have booted from snow leopard dvd and the left arrow still does not work.
I have tried using the left arrow key in all of applications I use such as: excel, ms word, address book, calendar, iphoto, terminal, & highlighting an icon and using the arrows to move to another selected icon.
Here is the kicker! In addition, I purchased a logitech solar bluetooth keyboard and the arrows work fine with my ipad but do not work when paired with the macbook pro. All other keys work fine on the macbook pro using the bluetooth keyboard.
I believe this says that the problem is not in my macbook pro keyboard. So where can it be?
Can anyone think of any other rabbit holes I can search?
thanks and regards
vats3I would also like to add that I've reverted the two cd drive and hard drive mods I did and the laptop is back to factory hardware and there is 0 corrosion or mold visible.
-
Query rewrites with Nested materialized views with different aggregations
Platform used : Oracle 11g.
Here is a simple fact table (with measures m1,m2) and dimensions (a) Location (b) Calendar and (c) Product. The business problem is that aggregation operator for measure m1,m2 are different along location dimension and Calendar dimension. The intention is to preaggregate the measures for a product along the calendar dimension and Location dimension and store it as materialized views.
The direct option is to define a materialized view with Inline queries (Because of the different aggrergation operator, it is not possible to write a query without Inline query). http://download-uk.oracle.com/docs/cd/B28359_01/server.111/b28313/qradv.htm#BABEAJBF documents the limitations that it works only for 'Text match' and 'Equivalent queries' and that is too limiting.
So decided to have nested materialized view, with first view having just joins(my_dim_mvw_joins), the second view having aggregations along Calendar dimension (my_dim_mvw_calendar) and third view having aggregations along the Location dimension(my_dim_mvw_location). Obviously I do not want the query I fire to know about materialized views and I fire it against the fact table. I see that for the fired query (Which needs aggregations along both Calendar and Location), is rewritten with just second materialized view but not the third. (Had set QUERY_REWRITE_INTEGRITY as TRUSTED) .
Wanted to know whether there are limitations on Query Writes with nested materialized views? Thanks
(Have given a simple testable example below. Pls ignore the values given in 'CALENDAR_IDs', 'PRODUCT_IDs' etc as they are the same for all the queries)
-- Calendar hierarchy table
CREATE TABLE CALENDAR_HIERARCHY_TREE
( "CALENDAR_ID" NUMBER(5,0) NOT NULL ENABLE,
"HIERARCHY1_ID" NUMBER(5,0),
"HIERARCHY2_ID" NUMBER(5,0),
"HIERARCHY3_ID" NUMBER(5,0),
"HIERARCHY4_ID" NUMBER(5,0),
CONSTRAINT "CALENDAR_HIERARCHY_TREE_PK" PRIMARY KEY ("CALENDAR_ID")
-- Location hierarchy table
CREATE TABLE LOCATION_HIERARCHY_TREE
( "LOCATION_ID" NUMBER(3,0) NOT NULL ENABLE,
"HIERARCHY1_ID" NUMBER(3,0),
"HIERARCHY2_ID" NUMBER(3,0),
"HIERARCHY3_ID" NUMBER(3,0),
"HIERARCHY4_ID" NUMBER(3,0),
CONSTRAINT "LOCATION_HIERARCHY_TREE_PK" PRIMARY KEY ("LOCATION_ID")
-- Product hierarchy table
CREATE TABLE PRODUCT_HIERARCHY_TREE
( "PRODUCT_ID" NUMBER(3,0) NOT NULL ENABLE,
"HIERARCHY1_ID" NUMBER(3,0),
"HIERARCHY2_ID" NUMBER(3,0),
"HIERARCHY3_ID" NUMBER(3,0),
"HIERARCHY4_ID" NUMBER(3,0),
"HIERARCHY5_ID" NUMBER(3,0),
"HIERARCHY6_ID" NUMBER(3,0),
CONSTRAINT "PRODUCT_HIERARCHY_TREE_PK" PRIMARY KEY ("PRODUCT_ID")
-- Fact table
CREATE TABLE RETAILER_SALES_TBL
( "PRODUCT_ID" NUMBER,
"PRODUCT_KEY" VARCHAR2(50 BYTE),
"PLAN_ID" NUMBER,
"PLAN_PERIOD_ID" NUMBER,
"PERIOD_ID" NUMBER(5,0),
"M1" NUMBER,
"M2" NUMBER,
"M3" NUMBER,
"M4" NUMBER,
"M5" NUMBER,
"M6" NUMBER,
"M7" NUMBER,
"M8" NUMBER,
"LOCATION_ID" NUMBER(3,0),
"M9" NUMBER,
CONSTRAINT "RETAILER_SALES_TBL_LOCATI_FK1" FOREIGN KEY ("LOCATION_ID")
REFERENCES LOCATION_HIERARCHY_TREE ("LOCATION_ID") ENABLE,
CONSTRAINT "RETAILER_SALES_TBL_PRODUC_FK1" FOREIGN KEY ("PRODUCT_ID")
REFERENCES PRODUCT_HIERARCHY_TREE ("PRODUCT_ID") ENABLE,
CONSTRAINT "RETAILER_SALES_TBL_CALEND_FK1" FOREIGN KEY ("PERIOD_ID")
REFERENCES CALENDAR_HIERARCHY_TREE ("CALENDAR_ID") ENABLE
-- Location dimension definition to promote query rewrite
create DIMENSION LOCATION_DIM
LEVEL CHAIN IS LOCATION_HIERARCHY_TREE.HIERARCHY1_ID
LEVEL CONSUMER_SEGMENT IS LOCATION_HIERARCHY_TREE.HIERARCHY3_ID
LEVEL STORE IS LOCATION_HIERARCHY_TREE.LOCATION_ID
LEVEL TRADING_AREA IS LOCATION_HIERARCHY_TREE.HIERARCHY2_ID
HIERARCHY PROD_ROLLUP (
STORE CHILD OF
CONSUMER_SEGMENT CHILD OF
TRADING_AREA CHILD OF
CHAIN
-- Calendar dimension definition
create DIMENSION CALENDAR_DIM
LEVEL MONTH IS CALENDAR_HIERARCHY_TREE.HIERARCHY3_ID
LEVEL QUARTER IS CALENDAR_HIERARCHY_TREE.HIERARCHY2_ID
LEVEL WEEK IS CALENDAR_HIERARCHY_TREE.CALENDAR_ID
LEVEL YEAR IS CALENDAR_HIERARCHY_TREE.HIERARCHY1_ID
HIERARCHY CALENDAR_ROLLUP (
WEEK CHILD OF
MONTH CHILD OF
QUARTER CHILD OF
YEAR
-- Materialized view with just joins needed for other views
CREATE MATERIALIZED VIEW my_dim_mvw_joins build immediate refresh complete enable query rewrite as
select product_id, lht.HIERARCHY1_ID, lht.HIERARCHY2_ID, lht.HIERARCHY3_ID, lht.location_id, cht.HIERARCHY1_ID year,
cht.HIERARCHY2_ID quarter, cht.HIERARCHY3_ID month, cht.calendar_id week, m1, m3, m7, m9
from retailer_sales_tbl RS, calendar_hierarchy_tree cht, location_hierarchy_tree lht
WHERE RS.period_id = cht.CALENDAR_ID
and RS.location_id = lht.location_id
and cht.CALENDAR_ID in (10,236,237,238,239,608,609,610,611,612,613,614,615,616,617,618,619,1426,1427,1428,1429,1430,1431,1432,1433,1434,1435,1436,1437,1438,1439,1440,1441,1442,1443,1444,1445,1446,1447,1448,1449,1450,1451,1452,1453,1454,1455,1456,1457,1458,1459,1460,1461,1462,1463,1464,1465,1466,1467,1468,1469,1470,1471,1472,1473,1474,1475,1476,1477)
AND product_id IN (5, 6, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20)
AND lht.location_id IN (2, 3, 11, 12, 13, 14, 15, 4, 16, 17, 18, 19, 20)
-- Materialized view which aggregate along calendar dimension
CREATE MATERIALIZED VIEW my_dim_mvw_calendar build immediate refresh complete enable query rewrite as
select product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID ,location_id, year, quarter, month, week,
sum(m1) m1_total, sum(m3) m3_total, sum(m7) m7_total, sum(m9) m9_total,
GROUPING_ID(product_id, location_id, year, quarter, month, week) dim_mvw_gid
from my_dim_mvw_joins
GROUP BY product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID , location_id,
rollup (year, quarter, month, week);
-- Materialized view which aggregate along Location dimension
CREATE MATERIALIZED VIEW my_dim_mvw_location build immediate refresh complete enable query rewrite as
select product_id, year, quarter, month, week, HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id,
sum(m1_total) m1_total_1, sum(m3_total) m3_total_1, sum(m7_total) m7_total_1, sum(m9_total) m9_total_1,
GROUPING_ID(product_id, HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id, year, quarter, month, week) dim_mvw_gid
from my_dim_mvw_calendar
GROUP BY product_id, year, quarter, month, week,
rollup (HIERARCHY1_ID, HIERARCHY2_ID, HIERARCHY3_ID, location_id)
-- SQL Query Fired (for simplicity have used SUM as aggregation operator for both, but they will be different)
select product_id, year, HIERARCHY1_ID, HIERARCHY2_ID,
sum(m1_total) m1_total_1, sum(m3_total) m3_total_1, sum(m7_total) m7_total_1, sum(m9_total) m9_total_1
from
select product_id, HIERARCHY1_ID , HIERARCHY2_ID , year,
sum(m1) m1_total, sum(m3) m3_total, sum(m7) m7_total, sum(m9) m9_total
from
select product_id, lht.HIERARCHY1_ID , lht.HIERARCHY2_ID , lht.HIERARCHY3_ID ,lht.location_id, cht.HIERARCHY1_ID year, cht.HIERARCHY2_ID quarter, cht.HIERARCHY3_ID month, cht.calendar_id week,m1,m3,m7,m9
from
retailer_sales_tbl RS, calendar_hierarchy_tree cht, location_hierarchy_tree lht
WHERE RS.period_id = cht.CALENDAR_ID
and RS.location_id = lht.location_id
and cht.CALENDAR_ID in (10,236,237,238,239,608,609,610,611,612,613,614,615,616,617,618,619,1426,1427,1428,1429,1430,1431,1432,1433,1434,1435,1436,1437,1438,1439,1440,1441,1442,1443,1444,1445,1446,1447,1448,1449,1450,1451,1452,1453,1454,1455,1456,1457,1458,1459,1460,1461,1462,1463,1464,1465,1466,1467,1468,1469,1470,1471,1472,1473,1474,1475,1476,1477)
AND product_id IN (5, 6, 7, 8, 11, 12, 13, 14, 17, 18, 19, 20)
AND lht.location_id IN (2, 3, 11, 12, 13, 14, 15, 4, 16, 17, 18, 19, 20)
GROUP BY product_id, HIERARCHY1_ID , HIERARCHY2_ID , HIERARCHY3_ID , location_id, year
) sales_time
GROUP BY product_id, year,HIERARCHY1_ID, HIERARCHY2_ID
This Query rewrites only with my_dim_mvw_calendar. (as saw in Query Plan and EXPLAIN_MVIEW). But we would like it to use my_dim_mvw_location as that has aggregations for both dimensions.blackhole001 wrote:
Hi all,
I'm trying to make my programmer's life easier by creating a database view for them to query the data, so they don't have to worry about joining tables. This sounds like a pretty horrible idea. I say this because you will eventually end up with programmers that know nothing about your data model and how to properly interact with it.
Additionally, what you will get is a developer that takes one of your views and see's that of the 20 columns in it, it has 4 that he needs. If all those 4 columns comes from a simple 2 table join, but the view has 8 tables, you're wasting a tonne of resources by using the view (and heaven forbid they have to join that view to another view to get 4 of the 20 columns from that other view as well).
Ideally you'd write stored routines that satisfy exactly what is required (if you are the database resource and these other programmers are java, .net, etc... based) and the front end developers would call those routines customized for an exact purpose.
Creating views is not bad, but it's by no means a proper solution to having developers not learn or understand SQL and/or the data model. -
Trying to UNION two views with nested tables
I am using Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod, and my objective is to generate some XML. What I have been doing in the past, is to create a view, and then pass that view to the DBMS_XMLQuery routine. This gives me a CLOB that I pass along to the application. A typical object would be something like:
create or replace type XML_UGroup_Member_Type as object (
username varchar2(128),
group_key varchar2(128));
create or replace type XML_UGroup_Member_List
as table of XML_UGroup_Member_Type;
show errors
Create or replace type XML_UGroup_Type as object (
Group_Space varchar2(32),
group_key varchar2(128),
group_name varchar2(255),
members XML_UGroup_Member_List);
/This particular application will be doing stuff with group information. Pretty simply types - a group with a name and a few other keys, and a list of members. A sample view would be like:
create or replace view xml_department_ugroup_view of xml_ugroup_type
with object identifier ( group_key ) as
Select 'Department',
'Department:' || orgn_code,
'Department_' || orgn_name
cast ( multiset (
select Username, person_id,
'Department:' || effective_orgn
from directory_master dm, logins l
where effective_orgn = dd.orgn_code
and dm.person_id = l.owner)
as XML_UGroup_Member_List )
as members
from directory_departments dd
where dept_include = 'Y';
can select from this view, and I can pass it to the DBMS_XMLQUERY package and get a nice XML document. What I want to is essentially put several of these views together, like
Select * from XML_Department_Ugroup_View
Union
Select * from XML_Portfolio_Ugroup_View;But UNION does not work with nested tables:
ERROR at line 1: ORA-00932: inconsistent datatypes: expected - got SIMON.XML_UGROUP_MEMBER_LIST
What I was hoping to do, was to develop a set of sub views for each of the group "spaces", and then generate a view/object that includes all of the sub views, and be able to operate with that single object.
Thoughts on how to make this work, or on alternate approaches? I have considered calling XMLQuery on each of the sub views and concatenating the XML documents and returning that to the application, but I was hoping to find a more "unified" approach.I modified my approach a bit - I changed the base views to return an XMLType object, like:
create or replace view xml_portfolio_ugroup_xml
as
Select XMLElement("group",
xml_ugroup_type(
'Portfolio',
'Portfolio:' || coas_code || ':' || orgn_Code,
cast ( multiset (
select Username,
from directory_master dm, logins l
where ( effective_orgn, effective_coas ) in
where effective_orgn = dd.orgn_code
and dm.person_id = l.owner
as XML_UGroup_Member_List ))) as grp
from directory_departments dd
where dept_include = 'Y';and then I combined them with something like the following (I expect to adjust this as I learn more about the XML DB support)
create or replace view xml_ugroup_xml as
select xmlconcat(
(select xmlagg(grp) from xml_department_ugroup_xml),
(select xmlagg(grp) from xml_portfolio_ugroup_xml)
) as GROUPS
from dualand as I define more group branches, I can add them into the XMLConCat stanzas. I am still open to suggestions as to ways of doing this better or cleaner, but this at least gets the project moving forward again. -
HANA Studio rev.74 - performance in calc view with union of many sources
Hi,
Windows 7 32 bit, 4GB system memory, Intel Core Duo 2.26Ghz, HANA studio rev 74.
Maintaining a graphical calculation view where first node is union of 30 calculation views each with 150 columns. Maintenance of the view is terribly slow almost to the point of unusable as I add sources to the union, leading to a consideration of remodelling the requirement with a scripted view (or breaking down into smaller sets of graphical calculation views) to work around the sluggish response.
As well as building the view for development purposes I'm considering longer term maintenance options where I cannot guarantee system specs of the supporting developer.
Does anyone else have experience of such sluggish Studio performance with a graphical calculation view using many large view sources?
Is there any theoretical limit to the number of sources in a union?
Cheers,
JP.Hi Jon-Paul,
sorry for going off topic, but...
if there's still an issue with the appliance (on CAL?), doesn't it flow over to the client? i have the client SP80 installed, but until i get the confirmation that the server i'm connecting to is 'production' ready i can't really take the full advantage of the upgraded client as i don't see any significant point of using client 80 with server 74, but it sounds like you would want to make it work, nevertheless.
to me, yellow is still yellow even though it doesn't really stand for anything.
good luck and let us know your test results,
greg -
HST60: Huge Performance Problem with VAPI Views
We are using a VAPI view (with instead-of-triggers) for a table with +/- 60 columns.
In this instead-of-trigger we call some functions to return constants and variables.
Using DML (for example a Update) on this view takes the Server 80 sec. CPU time.
Direct update on the table takes 0.2 secs. CPU time.
Assistance please cause we are planning to use VAPI views to populate a new database model with old Forms.
As I know in Oracle 7 there was a problem with code in triggers. I believe they were compiled each time they were called. And package onces !! MAybe has this something to do with it.
Thanks in advise,
M. Overdijk
nullMarc,
Thanks for the reply....
We are using 8.1.6 currently.
This is a problem of one my fellow developers. The problem is the update using the rowid. Headstart has a booster to customize a Designer module to not use this rowid.
Problem we have is we have a old Forms 4.5 application. We made a new server model along with cdm ruleframe. The old tables are dropped and the old forms now work with VAPI views......redericting the data the new tables.
Now we have (we think) the same problem wherefor Headstart has this above called booster.
Any solutions for us ??? Cause we don't want to change the old application forms (there are to much !!)
Our solution is to drop the instead of triggers and use some cev business rule to redirect the data...
Disadvantages:
1. some work to do
2. whern the old application is dropped we have to remove the cev rules.
Any other solutions -
We've got some performance problems when using a complex view that queries against a couple nested views.
We need to use views because we have two outer joins against the same table.
Here's a simplified version:
create or replace view_b as
select a1, b1, c1, d1
from table_c, table_d, view_a
where table_c.c1 = view_a.a1(+)
and table_c.c2= table_d.d1
create or replace view_a as
select a1
from table_a, table_b
where table_a.a1 = table_b.b1(+)
A query that may present problems with large amounts of data is:
select a1, b1
from view_b
where a1 = 1234;
Do indexes of nested views get utilized? Any suggestions?
ThanksHow selective is INSTRUMENT_ID? Is that a primary key? Or are there many rows in the INSTRUMENT table with an INSTRUMENT_ID of 1?
Are the statistics on your table and your index up to date? How, precisely, were statistics gathered?
What version of Oracle are you using? If you are using something earlier than 11.1, it's entirely possible that you have a bind variable peeking problem.
Realistically, you would want Oracle to use two different query plans for this statement depending on the value of the bind variable. If you pass in a NULL, you'd want Oracle to do a table scan. If you pass in a value, you'd want Oracle to do an index scan. Prior to 11.1, when this statement is first parsed, Oracle looks at the bind variable you passed in and picks the best plan for that bind variable value. When you subsequently execute this statement with other bind variable values, that first query plan is used. Thus, if the first time this code was executed you passed in a NULL, it would have made sense for Oracle to choose the table scan and all subsequent executions (until the query was aged out of the shared pool) would continue to use that query plan.
Oracle 11.1 introduced the ability to have multiple query plans for the same query depending on the bind variable values that were passed in which may well alleviate the problem you're seeing.
Justin -
I have a Oracle Spatial table with 3.5 million rows plus another auxillary table with 3.5 million rows. A query over these two tables joined returns a full result (250 rows) based on one to one join - here's an example:
Select count(*)
from F, N
where F.id = n.id and (F.GEOM,mdsys.sdo_geometry (2003,8307, null, mdsys.sdo_elem_info_array (1,1003,1), mdsys.sdo_ordinate_array(-120.0,49.5,-119.0,49.5,-119.0,60.35,-120.0,60.35,-120.0,49.5)),
'mask= ANYINTERACT querytype=WINDOW') = 'TRUE') AND N.PNUM = '4';
It takes an average of 35 seconds to get the full result set back. I've gathered statistics, tweaked memory parameters and this is the best I can get. Does anyone have any suggestions?This is an interesting problem. It looks like Oracle is doing the right thing for each of the table accesses - use the index and fetch by rowid.
The only thing you have to play with if you don't go to materialized views or temp tables is how the results of the two table queries are joined.
You don't have a lot of options. Hash join seems to be slow, but you don't know if it is faster or slower compared with nested loops or merge join.
I'd compare what you have done with something like the following to test nested loops:
select /*+ no_merge use_nl (f1,n1) */ count(*)
from
(select id
from f
where sdo_anyinteract ( F.GEOM,
sdo_geometry (2003,8307, null, sdo_elem_info_array (1,1003,1),
sdo_ordinate_array (-120.0,49.5,-119.0,49.5,-119.0,60.35,
-120.0,60.35,-120.0,49.5))) = 'TRUE') f1,
(select id
from n
where n.pnum='4') n1
where f1.id=n1.id ;
and presort with a merge join hint to see how it performs:
select /*+ no_merge use_merge (f1,n1) */ count(*)
from
(select id
from f
where sdo_anyinteract ( F.GEOM,
sdo_geometry (2003,8307, null, sdo_elem_info_array (1,1003,1),
sdo_ordinate_array (-120.0,49.5,-119.0,49.5,-119.0,60.35,
-120.0,60.35,-120.0,49.5))) = 'TRUE'
order by id) f1,
(select id
from n
where n.pnum='4'
order by id) n1
where f1.id=n1.id ;
It might be that you already have the best Oracle can do, but I'd be curious to know how you make out.
Dan Abugov
VP Software Support and Services
Acquis Inc. -
Degraded Performance with Partitioning
We are using Oracle 11.2.0.3 on Solaris. There is a view defined on a few tables. Because of its complexness and the size of tables, the performance of the view is not good. So, I changed two of the tables to partitioned tables, list-partitioned by year. All indexes on these two tables were changed to local partitioned, with year as the leading index keys. Statistics on all tables and indexes were collected. I then created a new view with the two tables replaced with the partitioned ones. I also ran SQL Tuning advisor and created recommended indexes. I hoped the new view would be faster than the old one, but the fact is the opposite.
The old view has order-by clause. If I remove the order-by in the new view, the elapsed time is close to the old one which has order-by. With "select * from new-view order by ...", or even a "select count(*) from new-view", I never got a return in few hours.
SQL Tuning Advisor shows partition-pruning, all operations are on one partition, and the only recommendation now is accepting SQL profile. I don't understand why partitioning has such a bad result. This is really frustrating to me. Not sure if anyone here experienced something similar, or know there is an Oracle bug, or can tell me where I am lost.
Appreciate your advice.
Gary
Edited by: user12131557 on Feb 25, 2013 3:15 PMThis is the old plan. Again, please replace # with seven spaces to read.
| Id | Operation####### | Name### | Rows | Bytes |TempSpc| Cost |
| 0 | SELECT STATEMENT###### |#### |#|#|#| 50259 |
| 1 | SORT ORDER BY###### |#### | 27 | 21951 |#| 50259 |
| 2 | VIEW####### | VW_BCZC_REPORT## | 27 | 21951 |#| 50233 |
| 3 | SORT ORDER BY###### |#### | 27 | 8937 |#| 50233 |
| 4 | NESTED LOOPS OUTER##### |#### | 27 | 8937 |#| 50207 |
|* 5 | HASH JOIN OUTER##### |#### | 27 | 7614 |#| 50167 |
|* 6 |#HASH JOIN###### |#### | 27 | 6291 |#| 46428 |
| 7 |# TABLE ACCESS FULL##### | HSD_SUMMARY_OUTPUT# | 762 | 21336 |#| 4 |
|* 8 |# HASH JOIN###### |#### | 44145 | 8837K|#| 46421 |
| 9 |# TABLE ACCESS FULL##### | HSD_LOOKUP###| 132 | 6732 |#| 3 |
|* 10 |# HASH JOIN###### |#### | 43142 | 6488K|#| 46417 |
| 11 |# TABLE ACCESS FULL#####| HSD_COUNTY###| 3227 | 74221 |#| 4 |
|* 12 |# HASH JOIN###### |#### | 43142 | 5519K|#| 46406 |
| 13 |# VIEW###### |#### | 4 | 56 |#| 208 |
| 14 |# SORT UNIQUE##### |#### | 4 | 406 |#| 208 |
| 15 |# UNION-ALL##### |#### |#|#|#|#|
|* 16 |##FILTER######|#### |#|#|#|#|
| 17 |## SORT GROUP BY#### |#### | 1 | 109 |#| 67 |
| 18 |## NESTED LOOPS#### |#### | 1 | 109 |#| 18 |
| 19 |## NESTED LOOPS#### |#### | 1 | 67 |#| 17 |
|* 20 |## INDEX FULL SCAN#### | HSD_SUMMARY_OUTPUT_INDX3#| 10 | 230 |#| 2 |
| 21 |## TABLE ACCESS BY INDEX ROWID## | CONTRACT_X_COUNTY##| 1 | 44 |#| 2 |
|* 22 |## INDEX RANGE SCAN### | CONTRACT_X_COUNTY_APP_ID_IDX | 1 |#|#| 1 |
|* 23 |## INDEX RANGE SCAN#### | CONTRACT_X_COUNTY_PK# | 1 | 42 |#| 1 |
|* 24 |##FILTER######|#### |#|#|#|#|
| 25 |## SORT GROUP BY#### |#### | 1 | 106 |#| 62 |
| 26 |## NESTED LOOPS#### |#### | 1 | 106 |#| 13 |
| 27 |## NESTED LOOPS#### |#### | 1 | 64 |#| 12 |
|* 28 |## INDEX FULL SCAN#### | HSD_SUMMARY_OUTPUT_INDX3#| 10 | 230 |#| 2 |
|* 29 |## TABLE ACCESS BY INDEX ROWID## | CONTRACT_X_PARTIAL_ZIPCODE | 1 | 41 |#| 1 |
|* 30 |## INDEX RANGE SCAN### | CONTRACT_X_PAR_ZIP_APP_ID_IDX | 1 |#|#| 1 |
|* 31 |## INDEX RANGE SCAN#### | CONTRACT_X_PARTIAL_ZIPCODE_PK | 1 | 42 |#| 1 |
|* 32 |##FILTER######|#### |#|#|#|#|
| 33 |## NESTED LOOPS#####|#### | 1 | 94 |#| 8 |
| 34 |## NESTED LOOPS#### |#### | 1 | 72 |#| 6 |
| 35 |## NESTED LOOPS#### |#### | 1 | 63 |#| 5 |
| 36 |## NESTED LOOPS#### |#### | 1 | 52 |#| 4 |
|* 37 |## TABLE ACCESS BY INDEX ROWID## | CONTRACT_INFORMATION# | 1 | 25 |#| 3 |
|* 38 |## INDEX RANGE SCAN### | IX2_CONTRACT_INFORMATION#| 1 |#|#| 2 |
| 39 |###SORT AGGREGATE### |#### | 1 | 22 |#|#|
| 40 |### FIRST ROW#### |#### | 1 | 22 |#| 1 |
|* 41 |### INDEX RANGE SCAN (MIN/MAX)# | CONTRACT_INFORMATION_PK# | 1 | 22 |#| 1 |
|* 42 |## TABLE ACCESS BY INDEX ROWID## | CONTRACT_X_REGION##| 1 | 27 |#| 1 |
|* 43 |## INDEX RANGE SCAN### | CONTRACT_X_REGION_PK# | 1 |#|#| 1 |
|* 44 |## INDEX RANGE SCAN####| HSD_SUMMARY_OUTPUT_INDX4#| 1 | 11 |#| 1 |
| 45 |## TABLE ACCESS BY INDEX ROWID## | STATES### | 1 | 9 |#| 1 |
|* 46 |## INDEX RANGE SCAN####| STATES_INDX2## | 2 |#|#| 1 |
|* 47 |## TABLE ACCESS BY INDEX ROWID## | COUNTIES### | 2 | 44 |#| 2 |
|* 48 |## INDEX RANGE SCAN#### | COUNTIES_INDX_4## | 54 |#|#| 1 |
| 49 |## SORT AGGREGATE#### |#### | 1 | 25 |#|#|
|* 50 |## TABLE ACCESS BY INDEX ROWID## | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|* 51 |## INDEX RANGE SCAN#### | IX1_CONTRACT_X_REGION# | 1 |#|#| 1 |
|* 52 |##FILTER######|#### |#|#|#|#|
| 53 |## NESTED LOOPS#####|#### | 1 | 97 |#| 18 |
| 54 |## NESTED LOOPS#### |#### | 1 | 75 |#| 16 |
| 55 |## NESTED LOOPS#### |#### | 1 | 66 |#| 15 |
| 56 |## NESTED LOOPS#### |#### | 4 | 152 |#| 11 |
|* 57 |## INDEX RANGE SCAN### | IX1_HSD_SUMMARY_OUTPUT# | 10 | 110 |#| 1 |
|* 58 |## TABLE ACCESS BY INDEX ROWID## | CONTRACT_X_REGION##| 1 | 27 |#| 1 |
|* 59 |## INDEX RANGE SCAN### | CONTRACT_X_REGION_PK# | 1 |#|#| 1 |
|* 60 |## TABLE ACCESS BY INDEX ROWID## | CONTRACT_INFORMATION# | 1 | 28 |#| 1 |
|* 61 |## INDEX RANGE SCAN### | CONTRACT_INFORMATION_PK# | 1 |#|#| 1 |
| 62 |## SORT AGGREGATE####|#### | 1 | 22 |#|#|
| 63 |###FIRST ROW#### |#### | 1 | 22 |#| 1 |
|* 64 |### INDEX RANGE SCAN (MIN/MAX)##| CONTRACT_INFORMATION_PK# | 1 | 22 |#| 1 |
| 65 |## TABLE ACCESS BY INDEX ROWID## | STATES### | 1 | 9 |#| 1 |
|* 66 |## INDEX RANGE SCAN####| STATES_INDX1## | 1 |#|#| 1 |
|* 67 |## TABLE ACCESS BY INDEX ROWID## | COUNTIES### | 2 | 44 |#| 2 |
|* 68 |## INDEX RANGE SCAN#### | COUNTIES_INDX_4## | 54 |#|#| 1 |
| 69 |## SORT AGGREGATE#### |#### | 1 | 25 |#|#|
|* 70 |## TABLE ACCESS BY INDEX ROWID## | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|* 71 |## INDEX RANGE SCAN#### | IX1_CONTRACT_X_REGION# | 1 |#|#| 1 |
| 72 |# VIEW###### |#### | 1078K| 120M|#| 46189 |
| 73 |# SORT GROUP BY##### |#### | 1078K| 120M|#| 46189 |
| 74 |# VIEW###### |#### | 1078K| 120M|#| 35578 |
| 75 |##SORT UNIQUE##### |#### | 1078K| 147M| 324M| 35578 |
| 76 |## UNION-ALL##### |#### |#|#|#|#|
|* 77 |## FILTER##### |#### |#|#|#|#|
|* 78 |## HASH JOIN OUTER#### |#### | 1078K| 147M| 141M| 5496 |
| 79 |## VIEW##### |#### | 1078K| 129M|#| 1082 |
|* 80 |## HASH JOIN#### |#### | 1078K| 46M|#| 1082 |
| 81 |## INDEX FULL SCAN### | HSD_SUMMARY_OUTPUT_INDX3#| 762 | 11430 |#| 2 |
| 82 |## TABLE ACCESS FULL### | HSD_NCB_OUTPUT## | 1078K| 30M|#| 1071 |
| 83 |## VIEW##### |#### | 5 | 85 |#| 2152 |
| 84 |## SORT UNIQUE#### |#### | 5 | 262 |#| 2152 |
| 85 |## UNION-ALL#### |#### |#|#|#|#|
| 86 |###VIEW##### |#### | 4 | 68 |#| 203 |
| 87 |### SORT UNIQUE#### |#### | 4 | 398 |#| 203 |
| 88 |### UNION-ALL#### |#### |#|#|#|#|
|* 89 |### FILTER#### |#### |#|#|#|#|
| 90 |### SORT GROUP BY### |#### | 1 | 107 |#| 62 |
| 91 |### NESTED LOOPS### |#### | 1 | 107 |#| 13 |
| 92 |### NESTED LOOPS### |#### | 1 | 65 |#| 12 |
|* 93 |####INDEX FULL SCAN## | HSD_SUMMARY_OUTPUT_INDX3#| 10 | 230 |#| 2 |
|* 94 |####INDEX RANGE SCAN## | CONTRACT_X_COUNTY_APP_ID_IDX | 1 | 42 |#| 1 |
|* 95 |### INDEX RANGE SCAN## | CONTRACT_X_COUNTY_PK# | 1 | 42 |#| 1 |
|* 96 |### FILTER#### |#### |#|#|#|#|
| 97 |### SORT GROUP BY### |#### | 1 | 104 |#| 62 |
| 98 |### NESTED LOOPS### |#### | 1 | 104 |#| 13 |
| 99 |### NESTED LOOPS### |#### | 1 | 62 |#| 12 |
|*100 |####INDEX FULL SCAN## | HSD_SUMMARY_OUTPUT_INDX3#| 10 | 230 |#| 2 |
|*101 |####TABLE ACCESS BY INDEX ROWID#| CONTRACT_X_PARTIAL_ZIPCODE | 1 | 39 |#| 1 |
|*102 |#### INDEX RANGE SCAN## | CONTRACT_X_PAR_ZIP_APP_ID_IDX | 1 |#|#| 1 |
|*103 |### INDEX RANGE SCAN## | CONTRACT_X_PARTIAL_ZIPCODE_PK | 1 | 42 |#| 1 |
|*104 |### FILTER#### |#### |#|#|#|#|
|*105 |### FILTER#### |#### |#|#|#|#|
| 106 |### NESTED LOOPS### |#### | 1 | 92 |#| 8 |
| 107 |### NESTED LOOPS### |#### | 1 | 70 |#| 6 |
| 108 |####NESTED LOOPS### |#### | 1 | 61 |#| 5 |
| 109 |#### NESTED LOOPS###|#### | 1 | 50 |#| 4 |
|*110 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_INFORMATION# | 1 | 25 |#| 3 |
|*111 |#### INDEX RANGE SCAN## | IX2_CONTRACT_INFORMATION#| 1 |#|#| 2 |
| 112 |#### SORT AGGREGATE## |#### | 1 | 22 |#|#|
| 113 |#### FIRST ROW## |#### | 1 | 22 |#| 1 |
|*114 |#### INDEX RANGE SCAN (MIN/MAX) | CONTRACT_INFORMATION_PK# | 1 | 22 |#| 1 |
|*115 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|*116 |#### INDEX RANGE SCAN## | CONTRACT_X_REGION_PK# | 1 |#|#| 1 |
|*117 |#### INDEX RANGE SCAN## | HSD_SUMMARY_OUTPUT_INDX4#| 1 | 11 |#| 1 |
| 118 |####TABLE ACCESS BY INDEX ROWID#| STATES### | 1 | 9 |#| 1 |
|*119 |#### INDEX RANGE SCAN## | STATES_INDX2## | 2 |#|#| 1 |
|*120 |### TABLE ACCESS BY INDEX ROWID# | COUNTIES### | 2 | 44 |#| 2 |
|*121 |####INDEX RANGE SCAN## | COUNTIES_INDX_4## | 54 |#|#| 1 |
| 122 |### SORT AGGREGATE### |#### | 1 | 25 |#|#|
|*123 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|*124 |### INDEX RANGE SCAN## | IX1_CONTRACT_X_REGION# | 1 |#|#| 1 |
|*125 |### FILTER#### |#### |#|#|#|#|
|*126 |### FILTER#### |#### |#|#|#|#|
| 127 |### NESTED LOOPS### |#### | 1 | 95 |#| 18 |
| 128 |### NESTED LOOPS### |#### | 1 | 73 |#| 16 |
| 129 |####NESTED LOOPS### |#### | 1 | 64 |#| 15 |
| 130 |#### NESTED LOOPS###|#### | 4 | 144 |#| 11 |
|*131 |#### INDEX RANGE SCAN## | IX1_HSD_SUMMARY_OUTPUT# | 10 | 110 |#| 1 |
|*132 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|*133 |#### INDEX RANGE SCAN## | CONTRACT_X_REGION_PK# | 1 |#|#| 1 |
|*134 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_INFORMATION# | 1 | 28 |#| 1 |
|*135 |#### INDEX RANGE SCAN## | CONTRACT_INFORMATION_PK# | 1 |#|#| 1 |
| 136 |#### SORT AGGREGATE## |#### | 1 | 22 |#|#|
| 137 |#### FIRST ROW###|#### | 1 | 22 |#| 1 |
|*138 |#### INDEX RANGE SCAN (MIN/MAX) | CONTRACT_INFORMATION_PK# | 1 | 22 |#| 1 |
| 139 |####TABLE ACCESS BY INDEX ROWID#| STATES### | 1 | 9 |#| 1 |
|*140 |#### INDEX RANGE SCAN## | STATES_INDX1## | 1 |#|#| 1 |
|*141 |### TABLE ACCESS BY INDEX ROWID# | COUNTIES### | 2 | 44 |#| 2 |
|*142 |####INDEX RANGE SCAN## | COUNTIES_INDX_4## | 54 |#|#| 1 |
| 143 |### SORT AGGREGATE### |#### | 1 | 25 |#|#|
|*144 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|*145 |### INDEX RANGE SCAN## | IX1_CONTRACT_X_REGION# | 1 |#|#| 1 |
| 146 |###INTERSECTION#### |#### |#|#|#|#|
| 147 |### SORT UNIQUE#### |#### | 1 | 97 |#|#|
|*148 |### FILTER#### |#### |#|#|#|#|
| 149 |### SORT GROUP BY### |#### | 1 | 97 |#| 1822 |
|*150 |### HASH JOIN####|#### | 7 | 679 |#| 1773 |
|*151 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_COUNTY##| 2357 | 98994 |#| 885 |
|*152 |### INDEX RANGE SCAN## | CONTRACT_X_COUNTY_INDX_6#| 148K|#|#| 157 |
| 153 |### NESTED LOOPS OUTER## |#### | 2338 | 125K|#| 886 |
|*154 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_COUNTY##| 2338 | 86506 |#| 885 |
|*155 |####INDEX RANGE SCAN## | CONTRACT_X_COUNTY_INDX_6#| 148K|#|#| 157 |
|*156 |### INDEX UNIQUE SCAN## | CONTRACT_AREA_SUPP_INFO_PK | 1 | 18 |#| 1 |
| 157 |### SORT UNIQUE#### |#### | 1 | 97 |#|#|
|*158 |### FILTER#### |#### |#|#|#|#|
| 159 |### SORT GROUP BY### |#### | 1 | 97 |#| 103 |
| 160 |### NESTED LOOPS### |#### | 1 | 97 |#| 54 |
| 161 |### NESTED LOOPS OUTER## |#### | 20 | 1100 |#| 34 |
|*162 |### INDEX RANGE SCAN## | IX1_CONTRACT_X_COUNTY# | 20 | 740 |#| 33 |
|*163 |### INDEX UNIQUE SCAN## | CONTRACT_AREA_SUPP_INFO_PK | 1 | 18 |#| 1 |
|*164 |### INDEX RANGE SCAN## | CONTRACT_X_COUNTY_PK# | 1 | 42 |#| 1 |
| 165 |## TABLE ACCESS BY INDEX ROWID## | HSD_NCB_OUTPUT## | 1 | 30 |#| 2 |
| 166 |## NESTED LOOPS#### |#### | 1 | 78 |#| 6158 |
|*167 |## HASH JOIN#####|#### | 1 | 48 |#| 6157 |
| 168 |## NESTED LOOPS#### |#### | 1 | 31 |#| 4004 |
| 169 |## VIEW##### |#### | 2 | 32 |#| 4004 |
| 170 |###SORT UNIQUE#### |#### | 2 | 152 |#| 4004 |
| 171 |### UNION-ALL#### |#### |#|#|#|#|
|*172 |### HASH JOIN#### |#### | 1 | 88 |#| 2002 |
|*173 |### FILTER#### |#### |#|#|#|#|
|*174 |### HASH JOIN OUTER### |#### | 1 | 64 |#| 1938 |
|*175 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_PARTIAL_ZIPCODE | 1 | 40 |#| 1 |
| 176 |### NESTED LOOPS### |#### | 1 | 56 |#| 12 |
|*177 |####INDEX FULL SCAN## | HSD_SUMMARY_OUTPUT_INDX3#| 10 | 160 |#| 2 |
|*178 |####INDEX RANGE SCAN## | CONTRACT_X_PAR_ZIP_APP_ID_IDX | 1 |#|#| 1 |
| 179 |### VIEW#### | VW_HSD_PARTIAL_EXPANSION_ONLY | 1 | 8 |#| 1925 |
| 180 |### INTERSECTION### |#### |#|#|#|#|
| 181 |####SORT UNIQUE### |#### | 1 | 97 |#|#|
|*182 |#### FILTER### |#### |#|#|#|#|
| 183 |#### SORT GROUP BY## |#### | 1 | 97 |#| 1822 |
|*184 |#### HASH JOIN### |#### | 7 | 679 |#| 1773 |
|*185 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_X_COUNTY##| 2357 | 98994 |#| 885 |
|*186 |#### INDEX RANGE SCAN# | CONTRACT_X_COUNTY_INDX_6#| 148K|#|#| 157 |
| 187 |#### NESTED LOOPS OUTER# |#### | 2338 | 125K|#| 886 |
|*188 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_X_COUNTY##| 2338 | 86506 |#| 885 |
|*189 |#### INDEX RANGE SCAN# | CONTRACT_X_COUNTY_INDX_6#| 148K|#|#| 157 |
|*190 |#### INDEX UNIQUE SCAN# | CONTRACT_AREA_SUPP_INFO_PK | 1 | 18 |#| 1 |
| 191 |####SORT UNIQUE### |#### | 1 | 97 |#|#|
|*192 |#### FILTER### |#### |#|#|#|#|
| 193 |#### SORT GROUP BY## |#### | 1 | 97 |#| 103 |
| 194 |#### NESTED LOOPS## |#### | 1 | 97 |#| 54 |
| 195 |#### NESTED LOOPS OUTER# |#### | 20 | 1100 |#| 34 |
|*196 |#### INDEX RANGE SCAN# | IX1_CONTRACT_X_COUNTY# | 20 | 740 |#| 33 |
|*197 |#### INDEX UNIQUE SCAN# | CONTRACT_AREA_SUPP_INFO_PK | 1 | 18 |#| 1 |
|*198 |#### INDEX RANGE SCAN##| CONTRACT_X_COUNTY_PK# | 1 | 42 |#| 1 |
| 199 |### VIEW#### | VW_SQ_7### | 30 | 720 |#| 64 |
|*200 |### FILTER#### |#### |#|#|#|#|
| 201 |### SORT GROUP BY### |#### | 30 | 1530 |#| 64 |
|*202 |### INDEX FAST FULL SCAN## | CONTRACT_X_PARTIAL_ZIPCODE_PK | 588 | 29988 |#| 37 |
|*203 |### FILTER#### |#### |#|#|#|#|
| 204 |### NESTED LOOPS OUTER## |#### | 1 | 64 |#| 1952 |
| 205 |### VIEW#### |#### | 1 | 38 |#| 1951 |
| 206 |### SORT UNIQUE### |#### | 1 | 50 |#| 1951 |
| 207 |### NESTED LOOPS### |#### | 1 | 50 |#| 1927 |
| 208 |####NESTED LOOPS### |#### | 1 | 34 |#| 1926 |
| 209 |#### VIEW#### | VW_HSD_PARTIAL_EXPANSION_ONLY | 1 | 14 |#| 1925 |
| 210 |#### INTERSECTION## |#### |#|#|#|#|
| 211 |#### SORT UNIQUE## |#### | 1 | 97 |#|#|
|*212 |#### FILTER### |#### |#|#|#|#|
| 213 |#### SORT GROUP BY## |#### | 1 | 97 |#| 1822 |
|*214 |#### HASH JOIN## |#### | 7 | 679 |#| 1773 |
|*215 | D#### TABLE ACCESS BY INDEX ROWI | CONTRACT_X_COUNTY##| 2357 | 98994 |#| 885 |
|*216 |##### INDEX RANGE SCAN# | CONTRACT_X_COUNTY_INDX_6#| 148K|#|#| 157 |
| 217 |#####NESTED LOOPS OUTER# |#### | 2338 | 125K|#| 886 |
|*218 | ID#### TABLE ACCESS BY INDEX ROW | CONTRACT_X_COUNTY##| 2338 | 86506 |#| 885 |
|*219 |##### INDEX RANGE SCAN# | CONTRACT_X_COUNTY_INDX_6#| 148K|#|#| 157 |
|*220 |##### INDEX UNIQUE SCAN# | CONTRACT_AREA_SUPP_INFO_PK | 1 | 18 |#| 1 |
| 221 |#### SORT UNIQUE## |#### | 1 | 97 |#|#|
|*222 |#### FILTER### |#### |#|#|#|#|
| 223 |#### SORT GROUP BY## |#### | 1 | 97 |#| 103 |
| 224 |#### NESTED LOOPS## |#### | 1 | 97 |#| 54 |
| 225 |#####NESTED LOOPS OUTER# |#### | 20 | 1100 |#| 34 |
|*226 |##### INDEX RANGE SCAN# | IX1_CONTRACT_X_COUNTY# | 20 | 740 |#| 33 |
|*227 |##### INDEX UNIQUE SCAN# | CONTRACT_AREA_SUPP_INFO_PK | 1 | 18 |#| 1 |
|*228 |#####INDEX RANGE SCAN# | CONTRACT_X_COUNTY_PK# | 1 | 42 |#| 1 |
| 229 |#### TABLE ACCESS BY INDEX ROWID | HSD_SUMMARY_OUTPUT# | 1 | 20 |#| 1 |
|*230 |#### INDEX RANGE SCAN## | HSD_SUMMARY_OUTPUT_INDX4#| 1 |#|#| 1 |
|*231 |####INDEX RANGE SCAN## | PK_HSD_NCB_OUTPUT1# | 6 | 96 |#| 1 |
|*232 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_PARTIAL_ZIPCODE | 1 | 26 |#| 1 |
|*233 |### INDEX RANGE SCAN## | IX5_CONTRACT_X_PARTIAL_ZIPCODE | 1 |#|#| 1 |
|*234 |## INDEX RANGE SCAN### | IX1_HSD_SUMMARY_OUTPUT# | 1 | 15 |#| 1 |
| 235 |## VIEW##### |#### | 5 | 85 |#| 2152 |
| 236 |## SORT UNIQUE#### |#### | 5 | 262 |#| 2152 |
| 237 |###UNION-ALL#### |#### |#|#|#|#|
| 238 |### VIEW##### |#### | 4 | 68 |#| 203 |
| 239 |### SORT UNIQUE####|#### | 4 | 398 |#| 203 |
| 240 |### UNION-ALL#### |#### |#|#|#|#|
|*241 |### FILTER#### |#### |#|#|#|#|
| 242 |### SORT GROUP BY### |#### | 1 | 107 |#| 62 |
| 243 |### NESTED LOOPS### |#### | 1 | 107 |#| 13 |
| 244 |####NESTED LOOPS### |#### | 1 | 65 |#| 12 |
|*245 |#### INDEX FULL SCAN## | HSD_SUMMARY_OUTPUT_INDX3#| 10 | 230 |#| 2 |
|*246 |#### INDEX RANGE SCAN## | CONTRACT_X_COUNTY_APP_ID_IDX | 1 | 42 |#| 1 |
|*247 |####INDEX RANGE SCAN## | CONTRACT_X_COUNTY_PK# | 1 | 42 |#| 1 |
|*248 |### FILTER#### |#### |#|#|#|#|
| 249 |### SORT GROUP BY### |#### | 1 | 104 |#| 62 |
| 250 |### NESTED LOOPS### |#### | 1 | 104 |#| 13 |
| 251 |####NESTED LOOPS### |#### | 1 | 62 |#| 12 |
|*252 |#### INDEX FULL SCAN## | HSD_SUMMARY_OUTPUT_INDX3#| 10 | 230 |#| 2 |
|*253 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_X_PARTIAL_ZIPCODE | 1 | 39 |#| 1 |
|*254 |#### INDEX RANGE SCAN## | CONTRACT_X_PAR_ZIP_APP_ID_IDX | 1 |#|#| 1 |
|*255 |####INDEX RANGE SCAN## | CONTRACT_X_PARTIAL_ZIPCODE_PK | 1 | 42 |#| 1 |
|*256 |### FILTER#### |#### |#|#|#|#|
|*257 |### FILTER#### |#### |#|#|#|#|
| 258 |### NESTED LOOPS### |#### | 1 | 92 |#| 8 |
| 259 |####NESTED LOOPS### |#### | 1 | 70 |#| 6 |
| 260 |#### NESTED LOOPS###|#### | 1 | 61 |#| 5 |
| 261 |#### NESTED LOOPS## |#### | 1 | 50 |#| 4 |
|*262 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_INFORMATION# | 1 | 25 |#| 3 |
|*263 |#### INDEX RANGE SCAN##| IX2_CONTRACT_INFORMATION#| 1 |#|#| 2 |
| 264 |#### SORT AGGREGATE## |#### | 1 | 22 |#|#|
| 265 |#### FIRST ROW## |#### | 1 | 22 |#| 1 |
|*266 |#####INDEX RANGE SCAN (MIN/MAX) | CONTRACT_INFORMATION_PK# | 1 | 22 |#| 1 |
|*267 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|*268 |#### INDEX RANGE SCAN##| CONTRACT_X_REGION_PK# | 1 |#|#| 1 |
|*269 |#### INDEX RANGE SCAN## | HSD_SUMMARY_OUTPUT_INDX4#| 1 | 11 |#| 1 |
| 270 |#### TABLE ACCESS BY INDEX ROWID | STATES### | 1 | 9 |#| 1 |
|*271 |#### INDEX RANGE SCAN## | STATES_INDX2## | 2 |#|#| 1 |
|*272 |####TABLE ACCESS BY INDEX ROWID#| COUNTIES### | 2 | 44 |#| 2 |
|*273 |#### INDEX RANGE SCAN## | COUNTIES_INDX_4## | 54 |#|#| 1 |
| 274 |### SORT AGGREGATE### |#### | 1 | 25 |#|#|
|*275 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|*276 |####INDEX RANGE SCAN## | IX1_CONTRACT_X_REGION# | 1 |#|#| 1 |
|*277 |### FILTER#### |#### |#|#|#|#|
|*278 |### FILTER#### |#### |#|#|#|#|
| 279 |### NESTED LOOPS### |#### | 1 | 95 |#| 18 |
| 280 |####NESTED LOOPS### |#### | 1 | 73 |#| 16 |
| 281 |#### NESTED LOOPS###|#### | 1 | 64 |#| 15 |
| 282 |#### NESTED LOOPS## |#### | 4 | 144 |#| 11 |
|*283 |#### INDEX RANGE SCAN## | IX1_HSD_SUMMARY_OUTPUT# | 10 | 110 |#| 1 |
|*284 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|*285 |#### INDEX RANGE SCAN##| CONTRACT_X_REGION_PK# | 1 |#|#| 1 |
|*286 |#### TABLE ACCESS BY INDEX ROWID | CONTRACT_INFORMATION# | 1 | 28 |#| 1 |
|*287 |#### INDEX RANGE SCAN## | CONTRACT_INFORMATION_PK# | 1 |#|#| 1 |
| 288 |#### SORT AGGREGATE## |#### | 1 | 22 |#|#|
| 289 |#### FIRST ROW## |#### | 1 | 22 |#| 1 |
|*290 |#### INDEX RANGE SCAN (MIN/MAX) | CONTRACT_INFORMATION_PK# | 1 | 22 |#| 1 |
| 291 |#### TABLE ACCESS BY INDEX ROWID | STATES### | 1 | 9 |#| 1 |
|*292 |#### INDEX RANGE SCAN## | STATES_INDX1## | 1 |#|#| 1 |
|*293 |####TABLE ACCESS BY INDEX ROWID#| COUNTIES### | 2 | 44 |#| 2 |
|*294 |#### INDEX RANGE SCAN## | COUNTIES_INDX_4## | 54 |#|#| 1 |
| 295 |### SORT AGGREGATE### |#### | 1 | 25 |#|#|
|*296 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_REGION##| 1 | 25 |#| 1 |
|*297 |####INDEX RANGE SCAN## | IX1_CONTRACT_X_REGION# | 1 |#|#| 1 |
| 298 |### INTERSECTION####|#### |#|#|#|#|
| 299 |### SORT UNIQUE####|#### | 1 | 97 |#|#|
|*300 |### FILTER#### |#### |#|#|#|#|
| 301 |### SORT GROUP BY### |#### | 1 | 97 |#| 1822 |
|*302 |### HASH JOIN### |#### | 7 | 679 |#| 1773 |
|*303 |### TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_COUNTY##| 2357 | 98994 |#| 885 |
|*304 |####INDEX RANGE SCAN## | CONTRACT_X_COUNTY_INDX_6#| 148K|#|#| 157 |
| 305 |### NESTED LOOPS OUTER## |#### | 2338 | 125K|#| 886 |
|*306 |####TABLE ACCESS BY INDEX ROWID#| CONTRACT_X_COUNTY##| 2338 | 86506 |#| 885 |
|*307 |#### INDEX RANGE SCAN## | CONTRACT_X_COUNTY_INDX_6#| 148K|#|#| 157 |
|*308 |####INDEX UNIQUE SCAN## | CONTRACT_AREA_SUPP_INFO_PK | 1 | 18 |#| 1 |
| 309 |### SORT UNIQUE####|#### | 1 | 97 |#|#|
|*310 |### FILTER#### |#### |#|#|#|#|
| 311 |### SORT GROUP BY### |#### | 1 | 97 |#| 103 |
| 312 |### NESTED LOOPS### |#### | 1 | 97 |#| 54 |
| 313 |### NESTED LOOPS OUTER## |#### | 20 | 1100 |#| 34 |
|*314 |####INDEX RANGE SCAN## | IX1_CONTRACT_X_COUNTY# | 20 | 740 |#| 33 |
|*315 |####INDEX UNIQUE SCAN## | CONTRACT_AREA_SUPP_INFO_PK | 1 | 18 |#| 1 |
|*316 |### INDEX RANGE SCAN## | CONTRACT_X_COUNTY_PK# | 1 | 42 |#| 1 |
|*317 |## INDEX RANGE SCAN####| PK_HSD_NCB_OUTPUT1# | 1 |#|#| 1 |
| 318 |#VIEW####### |#### | 1155 | 56595 |#| 3738 |
|*319 |# HASH JOIN###### |#### | 1155 | 56595 | 10M| 3738 |
|*320 |# TABLE ACCESS FULL##### | HSD_NCB_OUTPUT## | 304K| 7443K|#| 1071 |
|*321 |# TABLE ACCESS FULL##### | HSD_CALC_OUTPUT## | 340K| 7986K|#| 2308 |
| 322 | VIEW PUSHED PREDICATE#####|#### | 1 | 49 |#| 2 |
| 323 |#NESTED LOOPS###### |#### | 1 | 49 |#| 3 |
| 324 |# TABLE ACCESS BY INDEX ROWID### | HSD_NCB_OUTPUT## | 1 | 25 |#| 2 |
|*325 |# INDEX UNIQUE SCAN##### | PK_HSD_NCB_OUTPUT1# | 1 |#|#| 1 |
| 326 |# TABLE ACCESS BY INDEX ROWID### | HSD_CALC_OUTPUT## | 1 | 24 |#| 1 |
|*327 |# INDEX UNIQUE SCAN##### | PK_HSD_ACC_CALC_OUTPUT1# | 1 |#|#| 1 |
--------------------------------------------------------------------------------------------------------------------------------------- -
Please validate my logic performance point of view:
Please validate my logic performance point of view:
logic I wrote :
LOOP AT i_mara INTO wa_mara.
*-----For material description, go to makt table.
SELECT SINGLE maktx
FROM makt
INTO l_maktx
WHERE matnr = lwa_mara-matnr
AND SPRAS = 'E'.
IF sy-subrc = 0.
wa_mara-MAKTX = l_maktx.
ENDIF. " IF sy-subrc = 0.
*-----For Recurring Inspection, go to marc table.
SELECT prfrq
FROM marc
INTO l_prfrq
UP TO 1 ROWS
WHERE matnr = lwa_mara-matnr.
ENDSELECT.
IF sy-subrc = 0.
wa_mara-prfrq = l_prfrq.
ENDIF. " IF sy-subrc = 0.
MODIFY TABLE i_mara FROM wa_mara
TRANSPORTING maktx.
CLEAR : wa_mara.
ENDLOOP. " LOOP AT i_mara INTO wa_mara.
Or is it better below : ?
To SELECT all the maktx values from makt and all prfrq values from marc
in two internal tables and
Loop at i_mara.
LOOP at all maktx itab
and pass corresponding maktx values into i_mara table
and pass corresponding prfrq values into i_mara table
ENDLOOP.
OR
is there any better performance logic you suggest ?
THANKS IN ADVANCE.ok this is very funny so if someone gets a good way to code he should wait till he gets 1198 points till he write a performance wiki
so that means ppl who has high SDN points only can write wiki
for your information wiki definition is
[http://en.wikipedia.org/wiki/Wiki |http://en.wikipedia.org/wiki/Wiki]
its all about contribution and sharing.
did you try that code on a production or a Quality server. If you did you wont say that coz the results i have shown in that blog is what i my self tested on a Quality system of our client.
and for your information i did my internship at a SAP AFS consultancy firm and i created the account at that time. I have joined that company and now working as a developer over there.
if you have worked on a client system development on SD and MM you will know that most of the time
we use header and item tables like
likp,lips
vbak,vbap
vbrk,vbrp
most of the time we come across nested loops with smiler kind of condition.
in this Q he has MATNR as reference.
if you see it properly you can see both tables are sorted.
and the select statement is for all entries.
for your information there can be a delivery document item with out a header if you are aware of DB concepts in that case there will be a foreign key error.
ok lets think about a situation like that even in that case if there ant any header data then simply the client wont request for that record.( you would know if you have worked with clients )
last but not least i dont care about my points rate at SDN i just wanted to share what i know coz anyway i have a very good job here. dont try to put down ppl just because they are new.
Thomas Zloch : i never told its my code i saw it some where then i checked and i bogged it so that i can get it when i want and i saw it in se30 ( its not se38 ) but i know most of ABAP developers dont check it much so i just wanted to help.
Rui Pedro Dantas : ya your correct we dont need to use it most of the time since sorted table is easy but there are programs which works with bulky data load we can use it in places like that. Thanks for talking the truth
Nafran
sorry if i said anything to hurt anyone. -
Massive problems with nested multi-cam sequences
Hey all,
I'm absolutely pulling my hair out over some issues I'm having and hope somebody out there might have an answer. I'm creating a short interview project, including interviews of two people individually, with two separate cameras and external sound capture. My goal is to cut between their separate answers to each question. For each interview I created a multi-cam sequence within its own timeline. Then, in my master sequence, I used the source monitor to pull out the specific clips from each interview sequence which I wanted to include, and assembled them into the master timeline.
I'm having two difficulties. First, for whatever reason, I'm experiencing audio glitching when the cuts between sequence clips occur. The glitch is like an audio "scramble," lasts about a half second, plenty of time to be distracting and detract from the whole of the project. There are no such audio glitches present when viewing the interview sequences specifically. I had applied effects to the audio tracks both within the interview sequences and the master sequence. I've since disabled every effect but the problem persists, and it is still present upon rendering the master timeline. I have absolutely no idea what to do about this.
The second issue is more general. I've got my media cache on an internal SSD, and I'm pulling my media from an internal HDD, with Premiere Installed on a different SSD with my operating system. The two interview sequences play back wonderfully, no delays whatsoever. The master timeline, however, with all the clips extracted from the interview sequences, plays slow as molasses. It takes 10-15 seconds for the play head to even start moving once I click 'play', which has made this entire process excruciatingly difficult. Is this a known issue? Why would my performance be so completely degraded working with nested sequences? Isn't everything referencing the exact same files?
Ugh, long night working on this. Thank you for any help.Well, I've come up with a terrible, but comical solution for the second issue which doesn't involve reworking anything. It turns out that, upon launching premiere, I can play the master sequence with nested multi-cam sequences a grand total of ONCE with minimal delay. If I stop the play through, then it will take 3-4 minutes to get the sequence playing again. Of course, the Premiere decides to hang when I try to close it after playing this master timeline, so I'm finding that I can inch my way through this project by (1) launching premiere, (2) playing the master sequence, (3) make the edits I need, (4) forcibly crash Premiere, and (5) relaunch Premiere and repeat. It's a terrible way to work, but the project is so close to completion that I'm willing to suffer through it.
As to issue 1, I've taken each offending clip, extending the audio track one or two frames in the beginning of each clip, and then use those frames to ramp the volume up from silent to 0db. This seems to avoid the brief moment of distortion at the beginning. Notably I did try your suggestion by going back to the original, source audio, but I was still getting the same issue. My work-around is the only solution I've been able to come up with. -
Import tables with nested table : ORA-00600
In Oracle 9.2
Create object, type as table, and table with nested table (store as syms_ntab) are successfully.
Also its export.
In process of import on another server (also 9.2, 'fromuser=one touser=two') shows errors:
. . importing table "SYMS_NTAB"
IMP-00058: ORACLE error 600 encountered
ORA-00600: internal error code, arguments: [kokeeafi1], [2], [2], [], [], [], [], []
IMP-00075: Warning: The nested table may contain partial rows or duplicate rows
But for all that table is created and error occur on phase inserting strings.
What is this?
In Oracle 8.0.5 i perform similar operation without error.From Oracle error messages and codes manual:
ORA-00600 internal error code, arguments: [string], [string], [string], [string], [string], [string], [string], [string]
Cause: This is the generic internal error number for Oracle program exceptions. It indicates that a process has encountered a low-level, unexpected condition. Causes of this message include:
* timeouts
* file corruption
* failed data checks in memory
* hardware, memory, or I/O errors
* incorrectly restored files
The first argument is the internal message number. Other arguments are various numbers, names, and character strings. The numbers may change meanings between different versions of Oracle.
Action: Report this error to Oracle Support Services after gathering the following information:
* events that led up to the error
* the operations that were attempted that led to the error
* the conditions of the operating system and databases at the time of the error
* any unusual circumstances that occurred before receiving the ORA-00600 message
* contents of any trace files generated by the error
* the relevant portions of the Alter files
Note: The cause of this message may manifest itself as different errors at different times. Be aware of the history of errors that occurred before this internal error. -
We are working on some extraordiary long SQL stored procedure. Due to the shear size and IF/ELSE nesting it is very tedious to understand the logic .
What I am looking for is an SQL editor with tree view, where we can see IF/ ELSE, LOOP etc block as nodes. For example expand a node and see all blcoks of code within it.
+ IF block 1
expand---
-IF blcok 1
+IF block 1.1
+IF block 1.2
further expand
-IF blcok 1
+IF block 1.1
-IF block 1.2
IF block 1.2.1Do some Google searches for a text editor that supports "folding".
Maybe you are looking for
-
right forum? first time here. none of the options seem perfect. so i guess this applies to 'setup.' i tried to describe what's happening verbosely from the start of a file transfer to completion of writing file to 2nd hard drive. win 7 64bit home -
-
Solaris 8 boot disk...
I have been having problems trying to install Solaris 8 to a PC. I keep getting the error "can't open - no VTOC" when booting with the CD and people have been suggesting I need to use the Solaris fdisk and format tools but I cant find a boot disk any
-
FI Postings...
Hi all, How do i do an FI Posting? The FC i asked for help just throw me two tcodes : F-22 and F-28. One more FB03. As you see, I am not familiar with FI Postings... and i need to do some posting of data on my own to test out my report. Thus i need t
-
Alias hotmail.fr and iphone
Hi everybody ! I would like to use an alias adress with the app Mail and I'm getting in trouble : - I have a parent adress "[email protected]" - and an alias "[email protected]" I've tried to configure with pop or exchange protocols but failed ( with
-
Problems because install adobe flash palyer.
install adobe flash palyer on my macbook pro retina display, and now I hacer.lo failing to install because the program mactube needed. that is good program to download videos from youtube?