Harvest collection of statistics vs automatic statistics

Similar Questions

• Collection of statistics online

  Hi all
  
  Is it possible to collect statistics for a schema that use sound. When I try to analyse the tables to a diagram, it shows that the statistics for this table are locked. So is it possible that rather than analyze a table, one by one, I can go for gathering statistics for schema objects of this scheme while is still in use (such as DML or select statements issued on these schema objects).
  
  DB version: 10.2.0.4
  Version of the OS: RHEL 5.8
  
  DB type: CARS
  
  
  Kind regards
  Imran Khan

  Imran khan says:
  Hi Mark,

  Why is there a question about the inability to update statistics? Someone has locked the collection of statistics.

  How can we check if statistics collection has been locked? Are you talking about on the level of the db, or for a particular schema or its purpose? As far as I know in oracle 10g statistics are collected automatically (if I have a lot of m).

  Kind regards
  Imran Khan

  Published by: imran khan on December 24, 2012 07:33

  Well, as SB said, just look at the relevant information in the documentation for your version.

  If you don't have local copies of the documentation for your version, you can find copies for recent versions here:

  http://www.Oracle.com/technetwork/indexes/documentation/index.html

  (or docs.oracle.com or tahiti.oracle.com)

  I recommend you watch DBMS_STATS package and the [USER |] ALL THE | S/n] _TAB_STATISTICS view (s).

  Those who should have what you need.

• performance degrades after the collection of statistics

  Oracle 11 g 2 OEL 5
  
  We have several very large tables (40 million lines and more) and recently we gathered stats on tables and it degraded our performance. He began to do table scans complete rather than use the index. The same queries are very well in other environments. Only difference is the collection stats. Logically, the performance should be better after the collection of statistics. But it is rather poor.
  
  I ran track 10053 on request and I see that the cardinality and the cost is medium high in the inefficient environment. A test, I have restored the old stats in the environment and it put everything back to normal - the query runs quickly again. Note that the restored stats were collected for more than a year. Should not collect us statistics regularly on very large tables?
  
  Thank you.

  Hello

  the stats of the default collection behavior is to determine the number of cells (i.e. a histogram is necessary or not and if yes, how accurately must be) automatically, depending on distribution and usage of the column of data in different types of predicates. This means that, in many cases collection histogram is almost a random process - once you get a histogram, the next time that you don't have, even if there is almost no change. This is (unfortunately) the normal behavior.

  I could quite at the bottom of your question - the optimizer esteem seem to be all correct in the second case, it is not clear to me why the plan that is so bad (there are also some other problems, as lines of 40G supposed to be returned by one of the nested loops, or estimation of cardinality missing for another nested loop). But in any case, histograms and bind variables do not mix, so you can just solve your problem by specifying method_opt => "for columns size 1' to disable the histograms for this table.

  Best regards
  Nikolai

• Collection of statistics

  It is said that, in order to allow the CBO work correctly, I need first "collection of statistics. Is this true? If so, no ORACLE "collection of statistics" automatically? or I have to run a package to "gathering statistics?
  
  
  
  Thank you
  
  
  Scott

  scottjhn wrote:
  It is said that, in order to allow the CBO work correctly, I need first "collection of statistics.
  Is this true?

  Yes

  If so, no ORACLE "collection of statistics" automatically? or,

  With V10 + statistics are collected once every 24 hours.

  I have to run a package to "gathering statistics?

  DBMS_STATS can be used manually to collect statistics

• With respect to the analysis and collection of statistics

  Hello

  Why the collection of statistics is necessary in the DB?

  Thank you

  Hello Balmo-Oracle

  You can start reading this document for example: Managing optimizer statistics

  or this: http://www.oracle.com/technetwork/database/bi-datawarehousing/twp-optimizer-stats-concepts-110711-1354477.pdf

  The best way if you check yourself in google.

  Best regards, David

