Objective of this thread is to walk through across several issues found in RPD post Up-gradation from 10g to 11g. Let’s first start with OBIEE 11g Warnings / Errors and then I quickly moved to other areas to explore other glitches …. Idea is to bring a valuable thread for target audience to include important topics rather the conventional one found over several other fellow Bloggers post !

Nice Oracle documentation is there to detail out the step by step up-gradation process…

http://www.oracle.com/webfolder/technetwork/tutorials/obe/fmw/bi/bi11115/upgrade/upgrade_to_11g.htm

Pretty simple huh?? Yes …. Until you know the unknown and erratic issues on your way soon … So hold your seat belt tight to fly across the unknown territory with several assumptions/concerns/endless issues/unpredictable behaviors and finally achieving the goal …successful Up-gradation :)

1)      There are lots of unusual warnings have been observed after up-grading the RPD to 11g version. Some of them are really nonsense. However as Oracle said that strong consistency checker is involved in the whole process to mitigate the future risk of enhancement resulting these number of warnings. Details of the warnings could be found at 11g Up-grade planning ref doc:

Refer to section: 1.2.1.1 Enhanced Repository Consistency Checking

http://docs.oracle.com/cd/E21764_01/bi.1111/e16452/bi_plan.htm

Each warning has some specific number by which we can call them. Let’s see each of them one by one:

A)     Warnings [39028] 

Resolution: Call interface checked by consistency checker to see how compatible it is with the underlying database specification and how much it is aligned with database features defined in repository. Typically we have seen after up-gradation the features retains what is in 10g. In that case, solution is to make it Default database feature against each Physical layer database. That will remove the warnings however make sure that none of your overriding database features will cause performance concern. Some of them in 10g which could be done to get performance benefit in terms of better utilization of joins. So be careful before making them default and if that is mandatory to gain the similar performance benefits then that needs to be retained even if that will throw warnings irrespective of Oracle’s recommendation.

B)      Warnings [39055]/[39054]

Resolution: Typically the join missing between the mentioned Logical Dimension and Facts. Adding the extra join will resolve your problem. Make sure it is necessary and could not cause impact in other areas or otherwise ignore if you are not going to extract the projects. It is not really mandatory to fix these warnings. We remove these warnings to get some lesser counts.

Out of this warning context, in terms of join conditions I have experienced issues with Physical layer join problems post up-gradation. Some of my join conditions were invalid and this has been observed particularly in Usage Tracking physical database. However the error it will throw is really not comprehensible and hence I removed the invalid physical joins and add them back and did similar for logical joins too. This might be one-off incident but that is true for me.

C)      Warnings [39057]

Resolution: The reason of this warning as per my analysis is , whenever you add inner joins/outer joins with logical tables in the single logical table source you definitely specify the join condition with attributes and it is not a mandate to map those logical columns with the column mapping. But this warning expects attributes participated in the join conditions should be part of the column mapping. Necessarily older designs either 7.8.5 or 10.1.3.4, it is not mandatory to be those columns in the column mapping. But here at-least the join condition column needs to be in the column mapping. I don’t know the rationale behind this extra check and I don’t know the other possible solutions to remove these warnings. But the above mentioned approach helpful for me and I am sure if you are unlucky enough but want to fix these warnings then you might have to do a lot of hard-work as one of our repository we fix around 550 of this kind of warnings … Really annoying …! Without much business or design benefit. Good luck

D)     Warnings [39059]

Resolution: Most unwanted and most confusing and problematic warnings. This warning emphasis some best practices to be adhered. Typically we have seen some snow-flaking across dimensions and leveling those dimensions in different level of hierarchy across logical table source resulting these problems. You seem to hit this problem due to incorrect and un-orthodox content aggregation leveling. However there might be several other angles and reasons too.As in the document it specified that  ”a new consistency check warning (39059) highlights when a fact logical table source joins to a lower-level dimension logical table source, resulting in a potentially invalid join. If you get a 39059 warning after upgrade, verify that the join is as intended and does not result in incorrect double counting.”

Fixing those warnings is really a tedious jobs specially when my RPD already build in 7.8.5, migrated to 10g and then 11g as lot of developers mind-blowing design already enriched the RPD a lot and while you don’t know the business reason there is no point of fixing those warnings as this caused the design changes in greater aspects and this is quite impossible if you are old enough with your RPD. Fixing this warning is good for health of the RPD for new development & indeed bad for developers but bit difficult and quite risky for older data models. For our case we left ~1500 warnings in our Repository as it is as we are not sure how much the data impact will be there in our ~650+ reports.As per Oracle “ If the join is as intended, then ignore the 39059 warning”

 Last but not the least

