Download Best Practices Guide: MDB Database Maintenance

Best Practices: Ingres MDB Housekeeping
© 2005 Computer Associates International, Inc.
Author Computer Associates
Last Saved Date November 07, 2005
Revision 1.1A(tp)
TABLE OF CONTENTS
1.
2.
Best Practices Guide: MDB Database Maintenance .......................................................... 4
Monitoring file sizes and disk space ................................................................................... 5
2.1.1.
Tool .......................................................................................................................................... 5
2.1.2.
Concept of files and file size in the MDB database ................................................................. 5
2.1.3.
File Size considerations on 32 bit and 64 bit OS .................................................................... 5
2.1.4.
Using the Ingres Modify command when files approach the 2G limit ..................................... 6
2.1.5.
Best Practice ........................................................................................................................... 6
2.1.6.
Examples ................................................................................. Error! Bookmark not defined.
2.2.
Monitoring disk space usage ....................................................................................................... 6
2.2.1.
Disk space Requirements ....................................................................................................... 6
2.2.2.
Monitoring disk space .............................................................................................................. 6
2.2.3.
Best Practice ........................................................................................................................... 6
3.
Reorganizing the MDB .......................................................................................................... 8
3.1.1.
Tool .......................................................................................................................................... 8
3.1.2.
What does table reorganization mean? .................................................................................. 8
3.1.3.
Reorganizing with the Ingres usermod command ................................................................... 8
3.1.4.
When should the usermod command be run? ........................................................................ 8
3.1.5.
Best Practice ........................................................................................................................... 8
3.1.6.
Examples ................................................................................................................................. 8
4.
Gathering Statistics............................................................................................................. 10
4.1.1.
Tool ........................................................................................................................................ 10
4.1.2.
Statistic gathering explained ................................................................................................. 10
4.1.3.
When to gather statistics using optimizedb ........................................................................... 10
4.1.4.
Example of when optimizedb may be desired ....................................................................... 10
4.1.5.
Best Practice ......................................................................................................................... 10
4.1.6.
Examples ............................................................................................................................... 10
5.
Reorganizating the Ingres System Catalog ...................................................................... 12
5.1.1.
Tools ...................................................................................................................................... 12
5.1.2.
When to reorganize the Ingres system catalog ..................................................................... 12
5.1.3.
What does the sysmod command do? .................................................................................. 12
5.1.4.
Prerequisites.......................................................................................................................... 12
5.1.5.
Best Practice ......................................................................................................................... 12
5.1.6.
Examples ............................................................................................................................... 12
6.
Relocating the MDB............................................................................................................. 14
6.1.1.
Tools ...................................................................................................................................... 14
6.1.2.
When to change a database location .................................................................................... 14
6.1.3.
What is relocated by relocatedb ............................................................................................ 14
6.1.4.
Prerequisites for relocation of a database location ............................................................... 14
6.1.5.
Best Practice ......................................................................................................................... 14
6.1.6.
Examples ............................................................................................................................... 14
7.
Extending the MDB.............................................................................................................. 16
7.1.1.
Tool ........................................................................................................................................ 16
7.1.2.
When to extend a database .................................................................................................. 16
7.1.3.
What locations are extended? ............................................................................................... 16
7.1.4.
Pre-requisites for extending a database location .................................................................. 16
7.1.5.
Best Practice ......................................................................................................................... 16
7.1.6.
Examples ............................................................................................................................... 16
8.
Backing up the MDB............................................................................................................ 17
8.1.1.
Tool ........................................................................................................................................ 17
8.1.2.
The backup process described ............................................................................................. 17
8.1.3.
Backup frequency .................................................................................................................. 17
8.1.4.
Information on checkpoints ................................................................................................... 17
841012993
Page 2 of 30
9.
10.
11.
12.
13.
8.1.5.
Best Practice ......................................................................................................................... 18
8.1.6.
Examples ............................................................................................................................... 18
Recovering a MDB ............................................................................................................... 19
9.1.1.
Tool ........................................................................................................................................ 19
9.1.2.
Prerequisites for database recovery ..................................................................................... 19
9.1.3.
How the database recovery process works .......................................................................... 19
9.1.4.
Best Practices........................................................................................................................ 19
9.1.5.
Examples ............................................................................................................................... 19
Retrieving information about the MDB.............................................................................. 21
10.1.1.
Tool ................................................................................................................................... 21
10.1.2.
Why, what and when database information can be required ............................................ 21
10.1.3.
Best Practice ..................................................................................................................... 21
10.1.4.
Examples .......................................................................................................................... 21
Exporting Data ..................................................................................................................... 23
11.1.1.
Tool ................................................................................................................................... 23
11.1.2.
Ways to export/view data .................................................................................................. 23
11.1.3.
Best Practices ................................................................................................................... 23
11.1.4.
Examples: ......................................................................................................................... 23
Troubleshooting MDB ......................................................................................................... 26
12.1.1.
Information Logged ........................................................................................................... 26
12.1.2.
Best Practice ..................................................................................................................... 26
Determining the MDB Version ............................................................................................ 27
13.1.1.
Examples .......................................................................................................................... 27
841012993
Page 3 of 30
1.
Ingres MDB Housekeeping
This document describes the functions that are recommended for housekeeping and maintenance of the
Ingres Management Database (mdb). Each function includes a description that explains what is required
and why it is important along with information about how to implement the function.
The following are the recommended functions to perform:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Monitoring file sizes and disk space
Reorganizing the MDB
Gathering statistics
System catalog reorganization
Relocating the MDB
Extending the MDB
Backing up the MDB
Recovering the MDB
Retrieving information about the MDB
Exporting Data
Troubleshooting the MDB
Determining the MDB Version
841012993
Page 4 of 30
2.
Monitoring file sizes and disk space
This section provides an understanding of the relationship of files to the mdb database and why
monitoring file sizes and disk space is necessary. It also provides a look at the file sizes supported by
various operating systems, the issues associated with them and what to do when reaching the size limits.
2.1.1. Tool
Modify: The Ingres command used to reorganize and relocate table(s) in the mdb.
Note: You should consult with Technical Support prior to using this command to modify your MDB.
2.1.2. Concept of files and file size in the MDB database

