RE: thank you IBM

> -----Original Message----- > From: Madison Pruet [mailto:mpruet@comcast.net] > > What is described by the 'victim' in the Admin Guide is the same as a > forground write in IDS. This does not mean that every dirty page must > be flushed to disk before it can be used again. It means that if the > buffer pool is so tight that there are no clean buffers available, > then a page will be forced to disk, just as with the IDS forground > write. > > Normally the dirty buffers will be flushed to disk by the page > cleaners when the parameter of chngpgs_thresh is reached, or if the > distance between the oldest dirty page and the current log position > reaches a set percentage as defined by the 'softmax' parameter. > Therefor, recovery time is based on a set percentage of the total log > file size. If you want to minimize the recovery time, you can set > 'softmax' to 1 and thus ensure that the recovery > process will only need to process 1% of the logs. > > > t > Madison, I can just give a bigger fragment of DB2 documentation. There is a chance that my understanding of that fragment is wrong (English is not my native language). May be, this fragment is written incorrectly As for myself, I can't understand the necessity of that additional dirty page flush. Unfortunately, I don't have any access to any additional information on DB2 architecture except the official manual. ........................ Administration Guide: Performance Chapter 2. Architecture and processes -> -> Processes -> Update process "When an agent updates a page, the database manager uses the following protocol to minimize the I/O required by the transaction and ensure recoverability. 1. The page to be updated is pinned and latched with an exclusive lock. A log record is written to the log buffer describing how to redo and undo the change. As part of this action, a log sequence number (LSN) is obtained and is stored in the page header of the page being updated. 2. The change is made to the page. 3. The page is unlatched and unfixed. The page is considered to be "dirty" because changes to the page have not been written out to disk. 4. The log buffer is updated. Both the data in the log buffer and the "dirty" data page are forced to disk. For better performance, these I/Os are delayed until a convenient point, such as during a lull in the system load, or until necessary to ensure recoverability, or to limit recovery time. Specifically, a "dirty" page is forced to disk at the following times: - When another agent chooses it as a victim. - When a page cleaner acts on the page as the result of: - Another agent choosing it as a victim. - The chngpgs_thresh database configuration parameter percentage value is exceeded. When this value is exceeded, asynchronous page cleaners wake up and write changed pages to disk. - The softmax database configuration parameter percentage value is exceeded. Once exceeded, asynchronous page cleaners wake up and write changed pages to disk. - When the page was updated as part of a table which has the NOT LOGGED INITIALLY clause invoked and a COMMIT statement is issued. When the COMMIT statement is executed, all changed pages are flushed to disk to ensure recoverability." Best regards, Alexey sending to informix-list

See below... "Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message news:caj34l$lpd$1@news.xmission.com... > > > > > -----Original Message----- > > From: Madison Pruet [mailto:mpruet@comcast.net] > > > > What is described by the 'victim' in the Admin Guide is the same as a > > forground write in IDS. This does not mean that every dirty page must > > be flushed to disk before it can be used again. It means that if the > > buffer pool is so tight that there are no clean buffers available, > > then a page will be forced to disk, just as with the IDS forground > > write. > > > > Normally the dirty buffers will be flushed to disk by the page > > cleaners when the parameter of chngpgs_thresh is reached, or if the > > distance between the oldest dirty page and the current log position > > reaches a set percentage as defined by the 'softmax' parameter. > > Therefor, recovery time is based on a set percentage of the total log > > file size. If you want to minimize the recovery time, you can set > > 'softmax' to 1 and thus ensure that the recovery > > process will only need to process 1% of the logs. > > > > > > t > > > > Madison, > > I can just give a bigger fragment of DB2 documentation. > There is a chance that my understanding of that fragment is wrong (English > is not my native language). > May be, this fragment is written incorrectly > > As for myself, I can't understand the necessity of that additional dirty > page flush. Unfortunately, I don't have any access to any additional > information on DB2 architecture except the official manual. > > ........................ > Administration Guide: Performance > Chapter 2. Architecture and processes -> > -> Processes -> Update process > > "When an agent updates a page, the database manager uses the following > protocol to minimize the I/O required by the transaction and ensure > recoverability. 1. The page to be updated is pinned and latched with an > exclusive lock. A log record is written to the log buffer describing how to > redo and undo the change. As part of this action, a log sequence number > (LSN) is obtained and is stored in the page header of the page being > updated. 2. The change is made to the page. 3. The page is unlatched and > unfixed. The page is considered to be "dirty" because changes to the page > have not been written out to disk. 4. The log buffer is updated. Both the > data in the log buffer and the "dirty" data page are forced to disk. > > For better performance, these I/Os are delayed until a convenient point, > such as during a lull in the system load, or until necessary to ensure > recoverability, or to limit recovery time. Specifically, a "dirty" page is > forced to disk at the following times: > - When another agent chooses it as a victim. Same as a forground write. > - When a page cleaner acts on the page as the result of: > - Another agent choosing it as a victim. Same as a forground write > - The chngpgs_thresh database configuration parameter percentage value is > exceeded. When this value is exceeded, asynchronous page cleaners > wake up and write changed pages to disk. In essence, the same as LRU_MIN/LRU_MAX > - The softmax database configuration parameter percentage value is > exceeded. Once exceeded, asynchronous page cleaners wake up and > write changed pages to disk. In essence, flush the page when not flushing it would cause recovery to have to start too far back in the logs. > - When the page was updated as part of a table which has the NOT LOGGED > INITIALLY clause invoked and a COMMIT statement is issued. When the COMMIT > statement is executed, all changed pages are flushed to disk to ensure > recoverability." Well --- that makes sense. If you have an unlogged database, how else can you guarentee consistancy? > > > Best regards, > Alexey > sending to informix-list