Configuring a Separate Management History Database

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.

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.