Apart from those warnings all errors should be fixed to have a Consistent repository and essentially you need to note that while there are 3 errors in repository your warnings count could be say 20 but after fixing those errors (which you must have to do) count can increase to 600 .Sound strange.. ! Really not , as when Consistency checker encounter error it skips showing the warnings and insist you to fix the errors before it proceed with further level of checks ! So best of luck. One more things don’t worry much about the warnings … even if there are your repository is consistent and none of the reports (apart from the complex one in catalog specially the combined requests) will show incorrect results. We have experienced this and you can easy to go ahead with warnings …. Let’s keep the life simple …. Now lets see what Oracle made for us to lead simple life …

Essentially Oracle has faced lot of questions with this mind-blowing checker (!) (yes I mean it) and they release a patch for OBIEE 11g (11.1.1.3) to hide those warnings(not errors) but not yet for 11.1.1.5. They are yet to fix this in future version 11.1.1.6, if any. See Oracle Doc ID 1365964.1 [How to Hide Selected Consistency Check Warnings in BIEE 11G]

Patch 11810367

As of when I am writing this thread for BIEE 11.1.1.5 Development teams are working on a Patch for BIEE 11.1.1.5. Please open an SR with BIEE Support to check if the Patch is available for your platform or not. This issue will be fixed in BIEE 11.1.1.6.

2)      During up-gradation the Upgrade Assistant migrate the Security groups / roles and users from Repository to Weblogic security policy store and hence it is the best practice to up-grade the repository at-least irrespective of whether you upgrade the catalog at all. But if you think of to up-grade the catalog first then you will definitely lose all the Catalog groups and permissions setup inside your Catalog objects even if you up-grade the RPD next time. So upgrade either RPD or RPD and Catalog both and never Catalog alone.  You will hit a lot of unforeseen behavior post up-gradation with catalog privileges as it has been observed that the permissions are not propagated properly in the online catalog.

3)      Job Manager “Administrator” Password is not upgraded with RPD upgrade .It still retains the password of source RPD and you need to change it manually.

4)      Usage Tracking (S_NQ_ACCT) and Scheduling objects (S_NQ_) moved from the target database area to RCU schema and the object definition itself changed like new column added and several column types changed. So ideally it is better to copy the 11g provided Usage tracking RPD layers and merge it with your upgraded RPD .However in that case all the Usage Tracking customization needs to be properly applied too.

5)      “Act As Proxy User” functionality no more going to work with Administrator while this user is part of Weblogic Default Authenticator scheme. Ideally this Administrator user-created by default in every Weblogic Default authentication scheme as it is automatically migrated from RPD to WLS security policy. Considering your RPD has authentication scheme set to LDAP in that scenario “ACT As” is no going to work with “Administrator” as dual switching of mixed Authentication scheme not possible (in this case one is WLS authentication and another is RPD LDAP authentication).So any of the LDAP user could Act as proxy users for other LDAP users and thus authentication scheme belongs to one area only. Otherwise you will see that Act As will not populated the list of proxy users and the list will be NULL or blank.

Another way will be to define the LDAP in Weblogic itself and maintain the Administrator user in the LDAP tree so that you can use Administrator to ACT AS proxy for other LDAP users.

So either all should be LDAP of Weblogic Default Authenticator or LDAP of RPD only at a time.

6)      Post upgrade Repository could not be opened online using the Administrator password .Resolution is perform the refresh GUID activities. You will get below error in log file:

[nQSError: 13041] The GUID of user ‘Administrator’ does not match user reference GUID at the repository. Please ask the administrator to delete the old user reference at the repository and login again. The process is explained under Oracle Doc ID 1265802.1. There might be several blog in the net which already listed down the steps.

7)      In our implementation we have seen that upgraded 11g repository crashes the environment while user try to log in .However this behavior not observed for all users. Digging into details our finding is that “Log Level” value populated from external table authorization should not be NULL otherwise 11g repository will crash your environment. So make sure the loglevel field must be updated at-least with some numeric value.

8)      While Saving Online RPD Changes in the Administrator Tool of OBIEE 11g Throws “[nQSError: 37005] Transaction update failed.” This is an Unpublished bug 9884975 – 11g admin tool receives nqserror: 37005 when saving online rpd changes

9)      During check-in and saving the repository we have encountered getting error : [46036] internal assertion: condition m_lock.isacquired() . For both 8) and 9) apply Patch 12909840

10)      Issue exist with Presentation column level security default access and it is not working properly with the PROJECT INACCESSIBLE COLUMN is NULL settings of NQSCONFIG.INI.Get the patch from Oracle to get rid of this issue.

