By Theresa Miller

As a Citrix administrator, it probable that you are not a DBA. Not to say that you couldn’t be, but let’s assume that you are not. That being said, as a Citrix administrator it is still becomes your responsibility to have some level of understanding of the databases used for XenDesktop 7.x. For example, how many databases there are, what each database is used for, options for redundancy, what happens if the database is failed, and best practices for their overall care and maintenance. Understanding these aspects of a database will better help ensure the uptime and availability of your organizations Citrix environment. That being said, let’s dive in!

First, there are 3 primary databases required for XenDesktop 7.x. They are the Site Database, Monitoring Database and Configuration Logging Database. Each one has its purpose and if not redundant or fails will cause some level of impact.

Site Database

This database is required and brokers user sessions to the Citrix environment.  This database doesn’t hold much persistent information, because it relies on a log of all the connections. This information is maintained in the database for 48 hours. The database will grow as the site grows in time as the number of users that connect to you farm increases within that 48 hour period of time.

The following chart from Citrix (CTX139508) shows how to estimate the growth of this database.


As for impact, if this database is failed existing users will be unaffected, but new users will not be able to create new connections until it is back online.

Monitoring Database

This database holds historical information about the site and the data is used by Citrix Director to be displayed. Depending on your licensing model the database will maintain 7-90 days of information retention by default.  If your organization has Platinum licensing then the retention can be adjusted to any timeframe suitable for your organization.  With a retention period in place the data that falls outside of the retention period becomes removed during overnight processing. This database grows based on the number of users and connections they have made during a certain period of time.

The following chart from Citrix (CTX139508) provides sample estimate of growth for this database.


If this database were to incur an outage, your Citrix team and anyone else using this information from within Director would not be able to pull the historical connection data until it’s back online.

Configuration Logging Database

This database maintains all the administrative changes made within the farm. Changes to applications, session resets, etc. The size of this database is a challenge to predict, because if changes are not required then there isn’t any growth. Data is not automatically purged and is only removed if done so by an administrator.

If this database is fails the impact will depend on the site configuration. If it was setup to allow changes when the database is not available then they can be made, but will not be tracked. If configured to prevent changes when the database is failed, then changes to the farm will not be able to be made.


Best Practices for Setup, Care and Maintenance

So what else should your team be thinking about related to your Citrix farm and database best practices?  Well first, it is important to understand that you can use database mirroring or clustering for your design.  These types of redundancy will help prevent failures, and the types of outages addressed in this article.  Also, if you choose to use database redundancy, make sure you take the time to test your database failover. That way your team will be completely ready for that unexpected failure, and it validates the overall configuration.  Secondly, create a regular schedule for backing up your databases. While clustering or mirroring provide redundancy backups will allow recovery for almost any other situation. Finally, check out this article for additional information about Citrix database considerations.


Databases are a very important part of your Citrix farm, so work with your DBA’s to put together a design that is suitable for your organizational needs.