Index Statistics in 9i

SQL Developer v1422, DB 9.2.0.5, Win XP Pro 2002
When navigating to the statistics tab for an index (opening the index from the index folder), I am getting the following result:
No Valid query found for Database Version:9.2
DB Version:10.0-0.0
select * from sys.all_ind_statistics where owner = :OBJECT_OWNER and index_name = :OBJECT_NAME
I found a thread saying that this tab was empty for some people with Raptor v804 (v 0804 : Index/statistics empty but nothing apart from that.
I can see that there is no ALL_IND_STATISTICS view in my DB, but as the data that is displayed on this tab in my 10g DB (where this works) is on the details tab in both 9i and 10g, I don't see why we can't have a query that populates this tab in 9i.
As an alternative, if SQL Developer can tell that it doesn't have a valid query for the tab in the current DB version, shouldn't it hide the tab?

Actually the framework doesn't allow hiding the tab. I've put in a request for this when it's available to me I will definitely put it in.
-kris

Similar Messages

Index Statistics Update - Problem

We had performance problem yesterday with FI report FAGLL03, it timed out in online execution and in background mode it took 5000+ sec to execute. Result was no more than 100 records.
Later with some investigation problem drill down to index usage of table FAGLFLEXA. We then updated the index statistics of table from DB02. After that report worked fine with execution time of 10-15 sec for same set of input.
However user, in morning , was complaining again about performance problem with same report FAGLL03. We did that update index statistics again and as it was the case yesterday it fixed the problem.
Later today I checked SQL server the job SAP CCMS_xxx_xxx_Update_Tabstats, which I guess is updating index statistics daily at 0400 hours, is working fine. I can't see any error log there. Daily job to check database consistency is also not reporting anything.
Anyidea what could be going wrong.
Basis Consultants are looking into problem however I am putting this case here if anyone of you had same problem and fixed it.
Thanks,
Pawan.
Edited by: Pawan Kesari on Dec 11, 2009 4:05 PM

Hi,
Appears the stats are dropped eveytime the job runs @04:00
Have a look at the table DBSTATC in trx: DB21 to see if it's setup to dropped the stats..
Mark

SQL Developer Behavior When Gathering Table/Index Statistics

Hey All,
Not sure if this has been posted yet. I did a search and did not find any threads on the topic though.
I noticed with SQL Developer 2.x, when you using the context menu to gather table/index statistics for a given table, you get no modal progress/waiting window like you did in 1.x. It just kind of "does nothing", even though it did actually execute the DBMS_STATS package. If you press cancel and try to navigate around, you get multiple "Connection is Busy" errors. Eventually it will come back and say "Statistics gathered for table <whatever>". In the old versions there was just a modal window with an animated progress bar while it ran the DBMS_STATS package. What happened to that? Or is this something unique to my install? Anyone else ran into this? Is there a fix or somewhere I can report this as an official bug? FWIW I'm running 2.1.1.64, and this did occur in the initial 2.0 release.
It is very confusing the first time you run into it... I pressed the "apply" button several times thinking it didn't take, but it ended up running the DBMS_STATS for every click I did.
Thanks!

Same happens to all the other context menu opened dialogs. Indeed very confusing at first and disturbing.
The only official site to report bugs is Metalink/MOS, but you might be lucky if someone from the team picks it up here.
Regards,
K.

What permissions needed to view index statistics for a database?

Im trying to setup a job that will read index statistics about a given database. The system management views are in Master.
Im trying to test the permissions for the login that will be used by doing Execute As, but Im getting permission errors such as
The user does not have permission to perform this action. Also, since the login is a domain account mapped to a sql login, I cant simply login as that user to run the statement.
So what permissions would be needed to run the statement below? I can run it without issue, but ive got Admin rights. I really dont want to give this user admin rights
--Missing index count
SELECT @MissingIndexCount = COUNT(*)
FROM sys.dm_db_missing_index_groups mig
INNER JOIN sys.dm_db_missing_index_group_stats migs ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid ON mig.index_handle = mid.index_handle
INNER JOIN sys.databases db ON mid.database_id = db.database_id
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
AND db.name = 'My Database Name'
[update]
I think I found my answer here
https://msdn.microsoft.com/en-us/library/ms188754%28v=sql.105%29.aspx?f=255&MSPPError=-2147217396

Hi
I think you'll need
VIEW SERVER STATE for the dmvs and
VIEW AND DATABASE for sys.databases.
There's a "permissions" section in the documentation for each of these objects, e.g.
sys.databases

Table statistics / index statistics generation

Hi,
How often do you run/should system run table & index statistics through DBA calendar/BRtool? What impact on system load does it have? Do you run it for all tables & indecies above certain size?
Thank you,
Mike

hi Dear,
How often do you run/should system run table & index statistics through DBA calendar/BRtool*S*?
basically we can run with DB13 and if you want to run through BRTOOLS then following steps:
Run --> brtools
select   7
select   1
press   C three time
process will be executing the table.
press    c              // now i m applying
What impact on system load does it have?
it maintain the update and good for health of database...// like.. you don't stable yourseft with out exercise mean it is exercise of datebase
Do you run it for all tables & indecies above certain size?
yea
don't forget the point
regards,
majamil

Importing a table and its index statistics, cannot import index stats

Hi,
Oracle 10.2.0.4 on Solaris.
I have DBA to imprt tables and index statistics for a table from prod into QA for further analysis. The stats for this table are locked in prod
DBA has used the following command for export and import table statistics
exec dbms_stats.export_table_stats('SCHEMA','TABLE',null,'TABLE_20130225',null,true,'INV');
exec dbms_stats.import_table_stats('SCHEMA','TABLE',null,'TABLE_20130225',null,true,'SCHEMA');Although cascade is set to true above, this resulted in "only table stats" to be imported no index stats. So we have imported the prod table level stats but no index stats! FYI, the indexes in prod have stats (last_analyzed) set.
Next DBA tried the export and import using export_index_stats and import_index_stats but no luck. DBA advising me that the only option we have is to import the table itself from prod to QA. It seems that import with cascade does not work.
Is this a bug in 10g or there is another way around to get index statistics as well?
Thanks
Edited by: 902986 on 25-Feb-2013 06:22

902986 wrote:
Hi,
Oracle 10.2.0.4 on Solaris.
I have DBA to imprt tables and index statistics for a table from prod into QA for further analysis. The stats for this table are locked in prod
DBA has used the following command for export and import table statistics
exec dbms_stats.export_table_stats('SCHEMA','TABLE',null,'TABLE_20130225',null,true,'INV');
exec dbms_stats.import_table_stats('SCHEMA','TABLE',null,'TABLE_20130225',null,true,'SCHEMA');Although cascade is set to true above, this resulted in "only table stats" to be imported no index stats. Problem Exists Between Keyboard And Chair
"Gather statistics on the indexes for this table. Index statistics gathering is not parallelized. Using this option is equivalent to running the GATHER_INDEX_STATS Procedure on each of the table's indexes. Use the constant DBMS_STATS.AUTO_CASCADE to have Oracle determine whether index statistics to be collected or not. This is the default. The default value can be changed using theSET_PARAM Procedure."
Handle:     902986
Status Level:     Newbie
Registered:     Dec 17, 2011
Total Posts:     69
Total Questions:     18 (12 unresolved)
Why so MANY unanswered questions?

How to find table/index statistics are outdated

Hi guys,
How can we find whether the statistics of a table or a index are outdated.
thanks...

You can use DBA_TAB_MODIFICATIONS view: please read "Determining Stale Statistics" http://download.oracle.com/docs/cd/E11882_01/server.112/e16638/stats.htm#PFGRF94738

Index statistics

Hi all,
what are the condition for oracle to make an index stale ... as more than 10% changes can make an table stale ..
Thanks
Subi

Index's statistics can get stale, but index can get valid or unsuable only.Index's statistics get stale when approximately 10% of rows for an object have been modified.
To check
select owner,index_name,table_name,table_owner,stattype_locked as locked, to_char(last_analyzed,'DD-MON-YYYY HH:MI:SS'), stale_stats from user_ind_statistics where stale_stats='YES';
Anand
Edited by: Anand... on Sep 25, 2009 1:36 AM

INDEX STATISTICS(compute when)

How can I know if a index statistic of a table is too old, and if I have to recalculate it?
How can I watch the process of computing statistics?
Thanks
PS: The version that I'm using is Oracle 9.2.0.4.0.

Hi
Query USER_INDEXES view to find out when the indexes were analyzed.
SQL> select index_name, last_analyzed from user_indexes;
INDEX_NAME                     LAST_ANAL
PART_IDX                       09-OCT-08
TEST_NULLS_I2                  27-JUL-08
ZIGGY_I                        01-JUL-08
A_IDX                          01-AUG-08
B_IDX                          01-AUG-08
How can I watch the process of computing statistics?What do you mean?
You compute statistics using DBMS_STATS package, if this is what you are looking for.
Regards
Asif Momen
http://momendba.blogspot.com

How oracle decide whetehr to use index or full scan (statistics)

Hi Guys,
Let say i have a index on a column.
The table and index statistics has been gathered. (without histograms).
Let say i perform a select * from table where a=5;
Oracle will perform a full scan.
But from which statistics it will be able to know indeed most of the column = 5? (histograms not used)
After analyzing, we get the below:
Table Statistics :
(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)
thanks
Index Column (A)
======
1
1
2
2
5
5
5
5
5
5

I have prepared some explanation and have not noticed that the topic has been marked as answered.
This my sentence is not completely true.
A column "without histograms" means that the column has only one bucket. More correct: even without histograms there are data in dba_tab_histograms which we can consider as one bucket for whole column. In fact these data are retrieved from hist_head$, not from histgrm$ as usual buckets.
Technically there is no any buckets without gathered histograms.
Let's create a table with skewed 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     999998So, we have table with very skewed data distribution.
Let's gather 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            C104So, Oracle suggests that values between 1 and 3 (raw C102 and C104) are distributed uniform and the density of the distribution is 0.33.
Let's try to explain 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)Below is 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: 0Cost of FTS here is 300 and cost of Index Range Scan here is 2377.
I have disabled cpu costing, so selectivity does not affect the cost of FTS.
cost of Index Range Scan is calculated as
blevel + (leaf_blocks * selectivity + clustering_factor * selecivity) = 2 + (4017*0.33333 + 3107*0.33333) = 2377.
Oracle considers that it has to read 2 root/branch blocks of the index, 1339 leaf blocks of the index and 1036 blocks of the table.
Pay attention that selectivity is the major component of the cost of the Index Range Scan.
Let's try to gather 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 completedIf you look at dba_tab_histograms you will see following
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         1000000ENDPOINT_VALUE is the column value (in number for any type of data) and ENDPOINT_NUMBER is cumulative number of rows.
Number of rows for any ENDPOINT_VALUE = ENDPOINT_NUMBER for this ENDPOINT_VALUE - ENDPOINT_NUMBER for the previous ENDPOINT_VALUE.
explain plan and 10053 trace of 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: 0Pay attention on selectivity, ix_sel: 1.0000e-06
Cost of the FTS is still the same = 300,
but cost of the Index Range Scan is 4 now: 2 root/branch blocks + 1 leaf block + 1 table block.
Thus, conclusion: histograms allows to calculate selectivity more accurate. The aim is to have more efficient execution plans.
Alexander Anokhin
http://alexanderanokhin.wordpress.com/

Compute Statistics after create a index

Good night, I tryed it before and got no help.
So I'll try it again, because I didn't find it yet.
I have to create some indexes in a production database.
I have a doubt.
Do I need to Compute Statistics after creating indexes?
Or when I create they automatically are computed?
Thanks for any help.
The version I'm using is:
Oracle Database 10g Release 10.2.0.5.0 - 64bit Production
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for 64-bit Windows: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production

Petri BR wrote:
Good night, I tryed it before and got no help.
So I'll try it again, because I didn't find it yet.
I have to create some indexes in a production database.
I have a doubt.
Do I need to Compute Statistics after creating indexes?after CREATE INDEX what are the values for the index statistics?
Or when I create they automatically are computed?Just look at the statistics values after issuing CREATE INDEX & answer the question yourself!

Primary key index not working in a select statment

Hi ,
I'm doing a :
select *
from my_table
where B = v1 and
A = v2 ;
where A and B are the primary key of the table, in that table the primary key index is there and the order of the primary key definition is A first and then B.
While testing this statment in my database the Explain Plan shows that it is using the index ok but when
runninng in client database it is not using it becasue of the order (i think), is this something configurable that I need to ask to my DBA ?
The solution I found was to do the select with a hint wich fix the problem , but I'm curious about why is working in my dadabase and not in the client database
thanks in advance .
oracle version 11g

This is the forum for SQL Developer (Not for general SQL/PLSQL questions). Your question would be better asked in the SQL and PL/SQL forum.
Short answer: The execution plan used will depend on optimizer settings and table/index statistics. For example if the table has very few rows it may not bother using the index.

Help,why brconnect do not collect statistics for mseg table?

I found "MSEG" table`s statistics is too old.
so i check logs in db13,and the schedule job do not collect statistics for "MSEG".
Then i execute manually: brconnect -c -u system/system -f stats -t mseg -p 4
this command still do not collect for mseg.
KS1DSDB1:oraprd 2> brconnect -c -u system/system -f stats -t mseg u2013f collect -p 4
BR0801I BRCONNECT 7.00 (46)
BR0154E Unexpected option value 'u2013f' found at position 8
BR0154E Unexpected option value 'collect' found at position 9
BR0806I End of BRCONNECT processing: ceenwjre.log 2010-11-12 08.41.38
BR0280I BRCONNECT time stamp: 2010-11-12 08.41.38
BR0804I BRCONNECT terminated with errors
KS1DSDB1:oraprd 3> brconnect -c -u system/system -f stats -t mseg -p 4
BR0801I BRCONNECT 7.00 (46)
BR0805I Start of BRCONNECT processing: ceenwjse.sta 2010-11-12 08.42.04
BR0484I BRCONNECT log file: /oracle/PRD/sapcheck/ceenwjse.sta
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.11
BR0813I Schema owners found in database PRD: SAPPRD*, SAPPRDSHD+
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.12
BR0807I Name of database instance: PRD
BR0808I BRCONNECT action ID: ceenwjse
BR0809I BRCONNECT function ID: sta
BR0810I BRCONNECT function: stats
BR0812I Database objects for processing: MSEG
BR0851I Number of tables with missing statistics: 0
BR0852I Number of tables to delete statistics: 0
BR0854I Number of tables to collect statistics without checking: 0
BR0855I Number of indexes with missing statistics: 0
BR0856I Number of indexes to delete statistics: 0
BR0857I Number of indexes to collect statistics: 0
BR0853I Number of tables to check (and collect if needed) statistics: 1
Owner SAPPRD: 1
MSEG
BR0846I Number of threads that will be started in parallel to the main thread: 4
BR0126I Unattended mode active - no operator confirmation required
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.16
BR0817I Number of monitored/modified tables in schema of owner SAPPRD: 1/1
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.16
BR0877I Checking and collecting table and index statistics...
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.16
BR0879I Statistics checked for 1 table
BR0878I Number of tables selected to collect statistics after check: 0
BR0880I Statistics collected for 0/0 tables/indexes
BR0806I End of BRCONNECT processing: ceenwjse.sta 2010-11-12 08.42.16
BR0280I BRCONNECT time stamp: 2010-11-12 08.42.17
BR0802I BRCONNECT completed successfully
the log says:
Number of tables selected to collect statistics after check: 0
Could you give some advices? thanks a lot.

Hello,
If you would like to force the creation of that stats for table MSEG you need to use the -f (force) switch.
If you leave out the -f switch the parameter from stats_change_threshold is taken like you said correctly:
[http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/02/0ae0c6395911d5992200508b6b8b11/content.htm|http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/02/0ae0c6395911d5992200508b6b8b11/content.htm]
[http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/cb/f1e33a5bd8e934e10000000a114084/content.htm|http://help.sap.com/saphelp_nw70ehp1/helpdata/EN/cb/f1e33a5bd8e934e10000000a114084/content.htm]
You have tried to do this in your second example :
==> brconnect -c -u system/system -f stats -t mseg u2013f collect -p 4
Therefore you received:
BR0154E Unexpected option value 'u2013f' found at position 8
BR0154E Unexpected option value 'collect' found at position 9
This is the correct statement, however the hyphen in front of the f switch is not correct.
Try again with the following statement (-f in stead of u2013f) you will see that it will work:
==> brconnect -c -u system/system -f stats -t mseg -f collect -p 4
I hope this can help you.
Regards.
Wim

Index order in Oracle 10g

Hi
I have a query:
I have a table having date and status as fields. Date is indexed.
Now i want to know whether the performance will hit if i make the query as:
where status = 'A' and date >= sysdate-100 and date <= sysdate
Does it matter that the where clause ordering should be as per ordering of indexes?
Similarly the same thing for partition. If date field is partitioned, will the partitioning advantage is there if we put status condition first.
Regards

The optimizer will choose the order of operations that it believes will cause your query to run the most quickly regardless of the order you specify conditions in your WHERE clause. The optimizer's decision will be driven by a number of factors-- optimizer parameters, database version, system statistics, table statistics, index statistics, histograms, the selectivity of your conditions, etc. No one can say with any level of certainty what the optimizer in your particular database with your particular tables and indexes with your particular statistics would generate for a query plan.
If you as a human have reason to believe that the date condition is sufficiently selective that the optimizer should use that to do an index range scan as the first step, the optimizer should come up with that plan assuming your statistics back up your intuition.
Justin

Statistics Collection in Oracle 10g

In Oracle 10g gathering table and index statistics are automatic ?
or we have to physically gather statistics for table and indexes

It depends how your database is configured -
PARAMETER statistics_level should be set to typical and there must be a job NAMED as GATHER_STATS_JOB should be active. you can change the job parameters

Index Statistics in 9i

Similar Messages

Maybe you are looking for