COGNOS 10 Planning

[manoj pipariya]

Hello,

We are planning to migrate to cognos 10, it would be a distributed installation.
We are having two database DW_1 & DW_2, Now if I create content store in  DW_1 and Planning Store in DW_2 (both are new schemas) and migrate planning application in COGNOS10 then in which database planning application datstore will be created, DW_1 or DW_2 ??

[SomeClown]

Neither.  Planning applications are separate databases and are stored on the server defined in the datastore connection in the Contributor Administration Console.

[ovo]

Also since the Planning Store and Content Store have a dependency on each other why not just merge them.  I know you can have them seperate and this was done due to perceived risk when the product were integrated, but I see little point.

If anyone has tangeble reasons to seperate them, I would be interested to hear them.

[SomeClown]

I wouldn't trust that a merged configuration for the database has been tested under load. 
Earlier concerns stemmed from responses from support like "drop the planning store and recreate" - problematic if they were merged.  Since support has not improved under IBM, I'm skeptical that responses from support would be any better these days.

[ericlfg]

I would agree that manually merging 2 separate DB resources into one is risky, not to mention likely not supported.  Instead, create one singular DB resource and use the normal deployment processes to repopulate it.

Skepticism regarding IBM Support's abilities these days aside, tangible reasons to keep them separate are simple, ease of restore processes and removal of the need to hack tables.  I've seen both instances where a CS or a PS needs to be restored due to a server outage during a job run.  To avoid losing data associated with the opposite product you would need to manually move tables to staging locations, restore your DB, and then overwrite the restored values with the staged values.  Frankly it takes less time to maintain both resources in a disaster recovery operation.

[ovo]

In all the load testing I have done I have never seen an issue either merged or seperated... in fact the only load I have seen on CM is due to CAM requests and not storage/retrieval of Planning metadata.

To the backup/restore question.  Yes it is simpler, but should you really be backing up and restoring these two databases independently.  The PS depends on the CS, so surely you have to ensure that they are both reset to a consistant point in time.  Moreover on DB2 you do not have the ability to backup and restore schemas independently, only at the database level.

[ericlfg]

Hi ovo,

I would agree that during a load test on the planning side you would not see any difference in performance between having a single CS with the PS tables or a separate CS and PS.

I cannot say that I agree with your second paragraph.  The PS does not really have a dependency on the CS.  In versions prior to 10.1.x, if you only provided the CS database in your configuration then when you start the CAC for the first time, it will create the P_* tables in the CS resource.  When you start the CAC, it uses whatever DB resource you've told it contains the P_* tables and attempts to load the information.  If you're version 10.1.x + then you have to specify a planning store database resource in your config, but it can be the CS DB or a separate PS DB.

Every time you open the CAC, it communicates with the CAC service and determines on which DB it should be looking for the P_ tables.  If you change your configuration after the fact, possibly creating a separate PS when the CS was being used solely, then you'll get prompted to create the P_ tables again.  However, if you switch your configuration back to the original CS with the P_ tables, the environment will pop back up.  The point in time does not need to be consistent between the 2.

Example:

Let's say you have a single CS that also holds the PS and is corrupted by some external issue, not related to planning, on a Friday night.  You only have a backup from 2 days ago or even the night before.  Your planning people have created a large number of new macros, creating and working with admin links, during the day Friday.  At this point, if you restore the CS that also holds the PS, then all the work the planning folks have done during the day are lost.

If the PS was separate, then the CS could be restored with no effect to the planning folks.

I can agree that normally you could be safe using a single CS resource to hold the PS tables.  The example I described would be rare, but since in SQL and Oracle you could restore the CS independently of the PS, it makes sense to keep it separate.

(This is all meant to be friendly and is really for conversation sake, I like talking shop)

Cheers