Friday, March 22, 2013

Security Lapses in OBI 10g / 11g - Part -1



Security risk involved in OBIEE 10g /11g  or Stealing Information using OBIEE

With Evaluate Function we can able to view all back-end DB info. To demonstrate this, we use SCOTT table. Below we have modeled SCOTT,  EMP and DEPT table. And from EMP table, the SAL & COMM is removed. 

 








After modelling without 'SAL' & 'COMM' column. I am now trying the following query in my Analysis:

 











I have selected Employee Name & Job. Now in my next report, i am selecting Job like : 
    
 Evaluate('%1',EMP.JOB)


And the report looks like : 
















Now I am adding another column which would fetch the salary info: 






Now the Result : 





As you can see, even though we didn't bring in SAL column to the RPD, I can able to view the values. Now comparing it with SQL Developer result: 



The Results are matching!!! The Query generated for the OBI Report: 


WITH 
SAWITH0 AS (select distinct replace(SAL||T10687.JOB , T10687.JOB , '') as c1,
     T10687.JOB as c2,
     T10687.JOB as c3,
     T10687.ENAME as c4
from 
     EMP T10687),
SAWITH1 AS (select D1.c1 as c1,
     D1.c2 as c2,
     D1.c3 as c3,
     D1.c4 as c4,
     D1.c5 as c5
from 
     (select 0 as c1,
               D1.c4 as c2,
               D1.c3 as c3,
               D1.c2 as c4,
               D1.c1 as c5,
               ROW_NUMBER() OVER (PARTITION BY D1.c3, D1.c4 ORDER BY D1.c3 ASC, D1.c4 ASC) as c6
          from 
               SAWITH0 D1
     ) D1
where  ( D1.c6 = 1 ) )
select D1.c1 as c1, D1.c2 as c2, D1.c3 as c3, D1.c4 as c4, D1.c5 as c5 from ( select distinct D1.c1 as c1,
     D1.c2 as c2,
     D1.c3 as c3,
     D1.c4 as c4,
     D1.c5 as c5
from 
     SAWITH1 D1
order by c1, c2, c3, c4, c5 ) D1 where rownum <= 40001

Overall, if we know the back end column its easy to
get the information evaluate function.







Thursday, March 21, 2013

FETCH FIRST 65001 ROWS ONLY OBIEE 11g


FETCH FIRST 65001 ROWS ONLY OBIEE 11g 


By Default, OBI renders only 65000 rows for a report. This value can be modified
to increase the performance.However, this would be a last option to optomize performance.


To change the setting for all User:

1. Log into EM
2. Go to "Business Intelligence"
3. Click on "coreapplication" ->   "Capacity Management" Tab -> "Performance" tab

4. Under section "Maximum Number of Rows Processed when Rendering a Table View"
    Lock and edit configuration
    Enter appropriate value as per your business request 

5. Restart services.





nQSError: 38107 Not all four columns are defined for closure table


We get the below Error Message in a Parent Child Settings. 
BI consistency check will be fine. But in the Analysis, when we select the hierarchy, the report would throw this: 


    [nQSError: 38107] Not all four columns are defined for closure table



This is mainly because Parent Child settings in the hierarchy can't be set up properly when 
the BI Server is Online. 

TO FIX

  •          Switch the server to OFFLINE mode 
  •          Implement the Parent - Child settings 
  •  Save and switch the RPD to ONLINE mode. 


This would fix the issue.  :)

[nQSError: 14020] None of the fact tables are compatible with the query request

[nQSError: 14020] None of the fact tables are compatible with the query request 

Recently, I ran into this issue. lets see what the reason behind this: 

Scenario: 

  I have "Demo2" BMM Layer created from BISample Schema: Here is the BMM layer 




I have a Product Hierarchy created. Now I am providing the content level for the Logical Table Source.


In the above pic, I have selected the Bottom most level 'Product Name' as aggregation content. And for the Fact, I have selected the topmost level 'Product total' as its aggregation content.


 Now after saving the RPD &the report in dashboard throws error: 






Here, we are getting the error: 

[nQSError: 14020] None of the fact tables are compatible with the query request . 

