The DB2 tutorial you are looking at is: IBM DB2 basic Performance tuning. Buffer pool
If you have experience using DB2 UDB, you should know that the buffer pool is a space in memory that is allocated separately to the DB2 database manager, allowing it to add new data to the database or to respond to a query that returns a buffer from the disk to some data data pages. Because accessing data from memory is bound to be much faster than reading from disk, it improves the overall performance of the database by reducing the disk's I/O operations buffer pool. In fact, studying how buffer pools are created and used in tuning optimized database performance is the most important step.
Because of the importance of the buffer, each DBA should understand how DB2 UDB uses them. Here is a quick review of its course. When new data is added to the database, it first adds a new page to the buffer. Eventually, the page will be materialized into the database storage space. On the other hand, in response to queries when data is retrieved from the database, the DB2 Database Manager will first store the pages containing the data in the buffer pool before passing it on to the application or user who needs it. Each time a new query is executed, a page in each of the available buffer pools to search for data that has already been needed resides in memory. If so, it is immediately passed to the corresponding application or user. However, if the required data cannot be found in these buffer pools, the DB2 database Manager will say that the data is retrieved from memory and copied into the buffer before the data is passed. Once the page is copied to the buffer pool, the page will remain in the buffer until the database is closed or until the space in which it resides needs to store another page. (Since all data is loaded and modified first in the buffer--the modified page will eventually refresh the disk storage--so the data stored in the buffer pool is always up to date) when the buffer pool is full, the DB2 Database manager will pass the last reference time of the test page, the page type, Or the page changes will not affect the disk content changes to choose which pages to remove, these pages may be referenced again. For example, a page that was retrieved 30 minutes ago in response to a query would be more easily overwritten than a page that contains an update operation and does not implement an update.
The DB2 udb default creates a buffer pool (IBMDEFAULTBP) as part of the database creation process. On Linux and UNIX platforms, the buffer pool is allocated 1,000 4KB pages from memory, and on the Windows platform, the buffer pool is allocated 250 4KB pages from memory. You can increase or decrease the number of 4KB pages in this buffer pool by finding the buffer pool menu in the control center and selecting the appropriate operation or executing the ALTER BUFFERPOOL statement. You can also create additional buffers by using the same method in the control center or by executing the Create BUFFERPOOL statement.
Because of the importance of buffers, you should carefully consider how many buffer pools to use to accommodate your implementation needs, how big each one will be, and how each buffer pool can be fully exploited. In most environments, the number of buffers that can be used effectively depends on the size of the available system memory. If the available memory can retain 10,000 4k pages (or less), it is usually better to use a separate large buffer pool than to use multiple small buffer pools. Using multiple small buffers will result in frequent access to pages to and from memory, which in turn results in competition for storage objects such as I/O for catalog tables, or repeated access to user tables and indexes. However, if you have more memory, you should consider creating a separate buffer for the following:
· Each kind of temporary table space is defined
· Contains a table space that has been or is repeatedly accessed by some short-term update transactions
· Table space containing frequently updated tables and indexes
· Table spaces containing tables and indexes that are frequently queried but rarely updated
· Table spaces that contain tables that are frequently used in random queries
· Table space containing data that is rarely accessed by the application
· Contains some table spaces for the data and indexes you want to use.
In many cases, a larger buffer pool is preferable to a smaller buffer pool. However, consider the total amount of memory that can be used and how the buffer pool will be used. If you have an application to perform many random access operations from a very large table, then you should create and use a small buffer pool for this particular table. In this case, it is not necessary to keep the data pages in the buffer pool memory once they are used to execute a separate query. On the other hand, if you have an application to retrieve data frequently from a few seemingly small tables, you should consider creating a large enough buffer pool to hold all of the data in the list. With this design, the data can be loaded into memory at one time, allowing it to be retrieved over and over again without the need for additional disk I/O.
This news total 3 pages, current in 1th page 1 2 3
<
