When to create index on partitioned table ?

Hi,
The original table TEST1 contain one index called INDX_HIREDATE on field HIREDATE
CREATE TABLE TEST1(
COD NUMBER PRIMARY KEY,
HIREDATE DATE);
CREATE INDEX INDX_HIREDATE ON TEST1 (HIREDATE);
I created a example partitioned table as below:
CREATE TABLE TEST2_PART(
COD NUMBER PRIMARY KEY,
HIREDATE DATE)
PARTITION BY RANGE (HIREDATE)(
PARTITION P2003 VALUES LESS THAN (TO_DATE('01/01/2004','DD/MM/YYYY')),
PARTITION P2004 VALUES LESS THAN (TO_DATE('01/01/2005','DD/MM/YYYY')),
PARTITION P3000 VALUES LESS THAN (MAXVALUE));
INSERT /*+ APPEND */ INTO TEST2 SELECT * FROM TEST1;
Questions:
Need i to create the index on TEST2 table the same way done on the TEST1 table?
ex: CREATE INDEX INDX_HIREDATE ON TEST2 (HIREDATE);
or have i need to create the global/local index on each partition?
The Primary Key index is a global for partitions??
What is the best way?
Thanks

Index creation on partitioned tables is similar to the non-partitioned tables. There is no special syntax unless you need to create LOCAL indexes. For creating local indexes, add LOCAL key word at the end of the "create index...." command.
To create local primary key index you may need to use different syntax the one used in your create table command. Refer to SQL Reference manual for actual syntax. (remember manuals are the best place for getting quick answers). All the manuals are available online (at otn.oracle.com).

