Query partition tables

hi all,
i want to query the partition tables which are more than 1GB in size?
how can i query?

Use the view DICT to query for the dictionary view which contains partition info.
Join that view with DBA_ or USER_SEGMENTS.
Generally speaking queries with respect to the contents of the dictionary are most easily resolved by consulting documentation or the views DICT, DICT_COLUMNS and DICT_COMMENTS, and doing so is also faster than asking here, as this is not a chatroom.
Sybrand Bakker
Senior Oracle DBA

Similar Messages

  • ORA-00604 ORA-00904 When query partitioned table with partitioned indexes

    Got ORA-00604 ORA-00904 When query partitioned table with partitioned indexes in the data warehouse environment.
    Query runs fine when query the partitioned table without partitioned indexes.
    Here is the query.
    SELECT al2.vdc_name, al7.model_series_name, COUNT (DISTINCT (al1.vin)),
    al27.accessory_code
    FROM vlc.veh_vdc_accessorization_fact al1,
    vlc.vdc_dim al2,
    vlc.model_attribute_dim al7,
    vlc.ppo_list_dim al18,
    vlc.ppo_list_indiv_type_dim al23,
    vlc.accy_type_dim al27
    WHERE ( al2.vdc_id = al1.vdc_location_id
    AND al7.model_attribute_id = al1.model_attribute_id
    AND al18.mydppolist_id = al1.ppo_list_id
    AND al23.mydppolist_id = al18.mydppolist_id
    AND al23.mydaccytyp_id = al27.mydaccytyp_id
    AND ( al7.model_series_name IN ('SCION TC', 'SCION XA', 'SCION XB')
    AND al2.vdc_name IN
    ('PORT OF BALTIMORE',
    'PORT OF JACKSONVILLE - LEXUS',
    'PORT OF LONG BEACH',
    'PORT OF NEWARK',
    'PORT OF PORTLAND'
    AND al27.accessory_code IN ('42', '43', '44', '45')
    GROUP BY al2.vdc_name, al7.model_series_name, al27.accessory_code

    I would recommend that you post this at the following OTN forum:
    Database - General
    General Database Discussions
    and perhaps at:
    Oracle Warehouse Builder
    Warehouse Builder
    The Oracle OLAP forum typically does not cover general data warehousing topics.

  • Partition Table Query taking Too Much Time

    I have created partition table and Created local partition index on a column whose datatype is DATE.
    Now when I Query table and use index column in the where clause It is scaning all the table (Full scan) . The quey is :
    Select * From mytable
    where to_char(transaction_date, 'DD-MON-YY') = '01-Aug-07';
    I have to use to_char function not to_date due to Front end application problem.

    Before we go too far with this, if you manually query with TO_DATE on the variable instead of TO_CHAR on the column, does the query actually use the index?
    The TO_CHAR on the column will definitely stop Oracle from using any index on the column. If the query will use the index if you TO_DATE the variable, as I see it, you have three options. First, fix the application problem that won't let you use TO_DATE from the application. Second, change the application to call a function returning a ref cursor, get the date string as a parameter to the function, and do the TO_DATE in the function.
    Third, you could consider creating a function-based index on TO_CHAR(transaction_date, 'dd-Mon-yy'). This would be the least desirable option, particularly if you would also be selecting records based on a range of transaction_dates, since it loses a lot of information that the optimizer could use in devising an efficient query plan. It could also change your results for a range scan.
    John

  • Query regarding Partition table Explain plan

    Hello,
    We are amidst a tuning activity, wherein a large table has been partitioned for better administration. During testing, I was analyzing the explain plans for long running sql's and found a piece that I was unable to understand. The PSTART and PSTOP columns show ROWID as its value, which in normal partition pruning scenario be the Partition number or the KEY. I tried to look around for this issue but did not get enough information. Can anybody help me of what it means? Also, if there is a good explanation of the same, it will be extremely helpful.
    The snippet from explain plan looks like:
    | Id  | Operation                                | Name                          | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    7 |        TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXXXXXXXX             | 43874 |  9083K|       |  1386   (1)| 00:00:17 | ROWID | ROWID |
    On another similar query it looks like:
    | Id  | Operation                             | Name                         | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
    |   6 |     TABLE ACCESS BY GLOBAL INDEX ROWID| XXXXXXXXXXXXXX               | 22455 |  4648K|       |   456   (1)| 00:00:06 |     9 |     9 |
    I have another query with regards to the Partition tables. Does it, require/benefit if, the Indexes to be in partitioned mode? I tried to read about it but did not get a conclusive evidence. I am trying to test it and post here the outcome, but if anybody has experience of working with it, it would be great to have some advice.
    Oracle Version:- 10.2.0.4
    Regards,
    Purvesh.

    Hi Purvesh.
    Great explanation and example on this this topic...
    Ask Tom "explain plan on range-partitioned table"
    Hope this help.

  • Query to Partitioned Table

    I have two partition
    upto_mar_2011 , upto_jun_2011
    table_name : order
    1> if I run query as below
    Select * from order where order_date =to_date('23/03/2011','dd/mm/yyyy');
    Oracle will automatically search the data in Partition upto_mar_2011
    or it will search the data in whole table .
    2> Or I have to give query as below
    Select * from order partition (upto_mar_2011) where order_date =to_date('23/03/2011','dd/mm/yyyy');
    Is there any difference between this two query

    OraFighter wrote:
    Is it enough to write as below
    Select * from order where order_date = to_date('23/03/2011','dd/mm/yyyy')
    or order_date = to_date(('23/05/2011','dd/mm/yyyy');
    and CBO will search the data only the partition where it is available.
    Wheather it is span in one or two or three partition
    it will ignore all other partition automaticallyCorrect. It is called partition pruning. This is the approach you should use for application code. Applications should not be concerned with partitioning - should not need to know partition names and other physical attributes of the physical table it is using.
    You can also see partition pruning when looking at the execution plan of such a SQL statement.
    The only code that will deal with partition names and the physical aspects of the table, is maintenance code. For example, you need to maintain a sliding window of 32 days in the date ranged partitioned table. This code needs to determine which partitions are older than 32 days and drop them. And then add new partitions for future processing. This code deals with the physical layer and not the logical layer.
    It is important to keep the two apart and not mix physical stuff into the logical layer that the app is using. Mixing it means that changes to optimise performance and leverage new features cannot be made to the physical layer, as it will break the app layer code.

  • 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 delete the data from partition table

    Hi all,
    Am very new to partition concepts in oracle..
    here my question is how to delete the data from partition table.
    is the below query will work ?
    delete from table1 partition (P_2008_1212)
    we have define range partition ...
    or help me how to delete the data from partition table.
    Thanks
    Sree

    874823 wrote:
    delete from table1 partition (P_2008_1212)This approach is wrong - as Andre pointed, this is not how partition tables should be used.
    Oracle supports different structures for data and indexes. A table can be a hash table or index organised table. It can have B+tree index. It can have bitmap indexes. It can be partitioned. Etc.
    How the table implements its structure is a physical design consideration.
    Application code should only deal with the logical data structure. How that data structure is physically implemented has no bearing on application. Does your application need to know what the indexes are and the names of the indexes,in order to use a table? Obviously not. So why then does your application need to know that the table is partitioned?
    When your application code starts referring directly to physical partitions, it needs to know HOW the table is partitioned. It needs to know WHAT partitions to use. It needs to know the names of the partitions. Etc.
    And why? All this means is increased complexity in application code as this code now needs to know and understand the physical data structure. This app code is now more complex, has more moving parts, will have more bugs, and will be more complex to maintain.
    Oracle can take an app SQL and it can determine (based on the predicates of the SQL), which partitions to use and not use for executing that SQL. All done totally transparently. The app does not need to know that the table is even partitioned.
    This is a crucial concept to understand and get right.

  • Error While Firing select Query  on Table

    Hi aill,
    we have Oracle 11g RG2 RAC on Production Machine. When I am firing select query on one partiton table,it will show me below error in Alter Log file :
    Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x84056AA, kkpamDInfo()+38] [flags: 0x0, count: 1]
    Errors in file /opt/app/oracle/diag/rdbms/winsdb/WINSDB2/trace/WINSDB2_ora_29686.trc (incident=288563):
    ORA-07445: exception encountered: core dump [kkpamDInfo()+38] [SIGSEGV] [ADDR:0x0] [PC:0x84056AA] [Address not mapped to object] []
    Incident details in: /opt/app/oracle/diag/rdbms/winsdb/WINSDB2/incident/incdir_288563/WINSDB2_ora_29686_i288563.trc
    While checking the trace file :
    ========== FRAME [2] (ksedst1()+98 -> skdstdst()) ==========
    defined by frame pointers 0x2ba371efaa40 and 0x2ba371efa990
    CALL TYPE: call ERROR SIGNALED: no COMPONENT: KSE
    RDI 0000000000000000 RSI 0000000000000000 RDX 00002BA371EF6118
    RCX 0000000000000001 R8 0000000000000000 R9 0000000000000000
    RAX 0000000000000000 RBX 0000000000000003 RBP 00002BA371EFAA40
    R10 71EFA9A000000000 R11 0000000000000000 R12 0000000000000003
    R13 0000000000000003 R14 0000000000000001 R15 0000000000000001
    RSP 00002BA371EFA9A0 RIP 000000000349E72E
    Dump of memory from 0x2ba371efaa40 to 0x2ba371efaaf0
    2BA371EFAA40 71EFAB10 00002BA3 0349E77F 00000000 [...q.+....I.....]
    2BA371EFAA50 00000000 00000000 00000000 00000000 [................]
    2BA371EFAA60 71B996F0 00002BA3 02050034 00000000 [...q.+..4.......]
    2BA371EFAA70 000000FF 00002BA3 00002004 00000000 [.....+... ......]
    2BA371EFAA80 00000000 00000000 2338D058 00016DAB [........X.8#.m..]
    2BA371EFAA90 00000003 00000000 085232F3 00000000 [.........2R.....]
    2BA371EFAAA0 0000000D 00000000 00000002 00000000 [................]
    2BA371EFAAB0 00000000 00000000 00000000 00000000 [................]
    2BA371EFAAC0 71EFAAD0 00002BA3 085BBFCF 00000000 [...q.+....[.....]
    2BA371EFAAD0 71EFAB10 00002BA3 0349E249 00000000 [...q.+..I.I.....]
    2BA371EFAAE0 00000000 00002BA3 00000013 00000000 [.....+..........]
    Can Anyone guide me for above Errors. How can I resolve the same.

    A quick search of Oracle Support shows that there are a handful of bugs that match ORA-07445 with an argument of kkpamDInfo()+38.
    Whether yours is already identified and patched depends on the exact version of 11.2 and the specific circumstances.
    If you're on 11.2.0.1 then this might be part of what sounds like quite a big bucket of such errors - Bug 9399991 relating to errors and dumps with SQL against partitioned tables.

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

  • Deadlock issue in Oracle 10g Partitioned Tables

    Hi ALL,
    I am facing an issue of Deadlock while inserting data into a partitioned table.
    I get an error "ORA-00600: Deadlock detected". when i see the trace files, following lines are appearing in them:
    "Single resource deadlock: blocking enqueue which blocks itself".
    Here is the detail of my test case:
    1. I have a list-partitioned table, with partitioning defined on some business codes.
    2. I have a query that merges data into partitioned table (actually compares unique keys between temporary table and partitioned table and then issue an insert if keys not matched, no update part).
    3. The temporary table contains transactional data against many business codes.
    3. when calling the above query from multiple (PL/SQL) sessions, i observe that when we merge data in same partition (from different sessions) than deadlock issue occurs, otherwise it is OK.
    4. Note that all sessions are executed at same time. Also note that Commit is called after each session is completed. Each session contains 2-3 more queries after the mentioned merge statement.
    Is there an issue with oracle merge/insert on same partition (from different sessions)? What is the locking mechanism for this particular case (partitioned tables)?
    My oracle version is Oracle 10g (10.2.0.4). Kindly advice.
    Thanks,
    QQ.

    Could you print the deadlock tree so we can see the type and mode of the locking. (Please use the 'code' tags - see FAQ at top right of screen - to showthe output in fixed font). can you list any SQL operated by this session that gets reported in the trace file.
    Does the table reference itself in a foreign key.
    Is this table involved in any referential integrity constraints.
    Do you have a global primary key index, or a local primary key index ?
    Are there any triggers on the table - if so do they contain autonomous transactions.
    At present the only though that springs to mind is that the merge command has to lock the target table to do the insert/update, but it also has to lock any child table. The mode of the child lock depends on whether it has a suitable index or not, and whether the child table IS also the parent table. If you have two merges to the same partition one partition may get its locks, and the other partition may be in a state where it can't get one of the locks because it's wait for the other. (This shouldn't be a self-deadlock, though, but the scenario might be heading in the right direction for a self-deadlock).
    Regards
    Jonathan Lewis
    http://jonathanlewis.wordpress.com
    http://www.jlcomp.demon.co.uk
    "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." (Stephen Hawking)

  • Extract DDL for Partitioned tables in Oracle 8i

    Hi
    I am currently working on an Oracle 8i database. I have a need to extract the DDL of the existing tables & indexes. Dont need a schema level DDL extract, i just need it for a couple of tables and the corresponding indexes. I am currently using PL/SQL Developer a third party tool which is okay for extracting DDL for Non Partitioned tables, but when it comes to getting the DDL for PARTITIONED tables, it doesnt give me the partition information nor the tablespace information. We dont have a license for Toad or any other tools to get the DDL's. I also dont have the export/import privs on the DB. I need a free ware that can give me the DDL for the existing partitioned tables or atleast a query that I can run against the regular DBA views, which can give me the DDL along with Storage clause, the tablespace, indexes, grants & constraints.
    Thanks in Advance
    Chandra

    I also dont have the export/import privs on the DB. I need a
    free ware that can give me the DDL for the existing
    partitioned tables or atleast a query that I can run
    against the regular DBA views, which can give me the
    DDL along with Storage clause, the tablespace,
    indexes, grants & constraints.But you (or the owner or the tables you connect with) should have export/import privs on its on tables (i.e the two tables). So use the User Views instead of DBA Views.
    USER_TABLES, USER_TAB_PARTITIONS etc

  • How can I find which datafile a row in a huge partitioned table belongs to?

    Hello guys.
    We have a bunch of potentially corrupt LOB data in a 15TB partitioned table. I have run a query to find out what rows may be corrupt. Is it possible to find out if these belong to a common datafile (the are 450 datafiles in this tablespace)?
    Oracle 10.2.0.4 single instance on HP-UX
    Any help appreciated
    Sandy

    The Flaz wrote:
    Hello guys.
    We have a bunch of potentially corrupt LOB data in a 15TB partitioned table. I have run a query to find out what rows may be corrupt. Is it possible to find out if these belong to a common datafile (the are 450 datafiles in this tablespace)?
    Oracle 10.2.0.4 single instance on HP-UX
    Any help appreciated
    SandyTo checking corruption datafile level you can use dbv utility.But to fixing(marking) corruption you have to use dbms_repair package.Please refer below links
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/repair.htm#sthref3170
    http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/repair.htm#sthref3192

  • Analyse a partitioned table with more than 50 million rows

    Hi,
    I have a partitioned table with more than 50 million rows. The last analyse is on 1/25/2007. Do I need to analyse him? (query runs on this table is very slow).
    If I need to analyse him, what is the best way? Use DBMS_STATS and schedule a job?
    Thanks

    A partitioned table has global statistics as well as partition (and subpartition if the table is subpartitioned) statistics. My guess is that you mean to say that the last time that global statistics were gathered was in 2007. Is that guess accurate? Are the partition-level statistics more recent?
    Do any of your queries actually use global statistics? Or would you expect that every query involving this table would specify one or more values for the partitioning key and thus force partition pruning to take place? If all your queries are doing partition pruning, global statistics are irrelevant, so it doesn't matter how old and out of date they are.
    Are you seeing any performance problems that are potentially attributable to stale statistics on this table? If you're not seeing any performance problems, leaving the statistics well enough alone may be the most prudent course of action. Gathering statistics would only have the potential to change query plans. And since the cost of a query plan regressing is orders of magnitude greater than the benefit of a different query performing faster (at least for most queries in most systems), the balance of risks would argue for leaving the stats alone if there is no problem you're trying to solve.
    If your system does actually use global statistics and there are performance problems that you believe are potentially attributable to stale global statistics and your partition level statistics are accurate, you can gather just global statistics on the table probably with a reasonably small sample size. Make sure, though, that you back up your existing statistics just in case a query plan goes south. Ideally, you'd also have a test environment with identical (or nearly identical) data volumes that you could use to verify that gathering statistics doesn't cause any problems.
    Justin

  • Deadlock issue in Partitioned Tables

    Hi ALL,
    I am facing an issue of Deadlock while inserting data into a partitioned table.
    I get an error "ORA-00600: Deadlock detected". when i see the trace files, following lines are appearing in them:
    "Single resource deadlock: blocking enqueue which blocks itself".
    Here is the detail of my test case:
    1. I have a list-partitioned table, with partitioning defined on some business codes.
    2. I have a query that merges data into partitioned table (actually compares unique keys between temporary table and partitioned table and then issue an insert if keys not matched, no update part).
    3. The temporary table contains transactional data against many business codes.
    3. when calling the above query from multiple (PL/SQL) sessions, i observe that when we merge data in same partition (from different sessions) than deadlock issue occurs, otherwise it is OK.
    4. Note that all sessions are executed at same time. Also note that Commit is called after each session is completed. Each session contains 2-3 more queries after the mentioned merge statement.
    Is there an issue with oracle merge/insert on same partition (from different sessions)? What is the locking mechanism for this particular case (partitioned tables)?
    My oracle version is Oracle 10g (10.2.0.4). Kindly advice.
    Thanks,
    QQ.

    Oracle MERGE statements are slow as they must validate every record before insert.
    If you use array processing with BULK COLLECT and FORALL with the SAVE EXCEPTIONS clause you can avoid most of the overhead. Just collect your rows in an array, issue a FORALL INSERT SAVE EXCEPTIONS and let Oracle handle whatever happens.
    When Oracle is done, and it will be hundreds of times faster than what you are doing now, you can either process or ignore the records in the exceptions array.
    Another solution, more efficient if you can do it, is to just to an INSERT INTO SELECT FROM using an exceptions table created with DBMS_ERRLOG.
    www.psoug.org/reference/dbms_errlog.html

  • Partition Tables - issue

    I have lots of partitioned tables in my schema , the requirement is to identify the current partition of the table.
    Let me explain this with an eg.
    Lets say I have a table T , with 24 partitions .. starting for Jan -04 to Dec-05. Now , my current partition is Dec-04. Partition w.r.t sysdate
    How can I achive this by querying the data dictionary

    120196, I think you are mistaken. There is no such thing as "current" partition. Oracle offers 3 types of partition, i.e. range partitioning, hash partitioning and composite partitioning. For all 3 types of partitions, you specify the column you want to partition on. Then, then when you insert/update/delete rows, Oracle does "partition elimination" (if the columns you partitioned is part of the query), which greatly improves performance. So, the partition you deal with (I guess this is what you mean by current partition) is the same one your row has to deal with. Hope this makes it clearer and gives you a 10,000 foot view. There is lots more to partitioning.
    -Raj Suchak
    [email protected]

Maybe you are looking for