Checks the internal integrity of database data structures.
The RMU Verify command does not verify the data itself. You
can verify specific portions of a database or the integrity of
routines stored in the database by using qualifiers.
If you specify the RMU Verify command without any qualifiers, a
database root file verification and full page verification of the
area inventory page (AIP) and the area bit map (ABM) pages in the
default RDB$SYSTEM storage area are performed. Also, the snapshot
files and after-image journals are validated (even if journaling
has been disabled).
The RMU Verify command checks space area management (SPAM) pages
for proper format. The contents of the individual entries are
verified as the individual data pages are verified. The command
does not attempt to determine if data within rows is reasonable
or plausible.
1 – Description
The RMU Verify command checks the internal integrity of database
data structures. Oracle Corporation strongly recommends that
you verify your database following any kind of serious system
malfunction. You should also verify your database as part of
routine maintenance, perhaps before performing backup operations.
You can use the various qualifiers to perform verification of the
maximum number of database areas in the time available.
NOTE
If you use the RMU Convert command with the Nocommit
qualifier to convert a database created prior to Oracle Rdb
Version 6.1, and then use the RMU Convert command with the
Rollback qualifier to revert to the prior database structure
level, subsequent verify operations might return an RMU-W-
PAGTADINV warning message. See the Usage_Notes help entry
under this command for details.
2 – Format
(B)0[m RMU/Verify root-file-spec
[4mCommand[m [4mQualifiers[m x [4mDefaults[m
x
/All x See description
/Areas [ = storage-area-list] x No Area checking performed
/Checksum_Only x Full page verification
/[No]Constraints = [(Options)] x /NoConstraint
/[No]Data x /Data when /Indexes is used
/End=page-number x /End=last-page
/[No]Functions x /Nofunctions
/Incremental x See description
/Indexes [ = index-list] x No index checking performed
/Lareas [ = logical-area-list] x No LAREA checking performed
/[No]Log x Current DCL verify value
/Output=file-spec x SYS$OUTPUT
/[No]Root x /Root
/[No]Routines x /Noroutines
/[No]Segmented_Strings x See description
/Snapshots x No snapshot verification
/Start=page-number x /Start=1
/Transaction_Type=option x /Transaction_Type=Protected
3 – Parameters
3.1 – root-file-spec
The Oracle Rdb database to verify. The default file extension is
.rdb.
4 – Command Qualifiers
4.1 – All
All
When you specify the All qualifier, the entire database is
checked, including any external routines. Specifying the All
qualifier is equivalent to issuing the list of qualifiers shown
in the following command:
$ RMU/VERIFY/ROOT/CONSTRAINTS/INDEXES/DATA/AREAS -
_$ /SNAPSHOTS/LAREAS/ROUTINES MF_PERSONNEL.RDB
If you do not specify the All qualifier, the verification
requested by the other qualifiers you specify is performed.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
4.2 – Areas
Areas[=storage-area-list]
Specifies the storage areas of the database to verify. You can
specify storage areas by name or by the area's ID number. When
you specify the storage area by name, each storage area name must
be the name defined in the SQL CREATE STORAGE AREA statement for
the storage area, not the storage area file name. If you list
multiple storage areas, separate the storage area names or ID
numbers with a comma, and enclose the storage area list within
parentheses. The Areas qualifier with no arguments (or Areas=*)
directs Oracle RMU to verify all storage areas of the database.
With a single-file database, if you do not specify a storage area
name, the RDB$SYSTEM storage area is verified.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
The Areas qualifier can be used with indirect file references.
See the Indirect-Command-Files Help entry for more information.
When the Areas qualifier is not specified, Oracle RMU does not
verify any storage areas.
4.3 – Checksum Only
Checksum_Only
Specify with the Areas qualifier to perform only checksum
verification of pages. This reduces the degree of verification
done on a database page. While the RMU Verify command executes
faster with the Checksum_Only qualifier than without it, it does
not verify pages completely. This qualifier allows you to make
trade-offs between speed of verification and thoroughness of
verification. For more information on these trade-offs, see the
Oracle Rdb Guide to Database Maintenance.
If this command finds a problem with a certain page, then that
page can be verified in depth by using other qualifiers, such as
Indexes, Areas, or Lareas.
Note that you can accomplish the same degree of verification
during a backup operation by specifying the Checksum qualifier
with the RMU Backup command. The advantage of specifying the
Checksum qualifier with the RMU Backup command is that the
checksum operation takes place concurrently with the backup
operation.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
The default is for full verification of pages.
4.4 – Constraints
Constraints
Constraints[=(Constraints=(list))]
Constraints[=(Tables=(list))]
Constraints[=(Tables=(list), Constraints=(list))]
Noconstraints
Specifies which constraints Oracle RMU is to load and execute
to check the integrity of data in the database. In addition,
external routines (procedures and functions) referenced by
constraints are activated and executed. Any exceptions produced
cause the verify operation to report a failure. See the
description of the routines qualifier for information on how
routines are activated and executed.
The options are as follows:
o Tables=(list)
Specifies the table for which constraints are to be checked.
If you specify more than one table, separate each table name
with a comma and enclose the list in parentheses. You can
specify the wildcard character, the asterisk (*), instead of
a table list to indicate that you want constraints checked
for all tables in the database. This option is useful if you
issued an RMU Load command with the Noconstraints qualifier.
o Constraints=(list)
Specifies the constraints which you want Oracle RMU to load
and execute. If you specify more than one constraint, separate
each constraint name with a comma and enclose the list in
parentheses. You can specify the wildcard character, the
asterisk (*), instead of a constraint list to indicate that
you want all constraints checked for the database.
o (Tables=(list), Constraints=(list))
You can specify both the Tables and Constraints options to
specify which combination of tables and constraints you
want Oracle RMU to verify. If you specify the wildcard
character, the asterisk (*), for the Tables option and a
named constraint or constraints for the Constraint option
within the same Oracle RMU command line, Oracle RMU verifies
all constraints.
See the Oracle Rdb Guide to Database Maintenance for more
information on verifying constraints.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
The default is the Noconstraints qualifier. When you specify
the Noconstraints qualifier, Oracle RMU does not verify any
constraints.
4.5 – Data
Data
Nodata
Specifies whether consistency checks are made between indexes and
tables. When you specify the Data qualifier, Oracle RMU checks
that every row to which an index points is a valid row for the
table and it checks that every row in a table is pointed to by
every index defined on the table. See the description of the
Indexes qualifier for more information on how these comparisons
are made.
The Data qualifier is valid only when it is used with the Indexes
qualifier.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
The default is the Data qualifier.
4.6 – End
End=page-number
Specifies the last page to be verified. This qualifier is used in
conjunction with the Areas and Lareas qualifiers. If you do not
use the End qualifier, Oracle RMU verifies all pages between the
first page (or the page specified in the Start qualifier) and the
last page of the storage area.
The End qualifier is valid only when you specify the Areas or
Lareas qualifier.
See the Usage Notes entry in this command for the rules that
determine which other qualifiers can be used in combination on
the same RMU Verify command line.
4.7 – Functions
Functions
Nofunctions
This qualifier is synonymous with the Routines qualifier. See the
description of the Routines qualifier.
4.8 – Incremental
Incremental
Directs Oracle RMU to verify database pages that have changed
since the last full or incremental verification. Oracle RMU
stores timestamps in the database root file for both full
and incremental verifications. To determine which pages
have changed since the last verify operation, Oracle RMU
compares these timestamps with the page timestamps. The page
timestamps are updated whenever pages are updated. An incremental
verification performs the same number of I/O operations as a
full verification, but the incremental verification takes fewer
CPU cycles than a full verification, allowing you to perform
incremental verifications more frequently than you would perform
full ones. The default is to perform a full verification.
NOTE
If you use the Incremental qualifier with the RMU Verify
command, Oracle Corporation recommends that you use it only
with the All qualifier and not with any other qualifiers.
The timestamps in the database root file are updated during
full and incremental verifications only when the All
qualifier is specified. Therefore, if you do not specify
the All qualifier, two successive incremental verifications
of the same storage area of the database perform the same
verifications. This means that the second incremental
verification does not pass over pages verified by the first
incremental verification, contrary to what you might expect.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
If the Incremental qualifier is not specified, all requested
pages are verified, regardless of the timestamp.
4.9 – Indexes
Indexes[=index-list]
Verifies the integrity of all but disabled indexes in the
database if you specify the Indexes or the Indexes=* qualifier;
verifies the integrity of a specific index, or of multiple
indexes if you provide an index list. If you list multiple
indexes, separate the index names with a comma, and enclose the
index list within parentheses.
Beginning with Oracle Rdb V7.0, Oracle RMU uses a new method to
verify indexes. In prior versions, the verify operation tried
to retrieve the table row to which the index pointed. Beginning
with Oracle Rdb V7.0, the verify operation creates a sorted list
of all dbkeys for a table and a sorted list of all dbkeys in an
index. By comparing these two lists, the verify operation can
detect any cases of an index missing an entry for a data row. In
addition, the verify operation runs faster. This comparison of
dbkeys occurs at the end of the verify operation. If you specify
the log qualifier, you see messages similar to the following to
indicate that the comparison is occurring:
%RMU-I-IDXVERSTR, Index data verification of logical area
60 (DEGREES) started.
%RMU-I-IDXVEREND, Index data verification of logical area
60 finished.
In addition, beginning in Oracle Rdb V7.0, when you verify an
index with the Data qualifier (the default), Oracle RMU also
verifies the logical areas referenced by the indexes. See Example
5 in the Examples help entry under this command.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
By default, Oracle RMU does not verify indexes.
The Indexes qualifier can be used with indirect file references.
See the Indirect-Command-Files Help entry for more information.
4.10 – Lareas
Lareas[=logical-area-list]
Specifies the storage area pages allocated to a logical area
or logical areas that you want verified. If you list multiple
logical areas, separate the logical area names with a comma,
and enclose the logical area list within parentheses. The Lareas
qualifier with no arguments (or Lareas=*) directs Oracle RMU to
verify all logical areas of the database. When a logical area is
verified, each page in the area is read and verified sequentially
starting at the first page.
If an index name is specified with the Lareas qualifier, the
index is verified, but it is not verified as a logical area.
In this case, the first index record is fetched (which could be
on any page) and the verification follows the structure of the
index. (For example, if the index record points to other index
records, then those records are fetched and verified. If the
index node is a leaf node, then the data record is fetched and
verified. These data pages might reside in different logical
areas.)
Use this qualifier to verify one or more tables.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
The Lareas qualifier can be used with indirect file references.
See the Indirect-Command-Files Help entry for more information.
By default, Oracle RMU does not verify logical areas.
4.11 – Log
Log
Nolog
Specifies whether the processing of the command is reported to
SYS$OUTPUT. By default, SYS$OUTPUT is your terminal. Specify the
Log qualifier to request that each verify operation be displayed
to SYS$OUTPUT and the Nolog qualifier to prevent this display.
If you specify neither, the default is the current setting of the
DCL verify switch. (The DCL SET VERIFY command controls the DCL
verify switch.)
When you specify the Log qualifier, Oracle RMU displays the time
taken to verify each database area specified and the total time
taken for the complete verification operation. The display from
the Log qualifier is also useful for showing you how much of the
verification operation is completed.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
4.12 – Output
Output=file-spec
Specifies the name of the file where output will be sent. The
default is SYS$OUTPUT. When you specify a file name, the default
output file type is .lis.
If you specify both the Log qualifier and the Output qualifier,
the messages produced by the Log qualifier and any error messages
are directed into the output file specification. If you specify
only the Output qualifier, only error messages are captured
in the output file. See the Usage Notes entry in this command
for the rules that determine which qualifiers can be used in
combination on the same RMU Verify command line.
4.13 – Root
Root
Noroot
Specifies that, in a multifile database, only fields in the
database root (.rdb) file and all the pointers to the database
(.rda, .snp, .aij) files are verified. The snapshot (.snp) files
are validated; that is, only the first page is checked to make
sure that it is indeed an .snp file and belongs to the database
being verified. If after-image journaling is enabled, the .aij
files are validated. The AIP and ABM pages are verified when you
specify the Root qualifier.
If you specify the Noroot qualifier, and no other qualifiers,
only the AIP pages are verified. If you specify the Noroot
qualifier, and the Areas or the Lareas qualifier, ABM and SPAM
pages are verified as the other pages in the storage area or
logical area are verified.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
You can specify the Root qualifier for a single-file database.
The default is the Root qualifier.
4.14 – Routines
Routines
Noroutines
The Routines qualifier verifies the integrity of all routine
(function and procedure) definitions stored in the database.
Oracle RMU performs the verification by activating and
deactivating each external routine, one at a time. Any exceptions
produced cause the verify operation to report a failure.
The Routines qualifier verifies that the shareable image is
located where expected, is accessible, and that the correct entry
point is at this location. The expected location is that which
was specified in the SQL CREATE FUNCTION or CREATE PROCEDURE
statement. If the shareable image is not in the expected
location, is not accessible, or the entry point is not at the
expected location, you receive an error message.
If Oracle RMU is installed with SYSPRV, any external routine
image for a routine that is registered with client-site binding
must meet the following criteria or the RMU Verify command cannot
check for the existence of the entry point for the routine in the
image:
o It must be installed.
o It must have been specified with an image file specification
that uses only logicals defined with the DCL /SYSTEM and
/EXECUTIVE qualifiers.
In addition, the user issuing the RMU Verify command must have
OpenVMS SYSPRV in order for the routine to be activated.
The Noroutines qualifier specifies that routine interface not be
verified.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
By default, Oracle RMU does not verify any routines.
4.15 – Segmented Strings
Segmented_Strings
Nosegmented_Strings
Verifies all list (segmented string) data for each column, in
each table in any of the two types of storage areas: read/write
and read-only (on read/write disk devices). When you specify
the RMU Verify command with the All qualifier, all list data
(segmented strings) in all tables is verified in the database.
The Segmented_Strings qualifier can only be used with the Lareas
qualifier and has the following meanings when used with this
qualifier:
o RMU Verify command with the Lareas=* and the Segmented_Strings
qualifiers.
Segmented strings in all tables are verified.
o RMU Verify command with the Lareas=(LAREA_1, . . . ,LAREA_N)
and the Segmented_Strings qualifiers.
Segmented strings in tables LAREA_1, . . . ,LAREA_N are
verified.
If the Segmented_Strings qualifier is omitted, there is no
list data verification.
The Segmented_Strings qualifier verifies all list data in
each column of each row in the database. The verify operation
tries to fetch all pointer segments and all data segments from
the pointer segments, and verifies all header information,
including the total length of the segment, the number of
pointer segments, the number of data segments, and the length
of the longest segment for the list data.
4.16 – Snapshots
Snapshots
Verifies the snapshot area of the specified storage areas up
to the page header level. The Snapshots qualifier only performs
checksum verification of snapshot pages.
The Snapshots qualifier is valid only when you also specify the
Areas qualifier.
See the Usage Notes entry in this command for the rules that
determine which other qualifiers can be used in combination on
the same RMU Verify command line.
The Snapshots qualifier can be used with indirect file
references. See the Indirect-Command-Files Help entry for more
information.
By default, Oracle RMU does not verify snapshots.
4.17 – Start
Start=page-number
Specifies the first page to be verified. This qualifier is used
in conjunction with the Areas and Lareas qualifiers. If you do
not use the Start qualifier, the verification begins with the
first page of the storage area.
The Start qualifier is valid only when you specify the Areas or
Lareas qualifier also.
See the Usage Notes entry in this command for the rules that
determine which other qualifiers can be used in combination on
the same RMU Verify command line.
4.18 – Transaction Type
Transaction_Type=option
Sets the retrieval lock for the storage areas being verified.
Use one of the following keywords to control the transaction
mode:
o Automatic
When Transaction_Type=Automatic is specified, the transaction
type depends on the current database settings for snapshots
(enabled, deferred, or disabled), transaction modes available
to this user, and the standby status of the database.
o Read_Only
Starts a Read_Only transaction.
o Exclusive
Starts a Read_Write transaction and reserves the table for
Exclusive_Read.
o Protected
Starts a Read_Write transaction and reserves the table for
Protected_Read. Protected mode is the default.
o Shared
Starts a Read_Write transaction and reserves the table for
Shared_Read.
Use one of the following options with the keyword Isolation_
Level=[option] to specify the transaction isolation level:
o Read_Committed
o Repeatable_Read
o Serializable. Serializable is the default setting.
Refer to the SET TRANSACTION statement in the Oracle Rdb SQL
Reference Manual for a complete description of the transaction
isolation levels.
Specify the wait setting by using one of the following keywords:
o Wait
Waits indefinitely for a locked resource to become available.
Wait is the default behavior.
o Wait=n
The value you supply for n is the transaction lock timeout
interval. When you supply this value, Oracle Rdb waits n
seconds before aborting the wait and the RMU Verify session.
Specifying a wait timeout interval of zero is equivalent to
specifying Nowait.
o Nowait
Does not wait for a locked resource to become available.
See the Usage Notes entry in this command for the rules that
determine which qualifiers can be used in combination on the same
RMU Verify command line.
5 – Usage Notes
o To use the RMU Verify command for a database, you must have
the RMU$VERIFY privilege in the root file access control
list (ACL) for the database or the OpenVMS SYSPRV or BYPASS
privilege. You must also have the SQL DBADM privilege.
o The rules that determine which qualifiers can be used in
combination on the same RMU Verify command line are as
follows:
- The Incremental, Log, Output, and Transaction_Type
qualifiers can be used in combination with any other
qualifiers on the same RMU Verify command line.
- If the All qualifier is specified, the only other
qualifiers you can specify on the same command line are:
* Noroutines (or Nofunctions)
* Nosegmented_Strings
- If the All qualifier is not specified, then any combination
of the following qualifiers can be specified on the same
command line:
* Areas
* Constraints
* [No]Functions
* Indexes
* Lareas
* [No]Root
* [No]Routines
- You must specify the Areas qualifier to specify the
Checksum_Only or Snapshots qualifier.
- You must specify the Lareas qualifier to specify the
Segmented_Strings qualifier.
- You must specify either the Areas or Lareas qualifier to
specify the Start and End qualifiers.
- You cannot specify the Indexes qualifier on the same RMU
Verify command line with the Start and End qualifiers.
- You must specify the Indexes qualifier to specify the
[No]Data qualifier.
o You can significantly improve the performance of RMU Verify
for your database by employing the verification strategies
described in the Oracle Rdb Guide to Database Maintenance. In
addition, detected asynchronous prefetch should be enabled to
achieve the best performance of this command. Beginning with
Oracle Rdb V7.0, by default, detected asynchronous prefetch
is enabled. You can determine the setting for your database by
issuing the RMU Dump command with the Header qualifier.
If detected asynchronous prefetch is disabled, and you do not
want to enable it for the database, you can enable it for your
Oracle RMU operations by defining the following logicals at
the process level:
$ DEFINE RDM$BIND_DAPF_ENABLED 1
$ DEFINE RDM$BIND_DAPF_DEPTH_BUF_CNT P1
P1 is a value between 10 and 20 percent of the user buffer
count.
o If you use the RMU Convert command with the Nocommit qualifier
to convert a database created prior to Oracle Rdb Version
6.0, and then use the RMU Convert command with the Rollback
qualifier to revert to the previous database structure level,
subsequent RMU Verify commands might produce messages such as
the following:
%RMU-W-PAGTADINV, area RDB$SYSTEM, page 1
contains incorrect time stamp
expected between 14-APR-1992 15:55:25.74
and 24-SEP-1993 13:26:06.41, found:
Beginning in Oracle Rdb Version 6.0, the fast incremental
backup feature alters the page header of updated SPAM pages to
record which page ranges have been updated since the previous
full backup operation. The RMU Verify command in versions
of Oracle Rdb prior to Version 6.0 does not contain code to
understand the updated page header and issues the PAGTADINV
warning when encountering an updated SPAM page header. The
update page headers are only detected by the RMU Verify
command and do not affect the run-time operation of Oracle
Rdb. To correct the updated SPAM pages, you can use the RMU
Repair command with the Spams qualifier as follows:
$ RMU/VERIFY/ALL/NOLOG MF_PERSONNEL
%RMU-W-PAGTADINV, area RDB$SYSTEM, page 1
contains incorrect time stamp
expected between 14-APR-1992 15:55:25.74
and 24-SEP-1993 13:26:06.41, found:
$
$ RMU/REPAIR/SPAMS MF_PERSONNEL
%RMU-I-FULBACREQ, A full backup of this database should be performed
after RMU/REPAIR
$
$ RMU/VERIFY/ALL/NOLOG MF_PERSONNEL
$
o The RMU Verify command ignores any constraint that has
been disabled (with the SQL ALTER TABLE enable-disable
clause) unless you specify the constraint name in the
Constraints=(Constraints=list) qualifier of the RMU Verify
command. If the Constraints qualifier is specified without a
list, disabled constraints are ignored.
By specifying the name of a disabled constraint in the
Constraints=(Constraints=list) qualifier, you can check it
periodically without having to reenable it. You might use
this to provide a business rule in the database that needs
checking only occasionally. This is a useful practice if the
overhead of checking the constraint during operating hours
is too expensive, or if it is already being enforced by the
application.
o The number of work files used by the RMU Verify command is
controlled by the RDMS$BIND_SORT_WORKFILES logical name. The
allowable values are 1 through 10 inclusive, with a default
value of 2. The location of these work files can be specified
with device specifications, using the SORTWORKn logical
name (where n is a number from 0 to 9). See the OpenVMS
documentation set for more information on using SORT/MERGE.
See the Oracle Rdb7 Guide to Database Performance and Tuning
for more information on using these Oracle Rdb logical names.
Because two separate sort streams are used internally by the
RMU Verify command when the Index qualifier is specified,
the number of work files specified is used for each stream.
For example, if RDM$BIND_SORT_WORKFILES is defined to be 10,
twenty work files are created.
6 – Examples
Example 1
The following command verifies the entire mf_personnel database
because the All qualifier is specified:
$ RMU/VERIFY/ALL/LOG MF_PERSONNEL.RDB
Example 2
The following command verifies the storage areas EMPIDS_LOW,
EMPIDS_MID, and EMPIDS_OVER in the mf_personnel database:
$ RMU/VERIFY/AREAS=(EMPIDS_LOW,EMPIDS_MID,EMPIDS_OVER)/LOG -
_$ MF_PERSONNEL.RDB
Example 3
The following command performs only a checksum verification on
all the storage areas in the database called large_database. The
Checksum_Only qualifier quickly detects obvious checksum problems
with the database. If a checksum problem is found on a page, you
can dump the page by using the RMU Dump command, and verify the
appropriate logical areas and indexes.
$ RMU/VERIFY/AREAS=*/CHECKSUM_ONLY/LOG LARGE_DATABASE
Example 4
The following command verifies the Candidates and Colleges
tables:
$ RMU/VERIFY/LAREAS=(CANDIDATES,COLLEGES)/LOG MF_PERSONNEL.RDB
Example 5
The following example displays the behavior of the index
verification method Oracle RMU employs beginning in Oracle Rdb
V7.0. The first RMU Verify command shows the log output when the
command is issued under Oracle Rdb V6.1. The second RMU Verify
command shows the log output when the command is issued under
Oracle Rdb V7.0.
$ @SYS$LIBRARY:RDB$SETVER 6.1
$ SET DEF DB1:[V61]
$ RMU/VERIFY/INDEXES=EMP_EMPLOYEE_ID/DATA MF_PERSONNEL.RDB/LOG
%RMU-I-BGNROOVER, beginning root verification
%RMU-I-ENDROOVER, completed root verification
%RMU-I-DBBOUND, bound to database "DB1:[V61]MF_PERSONNEL.RDB;1"
%RMU-I-OPENAREA, opened storage area RDB$SYSTEM for protected retrieval
%RMU-I-BGNAIPVER, beginning AIP pages verification
%RMU-I-ENDAIPVER, completed AIP pages verification
%RMU-I-BGNABMSPM, beginning ABM pages verification
%RMU-I-OPENAREA, opened storage area MF_PERS_SEGSTR for protected retrieval
%RMU-I-ENDABMSPM, completed ABM pages verification
%RMU-I-BGNNDXVER, beginning verification of index EMP_EMPLOYEE_ID
%RMU-I-OPENAREA, opened storage area EMPIDS_LOW for protected retrieval
%RMU-I-OPENAREA, opened storage area EMPIDS_MID for protected retrieval
%RMU-I-OPENAREA, opened storage area EMPIDS_OVER for protected retrieval
%RMU-I-ENDNDXVER, completed verification of index EMP_EMPLOYEE_ID
%RMU-I-CLOSAREAS, releasing protected retrieval lock on all storage areas
%RMU-S-ENDVERIFY, elapsed time for verification : 0 00:00:09.14
$ @SYS$LIBRARY:RDB$SETVER 7.0
$ SET DEF DB1:[V70]
$ RMU/VERIFY/INDEXES=EMP_EMPLOYEE_ID/DATA MF_PERSONNEL.RDB/LOG
%RMU-I-BGNROOVER, beginning root verification
%RMU-I-ENDROOVER, completed root verification
%RMU-I-DBBOUND, bound to database "DB1:[V70]MF_PERSONNEL.RDB;1"
%RMU-I-OPENAREA, opened storage area RDB$SYSTEM for protected retrieval
%RMU-I-BGNAIPVER, beginning AIP pages verification
%RMU-I-ENDAIPVER, completed AIP pages verification
%RMU-I-BGNABMSPM, beginning ABM pages verification
%RMU-I-ENDABMSPM, completed ABM pages verification
%RMU-I-BGNNDXVER, beginning verification of index EMP_EMPLOYEE_ID
%RMU-I-OPENAREA, opened storage area EMPIDS_LOW for protected retrieval
%RMU-I-OPENAREA, opened storage area EMPIDS_MID for protected retrieval
%RMU-I-OPENAREA, opened storage area EMPIDS_OVER for protected retrieval
%RMU-I-ENDNDXVER, completed verification of index EMP_EMPLOYEE_ID
%RMU-I-BSGPGLARE, beginning verification of EMPLOYEES logical area
as part of EMPIDS_LOW storage area
%RMU-I-ESGPGLARE, completed verification of EMPLOYEES logical area
as part of EMPIDS_LOW storage area
%RMU-I-BSGPGLARE, beginning verification of EMPLOYEES logical area
as part of EMPIDS_MID storage area
%RMU-I-ESGPGLARE, completed verification of EMPLOYEES logical area
as part of EMPIDS_MID storage area
%RMU-I-BSGPGLARE, beginning verification of EMPLOYEES logical area
as part of EMPIDS_OVER storage area
%RMU-I-ESGPGLARE, completed verification of EMPLOYEES logical area
as part of EMPIDS_OVER storage area
%RMU-I-IDXVERSTR, Beginning index data verification of logical area 69
(EMPLOYEES).
%RMU-I-IDXVEREND, Completed data verification of logical area 69.
%RMU-I-IDXVERSTR, Beginning index data verification of logical area 70
(EMPLOYEES).
%RMU-I-IDXVEREND, Completed data verification of logical area 70.
%RMU-I-IDXVERSTR, Beginning index data verification of logical area 71
(EMPLOYEES).
%RMU-I-IDXVEREND, Completed data verification of logical area 71.
%RMU-I-CLOSAREAS, releasing protected retrieval lock on all storage areas
%RMU-S-ENDVERIFY, elapsed time for verification : 0 00:00:11.36
Example 6
The following example loads data into a table, verifies
the table, and then identifies loaded rows that violated a
constraint.
Because the Noconstraints qualifier is specified with the RMU
Load command, data that violates database integrity might be
added to the database. The second RMU Verify command verifies the
table that was just loaded and reveals that data that violates
constraints on the table was indeed loaded.
An SQL command is issued to determine which rows violated the
constraint so that they can either be removed from the database,
or added to the EMPLOYEES table to restore database integrity.
The final RMU Verify command checks the constraint again to
ensure that changes made have restored the integrity of the
database.
$ !
$ ! Load data into the JOB_HISTORY table of the mf_personnel database.
$ ! Specify the Noconstraints qualifier:
$ !
$ RMU/LOAD/RECORD_DEFINITION=(FILE=JOB_HIST.RRD, FORMAT=TEXT) -
_$ MF_PERSONNEL.RDB JOB_HISTORY JOB_HIST.UNL/NOCONSTRAINTS
%RMU-I-DATRECREAD, 18 data records read from input file.
%RMU-I-DATRECSTO, 18 data records stored.
$ !
$ ! Verify the JOB_HISTORY table:
$ !
$ RMU/VERIFY/CONSTRAINTS=(TABLE=JOB_HISTORY) MF_PERSONNEL.RDB
%RMU-W-CONSTFAIL, Verification of constraint "JOB_HISTORY_FOREIGN1"
has failed.
$ !
$ ! Issue SQL statements to determine what the definition of the
$ ! constraint is and which of the loaded rows violated
$ ! the constraint. Then issue an SQL command to insert data that will
$ ! restore the data integrity of the database:
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL.RDB';
SQL> SHOW TABLE JOB_HISTORY
.
.
.
JOB_HISTORY_FOREIGN1
Foreign Key constraint
Column constraint for JOB_HISTORY.EMPLOYEE_ID
Evaluated on COMMIT
Source:
JOB_HISTORY.EMPLOYEE_ID REFERENCES EMPLOYEES (EMPLOYEE_ID)
.
.
.
SQL> SELECT DISTINCT(EMPLOYEE_ID)
cont> FROM JOB_HISTORY
cont> WHERE NOT EXISTS
cont> (SELECT *
cont> FROM EMPLOYEES AS E
cont> WHERE E.EMPLOYEE_ID = JOB_HISTORY.EMPLOYEE_ID);
EMPLOYEE_ID
10164
10165
10166
10167
10168
10169
6 rows selected
SQL> INSERT INTO EMPLOYEES (EMPLOYEE_ID, LAST_NAME)
cont> VALUES ('10164', 'Smith');
SQL> INSERT INTO EMPLOYEES (EMPLOYEE_ID, LAST_NAME)
cont> VALUES ('10165', 'Frederico');
SQL> INSERT INTO EMPLOYEES (EMPLOYEE_ID, LAST_NAME)
cont> VALUES ('10166', 'Watts');
SQL> INSERT INTO EMPLOYEES (EMPLOYEE_ID, LAST_NAME)
cont> VALUES ('10167', 'Risley');
SQL> INSERT INTO EMPLOYEES (EMPLOYEE_ID, LAST_NAME)
cont> VALUES ('10168', 'Pietryka');
SQL> INSERT INTO EMPLOYEES (EMPLOYEE_ID, LAST_NAME)
cont> VALUES ('10169', 'Jussaume');
SQL> COMMIT;
SQL> EXIT
$ !
$ ! Check that data integrity has been restored:
$ !
$ RMU/VERIFY/CONSTRAINTS=(CONSTRAINTS=JOB_HISTORY_FOREIGN1, -
_$ TABLE=JOB_HISTORY) MF_PERSONNEL.RDB
$ !
$ ! No messages are returned. Data integrity has been restored.
Example 7
The following example creates an external function in which
the external name is incorrect. When the function is verified,
Oracle RMU cannot find the entry point and returns an error. The
external function is then dropped and then re-created correctly.
The verification now succeeds:
$ ! Attach to database and create a function. The external name is
$ ! mistyped:
$ !
SQL> ATTACH 'filename mf_personnel.rdb';
SQL> create function SQRT (in double precision) returns double precision;
cont> external name MTH$SORT location 'SYS$SHARE:MTHRTL'
cont> language GENERAL
cont> GENERAL PARAMETER STYLE;
SQL> COMMIT;
SQL> EXIT;
$ !
$ ! Verify the function:
$ !
$ RMU/VERIFY/ROUTINES MF_PERSONNEL.RDB
%RMU-E-NOENTRPT, No entry point found for external routine SQRT.
Image name is SYS$SHARE:MTHRTL.
Entry point is MTH$SORT.
$ !
$ ! Oracle RMU cannot find the entry point. Drop the
$ ! function and reenter correctly:
$ !
$ SQL
SQL> ATTACH 'FILENAME mf_personnel.rdb';
SQL> DROP FUNCTION SQRT;
SQL> create function SQRT (in double precision) returns double precision;
cont> external name MTH$SQRT location 'SYS$SHARE:MTHRTL'
cont> language GENERAL
cont> GENERAL PARAMETER STYLE;
SQL> COMMIT;
SQL> EXIT;
$ !
$ ! Verification is now successful:
$ !
$ RMU/VERIFY/ROUTINES MF_PERSONNEL.RDB
Example 8
The following example demonstrates that the RMU Verify command
verifies disabled constraints only when you explicitly specify
the disabled constraint.
$ SQL
SQL> ATTACH 'FILENAME MF_PERSONNEL.RDB';
SQL> -- Disable the EMP_SEX_VALUES constraint.
SQL> ALTER TABLE EMPLOYEES DISABLE CONSTRAINT EMP_SEX_VALUES;
SQL> COMMIT;
SQL> -- Insert a value that violates the EMP_SEX_VALUES constraint.
SQL> INSERT INTO EMPLOYEES
cont> (EMPLOYEE_ID, LAST_NAME, SEX)
cont> VALUES ('99999', 'JICKLING', 'G');
1 row inserted
SQL> COMMIT;
SQL> EXIT;
$ !
$ ! The following two verify commands do not return an error
$ ! because the disabled constraint is not explicitly specified.
$ !
$ RMU/VERIFY MF_PERSONNEL.RDB
$ RMU/VERIFY MF_PERSONNEL.RDB/CONSTRAINTS
$ !
$ ! The following verify command returns an warning message to
$ ! inform you that data that violates the disabled constraint
$ ! has been inserted into the database.
$ !
$ RMU/VERIFY MF_PERSONNEL.RDB/CONSTRAINT=(CONSTRAINT=EMP_SEX_VALUES)
%RMU-W-CONSTFAIL, Verification of constraint "EMP_SEX_VALUES" has failed.