• Collection of statistics takes forever after adding new index - why?

  Hello everyone,

  I'm on Oracle 11.2.0.2. Collection of statistics for one of my paintings takes extremely long (several hours), and I don't know why.

  I'm inserting about 11,000 new records in a table with 5.3 million existing records using a INSERT INTO... SELECT...

  This insert takes a little more than 3 minutes

  Then I collect stats using:

  DBMS_STATS.gather_table_stats ('SCOTT', 'S_RMP_EVALUATION_CSC_MESSAGE', estimate_percent = > DBMS_STATS.) AUTO_SAMPLE_SIZE);

  It takes 2 hours.

  If the number of records increases, the time it takes for the stats increases (8 hours after 70,000 newly inserted records)

  I don't have this problem until recently, I created the I_S_RMP_EVAL_CSC_MSG_ACTIONSindex, but I do not understand why it would cause a radical change like that. Especially since the insertion of records to update the index takes only a few minutes.

  I'm writing the create for the table and the index statements in the table below.

  There are about 5.3 million records in the table. The table uses about 7.8 GB of space for the 'regular' table data and 37.6 GB for the LOB. Use the index:

  Index	Space used
  I_S_EVALUATION_CSC_MSG_LMID:	152 MB
  I_S_EVALUATION_CSC_MSG_IDLM:	144 MB
  PK_S_RMP_EVALUATION_CSC_MESSAG:	118 MB
  I_S_RMP_EVAL_CSC_MSG_ACTIONS:	5 MB

  CREATE TABLE "QQRCSBI0"."S_RMP_EVALUATION_CSC_MESSAGE" 
  ( "ID" NUMBER(22,0) NOT NULL ENABLE, 
    "XML_MESSAGE_TEXT" CLOB, 
    "CREATION_TIME" TIMESTAMP (6), 
    "LAST_UPDATE_TIME" TIMESTAMP (6), 
    "NEXT_UPDATE_SYNC_TS" TIMESTAMP (6), 
    "SW_VERSION_XML" VARCHAR2(100 BYTE), 
    "DWH_LM_TS_UTC" DATE DEFAULT NULL NOT NULL ENABLE, 
    CONSTRAINT "PK_S_RMP_EVALUATION_CSC_MESSAG" PRIMARY KEY ("ID")
    USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS NOLOGGING 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
    TABLESPACE "STAGING"  ENABLE
  ) SEGMENT CREATION IMMEDIATE 
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
  STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "STAGING" 
  LOB ("XML_MESSAGE_TEXT") STORE AS BASICFILE (
    TABLESPACE "STAGING" ENABLE STORAGE IN ROW CHUNK 8192 RETENTION 
    NOCACHE LOGGING 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  ) ;
  
  
  CREATE INDEX "QQRCSBI0"."I_S_EVALUATION_CSC_MSG_IDLM" ON "QQRCSBI0"."S_RMP_EVALUATION_CSC_MESSAGE" ("ID", "DWH_LM_TS_UTC") 
    PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
    TABLESPACE "STAGING" ;
  
  
  CREATE INDEX "QQRCSBI0"."I_S_EVALUATION_CSC_MSG_LMID" ON "QQRCSBI0"."S_RMP_EVALUATION_CSC_MESSAGE" ("DWH_LM_TS_UTC", "ID") 
    PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS NOLOGGING 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
    TABLESPACE "STAGING" ;
  
  
  CREATE BITMAP INDEX "QQRCSBI0"."I_S_RMP_EVAL_CSC_MSG_ACTIONS" ON "QQRCSBI0"."S_RMP_EVALUATION_CSC_MESSAGE" (DECODE(INSTR("XML_MESSAGE_TEXT",'<actions>'),0,0,1)) 
    PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS 
    STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
    PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
    TABLESPACE "STAGING" ;
  

  What causes this extreme long to collect statistics, and what I can do to fix that (apart from the removal of the index again)? Why collect stats lasts much longer than the update data and indexes?

  Thank you...

  It's a VIRTUAL column - Oracle does not store the value of the function in the table for each line, it simply records the description of the decisive function in the column definition in the data dictionary.  The index takes the calculated actual value (with the identifier of the line from each value), but Oracle does not have a mechanism to watch the index when collecting column statistics.  (In fact, such a mechanism could only be created for a single column still index).

  Concerning

  Jonathan Lewis

