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,
    Chris

    I 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.

  • Complex query - improve performance with nested arrays, bulk insert....?

    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!
    Coop

    I 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.

  • TS1381 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, test all other keys with keyboard view (all others work)  - HELP!!

    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
    vats3

    I 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
    null

    Marc,
    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

  • Index usage and nested views

    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?
    Thanks

    How 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

  • Spatial Performance with join

    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 PM

    This 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.

  • SQL editor with tree view

    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.1

    Do some Google searches for a text editor that supports "folding".

Maybe you are looking for

  • Is there a way to turn off using ram as intermediary when transfering files between 2 internal hdds? (write cache is off on all drives)

    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?