I’m working, once again, on a 7.8 to 8.1.1.5 upgrade. This time, we’re looking to migrate from Windows 2003 to 2008 (SP2 for 32-bit servers, R2 SP1 for 64-bit) along with 10.2.0.0 to 11.2.0.2 on the Oracle side. All very interesting!

I came across an issue that I’d like to share with you: when performing the Siebel Database Upgrade (upgrep), the upgrade wizards executes some SQL against the ‘Prior Customer Repository’. There’s no magic to this – have a look at the repos_upgrade.sql file in the Oracle (or equivalent) folder in the dbserver installation.

Now, there’s a problem with 11.0.2.1 (which is what you’ll get if you download from the Oracle Software Deliver Cloud – aka eDelivery). The upgrade script will actually corrupt your repository definition.

You’ll know you’ve been rumbled if you run the upgrep step then try to connect to the ‘Prior Customer Repository’ via Siebel Tools – you’ll get:

ORA-24345: A Truncation or null fetch error occurred

This can be resolved by running the following against your Oracle database, then restarting the database instance:

alter system set "_add_col_optim_enabled"=false SCOPE= BOTH ;

You’ll need to restore your 7.x database and run the upgrade process again though

Check out MOS article 1073581.1 for more info.

There are many pitfalls in the Siebel business – as Oracle support more and more diverse integration platforms, incompatibility will continue to be an issue for us. If anyone has experience of other such issues, please post your thoughts.

The next major stage of the process is to upgrade your repository configuration – a process called Repository Merge.

Having completed the database upgrade, you’ll now have 4 repositories in your swanky new Siebel 8 database:

1. Prior Customer Repository – your Siebel 7 repository
2. Prior 7.x Siebel Repository – the vanilla Siebel 7 repository
3. New Siebel Repository – the vanilla Siebel 8 repository
4. New Customer Repository – this is going to be your new Siebel 8 configuration, once the process completes, but it basically a vanilla Siebel 8 repository at this point

So, to summarise what to do next:

1. Start Siebel Tools and connect to the upgraded database
2. Select Tools > Upgrade > Upgrade Application
3. Select your repositories in the dialog that’s displayed:
4. Prior Standard Repository = Prior v7.x Siebel Repository
5. Prior Customized Repository = Prior Customer Repositry
6. New Standard Repository = New Siebel Repository
7. New Customized Repository = New Customer Repository
8. Click Advanced.
9. This is optional – select the ‘ICL’ option, select ‘Left’ label position and ’7.8′ as the original version
10. Click ‘Merge’
11. Confirm all checklist items and check each one
12. Click ‘Continue’ to complete the merge process

The process will generally take a LONG time: Siebel is comparing objects in 3 of the repositories and attempting to come to the best conclusion for each in the 4th, final repository. This can take up to a day to run.

My good friend Alex at Siebel Essentials@Blogspot posted an article some time back relating to the merge process.

With luck, the merge process will run through and we’ll have the beginnings of a Siebel 8 configuration!

If you’ve had a chance to run the upgrep process that I talked about in the last article, one of two things will have happened:

1. It will have worked first time. Now’s the time to buy a lottery ticket as you’re very, very lucky
2. It will have failed

The upgrep process involves a load of SQL scripts being run against the Siebel 7.8 database to update the schema and migrate data if required. For example, the audit functionality has changed significantly in Siebel 8: the upgrade process will create new tables, update existing tables and move data from one table to another.

This introduces a number of potential issues:

1. If you have a lot of data in tables that are affected, the upgrade could take a long time to run
2. If you have data that breaks a unique constraint when the data is moved, it will cause the upgrade to fail

It’s recommended by Oracle that you use a DBA to help tune your upgrade scripts – this is especially important when moving into the Production deployment stage, where you might need to apply the upgrade over a weekend or even over night.

Data integrity issues will cause the upgrade to fail and it’s up to you to examine the logs and take remedial action. In one upgrade that I ran we were auditing the same link from two different Business Object definitions and the upgrade scripts tried to use the link ROW_ID as a ROW_ID in one of the audit tables. Result – two rows with the same ROW_ID and a failed upgrade.

So, tune your upgrade and keep an eye on the upgrade logs – talk to Oracle via MetaLink if you need to determine why an upgrade has failed as their upgrade SQL scripts haven’t been tested against every combination of schema and data. They are generally very good at helping to fix integrity issues.

Good luck!

Now, I know this is a ‘technology’ blog and I’m usually loath to get into non-technical subjects or discussions, but this is important!

You’ll notice two words in the post title that are really, really important when considering a Siebel upgrade: ‘Plan’ and ‘Project’.

First things first: your Siebel upgrade will not take a week. It won’t take a month. It probably won’t take 3 months! In fact, if you can execute a Siebel upgrade from start to finish in less than 6 months, you’ll be doing pretty well, considering. It is possible – if you’re going from 7.7 to 7.8 or 8.1 to 8.2 or if your Siebel implementation is almost entirely vanilla. Even then, it’s going to be non trivial.

I can’t emphasise this enough – you have to plan and treat the upgrade as a project. If you do it any other way the upgrade will fail, I can almost guarantee it.

So, a few pointers before we get into the technicalities of the upgrade process:

1. Create a plan
2. Consider other elements of the upgrade, such as Actuate to BIP and Analytics to OBI
3. Identify key resources – you’ll want a PM, test manager, testers, a DBA, Siebel and OBI technical resources and all the supporting management bodies that you would have on any other project
4. Build your environments
5. Run the upgrade
6. Scrap what you’ve done and run it again
7. Run it again and again until you could upgrade in your sleep
8. Regression test over at least two test cycles
9. Test, test and test again!
10. Plan how you’re going to go live
11. Be glad you told your boss 6 months and not 4 weeks
12. Create cutover plans
13. Rehearse the cutover
14. Rehearse it again and again
15. Go live
16. Upgrade your development, test and UAT systems
17. Wipe the sweat from your brow and admire your new, slightly bluer, Siebel system

Oracle have produced some guidelines and best practice documentation that I have found to be very, very useful. Check out what they have to say and remember:

A Siebel upgrade is non-trivial! There is no ‘install.exe’ that will magically do it for you.

Phew, rant over! Next time you hear from me I’ll be back in full tech mode and we’ll start to cover the aspects of a Siebel technical upgrade.