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 🙂
Repository Up-Gradation Issues
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 Stars ! 🙂
Stay tuned for more update on Enviroment/Configuration Issues and BI Catalog Issues ….
Latest update for those available at: https://debaatobiee.wordpress.com/2012/05/14/obiee-11g-up-gradation-issueschallenges-11-1-1-5-and-6-too/
Cheers , DxP
D£bashis's Technology Blog - For Geeks having technical chic .... 
You must be logged in to post a comment.