Ingres uses the term “location” to define the directory structures which are assigned to store one or
more of the following:
o database files – tables, indexes and system catalogs
o journal files – needed for recovery
o checkpoint files – the database backup
o work files – transient files
o dump files – created as a result of an on-line checkpoint
Refer to the “Ingres r3 Database Administrators Guide”, Chapter 3: Creating Databases and
Alternate Locations”, Section entitled “Types of Files in an Ingres database” for additional
information about these files.

By default each of these locations is created under the Ingres home directory II_SYSTEM.
o For example, if II_SYSTEM is set to “C:\Program Files\CA\Ingres [EI]” and the default
database location is defined within this directory
o The database “location” or directory for the mdb is “C:\Program Files\CA\Ingres
[EI]\ingres\data\default\mdb”.

Within the database directory a file is created for every table or index. Refer to the “Ingres r3
Database Administrators Guide”, Chapter 8: Maintaining Databases, Section entitled “Databases
Shared Among Multiple Users” to understand the relationship between table and indexes to the files
that hold their data.

As the number of rows in the table increases, the table size increases and so does the space it uses
on the disk.

As an example, consider the location %II_SYSTEM%/ingres/data/mdb that contains the data files for
the database called as mdb’.

Every file in this location corresponds to a table name or an index name in the mdb database. The
size of such a file cannot exceed the max file size allowed for the operating system in use. On some
operating systems this limit is 2GB.
2.1.3. File Size considerations on 32 bit and 64 bit OS


32 Bit operating systems (Windows 2000, RedHat ES 3.0) - Max file size is 2 GB
64 Bit operating systems (Windows XP Itanium, Windows 2003 Enterprise Edition Itanium, and
RedHat ES 3.0 AMD64) - Max files size is greater than 2 GB.
841012993
Page 5 of 30

