- Installing DB2 UDB Servers
- Before You Begin
- Installing DB2 UDB
- Installed Directory Structure
- Considerations in an NIS Environment
- Distributed Installation
- Sample Response Files
- Creating a Response File
- Distributed Installation with a Response File
- Installing DB2 with db2_install
- DB2 UDB Environment Definitions
- DB2 Profile Registry
- Managing the DB2 Profile Registry
- The db2set Command
- Environment Variables
- Hierarchy of the DB2 UDB Environment
- DB2 Administration Server (DAS)
- DAS Process
- DB2 Instances
- Creating the Sample Database
- Using the Command Line Processor (CLP)
- Uninstalling DB2 Products
- Stopping the DAS Instance
- Stopping All DB2 Instances
- Removing the DAS Instance
- Removing DB2 Instances
- Removing DB2 Products
Installing DB2 UDB
To install DB2 UDB on a Solaris operating environment, you can choose from among several options. You must be root to install DB2.
The available installation methods for DB2 on Solaris are:
The DB2 Installer graphical interface (db2setup)— This Java program is supplied with the DB2 UDB product and is the recommended choice. It detects and configures communication protocols to use with the DB2 Administration Server (DAS) service and DB2 instances (these instances will be discussed later). It will also create the necessary userids and groups, and define an instance at installation time. The other methods require you to manually configure your system. It is a Java GUI, and will have the same look and feel on all platforms. In addition, it only installs the DB2 binaries into opt/IBM/db2/V8.1.
A text-based DB2 Installer program (db2_install)— This program is also supplied with the DB2 UDB product. It does not detect or configure communication protocols. It does not create a DB2 instance or the DAS service, either. While db2_install requires more tailoring than db2setup, it allows you to place the binaries into a location other than /opt/IBM/db2/V8.1; however, there will still be links placed there. After using db2_install, you can still use db2setup to “set up” your instance, including creating users/groups and the administration daemon (db2as).
The install command (pkgadd) of the Solaris operating environment— Using the install command requires you to know the complete syntax.
An installation utility available in your environment— For example, if the CDE (Common Desktop Environment) has been installed in your environment, the software installation tool can be used. This is a better choice than using the install command. However, neither communication detection nor configuration is performed. And, the DAS service and DB2 instance are not created.
The installation program of choice (db2setup) detects the active communication protocols on your system and configures them to work with DB2 UDB. It will create the database instance when DB2 UDB is installed, as well as the administration service or daemon, the DAS. The DAS service is used by the DB2 UDB administration tools, including the Control Center and Configuration Assistant, to satisfy requests. The second instance, called DB2, is used to create and manage databases.
The DB2 Installer program is the recommended choice. It is consistent across all UNIX environments. To run the DB2 Installer program, perform the following steps:
Log on to the system as root (the UNIX system administrator).
Mount the CD-ROM file system.
From the directory where the CD-ROM is mounted, type db2setup. The Java graphical interface will start up. If you are doing the installation remotely, remember to export your Display variable appropriately. Figure 2.5 shows an example of the initial screen.
Figure 2.5. Initial db2setup Screen
As illustrated in Figures 2.6 and 2.7, db2setup allows you to view the Installation Prerequisites and the Release Notes for the latest possible information available. It would be valuable for you to review this information before proceeding.
Figure 2.6. Installation Notes
Figure 2.7. Release Notes
Figure 2.8 shows the components you can install from the distribution CD image. We have chosen the ESE, and the following panels provide tailoring options to allow you to override default selections, including components to install, user/group definitions, communications settings, and notification options.
Figure 2.8. Product Installation Selection Screen
After selecting to install the ESE, the Installer program will check your system, followed by your acknowledgment of the license agreement. After you agree to the license (Figure 2.9) , you can choose what kind of install to execute, Typical, Compact, or Custom. In Figure 2.10, we have chosen a typical install, but we will review some of the custom options later in this chapter. You may also choose whether or not you wish to install the Warehouse Center or Satellite Administration function.
Figure 2.9. DB2 License Agreement
Figure 2.10. Choose Installation Type
Figure 2.11 shows the components that are installed with a Typical install.
Figure 2.11. Components Installed with a Typical Installation of DB2 ESE
The next screen, Figure 2.12, gives you the option of saving your installation into a response file, which will allow you to remotely install the same image of DB2 on other machines. In fact, you can create a response file without actually installing DB2 on a machine.
Figure 2.12. Install DB2, Create a Response File, or Both
The db2setup tool can create users and groups for you, as well as define services and create instances. The next panel prompts for the userid that will be used for the DAS. As shown in Figure 2.13, the default is dbasusr1 in group dasadm1 (both of which will be created in this example).
Figure 2.13. Creating the DAS User
Once you have supplied information about the DAS userid (you can also select an existing user), DB2 will ask if you wish to create an instance, and if so, what kind of memory model should that instance use (32- or 64-bit), Figure 2.14 shows the screen options. If you have not already modified your kernel parameters, do not create an instance at this time. You can use db2isetup (similar to db2setup, but only for tailoring instances) after you get DB2 installed to create your instances/users/groups, etc. at a later time. Indicate whether an instance will be partitioned or not, as shown in Figure 2.15. Partitioning considerations will be covered in more depth in Chapter 10.
Figure 2.14. Instance Creation Selection
Figure 2.15. Partitioned Instance or Not?
After deciding to partition (or not) this instance, in Figure 2.16 you define the “instance owning” userid, which becomes the name of this instance.
Figure 2.16. Instance Owner Creation
The next step is to define the userid where “fenced” procedures will be run (this will put them into a separate address space, and will help keep a “bad” stored procedure from crashing DB2). You must supply a userid for fenced procedures when creating an instance (Figure 2.17)
Figure 2.17. Fenced User Creation.
Following the definition of the fenced user, you must decide if this system will contain tables to use for the monitoring functions within DB2. This information is stored by the administration server for scheduling, notification, and completion information, mainly generated by the Task Center (Figure 2.18).
Figure 2.18. Keep DB2 Tools Information in a Local Database?
If you have selected to prepare a local database for use by the DB2 tools, you must tell DB2 the instance, database, and schema you wish to use, as shown in Figure 2.19.
Figure 2.19. Define the Instance, Database, and Schema to Use for the DB2 Tools Information
Along with the administration service, which communicates with the graphical management tools supplied with DB2, you will also need to define contact information, to tell DB2 the correct list of contacts to use for sending messages for system notification, as shown in Figure 2.20.
Figure 2.20. Contact List for System Notification Messages
To prepare DB2 to interact with the tools shipped with Version 8, you need to specify a database for the tools to use (Figures 2.18 and 2.19). A second notification screen (Figure 2.21) defines who to contact for Health Monitor (one of the tools) messages.
Figure 2.21. Health Monitor Contact Information
Finally (at last!), a screen will appear that allows you to verify what is about to be installed or created, the userids and groups that will be used, the services file entries and contact lists you have defined, and the amount of disk space that will be consumed. Check to make sure that what is going to occur is what you intended, by scrolling through the display, then click “Install” to begin the installation (Figure 2.22).
Figure 2.22. Installation Actions Confirmation
Don't forget that if you are creating an instance, you MUST have already modified the kernel configuration and rebooted, or the instance creation portion of the db2setup actions will fail.
If you had chosen to do a Custom install (Figure 2.10), you would have been provided other options. Figure 2.23 shows some of the other installation options based on a Custom install.
Figure 2.23. Custom Install Options
With a Typical install, you do not have the option to modify the communications parameters during setup (you can still tailor them later) and will get default settings. With the Custom installation path, you can define /etc/services file definitions during the setup process, as shown in Figure 2.24.
Figure 2.24. Defining TCP/IP Definitions During a Custom Install
Other options that you can modify are authentication type and Autostart (Figure 2.25) or the Languages you want installed (Figure 2.26).
Figure 2.25. Authentication and Autostart Selection
Figure 2.26. Choosing Languages in a Custom Install
With that, and selecting “Finish” from the confirmation dialogue in Figure 2.22, you will see a progress screen that shows something is happening (Figure 2.27).
Figure 2.27. Installation Progress
Finally, you get a completion dialogue that allows you to review the success of your installation, as shown in Figure 2.28.
Figure 2.28. db2setup Completion Results