DB Statistics & BI Indexes

Hi All,
I have been going through a lot of threads related to DB Statistics & BI Indexes and I am confused.
1) How do I come to know that the DB Statistics and BI Indexes for a cube are active or created?
Is it through RSDDSTAT where the status is X means stats are active? Is there another way to find out?
What about BI Indexes?
2) How do I create DB Statistics?
3) Does creatting DB statistics for query help the query performance or creating DB statistics on cube helps the Query performance or is it both?
4) I understand primary indexes are created while creating the cube.However, when we try to create secondary indexes through performance tab in which table the details are stored? Can it be deleted later?
5) Is there another way to create BI Indexes other than performance tab?

P.S: the formatting went nuts... I added *** before each of my replies... COME ON SAP!! Cant you fix this???
Hi.
1) How do I come to know that the DB Statistics and BI Indexes for a cube are active or created?
Is it through RSDDSTAT where the status is X means stats are active? Is there another way to find out?
What about BI Indexes?
In addition to the performance tab where you got the traffic lights, you can check the indexes through tcode SE11. Just input the table name and on the next sceen click the button reading "Indexes...". A popup will show you the indexes that exist for the table you are looking at. Doubleclicking any of the indexes will take you to the details.
You can also define a new, secondary index here. You might have to go to DB02->missing indexes to have it created on the database, even though it says it exists and is active in se11... get your basis guy in on all of this.
2) How do I create DB Statistics?
Through Performance tab or step in process chain, but you should schedule db stats at least once a week in that DB-maintenance-calendar-thingy you can get to with a tcode I cannot remember... DBxx where xx is two numbers...ask your basis guy.
3) Does creatting DB statistics for query help the query performance or creating DB statistics on cube helps the Query performance or is it both?
You cannot create statistics for a query. You can collect statistics about the query use. This is the statistics stuff you can activate from bct; the "statistics-cubes" and all that. They store the info you collect and this is then called BI Statistics. It is of absolutely no use whatsoever with regards to performance. You can learn a lot about your system by analysing this, but starting to collect the BI Statistics wont help your slow running queries.
You can create statistics for cubes. This is the DB Stats and the effect of creating it is that the system will know how the data is distributed in the cube and because of that, it will have a better chance of reading data according to your selections faster. Much faster in some cases! This goes for both queries and loads (a load is just a special kind of query, where results are not put on the screen but in another table). Try to keep your DB Stats as up to date as you can - I always update the stats after each load and compression... It is especially important on transactional cubes, because data is more volatile here than when you only load every second day or so.
4) I understand primary indexes are created while creating the cube.However, when we try to create secondary indexes through performance tab in which table the details are stored? Can it be deleted later?
I dont know the tables this is stored in, but you can delete any index using SE11as mentioned above. Secondary indexes will need to be re-defined in SE11 when your system has been taken down... or if you activate the cube. In that case, only the hardwired primary indexes are created.
5) Is there another way to create BI Indexes other than performance tab?
I think you can only create/define an index in SE11, but you can refresh it from the Performance tab or in a process chain.
Regards,
Jacob
Edited by: Jacob Jansen on Aug 10, 2010 9:56 PM

Similar Messages

What is COMPUTE STATISTICS in index

Hi,
I need the explanations of compute statistics in index.
what is compute statistics?
Regards,
B.Prakash

Hi,
Compute statistics tells Oracle to collect statistics during the creation of the index. The statistics are then used by the optimizer to choose a "plan of execution" when SQL statements are executed.
Thanks

Statistics and indexes

hi gurus,
wat r bw statistics and indexes .... how to use them
thanx in advance

Anna,
Indexes are structures sorted by attribute values that contains a pointer to data stored in a table.
In plain words, when we run an indexing process on a table we basically build a pointer to that table records. That pointer has one main purpose: to enhance read performance (in our case - to enhance query performance).
BW Statistics are used in order to analyze the performance of queries and processes in the warehouse management (for example loading processes and aggregations). In order to use BW Statistics, you will need to enable them for your infoprovider and then be able to browse them from transcation ST03 or using the Technical Content Infoprovider and Queries.
See the Statistics How to: https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5401ab90-0201-0010-b394-99ffdb15235b
Hope it helps,
Gili

Gathering schema Statistics and Index rebuilding

I want to know after how much time we must gather the schema Statistics and Index rebuilding.
In our system approximately 7 logfile generates in one day
Please suggest me

Index rebuilding sounds so much Oracle 7! Indexes today generally take care of themselves quite well, throughout inserts, deletes and updates. It rebalances itself automatically when necessary, without requiring any rebuild. As for the stats, run it for sure after large data movements (i.e. deletes and inserts). Besides that, implement table monitoring for your tables, and run once in a while dbms_stats with the options parameter as GATHER STALE. That way, Oracle will automatically know which objects need their stats refreshed.
Daniel

How to create statistics for INDEX thru GUI

In DB13 i see messages MISSING_STATISTICS for some indexes.
I manage for tables thru DB20. How can i create statistsics for INDEX.
Rgds
PR

Hello PR,
at first let's say you should use the BRTools to create statistics for the indexes, because of the sample method (estimate, compute) - SAP has an algorithm to choose the right sample size.
Have a look at here:
http://help.sap.com/saphelp_nw70/helpdata/en/f4/81e93a637bfd70e10000000a11402f/content.htm
If you want to create statistics manually out of the R/3 ... you can use the report "RSANAORA"
Transaction SE38 -> Report RSANAORA -> Choose your index and sample method... and go on.
Regards
Stefan

EAR4 - Gathering Statistics, unusable indexes and more

Hi,
Some feedback on statistics:
1. When choosing a table -> Statistics -> gather Statistics, the minimum is to have a CASCADE option (so all the indexes will be analyzed too). I think it should be the deafult! This way there is a chance that the developers will have good statistics...
As a bonus, an advanced tab with the rest of the options might be nice, when you have time.
2. When choosing to gather statistics on an index, you should you dbms_stats and not ALTER INDEX... COMPUTE STATISTICS which is a deprecated syntax.
And about indexes:
1. When looking at the index tab of a table, unusable indexes should be visibly different - maybe just color the status column. Well, any color-coding can help to gain more infomation very fast (index types and index status). Well, I guess the same goes for disabled triggers, disabled constraints etc...
2. When right-clicking an index in an index tab of a table, the only option is export, which makes no sense. Could you replace it with the six relevant index options, just like when we right click an index in the side bar (drop, rebuild, rename, make unusable...)
Well, same goes for the triggers tab of a table - when right-clicking a trigger give us the trigger actions(enable/disable, drop...), not export.
my two cents,
Ofir

When Choose a partitioned table from the tables list (tree view on the left), I have many tabs with details (Columns, data, indexes,etc).
1. The last tab, SQL, doesn't generate any CREATE TABLE sql at all for the simple partition table I created (10g Release 2 on windows 2000, raptor 4.1, a table with a single partition).
2. There is no way to see the partitions definitions - for example, the list of partitions and their ranges (or list values). I would like to have another tab for partitioned table with that information (from all_tab_partitions). Also, how can I easily see the type of partitioning and the partition key of the table?
3. Also in the builtin reports, there is no way to get that data. The only report about partitioned tables that I see is Table -> Organization -> Partitioned -> Partitioned Tables, that only provide owner, table_name, maybe tablespace and logging (blank in my case).. I think:
a. You should rewrite the report to use dba/all_part_tables - with columns like partitioning_type, subpartitioning_type, partition_count etc.
b. add a report about the partition key columns per partitioned table from dba_part_key_columns.
4. When adding an index to a partitioned table, I can't choose local/global index. The index is always created as a global index. For example, can't create bitmap index on partitioned tables because they must be local.
Ofir