When the maximum file size is reached it becomes impossible to add more rows to a table in the
mdb. On 32-bit operating systems this can be an issue where it is easy to reach the 2GB file size
limit.
2.1.4. Using the Ingres Modify command when files approach the 2G limit
The Ingres modify command can be used for the following:


Relocate a table - move the data from one location to another without changing number of locations.
As an example, if there are 2 locations in which a table resides then relocating the table means
moving the table from the current 2 locations to 2 new locations.
Reorganize the table- moves the data and changes the number of locations for the table. As an
example, if there are 2 locations in which a table resides then reorganizing the table means the table
can be moved to any number of locations.
2.1.5. Best Practice

The size of files in the database location need to be monitored, so that as files in the location
approach a size of 2 gigabytes on 32 bit OS, the appropriate action can be taken to reorganize the
table(file) across additional locations using the modify command
Note: The modify command will destroy any indexes and not recreate them unless the indexes were
defined as “with persistence”. For indexes that are not created as “with persistence” it is necessary to
create the index after “modify” has completed.
If you need to relocate a table, you should contact Technical Support first to avoid compromising the
integrity of your MDB.
2.2.
Monitoring disk space usage
This section covers a description of why disk space is necessary for mdb and needs to be monitored as
well as the activities to successfully monitor disk space
2.2.1. Disk space Requirements


The limit on how much disk space an Ingres database location can use based on the underlying
operating system and its file size limitations.
Databases needs disk space for more than just the database’s tables and procedures. It requires
sufficient disk space for work locations which are used for sorting, temporary and transient files.
2.2.2. Monitoring disk space


Available disk space is easy to monitor; it is the amount of unused space on a disk.
There are no special tools required (unless a raw location has been used). OS tools can be used for
this purpose. E.g. the df command on UNIX.
2.2.3. Best Practice




Disk space is a critical factor for operation with the Ingres database.
The mdb is a large database; product operation and database backups can require a lot of disk
space.
It is important to make sure that there is sufficient available disk space for all of the defined Ingres
database locations.
If necessary, the modify command can also be used to relocate table(s) or reorganize table(s) in an
effort to move the tables into a new disk location where additional space is available.
841012993
Page 6 of 30

Refer to sections 1.6 (relocating databases) and 1.7 (extending databases) to learn how to resolve
disk space issues.
Additional information regarding the ‘modify’ command, can be found in the SQL Reference Guide from
the Ingres installation, however, you should first consult with Technical Support prior to executing this
command to manage your MDB.
841012993
Page 7 of 30
3.
Reorganizing the MDB
This section provides information on reorganization of tables in the mdb, including why and when it is
required.
3.1.1. Tool
usermod – The Ingres command that modifies tables in the mdb
3.1.2. What does table reorganization mean?



The mdb includes a large number of tables each of which have different:
o Numbers of pages
o Numbers of indexes
o Rates of growth
o Rates of change
Each table will have a different modification cycle e.g. some may need to be modified once a year
others may need to be modified a frequently as once a day.
Each product’s documentation will provide guidance with respect to the need to reorganize the tables
they use.
3.1.3. Reorganizing with the Ingres usermod command




The usermod command modifies the user-defined tables of a mdb to their currently defined storage
structure and recreates any secondary indexes that are defined.
This command runs on the mdb tables and not on the Ingres system catalog tables
The command fixes the overflow pages in a table which improves performance of query processing.
If a table does not need to be modified but an index does, either the index can be dropped and
recreated or the index can be modified. Dropping and recreating the index may be quicker than
reorganizing the table and all indexes.
3.1.4. When should the usermod command be run?



When tables are in overflow
To reclaim space
Before optimizedb/sysmod
Note: To whether tables are in overflow, please refer to the “Ingres r3 Database Administrators Guide”,
Chapter 12: Maintaining Storage Structures, Section Overflow Management.
3.1.5. Best Practice



As a table grows in size there is a need to tidy up the table to reclaim space.
Every table within the mdb will, at some point, be a candidate for modification using the ‘usermod’
command.
The usermod command needs to be run when there is a need to modify tables and recreate indexes.
3.1.6. Examples
To modify the mdb to its current storage structure and recreate the secondary indexes –
usermod –online –umdbadmin mdb
841012993
Page 8 of 30
where:


