Split the monitor and logging databases from site database as part of best practices which will eventually help to resolve excessive growth of site database and improve the performance.

Starting from XenApp/Xendesktop 7.6 we introduced 3 types of databases: 

Site: (also known as Site Configuration) stores the running Site configuration, plus the current session state and connection information.
Configuration Logging: (also known as Logging) stores information about Site configuration changes and administrative activities. This database is used when the Configuring Logging feature is enabled (default = enabled).
Monitoring: stores data used by Director, such as session and connection information.

In previous versions of Citrix Virtual Apps and Desktops, such as XenApp and XenDesktop 7.6, the database required for Citrix Virtual Apps and Desktops has been created as one database during the initial Site configuration (via Studio or by running scripts on the SQL Server). After the installation, the admin could split it into different databases to enhance performance or comply with backup/security guidelines.

With newer releases of Citrix Virtual Apps and Desktops, you can create the databases during the initial Site configuration, as well as via Studio, or by running scripts on the SQL Server. Your database is automatically split into three separate databases.

For environments with large Monitoring databases, an ideal configuration would be to host the Monitoring database on a different server from the Site Configuration and Configuration Logging databases. It records more data, changes occur more frequently, and the data is not considered to be as critical as the other databases. 

Each cumulative update (CU) for the long-term service release (LTSR) contains fixes to the SQL database schema. For example, see CTX230536. To best protect your environment against unexpected issues, make sure that you have a process to regularly upgrade your environment to the latest CU. Also, make sure that appropriate SQL server and database monitoring are in place to catch failure events and issues with high resource utilization and free space.

Instructions

• The data in the previous database is not imported to the new database.
• Logs cannot be aggregated from both databases when retrieving logs.
• The first log entry in the new database indicates that a database change occurred, but it does not identify the previous database.

1. Ensure a supported version of Microsoft SQL Server is installed on the server where you want the database to reside. Set up high availability features as needed.
2. Select Configuration in the Studio navigation pane.
3. Select the database for which you want to specify a new location and then select Change Database in the Actions pane.
4. Specify the new location and the database name.
5. If you want Studio to create the database and you have the appropriate permissions, click OK. When prompted, click OK, and then Studio creates the database automatically. Studio attempts to access the database using your credentials. If that fails, you are prompted for the database user’s credentials. Studio then uploads the database schema to the database. The credentials are retained only for the database creation time frame.
6. If you do not want Studio to create the database, or you do not have sufficient permissions, click Generate script. The generated scripts include instructions for manually creating the database and a mirror database, if needed. Before uploading the schema, ensure that the database is empty and that at least one user has permission to access and change the database.