No special server setup is required.

    You can consider this topic an extension of the small footprint topic. Contrarily to other products, Interbase installation is straightforward. In UNIX, it must be copied on some directory and a system script must be changed to start it. In Windows, after the setup program is finished, IB is ready to run and on NT it can run as a service. In Netware, the installation doesn't differ from installing and loading another NLM in the server.

IB does not require a separate disk partition, like some other vendor's products. IB doesn't require a fixed section of the disk to mount a virtual file system on top of the one that the operating system provides. IB doesn't require to define a "device" that's a huge operating system file with all databases inside. The "device" seems to be a Sybase idea that appeared on MS-SqlServer because the first version was done by Sybase for Microsoft. Until Sql v6.5, this idea was kept but it was inflexible, because the db couldn't grow automatically but the DBA needed to define its maximum size and this size was reserved in the operating system. Also, there was the overhead of the database's file system on top of the operating system's file system. It seems later Bill Gates learned from Interbase, because Sql v7.0 relies on the operating system and each database is a file in the engine's database directory. However, there's only one directory for all databases.

IB doesn't require a special directory for all databases. Indeed, there's no special default or suggested directory. Each database can use any directory on any partition and disk that's owned by the machine where IB runs. As you may guess, no database engine uses a database through a share but always the database must be accessed directly. Because IB is a real C/S database, no user needs access to the IB directory nor to the databases' directories. In fact, for security reasons, only IB, administrators and the operating system must have rights over these directories. Each client make a request to IB to connect to some database in behalf of the user and return results.

IB doesn't own databases in the sense it doesn't need to define a root directory where each database can use its own subdirectory. In fact, if a database is moved to another partition inside the server, IB settings don't have to be modified; only the clients should specify the current full path of the database, always from the root of the owning machine and never through a share name the user has opened on the server. IB was planned as an embedded database and for this reason, it provides maximum flexibility.

In Interbase, each database file has a maximum of 2 GB on FAT, 4 GB on NTFS and other values according to the operating system flavor and the engine itself in UNIX. However, this doesn't mean this is the maximum size of a database. In fact, a database can span multiple files as long as these files are all in the same node. By "node" Interbase understands one machine, so if you have a SCSI subsystem with 10 SCSI disks each one of 20 GB and Linux, you can have a database in 50 files to use the full 200 GB. There's no need to know in advance how much space you need: you can add more files as needed if you get exclusive access to the database for a moment by means of turning the database in single user mode (referered as shut down), adding secondary files and tuning the database in multi user mode again (referred as restart).

Conversely, if your database is little but you want to preserve your data against HW failure, you can set a shadow. This shadow is a duplicate, in-sync copy of a database. IB takes care of writing to multiple shadows' files at the same time. However, if you have a SCSI subsystem, it's probable you have a RAID subsystem. In that case, redundancy by means of HW is much faster than redundancy provided by the operating system or the database engine.

This page was last updated on 2000-05-26 04:28:46