Update statistics / missing index

The performance has been downgraded after the DB migration... The Query seems running slower than it used to be,
How can I update statistics / find missing index to fix it in Oracle?

hi....
after the importing of the db please run the compilation script below
SET HEAD OFF
SET FEEDBACK OFF
SET PAGESIZE 0
SPOOL COM.SQL
SELECT 'ALTER '|| OBJECT_TYPE||' '|| OBJECT_NAME ||' COMPILE ; ' FROM
USER_OBJECTS
WHERE STATUS = 'INVALID'
AND OBJECT_TYPE != 'PACKAGE BODY'
ORDER BY OBJECT_TYPE
SELECT 'ALTER PACKAGE '|| OBJECT_NAME ||' COMPILE BODY ; ' FROM USER_OBJECTS
WHERE STATUS = 'INVALID'
AND OBJECT_TYPE = 'PACKAGE BODY'
ORDER BY OBJECT_TYPE
spool off
@com.sql
SET HEAD ON
SET FEEDBACK ON
SET PAGESIZE 100
this will compile database objects such as packages, functions and rebuilds indexes
regards,
steved

Statistics, Rebuilding Indexes, Performance Issues

I have a query which use to run 2-3 sec
After taking stats and rebuliding indexes
This Query is taking 25 sec
Is there anyway that I can get mt performance back?
Collected Stats
First Using Analyze table Compute stats
Second DBMS_STATS.GATHER_ TABLE_STATS
Level 12 Tracing
TKPROF: Release 9.2.0.6.0 - Production on Sun Jun 29 13:23:11 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
ped.eft_payee_seq_no, ped.partition_desgntr,
ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
WHERE ped.curr_row_ind = 'A'
AND cp.curr_row_ind = 'A'
AND cp.clm_payee_no = el.clm_payee_no
AND cp.mail_zip = 'XXXXXX'
AND ped.paye_bnk_rtng_no = 'XXXXXX'
AND ped.paye_bnk_acct_no = 'XXXXXXX'
AND ped.payee_bnk_acct_typ = 'XXXX'
AND ped.eft_payee_seq_no = el.eft_payee_seq_no
call count cpu elapsed disk query current rows
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 23.46 22.91 0 1292083 0 0
total 3 23.48 22.93 0 1292083 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 117
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 23.46 22.91 0 1292083 0 0
total 3 23.48 22.93 0 1292083 0 0
Misses in library cache during parse: 1
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
1 user SQL statements in session.
0 internal SQL statements in session.
1 SQL statements in session.
Trace file compatibility: 9.02.00
Sort options: prsela exeela fchela
1 session in tracefile.
1 user SQL statements in trace file.
0 internal SQL statements in trace file.
1 SQL statements in trace file.
1 unique SQL statements in trace file.
41 lines in trace file.
****************-----==========================================*****
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 73 | 5 | | |
| 1 | NESTED LOOPS | | 1 | 73 | 5 | | |
| 2 | NESTED LOOPS | | 12 | 708 | 4 | | |
| 3 | TABLE ACCESS BY GLOBAL INDEX ROWID| PAYEE_EFT_DETAIL_T | 12 | 540 | 1 | ROWID | ROW L |
|* 4 | INDEX RANGE SCAN | TEST_PAYEE_EFT_DETAIL_T_IE21 | 12 | | 3 | | |
| 5 | TABLE ACCESS BY GLOBAL INDEX ROWID| EFT_PAYEE_LNK_T | 1 | 14 | 1 | ROWID | ROW L |
|* 6 | INDEX RANGE SCAN | EFT_PAYEE_LNK_PK | 1 | | 1 | | |
|* 7 | INDEX RANGE SCAN | CLM_PAYEE_T_IE10 | 1 | 14 | | | |
Predicate Information (identified by operation id):
4 - access("PED"."PAYE_BNK_RTNG_NO"='XXXXXXX' AND "PED"."PAYE_BNK_ACCT_NO"='XXXXXXXXXX' AND
"PED"."PAYEE_BNK_ACCT_TYP"='CHK' AND "PED"."CURR_ROW_IND"='A')
6 - access("PED"."EFT_PAYEE_SEQ_NO"="LNK"."EFT_PAYEE_SEQ_NO")
7 - access("LNK"."CLM_PAYEE_NO"="CP"."CLM_PAYEE_NO" AND "CP"."MAIL_ZIP"='XXXXXX' AND "CP"."CURR_ROW_IND"='A')
==++++++++++++++*************************=+++++++++++++----------------=========
TKPROF: Release 9.2.0.6.0 - Production on Sun Jun 29 19:28:39 2008
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
ped.eft_payee_seq_no, ped.partition_desgntr,
ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
WHERE ped.curr_row_ind = 'A'
AND cp.curr_row_ind = 'A'
AND cp.clm_payee_no = el.clm_payee_no
AND cp.mail_zip = 'XXXXXX'
AND ped.paye_bnk_rtng_no = 'XXXXXXXXXX'
AND ped.paye_bnk_acct_no = 'XXXXXXXX'
AND ped.payee_bnk_acct_typ = 'CHK'
AND ped.eft_payee_seq_no = el.eft_payee_seq_no
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 23.30 22.75 0 1292083 0 0
total 3 23.30 22.75 0 1292083 0 0
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 117
Rows Row Source Operation
0 NESTED LOOPS
214395 NESTED LOOPS
214395 TABLE ACCESS BY GLOBAL INDEX ROWID PAYEE_EFT_DETAIL_T PARTITION: ROW LOCATION ROW LOCATION
214395 INDEX RANGE SCAN TEST_PAYEE_EFT_DETAIL_T_IE21 (object id 160840)
214395 TABLE ACCESS BY GLOBAL INDEX ROWID EFT_PAYEE_LNK_T PARTITION: ROW LOCATION ROW LOCATION
214395 INDEX RANGE SCAN EFT_PAYEE_LNK_PK (object id 75455)
0 INDEX RANGE SCAN CLM_PAYEE_T_IE10 (object id 71871)
alter session set sql_trace=false
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 2 0.00 0.00 0 0 0 0
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 117
ALTER SESSION SET SQL_TRACE = TRUE
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer goal: CHOOSE
Parsing user id: 117
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 3 0.00 0.00 0 0 0 0
Fetch 1 23.30 22.75 0 1292083 0 0
total 6 23.30 22.75 0 1292083 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
3 user SQL statements in session.
0 internal SQL statements in session.
3 SQL statements in session.
Trace file compatibility: 9.02.00
Sort options: prsela exeela fchela
1 session in tracefile.
3 user SQL statements in trace file.
0 internal SQL statements in trace file.
3 SQL statements in trace file.
3 unique SQL statements in trace file.
57 lines in trace file.
Message was edited by:
user644525

