Non Unique Indexes on Dimension Table

Hello ,
  I have Material Dimension that has Product MainGroup, Brand , SPC code broken from Product Hierarchy.
  As per Business Requirement , we don't want to use the Product Hierarchy , that should need to split into 3 pieces.
  Since The Cube Dimensions already reached the 13 , we can not increase the dimensions to keep these 3 fields into separate dimensions.
  I heard from Basis guy as <b>we can have index on three fields in same dimension table</b> & read some negative impact on aggregate definition.
  Is it true , which one is true , am not sure.
  Which one impact causes more worst & usefull..?
  Could please some experts throw some light on this.
Cheers
Martin

Martin -
Not sure what you mean by "read some negative impact on aggregate definition".
But as far as adding additional indices on other columns of a dimension table, that certainly is doable. I have never done this as part of an actual intentiional design, but it seems like a valid apporach if you are limited by dimensions.  I'm assuming when you say you already have 13, that the 13 does not include the three standard dimensions for time, request, (drawing a blank, is it currency), so that you really have 16 dimensions, 13 of which are user defined. 
We have added dimension tabl e indices in our shop when we have found large dimension tables that, either from poor initial design, or changes to the data and/or queries, have resulted in full tables scans against large dimension tables.  In some cases, the query costs of the full scan of the dimension table was more than the cost for the access of the fact table itself.
These indices must be added by your DBA as they can not be added thru the Admin Wkbench.  You should also probably keep a record of any of these indices you create because if for some reason you delete the tables and reactivate the cube, you'll probably lose them.
Pizzaman

Similar Messages

  • Unique index vs non-unique index

    Hi Gurus,
    I'm getting lots of "TABLE ACCESS FULL" for lots of columns which have non-unique indexes is some queries. So my question is does optimizer does not pick up non-unique index but only pickes up unique indexes for those columns.
    Thanks
    Amitava.

    amitavachatterjee1975 wrote:
    Hi Gurus,
    I'm getting lots of "TABLE ACCESS FULL" for lots of columns which have non-unique indexes is some queries. So my question is does optimizer does not pick up non-unique index but only pickes up unique indexes for those columns.
    Thanks
    Amitava.WHY MY INDEX IS NOT BEING USED
    http://communities.bmc.com/communities/docs/DOC-10031
    http://searchoracle.techtarget.com/tip/Why-isn-t-my-index-getting-used
    http://www.orafaq.com/tuningguide/not%20using%20index.html

  • Primary Key supported by a non-unique index?

    Encountered a weird situation today. A utility we setup which allows Analysts to restore data into their tables, started failing when it attempted to drop an index. The index was supporting a Primary Key. Makes sense. But our script was supposed to only be attempting to drop/recreate non-unique indexes. Turns out the supporting index on the Primary Key was non-unique, and to the best of my knowledge came about as follows:
    SQL> create table junk (f number(1));
    Table created.
    SQL> create index junk_ix on junk(f);
    Index created.
    SQL> select UNIQUENESS from DBA_INDEXES where index_name = 'JUNK_IX';
    UNIQUENES
    NONUNIQUE
    SQL> alter table forbesc.junk add constraint junk_pk primary key (f) using index junk_ix;
    Table altered.
    SQL> select UNIQUENESS from DBA_INDEXES where index_name = 'JUNK_IX';
    UNIQUENES
    NONUNIQUE
    SQL> insert into junk values (1);
    1 row created.
    SQL> insert into junk values (1);
    insert into junk values (1)
    ERROR at line 1:
    ORA-00001: unique constraint (FORBESC.JUNK_PK) violated
    SQL> select index_name from dba_constraints where constraint_name = 'JUNK_PK';
    INDEX_NAME
    JUNK_IXWhat I can't figure out is how a non-unique index is enforcing uniqueness. I thought that it was the key in that very same process. I thought that perhaps an index with the 'SYS_123456' was getting created, perhaps, but I couldn't find one:
    SQL> select object_name, object_type from dba_objects order by created desc;
    OBJECT_NAME   OBJECT_TYPE
    JUNK_IX     INDEX
    JUNK     TABLE
    ...How is the uniqueness getting enforced in this case? This is in Oracle 11.1.0.7
    Thanks,
    --=Chuck

    It has always been that way. Oracle can, and will, use a non-unique index to enforce a PK constraint, The existing index just needs to have the PK column(s) as the leading column(s) of the index:
    SQL> create table t (id number, id1 number, descr varchar2(10));
    Table created.
    SQL> create index t_ids on t(id, id1);
    Index created.
    SQL> select index_name from user_indexes
      2  where table_name = 'T';
    INDEX_NAME
    T_IDS
    SQL> alter table t add constraint t_pk
      2  primary key (id);
    Table altered.
    SQL> select index_name from user_indexes
      2  where table_name = 'T';
    INDEX_NAME
    T_IDS
    SQL> insert into t values (1, 1, 'One');
    1 row created.
    SQL> insert into t values (1, 2, 'Two');
    insert into t values (1, 2, 'Two')
    ERROR at line 1:
    ORA-00001: unique constraint (OPS$ORACLE.T_PK) violatedJohn

  • What is '#Distinct values' in Index on dimension table

    Gurus!
    I have loaded my BW Quality system (master data and transaction data) with almost equivalent volume as in Production.
    I am comparing the sizes of dimension and fact tables of one of the cubes in Quality and PROD.
    I am taking one of the dimension tables into consideration here.
    Quality:
    /BIC/DCUBENAME2 Volume of records: 4,286,259
    Index /BIC/ECUBENAME~050 on the E fact table /BIC/ECUBENAME for this dimension key KEY_CUBENAME2 shows #Distinct values as  4,286,259
    Prod:
    /BIC/DCUBENAME2 Volume of records: 5,817,463
    Index /BIC/ECUBENAME~050 on the E fact table /BIC/ECUBENAME for this dimension key KEY_CUBENAME2 shows #Distinct values as 937,844
    I would want to know why the distinct value is different from the dimension table count in PROD
    I am getting this information from the SQL execution plan, if I click on the /BIC/ECUBENAME table in the code. This screen gives me all details about the fact table volumes, indexes etc..
    The index and statistics on the cube is up to date.
    Quality:
    E fact table:
    Table   /BIC/ECUBENAME                    
    Last statistics date                  03.11.2008
    Analyze Method               9,767,732 Rows
    Number of rows                         9,767,732
    Number of blocks allocated         136,596
    Number of empty blocks              0
    Average space                            0
    Chain count                                0
    Average row length                      95
    Partitioned                                  YES
    NONUNIQUE  Index   /BIC/ECUBENAME~P:
    Column Name                     #Distinct                                       
    KEY_CUBENAMEP                                  1
    KEY_CUBENAMET                                  7
    KEY_CUBENAMEU                                  1
    KEY_CUBENAME1                            148,647
    KEY_CUBENAME2                          4,286,259
    KEY_CUBENAME3                                  6
    KEY_CUBENAME4                                322
    KEY_CUBENAME5                          1,891,706
    KEY_CUBENAME6                            254,668
    KEY_CUBENAME7                                  5
    KEY_CUBENAME8                              9,430
    KEY_CUBENAME9                                122
    KEY_CUBENAMEA                                 10
    KEY_CUBENAMEB                                  6
    KEY_CUBENAMEC                              1,224
    KEY_CUBENAMED                                328
    Prod:
    Table   /BIC/ECUBENAME
    Last statistics date                  13.11.2008
    Analyze Method                      1,379,086 Rows
    Number of rows                       13,790,860
    Number of blocks allocated       187,880
    Number of empty blocks            0
    Average space                          0
    Chain count                              0
    Average row length                    92
    Partitioned                               YES
    NONUNIQUE Index /BIC/ECUBENAME~P:
    Column Name                     #Distinct                                                      
    KEY_CUBENAMEP                                  1
    KEY_CUBENAMET                                 10
    KEY_CUBENAMEU                                  1
    KEY_CUBENAME1                            123,319
    KEY_CUBENAME2                            937,844
    KEY_CUBENAME3                                  6
    KEY_CUBENAME4                                363
    KEY_CUBENAME5                            691,303
    KEY_CUBENAME6                            226,470
    KEY_CUBENAME7                                  5
    KEY_CUBENAME8                              8,835
    KEY_CUBENAME9                                124
    KEY_CUBENAMEA                                 14
    KEY_CUBENAMEB                                  6
    KEY_CUBENAMEC                                295
    KEY_CUBENAMED                                381

    Arun,
    The cube in QA and PROD are compressed. Index building and statistics are also up to date.
    But I am not sure what other jobs are run by BASIS as far as this cube in production is concerned.
    Is there any other Tcode/ Func Mod etc which can give information about the #distinct values of this Index or dimension table?
    One basic question, As the DIM key is the primary key in the dimension table, there cant be duplicates.
    So, how would the index on Ftable on this dimension table show #distinct values less than the entries in that dimension table?
    Should the entries in dimension table not exactly match with the #Distinct entries shown in
    Index /BIC/ECUBENAME~P on this DIM KEY?

  • Create unique index on flow table

    Hi
    I always get this error 'Create unique index on flow table ERROR" while implementing SCD2. Please help me.I have made an Update Key which is a combination of 4 columns that want a new row to be inserted if there is a change in data.One of the above columns is the EMPLOYEE ID,
    My surrogate key is the table's primary key but I have not defined it as a key in mapping and also I have turned off the Primary Key Constraint Option in Controls Panel as NO.
    Where am I wrong? Also please tell me what to take care off while making Natural Key ?

    There are two solutions:
    1. Only use uppercase in the table name
    2. go in Topology>Physical Architecture and edit the technology, then click on
    the "Language" tab and set "Object Delimiter" to empty.
    Thanks,
    Sutirtha

  • Impact of creating a non-clusterd index on a huge transaction table?

    Hello Everyone,
    We have a transaction table containing 10 million records and everyday a million records will be inserted. We don’t have any clustered index on this table as this is a transaction table (more than 10 columns to uniquely identify a row). We
    do have some SPs which in turn some reports getting generated using this table. In order to improve the performance of an SP, we created a non-clustered index on this table and we found a huge performance gain.
      Here comes my question - will this (creation of non-clustered index) impacts my table data load performance or other reports generation?
    Any suggestions will be appreciated.
    Many Thanks!
    Rajasekhar.

    Hello Rajasekhar, 
    First identify this table and corresponding columns usage. Through SP_depends system procedure you can identify this table dependencies. 
    Then look at complex queries and it's execution plans. You can get an output recommendations of appropriate missing indexes. 
    Now you can try to create appropriate indexes. Always I suggest you to limit the index count if you are inserting/updating large volume records. Also if possible create clustered index. 
    One more option, you can horizontally partitioned the table and move data to multiple filegroups. Based of range of data your query performance also improve a lot. 
    To apply partition for existing table, you should take backup and recreate from scartch. 
    Check this link : http://www.mssqltips.com/sqlservertip/2888/how-to-partition-an-existing-sql-server-table/
    Best Regards, 
    Ashokkumar.
    Ashokkumar

  • Create Unique Index On Flow does not work for table names 23 characters

    I have a "create unique index on flow table" step that is dynamically generated by the IKM.
    The index name that is generated by the IKM is based on the table name except that the created index name is prefixed with "I$_" and ends with "_idx". Obviously, since Oracle table names can not exceed 30 characters in length, the index creation step will fail if the base table name exceeds 23 characters.
    I have tried to substring the index name generation step in the IKM so that it only uses the first 23 characters of the table name, but have not had any luck with using the "substring" command together with snpRef.getTable call.
    This is the section of the IKM that I desire to change:
    - <Field name="Txt" type="java.lang.String">
    - <![CDATA[
    create unique index      <%=snpRef.getTable("L","INT_NAME","W")%>_idx
    on          <%=snpRef.getTable("L","INT_NAME","W")%> (<%=snpRef.getColList("", "[COL_NAME]", ", ", "", "UK")%>)
    <%=snpRef.getUserExit("FLOW_TABLE_OPTIONS")%>
    ]]>
    </Field>
    I would like to change the above to something similar to the following (note the only change is the addition of substring(1,23))
    - <Field name="Txt" type="java.lang.String">
    - <![CDATA[
    create unique index <%=snpRef.getTable("L","INT_NAME","W")*.substring(1,23)*%_idx
    on          <%=snpRef.getTable("L","INT_NAME","W")%> (<%=snpRef.getColList("", "[COL_NAME]", ", ", "", "UK")%>)
    <%=snpRef.getUserExit("FLOW_TABLE_OPTIONS")%>
    ]]>
    </Field>
    Any help greatly appreciated. Thanks.

    As the index is temporary, just like the I$ talbel, the easiest way is to replace the table name with some unique identifier like the session is:
    bq. I$_&lt;%=odiRef.getSession("SESS_NO")%&gt;_idx
    If for some reason that is not unique enough, add the NNO:
    bq. I$_&lt;%=odiRef.getSession("SESS_NO")%&gt;&lt;%=odiRef.getSession("NNO")%&gt; \\ _idx                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   

  • Difference between Unique key and Unique index

    Hi All,
    I've got confused in the difference between unique index & unique key in a table.
    While we create a unique index on a table, its created as a unique index.
    On the other hand, if we create a unique key/constraint on the table, Oracle also creates an index entry for that. So I can find the same name object in all_constraints as well as in all_indexes.
    My question here is that if during creation of unique key/constraint, an index is automatically created than why is the need to create unique key and then two objects , while we can create only one object i.e. unique index.
    Thanks
    Deepak

    This is only my understanding and is not according to any documentation, that is as follows.
    The unique key (constraint) needs an unique index for achieving constraint of itself.
    Developers and users can make any constraint (unique-key, primary-key, foreign-key, not-null ...) to enable,disable and be deferable. Unique key is able to be enabled, disabled, deferable.
    On the other hand, the index is used for performance-up originally, unique index itself doesn't have the concept like constraints. The index (including non-unique, unique) can be rebuilded,enabled,disabled etc. But I think that index cannot be set "deferable-builded" automatic.

  • Can I have a primary key as a non-unique column

    Hi all,
    I have a table with 35 columns and only one column in a not null column. But this column data is not unique. I want to create a primary key with non-unique index, can I don it, if it is not possible is there any other way to it. Please help me with this.
    Thanks for your help.vinaykotha

    1) Do the 'Unique Column combination' check first, using this example. (Pl. Change the column name and number of columns you consider as candidate key.) The SQL as follows:-
    ;WITH CTE (ProductKey, CustomerKey, SalesTerritoryKey, DupRec)
     AS
      (SELECT ProductKey, CustomerKey, SalesTerritoryKey, ROW_NUMBER() OVER
         (PARTITION BY ProductKey, CustomerKey, SalesTerritoryKey
          ORDER BY ProductKey, CustomerKey, SalesTerritoryKey) AS DupRec
       FROM dbo.FactSales 
    SELECT *
    FROM CTE
    WHERE DupRec > 1
    2) if CTE Table returns no records, you are good to create a Composite CLUSTERED PRIMARY KEY, like:
    ALTER TABLE dbo.FactSales
    ADD CONSTRAINT PK_ProductKey_CustomerKey_SalesTerritoryKey 
    PRIMARY KEY CLUSTERED (ProductKey, CustomerKey, SalesTerritoryKey);
    If no error..bingo! if NOT, Don't worry, create a Composite Index like this:-
    3)
    CREATE NONCLUSTERED INDEX [IX_ProductKey_CustomerKey_SalesTerritoryKey] 
    ON dbo.FactSales(ProductKey, CustomerKey, SalesTerritoryKey);
    This will work still efficiently. Usually all transaction table are like that like Daily_Order table, Ship_Details table etc.
    -NC

  • ORA-01502 error in case of unusable unique index and bulk dml

    Hi, all.
    The db is 11.2.0.3 on a linux machine.
    I made a unique index unusable, and issued a dml on the table.
    Howerver, oracle gave me ORA-01502 error.
    In order to avoid ORA-01502 error, do I have to drop the unique index ,and do bulk dml, and recreate the index?
    Or Is there any other solution without re-creating the unique index?
    create table hoho.abcde as
    select level col1 from dual connect by level <=1000
    10:09:55 HOHO@PD1MGD>create unique index hoho.abcde_dx1 on hoho.abcde (col1);
    Index created.
    10:10:23 HOHO@PD1MGD>alter index hoho.abcde_dx1 unusable;
    Index altered.
    Elapsed: 00:00:00.03
    10:11:27 HOHO@PD1MGD>delete from hoho.abcde where rownum < 11;
    delete from hoho.abcde where rownum < 11
    ERROR at line 1:
    ORA-01502: index 'HOHO.ABCDE_DX1' or partition of such index is in unusable stateThanks in advance.
    Best Regards.

    Hi. all.
    The following is from "http://docs.oracle.com/cd/E14072_01/server.112/e10595/indexes002.htm#CIHJIDJG".
    Is there anyone who can show me a tip to avoid the following without dropping and re-creating an unique index?
    •DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
    Unusable indexes
    An unusable index is ignored by the optimizer and is not maintained by DML. One reason to make an index unusable is if you want to improve the performance of bulk loads. (Bulk loads go more quickly if the database does not need to maintain indexes when inserting rows.) Instead of dropping the index and later recreating it, which requires you to recall the exact parameters of the CREATE INDEX statement, you can make the index unusable, and then just rebuild it. You can create an index in the unusable state, or you can mark an existing index or index partition unusable. The database may mark an index unusable under certain circumstances, such as when there is a failure while building the index. When one partition of a partitioned index is marked unusable, the other partitions of the index remain valid.
    An unusable index or index partition must be rebuilt, or dropped and re-created, before it can be used. Truncating a table makes an unusable index valid.
    Beginning with Oracle Database 11g Release 2, when you make an existing index unusable, its index segment is dropped.
    The functionality of unusable indexes depends on the setting of the SKIP_UNUSABLE_INDEXES initialization parameter.
    When SKIP_UNUSABLE_INDEXES is TRUE (the default), then:
    •DML statements against the table proceed, but unusable indexes are not maintained.
    •DML statements terminate with an error if there are any unusable indexes that are used to enforce the UNIQUE constraint.
    •For non-partitioned indexes, the optimizer does not consider any unusable indexes when creating an access plan for SELECT statements. The only exception is when an index is explicitly specified with the INDEX() hint.
    •For a partitioned index where one or more of the partitions are unusable, the optimizer does not consider the index if it cannot determine at query compilation time if any of the index partitions can be pruned. This is true for both partitioned and non-partitioned tables. The only exception is when an index is explicitly specified with the INDEX() hint.
    When SKIP_UNUSABLE_INDEXES is FALSE, then:
    •If any unusable indexes or index partitions are present, any DML statements that would cause those indexes or index partitions to be updated are terminated with an error.
    •For SELECT statements, if an unusable index or unusable index partition is present but the optimizer does not choose to use it for the access plan, the statement proceeds. However, if the optimizer does choose to use the unusable index or unusable index partition, the statement terminates with an error.Thanks in advance.
    Best Regards.

  • Use of indexes on dimensions

    Hi:
    Is necessary to create the unique key of a dimension with an index? In what cases is suitable to deploy it with or without an index? In respect to fact tables, what are the indexes and constraints to create? The use of an unique key on the columns of the foreign keys is suitable?
    Thanks,
    Hazbleydi C. Verástegui

    Hii
    Don't create unique key with a column of a fact table which refers with a foreign key to another table (dimension)! This data must be unique in the dimension table!
    But indexes in the columns of foreign keys will speed up your queries.
    Ott Karesz
    http://www.trendo-kft.hu

  • Indexes in Internal Tables

    Can we use primary and secondary  indexes on internal tables? If yes can anyone give me description how to use them?
    thank you.
    jeevi.

    Hi Thomas,
    please give an example.
    AFAIK starting with 4.6 ABAP uses unique and non-unique keys for internal tables of type SORTED and unique keys for hashed tables. One key per table. That means primary.
    A key is build of one or more fields or pseudo field table_line.
    I know secondary keys only with database tables.
    Regards,
    Clemens

  • Use secondary index in internal tables.

    what are the uses of secondary index in internal table?

    http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eb47446011d189700000e8322d00/content.htm
    Creating Secondary Indexes
    Proceed as follows to create a secondary index on a table:
    In the field maintenance screen for the table, choose Goto --> Indexes.
    1. If you went to the field maintenance screen of the table in display mode, only correct the index (and not the table).
    If indexes already exist on the table, a list of these indexes is displayed. Choose Create. A dialog box appears in which you must enter the three-place index identifier. If there are no indexes, go directly to the dialog box.
    2. Enter the index identifier and choose Continue.
    You will go to the maintenance screen for indexes.
    3. Enter an explanatory short text in the field Short text.
    Choose TabFields.
    4. A list of all the fields of the table is displayed.
    5. Select the fields which you want to copy to the index.
    6. Choose Copy.
    The selected fields are copied to the index.
    7. If the values in the index fields already uniquely identify each record of the table, select Unique index.
    A unique index is automatically created on the database during activation because a unique index also has a functional meaning (prevents double entries of the index fields).
    8. If it is not a unique index, leave Non-unique index selected. In this case you can use the corresponding radio buttons to define whether the index should be created automatically on the database for all database systems, for selected database systems or for no database system.
    9. If you chose For selected database systems, you must specify these systems.
    You have two possibilities here:
    List of inclusions: The index is only created automatically during activation for the database systems specified in the list. The index is not created on the database for the other database systems.
    List of exclusions: The index is not created automatically on the database during activation for the specified database systems. The index is automatically created on the database for the other database systems.
    Click on the arrow symbol behind the radio buttons. A dialog box appears in which you can define up to 4 database systems. Use the corresponding radio buttons to decide whether this list should be treated as a list of inclusions or exclusions.
    10. Activate the index with Index ® Activate. The activation log tells you about the flow of the activation. Call it with Utilities ® Act.log. If an error occurred when activating the secondary index, you will automatically go to this log.
    The secondary index is automatically created on the database during activation if the corresponding table has already been created there and index creation was not excluded for the database system.
    Reward points if useful.

  • Insert with unique index slow in 10g

    Hi,
    We are experiencing very slow response when a dup key is inserted into a table with unique index under 10g. the scenario can be demonstrated in sqlplus with 'timing on':
    CREATE TABLE yyy (Col_1 VARCHAR2(5 BYTE) NOT NULL, Col_2 VARCHAR2(10 BYTE) NOT NULL);
    CREATE UNIQUE INDEX yyy on yyy(col_1,col_2);
    insert into yyy values ('1','1');
    insert into yyy values ('1','1');
    the 2nd insert results in "unique constraint" error, but under our 10g the response time is consistently in the range of 00:00:00.64. The 1st insert only took 00:00:00.01. BTW, if no index or non-unique index then you can insert many times and all of them return fast. Under our 9.2 DB the response time is always under 00:00:00.01 with no-, unique- and non-unique index.
    We are on AIX 5.3 & 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production.
    Has anybody seen this scenario?
    Thanks,
    David

    It seems that in 10g Oracle simply is doing something more.
    I used your example and run following script on 9.2 and 10.2. Hardware is the same i.e. these are two instances on the same box.
    begin
      for i in 1..10000 loop
        begin
          insert into yyy values ('1','1');
        exception when others then null;
        end;
      end loop;
    end;
    /on 10g it took 01:15.08 and on 9i 00:47.06
    Running trace showed that in 9i there was difference in plan of following recursive sql:
    9i plan:
    select c.name, u.name
    from
    con$ c, cdef$ cd, user$ u  where c.con# = cd.con# and cd.enabled = :1 and
      c.owner# = u.user#
    call     count       cpu    elapsed       disk      query    current        rows
    Parse    10000      0.43       0.43          0          0          0           0
    Execute  10000      1.09       1.07          0          0          0           0
    Fetch    10000      0.23       0.19          0      20000          0           0
    total    30000      1.76       1.70          0      20000          0           0
    Misses in library cache during parse: 1
    Optimizer mode: CHOOSE
    Parsing user id: SYS   (recursive depth: 2)
    Rows     Row Source Operation
          0  NESTED LOOPS 
          0   NESTED LOOPS 
          0    TABLE ACCESS BY INDEX ROWID CDEF$
          0     INDEX RANGE SCAN I_CDEF4 (object id 53)
          0    TABLE ACCESS BY INDEX ROWID CON$
          0     INDEX UNIQUE SCAN I_CON2 (object id 49)
          0   TABLE ACCESS CLUSTER USER$
          0    INDEX UNIQUE SCAN I_USER# (object id 11)10g plan
    select c.name, u.name
    from
    con$ c, cdef$ cd, user$ u  where c.con# = cd.con# and cd.enabled = :1 and
      c.owner# = u.user#
    call     count       cpu    elapsed       disk      query    current        rows
    Parse    10000      0.21       0.20          0          0          0           0
    Execute  10000      1.20       1.31          0          0          0           0
    Fetch    10000      2.37       2.59          0      20000          0           0
    total    30000      3.79       4.11          0      20000          0           0
    Misses in library cache during parse: 1
    Misses in library cache during execute: 1
    Optimizer mode: CHOOSE
    Parsing user id: SYS   (recursive depth: 2)
    Rows     Row Source Operation
          0  HASH JOIN  (cr=2 pr=0 pw=0 time=301 us)
          0   NESTED LOOPS  (cr=2 pr=0 pw=0 time=44 us)
          0    TABLE ACCESS BY INDEX ROWID CDEF$ (cr=2 pr=0 pw=0 time=40 us)
          0     INDEX RANGE SCAN I_CDEF4 (cr=2 pr=0 pw=0 time=27 us)(object id 53)
          0    TABLE ACCESS BY INDEX ROWID CON$ (cr=0 pr=0 pw=0 time=0 us)
          0     INDEX UNIQUE SCAN I_CON2 (cr=0 pr=0 pw=0 time=0 us)(object id 49)
          0   TABLE ACCESS FULL USER$ (cr=0 pr=0 pw=0 time=0 us)So in 10g it had hash join instead of nested loop join at least for this particular select. Probably time to gather stats on sys tables?
    The difference in time wasn't so big though 4.11 vs 1.70 so it doesn't explain all the time taken.
    But you can probably check whether you haven't more difference.
    Also you can download Thomas Kyte runstats_pkg and run it on both environments to compare whether some stats or latches haven't very big difference.
    Gints Plivna
    http://www.gplivna.eu

  • Transactional Replication: Non-Clustered Indexes not copying.

    Hello,
    I set up replication on our servers at work to streamline some procedures we run daily/weekly on them.
    This copies around 15 articles from two databases on the "Master" server to another server used for execution purposes. For the most part it was a pretty straight forward task and it seemed to work nicely; but I realised after some investigation that the
    non-clustered indexes weren't copying over to the child server.
    I set the non-clustered indexes property in the properties of the publishing articles to "True" and generated a new snapshot, this seemed to work, but I've come into work this morning to find the property has reset to "False" and I have no indexes on the
    table again. Why is this happening and is there any way I can resolve the matter so the indexes are copied over concurrently?
    Thanks in advance for your advice.
    JB

    I actually solved this.
    You can use a post-replication SQL script to create the indexes. Whatever articles you're publishing open up the indexes drop down list of the article in object explorer, right-click on an index and hover over Script Index as, then Create-to, then click
    New Query Window editor.
    Up will pop up a new query window with the resulting index. Work your way through all the indexes on all the articles of the publication, copy and pasting just the create index line and below of each script, pull them all together into one query window.
    Once you're done find a safe folder somewhere on your harddrive and save the SQL query as an .sql file with a sensible name.
    Right click on the publication and goto properties. Click on the "Snapshot" tab, in there; there should be a section saying "Run additional scripts". Choose the browse button next to "After applying the Snapshot; execute this script:"
    Navigate to your script file and choose it. Once done click ok and it'll prompt you that something has changed and if you'd like to generate a new snapshot, make sure you do or it won't work.
    That's it, you'll find once the publication has bulk copied over the the subscriptions successfully there are non clustered indexes on the tables. Pretty simple!

Maybe you are looking for