Gathering without histogram statistics

Similar Questions

• 10.2.0.4 behavior of CBO without histograms and lie / literals

  Hello
  I have a question about the CBO and collected LOW_VALUE and HIGH_VALUE statistics values. I saw the following on a database of oracle 10.2.0.4.
  CBO decides a different execution plan, if we use the bind variable (without bind peeking) or literals - no histograms do exist on the columns of the table.
  Unfortunately I have no export statistics to reproduce this behavior on my test database, but it was 'something' like that.
  
  Environment:
  -Oracle 10 g 10.2.0.4
  -Bind peeking disabled (_optim_peek_user_binds = FALSE)
  -No histograms
  -No partitioned table/index
  
  The table (TAB) has 2 indexes on it:
  -An index (INDEX A1) included the date (which was a NUMBER column) and the values in the columns of this spread of 0 (LOW_VALUE) up to 99991231000000 (HIGH_VALUE).
  -An index (INDEX A2) included the number that has been very selective (separate keys almost the same num lines)
  
  The query now looks like this:

  SELECT * FROM TAB WHERE DATE BETWEEN :DATE1 AND :DATE2 AND ARTICLENR = :ARTNR;

  And calculated the CBO, the best execution plan would be a scan interval index on two indexes and perform a btree-to-bitmap conversion... compare the row ID returned the two indexes and then access the table TAB with that.
  What the CBO didn't know not (because of the handicapped stealthily) was, that the user has entered (= 0) of DATE1 and DATE2 (= 99991231000000)... so the access index index A1 makes no sense.
  
  Now, I run the query with literals just to DATE... so the query looks like this:

  SELECT * FROM TAB WHERE DATE BETWEEN 0 AND 99991231000000 AND ARTICLENR = :ARTNR;

  And then the CBO has made the right choice... just accessing index A2 which was very selective, then acceesed table TAB by ROWID.
  The query has been much faster (factor 4-5) and the user was happy.
  
  As I already mentioned, there is no historgrams that I was very surprised, the execution plan changed due to the use of literals.
  
  Anyone know what the CBO includes HIGH_VALUE and LOW_VALUE values in its calcuation of execution plan?
  So far, I thought that these values will be used only in the case of histograms.
  
  Thanks and greetings

  oraS-

  It's in the Oracle cost-based book Fundamentals of Jonathan:

  Page 51/52-

  Case No. 14:

  "month_no between: b1 and: b2.

  «The optimizer simply defines the selectivity to 0.25% (which is in fact 5% of 5%).» {} quote}

  That's what I said in my post above. The literal form of selectivity is box 5 on page 53.

  HTH!

• For data asymmetric distributions, should I believe the man of histogram statistics

  For data asymmetric distributions, can I collect statistics of the histogram manually in 11g?

  If you set the value of this argument for all COLUMNS SIZE AUTO, the optimizer will gather statistics about all groups of existing columns and angled columns.
  Histograms are specified using the argument of the DBMS_STATS METHOD_OPT collection procedures. Oracle recommends affecting the METHOD_OPT for all COLUMNS SIZE AUTO. With this setting, Oracle automatically determines which columns require histograms and the number of compartments (size) of each histogram.
  But for group arotmatically running column statistics, you must specify the new group using COLUMNS. The column group is automatically created as part of the collection of statistics.

• Gathering table only statistics with DBMS_SCHEDULER

  Version: 10 gr 2
  
  I have statistics sql file called gather_emp_stats.sql whose content is as follows
  

  begin
  dbms_stats.gather_table_stats('SCOTT', 'EMP',
  estimate_percent=>100,
  no_invalidate=>FALSE,
  degree => DBMS_STATS.DEFAULT_DEGREE,
  cascade=>TRUE);
  end;

  How can I run the .sql above script every five minutes using DBMS_SCHEDULER?

  begin
    dbms_scheduler.create_job(
        job_name => 'gather_emp_statistics'
       ,job_type => 'PLSQL_BLOCK'
       ,job_action => '??----??'
       ,start_date => sysdate
       ,repeat_interval => 'FREQ=MINUTELY;INTERVAL=5'
       ,enabled => TRUE
       ,comments => 'Gathering stats for EMP table.');
  end;
  /

  If you do not insist to use a file (I believe that Planner can make files too, but I do not currently know the syntax).

  Simply put the command in a single line and use it as a parameter

  begin
    dbms_scheduler.create_job(
        job_name => 'gather_emp_statistics'
       ,job_type => 'PLSQL_BLOCK'
       ,job_action => 'dbms_stats.gather_table_stats(''SCOTT'', ''EMP'',  estimate_percent=>100, no_invalidate=>FALSE, degree => DBMS_STATS.DEFAULT_DEGREE, cascade=>TRUE);'
       ,start_date => sysdate
       ,repeat_interval => 'FREQ=MINUTELY;INTERVAL=5'
       ,enabled => TRUE
       ,comments => 'Gathering stats for EMP table.');
  end;
  /
  

