Re: any way to know the progress of a level1 (or level0) ontape save?

"Neil Truby" <neil.truby@ardenta.com> wrote in message news:<2qss9nF13kr5eU1@uni-berlin.de>... > "sumGirl" <emebohw@netscape.net> wrote in message > news:a5e13cff.0409151450.245785df@posting.google.com... > > Just wondering if anyone knows of a way to check the progress of an ontape > backup? > > If you zero out the stats with onstat -z then do an onstat -D you can see > which chunk it's on. You'll be able to tell then how far through that > dbspace it is. Telling the order of the dbspaces is more tricky. > > If you don't zero out the stats onstat -u will show you how many reads the > archive session has done. Since the total number of pages it will read is > (allocated - free) pages for all your chunks you should be able to tell > from here how far through it is too. Does a level 1 have to go through every page in every chunk or does it have a modified page list to work with? I.E. Does it look at the logs to determine which pages were modified since the last level 0? I guess because logs can roll to tape it can't look there for everything. But is there a list of pages that have been modified or does it have to look at the timestamp on every page to determine if this page should go into the level 1? It would be nice if there were some mechanism for the server to keep track of modified pages then a level 1 could run much faster. a Bit map of a 1 gig database would take 64k or 32 pages. The point of this is if it just looks at a list you might not be able to tell by looking at onstat -D where the backup is. Also, since other sessions are reading pages you are really estimating where the backup is by the large number of reads happening in a particular chunk. Of course I always use "onstat -D" to tell where a restore is because you don't have the same issues of other jobs writing data since only the restore can be working.

"Curtis Crowson" <curtis@crowson1.com> wrote in message news:eb5a5e2b.0409210750.3bb11d69@posting.google.com... > "Neil Truby" <neil.truby@ardenta.com> wrote in message news:<2qss9nF13kr5eU1@uni-berlin.de>... > > "sumGirl" <emebohw@netscape.net> wrote in message > > news:a5e13cff.0409151450.245785df@posting.google.com... > > > Just wondering if anyone knows of a way to check the progress of an ontape> > backup? > > > > If you zero out the stats with onstat -z then do an onstat -D you can see > > which chunk it's on. You'll be able to tell then how far through that > > dbspace it is. Telling the order of the dbspaces is more tricky. > > > > If you don't zero out the stats onstat -u will show you how many reads the > > archive session has done. Since the total number of pages it will read is > > (allocated - free) pages for all your chunks you should be able to tell > > from here how far through it is too. > > > Does a level 1 have to go through every page in every chunk or does it > have a modified page list to work with? The former > I.E. Does it look at the logs > to determine which pages were modified since the last level 0? The logs would necessarily be online. > It would be nice if there were some mechanism for the server to keep > track of modified pages then a level 1 could run much faster. a Bit > map of a 1 gig database would take 64k or 32 pages. Well, yes, but why are you overly concerned about the duration of a backup? It's the restore you want to worry about, and of course the duration of a restore is unaffected by the method by which the pages to be backed up in a level 1 were identified. > The point of this is if it just looks at a list you might not be able > to tell by looking at onstat -D where the backup is. Well, you can! > Also, since other > sessions are reading pages you are really estimating where the backup > is by the large number of reads happening in a particular chunk. Of > course I always use "onstat -D" to tell where a restore is because you > don't have the same issues of other jobs writing data since only the > restore can be working. It's unlikely that any other processes will be reading a single chunk sequentially at the rate of a backup, so it's pretty easy to identify.

On Tue, 21 Sep 2004 11:50:34 -0400, Curtis Crowson wrote: <SNIP> > Does a level 1 have to go through every page in every chunk or does it have > a modified page list to work with? I.E. Does it look at the logs to > determine which pages were modified since the last level 0? I guess because > logs can roll to tape it can't look there for everything. But is there a > list of pages that have been modified or does it have to look at the > timestamp on every page to determine if this page should go into the level > 1? Prior to 7.30 IDS read the entire dbspace during the archive which sometimes caused the tape to stop frequently making the archives rather slow. Since IDS 7.3x (9.2x) IDS starts each archive be blasting through the dbspaces and creating a bitmap of pages modified since the last archive in a temp table. The archive can then run at full speed keeping up with the tape by only reading older pages. > It would be nice if there were some mechanism for the server to keep track > of modified pages then a level 1 could run much faster. a Bit map of a 1 gig > database would take 64k or 32 pages. The only on disk bitmap shows the fullness of the pages not their archive status. A bitmap is used, but it's generated at the start of the archive. > The point of this is if it just looks at a list you might not be able to > tell by looking at onstat -D where the backup is. Also, since other sessions > are reading pages you are really estimating where the backup is by the large > number of reads happening in a particular chunk. Of course I always use > "onstat -D" to tell where a restore is because you don't have the same > issues of other jobs writing data since only the restore can be working. Art S. Kagel