• Collection of statistics with the cascade option is slow

  Hi all.
  
  The database is 11.2.0.3 on a linux machine.
  
  I published the following command, but the session was a bit slow.
  
  The size of the table is about 50 GB and has 3 clues.
  
  I said 'degree = 8' for parallel processing.
  
  When collecting statistics on the table, parallel slaves have been invoked and gather statistics on the table ended pretty quickly.
  
  However, when he goes to the collection of statistics on indexes, only an active session was invocked and so "level = 8" option is ignored.
  
  My question is:
  
  Do I need to use dbms_stats.gahter_index_stats instead of the option "cascade" in order to gather statistics on indexes with parallelism?
  
  

  exec dbms_stats.gather_table_stats(ownname=>'SDPSTGOUT',tabname=>'OUT_SDP_CONTACT_HIS',estimate_percent=>10, degree=>8 , method_opt=>'FOR ALL COLUMNS SIZE 1',Granularity=>'ALL',cascade=>TRUE);

  Thanks in advance.
  
  Best regards.

  Hello

  This could happen due to the index being created as NOPARALLEL. Try to redefine with DOP = 8 and see if that helps (running a quick test to verify this before making any expensive DDLS).

  Best regards
  Nikolai

• Collect table statistics take longer for large tables

  Version: 11.2
  
  I noticed brings his stats (via dbms_stats.gather_table_stats) takes more time for the large tables.
  
  As number of rows must be calculated, collection of statistics on the table a big would naturally be a little longer (running COUNT (*) SELECT internal).
  But for a table not partitioned with 3 million lines, it took 12 minutes to retrieve the stats? Outside the County info and the row index what other information is collected for the table stats gather?
  
  Size of the Table is actually important for the collection of statistics?

  USER_TABLES DESC

  and also

  USER_IND_STATISTICS
  USER_PART_COL_STATISTICS
  USER_SUBPART_COL_STATISTICS
  USER_TAB_COL_STATISTICS
  USER_TAB_STATISTICS
  USER_TAB_STATS_HISTORY
  USER_USTATS
  USER_TAB_HISTOGRAMS
  USER_PART_HISTOGRAMS
  USER_SUBPART_HISTOGRAMS

• Collection of statistics on partitioned and non-partitioned tables

  Hi all
  My DB is 11.1
  
  I find that the collection of statistics on partitioned tables are really slow.
  

  TABLE_NAME                       NUM_ROWS     BLOCKS SAMPLE_SIZE LAST_ANALYZED PARTITIONED COMPRESSION
  ------------------------------ ---------- ---------- ----------- ------------- ----------- -----------
  O_FCT_BP1                        112123170     843140    11212317 8/30/2011 3:5            NO                    DISABLED
  LEON_123456                      112096060     521984    11209606 8/30/2011 4:2           NO                   ENABLED
  O_FCT                           115170000     486556      115170 8/29/2011 6:3            YES         
  
  SQL> SELECT COUNT(*)  FROM user_tab_subpartitions
    2  WHERE table_name =O_FCT'
    3  ;
  
    COUNT(*)
  ----------
         112

  I used the following script:

  BEGIN
    DBMS_STATS.GATHER_TABLE_STATS(ownname          => user,
                                  tabname          => O_FCT',
                                  method_opt       => 'for all columns size auto',
                                  degree           => 4,
                                  estimate_percent =>10,
                                  granularity      => 'ALL',
                                  cascade          => false);
  END;
  /

  It costs 2 minutes for the first two tables to gather statistics respectively, but more than 10 minutes for the partitioned table.
  Time of collection of statistics represents a large part of the time of the whole lot.
  Most of the work of the lot are at full load, which case all partitions and subpartitions will be affected and we cannot collect just specified partitions.
  
  Does anyone have experiences on this subject? Thank you very much.
  
  Best regards
  Leon
  
  Published by: user12064076 on August 30, 2011 01:45

  Hi Leon

  Why don't collect you statistics to the partition level? If your data partitions will not change after a day (score range date for ex), you can simply do to the partition level

  GRANULARITY-online 'SCORE' for partition level and
  GRANULARITY-online 'SUBPARTITION' for subpartition level

  You collect global stats whenever you can not require.

  Published by: user12035575 on August 30, 2011 01:50

• collection of statistics on a remote table

  Hello
  
  Is it possible and how to collect statistics on remote tables of non-Oracle?
  In my set up an Oracle Server (11g r2) is connected to an Oracle Server remote gateway to Oracle and DB2 server through ODBC gateway. All queries are distributed and heterogeneous, that is, the access data of the two remote servers. The query optimizer uses the real on remote tables from Oracle statistics, while for DB2 tables some default values are used. The difference between the default values and actual statistics is huge.
  I found in a user's guide this column selectivity cannot be collected for tables non-Oracle. Is it possible to collect general statistics such as number of rows from the tables? It would be different if I use DRDA gateway to access DB2?
  
  Concerning

  Ruslan,
  The HS_FDS_SUPPORT_STATISTICS = TRUE parameter is supported using DG4ODBC, even if it is not documented. However, as already said it depends on the ODBC driver and the database non-Oracle to what is returned when set.
  To see if it is used by the pilot, then check track of debug gateway. With the parameter set to true, then you should see explicit SQLStatistics ODBC calls. If these are not present then the parameter is to have no effect. You can also view an ODBC trace for these calls.

  Kind regards
  Mike

• collect system statistics in a CCR environment

  11.2.0.2
  OEL 5, 2 node rac
  
  
  If you gather system statistics it populates the sys.aux_stats$. How does this work on a 2 node rac where you can have 1 with favorite services for oltp and other nodes with a service for favorite batch? I want to get different statistics on the other node to different purposes.
  
  Collect stats system (automatic or manual setting) on a single node affect the other? I remember vaguely a node that said I could change if I need but can't locate it on playback support.

  961469 wrote:
  11.2.0.2
  OEL 5, 2 node rac

  If you gather system statistics it populates the sys.aux_stats$. How does this work on a 2 node rac where you can have 1 with favorite services for oltp and other nodes with a service for favorite batch? I want to get different statistics on the other node to different purposes.

  Collect stats system (automatic or manual setting) on a single node affect the other? I remember vaguely a node that said I could change if I need but can't locate it on playback support.

  There is only one set of statistics the system, visible by all instances. It's what you want, assuming that the nodes are the same. Two instances must this information be correct, regardless of the type of work they perform. I suppose it is theoretically possible to have two nodes with different processors and disk controllers, in which case it could be a problem - is it really you?

• collection of statistics auto disabled during installation of 12 OEM

  During 12 c the Oracle grid control process, it disabled automatic statistics collection. How to activate it? or OEM grid control supposed to be disabled?
  
  How to proceed with the statistics then?
  
  Thank you.

  Date of arrival:
  http://docs.Oracle.com/CD/B28359_01/server.111/b28274/stats.htm#CIHDGIID

• Specifying the user name for the collection of statistics of servers windows performance monitor?

  When using load OATS tests collect statistics of servers Windows (perfmon stats), the load test server runs under the user Id must be a member of the monitoring group of the Performance on all Windows servers, I'm watching. I have a user ID standard I use for this type of surveillance. It is automatically configured on all servers in our company. Where can I specify this user ID and password in OATS load tests?
  
  The only reference I can find in the documentation says to change the user ID and un_mot_de_passe in the Oracle Load Test Agent Serivce. I don't think that's what I want. And there is no installed service named 'Oracle Load Testing Service Agent' on my server in any case.
  
  Thanks for the help!

  Hello Bob
  You should have a service called Service Oracle Application Testing Suite Agent on each server running a load test agent. If this is not the case, there is a problem it somethere and you can't run a load test.
  This is the service you need to run as the specific user (go to control panel-> service-> change the service to log on under your username).

  And tell us the resultl
  See you soon
  JB

