RE: Tape capacity planning?
I would like to add my thoughts to this issue.
Isn't it true that ontape and onbar backup all pages
that have ever been allocated? I know that used to be
the case. If that is so then the calculations using
the amount of free space in a dbspace are quite
possibly going to be less than the space required by
the number of tables/indexes that have been deleted
and the space not yet re-used. Ok that doesn't seem
to be the case in this example but I wouldn't want
other users to work on the same basis.
regards
Malcolm
--- Martin Fuerderer <MARTINFU@de.ibm.com> wrote:
> 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
> > >
>
=== message truncated ===
sending to informix-list