Plan for DB2 for z/OS

 

+
Search Tips   |   Advanced Search

 

You are here

  1. Planning for DB2 for z/OS (Current task)
  2. Installing DB2 for z/OS
  3. Creating databases and users for DB2 for z/OS
  4. Transferring DB2 for z/OS manually or Transferring between databases manually
  5. Verifying database connections

This section is designed to give the IBM DB2 Universal Database™ for z/OS administrator an overall picture of IBM WebSphere Portal database requirements.

 

Before you begin:

  • You should have reviewed the Configuring databases topic to determine if you are going to transfer WebSphere Portal data to another supported database.

  • Ensure the database you plan to use is supported by WebSphere Portal v6.0. Refer to Supported hardware and software for supported database that are needed for WebSphere Portal.

  • Ensure that the job DSNTIJSG has been executed to create the objects required for the DB2 JDBC and ODBC metadata methods. See the DB2 Installation Guide Enabling stored procedures and tables for JDBC and ODBC support at http://www.ibm.com/software/data/pubs/.

  • Ensure that support for table spaces that are defined with the Unicode encoding schema is enabled.

  • Ensure that prepared, dynamic SQL statements are cached (DSN6SPRM CACHEDYN set to YES). See the DB2 for z/OS Installation Guide for details.

  • Ensure that the set system parameter is set to rrulock=yes.

  • During database transfer from Cloudscape to DB2 for z/OS, a supporting Low Order Byte (LOB) table space is created for the database tables storing documents in Portal Document Manager (PDM). The PRIQTY and SECQTY for the table space are assigned using the default values. If you plan to store a large number of documents, you should use an automatic class selection (ACS) routine to allocate the DB2 for z/OS data sets with a primary and secondary space allocation of at least 10 cylinders. The LOB tables spaces can be identified by their name, having a structure like JCRDB.Sxxxxxxx, where xxxxxxx is a system-assigned combination of seven numbers and characters.

 

Plan

The following areas provide an overview of the database and user names used in the documentation as well as some information about each database and user you should consider in the planning. The database names and users on this page are suggested values and provide consistency throughout the documentation. During the implementation, replace these values with values in the environment. If you plan to use a single DB2 for z/OS subsystem to hold data for more than one portal instance, create a unique database user for each portal instance. By default all database table names include the name of the database user used to access the data. Therefore, to prevent table name conflicts, create a unique database user for each WebSphere Portal instance on the shared DB2 for z/OS subsystem.

Each portal instance must be in separate and distinct WebSphere Application Server cells. If the portal instances are installed in the same file system (for example, two portal instances on one Windows server box), each instance must be installed in a separate and unique directory. If the portal instances are installed in different file systems (for example, two portal instances on two Windows server boxes), the same directory name can be used.

Each portal instance must be in separate and distinct WebSphere Application Server cells. If the portal instances are installed in the same file system, each instance must be installed in a separate and unique directory. If the portal instances are installed in different file systems, the same directory name can be used.

Notes:

  • After the database software has been installed, create the required databases and users and grant the proper privileges to those users.

  • If WebSphere Portal Version 6.0 and an earlier version of WebSphere Portal coexist, the database user IDs for WebSphere Portal Version 6.0 must be different than earlier versions to avoid conflicts during installation.

    If the two versions of WebSphere Portal coexist on different databases, using the same user ID will not cause conflict.

  • The Feedback function is not configured by default. It must first be turned it on by following the steps in Enable logging, otherwise the Feedback tables will not be created in the new database.

  • DB2 Content Manager Runtime Edition is a data repository running against DB2 for z/OS that is used to store data for applications such as Personalization, Document Manager.

  • If you are using DB2 Fix Pack 10 or DB2 Fix Pack 11, complete the following steps prior to database transfer. This fix should be applied to the client side of the DB2 installation. Failure to follow these steps will cause the database transfer to hang at the task action-process-constraints.

    1. Locate the following file:

      • UNIX:

        /home/db2inst1/sqllib/cfg/db2cli.ini

      • Windows:

        db2home/sqllib/db2cli.ini

    2. Edit the file by adding the following to the end of the file: 

      [COMMON]