mdb is the name of the database
-online means that this command is run online. Note that if this option is not specified the
command is expected to be run offline and it is expected that there will be no active connections
to the database.
For more information on the ‘usermod’ command, please refer to the “Ingres r3 Command Reference
Guide”.
841012993
Page 9 of 30
4.
Gathering Statistics
This section describes the process of statistics gathering, why it is necessary and how to collect statistics
for the mdb.
4.1.1. Tool
optimizedb –The Ingres command for generation of statistics used by the query optimizer for efficient
query processing
4.1.2. Statistic gathering explained





Statistics need to be calculated in order to reflect the changes of values in tables.
This is especially important after restructuring the tables with the modify command
The Query Optimizer Facility (OPF) makes use of statistic and histogram data gathered against table
columns that are used in queries.
The absence of statistics is more likely to result in sub-optimal query performance.
Statistics are stored in system catalog tables such as (iistats and iihistograms)
4.1.3. When to gather statistics using optimizedb


As with table modification, the frequency of running optimizedb on a table column depends on the
rate of change of:
o Histogram data within the column
o Range of values within the column
Within a multi-column table each column may have a different requirement with respect to frequency
of execution of the 0ptimizedb command.
o There can be columns in a table that never need to be optimized, as these columns are
never used in the “where clause” of an SQL statement.
o It is possible that the number of rows in the table is so large that using the optimizedb
option of sampling against a column is as effective as running optimizedb against every
column of every row within the table.
4.1.4. Example of when optimizedb may be desired
A table that has columns {transaction_id, amount, credit_or_debit_flag, account_number} where the table
is growing at the rate of 100,000 rows per day may need to have statistics gathered on transaction_id
every day as it is an incremental number, on credit_or_debit_flag once a year, on amount never and
account_number once a week when the table is initially used and then every siz months once the table
reaches a sufficient size where the histogram for account_number no longer changes as often.
4.1.5. Best Practice




Statistics affect the speed of query processing
Generating statistics for a database means effectively optimizing the database and should not be
done
The optimizedb command should be run periodically on the keys or index columns for mdb tables.
Each product’s tables have different optimization requirements. Please consult product
documentation to review information about optimization/statistics gathering requirements.
4.1.6. Examples
optimizedb –zk –zv –umdbadmin mdb
841012993
Page 10 of 30
where:
 -zk specifies running for the keys of the table.
 -zv specifies verbose mode
 mdb is the name of the database
For more information on the ‘optimizedb’ command, please refer to the “Ingres r3 Command Reference
Guide”.
841012993
Page 11 of 30
5.
Reorganizating the Ingres System Catalog
This section covers how and why system catalog reorganization is needed
5.1.1. Tools
Sysmod – The Ingres command that reorganizes and optimizes the tables that make up the Ingres
system catalog.
5.1.2. When to reorganize the Ingres system catalog


After the optimizedb command has run; optimizedb modifies the Ingres system catalog
After database creation, significant changes to database schema e.g. creating and dropping tables or
running Optimizedb.
o Note that the mdb creation process issues a sysmod command when it completes
5.1.3. What does the sysmod command do?



Reorganizes the system catalogs for the database.
Runs quickly
Requires exclusive access to the database
5.1.4. Prerequisites
The sysmod command requires there be no active sessions connected to the database.
The following commands can be run to determine whether there are active sessions:



sql -u$ingres -i44 -v imadb
execute procedure ima_set_vnode_domain\g
select count(*) from ima_server_sessions where db_name = 'mdb'\g
If a count of 0 is returned there are no active sessions. If a value greater than 0 is returned then there are
active sessions and the sysmod command should not be run.
5.1.5. Best Practice
The Ingres catalog should be optimized whenever there are significant changes to the database or after
the optimizedb command is run.
5.1.6. Examples
To modify all the system catalogs for a database
sysmod mdb
To modify the system catalogs and wait for the database to be free of sessionssysmod mdb +w
A database name can be specified or a list of tables. If a table list is not provided all tables are
considered. The command can be made to wait (+w) or not wait (-w) until the database is free before
executing. The default is -w.
841012993
Page 12 of 30
For more information on the ‘sysmod’ command, please refer to the “Ingres r3 Command Reference
Guide”.
841012993
Page 13 of 30
6.
Relocating the MDB
This section covers how the mdb database location can be changed and what parts of a database are
able to be relocated
6.1.1. Tools
Relocatedb – The Ingres command to relocate a database
6.1.2. When to change a database location


