Dimension key 16 missing in dimension table /BIC/DZPP_CP1P

Hi all,
I have a problem with an infocube ZPP_CP1. I am not able to delete nor load any data. It was working fine till some time back.
Below is the outcome of running RSRV check on this cube. I tried to run the error correction in RSRV. But n o use
Please help.
Dimension key 16 missing in dimension table /BIC/DZPP_CP1P
Message no. RSRV018
Diagnosis
The dimension key 16 that appears as field KEY_ZPP_CP1P in the fact table, does not appear as a value of the DIMID field in the dimensions table /BIC/DZPP_CP1P.
There are 17580 fact records that use the dimension key 16.
The facts belonging to dimension key 16 are therefore no longer connected to the master data of the characteristic in dimension.
Note that errors that are reported for the package dimension are not serious (They are thus shown as warnings (yellow) and not errors (red). When deleting transaction data requests, it can arise that the associated entries in the package dimension have already been deleted. As a result, the system terminates when deleting what can be a very large number of fact records. At the moment, we are working on a correction which will delete such data which remains after deletion of the request. Under no circumstances must you do this manually. Also note that data for request 0 cannot generally be deleted.
The test investigates whether all the facts are zero. If this is the case, the system is able to remove the inconsistency by deleting these fact records. If the error cannot be removed, the only way to re-establish a consistent status is to reconstruct the InfoCube. It may be possible for SAP to correct the inconsistency, for which you should create an error message.
Procedure
This inconsistency can occur if you use methods other than those found in BW to delete data from the SAP BW tables (for example, maintaining tables manually, using your own coding or database tools).

Hi Ansel,
             There has been no changes in the cube. I am getting this problem in my QA server. So I retransported the cube again from Dev to QA. But did not help me..
Any other ideas??
Regards,
Adarsh

Similar Messages

  • Dimension key in a fact table should be repetitive?

    Hi All,
    We do have one to one  relationship between a FACT table and Dimension table? Is it correct to have this kind of dimensional model.

    You may find this link of some help.
    How to Model Fact table having 1:1 relationship with key Dimension attributes

  • Load fact table with null dimension keys

    Dear All,
    We have OWB 10g R2 and ROLAP star schema. In our source system some rows don’t have all attributes populated with values (null value), and this empty attributes are dimension (business) keys in star schema. Is it possible to load fact table with such rows (some dimension keys are null) in the OWB mappings? We use cube operator in mappings.
    Thanks And Regards
    Miran

    The dimension should have a row indicating UNKNOWN, this will have a business key outside of the normal range e.g. -999999.
    In the mapping the missing business keys can then be NVL'd to -999999.
    Cheers
    Si

  • Missing most detailed table for dimension tables

    Hi ,
    I am getting this following error
    Business Model Core:
    [nQSError: 15003] Missing most detailed table for dimension tables: [Dim - Customer,Dim - Account Hierarchy,Dim - Account Region Hierarchy,Fact - Fins - Period Days Count].
    [nQSError: 15001] Could not load navigation space for subject area Core.
    I got this error when I tried to configure # of Elapsed Days and # of Cumulative Elapsed Days by following way-
    1. Using the Administration Tool, open OracleBIAnalyticsApps.rpd.
    Configuration Steps for Controlling Your Data Set
    Configuring Oracle Financial Analytics 5-51
    The OracleBIAnalyticsApps.rpd file is located at:
    ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_
    obisn\repository
    2. In the Business Model and Mapping layer, go the logical table Fact - Fins - Period
    Days Count.
    3. Under Sources, select the Fact_W_DAY_D_PSFT logical table source.
    4. Clear the Disabled option in the General tab and click OK.
    5. Open the other two logical table sources, Fact_W_DAY_D_ORA and Fact_W_
    DAY_D_PSFT, and select the Disabled option.
    6. Add the "Fact - Fins - Period Days Count" and "Dim - Company" logical tables to
    the Business Model Diagram. To do so, right-click the objects and select Business
    Model Diagram, Selected Tables Only.
    7. In the Business Model Diagram, create a new logical join from "Dim - Company"
    to "Fact - Fins - Period Days Count." The direction of the foreign key should be
    from the "Dim - Company" logical table to the "Fact - Fins - Period Days Count"
    table. For example, on a (0,1):N cardinality join, "Dim - Company" will be on the
    (0/1) side and "Fact - Fins - Period Days Count" will be on the N side.
    8. Under the Fact - Fins - Period Days Count logical table, open the "# of Elapsed
    Days" and "# of Cumulative Elapsed Days" metrics, one at a time.
    9. Go to the Levels tab. For the Company dimension, the Logical Level is set to All.
    Click the X button to remove it. Repeat until the Company dimension does not
    have a Logical Level setting.
    10. Make sure to check Global Consistency to ensure there are no errors, and then
    save the RPD file.
    Please help me to resolve.
    Thanks,
    Soumitro

    Could you let me know how you resolved this. I am facing the same.

  • "Missing most detailed table for dimension tables" eror when I run the Global Consistency check

    ERRORS:
    Business Model DAC Measures:
    [nQSError: 15003] Missing most detailed table for dimension tables: [D_DETAILS,D_EXECUTION_PLAN,D_TASK].
    [nQSError: 15001] Could not load navigation space for subject area DAC Measures.
    I am also attaching my Business Model layer for easy understanding. I have a fact table and several Dimension table. I got this error only after creating the following hierarchies:
    Execution Plan -> Tasks -> Details
    Start Date Time Hierarchy
    End Date Time Hierarchy
    Is there a solution for this problem? Thanks in advance!

    Yes ! My Task Hierarchy has 3 dimension tables that form a hierarchy :Execution Plan -> Tasks -> Detail
    All the 3 levels in the hierarchy are 3 different dimension tables.

  • Define logical Key on Logical Dimension Table

    It's recommended to define a logical key for any logical dimension table - in 10g there was a function on the right mouse button, as far as I remember - but in 11g there is no such functionality ? the foreign key can be added by "green plus" button, but not the primary key ?? you have to type in the name of the key, then you can choose the column and then you select as primary key ... funny.
    bug or undocumented feature?

    Hi Srini,
    Since my main logical fact table consists of two LTS and the dimension being created from this table will also have 2 LTS, the content level will be set to all levels on which the fact is joined.
    So I would like to create a logical dimension based out of my dimension and then assign the content level at the detail level.
    Please let me know if I am not clear.
    Thanks

  • Foreign keys in SCD2 dimensions and fact tables in data warehouse

    Hello.
    I have datawarehouse in snowflake schema. All dimensions are SCD2, the columns are like that:
    ID (PK) SID NAME ... START_DATE END_DATE IS_ACTUAL
    1 1 XXX 01.01.2000 01.01.2002 0
    2 1 YYX 02.01.2002 01.01.2004 1
    3 2 SYX 02.01.2002 1
    4 3 AYX 02.01.2002 01.01.2004 0
    5 3 YYZ 02.01.2004 1
    On this table there are relations from other dimension and fact table.
    Need I create foreign keys for relation?
    And if I do, on what columns? SID (serial ID) is not unique. If I create on ID, I have to get SID and actual row in any query.

    >
    I have datawarehouse in snowflake schema. All dimensions are SCD2, the columns are like that:
    ID (PK) SID NAME ... START_DATE END_DATE IS_ACTUAL
    1 1 XXX 01.01.2000 01.01.2002 0
    2 1 YYX 02.01.2002 01.01.2004 1
    3 2 SYX 02.01.2002 1
    4 3 AYX 02.01.2002 01.01.2004 0
    5 3 YYZ 02.01.2004 1
    On this table there are relations from other dimension and fact table.
    Need I create foreign keys for relation?
    >
    Are you still designing your system? Why did you choose NOT to use a Star schema? Star schema's are simpler and have some performance benefits over snowflakes. Although there may be some data redundancy that is usually not an issue for data warehouse systems since any DML is usually well-managed and normalization is often sacrificed for better performance.
    Only YOU can determine what foreign keys you need. Generally you will create foreign keys between any child table and its parent table and those need to be created on a primary key or unique key value.
    >
    And if I do, on what columns? SID (serial ID) is not unique. If I create on ID, I have to get SID and actual row in any query.
    >
    I have no idea what that means. There isn't any way to tell from just the DDL for one dimension table that you provided.
    It is not clear if you are saying that your fact table will have a direct relationship to the star-flake dimension tables or only link to them through the top-level dimensions.
    Some types of snowflakes do nothing more than normalize a dimension table to eliminate redundancy. For those types the dimension table is, in a sense, a 'mini' fact table and the other normalized tables become its children. The fact table only has a relation to the main dimension table; any data needed from the dimensions 'child' tables is obtained by joining them to their 'parent'.
    Other snowflake types have the main fact table having relations to one or more of the dimensions 'child' tables. That complicates the maintenance of the fact table since any change to the dimension 'child' table impacts the fact table also. It is not recommended to use that type of snowflake.
    See the 'Snowflake Schemas' section of the Data Warehousing Guide
    http://docs.oracle.com/cd/B28359_01/server.111/b28313/schemas.htm
    >
    Snowflake Schemas
    The snowflake schema is a more complex data warehouse model than a star schema, and is a type of star schema. It is called a snowflake schema because the diagram of the schema resembles a snowflake.
    Snowflake schemas normalize dimensions to eliminate redundancy. That is, the dimension data has been grouped into multiple tables instead of one large table. For example, a product dimension table in a star schema might be normalized into a products table, a product_category table, and a product_manufacturer table in a snowflake schema. While this saves space, it increases the number of dimension tables and requires more foreign key joins. The result is more complex queries and reduced query performance. Figure 19-3 presents a graphical representation of a snowflake schema.

  • [nQSError: 15003] Missing most detailed table for dimension tables:

    Hi,
    I am new to BI. I created fresh respository from the scratch.
    When run the consistency check I get the following messages.
    [nQSError: 15001] Could not load navigation space for subject area SALES.
    [nQSError: 15003] Missing most detailed table for dimension tables: [Products,Customers].
    Can anyone help me on this.
    Thank you
    subra.

    Got rid of the problem by deleting and recreating the dimension tables.
    Subra.

  • Loading Parent Keys in Customer Dimension

    I have a question about how to setup my mapping for my Customer Dimension. A subset of the dimension attributes is below:
    Customer_Key (Surrogate Key)
    Customer_Number
    Parent_Key
    Bill_To_Key
    My source table has the following fields:
    Customer_Number
    Bill_to_Customer_number
    Parent_Customer_number
    I am having difficulty in visualizing this because I can see where the current record may be for customer 10 and its parent is customer 20. Since I have not loaded the record for customer 20, I cannot use a lookup to get the surrogate key for customer 20 as it does not exist. So, my only thought was to load the dimension without the parent and bill_to keys and then run a post-mapping process to update the missing fields. This works, but takes an extremely long time (4 hours) as there are over 300,000 records that it has to update. Maybe my post-mapping process was just inefficient, I am not sure. What I am doing is running an update command on my dimension and looking up the customer-numbers from my staging table, then looking up the surrogate key in my dimension.
    Is there a better, more efficient, way to do this?
    Thanks,
    Jason

    I did a little more work with this and have developed at procedure in the post-mapping process that updates the necessary fields in about 3-4 seconds.
    Sorry for taking up extra room in the OWB forum with a sql efficiency issue.
    Thanks,
    Jason

  • About Surrogate Key and Dimension Key on OWB 10.2

    Hi, everyone.
    I am using OWB 10.2 and I have a question about Surrogate key and Dimension Key.
    I indicated the foreign key as VARCHAR2 type in Fact Table and Dimension Key as VARCHAR2 type is operated as Primary key in Dimension Table. I made Single Level in Dimension Table.
    I know that Dimension Key stores the surrogate ID for dimension and is the primary key of the table. Also, Surrogate ID should be only NUMBER type.
    So, in this case, Surrogate ID is NUMBER type
    Dimension key should be NUMBER type to store the surrogate ID.
    But, Dimension key also should operate the primary to relate Foreign key as VARCHAR2 type.
    How I can solve this confusing condition?
    Please let me know that.
    JWS

    Hi JWS,
    From a SQL point of view it should not be a problem to join a NUMBER field to a VARCHAR2 field because during execution there will be an implicite cast for the NUMBER value to a VARCHAR2 value. See the example below.
       SELECT * FROM DUAL
       WHERE   1 = '1'From an OWB point of view it is not possible to have a Dimension with an NUMBER value Key that has a relation to a VARCHAR2 value Foreign key in a Fact table. This is caused due to the creation of a Fact table in OWB in which the Foreign keys in it are build from de Dimension tables that refer to them.
    You will loose the reference to the Dimension when changing the type of the Foreign Key.
    To resolve this issue I would advise you to use a Sequence that generates your Surrogate Key (NUMBER type) for the Dimension table and store it in the Primary Key Column (VARCHAR2 type).
    When validating the mapping you will get a warning, but when executing this should give no problems.
    Regards,
    Ilona

  • Logical Key for Degenerate Dimension

    Hi Gurus,
    Need some help on the degenerate dimensions in the BMM layer.
    I have one fact table with dimension attributes and I would like to move the attributes into separate logical table and treat it as dimension.
    Now my newly created dimension has the Fact LTS and I would like to assign a logical key to the newly created table and then create the logical dimension.
    Can anyone provide some inputs on we can assign the logical key to the column?
    Thanks

    Hi Srini,
    Since my main logical fact table consists of two LTS and the dimension being created from this table will also have 2 LTS, the content level will be set to all levels on which the fact is joined.
    So I would like to create a logical dimension based out of my dimension and then assign the content level at the detail level.
    Please let me know if I am not clear.
    Thanks

  • Difference between Dimension Id and Dimension Key

    I am reading the third chapter of Rittman's OBIEE book on design of Repository.
    It says while building the BMM, don't drag the dimension Id columns from physical layer to logical layer as the BI Server takes care of the join for you but make sure you drag across the dimension key columns as you will need these later on to create your logical table keys.
    Can someone enlighten me on what is the difference between a dimension id and dimension key (may be with an example).
    Thanks.

    Besides the theory says that a fact table can reference any level of a dimension, I couldn't do it with OWB. I don't know if there is a specific way to do that, but I only could assign a dimension detail level to a fact table.
    The ID's can have different values when I use a hierarchy in a dimension. OWB generates automatically negative ID's for the more summarized levels.
    For example, a product dimension with 2 levels: category and detail. If the product has 4 categories and 20 products (detail level), the table has 4 rows for categories with negative id's. Each row has a category and the fields specific for detail level are empty. The table will have other 20 rows for the detail level, with all fields filled, and all id's positive. The table will have 24 rows in the end.

  • How can we know that size of dimension is more than fact table?

    how can we know that size of dimension is more than fact table?
    this was the question asked for me in interview

    Hi Reddy,
      This is common way finding the size of cube or dimensions or KF.
    Each keyfiure occupies 10 Bytes of memory
    Each Char occupies 6 Bytes of memory
    So in an Infocube the maximum number of fields are 256 out of which 233 keyfigure, 16 Dimesions and 6 special char.
    So The maximum capacity of a cube
    = 233(Key figure)10 + 16(Characteristics)6 + 6(Sp.Char)*6
    In general InfoCube size should not exceed 100 GB of data
    Hope it answer your question.
    Regards,
    Varun

  • Want binary_float dimension key

    Hi,
    I would like to set up a star schema with binary_float dimension keys to make them much smaller than the numeric datatype. When I do, I get validation warnings in the dimensions built in OWB. Can I ignore the warnings and use the smaller binary_float datatypes or am I setting myself up for trouble later in the project. We are running Oracle 10G 10.2.0.4 on HP Unix. We have OLAP installed but I am deploying dimensions and cubes with the "Deploy Data Objects Only" option because of all of the bugs in OWB. The fact table has about 110 million rows and about 100 gig.
    Has anyone used OWB with a star schema that uses binary_float surrogate keys?
    Thanks
    Don K.

    I am using the dimension operator in the map that loads the dimension and it seems to create the surrogate key correctly for new rows and merge the data for existing rows. I am have all of the dimensions set to Type 1. For the fact table map, I could not get the dimension objects to work correctly so I am using lookups into the dimension tables to get the surrogate keys. When I tried to use the dimension objects in the lookups it keeps adding an extra column with "_1" for the dimension key. It works correctly when I do the lookup using the dimension table. It seems like everything works okay. I am just worried about the warning message and wondering why OWB forces a number datatype when a float is much smaller.
    Thanks
    Don

  • How we use Surrogate Keys for snowflake dimension

    Hi All,
    my question is - How we use  Surrogate Keys for  snowflake dimension
    i heard from some body Surrogate Keys only work with star schema.
    please correct me if i wrong.
    Regards,
    Manish

    Hi manishcal16PPS,
    According to your description, you can only create natural key in your dimension. But it's not working when using surrogate key. Right?
    In Analysis Services, the snowflake schema of the dimensions are represented by more than one dimension table in other words its takes multiple dimension tables to define a dimension. Surrogate key are just some extra, redundant, unique key based on the
    natural key. So there's no direct relationship or some limitations between surrogate keys and snowflake schema.
    In this scenario, since there's relationship between the two dimensions, you should create natural key. For using natural key or surrogate key. Please refer to an article below:
    Surrogate Key vs. Natural Key
    For understanding star/snowflake schema, please see:
    Understanding Star and Snowflake Schemas 
    Regards,
    Simon Hou
    TechNet Community Support

Maybe you are looking for