Indexes on a fact table

Hi All,
We are trying to build a data warehouse. The data marts would be accessed by cognos reporting layer. In the data marts we have around 9 dimension tables and 1 fact table. For each month we will have around 21-25 million records in the fact table. Out of 9 dimensions there dim1 and dim2 have 21 million and 10 million records respectively. The rest 7 dimensions are very small like less than 10k records.
In cognos reports they are trying to join the some dimension tables and the fact table to populate some reports. they are taking around 5-6 min.
I have around 8 B-Tree indexes on this fact table with all possible combination of columns. I believe that these many indexes is not improving the performance. So I decided to create a aggregated table with measures. But in cognos there are some reports which give detailed information from the fact table and that are taking around 8 min.
please advice as to what type indexes can be created on fact tables.
I read that we can create bit map indexes based on join conditions but the documentation says that it can include columns only from dimension tables and not fact tables. Should the indexed columns be keys in dimensional tables?
I have observed that the fact table is around 1.5gb. But each index is around 1.9 -2gb. I was kind of surprised when I saw that figure. Does it imply that index scan and table lookup would take more time than the full table scan? And hence it is not using the indexes.
Any help is greatly appreciated.
Thanks
Hari

What sort of queries are you running? Do you have an example (with a query plan)?
Are indexes even useful? Or are you accessing too much data to make indexes worthwhile?
Are you licensed to use partitioning? If so, are your fact tables partitioned? Are the queries doing partition pruning?
Are you using parallelism? If so, is parallel query actually being invoked?
If creating aggregate tables is a potentially useful strategy, you would want to use materialized views with query rewrite.
Justin

Similar Messages

ROWNUM is indexed in the Fact table - How to optimize performace with this?

Hi,
I have a scenario where there is an index on the Rownum.
The main Fact table is partitioned based on the job number (Daily and monthly). As there can be multiple entries for a single jobID, the primary key is made up of the Job ID and the Rownum
This fact table in turn is joined with another fact table based on this job number and rownum. This second fact table is also partitioned on job ID.
I have few reference tables that are joined with the first fact table with btree index.
Though in a normal DW scenario we should use bitmap, here we can't do that as lot of other applications are accessing data (DML queries) where bitmap will be slow. So I am using STAR_TRANSFORMATION hint to use the normal index as bitmap index.
Till here it is fine. Problem is when I simply do a count for a specific partition from a reference table and a fact table, it is using all required indexes as bitmap with very low cost. But also it is using ROWNUM index that is of very very high cost.
I am relatively new to Oracle tuning. I am not able to understand what it is exactly doing. Could you please suggest if I can get rid of this ROWNUM to make my query performance faster? This index can not be dropped. Is there a way in the hint I can instruct not to use this primary key index?
Or Even by using is there a way that the performance will be faster?
I will highly appreciate any help in this regard.
Regards
...

