Rollforwarddb with -v and #x flags

Steve Grantham (Remove XX to respond) wrote in message
<36f32069.757553@news.mindspring.com>...
>Jim,
>
>We have a 24 gig database on an alpha 8460 server, using a tz887 dlt
>tape drive. It takes 4 hours to checkpoint (using tar) and about 5
>hours to untar the checkpoint if doing a rollforwarddb. Journals
>ranging from 20-50 gig take about 10-20 mins apiece to unroll. I
>noticed you specified the -v option. Our former dba had a rule about
>that: DON'T. We filled up a 2 gig drive once with status messages from
>a rollforwarddb we were doing and spent the last 4 hours of the
>rollforward trying to purge the errlog.log before it was overrun.
>
>I don't know if the rollforwarddb would slow down in order to write
>status messages to a heavily fragged disk drive, but it's a thought.
>
>Mike is probably closer to the truth in examining how tar and the
>uncompress are using your system resources. Having only one i/o path
>for the drives could be an issue as well, in that case tar would be
>reading and writing blocks through the same pipeline.
>
>Given all that, it is still difficult to understand a 72 hour
>(projected) rollforwarddb on 20gig.
>
>Unfortunately, none of this offers a solution to your present dilemma,
>and for that I can only wish you the best.
>
>Steve Grantham
>Ingres/Unix/MST3k (not in that order)




I agree totally with your "don't use the -v " rule.  I see it as a last
resort when you need to accompany a problem rollforward, and only if the
quantity of journals being recovered is small.

I have had a similar experience with this option...  once I had to
rollforward a 4Gb table (just one table -- using the -table option).  The
rollforward took over 8 hours with the -v option (I don't recall how many
journal files were applied), but in the end the rollforward failed because
the operator had inserted the wrong checkpoint tape.  By that time I was
monitoring closely the output of my tee to a log file, because the
filesystem where it was dumped was nearly full.  When I ran the rollforward
again without -v, it took less than two hours, even applying all of the
journals.

Another time I ran an even smaller rollforward from over telnet through a
19.2 K baud dial-up connection, and dumped the output to my terminal.  Not
Smart!!!   It ran all night, as I sat watching the stupid log scroll across
my terminal.  About 6AM (over four or five hours later) I logged another
session and saw that the rollforward had actually finished hours earlier!
It took that long just to transmit the output to me.  The -v option is
extremely VERBOSE!

Regards,

James Gramling
Rio de Janeiro, Brazil
jamesg@NOSPAMnovanet.com.br  (remove NOSPAM to return mail).



>    I've just noticed that the rollforwarddb will not recover a hash table
>    where the transaction being applied has any work to do on an overflow
>    page. The rollforwarddb will not crash it simply hangs! There are no
>    messages in the log file nor does running with '-v' option shed any light

Make sure you properly copy the journal and dump directories.  Then, 
if that doesn't work use the -v and '#x' flags on the command line.
This will give more detailed error messages and the '#x' flag will 
produce a .dbg file in your current directory (make sure your current
directory is writeable).


Chip Nickolett           ChipN@Comp-Soln.com
Comprehensive Consulting Solutions, Inc.   (www.Comp-Soln.com)
Phone:  262-544-9954     Fax:  262-544-1236
Ingres Q & A
Back to William's Home Page
Email William