RE: Tape capacity planning?
Hi,
Yes, it is the number of pages.
I don't know what exactly the dbavail script from Bob Johnston
does. But note that the difference between his script's result and
the result from "my" queries is just 5 GB. Now 5 GB look like a
lot of space, but in relation to the total (say 336 GB), this is just
about 1.5 %. And I think that kind of deviation is pretty good by
most standards ... :)
It may be unlucky for you as you are now "hovering" around the
number where things will no longer fit onto one tape and I understand
that you would like to get a better, more accurate estimate. But I guess
it will be difficult to be much more accurate. Generally I think it is
better
to have the estimate a bit higher and the actual value a bit lower rather
than the other way round. Also, there are a couple of tape-blocks
(TAPEBLKSIZE) written to tape to mark begin and end, etc. So this is
additional (small) overhead ...
The compression efficiency that they use to calculate the tape
capacity for compressed data also is a heuristic / average estimate
as this depends on your data, too. Compression of your data may
be much better than 2:1. But other data may fare much worse (in effect
even increase instead of shrink). And I guess that this is much more
varying in your case than the 1.5% differences in the used-pages counting.
Therefore you would have to do an exact measurement as to how much
data was actually written to tape. But even then, some mere updates in the
database (that do not even change the amount of data) can influence the
compression rate so that things "suddenly" don't fit anymore.
If your database is slowly growing anyway, I suggest you get ready to
handle
more data rather sooner than later.
Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management
owner-informix-list@iiug.org wrote on 23.03.2005 20:00:43:
> Martin,
>
> If I use your script below for all dbspaces I get a value that is
greater
> than the total amount allocated in the instance. 341 gig
>
> Right now I'm at 336 gig used with in my instance (I use a script called
> dbavail written by Bob Johnston). I'm backing up to 320 gig tapes.
> I'm trying to figure out how long I have on these tapes before getting
new
> larger drives or going to a 2 tape backup.
>
> If I sum ti_npused from systabinfo I get 313 gig. I'm thinking this
could
> be a fairly good figure that is going to tape or, according to your
script,
> the SDLT 320 tape (2:1 compression) is holding 341 gig .
>
> Oh yeah, my TAPESIZE parm is set to 320 gig so I know I can't be putting
> more that 320 to the tape.
>
> Martin Fuerderer
> <MARTINFU@de.ibm.
> com> To
> "Dirk Moolman"
> 03/23/2005 01:04 <DirkM@mxgroup.co.za>
> PM cc
> Darren_Jacobs@carmax.com,
> informix-list@iiug.org,
> owner-informix-list@iiug.org
> Subject
> RE: Tape capacity planning?
>
> Hi,
>
> this is what we use to get it for a single dbspace:
>
> EXEC SQL select (sum(chksize - nfree)) into :spages
> from sysdbspaces, syschunks where
> sysdbspaces.dbsnum = syschunks.dbsnum and
> name = :sname;
>
> against sysmaster database.
>
> There are a couple of things to keep in mind:
>
> - TEMP dbspaces are not backed up/archived, so you
> don't want to count their size/usage.
> - for a whole system backup (onbar) and all ontape
> archives (by default they are "whole system"), those log
> records are backed up, that are necessary to roll back
> open transactions in case no logs are restored after physical
> restore (i.e. no log rollforward).
> Depending on amount/length of open transactions at time
> of archive (i.e. archive checkpoint) the size of this log data
> will vary.
> BLOBSpace BLOBs belong to this log record data, so if BLOBs
> are involved that can increase the numbers ...
> - tape device compression:
> always an interesting theme which I tried to explain before ...
> In short: already compressed data (think JPEG in BLOBs) often
> increases when compressed again (no matter whether compression
> is done by hard- or software).
> So be cautious with the claims on the tapes/devices regarding
> compression efficiency.
>
> Regards,
> Martin
> --
> Martin Fuerderer
> IBM Informix Development Munich, Germany
> Information Management
>
> owner-informix-list@iiug.org wrote on 23.03.2005 16:05:25:
>
> > Yes, it is a rough estimate - will have to go back to my queries if
you
> > want more precise info ....
> >
> >
> >
> > -----Original Message-----
> > From: Darren_Jacobs@carmax.com [mailto:Darren_Jacobs@carmax.com]
> > Sent: 23 March 2005 04:28 PM
> > To: Dirk Moolman
> > Cc: informix-list@iiug.org
> > Subject: RE: Tape capacity planning?
> >
> > Dirk,
> >
> > Thanks for the response. However, the sum below is more than the
total
> > allocated in my database. I did perform a sum on systabinfo on
> > ti_pagesused and ti_npused and ti_npdata. Does anyone know if this
> > would
> > reflect the amount being backed up?
> >
> > BTW, 9.40 FC2 on HPUX 11
> >
> > Thanks
> >
> > "Dirk Moolman"
> > <DirkM@mxgroup.co
> > .za>
> > To
> > <Darren_Jacobs@carmax.com>,
> >
> > 03/23/2005 09:10 <informix-list@iiug.org>
> >
> > AM
> > cc
> >
> > Subject
> > RE: Tape capacity planning?
> >
> > On my version of Informix, it is the "used space" in the database
chunks
> > that gets backed up(would guess that it is the same in the new
versions
> > as well)
> >
> > I run a query that calculates this for me, on Informix:
> >
> > database sysmaster;> > select sum(chksize - nfree) * 2048 (2048 for the 2k page size in my
> > opsys)
> > from syschunks
> >
> > -----Original Message-----
> > From: owner-informix-list@iiug.org
[mailto:owner-informix-list@iiug.org]
> > On Behalf Of Darren_Jacobs@carmax.com
> > Sent: 23 March 2005 03:12 PM
> > To: informix-list@iiug.org; ids@iiug.org
> > Subject: Tape capacity planning?
> >
> > Greetings,
> >
> > By chance, does any one have a script that will calculate the amount
of
> > space a backup will use on a tape?
> >
> > Thanks
> >
> > sending to informix-list
> > sending to informix-list
> sending to informix-list
sending to informix-list