Configuring a Separate Management History Database

Question

I'm rolling out a new Active Roles 7 infrastructure alongside my production ARS 6.9. In all past ARS versions, I've kept the Configuration and Management History within the same database, e.g. ActiveRoles69.

I'd like to consider separating the two databases above.

Can anyone enlighten as as to all the pros and cons of separate databases?

Has anyone configured separate databases in production and, if so, can you provide any positive or negative feedback from that decision?

Thanks for any commentary.
-Steve

Terrance.Crombie · Accepted Answer

I always recommend having separate databases, for several reasons. 
 With Active Roles, the Management History database isn't just a static reporting database. It is actually the execution database for the product. We write to the database as we perform tasks, and then run reports by querying the actual work which was performed. In very busy environments, or environments were the Change History retention period has been increased beyond the default 30 days, this can mean that the performance of the SQL instance hosting the Management History database can actually be a performance bottleneck for the product. Having the databases separated makes it easier to migrate the more resource-intensive Management History database to new hardware or a cluster if necessary. 
 In addition, since the Management History database is read from and written to much more often, it is more likely to suffer from malformation, since software is a mutable medium. This can sometimes mean that the Management History database needs to be archived, a new database created, and the data recovered using the Management History Transfer Wizard or the Active Roles Configuration Center. This is a resource which I created for help with those rare circumstances: 
 
 This process is much easier if the databases are separate.