11)      I have seen several connection related problem from RPD to database and most of the errors are Unable to connect the database. This happens due to Oracle Native OCI call and Middleware Native OCI conflict. As a best practice I usually follow below rule:

Copy the same tnsnames.ora across Oracle Home and Middleware home .Then create 3 variables in Windows : ORACLE_HOME , BI_ORACLE_HOME , ORACLE_BI_HOME as Middleware Home directory and then ORACLE_INSTANCE as Middleware instance directory . Bounce all services and you will be clean with any connection.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I hope above information is helpful for your 10g -) 11g Up-gradation process . Then don’t forget to rate this thread as above with starts !

Stay tuned for more update on Enviroment/Configuration Issues and BI Catalog Issues ….

Cheers , DxP

Here’s an excerpt:

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 160,000 times in 2011. If it were an exhibit at the Louvre Museum, it would take about 7 days for that many people to see it.

Click here to see the complete report.

The actual process to do this is using the Migration assistant under Security realm of  Weblogic Console. See below image . Go to Export tab and put any directory name where you want the exported copy like : D:\Share\Security …

The .dat file list would be like below:

Now once you get this list click on Import button of the target environment (say. Test) and simply click the update button . You will see all list of users and groups will be automatically migrated from Dev to Test .

Cheers…

Briefly, I had the full installation with Weblogic , RCU , Oracle in some path in Windows Server(2008,R2, 64 bit) and after De-installation I want to continue using the same path so all the De-install process should be very clean so that it will not leave any footprints of previous installation in any of the places for a successful installation once again.

Here you go …

• Stop all running processes for Admin and Managed servers including BI components services. Stop all the processes, if any, created during service process creation for e.g. Windows Process.
• Remove the Weblogic Server using the Un-installation wizard under Control Panel.
• Perform De-install from Oracle Business Intelligence -) De-install option of Program menu
• Drop the RCU schemas using the RCU batch file -) Drop option
• Manually remove the RCU Tablespace DBF file (to have a clean new RCU schema) . In my case I didn’t remove the DBF file as the Database server is under DBA’s control .Hence, to be safer side I re-create the RCU during the fresh installation process under different tablespace. This will make sure nothing is going to messed up with your previous installation … See below image:

• De-install Middleware Oracle home (traverse to ..\[MIDDLEWARE_HOME]\Oracle_BI\oui\bin\ and execute below from command line: setup.exe -deinstall)
• De-install the Middleware common Oracle Home  (traverse to ..\[MIDDLEWARE_HOME]\oracle_common\oui\bin\ and execute below from command line: setup.exe -deinstall –jreLoc  ..\[MIDDLEWARE_HOME]\Oracle_BI1\jdk)
• Remove the Middleware Home directory with all contents forcefully,if reqd.
• Remove the environment variable pointing to earlier locations and the relevant paths if any. This is Important!
• Re-boot the entire server.
• Delete the Oracle common keys , if any, from registry. This is Important ! Most of the common problem lies here . So in my case I follow the process of finding my Middleware Home path from Registry and delete all relevant Keys and values . Be careful while playing with registry
• Remove the windows service process key from registry , if any
• As in my case I don’t need to De-install my Oracle Client/DB Home hence I skip the process as I going to re-use the same Oracle Home in the next installation time.So if you are going to do the same probably you can skip De-installing your Oracle Client/DB home.

Thats it , Welldone! until you have performed the clean installation once again …..:)

The new journey begins as we landed to New year 2012… Forgetting the old torn memories as it should be better to be in oblivion …. Keep the memories of delightful times and live in each day now as it is to be spent…. !  It is an immense pleasure to let you know my best New year wishes for you … The people … my near and dear ones , my enemy , my followers (Twitters et all) , my critics , my seniors and beloved juniors , finally them whom I don’t know when they silently came to my blog and escape … Hope for all of them it will be a very good year ahead of you both personally and professionally.

Thank you all who encouraged me to carry on my blog and hopefully GOD & you all bless me and it will be continued in greater extent in this year and I hope my threads someway,  sometime  help you !

last but not the least a Season Greetings Card for all of you… Smile

Cheers …. and bonne santé …. !

Yours ,

Debashis (DxP)

See you soon with some new geeks and hope you will enjoy … Till then …

OBIEE 11g Graph colors are quite jazzy comparing to 10g… this is one of the recent feedback we received from clients in our post up-gradation review of codes .So one of the obvious requirement came into picture is that, how do we retain the 1og Graphical color schemes in 11g. This could be easily done by playing across the XML codes for color definition .

