Plan 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.When planning to transfer data to IBM DB2 Universal Database for z/OS, consider the following factors:
- the domain data we 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 to use is supported by this version of WebSphere Portal. Refer to the list of supported databases in the System requirements.
- Ensure that Java Database Connectivity requirements are met. Consult the following references:
- DB2 Universal Database for OS/390 and z/OS: Application Programming Guide and Reference for Java
- The IBM Redbooks publication, DB2 for z/OS and OS/390: Ready for Java SG24-6435-00.
- To use IBM DB2 Universal Database for z/OS for a database transfer, as a database user registry, or a property extension 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:
- DB2 for z/OS v8, Common service area
- DB2 for z/OS Version 9.1, Common service area storage requirements
- If we 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/Othat 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 the system and define the bufferpools as appropriate for the 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. To store a large number of documents, 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 the 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 Enable 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 containing such data. With LOB logging disabled, we can recover full backups, but not incremental backups that can be used for point in time recovery. To recover point in time backups, enable LOB logging. For detailed instructions, see Technote 1306637, Manage 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 is 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.
The database names and users on this page are suggested values and provide consistency throughout the documentation. Replace these values with values in the 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.
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.
To use a single DB2 for z/OS subsystem to hold data for more than one portal installation, create unique schema names for each portal installation to prevent table name conflicts. For Member Manager data, create and use a unique Member Manager database user ID for each portal instance, to prevent table name conflicts. We can share some of the portal databases between the portal instances. For more information, refer to the topis that explains sharing database domains between separate portal instances.
Each portal installation must be in separate and distinct WAS 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 WAS 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).
- Review the different databases shown in the following table and replace these values with the values in the environment; schema names must be different when the database subsystem is shared. Configure WebSphere Portal to use one database. However, using separate databases will improve scalability and performance.
Application DB 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 Information logged by the 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 logged per login-enabled page can vary. LikeMinds Contains the recommendations to be displayed to users when their interactions with the Web site have been analyzed and predictions generated.
- Database: lmdbzos
- Table space: lmdbts
Depends on the amount of traffic to the site.
Application and domains DB 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.
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, 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.
Application and domains DB names Function Space required Information logged by the Web site for generating reports for analysis of site activity.
WPSDBFEE Depends on the amount of traffic to the site. The amount of data logged per login-enabled page can vary.
Application and domains DB names Function Space required Contains the recommendations to be displayed to users when their interactions with the Web site have been analyzed and predictions generated.
WPSDBLIK Depends on the amount of traffic to the site.
- 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.
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.
- 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.
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.
- If the 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:
on how to create a TEMP database and a TEMP tablespace by database
Refer to the DB2 for z/OS documentation for additional information on setting up the TEMP database and TEMP tablespaces.Database version Example DB2 for z/OS v8 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 statemento 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.
Parent: Database considerations
Related: