DB2 10.5 for Linux, UNIX, and Windows

DB2® object naming rules

All objects follow the general gaming rules. In addition, some objects have additional restrictions shown in the accompanying tables.

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 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.