• Weird question on implementation with the paragraph plan

  OS: CentOS 5

  Oracle 10.2.0.1

  We are facing a weird problem.

  The table is as

  create table A)

  key elementary/ID varchar2 (200)

  ...

  )

  ID's value is a bit special, because it starts by ' * ' (asterisk), and his motive is ' *' + 'onestring' + 'uuid '.

  We have a query clause IN with 20 arguments such as:

  Select * from where id in)

  '* line_item.name.uuid1...',

  '* line_item.name.uuid2...',

  '* line_item.name.uuid3...',

  '* line_item.name.uuid4...',

  '* line_item.name.uuid5...',

  '* line_item.name.uuid6...',

  '* line_item.name.uuid7...',

  '* line_item.name.uuid8...',

  '* line_item.name.uuid9...',

  '* line_item.name.uuid10...',

  '* line_item.name.uuid11...',

  ....

  )

  Number of rows in the table is of 30 M, and the number of rows in the primary key index is also 30 M.

  Select user_indexes index_name, blevel, num_rows where table_name = "A";

  
  

  20 is a lot less than 30 M, but the execution of Oracle for this query plan is full table to a table scan.

  I try to remove the ' *' in the id, then the plan execution is range limited index scan and then obtain registration of the line id. I think it should work this way.

  Is ' *' a special character in Oracle 10 g?

  Hi Nesta,

  It's an interesting test case - behold, I get:

  create table t

  as

  Select 'testtesttesttesttesttesttesttesttesttest ' | rownum id

  , mod (rownum, 16) col2

  , lpad ('* ', 50,' *') padding

  of the double

  connect by level<=>

  ALTER table t add constraint primary key t_pk (id, col2);

  exec dbms_stats.gather_table_stats (user, 't')

  explain plan for

  Select *.

  t

  where id in ("testtesttesttesttest1"

  , "testtesttesttesttest2".

  , "testtesttesttesttest3".

  , "testtesttesttesttest4".

  , "testtesttesttesttest5".

  , "testtesttesttesttest6".

  , "testtesttesttesttest7".

  , "testtesttesttesttest8".

  , "testtesttesttesttest9".

  , "testtesttesttesttest10".

  , "testtesttesttesttest11".

  , "testtesttesttesttest12".

  , "testtesttesttesttest13".

  , "testtesttesttesttest14".

  , "testtesttesttesttest15".

  , "testtesttesttesttest16".

  , "testtesttesttesttest17".

  , "testtesttesttesttest18".

  , "testtesttesttesttest19".

  , "testtesttesttesttest20".

  );

  -------------------------------------------------------------------------------------

  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

  -------------------------------------------------------------------------------------

  |   0 | SELECT STATEMENT |      |    20.  2020 |    27 (0) | 00:00:01 |

  |   1.  INLIST ITERATOR.      |       |       |            |          |

  |   2.   TABLE ACCESS BY INDEX ROWID | T    |    20.  2020 |    27 (0) | 00:00:01 |

  |*  3 |    INDEX RANGE SCAN | T_PK |    20.       |    22 (0) | 00:00:01 |

  -------------------------------------------------------------------------------------

  --> still a scan interval index with cardinality 20

  exec dbms_stats.delete_column_stats (user, ', 'ID')

  -------------------------------------------------------------------------------------

  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

  -------------------------------------------------------------------------------------

  |   0 | SELECT STATEMENT |      | 10000 |   937K |   851 (0) | 00:00:05 |

  |   1.  INLIST ITERATOR.      |       |       |            |          |

  |   2.   TABLE ACCESS BY INDEX ROWID | T    | 10000 |   937K |   851 (0) | 00:00:05 |

  |*  3 |    INDEX RANGE SCAN | T_PK |  4000 |       |    42 (0) | 00:00:01 |

  -------------------------------------------------------------------------------------

  Information of predicates (identified by the operation identity card):

  ---------------------------------------------------

  3 - access ("ID" = 'ID"= 'testtesttesttesttest10' OR'testtesttesttesttest1 '

  OR 'ID' = 'testtesttesttesttest11' OR 'ID' = 'testtesttesttesttest12' OR

  'ID' = 'testtesttesttesttest13' OR 'ID' = 'testtesttesttesttest14' OR

  'ID' = 'testtesttesttesttest15' OR 'ID' = 'testtesttesttesttest16' OR

  'ID' = 'testtesttesttesttest17' OR 'ID' = 'testtesttesttesttest18' OR

  'ID' = 'testtesttesttesttest19' OR 'ID' = 'testtesttesttesttest2' OR

  'ID' = 'testtesttesttesttest20' OR 'ID' = 'testtesttesttesttest3' OR

  'ID' = 'testtesttesttesttest4' OR 'ID' = 'testtesttesttesttest5' OR

  'ID' = 'testtesttesttesttest6' OR 'ID' = 'testtesttesttesttest7' OR

  'ID' = 'testtesttesttesttest8' OR 'ID' = "testtesttesttesttest9")

  --> now, we see le.004 factor in the calculation of the cardinality

  exec dbms_stats.gather_table_stats (user, 't', method_opt => "for IDs of the columns");

  exec dbms_stats.gather_table_stats (user, 't', method_opt => "for the column col2");

  --------------------------------------------------------------------------

  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

  --------------------------------------------------------------------------

  |   0 | SELECT STATEMENT |      |  1000K |    96 M |  7435 (0) | 00:00:38 |

  |*  1 |  TABLE ACCESS FULL | T    |  1000K |    96 M |  7435 (0) | 00:00:38 |

  --------------------------------------------------------------------------

  --> After having re-creating column statistics I now also get the full table scan

  What happens here? A look at column statistics the case becomes a little clearer:

  Select column_name

  num_distinct

  Histogram

  num_buckets

  sample_size

  of user_tab_cols

  where table_name = 't'

  COLUMN_NAME NUM_DISTINCT HISTOGRAM SAMPLE_SIZE NUM_BUCKETS

  ------------------------------ ------------ --------------- ----------- -----------

  ID 988992 1 5616 FREQUENCY

  COL2 FREQUENCY 16 16 5472

  1. NO 1000000 1 PADDING

  Select column_name

  endpoint_number

  endpoint_value

  of user_tab_histograms

  where table_name = 't';

  COLUMN_NAME ENDPOINT_NUMBER ENDPOINT_VALUE

  ------------------------------ --------------- --------------

  ID 5616 6, 0436E + 35

  COL2                                       334              0

  COL2                                       681              1

  COL2                                      1008              2

  COL2                                      1345              3

  COL2                                      1717              4

  COL2                                      2039              5

  COL2                                      2388              6

  COL2                                      2734              7

  COL2                                      3089              8

  COL2                                      3440              9

  COL2                                      3797             10

  COL2                                      4132             11

  COL2                                      4473             12

  COL2                                      4790             13

  COL2                                      5128             14

  COL2                                      5472             15

  PADDING 0 2, 1893RD + 35

  FILLING 1 2, 1893RD + 35

  So we now have histograms of frequency for the two columns (created with a small sample of ~ 5500 lines - but this isn't the problem here): a histogram of the frequency must contain a bucket for each distinct value - but we have distinct values of 1 M and only a bucket. Of course, the CBO is not able to see the difference in values due to the great prefix. With histgrams the calculation of costs is another, and when he sees that a single bucket the optimizer would decide that such access does not bring a lot of selectivity.

  So I'll be back to my initial index access when I recreate the column without histograms statistics:

  exec dbms_stats.gather_table_stats (user, ' t ', method_opt => ' ID columns size 1');

  exec dbms_stats.gather_table_stats (user, ' t ', method_opt => "for the column col2 size 1');

  In his blog, Jonathan Lewis wrote: "If you have fairly similar, and long strings in a column that is a good candidate for a histogram of the frequency (for example a very descriptive status column) then you have a problem, if a value which is very rare looks identical to a very popular value until the first 32 characters." http://jonathanlewis.wordpress.com/2010/10/13/frequency-histogram-5/ - and also says that the situation is changed to 12 c, but that's a different story.

  Concerning

  Martin

• How oracle decide whetehr to use the index or full analysis (statistics)

  Hi guys,.
  
  Let's say I have an index on a column.
  Tables and index statistics were collected. (without the histograms).
  
  Let's say I have run a select * from table where a = 5;
  Oracle will perform a complete analysis.
  But what statistics, it will be able to know indeed the greater part of the column = 5? (histograms do not used)
  
  After analysis, we get the following:
  Statistical table:
  (NUM_ROWS)
  (BLOCKS)
  (EMPTY_BLOCKS)
  (AVG_SPACE)
  (CHAIN_COUNT)
  (AVG_ROW_LEN)
  
  Index statistics:
  (BLEVEL)
  (LEAF_BLOCKS)
  (DISTINCT_KEYS)
  (AVG_LEAF_BLOCKS_PER_KEY)
  (AVG_DATA_BLOCKS_PER_KEY)
  (CLUSTERING_FACTOR)
  
  Thank you
  
  
  
  
  
  Index of column (A)
  ======
  1
  1
  2
  2
  5
  5
  5
  5
  5
  5

  I have prepared a few explanations and did not notice that the topic has been marked as answer.

  My sentence is not quite true.

  A column "without histograms' means that the column has only a bucket.

  More correct: even without the histogram there are data in dba_tab_histograms which can be considered a bucket for the whole column. In fact, these data are extracted from hist_head$, not from $ histgrm as usual buckets.
  Technically there are no buckets without combined histograms.

  Let's create a table with the asymmetric data distribution.

  SQL> create table t as
    2  select least(rownum,3) as val, '*' as pad
    3    from dual
    4  connect by level <= 1000000;
  
  Table created
  
  SQL> create index idx on t(val);
  
  Index created
  
  SQL> select val, count(*)
    2    from t
    3   group by val;
  
         VAL   COUNT(*)
  ---------- ----------
           1          1
           2          1
           3     999998
  

  So, we have table with the very uneven distribution of the data.
  We collect statistics without histograms.

  SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for all columns size 1', cascade => true);
  
  PL/SQL procedure successfully completed
  
  SQL> select blocks, num_rows  from dba_tab_statistics
    2   where table_name = 'T';
  
      BLOCKS   NUM_ROWS
  ---------- ----------
        3106    1000000
  
  SQL> select blevel, leaf_blocks, clustering_factor
    2    from dba_ind_statistics t
    3   where table_name = 'T'
    4     and index_name = 'IDX';
  
      BLEVEL LEAF_BLOCKS CLUSTERING_FACTOR
  ---------- ----------- -----------------
           2        4017              3107
  
  SQL> select column_name,
    2         num_distinct,
    3         density,
    4         num_nulls,
    5         low_value,
    6         high_value
    7    from dba_tab_col_statistics
    8   where table_name = 'T'
    9     and column_name = 'VAL';
  
  COLUMN_NAME  NUM_DISTINCT    DENSITY  NUM_NULLS      LOW_VALUE      HIGH_VALUE
  ------------ ------------ ---------- ---------- -------------- ---------------
  VAL                     3 0,33333333          0           C102            C104
  

  Therefore, Oracle suggests that the values between 1 and 3 (raw C102 C104) are distributed uniform and the density of the distribution is 0.33.
  We will try to explain the plan

  SQL> explain plan for
    2  select --+ no_cpu_costing
    3         *
    4    from t
    5   where val = 1
    6  ;
  
  Explained
  
  SQL> @plan
  
  --------------------------------------------------
  | Id  | Operation         | Name | Rows  | Cost  |
  --------------------------------------------------
  |   0 | SELECT STATEMENT  |      |   333K|   300 |
  |*  1 |  TABLE ACCESS FULL| T    |   333K|   300 |
  --------------------------------------------------
  Predicate Information (identified by operation id):
  ---------------------------------------------------
     1 - filter("VAL"=1)
  Note
  -----
     - cpu costing is off (consider enabling it)
  

  An excerpt from trace 10053

  BASE STATISTICAL INFORMATION
  ***********************
  Table Stats::
    Table:  T  Alias:  T
      #Rows: 1000000  #Blks:  3106  AvgRowLen:  5.00
  Index Stats::
    Index: IDX  Col#: 1
      LVLS: 2  #LB: 4017  #DK: 3  LB/K: 1339.00  DB/K: 1035.00  CLUF: 3107.00
  ***************************************
  SINGLE TABLE ACCESS PATH
    -----------------------------------------
    BEGIN Single Table Cardinality Estimation
    -----------------------------------------
    Column (#1): VAL(NUMBER)
      AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 0.33333 Min: 1 Max: 3
    Table:  T  Alias: T
      Card: Original: 1000000  Rounded: 333333  Computed: 333333.33  Non Adjusted: 333333.33
    -----------------------------------------
    END   Single Table Cardinality Estimation
    -----------------------------------------
    Access Path: TableScan
      Cost:  300.00  Resp: 300.00  Degree: 0
        Cost_io: 300.00  Cost_cpu: 0
        Resp_io: 300.00  Resp_cpu: 0
    Access Path: index (AllEqRange)
      Index: IDX
      resc_io: 2377.00  resc_cpu: 0
      ix_sel: 0.33333  ix_sel_with_filters: 0.33333
      Cost: 2377.00  Resp: 2377.00  Degree: 1
    Best:: AccessPath: TableScan
           Cost: 300.00  Degree: 1  Resp: 300.00  Card: 333333.33  Bytes: 0
  

  FTS here costs 300 and Index Range Scan here costs 2377.
  I disabled cpu cost, so the selectivity does not affect the cost of FTS.
  cost of the Index Range Scan is calculated as
  blevel + (leaf_blocks * selectivity + clustering_factor * selecivity) = 2 + (4017 * 0.33333 + 3107 * 0.33333) = 2377.
  Oracle believes that he must read 2 blocks root/branch index, 1339 the index leaf blocks and 1036 blocks in the table.
  Pay attention that the selectivity is the main component of the cost of the Index Range Scan.

  We will try to collect histograms:

  SQL> exec dbms_stats.gather_table_stats( user, 'T', estimate_percent => 100, method_opt => 'for columns val size 3', cascade => true);
  
  PL/SQL procedure successfully completed
  

  If you look at dba_tab_histograms you can see more

  SQL> select endpoint_value,
    2         endpoint_number
    3    from dba_tab_histograms
    4   where table_name = 'T'
    5     and column_name = 'VAL'
    6  ;
  
  ENDPOINT_VALUE ENDPOINT_NUMBER
  -------------- ---------------
               1               1
               2               2
               3         1000000
  

  ENDPOINT_VALUE is the value of the column (in number for any type of data) and ENDPOINT_NUMBER is the cumulative number of lines.
  Number of lines for any ENDPOINT_VALUE = ENDPOINT_NUMBER for this ENDPOINT_VALUE - ENDPOINT_NUMBER to the previous ENDPOINT_VALUE.

  explain the plan and track 10053 the same query:

  ------------------------------------------------------------
  | Id  | Operation                   | Name | Rows  | Cost  |
  ------------------------------------------------------------
  |   0 | SELECT STATEMENT            |      |     1 |     4 |
  |   1 |  TABLE ACCESS BY INDEX ROWID| T    |     1 |     4 |
  |*  2 |   INDEX RANGE SCAN          | IDX  |     1 |     3 |
  ------------------------------------------------------------
  Predicate Information (identified by operation id):
  ---------------------------------------------------
     2 - access("VAL"=1)
  Note
  -----
     - cpu costing is off (consider enabling it)
  

  ***************************************
  BASE STATISTICAL INFORMATION
  ***********************
  Table Stats::
    Table:  T  Alias:  T
      #Rows: 1000000  #Blks:  3106  AvgRowLen:  5.00
  Index Stats::
    Index: IDX  Col#: 1
      LVLS: 2  #LB: 4017  #DK: 3  LB/K: 1339.00  DB/K: 1035.00  CLUF: 3107.00
  ***************************************
  SINGLE TABLE ACCESS PATH
    -----------------------------------------
    BEGIN Single Table Cardinality Estimation
    -----------------------------------------
    Column (#1): VAL(NUMBER)
      AvgLen: 3.00 NDV: 3 Nulls: 0 Density: 5.0000e-07 Min: 1 Max: 3
      Histogram: Freq  #Bkts: 3  UncompBkts: 1000000  EndPtVals: 3
    Table:  T  Alias: T
      Card: Original: 1000000  Rounded: 1  Computed: 1.00  Non Adjusted: 1.00
    -----------------------------------------
    END   Single Table Cardinality Estimation
    -----------------------------------------
    Access Path: TableScan
      Cost:  300.00  Resp: 300.00  Degree: 0
        Cost_io: 300.00  Cost_cpu: 0
        Resp_io: 300.00  Resp_cpu: 0
    Access Path: index (AllEqRange)
      Index: IDX
      resc_io: 4.00  resc_cpu: 0
      ix_sel: 1.0000e-06  ix_sel_with_filters: 1.0000e-06
      Cost: 4.00  Resp: 4.00  Degree: 1
    Best:: AccessPath: IndexRange  Index: IDX
           Cost: 4.00  Degree: 1  Resp: 4.00  Card: 1.00  Bytes: 0
  

  Be careful on selectivity, ix_sel: 1.0000e - 06
  Cost of the FTS is always the same = 300,
  but the cost of the Index Range Scan is now 4: 2 blocks from root/branch + block 1 sheet + 1 table blocks.

  So, conclusion: histograms to calculate more accurate selectivity. The goal is to have more efficient execution plans.

  Alexander Anokhin
  http://alexanderanokhin.WordPress.com/

• columns size auto or 1

  Hello

  We use auto size 0 columns in our stored procedure to collect statistics.

  Please let me know if there is an advantage of the use of column size 1 auto or auto size 0 to collect statistics.

  Kind regards

  VN

  If you gather statistics with SIZE 0 COLUMN and your question is what benefit if change us to 1 so my answer is

  I can't find any documentation on the value of 0->, so I don't know how oracle works with this value.

  What I know is that if you set this value to 1, then do you disable the collection of statistics of the histogram.

  But my assumption is that 0 means 1-> so there is no change-> but it's my hypothesis.

  -> Histogram statistics gathering are good or not good, it's a matter of adjustment. It depends!

• Invisible indexes

  Oracle DB 11g Enterprise Edition

  Release 11.2.0.3.0 - 64 bit

  People,

  We have a job for which we created invisible indexes. We use the ALTER SESSION SET OPTIMIZER_USE_INVISIBLE_INDEXES = TRUE;  Howerver our work always straightens not indexes.

  The work is performed as a flexible people process. Other session controls, we have tried in the past and they worked very well. Other than the use / * + index (index table) * / HINT is another way to make sure that invisible indexes are used.

  Thank you

  AJ

  Different environments have different statistics, giving optimizer different decisions.

  A cause I've seen often is load data into data bases development or test and immediately do a DBMS_STATS. GATHER_SCHEMA_STATS (USER). 11.2 that will usually use method_opt = 'for all columns size auto. Auto size collects only the histograms on columns that were used as query predicates, but a newly loaded schema never had questions, so there no predicates query saved, while it does collect SOME histograms. Environments that change data (including production) automatically gather statistics after a number of activities and build appropriate histograms, but the environments that make few changes continue to have basic with no histograms statistics.

  One way to avoid this problem is to use DBMS_STATS. GATHER_SCHEMA_STATS (USER, method_opt => 'for all columns size 255') after any schema reload. Bringing together histograms on all columns, which will be closer to production than any gathering.

• Why the CBO will ignore my index?

  I have a strange situation with a "simple" query
  
  This is my table:
  CREATE TABLE 'BAG_MOVEMENTS '.
  ('MOVEMENT_ID' NUMBER(*,0) NOT NULL ACTIVATE,)
  ACTIVATE THE 'BAG_ID' NUMBER(*,0) NOT NULL,
  * "TRANSACTION_ID" ACTIVATE VARCHAR2 (255 BYTE) NOT NULL, * "
  ACTIVATE THE 'AMOUNT' FLOAT (126) NOT NULL,
  ACTIVATE "INSERT_DATE" STAMP (6) NOT NULL,
  NUMBER(*,0) "RATER_ID"
  NUMBER(*,0) "RATER_PLAN_ID"
  'START_DATE' TIMESTAMP (6).
  'END_DATE' TIMESTAMP (6).
  NUMBER(*,0) "SUBSERVICE_ID"
  NUMBER(*,0) "LEVEL_ID"
  VARCHAR2 (24 BYTE) "RATER_TYPE."
  'PK__BAG_MOVEMENTS' CONSTRAINT PRIMARY KEY ('MOVEMENT_ID'),
  KEY FOREIGN CONSTRAINT "FK_BA_REF_19553_BA" ("BAG_ID")
  SELECT REFERENCES 'BAG' ('BAG_ID') ON DELETE CASCADE
  );
  Here are the clues:
  CREATE INDEXES ' IDX$ $_53670001 ' ON 'BAG_MOVEMENTS' ("TRANSACTION_ID");
  
  CREATE INDEXES '_BAG_MOVEMENTS_FK1' ON 'BAG_MOVEMENTS' ('BAG_ID');
  
  CREATE AN INDEX UNIQUE 'BAG_MOVEMENTS_PK' ON 'BAG_MOVEMENTS' ('MOVEMENT_ID');
  
  I expect that the following query should use the IDX index $ $_53670001... and he does.
  Select * from BAG_MOVEMENTS
  where transaction_id = "32260-3gpp.org@9af63e37-521e-4fda-85d5-afb5768227fceebce62d-bc87-4915-8b56-ca255eb2a163"
  and rater_id <>- 1
  
  Execution plan
  ----------------------------------------------------------
  Hash value of plan: 1805212729
  
  ---------------------------------------------------------------------------------------------------
  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
  ---------------------------------------------------------------------------------------------------
  | 0 | SELECT STATEMENT | 1. 141. 5 (0) | 00:00:01 |
  |* 1 | TABLE ACCESS BY INDEX ROWID | BAG_MOVEMENTS | 1. 141. 5 (0) | 00:00:01 |
  |* 2 | INDEX RANGE SCAN | IDX$ $_53670001 | 1 | | 4 (0) | 00:00:01 |
  ---------------------------------------------------------------------------------------------------
  
  Information of predicates (identified by the operation identity card):
  ---------------------------------------------------
  
  1 Filter ("RATER_ID" <>(-1))
  2 - access ("TRANSACTION_ID" = '32260-3gpp.org@9af63e37-521e-4fda-85d5-afb5768227fceebce62d-bc87-4915-8b56-ca255eb2a163')
  
  
  Statistics
  ----------------------------------------------------------
  1 recursive calls
  0 db block Gets
  6 compatible Gets
  2 physical reads
  0 redo size
  1434 bytes sent via SQL * Net to client
  492 bytes received via SQL * Net from client
  2 SQL * Net back and forth to and from the client
  0 sorts (memory)
  0 sorts (disk)
  1 rows processed
  
  
  When I use another TRANSACTION_ID I get FULL TABLE SCAN with a cost of 11887 (previous was 5!):
  Select *.
  of BAG_MOVEMENTS
  where transaction_id = "[email protected]@nov2902.mydomain.com;9998;1257262489;6458"
  and rater_id <>- 1;
  
  Execution plan
  ----------------------------------------------------------
  Hash value of plan: 2308301958
  
  -----------------------------------------------------------------------------------------
  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
  -----------------------------------------------------------------------------------------
  | 0 | SELECT STATEMENT | 802K | 107 M | 11887 (2) | 00:02:23 |
  |* 1 | TABLE ACCESS FULL | BAG_MOVEMENTS | 802K | 107 M | 11887 (2) | 00:02:23 |
  -----------------------------------------------------------------------------------------
  
  Information of predicates (identified by the operation identity card):
  ---------------------------------------------------
  
  1 - Filter ("TRANSACTION_ID" = "[email protected]@nov2902.mydomain.com;9998;1257262489;6458" AND "RATER_ID" <>(-1))
  
  
  Statistics
  ----------------------------------------------------------
  1 recursive calls
  0 db block Gets
  44365 compatible Gets
  0 physical reads
  0 redo size
  1501 bytes sent via SQL * Net to client
  492 bytes received via SQL * Net from client
  2 SQL * Net back and forth to and from the client
  0 sorts (memory)
  0 sorts (disk)
  2 rows processed
  
  If I force Oracle to use the index of the cost increases to 711685!
  Select / * + INDEX (IDX BAG_MOVEMENTS $$ _53670001) * / *.
  of BAG_MOVEMENTS
  where transaction_id = "[email protected]@nov2902.mydomain.com;9998;1257262489;6458"
  and rater_id <>- 1;
  
  Execution plan
  ----------------------------------------------------------
  Hash value of plan: 1805212729
  
  ---------------------------------------------------------------------------------------------------
  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
  ---------------------------------------------------------------------------------------------------
  | 0 | SELECT STATEMENT | 802K | 107 M | 711K (1) | 02:22:21 |
  |* 1 | TABLE ACCESS BY INDEX ROWID | BAG_MOVEMENTS | 802K | 107 M | 711K (1) | 02:22:21 |
  |* 2 | INDEX RANGE SCAN | IDX$ $_53670001 | 810K | 8845 (1) | 00:01:47 |
  ---------------------------------------------------------------------------------------------------
  
  Information of predicates (identified by the operation identity card):
  ---------------------------------------------------
  
  1 Filter ("RATER_ID" <>(-1))
  2 - access ("TRANSACTION_ID" = '[email protected]@nov2902.mydomain.com;9998;1257262489;6458')
  
  
  Statistics
  ----------------------------------------------------------
  1 recursive calls
  0 db block Gets
  Gets 7 compatible
  2 physical reads
  0 redo size
  1501 bytes sent via SQL * Net to client
  492 bytes received via SQL * Net from client
  2 SQL * Net back and forth to and from the client
  0 sorts (memory)
  0 sorts (disk)
  2 rows processed
  
  Oracle is selecting the right plan for TRANSACTION_ID * "[email protected]@nov2902.mydomain.com;9998;1257262489;6458."
  But why he does not use the index in what concerns the TRANSACTION_ID * "32260-3gpp.org@9af63e37-521e-4fda-85d5-afb5768227fceebce62d-bc87-4915-8b56-ca255eb2a163?"
  
  Thank you

  Background stats task gathers the outdated statistics, so you could either turn it off completely and replace it with your own job (perhaps exaggerated if it works for most good for you), or lock the statistics for a table or set the table to NOMONITORING to prevent his stats being marked as stale. Then you need a job to collect statistics on a table using dbms_stats.gather_table_stats and passage of your own custom settings.

  To collect default statistics on only specified columns, you will need something like this:

  BEGIN
      DBMS_STATS.GATHER_TABLE_STATS
      ( 'yourtableowner'
      , 'bag_movements'
      , method_opt =>
        'for columns size auto movement_id bag_id amount insert_date rater_id rater_plan_id start_date end_date subservice_id level_id rater_type'
      , force => TRUE );
  END;
  

  Or collect transaction_id basic stats but no histograms.

  BEGIN
      DBMS_STATS.GATHER_TABLE_STATS
      ( 'yourtableowner'
      , 'bag_movements'
      , method_opt =>
        'for columns size auto movement_id bag_id amount insert_date rater_id rater_plan_id start_date end_date subservice_id level_id rater_type ' ||
        'for columns size 1 transaction_id'
      , force => TRUE );
  END;
  

  There is no syntax of ' all columns except ", so you'll have all the columns you need for statistics on the list. You might want to consider the option "size" for the other columns while you're there. The option 'force' is for when you have locked the stats to prevent the background stats task collect default statistics.

  Obviously, test to make sure it's doing what you want it to do, especially as the method_opt syntax is not clearly documented.

  Edited by: William Robertson on November 25, 2009 18:40

• Monitor the quality of my Internet service provider and document the results.

  OT: ping.

  I am trying to monitor the quality of my Internet service provider and to document the results.   I would like to create a ping file during the execution of the order would send ping results to the screen and a file.   I ran the file whenever the computer is turned on.  The batch file must run continuously until interrupted and view the results of ping on the screen without the statistics, and it looks something like:

  Reply from 173.194.115.4: bytes = 32 time = 19ms TTL = 52

  Reply from 173.194.115.4: bytes = 32 time = 17ms TTL = 52

  Reply from 173.194.115.4: bytes = 32 time = 12ms TTL = 52

  Request timed out.

  Reply from 173.194.115.4: bytes = 32 time = 25 ms TTL = 52

  Reply from 173.194.115.4: bytes = 32 time = 191ms TTL = 52

  ...

  In the file, it should write the results and look like:

  Wednesday, December 2, 2015 9:30:34.02 response from 173.194.115.4: bytes = 32 time = 19ms TTL = 52
  Wednesday, December 2, 2015 9:30:34.58 request has expired.

  ...

  The batch file should display the results of ping on the screen.

  In the file, it should write the results and look like:

  It is one or the other: write the result on the screen or write to a file.

  It seems that you forgot to ask a question. If you want to know how to do such a thing, so this batch file would do the trick. It will write the result in the desktop Ping.txt file.

  off @echo
  Set IP = 173.194.115.4
  value = Write date % echo %%d time % > ^ > '% UserProfile%\Desktop\Ping.txt '.

  : Loop
  for /F "delims =" % in (' ping-n 1% IP % ^ | findstr /i "demand response" ' "") do write %
  Timeout 5 > zero
  GoTo loop

• Upgrade of PeopleTools to 8.54 8.51

  Team,

  We are thinking of an upgrade of 8.54 8.51 and would like to know on what are the steps that can be performed in parallel to reduce the time to upgrade. In addition, there is minimal risk measures can be ignored...

  All entries on this will be highly appreciated.

  Thank you!

  As CCR says, the only way to achieve synchronization for your systems is to carry out preliminary tests.

  In my class upgrade, the Tools section takes around 07:15.  I could accelerate it if necessary in preparing exports of table following a development freeze.  This would save about 30 minutes on the tables of PeopleTools export step 04/03/14 system.  Similarly, no matter where scripts are generated, if your source has not changed (i.e. a gel development forced after PSG last of the trial), you are able to reuse the previous scripts and save a few minutes here.

  In addition, almost three hours of my time to run statistics (twice).  If you find that performance is acceptable without these statistics, you could potentially save more time.  I've scheduled some tests for this further in our upgrade project.

  Mind you, I've also included a script which gives an extra level of verification - which requires my current site.  This extra step is 30 minutes at the beginning and at the end of 30 minutes.

  Finally, look at the DMS scripts are running.  A number of them use the code independent of the platform such as the XXX DELETE; who can be accelerated using TRUNCATE TABLE XXX;

  How do you know where the time can be saved?  You perform a test run and look at the timings on every step.  Anything less than 30 seconds is not worth spending time on.  Nothing more than 5 minutes (an arbitrary value - set your own limit) is a potential target for further investigation.

• DBMS_STATS. CREATE_STAT_TABLE

  Hello
  
  Can someone help me understand the different columns of the stat_table and how to interpret the data in this table?
  
  Kind regards
  Narayan

  user7202581 wrote:
  Hello

  Can someone help me understand the different columns of the stat_table and how to interpret the data in this table?

  I thought that I had published a breakdown of this, but I can't find it online. However, this is a very old link which is probably more often correct, although incomplete which could help you get started.
  It is fairly easy to work, however. Just go through the different scenarios:

  create a table with two columns, gather stats with no histograms, then save its stats, look at the table - then truncate the table stat
  Repeat without histograms
  Repeat after the addition of an index
  Repeat using a simple table partitioned
  Repeat using a composite partitioned table
  Repeat using an IOT with no overflow
  Repeat using an IOT with overflow

  etc.

  Concerning
  Jonathan Lewis
  http://jonathanlewis.WordPress.com

  To get answers to common questions of SQL and PL/SQL (including how to mark your code):
  Re: 3. how to improve the performance of my query? / My query is slow.

• Linear decay of cardinality in 9.2.0.8

  Hello
  lets say, I've got a date with the date (populated as sysdate) column, point of view of time, I have created (statistical computing) index on this column without histogram (min/max value).
  So, if I gather stats on this column, my estimation of cardinality will lower each day up to a value of 1, the right (because out of linear decline)?
  Concerning
  GregG

  See also

  http://hemantoracledba.blogspot.SG/2012/09/cardinality-decay.html

  Hemant K Collette

• Estimate of time for CTAS

  Hello
  I'm looking for a long time to find a way to estimate the time of execution of the orders of the ETG. I'm a DBA. Our users are running DEC orders to charge millions of rows. Commands extract the data from 4-5 very large tables each with millions of records and process them using where clause and group by clause and finally to create the table. All these things are coded in the order of the ETG. These CTAS sometimes takes a lot of time as 5, 8 Hrs. users frequently ask me to find how long it will take. I use the OEM and the TOAD. But I couldn't find the estimated time for these tools. I think there must be a way, but I do not know the method.
  Can any body please help me in this regard?
  
  Thanks and greetings
  Ananda Basak

  915354 wrote:
  I started using the method of table surface and looking at the value of column time to estimate the execution time long-running queries. For the first test case, it gave me good estimate. But for the 2nd case today, the plan for a DEC showed the value of the column time as around 40 minutes wherever the ETG was already running for 1 hour 45 minutes. If the value of column time is not estimate this matter correctly.
  Please suggest why this might be happening?

  That's why I said at the beginning

  "Of course, the optimizer estimates are only estimates and are not as accurate as the database statistics that are in place." If the optimizer generates a bad plan, it is likely because the optimizer expects an operation to take much more or much less time that it in fact in this case the runtime optimizer estimate is likely to be far. »

  Even in the best of cases, the optimizer estimates will be rough. If statistics are imprecise, estimates of the cardinality and runtime optimizer may potentially be off by a bit. You will have to dig into the specific query plan to see where the optimizer estimates do not go and then to understand the statistics are misleading it. Most likely, you will find statistics on a column, other tables, or some indexes are updated but you might also find a column that has need of a histogram, statistics system that is obsolete or a myriad of other possible sources of error.

  Justin

• "Resume" a Data Pump import Execution failure

  First of all, here is a "failure" Data Pump Import I want to "resume":
  

  ] $ impdp directory dumpfile=mySchema%U.dmp "" / as sysdba "" = DATA_PUMP_DIR logfile = Import.log patterns parallel = MYSCHEMA = 2
  
  Import: Release 10.2.0.3.0 - 64 bit Production Tuesday, February 16, 2010 14:35:15
  
  Copyright (c) 2003, 2005, Oracle. All rights reserved.
  
  Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64 bit Production
  With the options of Real Application Clusters, partitioning, OLAP and Data Mining
  Table main 'SYS '. "' SYS_IMPORT_SCHEMA_01 ' properly load/unloaded
  Departure 'SYS '. "' SYS_IMPORT_SCHEMA_01 ': ' / * AS SYSDBA"dumpfile=mySchema%U.dmp directory = DATA_PUMP_DIR logfile = Import.log patterns parallel = MYSCHEMA = 2
  Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA
  Object type SCHEMA_EXPORT/SYNONYM/SYNONYM of treatment
  Object type SCHEMA_EXPORT/TYPE/TYPE_SPEC of treatment
  Object type SCHEMA_EXPORT/SEQUENCE/SEQUENCE of treatment
  Processing object type SCHEMA_EXPORT/SEQUENCE/EXCHANGE/OWNER_GRANT/OBJECT_GRANT
  Object type SCHEMA_EXPORT/TABLE/TABLE processing
  Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
  . . imported "MYSCHE"...
  ...
  ... 0 KB 0 rows
  Processing object type SCHEMA_EXPORT/TABLE/SCHOLARSHIP/OWNER_GRANT/OBJECT_GRANT
  Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX
  ORA-39126: worker unexpected fatal worker error of $ MAIN. LOAD_METADATA [INDEX: "MONSCHEMA".] ["" OBJECT_RELATION_I2 "]
  SELECT process_order, flags, xml_clob, NVL (dump_fileid,: 1), NVL (dump_position,: 2), dump_length, dump_allocation, constituent, object_row, object_schema, object_long_name, processing_status, processing_state, base_object_type, base_object_schema, base_object_name, goods, size_estimate, in_progress 'SYS '. "" SYS_IMPORT_SCHEMA_01 "process_order where: 3: 4 AND processing_state <>: 5 AND double = 0 ORDER BY process_order
  ORA-06502: PL/SQL: digital error or value
  ORA-06512: at "SYS." "MAIN$ WORKER", line 12280
  ORA-12801: error reported in the parallel query P001, instance pace2.capitolindemnity.com:bondacc2 Server (2)
  ORA-30032: the suspended order (trade-in) has expired
  ORA-01652: unable to extend segment temp of 128 in tablespace OBJECT_INDX
  ORA-06512: at "SYS." DBMS_SYS_ERROR', line 105
  ORA-06512: at "SYS." "MAIN$ WORKER", line 6272
  -PL/SQL call stack-
  the line object
  serial number of handle
  package body 14916 0x1f9ac8d50 SYS. MAIN$ WORKER
  body 0x1f9ac8d50 6293 package SYS. MAIN$ WORKER
  body 0x1f9ac8d50 3511 package SYS. MAIN$ WORKER
  body 0x1f9ac8d50 6882 package SYS. MAIN$ WORKER
  body 0x1f9ac8d50 1259 package SYS. MAIN$ WORKER
  0x1f8431598 anonymous block 2
  Job 'SYS '. "' SYS_IMPORT_SCHEMA_01 ' stopped because of the fatal 23:05:45
  

  As you can see this work is not without treatment statistics, constraints, etc. from PL/SQL. I want to do is make another impdp command but ignore objects that were imported with success as shown above. Is it possible to do (using the EXCLUDE parameter maybe?) with impdp? If so, what would it be?
  
  Thank you
  
  John

  Why you just restart this work. It ignores everything that has already been imported.

  Impdp "" / as sysdba "" attach = "SYS." "" SYS_IMPORT_SCHEMA_01 ".

  Import > keep

  Dean