Planning for DB2 for z/OS

When planning to transfer data to IBM® DB2 Universal Database™ for z/OS®, you should consider the databases and user information, such as database names, what data is stored, and the database space needed. Some fix packs require steps prior to the transfer task to complete successfully.

Before you begin

When planning to transfer data to IBM DB2 Universal Database for z/OS, consider the following factors:
  • the domain data you are planning to transfer
  • the database name for that domain
  • its user information
  • the space needed for the data transfer to complete successfully

    Allot a higher percentage of space in the target database to allow for future scalability.

When planning to install DB2 for z/OS to use as the database for WebSphere® Portal, consider the following:

  • Review the database considerations.
  • Ensure the database that you plan to use is supported by this version of WebSphere Portal. Refer to the list of supported databases in the WebSphere Portal detailed system requirements.
  • Ensure that Java Database Connectivity requirements are met. Consult the following references:
  • If you plan to use IBM DB2 Universal Database for z/OS for a database transfer, as a database user registry, or a property extension (lookaside) database, change the Common Service Area (CSA) setting to 3500,350000. See the appropriate DB2® for z/OS Information Center topic for complete information about calculating and setting CSA:
  • If you are planning to use Type 2 driver with DB2 for z/OS Version 9.1.2, ensure that DB2 for z/OS APAR PK58105 is installed.
  • Review the following guidelines:
    • If the current version of WebSphere Portal and an earlier version coexist using the same DB2 for z/OS subsystem, the database user IDs for the current version of WebSphere Portal must be different than the earlier version to avoid conflicts during installation. If the two versions of WebSphere Portal connect to two different DB2 for z/OS subsystems, using the same user ID will not cause conflict.
    • Except when migrating to a new release of WebSphere Portal, using the same DB2 for z/OS subsystem for two independent lines of production should be avoided. Each line of production of WebSphere Portal should use a subsystem of DB2 for z/OS that is dedicated exclusively to this installation. Because the DB2 for z/OS database catalog is shared, complications may occur in a shared environment.
    • Check the bufferpool allocations for your system and define the bufferpools as appropriate for your installation and define a large enough size, for example: 
      -db2 display bufferpool(bp2) 
-db2 alter bufferpool(bp2) vpsize(15000)
      • Repeat for additional bufferpools as needed, for example:
        • bp3
        • bp4
        • bp5
        • bp32k1
        • bp32k2
      • Update BP8K0 catalog bufferpool to 35,000 before performing database transfer. The SYSIBM.SYSDATABASE table resides in this bufferpool and is used extensively by DB2 for z/OS during database transfer.
    • During database transfer from Derby to DB2 for z/OS, a supporting low order byte table space is created for the database tables storing documents. 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, or specify a large enough value for PRIQTY and SEQTY in the DB2 DSNTIJUZ member. The table 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.
    • Also in member DSNTIJUZ, update the following parameters and then verify DSNTIJUZ runs successfully:
      • edmdbdc = 204800
      • edmpool=409600
      • edmstmtc=204800
      • rrulock=no
      • cachedyn=yes (prepared, dynamic SQL statements are cached)
      • dbacrvw=yes (to allow database administrators to create Views)
      • +++tbsbpxml=BP16K1 (to explicitly create an XML table space. This value can be changed to any valid 16K bufferpool where the Administrative User has the USE privilege.)
    • If you intend to run the LikeMinds sample, increase the NUMLKTS and NUMLKUS parameters: Ten times the default is sufficient, more depending on your usage of the sample. For example, if NUMLKTS=1000 and NUMLKUS=10000 are the installation default values, then update these values to NUMLKTS=10000 and NUMLKUS=100000.
    • 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.
    • Ensure that job DSNTIJMS runs successfully (re-execute binds)
    • Ensure that job DSNTIJEX runs successfully
    • Because large objects are stored in columns that can become very large, logging changes to these columns requires a huge amount of log space. For this reason, large object (LOB) logging is disabled by default for tablespaces that contain such data. With LOB logging disabled, you can recover full backups, but not incremental backups that can be used for point in time recovery. To recover point in time backups, you must enable LOB logging. For detailed instructions, see Technote 1306637, Managing LOB logging in DB2 for z/OS.
  • Changes to DB2 for z/OS Version 9.1 related to defaults bufferpools affect the CREATE LOB TABLESPACE in that version of DB2 for z/OS. The CREATE LOB TABLESPACE will now take its default buffer pool from ZPARM field TBSBPLOB if the buffer pool is not explicitly specified, rather than taking the buffer pool from the database.

