March 6th, 2012 by Mark Rittman
Over the past few weeks we’ve run a series of articles on the blog about the new, 220.127.116.11 release of OBIEE, and talked about some of the new features that this release enables. So you may well be asking yourself, what’s involved in upgrading to this release, and is it worth the effort involved? Let’s take a look now at what’s involved in an upgrade, and what you might get in terms of benefits out of doing this.
Let’s start first with customers who are currently on OBIEE 10g, either as part of a custom install, or through their use of Siebel Analytics or Oracle Business Intelligence Applications. For these customers, moving to OBIEE 11g in general and 18.104.22.168 specifically is going to bring you a number of benefits including:
- The updated, more user-friendly dashboard interface
- Access to new features such as KPIs and Scorecards, Mapping, the Action Framework and Oracle BI Mobile
- WebLogic Server as the application server, and Enterprise Manager for systems administration
- Better support for Essbase and for ragged, skip-level and value-based hierarchies
If you’re using the BI Applications, you’ll need to consider the impact on your existing dashboards, analyses and security infrastructure, though it’s usually possible to just upgrade the underlying OBIEE installation to 11g rather than having to move the whole installation up to Oracle BI Applications 22.214.171.124 (the version that officially introduces OBIEE 11g as the BI platform). In whatever type of 10g deployment you’ve got, you need to consider how you’ll re-implement your security setup in 11g, for example moving it all to the new FMW11g-style security based around WebLogic providers, or whether you’ll just replicate what you currently do with initialisation blocks and move it across to new-style security later on.
For customers already on either OBIEE 126.96.36.199 or 188.8.131.52 who are interested in upgrading to 184.108.40.206, whilst the benefits aren’t as vast as going from 10g to 11g, there’s in my opinion quite of lot of other benefits from going to 220.127.116.11:
- Particularly if you’re still on 18.104.22.168, the 22.214.171.124 version has lots of bug fixes, and you’ll get better support from Oracle if you’re on the latest version
- There’s a bunch of enhancements to the user interface, particularly around ad-hoc analyses
- The Admin tool now supports direct integration with version control tools such as Subversion and CVS
- In each release, the security implementation within Fusion Middleware gets more “complete”, making it more likely you’ll be able to move wholesale from init blocks to proper WebLogic-based security providers
- You’re “Exalytics-ready”, as this new platform requires you to be on OBIEE 126.96.36.199
So if you’ve decided to do an upgrade, what’s involved? Well, the flowchart below sets out the basic decision steps you’ll need to go through:
Starting at the top, the first decision is whether you’re on OBIEE 10g, or 11g, currently. If you’re on 10g, then you’ll need to do a new install of OBIEE 188.8.131.52, then run the Upgrade Assistant to migrate and update your existing repository and catalog across to the new 11g installation. This article by myself in Oracle Magazine goes through the overall process.
If you’re on OBIEE 184.108.40.206 or 220.127.116.11 and you want to upgrade to 18.104.22.168, then you’ve basically got two choices. If you have an existing installation of OBIEE 11g that you want to preserve (typically, because you’ve heavily configured or customised it, or you don’t have a spare server that you can use for the new 22.214.171.124 installation), then you’d perform what’s called a Patch Upgrade, which involves doing a software-only install of OBIEE then running some post-upgrade steps to update libraries, metadata and so on. The steps to do this are here, but typically customers get in partners such as ourselves to do this as it’s quite a tricky process to get right.
Alternatively, if you’ve got enough disk space on your existing server, or a new server you want to use for 126.96.36.199, you can do what’s called an out-of-place upgrade, similar to the 10g to 11g migration, where you install 188.8.131.52 fresh, then in this case copy across the repository, catalog and metadata to the new installation, check that it’s working, and then de-commission the old 184.108.40.206 or 220.127.116.11 installation. Many customers choose this second approach as whilst it requires a bit more resources, the steps are a bit easier than the in-place, patch upgrade.
So that’s an overview of what the benefits are of an upgrade, and how you go about it. It obviously goes without saying that the team here at Rittman Mead have performed many, many upgrades to 11g over the past few years, so if you need a hand with anything, just drop us a line.