1257 lines
22 KiB
HTML
1257 lines
22 KiB
HTML
<HTML
|
|
><HEAD
|
|
><TITLE
|
|
>Preparing for the Installation</TITLE
|
|
><META
|
|
NAME="GENERATOR"
|
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.63
|
|
"><LINK
|
|
REL="HOME"
|
|
TITLE="Ingres II HOWTO"
|
|
HREF="index.html"><LINK
|
|
REL="PREVIOUS"
|
|
TITLE="System Requirements"
|
|
HREF="sysreq.html"><LINK
|
|
REL="NEXT"
|
|
TITLE="The Installation Process"
|
|
HREF="install.html"></HEAD
|
|
><BODY
|
|
CLASS="SECT1"
|
|
BGCOLOR="#FFFFFF"
|
|
TEXT="#000000"
|
|
LINK="#0000FF"
|
|
VLINK="#840084"
|
|
ALINK="#0000FF"
|
|
><DIV
|
|
CLASS="NAVHEADER"
|
|
><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TH
|
|
COLSPAN="3"
|
|
ALIGN="center"
|
|
>Ingres II HOWTO</TH
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="left"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="sysreq.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="80%"
|
|
ALIGN="center"
|
|
VALIGN="bottom"
|
|
></TD
|
|
><TD
|
|
WIDTH="10%"
|
|
ALIGN="right"
|
|
VALIGN="bottom"
|
|
><A
|
|
HREF="install.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"></DIV
|
|
><DIV
|
|
CLASS="SECT1"
|
|
><H1
|
|
CLASS="SECT1"
|
|
><A
|
|
NAME="PREP"
|
|
>4. Preparing for the Installation</A
|
|
></H1
|
|
><P
|
|
>This is the longest section and so it should be: after
|
|
careful planning the installation itself should be an easy task.</P
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="INGENV"
|
|
>4.1. Ingres Environment Variables</A
|
|
></H2
|
|
><P
|
|
>You will use <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> environment variables
|
|
to determine where to put further elements (besides the software itself)
|
|
of the <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> installation.
|
|
These variables, unlike <TT
|
|
CLASS="ENVAR"
|
|
>II_SYSTEM</TT
|
|
>, are not shell variables
|
|
but rather parameters of <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> 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.</P
|
|
><P
|
|
>During installation, you can choose between setting these variables
|
|
manually or letting the installer set them to their default values
|
|
(<SPAN
|
|
CLASS="GUIMENUITEM"
|
|
>Express Install</SPAN
|
|
> option).</P
|
|
><P
|
|
>In the following, we will take the relevant
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> 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
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>Getting Started Guide</I
|
|
> which you can print out and
|
|
use for this purpose.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="IILOG"
|
|
>4.2. II_LOG_FILE and II_DUAL_LOG</A
|
|
></H2
|
|
><P
|
|
><SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> uses an installation-wide
|
|
transaction log file to record information on all changes made to any database.
|
|
This information broadly consists of:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
><EM
|
|
>Before images</EM
|
|
> of updated or deleted rows.
|
|
These are necessary for rolling back uncommitted transactions,
|
|
should it be required <EM
|
|
>(undo)</EM
|
|
>.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The changes made to database objects.
|
|
Recording them makes it possible to <EM
|
|
>redo</EM
|
|
>
|
|
committed transactions after a system crash if the new data
|
|
had not been written to the database prior the crash.</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>The transaction log resides in the
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>II_LOG_FILE/ingres/log</TT
|
|
> directory,
|
|
where <TT
|
|
CLASS="ENVAR"
|
|
>II_LOG_FILE</TT
|
|
> is an <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>
|
|
environment variable.
|
|
The name of the log file is <TT
|
|
CLASS="FILENAME"
|
|
>ingres_log</TT
|
|
>.</P
|
|
><P
|
|
><SPAN
|
|
CLASS="GUIMENUITEM"
|
|
>Express Install</SPAN
|
|
> 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.</P
|
|
><P
|
|
>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
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>System Reference Guide</I
|
|
>.</P
|
|
><P
|
|
>You also have to decide if you want dual logging (mirroring the
|
|
transaction log).
|
|
If the log gets corrupted for any reason, <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>
|
|
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 <SPAN
|
|
CLASS="ACRONYM"
|
|
>RAID</SPAN
|
|
> protection of the log or to have
|
|
it mirrored by <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>.
|
|
If you use dual logging, the copy of the log file can be found under
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>II_DUAL_LOG/ingres/log</TT
|
|
>.
|
|
Its name is <TT
|
|
CLASS="FILENAME"
|
|
>dual_log</TT
|
|
>.</P
|
|
><P
|
|
>In a development or test environment, mirroring the log is not
|
|
always necessary.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="LOC"
|
|
>4.3. Database Locations</A
|
|
></H2
|
|
><P
|
|
>There can be any number of databases in an
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> installation.
|
|
A database, on the other hand, consists of files of different types.
|
|
These are:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Control file: it stores certain basic information about the
|
|
database.
|
|
You can see this information with the <B
|
|
CLASS="COMMAND"
|
|
>infodb</B
|
|
>
|
|
command after you have completed the installation.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Data files: every system table, user table, and also every
|
|
index goes in a separate file.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Checkpoint files: checkpoint is the term
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> uses for a database backup.
|
|
A backup can consist of more than file.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Dump files: online backups are possible in
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>, 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.
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>, so that it can restore the database
|
|
to the state it was in at the <EM
|
|
>beginning</EM
|
|
> 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.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Journal files: from time to time,
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> 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.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Work files: <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>, if it needs to
|
|
sort large volumes of data, creates temporary files on disk.</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>The files constituting a database reside in different directories,
|
|
according to their types.
|
|
These directories are specified indirectly, by means of
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> <EM
|
|
>locations</EM
|
|
>.</P
|
|
><P
|
|
>There are five location types:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>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 <EM
|
|
>extending</EM
|
|
> the database).
|
|
However, every database has a <EM
|
|
>primary</EM
|
|
> 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.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Checkpoint location: by default, backups are created here.
|
|
Not necessarily, however: the <B
|
|
CLASS="COMMAND"
|
|
>ckpdb</B
|
|
> command
|
|
allows you to specify an arbitrary place for the backup, this way you
|
|
can checkpoint a database directly to tape as well.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Dump location: for dump files.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Journal location: this is where the journal files for a
|
|
database reside.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>Work location: <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> 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, <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>, by default,
|
|
uses all of them for each sort operation.</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>Let us see how these locations work in practice.
|
|
Say we have a database, called <SPAN
|
|
CLASS="DATABASE"
|
|
>test</SPAN
|
|
>, with the
|
|
following locations:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>DATALOC1</TT
|
|
>: data location -->
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt</TT
|
|
></P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>CKPLOC</TT
|
|
>: checkpoint location -->
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt</TT
|
|
></P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>DMPLOC</TT
|
|
>: dump location -->
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt</TT
|
|
></P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>JRNLLOC</TT
|
|
>: journal location -->
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt</TT
|
|
></P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>WORKLOC1</TT
|
|
>: work location -->
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt</TT
|
|
></P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>Every location of the <SPAN
|
|
CLASS="DATABASE"
|
|
>test</SPAN
|
|
> database points to the
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt</TT
|
|
> directory.
|
|
Elements of the database go in these directories:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>data files:
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt/ingres/data/default/test</TT
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>checkpoint files:
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt/ingres/ckp/default/test</TT
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>dump files:
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt/ingres/dmp/default/test</TT
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>journal files:
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt/ingres/jnl/default/test</TT
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>temporary files:
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt/ingres/work/default/test</TT
|
|
>
|
|
</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>Let us suppose now, that we <EM
|
|
>extend</EM
|
|
> the database
|
|
to the following locations:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>DATALOC2</TT
|
|
>: data location -->
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt</TT
|
|
></P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>DATALOC3</TT
|
|
>: data location -->
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/disk2</TT
|
|
></P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>WORKLOC2</TT
|
|
>: work location -->
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/disk2</TT
|
|
></P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>The database is effectively extended to the following directories:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>data files:
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/disk2/ingres/data/default/test</TT
|
|
>
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>temporary files:
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/disk2/ingres/work/default/test</TT
|
|
>
|
|
</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>DATALOC2</TT
|
|
> points to
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt</TT
|
|
>, just like <TT
|
|
CLASS="ENVAR"
|
|
>DATALOC1</TT
|
|
>.
|
|
Tables to be created in location <TT
|
|
CLASS="ENVAR"
|
|
>DATALOC2</TT
|
|
> will go to
|
|
<TT
|
|
CLASS="FILENAME"
|
|
>/opt/ingres/data/default/test</TT
|
|
>,
|
|
the same directory where tables created in location <TT
|
|
CLASS="ENVAR"
|
|
>DATALOC1</TT
|
|
>
|
|
reside.</P
|
|
><P
|
|
>As is apparent from the example, we could have created just one
|
|
location for <TT
|
|
CLASS="ENVAR"
|
|
>DATALOC1</TT
|
|
>, <TT
|
|
CLASS="ENVAR"
|
|
>DATALOC2</TT
|
|
>,
|
|
<TT
|
|
CLASS="ENVAR"
|
|
>CKPLOC</TT
|
|
>, <TT
|
|
CLASS="ENVAR"
|
|
>DMPLOC</TT
|
|
>, <TT
|
|
CLASS="ENVAR"
|
|
>JRNLLOC</TT
|
|
>,
|
|
and <TT
|
|
CLASS="ENVAR"
|
|
>WORKLOC1</TT
|
|
>.</P
|
|
><P
|
|
>Summarizing the main points about locations:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Every location points to the root of a directory tree.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>More than one location can point to the same directory.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>A location can be used for storing different types of files.
|
|
</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>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.
|
|
</P
|
|
></LI
|
|
></UL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="IIDBDB"
|
|
>4.4. The iidbdb Database</A
|
|
></H2
|
|
><P
|
|
>Every <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> installation has a master
|
|
database called <SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
>.
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> stores information about users, locations
|
|
and user databases in this database.
|
|
<SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
> is created by the installer.</P
|
|
><P
|
|
>You have to set the locations for <SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
> during
|
|
installation.
|
|
These locations are stored in the following
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> environment variables:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_DATABASE</TT
|
|
>: data location</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_CHECKPOINT</TT
|
|
>: checkpoint location</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_DUMP</TT
|
|
>: dump location</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_JOURNAL</TT
|
|
>: journal location</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_WORK</TT
|
|
>: work location</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>These variables determine the default locations for every user database
|
|
as well, if you do not override them when creating those databases.
|
|
See <A
|
|
HREF="admin.html#CREATEDB"
|
|
>Creating and Destroying Databases</A
|
|
> for more information.</P
|
|
><DIV
|
|
CLASS="WARNING"
|
|
><P
|
|
></P
|
|
><TABLE
|
|
CLASS="WARNING"
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="25"
|
|
ALIGN="CENTER"
|
|
VALIGN="TOP"
|
|
><IMG
|
|
SRC="../images/warning.gif"
|
|
HSPACE="5"
|
|
ALT="Warning"></TD
|
|
><TD
|
|
ALIGN="LEFT"
|
|
VALIGN="TOP"
|
|
><P
|
|
>Changing the value of <TT
|
|
CLASS="ENVAR"
|
|
>II_DATABASE</TT
|
|
>,
|
|
<TT
|
|
CLASS="ENVAR"
|
|
>II_CHECKPOINT</TT
|
|
>, <TT
|
|
CLASS="ENVAR"
|
|
>II_DUMP</TT
|
|
>,
|
|
<TT
|
|
CLASS="ENVAR"
|
|
>II_JOURNAL</TT
|
|
>, or <TT
|
|
CLASS="ENVAR"
|
|
>II_WORK</TT
|
|
> requires a complete
|
|
re-install of <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>.</P
|
|
></TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
><P
|
|
>Let us see these variables one by one.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="IIDATAB"
|
|
>4.5. II_DATABASE</A
|
|
></H2
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_DATABASE</TT
|
|
> determines the data location of
|
|
<SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
>.
|
|
Its default value is <TT
|
|
CLASS="ENVAR"
|
|
>$II_SYSTEM</TT
|
|
> (in case of a manual
|
|
install you can enter a different value for <TT
|
|
CLASS="ENVAR"
|
|
>II_DATABASE</TT
|
|
>,
|
|
while <SPAN
|
|
CLASS="GUIMENUITEM"
|
|
>Express Install</SPAN
|
|
> inevitably sets it to
|
|
<TT
|
|
CLASS="ENVAR"
|
|
>$II_SYSTEM</TT
|
|
>).</P
|
|
><P
|
|
>The size of <SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
> after the installation is
|
|
somewhat more than 5 Mb.
|
|
It can only grow significantly if you create hundreds of
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> users, databases or locations.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="IICHECK"
|
|
>4.6. II_CHECKPOINT</A
|
|
></H2
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_CHECKPOINT</TT
|
|
> contains the value for the checkpoint
|
|
location of <SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
>.
|
|
By default, it is also set to <TT
|
|
CLASS="ENVAR"
|
|
>$II_SYSTEM</TT
|
|
>.</P
|
|
><P
|
|
>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 <A
|
|
HREF="admin.html#BACKUP"
|
|
>Backup and Recovery</A
|
|
>).
|
|
The installer takes the first checkpoint of <SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
>.</P
|
|
><P
|
|
>If you plan to place checkpoints of user databases under
|
|
<TT
|
|
CLASS="ENVAR"
|
|
>II_CHECKPOINT</TT
|
|
> then you have to provide for more space here.
|
|
</P
|
|
><P
|
|
>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.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="IIDUMP"
|
|
>4.7. II_DUMP</A
|
|
></H2
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_DUMP</TT
|
|
> determines the dump location of the
|
|
<SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
> database.
|
|
By default, its value equals to that of <TT
|
|
CLASS="ENVAR"
|
|
>II_CHECKPOINT</TT
|
|
>.</P
|
|
><P
|
|
>By the end of the installation process, <TT
|
|
CLASS="ENVAR"
|
|
>II_DUMP</TT
|
|
> will
|
|
contain a very small amount of data.
|
|
If you always create checkpoints off-line then you will not need much space
|
|
here.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="IIJRNL"
|
|
>4.8. II_JOURNAL</A
|
|
></H2
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_JOURNAL</TT
|
|
> contains the value for the journal location
|
|
of the <SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
> database.
|
|
Its default value is the same as <TT
|
|
CLASS="ENVAR"
|
|
>II_CHECKPOINT</TT
|
|
>'s.</P
|
|
><P
|
|
>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 <TT
|
|
CLASS="ENVAR"
|
|
>II_JOURNAL</TT
|
|
> depends on
|
|
three factors:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Whether you want <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> 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.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>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
|
|
<TT
|
|
CLASS="ENVAR"
|
|
>II_JOURNAL</TT
|
|
>.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
>The third factor is, how long you wish to keep old journal files.
|
|
If, when taking a checkpoint, you instruct <B
|
|
CLASS="COMMAND"
|
|
>ckpdb</B
|
|
>
|
|
to delete the old checkpoints, then previous journal files will be
|
|
removed as well.</P
|
|
></LI
|
|
></UL
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="IIWORK"
|
|
>4.9. II_WORK</A
|
|
></H2
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_WORK</TT
|
|
> determines the work location of the
|
|
<SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
> database.
|
|
It also defaults to <TT
|
|
CLASS="ENVAR"
|
|
>II_CHECKPOINT</TT
|
|
>.</P
|
|
><P
|
|
>The problem of sizing the work location only arises if
|
|
<TT
|
|
CLASS="ENVAR"
|
|
>II_WORK</TT
|
|
> 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.</P
|
|
><P
|
|
>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.</P
|
|
></DIV
|
|
><DIV
|
|
CLASS="SECT2"
|
|
><H2
|
|
CLASS="SECT2"
|
|
><A
|
|
NAME="OTHER"
|
|
>4.10. Other Ingres Environment Variables</A
|
|
></H2
|
|
><P
|
|
>Besides the <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> environment variables
|
|
that determine locations there are a couple more that you have to set
|
|
during installation (or have <SPAN
|
|
CLASS="GUIMENUITEM"
|
|
>Express Install</SPAN
|
|
>
|
|
set them to their default value). These are:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_INSTALLATION</TT
|
|
>: a two-character code,
|
|
identifying the installation.
|
|
Every <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> installation on a machine
|
|
must have its own, unique, installation code.
|
|
The default value for <TT
|
|
CLASS="ENVAR"
|
|
>II_INSTALLATION</TT
|
|
> is
|
|
<TT
|
|
CLASS="CONSTANT"
|
|
>II</TT
|
|
>.
|
|
Once set, it cannot be changed.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_NUM_OF_PROCESSORS</TT
|
|
>: number of processors in
|
|
the machine.
|
|
By default, it is <TT
|
|
CLASS="CONSTANT"
|
|
>1</TT
|
|
>.
|
|
If you set it to a higher value, <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
>
|
|
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 <TT
|
|
CLASS="ENVAR"
|
|
>II_NUM_OF_PROCESSORS</TT
|
|
> to
|
|
<TT
|
|
CLASS="CONSTANT"
|
|
>2</TT
|
|
> if you have a multiprocessor machine.
|
|
Its value can be changed at any time later.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_CHARSET</TT
|
|
>: this variable determines the code
|
|
set of all character data stored in all databases you will create in
|
|
the installation.
|
|
Its default value is <TT
|
|
CLASS="CONSTANT"
|
|
>ISO88591</TT
|
|
>.
|
|
Perhaps it is not surprising that changing it to a different value
|
|
after installation may corrupt data stored in your existing databases.
|
|
Since the <SPAN
|
|
CLASS="DATABASE"
|
|
>iidbdb</SPAN
|
|
> database is created by the
|
|
installer program, you should not choose
|
|
<SPAN
|
|
CLASS="GUIMENUITEM"
|
|
>Express Install</SPAN
|
|
> if
|
|
<TT
|
|
CLASS="CONSTANT"
|
|
>ISO88591</TT
|
|
> does not suit you.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><TT
|
|
CLASS="ENVAR"
|
|
>II_TIMEZONE_NAME</TT
|
|
>: name of the time zone, by
|
|
default <TT
|
|
CLASS="CONSTANT"
|
|
>NA-PACIFIC</TT
|
|
>.
|
|
During manual install you can select its value from a list of valid
|
|
codes.
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> stores all date and time values
|
|
in <SPAN
|
|
CLASS="ACRONYM"
|
|
>GMT</SPAN
|
|
> and adjusts them according to
|
|
<TT
|
|
CLASS="ENVAR"
|
|
>II_TIMEZONE_NAME</TT
|
|
> when communicating with the client.
|
|
Therefore, if you set <TT
|
|
CLASS="ENVAR"
|
|
>II_TIMEZONE_NAME</TT
|
|
> 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.</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>The (manual) installer prompts you for the value of two further
|
|
parameters which are not <SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> environment
|
|
variables:</P
|
|
><P
|
|
></P
|
|
><UL
|
|
><LI
|
|
><P
|
|
>Expected number of concurrent users in the system: this is
|
|
<TT
|
|
CLASS="CONSTANT"
|
|
>32</TT
|
|
> 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.</P
|
|
></LI
|
|
><LI
|
|
><P
|
|
><SPAN
|
|
CLASS="ACRONYM"
|
|
>SQL-92</SPAN
|
|
> compatible databases: by default,
|
|
<SPAN
|
|
CLASS="APPLICATION"
|
|
>Ingres</SPAN
|
|
> databases differ from the
|
|
<SPAN
|
|
CLASS="ACRONYM"
|
|
>SQL-92</SPAN
|
|
> 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
|
|
<I
|
|
CLASS="CITETITLE"
|
|
>SQL Reference Guide</I
|
|
>.</P
|
|
></LI
|
|
></UL
|
|
><P
|
|
>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 <SPAN
|
|
CLASS="GUIMENUITEM"
|
|
>Express Install</SPAN
|
|
>.</P
|
|
></DIV
|
|
></DIV
|
|
><DIV
|
|
CLASS="NAVFOOTER"
|
|
><HR
|
|
ALIGN="LEFT"
|
|
WIDTH="100%"><TABLE
|
|
WIDTH="100%"
|
|
BORDER="0"
|
|
CELLPADDING="0"
|
|
CELLSPACING="0"
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="sysreq.html"
|
|
>Prev</A
|
|
></TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="index.html"
|
|
>Home</A
|
|
></TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
><A
|
|
HREF="install.html"
|
|
>Next</A
|
|
></TD
|
|
></TR
|
|
><TR
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="left"
|
|
VALIGN="top"
|
|
>System Requirements</TD
|
|
><TD
|
|
WIDTH="34%"
|
|
ALIGN="center"
|
|
VALIGN="top"
|
|
> </TD
|
|
><TD
|
|
WIDTH="33%"
|
|
ALIGN="right"
|
|
VALIGN="top"
|
|
>The Installation Process</TD
|
|
></TR
|
|
></TABLE
|
|
></DIV
|
|
></BODY
|
|
></HTML
|
|
> |