I have a query which use to run 2-3 sec
After taking stats and rebuliding indexes
This Query is taking 25 sec
Is there anyway that I can get mt performance back?
PLAN_TABLE_OUTPUT
| Id | Operation                            | Name                         | Rows | Bytes | Cost | Pstart| Pstop |
|   0 | SELECT STATEMENT                     |                               |     1 |    73 |     5 |       |       |
|   1 | NESTED LOOPS                        |                               |     1 |    73 |     5 |       |       |
|   2 |   NESTED LOOPS                       |                               |    12 |   708 |     4 |       |       |
|   3 |    TABLE ACCESS BY GLOBAL INDEX ROWID| PAYEE_EFT_DETAIL_T            |    12 |   540 |     1 | ROWID | ROW L |
|* 4 |     INDEX RANGE SCAN                 | TEST_PAYEE_EFT_DETAIL_T_IE21 |    12 |       |     3 |       |       |
|   5 |    TABLE ACCESS BY GLOBAL INDEX ROWID| EFT_PAYEE_LNK_T               |     1 |    14 |     1 | ROWID | ROW L |
|* 6 |     INDEX RANGE SCAN                 | EFT_PAYEE_LNK_PK              |     1 |       |     1 |       |       |
|* 7 |   INDEX RANGE SCAN                   | CLM_PAYEE_T_IE10              |     1 |    14 |       |       |       |
Predicate Information (identified by operation id):
   4 - access("PED"."PAYE_BNK_RTNG_NO"='XXXXXXX' AND "PED"."PAYE_BNK_ACCT_NO"='XXXXXXXXXX' AND
              "PED"."PAYEE_BNK_ACCT_TYP"='CHK' AND "PED"."CURR_ROW_IND"='A')
   6 - access("PED"."EFT_PAYEE_SEQ_NO"="LNK"."EFT_PAYEE_SEQ_NO")
   7 - access("LNK"."CLM_PAYEE_NO"="CP"."CLM_PAYEE_NO" AND "CP"."MAIL_ZIP"='XXXXXX' AND "CP"."CURR_ROW_IND"='A')
