What is the DBTUNE table?

At its most basic level, the DBTUNE table is a lookup table; when you create data in, or add data to, a geodatabase, ArcSDE looks in the DBTUNE table for the configuration keyword you specify. ArcSDE takes the parameters and configuration strings associated with the keyword and appends them to the CREATE TABLE or CREATE INDEX statements the client application sends to the database. This determines how that table or index gets stored in the database.

For example:

A user named pablo creates a new mines feature class using the New Feature Class wizard in ArcCatalog. Pablo specifies a name for the feature class (mines), field names, types, and lengths. He also specifies the DEFAULTS configuration keyword when creating the feature class and specifies, all the other characteristics of the feature class using the wizard. Because pablo's geodatabase is stored in Oracle, the wizard causes CREATE TABLE and CREATE INDEX statements to be sent to Oracle. ArcSDE searches the DBTUNE table for all records with DEFAULTS as the keyword. It adds the config_string values for each parameter associated with the DEFAULTS keyword to the CREATE TABLE and CREATE INDEX commands sent by the wizard to the database. For the B_STORAGE parameter (which specifies the storage for the business table of the feature class) under DEFAULTS, the statement might be as follows:

CREATE TABLE pablo.mines (OBJECTID NUMBER(38), NAME NVARCHAR2(40), STATUS NUMBER(4)...)
IN TABLESPACE gisdata
WHERE PCTFREE = 0 and INITRANS = 4

Caution:

ESRI does not recommend you use SQL from a SQL editor to directly alter the contents of the DBTUNE table. Doing so would bypass certain protections written into the sdedbtune utility, possibly leading to reduced performance.

The DBTUNE table is created during the postinstallation setup and populated with default keywords, parameter names, and configuration string values or any customized values you made in the dbtune file prior to running the postinstallation tasks. The table contains the following columns:

• keyword—The configuration keyword
• parameter_name—The configuration parameter
• config_string—The value assigned to the configuration parameter

The DBTUNE table in DB2

Some things for which the DBTUNE table is used in a DB2 for Linux, UNIX, or Windows database include the following:

• Loading tables and indexes into specific table spaces
• Setting the default binary large object (BLOB) and CLOB sizes on column creation
• Running statistics on a business table after a layer is loaded into the database
  Tip:

  Set the B_RUNSTATS parameter to YES to automatically perform a full runstats on the business table at the end of a data load after all the records are inserted and the layer is being readied to put into normal_io mode. The last part of switching to normal_io mode is checking B_RUNSTATS. If B_RUNSTATS is equal to YES (the default), a full runstats will be performed on the table. If it is set to anything else, a runstats will not happen. The vast majority of users will want to have the full runstats done on the table. For those who want to do something special with it for some reason, such as only do indexes, they can set B_RUNSTATS to NO and perform a manual RUNSTATS command with any options they choose.

• Controlling how many cursors per user can be allocated to the cache
  Tip:

  On heavily loaded systems, you'll want to be able to control the maximum cursor value or disable the cache entirely. For this, the DBTUNE parameter MAX_CACHED_CURSORS was added as a DEFAULTS keyword. The current default value is 80. To disable caching, set it to 0.

• Specifying how full-text indexes and XML documents are stored

The DBTUNE table for DB2 for z/OS is used for the following:

• Loading tables and indexes into specific database subsystems
• Setting the default BLOB and CLOB sizes on column creation
• Controlling how many cursors per user can be allocated to the cache