Bad performance "CREATE BITMAP INDEX"
Hi,
i just create a bitmap index on a fact table with ~90.000.000 entries. The indexed table is the artice dimension with a cardinality of about 900.000 articles.
The process is running since 24 hours with a parallel degree of 4, 3 slaves finished their work, only one is still collecting/sorting. PGA_AGGREGATE_TARGET is 4 GB.
Oralce has allocated a temporary segment in the temp. tablespace which has a size of 760 MB up to now.
Any idea how to speed up the process except increasing the degree for parallel query ?
Is there a space limit for processes allocating main memory in the PGA. Or is it absolutely impossible to setup Oracle memory for workareas in a way, so that such a big bitmap can be created in main memory ? I dont want to switch back to the 8i features CREATE_BITMAP_AREA_SIZE,...
Any hint is welcome, thx in advance...
Paul
Hello,
Please check <Bug:3048661>
Hdr: 3048661 9.2.0.3.0 RDBMS 9.2.0.3.0 RAM INDEX PRODID-5 PORTID-23
Abstract: CREATE BITMAP INDEXES TAKES LONGER IN 9203 WHEN PGA => 2GB
Thanks
Ashish
Similar Messages
-
Bad performance after analyze index
Hi,
I have a range partitioned table which recently I had to added new partitions to. After adding new partitions a particular query I had running on it started doing full table scans instead of using the index.
I read somewhere that you have to disable the primary key prior to adding new partitions and renable after completion. This I did and true, the query was using the index again. However as soon as I analyze the index, the full table scan is back.
I even tried to analyze the table using:
begin
dbms_stats.gather_table_stats
(user,'tablename',
method_opt => 'for all indexes for all indexed columns size auto',
cascade => true);
end;
Still the query doesn't improve.
I am using 9.0.1.3 on Solaris.
Any ideas on this as I'm stuck at the moment.
Thanks!Hello,
Please check <Bug:3048661>
Hdr: 3048661 9.2.0.3.0 RDBMS 9.2.0.3.0 RAM INDEX PRODID-5 PORTID-23
Abstract: CREATE BITMAP INDEXES TAKES LONGER IN 9203 WHEN PGA => 2GB
Thanks
Ashish -
Error while attempting to create bitmap index
I get the error below while creating a bitmap index on a table in SQL Developer.
How do a go about enabling this feature? I looked on Tools | Preferences menu and didn't see anything.
Using Version 1.0.0.14.67
>>>
Error starting at line 1 in command:
CREATE BITMAP INDEX "SYSTEM"."PUB_SRC_INDX_0197_US4" ON "SYSTEM"."PUB_SRC_TBL_0197_US" ("STATUS_ID")
Error report:
SQL Error: ORA-00439: feature not enabled: Bit-mapped indexes
>>>
ThanksNevermind.. I found it on google. You must have an SE version of Oracle which does not support Bitmapped Indexes. You will have to use another index type.
-
Unable to create a bitmap index
Hi,
I want to create a bitmap index on one of the colums on a table. I fired following query and it failed.
SQL> CREATE BITMAP INDEX TRANS_N_BITMAPIDX_VEH_PLATFORM ON TRANSACTION_NEW(VEH_PLATFORM) LOCAL;
Error starting at line 2 in command:
CREATE BITMAP INDEX TRANS_N_BITMAPIDX_VEH_PLATFORM ON TRANSACTION_NEW(VEH_PLATFORM) LOCAL
Error at Command Line:2 Column:70
Error report:
SQL Error: ORA-01408: such column list already indexed
01408. 00000 - "such column list already indexed"
*Cause:
*Action:I found there is a combined NORMAL index with VEH_PLATFORM column called ‘IDX$$_30AA00021’. It has following columns
• VEH_PLATFORM
• VEH_MODEL
• MODL_YR_NBR
• VEH_MAKE
• TXN_PROCS_DT
But I was able to create bitmap index on VEH_MODEL,MODL_YR_NBR and VEH_MAKE columns without any error.
Why does it error out for VEH_PLATFORM column?
Regards,
SamHi,
I am sure that BITMAP index is only created for
VEH_MAKE
VEH_MODEL
MODL_YR_NBR
BUILD_REGION
VEH_LINE_SERIES
TRANS_CTG_ID
and not for VEH_PLATFORM.
SQL> SELECT * FROM USER_INDEXES WHERE INDEX_TYPE='BITMAP' AND TABLE_NAME='TRANSACTION_NEW';
INDEX_NAME INDEX_TYPE TABLE_OWNER TABLE_NAME TABLE_TYPE UNIQUENESS COMPRESSION PREFIX_LENGTH TABLESPACE_NAME INI_TRANS MAX_TRANS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE PCT_THRESHOLD INCLUDE_COLUMN FREELISTS FREELIST_GROUPS PCT_FREE LOGGING BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR STATUS NUM_ROWS SAMPLE_SIZE LAST_ANALYZED DEGREE INSTANCES PARTITIONED TEMPORARY GENERATED SECONDARY BUFFER_POOL FLASH_CACHE CELL_FLASH_CACHE USER_STATS DURATION PCT_DIRECT_ACCESS ITYP_OWNER ITYP_NAME PARAMETERS GLOBAL_STATS DOMIDX_STATUS DOMIDX_OPSTATUS FUNCIDX_STATUS JOIN_INDEX IOT_REDUNDANT_PKEY_ELIM DROPPED VISIBILITY DOMIDX_MANAGEMENT SEGMENT_CREATED
TRANS_N_BITMAPIDX_MAKE BITMAP VISUAL TRANSACTION_NEW TABLE NONUNIQUE DISABLED 2 6102 20 305 611 12226 N/A 12226 2208 11-MAY-11 1 1 YES N N N DEFAULT DEFAULT DEFAULT NO YES NO NO NO VISIBLE N/A
TRANS_N_BITMAPIDX_MODEL BITMAP VISUAL TRANSACTION_NEW TABLE NONUNIQUE DISABLED 2 11284 158 71 144 22813 N/A 22813 2321 11-MAY-11 1 1 YES N N N DEFAULT DEFAULT DEFAULT NO YES NO NO NO VISIBLE N/A
TRANS_N_BITMAPIDX_BUILD_REGION BITMAP VISUAL TRANSACTION_NEW TABLE NONUNIQUE DISABLED 2 2911 5 582 1161 5808 N/A 5808 5808 11-MAY-11 1 1 YES N N N DEFAULT DEFAULT DEFAULT NO YES NO NO NO VISIBLE N/A
TRANS_N_BITMAPIDX_MODL_YR_NBR BITMAP VISUAL TRANSACTION_NEW TABLE NONUNIQUE DISABLED 2 2911 5 582 1161 5808 N/A 5808 5808 11-MAY-11 1 1 YES N N N DEFAULT DEFAULT DEFAULT NO YES NO NO NO VISIBLE N/A
TRANS_N_BITMAPIDX_TRANS_CTG_ID BITMAP VISUAL TRANSACTION_NEW TABLE NONUNIQUE DISABLED 2 7547 43 175 359 15457 N/A 15457 2345 11-MAY-11 1 1 YES N N N DEFAULT DEFAULT DEFAULT NO YES NO NO NO VISIBLE N/A
TRANS_N_BITMAPIDX_VEH_LINE_S BITMAP VISUAL TRANSACTION_NEW TABLE NONUNIQUE DISABLED 2 10581 253 41 84 21477 N/A 21477 2247 11-MAY-11 1 1 YES N N N DEFAULT DEFAULT DEFAULT NO YES NO NO NO VISIBLE N/A
6 rows selectedRegards,
Sam -
Multi-column BITMAP index vs. multiple BITMAP indices?
Given the table (simple, made-up example):
CREATE TABLE applicant_diversity_info (
applicant_diversity_id NUMBER(12), PRIMARY KEY(applicant_diversity_id),
apply_date DATE,
ssn_salted_md5 RAW(16),
gender CHAR(1), CHECK ( (gender IS NULL OR gender IN ('M','F')) ),
racial_continent VARCHAR2(30), CHECK ( (racial_continent IS NULL
OR racial_continent IN ('Europe','Africa','America','Asia_Pacific')) ),
ethnic_supergroup VARCHAR2(30), CHECK ( (ethnic_supergroup IS NULL OR ethnic_supergroup IN ('Latin American','Other')) ),
hire_salary NUMBER(11,2),
hire_month DATE,
termination_salary NUMBER(11,2),
termination_month DATE,
termination_cause VARCHAR2(30), CHECK ( (termination_cause IS NULL
OR termination_cause IN ('Resigned','Leave of Absence','Laid Off','Performance','Cause')) )
Oracle (syntactically) allows me to create either one BITMAP index over all four small-cardinality columns
CREATE BITMAP INDEX applicant_diversity_diversity_idx ON applicant_diversity_info (
gender, racial_continent, ethnic_supergroup, termination_reason );
or four independent indexes
CREATE BITMAP INDEX applicant_diversity_gender_idx ON applicant_diversity_info ( gender );
CREATE BITMAP INDEX applicant_diversity_race_idx ON applicant_diversity_info ( raceial_continent );
etc.
What is the difference between the two approaches; is there any meaningful difference in disk-space between the one multi-colum index and the four single-column indexes? Does it make a difference in what the query-planner will consider?
And, if I define one multi-column BITMAP index, does the order of columns matter?>
What is the difference between the two approaches; is there any meaningful difference in disk-space between the one multi-colum index and the four single-column indexes? Does it make a difference in what the query-planner will consider?
And, if I define one multi-column BITMAP index, does the order of columns matter?
>
You may want to read this two-part blog, that answers that exact question, by recognized expert Richard Foote
http://richardfoote.wordpress.com/2010/05/06/concatenated-bitmap-indexes-part-i-two-of-us/
http://richardfoote.wordpress.com/2010/05/12/concatenated-bitmap-indexes-part-ii-everybodys-got-to-learn-sometime/
As with many things Oracle the answer is 'it depends'.
In short the same considerations apply for a concatenated index whether it is bitmap or b-tree: 1) will the leading column usually be in the predicate and 2) will most or all of the index columns be specified in the queries.
Here are some quotes from part 1
>
Many of the same issues and factors in deciding to create a single, multi-column index vs. several, single column indexes apply to Bitmap indexes as they do with B-Tree indexes, although there are a number of key differences to consider as well.
Another thing to note regarding a concatenated Bitmap index is that the potential number of index entries is a product of distinct combinations of data of the indexed columns.
A concatenated Bitmap index can potentially use less or more space than corresponding single column indexes, it depends on the number of index entries that are derived and the distribution of the data with the table.
>
Here is the lead quote from part 2
>
The issues regarding whether to go for single column indexes vs. concatenated indexes are similar for Bitmap indexes as they are for B-Tree indexes.
It’s generally more efficient to access a concatenated index as it’s only the one index with less processing and less throwaway rowids/rows to contend with. However it’s more flexible to have single column indexes, especially for Bitmap indexes that are kinda designed to be used concurrently, as concatenated indexes are heavily dependant on the leading column being known in queries. -
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". -
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 -
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 -
Bitmap index column goes for full table scan
Hi all,
Database : 10g R2
OS : Windows xp
my select query is :
SELECT tran_id, city_id, valid_records
FROM transaction_details
WHERE type_id=101;
And the Explain Plan is :
Plan
SELECT STATEMENT ALL_ROWSCost: 29 Bytes: 8,876 Cardinality: 634
1 TABLE ACCESS FULL TABLE TRANSACTION_DETAILS** Cost: 29 Bytes: 8,876 Cardinality: 634
total number of rows in the table = 1800 ;
distinct value of type_ids are 101,102,103
so i created a bit map index on it.
CREATE BITMAP INDEX btmp_typeid ON transaction_details
(type_id)
LOGGING
NOPARALLEL;
after creating the index, the explain plan shows the same. why it goes for full table scan?.
Kindly share ur idea on this.
Edited by: 887268 on Apr 3, 2013 11:01 PM
Edited by: 887268 on Apr 3, 2013 11:02 PM>
I am sorry for being ignorant, can you please cite any scenario of locking due to bitmap indices? A link can be useful as well.
>
See my full reply in this thread
Bitmap index for FKs on Fact tables
>
ETL is affected because DML operations (INSERT/UPDATE/DELETE) on tables with bitmapped indexes can have serious performance issues due to the serialization involved. Updating a single bit-mapped column value (e.g. from 'M' to 'F' for gender) requires both bitmapped index blocks to be locked until the update is complete. A bitmap index stored ROWID ranges (min rowid - max rowid) than can span many, many records. The entire 'range' of rowids is locked in order to change just one value.
To change from 'M' the 'M' rowid range for that one row is locked and the ROWID must be removed from the range byt clearing the bit. To change to 'F' the 'F' rowid id range needs to be found, locked and the bit set that corresponds to that rowid. No other rows with rowids in the range can be changed since this is a serial operation. If the range includes 1000 rows and they all need changed it takes 1000 serial operations. -
How does OWB deal with bitmap indexes when inserting?
How does OWB 9.2 deal with bitmap indexes on a fact table when records are inserted from a staging table? It seems to me that they are left on the table, while in the 9i Server manuals it says that one should not perform heavy DML in this case, because this slows down the inserts considerably and the indexes can get bloated. Should one define a premapping and postmapping process for removal and recreation of the bitmap indexes?
How handles OWB bitmap indexes in case of PEL and what action should one take then?
Jaap.Hai Japp,
It depends on the volume of the data.
The best way is drop index in pre mapping process and recreate it in post mapping process.
You need to use EXECUTE IMMEDIATE command in the procedure to create or drop indexes.
e.g:
EXECUTE IMMEDIATE 'CREATE BITMAP INDEX INDX_BI_TABLE ON TABLE_NAME(COL_NAME)'
Regards,
Malli -
Hello friends,
Can we use BITMAP Index in RBO (Rule Based Optimizer) ?
I tested on my development database, the result always FULL TABLE SCAN.
Please look at this:
SQL> show parameter optimizer_mode;
NAME TYPE VALUE
optimizer_mode string RULE
SQL> SET AUTOTRACE ON
SQL> SELECT optn1 FROM C46010.BOXINVTRY WHERE BEQUIP = 'M';
261164 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=RULE
1 0 TABLE ACCESS (FULL) OF 'BOXINVTRY'
Statistics
0 recursive calls
0 db block gets
42759 consistent gets
466 physical reads
0 redo size
4558130 bytes sent via SQL*Net to client
192162 bytes received via SQL*Net from client
17412 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
261164 rows processed
I created BITMAP index for column BEQUIP on that table because it has low cardinality.
Please advice...
Thanks,
Bayu.Ordinary B-tree index should still do, especially as the general strategy of RBO is 'If there is any index use it' ;)
(also if the index is detrimental to performance)
My experience is in 9i CBO outperforms RBO on many counts.
I would recommend (if you can spare the resources) to setup a test 9i database before you migrate, testing CBO in 9i.
I definitely don't recommend upgrading to 11g (10g is desupported too) without testing it before going production.
Sybrand Bakker
Senior Oracle DBA -
Partitioned IOT of Object Type - mapping table not allowed for bitmap index
Hi,
looks like a feature available for standard Partitioned IOTs is not supported for object based tables, namely the MAPPING TABLE construct to support secondary local bitmap indexes.
Can you confirm behaviour is as expected/documented?
If so, is a fix/enhancement to support mapping table for object-based Partitioned IOTs in the pipeline?
Results for partition-wise load using pipelined table function are very good, look-ups across tens of millions of rows are excellent.
Environment = Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
OS = Oracle Enterprise Linux Server release 5.2 (Carthage) 2.6.18 92.el5 (32-bit)
Here's the potted test-case...
1) First the non object based Partitioned IOT - data is range-partitioned across the alphabet
CREATE TABLE IOT_Table (
textData VARCHAR2(10),
numberData NUMBER(10,0),
CONSTRAINT IOT_Table_PK PRIMARY KEY(textData))
ORGANIZATION INDEX MAPPING TABLE PCTFREE 0 TABLESPACE Firewire
PARTITION BY RANGE (textData)
(PARTITION Text_Part_A VALUES LESS THAN ('B') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_B VALUES LESS THAN ('C') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_C VALUES LESS THAN ('D') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_D VALUES LESS THAN ('E') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_E VALUES LESS THAN ('F') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_F VALUES LESS THAN ('G') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_G VALUES LESS THAN ('H') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_H VALUES LESS THAN ('I') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_I VALUES LESS THAN ('J') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_J VALUES LESS THAN ('K') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_K VALUES LESS THAN ('L') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_L VALUES LESS THAN ('M') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_M VALUES LESS THAN ('N') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_N VALUES LESS THAN ('O') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_O VALUES LESS THAN ('P') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_P VALUES LESS THAN ('Q') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_Q VALUES LESS THAN ('R') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_R VALUES LESS THAN ('S') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_S VALUES LESS THAN ('T') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_T VALUES LESS THAN ('U') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_U VALUES LESS THAN ('V') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_V VALUES LESS THAN ('W') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_W VALUES LESS THAN ('X') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_X VALUES LESS THAN ('Y') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_Y VALUES LESS THAN ('Z') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_Z VALUES LESS THAN (MAXVALUE) PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0))
NOLOGGING PARALLEL -- FLASHBACK ARCHIVE IOT_Flashback_Data
SQL> table IOT_TABLE created.
2) Create the local secondary bitmap index utilising the underlying mapping table
CREATE BITMAP INDEX IOT_Table_BMI1 ON IOT_Table (numberData)
LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
SQL> bitmap index IOT_TABLE_BMI1 created.
3) Quick test to confirm all ok
SQL> INSERT INTO IOT_Table VALUES ('ABC123',100);
SQL> 1 rows inserted.
SQL> SELECT * FROM IOT_Table;
TEXTDATA NUMBERDATA
ABC123 100
4) Now create a minimal object type to use as the template for object table
CREATE TYPE IOT_type AS OBJECT
textData VARCHAR2(10 CHAR),
numberData NUMBER(10,0)
) FINAL
SQL> TYPE IOT_type compiled
5) Attempt to create an object-based range partitioned IOT, including MAPPING TABLE clause as per step (1)
CREATE TABLE IOTObj_Table OF IOT_type (textData PRIMARY KEY)
OBJECT IDENTIFIER IS PRIMARY KEY ORGANIZATION INDEX
MAPPING TABLE -- we'd like to use this feature to enable use of Bitmap Indexes...
PCTFREE 0 TABLESPACE Firewire
PARTITION BY RANGE (textData)
(PARTITION Text_Part_A VALUES LESS THAN ('B') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_B VALUES LESS THAN ('C') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_C VALUES LESS THAN ('D') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_D VALUES LESS THAN ('E') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_E VALUES LESS THAN ('F') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_F VALUES LESS THAN ('G') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_G VALUES LESS THAN ('H') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_H VALUES LESS THAN ('I') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_I VALUES LESS THAN ('J') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_J VALUES LESS THAN ('K') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_K VALUES LESS THAN ('L') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_L VALUES LESS THAN ('M') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_M VALUES LESS THAN ('N') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_N VALUES LESS THAN ('O') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_O VALUES LESS THAN ('P') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_P VALUES LESS THAN ('Q') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_Q VALUES LESS THAN ('R') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_R VALUES LESS THAN ('S') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_S VALUES LESS THAN ('T') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_T VALUES LESS THAN ('U') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_U VALUES LESS THAN ('V') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_V VALUES LESS THAN ('W') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_W VALUES LESS THAN ('X') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_X VALUES LESS THAN ('Y') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_Y VALUES LESS THAN ('Z') PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0),
PARTITION Text_Part_Z VALUES LESS THAN (MAXVALUE) PCTFREE 0 TABLESPACE Firewire Storage (Initial 10M Next 1M PCTIncrease 0))
NOLOGGING PARALLEL -- FLASHBACK ARCHIVE IOT_Flashback_Data
This errors out with the following...
SQL Error: ORA-25182: feature not currently available for index-organized tables
25182. 00000 - "feature not currently available for index-organized tables"
*Cause: An attempt was made to use one or more of the following feature(s) not
currently supported for index-organized tables:
CREATE TABLE with LOB/BFILE/VARRAY columns,
partitioning/PARALLEL/CREATE TABLE AS SELECT options,
ALTER TABLE with ADD/MODIFY column options, CREATE INDEX
*Action: Do not use the disallowed feature(s) in this release.
6) Re-running the create table statement in step 5 without the MAPPING TABLE clause works fine. Not surprisingly an attempt to create a secondary local bitmap index on this table fails as there's no mapping table, like so...
CREATE BITMAP INDEX IOTObj_Table_BMI1 ON IOTObj_Table (numberData)
LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
CREATE TABLE with LOB/BFILE/VARRAY columns,
partitioning/PARALLEL/CREATE TABLE AS SELECT options,
ALTER TABLE with ADD/MODIFY column options, CREATE INDEX
*Action: Do not use the disallowed feature(s) in this release.
CREATE BITMAP INDEX IOTObj_Table_BMI1 ON IOTObj_Table (numberData)
LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL
Error at Command Line:99 Column:13
Error report:
SQL Error: ORA-00903: invalid table name
00903. 00000 - "invalid table name"
7) Creating a secondary local b-tree index is fine, like so...
SQL> CREATE INDEX IOTObj_Table_I1 ON IOTObj_Table (numberData)
LOCAL STORAGE (INITIAL 1M PCTINCREASE 0 NEXT 512K) NOLOGGING PARALLEL;
index IOTOBJ_TABLE_I1 created.
8) A quick test to ensure object table ok...
SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DEF456',500));
SQL> 1 rows inserted.
SQL> SELECT * FROM IOTObj_Table;
TEXTDATA NUMBERDATA
DEF456 500Thanks Dan,
the intention is to range partition based on the initial character, so A* -> Text_Part_A, B* -> Text_Part_B, and so on.
Here's an example, using an empty IOTObj_Table as created previously.
1) Set up & confirm some test data (two 'D's, one 'N', and two 'Z's)
SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DEF456',500));
SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('DDD111',510));
SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('N3000',515));
SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('ZZ1212',520));
SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530));
SQL> COMMIT;
SQL> SELECT * FROM IOTObj_Table;
TEXTDATA NUMBERDATA
DDD111 510
DEF456 500
N3000 515
Z111X 530
ZZ1212 520
2) Just to prove our IOT is enforcing the Primary Key based on the TextData attribute, try to insert a duplicate
SQL> INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530));
Error starting at line 141 in command:
INSERT INTO IOTObj_Table VALUES (IOT_Type('Z111X',530))
Error report:
SQL Error: ORA-00001: unique constraint (OCDataSystems.SYS_IOT_TOP_84235) violated
00001. 00000 - "unique constraint (%s.%s) violated"
*Cause: An UPDATE or INSERT statement attempted to insert a duplicate key.
For Trusted Oracle configured in DBMS MAC mode, you may see
this message if a duplicate entry exists at a different level.
*Action: Either remove the unique restriction or do not insert the key.
3) Now confirm that our data has been slotted into the range-based partition we expect using the PARTITION clause of SELECT...
- The two 'D's...
SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_D);
TEXTDATA NUMBERDATA
DDD111 510
DEF456 500
- The single 'N'...
SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_N);
TEXTDATA NUMBERDATA
N3000 515
- The two 'Z's...
SQL> SELECT * FROM IOTObj_Table PARTITION (Text_Part_Z);
TEXTDATA NUMBERDATA
Z111X 530
ZZ1212 520
4) And to wrap up confirm an empty partition
SELECT * FROM IOTObj_Table PARTITION (Text_Part_W); -
Creation of bitmap index taking long time
Hi
I have OLTP compression enabled on the table
CREATE BITMAP INDEX
I1 ON
T1(
col 1Asc
NOLOGGING TABLESPACE ts_index01
taking very long time.
The wait event is : cell single block physical read.
Any ideas what I can do?
Thank uHi Marc
thanks for your answer. The issue is this is a cOTS product(Siebel Analytics). The indexes are created by DAC(Informatica) automatically. I do not have away to "create index index_name parallel degree 24" clause in there.
Thanks -
hi everyone,
There is table t
and there are several bitmap one-column indexes
i1 on t(c1)
i2 on t(c2)
i3 on t(c3)
Column C1 is not nullable.
Columns C2 and C3 is nullable.
There is query
select /*+ index_combine(t) */
from t
where c1 = :1
and c2 in (:2, 'X')
and c3 = :3
| Id | Operation |
| 0 | SELECT STATEMENT |
| 1 | TABLE ACCESS BY INDEX ROWID |
| 2 | BITMAP CONVERSION TO ROWIDS |
| 3 | BITMAP AND |
| 4 | BITMAP INDEX SINGLE VALUE |
| 5 | BITMAP INDEX SINGLE VALUE |
| 6 | BITMAP OR |
| 7 | BITMAP INDEX SINGLE VALUE|
| 8 | BITMAP INDEX SINGLE VALUE|
---------------------------------------Fine.
But if I create following indexes (and drop previous)
create bitmap index idx1 on t(C1, C2);
create bitmap index idx2 on t(C1, C3);
then the plan of the query above is following:
| Id | Operation |
| 0 | SELECT STATEMENT |
| 1 | TABLE ACCESS BY INDEX ROWID |
| 2 | BITMAP CONVERSION TO ROWIDS|
| 3 | BITMAP INDEX SINGLE VALUE |
--------------------------------------And the question:
why the plan does not consist BITMAP AND ?
Is it possible to scan both new indexes in the query with BITMAP AND?
Thanks793769 wrote:
Jonathan Lewis wrote:
I think this means there's a hole in the optimizer's legal strategies that you might have to fill by other methods.Do I right understand that it is impossible to combine bitmap non-one-column indexes?No, you're generalising from the particular - thus are myths created.
I have demonstrated a case where two bitmap indexes start with the same column+, and the optimizer therefore refuses to do a "bitmap and" between these two indexes when you have where clause that uses equality on the common first column and equalities on the seperate second columns. This is a very small subset of query patterns involving combinations of "non-one-column" (multi-column) indexes.
For example - why don't you try recreating your (c1, c3) index as (c3, c1) to see what the optimizer can do ?
In my example it produced the following path:
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 10 | 1250 | 6 |
| 1 | TABLE ACCESS BY INDEX ROWID | T1 | 10 | 1250 | 6 |
| 2 | BITMAP CONVERSION TO ROWIDS| | | | |
| 3 | BITMAP AND | | | | |
|* 4 | BITMAP INDEX SINGLE VALUE| T1_B1B2 | | | |
| 5 | BITMAP MERGE | | | | |
|* 6 | BITMAP INDEX RANGE SCAN | T1_B3B1 | | | |
Predicate Information (identified by operation id):
4 - access("C1"=5 AND "C2"=50)
6 - access("C3"=50)
filter("C3"=50)So it is combining two multi column indexes - but it doesn't appear to be able to use the common column twice to make the second index access as efficient as possible. (This plan appeared for 10.2.0.3 and 11.2.0.2).
Regards
Jonathan Lewis -
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
Maybe you are looking for
-
Query Scenario Help - Average of Multiple Regions
Hi, I have a query scenario I can't create and I hope someone can help with. The user inputs a sales Area and the report is to output the regions in that area and provide the Volume (easy) and the Average of all the presented regions. The problem is
-
There is no source data for this data record, Message FZ205
Hi Experts, I am facing a problem with the DME File download. This problem happened all of sudden in our production system since last month and it was never before. Our system landscape has also not been changed but as per our basis consultant he has
-
Chinese/Japanese/Korean characters do not display ...
Hi there, I recently noticed that no characters show up on Skype at all, they appear only as squares, however if I copy and paste these into a different program, then the characters are displayed. This is obviously a display problem which is specific
-
Hi All, when i execute RTTCTOOL in solman dev,prd system i got following missing recommandation in prd ssyetm 8. [Note 1320940 ] SolMan does not fulfill s/w levels Description BPA/BPO Scope 2: Your Solution Manager does not fulfill the mini
-
Hi, What are the accounting documents raised at the time of Depot bill? MP will be coming or not? If no, how to clear the accounting entries? Regads, CS