Lets do it …

As you might already be aware of that 10g Color contents (hex-codes) definition are stored in the palette.cxml file. So what you need to do is only copying the color Hexcodes from 10g files and put those under the file located : “..\Middleware\Oracle_BI1\bifoundation\web\msgdb\s_blafp\viewui\chart\dvt-graph-skin.xml” having the below sample syntax  (do the same for other style folders like s_FusionFX  if you need it)

So below content copied to the above xml and put this between the first and last tag of  SeriesSlice :

<SeriesItems>
<Series id=”0″ color=”#A4D5F9″ borderColor=”#A4D5F9″/>
<Series id=”1″ color=”#5592D0″ borderColor=”#5592D0″/>
<Series id=”2″ color=”#EFD084″ borderColor=”#EFD084″/>
<Series id=”3″ color=”#687FA1″ borderColor=”#687FA1″/>
<Series id=”4″ color=”#CFC4E5″ borderColor=”#CFC4E5″/>
<Series id=”5″ color=”#8D9EB7″ borderColor=”#8D9EB7″/>
<Series id=”6″ color=”#5898AA” borderColor=”#5898AA”/>
<Series id=”7″ color=”#CEE4EA” borderColor=”#CEE4EA”/>
<Series id=”8″ color=”#90B5D1″ borderColor=”#90B5D1″/>
<Series id=”9″ color=”#F6E795″ borderColor=”#F6E795″/>
<Series id=”10″ color=”#C7C1C1″ borderColor=”#C7C1C1″/>
<Series id=”11″ color=”#85A8EE” borderColor=”#85A8EE”/>
</SeriesItems>

Make sure all the services restarted before the change to be effective.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

See below difference before applying the XML(11g Original) and after applying (aligned with 10g color).

N.B:- It has been observed that though the 10g color scheme applied for 11g but it is not at per with existing 10g colors and there are slight deviations in terms of colors which is not eye-catching but somehow not matching exactly due to the difference of the rendering engine of 10g and 11g.

A worth to note is that, in our implementation we have seen that in several charts the color change is not propagated and hence it seems that the color scheme is not applied properly as per the defined XML. However if you edit the chart and remove any measure and then drag the same measure again we see that the color starts changing as per XML . The behavior seems to be unpredictable for us. Assumption is that ,it might happened due to some internal cache specially for the chart engine here.  But the problem is not observed for any new reports created in answers in 11g and it starts reflecting the new colors scheme from very beginning.

 [nQSError: 13043] Could not get repository password for CSF key ‘repository.MyRPD_BI0001′ from CSF: [46147] The Repository credential does not exist.

The reason behind the issue is that I had just copied the RPD from 11g Dev env and Paste it to 11g Test env and change the RPD name in NQSConfig.INI file and try to up the server using unconventional way just to figure out what kind of check it does …. Quite intelligent… Each RPD has a unique identifier and it is stored in Credential Store and you can’t bypass the Credential store verification during your update of the RPD. So always do a clean deployment process otherwise you will be messed with it

So above error you will be getting for incorrect deployment procedure of your repository. This is specially recommended during the env migration . However I have seen in the same env if you are doing the copy paste of the same RPD and rename it and then change the name in NQSConfig.INI it somehow works out fine.

Again don’t try to Update Account GUID’s (FMW_UPDATE_…. under NQSCONFIG and UpdateAccountGUIDs under instanceConfig) and Deployment of RPD at the same time .It will give you erratic behavior. And in those scenario your RPD and Catalog name is always going to refer old name rather new one.

Hey Weblogic , not a good friend yet with OBIEE 11g causing a nightmare for last couple of weeks while engaged in couple of migration project from OBIEE 10g to 11g .Overall experience is not satisfactory with this new planet …. Weblogic … in the Universe…. Lets make it simple and manageable… !!

Okay coming to the point … Now not with Weblogic …but the analytics/reports piece itself …

As per the 10g release is concerned using some conditional clause any NULL value could be presented as 0 specially when there is divide by zero scenario . In 10g it is pretty easy to handle such situation from RPD or Webcatalog but in 11g it is a proven bug . Oracle Ref: Internal Bug Id: 13054445 .

Came to our notice in Pivot table operation neither the CASE WHEN in RPD/Catalog ,not the IFNULL or NULLIF handler able to replace the NULL value with 0 for my Pivot table. Forget anything to do in any of the config file or the database feature in RPD . Nothing will be helpful at all…If yes , your comments are most welcome !

Resolution: Nothing . Ask Oracle to get a patch if this is critical for you or wait till unplanned 11.1.1.7.0 release.