The title of this post may seem a little strange as you are probably saying to yourself there is no out of place maintenance release and a maintenance release has to be applied to an existing 11.1.2.x deployment.
If you have a look at the 11.1.2.4 installation documentation you will see the rules behind a maintenance release.
It seems crazy that say you are currently on 11.1.2.1 and want to move to 11.1.2.4 you have to first apply the maintenance release and go through the configuration before being able to move to a new environment.
There are so many different reasons that you would want to upgrade to a new version but not want to go down the maintenance release path, I went through a number of those in a previous blog
My main issues with a maintenance release are that it doesn't clean up the previous release so you can be left with lots of unneeded files and a messy system, if the EPM registry is polluted already then the maintenance release does no good to help this cause, to apply a maintenance release you have to apply to a live system and many customers cannot have that sort of downtime and risk as what happens If at any point the upgrade process fails.
What has always confused me is that most of the EPM products and application store everything in relational databases and the maintenance release surely just upgrades the database structure, I know they are some exceptions to this rule like essbase databases and the RAF RM1 directory but I will cover those later.
What makes it more baffling in previous releases you could point to 9.2, 9.3, 11.1.1.x databases and upgrade them, yet if you are on any release of 11.1.2.x this is not possible.
Looking at the EPM configuration utility in different 11.1.2 releases you can see the upgrade database options.
In 11.1.2.1 it was possible to upgrade from 9.2.1+, 9.3.3+ and 11.1.1.3+
In 11.1.2.2 the options were 9.3.3+ and 11.1.1.3+
In 11.1.2.3 the only option was 11.1.1.4+
In 11.1.2.4 there are no upgrade database options.
As you can see in all those releases there is nothing about 11.1.2.x and the likelihood that if you are currently on 11.1.2.1 and upgrading to 11.1.2.4 you will want to install on new hardware or a new OS so why is there no option to upgrade the databases, wouldn’t this make more sense that the route highlighted in the table above.
I like the way some of the other Oracle products work when a new release is to be installed you can install either to a different directory or a new machine and then run an upgrade assistant which will upgrade the existing database elements.
Anyway I wanted to find out if it was possible to go down the maintenance route on a new install so I spent a fair amount of time studying what actually happens in a maintenance release, surely if you are on 11.1.2 it doesn’t perform some kind of magic that is only possible when running on an already deployed environment.
Now let’s ignore that not supported statement for a while as maybe by the end of this post it might be clearer if this is a viable option.
So here is an example of the process I followed on a fresh install of 11.1.2.4 on new hardware but still trying to replicate a maintenance release from 11.1.2.3
The first step really is take an LCM extract of HSS provisioning from the 11.1.2.3 environment as in the 11.1.2.4 install the Shared Services database is going to be blank, you wouldn’t want to ever contemplate upgrading the database as it contains configuration information like will be only valid in 11.1.2.3 environment.
I have found that LCM provisioning extracts work pretty well across different versions of 11.1.2 and it is one area that is not too painful in migrations and upgrades.
I have taken a copy of all the other relational schemas e.g. Calculation Manager, EPMA, Planning, HFM, RAF, FDMEE and so on, also the RAF RM1 folder and the essbase app directory and sec file.
I also created a blank schema which will be only temporally be used and can be dropped at the end.
11.1.2.4 was then installed and just the HSS database configured.
After spending time investigating what happens in a maintenance release I narrowed it down to a few changes that occur within the EPM registry for each product component.
The problem at this point is if you run a registry report there is nothing in the EPM registry for the various products.
So basically I ran the EPM configuration utility and only selected “configure database” for each product.
I pointed all the database configurations to the temporary schema I created so I could populate the registry with the required product component information.
Running the configuration utility again you will see all the database sections are now configured.
Running a registry report now reveals sections for each product and the important Instance and Systems tasks.
At this point it is no different than a standard configuration.
As you can see the versions in the registry are all at 11.1.2.4 and the relational configuration has a value of configured.
You may be asking well why couldn't I just have pointed to the copies of the 11.1.2.3 schemas and reuse them, well you can but unfortunately it will not upgrade the database structure and leave it at the previous version which would not be good.
Going back to a maintenance release upgrade if you look in the EPM registry at the correct point in time you will see changes are made.
I am not going to give away all the secrets of the changes that are made but by using the epmsys_registry tool it is possible to set the registry up in such a way that it believes it is part of a maintenance release.
The format for the updates are:
epmsys_registry updateproperty #<Object ID>/@<Property Name> <Property Value>
Once you have a full list the changes can be implemented for all products pretty quickly.
Running the EPM configuration again returns all the database sections to require configuration like in a maintenance release.
All the other required configuration sections are also pre populated and are going to be treated exactly like a new configuration.
In the configure database panel I can set all the databases to the ones copied from 11.1.2.3
Next you just run through the configuration like you would with any new configuration.
During the configuration all the databases will be upgraded just the same as in a typical maintenance release.
Even the RAF directory can be copied from the release that is being upgraded and both the database / RM1 folder are upgraded and in sync.
Once complete and up and running then the same sort of processes can be carried out for upgrading applications.
The planning wizard process is the same as a maintenance release except the data sources will require pointing to the new databases/schemas.
The applications can then be upgraded.
Once upgraded they will be registered in Shared Services under default application groups
For HFM the upgrade applications from an earlier release can be selected in the configuration utility.
The applications will also be registered in Shared Services, for more information about what happens in the upgrade then take a look at my previous 11.1.2.4 maintenance release post.
As usual EPMA doesn’t play ball but there is a simple solution, the problem with EPMA applications is that there status will be set as deployed but they have yet to be registered with Shared Services.
The diagnostics can be run for each application and then set back to ‘Not Deployed’ so this allows full functionality and the apps can be deployed as normal.
With essbase it is possible to copy app directory over and with a little clever manipulation of the sec file the apps will automatically register in Shared Services.
Though to be honest with essbase I would always export/clear/import data to bring it in line with the latest release plus there are a number of alternative methods to upgrade.
If the essbase index/data locations are going to be different from the source environment then you can use the trick I previously blogged about.
The remaining products shouldn’t need much attention and will be automatically upgraded.
Once completed you can then import all the provisioning with the LCM backup that was taken from the previous release.
Now you may not be convinced with this process and be saying that it is not supported and the database for each of the products is not a clean 11.1.2.4 version because it has been upgraded.
Well now that everything is up and running and using the 11.1.2.4 code line you could easily run the EPM clone utility to export all the artifacts out using LCM.
I wrote a comprehensive post on the utility which you can read all about here.
Basically by running a simple bit of command line you can get the utility to extract everything out.
Once completed you will have LCM extracts for all products in one directory.
The EPM configuration utility can be again and all of the configure database sections selected, when asked choose to drop and re-create tables.
This this should clear all the database tables and it will be like a clean install. (watch out for things like HFM app tables as it doesn't clear them out so well)
Now just delete the registered apps from Shared Services and use the LCM full export and import everything back in, hopefully it should run a lot smoother because the export will be at the same version.
So by using this technique you have a clean install and a full set of LCM artifacts at the same version without affecting the source environment.
The beauty of this method is that you can pick and choose the products you would like to apply the maintenance release to and there may be slightly more overhead in process time but I can tell you it is much easier than trying to convert all the LCM files from a previous release to the release they are to be imported into.
This process has been tested out on an upgrade from 11.1.2.1 to 11.1.2.4 and not using sample apps but a live environment and it worked pretty flawlessly though that doesn't mean I am certifying it for everyone.
If you would like to know more then get in touch but please don’t ask for a step by step guide :)
If you have a look at the 11.1.2.4 installation documentation you will see the rules behind a maintenance release.
It seems crazy that say you are currently on 11.1.2.1 and want to move to 11.1.2.4 you have to first apply the maintenance release and go through the configuration before being able to move to a new environment.
There are so many different reasons that you would want to upgrade to a new version but not want to go down the maintenance release path, I went through a number of those in a previous blog
My main issues with a maintenance release are that it doesn't clean up the previous release so you can be left with lots of unneeded files and a messy system, if the EPM registry is polluted already then the maintenance release does no good to help this cause, to apply a maintenance release you have to apply to a live system and many customers cannot have that sort of downtime and risk as what happens If at any point the upgrade process fails.
What has always confused me is that most of the EPM products and application store everything in relational databases and the maintenance release surely just upgrades the database structure, I know they are some exceptions to this rule like essbase databases and the RAF RM1 directory but I will cover those later.
What makes it more baffling in previous releases you could point to 9.2, 9.3, 11.1.1.x databases and upgrade them, yet if you are on any release of 11.1.2.x this is not possible.
Looking at the EPM configuration utility in different 11.1.2 releases you can see the upgrade database options.
In 11.1.2.1 it was possible to upgrade from 9.2.1+, 9.3.3+ and 11.1.1.3+
In 11.1.2.2 the options were 9.3.3+ and 11.1.1.3+
In 11.1.2.3 the only option was 11.1.1.4+
In 11.1.2.4 there are no upgrade database options.
As you can see in all those releases there is nothing about 11.1.2.x and the likelihood that if you are currently on 11.1.2.1 and upgrading to 11.1.2.4 you will want to install on new hardware or a new OS so why is there no option to upgrade the databases, wouldn’t this make more sense that the route highlighted in the table above.
I like the way some of the other Oracle products work when a new release is to be installed you can install either to a different directory or a new machine and then run an upgrade assistant which will upgrade the existing database elements.
Anyway I wanted to find out if it was possible to go down the maintenance route on a new install so I spent a fair amount of time studying what actually happens in a maintenance release, surely if you are on 11.1.2 it doesn’t perform some kind of magic that is only possible when running on an already deployed environment.
Now let’s ignore that not supported statement for a while as maybe by the end of this post it might be clearer if this is a viable option.
So here is an example of the process I followed on a fresh install of 11.1.2.4 on new hardware but still trying to replicate a maintenance release from 11.1.2.3
The first step really is take an LCM extract of HSS provisioning from the 11.1.2.3 environment as in the 11.1.2.4 install the Shared Services database is going to be blank, you wouldn’t want to ever contemplate upgrading the database as it contains configuration information like will be only valid in 11.1.2.3 environment.
I have found that LCM provisioning extracts work pretty well across different versions of 11.1.2 and it is one area that is not too painful in migrations and upgrades.
I have taken a copy of all the other relational schemas e.g. Calculation Manager, EPMA, Planning, HFM, RAF, FDMEE and so on, also the RAF RM1 folder and the essbase app directory and sec file.
I also created a blank schema which will be only temporally be used and can be dropped at the end.
11.1.2.4 was then installed and just the HSS database configured.
After spending time investigating what happens in a maintenance release I narrowed it down to a few changes that occur within the EPM registry for each product component.
The problem at this point is if you run a registry report there is nothing in the EPM registry for the various products.
So basically I ran the EPM configuration utility and only selected “configure database” for each product.
I pointed all the database configurations to the temporary schema I created so I could populate the registry with the required product component information.
Running the configuration utility again you will see all the database sections are now configured.
Running a registry report now reveals sections for each product and the important Instance and Systems tasks.
At this point it is no different than a standard configuration.
As you can see the versions in the registry are all at 11.1.2.4 and the relational configuration has a value of configured.
You may be asking well why couldn't I just have pointed to the copies of the 11.1.2.3 schemas and reuse them, well you can but unfortunately it will not upgrade the database structure and leave it at the previous version which would not be good.
Going back to a maintenance release upgrade if you look in the EPM registry at the correct point in time you will see changes are made.
I am not going to give away all the secrets of the changes that are made but by using the epmsys_registry tool it is possible to set the registry up in such a way that it believes it is part of a maintenance release.
The format for the updates are:
epmsys_registry updateproperty #<Object ID>/@<Property Name> <Property Value>
Once you have a full list the changes can be implemented for all products pretty quickly.
Running the EPM configuration again returns all the database sections to require configuration like in a maintenance release.
All the other required configuration sections are also pre populated and are going to be treated exactly like a new configuration.
In the configure database panel I can set all the databases to the ones copied from 11.1.2.3
Next you just run through the configuration like you would with any new configuration.
During the configuration all the databases will be upgraded just the same as in a typical maintenance release.
Even the RAF directory can be copied from the release that is being upgraded and both the database / RM1 folder are upgraded and in sync.
Once complete and up and running then the same sort of processes can be carried out for upgrading applications.
The planning wizard process is the same as a maintenance release except the data sources will require pointing to the new databases/schemas.
The applications can then be upgraded.
Once upgraded they will be registered in Shared Services under default application groups
For HFM the upgrade applications from an earlier release can be selected in the configuration utility.
The applications will also be registered in Shared Services, for more information about what happens in the upgrade then take a look at my previous 11.1.2.4 maintenance release post.
As usual EPMA doesn’t play ball but there is a simple solution, the problem with EPMA applications is that there status will be set as deployed but they have yet to be registered with Shared Services.
The diagnostics can be run for each application and then set back to ‘Not Deployed’ so this allows full functionality and the apps can be deployed as normal.
With essbase it is possible to copy app directory over and with a little clever manipulation of the sec file the apps will automatically register in Shared Services.
Though to be honest with essbase I would always export/clear/import data to bring it in line with the latest release plus there are a number of alternative methods to upgrade.
If the essbase index/data locations are going to be different from the source environment then you can use the trick I previously blogged about.
The remaining products shouldn’t need much attention and will be automatically upgraded.
Once completed you can then import all the provisioning with the LCM backup that was taken from the previous release.
Now you may not be convinced with this process and be saying that it is not supported and the database for each of the products is not a clean 11.1.2.4 version because it has been upgraded.
Well now that everything is up and running and using the 11.1.2.4 code line you could easily run the EPM clone utility to export all the artifacts out using LCM.
I wrote a comprehensive post on the utility which you can read all about here.
Basically by running a simple bit of command line you can get the utility to extract everything out.
Once completed you will have LCM extracts for all products in one directory.
The EPM configuration utility can be again and all of the configure database sections selected, when asked choose to drop and re-create tables.
This this should clear all the database tables and it will be like a clean install. (watch out for things like HFM app tables as it doesn't clear them out so well)
Now just delete the registered apps from Shared Services and use the LCM full export and import everything back in, hopefully it should run a lot smoother because the export will be at the same version.
So by using this technique you have a clean install and a full set of LCM artifacts at the same version without affecting the source environment.
The beauty of this method is that you can pick and choose the products you would like to apply the maintenance release to and there may be slightly more overhead in process time but I can tell you it is much easier than trying to convert all the LCM files from a previous release to the release they are to be imported into.
This process has been tested out on an upgrade from 11.1.2.1 to 11.1.2.4 and not using sample apps but a live environment and it worked pretty flawlessly though that doesn't mean I am certifying it for everyone.
If you would like to know more then get in touch but please don’t ask for a step by step guide :)
No comments:
Post a Comment
Note: only a member of this blog may post a comment.