==++++++++++++++*************************=+++++++++++++----------------=========
SELECT    ped.addrs_typ, ped.bnk_addrs_seq_no, ped.clm_case_no,
                ped.eft_payee_seq_no, ped.partition_desgntr,
                ped.payee_bnk_acct_typ, ped.payee_eft_dtl_no,
                ped.paye_bnk_acct_no, ped.paye_bnk_nm, ped.paye_bnk_rtng_no,
                ped.row_updt_sys_id, ped.vrsn_no, el.clm_payee_no
           FROM payee_eft_detail ped, eft_payee_lnk el, clm_payee cp
          WHERE ped.curr_row_ind = 'A'
            AND cp.curr_row_ind = 'A'
            AND cp.clm_payee_no = el.clm_payee_no
            AND cp.mail_zip = '16803'
            AND ped.paye_bnk_rtng_no = '111000614'
            AND ped.paye_bnk_acct_no = '1586266775'
            AND ped.payee_bnk_acct_typ = 'CHK'
            AND ped.eft_payee_seq_no = el.eft_payee_seq_no
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     23.30      22.75          0    1292083          0           0
total        3     23.30      22.75          0    1292083          0           0
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 117
Rows     Row Source Operation
      0 NESTED LOOPS
214395   NESTED LOOPS
214395    TABLE ACCESS BY GLOBAL INDEX ROWID PAYEE_EFT_DETAIL_T PARTITION: ROW LOCATION ROW LOCATION
214395     INDEX RANGE SCAN TEST_PAYEE_EFT_DETAIL_T_IE21 (object id 160840)
214395    TABLE ACCESS BY GLOBAL INDEX ROWID EFT_PAYEE_LNK_T PARTITION: ROW LOCATION ROW LOCATION
214395     INDEX RANGE SCAN EFT_PAYEE_LNK_PK (object id 75455)
      0   INDEX RANGE SCAN CLM_PAYEE_T_IE10 (object id 71871)Trying to recreate my response to this thread that was posted yesterday...
The query is performing 1.3 million logical reads, per the "query" column in the TKPROF output. 1.3 million 8KB (or 16KB) logical reads takes a fair amount of time, and is consuming 23.30 CPU seconds of time (execution time is 22.75 seconds). The explain plan and the row source execution plan are identical, although the predicted cardinality numbers are much lower than the actual number of rows returned, per the TKPROF output (12 rows versus 214,395 rows). The CLM_PAYEE table seems to have the greatest number of restrictions placed on it, yet Oracle is joining that table last.
You found, per my recommendation, that adding the hint /*+ LEADING(CP) */ significantly decreased the execution time to less than one second. You may not have collected statistics on the indexes, even though you collected statistics on the tables. This may also be a sign that one or more histograms are required for the cardinality estimates to be close to accurate.
Did your GATHER_TABLE_STATS commands look similar to the following:
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'PAYEE_EFT_DETAIL',CASCADE=>TRUE);
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'EFT_PAYEE_LNK',CASCADE=>TRUE);
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'CLM_PAYEE',CASCADE=>TRUE);Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Reg: statistics on indexes