About this task

The database names and users on this page are suggested values and provide consistency throughout the documentation. Replace these values with values in your environment. The database name cannot exceed eight characters and can only contain letters and numbers.

The WebSphere Portal Customization Dialog generates jobs for creating the databases and end users, and granting privileges to these end users. The following table gives an overview of the databases WebSphere Portal requires.

If you plan to use a single DB2 for z/OS subsystem to hold data for more than one portal installation, use the same user name but a separate schema name for each database domain. For Member Manager, the user name must match the schema; the same database user cannot be used for the Member Manager databases of two distinct portal installations.

If you plan to use a single DB2 for z/OS subsystem to hold data for more than one portal installation, you must create unique schema names for each portal installation to prevent table name conflicts. For Member Manager data, you must create and use a unique Member Manager database user ID for each portal instance, to prevent table name conflicts. You can share some of the portal databases between the portal instances. For more information, refer to the topic that explains sharing database domains between separate portal instances.

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

Each portal installation must be in separate and distinct WebSphere Application Server cells and in separate and unique directories.

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

Procedure

  1. Review the different databases shown in the following table and replace these values with the values in your environment; schema names must be different when the database subsystem is shared. You can configure WebSphere Portal to use one database. However, using separate databases will improve scalability and performance.
    Table 1. Applications, database names, and space required
    Application Database name Space required
    WebSphere Portal

    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.
    • relzos
    • commzos
    • custzos
    		 Depends on the number of WebSphere Portal users and portal objects, such as pages and portlets.
    Personalization, Web Content Manager

    Contains documents and other content, personalization rules, personalization campaigns, and document library configuration information.

    		 jcrdbzos Depends on the number and size of Personalization rules and campaigns, and the number and size of items and elements created in Web Content Manager.
    Feedback

    Contains the information that is logged by your Web site for generating reports for analysis of site activity.
    • Database: fdbkzos
    • Table space: fdbkdbts
    		 Depends on the amount of traffic to the site. The amount of data that is logged per login-enabled page can vary.
    LikeMinds

    Contains the recommendations to be displayed to users when their interactions with your Web site have been analyzed and predictions generated.
    • Database: lmdbzos
    • Table space: lmdbts
    		 Depends on the amount of traffic to the site.
    Table 2. WebSphere Portal applications, database names, and space required
    Application and domains Database names Function Space required
    • Release
    • Customization
    • Community

    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.
    • WPSDBREL
    • WPSDBCUS
    • WPSDBCOM
    Core user who owns approximately 230 tables in total for all database domains used for WebSphere Portal core objects, including tables that store the page customizations made by users:
    • Release, approximately 120
    • Community, approximately 80
    • Customization, approximately 30
    		 Depends on the number of WebSphere Portal users and portal objects, such as pages and portlets.

    Contains documents and other content, personalization rules, personalization campaigns, and document library configuration information.

    Tip: The JCR domain needs to be unique, specifically, the JCR prefix cannot be the same exact (3 or 4) letters as the beginning of another database name; for example, it cannot be the same 3 or 4 letters as the LikeMinds domain.
    		 WPSDBJCR While only one database is indicated here, you should set the appropriate values in the icm.properties file to specify the tables for each database and the database prefix and create the necessary JCR databases. Depends on the size and number of documents created and uploaded, the number and size of Personalization rules and campaigns, and number of Web Content Manager objects.
    Table 3. Feedback applications, database names, and space required
    Application and domains Database names Function Space required

    Contains the information that is logged by your Web site for generating reports for analysis of site activity.

    		 WPSDBFEE   Depends on the amount of traffic to the site. The amount of data that is logged per login-enabled page can vary.
    Table 4. LikeMinds applications, database names, and space required
    Application and domains Database names Function Space required

    Contains the recommendations to be displayed to users when their interactions with your Web site have been analyzed and predictions generated.

    		 WPSDBLIK   Depends on the amount of traffic to the site.
  2. Review the tables and types of objects owned by each user. The architecture allows each of the following users to exist in the same database. All table spaces are approximately 2.8 GB by default. The size increases with the use of Java Content Repository.
    Table 5. Tables and objects owned by database users
    Application Database user placeholder Function
    WebSphere Portal
    • releaseusr
    • communityusr
    • customizationusr
    		 Core user who owns approximately 230 tables, used for WebSphere Portal core objects, which includes tables that store the user customizations made to pages.
    Java Content Repository
    • jcr
    		 Java Content Repository user who owns at least 1130 tables. The number could be higher depending on usage.
    Feedback
    • feedback
    		 Feedback user who owns approximately 50 tables used for logging site and personalization usage.
    LikeMinds
    • likeminds
    		 LikeMinds user who owns approximately 15 tables used to hold the Web site usage analysis routines and recommendation text.
  3. Review the tables and types of objects owned by each user. The WebSphere Portal architecture allows each of the following users to be the same.
    Table 6. Applications, database user placeholders, runtime database users, and functions
    Application Database user placeholder Runtime database user Function
    WebSphere Portal

    Core user who owns tables for each domain, used for WebSphere Portal core objects, including tables that store the page customizations made by users:

    • reladm
    • comadm
    • cusadm

    An optional database user who can connect to the database domain to perform configuration tasks.
    • reladm owns 121 tables, used for WebSphere Portal core objects, for example, page hierarchy definitions.
    • comadm owns 77 tables, used for WebSphere Portal core objects,
    • cusadm owns 30 tables, used for WebSphere Portal core objects, which includes tables that store the user customizations made to pages.
    Java Content Repository icmadmin

    An optional database user who can connect to the Java Content Repository database domain to perform configuration tasks.

    		 Java Content Repository user who owns at least 1130 tables; the number could be higher depending on usage.
    Feedback feedback

    An optional database user who can connect to the Feedback database domain to perform configuration tasks.

    		 Feedback user who owns approximately 50 tables used for logging site and personalization usage.
    LikeMinds lmadm

    An optional database user who can connect to the LikeMinds database domain to perform configuration tasks.

    		 LikeMinds user who owns approximately 15 tables used to hold the web site usage analysis routines and recommendation text.
  4. If your Java Content Repository is using declared global temporary tables (DGTT), you must have the appropriate TEMP database and TEMP tablespaces configured prior to use. The TEMP database may also require additional allocated space. Use the following information as a guideline to create a TEMP database and a TEMP tablespace to contain the declared temporary tables:
    Table 7. Examples on how to create a TEMP database and a TEMP tablespace by database version
    Database version Example
    DB2 for z/OS Version 8 Create a TEMP database and tablespace if it does not already exist. The following is a representative example of a TEMP database definition:
    CREATE DATABASE TEMP AS TEMP STOGROUP SYSDEFLT;