DYNAMIC=1

      An empty line is required after the dynamic=1 at the end of the file.

The following sections provide an overview of the different databases and database user names you should consider in the planning. While configuring Portal to use one database is technically possible, you strongly recommend using separate databases for scalability and performance tuning reasons. To use a single shared database, replace each database and user variable with the name of the database and database user, respectively.

 

Databases

The following table demonstrates the information each application will store in the databases.

Application Placeholder Names Function Space considerations
WebSphere Portal Databases:

  • releaseonzos

  • communityonzos

  • customizationonzos

Used for WebSphere Portal (at a minimum) or to hold all data. Stores information about user customizations, such as Pages, and user profile and login information. Amount of database space that is required depends on the number of WebSphere Portal users and portal objects, such as pages and portlets.
Member Manager wmmdbonzos Used for Member Manager if the data is not stored on the WebSphere Portal database. Stores information about users and groups. Dependent on the configuration of users, groups and their relationship, or only additional attributes are stored Amount of this database depends on the number of Users and groups you are storing within the database repository. If your user repository is an LDAP this database is not used.
Document Manager Personalization Web Content Management Database:jcrdbnameonzos Used by DB2 Content Manager Runtime Edition to store Document Manager and Personalization components. Contains documents, personalization rules, personalization campaigns, and document library configuration information. Amount of database space that is required depends on the size and number of documents created and/or uploaded by the Document Manager and the number and size of Personalization rules and campaigns.
Feedback Database:fdbkdbnameonzos Table space:fdbkdbts Used by Feedback components. Contains the information that is logged by the web site for generating reports for analysis of site activity. Amount of database space that is required for logging depends on the amount of traffic to the site. The amount of data that is logged per login-enabled page can vary.
Likeminds Database:lmdbnameonzos Table space:lmdbts Used for LikeMinds data. Contains the recommendations to be displayed to users when their interactions with the Web site have been analyzed and predictions generated. Amount of database space that is required depends on the amount of traffic to the site.

 

Users

The following table demonstrates the number of tables and types of objects owned by each user. The WebSphere Portal architecture allows each of the following users to exist in the same database.

All tablespaces will be approximately 2.8 GB by default. The size will increase with the use of the DB2 Content Manager Runtime Edition function.

Application Database user placeholder Recommended name Function
WebSphere Portal

<none> Core user. Will own approximately 130 tables for each domain. Owns WebSphere Portal core objects, which includes tables that store the user customizations made to Pages.
DB2 Content Manager Runtime Edition icmadmin <none> DB2 Content Manager Runtime Edition user. Will own at least 1130 tables; the number could be higher depending on usage.
Member Manager wmmdbusr <none> Member Manager user. Will own approximately 35 tables. Owns the Member Manager objects, which includes the tables that store login information about WebSphere Portal users.
Feedback feedback <none> Feedback user. Will own approximately 50 tables used for logging site and personalization usage.
Likeminds lmdbusr <none> Likeminds user. Will own approximately 15 tables used to hold the web site usage analysis routines and recommendation text.

 

DB2 for z/OS architecture

In a remote database environment, WebSphere Portal and DB2 for z/OS Connect are installed on one machine (the local machine). The DB2 for z/OS server is installed on a separate machine (the remote machine).

Figure: Remote Database Environment

Local Machine IP Address: 1.2.3.4
  WebSphere Portal  
     
  DB2 for z/OS Connect: db2inst1 Connect to server on 1.2.3.5  
     

Remote Machine IP Address: 1.2.3.5
   
  DB2 for z/OS server: db2inst1  
   
     

 

Next steps

You have completed this step. Continue to the next step:

 

Parent topic:

Plan for databases