RE: thank you IBM

Madison, I have suspicion, that this particular fragment of the UDB documentation came from DB2 for z/OS (mainframe) documentation. DB2 on mainfraims support shared-disk (like Oracle Parallel Server) architecture. With shred-disk approach, it is necessary to synchronize modified page with the disk before 'agent' running on another machine can make another modification of the page. Alexey -----Original Message----- From: Madison Pruet [mailto:mpruet@comcast.net] "Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message news:cakm7m$sjd$1@news.xmission.com... > > Madison, > > Thank You very much for the clarification. > > My understanding was that 'choosing the page as a victim' > is the same as 'choosing the page for modification', > and that 'page is forced to disk' means that the page MUST > be flushed before the further modification Not quite, the victim page is a forground write. > > Even if the page flushing can be delayed, the affect of > forcing the page to disk should be similar to setting > LRU_MIN/LRU_MAX to 0/0 with Informix (this setting dramatically > increases write activity) This would be the case only if chngpgs_thresh is set to zero. > > If this relates only to cases when buffer pool if full > of modified pages (similar to Informix FG writes) - > then it's OK. But still not clear from the Manual. > > I think this chapter of DB2 documentation need to be > written more clearly Yep - same with Oracle documentation, Microsoft documentation, and IDS documentation. ;-) > > > ------------------------------------------ > Alexey Sonkin > > > > -----Original Message----- > > From: Madison Pruet [mailto:mpruet@comcast.net] > > > > 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 > > > > sending to informix-list sending to informix-list