Query on partitioned table runs indefinitely

Hi,
Customer's Oracle GL implementation has tables GL_BALANCES and GL_JE_LINES partitioned on PERIOD_NAME i.e MON-YY.
Both GL_BALANCES and GL_JE_LINES have LOCAL INDEXES.
For GL_JE_LINES it is (PERIOD_NAME, CODE_COMBINATION_ID)
For GL_BALANCES it is (PERIOD_NAME, CODE_COMBINATION_ID)
We have had more than one occasion is our Production Instance when queries run indefinitely for hours when accessing rows via the above local indexes. We then gather stats using fnd_stats.gather_table_stats for the specific partition e.g. NOV-09 and immediately the queries complete once the stats gathering is in progress.
I am really puzzled how gather stats helps in this case, when the query is already running and from tracing the SQL session shows usage of the LOCAL INDEX.
Any pointers on what Gather Stats is doing would be great.
We do gather stats regularly in our Production Instance.
Also when the SQL query for example against GL_BALANCES for specific period is running for long, I checked the stats and the number of rows in the dba_tab_partitions is not much different from the physical count of records for that period.
Sometimes we have noticed the TEMP space run out say even upto 48 GB.
In one instance we saw huge number of direct path write temp wait events. After gather stats was done, we no more see this wait event. Note we never used SORT or GROUP BY when we saw the above wait event.
Regards,
Prince
Edited by: prc_richard on 10/11/2009 15:16

Presumably the optimizer was choosing a poor execution plan because the statistics (data volumes and distribution) were out of date, and gathering the stats enabled it to make some better decisions and arrive at a better execution plan.
For example, it may have thought the newest partitions were empty (see num_rows in all_tab_partitions) when in fact they had been loaded with millions of rows since you last gathered stats.
Edited by: William Robertson on Nov 11, 2009 12:16 AM

