Excellent, thank you Keith. I didn't think of that. The previous upgrade I did, was not an in-place upgrade, that's why I needed so much more space.

Yes, if I do this one in-place, I might just do it without hassles. I must just remember in future, if I move my data, that they will get detached.


Thanks Keith


-----Original Message-----
From: Simmons, Keith [mailto:keith.simmons@office2office.biz]
Sent: Wednesday, October 08, 2003 10:31 AM
To: Dirk Moolman
Subject: RE: Upgrading from 7.31 to 9.3 - storage requirements

Dirk

1. The indexes are detached by default but this can be overridden using the
environmental variable DEFAULT_ATTACH=1

2. The actual upgrade process will not detach your existing indexes so you
will not require additional space at time of upgrade.

3. Even though the indexes are created detached you should not require
significantly more storage, the space will just be allocated to separate
index extents rather than being merged with the data. You may require a bit
more space to handle larger system tables, but again this will be relatively
small.

Keith

-> -----Original Message-----
-> From: Dirk Moolman [mailtoirkM@mxgroup.co.za]
-> Sent: Tuesday, October 07, 2003 9:36 AM
-> To: informix-list@iiug.org
-> Subject: FW: Upgrading from 7.31 to 9.3 - storage requirements
->
->
-> Anyone ?
->
-> -----Original Message-----
-> From: Dirk Moolman
-> Sent: Wednesday, October 04, 2003 10:38 AM
-> To: informix-list@iiug.org
-> Subject: Upgrading from 7.31 to 9.3 - storage requirements
->
-> I know that the indexes are detached in version 9, so
-> upgrading from 7 to 9 will require more storage.
->
-> Question: Does anyone have a query I can use that will
-> calculate my storage requirements for the upgrade ?
->
->
->
->
-> sending to informix-list
->
-> sending to informix-list
->

************************************************** ********************************
This message is sent in strict confidence for the addressee only. It may
contain legally privileged information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised recipients are requested
to preserve this confidentiality and to advise the sender immediately of any
error in transmission.
This footnote also confirms that this email message has been swept for the
presence of computer viruses, however we cannot guarantee that this message
is free from such problems.
************************************************** ********************************

sending to informix-list

First of, when we went through this process we did dbexports and
dbimports to be able to come over clean. The time for an upgrade in
place depends upon the number of databases and tables and we had lots.

The algorithm approach can be a little tricky. We had a lot of small
tables where data and the five (yes, five) indexes all fit within the
initial extent of 32K.

If you go with the default, detached, you now end up with six
"tables", each at 32K (one for the data, five for the indexes.) Are
those 32k extents close to empty - you bet - but the space is used.

On the flip side, we had large tables with only one or two indexes so
there is very little net effect

Using the "space is cheap and getting cheaper" philosophy and not
wishing to perform calculations against each of 400 tables (times 150
databases) we swagged it at 50% and justified it with room for growth.

Fred Prose
Arizona Supreme Court