Idaho National Engineering and Environmental Laboratory
Environmental Restoration Information System
Database Administration Plan and Procedures
January, 1998, Revision 3
ABSTRACT
The database administration plan and procedures is used to ensure that the Environmental
Restoration Information System database is managed in a manner that will guarantee data
integrity and consistency, will guarantee database security, will facilitate the sharing of data
among users, and will meet the requirements defined in the General Requirements for the
Environmental Restoration Information System(8). This document describes the procedures used
for the Environmental Restoration Information System database, which resides on the Oracle
Relational Data Base Management System. For more detailed information on these
procedures, please refer to the most recent revision of the Oracle RDBMS Database
Administrator's Guide.
TABLE OF CONTENTS
1. PURPOSE
- 2.1 Development Environment
- 2.2 Production Environment
- 2.3 Porting Data to the Production Environment
- 3.1 Database Access
- 3.1.1 Assigning Privileges
- 3.1.2 Assigning Default Tablespaces
- 3.3.3 Revoking Tablespace Access
- 3.1.4 Dropping Users
- 3.2 Auditing Database Access
- 3.3 Database Objects
- 3.3.1 Access to Data
- 3.3.2 Access to Views
- 4.1 Structures Used In Recovery
- 4.2 Archiving
- 4.3 Database Files
- 4.4 Backup Procedures
- 4.4.1 Offline and Online Backups
- 4.4.2 Control Files
- 4.4.3 Frequency of Backups
- 4.5 Exporting and Importing Data
- 4.5.1 Exporting Data
- 4.5.2 Importing Data
- 5.1 Database File Maintenance
- 5.2 Redo Log File Maintenance
- 5.3 Rollback Segment Maintenance
- 5.3.1 Creating Rollback Segments
- 5.3.2 Altering Rollback Segments
- 5.3.3 Monitoring Rollback Segments
- 5.3.4 Dropping Rollback Segments
- 5.4 Tablespace Maintenance
- 5.4.1 Creating Tablespaces
- 5.4.2 Enlarging a Tablespace
- 5.4.3 Renaming a Tablespace
- 5.4.4 Dropping a Tablespace
- 5.5 Maintenance
- 5.5.1 Determining Space Requirements
- 5.5.2 Index Storage
- Appendix A - Notification Procedure
The purpose of this document is to establish the Proper database administration plan and procedures
that must be followed in order to ensure that the Environmental Restoration Information System (ERIS)
databases meet the requirements defined in the System Quality Assurance Plan for the Environmental
Restoration Information System(3) and the System Configuration Management Plan for the Environmental
Restoration Information System(4).
2.1 Development Environment
The development database environment of ERIS is used primarily by the application engineers.
Data changes in this environment are made as needed by the application engineers. Only data changes
that affect the design of the database are scrutinized.
2.2 Production Environment
Data changes in the production database environment of ERIS are strictly managed. The data owner
identifies the need for the change(s) and makes the necessary changes interactive1y. All changes are
reported to the ERIS Data Base Administrator (DBA) for auditing purposes. Errors and modifications
noted by others are reported to the data owner by the DBA with a listing and a cover letter.
Modifications are made to the original listing, dated and initialed, and a copy is returned to the DBA.
2.3 Porting Data to the Production Environment
Data are moved from the development environment to the production environment using the following
steps:
- The data are verified in the development environment by the application engineer.
- The DBA is notified of the need to move the data.
- (Optional) The data are inspected by the derivative classifier. This step is not necessary if the data is public domain.
- The data are moved.
- The data are re-inspected by the application engineer.
- The DBA grants the "ALL" privilege to the data owner, and the "SELECT" privilege to "PUBLIC".
- A report of the data move is sent to the project office, a copy is kept by the DBA.
- (Optional) The data are verified by the data owner.
For more detailed information on these procedures, please refer to the Standard Operating
Procedures for theTransfer of Data from the ERIS Development Database to the ERIS Production
Database(10).
3.1 Database Access
Users of ERIS must contact ERIS Customer Service and complete forms 1752 and 557. These forms must be returned to ERIS customer Service, they will
then be sent to CRCS, assigned a User-ID, password, and new users will
be connected to the server.
CRCS will assign user privileges using the SQL statement GRANT, to the applicable databases. A user must have CONNECT privileges in order to
access data in the database. A user with only the CONNECT privilege may:
- Access the database, query other users' data (SELECT from tables and views), if SELECT access has been granted to the user or to PUBLIC,
- Perform data manipulation operations (INSERT, UPDATE, DELETE) on other users' tables if appropriate access has been granted,
- Create views, synonyms, and database links,
- Perform table or user exports.
- The syntax to grant the CONNECT privilege is:
-
- GRANT CONNECT TO username IDENTIFIED BY password.
3.1.1 Assigning Privileges
If a user has the RESOURCE privilege in addition to the CONNECT privilege, the user will have
the privileges listed above, and, in addition, the user will be able to create database objects such as tables,
indexes, clusters, and sequences. The user will also be able to enable or disable the auditing of such
database objects, and grant or revoke to other users privileges on those database objects. CRCS will
grant resource privileges as applicable. The DBA may change privileges for users following this
procedure:
The RESOURCE privilege may be granted in three ways:
- Unrestricted access to any tablespace with no quota, as in:
- GRANT RESOURCE to username,
- Access to specified tablespaces only, but with no quotas, as in:
- GRANT RESOURCE on tablespace to user-name,
- Access to specified tablespaces with space quotas, as in:
- GRANT RESOURCE on tablespace to username.
3.1.2 Assigning Default Tablespaces
SYSTEM is the default tablespace for creating objects and temporary segments. To change the
defaults, use the syntax:
- ALTER USER username IDENTIFIED BY username.
- DEFAULT TABLESPACE tablespace
- TEMPORARY TABLESPACE tablespace
3.1.3 Revoking Tablespace Access
To revoke access to a tablespace, use:
- REVOKE RESOURCE ON tablespace FROM username
3.1.4 Dropping Users
Users are normally dropped from system access by CRCS actions. With sufficient reason, the DBA
may also revoke connect to the system at any time, following this procedure. To take database privileges
away from a user, use the SQL statement:
- REVOKE CONNECT FROM username.
3.2 Auditing Database Access
By default, auditing is disabled, but it can be enabled whenever an instance is started. To enable
auditing, set the parameter AUDIT_TRAIL in the INIT.ORA parameter file to TRUE, then start the
instance using the edited INIT.ORA file. The DBA may enable system-wide defaults or options, such
as setting default auditing options for database objects (such as auditing all successful attempts to ALTER
any Oracle table) and system-wide database auditing options (such as auditing all unsuccessful attempts
to access the database itself). To specify the auditing of system operations, use the following syntax:
- AUDIT [CONNECT] [DBA] [RESOURCE] [NOT EXISTS] [ALL] WHENEVER
- [NOT] SUCCESSFUL.
All auditing records are written to one database table, AUDIT TRAIL. Two views are created on this
table: DBA_AUDIT_TRAIL and USER_AUDIT_TRAIL (a subset of DBA_AUDIT_TRAIL). The
columns ACTION and ACTION_NAME respectively list the action code and the action audited.
Auditing has been turned on at the request of the project office. The database files are purged at the
DBA's discretion for data older than one year.
3.3 Database Objects
3.3.1 Access to Table Data
Owners of tables have several options for allowing other users to see or change data in their tables.
Access is given with the SQL statement GRANT, and views can be used to limit the data accessed. Table
owners can give permission to other users to access either all of the data in the table, or just portions of
the data. Various types of privileges can be given, for example, to read only (SELECT access), to
change data as well (UPDATE and DELETE) access. To grant privileges on a specific table to a
particular user, use the following syntax:
- GRANT privilege ON tablename TO username.
3.3.2 Access to Views
A view can be created on a table, and user access granted to the view rather than the table. The
view is a subset of rows or columns from a table. To grant privileges on a specific view to a particular
user, use the following syntax:
- GRANT privilege ON viewname TO username.
4.1 Structures Used In Recovery
The important structures used in instance and media recovery are redo log files, rollback segments,
and database backups.
A redo log is a set of operating system files, external to the database files, that records all changes
made to the database, regardless of whether those changes are committed or rolled back. Redo log files
are written to by the LGWR (Log Writer process) A redo log file that is online and can be written to by
the LGWR is called an active online redo log file. Redo logs that are archived, or saved, while Oracle
is being operated in the ARCHIVELOG mode are called offline, or archived redo log files.
A rollback segment is a disk storage area containing information that Oracle uses to identify and
undo transactions which were active at the time of a failure. Rollback segments contain all of the
information that is needed to roll back, or undo, any uncommitted changes made in a database as a result
of rolling forward.
A database backup is a copy of the database at a particular point in time. A database backup is
merely an image copy of a group of files, and is created using the host systems's file copying utilities.
4.2 Archiving
In order to ensure that the Environmental Restoration Information System (ERIS) production
database can be recovered from any type of media failure, the redo log files must be archived. Archiving
a file is the process of copying a filled online redo log file to a secondary storage device. For purposes
that apply to the ERIS production data base, Oracle will be operated in the ARCHIVELOG mode. In
this mode, recovery can be obtained by restoring a consistent copy of the database, and then using the
redo log file to reenter any work done since the time the last backup was taken. Archiving will be
enabled using the CREATE DATABASE command with the ARCHIVELOG option as follows:
- CREATE DATABASE erp
- DATAFILE `/usr/oracle/erp/erp_0l.dbs' SIZE 5000k REUSE
- LOGFILE `/usr/oracle/erp/erp01.rdo' SIZE 50k REUSE
- `/usr/oracle/erp/erp02.rdo SIZE 50k REUSE
- `/usr/oracle/erp/erp03.rdo SIZE 50k REUSE
- ARCHIVELOG
After the production database is created, archiving will be enabled by shutting down the database
and executing the this statement:
- ALTER DATABASE database ARCHIVELOG
To enable automatic archiving permanently for the database, two ORACLE INIT.ORA parameters
must be set as follows:
- INITERP.ORA
- LOG_ARCHIVE_START = TRUE
- LOG_ARCHIVE_DEST = D$ERP1:[ORAERP]ARCH
Archiving status and log sequence numbers within the database may be obtained by using the
following SQL*DBA command:
- SQLDBA> ARCHIVE LOG LIST
4.3 Database Files
If one or more database files have been lost due to a media failure, if all redo log files needed for
recovery are available, and if a current control file is available, normal media recovery can be used to
restore the database to a consistent state, exactly as the database existed at the time of failure. There are
two types of normal media recovery, online recovery that can be performed while the database is opened,
and offline recovery that is performed while the database is closed. Online recovery on a tablespace or
multiple tablespaces can be performed by executing the SQL*DBA RECOVER command as follows:
- CONNECT INTERNAL
- ALTER TABLESPACE tablespace OFFLINE
- RECOVER TABLESPACE tablespace
- ALTER TABLESPACE tablespace ONLINE
Offline recovery of the production database will be performed in four phases:
- SHUTDOWN ABORT
- Restore damaged database files from a backup with command:
- STARTUP DBA EXCLUSIVE MOUNT
- CONNECT INTERNAL
- ALTER DATABASE RENAME FILE
- `/usr/oracle/erp/erp_01.dbs
- TO `/usr/oracle/erp/erp_02.dbs
- (Perform this step if original name has become invalid)
- ALTER DATABASE DATAFILE `/usr/oracle/erp/erp_02.dbs ONLINE
- RECOVER DATABASE
- ALTER DATABASE erp OPEN
4.4 Backup Procedures
4.4.1 Offline and Online Backups
Oracle supports two types of backups, offline backups and online backups. An offline backup, also
known as a "cold" backup, is a backup that is taken while the database is shut down. It includes all
database files, a copy of the current control file, and all online redo log files. An online backup, also
known as a "hot" backup, is a backup that is taken while the database is operating. It includes copies
of all database files, a backup of the current control file, and all redo log files written during the period
of the backup from the online archives. (When online backup is used for media recovery all offline redo
log files written during the backup, as well as all offline redo log files archived from the time the backup
ended until the time the recovery began, must be applied.) It is important to remember that an online
backup does not include online redo log files. The procedures for each of these types of backups follow:
OFFLINE BACKUPS:
- Shut down the production database.
- Copy the database files, online redo log files, and the control files to backup storage.
- Restart the instance or the database.
ONLINE BACKUPS:
(To make and use online backups, the RDBMS must be operating in ARCHIVELOG mode)
- With the production database open and all tablespaces to be backed up online, enter the SQL statement:
- ALTER TABLESPACE tablespace BEGIN BACKUP (This statement must be issued for each tablespace to be backed up).
- Copy the database files to backup storage.
- Enter the SQL statement:
- ALTER TABLESPACE tablespace END BACKUP
4.4.2 Control Files
Control files are essential to the operation of the Oracle RDBMS. A control file contains the name
of the database, the names of database and redo log files, a timestamp showing when the database was
created, the current log sequence number, and other important information about database and redo log
files. Because of the importance of the control files, the following two steps will be taken to prevent their
loss:
- Each database will have at least two control files. They will be kept on separate disks so that all control files are not lost in the event of a media failure.
- In addition to using multiple control files, the control file should be backed up each time a database or redo log file is added, deleted, or renamed.
When two or more control files are used, Oracle writes to all of them simultaneously, keeping them
current. Oracle can be configured to write multiple control files by placing each control file's name in
the INITERP.ORA parameter CONTROL_FILES. A new control file can be added to the database by
performing the following steps:
- Shut down the production database.
- Copy the control file.
- Add the name of the new control file to the INIT-ERP.ORA parameter CONTROL_FILES.
- Restart the production database.
Control files will be backed up each time a tablespace is added or dropped, each time a database
file or a redo log file is added, dropped, or renamed, and each time the database is backed up.
Additionally, the production database will be backed up according to the schedule in Section 3.3. When
the production database is open, the following SQL*DBA command may be executed to make a backup
copy of the control file:
- ALTER DATABASE BACKUP CONTROLFILE TO backup_file_spec
For more detailed information on backup and recovery procedures, please refer to the most recent
revision of the Oracle RDBMS Database Administrator's Guide (6).
4.4.3 Frequency of Backups
Backups are performed according to the following schedule:
- Daily-Monday through Thursday backups are recycled the following Monday through Thursday; Friday backups are kept as weekly.
- Weekly-Weeks one through three are recycled beginning with week five, week four backup is kept as monthly.
- Monthly-Monthly backups are kept for twelve months and then recycled.
The backups will be written to tape using the UNIX TAR utility program. (For more
detailed information on this utility program, refer to A Practical Guide to the UNIX System(7).
Weekly and monthly tapes are stored at the INEEL Supercomputing Center. Refer to the ERIS
System Administration Procedures(8) for a more detailed description of the UNIX backup and restore
procedures.
4.5 Exporting and Importing Data
4.5.1 Exporting Data
Export utility writes data from an Oracle database to operating system files (on disk or tape) called
export files. The files are written in Oracle binary format. The export files can be stored in archives
or saved for future imports. The DBA can choose from three export modes:
- Table: This mode allows the exporting of specified tables. The DBA must qualify the
tables by specifying the owner. The default is to export all of the tables belonging
to a specific owner.
- User: This mode allows the exporting of all objects (such as tables, data, grants, and
indexes) belonging to one user.
- Full Database: Only DBA's can export in this mode, which exports all database objects except
those owned by SYS.
Export can be used in two ways, the command-line method and the interactive method. The
command-line method is more flexible and gives the user full control over the export. The user can
provide arguments on the command line by using Export keywords. Experienced Export users prefer
the command-line method because it allows them to take advantage of new features such as incremental
exports and parameter files. Through interactive method, Export gathers information using a series of
interactive prompts. Some of the prompts show a default answer which can be accepted by pressing
ENTER or RETURN. The interactive method does not allow incremental exports or parameter files.
(For more detailed information on this utility program, refer to A Practical Guide to the UNIX System (7).
Using the UNIX cron utiltiy, full system exports of both the development and production databases
are performed on a daily basis. These full exports can be used to regenerate the databases in extreme
conditions. These export files are archived to tape within the next twenty-four hour period.
4.5.2 Importing Data
The Import utility reads data from export files into an Oracle database. Like the Export utility,
Import can be used in two ways, the command-line method and the interactive method. The
characteristics of these methods for the Import utility are the same as they are for the Export utility.
When importing large tables, it is best to first import the table structure, and then import the data. When
importing large data files, it is best to use the command-line method, and to use the keyword
COMMIT=Y so the data will be committed after each array insert.
Note that files imported from another system DBA account may have unpredictable results. Always
assure that unique keys exist for any data imports. Failing to do so may cause the import to duplicate
data in the tables. (For more detailed information on this utility program, refer to ORACLE RDBMS
Database Administrator's Guide (6).
5.1 Database File Maintenance
Physical database files map to logical divisions of a database called tablespaces. A tablespace must
have at least one file, it may have many files. Most tablespace maintenance is done using SQL statements
referencing tablespaces. For instance, to add a datafile to a tablespace, use the following SQL command:
- ALTER TABLESPACE tablespace name
- ADD DATAFILE filespec
The DBA may wish to rename the files in a tablespace in order to relocate files to different devices
or to use files of different sizes. To rename a database file, use the following SQL command:
- ALTER TABLESPACE tablespace name
- RENAME DATAFILE text
5.2 Redo Log File Maintenance
The redo log files are used to record changes made to database blocks when transactions are
committed and for rolling forward during recovery. In order to perform any maintenance on the redo
log files, two conditions are required:
- The database must be mounted but closed.
- Connect to the database with the keyword INTERNAL.
Then, use the ALTER DATABASE command to add, drop, or rename log files. After the database
alteration has been completed, shutdown the instance and then restart.
Redo log files may need to be added to the database to increase online log storage, to change the
size of an online file, or to gain more flexibility regarding when the online redo log files are archived.
To add a new redo log file, connect to the database as described, then use the following SQL command:
- ALTER DATABASE database name
- ADD LOGFILE filespec
All redo log files should be a minimum of 50 Kbytes in size. The DBA may wish to drop a redo
log file in order to change the size of a redo log file, or to decrease the number of redo log files that the
database may write to. To drop a new redo log file, connect to the database as described, then use the
following SQL command:
- ALTER DATABASE database name
- DROP LOGFILE filespec
After completing the database alteration, shutdown the instance and then restart.
The DBA may wish to rename redo log files in order to specify a file which is larger, smaller, or
in a different location than existing redo log files. To rename a new redo log file, connect to the database
as described, then use the following SQL command:
- ALTER DATABASE database name
- RENAME FILE filespec
5.3 Rollback Segment Maintenance
5.3.1 Creating Rollback Segments
Rollback segments contain information required for read consistency and to undo changes made by
transactions that roll back. Most databases have multiple rollback segments. There are two types of
rollback segments, public and private. Public rollback segments form a pool of segments that can be
acquired by any instance needing an additional rollback segment, while private rollback segments are
usually associated with one and only one instance. By default, a rollback segment is private (with the
exception of the SYSTEM rollback segment) and can be used only by an instance naming-it the
ROLLBACK SEGMENTS parameter. To create a public rollback segment, use thefollowing SQL
command:
- CREATE PUBLIC ROLLBACK SEGMENT rs_name
- TABLESPACE tablespace name
- STORAGE storage parameter
To create a private rollback segment, use the following SQL command:
- CREATE ROLLBACK SEGMENT rs_name
- TABLESPACE tablespace name
- STORAGE storage parameter
When a rollback segment is created, you can optionally specify parameters for the segment's
extents. The syntax for the storage parameters is:
- STORAGE (
- [INITIAL integer] [NEXT integer]
- [MINEXTENTS integer] [MAXEXTENTS integer]
- [PCTINCREASE integer]
5.3.2 Altering Rollback Segments
Rollback segment storage parameters for a specific rollback segment can be altered using the
following command:
- ALTER ROLLBACK SEGMENT rs_name
- STORAGE (
- [NEXT integer]
- [MAXEXTENTS integer]
- [PCTINCREASE integer]
However, the ALTER ROLLBACK SEGMENT command only affects future extents used by the
rollback segments.
5.3.3 Monitoring Rollback Segments
To monitor how much space rollback segments are using, query the data dictionary views
DBA_ROLLBACK_SEGS and DBA_SEGMENTS. You can also use the SQL*DBA command
MONITOR ROLLBACK to see information about rollback segments. To see the current rollback
segments of the database, query the DBA_ROLLBACK_SEGS view of the data dictionary with the
following command:
- SELECT SEGMENT NAME, TABLESPACE_NAME, STATUS
- FROM SYS.DBA_ROLLBACK_SEGS
This query displays the name of the rollback segment, the tablespace it is assigned to, and whether
or not the rollback segment is in use.
5.3.4 Dropping Rollback Segments
A rollback segment may need to be dropped for reasons such as a segment becomes to fragmented,
having many extents; a segment is no longer needed because the instance using it is no longer accessing
the database; the status may need to be changed to PUBLIC or private; or it should be relocated to
another tablespace. To drop a rollback segment, follow these steps:
- Check that the database is open
- Connect using a DBA username
- Make sure that the rollback segment to be dropped is not in use by any instance by querying the data dictionary view DBA_ROLLBACK_SEGS
- Enter the SQL statement:
- DROP (PUBLIC) ROLLBACK SEGMENT name
5.4 Tablespace Maintenance
5.4.1 Creating Tablespaces
A tablespace may need to be added to the database for any of the following reasons:
- for the specific allocation of memory segments
- for non-SYSTEM rollback segments
- to spread and control I/O contention
- to facilitate the backup/recovery plan
- to control resource use on a user basis
- to separate table and index storage
To create a new tablespace, use the following syntax:
- CREATE TABLESPACE tablespace name
- DATAFILE filespec
- [DEFAULT STORAGE]
- [INITIAL integer] [NEXT integer]
- [MINEXTENTS integer] [MAXEXTENTS integer]
- [PCTINCREASE integer]
- [ONLINE] [OFFLINE]
By default, a tablespace is always online after it has been created.
One characteristic of a tablespace is that is sets the default storage parameters and limits for tables
or indexes created in the tablespace. To alter these storage parameters, use the following syntax:
- ALTER TABLESPACE tablespace name
- [DEFAULT STORAGE]
- [INITIAL integer] [NEXT integer]
- [MINEXTENTS integer] [MAXEXTENTS integer]
- [PCTINCREASE integer]
5.4.2 Enlarging a Tablespace
To increase the size of a tablespace, a new file must be added to it. To add a new database file,
follow these steps:
- The database should be open; the tablespace can be online or offline
- Use SQL*DBA and connect to the database as DBA
- Use the following syntax:
- ALTER TABLESPACE tablespace name
- ADD DATAFILE filespec
5.4.3 Renaming a Tablespace
A tablespace may need to be renamed in order to relocate files to different devices to use files of
different sizes:
- ALTER DATABASE database name
- RENAME FILE filespec
5.4.4 Dropping a Tablespace
Tablespaces may be dropped even thought they have data in them. To drop an online tablespace,
use the following syntax:
- DROP TABLESPACE tablespace name
5.5 Table Maintenance
5.5.1 Determining Table Space Requirements
To estimate the space required by a single, non-clustered table, use the following formula:
- x is the number of rows per table.
- y is the number of columns per table.
- len is the average column length.
- A block requires an average of 90 bytes of overhead.
- A row requires an average of 5 bytes of overhead, including information in the block's row directory.
- A column requires I byte of overhead.
The fully annotated formula resulting in the number of blocks required per non-clustered table is:
- # blocks = x rows * (5 bytes + y cols * (1 byte + len)) / (blocksize - 90 bytes) * (1 - PCTFREE/l00)
or expressed more concisely:
- # blocks = x * (5 + y * (1 + len)) / (blocksize - 90 bytes) * (1 - PCTFREE/100)
To calculate the number of bytes, multiply the result of the above calculation by the blocksize in
bytes. The total number of bytes can be used for the INITIAL storage parameter. Less space will be
required if there is a large number of trailing nulls, and more space will be required if there is a large
number of long columns or rows.
One the table exists, the storage parameters can be changed using either the ALTER TABLE or ALTER
TABLESPACE command. All of the parameters except the INITIAL and the MINEXTENTS can be
altered.
5.5.2 Index Storage
Indexes for tables are created and stored independently from the tables. An index can be created
or dropped anytime after a table is created. Indexes for tables can be in different tablespaces and
different devices from each other, and from the table's data. To ensure access to a table, the tablespaces
containing its data and indexes must be online. It is usually best to use the default storage PCTFREE
parameters when creating indexes. It is best if the index is densely packed, so that fewer blocks need
to be read when using the index. The storage parameter for an index can be altered with the SQL
statement ALTER INDEX. Changes in the extent parameters will effect only future extents, not extents
which currently exists.
- EG&G Idaho, Inc., Conduct of Operations for the Computer Applications and Technology Transfer Group, SP2.2 "Software Configuration Management." May 1, 1991.
- EG&G Idaho, Inc., Conduct of Operations for the Computer Applications and Technology Transfer Group, SP2.4 "Software Configuration Control Board." May 1, 1991.
- System Quality Assurance Plan for the Environmental Restoration Information System, EG&G Idaho, Inc., EGG-WM-9760, latest revision.
- System Configuration Management Plan for the Environmental Restoration Information System, EG&G Idaho, Inc., EGG-WM-9759, latest revision.
- Configuration Control Procedures for the Environmental Restoration Information System, EG&G Idaho, Inc., latest revision.
- ORACLE RDBMS Database Administrator's Guide, latest revision, Oracle Corporation.
- Mark G. Sobell, A Practical Guide To The UNIX System, Second Edition, The Benjamin Cummings Publishing Company, Inc., 1989.
- General Requirements for the Environmental Restoration Information System, EG&G Idaho, Inc., EGG-WM-86l5, July 1989.
- Environmental Restoration Information System Operating Procedures, latest revision.
- Transfer of Data From ERIS Development to ERIS Production Databases, EG&G ERD-SOP 14.1.2, December, 1992.
Notification Procedure
When either the development (eris) or production (erip) database is unaccessible by any of the
Oracle tools for a minimum period of thirty minutes, the database is determined to be "down". When
a "down" database occurs, it is essential that the following persons be notified: the Environmental
Information Systems unit manager, the ERP-Data Management unit manager, the ERIS project
coordinator, and the ERIS customer representative.
Within three working days of having the database fully functional, the database administrator will
issue a report to the persons listed above defining the problem, stating the cause of the problem, and the
solution for the problem. The format of the report follows:
TO:
DATE:
SUBJECT:
PROBLEM DEFINITION:
PROBLEM CAUSE:
PROBLEM SOLUTION:
