Idea Details

Identity Manager installer to allow multiple databases

Last activity 06-13-2019 10:02 AM
Sagi Gabay's profile image
05-27-2015 10:34 AM

Currently the IDM installer only sets up a single database for objectstore, task persistence, workflow etc...

It is a post installation step that allows customers to split to mulitple databases. Further, if they did split to multiple databases then upon upgrade it's reversed to a single one and they need to split again.

 

We would like to request an enhancement that will allow to specify the multiple databases during initial install and also will recognize this is the situation upon upgrade and make sure to leave it untouched on upgrades.

 

 

Thank you.


Comments

01-10-2017 10:10 AM

CA Identity Suite 14.0 introduced a tool that allows for automatic distribution of the Identity Manager installation to multiple databases as per this enhancement request.

See release notes in this link:

Release Notes - 14.0 - CA Identity Manager - 14.0 - CA Technologies Documentation 

09-06-2015 04:01 PM

Since is a good practice to separate the database components this enhancement would be very useful to preserve as-is databases configurations.

thanks !

08-14-2015 03:07 PM

Thanks for the comment. The point about upgrade is especially enlightening.

Ehud

08-10-2015 03:56 PM

1. The issue isn't whether or not we need to separate the database components.  The issue is that if we previously separated the database components for some reason, those separations are not preserved by the IDM installation wizard during the SP upgrade process.  The most recent example of this in my experience was the upgrade from R12.6 SP4 to SP5.  After the upgrade, I had to manually modify the parameters for JNDI connections back to their previous values, because the upgrade wizard reset them to their default values (the single database for everything).

 

2.  I would like to have the option of changing/specifying different databases for these components:

  • Auditing
  • Task Persistence
  • Snapshots (Reporting)
  • Archive (Task Persistence archive)

 

Thanks!

08-07-2015 11:03 AM

This one is indeed receiving a lot of interest. There is however a trade-off here. More flexibility on deploying each component on a separate DB, also means more permutations and more points of failure. In general, the comments and lessons we have received and learned over the years is that the addition flexibility must be handled in a very carful consideration of supportability and sustainability.

 

So here are few questions for the team.

 

1. Can you share more insight into the main reason why a separation of the multiple DB components is needed?

2. if done, what are the most comment DB components that should be separated out (and please don't say all)?

 

Ehud

06-15-2015 01:17 AM

Totally Agree

06-12-2015 09:30 AM

totally agree

06-11-2015 03:27 PM

My like button needs a like button, I like this so much.

06-02-2015 03:34 PM

I second the motion.