Data Sharing Administration Guidelines

When implementing and managing data sharing in your shop, be sure to abide by the following guidelines.

Consider Multiple Coupling Facilities

To reduce the risk of downtime, deploy multiple coupling facilities. If one coupling facility fails, you can always switch to another "backup" coupling facility.

A recommended implementation is to have one coupling facility to house the group buffer pools and a second coupling facility for the SCA and lock structures.

Implement Group Buffer Pool Duplexing

Duplex your group buffer pool structures to provide failover capability for buffering in your data sharing environment. With group buffer pool duplexing a secondary group buffer pool is waiting on standby to take over buffering activity if the primary group buffer pool fails.

To start group buffer pool duplexing, at least one DB2 member must be actively connected to the group buffer pool. When group buffer pool duplexing is started, all activity to the group buffer pools is quiesced until duplexing is established. This usually lasts only a few seconds.

CAUTION

Initiate group buffer pool duplexing during a period of low system activity to avoid resource unavailable conditions while duplexing is being established.

You must use CFRM policies to activate group buffer pool duplexing. There are two ways to start duplexing a group buffer pool:

• Activate a new CFRM policy specifying DUPLEX(ENABLED) for the structure. If the group buffer pool is currently allocated, OS/390 can automatically initiate the process to establish duplexing as soon as you activate the policy. If the group buffer pool is not currently allocated, the duplexing process can be initiated when the group buffer pool is allocated.

• Activate a new CFRM policy specifying DUPLEX(ALLOWED) for the structure. If the group buffer pool is currently allocated, you must rebuild duplexing using the following command:

  
  

   SETXCF START,REBUILD,DUPLEX,STRNAME=  strname  

  
  

  If the group buffer pool is not currently allocated, you need to wait until it is allocated before using the SETXCF command to start the duplexing rebuild.

Take Action to Help Prevent Coupling Facility Failures

To limit down time due to coupling facility failure consider taking the following actions:

• Configure multiple coupling facilities.

• Reserve space in an alternate coupling facility in case the lock and SCA structures must be rebuilt.

• Use dedicated coupling facilities so that the MVS image is not lost during processor failure.

• Use uninterruptible power supplies for all dedicated coupling facilities.

• Implement group buffer pool duplexing.

• Configure more than one Sysplex timer.

Consider Archiving Logs to Disk

Consider archiving the primary DB2 log files to DASD. Doing so can significantly speed up the amount of time it takes to recover.

Of course, you should favor writing the second archive copy to tape for disaster recovery purposes.

Avoid Confusing Names for Data Sharing Groups

Avoid names that IBM uses for its XCF groups by avoiding the letters A-I as the first character of the group name (unless the first three characters are " DSN "). Additionally, avoid using " SYS " as the first three characters, and do not use the string " UNDESIG " as your group name.

Avoid Using DSNDB07 As a Work File Database Name

Each data sharing group member must have a work file database defined for it. Although one of the members of the data sharing group can use DSNDB07 , this is not advisable. Instead, create a descriptive name, for each work file database, for example the string "WK" concatenated to the member name.

CAUTION

You cannot specify a name that begins with DSNDB unless the name is DSNDB07 .

Consider CASTOUT(NO) to Speed Member Shutdown

As of DB2 V7, you can achieve a faster shutdown of DB2 data sharing members by specifying CASTOUT(NO) when stopping a member. By specifying CASTOUT(NO) when you STOP a member for maintenance, the window of unavailability decreases because it take less time to shutdown.

Be aware, though, that when you shutdown multiple members of a data sharing group with CASTOUT(NO) , some changed data might remain in the group buffer pools after the members have been stopped . If you need to ensure consistent data on disk (for example, to make a copy), then specify CASTOUT(YES) instead of CASTOUT(NO) .

You can check on the status of castout by displaying the DB2 member. The status will appear as QC on the display output if the member quiesced with some castout processing not completed.

Allocate Buffer Pools for Data Sharing

Specify separate buffer pools for shared data and non-shared data. Doing so makes it easier to manage and tune the group buffer pools in the coupling facility.

Keep an Eye on the EDM Pool

After implementing data sharing applications be sure to closely monitor EDM Pool storage. Because data sharing applications should be bound using RELEASE(DEALLOCATE) , storage used by the EDM Pool tends to increase when data sharing is in use.

Avoid Row-Level Locking

Row-level locking will increase data sharing overhead. The resources required to acquire, maintain, and release a row lock are about the same as required for a page lock. Use LOCKSIZE(ROW) sparingly, if at all, in a data sharing environment.

Specify Lock Structure Size with Care

The size of the coupling facility's locking structure directly affects the number of false contentions (collisions) that occur. If the hash table is too small, the propensity for false collisions increases . Any contention, including false contention , requires additional asynchronous processing which negatively impacts performance.