• Concept of collection of statistics

  Hi I use Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0 - 64 bit Production.

  We do not want the histogram to be created on the column C1 of table TEST. To do this, I did below

  begin
  dbms_stats.delete_column_stats(
  ownname=>'SCHEMA1', tabname=>'TEST', colname=>'C1', col_stat_type=>'HISTOGRAM');
  END;
  /
  
  BEGIN
  dbms_stats.set_table_prefs('SCHEMA1', 'TEST','METHOD_OPT', 'FOR ALL COLUMNS SIZE AUTO, FOR COLUMNS SIZE 1 C1');
  END;
  /
   
  but then i see this histogram getting override during weekend stats job, which gathers schema statistics, which is as below
  
   BEGIN
     DBMS_STATS.GATHER_SCHEMA_STATS (
        OWNNAME            => 'SCHEMA1',
        ESTIMATE_PERCENT   => DBMS_STATS.AUTO_SAMPLE_SIZE,
        METHOD_OPT         => 'FOR ALL COLUMNS SIZE AUTO',
        GRANULARITY        => 'AUTO',
        CASCADE            => DBMS_STATS.AUTO_CASCADE,
        NO_INVALIDATE      => DBMS_STATS.AUTO_INVALIDATE,
        DEGREE             => 16);
  END;
  /
  
  begin
  dbms_stats.delete_column_stats(
  ownname=>'SCHEMA1', tabname=>'TEST', colname=>'C1', col_stat_type=>'HISTOGRAM');
  END;
  /
  
  BEGIN
  dbms_stats.set_table_prefs('SCHEMA1', 'TEST','METHOD_OPT', 'FOR ALL COLUMNS SIZE AUTO, FOR COLUMNS SIZE 1 C1');
  END;
  /
  but then i see this histogram getting override during weekend stats job, which gathers schema statistics, which is as below
  BEGIN
     DBMS_STATS.GATHER_SCHEMA_STATS (
        OWNNAME            => 'SCHEMA1',
        ESTIMATE_PERCENT   => DBMS_STATS.AUTO_SAMPLE_SIZE,
        --METHOD_OPT         => 'FOR ALL COLUMNS SIZE AUTO',
        GRANULARITY        => 'AUTO',
        CASCADE            => DBMS_STATS.AUTO_CASCADE,
        NO_INVALIDATE      => DBMS_STATS.AUTO_INVALIDATE,
        DEGREE             => 16);
  END;
  /
   
  
  

  But I was under the assumption that the festive preference is picked up, which was wrong. Now to address this scenario, I tested the stats diagram above commenting on the METHOD_OPT parameter and then she won the festive pereference and the histogram has not created as expected. But I'm a bit worried, if commenting on above the METHOD_OPT parameter will have a negative impact on other objects?

  
  Another option that I am thing is to have
  lock the stats so run pattern as usual stats, then unlock the stats and then collect statistics on table as below.

  Start
  DBMS_STATS.lock_table_stats ('XIGNCMN', 'TEST');
  end;

  
  BEGIN
  DBMS_STATS. () GATHER_SCHEMA_STATS
  OWNNAME = > 'SCHEMA1. "
  ESTIMATE_PERCENT = > DBMS_STATS. AUTO_SAMPLE_SIZE,
  METHOD_OPT = > 'FOR ALL COLUMNS SIZE AUTO ',.
  GRANULARITY = > 'AUTO',
  CASCADE = > DBMS_STATS. AUTO_CASCADE,
  NO_INVALIDATE = > DBMS_STATS. AUTO_INVALIDATE,
  DEGREE = > 16);
  END;
  /

  Start
  DBMS_STATS.unlock_table_stats ('SCHEMA1', 'TEST');
  end;

  
  BEGIN
  DBMS_STATS. () GATHER_TABLE_STATS
  OWNNAME = > 'SCHEMA1. "
  TABNAME = > 'TEST ',.
  ESTIMATE_PERCENT = > DBMS_STATS. AUTO_SAMPLE_SIZE,
  METHOD_OPT = > ' FOR ALL COLUMNS SIZE AUTO, FOR COLUMNS SIZE 1 C1. "
  GRANULARITY = > 'AUTO',
  CASCADE = > DBMS_STATS. AUTO_CASCADE,
  NO_INVALIDATE = > DBMS_STATS. AUTO_INVALIDATE,
  DEGREE = > 16);
  END;

  
  So my question is, whether by just commenting that the METHOD_OPT parameter will have a negative impact on other stats of the object,
  or should I go for option-2?

  "METHOD_OPT" parameter with a null value, chooses preferences set to dba_tab_stat_prefs and the tables for which preference is not set, it will choose the default value 'for all cars of column size.

  After the removal of the histogram, so we put the METHOD_OPT as NULL in the stats of scheme together work and it worked according to our condition.

• Clarification on the collection of statistics

  Hello

  My very slow query performns and it contains the tables of partitions and uses parallel and index.

  Last_analysed columns shows that he is 11 - July (2 weeks)

  What statistics to be gathered every day?

  What will be the timeduration?

  S

  Also check the STALE_STATS column in the views of the statistical dictionary (ALL_TAB_STATISTICS, ALL_IND_STATISTICS).

  The optimizer statistics management

  This indicates when there was enough DML operations on the subject to warrant an update of statistics. The auto night stats collection work should give priority to update statistics on these objects.