Analyze table 10g steps

Hi,
DB: 10.2.0.4 RAC ASM
OS: AIX 5.3L 64-bit
I want to do analyze tables for all users.Please give me the steps for table and schema level.
Thanks & Regards,
Sunand

CJ,
dbms_utility.analyze_schema has been deprecated since 9i- you should be using dbms_stats.
Sunand, by default there will be a gather stats job running on your database picking up any 'stale' statistics, have you disabled it?
If you want/need to run it manually, dbms_stats.gather_database_stats is what you need. Documentation is here http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#i41448
Carl

Similar Messages

  • ORA-00081 & ORA-00600 while analyzing tables in 10g 10.2.0.2

    Did anyone face the below issue while analyzing the tables and table partitions?
    ORA-00081: address range [0x600000000009EC20, 0x600000000009EC24) is not readable
    ORA-00600: internal error code, arguments: [qkaffsindex3], [], [], [], [], [], [], []
    The failing sql is
    'ANALYZE TABLE "SAP<SID>"."/BIC/E100076" PARTITION ("/BIC/E100076142008007") COMPUTE STATISTICS FOR TABLE FOR COLUMNS SIZE 75 "SID_0FISCPER","KEY_
    1000761","KEY_1000762","KEY_1000763","KEY_1000765","KEY_1000766","KEY_1000767","KEY_100076P","KEY_ZXGL_C19T","KEY_ZXGL_C19U" FOR ALL LOCAL INDEX
    ES'
    Oracle version is 10.2.0.2 and OS is HP-UX Itanium ia64 11.23.

    I almost forgot it, anyway:
    Do not use the COMPUTE and ESTIMATE clauses of ANALYZE statement to collect optimizer statistics. These clauses are supported solely for backward compatibility and may be removed in a future release. The DBMS_STATS package collects a broader, more accurate set of statistics, and gathers statistics more efficiently.
    You may continue to use ANALYZE statement to for other purposes not related to optimizer statistics collection:
    To use the VALIDATE or LIST CHAINED ROWS clauses
    To collect information on free list blocks
    Further reference:
    http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14211/stats.htm#i41282
    Adith

  • Analyze table after insert a large number of records?

    For performance purpose, is it a good practice to execute an 'analyze table' command after inserting a large number of a records into a table in Oracle 10g, if there is a complex query following the insert?
    For example:
    Insert into foo ...... //Insert one million records to table foo.
    analyze table foo COMPUTE STATISTICS; //analyze table foo
    select * from foo, bar, car...... //Execute a complex query whithout hints
    //after 1 million records inserted into foo
    Does this strategy help to improve the overall performance?
    Thanks.

    Different execution plans will most frequently occur when the ratio of the number of records in various tables involved in the select has changed tremendously. This happens above all if 'fact' tables are growing and 'lookup' tables stayed constant.
    This is why you shouldn't test an application with a small number of 'fact' records.
    This can happen both with analyze table and dbms_stats.
    The advantage of dbms_stats is, it will export the current statistics to a stats to table, so you can always revert to them using dbms_stats.import_stats.
    You can even overrule individual table and column statistics by artificial values.
    Hth
    Sybrand Bakker
    Senior Oracle DBA

  • ORA-04092 trying to analyze table

    Hi,
    I was trying to analyze some tables issuing:
    analyze table owner.table_name compute statistics;
    Immediately raises the ora-04092, as far as I seen, read, and googled, this ORA error occurs only when someone try to commit inside a trigger, but clearly this is not the case.
    And even in some web applications this error appears.
    This error started to occur after session limit exceeded, doesn't sound related to me, but maybe it can be interesting information.
    Any suggestions please, I'm comfused.
    Regards

    Here more information:
    SQL> select * from v$version;
    BANNER
    Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Prod
    PL/SQL Release 10.2.0.4.0 - Production
    CORE 10.2.0.4.0 Production
    TNS for Linux: Version 10.2.0.4.0 - Production
    NLSRTL Version 10.2.0.4.0 - Production
    SO: RHELAS 5
    And according recomendation, I tryed to use DBMS_STAT, with same results:
    SQL> conn system/*******@siin
    Connected.
    SQL> conn mailedu/*******@siin
    ERROR:
    ORA-04092: cannot COMMIT in a trigger
    ERROR:
    ORA-24315: illegal attribute type
    Warning: You are no longer connected to ORACLE.
    SQL> conn mailedu/********@siin
    ERROR:
    ORA-24315: illegal attribute type
    SQL> conn system/********@siin
    ERROR:
    ORA-24315: illegal attribute type
    Once I restart sqlplusw, and I could connect (just the first connect is successfull) I tryed with dbms_stats:
    SQL> exec dbms_stats.gather_schema_stats ( -
    ownname => 'MAILEDU', -
    options => 'GATHER' );BEGIN dbms_stats.gather_schema_stats ( ownname => 'MAILEDU', options => 'GATHER' ); END;
    ERROR at line 1:
    ORA-04092: cannot COMMIT in a trigger
    ORA-06512: at "SYS.DBMS_STATS", line 14002
    ORA-06512: at "SYS.DBMS_STATS", line 13974
    ORA-06512: at line 1
    Looking further inside the forum I found this thread:
    stupid ora-04092 error message
    In the conversation it is mentioned that according document Link:[7886990|https://metalink.oracle.com/CSP/ui/flash.html#tab=KBHome(page=KBHome&id=()),(page=KBNavigator&id=(bmDocDsrc=Bug&bmDocTitle=AFTER%20OCCURRING%20ORA-18,%20ORACLE%20THROWS%20ORA-4092%20CONTINOUSLY&bmDocID=7886990&viewingMode=1143&from=BOOKMARK&bmDocType=BUG))]
    it can occur after ORA-00018 maximum number of sessions exceeded
    this one is my scenario,
    And...
    Bug No: 6977167
    Filed 16-APR-2008 Updated 19-AUG-2009
    Product Oracle Server - Enterprise Edition Product Version 10.2.0.2
    Platform Linux x86-64 Platform Version rel4
    Database Version 10.2.0.2 Affects Platforms Generic
    Severity Severe Loss of Service Status Development to Q/A
    Base Bug N/A Fixed in Product Version 11.2
    So I would like to mark this as a known bug, but I don't know how to proeced.
    Regards

  • Reindexing versus Analyze Table

    We have a table that has stale statistics in dba_tables. It has a last analyzed date from a few months back and the num_rows is about 38 million records off. I've told the DBA to run ANALYZE TABLE mytable COMPUTE STATISTICS against it. He says they drop and recreate the indexes every Sunday which is the same thing as analyzing the table. Is this true? That doesn't make sense. If that was the case then why are the stats off in dba_tables. The indexes that are dropped and recreated total about 7. Of the 7, one of them has an ANALYZE INDEX statement run against it. I'm just trying to understand why someone would think that reindexing a table is the same as analyzing or gatherings stats on the table. Reindexing I thought updated stats only on the individual indexes, not on the entire table. And Analyzing the table using the statement above updates the stats for the table rows and blocks, not on the indexes. Somebody please explain the difference.

    user1175547 wrote:
    We have a table that has stale statistics in dba_tables. It has a last analyzed date from a few months back and the num_rows is about 38 million records off. I've told the DBA to run ANALYZE TABLE mytable COMPUTE STATISTICS against it. He says they drop and recreate the indexes every Sunday which is the same thing as analyzing the table. Is this true? That doesn't make sense. If that was the case then why are the stats off in dba_tables. The indexes that are dropped and recreated total about 7. Of the 7, one of them has an ANALYZE INDEX statement run against it. I'm just trying to understand why someone would think that reindexing a table is the same as analyzing or gatherings stats on the table. Reindexing I thought updated stats only on the individual indexes, not on the entire table. And Analyzing the table using the statement above updates the stats for the table rows and blocks, not on the indexes. Somebody please explain the difference.Ok, Gather statistics is automatic from 10g. but, it can be turn off by the DBA.
    ANALYZE TABLE my_table COMPUTE STATISTICS is correct and update the table statistics,
    Create index my_index… compute statistics ; is also correct and update the table statistics.
    I don't really know how your database and stats are working , but by default it should be automatic gathered.
    I will show you an example , that maybe help you :)
    Connected to Oracle Database 11g Enterprise Edition Release 11.2.0.1.0
    Connected as SYS
    SQL> create table sales as select * from dba_users where rownum < 4;
    Table created
    SQL> exec dbms_stats.gather_table_stats(null,'sales');
    PL/SQL procedure successfully completed
    SQL>
    SQL> SELECT d.num_rows
      2  FROM Dba_Tables D
      3  WHERE d.table_name = 'SALES'
      4  AND d.owner = 'SYS';
      NUM_ROWS
             3
    SQL> insert into sales select * from dba_users where rownum < 40000;
    36 rows inserted
    SQL> commit;
    Commit complete
    SQL> create index sales_indx on sales (user_id);
    Index created
    SQL>
    SQL> SELECT d.num_rows
      2  FROM Dba_Tables D
      3  WHERE d.table_name = 'SALES'
      4  AND d.owner = 'SYS';
      NUM_ROWS
             3
    SQL> ----statistics are not updated
    SQL> explain plan for select * from sales where user_id = 74;
    Explained
    SQL> @utlxpls
    Error reading file
    SQL> SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 781590677
    | Id  | Operation         | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
    |   0 | SELECT STATEMENT  |       |     1 |    91 |     2   (0)| 00:00:01 |
    |*  1 |  TABLE ACCESS FULL| SALES |     1 |    91 |     2   (0)| 00:00:01 |
    Predicate Information (identified by operation id):
       1 - filter("USER_ID"=74)
    13 rows selected
    SQL> ----Full access because the statistics are not updated
    SQL> exec dbms_stats.gather_table_stats(null,'sales');
    PL/SQL procedure successfully completed
    SQL>
    SQL> SELECT d.num_rows
      2  FROM Dba_Tables D
      3  WHERE d.table_name = 'SALES'
      4  AND d.owner = 'SYS';
      NUM_ROWS
            39
    SQL> explain plan for select * from sales where user_id = 74;
    Explained
    SQL> SELECT * FROM TABLE(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 1381833853
    | Id  | Operation                   | Name       | Rows  | Bytes | Cost (%CPU)|
    |   0 | SELECT STATEMENT            |            |     1 |   111 |     2   (0)|
    |   1 |  TABLE ACCESS BY INDEX ROWID| SALES      |     1 |   111 |     2   (0)|
    |*  2 |   INDEX RANGE SCAN          | SALES_INDX |     1 |       |     1   (0)|
    Predicate Information (identified by operation id):
       2 - access("USER_ID"=74)
    14 rows selected
    SQL> ---now after the stats are updated the index is used
    SQL>

  • Analyze Table required on a Global Temp. Table

    Hi,
    This is the background. We have a Windows reporting Oracle Server where we write stored procedures to access data mainly based off a warehouse residing on a unix box. DBLinks have been setup and synonym's created .
    We create Global Temp. Tables to store temp. data used by our report stored procedures. I have one query that accesses 5 remote tables and one local table
    The query was taking hours to run...after some research i found out that when I did an "Analyze Table" on my Global temp. table, the query came back in a few minutes.
    My confusion is that this table being a GTT.. it will always be empty when we run "Analyze Table" on it. What information is oracle? Do we need to run "analyze table" on all our GTT's created for different reports?
    Second question on show query plan
    Also if I do a query plan on this query ORacle dooes not provide a plan on the remote tables. If i change the query by removing the reference to the local table and hardcoing some vlaues, oralce returns a query plan for the query which now only uses the remote tables. Is this correct?

    Hi,
    you can fake the statistics of the temporary table.
    First create a real table (with indexes) that looks like the temporary table. Load the table with representative data.
    Then
    dbms_stats.gather_table_stats(ownname=>'schemauser',tabname=>'TEMPCOPY');
    dbms_stats.create_stat_table(ownname=>'schemauser',stattab=>'TEMPSTATS');
    dbms_stats.export_table_stats(ownname=>'schemauser',tabname=>'TEMPCOPY',stattab=>'TEMPSTATS'); --do that for every index
    dbms_stats.export_index_stats(ownname=>'schemauser',indname=>'INDEXNAME',stattab=>'TEMPSTATS');Now we import the generated statistics:
    dbms_stats.import_table_stats(ownname=>'schemauser',tabname=>'TEMPTABLE',stattab=>'TEMPSTATS');
    dbms_stats.import_index_stats(ownname=>'schemauser',tabname=>'TEMPTABLE',stattab=>'TEMPSTATS'); --for every indexOf course you can create a set of statistics and load them as needed.
    Dim
    dbms_stats.

  • Analyze table

    Dear all,
    What are the advantages if we do
    analyze table <table name> compute statisticsWhen ever i run this it is computing huge CPU utilization and taking long time........
    if we do this as far as i know
    1)it will analyze the table and count number of rows in a table properly.......
    Is there any advantage for INDEX if we do this operation.
    Regards,
    Vamsi

    Hey,
    Actually this command is old. I think it is 9i and below; It is still there for backwards compatibility.
    Since you are computing the statitics, oracle is going over all the records to get the stats. You can do estimate statics instead.
    OR, even better, you can use the new DBMS_Stats Package:
    EXEC DBMS_STATS.GATHER_TABLE_STATS (ownname=>'SCHEMA_NAME', tabname => 'TABLE_NAME', estimate_percent=>dbms_stats.auto_sample_size, degree=>2);
    This uses DBMS stats package, to estimate the statistics via a sample size automatically set through oracle.
    You can also use a similar command to estimate the stats of the whole schema
    EXEC DBMS_STATS.GATHER_SCHEMA_STATS (ownname=> 'SCHEMA_NAME', estimate_percent=>dbms_stats.auto_sample_size, degree=>2);
    From previous experience, creating an index is not enough, you have to gather the stats on the related table, so that the execution plan gets optimized.
    This command get table stats, histogram, uniqueness.. etc

  • Analyze table in oracle 8.1.6

    Hi,
    I am working in oracle 8.1.6 on unix.the optimizer used here is RBO. I need to analyze a table using the command "analyze table <tablename> compute statistics; but my team mate said that the using anlyze table will degrade the performance.
    how can i analyze a table without affecting the performance?...
    give me an example..
    rgds..

    user537350 wrote:
    hi,
    i did defrag table using the command alter table move tablespace then rebuild the indexes and then analyze the table.
    while doing the analyze of table my teammate said it will degrade the performance?..how can i proceed ..First, I wouldn't just blindly assume I have a problem to be fixed just because "my teammate" said that what I did would degrade performance. Did he have a valid theory to back up his assertion? Why not actually measure performance and see if it degraded?
    BTW, I assume you realize that your vesion of oracle is totally unsupported in this millenium .... which means your organization doesn't value the data in the database.
    Edited by: EdStevens on Aug 12, 2009 10:46 AM

  • Where is the output of analyze table name validate structure cascade

    Hi,
    database version:8.1.7.0.0
    os :solaris 5.9
    since i used to get ORA-00600: INTERNAL ERROR CODE, ARGUMENTS: [25012], [7], [39] and i need to validate the table and this table is very huge(200 gb) where will be the output generated if any error is there in table including indexes.
    sql>analyze table event_t validate structure cascade;
    Regards
    Prakash

    Hello Helios
    sorry ,
    I am using 10.2 and reviewing
    http://docs.oracle.com/cd/B14117_01/server.101/b10759/statements_4005.htm#sthref4205
    my quote is from this document. My question of an ideal case, when there is no block corruption
    regards ,
    Pavel
    Edited by: Pavel on Oct 17, 2012 3:55 AM

  • ORA-20000: Unable to analyze TABLE "ECI"."COUNTRY"

    Oracle9i 9.2.0.7 on Windows Server 2003 32bit
    Using the "ANALYZE" in the Enterrpise Manager Console
    begin
    dbms_stats.gather_table_stats(ownname=>'ECI',tabname=>'COUNTRY',partname=>NULL);
    end;
    ORA-20000: Unable to analyze TABLE "ECI"."COUNTRY", insufficient priviledges or does not exist
    ORA-06512: at "SYS.DBMS_STATS", line 10292
    ORA-06512: at "SYS.DBMS_STATS", line 10315
    ORA-06512: at line 2
    Using SQLPLUS
    SQL>begin
    2>dbms_stats.gather_table_stats(ownname=>'ECI',tabname=>'country',partname=>NULL);
    3>end;
    4>/
    ORA-20000: Unable to analyze TABLE "ECI"."COUNTRY", insufficient priviledges or does not exist
    ORA-06512: at "SYS.DBMS_STATS", line 10292
    ORA-06512: at "SYS.DBMS_STATS", line 10315
    ORA-06512: at line 2
    COMMENT:I noticed here that eventhough I specifically used (tabname=>'country') it still used "ECI"."COUNTRY"(ALL CAPS) in executing my statement
    I also tested on other procedure.
    Using SQLPLUS
    SQL>begin
    2>dbms_redefinition.can_redef_table('ECI','country',dbms_redefinition.cons_use_pk);
    3>end;
    4>/
    BEGIN
    ERROR at line 1:
    ORA-00942: table or view does not exist
    ORA-06512: at "SYS.DBMS_REDEFINITION", line 8
    ORA-06512: at "SYS.DBMS_REDEFINITION", line 247
    ORA-06512: at line 2
    I don't understand why this error happens because
    a) the schema and table exist (I double checked)
    b) the error only happens on a single schema for only the old tables, when I create new tables I could "ANALYZE" it. I also can "ANALYZE" the indexes.
    c)I have used both the sys and system user logging in as SYSDBA
    In the ff exercise, I noticed that "ECI"."productrange" will work but "ECI"."PRODUCTRANGE" won't:
    SQL>select count(*) from "ECI"."productrange";
    COUNT(*)
    8
    SQL>select count(*) from "ECI"."PRODUCTRANGE";
    select count(*) from "ECI"."PRODUCTRANGE"
    ERROR at line 1:
    ora-00942: TABLE OR VIEW DOES NOT EXIST
    Can anyone kindly help me?

    You should not be creating tables in Oracle with names enclosed in double quotes. In that case Oracle preserves the case, making it difficult for others to identify the table.
    Create the table without using double quotes (may be CTAS) and everything should work fine.

  • OWB ORA-2000 unable to analyze table

    During execution I received the error above. In the mapping, I have two targets in two different schema's. I receive the error on the target that is in a different schema than the mapping.
    Is there a workaround? We do not have rights to grant analyze any table to the schema owner of the mapping.

    In OWB select Mapping, context menu Properties -> Code generation options -> Change Analyze table statements to false.
    Bye
    Detlef

  • How to make Form builder 10g step into libraries *.pll while remote debug

    How to make Form builder 10g step into libraries *.pll while remote debug. It attaches fine and goes through code located in form but skips pll's. In this case I am interested in debuging CUSTOM.pll. How to step into pll's and is it possible at all?

    Is the library in the same directory or within your FORMS_PATH? Note that the runtime setting in the default.env doesn't work for the builder.
    cheers

  • Sql slow afterweekly STATS-JOB,then run analyze table it is fast again

    Oracle R11.2.0.2 :
    I hade some slow sql / reports and found the effect,
    that the sql is slow obvious after the weekend ,
    when STATS - JOB BSLN_MAINTAIN_STATS_JOB and other Jobs were running weekly on SYS.
    I did run dbms_stats.GATHER_TABLE_STATS on schema
    it doesn't help.
    But when
    run ANALYZE TABLE afterwards on only one or two tables of the schema
    the sql / reports performance is well and fast.
    in the dba_tables I can see the last_analyze - date
    and in GLOBAL_STATS = NO ( when Table runs with ANALYZE ),
    GLOBAL_STATS = YES( when Table runs with STATS )
    what does the ANALYZE TABLE command doing good and let my sql run well and fast,
    while dbms_stats.GATHER_TABLE_STATS
    seems not work well in this situation ?
    regards

    astramare wrote:
    Oracle R11.2.0.2 :
    I hade some slow sql / reports and found the effect,
    that the sql is slow obvious after the weekend ,
    when STATS - JOB BSLN_MAINTAIN_STATS_JOB and other Jobs were running weekly on SYS.
    I did run dbms_stats.GATHER_TABLE_STATS on schema
    it doesn't help.
    What options do you use for the gather_stats command ?
    Do you also have collected system stats?
    But when
    run ANALYZE TABLE afterwards on only one or two tables of the schema
    the sql / reports performance is well and fast.Analyze table is deprecated, but still does its work for some part. It is not as complete as dbms_stats
    >
    in the dba_tables I can see the last_analyze - date
    and in GLOBAL_STATS = NO ( when Table runs with ANALYZE ),
    GLOBAL_STATS = YES( when Table runs with STATS )
    It must have to do something with the way you use it..
    HTH
    FJFranken

  • Question about Analyze Table

    Hi Guys,
    I am creating an Oracle Job that performs two tasks:
    1.) Delete record from a Table A older than 30 days.
    2.) Perform Analyze Table to the Table A after deleting records.
    The thing that makes me think is that aside from the job I'm creating, there are other jobs/processes that accesses Table A.
    Will there be any problem that may occur once my job performs the Analyze Table to Table A and other jobs/process are also accessing Table A concurrently (e.g. inserting, querying)?
    I'll surely appreciate any idea from you guys!
    Thanks,
    Jay

    Other than the IO load that it causes, the ANALYZE statement has no effect on other sessions while it is running+.
    However, on completion, it will invalidate all SQLs referencing that table. All new invocations of SQLs will need re-parsing and may generate a new Execution Plan, different from those for the same statements before the ANALYZE. Rrunning SQLs already begun will continue running until they complete.
    If you have a job / session / application that frequently queries the table, you might suddenly see a change in execution plan for those queries after the ANALYZE completes.

  • ANALYZE TABLE ... VALIDATE STRUCTURE

    I did ANALYZE TABLE ... VALIDATE STRUCTURE CASCADE. MetaLink says output
    is in trace file in udump location. Well it is not. Does anyone
    know where Oracle does hide this info?

    Oracle is not hiding anything.
    There will be only info when there is something wrong.
    Rather than discussing irrelevant issues like defragmenting tablespaces, rebuilding indices etc,etc why don't you start reading the documentation?
    You seem to have too much time on your hands.
    Sybrand Bakker
    Senior Oracle DBA

Maybe you are looking for