Hi,
Need to know how to build the statistics on the primary index.
Command : brconnect -u / -c -f stats -m +I
But i don know how to build the statistics for the primary index.

Hello Ambarish,
> But now when checked in production the query is picking up the index that is primary index and in quality system it is picking up the same
So how do you get the conclusion that an index rebuild will fix the issue? Does the index sizes differ so much? What is the clustering factor? What are the wait events of the SQL statement in the quality system?
At first you need to understand the root cause of the performance problem until you can solve the problem. Many questions are still open and an index rebuild is just one "little piece of the big oracle mosaic".
> Any one please help.How to rebuild primary key index .
I have already posted the brconnect call to rebuild the primary index.
Regards
Stefan

Alter index rebuild calculates statistics?

Hi
Does anyone know if ALTER INDEX REBUILD gathers statistics on the index automatically? Does it do it at a 100% by default?
Thanks for your help!!!

On 10g+ the alter index command defaults to compute statistics which to the best o my knowledge is a 100% sample. With lower versions you need to specify that you want statistics: alter index owner.index_name rebuild compute statistics;
HTH -- Mark D Powell --

Rebuild index vs Analyze index

Hi All,
I am realy confused about rebuilding index versus Analyzing index.
Could anyone plz help me out what is the diffrence between them.
How to Perform analyze of indexes and Rebuld of Indexes for both Oracle 9i and 10g databases.
Thanks a lot

CKPT wrote:
You can see the posts of experts by jonathan
I am realy confused about rebuilding index versus Analyzing index. tell us you are getting confused why we need to ananlyze before reubild index? if so
if index analyzed the whole statistics of index will be gathered.... then you can check what is the hieght of the index.. according to the height of the index you need to take step is index need to be really rebuild or not...
lets see furhter posts from experts if not clear..Thanks OK, so you determine the height of an index is (say) 4. What then ? If you decide to rebuild the index and the index remains at a height of 4, what now ? Was it really worth doing and do you rebuild it again as the index height is still 4 and still within your index rebuild criteria ? At what point do you decide that rebuilding the index just because it has a height of 4 is a total waste of time in this case ?
OK, so you determine the index only has a height of (say) 3, does that mean you don't rebuild the index ? But what if by rebuilding the index, the index now reduces to a height of just 1 ? Perhaps not rebuilding the index even though it has just a height of 3 and doesn't currently meet your index rebuild criteria is totally the wrong thing to do and a rebuild would result in a significantly leaner and more efficient index structure ?
So what if it's pointless rebuilding an index with a height of 4 but another index with a height of 3 is a perfect candidate to be rebuilt ?
Perhaps knowing just the height of an index leaves one totally clueless after all as to whether the index might benefit from an index rebuild ...
Cheers
Richard Foote
http://richardfoote.wordpress.com/

Archiver Import & Indexing is running very slow

Dear All,
We have OracleTextSearch search engine configured for Metadata only indexing. The server specs for application and database machines are way high & underutilized.
FileStoreProvider is used to store content in WEBLESS mode on a filesystem.
Our Archiver Exports are quite fast but Imports are pathetically slow. We suspect that the Indexing is the culprit.
Indexer is configured for 25 items per batch, 1000 items per checkpoint.
What various factors do you think can slow down the Indexer?
We have several content stuck in GENWWW due to an earlier bug in DIS Outlook integration. Could those be an issue and is there a way to move them to released state.
Regards,
Prateek

