Product Documentation

Data Store Database Reference

Oct 09, 2015

See the database vendor documentation before installing, configuring, and using the database software. CTX114501 contains information about supported database versions.

If you use a Microsoft SQL Server 2008 Express database for the farm data store, XenApp configuration automatically installs it.

  • Citrix does not support case-sensitive databases.
  • To avoid corruption, do not directly edit data in the data store database with utilities or tools other than those provided by Citrix.

Maintaining, Backing up, and Restoring a XenApp Data Store

Most database maintenance requires running the dsmaint and dscheck commands on XenApp farm servers. The XenApp Commands Reference documentation contains syntax and use details.

Use dsmaint to:
  • Upgrade the XenApp data store
  • Move the data in the data store to a different database server
  • Change the name of the DSN file

If the data store fails, each farm server can run from the data in its Local Host Cache indefinitely, provided it can contact the license server. However, you cannot make any modifications to the farm or use the Delivery Services Console.

Create a backup copy of the data store (dsmaint backup). Without a backup, you must manually recreate all of the farm policies, settings, accounts, and other persistent data in the data store.

To restore a backup database or to migrate to a new server, use the dsmaint migrate command. Without a backup, prepare a new data store the way you did before configuring XenApp and run the Server Configuration Tool from any farm server. After running the Server Configuration Tool, manually reenter the lost settings. If you use the same name as the previous data store, you do not need to reconfigure the farm servers.

Microsoft SQL Server Database

The server hosting the Microsoft SQL Server database should meet the following minimum requirements:
  • Approximately 100MB of disk space for every 250 servers and 50 published applications in the XenApp farm. Provide more disk space for greater numbers of published applications.
  • Set the "temp" database to automatically grow on a partition with at least 1GB of free disk space. Citrix recommends 4GB if the farm is large and includes multiple print drivers.

The default database installation settings and database sizes usually suffice for XenApp data store needs.

Microsoft SQL Server supports Windows and Microsoft SQL Server authentication. For high-security environments, Citrix recommends using Windows authentication only.

The user account for installing, upgrading, or applying hotfixes to the data store must have database owner (db_owner) rights to the database. When you finish installing the database with database owner rights, set the user permissions to read/write only to increase the security of the database. Change the rights back to database owner before installing service packs or feature releases; installations can fail if the user account used to authenticate to the data store during Setup does not have database owner rights.

When using Microsoft SQL Server in a replicated environment, use the same user account for the data store on each Microsoft SQL Server.

Each farm requires a dedicated database. However, multiple databases can be running on a single server running Microsoft SQL Server. Do not configure the farm to use a database that is shared with any other client/server applications.

Back up the database regularly and follow Microsoft recommendations for configuring database and transaction logs for recovery (for example, setting the Truncate log on Checkpoint option to control log space).

Using Sockets to Connect to a Microsoft SQL Server Database

Two protocols used to connect to a database are TCP/IP sockets and named pipes. Named pipes is an authenticated communication protocol, so any time you attempt to open a connection to the SQL Server database using this protocol, the Windows authentication process occurs. TCP/IP sockets do not rely on Windows authentication to establish a connection, but do provide user/password authentication to the database after the connection is established. Windows authentication reduces the possibility of an error occurring when the server hosting SQL Server and the XenApp server do not have the correct domain or Active Directory trust relationship. Therefore, Citrix recommends using TCP/IP sockets.

If you use named pipes, manually enable the named pipes option on the database server using the Surface Area Configuration tool packaged with SQL Server.

Creating a Microsoft SQL Server Data Source Connection

  1. On the Create a New Data Source to SQL Server screen, enter the data source description and select the SQL Server to which to connect.
  2. Select Windows NT Authentication or SQL Server Authentication.
  3. Click Client Configuration.
  4. Select TCP/IP from the available network libraries.
  5. After installing XenApp, modify the Data Source Name (DSN) created during configuration and change its client configuration to use TCP/IP.

    To modify a DSN, use the Windows ODBC Data Source Administrator utility to open the File DSN, which is located by default in the %ProgramFiles(x86)%\Citrix\Independent Management Architecture folder, and select TCP/IP as the connection protocol for the client configuration.

Using Failover with Microsoft SQL Server

For fault tolerance with Microsoft SQL Server, use Microsoft clustering, which provides failover and failback for clustered systems. Failover of the SQL Server database in a clustered environment is transparent to XenApp.

The database files for an instance of Microsoft SQL Server are placed in a single cluster group owned by the node on which the instance is installed. If a node running an instance of Microsoft SQL Server fails, the cluster group containing the data files for that instance is switched to another node. The new node already has the executable files and registry information for that instance of Microsoft SQL Server on its local disk drive, so it can start up an instance of Microsoft SQL Server and start accepting connection requests for that instance.

Microsoft Cluster Services clustering does not support load balancing among clustered servers because it functions in active/passive mode only.