CREATE TABLESPACE TEMP IN TEMP  
USING STOGROUP SYSDEFLT  
BUFFERPOOL BP8  
SEGSIZE 32;
    This version also requires work file database storage for SQL statements that require working storage, such as sorts. This requires the addition of a table space to support sorting operations in addition to the TEMP database.
    DB2 for z/OS Version 9 in a non-data sharing environment The TEMP database is DSNDB07 and is created during database installation. Temporary table spaces are added to the existing TEMP database. The following is a representative example of a temporary table space:
    CREATE TABLESPACE ICMTEMP IN DSNDB07  
USING STOGROUP SYSDEFLT  
BUFFERPOOL BP8  
SEGSIZE 32;

    In this version the work file database and TEMP databases are combined. See the DB2 for z/OS information center for the procedures and sizing recommendations for creating work file databases.
    DB2 for z/OS Version 9 in a data sharing environment Create a WORKFILE database. Only one WORKFILE database can be created per subsystem. The following is a representative example for creating a WORKFILE database and temporary table space:
    CREATE DATABASE WORKTEMP AS WORKFILE STOGROUP SYSDEFLT;  
CREATE TABLESPACE ICMTEMP IN WORKTEMP  
USING STOGROUP SYSDEFLT  
BUFFERPOOL BP8  
SEGSIZE 32;

    In this version the work file database and TEMP databases are combined. See the DB2 for z/OS information center for the procedures and sizing recommendations for creating work file databases.
    Refer to the DB2 for z/OS documentation for additional information on setting up the TEMP database and TEMP tablespaces.