Creating and configuring instances for non-partitioned environments
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:
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 db2setup from the IBM DB2 9.7 Enterprise Server Edition software installation kit.
Note
Instance owner user db2inst and fenced user db2fenc will be created during installation. The groups db2iadm1 and db2fadm1 will automatically fill in on the screen.
To create a new instance during the installation with db2setup in 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 db2inst1 created.
Another way to create an instance is to use the db2icrt command. This method is suitable in the case that you install the DB2 software with db2_install (manual installation), or that you do not check the Create a DB2 instance option during installation with db2setup. 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 root user, we will create the user db2inst2 as instance owner and db2fenc2 as fenced user; set passwords identical to the individual usernames:
At this step, set the communication protocol to TCP/IP. The instance communication protocol is set up using the DB2COMM variable. We can set this variable no protocol managers will be started and will lead to communication errors at the client side.
Next, as user root, edit /etc/services and add db2c_db2inst2 50002/tcp entry (highlighted in bold in the listing bellow). Port 50002 will be assigned to db2inst2 instance. Port 50001 corresponds to the db2c_db2inst1 service name and was added at db2inst1 instance creation. Port names prefixed with DB2 are reserved for inter-partition communication, a subject that we're going to discuss later on.
Note
If you choose to use only port numbers for SVCENAME database manager parameter you do not need to edit this file.
As root user, create instance db2inst2, using the previously created users as instance owner and fenced user:
We need to explain a little bit about the options used for creating instance db2inst2:
The –a option indicates the authentication type; the default is SERVER. Using the –a option, the following authentication modes are available: SERVER, CLIENT, and SERVER ENCRYPT. We may change it later by modifying the AUTHENTICATION or the SRVCONN_AUTH instance parameter.
The –u switch is used to set the fenced user.
The –p option 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 the SVCENAME database manager parameter
For MS Windows platforms, we don't have the –a option to
specify the authentication mode. The –p option in Windows has a different meaning; it is used to specify the instance profile. The –u option 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:
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:
To find the associated Windows service with db2win instance, execute the following command:
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.
Updating instances using the db2iuptd command
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.
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
Filter
