<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 >
