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