A DB2 instance can be defined as a logical container or as a logical context for databases. It can also be described as a layer between DB2 software binaries, a database, and its objects. Also it provides a level of isolation between databases; for example, it is possible to have two or more databases on the same environment, with the same name, but under different instances. It also provides and ensures the communication layer between clients and databases.
For this recipe (and almost all recipes in this book), we will use two servers running Red Hat Enterprise Linux Server x64 release 5.5 (Tikanga), named nodedb21 and nodedb22. The hostnames are optional, but our recommendation is to set up an identical environment to avoid confusion during reading and applying the recipes.
As install location for the IBM DB2 9.7 Enterprise Server Enterprise software product, we will use the directory /opt/ibm/db2/V9.7 on nodedb21. On nodedb22, we will install DB2 Client software to location /opt/ibm/db2/V9.7_clnt. The instance owner will be db2inst1 on nodedb21 and db2clnt1 as client instance owner on nodedb22. Also, on nodedb21, we will create a second instance owner user named db2inst2, to demonstrate how to create an instance manually.
The default method to create an instance is during the IBM DB2 9.7 Enterprise Server Edition software installation. The other possible option is to use the db2icrt command.
In Linux and Unix, every instance is created under a dedicated user, called the instance owner. To create an instance in Linux and UNIX you have to be the root user; on these platforms, we are limited to one instance per user. On Microsoft Windows platforms, you may have more than one instance created under the same user.
Usually, if you set up the software in graphical mode you do not have to create the users manually—you can do this using the wizard. In our recipes, we want to reuse the same groups (db2iadm1 and db2fadm1) for the non-partitioned and the multipartitioned instance and database setup. For the multipartitioned setup we will have the same groups defined on both servers; because we have to deal with security regarding permissions, here, we should create the groups with the same group ID (GID):
Create primary groups with the same GID on both servers:
[root@nodedb21 ~]# groupadd -g 1103 db2iadm1 [root@nodedb21 ~]# groupadd -g 1102 db2fadm1 [root@nodedb21 ~]# [root@nodedb22 ~]# groupadd -g 1103 db2iadm1 [root@nodedb22 ~]# groupadd -g 1102 db2fadm1 [root@nodedb22 ~]#
Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
Run
db2setupfrom the IBM DB2 9.7 Enterprise Server Edition software installation kit.To create a new instance during the installation with
db2setupin graphical mode, navigate through configuration steps 1 to 6 and, at step 7 you will find Create a DB2 instance option checked; this is the default option.and let as it is.Click Next.
At step 8—Partitioning options—you will find Single partition instance option checked ; this is the default option and let as it is. Click Next and finalize installation. If installation was successful, we have a new instance named
db2inst1created.Another way to create an instance is to use the
db2icrtcommand. This method is suitable in the case that you install the DB2 software withdb2_install(manual installation), or that you do not check the Create a DB2 instance option during installation withdb2setup. Other scenarios would be if you drop an instance and want to create a new one, or if you want to create an additional instance.As mentioned previously, in Linux and Unix, every instance has to be created under an instance owner user. As a
rootuser, we will create the userdb2inst2as instance owner anddb2fenc2as fenced user; set passwords identical to the individual usernames:[root@nodedb21 ~]# useradd -g db2iadm1 db2inst2 [root@nodedb21 ~]# useradd -g db2fadm1 db2fenc2 [root@nodedb21 ~]# passwd db2inst2 Changing password for user db2inst2. New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. [root@nodedb21 ~]# passwd db2fenc2 Changing password for user db2fenc2. New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully. [root@nodedb21 ~]#
At this step, set the communication protocol to TCP/IP. The instance communication protocol is set up using the
DB2COMMvariable. We can set this variable no protocol managers will be started and will lead to communication errors at the client side.[db2inst2@nodedb21 ~]$ db2set DB2COMM=TCPIP [db2inst2@nodedb21 ~]$
Next, as user
root, edit/etc/servicesand adddb2c_db2inst2 50002/tcpentry (highlighted in bold in the listing bellow). Port50002will be assigned todb2inst2instance. Port50001corresponds to thedb2c_db2inst1service name and was added atdb2inst1instance creation. Port names prefixed with DB2 are reserved for inter-partition communication, a subject that we're going to discuss later on.db2c_db2inst1 50001/tcp DB2_db2inst1 60000/tcp DB2_db2inst1_1 60001/tcp DB2_db2inst1_2 60002/tcp DB2_db2inst1_END 60003/tcp db2c_db2inst2 50002/tcpAs
rootuser, create instancedb2inst2, using the previously created users as instance owner and fenced user:[root@nodedb21.~]# /opt/ibm/db2/V9.7/instance/db2icrt -a SERVER ENCRYPT -p db2c_db2inst2 -u db2fenc2 db2inst2 DBI1070I Program db2icrt completed successfully. [root@nodedb21 ~]#
We need to explain a little bit about the options used for creating instance
db2inst2:The
–aoption indicates the authentication type; the default isSERVER. Using the–aoption, the following authentication modes are available:SERVER,CLIENT, andSERVER ENCRYPT. We may change it later by modifying theAUTHENTICATIONor the SRVCONN_AUTH instance parameter.The
–uswitch is used to set the fenced user.The
–poption is used to specify the port or its corresponding service name used for client communication, as defined in/etc/services. The port or service name may be changed later by modifying theSVCENAMEdatabase manager parameterFor MS Windows platforms, we don't have the
–aoption to specify the authentication mode. The–poption in Windows has a different meaning; it is used to specify the instance profile. The–uoption is for specifying the account name and password used that will be included in the Windows service definition associated with the instance.
Note
To use the Control Center for managing an instance locally or remotely, you need to have DB2 Administration Server (DAS) up and running, on the server.
To check the status of DAS, execute the following command, as DAS owner user, which is in our case dasusr1:
[dasusr1@nodedb21 ~]$ db2dascfg get dasstatus
ACTIVE
[dasusr1@nodedb21 ~]$
Usually, it is installed and created during IBM DB2 software installation. If there is no DAS created, you should create it using the dascrt command. The steps are similar to those for creating an instance—create a group and a user. It has to be created by specifying the owner.
For example, /opt/ibm/db2/V9.7/instance/dascrt –u dasusr1.
In Linux or Unix, when an instance is created, the db2icrt command builds up under the instance owner home directory, the sqllib directory, as a collection of symbolic links pointing to the IBM DB2 software installation home directory. If you want to see what is executing db2icrt in the background, you need to include the –d option to enable debug mode. This explains what happens behind the scenes for the steps mentioned earlier. Usually, this switch is used for detailed diagnostics, and should be activated at the request of IBM support.
Almost all files and directories from sqllib directory are symbolic links to the corresponding installation path (DB2HOME). A short listing inside sqllib directory looks like this:
[db2inst1@nodedb21]/home/db2inst1/sqllib>symlinks -v . other_fs: /home/db2inst1/sqllib/map -> /opt/ibm/db2/V9.7/map other_fs: /home/db2inst1/sqllib/bin -> /opt/ibm/db2/V9.7/bin other_fs: /home/db2inst1/sqllib/ruby64 -> /opt/ibm/db2/V9.7/dsdriver/ruby64
On MS Windows platforms, the db2icrt command creates a service. The binaries are actually copied and a service associated with the instance is created.
On a generic Windows machine we'll create an instance named db2win. Initially, the associated service has the status set to stopped and the startup type set to manually. If you want the service to start automatically at system boot, you have to change its startup type to automatic.
To create instance db2win, execute the following command under a privileged user:
C:\Windows\system32>db2icrt db2win DB20000I The DB2ICRT command completed successfully.
To find the associated Windows service with db2win instance, execute the following command:
C:\Windows\system32>sc query state= all | findstr "DB2WIN" SERVICE_NAME: DB2WIN DISPLAY_NAME: DB2 - DB2COPY1 - DB2WIN C:\Windows\system32>
The db2isetup graphical tool might be used also for creating instances; this tool is available only on the Linux and Unix platforms.
On Linux and Unix you have the possibility to create a non-root type instance using the installer. You are limited to only one non-root instance per server.
Usually this command is used to update an instance after an upgrade to a higher version, or migrate an instance from a lower product level such as Workgroup Edition to Enterprise Edition. Also it might be used for instance debug using the –d option. Like db2icrt, this command has its own particularities on MS Windows operating systems. To find the available options and related descriptions of this command issue db2iuptd –h. For non-root type instances exists a variant of this command named db2nruptd.