A database location should be changed when a disk or file partition used for the various database
locations (journal, checkpoint, dump and work) becomes full
A location should be changed when a database had been defined as residing on a single disk and
due to performance issues e.g. disk I/O bottlenecks or space issues, it is necessary to move or split
across more database locations
There are two options available for changing database locations:
 Create a new Ingres location and distribute files between the old and new location
 Use the Ingres command relocatedb to move locations.
6.1.3. What is relocated by relocatedb
Checkpoint, journal, or dump files are relocated. The existing files are moved to the new location and any
new files that result from subsequent database activity are created in the new location. E.g. Journal files
that were in location1 are relocated to location2, any new journals will also be created in location2.
6.1.4. Prerequisites for relocation of a database location
The location(s) that are specified on the relocatedb command must exist prior to command execution.
and the location must be specified with the appropriate usage type (journal, checkpoint, or dump).
Note: The Ingres command extenddb can be used to add new locations and extend databases to new
locations
6.1.5. Best Practice





Monitor the size of the database and the available disk space using the operating system tools
appropriate to the installation
Monitor the rate of growth of files in database locations
Plan to purchase new disk or regularly archive files like the transaction log file(s), checkpoint files,
journal files from disks to ensure there is space for future growth
Plan a database relocation and ensure that the disks for the proposed new locations have sufficient
disk space and the IO throughput is appropriate for the activity put upon the disks
Make sure you take a full backup before undertaking a relocation
6.1.6. Examples
The following examples describe how to use the Ingres tool relocatedb to move a database location and
copy an entire database.
To relocate a journal location to a new location
relocatedb mdb -new_jnl_location=newjnl
841012993
Page 14 of 30
To relocate a dump location to a new location
relocatedb mdb -new_dump_location=newdump
To relocate the database to a new location
relocatedb mdb –new_database=mdb1
For more information on the ‘relocatedb’ command, please refer to the “Ingres r3 Command Reference
Guide”.
841012993
Page 15 of 30
7.
Extending the MDB
This section describes the how to extending the mdb and the parts of a database that can be relocated
7.1.1. Tool
Extenddb – The Ingres command to extend an Ingres database
7.1.2. When to extend a database
A database should be extended when there is a need for additional database or work locations.
7.1.3. What locations are extended?
Database and work locations can be extended. Checkpoints, journals and dump files can only be
relocated or moved to a new location but cannot be extended.
7.1.4. Pre-requisites for extending a database location
The new disk locations must exist before this command is run.
7.1.5. Best Practice


Monitor the size of data and work areas
If there is no need to extend the location for a database there is an explicit need to use the ‘-nodb’
flag. This would create a new location without extending it.
7.1.6. Examples
To extend the mdb database
extenddb –lextraloc3 –Udata mdb
To create a new location but not extending the databases
extenddb –lnewloc2 –a/disk2/loc2 –Uckp, jnl –nodb
For more information on the ‘extenddb’ command, please refer to the “Ingres r3 Command Reference
Guide”.
841012993
Page 16 of 30
8.
Backing up the MDB
This section describes the process of taking database backups, understanding the backup process and
discusses the different approaches for taking backups
8.1.1. Tool
ckpdb - The Ingres command for backing up databases. Backing up an Ingres database is often referred
to as “checkpointing” the database.
8.1.2. The backup process described