Similar Messages

  • Query on a table runs more than 45mins(after stats) and same query runs 19secs(before stats - rebuild)

    Query on a table runs more than 45mins(after stats) and same query runs 19secs(before stats - rebuild) - Not sure what the cause is.
    - Analysed the explain the plan
    - different explain plan used afterr stats gather.
    Any idea what could be the cause with this kind of difference.
    Thank you!

    What is the difference you see in the explain plan ? Where it spends most time. All these needs to be analysed.

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

  • Timestamp query in partitioned table - can this work?

    Hi,
    I have a table RANGE partitioned by a column named: CREATE_DATE (DATE). Its purpose is to manage the daily create/drop partitions of this table, I do not want to include this column in queries. I do not have an index on this column. We chose DATE for this column because we want to maintain a specific number of days in this table. And when we originally tried to use the STOP_TMSTMP column, TIMESTAMP proved to be unusable for RANGE partitioning.
    There are two other Timestamp columns that ARE used for precise transaction time calculation (STOP_TMSTMP - START_TMSTMP), and included within queries.
    I have an index on the STOP/START_TMSTMP but it is not getting used. And a table scan is occurring. So, finally my main question: How can I make the STOP_TIMESTAMP column index be used in queries against this table? And Is the CREATE_DATE required in a query, or can I safely ignore this column?
    Thanks,
    Mike

    Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
    PL/SQL Release 10.2.0.3.0 - Production
    "CORE     10.2.0.3.0     Production"
    TNS for Solaris: Version 10.2.0.3.0 - Production
    NLSRTL Version 10.2.0.3.0 - Production
    Example query:
    select count(*)
    from flow_completion_record
    where stop_timestamp > '03-MAY-10 12.00.01.000000 AM'
    Takes 370 seconds and returns 2.7 million rows.
    Are you smarter than Oracle's optimizer?I will answer this rhetorical question with another question: does anyone really know what the optimizer will do? Or are you just best-guessing?
    Back to the original question: If I use the CREATE_DATE column to RANGE PARTITION this table, can I ignore it for queries in this table when it comes to TIMESTAMP?
    I really want to treat CREATE_DATE like I would an ID primary key column. Its value is set but I do not use it for queries.
    Thanks

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

  • 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

  • Querying a partition performance.

    Hi Oracle Gurus,
    I had a small question. I was thinking which one of the 2 techniques will give me a better performance.
    1). Querying a table and using partition name in the from clause like
    select count(*) from table_name partition (partition_name);
    The partition in on the business_date for that table.
    2). Querying a partitioned table with a where condition (here the column in the where condition is partitioned for date).
    select count(*) from table_name where table_name.business_date='1-Dec-2009'
    Please let me know if you need any clarification.

    The performance difference is not at all related to the data volume. It is solely related to the cost of parsing the query. If anything, the static SQL solution will be more efficient in a production environment.
    - If you are using static SQL, Oracle only has to parse the SQL statement once and you can pass in whatever bind values you'd like. If you are using dynamic SQL, Oracle has to parse every SQL statement separately which means generating a brand new query plan (if you repeat the query for the same date, you'd probably only need a soft parse). Generating a query plan takes some time (on the order of tenths of a second probably) in addition to requiring various latches on the shared pool. Those tenths of a second will dwarf whatever potential benefit you get in not having Oracle prune partitions. Plus, you're increasing serialization, pressure on the shared pool, etc.
    - Even beyond that, I find it extremely unlikely that your code could determine the partition to use more quickly than Oracle could. Even if it is a simple algorithm to convert the date into a partition name, that's not appreciably more work than Oracle will have to figure out what partition the date value would be in. And Oracle's lookup is happening in highly optimized and compiled kernel code-- your application is likely using a higher level language with less optimized code. At best, if you've got hundreds of thousands of partitions, it's probably a wash.
    Justin

  • Run a query on linked tables to create a new datasource

    Using Crystal XI
    I have a report that draws from two data sources.  They can't be joined at the server side, but they are linked in Crystal Database Expert. 
    I can't figure out if Crystal gives me a way to write an SQL Query to run an aggregate function referencing both tables.  The results of this query would be the datasource for a graph in the report.  I'm wondering if Crystal gives me a way, maybe through subreports, to write the query I need.
    More concretely:
    And I want to include in my datasource alarmId, Hour and the Maximum amount of calls received in any one hour for any one station (this maximum is to provide scale for a graph)
    In one table nameed AlarmStartTimes I have data like
    Alarms
    AlarmID  Hour    Recipient
    Alarm1       8       Joe
    Alarm23  10      Mark
    Alarm60  7      Joe
    Alarm95  8      Linda
    In another I have data like
    EELocation
    Recipient   Location
    Joe         Station1
    Mark         Station2
    Linda          Station1
    So if I could just join my talbes at the server side I'd use a query like:
    select *, max(select count(AlarmID) from Alarms, EELocation from Alarms Join EELocationo on Alarms.Recipient=EELocation.Recipient group by Hour, Location) AS  from Alarms
    Anyway, that's probably got a syntax error or 4 in it, but you get the idea.
    I can't group on the database side.  Since Crystal is able to link the two tables and successfully group them out by Location, it seems like there should be some way for me to run a query against the tables reflecting that existing link, but I can't see how to do it.
    The reason I can't link on database side is that the data is in two databases, and it's not known what the location of the databases is at report-writing time.  The location of the databases gets set via the Crystal API when the report is launched from an application.

    Since you have 2 datasource in the report you are limited on what you can use in crystal, such as crystal will not allow you to use sql expressions.

  • 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 Needed for Partitioning table

    Hi,
    I have created a table called Test. There is a column named business_name.
    There are several businesses like ABC,BCD,ADE....
    There will be lakhs of rows corresponding to each business, i mean there will be lakhs of entires corresponding to ABC,BCD....
    So i like to partition the table according to business_name so that the search will be more faster.As we had partitioned according to the business_name, i hope we need to search only on the partition corresponding to the particular business.
    can any one provide the Query to partition the table ' TEST ' according to the column ' business_name ' .
    Also can anyone provide Query to modify the already existing table ' TEST ' to incorporate partition for the column ' business_name '.

    We can partiton a table by the following
    create table Generalledger (
         record_id     number,
         business_name     varchar2(3)
         sales_dt     date,
         amount     number(10)
    partition by list (business_name)
    partition ct values ('ABC'),
    partition ca values ('BCD'),
    partition def values (default)
    But if we dont know the values like 'ABC' , 'BCD'
    ....how can we do the partitionuse SQL to generate part (or all) of your DDL statement. The following will output one partition statement for each business_name:
    SELECT DISTINCT 'partition p_' || BUSINESS_NAME || ' values (''' ||
                     BUSINESS_NAME || '''),'
    FROM GENERALLEDGER;

  • Query for inserting into dynamic partitioned table

    i want to insert into a table which is partitioned (partition name will be obtained dynamically) based on some select statement using execute immediate statement can some one help with query

    First u create table with partition.when u will insert record it will automatically enter in right partition in dynamically.
    and when u will select that record give SELECT query with partition
    Ex:
    SELECT * FROM table_name PARTITION(partition name);

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

  • 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

Maybe you are looking for