Repository



REPOSITORY


1. Make sure you have a level-based dimension for each of your logical table dimensions (both conforming and non-conforming).
2. For the fact table measures, set the levels as you did in 10g with the non-conforming dimensions at the Grand Total logical level for each measure.
3. For the fact table LTSs, set the logical level in the Content tab to the dimension's lowest level for each conforming dimension (leave the non-conforming dimensions level blank).

Unfortunately, the query generated in 11g will add an additional sub-query to the mix even though it doesn't appear to have any benefit. Therefore in 10g, if you have two logical fact tables with non-conforming dimensions, three sub-queries were required to create the result set. Two queries for the facts and their related dimensions and a final full outer join to stitch the results together. In 11g, you have one query without the measures, two queries with the measures, and the final outer join.

I am talking to Oracle support about this issue, but I haven't made much progress yet. I asked development to confirm my repository design and they say it checks out. They indicated that the additional query is a design change/enhancement. I am not getting a warm and fuzzy on this one. I'll post back if I make any progress.

Oh, did I mention that this change has broken queries where I attempt to combine fields from two non-conforming dimensions?!? This worked fine in 10g.

TIME DIMENSIONS- COMPARING DIFFERENT MONTHS
Ago(<<Measure>>, <<Level>>, <<Number of Periods>>)

Sample Application : SampAppLite in
C:\oracle\Middleware\instances\obieedev01\bifoundation\OracleBIServerComponent\coreapplication_obis1\repository
Renaming objects in the repository
1-It can be catastrophic, first back up all data.
2-You can rename the display name, but it will only have a “visual effect”. The underlying code will still point to the real business area. If this option is chosen, the names in the repository and the analysis will be different, which will create confusion.
3-In all cases, when changes are made a refresh must be done. The “display name” of the subject area will eventually show up in the list to pick up the Subject Areas, and in the analysis when using the catalog, BUT you must make sure to (a) reload server metadata and (b) refresh. Sometimes it takes a while to take the changes, not sure about the cause, but refresh whenever possible.
RENAMING OBJECTS IN A WAY THAT IT WORKS AND IT DOES NOT BREAK THE ANALYSIS
1-Backup the analysis
2-Open the analysis in Edit mode
3-Go to the advanced tab
4-Change the name of the repository here

  

THIS WILL NOT WORK if the analysis is a bit complex: if there are dimensions with hierarchies for instance.


5-Try running, it should work
Problem: Creating a copy of the repository  between environments will break the Administrator userid
SOLUTION(1): the original (seed) repository should be copied directly from the server, and then that one can be modified.,i.e., copy the file from unix to windows, and then work with it if necessary.
SOLUTION(2):may be doing a merge will keep all the IDs.


ERROR when trying to do rowcount referencing a Subject area that does not longer exists

Solution: Go to the ODBS connection for the repository and remove the default settings

 

 
ERROR
Level has drilldown levels assocaited with multiple (likely overlapping) dimensions.
Please check logical table key definitions, particuarly for fact tables, and level-based measure definitions
SOLUTION=
The logical key of the dimension table is mapped to the lowest level of the  hierarchy and specified as the level key. This logical column should map to the  key column of the lowest level table in the dimension source.
The key at each level must be really a key, for instance, for a month to be key it must be yyyy-mm, otherwise just simply saying “MM” is not a key

Definitions
A logical key for a fact table must be made up of the key columns that  join to the attribute tables. Logical foreign key joins may be needed if  the Oracle BI Server is to be used as an ODBC data source for certain  third-party query and reporting tools



ERROR None of the fact tables are compatible with the query request LMS Course.ACTIVE

State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 43113] Message returned from OBIS. [nQSError: 43119] Query Failed: [nQSError: 14020] None of the fact tables are compatible with the query request LMS Course.ACTIVE. (HY000)

Soltuion1: Check all physical and business joins
Soltuion2: Pull the table from the physical model and start from scractch.
Soltuion3:Try re-loading Administraion-XML data
Soltuion3:Try deleted and rebuilding logical dimensions for that table



 

 

 

 

 

 

 

ERROR=38073 - Dimension ‘@1%ls‘ has multiple leaf levels which are not identical

Change the default number of levels from 1 to 3 (or as many as you have)
 

 
 

PROBLEM: Physical Layer is unable to retrieve data, update counts are not updated
Possible causes all in the Database And Connection Pool properties:
(1)     Database property set to “Virtual Database
(2)    Database properties set to a different one other than the Oracle version (i.e., we have 11g and property says 9)
(3)    Properties are set differently (reset to Default)
(4)     Using repository variables for username/DSN will not work for the update count
 


No comments:

Post a Comment