Checkpointing is the recommended method for backing up Ingres databases
Checkpoint (ckpdb) is the Ingres command that backs up the database; it can be run in on-line or offline mode; it can be run against the database or against a table or a list of tables.
The location where checkpoints are stored is – %II_SYSTEM%/ingres/ckp/<dbname>. There is a
sub-directory with the name of each database(dbname) for each and every database created on the
server. For every sub-directory there will be a corresponding file by the name of c*******.ckp for every
checkpoint taken for that database.
Another way to back up the database is to take an operating system backup. Before you do this you
must make sure that Ingres is shut down. (OS backups taken when Ingres is operational that are
restored, can not be supported. You risk data integrity problems if you do this.)
Journaling is the way to capture changes that have been made to the database. Journaling can be
switched on or off for all tables in a database or specific tables.
Having a checkpoint and journals for a database allow the database to be recovered from a
catastrophic failure e.g. loss of database disks. The time taken to recover a database is a function of
the size of the database, the time to replace the database files onto disk and the size of the journal
files.
Journaling is always turned on for the mdb. The location where checkpoints are stored is –
%II_SYSTEM%/ingres/jnl/mdbThere will be a sub directory for each and every database created on
the server. Journal files are named j*******.jnl.
When an online checkpoint is taken, all the data that written to the database is saved in the dump
files which would are used whenever recovery is done.
8.1.3. Backup frequency




A backup should be run at the end of a housekeeping cycle.
This means that all that would be needed if a failure were to occur is to recover the database from the
backup and apply the journals; there would be no need to reapply any housekeeping.
A more rigorous option is to do a backup prior to and after housekeeping. This would give a recovery
point, at start of housekeeping, from which recovery could be done should housekeeping fail.
An even more rigorous option is to perform a backup before and after housekeeping and at suitable
points in between. This would allow minimum time for recovery based on the size of the checkpoint
and the size of the journal files.
8.1.4. Information on checkpoints

There are two mechanisms for removing old checkpoints.
o The “alterdb –delete_oldest_ckp” command which deletes the oldest available checkpoint,
including related journals and dump files. The request fails if an attempt is made to delete the
only remaining valid checkpoint.
o The “ckpdb –d” which destroys ALL previous checkpoints, including related journals and
dump files.
841012993
Page 17 of 30

A list of up to 99 checkpoints is kept in the aaaaaaaa.cnf configuration file for the database. When
the 99th checkpoint is taken the oldest is dropped from the list. It is possible to restore a checkpoint
that is not on the list but it is not a supported procedure and should be done with the assistance of
support.
8.1.5. Best Practice








Database backup should occur after mdb maintenance.
After a checkpoint has completed all the files for that checkpoint (those in the checkpoint, journal and
dump directories) should be archived to tape and stored. The previous checkpoint files in the
checkpoint, journal and dump directories can be deleted from disk since it is already been backed up
to a tape. This means that the latest checkpoint will always be on disk. It also means that there
needs to be disk space available to hold two complete checkpoints of the mdb.
The checkpoint option of deleting old checkpoints should not be used. The alterdb command with the
“-delete_oldest_ckp” option should not be used. This means that the mdb database configuration file
“ aaaaaaaa.cnf” will eventually hold a history of the 99 previous checkpoints. When a new checkpoint
is taken, the oldest one in the .cnf file will be overwritten by this newer one.
Although it is hoped that recovery is not needed, because the checkpoints are not being deleted the
ability to recover to previous backups is possible, and provides a great deal of flexibility should this be
required.
Keep the last checkpoint and associated journals and dump files on disk
Take a copy of the checkpoint files, dump directory for the database and the journal files to tape (or
disk)
Delete all checkpoints except the last from the checkpoint, journal and dmp directories from the disk
Allow the number of checkpoints in the aaaaaaaa.cnf file to grow to the maximum and then for
database to drop the eldest.
8.1.6. Examples
To checkpoint a database
ckpdb –umdbadmin mdb
For more information on the ‘ckpdb’ command, please refer to the “Ingres r3 Command Reference
Guide”.
841012993
Page 18 of 30
9.
Recovering a MDB
This section covers information on when to do a recovery, how to proceed with recovery and how the
recovery tool works
9.1.1. Tool
rollforwarddb – The Ingres command used to recover database or table(s) from backups
9.1.2. Prerequisites for database recovery


