DB2 Version 10.1 for Linux, UNIX, and Windows

Limitations of non-root installations

In addition to the differences between root installations and non-root installations, there are several limitations on non-root installations. This topic discusses the limitations to help you decide if you want to use a non-root installation.

Product limitations

Some DB2® database products are not supported in non-root installations:

DB2 Net Search Extender
Locally installed DB2 Information Center
Note: The locally installed DB2 Information Center is not supported in non-root installations because it requires root user authority to start the daemon. However, a non-root-installation DB2 instance can be configured to use a locally installed DB2 Information Center if it is installed on the same computer.

Features and tools limitations

The following features and tools are not available in non-root installations:

The DB2 Administration Server (DAS) and its associated commands: dascrt, dasdrop, daslist, dasmigr, and dasupdt
The ability for the db2governor to increase priority is not supported
In the Work Load Manager (WLM), attempts to set agent priority in a DB2 service class in a non-root DB2 instance are allowed. However, the agent priority will not be respected, and no SQLCODE error is returned.
Automatic starting of non-root DB2 instances at system reboot is not supported

Health monitor limitations

The following health monitor features are not supported in non-root installations:

Running script or task actions on alert occurrences
Sending alert notifications

Partitioned database limitation

Only single-partition databases are supported in non-root installations. You cannot add additional database partitions.

Listing DB2 database products

The output produced by the db2ls command, when run as a non-root user, is different than the output produced when run as a root user. For details, refer to the db2ls command topic.

DB2 copies

Each non-root user can have only one copy of a DB2 database product installed.

DB2 instance limitation

In non-root installations, one DB2 instance is created during installation. Additional instances cannot be created.

DB2 instance actions can be performed only by the instance owner

Root installations and non-root installations can coexist on the same computer in different installation paths. However, a non-root instance can be updated, or dropped (using the db2_deinstall command), only by the non-root user who owns the non-root instance.

A DB2 instance created by a user with root user authority can be updated or dropped only by a user with root user authority.

DB2 instance commands

The following DB2 instance commands are unavailable in non-root installations:

db2icrt: When installing a DB2 database product as a non-root user, a single instance is automatically created and configured. Further instances cannot be created in non-root installations. However, if the automatically created instance needs to be configured, you can use the non-root install configuration command, db2nrcfg.
db2iupdt: The db2iupdt command cannot be used for non-root instances. Instead, use the non-root install configuration command (db2nrupdt) to update the non-root DB2 instance. However, updating the non-root instance is normally not required because it gets updated automatically when updating your DB2 database product.
db2idrop: The instance that gets automatically created during non-root installations cannot be dropped. The DB2 database product must be uninstalled to drop the DB2 instance.
db2iupgrade: Upgrading is not supported for non-root installations. To upgrade a non-root instance, use the db2nrupgrade command.

Upgrading limitation

Root instances cannot be upgraded to a non-root instance.

Manual kernel parameter updates required

Automatic Linux kernel parameter modification is not supported for non-root installations. Kernel parameters in non-root installations must be updated manually as described in the "Modifying Kernel Parameters (Linux)" topic.

Post-installation actions can be performed only by the DB2 instance owner

Root installations and non-root installations can coexist on the same computer. However, only the original non-root user who installed the DB2 database product can perform subsequent actions such as:

Applying fix packs
Adding features
Installing add-on products

Adjusting ulimit values

The ulimit command on UNIX and Linux operating systems sets or reports user resource limits, such as data and stack limits. For root instances, the database server dynamically updates required ulimit settings without changing the permanent settings. However, for non-root instances, the ulimit settings can only be checked during installation. A warning message is displayed if the settings are inadequate. Root user authority is required to change the ulimit settings.

Limitations that can be overcome by running db2rfe

There are further limitations on non-root installations which can be overcome by running the db2rfe command. The following features and abilities are initially unavailable in non-root installations:

Operating system-based authentication
High Availability (HA) feature
The ability to reserve service names in the /etc/services file
The ability to increase user data limits (ulimits). This ability applies only to AIX®. On other operating systems, user data limits must be increased manually.

Run the Enable root features for non-root install command (db2rfe) to enable these features and abilities. Running the db2rfe command is optional, and must be run by a user with root user authority.

Authentication type in non-root installations

Operating system-based authentication is the default authentication type for DB2 database products. Since non-root installations do not support operating system-based authentication, if you choose not to run the db2rfe command after installing your DB2 database product as a non-root user, then you must manually set the authentication type. You can do so by updating the following parameters in the database manager configuration (dbm cfg) file:

clnt_pw_plugin (Client userid-password plug-in configuration parameter)
group_plugin (Group plug-in configuration parameter)
srvcon_pw_plugin (Userid-password plug-in for incoming connections at the server configuration parameter)