Re: Incremental Archive performance issue......

On Wed, 14 Apr 2004 23:13:29 GMT, Richard Kofler <richard.kofler@chello.at> wrote: >Neil Truby wrote: >> >> "Five Cats" wrote: >> > Neil Truby writes: >> > >"Five Cats" wrote: >> > >> Alexey Sonkin writes: >> > >> > >> > > >> > >> >For L1 archive, the backup speed is mostly limited by the >> > >> >disk array throughput: as I've already mentioned, Informix >> > >> >must read the entire database (like in L0 archive) >> > >> >> > >> Surely this depends on some extent as to how much of the database has >> > >> actually changed since the last L0 archive? >> > > >> > >And how, pray, is the Informix engine to know if a page has changed since >> > >the last level 0 archive???? >> > >> > The date stamp on the page. >> >> OK, but it has to read the page to know this. So Informix has to read all >> pages (at least, all those with at least some data in them), even for an >> incremental backup. > >exactly this! >The engine must read all pages (even those, which have no more >any data in them - as this might be the change), but Level 1 in >contrary to a full system backup (Level 0) in general terms brings >less >pages onto the XBSA pipe or onto the respective SW interface of >ontape, and therefore is rather less dependant on the tape speed >(or output speed to disk if using disk pools or ontaping to disk) >And YES - as J. Tong pointed out many times: ontape to disk never >was unsupported! :)))) > >dic_k Fortunately it is smart enough to not read *all* pages - it will consult the chunk free list and only examine those pages actually allocated to a tablespace or system object (i.e. logical log, etc.). Then again, it does this for all levels of archive. Timestamps need to be read for any archive level - even a full, as you have to deal with pages updated after the archive start time - so the "scan time" for archives of any level will be pretty much the same. It is the time spent writing to tape that will differ for a full vs. incremental. Another possible factor is the amount of update activity during the archive, as the physical log needs to be checked regularly to grab pages that have been updated after the archive start (though the amount of impact depends on the version you are using - older stuff, pre-7.2 I think, writes the pages from the plog to the backup during checkpoints; the later versions collect them in a temp table and add them to the archive at the end.) The tape hardware can also be a factor. Newer, high-speed tape drives see maximum i/o performance when a constant stream of data is supplied. Writing in smaller "chunks" sporadically results in much poorer performance on such drives. As an incremental archive is likely to produce the latter behavior, you can expect to see reduced performance on that end. Dave Kosenko