For recovery to be possible, a database backup and its checkpoint files should exist. (Without a
backup there can be no recovery.)
Recovery can be done from checkpoints and journals or from checkpoints only.
9.1.3. How the database recovery process works

A table as well as a database can be recovered. The rollforwarddb command recovers a database or
table from the last checkpoint and the current journal and dump files.
 The rollforwarddb command must be issued by an Ingres user with DBA or a system administrator
privileges. The mdbadmin user as the owner of the mdb can issue this command. Note that the
command can be issued from the OS user that installed the database.
 The database recovery depends on the way in which a backup occurred. If the backup was
performed online, the recovery command applies the checkpoints, the journals and finally the dump
files from the dump folder.
 If the backup was offline then the database is recovered from the checkpoint and journals are applied.
A specific set of checkpoint files can also be used to enable recovery from a point in time.
 Journals are applied as necessary. Once a recovery is complete, the backed up data (checkpoint
files) are restored in the database directory.
 Recovery requires exclusive access to the database when it executes. It requires no active sessions
connected to the database.
 Once the utility completes its operation the database is made available.
 If recovery is from a checkpoint on disk it needs to be copied to disk prior to execution of the
rollforward command.
 On the Unix platform the backup (ckpdb) can be directly to a tape. If this is how the backup was
executed it can be recovered directly from the tape drive.
Note: Before database recovery using rollforwarddb can occur, it is imperative that a backup occur. This
provides the ability to restore in the case of errors during recovery. In addition, all log files including the
transaction log should be saved. Please refer to the section of this document that discusses
Troubleshooting for additional information.
9.1.4. Best Practices




Database recovery requires a previous backup and valid checkpoint files.
A database or a table can be recovered (or roll backed) from any available checkpoints. By default
the recovery will be from the last checkpoint.
Use of the verbose option in this command allows the user to see diagnostic information about the
operation executed during the recovery process.
A backup of all the log files and the transaction log file should be taken before a recovery is started
9.1.5. Examples
To recover database mdb from the last known checkpoint
841012993
Page 19 of 30
rollforwarddb –umdbadmin mdb -v
To recover the above database from the fourth oldest checkpoint
rollforwarddb #c4 –umdbadmin mdb -v
For more information on the ‘rollforward’ command, please refer to the “Ingres r3 Command Reference
Guide”.
841012993
Page 20 of 30
10.
Retrieving information about the MDB
This section describes how to get information on the databases you own and to understand how to get
DBA related information for the mdb
10.1.1.Tool
infodb – The Ingres command to retrieve information on databases in an Ingres instance.
10.1.2.Why, what and when database information can be required






Provides a simple way to get high level information on a database
When details about a database’s status, the location of its files and history of checkpoints and
journals is required.
This command requires a user with DBA or system administrator privlidges
Includes useful information for checkpoints such as if and when they were taken and whether
journaling is turned on or not.
Displays problems with the databases such as the state and information about underlying causes.
Information for the dump, journals, similar to that displayed for databases and checkpointing.
10.1.3.Best Practice
Whenever there is a need to get high level information about the mdb
10.1.4.Examples
To run this command from a command line
infodb mdb
To get a list of tables in database checkpoint number 4
infodb mdb #c4
841012993
Page 21 of 30
Output Explained:
 Status on the database which indicates that the database is in a valid state, has been
checkpointed and also that journaling is enabled.
 The date and time the checkpoint was taken. (In the screenshot above we see that the
checkpoint was taken Offline.)
 Additional information on the location of the checkpoints, journals, dump and the work areas is
also shown.
For more information on the ‘infodb command, please refer to the “Ingres r3 Command Reference Guide”.
841012993
Page 22 of 30
11.
Exporting Data
This section covers how to export mdb table(s) and to create reports
11.1.1.Tool


iea – The Ingres export assistant
Microsoft Excel
11.1.2.Ways to export/view data



