[comp.databases] large informix databases

yerneni@pdn.UUCP (Prasad Yerneni) (09/30/88)

Hello,
I would like to know if anyone has tackled the problem of an Informix2.3 
database, on a SYSV machine, growing beyond the volume size of the partition 
that it is resident on.

The informix manuals don't tell me what happens in such a case, and since 
Unix does not allow a file to be split between volumes is there any ingenious 
method that someone has tried to overcome this problem? 

We currently use Informix only as a database manager, with our own user 
interface to it.  This suggests that the database could be split into two 
or more databases resident on different volumes. However, any manipulation 
of data using inter-relationships between those databases would have to be 
taken care by user written software.  Has anyone done this, and what should 
I watch out for.

Or is there a better way? 

NOTE: I know that Unify can share data between volumes 
but given its inflexibility with respect to any schema change (takes hours to
just change the name of an attribute!!), and other considerations, 
it looks like we are stuck with Informix for the moment.

Prasad.

billp@kitchen.ctt.bellcore.com (Bill Puig) (09/30/88)

 In article <4477@pdn.UUCP> yerneni@pdn.UUCP (Prasad Yerneni) writes:
 >
 >Hello,
 >I would like to know if anyone has tackled the problem of an Informix2.3 
 >database, on a SYSV machine, growing beyond the volume size of the partition 
 >that it is resident on.
 >
 >The informix manuals don't tell me what happens in such a case, and since 
 >Unix does not allow a file to be split between volumes is there any ingenious 
 >method that someone has tried to overcome this problem? 

An INFORMIX-SQL database can have tables within the database
residing on different file systems, so long as each individual table
can fit on its assigned file system.  I don't have a manual handy, but
I think options to the "CREATE TABLE" SQL statement are provided to let
you do this if needed.

The INFORMIX-TURBO backend of the product (optionally available $$$)
uses raw disk space instead of the UNIX file system, and is able to
split databases across devices automatically.  The major drawback with
this product is that, at least in its current implementation, a raw
disk partition should not be taken away from TURBO once allocated to it.
Options on the TURBO admin monitor program provided with the product
don't provide much statistical info on how data is distributed across the
devices available to TURBO.  A menu option is available thru the program
from disassociating disk "chunks" from TURBO, but attempts to use this
option result in a message that reads "Option not available".  Hopefully
this situation will be corrected in future editions of the product.
(Are you listening, guys?)

Hope this helps --

Bill

aland@infmx.UUCP (Dr. Scump) (10/06/88)

In article <4477@pdn.UUCP>, yerneni@pdn.UUCP (Prasad Yerneni) writes:
> 
> Hello,
> I would like to know if anyone has tackled the problem of an Informix2.3 
> database, on a SYSV machine, growing beyond the volume size of the partition 
> that it is resident on.
> 
> The informix manuals don't tell me what happens in such a case, and since 
> Unix does not allow a file to be split between volumes is there any ingenious 
> method that someone has tried to overcome this problem? 

By using the IN <pathname> clause of the CREATE TABLE statement, you
can create any given table in another directory (which may reside on
another file system).  For example:

   create table foo (bar char(500)) in "/usr/othrdisk/foo";
   create table pingpong (doric char(500)) in "/usr2/wherever/pingpong";

The resulting file names for table foo are: 
     /usr/othrdisk/foo.dat
     /usr/othrdisk/foo.idx
     /usr/othrdisk/foo.lok    (if not a system call locking port)

The resulting file names for table pingpong are: 
     /usr2/wherever/pingpong.dat
     /usr2/wherever/pingpong.idx
     /usr2/wherever/pingpong.lok   (if not a system call locking port)

In the Turbo backend, tables can span chunks, so no special placement
commands are necessary.

> 
> Prasad.


-- 
 Alan S. Denney  |  Informix Software, Inc.  |  {pyramid|uunet}!infmx!aland
 Disclaimer: These opinions are mine alone.  If I am caught or killed,
             the secretary will disavow any knowledge of my actions.
 Santos' 4th Law: "Anything worth fighting for is worth fighting *dirty* for"