Just sending the portion having info on the partition and Primary index as the entire script is too big.
CREATE TABLE FACT_TABLE
JOBID VARCHAR2(10 BYTE) DEFAULT '00000000' NOT NULL,
RECID VARCHAR2(18 BYTE) DEFAULT '000000000000000000' NOT NULL,
REP_DATE VARCHAR2(8 BYTE) DEFAULT '00000000' NOT NULL,
LOCATION VARCHAR2(4 BYTE) DEFAULT ' ' NOT NULL,
FUNCTION VARCHAR2(6 BYTE) DEFAULT ' ' NOT NULL,
AMT.....................................................................................
TABLESPACE PSAPPOD
PCTUSED 0
PCTFREE 10
INITRANS 11
MAXTRANS 255
STORAGE (
INITIAL 32248K
LOGGING
PARTITION BY RANGE (JOBID)
PARTITION FACT_TABLE_1110500 VALUES LESS THAN ('01110600')
LOGGING
NOCOMPRESS
TABLESPACE PSAPFACTTABLED
PCTFREE 10
INITRANS 11
MAXTRANS 255
STORAGE (
INITIAL 32248K
MINEXTENTS 1
MAXEXTENTS 2147483645
BUFFER_POOL DEFAULT
PARTITION FACT_TABLE_1191800 VALUES LESS THAN ('0119190000')
LOGGING
NOCOMPRESS
TABLESPACE PSAPFACTTABLED
PCTFREE 10
INITRANS 11
MAXTRANS 255
CREATE UNIQUE INDEX "FACT_TABLE~0" ON FACT_TABLE
(JOBID, RECID)
TABLESPACE PSAPFACT_TABLEI
INITRANS 2
MAXTRANS 255
LOCAL (
PARTITION FACT_TABLE_11105
LOGGING
NOCOMPRESS
TABLESPACE PSAPFACT_TABLEI
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64K
MINEXTENTS 1
MAXEXTENTS 2147483645
BUFFER_POOL DEFAULT
......................................................

Indexes for OWB fact tables

Hi All,
I had completed development of my OWB with 10 fact tables, each fact table is having index like(SA_PROD_S_IDX1_1).
Now Client had given the production database(table space and indexes) with default tablespace USERS and unlimited quota on MASTER_DATA, MASTER_IDX, TRANS_DATA, and TRANS_IDX.
My Problem is that I can put table space to my fact tables in the table properties, but how to specify my indexes to the dabase indexes.
Please help me in this regard.
Regards,
Kumar.

Hi,
I have another problem.
I Created ProcessFlows and by using email notification, I can send SUCCESS / ERROR / WARNING notification.
In process flows I have 3 maps.
When there is any error or warnings in any of the map execution, I am getting only message which I put in my email subject body, but I am not getting exactly which map got error or warnings.
Is there any way to send the execution details of the map through mail notification.
Or Please suggest me to do any solution.
Regards,
Kumar

BWA Fact Table Index Size

Hi
Can anybody tell me how the BWA decides when a fact table index gets split into multiple parts? We have a number of very large cubes that are indexed and some have a fact table index that consists of one logical index which is made up of multiple physical indexes but other, similar sized cubes, just have one very large physical index for the fact table.
With the one very large physical index we seem to get an overload problem but when they are split into multiple parts we don't.
Thanks
Martin

Hi Martin,
this depends on the reorg config and the attribute of the index. You can manually trigger a splitting of an index via command 'ROUNDROBIN x', x stand for the number of parts which the index will be split to. Therefore you have to go into trexadmin standalone tool -> landscape right click on index -> split/merge index...
If you want an automatically split, you have to setup your reorg settings. Goto trexadmin standalone tool -> tab reorg -> options -> here you can choose the type of algorithm. Have a look into note 1313260 and 1163149.
Do you have a scheduled reorg job?
Regards,
Jens
PS: Every black box can be understood...

Way to handle fact table

hi,
let;s say that we have a fact table with 250 millions rows of data.
9 dimensions.
My question is ,even we make aggregates to all possible levels,the queries in low levels are really slow(30-60 seconds).
We use indexes in the fact table in columns where we have the joins to dimensions.
Any ideas???
Is it a way to have the same logical fact and make more datasources,meaning
measures in fact
and let;s say 2 dimensions,product and supplier.
In one product_dim have the measures of the items begins from a to g ,
second product_dim have the measures of the items begins from g to t ,
and third product_dim have the measures of the items begins from u to z .
So if the queries wants data from one Dsource go from a smaller fact (with the appropriates aggregates)...
and if the query requires data from both or all of them,Bi suite make the union all by itself...
Any other recomondation...
tnks

I'd start with a trainining education session with your users discussing the merits of star schemas.
Accept OBIEE does not handle Outerjoins that well in current guise (at least with extending the outer join syntax to where clause predicates / filters)
Resolve any missing fact / dimension records with a '-1' dimension key in the fact and a corresponding -1 PK with 'unknown' attributes in the dimension - not everybody likes this idea but it is a tradeoff with the outer join problem.
Change your ETL routines to create either
a) consolidated facts where the join is already done (ie between sales orders + orders + invoices)
b) simple indexed bridge / mapping tables that again, hold 'unknown' for missing relationships between sales orders / invoices / and negate the need for outerjoins.
Just my 2c - a common misconception is that OBIEE 'can do everything' - Its only going to be as good / fast as your underlying database design - im sure you already know this but i've met a few power users / developers who feel they dont need to change the ETL at all - both OBIEE and ETL should compliment each other as a solution

Fact Table index vs BIA Index

BIA gurus..
Prior to our BIA implementation we had the drop and rebuild index process variants in our process chains.
Now after the BIA implementation we have the BIA index roll-up process variant included in the process chain.
Is it still required to have the drop and rebuilt index process variants during data load ?
Do the infocube fact table indexes ever get hit after the BIA implementation ?
Thanks,
Ajay Pathak.

I think you still need the delete/create Index variants as it not only helps in query performance but also speeds up the load to your cubes.
Documentation in Perfomance tab:
"Indices can be deleted before the load process and after the loading is finished be recreated. This accelerates the data loading. However, simultaneous read processes to a cube are negatively influenced: they slow down dramatically. Therefore, this method should only be used if no read processes take place during the data loading."
More details at:
[http://help.sap.com/saphelp_nw70/helpdata/EN/80/1a6473e07211d2acb80000e829fbfe/frameset.htm]

Select count from large fact tables with bitmap indexes on them

Hi..
I have several large fact tables with bitmap indexes on them, and when I do a select count from these tables, I get a different result than when I do a select count, column one from the table, group by column one. I don't have any null values in these columns. Is there a patch or a one-off that can rectify this.
Thx

You may have corruption in the index if the queries ...
Select /*+ full(t) */ count(*) from my_table t
... and ...
Select /*+ index_combine(t my_index) */ count(*) from my_table t;
... give different results.
Look at metalink for patches, and in the meantime drop-and-recreate the indexes or make them unusable then rebuild them.

Issue with Multiple LTS for a fact table and filters

Hello,
I am facing an issue with obiee 10g.
In my model, I have a huge FACT table F1 (partitioned and indexed). The average response time for the queries, which targeted it, was ~30-60 seconds, which was not really convincing our end user.
So, we decided to create a materialized view, which removes some dimensions that are not used by default, but might be used if the end user adds some filters. I added the Materialized view in the Physical Layer and in the corresponding Logical Table Source.
I then tried to see if it works, but I was a bit surprised by the result. Indeed,
-> If the report does not reference a truncated dimension, it targets the materialized view. -> Perfect
-> If the report does reference a truncated dimension in the columns, it targets the Fact Table. -> Perfect
-> If the report does reference a truncated dimension in the Filters, it targets the materialized view. For this reason, the filter is never resolved and no join on the dimension table is applied, whereas it exists in logical SQL generated. -> Ko.
A suggestion could be to add the filters into the columns, but I am not satisfied by this response because it will never use the materialized view in that case.
An other suggestion could be to use query rewrite, but I 'd like to have the full control on the generation of the queries.
Does someone know if the filters are not evaluated to determine which LTS to use? How can I force this evaluation?
Regards,

Hi,
If I understand your description correctly, then your materialized view skips some dimensions (infrequent ones). However, when you reference these skipped dimensions in filters, the queries are hitting the materialized view and failing as these values do not exist. In this case, you could resolve it as follows
1. Create dimensional hierarchies for all dimensions.
2. In the fact table's logical sources set the content tabs properly. (Yes, I think this is it).
When you skipped some dimensions, the grain of the new fact source (the materialized view in this case) is changed. For example:
Say a fact is available with the keys for Product, Customer, Promotion dimensions. The grain for this is Product * Customer * Promotion
Say another fact is available with the keys for Product, Customer. The grain for this is Product * Customer (In fact, I would say it is Product * Customer * Promotion Total).
So in the second case, the grain of the table is changed. So setting appropriate content levels for these sources would automatically switch the sources.
So, I request you to try these settings and let me know if it works.
Thank you,
Dhar

Fact Tables

Hi!
I needed help on understanding how data is tored in the FACT Tables.
I am currently facing an issue after running SPRUNCONVERSION. The stored procedure generates 4 records in the FACT tables and thereby eliminates any converted values. For eg, If an liability account 1111001 is loaded with a value -5000 at LC; Local Currency, Running SPRUNCONVERSION say wthe the Translation rate of 2, generates 4 records in the FACTWB Tables:
-10000 in USD,
10000 in USD,
-10000 in USD and another +10000 in USD at the same account and at the same crossings.
This in effect shows no converted data in USD and shows a 0 value.
Any guidance to understand how these records are generated and stored will be of great help.
Regards,
Pankti Shroff

Hi
when you save an application Outlooksoft Admin rebuilds the cube or application in Analysis Services and recreates the following SQL items on the applications wb, fac2, and fact table.
1. Dependencies
2. Indexes
3. Contraints
4. Stored procedures
The source field of the applications wb, fac2, and fact tables is used for optimization purposes only. The 'updating source field' step can vary in time depending on the record count and the default value of the source field. This process will take more time when performing a full optimization because we are querying the wb, fac2, and fact tables.
Hope this helps...
Regards
SN...

Fact tables in Infocube

How many tables Exact Contain in Info cube?
Please search the forum
Edited by: Pravender on Sep 16, 2011 12:31 AM

Hi Mahesh,
For Basis InfoCubes in SAP BW, there are two fact tables for
including transaction data: The F and the E fact table.
Unlike the E fact table, the F fact table contains the information
about the request from where the transaction data originates
When loading data (when receiving requests), the system writes data
into the F fact table.
During "compression", the system summarizes data from different
requests and writes it to the E fact table.
To ensure good reporting performance, it is important that you only
keep data from a few requests in the F fact table, which means that you
should compress requests as soon as possible.
Also bear in mind that deleting transaction data according to the
request is only possible from the F fact table, as only this table
contains the information regarding which data belongs to which
request.
You should therefore compress a request as soon as you are certain
that the data loaded is correct. When you install BW on an ORACLE database, BITMAP indexes are created on the fact tables to improve the reporting performance of the system
And yes try to search on help.sap, there is plenty of information.
Regards
Sunny

How to create unique key column in ROLAP fact table?

Hi all,
Is there a way to create a single column primary key (or unique index) on my ROLAP cube (and fact tables) in OWB? if so, what I should do in my mappings?
Thanks!
- Andrew

Have you all conformed dimensions between the two facts?

Is it ok? if we have 42 million records in a single fact table!!

Hello,
We have three outstanding fact tables, and we need to add one more fact type, and we were thinking whether we can do two different fact tables, or can we put the values in one of the same fact table which is similar, but the records are upto 42 million if we add ,so my question is having a single fact table with all records, or breaking it down, to two different ones!!!Thnx!!

I am not sure what is an "outstanding fact" or an "fact type". A 42m fact table doesn't necessarily indicate you are doing something wrong although it does sound as odd. I would expect most facts to be small as they should have aggregated measures to speed up report. In some cases you may want to drill down to the detailed transaction level in which case you may find these large facts. But care should be taken not to allow users to query on this fact without user the "transaction ID" which obviously should be indexed and should guarantee that queries will be quick.
Guessing from your post (as it is not clear not descriptive enough) it would seem to imply that you are adding a new dimension to your fact and that will cause the fact to increase it's row count to 42m. That probably means that you are changing the granularity of the fact. That may or may not be correct, depending on your model.

Reg: Using Multiple fact tables in the RPD!

Hello everyone,
Can I get some help with the following scenario?
We use OBIEE 11g.
We have a report that uses only 1 fact table to retrieve the data and it takes hell lot of time to bring up the data in the report.
My question here is is there a way to bring up the performance of the report if we split the data in 1 fact table to 2 fact tables and make the report use the 2 fact tables.
Are there any other ways of tuning the report for better performance.
Thanks for the help in advance!
Ajay.

Hi Ajay,
Follow the following steps for the tuning;
1. Try to tune the SQL query first generated by the report, and make necessary changes. (Put indexes on required column so that your query is scanning the index instead of entire table)
2. You can try to create agg fact table and use the agg navigation for improving the performance. (Idea is to reduce the data set on which sql is fired)
3. You can try to create partitions on the FACT table in the DB and so that required partitions are queried as per filters.
4. In the Last if all the above doesn't tune your query you can try splitting the FACT table in to TWO or More as per your decision and then use fragmentation content in the BMM layer of the RPD so it will hit appropriate tables as per you report.
Mark Correct/Helpful if it helps.
Best of Luck,
Kashi

How to design a fact table to keep track of active dimensions?

I would like to design a classic OLAP facts table using a star scheme. The SQL model of the facts table should be independent of any concrete RDBMS technology and portable between different systems.
The problem is this: users should be able to select subsets of the facts based on conjunctive queries on the dimension values defined for the facts. However, the program that provides the interface for doing this to the user should only present those dimensions where anything is still selectable at all. For example, if a user selected year 2001 and for dimension contract code there is only a single value for all records in the fact table for that year, this dimension should not be shown to the user any more. This should be solved in a generic way. So for n dimensions in total, if the current set of facts is based on constraints from j dimensions, I want to know for which of the remaining n-j dimensions there is still something to select from and only show those.
The obvious way is to make a count(*) query on the distinct foreign keys of each of the dimensions on the fact table, using the same where clause. That means that one would need (n-j) such queries on the whole facts table and that sounds like an awful waste of resources given that the original query for selecting the facts could have done it internally "on the fly".
How can this be achieved in the most performant way? Is there a "classical" way of how to approach this problem? Is there tool support for doing this efficiently?
Any help or pointers to where one could find out more about this would be greatly apreciated - thank you!

>
Did you get the counts for each value of each dimension by doing a separate query with the current "WHERE" clause on each dimension?
>
My method doesn't apply to your use case. I wrote a Java class to create my own bit-mapped indexes on CSV files. So each attribute value was a one million bit binary raw.
I don't know, and don't want to know, what your particular requirements are. But I can show you a basic process that will work for large numbers of rows. Get a simple process working and then explore to see if it will meet your particular needs. Not going to answer questions here about anything but about my example code
1. Assume a single fact table with one primary key column and multiple single-value attribute columns.
2. The table is not subject to DML operations AT ALL - truncate and load if you want apply changes. Meaning it will be useful for research purposes on archived data.
3. The purpose of the table is to select the fact table ROWIDs for records of interest. So the only value selected is a result set of ROWIDs that can then be used to get any of the normal FACt table data and other linked data as needed.
Create the table - insert some records, create a bitmap index on each dimension column and collect the statistics
ALTER TABLE SCOTT.STAR_FACT
DROP PRIMARY KEY CASCADE;
DROP TABLE SCOTT.STAR_FACT CASCADE CONSTRAINTS;
create table star_fact (
    fact_key varchar2(30) DEFAULT 'N/A' not null,
    age      varchar2(30) DEFAULT 'N/A' not null,
    beer    varchar2(30) DEFAULT 'N/A' not null,
    marital_status varchar2(30) DEFAULT 'N/A' not null,
    softdrink varchar2(30) DEFAULT 'N/A' not null,
    state    varchar2(30) DEFAULT 'N/A' not null,
    summer_sport varchar2(30) DEFAULT 'N/A' not null,
    constraint star_fact_pk PRIMARY KEY (fact_key)
INSERT INTO STAR_FACT (FACT_KEY) SELECT ROWNUM FROM ALL_OBJECTS;
create bitmap index age_bitmap on star_fact (age);
create bitmap index beer_bitmap on star_fact (beer);
create bitmap index marital_status_bitmap on star_fact (marital_status);
create bitmap index softdrink_bitmap on star_fact (softdrink);
create bitmap index state_bitmap on star_fact (state);
create bitmap index summer_sport_bitmap on star_fact (summer_sport);
exec DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'STAR_FACT', NULL, CASCADE => TRUE);Now if you run the 'complex' query for the example from my first reply you will get
SQL> set serveroutput on
SQL> set autotrace on explain
SQL> select rowid from star_fact where
2   (state = 'CA') or (state = 'CO')
3 and (age = 'young') and (marital_status = 'divorced')
4 and (((summer_sport = 'baseball') and (softdrink = 'pepsi'))
5 or ((summer_sport = 'golf') and (beer = 'coors')));
no rows selected
Execution Plan
Plan hash value: 1934160231
| Id | Operation                      | Name                  | Rows | Bytes |
|   0 | SELECT STATEMENT               |                       |     1 |    30 |
|   1 | BITMAP CONVERSION TO ROWIDS   |                       |     1 |    30 |
|   2 |   BITMAP OR                    |                       |       |       |
|* 3 |    BITMAP INDEX SINGLE VALUE   | STATE_BITMAP          |       |       |
|   4 |    BITMAP AND                  |                       |       |       |
|* 5 |     BITMAP INDEX SINGLE VALUE | AGE_BITMAP            |       |       |
|* 6 |     BITMAP INDEX SINGLE VALUE | MARITAL_STATUS_BITMAP |       |       |
|* 7 |     BITMAP INDEX SINGLE VALUE | STATE_BITMAP          |       |       |
|   8 |     BITMAP OR                  |                       |       |       |
|   9 |      BITMAP AND                |                       |       |       |
|* 10 |       BITMAP INDEX SINGLE VALUE| SOFTDRINK_BITMAP      |       |       |
|* 11 |       BITMAP INDEX SINGLE VALUE| SUMMER_SPORT_BITMAP   |       |       |
| 12 |      BITMAP AND                |                       |       |       |
|* 13 |       BITMAP INDEX SINGLE VALUE| BEER_BITMAP           |       |       |
|* 14 |       BITMAP INDEX SINGLE VALUE| SUMMER_SPORT_BITMAP   |       |       |
Predicate Information (identified by operation id):
   3 - access("STATE"='CA')
   5 - access("AGE"='young')
   6 - access("MARITAL_STATUS"='divorced')
   7 - access("STATE"='CO')
10 - access("SOFTDRINK"='pepsi')
11 - access("SUMMER_SPORT"='baseball')
13 - access("BEER"='coors')
14 - access("SUMMER_SPORT"='golf')
SQL>As you can see Oracle is combining bitmap indexes on columns in a single table to implement the same AND/OR complex conditions I showed earlier. It doesn't need any other table to do this.
In 11g you can create virtual columns and then index them.
so if you find that the condition 'young' and 'divorced' is used frequently you could create a VIRTUAL 'young_divorced' column and create an index.
alter table star_fact add (young_divorced AS (case
   when (age = 'young' and marital_status = 'divorced') then 'TRUE' else 'N/A' end) VIRTUAL);
create bitmap index young_divorced_ndx on star_fact (young_divorced);
exec DBMS_STATS.GATHER_TABLE_STATS('SCOTT', 'STAR_FACT', NULL, CASCADE => TRUE);Now you can query using the name of the virtual column
SQL> select rowid from star_fact where young_divorced = 'TRUE'
2 and (state = 'CA') or (state = 'CO')
3 /
no rows selected
Execution Plan
Plan hash value: 2656088680
| Id | Operation                    | Name               | Rows | Bytes | Cost
|   0 | SELECT STATEMENT             |                    |     1 |    28 |
|   1 | BITMAP CONVERSION TO ROWIDS |                    |       |       |
|   2 |   BITMAP OR                  |                    |       |       |
|* 3 |    BITMAP INDEX SINGLE VALUE | STATE_BITMAP       |       |       |
|   4 |    BITMAP AND                |                    |       |       |
|* 5 |     BITMAP INDEX SINGLE VALUE| STATE_BITMAP       |       |       |
|* 6 |     BITMAP INDEX SINGLE VALUE| YOUNG_DIVORCED_NDX |       |       |
Predicate Information (identified by operation id):
   3 - access("STATE"='CO')
   5 - access("STATE"='CA')
   6 - access("YOUNG_DIVORCED"='TRUE')
SQL>
----------------------------------------------------------------Notice that at line #6 the new index was used. The VIRTUAL column itselfl doesn't create data for the fact table; the definition only exists in the data dictionary.
The YOUNG_DIVORCE_NDX is real and does consume space. The tradeoff is additional space for the index but you make the query easier because you don't have to recreate the complex condition every time.
Oracle can work with the complex condition and combine the indexes so this really only helps the query writer. Your UI should be able to hide the query construction from the user so I would avoid the use of VIRTUAL columns and an additional index until you demonstrate you really need it.
If you provide users with their own RESULT table to store custom query results you could just store the query name and the set of primary keys from the result set. I used ROWIDs in the example but don't use rowid for a real application - use a primary key value that won't change.
So your UI would let users construct complext dimension queries for 'young_sportsters' and get a result set of primary keys for that. They could save the label 'young_sportsters' and the primary keys in their own work table. Then you can let them run queries that use the primary keys to query data from your active data warehouse to get any other data it contains.
>
Did you get the counts for each value of each dimension by doing a separate query with the current "WHERE" clause on each dimension?
>
For an Oracle implementation you need to do a count select for each dimension. I haven't tried it but you might be able to do multiple dimensions in a singe query. One query would look like this>
-- get the dimension counts
SQL> select beer, count(*) from star_fact group by beer;
BEER                             COUNT(*)
N/A                                 56977
Execution Plan
Plan hash value: 1692670403
| Id | Operation                | Name        | Rows | Bytes | Cost (%CPU)| Ti
|   0 | SELECT STATEMENT         |             |     1 |    12 |     3   (0)| 00
|   1 | SORT GROUP BY NOSORT    |             |     1 |    12 |     3   (0)| 00
|   2 |   BITMAP CONVERSION COUNT|             | 56977 |   667K|     3   (0)| 00
|   3 |    BITMAP INDEX FULL SCAN| BEER_BITMAP |       |       |            |
SQL>Notice that Oracle uses only the index to gather the data.

How to skip the fact table /BI0/9AEDFC01 error while import phase in Heterogeneous migration

Hi.
Please find the below issue of the fact table while import phase in OS/DB migration and enclosed the below log for reference.
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: START OF LOG: 20140924185259
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: sccsid @(#) $Id: //bas/741_REL/src/R3ld/R3load/R3ldmain.c#6 $ SAP
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: version R7.40/V1.8 [UNICODE]
Compiled Nov 23 2013 13:06:03
-------------------- Start of patch information ------------------------
patchinfo (patches.h): (0.009) Support for SUM/ZDM and DMO (note 1778564)
DBSL patchinfo (patches.h): (0.011) DBSL error corrections in 7.41: (4) LOBs (note 1928526)
--------------------- End of patch information -------------------------
process id 14248
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: job completed
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: END OF LOG: 20140924185259
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: START OF LOG: 20140924185259
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: sccsid @(#) $Id: //bas/741_REL/src/R3ld/R3load/R3ldmain.c#6 $ SAP
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: version R7.40/V1.8 [UNICODE]
Compiled Nov 23 2013 13:06:03
-------------------- Start of patch information ------------------------
patchinfo (patches.h): (0.009) Support for SUM/ZDM and DMO (note 1778564)
DBSL patchinfo (patches.h): (0.011) DBSL error corrections in 7.41: (4) LOBs (note 1928526)
--------------------- End of patch information -------------------------
process id 14265
(DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): UTF16
(GSI) INFO: dbname = "AQ220140924040917                                                                                                              "
(GSI) INFO: vname    = "ORACLE                          "
(GSI) INFO: hostname = "VA1WIPRSCM03                                                    "
(GSI) INFO: sysname = "Linux"
(GSI) INFO: nodename = "VA1WIPRSCM03"
(GSI) INFO: release = "2.6.32-358.el6.x86_64"
(GSI) INFO: version = "#1 SMP Tue Jan 29 11:47:41 EST 2013"
(GSI) INFO: machine = "x86_64"
(SQL) INFO: Searching for SQL file SQLFiles.LST
(SQL) INFO: SQLFiles.LST not found
(SQL) INFO: Searching for SQL file /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: found /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: Trying to open /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST opened
(SQL) INFO: Searching for SQL file DFACT.SQL
(SQL) INFO: DFACT.SQL not found
(SQL) INFO: Searching for SQL file /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: found /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: Trying to open /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL opened
(SQL) ERROR: Invalid entry at line 5 in file /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) ERROR: SQL list was not built successfully
(DDL) ERROR: check_sql_list() failed for /BI0/9AEDFC01
(DB) INFO: disconnected from DB
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: job finished with 1 error(s)
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: END OF LOG: 20140924185259
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: START OF LOG: 20140925104442
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: sccsid @(#) $Id: //bas/741_REL/src/R3ld/R3load/R3ldmain.c#6 $ SAP
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: version R7.40/V1.8 [UNICODE]
Compiled Nov 23 2013 13:06:03
-------------------- Start of patch information ------------------------
patchinfo (patches.h): (0.009) Support for SUM/ZDM and DMO (note 1778564)
DBSL patchinfo (patches.h): (0.011) DBSL error corrections in 7.41: (4) LOBs (note 1928526)
--------------------- End of patch information -------------------------
process id 23939
(DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): UTF16
(GSI) INFO: dbname = "AQ220140924040917                                                                                                              "
(GSI) INFO: vname    = "ORACLE                          "
(GSI) INFO: hostname = "VA1WIPRSCM03                                                    "
(GSI) INFO: sysname = "Linux"
(GSI) INFO: nodename = "VA1WIPRSCM03"
(GSI) INFO: release = "2.6.32-358.el6.x86_64"
(GSI) INFO: version = "#1 SMP Tue Jan 29 11:47:41 EST 2013"
(GSI) INFO: machine = "x86_64"
(SQL) INFO: Searching for SQL file SQLFiles.LST
(SQL) INFO: SQLFiles.LST not found
(SQL) INFO: Searching for SQL file /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: found /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: Trying to open /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST opened
(SQL) INFO: Searching for SQL file DFACT.SQL
(SQL) INFO: DFACT.SQL not found
(SQL) INFO: Searching for SQL file /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: found /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: Trying to open /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL opened
(SQL) ERROR: Invalid entry at line 5 in file /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) ERROR: SQL list was not built successfully
(DDL) ERROR: check_sql_list() failed for /BI0/9AEDFC01
(IMP) INFO: a failed DROP attempt is not necessarily a problem
(SQL) ERROR: SQL list was not built successfully
(DDL) ERROR: check_sql_list() failed for /BI0/9AEDFC01
(DB) INFO: disconnected from DB
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: job finished with 1 error(s)
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: END OF LOG: 20140925104442
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: START OF LOG: 20140925124401
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: sccsid @(#) $Id: //bas/741_REL/src/R3ld/R3load/R3ldmain.c#6 $ SAP
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: version R7.40/V1.8 [UNICODE]
Compiled Nov 23 2013 13:06:03
-------------------- Start of patch information ------------------------
patchinfo (patches.h): (0.009) Support for SUM/ZDM and DMO (note 1778564)
DBSL patchinfo (patches.h): (0.011) DBSL error corrections in 7.41: (4) LOBs (note 1928526)
--------------------- End of patch information -------------------------
process id 25323
(DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): UTF16
(GSI) INFO: dbname = "AQ220140924040917                                                                                                              "
(GSI) INFO: vname    = "ORACLE                          "
(GSI) INFO: hostname = "VA1WIPRSCM03                                                    "
(GSI) INFO: sysname = "Linux"
(GSI) INFO: nodename = "VA1WIPRSCM03"
(GSI) INFO: release = "2.6.32-358.el6.x86_64"
(GSI) INFO: version = "#1 SMP Tue Jan 29 11:47:41 EST 2013"
(GSI) INFO: machine = "x86_64"
(SQL) INFO: Searching for SQL file SQLFiles.LST
(SQL) INFO: SQLFiles.LST not found
(SQL) INFO: Searching for SQL file /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: found /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: Trying to open /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST
(SQL) INFO: /data1/SCMEXPORT/EXPAQ2/ABAP/DB/SQLFiles.LST opened
(SQL) INFO: Searching for SQL file DFACT.SQL
(SQL) INFO: DFACT.SQL not found
(SQL) INFO: Searching for SQL file /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: found /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: Trying to open /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL
(SQL) INFO: /data1/SCMEXPORT/EXPAQ2/ABAP/DB/ORA/DFACT.SQL opened
------------------ C-STACK ----------------------
R3load[S](LinStackBacktrace+0x8c)[0x48d167]
R3load[S](LinStack+0x35)[0x6ca6c5]
R3load[S](CTrcStack2+0x48)[0x48fba1]
R3load[S](SigIGenAction+0x212)[0x58b4fb]
libpthread.so.0[T][0x397680f710]
R3load[S](check_sql_list+0xab0)[0x61bbb0]
R3load[S](DBDrop+0xbb)[0x60a8fb]
R3load[S](import+0xde6)[0x620986]
R3load[S](main_r3ldmain+0x1cfc)[0x6073bc]
libc.so.6[T](__libc_start_main+0xfd)[0x397601ed5d]
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: START OF LOG: 20140925125540
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: sccsid @(#) $Id: //bas/741_REL/src/R3ld/R3load/R3ldmain.c#6 $ SAP
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: version R7.40/V1.8 [UNICODE]
Compiled Nov 23 2013 13:06:03
-------------------- Start of patch information ------------------------
patchinfo (patches.h): (0.009) Support for SUM/ZDM and DMO (note 1778564)
DBSL patchinfo (patches.h): (0.011) DBSL error corrections in 7.41: (4) LOBs (note 1928526)
--------------------- End of patch information -------------------------
process id 25932
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: job completed
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: END OF LOG: 20140925125540
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: START OF LOG: 20140925125540
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: sccsid @(#) $Id: //bas/741_REL/src/R3ld/R3load/R3ldmain.c#6 $ SAP
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: version R7.40/V1.8 [UNICODE]
Compiled Nov 23 2013 13:06:03
-------------------- Start of patch information ------------------------
patchinfo (patches.h): (0.009) Support for SUM/ZDM and DMO (note 1778564)
DBSL patchinfo (patches.h): (0.011) DBSL error corrections in 7.41: (4) LOBs (note 1928526)
--------------------- End of patch information -------------------------
process id 25955
(DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): UTF16
(GSI) INFO: dbname = "AQ220140924040917                                                                                                              "
(GSI) INFO: vname    = "ORACLE                          "
(GSI) INFO: hostname = "VA1WIPRSCM03                                                    "
(GSI) INFO: sysname = "Linux"
(GSI) INFO: nodename = "VA1WIPRSCM03"
(GSI) INFO: release = "2.6.32-358.el6.x86_64"
(GSI) INFO: version = "#1 SMP Tue Jan 29 11:47:41 EST 2013"
(GSI) INFO: machine = "x86_64"
(TSK) ERROR: file /tmp/sapinst_instdir/BS2013SR1/SCM703SR1/ORA/COPY/SYSTEM/STD/AS-ABAP/SAPDFACT_1.TSK.bck already seems to exist
            a previous run may not have been finished cleanly
            file /tmp/sapinst_instdir/BS2013SR1/SCM703SR1/ORA/COPY/SYSTEM/STD/AS-ABAP/SAPDFACT_1.TSK possibly corrupted
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: job finished with 1 error(s)
/usr/sap/AQ2/SYS/exe/uc/linuxx86_64/R3load: END OF LOG: 20140925125540

Dear Ram Nath,
It may be late but it will be use full to others.
I faced similar issue and solved it by commenting the 5th line of DFACT.SQL file.
The issue was with the indexes not being generated properly to avoid such issues we must ensure to implement SAP note 1991576 in prior, if not we can comment the 5th line.
Below is the corrected file in my case
# ORACLE : NATIVE SQL EXPORT GENERATED AT 20150426083248
#ind: - commented line (earlier it was just 'ind: ')
ind: /BI0/E0PPM_VC1~0
tab: /BI0/F0PPM_VC1
Please let me know in case of queries if any.
Regards
Baranedharan S.

Indexes on a fact table

Similar Messages

Maybe you are looking for