I often get the question how to estimate the Orchestrator database size. It is not as the other System Center databases where we can simple look at number of agents or objects to handle and then we know the size. The Orchestrator database size depends on a number of parameters. For example

• Number of runbooks and how ofter they run. Each time a runbook runs, it writes data to the database. Orchestrator also stores all configuration information for runbooks in the database. A large number of runbooks uses more space, even if they are not running.
• Amount of data runbooks publish. Recommended for production is to use default logging, no extra logging of specific data. The database size will depend on the amount of data each activity publish
• Log Purge settings. By design, only runbook historical data is groomed from the database. If you create a run-book and later delete the runbook, it remains in the database but marked as deleted.Performing all testing and authoring in a test Orchestrator environment will save you space in the production Orchestrator database.  The log purge job purges job from the Policyinstances, Objectsinstances, and Objectsinstancedata tables in the Orchestrator database. Data from these tables is shown in the Historical Data pane in the Runbook Designer console. The Log and Log History views show selected data from the Policyinstances table. When you click on a log entry, data for the objects in that policy instance are shown from the Objectsinstances table. When selecting an object, data for that object is read from the Objectsinstancedata table.

A new Orchestrator installation have a database around 3Mb and after we add the System Center 2012 integration packs the size is almost 4 Mb.

Compared with the other System Center 2012 components the Orchestrator database is a quite small database. But it will start grow as soon as you build and run runbooks. On Technet you can find information about how to estimate the database size. But to make it a bit easier I have created a Excel that you can fill in information, and it will show you the database size.

1. Fill in runbook names in column A. Copy/pate more rows if needed
2. Fill in number of activities in each runbook in column B
3. Configure logging level in column C. For production you should configure your runbooks to use default logging configuration
4. Column D show you bytes added to the database each time the runbook runs. Number of bytes depends on logging level
5. Column E show you Mb added to the database if the runbook runs 500 times. To store info for 500 instances is the default log purge setting
6. Fill in number of times the runbook runs per day, in column F
7. Column G show you Mb added to the database per day
8. Column H show you Mb added to the database for 30 days without any log purge
9. Column I show you number of times the runbook will run during 30 days
10. Column J show you number of days that 500 invocations takes, for example if the runbook runs 100 times every day column J will show you 5. With default log purge settings you will store data for 5 days for that runbook.
11. Cell E15 and H15 show the database size. Column E show it with default log purge settings and column H show it without any purge for 30 days

You can download the Excel file here.

If you want to see which activity is writing the most object instance data in your database you can run this SQL query

SELECT COUNT(OBJECTS.Name) AS Instances,

POLICIES.Name AS Runbook, Objects.Name FROM OBJECTINSTANCEDATA

INNER JOIN OBJECTINSTANCES ON

OBJECTINSTANCEDATA.ObjectInstanceID = OBJECTINSTANCES.UniqueID

INNER JOIN OBJECTS ON OBJECTINSTANCES.ObjectID = OBJECTS.UniqueID

INNER JOIN POLICIES ON OBJECTS.ParentID = POLICIES.UniqueID

GROUP BY Policies.Name, Objects.Name

ORDER BY Instances DESC

Note that the Excel sheet is provided “AS-IS” with no warranties. These figures are not exact, see them as a rough estimates.