This documentation is archived and is not being maintained.

SQL Server data file location

[Applies to: Microsoft Dynamics CRM 4.0]

Each SQL Server database consists of one or more database files and one or more transaction log files. Microsoft Dynamics CRM creates two databases:

  • OrganizationName_MSCRM. This is the organization database where Microsoft Dynamics CRM data is stored, such as all records and activities. Microsoft Dynamics CRM 4.0 Enterprise supports multiple organizations so that you can have multiple-organization databases.
  • MSCRM_CONFIG. This database contains Microsoft Dynamics CRM metadata such as configuration and location information that is specific to each organization database.

Microsoft Dynamics CRM also relies on the SQL Server system databases to store Microsoft Dynamics CRM configuration information. These databases include the master and msdb databases. The database files that accompany a database contain all its data and properties. Transaction log files contain a record of the write activity in the database, such as when a row is added, changed, or removed. Transaction log files are binary and cannot be used for auditing database activity.

The transaction log is used for recovery, if a failure occurs, and to roll back (undo) transactions (writes) that cannot be finished. You may also periodically back up the transaction log as a way to perform an incremental backup while users are working in the application, with very low effect on available server resources.

To have the best chance of recovery, if there is a disk failure, and the best performance for the application, put the database files and transaction log files on separate sets of physical disks. The location that you specify for a file does not have to be the original location for data files specified during SQL Server Setup. You can select an alternative location for the database and transaction log files any time that you create or change the database. For more information, see the prior note about disk fault tolerance and performance.

If the partition that contains a database file has failed and the database has become unusable, but the partition that contains the transaction log is still available, you can back up the transaction log for that database. This can be the last backup in your back-up set. When you restore, this transaction log backup, made after the failure, will be the last restored backup. If all transaction log backups in the back-up set are restored successfully, you will have restored all the committed (100 percent successful) transactions up to the moment of the failure. This, of course, limits the data loss.

When the database files and transaction log files are on separate sets of disks, performance is optimized. Transaction log files can be write-intensive during periods when lots of data is being added, changed, or removed from the application.

For example, if you have a server wherein the drive C is the system partition (the drive where the Windows and program file folders are located). The Windows pagefile is also located on drive C. Drives D and E are RAID-5 partitions on separate sets of physical disks. Select the partitioning scheme for the database files that will give you the combination of performance and disk fault tolerance that you want. Drive D contains only data files for one or more databases, and drive E contains only log files for one or more databases. If you verify that performance will decrease because one database will have much more hard disk activity than other databases, you should put them all on separate sets of disks. If you estimate that data will significantly grow over time, make sure drive D has 100 gigabytes (GB) available for the database files. Because the log files will be truncated every time that a transaction-log backup is performed, make sure drive E has 10 GB available. Specify the location of the database file to be on drive D and the transaction log file to be on drive E when you create the database.


It is best to dedicate a partition to SQL Server data files. We recommend that you do not put a data file on the same partition as a Windows pagefile because of the degree of fragmentation that will occur.

By default, the directory where all database files and transaction log files are located is \Program Files\Microsoft SQL Server\Mssql.1\Mssql\Data. When you run SQL Server Setup, you can specify a different location as the default location for data files. The data file location is the root directory where Setup creates the folders that contain database and log files, in addition to directories for the System log, back-up, and replication data. Setup creates database and log files for the master, model, tempdb, and msdb databases. If you are selecting different locations for each file in the application, you do not have to change the default setting.


Data files cannot be installed on a file system that uses compression.

Specifying file paths

Because you can install multiple instances of SQL Server on one computer, an instance name is used in addition to the user-specified location for program and data files. For tools and other shared files, instance names are not required.

Default-instance file path for program and data files

For the default instance of SQL Server, the default SQL Server directory name (Mssql.1) is used as the default instance name, with the directory that you specify.

For example, if you specify the SQL Server default instance to be installed on D:\MySqlDir, the file paths are as follows:

D:\MySqlDir\Mssql.1\Mssql\Binn (for program files)

D:\MySqlDir\Mssql.1\Mssql\Data (for data files)


The program and data file locations can be changed, depending on the drive configuration of the computer that is running SQL Server.

© 2011 Microsoft Corporation. All rights reserved.