Use all memory in DB2 (1)

Now, in the world of Proteus and iSCSI, the 64-bit architecture is gradually becoming a standard that allows commercial UNIX®Such as AIX®, HP-UX, Solaris, etc.) to provide a lot of memory for your favorite relational database. The addressing capability of 32-Bit Memory is about 4 GB, and many UNIX machines have 20 to 100 GB memory, so you certainly want to use this large memory. The Intel world is not far behind: at present, Linux and Windows 2000 running on 64-bit Intel chips are a reality in operating systems, compilers, and database software laboratories, and will soon be sold on the websites around you.

If both the hardware and the operating system are ready to use huge memory and the database can also use large memory, how can you combine them and make them work? Use DB2®In version 7, we must first understand that, internally, DB2 assumes that it uses 32-Bit Memory and hardware. To take advantage of larger memory, you must tell DB2 how to use it and how to use it. Do not blame DB2-most DB2 clients and many DB2 servers will run on 32-bit Intel machines in the next few years. And even if DB2 detects 96 GB of memory on your machine, who can be sure that you want DB2 to use all the memory instead of sharing it with other applications?

When using this large memory, you have several options. The most obvious choice is to create a 64-bit DB2 instance. DB2 version 7 on AIX, Solaris, and HP-UX now supports this operation. If you have version 7.1, you must download revision package 1 to install the 64-bit DB2 database. If you have version 7.2 or later, you do not have to install the revision package to create a 64-bit DB2 instance. To create a 64-bit DB2 instance, run the db2icrt command and specify the value of-w as 64. For example:

db2icrt -w 64 -u db2fenc1 db2inst1

Describes the 64-bit environment where the DB2 User Manual is located: http://www-4.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/document.d2w/report? Fn1_db2q9e71frm3toc.htm.

1 + 1 = 2. The power of 2 is a great number.
Each 32-bit DB2 instance can address 4 GB memory. Generally, you want to allocate most of the memory to the buffer pool. However, memory segments on AIX, HP-UX, and Windows Limit the maximum buffer pool size to 4 GB. Even on Solaris with a very clean Memory Model in the 32-bit world, the memory used for the DB2 Buffer Pool cannot exceed 3.35 GB; the remaining 4 GB memory space must be dedicated to other shared memory usage of DB2. Fortunately, the memory model is cleaner for all operating systems in the 64-bit world .) On the HP-UX, the maximum buffer pool that a 32-bit DB2 instance can create is approximately 800 MB. On a HP-UX, a buffer pool of more than 1 GB is available only when you run multiple instances by using Memory Windows on a 32-bit HP-UX. HP Memory Windows is described in DB2 Release Notes .) On Windows, the buffer pool is limited to 3 GB, 1.75 GB on AIX, and about 1 GB on Linux. The following figures 1 and 2 illustrate the 32-Bit Memory Model of DB2 on AIX and Solaris respectively.

Figure 1. DB2 32-Bit Memory Model on AIX

 

Figure 2. DB2 32-Bit Memory Model on Solaris

 

In a large memory system running 32-bit DB2, a large amount of memory needs to be provided to the buffer pool. The simplest way is in a DB2 Enterprise Extended Edition Enterprise-Extended Edition (EEE )) run multiple logical DB2 instances in configuration. You only need to run one instance of the operating system, which helps to save costs and allow multiple DB2 instances to communicate with each other through shared memory instead of TCP/IP or communication switch. With the non-shared architecture of DB2, each instance can happily address 4 GB memory within its own database partition. In most DB2 TPC-H benchmarking-It typically enables DB2 EEE to run decision-making support queries on a database of up to 300 GB or larger-a large SMP divides each DB2 node up to 4 GB memory each node is a database partition that runs its own DB2 instance ).

DB2 can also use three other methods to leverage large memory machines. On AIX, Solaris, and Windows, DB2 supports Extended Storage (also known as ESTORE ). This allows DB2 to use the maximum memory available in the 32-Bit Memory Model for system temporary tables for sorting) and read-only user data. When DB2 acquires data from a disk, DB2 determines which data can be considered read-only, but DB2 needs to be configured to use extended storage.