The issue was at the Aggregation Content Level.The Correct Settings are (for the issue mentioned above)  




 Now in the Dashboard :





The drill down too works now.

 The issue was with choosing inappropriate content level for aggregation. Even for the corresponding dimensions we have to choose the content level at the lowest level of the hierarchy. 

This is applicable for both Conformed & Non-Conformed Dimensions.

Monday, March 18, 2013

OBI 11g Column Permission Setting: PROJECT_INACCESSIBLE_COLUMN_AS_NULL


In Oracle BI 10g, If a column is hidden from a user and when the User logs in there would be an error.

To fix this error, we have to change the parameter  PROJECT_INACCESSIBLE_COLUMN_AS_NULL in NQSConfig.ini

In Oracle BI 11g,  the parameter value is set to ‘YES’ :


[SECURITY]

DEFAULT_PRIVILEGES = READ;  
PROJECT_INACCESSIBLE_COLUMN_AS_NULL = YES;  # default is no

# Note that the paths below should be relative to the instance
# config directories if specified.  e.g.,
# $(ORACLE_INSTANCE)/config/OracleBIServerComponent/<instance_name>
#IGNORE_LDAP_PWD_EXPIRY_WARNING = NO;     // default is no.




Friday, March 15, 2013

New Features for Oracle BI EE11 g Release 1 (11.1.1.6)




New Features for Oracle BI EE11 g Release 1 (11.1.1.6)

1)      Ability to Limit and Offset Rows Returned:   You can use the FETCH and OFFSET clauses to constrain the number of rows returned by the SELECT statement and to offset the returned rows by a given number. Both clauses are optional and can be used together, or independently.

2)      Identify Query Candidates with Oracle BI Summary Advisor:   If you are running Oracle Business Intelligence on the Oracle Exalytics Machine, you can use the Oracle BI Summary Advisor feature to identify which aggregates will increase query performance. Summary Advisor intelligently recommends an optimal list of aggregate tables based on query patterns that will achieve maximum query performance gain while meeting specific resource constraints.

3)      Integrate the Administration Tool with a Third-Party Source Control Management System:   As an alternative to using a MUD environment, you can choose to save your repository in MDS XML format and integrate the Administration Tool with a third-party source control management system.

4)      Streamlined MUD Merge Process:  Repository developers using a multi-user development (MUD) environment can now merge and publish changes in a single step, rather than merging local changes and then publishing changes as two separate steps. They can also perform subset refreshes to perform incremental local merges with the master repository.

5)      Automated Repository Patching Process:  You can now use an option in the patch rpd command-line utility to enable automated patching without prompting for user input. In addition, new patching-specific rules are applied during patch merges.

6)      Support for Aggregate Persistence in a Cluster

7)      FIRST_PERIOD and LAST_PERIOD Time Series Functions:  You can now use the FIRST_PERIOD and LAST_PERIOD functions to compute the first and last value of an expression using the chronological key rather than the primary level key.

8)      Ability to Print the Physical and Business Model Diagrams:  You can now use Print Preview and Print to view and print the Physical and Business Model Diagrams in the Administration Tool.

SCD Types .... Part III

Here is the final post for the last  SCD type ...


Type 6
The Type 6 method combines the approaches of types 1, 2 and 3 (1 + 2 + 3 = 6).
The Customer table starts out with one record for our example Customer:
Customer_Key
Customer_Code
Customer_Name
Current_State
Historical_State
Start_Date
End_Date
Current_Flag
1
ABC
Oracle
NJ
CA
01-Jan-2005
31-Dec-9999
Y
The Current_State and the Historical_State are the same. The Current_Flag attribute indicates that this is the current or most recent record for this Customer.
When Oracle company moves to New Jersey, we add a new record, as in Type 2 processing:
Customer_Key
Customer_Code
Customer_Name
Current_State
Historical_State
Start_Date
End_Date
Current_Flag
1
ABC
Oracle
NJ
CA
01-Jan-2005
21-Dec-2009
N
2
ABC
Oracle
NJ
NJ
22-Dec-2009
31-Dec-9999
Y
We overwrite the Current_State information in the first record (Customer_Key = 1) with the new information, as in Type 1 processing. We create a new record to track the changes, as in Type 2 processing. And we store the history in a second State column (Historical_State), which incorporates Type 3 processing.
For example if the Customer were to relocate again, we would add another record to the Customer dimension, and we would overwrite the contents of the Current_State column:
Customer_Key
Customer_Code
Customer_Name
Current_State
Historical_State
Start_Date
End_Date
Current_Flag
1
ABC
Oracle
NY
CA
01-Jan-2005
21-Dec-2009
N
2
ABC
Oracle
NY
NJ
22-Dec-2009
03-Feb-2013
N
3
ABC
Oracle
NY
NY
04-Feb-2013
31-Dec-9999
Y
Note that, for the current record (Current_Flag = 'Y'), the Current_State and the Historical_State are always the same