Exporting data is useful when there is a need to create reports on a set of table(s) from the mdb.
On Windows Ingres provides an intuitive tool called the Ingres Export Assistant. This tool has the
ability to export a table(s) data into a file. Supported file formats are csv, xml and dbf. It can be run as
stand-alone from the command line using the command ‘iea’ or from Visual DBA (VDBA).
Another simple way to export data is with Microsoft Excel using Ingres ODBC connectivity. In order to
use Microsoft Excel a ODBC DSN needs to be setup.
11.1.3.Best Practices

Use the Ingres Export Assistant – Data from one or more tables can be exported using the export
utility. A user running this utility has to have the permissions to access the data in those tables. The
export utility can be run by running the command ‘iea’ on the command line.
11.1.4.Examples:
To run the Ingres Export utility from the command line type:
iea
841012993
Page 23 of 30
The following window displays:
Microsoft Excel
Using the Ingres 3.0 ODBC with Microsoft Excel - Using MS Excel and Ingres ODBC Connectivity, data
can be extracted from tables in the mdb. Some basic knowledge on how to connect to an ODBC DSN is
needed. Once an ODBC DSN is created use Excel to do the following:
841012993
Page 24 of 30
Then select the DSN created using the Ingres 3.0 ODBC driver and the rest should be fairly intuitive.
841012993
Page 25 of 30
12.
Troubleshooting MDB
This section provides information on the log files related to the mdb.
12.1.1.Information Logged







All database related information is logged to the log files within the database installation.
All the changes within the Ingres database including errors are written to the file errlog.log.
The Ingres archiver appends all the archiver progress information to the file iiacp.log.
The Ingres recovery server adds recovery information to the file iircp.log file.
If VDBA is used, the corresponding details are logged to the iivdba.log file.
Ingres startup information is logged to the ingstart.log file.
The mdb creation process writes status information into the file install_mdb.log.
12.1.2.Best Practice
All the information related to the database is stored in log files as explained above. Whenever there is a
need to troubleshoot a problem with the mdb, the first place to look at are these log files. The location of
these files is in the II_SYSTEM\ingres\files folder. The log files are:






errlog.log: default log file for the Ingres installation
iiacp.log—Archiver log
iircp.log—Recovery log
errvdba.log – VDBA log
ingstart.log – startup log file for Ingres
install_mdb.log – information about mdb creation processing
Whenever you contact CA Technical Support regarding issues with the database, these log files would
always be needed in addition to any other files.
841012993
Page 26 of 30
13.
Determining the MDB Version
It may be necessary to know the version of the mdb database that is currently installed. This is
functionality that can be accessed by the owner of the mdb database ‘mdbadmin’ or a user with
permissions defined for impersonation of the user ‘mdbadmin’.
13.1.1.Examples
1.1.1.1 MDB Version via SQL Command
Issue the following command:
sql –umdbadmin mdb
Type the following to retrieve data from the ‘mdb’ table:
select * from mdb \g
841012993
Page 27 of 30
Using the information displayed:
MDB Major Version=1
MDB Minor Version=3
MDB Build Number=25
MDB Release Date=15-May-2005
MDB Install Date=21-June-2005 at 11:26:34
1.1.1.2 MDB Version from the Ingres configuration files
Issue the following commands:
iigetres ii.<host-name>.mdb.mdb.version.build
iigetres ii.<host-name>.mdb.mdb.version.major
iigetres ii.<host-name>.mdb.mdb.version.minor
841012993
Page 28 of 30
1.1.1.3 MDB Version from the Ingres configuration files
You can also get the version information about the mdb by looking at the install_mdb.log file that was
written when the mdb was created. This file is located in the II_SYSTEM/ingres/files/ directory and is
named install_mdb.log.
841012993
Page 29 of 30
14.
Product Specific Housekeeping Requirements
Product
Unicenter Service Desk
Function
This will reorganize the tables and
recreate all indexes.
Tool/command
 bop_cmd -f reorg.frg "reorg()"
 ktoptdb
Unicenter Service Desk
Optimization


Unicenter Service Desk
Unicenter Service Desk


Backup
Restore
optimizedb -zk -umdbadmin mdb –
rskeletons
optimizedb -zk -umdbadmin mdb rindex_doc_links
pdm_backup
pdm_restore
841012993
Page 30 of 30