Desktop Help 10.0 - Types of configuration keywords

Some configuration keywords are present by default in all database management system (DBMS) implementations of ArcSDE. Others are present by default for only specific DBMS implementations. Still others can be created or customized by the ArcSDE administrator.

Keywords present by default in all DBMS implementations

The configuration keywords that are present by default in all DBMS implementations are described here.

DATA_DICTIONARY

The DATA_DICTIONARY configuration keyword in the DBTUNE table contains the parameters that define the storage of ArcSDE geodatabase system tables. That means these parameters are read when the geodatabase is created. Therefore, if you want to modify the storage of these tables, you must alter the dbtune.sde file prior to performing the postinstallation setup, then specify this file when the geodatabase is created.

Four of the ArcSDE system tables—VERSION, STATES, STATE_LINEAGES, and MVTABLES_MODIFIED—participate in the ArcSDE versioning model and record events resulting from changes made to multiversioned tables. If your site plans to make extensive use of a multiversioned database, these four system tables and their associated indexes will be quite active. In this case, modifying the DATA_DICTIONARY parameters associated with these objects to separate them into their own table spaces allows you to position their data files with data files that experience low input/output (I/O) activity and thus minimize disk I/O contention.

The following table contains descriptions of the DATA_DICTIONARY tables, common to all DBMS implementations, which have the potential to be quite active. An additional table that has the potential to be highly active if you use metadata searches is also described. Knowing what the tables do will help you determine how to store them and their associated indexes.

Table	Description
STATES	Stores change numbers (state IDs) during versioned editing, similar to Oracle SCNs; contains one row per state ID; active in a versioned editing environment and may contain thousands to tens of thousands of rows
STATE_LINEAGES	Identifies ordered sequences of state IDs describing chronology of versioned editing; highly active during versioned editing and may contain millions of rows
VERSIONS	Stores named references to logical groups of edits (versions); not active but may contain hundreds to thousands of rows
MV_TABLES_MODIFIED	Identifies which tables are edited at each state ID; active during versioned editing and may contain tens of thousands to hundreds of thousands of rows
SDE_XML_INDEX_TAGS	Defines properties of XPath indexes for metadata searches; active during content searches by tag and when rebuilding full-text indexes and may contain thousands to tens of thousands of rows, possibly more for large metadata portals

DATA_DICTIONARY system tables

Individual DBMS types may contain additional parameters for other tables or indexes. See the following topics to find DATA_DICTIONARY information specific to your DBMS:

DB2 DATA_DICTIONARY keyword Informix DATA_DICTIONARY keyword Oracle DATA_DICTIONARY keyword PostgreSQL DATA_DICTIONARY keyword SQL Server DATA_DICTIONARY keyword

DEFAULTS

As the name indicates, the settings under the DEFAULTS configuration keyword are used by default when you create tables, feature classes, raster datasets, and indexes. If you do not specify a different keyword when data is created in the geodatabase, or if you specify a keyword that is missing some necessary parameters, values from the DEFAULTS keyword are used. The DBTUNE table has a fully populated DEFAULTS configuration keyword upon geodatabase creation.

When you alter the DEFAULTS keyword parameter group, you should populate it with values that represent the most common storage configuration of your data. Doing so relieves you of the need to define all the parameters for each of the keywords you define. For example, if you create a configuration keyword to create tables in a storage space segregated from the rest of the data, you only need to add the parameters that specify the tables' storage location. The rest of the parameters, such as the geometry storage type, can be picked up from the DEFAULTS keyword parameter group.

Populating the DEFAULTS keyword with the most commonly used values for your particular site also makes it easier for the users who create data; if the DEFAULTS keyword contains the settings they need for 95 percent of the data, they only have to worry about selecting a different keyword for the remaining 5 percent.

The DEFAULTS configuration keyword can be selected whenever you create a table, index, feature class, or raster dataset. If you do not supply a keyword when you create or load data, the DEFAULTS keyword parameter group is used automatically.

The configuration parameters initially present in the DEFAULTS keyword parameter group vary by DBMS. See the following topics for the values present in the DEFAULTS parameter group for each DBMS if you do not customize it.

Note:

The keyword and its parameters are represented how they would appear in the dbtune file, not how they look in the DBTUNE table. (For instance, there would be no double pound sign in front of the configuration keyword in the DBTUNE table.)

DB2 DEFAULTS Informix DEFAULTS Oracle DEFAULTS PostgreSQL DEFAULTS SQL Server DEFAULTS

LOGFILE_DEFAULTS

Log file configuration keywords in the DBTUNE table are used to control the storage of ArcSDE log file tables. The LOGFILE_DEFAULTS keyword is present in all ArcSDE implementations.