SCD Part I     SCD Part 2

SCD Types.. Part II


Type III
This method tracks changes using separate columns and preserves limited history. The Type II preserves unlimited history as it's limited to the number of columns designated for storing historical data. The original table structure in Type I and Type II is the same but Type III adds additional columns. In the following example, an additional column has been added to the to record the Customer's original state - only the previous history is stored.
Customer_Key
Customer_Code
Customer_Name
Original_Customer_State
Effective_Date
Current_Customer_State
1
ABC
Oracle
CA
22-Dec-2009
NJ

Cons: This record contains a column for the original state and current state—cannot track the changes if the Customer relocates a second time. One variation of this is to create the field Previous_Customer_State instead of Original_Customer_State which would track only the most recent historical change.
Type IV
The Type 4 method is usually referred to as using "history tables", where one table keeps the current data, and an additional table is used to keep a record of some or all changes.
For the above example the original table name is Customer and the history table is Customer_History.
Customer
Customer_key
Customer_Code
Customer_Name
Customer_State
1
ABC
Oracle
NJ

Customer_History
Customer_key
Customer_Code
Customer_Name
Customer_State
Create_Date
1
ABC
Oracle
CA
22-Dec-2009


SCD Types... Part 1


Type 0
The Type 0 method is passive. It manages dimensional changes and no action is performed. Values remain as they were at the time the dimension record was first inserted
The most common types are I, II, and III.
Type I
This methodology overwrites old with new data, and therefore does not track historical data. Its common uses are for misspelled names
Example of a Customer table:
Customer_Key
Customer_Code
Customer_Name
Customer_State
1
ABC
Oracle
CA
In the above example, Customer_Code is the natural key and Customer_Key is a surrogate key.

If the Customer relocates the headquarters to New Jersey. The updated table would overwrite this record:
Customer_Key
Customer_Code
Customer_Name
Customer_State
1
ABC
Oracle
NJ
Cons:
·         No history in the data warehouse.
·         If you have calculated an aggregate table summarizing facts by state, it will need to be recalculated when the Customer_State is changed.
Pros: It's easy to maintain.

Type II
This method tracks historical data by creating multiple records for a given natural key in the dimensional tables with separate surrogate keys and/or different version numbers. Unlimited history is preserved for each insert.
For example, if the Customer relocates to New Jersey the version numbers will be incremented sequentially:
Customer_Key
Customer_Code
Customer_Name
Customer_State
Version.
1
ABC
Oracle
CA
0
2
ABC
Oracle
NJ
1
Another method is to add 'effective date' columns.
Customer_Key
Customer_Code
Customer_Name
Customer_State
Start_Date
End_Date
1
ABC
Oracle
CA
01-Jan-2005
21-Dec-2009
2
ABC
Oracle
NJ
22-Dec-2009
The null End_Date in row two indicates the current record version.
Pros: An aggregate table summarizing facts by state continues to reflect the historical state, i.e. the state the Customer was in at the time of the transaction; no update is needed.
Cons: If there are retrospective changes made to the contents of the dimension, or if new attributes are added to the dimension (for example a Customer_Rep column) which have different effective dates from those already defined, then this can result in the existing transactions needing to be updated to reflect the new situation. This can be an expensive database operation, so Type 2 SCDs are not a good choice if the dimensional model is subject to change.