COGNOiSe.com - The IBM Cognos Community

Planning & Consolidation => COGNOS Planning => Topic started by: JaromirSeps on 01 Sep 2009 04:46:41 AM

Title: Migration Oracle - MS SQL on planning 8.1 or 8.4
Post by: JaromirSeps on 01 Sep 2009 04:46:41 AM
Hello,

we are considering migration of Cognos Planning from Oracle to MS SQL database platform. We are currently running 8.1 and want to get to 8.4. We are not sure about the timing of both changes.

Does anyone have experience with migration on either of those versions?

I found some posts in the IBM knowledgebase relating to migration with the tools available in 7.3 - via Import/Upgrade. And I also found a post for exporting Content Store via "New Export".

Would you recommend to:
1) first migrate 8.1 - 8.4 on oracle and export to MS SQL
2) switch to MS SQL on version 8.1 and migrate to 8.4

I would really welcome any practical experience

Thank you
Jaromir Seps
Title: Re: Migration Oracle - MS SQL on planning 8.1 or 8.4
Post by: SomeClown on 01 Sep 2009 07:17:54 AM
Depends on how difficult it is to work with your Oracle DBAs.  The jump from 8.1 to 8.4 has you set up an additional schema or two (or you should anyway - good idea to separate the main content store from the planning store).  If schema and database changes are not an issue, then I'd recommend upgrade to 8.4 in Oracle, then migrate over to SQL Server.

Upgrade:
You probably won't be able to lift over the macros and admin links in the upgrade, but exports/imports should cover that.  I would not attempt a PAD upgrade, never seen those work, just re-link in the applications and gtp (not upgrading the pad is why you'd export links and macros). Analyst is pretty straightforward.

Migrate:
Once in 8.4, you can export the entire Planning content as a deployment package and then re-import once you move to SQL Server


Migrating first to SQL Server may require that you rebuild from scratch in 8.1 for one or more apps (migration tools improved in 8.3/8.4)

Title: Re: Migration Oracle - MS SQL on planning 8.1 or 8.4
Post by: craig_karr on 02 Sep 2009 04:17:58 AM
I would definitely upgrade first in the Oracle environment and then make a deployment from 8.4 and import it into the MS SQL server environment. This should actually be pretty straightforward. Contrary to the clown I strongly recommend that you upgrade the whole pad in order to get the macros, admin links etc pointing to the correct application. It is easy to make mistakes if you do it manually afterwards.
Title: Re: Migration Oracle - MS SQL on planning 8.1 or 8.4
Post by: craig_karr on 02 Sep 2009 04:41:45 AM
On a second thought - why not do the upgrade and migration in one step? I.e install 8.4 on the MS SQL server platform and then point to the 8.1 Oracle pad from the new environment during the normal upgrade pad wizard.

This requires that you have the oracle client installed of course, but that shouldn't be an issue
Title: Re: Migration Oracle - MS SQL on planning 8.1 or 8.4
Post by: JaromirSeps on 02 Sep 2009 08:21:49 AM
Thanx a lot guys.

However, I am still a little worried about the bult-in Oracle - MSSQL conversion ... is this flawless?

I mean this situation: MS SQL installed, 8.4 (8.1) installed, active pad on MS SQL. Now I try to import application and point it to the old Oracle pad/application.

Does this really work?

Thank you
Jaromir Seps
Title: Re: Migration Oracle - MS SQL on planning 8.1 or 8.4
Post by: craig_karr on 02 Sep 2009 08:49:33 AM
I have made several deployments from Oracle to MS Sql server environment and it has always worked without any problem at all. I have never tried to upgrade directly to MS from Oracle as I suggested in my second post, but I think it should work in theory at  least and the worst that could happen is that you have to drop some databases from your new SQL server environment if it fails (the Oracle source environment is not affected but make backups anyway just in case).

The only exception I can think of is if you have dlist, dlinks etc with ODBC as source and you have vendor specific sql in it. Those will of course not work if you plan to move the source databases for those ODBC connections as well.