See the following topics to view the default parameters for the LOGFILE_DEFAULTS keyword for each database management system:

DB2 LOGFILE_DEFAULTS keyword Informix LOGFILE_DEFAULTS keyword Oracle LOGFILE_DEFAULTS keyword PostgreSQL LOGFILE_DEFAULTS keyword SQL Server LOGFILE_DEFAULTS keyword

However, you can also create log file keywords for particular users so that whenever the user creates a selection set that leads to the creation of ArcSDE log file tables, the settings for that user's log file keyword are used. See the section "Custom log file keywords" in Custom configuration keywords for details.

Composite configuration keywords

The composite keyword is a unique type of keyword used when you want to store tables from the same network, terrain, or topology class in separate spaces. You would do this, for instance, if one table is much more active than the others or if one table in the class is much larger than the others.

Composite configuration keywords are subdivided into elements: the parent element, which does not have a suffix, and the composite keyword elements, which are demarcated by the addition of the ::<element name> suffix to the parent element’s configuration keyword.

You can create composite keywords of your own, but the ones present by default are the NETWORK_DEFAULTS, TOPOLOGY_DEFAULTS, and TERRAIN_DEFAULTS composite keywords.

Network composite keywords

NETWORK_DEFAULTS is the parent keyword for the default network composite keyword. The other elements of the default network composite keyword are NETWORK_DEFAULTS::DESC and NETWORK_DEFAULTS::NETWORK. When you specify the network parent keyword, parameters and values are read from all three configuration keywords.

If you want to create your own set of network configuration keywords, replace DEFAULTS with a different word. For example, for a custom network composite keyword used for highways, you could create the following keywords:

NETWORK_HWY
NETWORK_HWY::DESC
NETWORK_HWY::NETWORK

As with all custom keywords, you specify the storage values you want to use for special, nondefault network classes. In this example, when you specify the NETWORK_HWY parent keyword to create a network dataset, ArcSDE uses the values set for the NETWORK_HWY, NETWORK_HWY::DESC, and NETWORK_HWY::NETWORK keywords to create the tables that make up a network.

Networks are made up of multiple system tables and feature classes. The storage parameters set for each element of the composite keyword are used to store different tables depending on the type of network and whether or not you actually specify a keyword. The following table lists which elements of the network composite keyword affect the storage of which tables in a geometric network or network dataset:

If you...	Network composite keyword element
	NETWORK_<name>	NETWORK_<name>::DESC	NETWORK_<name>::NETWORK
Specify the network parent keyword when creating a network dataset	Defines how the system junction feature class and ND_<itemID>_DIRTYAREAS and ND_<ItemID>DIRTYOBJECTS tables are stored	Defines how the N_<ID>_DESC table is stored	Defines the storage of all other N_<ID>_* tables
Don't specify a network parent keyword when creating a network dataset	The system junction feature class and ND_<itemID>_DIRTYAREAS and ND_<ItemID>DIRTYOBJECTS tables are created using the DEFAULTS keywork. All other network dataset tables are created using the parameters of the NETWORK_DEFAULTS parent keyword.	Not used	Not used
Specify the network parent keyword when creating a geometric network	Defines how the orphan junction feature class and build errors table are stored	Defines how the N_<ID>_DESC table is stored	Defines the storage of all other N_<ID>_* tables
Don't specify a network parent keyword when creating a geometric network	The orphan junction feature class and build errors table are created using the DEFAULTS keywork. All other geometric network tables are created using the parameters of the NETWORK_DEFAULTS parent keyword.	Not used	Not used

For a description of geometric network and network dataset tables, see the topics for your DBMS:

Geometric networks in a geodatabase in DB2 Geometric networks in a geodatabase in Informix Geometric networks in a geodatabase in Oracle Geometric networks in a geodatabase in PostgreSQL Geometric networks in a geodatabase in SQL Server

Network datasets in a geodatabase in DB2 Network datasets in a geodatabase in Informix Network datasets in a geodatabase in Oracle Network datasets in a geodatabase in PostgreSQL Network datasets in a geodatabase in SQL Server

Topology composite keywords

The topology composite keyword controls the storage of topology tables. Your ArcSDE instance must have a valid topology keyword in the DBTUNE table for topology to be built. The topology composite keyword consists of the parent element, TOPOLOGY_DEFAULTS, and TOPOLOGY_DEFAULTS::DIRTYAREAS, which indicates where the DIRTYAREAS topology table will be stored. The DIRTYAREAS table can grow quite large and is very active in versioned geodatabases. Therefore, if your geodatabase uses topology and a lot of versioned editing takes place on the data, you should alter the parameter values of TOPOLOGY_DEFAULTS::DIRTYAREAS to store the DIRTYAREAS table components in a separate storage location; by default, they have the same storage settings as the topology table.

