版次注意事項


8.7 Chapter 13. Configuring DB2

The following parameters require changes:

8.7.1 Sort Heap Size (sortheap)

The "Recommendation" section has changed. The information here should now read:

When working with the sort heap, you should consider the following:

8.7.2 Sort Heap Threshold (sheapthres)

The second last paragraph in the description of this parameter has changed. The paragraph should now read:

Examples of those operations that use the sort heap include: sorts, dynamic bitmaps (used for index ANDing and Star Joins), and operations where the table is in memory.

The following information is to be added to the description of this parameter:

There is no reason to increase the value of this parameter when moving from a single-node to a multi-node environment. Once you have tuned the database and database manager configuration parameters on a single node (in a DB2 EE) environment, the same values will in most cases work well in a multi-node (in a DB2 EEE) environment.

The Sort Heap Threshold parameter, as a database manager configuration parameter, applies across the entire DB2 instance. The only way to set this parameter to different values on different nodes or partitions, is to create more than one DB2 instance. This will require managing different DB2 databases over different nodegroups. Such an arrangement defeats the purpose of many of the advantages of a partitioned database environment.

|8.7.3 Maximum Percent of Lock List Before Escalation (maxlocks)

| |

|The following change pertains to the Recommendation section of the "Maximum |Percent of Lock List Before Escalation (maxlocks)" database configuration |parameter.

|Recommendation: The following formula allows you |to set maxlocks to allow an application to hold twice |the average number of locks:

|   maxlocks = 2 * 100 / maxappls

|Where 2 is used to achieve twice the average and 100 represents the largest percentage value allowed. If you have only a |few applications that run concurrently, you could use the following formula |as an alternative to the first formula:

|   maxlocks = 2 * 100 / (average number of applications running 
|concurrently)

|One of the considerations when setting maxlocks |is to use it in conjunction with the size of the lock list (locklist). The actual limit of the number of locks held by an application |before lock escalation occurs is:

|   maxlocks * locklist * 4096 / (100 * 36)

|Where 4096 is the number of bytes in a page, 100 |is the largest percentage value allowed for maxlocks, |and 36 is the number of bytes per lock. If you know that one of |your applications requires 1000 locks, and you do not want lock escalation |to occur, then you should choose values for maxlocks |and locklist in this formula so that the result is |greater than 1000. (Using 10 for maxlocks and 100 |for locklist, this formula results in greater than |the 1000 locks needed.)

|If maxlocks is set too low, lock escalation happens |when there is still enough lock space for other concurrent applications. If maxlocks is set too high, a few applications can consume |most of the lock space, and other applications will have to perform lock escalation. |The need for lock escalation in this case results in poor concurrency.

|You may use the Database System Monitor to help you track and tune this configuration parameter.

|8.7.4 Configuring DB2/DB2 Data Links Manager/Data Links Access Token Expiry Interval (dl_expint)

|

|Contrary to the documentation, if dl_expint is set to "-1", the access |control token expires. The workaround for this is to set dl_expint to its |maximum value, 31536000 (seconds). This corresponds to an expiration time |of one year, which should be adequate for all applications.

|8.7.5 MIN_DEC_DIV_3 Database Configuration Parameter

|

|The addition of the MIN_DEC_DIV_3 database configuration parameter is provided |as a quick way to enable a change to computation of the scale for decimal |division in SQL. MIN_DEC_DIV_3 can be set to YES or NO. The default value |for MIN_DEC_DIV_3 is NO.

|The MIN_DEC_DIV_3 database configuration parameter changes the resulting |scale of a decimal arithmetic operation involving division. If the value is |NO, the scale is calculated as 31-p+s-s'. Refer to the SQL Reference, Chapter 3, "Decimal Arithmetic in SQL" for more information. |If set to YES, the scale is calculated as MAX(3, 31-p+s-s'). This causes the |result of decimal division to always have a scale of at least 3. Precision |is always 31.

|Changing this database configuration parameter may cause changes to applications |for existing databases. This can occur when the resulting scale for decimal |division would be impacted by changing this database configuration parameter. |Listed below are some possible scenarios that may impact applications. These |scenarios should be considered before changing the MIN_DEC_DIV_3 on a database |server with existing databases. |

|Note:
DB2 Version 7 also has the following limitations: |
  1. |The command GET DB CFG FOR DBNAME will not |display the MIN_DEC_DIV_3 setting. The best way to determine the current setting |is to observe the side-effect of a decimal division result. For example, |consider the following statement:
    |VALUES (DEC(1,31,0)/DEC(1,31,5))

    |If |this statement returns sqlcode SQL0419N, then the database does not have MIN_DEC_DIV_3 |support or it is set to OFF. If the statement returns 1.000, then |MIN_DEC_DIV_3 is set to ON.

  2. |MIN_DEC_DIV_3 does not appear in the list of configuration keywords when |you run the following command: ? UPDATE DB CFG |
|

