1 – Audit
Audit
Audit=Database_File=db-name
Allows you to load a database's security audit records from an
OpenVMS security audit journal into one of the following:
o A table in the database being audited
Specify the Audit qualifier without the Database_File option
to indicate that you want the security audit records to be
loaded into the database specified with the root-file-spec
parameter.
o A table in a different database than the one being audited
Specify the Audit=Database_File=db-name qualifier to indicate
that you want to security audit records for the database
specified with the root-file-spec command parameter to be
loaded into the database specified with the db-name option
parameter.
If you specify the Audit qualifier, you cannot specify the Fields
or Trigger_Relations qualifiers.
In addition you cannot specify the Audit qualifier with a
parallel load operation. If you attempt to do so, Oracle RMU
issues a warning and performs a single-executor load operation.
2 – Buffers
Buffers=n
Specifies the number of database buffers used for storing data
during the load operation. If no value is specified, the default
value for the database is used. (The default value for the
database is defined by the logical name RDM$BIND_BUFFERS, or
if the logical is not defined, can be determined by using the
RMU Dump command with the Header qualifier. The RDM$BIND_BUFFERS
logical name, if defined, overrides the value displayed with the
RMU Dump command.) Fewer I/O operations are required if you can
store as much data as possible in memory when many indexes or
constraints are defined on the target table. Therefore, specify
more buffers than allowed by the default value to increase the
speed of the load operation.
See the Oracle Rdb7 Guide to Database Performance and Tuning
for detailed recommendations on setting the number of database
buffers.
3 – Commit Every
Commit_Every=n
Specifies the frequency with which Oracle Rdb commits the data
being loaded. For a single-executor load operation, Oracle Rdb
commits the data after every n records that are stored. The
default is to commit only after all records have been stored.
For a parallel load operation, the Commit_Every qualifier
applies separately to each of the executors (processes) used.
For example, if five parallel processes are running, and the
Commit_Every=2 qualifier is specified, Oracle RMU commits data
for each process after it has stored 2 records. This means that
if the Commit_Every=1000 qualifier is specified when you load one
million records with 10 parallel processes, the .ruj files will
store up to 10,000 rows of before-image data.
If you specify the Defer_Index_Updates qualifier and a high value
for the Commit_Every qualifier, memory requirements are high. See
the description of the Defer_Index_Updates qualifier for details.
Commit operations may occur more frequently than you specify
under certain conditions. See the description of the Defer_Index_
Updates qualifier for details.
To determine how frequently you should commit data, decide how
many records you are willing to reload if the original load
operation fails. If you use the Statistics=On_Commit qualifier,
you receive a message indicating the number of records loaded at
each commit operation. Then, if a failure occurs, you know where
to resume loading.
If you specify the Place qualifier and a failure occurs, resume
loading at the point of the previous commit, instead of the
record number of the last successful commit. The Place qualifier
restructures the .unl file prior to loading, so the record number
on which the load operation failed does not correspond to the
same number in the original .unl file.
4 – Constraints
Constraints
Constraints=Deferred
Noconstraints
Specifies when or if constraints are evaluated for data
being loaded. If you specify the Constraints qualifier,
constraints are evaluated as each record is loaded. If you
specify the Noconstraints qualifier, constraints are not
evaluated at all during the load operation. If you specify the
Constraints=Deferred qualifier, constraints are evaluated after
all data from the input file has been loaded.
The default is the Constraints qualifier.
Oracle Corporation recommends that you accept the default for
most load operations. The Noconstraints and Constraints=Deferred
qualifiers are useful when load performance is your highest
priority, you fully understand the constraints defined for
your database, and you are familiar enough with the input data
to be fairly certain that loading that data will not violate
constraints; then you might use these qualifiers as follows:
o Constraints=Deferred
This qualifier is particularly useful for improving
performance when you are loading data into a new table.
Oracle Corporation strongly recommends that you issue an
RMU Verify command with the Constraints qualifier when the
load operation has completed. Note, however, that issuing the
RMU Verify command after the load operation has completed
takes about the same amount of time that would have been
spent had you specified the RMU Load command with the
Constraints qualifier. In other words, by specifying the
Constraints=Deferred qualifier, you are only delaying when
the constraint verification will take place.
o Noconstraints
This qualifier is particularly useful when you are performing
a parallel load operation with the Defer_Index_Updates
qualifier. Oracle Corporation strongly recommends that you
issue an RMU Verify command with the Constraints qualifier
when the load operation has completed. Note, however, that
when you issue the RMU Verify command with the Constraints
qualifier, all rows in the table are checked for constraint
violations, not just the rows that are loaded.
Consider the following before issuing an RMU Load command with
the Noconstraints or Constraints=Deferred qualifier:
o If a table is populated with data prior to a load operation,
it is less expensive to check constraints on each record
as it is being loaded, than to verify constraints on the
entire table after the set of new records has been loaded.
For example, assume you load 200 new records into a table that
currently holds 2,000 records and one constraint is defined
on the table. If you verify constraints as the records are
being loaded, constraint validation is performed 200 times.
If you wait and verify constraints after the load operation
completes, constraint verification must be performed for 2,200
records
o If an RMU Verify command reveals that constraint violations
occurred during the load operation, you must track down those
records and either remove them or make other modifications
to the database to restore the data integrity. This can be a
time-consuming process.
Also consider a situation where all of the following are true:
o You perform a parallel load operation
o You specify the Constraints qualifier
o The table into which you are loading data has a constraint
defined on it
o The constraint defined on the table was defined as deferred
o Constraint evaluation fails during the load operation
In a case such as the preceding, you can not easily determine
which rows were loaded and which were not. Therefore Oracle
Corporation recommends that if deferred constraints are defined
on a table, then you should also specify the Constraints=Deferred
qualifier in your parallel load command. When you follow this
recommendation, the records that violate the constraint are
stored in the database. When the load operation completes, you
can remove from the database those records that violate the
constraint.
See Example 6 in Verify for an example of the steps to take if
an RMU Verify command reveals that an RMU Load command has stored
data that violates constraints into your database.
5 – Corresponding
Corresponding
Loads fields into a table from the .unl file by matching the
field names in the .rrd file to the column names in the table.
The Corresponding qualifier makes it more convenient to unload,
restructure, and reload a table.
For example, if the columns in the table appear in the order:
EMPLOYEE_ID, LAST_NAME, FIRST_NAME, but the data in your .unl
file appears in the order: EMPLOYEE_ID, FIRST_NAME, LAST_NAME,
and your .rrd file lists the fields in the order: EMPLOYEE_ID,
FIRST_NAME, LAST_NAME, you can use the Corresponding qualifier
to load the data in your .unl file correctly. (You could also use
the Fields qualifier to accomplish the same task, but this can
get tedious if there are numerous fields.)
The .unl file must contain data for each field in the database
into which it is being loaded; if it does not, you should use the
Fields qualifier.
If the Corresponding qualifier is omitted, the RMU Load command
loads the data into database fields by the ordinal position in
which they appear in the .unl, not by the column name described
in the .rrd file.
The Corresponding qualifier cannot be used with either the Fields
or Audit qualifiers.
6 – Defer Index Updates
Defer_Index_Updates
Nodefer_Index_Updates
The Defer_Index_Updates qualifier specifies that non-unique
indexes (other than those that define the placement information
for data in a storage area) will not be rebuilt until commit
time.
Use of this qualifier results in less I/O and fewer lock
conflicts than when index builds are not deferred, but results
in a total failure of a load operation if any lock conflicts
are encountered. In such a case, the entire load operation is
rolled back to the previous commit and you must repeat the load
operation. (Record insertion recommences at the beginning of
the input file). For this reason, you should only use the Defer_
Index_Updates qualifier when all of the following are true:
o You specify the Noconstraints qualifier (or you have dropped
constraints, or no constraints are defined on the table).
o You have dropped triggers from the table (or triggers are not
defined for the table).
o No other users are accessing the table being loaded.
Also be aware that required virtual memory can be quite large
when you defer index updates. Required virtual memory is directly
proportional to the following:
o The length of the Ikeys in the indexes being deferred
o The number of indexes being deferred
o The value for n specified with the Commit_Every qualifier
You can estimate the amount of virtual memory required for each
deferred index using the following formula, where:
o n = the value specified with the Commit_Every qualifier
o I = (length of the Ikey + 50)
n * (I * number_defered_ikeys)
The Nodefer_Index_Updates qualifier is the default. When you
specify the Nodefer_Index_Updates qualifier (or accept the
default), both the indexes that define the placement information
for data in a storage area and any other indexes defined on the
table being loaded are rebuilt at verb time.
This can result in a managed deadlock situation when the Parallel
qualifier is specified. The following describes such a scenario:
o Executor_1 locks index node A in exclusive mode
o Executor_2 locks index node B in exclusive mode
o Executor_1 requests a lock on index node B
o Executor_2 requests a lock on index node A
In such a situation, Oracle Rdb resolves the deadlock by
directing one of the executors to commit the data it has already
stored. This resolves the deadlock situation and the load
operation continues.
7 – Dialect
Dialect
Nodialect
The Dialect qualifier is used to control whether truncation
of string data during the loading of data is reported or not.
This loss of data might be significant. RMU Load defaults to SQL
dialect SQL99 which implicitly checks for and reports truncations
during INSERT operations.
o /NODIALECT, /DIALECT=SQL89 or /DIALECT=NONE will not report
any truncation errors, which is the "old" behavior of Rdb
(prior to July 2008).
o /DIALECT=SQL99 (the default) will enable reporting of
truncation errors. Note that truncation occurs if non-space
characters are discarded during the insert.
8 – Execute
Execute
Noexecute
The Execute and Noexecute qualifiers are used with the List_Plan
qualifier to specify whether or not the generated plan file is
to be executed. The Noexecute qualifier specifies that the plan
file should be created but should not be executed. Regardless of
whether you use the Noexecute or Execute qualifier (or accept the
default), Oracle RMU performs a validity check on the RMU Load
command you specify.
The validity check determines such things as whether the
specified table is in the specified database, the .rrd file (if
specified) matches the table, and that the number of columns
specified with the Fields qualifier matches the number of
columns in the .unl file. The validity check does not determine
such things as whether your process and global page quotas are
sufficient.
By default, the plan file is executed when an RMU Load command
with the List_Plan qualifier is issued.
9 – Fields
Fields=(column-name-list)
Specifies the column or columns of the table to be loaded into
the database. If you list multiple columns, separate the column
names with a comma, and enclose the list of column names within
parentheses. Also, this qualifier specifies the order of the
columns to be loaded if that order differs from the order defined
for the table. The number and data type of the columns specified
must agree with the number and data type of the columns in the
.unl file. The default is all columns defined for the table in
the order defined.
If you specify an options file in place of a list of columns, and
the options file is empty, the RMU Load command loads all fields.
10 – List Plan
List_Plan[=output-file]
Specifies that Oracle RMU should generate a plan file and write
it to the specified output file. A plan file is a text file that
contains all the qualifiers specified on the RMU Load command
line. In addition, it specifies the executor names (if you are
performing a parallel load operation), the directory for the .ruj
files, the exception files, and the file created by the Place_
Only qualifier (if specified).
Oracle RMU validates the Oracle RMU command prior to generating
the plan file to ensure that an invalid plan file is not created.
(This is true regardless of whether or not you specify the
Noexecute qualifier.) For example, the following command is
invalid and returns an error message because it specifies
conflicting qualifiers (Corresponding and Fields):
$ RMU/LOAD/RECORD_DEF=FILE=NAMES.RRD/CORRESPONDING -
_$ /FIELDS=(LAST_NAME, FIRST_NAME)/LIST_PLAN=my_plan.plan -
_$ MF_PERSONNEL.RDB EMPLOYEES NAMES.UNL
%RMU-F-CONFLSWIT, conflicting options CORRESPONDING and FIELDS...
See the description of the Execute qualifier for a description
of what items are included when Oracle RMU validates the RMU
Load command. See the Examples section for a complete example and
description of a plan file.
You can use the generated plan as a starting point for building a
load operation that is tuned for your particular configuration.
The output file can be customized and then used with subsequent
load operations as the parameter to the RMU Load Plan command.
See Load Plan for details.
If you want to create only a load plan file and do not want
to execute the load plan when the RMU Load command is issued,
specify the Noexecute qualifier. When you specify the Noexecute
qualifier, you must specify a valid Oracle RMU command.
One way to prototype a plan file prior to creating a potentially
very large .unl file is to specify the List_Plan qualifier and
the Noexecute qualifier along with a valid record definition
(.rrd) file and an empty .unl file on the RMU Load command
line. The .rrd file contains the information Oracle RMU needs
to perform the validation of the plan file; however, because data
is not loaded when you specify the Noexecute qualifier, Oracle
RMU does not attempt to load the .unl file. Note, however, that
you cannot specify the Fields qualifier when using this strategy.
(When you specify the Fields qualifier, Oracle RMU checks to make
sure the number of columns specified with the Fields qualifier
match the number of columns specified in the .unl file.)
If you do not specify a file extension, the default file
extension for the plan file is .plan.
11 – Log Commits
Log_Commits
Nolog_Commits
Causes a message to be printed after each commit operation. In
the case of a parallel load, a message is printed after each
executor commits.
The default is the Nolog_Commits qualifier, where no message is
printed after individual commit operations. The Nolog_Commits
qualifier does, however, cause a commit operation total to be
printed after the operation completes or generates an error.
12 – Match Name
Match_Name=table-name
Nomatch_Name
Specifies the table name to be read. Tables exported by SQL into
an interchange file can be individually loaded into a database.
The default behavior of the RMU Load command is to locate and
load the first set of table data in the unload file. If this is
not the table you want, you can use the Match_Name qualifier to
specify a different table name. If the Match_Name qualifier is
used without a table-name, Oracle RMU assumes the name of the
table being loaded is also the name of the table in the source
data file. The default is the Nomatch_Name qualifier.
13 – Parallel
Parallel[=(options)]
Specifies a parallel load operation. A parallel load operation is
especially effective when you have large partitioned tables that
do not contain segmented strings and for which no constraints or
triggers are defined.
If you specify the Parallel qualifier without any options, your
load operation is assigned one executor and four communications
buffers for that executor. A communications buffer is used for
communications between your process and the executors.
If you want to assign additional executors or communications
buffers, or both, use one or both of the following options:
o Buffer_Count=n
Allows you to specify the number of communications buffers
assigned to each executor in a parallel load operation.
Do not confuse this with the Buffers=n qualifier. The
Buffers=n qualifier specifies the number of database buffers
to use during the load operation.
o Executor_Count=n
Allows you to specify the number of worker processes to
be assigned to the load operation. Ideally, the number of
executors should be equal to the number of table partitions.
You should not assign a greater number of executors than
the number of table partitions. If a table is randomly or
vertically partitioned, Oracle RMU creates only one executor,
regardless of the number you specify.
If the user account's MAXDETACH UAF value is greater than 0,
then executors are created as detached processes. If there
is no MAXDETACH value set, then executors are created as
subprocesses. (A MAXDETACH value = 0 equates to unlimited
detached processes.)
At the end of each load operation, Oracle RMU displays summary
statistics for each executor in the load operation and the main
process. Look at the "Idle time" listed in the statistics at the
end of the job to detect data skew and look at "Early commits" to
detect locking contention.
If some executors have a large amount of idle time, you likely
have data that is skewed. Ideally, data loaded with the Parallel
qualifier should appear in random order within the .unl file.
Data that is already in partition order when you attempt to
perform a parallel load operation results in high idle time for
each executor and thus defeats the advantages of a parallel load
operation.
The summary statistics also list the number of records read from
the input file, the number of data records stored, and the number
of data records rejected. In most cases, the number of data
records rejected plus the number of data records stored equals
the number of data read from the input file. However, under the
following circumstances this equation does not hold:
o The parallel load operation aborts due to a duplicate record
that is not allowed.
o You did not specify an exception file.
Similarly if a load operation aborts due to a record in the input
file being improperly delimited for a delimited text load, the
records rejected plus the records stored do not equal the number
of records read from the input file.
You cannot use a parallel load operation to load list data
(segmented string) records or security audit records. If you
specify a parallel load operation and attempt to load list data
or security audit records, Oracle RMU returns a warning and
performs a single-process (non-parallel) load operation.
14 – Place
Place
Noplace
Sorts records by target page number before they are stored.
The Place qualifier automatically builds an ordered set of
database keys (dbkeys) when loading data and automatically stores
the records in dbkey order, sequentially, page by page. During
a parallel load operation, each worker executor builds its own
ordered set of dbkeys.
The number of work files used by the RMU Load 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.
A significant performance improvement occurs when the records
are stored by means of a hashed index. By using the Commit_
Every qualifier with the Place qualifier, you can specify how
many records to load between COMMIT statements. Performance may
actually decrease when records are stored by means of a sorted
index.
The default is the Noplace qualifier.
15 – Record Definition
Record_Definition=(File=name[,options])
Record_Definition=(Path=name[,options])
Specifies the RMS record definition or the data dictionary record
definition to be used when data is loaded into the database. Use
the File=name parameter to specify an RMS record definition file;
use the Path=name parameter to specify that the record definition
be extracted from the data dictionary. (If the record definition
in the data dictionary contains variants, Oracle RMU will not be
able to extract it.)
The default file extension for the File=name parameter is
.rrd. The syntax for the .rrd file is similar to that used by
the Common Dictionary Operator (CDO) interface for the data
dictionary. You must define columns before you can define rows.
You can place only one column on a line. You can create a sample
.rrd file by using the RMU Unload command with the Record_
Definition qualifier. You must ensure that the record definition
in the .rrd file and the actual data are consistent with each
other. Oracle Rdb does not check to see that data types in the
record definition and the data match. See the help entry for
RRD_File_Syntax and the Oracle Rdb Guide to Database Design and
Definition for more information about the format of the .rrd
file.
You must specify either the File=name or Path=name parameter.
The options available are:
o Exception_File=exception-file
Allows you to write unloadable records to a single exception
file for a single-process load operation and into multiple
exception files for a parallel load operation. If you generate
a load plan for a parallel load operation, each executor is
assigned its own exception file. In this case, the exception-
file name you specify is given a different file extension for
each executor.
While Oracle RMU is loading data from an RMS file, if an
exception file is specified, then under certain circumstances
an invalid record in the input file does not cause the
RMU Load command to abort. Instead, Oracle RMU creates the
exception file (or files), writes the unloadable record into
this exception file (or files), and continues loading the
remaining records. This process occurs only if the data is
invalid on the actual insert, due to index, constraint, or
trigger errors. If the record has an invalid format in the RMS
file (for example, a missing delimiter), the exception file is
not used, and the load process aborts.
At the end of the load operation, you can process the
exception file (or files) to correct any problems, and then
reload directly from the exception file or files. The load
operation gives an informational message for each of the
unloadable records and also gives a summary of the number
of records stored and the number of records rejected.
All records that could not be loaded will be written into the
file or files as specified with the argument to the Exception_
File option. The default file extension for the exception
file is .unl for single-process loads; for parallel loads
the default extension is EXC_n, where n corresponds to the
executor number assigned by Oracle RMU. The exception file or
files are created only if there are unloadable records. If the
Exception_File option is not specified, no exception files are
created, and the load operation aborts at the first occurrence
of an exception.
However, note that if the Defer_Index_Updates qualifier is
specified, and a constraint violation or lock conflict occurs,
the load operation aborts when it attempts to commit the
transaction.
If the Defer_Index_Updates qualifier is not specified, records
that cause a constraint violation are written to the exception
file or files and the load operation continues loading the
remaining records.
o Format=Text
If you specify the Format=Text option, Oracle RMU converts all
data to printable text before loading it.
o If you do not specify the Format option, then Oracle RMU
expects to load a fixed-length binary flat file. The data
type of the fields must be specified in the .rrd file.
o Format=(Delimited_Text [,delimiter-options])
If you specify the Format=Delimited_Text option, the .rrd file
contains only text fields and specifies the maximum length of
the columns in the file containing delimited ASCII text. The
column values that are longer than those specified in the .rrd
file are truncated.
Note that DATE VMS types must be specified in the collatable
time format, which is yyyymmddhhmmsscc. For example, March 20,
1993 must be specified as: 1993032000000000.
Unless you specify the Format=Delimited_Text option,
delimiters are regarded as part of the data by Oracle RMU.
Example 13 in the Examples help entry under this command
demonstrates the Format=Delimited_Text option. Delimiter
options (and their default values if you do not specify
delimiter options) are as follows. Note that with the
exception of the Prefix and Suffix delimiter options, the
values specified must be unique. The Prefix and Suffix values
can be the same value as each other, but not the same as other
delimiter options. The Null string must also be unique.
- Prefix=string
Specifies a prefix string that begins any column value in
the ASCII input file. If you omit this option, the column
prefix is assumed to consist of a quotation mark (").
- Separator=string
Specifies a string that separates column values of a row.
If you omit this option, the column separator is assumed to
consist of a single comma (,).
- Suffix=string
Specifies a suffix string that ends any column value in
the ASCII input file. If you omit this option, the column
suffix is assumed to consist of a quotation mark (").
- Terminator=string
Specifies the row terminator that completes all the column
values corresponding to a row. If you omit this option, the
row terminator is assumed to be the end of the line.
- Null=string
Specifies a string, which when found in the input record,
is stored as NULL in the database column. This option is
only valid when the Delimited_Text option is specified
also.
The Null option can be specified on the command line as any
one of the following:
* A quoted string
* An empty set of double quotes ("")
* No string
If provided, the string that represents the null character
must be quoted on the Oracle RMU command line, however, it
must not be quoted in the input file. You cannot specify a
blank space or spaces as the null character.
If the final column or columns of a record are to be set
to NULL, you only have to specify data for the column up to
the last non-null column.
See the Examples section for an example of each of these
methods of storing the NULL value.
NOTE
The values of each of the strings specified in the
delimiter options must be enclosed by quotation
marks. Oracle RMU strips these quotation marks while
interpreting the values. If you want to specify a
quotation mark (") as a delimiter, specify a string
of four quotation marks. Oracle RMU interprets four
quotation marks as your request to use one quotation
mark as a delimiter. For example, Suffix = """".
Oracle RMU reads the quotation marks as follows:
o The first quotation mark is stripped from the
string.
o The second and third quotation marks are
interpreted as your request for one quotation mark
(") as a delimiter.
o The fourth quotation mark is stripped. This
results in one quotation mark being used as a
delimiter.
Furthermore, if you want to specify a quotation mark
as part of the delimiter string, you must use two
quotation marks for each quotation mark that you
want to appear in the string. For example, Suffix
**"**.
A delimiter of blank spaces enclosed in quotes is not
valid.
o Place_Only=sorted-placement-file
Allows you to sort the input file and create an output file
sorted in Placement order.
The input file can first be sorted into Placement order by
using the Place_Only option. The resultant file can then be
loaded with the Commit_Every qualifier to gain the required
efficiency. Do not use this option with a parallel load
operation; parallel load operations perform best when the
input file is not sorted.
The Place_Only option cannot be used with either the Commit_
Every qualifier or the Exception_File option (data is not
being stored in the database). However, the Place_Only option
requires the Place qualifier be specified (to sort the data).
The placement-sorted output file has the default file
extension of .unl.
Unless you specify the Null option (with the Format=Delimited_
Text parameter of the Record_Definition qualifier), any null
values stored in the rows of the tables being loaded are not
preserved. Therefore, use the Null option if you want to preserve
null values stored in tables and you are moving data within the
database or between databases.
See the examples in the Examples help entry under the RMU Unload
command for more information.
16 – Rms Record Def
Rms_Record_Def=(File=name[,options])
Rms_Record_Def=(Path=name[.options])
Synonymous with the Record_Definition qualifier. See the
description of the Record_Definition qualifier.
17 – Restricted Access
Restricted_Access
NoRestricted_Access
Allows a single process to load data and enables some
optimizations available only when restricted access is in use.
The default is Norestricted_Access.
If you are loading a table from an RMU Unload file which contains
LIST OF BYTE VARYING data, the Restricted_Access qualifier
reserves the LIST areas for EXCLUSIVE access. This reduces the
virtual memory used by long transactions during a load operation
and also eliminates I/O to the snapshot files for the LIST
storage areas.
The Restricted_Access and Parallel qualifiers are mutually
exclusive and cannot be specified together on the same RMU Load
command line or within a plan file. While RMU Load is running
with the Restricted_Access qualifier specified, no other user can
attach to the database.
18 – Row Count
Row_Count=n
Specifies that Oracle Rdb buffer multiple rows between the Oracle
Rdb server and the RMU Load process. The default for n is 500
rows; however, this value should be adjusted based on working
set size and length of loaded data. Increasing the row count may
reduce the CPU cost of the load operation. For remote databases,
this may significantly reduce network traffic for large volumes
of data because the buffered data can be packaged into larger
network packets.
The minimum value you can specify for n is 1. The default row
size is the value specified for the Commit_Every qualifier or
500, whichever is smaller.
19 – Skip
Skip=n
Noskip
Ignores the first n data records in the input file. Use this
qualifier in conjunction with the Commit_Every qualifier
when restarting an aborted load operation. An aborted load
operation displays a message indicating how many records have
been committed. Use this value for n. If you specify a negative
number, you receive an error message. If you specify a number
greater than the number of records in the file, you receive an
error message stating that no records have been stored. If you
do not specify a value, you receive an error message stating that
there is a missing keyword value.
Using the Skip qualifier to restart an aborted parallel load
operation is rarely useful. Because records are sorted by the
controller for each executor involved in the parallel load, there
are usually multiple sections of loaded and unloaded records in
the input file. Unless you are very familiar with the data you
are loading and how it is sorted by the controller, you risk
loading some records twice and not loading other records at all,
if you use the Skip qualifier when restarting an aborted parallel
load operation.
The default is the Noskip qualifier.
20 – Statistics
Statistics=(stat-opts)
Specifies that statistics are to be displayed at regular
intervals or each time a transaction commits, or both, so that
you can evaluate the progress of the load operation.
The stat-opts are the options you can specify with this
qualifier, namely: Interval=n, On_Commit, or both. If the
Statistics qualifier is specified, you must also specify at least
one option.
When the Statistics=(Interval=n) qualifier is specified, Oracle
RMU prints statistics every n seconds. The minimum value for n is
1.
When the Statistics=(On_Commit) qualifier is specified, Oracle
RMU prints statistics each time a transaction is committed.
If you specify both options, Statistics=(Interval=n, On_Commit),
statistics are displayed every n seconds and each time a
transaction commits.
The displayed statistics include:
o Elapsed time
o CPU time
o Buffered I/O
o Direct I/O
o Page faults
o Number of records loaded when the last transaction was
committed
o Number of records loaded so far in the current transaction
o If the Record_Definition=Exception_File option is also
specified, the following statistics are displayed also:
- Number of records rejected when the last transaction was
committed
- Number of records rejected so far in the current
transaction
o If the Parallel qualifier is specified also, the following
statistics are displayed also:
- Number of extra commits performed by executors
Extra commits are caused when the Oracle RMU directs your
process or the executors to commit a transaction earlier
than usual to avoid a hung load operation. For example, if
one executor is holding, but no longer needs a lock that
another executor requires, Oracle RMU directs the first
executor to commit its current transaction. By directing an
executor or executors to commit a transaction earlier than
usual, the locks under contention are released and the load
operation can proceed.
- The total number of executors
- The number of executors that are initializing, idle,
terminated, sorting, storing, committing, or executing
At any time during the load operation, you can press Ctrl/T to
display the current statistics.
21 – Transaction Type
Transaction_Type=share-mode
Specifies the share mode for the load operation. The following
share modes are available:
Batch_Update
Exclusive
Protected
Shared
You must specify a value if you use the Transaction_Type
qualifier. If you do not specify the Transaction_Type qualifier,
the default share mode is Protected.
If you specify a parallel load operation (with the Parallel
qualifier), and constraints are defined on the table you are
loading, Oracle Corporation recommends that you specify the
Shared share mode, or drop the constraints prior to starting a
parallel load operation, or specify the Noconstraints qualifier.
See the Usage Notes for details.
22 – Trigger Relations
Trigger_Relations[=(table-name-list)]
NoTrigger_Relations
You can use the Trigger_Relations qualifier in three ways:
o Trigger_Relations=(table-name-list)
Specifies the tables to be reserved for update. Using this
qualifier, you can explicitly lock tables that are updated
by triggers in store operations. If you list multiple tables,
separate the table names with a comma, and enclose the list of
table names within parentheses.
o Trigger_Relations
If you omit the list of table names, the tables updated by
triggers are locked automatically as required. This is the
default.
o NoTrigger_Relations
Disables triggers on the target table. This option requires
DROP privilege on the table being loaded. You cannot specify a
list of table names with this option.
If you specify a parallel load operation (with the Parallel
qualifier), and triggers are defined on the table you are
loading, Oracle Corporation recommends that you specify the
Shared share mode or drop the triggers prior to starting a
parallel load operation. See the Usage Notes for details.
The Trigger_Relations qualifier can be used with indirect file
references. See the Indirect-Command-Files help entry for more
information.
23 – Virtual Fields
Virtual_Fields(=[No]Automatic)
Novirtual_Fields
The Virtual_Fields qualifier is required to reload any AUTOMATIC
(or IDENTITY) fields with real data.
The Novirtual_Fields qualifier is the default, which is
equivalent to the Virtual_Fields=(Noautomatic) qualifier.
If you specify the Virtual_Fields qualifier without a keyword,
all fields are loaded except COMPUTED BY columns and calculated
VIEW columns.
Use this qualifier when restructuring a table and when you do
not wish the AUTOMATIC INSERT AS or IDENTITY column to recompute
new values. Instead, RMU will reload the saved values from a file
created by RMU/UNLOAD/VIRTUAL_FIELDS=AUTOMATIC.