Similar Messages

  • When do I really need to create indexes for a table?

    Once I was talking to a dba in a conference.
    He told me that not always I have to create indexes for a single table, it depends of its size.
    He said that Oracle read registers in blocks, and for a small table Oracle can read it fully, in a single operation, so in those cases I don't need indexes and statistcs.
    So I would like to know how to calculate it.
    When do I really need to create indexes for a table?
    If someone know any documment that explain that, or have some tips, I'd aprecciate.
    Thanks.
    P.S.: The version that I'm using is Oracle 9.2.0.4.0.

    Hi Vin
    You mentioned so many mistakes here, I don't know where to begin ...
    vprabhu_2000 wrote:
    There are different kinds of Index. B-tree Index is by default. Bit map index, function based index,index organized table.
    B-tree index if the table is large This is incorrect. Small tables, even those consisting of rows within just one block, can benefit from an index. There is no table size too small in which an index might not be benefical. William Robertson in his post references links to my blog where I discuss this.
    and if you want to retrieve 10 % or less of data then B-tree index is good. This is all wrong as well. A FTS on a (say) million row table could very well be more efficient when retrieving (say) just 1% of data. An index could very well be more efficient when retrieving 100% of data. There's nothing special about 10% and there is no such magic number ...
    >
    Bit Map Index - On low cardinality columns like Sex for eg which could have values Male,Female create a bit map index. Completely and utterly wrong. A bitmap index might be the perfect type of index, better than a B-Tree, even if there are (say) 100,000 distinct values in the table. That a bitmap index is only suitable for low cardinality columns is just not true. And what if it's an OLTP application, with lot's of concurrent DML on the underlining table, do you really think a bitmap index would be a good idea ?
    >
    You can also create an Index organized table if there are less rows to be stored so data is stored only once in index and not in table. Not sure what you mean here but an IOT can potentially be useful if you have very large numbers of rows in the table. The number of rows has nothing to do with whether an IOT is suitable or not.
    >
    Hope this info helps. Considering most of it is wrong, I'm not sure it really helps at all :(
    Cheers
    Richard Foote
    http://richardfoote.wordpress.com/

  • Can I create unpartitioned index on partitioned table??

    Hi,
    I am not clear about the concepts of partitioned and non partitioned index.I was under impression that If we create a index on partitioned table it will be automatically becomes a partitioned index.But I cheked in my DB there are many unpartitioned indexes on large partitioned tables.
    Which one of these is efficient? wht is the concept of local and global related to these partitioned and unparitioned.I am bit confused.pls help me.
    Thanks

    There's nothing prevent you from creating a nonpartitioned index on partitioned table. The official name for it is Global Nonpartitioned Indexes
    Global Nonpartitioned Indexes
    Global nonpartitioned indexes behave just like a nonpartitioned index. They are commonly used in OLTP environments and offer efficient access to any individual record.
    http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#i461446

  • Local index vs global index in partitioned tables

    Hi,
    I want to know the differences between a global and a local index.
    I'm working with partitioned tables about 10 millons rows and 40 partitions.
    I know that when your table is partitioned and your index non-partitioned is possible that
    some database operations make your index unusable and you have tu rebuid it, for example
    when yo truncate a partition your global index results unusable, is there any other operation
    that make the global index unusable??
    I think that the advantage of a global index is that takes less space than a local and is easier to rebuild,
    and the advantage of a local index is that is more effective resolving a query isn't it???
    Any advice and help about local vs global index in partitioned tables will be greatly apreciatted.
    Thanks in advance

    here is the documentation -> http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/partconc.htm#sthref2570
    In general, you should use global indexes for OLTP applications and local indexes for data warehousing or DSS applications. Also, whenever possible, you should try to use local indexes because they are easier to manage. When deciding what kind of partitioned index to use, you should consider the following guidelines in order:
    1. If the table partitioning column is a subset of the index keys, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 2.
    2. If the index is unique, use a global index. If this is the case, you are finished. If this is not the case, continue to guideline 3.
    3. If your priority is manageability, use a local index. If this is the case, you are finished. If this is not the case, continue to guideline 4.
    4. If the application is an OLTP one and users need quick response times, use a global index. If the application is a DSS one and users are more interested in throughput, use a local index.
    Kind regards,
    Tonguç

  • How   to  find  global  index  in partition table

    Hi guys ,
    need one help
    How to find global index on partition table
    How to find local index on partition table
    Need query
    Thanks in advance
    Edited by: nav on Feb 17, 2012 6:51 AM

    nav wrote:
    Hi Solomon,
    so I have to identify partition & index are created or not,
    also I have check the status of index ( both global and local)So what's the problem? Table/index partition is an object, so you can query DBA_OBJECTS:
    SELECT  SUBOBJECT_NAME,
            CREATED
      FROM  DBA_OBJECTS
      WHERE OWNER = partitioned-table-owner
        AND OBJECT_NAME = partitioned-table-name
        AND CREATED >= TRUNC(SYSDATE)
    /This will give you partitions created today. So if you run this right after your job (I hope your job doen't run too close to midnight), you'll get table partition name your job created. Same logic can be applied to indexes.
    SY.

  • Why should we create index on  the table after inserting data ?

    Please tell me the Reason, why should we create index on the table after inserting data .
    while we can also create index on the table before insertion of the data.

    The choice depends on a number of factors, the main being how many rows are going to be inserted in the table as a percentage of the existing rows, or the percentage growth.
    Creating index after a table has been populated works better when the tables are large or the inserts are large for the following reasons
    1. The sort and creation of index is more efficient when done in batch and written in bulk. So works faster.
    2. When the index is being written blocks get acquired as more data gets written. So, when a large number of rows get inserted in a table that already has an index , the index data blocks start splitting / chaining. This increases the "depth" of the inverted b-tree makes and that makes the index less efficient on I/O. Creating index after data has been inserted allows Orale to create optical block distribution/ reduce splitting / chaining
    3. If an index exists then it too is routed through the undo / redo processes. Thats an overhead which is avoided when you create index after populating the table.
    Regards

  • A query related to creating Indexes for a table

    Hi ,
    I am in a J2EE Banking Project using Oracle 10g as our Database .
    We have created Indexes on some tables .
    But this this is not called by any of our Java class .
    Could anybody please let me know how these Indexes will actually improve the Performance .
    Waiting for your replies .
    Thanks in advance .

    But in our safety database (huge & ofcourse Oracle), we use indexes just because to avoid duplicates, improve data retrieval and so on.As you pointed out indexes can do 2 things for you: enforce uniqueness and (hopefully) improve data retrieval. Enforcing uniqueness is pretty basic, but indexes don't always improve performance. Under the wrong condtions indexes can hurt performance. The ideas below refer to B-TREE indexes; other kinds of indexes have other considerations
    Indexes add overhead to insert, delete, and (hopefully not - updating index columns is a Bad Idea), enough so that if you're inserting a lot of rows into a large table it is sometimes helpful to drop the indexes, load the data, and recreate the indexes when done to help performance. The more indexes a table has the more overhead DML statements need to maintain them.
    Indexes help query performance under a couple of conditions. When using them as join keys to retrieve a small percentage of rows in a table (< 20% maybe; there is no firm number) indexes can help. When a query can read its columns from an index only (such as counts against a primary key index) index access can be faster than table access.
    Indexes can hurt performance by adding overhead for maintenance if the index is never actually used or if used to read most of the rows in a table when a full table scan would be more efficient (why go through the extra effort to read the index and then table when you'll have to read most of the rows in the table anyway?).

  • Indexing on partitioned tables

    I was wondering if there are any good standards for indexing very large partitioned tables (i.e. what should I index). Also, if there are any good standards for indexing these partitioned tables when running queries that do not include the partitioned column in the query?

    There's no real difference in what you would index, other than maybe a slightly lower requirement for indexing on tha partitioning key column(s).
    You ought to be considering whether you need local or global indexes though, and you'll find a lot of information on that over at http://asktom.oracle.com and in the documentation -- to simplify, OLTP usually uses global indexes and DWH usually uses local indexes. You'll want to understand the pro's and con's or each before deciding on your own situation though.

  • Index on partitioned table

    A table is partitioned. the table is range partitioned and the key for partition is order_date
    Column Datatype
    ID NUMBER
    Order_date DATE
    Status VARCHAR2
    I have to create an unique index on the column order_date.Will the index need to be partitioned?Is ther any procedure i can create unpartitioned index.
    Thanks in advance.

    user5698021 wrote:
    Will the index need to be partitioned?Is ther any procedure i can create unpartitioned index.You can create index as partitioned or as non-partitioned: Partitioned Index Examples.
    SY.

  • Creating Indexes in Cluster Tables

    Hi,
       I want to  enable the index for the a cluster table..how is it possible..As we see for transparent tables like MSEG ,index tab is enabled but tables like BSEG the option is disabled..Please help me find a solution..
    Regards
    Maria

    You cannot create index on cluster table in SAP.
    BSEG is a cluster table, so no index, but hopefully there are "database indexes" on BSEG, which are actual database table : BSIS, BSAS, BSID, BSAS, and so on.
    BSEG Access
    BSAD Accounting: Secondary index for customers (cleared items)
    BSAK Accounting: Secondary index for vendors (cleared items)
    BSAS Accounting: Secondary index for G/L accounts (cleared items)
    BSID Accounting: Secondary index for customers
    BSIK Accounting: Secondary index for vendors
    BSIM Secondary Index, Documents for Material
    BSIS Accounting: Secondary index for G/L accounts
    Create index on these tables.
    Look also at
    Re: Selecting data from BSEG.
    Regards

  • Create a GPT partition table and format with a large volume (solved)

    Hello,
    I'm having trouble creating a GPT partition table for a large volume (~6T). It is a RAID 5 (hardware) with 3 hard disk drives having a size of 3T each (thus the resulting 6T volume).
    I tried creating a GPT partition table with gdisk but it just fails at creating it, stopping here (I've let it run for like 3 hours...):
    Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
    PARTITIONS!!
    Do you want to proceed? (Y/N): y
    OK; writing new GUID partition table (GPT) to /dev/md126.
    I also tried with parted but I get the same result. Out of luck, I created a GPT partition table from Windows 7 and  2 NTFS partitions (15G and the rest of space for the other) and it worked just fine. I then tried to format the 15G partition as ext4 but, as for gdisk, mkfs.ext4 will just never stop.
    Some information:
    fdisk -l
    Disk /dev/sda: 256.1 GB, 256060514304 bytes, 500118192 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: dos
    Disk identifier: 0xd9a6c0f5
    Device Boot Start End Blocks Id System
    /dev/sda1 * 2048 104861695 52429824 83 Linux
    /dev/sda2 104861696 466567167 180852736 83 Linux
    /dev/sda3 466567168 500117503 16775168 82 Linux swap / Solaris
    Disk /dev/sdb: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk label type: dos
    Disk identifier: 0x00000000
    Device Boot Start End Blocks Id System
    /dev/sdb1 1 4294967295 2147483647+ ee GPT
    Partition 1 does not start on physical sector boundary.
    Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 4096 bytes / 4096 bytes
    Disk label type: dos
    Disk identifier: 0x00000000
    Device Boot Start End Blocks Id System
    /dev/sdd1 1 4294967295 2147483647+ ee GPT
    Partition 1 does not start on physical sector boundary.
    Disk /dev/sde: 320.1 GB, 320072933376 bytes, 625142448 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk label type: dos
    Disk identifier: 0x5ffb31fc
    Device Boot Start End Blocks Id System
    /dev/sde1 * 2048 625139711 312568832 7 HPFS/NTFS/exFAT
    Disk /dev/md126: 6001.1 GB, 6001143054336 bytes, 11720982528 sectors
    Units = sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 4096 bytes
    I/O size (minimum/optimal): 65536 bytes / 131072 bytes
    Disk label type: dos
    Disk identifier: 0x00000000
    Device Boot Start End Blocks Id System
    /dev/md126p1 1 4294967295 2147483647+ ee GPT
    Partition 1 does not start on physical sector boundary.
    WARNING: fdisk GPT support is currently new, and therefore in an experimental phase. Use at your own discretion.
    gdisk -l on my RAID volume (/dev/md126):
    GPT fdisk (gdisk) version 0.8.7
    Partition table scan:
    MBR: protective
    BSD: not present
    APM: not present
    GPT: present
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/md126: 11720982528 sectors, 5.5 TiB
    Logical sector size: 512 bytes
    Disk identifier (GUID): 8E7D03F1-8C3A-4FE6-B7BA-502D168E87D1
    Partition table holds up to 128 entries
    First usable sector is 34, last usable sector is 11720982494
    Partitions will be aligned on 8-sector boundaries
    Total free space is 6077 sectors (3.0 MiB)
    Number Start (sector) End (sector) Size Code Name
    1 34 262177 128.0 MiB 0C01 Microsoft reserved part
    2 264192 33032191 15.6 GiB 0700 Basic data partition
    3 33032192 11720978431 5.4 TiB 0700 Basic data partition
    To make things clear: sda is an SSD on which Archlinux has been freshly installed (sda1 for root, sda2 for home, sda3 for swap), sde is a hard disk drive having Windows 7 installed on it. My goal with the 15G partition is to format it so I can mount /var on the HDD rather than on the SSD. The large volume will be for storage.
    So if anyone has any suggestion that would help me out with this, I'd be glad to read.
    Cheers
    Last edited by Rolinh (2013-08-16 11:16:21)

    Well, I finally decided to use a software RAID as I will not share this partition with Windows anyway and it seems a better choice than the fake RAID.
    Therefore, I used the mdadm utility to create my RAID 5:
    # mdadm --create --verbose /dev/md0 --level=5 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1
    # mkfs.ext4 -v -m .1 -b 4096 -E stride=32,stripe-width=64 /dev/md0
    It works like a charm.

  • How to create index for particular table in R3

    Hi
    My load is taking too much time and it leads to process over due error. Does creating indexes on table in r3 side will solve this issue? If so how can we find out on which table does this particular data source depend. I went to maintain extract structure and findout only one table is supplying data for this data source.
    Is there any other factors depend to solve this.
    Thanks
    kk

    Hi,
    it will depend on the table.... Having an index created will speed up the loading but slow down the insert therefore slowing some process perhaps...
    May I ask which table it is? And which fields would you need to index?
    Are you sure that bottleneck is located in R/3? Analyze your loading time in the monitor and see if this is really the case.
    Otherwise you can create index for a table in Tx SE11; first check if an index is not already created...
    hope this helps,
    Olivier.

  • Cannot create text index in partition table on Oracle 10g

    I try to create context index in a table with 15 millions records. The table is divided 5 partitions and each patition has 3 millions records. When I create the context index in the table, the same error always arised. The follow are my work:
    --First create my own lexer
    begin
    ctx_ddl.createperference('my_chinese_lexer','chinese_lexer');
    end;
    --Second create index
    create index idx_part_text3 on tb_test_part(text3)
    indextype is ctxsys.context local (
    partition p1_ix,
    partition p2_ix,
    partition p3_ix ,
    partition p4_ix,
    partition p5_ix)
    parameters('lexer my_chinese_lexer') parallel;
    --error message
    create index idx_part_text3 on tb_test_part(text3)
    Error in 1 line:
    ORA-12801: Parellel Query Server P000 send error signal
    ORA-29855: Error on execute ODCIINDEXCREATE program
    ORA-06510: PL/SQL: User Defined Error
    ORA-06512: In "CTXSYS.DRIDISP", line 244
    ORA-04030: Try to alloc 65548 Bytes (CTX PRM heap,draccbx:message buffer) Out of memory
    ORA-06512: In "CTXSYS.DRIPARX", line 10
    ORA-06512: In "CTXSYS.TEXTINDEXMETHODS", line 359
    ORA-04030: Try to alloc 65548 Bytes (CTX PRM heap,draccbx:message buffer) Out of memory
    ORA-06512: In "CTXSYS.DRUE", line 191
    ORA-06512: In "CTXSYS.DRUE", line 49
    ORA-06512: In "CTXSYS.DRUE", line 24
    ORA-06512: In "CTXSYS.DRUE", line 186
    ORA-06512: In "CTXSYS.DRVDDL", line 682
    ORA-04030: Try to alloc 65548 Bytes (CTX PRM heap,draccbx:message buffer) Out of memory
    ORA-04030: Try to alloc 65548 Bytes (CTX PRM heap,draccbx:message buffer) Out of memory
    ORA-06512: In "CTXSYS.DRUE", line 191
    ORA-06512: In "CTXSYS.DRUE", line 49
    ORA-06512: In "CTXSYS.DRUE", line 24
    ORA-06512: In "CTXSYS.DRVDDL", line 452
    ORA-06510: PL/SQL: User Defined Error
    BTW:
    My oracle 10g run on linux AS3 box with 4xP4 and 6G Mem.
    I set pga_aggregate_target=2200M, and at the beginning of creating index, the max pga alloced is about 1100M, but when one patition finished, the error arised and the max pga alloced suddenly reached 3500M. So in every times, the index status is always like below:
    P1_ix usable
    P2_ix Inprogress
    P3_ix Inprogress
    P4_ix Inprogress
    P5_ix Inprogress
    Thx for any help!

    Try to increase LARGE_POOL_SIZE.
    PGA_AGGREGATE_TARGET is not only parameter that can meddle in parallel execution.
    Looks like parallel execution parameters is not correctly set. Check it all, including PARALLEL_EXECUTION_MESSAGE_SIZE.

  • Local Vs Global Index on partitioned table?

    Hello All,
    DESC PS_P1_EMP_QRYSCRTY
    Name Null? Type
    EMPLID NOT NULL VARCHAR2(11)
    EMPL_RCD NOT NULL NUMBER(38)
    ROWSECCLASS NOT NULL VARCHAR2(30)
    ACCESS_CD CHAR(1)
    MY SQL QUERY IS:-
    SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
    FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY EMP
    WHERE EMP.ROWSECCLASS=OPR.CLASSID
    This query was taking around 15 mins to run at sql-prompt
    I have created a partitioned table based on PS_P1_EMP_QRYSCRTY :-
    CREATE TABLE PS_P1_EMP_QRYSCRTY_BAK
    TABLESPACE PSNEWTAB
    PARTITION BY HASH(ROWSECCLASS)
    ( PARTITION PART1 ,
    PARTITION PART2 ,
    PARTITION PART3 ,
    PARTITION PART4 ,
    PARTITION PART5 ,
    PARTITION PART6 ,
    PARTITION PART7 ,
    PARTITION PART8 ,
    PARTITION PART9 ,
    PARTITION PART10 ,
    PARTITION PART11 ,
    PARTITION PART12 ,
    PARTITION PART13 ,
    PARTITION PART14 ,
    PARTITION PART15 ,
    PARTITION PART16
    ENABLE ROW MOVEMENT
    AS SELECT * FROM PS_P1_EMP_QRYSCRTY
    I created a local index like on PS_P1_EMP_QRYSCRTY_BAK
    CREATE INDEX PS_P1_EMP_QRYSCRTY_BAK
    ON PS_P1_EMP_QRYSCRTY_BAK(ROWSECCLASS,EMPLID,EMPL_RCD)
    TABLESPACE PSINDEX
    LOCAL;
    The Following is an extract From PS_P1_EMP_QRYSCRTY_BAK
    1ST COLUMN =TABLE NAME
    2ND COLUMN = PARTITION NAME
    3RD COLUMN = NUM OF DISTINCT ROWSECCLASS IN THE PARTITION
    4TH COLUMN = NUM OF TOTAL ROWS IN THE PARTITION
    TABLE_NAME PARTITION_NAME NUM_OF_DISTINCT_ROWSECCLASS NUM_OF_ROWS
    PS_P1_EMP_QRYSCRTY_BAK | PART1 | 25 | 289058
    PS_P1_EMP_QRYSCRTY_BAK | PART2 | 25 | 154537
    PS_P1_EMP_QRYSCRTY_BAK | PART3 | 27 | 364219
    PS_P1_EMP_QRYSCRTY_BAK | PART4 | 33 | 204528
    PS_P1_EMP_QRYSCRTY_BAK | PART5 | 23 | 527974
    PS_P1_EMP_QRYSCRTY_BAK | PART6 | 22 | 277210
    PS_P1_EMP_QRYSCRTY_BAK | PART7 | 23 | 517125
    PS_P1_EMP_QRYSCRTY_BAK | PART8 | 30 | 307634
    PS_P1_EMP_QRYSCRTY_BAK | PART9 | 28 | 523169
    PS_P1_EMP_QRYSCRTY_BAK | PART10 | 38 | 192565
    PS_P1_EMP_QRYSCRTY_BAK | PART11 | 27 | 120062
    PS_P1_EMP_QRYSCRTY_BAK | PART12 | 33 | 407829
    PS_P1_EMP_QRYSCRTY_BAK | PART13 | 37 | 522349
    PS_P1_EMP_QRYSCRTY_BAK | PART14 | 25 | 275991
    PS_P1_EMP_QRYSCRTY_BAK | PART15 | 21 | 259676
    PS_P1_EMP_QRYSCRTY_BAK | PART16 | 23 | 468071
    SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
    FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
    WHERE EMP.ROWSECCLASS=OPR.CLASSID
    Now when i run this query it gives result in around 5-6 mins
    MY PS_P1_EMP_QRYSCRTY_BAK table contains sumwhat 6 million rows...
    Now My Questions are:-
    1) Is the number of partition done by me optimal under these circumstances...i mean can i get better performance By increasing or decreasing the number of partitions.
    2) I created local index on PS_P1_EMP_QRYSCRTY_BAK.
    Whether creating local or global index will be more beneficial keeping in mind the where clause and Select clause of the query....
    SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
    FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
    WHERE EMP.ROWSECCLASS=OPR.CLASSID
    i mean in where clause rowsecclass is used thats why i partitioned my table on ROWSECCLASS.
    And in select clause i m selecting EMPLID and EMPL_RCD
    Thats y i made a local index on ROWSECCLASS,EMPLID ,EMPL_RCD .
    Thanks
    --Pradeep                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

    1) Is the number of partition done by me optimal under these circumstances...i mean can i get better performance >By increasing or decreasing the number of partitions.
    2) I created local index on PS_P1_EMP_QRYSCRTY_BAK.
    Whether creating local or global index will be more beneficial keeping in mind the where clause and Select clause of >the query....You'll have to see for yourself what is optimal. Every system is different. Here are some ideas, though.
    Your query
    SELECT DISTINCT OPR.OPRID , EMP.EMPLID ,EMP.EMPL_RCD , OPR.CLASSID ,'Y'
    FROM PS_SJT_OPR_CLS OPR , PS_P1_EMP_QRYSCRTY_BAK EMP
    WHERE EMP.ROWSECCLASS=OPR.CLASSIDappears to read all qualifying rows across all qualifying partitions. Since you are partitioning by an id that would appear to exclude range and list partitioning instead so the hash partition is probably the best for your application.
    Regarding global vs local partitions, I have seen timings indicate that global indexes can improve cross-partition queries slighly. I have not worked with partitions for a while but remember that global partition maintenance is difficult; anything the partition structure changes the global index had to be rebuild. You can check the documentation to see if that has changed.
    If possible creating a unique index should give better performance than using an index allowing duplicates.

  • Preserving Global indexes on partitioned tables

    Hello,
    we have a 24x7 application where a large number of client processes (around 200) loads details of transactions performed onto an historycal, date partitioned table - Clients are transactional, so they use INSERT + COMMIT for every row.
    We have the need to create an additional index with a unique constraint on a column where the partitioning key cannot be included, therefore this index has been declared global.
    When an old partition is dropped, the global index usually gets unusable, and client processes gets an ORA-01502.
    To avoid this, I have tried the following:
    LOCK TABLE ... IN EXCLUSIVE MODE to make the script wait until there are no pending COMMIT
    ALTER TABLE ... DROP PARTITION ... UPDATE GLOBAL INDEXES PARALLEL to avoin index to be marked UNUSABLE and release the table lock at the end of the operation.
    It seems working fine, as the clients gets locked on their INSERTs for a limited amount of time (apparently just the DROP time) and after that they go on on their activities while the global index is still USABLE and the index updates proceeds for some minutes.
    In the end, my perception is that the UPDATE GLOBAL INDEXES clause behave as an online rebuild, thus leaving other processes working on partition not affected by the DROP with the UNIQUE constraint still active.
    Is there anybody who can confirm me tha my idea is right, and this UPDATE clause is a SAFE way to achieve pratition drop without service interruption or index corruption for transactional clients?
    Many thanks,
    Riccardo

    Hi,
    In fact, only the UPDATE GLOBAL INDEXES clause is pertinent here. here's what happens when you're doign the LOCK/ALTER:
    LOCK TABLE ... IN EXCLUSIVE MODE
    You wait till you get a table lock. All "clients" are enqueued till you acquire the lock, and then stay enqueued till you release it.
    ALTER TABLE ... DROP PARTITION ... UPDATE GLOBAL INDEXES PARALLEL
    You start a DDL statement. So the first thing Oracle does is to COMMIT the current transaction, hence releasing the LOCK you previously acquired explicitly.
    The "clients" resume standard operations, meanwhile the partition is dropped and the global index updated. Once the drop is over, the DDL transaction is commited.Meaning simply: the explicit table locking is useless!
    Yoann.

Maybe you are looking for