|8.7.6 Application Control Heap Size (app_ctl_heap_sz)

| |

|The text for this parameter should now read:

|For partitioned databases and non-partitioned databases with intra-parallelism |enabled (intra_parallel=ON), this is the size of the shared memory area allocated |for the application control heap. For non-partitioned databases where intra-parallelism |is disabled (intra_parallel=OFF), this is the maximum private memory that |will be allocated for the heap. There is one application control heap per |connection per partition.

|The application control heap is required primarily for sharing information |between agents working on behalf of the same request, and, in a partitioned |database environment, for storing executable sections representing SQL statements. |Usage of this heap is minimal for non-partitioned databases when running queries |with a degree of parallelism less than or equal to 1.

|This heap is also used to store descriptor information for declared temporary |tables. The descriptor information for all declared temporary tables that |have not been explicitly dropped is kept in this heap's memory and cannot |be dropped until the declared temporary table is dropped.

|The "Recommendation" portion remains unchanged.

|8.7.7 Database System Monitor Heap Size (mon_heap_sz)

| |

|The default for the OS/2 and Windows NT Database server with local |and remote clients and Satellite database server with local clients has changed |from 24 to 32. The range is unchanged.

|8.7.8 Maximum Number of Active Applications (maxappls)

| |

|The upper range limit for all platforms has changed from 64 000 |to 60 000. The default value is unchanged.

|8.7.9 Recovery Range and Soft Checkpoint Interval (softmax)

| |

|The unit of measure is changed to the percentage of the size of one primary |log file.

8.7.10 Track Modified Pages Enable (trackmod)

Configuration Type: Database

Parameter Type: Configurable

Default [Range]: Off [ On; Off ]

When this parameter is set to ON, the database manager will track which pages in the database have changed since the most recent full backup was taken. This allows the backup utility to determine which pages should be included in an incremental backup without having to examine every page individually. For SMS tablespaces, the granularity of this tracking is at the tables pace level. For DMS table spaces, the granularity is at the extent level for data and index pages and at the table space level for other page types. After setting this parameter to ON, you must take a full database backup in order to have a baseline against which incremental backups can be taken.

8.7.11 Change the Database Log Path (newlogpath)

Configuration Type: Database

Parameter Type: Configurable

Default [Range]: Null [ any valid path or device]

Related Parameters: Location of Log Files (logpath); Database is Consistent (database_consistent)

This parameter allows you to specify a string of up to 242 bytes to change the location where the log files are stored. The string can point to either a path name, or to a raw device. If the string points to a path name, it must be a fully qualified path name, not a relative path name.

Note:
In a partitioned database environment, the node number is automatically appended to the path. This is done to maintain the uniqueness of the path in multiple logical node configurations.

To specify a device, specify a string that the operating system identifies as a device. For example, on Windows NT,

\\.\d: or \\.\PhysicalDisk5
Note:
You must have Windows NT Version 4.0 with Service Pack 3 installed to be able to write logs to a device.

On UNIX-based platforms,

/dev/rdblog8 
Note:
You can only specify a device on AIX, Windows 2000, Windows NT, Solaris, HP-UX, NUMA-Q, and Linux platforms.

The new setting does not become the value of logpath until both of the following occur:

When the first new connection is made to the database, the database manager will move the logs to the new location specified by logpath.

There might be log files in the old log path. These log files might not have been archived. You might need to archive these log files manually. Also, if you are running replication on this database, replication might still need the log files from before the log path change. If the database is configured with the User Exit Enable (userexit) database configuration parameter set to "Yes", and if all the log files have been archived either by DB2 automatically or by yourself manually, then DB2 will be able to retrieve the log files to complete the replication process. Otherwise, you can copy the files from the old log path to the new log path.

Recommendation:
Ideally, the log files will be on a physical disk which does not have high I/O. For instance, avoid putting the logs on the same disk as the operating system or high volume databases. This will allow for efficient logging activity with a minimum of overhead such as waiting for I/O.

You can use the database system monitor to track the number of I/Os related to database logging.

For more information, refer to the following monitor element descriptions in the System Monitor Guide and Reference:

The preceding data elements return the amount of I/O activity related to database logging. You can use an operating system monitor tool to collect information about other disk I/O activity, then compare the two types of I/O activity.

|8.7.12 Location of Log Files (logpath)

|Configuration Type: Database

|Parameter Type: Informational

|Related Parameters: Change the Database Log Path |(newlogpath)

|This parameter contains the current path being used for logging purposes. |You cannot change this parameter directly as it is set by the database manager |after a change to the newlogpath parameter becomes effective. When a database |is created, the recovery log file for it is created in a subdirectory of the |directory containing the database. The default is a subdirectory named SQLOGDIR |under the directory created for the database.

|8.7.13 Maximum Storage for Lock List (locklist)

|The maximum value is increased from 60 000 to 524 288.


[ 頁面頂端 | 前一頁 | 下一頁 | 目錄 | 索引 ]