3. Installation considerations and planningAfter verifying that your system meets the basic requirements, you
need to plan your installation by considering installation methods,
storage planning, and the creation of users and groups:
Installation choices:
Storage planning:
User and group setup:
User and group requirements Creating users - single-partition Creating users - multiple-partition
3.1. Installation methodsYou can use four methods to install DB2 UDB:
db2setup utility db2_install utility A DB2 response file Linux rpm command
Each
method has its own advantages and disadvantages. The preferred
method often depends on your level of expertise and type of environment,
but in general, if a graphical terminal is available, using db2setup is
recommended. 3.1.1. db2setup installationThe db2setup command starts the DB2 UDB Setup wizard, a
Java-based graphical tool that installs DB2 UDB. It lays down the DB2
UDB filesets, the IBM SDK for Java, and allows you to create DB2 UDB
instances, create new users and groups, configure existing users,
configure communications, create the tools catalog database, and set up
notification. The DB2 UDB Setup wizard also allows you to create a
response file. Using db2setup is the best method for less experienced
users, because most of the configuration is automatically performed
during the installation. Again, you require X Window System software
capable of rendering a graphical user interface, to use db2setup
successfully. 3.1.2. db2_install installationThe db2_install command starts the db2_install script. This script
installs all DB2 UDB packages on your Linux system using the RPM
installation utility. This method is reliable and commonly used by
expert users for installing DB2 UDB on larger, more complex
multiple-partition systems. However, tasks such as setting up users and
groups, creating instances, tools catalog database creation, and
notification setup need to be performed manually after the
installation is completed. A limitation to db2_install is that it only installs user
assistance (like help, messages, and tool interfaces) in English,
whereas db2setup installs support for one or more different languages.
Also, a db2_install installation can take longer (considering the higher
number of manual configuration tasks), it requires a higher level of
knowledge and skill, and it cannot create response
files. 3.1.3. Response file installationA response file can be created using the DB2 UDB Setup wizard or
by editing a sample response file. It allows you to install DB2 UDB
across multiple machines with consistent installation and configuration
settings. A response file installation is fast, because it bypasses the
graphical wizard and does the configuration for you. Another advantage
of using a response file is that it creates a Database Administration
Server (DAS) on each machine, while with db2_install
the DAS must be created manually after installation. The sample response file can be used to install DB2 UDB, configure
users, create instances, set up notification, create the tools catalog,
and configure a large number of DBM parameters. This is the quickest
installation method if you already have all the information you need.
Unlike db2setup, the response file installation is
not interactive, and it takes longer to prepare the response
file. 3.1.4. RPM command installationThe Red Hat Package Manager (RPM) is a Linux software installation
command. The various DB2 UDB installation methods use RPM to lay down
the appropriate files on the system. Using the RPM command to install
DB2 UDB allows you to select specific DB2 UDB files. However, the RPM
installation method will only install the DB2 UDB code. It will not
create instances, user IDs, or response files during DB2 installation.
Please note that this installation method is not officially supported or
recommended. 3.2. Storage planningIn this section these storage considerations are discussed:
3.2.1. Log storageBy default, DB2 UDB sets the log path to the default database path
during database creation. You should store both the primary copy of the logs and the mirror
logs each on a physically separate disk, preferably one that is also on
a different disk controller. Mirror logs are created using the MIRRORLOGPATH
configuration parameter. Log mirroring allows the database to write an
identical second copy of log files to a different path. For example, you
can change the primary log path from the default to /db2log1, and
set the mirror log path to /db2log2
by issuing these commands:
db2 update db cfg for db_name using NEWLOGPATH /db2log1
db2 update db cfg for db_name using MIRRORLOGPATH /db2log2 |
| These changes will only take place after you deactivate and
activate your database, using the db2stop and
db2start commands. |
3.2.2. Temporary table space storageDB2 UDB uses system temporary table spaces for many SQL
operations, such as JOIN and SORT. The temporary table space,
TEMPSPACE1, is one of the three default table spaces (SYSCATSPACE,
TEMPSPACE1, and USERSPACE1) that gets created during database creation.
By default, TEMPSPACE1 gets placed in the database path. For larger
systems, we recommend that your temporary tables paces are located on a
separate file system and disk. In a multiple-partition database environment, the catalog node
should contain all three default table spaces, and the other database
partitions should each contain only TEMPSPACE1 and USERSPACE1. The following example shows how to create a system temporary table
space on multiple nodes in the /db2temp
file system:
connect to db_name;
create temporary tablespace TEMPSPACE01 in IBMTEMPGROUP
managed by SYSTEM
using ('/db2temp/$INSTANCE/db_name/n001tmp/tempspace01') on \
dbpartitionnum (1)
using ('/db2temp/$INSTANCE/db_name/n002tmp/tempspace01') on \
dbpartitionnum (2)
using ('/db2temp/$INSTANCE/db_name/n003tmp/tempspace01') on \
dbpartitionnum (3)
using ('/db2temp/$INSTANCE/db_name/n004tmp/tempspace01') on \
dbpartitionnum (4)
extentsize 32
prefetchsize 128
bufferpool IBMDEFAULTBP
overhead 24.1
transferrate 0.9;
drop tablespace
tempspace1; |
3.3. User and group setupDB2 UDB requires user IDs and groups. This section discusses these
IDs and groups and how to create them. 3.3.1. User and group requirementsDB2 UDB requires a minimum of three users and groups: the instance
owning user, the fenced user, and the Database Administration Server
(DAS) user. You may use the default names provided by the setup
utilities, or specify your own user and group names. For example,
consider the following default user IDs and group names produced by the
DB2 UDB Setup wizard:
Table 6. Default user IDs and group names Required user | User name | Group name | Description |
---|
Instance owner | db2inst1 | db2iadm1 | Administers the
instance | Fenced user | db2fenc1 | db2fadm1 | Responsible for executing fenced user
defined functions, such as JDFs and stored
procedures. | DAS user | dasusr1 | db2asgrp | Administers the DB2 UDB Administration
Server |
3.3.2. Creating users - single-partitionYou must have root authority to create users and groups. There are
three ways in which you can create a DB2 UDB user ID:
DB2 UDB Setup Wizard. The DB2 UDB Setup Wizard creates
all of the required users and groups for you during installation. The
default users and groups that get created are displayed in the previous
table. DB2 UDB Setup also gives you an option to specify your own user
and group names. Response file. Users can also be created during a
response file installation if you specify user and group information in
the response file. For example, consider the following entries in a
response file that create the three required users and groups for DB2
UDB:
* DAS user
DAS_USERNAME = dasusr1
DAS_GROUP_NAME = dasadm1
DAS_HOME_DIRECTORY = /home/dasusr1
DAS_PASSWORD = ******
* Instance-owning user
inst1.NAME = db2inst1
inst1.GROUP_NAME = db2grp1
inst1.HOME_DIRECTORY = /db2home/db2inst1
inst1.PASSWORD = ******
inst1.AUTOSTART = YES
inst1.AUTHENTICATION = SERVER
inst1.SVCENAME = db2c_db2inst1
inst1.PORT_NUMBER = 50001
inst1.FCM_PORT_NUMBER = 60000
inst1.MAX_LOGICAL_NODES = 4
* Fenced user
nst1.FENCED_USERNAME = db2fenc1
inst1.FENCED_GROUP_NAME = db2fgrp1
inst1.FENCED_HOME_DIRECTORY = /db2home/db2fenc1
inst1.FENCED_PASSWORD = ******
|
Manually using command line. To use this method, follow
these steps:
Log on to your machine as root. Create groups for the instance owner, the fenced user
and the DAS user by using these commands:
groupadd db2iadm1
groupadd db2fadm1
groupadd db2asgrp |
Linux will
create the groups using the first available group ID (GID) numbers
available over 500. You can specify GID numbers if you
prefer.Create a user that belongs to each group and specify the
home directory. For example, you can choose to place all home
directories in /db2home by entering
these commands:
useradd -g db2iadm1 -m -d /db2home/db2inst1 db2inst1 -p password1
useradd -g db2fadm1 -m -d /db2home/db2fenc1 db2fenc1 -p password2
useradd -g db2asgrp -m -d /db2home/dasusr1 dasusr1 -p password3 |
3.3.3. Creating users - multiple-partitionIn a multiple-partition database environment, you only need to
create one shared home directory for the instance owner and fenced user
(but remember to create users on each computer). When creating users in
a multiple-partition environment, make sure that the user and group IDs
are the same on each machine. Consider the following setup:
A shared home directory, /db2home, on the
instance-owning machine, which is NFS-mounted on the remaining machines
in the cluster. In this directory are found the home directories for the
instance-owning user and fenced user: db2inst1 and
db2fenc1. A local home directory for the DAS user on each
computer, dasusr1, which is stored in the /home
directory.
The DB2 Administration Server
(DAS) has changed significantly in DB2 UDB Version 8. Therefore, you
should take note of the following DAS user
considerations. 3.3.3.1. DAS user considerations for a multiple-partition environment
A DAS must be running on each physical machine in the
multiple-partition database for the graphical administration tools (for
example, Control Center) to work. You can only have one Version 8 DAS on each machine
(although a V7 and V8 DAS can co-exist on one
machine). Just like an instance, each DAS must be created under a
user ID. It does not matter whether a different user ID is used for each
DAS in the environment, or whether the same user ID is used and that the
user ID's home directory is not shared. If the same user ID is to be used on each machine, then
that user ID's home directory cannot be shared with the other
machines. If a different user ID is used for each DAS, then the
home directories of the user IDs that are used can be
shared. If an existing user is used as the DAS user, this user
must also exist on all the participating computers before
installation. For response file installations: If your response file
specifies to create a new DAS user on each machine in the cluster, and
that user already exists on any of the participating computers, then
that user must have the same primary group as the new DAS
user.
3.3.4. Adding existing users as DB2 usersTo enable existing system users to act as DB2 administrators, you must
make a few modifications to the user accounts: Add your user to the db2grp1 group. The database manager SYSADM_GROUP
configuration parameter controls who has that level of access for all
databases in the that instance. You can determine what group is set
as the SYSADM group by entering:
db2 get dbm cfg | grep SYSADM_GROUP |
By default, DB2 sets this as the db2grp1 group. To add the user
to the SYSADM group, modify the /etc/groups file (as root), adding
the user account ID to the line for the DB2 system admin group. For example:
db2grp1:x:102:jackc,ellenp,frankj |
Update the user's profile by adding the following lines to the .bashrc file
in the home directory
# The following three lines have been added by the DB2 SYSADM.
if [ -f /home/db2inst1/sqllib/db2profile ]; then
. /home/db2inst1/sqllib/db2profile
fi |
If you want to add desktop icons for the user account, run the command:
/opt/IBM/db2/V8.1/bin/db2icons username |
where username is replaced by the user account you wish to enable.After installation, if you wish to grant or revoke access
to databases (or other objects), use the "User and Groups"
section of the Control Center or the GRANT and REVOKE SQL
statements.) For example, by default, the sample database
grants a number of privileges to "PUBLIC".
|
|