User databases on independent auxiliary storage pools
The user can create additional i5/OS® relational databases by configuring independent auxiliary storage pools (independent ASPs) on the system. Each independent auxiliary storage pool group is a relational database.
In this topic collection, independent auxiliary storage pool groups are called user databases. They consist of all the database objects that exist on the independent auxiliary storage pool group disks. Additionally, all database objects in the system database of the i5/OS operating system to which the independent auxiliary storage pool is varied on are logically included in a user database. However, from a commitment control perspective, the system database is treated differently.
There are a number of rules associated with the creation and use of user databases, besides those imposed by the commitment control considerations just mentioned. One example is that you cannot use an Advanced Program-to-Program Communication (APPC) protected distributed unit of work (DUW) conversation to connect to a database from an application requester (AR) which has been set to a user database (an auxiliary storage pool [ASP] group) for the current thread. Another example is that the name of any schema created in a user database must not already exist in that user database or in the associated system database. For more information about such restrictions, see the SQL reference topic.
There are certain DRDA-related objects that cannot be contained in user databases. DDM user exit programs must reside in libraries in the system database, as must any Application Requester Driver programs.
The process of varying on a user database causes the relational database (RDB) directory to be unavailable for a period of time, which can cause attempts by a DRDA® application requester or application server (AS) to use the directory to be delayed or to timeout. The exposure to having directory operations timeout is much greater if multiple databases are varied on at the same time. The first time a user database is varied on, an attempt is made by the system to add a directory entry for that database. If the directory is unavailable due to a concurrent vary on operation, the addition fails and the entry must be manually added.
Other considerations in the use of user databases concern configuration of entries in the RDB directory. One of the rules for naming user databases is that user RDB names cannot match the system name specified in the network attributes (as displayed by the Display Network Attributes (DSPNETA) command).
Local user database entries in the RDB directory are added automatically the first time that the associated databases are varied on. They are created using the *IP protocol type and with the remote location designated as LOOPBACK. LOOPBACK indicates that the database is on the same system as the directory. It is highly suggested that user databases that are intended to be switched among systems be configured to have a dedicated IP address associated with them. If the switchable database does not have a dedicated IP address, then whenever it is switched, manually update its directory entry on all the systems that reference that database.
Parent topic:
Initial setup
Related concepts
Managing application CRG takeover IP addresses
Troubleshooting transactions and commitment control
Using the relational database directory
Related reference
Display Network Attributes (DSPNETA) command
SQL reference