Rollforward of Large Checkpoints

Subject: Re: rollforwarddb on checkpoint > 2GB
> >> > 
> >> > We are runing 6.4/06 on Solaris 2.7
> >> > We are attempting to restore a test database from a checkpoint
> >> > but the errlog.log file says :
> >> > 
> >> > E_DM1318_RFP_NO_CKP_FILE The Checkpoint file c0005001.ckp for database
> >> > basispre8 t location:/opt/dbprd2/ingres/ckp/default/basispre8 does not 
> >exist.
> >> > stat() failed with UNIX error 79 (Value too large for defined data type)
> >> > 
> >> > The checkpoint file we are attempting to restore from is 2.5GB.
> >> > (and yes, it does exist)
> >> > 
> >> > When I attempt to restore the data using the commands that are in our
> >> > customized cktmpl.def file we have no problems. i.e. 
> >> > gzip -cd /opt/dbprd2/ingres/ckp/default/basispre8/c0005001.ckp | tar xvf -
> >> > works fine.
> >> > 
> >> > A truss of the rollforwardb produces :
> >> > stat("/opt/dbprd2/ingres/ckp/default/basispre8/c0005001.ckp", 
> >0xFFBEAB74) Err#79 EOVERFLOW
> >> > 
> >> > Has anyone run into this problem.
> >> > I am prepared to spread the database over multiple locations so that
> >> > none of the checkpoint files are greater than 2GB, but I want to 
> >> > explore what other options are available.
> >> > 
> >> > TIA
> >> > 
> >> > -- 
> >> > Michael McGarrigle        Michael.McGarrigle@BarwonWater.Vic.Gov.Au
> >> > Information Systems      Barwon Water
> >> > 61-67 Ryrie St Geelong   Phone: +61 352 262326
> >> > Victoria 3220 Australia  Fax:   +61 352 218236
> >> > 
From: Martin Bowes 
Subject: Re: rollforwarddb on checkpoint > 2GB

Hi Guys,

rollforwarddb probably needs to stat as part of the file globbing implied by
the %A construct. The stat command may itself not be able to handle the >2G
files. A C or PERL program could prove this for you.

Martin Bowes


At 12:54 PM -0500 8/16/99, Michael Leo wrote:
>Disagreeing with Karl is always a risky thing ... but here goes.
>
>The checkpoint file is what is greater than 2 gig, not necessarily
>the files inside it.  Since ckpdb managed to make it, rollforwarddb
>should be able to unravel it.
>
>Ingres itself doesn't touch the checkpoint files.  It is all done
>via the commands defined in cktmpl.def.  I would suspect this file
>has been modified so it can create checkpoints > 2.5GB, but the 
>corresponding recovery lines have not been properly modified.

Mike's answer was certainly better than mine.  Yes, one would think that
since ckpdb could make the file, rollforwarddb should be able to read it;
and if it can't, the cktmpl.def file was not properly set up.

Basically, if Ingres has to see a file offset larger than 2 gig, it will
blow up.  If it doesn't, it won't.  This is how (for instance) one
creates a COPY INTO file larger than 2 gig;  just feed the data through
a fifo into "cat largefile".  (Assuming of course that the filesystem
is set up for large files.)  Since Ingres sees the fifo as just a sink,
no large file problems ensue. 


Solaris 2.6 can understand files larger than 2 gig, but Ingres doesn't.
You will have to wait for Ingres II version 2.5 for that.
In the meantime, the safest option is as you suggested: define some extra
locations so that no one checkpoint file is over the 2 gig limit. 

Karl R. Schendel, Jr.
K/B Computer Associates   schendel@kbcomputer.com
Ingres and Unix Expertise

Past President, North American Ingres Users Association
past_president@naiua.org




From: Ken Richards 
Subject: Re: rollforwarddb on checkpoint > 2GB

Hi,
        We investigated this limitation some months back and the only
port of Ingres that coped with a rollforward of a single checkpoint file
>2Gb was DEC UNIX (64bit... no surprises there). You have to remember
that even the latest versions of 6.4 don't take any real advantage of
new O/S capabilities. In fact my understanding is that most ports of
Ingres will not be able to address this particular issue until INGRES
2.5!

We had a database of > 20Gb and with this limitation in place needed to
come up with a workaround. I wasn't prepared to spread the database onto
endless locations with the associated admin overhead and we already had
the performance aspects covered. Unfortunately even gzip couldn't do the
business on our 20Gb database. The solution was a "stealth" checkpoint
template file. 

This is an extract from the template file
...
WSD:    cd %D; echo STEALTH CHECKPOINT > %A ; date >> %A ; ls | cpio -
oBc > `echo %A | sed 's/default/stealth/'`/

WRD:    cd %D; cpio -iBcdm < `echo %A |sed 's/default/stealth/'`
...

You don't have to use cpio (unless you're stuck with HP10.20 tar and
it's associated performance characteristics). 

The idea is that it Ingres "thinks" it's reading a 48 byte checkpoint
from the ..ingres/ckp/default/mydb directory whereas it is in fact
pulling in a 20Gb checkpoint file from ../ingres/ckp/stealth/mydb.

Apart from actually having to create the directories initially for any
of the databases (a small price to pay). This is all you need to
overcome the stat() problem. My understanding is that it is the 64 bit
return from the O/S to this stat() call that actually causes the
problem. The real bummer is the fact that it is quite happy to create
the checkpoint in the first place!

hope this helps,
cheers,
Ken
Ingres Q & A
Back to William's Home Page
Email William