Be aware that datasets that participate in the same topology should use the same geometry storage type; if they do not, you may experience some topology errors due to slight variations in the way the data is stored. These variations are extremely small in most cases but could cause a violation of one or more of your topology rules. See the topic Topology basics for an introduction to topology.

For a description of topology tables, see the topology storage topic for your DBMS:

Topologies in a geodatabase in DB2 Topologies in a geodatabase in Informix Topologies in a geodatabase in Oracle Topologies in a geodatabase in PostgreSQL Topologies in a geodatabase in SQL Server

Terrain composite keywords

The terrain composite keyword controls the storage of the following tables created for terrain datasets:

DTM_<itemID>_COMPOSITETILES
DTM_<itemID>_DIRTYAREA
DTM_<itemID>_INSIDETILES
DTM_<itemID>_MRFC
DTM_<itemID>_PROPS
DTM_<itemID>_EMBED_<N>

ItemID is the value in the UUID field of the GDB_ITEMS table for the particular terrain dataset. N indicates the specific DTM_<itemID>_EMBED table; there can be any number (0...n) of these tables.

The default terrain keywords are TERRAIN_DEFAULTS, which controls the default storage of the first four tables listed above, and TERRAIN_DEFAULTS::EMBEDDED, which controls the storage of the DTM_<itemID>_EMBED_<N> table.

DTM_<itemID>_EMBED_<N> tables store embedded feature classes. For this reason, they could be much larger than the other terrain tables; therefore, you might want to alter the storage parameters of the TERRAIN_DEFAULTS::EMBEDDED keyword to store these tables in a different place or in a different-sized extent, depending on the DBMS you use to store your geodatabase.

License:

Terrains can only be created if you have the 3D Analyst extension installed and active.

For a description of the terrain tables, see the terrain storage topic for your DBMS:

Terrain datasets in a geodatabase in DB2 Terrain datasets in a geodatabase in Informix Terrain datasets in a geodatabase in Oracle Terrain datasets in a geodatabase in PostgreSQL Terrain datasets in a geodatabase in SQL Server

Geometry and raster storage keywords

If you only want to use a different geometry storage type for a small portion of your data, you can use separate configuration keywords to specify this when the data is created or brought into the database. The DBTUNE tables and dbtune files for ArcSDE for Oracle, PostgreSQL, and SQL Server all contain keywords you can use to specify the geometry or raster storage when creating or importing data using the ArcSDE administration commands or in ArcCatalog.

Note:

Datasets that participate in the same topology should be stored in the same geometry storage type. If they are not, you could experience some topology errors due to slight variations in the way the data is stored for different storage types. These variations are extremely small (a matter of millimeters, for instance) but could cause a violation of one of your topology rules. For example, if you have polygon feature class A stored in SDO_GEOMETRY and polygon feature class B stored in ArcSDE compressed binary (Long Raw), and you place them in a topology and specify the topology rule feature class A must not overlap with feature class B, slight differences in the way the features are rendered could cause adjacent features from A and B to cross, thus violating this topology rule.

If you specify a keyword that only has a few parameters, the rest of the parameters are read from the DEFAULTS configuration keyword. Therefore, if you specify SDELOB when you create a feature class in a geodatabase in Oracle, the software uses the values for the GEOMETRY_STORAGE, ATTRIBUTE_BINARY, and RASTER_STORAGE parameters from the SDELOB keyword, then goes to the DEFAULTS keyword for values for all the other parameters, such as B_STORAGE and UNICODE_STRING.

If you want to create a topology, terrain, or network that uses a geometry storage type other than what is stored under the DEFAULTS keyword, you need to create custom keywords that contain the desired geometry storage. For example, if you create a roads feature class in an Oracle database using SDO_GEOMETRY, when you create a network that involves that roads feature class, you want the network to also use SDO_GEOMETRY. For that, you need to create a set of NETWORK composite keywords that specify SDO_GEOMETRY storage. See Composite keywords and geometry storage for more information.

Keywords present in only specific DBMS implementations

For configuration keywords present by default in only one or two databases, see the topic specific to the DBMS in which you are interested.

Default_configuration_keywords_specific_to_DB2 Default_configuration_keywords_specific_to_Oracle Default_configuration_keywords_specific_to_PostgreSQL Default_configuration_keywords_specific_to_SQL_Server

Custom configuration keywords

As mentioned in the description of log file and composite configuration keywords, you can create your own keywords to group together specific parameters and settings you want to use. See Custom configuration keywords for more information.

8/19/2013