BW, BRTools, statistics, monitoring and bitmap indexes.
Hi all, I have a question about the above.
Oracle 10.2, Solaris 10, BW 7.00
We have a script that generates statistics weekly on our systems. lately, I have been noticing the following messages in the output after the BRTools statistics job is run:
BR0988W Bitmap index "Index_name" selected for checking statistics - please activate the monitoring attribute for table "Table_name"***
After reading SAPNotes 442395, 588688 & 408527, doing searches of SAPNotes, this forum and other forums such as ITToolbox, the answer to the above is "activate monitoring for the above/all tables". I get this.
My issue is that after seeing warnings or missing/skipped statistics, I will manually run the following
brconnect -u / -c -f stats -t all -p 4 as the SID_ORA user
When I do that, the warning message (BR0988W) does not appear in the output. And if I check the table in Oracle with something like the following:
select tablespace_name, table_name, partitioned, monitoring from all_tables where table_name = '"Table_name"';
The ouput is
TABLESPACE_NAME TABLE_NAME PAR MON
"Tablespace_name" "Table_name" YES YES
which shows that monitoring is activated for the table.
My question is, by running "brconnect -u / -c -f stats -t all -p 4" was monitoring turned on? This would mean that I would not have to run the script suggested in 408527. Or can the BR0988W error be generated even though monitoring is activated.
The next time I see the error in the statistics output, I will run the SQL and check the status of the table before running the BRTools stats update.
Table_name and Index_name are just generic markers. I have checked and confirmed that I have not mistyped actual names when running select statements.
As far as i know this message is outdated with 10g.
Please have a look at this discussion: DB13 - Update Sttats - activate the monitoring attribute for table
Cheers Michael
Similar Messages
-
Diff b/w btree and bitmap index ?
What is the difference between btree and bitmap index ?
which one to used and when.
how they are differ from each other.you'd love to see
http://www.oracle.com/technology/pub/articles/sharma_indexes.html -
Refreshing Materialized View and (Bitmap) indexes
In my data warehouse I have an MV that is re-built every night.
1. Initially it was fully refreshed, but dropping and re-creating was shown to be quicker as a general rule
2. It was sometimes sensitive to changes in the underlying objects
3. Its has union alls in it so is complex
It has 6 indexes (4 bitmap and 2 b-tree) built on it which take between 8 and 20 minutes each to create. I would like to reduce this time. I'm already doing the index creation as parallel jobs.
I can re-organise the underlying tables so that the MV is no longer complex, and put an MV log on, to enable a fast refresh. Then, ideally, the indexes can be permanent But I know that bitmap indexes don't like certain changes (they can multiply in size an become unusable). Does this include refreshes of MVs? If it does I might be able to switch to b-tree indexes as our report performance is well within the allowable window, unlike my nightly ETL.
The MV has 160M rows in it and the rate of change is rarely more than 1%/day
I'm on 9i<Initially it was fully refreshed, but dropping and re-creating was shown to be quicker as a general rule >
Huh? I wouldn't think that a drop and recreate would be any faster, but won't argue with your results. I assume the same events happen for both and take the same amount of time, with the drop/refresh promoting fragmentation.
< It was sometimes sensitive to changes in the underlying objects >
Yup. All kinds of views are, even real ones. I've found that on 10g MVs are also very tempermental
< Simplest answer from me is that I will go for a fast refresh with MV logs. >
I'm not sure you can fast refresh a query with UNIONS. There's a list of restrictions for fast refreshes that's so long I can't keep track of all the rules.
< would you drop and recreate the bitmp indexes either side of the fast refresh? >
If you're doing a fast refresh you shoud not need to.
You might also consider using the NOLOGGING option on index dropping recreation, used to turn archivel logging off. Since you won't be restoring a failed index creation in case of database failure anyway it should be fairly safe.
Also, when creating the bitmaps make sure you're allocating enough memory to the process. Check your initialization/session parameters, particularly the ones pertianing to bitmap indexes.
Message was edited by:
riedelme -
Difference between btree index and bitmap index
i knw btree is the default index.but what's are the other difference present.
21 characters and 10 seconds at google:
http://www.akadia.com/services/ora_bitmapped_index.html
http://www.oracle.com/technology/pub/articles/sharma_indexes.html
http://www.dba-oracle.com/art_9i_indexing.htm
Dim -
I'm trying to understand why Oracle 8.1.6 sometimes uses bitmap indexes sometimes not.
Of course I have all the statistics, my bitmap indexes are valid and so on.
The problem is this:
- I have a customer table very very large
- I have many columns with bitmap indexes
- I run this statement:
select education_key, count(*)
from customer
group by education_key
and obtain a correct execution plan:
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=235 Card=5 Bytes=10)
1 0 SORT (GROUP BY NOSORT) (Cost=235 Card=5 Bytes=10)
2 1 BITMAP CONVERSION (COUNT)
3 2 BITMAP INDEX (FULL SCAN) OF 'CL_EDU'
with the use of the bitmap indexes (only five different values)
- now I want to put a condition on a column
which has a bitmap index.
The new statement is:
select education_key, count(*)
from customer
where age_key = 30
group by education_key
No join, only a scan of a sort of
fact table. In this case Oracle
doesn't use the bitmap index on
education_key:
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3458 Card=5 Bytes=20
1 0 SORT (GROUP BY) (Cost=3458 Card=5 Bytes=20)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'CUSTOMER' (Cost=3395 C
ard=18296 Bytes=73184)
3 2 BITMAP CONVERSION (TO ROWIDS)
4 3 BITMAP INDEX (SINGLE VALUE) OF 'CL_AGE'
With this execution plan Oracle has to
read some blocks from the table when I
think that using both the bitmap indexes
the query is faster.
Someone knows why Oracle has this
behaviour? I'm trying to change
many things (also altering statistics
value), but it seems that with a
condition Oracle doesn'use the bitmap
index on the group by column.
nullHi Michael, what is the address for the lasagne? ....
In init.ora.parms I had 32Mb for bitmap index merge, I suppose it's enough, hovewer I have tried to increase it and nothing changes.
I already use STAR_TRASFORMATION_ENABLED=TRUE.
I have tried with different level of statistics (estimate, compute, also with very precise histograms), always the same
behaviour. I have also tried to change, in a manual way, the statistics in order to change the Oracle behaviour but nothing ...
For this particular statement even if I use the INDEX_COMBINE hint, I mantain the same execution plan.
I use CHOOSE, FIRST_ROWS, ALL_ROWS: always the same behaviour.
I think that Oracle is not able to use a bitmap index on a column involved in a group by when there is another condition in the select.
Hovewer with bitmap indexes, I have many other problems (to read 1% of the table Oracle decides to make a full table scan even if there are the correct bitmap indexes ...).
Many of them are solved using BITMAP_INDEX, but it's difficult to use it in a query tool like Discover or Business Objects because I have to fix the use of INDEX_COMBINE also in situation in which this use is not correct from a performance point of view.
The life with the query optimizer is very hard!
Thank you for your guesses -
Hi All,
We have one BITMAP index on a flag column (Y/N).Table is non partitioned with 3.4 million records.
Following are index stats.
select INDEX_NAME,INDEX_TYPE,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,CLUSTERING_FACTOR,NUM_ROWS,SAMPLE_SIZE,DEGREE FROM DBA_INDEXES WHERE
INDEX_NAME='LATE_VER_FLG_CAX_IDX' AND OWNER='EQHUB'
INDEX_NAME INDEX_TYPE BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR NUM_ROWS SAMPLE_SIZE DEGREE
LATE_VER_FLG_CAX_IDX BITMAP 11 716 2 72783 72783 72783 1
select last_analyzed,sample_size,num_rows from dba_indexes where index_name='LATE_VER_FLG_CAX_IDX';
LAST_ANALYZED SAMPLE_SIZE NUM_ROWS
31.Jan.09/00:29:41 72783 72783
NAME HEIGHT BLOCKS LF_ROWS LF_BLKS LF_ROWS_LEN BR_ROWS BR_BLKS DEL_LF_ROWS DISTINCT_KEYS BTREE_SPACE USED_SPACE PCT_USED
LATE_VER_FLG_CAX_IDX 12 4352 0 0 1 1 0 0 8028
CREATE BITMAP INDEX "EQHUB"."LATE_VER_FLG_CAX_IDX" ON "EQHUB"."BBO_CORPORATE_ACTIONS" ("LATEST_VERSION_FLAG")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 2097152 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)
TABLESPACE "ETDHUB_EQHUB_INDEX"
SQL> select LATEST_VERSION_FLAG,count(*) from BBO_CORPORATE_ACTIONS group by LATEST_VERSION_FLAG;
L COUNT(*)
N 2265303
Y 1189116I am wondering
1.What can be done to reduce index BLEVEL/HEIGHT? (i assume COALESCE will not help)..Should i rebuild the index?
2.Why BTREE_SPACE is only showing 8028 where dba_segments is showing index size =34 MB?
3.Why PCT_USED is NULL?
Is that so BLEVEL/PCT_USED not relative for BITMAP Indexes?
I found that no query is using this index for last 60 days and performance is getting degraded due to FTS.
Should i REBUILD the index so that i can reduce BLEVEL/HEIGHT/INDEX_SIZE and improve query performance with INDEX ACCESS.
Regards,
Bhavik DesaiBhavik Desai wrote:
You perfectely caught the DML pattern.There are 4 daily ELT jobs which INSERT 300 and UPDATE 250 records/execution.
May i ask you,upon which observation,you point this?Also it would be greate if you tell me how did you calculate 67% PCT_FREE.
This was based on the fact that an update to a single row in a table could result in a copy of an entire bitmap index chunk being made; so you need to leave a lot of space free in the leaf blocks to allow for these copies because you really don't want to cause an index leaf block split to occur - especially since that would tend to cascade up the index and cause a branch block split as well. On this basis, pctfree 51 should be adequate for most cases, but setting it to 67 (a) allows you to do a couple of updates/clones to the same chunk before you hit a problem, and (b) helps to keep the chunks smaller which helps to reduce the undo and redo a bit.
This has just reminded me of a little detail - I am a little surprised by the fact that you got an index into this state in 10.2, because that release of Oracle seems to avoid creating a long chain of clones of the same index chunk when you do a series of small updates, and it is the chain of clones that results in branch blocks split running up the index and exploding it to an enormous height. Has this database been upgraded from 9i (or even 10.1) some time in the fairly recent past ?
>
I still dont understand,
1.Why there is no difference in BTREE_SPACE?
2.Why PCT_USED is NULL?
I've just run a quick test on 10.2.0.1 and 10.2.0.3 creating a table with a y/n/null column and creating a bitmap index on it. The results from index_stats didn't match across versions, and the 10.2.0.3 stats were clearly garbage - very similar to yours. For the moment I would assume that something has been broken in 10.2.0.3 with this use of the validate command.
>
If we consider Franck Pachot's observation,then it would be better to convert the BITMAP to BTREE.Is this a normal bitmap behavior?Randolf's observation about the numbers of rows involved is most relevant: it doesn't look like an index that the optimizer should consider using for anything other than select flag, count(*), and changing from a bitmap to a btree won't make any difference. In other words, unless you can point to an important piece of code and say "it makes tis bit run much better" maybe the index shouldn't exist at all.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The temptation to form premature theories upon insufficient data is the bane of our profession."
Sherlock Holmes (Sir Arthur Conan Doyle) in "The Valley of Fear". -
Does dropping bitmap index and creation of b- index cause any dead locks
Does dropping a bitmap index on table which is being used continuously for DML operations and creation of b- index cause any dead locks on a table
in oracle 10g database
( 10.1.0.4.0 - 64bi).
we have seen alert log file which has dead lock occurrence.. would index change/re-creation resulted dead lock or some other reason?
Could you please give us info or help us on this.. thanks in advance..Bitmap indexes can be the cause of deadlocks on busy systems.
Dropping indexes may cause some locking.
Creating indexes may cause some locking.
You haven't given any traces or scripts or lock information, so difficult to say which one (if any) was the cause of your deadlocks.
It would be better to do this activity when the system is not busy. -
Bitmap Index Not Used in PROD and used in DEV
I am in a situation where in in DEV Bitmap Index is used and in PROD bitmap Index is not used. I checked the count, in PROD I have 10 mil rows and in DEV I have 16 mil rows. Optimizer is CHOOSE and also when I tried to force to use index in PROD, I got higher cost.
Any suggestions why Index is not used in PROD as opposed to DEVAs other says, no guarantee that the same query with same setting OS, ORACLE to produce the same execution plan. Also, as Justin said, dont every take cost as your tuning parameter, pay attention to response time, also, number of logical reads and physical reads. What are the wait events during?
For an index, most important factors are, blevel, clustering_factor, number of distinct values. Clustering actor make a lot of difference. You said, when you force index to use, your performance has gained. If so, why not, why the HINTS there in place? Go ahed and use it, but, after all the R&D. Are the Optimizer* paraemters same on the both databases?
If possible, post the execution plan of the query, with HINT and without HINT as well.
Jaffar -
Bitmap indexes have effect on query execution and equation of values.
Hi,
I have a Fact table and 17 dimension tables linked to it. On each foreign-key in the Fact-Table I have created a BITMAP Index. After that I Analyzed the fact table and made sure that the referential constraints were valid.
Everything seem to be OK until I ran into a difference in totals when using the next 2 queries that should both result into the same total amount.
Query 1:
Below query is resulting in a wrong total amount and seems to be cartesian.
SELECT SUM(F.DOLLARS)
FROM SALES_FACTS F
, DIM_TIME A
, DIM_CUSTOMER B
, DIM_SALESAGENT C
, DIM_SALESTYPE D
, DIM_GEOGRAFIC E
WHERE F.TIME_ID = A.TIME_ID
AND F.CUST_ID = B.CUST_ID
AND F.SA_ID = C.SA_ID
AND F.ST_ID = D.ST_ID
AND F.GEO_ID = E.GEO_ID
AND A.YEAR = '2006'
AND C.SALESNUM = '3770'
AND D.ST_ID <> '4'
Query 2:
Qeury 2 is the same as query 1 exept the the type of sales (D.ST_ID) is now set with in a range of allowed values. This query gives the correct result.
SELECT SUM(F.DOLLARS)
FROM SALES_FACTS F
, DIM_TIME A
, DIM_CUSTOMER B
, DIM_SALESAGENT C
, DIM_SALESTYPE D
, DIM_GEOGRAFIC E
WHERE F.TIME_ID = A.TIME_ID
AND F.CUST_ID = B.CUST_ID
AND F.SA_ID = C.SA_ID
AND F.ST_ID = D.ST_ID
AND F.GEO_ID = E.GEO_ID
AND A.YEAR = '2006'
AND C.SALESNUM = '3770'
AND D.ST_ID in ('1','2','3','5') In my situation it seems that when I use the <> (not equal to) symbols in combination with the bitmap indexes, that the result of the sum becomes cartesian and thus incorrect.
Has anyone an idea why the calculation of the total amount is different in both queries?
Any help is very appreciated.
Regards, IlonaAnother strange effect is when I leave out the quotation around the not equal to 4 for the Sales_type id (ST_ID <> 4 in stead op ST_ID <> '4' ) then the totals is perfect.
Query 1 version without quotations around ST_ID:
SELECT SUM(F.DOLLARS)
FROM SALES_FACTS F
, DIM_TIME A
, DIM_CUSTOMER B
, DIM_SALESAGENT C
, DIM_SALESTYPE D
, DIM_GEOGRAFIC E
WHERE F.TIME_ID = A.TIME_ID
AND F.CUST_ID = B.CUST_ID
AND F.SA_ID = C.SA_ID
AND F.ST_ID = D.ST_ID
AND F.GEO_ID = E.GEO_ID
AND A.YEAR = '2006'
AND C.SALESNUM = '3770'
AND D.ST_ID <> 4 I still have no clue what causes this effect.
Regards, Ilona -
Bitmap index and group by queries
Please could someone offer me some advice for a data warehouse table I am designing which will have ad hoc queries running against it mainly grouping by day/month/year and needs to use as little resources as possible.
TRANS_DATE DATE, LOC_ID VARCHAR2(8), USER_ID VARCHAR2(8), TRANS_CODE VARCHAR2(3), COUNT NUMBER(8,0)
In populating the table I truncated the trans_date to hourly data and aggregated the other columns to give me an hourly count for every combination of location, user and code. I wasn't sure if I should create 2 more columns with truncated dates by day and by month? There are 200,000 rows per day in this table.
The first 4 columns have low cardinality so I decided to create Bitmap indexes on them. However, when querying in Application Express SQL Workshop and looking at the query plan it seems that a full table scan is being performed whenever I use a group_by(example below), even when i use a hint for the index. The bitmap index is used on simple select queries with where clauses but no grouping.
SELECT LOC_ID, count(TOTAL)
FROM TRANS_SUMMARY
GROUP BY LOC_ID
Am I doing this the right way? Or would multiple materialised views / btree indexes be a better way of ensuring fast group_by queries on this table?
Thanks in advance.
PaulYou don't need a separate materialized view for every combination. You may need a few carefully chosen combinations, in addition to appropriate dimensions for rollups.
For example, a materialized view that aggregated dat based on location_id, trans_code, and hour could be used to aggregate by location_id, trans_code and day (i.e. adding up 24 rows from the MV for each trans_code and location_id) or location_id, trans_code and month (i.e. adding 24*30 rows from the MV for each trans_code and location_id). The more rows you have to aggregate, and the more frequently the higher level aggregates are accessed, the more likely you'd want to have a separate MV that aggregates at the higher level (i.e. if you're accessing monthly summary data totals all the time).
If you are rarely aggregating by trans_code, and you have lots of different trans_code values, you could use the one MV that aggregated by location_id, trans_code, and hour to do a monthly aggregate just on location_id and month, but that requires adding 24*30*# trans_code rows from the MV, which may be expensive. It may make sense to have a separate MV for that, or a set of MV's that are aggregated just by location_id and day, or some combination.
Justin -
DB 13 Message logs BR0988W Bitmap index /BI0/F0COPC_C08~08 selected for che
Dear Exprts,
We are getting following error in DB13 check DB, our server is BW Test and version BW3.5.
Kindly Suggest.
BR0988W Bitmap index /BI0/F0COPC_C08~08 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0CO
BR0988W Bitmap index /BI0/F0LSO_C01~020 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0LS
BR0988W Bitmap index /BI0/F0LSO_C02~050 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0LS
BR0988W Bitmap index /BI0/F0PAPA_C02~11 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0PA
BR0988W Bitmap index /BI0/F0PE_C01~050 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0PE_
BR0988W Bitmap index /BI0/F0PE_C02~050 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0PE_
BR0988W Bitmap index /BI0/F0PE_C03~050 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BI0/F0PE_
BR0988W Bitmap index /BIC/FC_0IC_C03~11 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_0
BR0988W Bitmap index /BIC/FC_0SD_C03~12 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_0
BR0988W Bitmap index /BIC/FC_AS_ROM~060 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_A
BR0988W Bitmap index /BIC/FC_BOL_BU~900 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_B
BR0988W Bitmap index /BIC/FC_BOL_DBL~07 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_B
BR0988W Bitmap index /BIC/FC_BOL_RTL~07 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_B
BR0988W Bitmap index /BIC/FC_CUST_MA~04 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_C
BR0988W Bitmap index /BIC/FC_FRSRCP~110 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_F
BR0988W Bitmap index /BIC/FC_HITMISL~08 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_H
BR0988W Bitmap index /BIC/FC_HITMISS~08 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_H
BR0988W Bitmap index /BIC/FC_MRL_RTL~06 selected for checking statistics - please activate the monitoring attribute for table SAPBWD./BIC/FC_M
Regards
YogeshHi,
check SAP Note Note 442395 - Descriptions of specific BR messages
search for BR0988W in note.
then Activate the MONITORING attribute for the table in question as per note.
also check Note 408527 - Checking the statistics using DBA_TAB_MODIFICATIONS
regards,
kaushal -
All,
I have Dataware house environment. I have bitmap index in all the dimension id's in fact table. Here is the query. This query took 10 min... It is not affordable time.
Any help?..
SELECT count(*)
FROM quote a, enterprise_sales_det_fact b, orders c
WHERE a.quote_dim_sid = b.quote_dim_sid
AND b.order_dim_sid = c.order_dim_sid
We have bit map index on quote_dim_sid & order_dim_sid .
Here is the analyze statement i used.
exec dbms_stats.gather_table_stats(ownname => 'QUOTEPRD', tabname => 'ORDERS',estimate_percent => 10, method_opt => 'FOR ALL COLUMNS SIZE 1',cascade => true);
Step # Step Name
12 SELECT STATEMENT
11 SORT [AGGREGATE]
10 NESTED LOOPS
8 NESTED LOOPS
6 . VIEW
5 HASH JOIN
2 BITMAP CONVERSION [TO ROWIDS]
1 QUOTEPRD.ENT_FACT_ORDER_BIDX BITMAP INDEX [FULL SCAN]
4 BITMAP CONVERSION [TO ROWIDS]
3 QUOTEPRD.ENT_FACT_QUOTE_BIDX BITMAP INDEX [FULL SCAN]
7 QUOTEPRD.QUOTE_UIDX INDEX [UNIQUE SCAN]
9 QUOTEPRD.ORDERS_UIDX INDEX [UNIQUE SCAN]
Step # Description Est. Cost Est. Rows Returned Est. KBytes Returned
1 This plan step retrieves one or more ROWIDs by scanning all bits in the bitmap index ENT_FACT_ORDER_BIDX to find the rows which satisfy a condition specified in the querys WHERE clause. -- -- --
2 This plan step accepts a bitmap representation of an index from its child node, and converts it to a ROWID that can be used to access the table.
3 This plan step retrieves one or more ROWIDs by scanning all bits in the bitmap index ENT_FACT_QUOTE_BIDX to find the rows which satisfy a condition specified in the querys WHERE clause. -- -- --
4 This plan step accepts a bitmap representation of an index from its child node, and converts it to a ROWID that can be used to access the table.
5 This plan step accepts two sets of rows, each from a different table. A hash table is built using the rows returned by the first child. Each row returned by the second child is then used to probe the hash table to find row pairs which satisfy a condition specified in the query's WHERE clause. Note: The Oracle cost-based optimizer will build the hash table using what it thinks is the smaller of the two tables. It uses the statistics to determine which is smaller, so out of date statistics could cause the optimizer to make the wrong choice. -- 27,037,540 290,442.324
6 This plan step represents the execution plan for the subquery defined by the view . 26,527 27,037,540 290,442.324
7 This plan step retrieves a single ROWID from the B*-tree index QUOTE_UIDX. -- 1 0.007
8 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 26,528 27,037,540 475,269.258
9 This plan step retrieves a single ROWID from the B*-tree index ORDERS_UIDX. -- 1 0.007
10 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 26,529 27,037,540 660,096.191
11 This plan step accepts a row set (its only child) and returns a single row by applying an aggregation function. -- 1 0.024
12 This plan step designates this statement as a SELECT statement. 26,529 -- --All, i forgot to give one more information about table count.
enterprise_sales_det_fact table has 30 million. quote has 2 million, orders has 3 millions. FYI.
Regards
Govind -
Peformance tuning of query using bitmap indexes
Hello guys
I just have a quick question about tuning the performance of sql query using bitmap indexes..
Currently, there are 2 tables, date and fact. Fact table has about 1 billion row and date dim has about 1 million. These 2 tables are joined by 2 columns:
Date.Dateid = Fact.snapshot.dates and Date.companyid = fact.companynumber
I have query that needs to be run as the following:
Select dates.dayofweek, dates,dates, fact.opened_amount from dates, facts
where Date.Dateid = Fact.snapshot.dates and Date.companyid = fact.companynumber and dates.dayofweek = 'monday'.
Currently this query is running forever. I think it is joining that takes a lot of time. I have created bitmap index on dayofweek column because it's low on distinctive rows. But it didn't seem to speed up with the performance..
I'd like to know what other indexes will be helpful for me.. I am thinking of creating another one for companynumber since it also have low distinctive records.
Currently the query is being generated by frontend tools like OBIEE so I can't change the sql nor can't I purge data or create smaller table, I have to what with what I have..
So please let me know your thoughts in terms of performance tunings.
ThanksThe explain plan is:
Row cost Bytes
Select statement optimizer 1 1
nested loops 1 1 299
partition list all 1 0 266
index full scan RD_T.PK_FACTS_SNPSH 1 0 266
TABLE ACCESS BY INDEX ROWID DATES_DIM 1 1 33
INDEX UNIQUE SCAN DATES_DIM_DATE 1 1
There is no changes nor wait states, but query is taking 18 mins to return results. When it does, it returns 1 billion rows, which is the same number of rows of the fact table....(strange?)That's not a bitmap plan. Plans using bitmaps should have steps indicating bitmap conversions; this plan is listing ordinary btree index access. The rows and bytes on the plan for the volume of data you suggested have to be incorrect. (1 row instead of 1B?????)
What version of the data base are you using?
What is your partition key?
Are the partioned table indexes global or local? Is the partition key part of the join columns, and is it indexed?
Analyze the tables and all indexes (use dbms_stats) and see if the statistics get better. If that doesn't work try the dynamic sampling hint (there is some overhead for this) to get statistics at runtime.
I have seen stats like the ones you listed appear in 10g myself.
Edited by: riedelme on Oct 30, 2009 10:37 AM -
Hi,
I'm running the following query:
SELECT
FLOW.PRODUCT_CODE,
FLOW.CUSTOMER_SK,
FLOW.BRAND_SK,
26,
FLOW.MPR_SK
FROM
RSB_FACT_FLOW_SD FLOW,
RSB_DIM_FLOW DIM
WHERE
FLOW.FLOW_SK = DIM.FLOW_SK
AND DIM.FLOW_ID = 'CFRD'
AND FLOW.PRODUCT_CODE = 'G'
AND FLOW.FLOW_DATE >= '01 JAN 2006'
AND FLOW.FLOW_DATE <= '31 JAN 2006'
AND EXISTS
( SELECT 1
FROM RSB_FACT_FLOW_SD A,
RSB_DIM_FLOW B
WHERE
A.MPR_SK = FLOW.MPR_SK
AND A.RECEIVED_DATE >= FLOW.RECEIVED_DATE
AND B.FLOW_SK= A.FLOW_SK
AND B.FLOW_ID= 'WAO2'
AND A.REASON= '02CRO'
I get ORA-00904: "FLOW"."RECEIVED_DATE": invalid identifier
This is the defintion of the table:
CREATE TABLE RSB_FACT_FLOW_SD
PRODUCT_CODE CHAR(1) NOT NULL,
WEEK_END_DATE DATE NOT NULL,
CUSTOMER_SK NUMBER(10) NOT NULL,
CUSTOMER_ATTRIBUTE_SK NUMBER(10) NOT NULL,
MPR_SK NUMBER(10) NOT NULL,
MPR_PROFILE_SK NUMBER(10) NOT NULL,
SPECCOND_PROFILE_SK NUMBER(10) NOT NULL,
BRAND_SK NUMBER(10) NOT NULL,
FLOW_SK NUMBER(10) NOT NULL,
FLOW_DATE DATE,
RECEIVED_DATE DATE,
VALIDATION_STATUS CHAR(1),
FLOW_TYPE CHAR(1),
RECEIVED_FROM_SENT_TO VARCHAR2(4),
REASON VARCHAR2(255),
FLOW_SEQUENCE NUMBER,
CUSTOMER_SEGMENT_SK NUMBER(10),
BRAND_PARTNER_SK NUMBER
TABLESPACE DW_DATA
PCTUSED 90
PCTFREE 0
PARALLEL
LOGGING;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX01 ON RSB_FACT_FLOW_SD
(PRODUCT_CODE) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX02 ON RSB_FACT_FLOW_SD
(WEEK_END_DATE) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX03 ON RSB_FACT_FLOW_SD
(CUSTOMER_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX04 ON RSB_FACT_FLOW_SD
(CUSTOMER_ATTRIBUTE_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX05 ON RSB_FACT_FLOW_SD
(MPR_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX06 ON RSB_FACT_FLOW_SD
(MPR_PROFILE_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX07 ON RSB_FACT_FLOW_SD
(SPECCOND_PROFILE_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX08 ON RSB_FACT_FLOW_SD
(BRAND_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX09 ON RSB_FACT_FLOW_SD
(FLOW_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX10 ON RSB_FACT_FLOW_SD
(RECEIVED_DATE) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX11 ON RSB_FACT_FLOW_SD
(FLOW_DATE) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX12 ON RSB_FACT_FLOW_SD
(CUSTOMER_SEGMENT_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
CREATE BITMAP INDEX RSB_FACT_FLOW_SD_IX13 ON RSB_FACT_FLOW_SD
(BRAND_PARTNER_SK) TABLESPACE DW_INDEXES PARALLEL PCTFREE 0 NOLOGGING COMPUTE STATISTICS;
If I drop the indexes on the table then the error goes away.
Any ideas??
Sheena( SELECT 1
FROM RSB_FACT_FLOW_SD A,
RSB_DIM_FLOW B
WHERE
A.MPR_SK = FLOW.MPR_SK
AND A.RECEIVED_DATE >= FLOW.RECEIVED_DATE =====>>>>
AND B.FLOW_SK= A.FLOW_SK
AND B.FLOW_ID= 'WAO2'
AND A.REASON= '02CRO'
Your sub query has the problem.
You didn't list flow table in the subquery, therefore, you subquery, dont understand about the column.
specify flow table in the subquery.
Your outquery tables doesn't recognized in the sub query.
Jaffar -
Hi,
I am using Oracle 10.2.0.3.0 on Solaris 5.10.
I have a range based partition table with 60 partitions. This is a fact table. I have to load 60 days data in this table. I have created a partition for each day and the partition key is the date column. I created the table with partition, but didn't create the local bitmap index on the partition key vdate, because as far as I know oracle makes the local bitmap index unusable before the insert and then we have to rebuild it after the load. Is that right?
So the better strategy is to first load the data in the partition and then create a local bitmap index on that partition, is that right?
For instance, in future, some rows get inserted in an existing partition where the local bitmap index is present, so then I should once again rebuild the index on that partition, because in case of insert Oracle would have disabled it?
In this table there is another column vactivity, which is a foreign key from a dimension. Many queries use this column in there where clause. I would also like to create a bitmap index on this column? On this non partitioned key column, the local bitmap index should be created. Is that right?
Please also suggest as which is more faster, rebuilding a local bitmap index after rendering it unusable, or dropping and recreating it?
Thanks and best regardsThe more I know, the more I know that how little I know. Thanks Jonathan for a very insightful answer. Please clarify some points and thanks for your valuable feedback.
Jonathan Lewis wrote:
Fahd Mirza wrote:
Hi,
I am using Oracle 10.2.0.3.0 on Solaris 5.10.
I have a range based partition table with 60 partitions. This is a fact table. I have to load 60 days data in this table. I have created a partition for each day and the partition key is the date column. I created the table with partition, but didn't create the local bitmap index on the partition key vdate, because as far as I know oracle makes the local bitmap index unusable before the insert and then we have to rebuild it after the load. Is that right?
That may depend on the software you use to load the data, it's not a necessity from the perspective of the database.I am using Oracle Warehouse Builder to load the data into the database.
>
So the better strategy is to first load the data in the partition and then create a local bitmap index on that partition, is that right?
Depends on the tools, and whether there is data in the table already - but Oracle will optimise index maintenance for bulk inserts in a way which means that it isn't necessary to worry about dropping/recreating if the index already exists and the table is empty.There is no data in the partitions prior to loading.
You may find that with one index it's more efficient to create the index with a lot of free space (51%, say) and leave it at that while another index works better if you mark unusable and rebuild.
Would you please elaborate on this point?
>
>>
In this table there is another column vactivity, which is a foreign key from a dimension. Many queries use this column in there where clause. I would also like to create a bitmap index on this column? On this non partitioned key column, the local bitmap index should be created. Is that right?
Your question raise more questions:
a) Does this mean you are only going to have a maximum of two bitmap indexes on this fact table with 60 million rows ? That doesn't sound like it's enough indexes.No, I will create local bitmap indexes on other columns too, which are likely to be used in the adhoc queries.
b) Are you hoping that the vactivity bitmap index will protect you against foreign key locking ? It won't. This (in part) is why people tend to set FK's to disable, novalidate, rely in data warehouses, they want bitmap indexes not btree indexesActually I haven't created the FK constraint.
d) Going back to the bitmap index on the date - is this column storing values that are date-only, or is it storing "date with time". If it's date-only then you've only got one date per partition and the index is a waste of space and processing overhead.The datatype of the column vdate is number. Actually it is refering to the pk of time dimension, in which we have preloaded the dates for the next ten years. Would the index be a total waste on this column?
>
>
Please also suggest as which is more faster, rebuilding a local bitmap index after rendering it unusable, or dropping and recreating it?
Here is the table. I have omitted many partitions for the sake of brevity:
CREATE TABLE CDR
CLNG_NMBR NUMBER,
CL_RFRNC_NMBR VARCHAR2(100 BYTE),
DT_KY NUMBER,
TM_KY NUMBER,
HRLY_KY NUMBER,
ACTVTY_KY NUMBER,
INS_DT DATE,
SRVC_ID VARCHAR2(100 BYTE),
MSC_ADRS VARCHAR2(100 BYTE),
TRF_ID NUMBER,
CL_TYP NUMBER,
LCTN_INFRMTN VARCHAR2(100 BYTE),
LCTN_KY NUMBER,
SRC_CLNG_NMBR VARCHAR2(50 BYTE),
ACTVTY_CL_TP VARCHAR2(100 CHAR)
PARTITION BY RANGE(DT_KY)
PARTITION DAY_20DEC2009 VALUES LESS THAN (4153),
PARTITION DAY_21DEC2009 VALUES LESS THAN (4154),
PARTITION DAY_22DEC2009 VALUES LESS THAN (4155),
PARTITION DAY_23DEC2009 VALUES LESS THAN (4156),
PARTITION DAY_24DEC2009 VALUES LESS THAN (4157),
PARTITION DAY_25DEC2009 VALUES LESS THAN (4158),
PARTITION DAY_26DEC2009 VALUES LESS THAN (4159),
PARTITION DAY_27DEC2009 VALUES LESS THAN (4160),
PARTITION DAY_28DEC2009 VALUES LESS THAN (4161),
PARTITION DAY_31DEC2011 VALUES LESS THAN (4894),
PARTITION DAY_END_PART VALUES LESS THAN (MAXVALUE)
TABLESPACE cdr
PCTUSED 0
PCTFREE 10
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 80K
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
BUFFER_POOL DEFAULT
NOLOGGING
NOCOMPRESS
NOCACHE
NOPARALLEL
MONITORING;Many many thanks and best regards
Fahd
Edited by: Fahd Mirza on Jun 3, 2010 2:00 PM
Edited by: Fahd Mirza on Jun 3, 2010 2:03 PM
Maybe you are looking for
-
Printer not working following iPad uodate
Printer not working following iPad upgrade
-
Extended Withholding Tax & MIRO - total balance
I have the following situation: Extended withholding tax is active in company code and the withholding tax type is defined for invoice posting. Everything seems to work correctly except for the following detail: if the invoice has additional charges
-
Narration stops briefly, then resumes. Why?
Why does the audio stop during a narration? I recorded and edited narration for a Keynote presentation in Garage Band, exported to iTunes, converted to mp3. Then I dropped the narration file into the audio well in Keynote. I recorded the presentation
-
Hindi language is not supported on bb 8520
I am from india using vodafone as service provider. My device is 8520. I am not able to read mail in HINDI language. How can I solve the problem ?
-
Audio content is different on iPhone and iPad
There are about 2 gbs of files that don't make it into my ipad but do make it into my iPhone, although the settings appear to be the same. Can I fix?