On the welcome page of the DB2(R) Information Center you will find a link to the list of new features added in this release. You can see the latest version of the DB2 Information Center through the IBM(R) Web site at http://publib.boulder.ibm.com/infocenter/db2help/index.jsp
The latest version of the DB2 Information Center can also be installed locally from the DB2 Information Center CD.
In addition to the new features listed in the DB2 Information Center, the following new features have also been added:
7 7 7Two new configuration parameters, log archive method 1 (LOGARCHMETH1) and 7log archive method 2 (LOGARCHMETH2), have been added to handle log file allocation 7and removal. These parameters cause the database manager to archive log files 7to a location that is not in the active log path. If both of these parameters 7are specified, each log file is archived twice. This means that you will have 7two copies of archived log files in two different locations. These two new 7configuration parameters replace the user exit (USEREXIT) and log retain enable 7(LOGRETAIN) configuration parameters, which are still available, but should 7be used for back level compatibility only.
7Three other new configuration parameters, ARCHRETRYDELAY, NUMARCHRETRY, 7and FAILARCHPATH, have been added so that you can better tune log archiving 7to meet your needs. If an error occurs when log files are being archived, 7archiving is suspended for the amount of time specified by the ARCHRETRYDELAY 7database configuration parameter. You can use the NUMARCHRETRY database configuration 7parameter to specify the number of times that DB2 UDB is to try archiving 7 a log file to the primary or secondary archive directory. After the specified 7number of attempts have been made, DB2 UDB tries to archive log files to the 7failover directory, specified by the FAILARCHPATH database configuration parameter.
7 7 7At database activation time, DB2 UDB automatically augments the database 7shared memory region with an overflow buffer. The buffer is used to satisfy 7peak memory requirements for any heap in the database shared memory region 7whenever a heap exceeds its configured size. If a heap exceeds its configured 7size, the data area is expanded as needed until the entire overflow memory 7area in the database shared memory region is used.
7 7 7In addition to the existing supported platforms, DB2 UDB Version 8.2 introduces 764-bit support for the DB2 Query Patroller(TM) server on the following platforms:
7The benefits of 64-bit coverage include more address space for code, 7variables, shared memory, and buffer pools.
DB2 Query Patroller server can now be installed on top of the following 7DB2 products:
7A lock type can be specified for queries that perform updates. This change 7to a query involving cursors allows FOR UPDATE cursors to take advantage 7of row blocking. In addition, Repeatable Read (RR) or Read Stability (RS) 7can be selected when querying a read-only results table so that positioned 7cursor updates will succeed. The isolation-clause and lock-request-clause 7cannot be used in a subselect, SQL function, SQL method, or trigger.
7 7 7A new tool, db2xprt.exe, is available to let you format trap files (*.TRP). 7This tool formats DB2 UDB's binary trap files into a human readable ASCII 7file. Trap files are located in the instance directory (DB2INSTPROF) by default 7or in the diagnostic data directory path if the DIAGPATH database manager 7configuration parameter is set.
7You must have access to the DIAGPATH directory.
77>>-db2xprt--+----------+--+----+--+----+--infile--+---------+-->< 7 +-/p--path-+ '-/m-' '-/n-' '-outfile-' 7 '-/v-------' 7
Memory pinning is now available as an option for DB2 UDB Version 8.2 on 7all Linux architectures. With memory pinning enabled, the database shared 7 memory set is kept in RAM and is not swapped out. This strategy results 7in better use of memory, and it keeps more memory available for other uses.
7To set memory pinning:
7The ipcs -m command shows shared memory segments 7with a LOCKED status when any agent is connected to a database in an instance 7that has been started with this option.
DB2 UDB now supports precise configuration of DB2 UDB use of some operating 7system resources. For example, you can pin each engine EDU to a single logical 7processor. Such advanced configurations can improve performance in some scenarios. 7However, these configurations should be attempted only by advanced users who 7are knowledgeable about their operating environment and its workload. Misconfiguration 7can result in degraded performance.
7A resource policy is defined to describe how DB2 UDB interacts with the 7operating system. The resource policy typically limits what resources DB2 7UDB uses, or it contains rules for assigning specific operating system resources 7to specific DB2 UDB objects. The extent of resource control varies depending 7on the operating system.
7 7Platform | 7Overview of support | 7
---|---|
Linux | 7Restrict a DB2 UDB instance to use only a subset of 7logical processors on the system. | 7
AIX(R) 5.2 | 7
7
|
7
The DB2_RESOURCE_POLICY registry variable is used to define a resource 7policy. This variable can be set to the path of a well formed configuration 7file.
7You might experience several types of failure when configuring a resource 7policy:
7Any error in configuring a resource policy results in db2start failing.
7The operating system requirements for resource policy support are described 7in the following table.
7 7Platform | 7Overview of support | 7
---|---|
Linux | 7
7
|
7
AIX 5.2 | 7
7
|
7
The following sample configuration file illustrates one-to-one 7processor-to-processor binding on AIX and Linux.
7 7<RESOURCE_POLICY> 7 <GLOBAL_RESOURCE_POLICY> 7 <METHOD>CPU</METHOD> 7 <RESOURCE_BINDING> 7 <RESOURCE>0</RESOURCE> 7 </RESOURCE_BINDING> 7 <RESOURCE_BINDING> 7 <RESOURCE>1</RESOURCE> 7 </RESOURCE_BINDING> 7 </GLOBAL_RESOURCE_POLICY> 7</RESOURCE_POLICY>
Each DB2 UDB engine process will be bound to either processor 0 or processor 71. Processor binding of engine processes to processors identified in the policy 7occurs in a circular round-robin fashion. This policy assumes that the system 7consists of at least 2 logical processors. Processors are identified by a 7number from 0 to (n-1) where n is the number of processors on the system.
7 7The following is a sample file for topology-based configuration:
7 7<RESOURCE_POLICY> 7 <DATABASE_RESOURCE_POLICY> 7 <DBNAME>MYDB</DBNAME> 7 <METHOD>RSET</METHOD> 7 <RESOURCE_BINDING> 7 <RESOURCE>sys/node.02.00000</RESOURCE> 7 <DBMEM_PERCENTAGE>25.0</DBMEM_PERCENTAGE> 7 <SERVICE_NAME>svnm0</SERVICE_NAME> 7 <BUFFERPOOL_BINDING> 7 <NUM_CLEANERS>3</NUM_CLEANERS> 7 <BUFFERPOOL_ID>4</BUFFERPOOL_ID> 7 <BUFFERPOOL_ID>8</BUFFERPOOL_ID> 7 </BUFFERPOOL_BINDING> 7 </RESOURCE_BINDING> 7 <RESOURCE_BINDING> 7 <RESOURCE>sys/node.02.00001</RESOURCE> 7 <DBMEM_PERCENTAGE>50.0</DBMEM_PERCENTAGE> 7 <SERVICE_NAME>svnm1</SERVICE_NAME> 7 <BUFFERPOOL_BINDING> 7 <NUM_CLEANERS>5</NUM_CLEANERS> 7 <BUFFERPOOL_ID>12</BUFFERPOOL_ID> 7 <BUFFERPOOL_ID>13</BUFFERPOOL_ID> 7 </BUFFERPOOL_BINDING> 7 <BUFFER_POOL_BINDING> 7 <NUM_CLEANERS>2</NUM_CLEANERS> 7 <BUFFERPOOL_ID>32</BUFFERPOOL_ID> 7 </BUFFERPOOL_BINDING> 7 </RESOURCE_BINDING> 7 </DATABASE_RESOURCE_POLICY> 7</RESOURCE_POLICY>7
The following points provide analysis of the preceding sample file:
7