Available with Data Reviewer license.
Configuration keywords allow you to control how objects are created within a geodatabase in SQL Server. You can determine how to allocate space to a table or index, in which FileGroup a table or index is created, and other SQL Server-specific storage attributes. They also allow you to specify one of the available storage formats for the geometry of a spatial column.
The configuration keywords are stored in the DBTUNE table. The DBTUNE table, along with all other metadata tables, is created in the database when the Create Enterprise Geodatabase or Enable Enterprise Geodatabase tool is executed.
If a large number of database connections are accessing the same files in the same location on the disk, database performance will be slow because the connections are competing with one another for the same resources. To reduce this competition, you can store database files in different locations on the disk.
For example, DBTUNE can be modified to store the Reviewer workspace tables in separate data files in different locations on the disk. This will lead to reduced disk contention and improved database input/output.
Standard GIS storage recommendations favor keeping index and log files separate from vector and tabular business tables. For performance reasons, it is better to position the business, feature, and spatial index tables separately and position FileGroup data files based on their usage pattern. For a multiversioned, highly active editing geodatabase, database files of the VERSIONS FileGroup may be separated and dispersed across available disks to avoid input/output contention.
Disk configuration
Large production enterprise geodatabase systems should employ a hardware striping solution. Your best disk and data organization strategies involve spreading your data across multiple disks.
With data spread across multiple disks, more spindles actively search for it. This can increase disk read time and decrease disk contention. However, too many disks can slow down a query. There are two main ways of achieving striping: FileGroups and redundant array of independent disks (RAID). You can also combine the two by creating FileGroups within disk arrays. You can employ data segregation strategies; keeping tables from indexes or certain types of tables from other tables will improve performance and alleviate administrative burdens.
The suggested SQL Server optimal configuration is as follows:
- DISK 0—SQL Server/Application software
- DISK 1—master, model, msdb
- DISK 2—tempdb
- DISK 3—Log files
- DISK 4—Feature data tables
- DISK 5—Spatial index data tables
- DISK 6—Attribute data/Business tables
- DISK 7—SQL Server indexes
Reducing disk input/output contention
As a rule, you should create database files as large as possible based on the maximum amount of data you estimate the database will contain to accommodate future growth. By creating large files, you can avoid file fragmentation and gain better database performance. In many cases, you can let data files grow automatically; just be sure to limit autogrowth by specifying a maximum growth size that leaves some available hard disk space. By putting different FileGroups on different disks, you can also help eliminate physical fragmentation of your files as they grow.
To configure data and log files for best performance, follow these best practices:
- To avoid disk contention, do not put data files on the same drive that contains the operating system files.
- Put transaction log files on a drive separate from data files. This gives you the best performance by reducing disk contention between data and transaction log files.
- Put the tempdb database on a separate drive, if possible—preferably on a RAID 10 or RAID 5 system. In environments in which there is intensive use of tempdb databases, you can get better performance by putting the tempdb on a separate drive, which allows SQL Server to perform tempdb operations in parallel with database operations.
- The RAID configuration that is best for your database files depends on several factors, including performance and recoverability needs. RAID 10 is the recommended RAID system for transaction log, data, and index files. Since the transaction log files are generally smaller than the data and index files, you can consider keeping the transaction log files in a RAID 10 system with a smaller array capacity and store the data and index files in a RAID 5 system with a larger array capacity for those who have budget restrictions.
For more information about RAID, see RAID Levels and SQL Server at http://technet.microsoft.com/en-us/library/ms190764(SQL.105).aspx and Microsoft Windows 2000 Server Administrator's Companion (Microsoft Press), Chapter 7, Planning Fault Tolerance and Avoidance, by Charlie Russel and Sharon Crawford, at http://technet.microsoft.com/pt-br/library/bb742464(en-us).aspx.
- Use partitioning on large tables. Partitioning allows you to split a table across multiple FileGroups by using partitions; you can place a subset of a table or index on a designated FileGroup. This capability allows you to separate specific pieces of a table or index onto individual FileGroups and effectively manage file I/O for volatile tables. Partitions allow you to easily manage archival routines and data-loading operations.
The following is a suggested design to reduce disk input/output contention:
| File type | Database activity | Move file to disk with |
|---|---|---|
| Transaction log files | Frequent edits | Relatively low input/output |
| Transaction log files | Few or no edits | Moderate input/output |
| tempdb | Frequent edits | Low input/output but separate from transaction log files |
| master, model, msdb | Few edits | Moderate input/output |
| Data | Frequent edits | Relatively low input/output |