Using Distributed Databases with Microsoft SQL Server

XenApp supports distributed (replicated) databases. Replicated databases are useful when too many read requests to the data store create a processing bottleneck. Microsoft SQL Server uses replication to create the distributed database environment.

XenApp requires data coherency across multiple databases. Therefore, a two-phase commit algorithm is required for storing data in the database. When configuring Microsoft SQL Server for a two-phase commit, use the Immediate Updating Subscriber model.

When configuring Microsoft SQL Server, you may need to increase the value of the Max Text Replication Size property to improve replication performance.

Caution: To avoid corruption, do not use merged replication.
To set up a distributed environment for an existing XenApp farm:
  1. Configure a Publisher (the Microsoft SQL Server currently hosting the data store) and Subscribers (remote sites) using Microsoft SQL Server Enterprise Manager.
  2. Run the dsmaint publishsqlds command on a server in the farm. This executes the necessary SQL statements to create the published articles on the current Microsoft SQL Server (Publisher).
  3. Configure the remote sites (Subscribers) to subscribe to the published articles created in the previous step.

Oracle Database

The server hosting the Oracle database should meet the following minimum requirements:
  • Approximately 100MB of disk space for every 250 servers and 50 published applications in the farm. Provide more disk space for greater numbers of published applications.
  • 20 MB minimum tablespace size.

Oracle supports Windows and Oracle authentication. Oracle for Solaris supports Oracle authentication only; it does not support Windows authentication.

In the Oracle sqlnet.ora file, set SQLNET.AUTHENTICATION_SERVICES= (NONE). The default setting (NTS) will cause connection failures.

Do not install XenApp on a server hosting an Oracle database.

Install the Oracle client on the server where you will be installing XenApp and then restart the server before you install XenApp.

The Oracle user account must be the same for every server in the farm because all XenApp servers share a common schema.

If you are using one database to hold information for multiple farms, each farm represented in the database must have a different user account because the data store information is stored in the Oracle user account.

The account used to connect to the data store database has the following Oracle permissions:
  • Connect
  • Resource
  • Unlimited Tablespace (optional)
Consider the following guidelines when configuring an Oracle server.
  • Use Shared/Multi-Threaded Server mode to reduce the number of processes in farms with more than 100 servers (performance may be affected during periods of high data store load).
  • If you are using Multi-Threaded Server mode, verify that values in the Init.ora file are greater than or equal to the following values. If you are running multiple farms on the same Oracle database, include all XenApp servers in the calculations. Round up fractional values.

    shared_servers = Number of servers / 10

    max_shared_servers = Number of servers / 5

    Where Number of servers is the total number of servers running XenApp.

  • When using an Oracle server in dedicated mode, add one additional process for each server connected directly to the Oracle database. For example, if the Oracle server uses 100 processes before installing XenApp, and the farm has 50 servers, set the processes value to at least 150 in the Init.ora file on the Oracle server.
  • Create online backups using Archivelog mode, which reduces the recovery time of an unresponsive database.
  • If you are using the same Oracle database for multiple server farms, create a unique tablespace with its own user name and password for added security for each farm. Do not use the default system account within Oracle.
  • Maintain a standby database for quick disaster recovery. A standby database maintains a copy of the production database in a permanent state of recovery.

Using Distributed Databases with Oracle

Oracle uses replication to create the distributed database environment. To reduce the load on a single database server, install read/write replicas and distribute the farm servers evenly across the master and replicas.

XenApp requires data coherency across multiple databases. Therefore, a two-phase commit algorithm is required for writes to the database.

Using Oracle as a distributed database solution has the following requirements:
  • All participating databases must be running Oracle.
  • All participating databases must be running in Multi-Threaded Server/Shared mode (rather than Dedicated mode).
  • All Oracle clients (XenApp servers that connect directly to the Oracle database) must be SQL*Net Version 2 or Net8.
  • Install the farm data store database first on the master site, then configure replication at the sites used for database replication snapshots.
  • Replicate all objects contained in the data store user schema (tables, indexes, and stored procedures).

If the performance at the replicated database site is significantly slower, verify that all the indexes for the user’s schema are successfully replicated.

When configuring Oracle for a two-phase commit:
  • Use synchronous snapshots that can be updated with a single master site. XenApp requires write access to snapshot.
  • Use the Oracle Fast Refresh feature where possible (this requires snapshot logs).
  • When setting up the replication environment, do not configure conflict resolution.
  • Set the replication link interval to be as frequent as the network environment allows. With Oracle replication, if no changes are made, data is not sent over the link.
  • When Oracle is configured in Multi-Threaded Server mode and remote data transfers are initiated from the remote site, they can block local data transfers (because all connections share a set of worker threads). To remedy this, increase the value of the Max_Mts_Servers parameter in the Init.ora file.