Db2 object naming rules

Beyond the general naming rules, some additional rules apply to specific Db2 objects. These rules affect the naming of databases, aliases, instances, and objects within federated and non-federated databases.

Table 1. Database, database alias and instance naming rules
Objects Guidelines
  • Databases
  • Database aliases
  • Instances
  • Database names must be unique within the location in which they are cataloged. On Linux® and UNIX implementations, this location is a directory path, whereas on Windows implementations, it is a logical disk.
  • Database alias names must be unique within the system database directory. When a new database is created, the alias defaults to the database name. As a result, you cannot create a database using a name that exists as a database alias, even if there is no database with that name.
  • Database, database alias, group name and instance name lengths must be less than or equal to 8 bytes.
  • On Windows, no instance can have the same name as a service name.
Note: To avoid potential problems, do not use the special characters @, #, and $ in a database name if you intend to use the database in a communications environment. Also, because these characters are not common to all keyboards, do not use them if you plan to use the database in another language.
Table 2. Database object naming rules
Objects Guidelines
  • Aliases
  • Audit policies
  • Buffer pools
  • Columns
  • Event monitors
  • Indexes
  • Methods
  • Nodegroups
  • Packages
  • Package versions
  • Roles
  • Schemas
  • Stored procedures
  • Tables
  • Table spaces
  • Triggers
  • Trusted contexts
  • UDFs
  • UDTs
  • Views
  • Lengths for identifiers for these objects must be less than or equal to the lengths listed in: SQL and XML limits. Object names can also include:
    • Valid accented characters (such as ö)
    • Multibyte characters, except multibyte spaces (for multibyte environments)
  • Package names and package versions can also include periods (.), hyphens (-), and colons (:).

For more information, see Identifiers.
Table 3. Federated database object naming rules
Objects Guidelines
  • Function mappings
  • Index specifications
  • Nicknames
  • Servers
  • Type mappings
  • User mappings
  • Wrappers
 Lengths for these objects must be less than or equal to the lengths listed in: SQL and XML limits. Names for federated database objects can also include:
  • Valid accented letters (such as ö)
  • Multibyte characters, except multibyte spaces (for multibyte environments)

Delimited identifiers and object names

Keywords can be used. If a keyword is used in a context where it could also be interpreted as an SQL keyword, it must be specified as a delimited identifier.

Using delimited identifiers, it is possible to create an object that violates these naming rules; however, subsequent use of the object could result in errors. For example, if you create a column with a + or - sign included in the name and you subsequently use that column in an index, you will experience problems when you attempt to reorganize the table.

Additional schema names information

  • User-defined types (UDTs) cannot have schema names longer than the lengths listed in: SQL and XML limits.
  • The following schema names are reserved words and must not be used: SYSCAT, SYSFUN, SYSIBM, SYSSTAT, SYSPUBLIC.
  • To avoid potential problems upgrading databases in the future, do not use schema names that begin with SYS. The database manager will not allow you to create triggers, user-defined types or user-defined functions using a schema name beginning with SYS.
  • It is recommended that you not use SESSION as a schema name. Declared temporary tables must be qualified by SESSION. It is therefore possible to have an application declare a temporary table with a name identical to that of a persistent table, in which case the application logic can become overly complicated. Avoid the use of the schema SESSION, except when dealing with declared temporary tables.