This is the longest section and so it should be: after
careful planning the installation itself should be an easy task. You will use Ingres environment variables
to determine where to put further elements (besides the software itself)
of the Ingres installation.
These variables, unlike II_SYSTEM, are not shell variables
but rather parameters of Ingres stored in a file.
Some of them can be changed at any time after the installation, but altering
the value of others requires a whole re-install.
Later you will see which of them are of this "stable" nature. During installation, you can choose between setting these variables
manually or letting the installer set them to their default values
( option). In the following, we will take the relevant
Ingres environment variables one by one and see
what each of them is good for.
It may help if you put their planned values on paper.
You can find an Installation Worksheet in the
Getting Started Guide which you can print out and
use for this purpose. Ingres uses an installation-wide
transaction log file to record information on all changes made to any database.
This information broadly consists of: Before images of updated or deleted rows.
These are necessary for rolling back uncommitted transactions,
should it be required (undo). The changes made to database objects.
Recording them makes it possible to redo
committed transactions after a system crash if the new data
had not been written to the database prior the crash.
The transaction log resides in the
II_LOG_FILE/ingres/log directory,
where II_LOG_FILE is an Ingres
environment variable.
The name of the log file is ingres_log. creates a log file
of the minimum possible size, 16 Mb.
Such a log file may not be large enough even in a development system.
If you have free disk space and choose manual install (in which
case you can specify the size of the log), set it to something much
larger. Both the location and the size of the log file can be changed
at any time after installation.
The method of doing this is described in the
System Reference Guide. You also have to decide if you want dual logging (mirroring the
transaction log).
If the log gets corrupted for any reason, Ingres
stops and you have to recover your databases from backup.
Therefore, in a live system, it is almost compulsory either to have
some type of RAID protection of the log or to have
it mirrored by Ingres.
If you use dual logging, the copy of the log file can be found under
II_DUAL_LOG/ingres/log.
Its name is dual_log. In a development or test environment, mirroring the log is not
always necessary. There can be any number of databases in an
Ingres installation.
A database, on the other hand, consists of files of different types.
These are: Control file: it stores certain basic information about the
database.
You can see this information with the infodb
command after you have completed the installation. Data files: every system table, user table, and also every
index goes in a separate file. Checkpoint files: checkpoint is the term
Ingres uses for a database backup.
A backup can consist of more than file. Dump files: online backups are possible in
Ingres, that is, the database may be in
use while the backup program is running.
For this reason, the database may change while it is being checkpointed.
Ingres, so that it can restore the database
to the state it was in at the beginning of
the backup, saves the before images of those data blocks (pages)
that have changed during the backup process.
These pages are saved in the dump files. Journal files: from time to time,
Ingres writes the records of committed
transactions from the log file to
journal files (at least, this is the default behavior: journalling may
be set off at the database or table level).
The frequency of the journalling activity is a tunable function of the
amount of information that is written to the transaction log.
Journalling protects the installation against media failures:
if the disk containing the database crashes, you can restore
the last (just before the failure occurred) committed state
of the database using a backup (checkpoint) of the database
and the journals created after that checkpoint was taken.
If you lose the log disk, you can restore the last committed
state the database was in at the time the last journal file
was written. Work files: Ingres, if it needs to
sort large volumes of data, creates temporary files on disk.
The files constituting a database reside in different directories,
according to their types.
These directories are specified indirectly, by means of
Ingres locations. There are five location types: Data location: place for data files of a database.
A database can have more than one data location (adding data locations
to a database is called extending the database).
However, every database has a primary data
location.
The system tables and the control file always reside in the primary
location.
When creating a table, if you do not specify the location(s) to put
it in, it will be placed in the primary data location of the
database. Checkpoint location: by default, backups are created here.
Not necessarily, however: the ckpdb command
allows you to specify an arbitrary place for the backup, this way you
can checkpoint a database directly to tape as well. Dump location: for dump files. Journal location: this is where the journal files for a
database reside. Work location: Ingres creates
temporary sort files in this location.
Just like with data locations, a database may have more than one
work location.
If this is the case, Ingres, by default,
uses all of them for each sort operation.
Let us see how these locations work in practice.
Say we have a database, called test, with the
following locations: DATALOC1: data location -->
/opt CKPLOC: checkpoint location -->
/opt DMPLOC: dump location -->
/opt JRNLLOC: journal location -->
/opt WORKLOC1: work location -->
/opt
Every location of the test database points to the
/opt directory.
Elements of the database go in these directories: data files:
/opt/ingres/data/default/test
checkpoint files:
/opt/ingres/ckp/default/test
dump files:
/opt/ingres/dmp/default/test
journal files:
/opt/ingres/jnl/default/test
temporary files:
/opt/ingres/work/default/test
Let us suppose now, that we extend the database
to the following locations: DATALOC2: data location -->
/opt DATALOC3: data location -->
/disk2 WORKLOC2: work location -->
/disk2
The database is effectively extended to the following directories: DATALOC2 points to
/opt, just like DATALOC1.
Tables to be created in location DATALOC2 will go to
/opt/ingres/data/default/test,
the same directory where tables created in location DATALOC1
reside. As is apparent from the example, we could have created just one
location for DATALOC1, DATALOC2,
CKPLOC, DMPLOC, JRNLLOC,
and WORKLOC1. Summarizing the main points about locations: Every location points to the root of a directory tree. More than one location can point to the same directory. A location can be used for storing different types of files.
Databases can share locations.
You can see from the example why this is true: the name of the
database becomes part of the directory tree, hence files of
different databases never mix.
Every Ingres installation has a master
database called iidbdb.
Ingres stores information about users, locations
and user databases in this database.
iidbdb is created by the installer. You have to set the locations for iidbdb during
installation.
These locations are stored in the following
Ingres environment variables: II_DATABASE: data location II_CHECKPOINT: checkpoint location II_DUMP: dump location II_JOURNAL: journal location II_WORK: work location
These variables determine the default locations for every user database
as well, if you do not override them when creating those databases.
See Creating and Destroying Databases for more information. | Changing the value of II_DATABASE,
II_CHECKPOINT, II_DUMP,
II_JOURNAL, or II_WORK requires a complete
re-install of Ingres. |
Let us see these variables one by one. II_DATABASE determines the data location of
iidbdb.
Its default value is $II_SYSTEM (in case of a manual
install you can enter a different value for II_DATABASE,
while inevitably sets it to
$II_SYSTEM). The size of iidbdb after the installation is
somewhat more than 5 Mb.
It can only grow significantly if you create hundreds of
Ingres users, databases or locations. II_CHECKPOINT contains the value for the checkpoint
location of iidbdb.
By default, it is also set to $II_SYSTEM. The size of a checkpoint is just about the same as that of the database
itself (at least until you modify the template file of the checkpoint program:
it is possible, as you will see in Backup and Recovery).
The installer takes the first checkpoint of iidbdb. If you plan to place checkpoints of user databases under
II_CHECKPOINT then you have to provide for more space here.
A further factor that must be taken into account is how long you want
to keep backups.
When starting the checkpoint program, you can request the deletion of older
backups if you do not have too much free space. II_DUMP determines the dump location of the
iidbdb database.
By default, its value equals to that of II_CHECKPOINT. By the end of the installation process, II_DUMP will
contain a very small amount of data.
If you always create checkpoints off-line then you will not need much space
here. II_JOURNAL contains the value for the journal location
of the iidbdb database.
Its default value is the same as II_CHECKPOINT's. The first checkpoint, taken by the installer causes the first, small
journal file to appear here.
If you do not use different journal locations for user databases then the
necessary amount of free space under II_JOURNAL depends on
three factors: Whether you want Ingres to journal
at all.
If you take checkpoints of your databases regularly and do not mind
losing the changes you have made to them since the latest checkpoint,
you may switch off journalling.
Naturally, running a live system without journalling is usually not
acceptable. If journalling is switched on, then the growth rate of the
journal area is determined by the volume of changes made to the
databases.
Frequent, large updates require quite a bit of space under
II_JOURNAL. The third factor is, how long you wish to keep old journal files.
If, when taking a checkpoint, you instruct ckpdb
to delete the old checkpoints, then previous journal files will be
removed as well.
II_WORK determines the work location of the
iidbdb database.
It also defaults to II_CHECKPOINT. The problem of sizing the work location only arises if
II_WORK serves as a work location for user databases as well.
It is next to impossible to estimate the temporary disk space that will be
needed here; however, having the size of the largest table multiplied by three
should work as a starting point. Remember that a database can have more than one work location.
If the original location turns out too small, you can always extend the
database to further work locations. Besides the Ingres environment variables
that determine locations there are a couple more that you have to set
during installation (or have
set them to their default value). These are: II_INSTALLATION: a two-character code,
identifying the installation.
Every Ingres installation on a machine
must have its own, unique, installation code.
The default value for II_INSTALLATION is
II.
Once set, it cannot be changed. II_NUM_OF_PROCESSORS: number of processors in
the machine.
By default, it is 1.
If you set it to a higher value, Ingres
will use spin-locks when accessing the database cache.
If you do not know what spin-locks are, do not bother.
The point is to set II_NUM_OF_PROCESSORS to
2 if you have a multiprocessor machine.
Its value can be changed at any time later. II_CHARSET: this variable determines the code
set of all character data stored in all databases you will create in
the installation.
Its default value is ISO88591.
Perhaps it is not surprising that changing it to a different value
after installation may corrupt data stored in your existing databases.
Since the iidbdb database is created by the
installer program, you should not choose
if
ISO88591 does not suit you. II_TIMEZONE_NAME: name of the time zone, by
default NA-PACIFIC.
During manual install you can select its value from a list of valid
codes.
Ingres stores all date and time values
in GMT and adjusts them according to
II_TIMEZONE_NAME when communicating with the client.
Therefore, if you set II_TIMEZONE_NAME to a different
value, you will see all date-time values in the databases change.
For this reason, set this variable to its final value before creating
the first user database.
The (manual) installer prompts you for the value of two further
parameters which are not Ingres environment
variables: Expected number of concurrent users in the system: this is
32 by default.
Based on this number, the installer sets the value of a number of
other parameters, such as the size of the database cache.
These derived parameters can later be adjusted. SQL-92 compatible databases: by default,
Ingres databases differ from the
SQL-92 standard in some ways.
For example, object names not protected by single or double quotes
are converted to lower case rather than upper case.
You can find the other differences in the
SQL Reference Guide.
After you have made up your mind on the values of all installation
parameters, you know whether the default values for those variables that
cannot be changed after installation are acceptable to you.
If they are, you can choose . |
|