In this section we outline the basic tasks of the Ingres system administrator and the Ingres database administrator. You will also see what tools Ingres provides to perform these tasks. In the following I suppose you are logged in as ingres.
You have already seen how to start Ingres:
$ ingstart
To stop Ingres, use the command:
$ ingstop
ingstop only stops Ingres if the are no active user sessions. If you want
to stop the system regardless of user sessions, use the form:
$ ingstop -force
Take care: forcing Ingres to stop might make your databases inconsistent.
After Ingres has stopped you can check if it released all shared memory segments and semaphores:
$ ipcs -a
If you see that ingres still has some shared memory segments or semaphores, you can release them with the utility:
$ ipcclean
Since the ingres user has unlimited power of changing and possibly destroying any element of an Ingres installation, it is highly advisable that you use this account for carrying out administrative tasks only. Create one or more new Linux users and set their environment to that of ingres.
In order for any user to have access to the Ingres installation, you have
to define them as Ingres users with the accessdb utility.
Start accessdb:
$ accessdb
Select the Users option:
Create
Enter the name of the user. You don't have to modify permissions (perhaps the Set Trace Flags could be set to y to allow debugging).
Save, then End and End.
You can also use accessdb to create new locations, change their types or
extend databases to new locations. The usage of accessdb is covered in the
System Reference Guide and the Database Administrator's Guide.
As an alternative to accessdb, you can maintain users and locations by
running SQL commands on iidbdb (create user, create location, etc.). The syntax
of these commands can be found in the SQL Reference Guide.
In section First Steps you created a new database. You didn't specify any options in the command
$ createdb test
Therefore the values stored in II_DATABASE, II_CHECKPOINT, etc. became locations of the test database. You could have specified each location explicitly:
$ createdb test -d<data location> -c<checkpoint location> -j<journal location> -b<dump location> -w<work location>
You can remove a database in the following manner:
$ destroydb test
Be careful, because Ingres won't prompt you before destroying the database.
The collation sequence determines which of any two character strings is less than the other. In Ingres, every database can have its own sorting order. You can specify the collation sequence when creating the database:
createdb test -lhun
If you omit the -l parameter, characters in that database will be ordered as determined by the code set of the installation.
In order to use a different collation sequence you have to create a text
file. The structure of this file must obey to simple rules by which you specify
the absolute or relative ordering of letters and/or strings in your language.
This file must then be compiled by the aducompile utility for Ingres to be
able to use it.
The Spanish collation sequence and the collation based on the DEC Multinational
Character Set are available both in source (spanish.dsc and multi.dsc) and
compiled form (spanish and multi).
You specify these collation sequences in the following way:
createdb test -lspanish
or
createdb test -lmulti
The compiled definition files for a collation sequence must be in the $II_SYSTEM/ingres/file/collation
directory. The syntax rules of the definition files can be found in the System
Reference Guide. It may also be useful to examine the definition files for
the Spanish and the DEC Multinational collations.
The only supported way of backing up Ingres databases is via the ckpdb
utility. With ckpdb, you can back up a whole database or certain tables of
it. The following command backs up the test database:
$ ckpdb test
Checkpoints can be taken on-line.
Restoring a database can be done with the rollforwarddb command:
$ rollforwarddb test
By default, rollforwarddb, using the latest checkpoint and all journal
files created since that checkpoint, restores the database to its current state.
However, you can specify a point in time to restore the database to the state
it was in at that time. You can go back as far as 16 checkpoints (Ingres stores
data for the last 16 checkpoints in the control file of the database).
Both ckpdb and rollforwarddb can have many parameters. You can read more
about these commands in the System Reference Guide. Besides, you should read
Michael Leo's paper on Ingres backup and recovery at:
http://www.naiua.org/papers/backup99.zip
ckpdb and rollforwarddb use a template file ($II_SYSTEM/ingres/files/cktmpl.def).
By modifying this file, you can customize the Linux commands that do the physical
backup and restore of the data files. The Database Administrator's Guide explains
the usage of this file.
Most Ingres parameters can be set via the cbf utility. This is the program
by which you can specify the number of DBMS servers, the sizes of different
caches and a lot of other variables. The usage of cbf is detailed in the System
Reference Guide.
You can use the ipm utility to monitor a running Ingres system (Visual
DBA doesn't have a Linux version). With ipm, you can monitor user sessions,
the locking and the logging subsystems. It also contains session and server
management functions.
IMA (Ingres Management Architecture) makes possible to write customized, SQL-based applications for monitoring and managing Ingres installations. You can find information on IMA in the System Reference Guide.
You can find the Ingres message files under $II_SYSTEM/ingres/files.
The most important of these is errlog.log. Should any problems arise during
the running of Ingres, this is the file to check first.