Cognos Upgrade - Content Store Questions

[adam_mc]

This is for my confirmation so I don't do anything stupid or make a mistake along the way.
Any notes, concerns, and/or confirmations would be appreciated.

I am planning to upgrade from CA 11.0.13 to CA 11.1.7 on our LAB environment.
The content store for this is an Oracle Database as schema cogcm_l.
However, the content store for our DEV environment is on the same database, but schema cogcm_d.

When I upgrade the LAB environment, it will only upgrade the content store tables in the cogcm_l schema, correct?
Therefore, it is my plan to only take a backup of the cogcm_l schema (in case I need to revert) - I already have an image of the servers pre-upgrade.
Should I backup any other schemas?

I can't do a backup and restore of the entire database, as I wouldn't want to restore the DEV environment content store as that is continually in use.
I am not an oracle expert, so any Oracle specific information would also be helpful.

Thanks in advance,
Adam.

[dougp]

It should work, but you'll want a backup.

I call my environments Dev, QA, and Production.  Defined as follows:
Dev -- One or more environments dedicated to testing upgrades, fix packs, scripting, configuration, tuning, customization, etc.  Only Analytics Administrators can use.
QA -- For testing changes to models and databases, familiarizing data subject experts/data stewards/BI leaders with new Cognos versions and features.  Can be used by everyone, but only those concerned with new features are invited to use.  Data is usually not current, so this is not intended for production use.
Production -- Used by all users for everyday work.

Is your lab for users to "kick the tires", like my QA environment?

So how did your dev upgrade go?

At a minimum, you should be able to restore the entire database to a staging area, then migrate only the appropriate schema into the real database.
Talk to your DBA.  I can't imagine your DBA would have created that architecture without the flexibility to perform restores separately.

[adam_mc]

We have LAB, DEV, QA, and Prod.

DEV, QA, and Prod are our SDLC environments whilst LAB is used purely by Administrators to test upgrades, explore new features, and generally play around.
Based on your description, my LAB environment would seem more comparable to your Dev environment.
DEV is used primarily by BI developers to create new reports before deploying to QA for UAT Testing and then final deployment to Prod.

This would be for our first install of CA 11.1.7 to test the Cognos upgrade process and also that everything still functions with it including SSO, SSL, corporate scheduler, etc...
Once that piece is set, it then will become our CA 11.1.7 sandbox for testing and exploring new Cognos functionality.
Then, at some point when we are comfortable, we would then upgrade our SDLC environments to the new Cognos release/version.

Thanks,
Adam.

[dougp]

Definitely work with your DBA regarding a proper backup/restore process before trying the upgrade.  (mainly to roll back and refine your install/configure process to minimize production downtime when you get there)


I think you'll be pleased.

I use SSO and SSL on Windows/IIS/SQL Server.
I don't know what "corporate scheduler" is.

My experience with upgrading from 11.0.13 to 11.1.7:

• Installs cleanly over-the-top.  SSL and SSO are unaffected.
• The UI is cleaner (more efficient, looks better) but takes some getting used to.
• Many new features including dramatic improvements in the data set editor and dashboarding.
• Many bugs fixed.
• Cognos Mashup Service (CMS) hides the WSDL (the doc that tells your app how to to communicate with Cognos, including how to authenticate) behind authentication.  This was a deal-breaker for me.

[adam_mc]

What, if any, updates did you need to do for IIS when going from 11.0.13 to 11.1.7?

If updates were done  to IIS, when did you do them in the process?

There used to be a script that IBM provided that could be edited - Is that still the case and still the way to go?

Thanks in advance,
Adam.

[dougp]

I'm sure there is still a script that performs the entire SSO config for IIS.  I didn't need it.