Hi Prateek,
I'm a bit confused with this statement "We have OracleTextSearch search engine configured for Metadata only indexing." OracleTextSearch is a full text indexer. How would you configure OTS itself as "metadata only" indexing? I would think that instead of using OTS, it would be more efficient to set the SearchIndexerEngine to "DATABASE.METADATA". Maybe this is the case already, but I'm just puzzled by the statement.
Indexing just metadata, though, should not be that performance intensive. There are a couple of things that jump out.
- File system access with regards to read/write. Even though you are using a webless state for STORAGE, the actual files being indexed would have to be resident on the file system during the indexing operation (unless the process has changed, which I don't think is the case, as the items are not indexed directly within the database itself. This would be true even though it's meta-only. It's just the way the product is written as I recall). You then would be subject to any other file system limitations, such as sufficient space, virus scanning, etc. Keep in mind that a txt file with the index value gets written, and this txt file is processed in the index insert/update operation. Slow writes/reads of this file would affect the process.
I point out the file system since the observation was made that the system is relatively underutilized. I've seen many high-end processor/memory configurations get sabotaged with slow disk/SAN/NAS access.
- Database access/performance. If searches are slow in addition to the indexing being slow, I'd think you'd be well served by looking at the database for some maintenance operation, like recomputing statistics, rebuilding indexes, etc.

Index and partition not visible !!!

Hello,
I am creation a table with partition by range and primary key constraint like
CREATE TABLE employees
(employee_id NUMBER(4) NOT NULL,
last_name VARCHAR2(10),
department_id NUMBER(2),
CONSTRAINT SUP_EMP_PK
PRIMARY KEY
(employee_id,department_id)
PARTITION BY RANGE (department_id)
(PARTITION employees_part1 VALUES LESS THAN (10) TABLESPACE DATA_003_P001_HUB3);
but when I query the user_ind_partitions as
select * from user_ind_partitions where partition_name='employee_part1';
it returns nothing
Why is this problem coming up?
Help..
Regards
Abhinav

Actually the problem statement is:
I have table as :
CREATE TABLE SUPERVISION_BPS
ID NUMBER NOT NULL,
servicetype NUMBER NOT NULL,
type VARCHAR2(6 BYTE) NOT NULL,
insertDate DATE NOT NULL,
filename VARCHAR2(100 BYTE) NOT NULL,
numberOK NUMBER NOT NULL,
numberKO NUMBER NOT NULL,
numberCRE NUMBER NOT NULL,
numberUPD NUMBER NOT NULL,
numberDEL NUMBER NOT NULL,
CONSTRAINT SUP_BPS_PK
PRIMARY KEY
(ID, servicetype, type)
using index local
TABLESPACE DATA_003_P001_HUB3
PARTITION BY RANGE (InsertDate)
PARTITION "PARTITION_LAST" VALUES LESS THAN (MAXVALUE)
create sequence seq_sup_bps start with 1 increment by 1;
The problem is whenever I am deleting a partition as
alter table &1 drop partition &2;
and rebuilding the partition as:
alter index &1 parallel;
alter index &1 rebuild partition &2 compute statistics;
alter index &1 noparallel;
based on unused indexes
select user_ind_partitions.index_name || '|' || user_ind_partitions.partition_name
from user_indexes, user_ind_partitions
where user_indexes.index_name=user_ind_partitions.index_name
and user_ind_partitions.status='UNUSABLE'
and upper(user_indexes.table_name)='&2';
Now when the entry for the same primary key takes place, it gives an error putting the same value again.
Kindly help
Tried all bit have not found the solution.
Note: have tried removing UNUSABLE check but how to get it done as per the need.
Regards
Abhinav
Edited by: user8744860 on Jul 2, 2012 2:35 AM

Performance problem because of ignored index

Hi,
We have a performance problem with kodo ignoring indexes in Oracle:
Our baseclass of all our persistent classes (LogasPoImpl) has a subclass
CODEZOLLMASSNAHMENIMPL.
We use vertical mapping for all subclasses and have 400.000 instances of
CODEZOLLMASSNAHMENIMPL.
We defined an additional index on an attribute of CODEZOLLMASSNAHMENIMPL.
A query with a filter like "myIndexedAttribute = 'DE'" takes about 15
seconds on Oracle 8.1.7.
Kodo logs something like the following:
[14903 ms] executing prepstmnt 6156689 SELECT (...)
FROM CODEZOLLMASSNAHMENIMPL t0, LOGASPOIMPL t1
WHERE (t0.myIndexedAttribute = ?)
AND t1.JDOCLASS = ?
AND t0.JDOID = t1.JDOID
[params=(String) DE, (String)
de.logas.zoll.eztneu.CodeZollMassnahmenImpl] [reused=0]
When I execute the same statement from a SQL-prompt, it takes that long as
well, but when I swap the tablenames in the from part
(to "FROM LOGASPOIMPL t1, CODEZOLLMASSNAHMENIMPL t0") the result comes
immediately.
I've had a look at the query plans, oracle creates for the two statements
and found, that our index on myIndexedAttribute is not used
by the first statement, but it is by the second.
How can I make Kodo use the faster statement?
I've tried to use the "jdbc-indexed" tag, but without success so far.
Thanks,
Wolfgang

Thank you very much, Stefan & Alex.
After computing statistics the index is used and the performance is fine
now.
- Wolfgang
Alex Roytman wrote:
ANALYZE TABLE MY_TABLE COMPUTE STATISTICS;
"Stefan" <[email protected]> wrote in message
news:btlqsj$f18$[email protected]..
When I execute the same statement from a SQL-prompt, it takes that longas
well, but when I swap the tablenames in the from part
(to "FROM LOGASPOIMPL t1, CODEZOLLMASSNAHMENIMPL t0") the result comes
immediately.
I've had a look at the query plans, oracle creates for the twostatements
and found, that our index on myIndexedAttribute is not used
by the first statement, but it is by the second.
How can I make Kodo use the faster statement?
I've tried to use the "jdbc-indexed" tag, but without success so far.I know that in DB2 there is a function called "Run Statistics" which you
can (and should do) on all tables involved in a query (at least once a
month, when there are heavy changes in the tables).
On information gathered by this statistics DB2 can optimize your queries
and execution path's
Since I was once involved in query performance optimizing on DB/2 I can
say you can get improvements of 80% on big tables on which statistics are
run and not. (Since the execution plans created by the optimizer differ
heavily)
Since I'm working now with Oracle as well, at least I can say, that Oracle
has a featere like statistics as well. (go into the manager enterprise
Console and click on a table, you will find a row "statisitics last run")
I don't know how to trigger these statistics nor whether they would
influence the query execution path on oracle (thus "swapping" tablenames
by itself), since I didn't have time to do further research on thatmatter.
But it's worth a try to find out and maybe it helps on you problem ?

Oracle 8i Function-based index

Hi,
i have problem with making Oracle8i to use function-based index. I am using version 8.1.6 Enterprise Edition.
So here is the test I did
CREATE INDEX first_name_index ON customer ( UPPER(first_name)) ;
alter session set QUERY_REWRITE_ENABLED = TRUE;
alter session set QUERY_REWRITE_INTEGRITY=TRUSTED;
ANALYZE TABLE customer COMPUTE STATISTICS;
alter index first_name_index compute statistics;
Everything seemed to be as required by Oracle but it doesn't use this function-based index when I make
select *
from customer
where upper(first_name) like 'J%';
I test it on large table and with table with few hundred rows. I don't have NULLs in that field.
Can anyone help me with this.

I would not create an index to have it prepared for an ORDER BY. An index is quite costly in DML opperations and space as well. More, a function based index will be costlier as the function has to be called for every read and/or write.
Do not forget that indexes a created for a direct access to data and not for sorting purposes.
George

DB Statistics & BI Indexes

Similar Messages

Maybe you are looking for