1 Replication_Option Replication Option is a software product that lets you distribute whole databases, or parts of them, to target directories on the same or different nodes in a network. The source database for extraction and extraction rollup target databases can be a DSRI-compliant database such as Oracle Rdb or one of the Oracle data access products, known as gateways. Note that RDO does not support all the latest Replication Option features. Oracle recommends that you use the SQL interface instead of RDO because SQL is an industry-standard database access language and only SQL supports all the latest Replication Option features. 2 Release_Notes To see the current Release Notes for Replication Option, type or print the following file: SYS$HELP:DDALvvu.RELEASE_NOTES where vv = version and u = update For example: SYS$HELP:DDAL060.RELEASE_NOTES 2 Error_msg_doc Errors returned by Replication Option are documented online in the file SYS$HELP:DDAL$MSG.DOC, which you can PRINT, TYPE, or SEARCH at DCL level. 2 EXTRACTION Specifies that Replication Option create an extraction database at the target site. Because each extraction database is independent of the source database, users at the target directory can access extraction databases with either read-only or read/write transactions. Each time an extraction transfer executes, Replication Option creates a new version of the target database and transfers a complete copy of the selected records to the target node. Indexes, constraints, and access rights are not transferred when the target database is created. Once the target database has been created, you can define views, indexes, and constraints for it and modify the access rights. Refer to the Replication Option Handbook for more information about extraction databases. 2 EXTRACTION_ROLLUP Specifies that Replication Option create an extraction rollup database at the target site with records selected from one or more source databases. Because each extraction rollup database is independent of the source database, users at the target directory can access extraction rollup databases with either read-only or read/write transactions. Each time an extraction rollup transfer executes, Replication Option creates a new version of the target database and transfers a complete copy of the selected records to the target node. Indexes, constraints, and access rights are not transferred when the target database is created. Once the target database has been created, you can define indexes and constraints for it and modify the access rights. Refer to the Replication Option Handbook for more information about extraction databases. 2 REPLICATION Specifies that Replication Option create a replication database at the target site. When a replication transfer executes, Replication Option creates a database at the target site during the initial execution and supplies updates to it during subsequent transfers. In addition, the execution of a replication transfer might create special-purpose relations in the source database and the target database to handle updating. Refer to the Replication Option Handbook for specific information about these special database entities. Because the source database is modified with the addition of these new system relations, the user who defined the transfer needs the DEFINE access right to the source database. After Replication Option creates the target database and transfers the data records to it, users are expected to access the replication database to retrieve data only. Applications should not attempt to store, modify, or erase values in records of the replication database. 2 SHOW_TRANSFER Displays information about the transfer definition, schedule definition, the transfer status, or all these transfer attributes. When you enter the SHOW TRANSFER statement, you can display information about one transfer or all transfers. NOTE The RDO SHOW TRANSFER statement does not display transfer protection, the checkpoint attribute, or the NO DELETE attribute that may have been established for a transfer definition using SQL. You must issue the SQL SHOW TRANSFER statement to display these attributes. 3 Format (B)0SHOW TRANSFER qqqq> transfer-attribute qqqk lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mqqqqqq> FOR qqqwqqq> ALL qqqqqqqqqqqqwqqq> mqqq> transfer-name qqj 4 transfer-attribute (B)0transfer-attribute = qqqwqqq> DEFINITION qqqqqwqqqq> tqqq> SCHEDULE qqqqqqqu tqqq> STATUS qqqqqqqqqu mqqq> ALL qqqqqqqqqqqqj The type of information you want displayed about the selected transfer or all transfers. 5 DEFINITION Displays transfer definition information for the specified transfer or for all transfers. 5 SCHEDULE Displays schedule definition information for the specified transfer or for all transfers. 5 STATUS Displays the following status information for the specified transfer or for all transfers: o Transfer name o State of the current transfer (unscheduled, scheduled, active, waiting-to-retry, retrying, suspended) o Time the transfer entered its current transfer state o Last transfer status o Time the last successful transfer completed o Next scheduled transfer time (for transfers in the scheduled or waiting-to-retry state) o Number of the currently executing retry (for transfers in the retrying state) o Number of the next retry (for transfers in the waiting-to- retry state) 5 ALL Displays all information about the definition, schedule, and status for the specified transfer or for all transfers. 4 ALL Specifies that you want Replication Option to display information about all transfers associated with your UIC. For transfers belonging to other UICs, Replication Option displays only the transfer name. To display information about transfers belonging to other UICs, you must have OpenVMS BYPASS or READALL privilege. 4 transfer-name The transfer about which you want Replication Option to display information. 2 DELETE_SCHEDULE Deletes the schedule definition associated with a transfer definition. You can delete a schedule definition only when the associated transfer is in the suspended state. Refer to the STOP TRANSFER statement for information about how to suspend a transfer. If you issue a START TRANSFER statement after deleting the schedule, the transfer will be placed in the unscheduled state. 3 Format (B)0DELETE SCHEDULE qq> FOR qqq> transfer-name qqqqqq> . 4 transfer-name Identifies the transfer whose schedule is to be deleted. The transfer-name parameter is required. 3 More You must execute the DELETE SCHEDULE statement outside of the scope of a transaction. If you issue this statement when a transaction is outstanding, Replication Option returns an error message. If a transfer has a schedule definition, DELETE TRANSFER also deletes the corresponding schedule definition. If you want to delete a transfer schedule, the schedule definition must be associated with your UIC. 3 Example This example places the NH_EMPLOYEES transfer in a suspended state and then deletes the associated schedule. RDO> STOP TRANSFER NH_EMPLOYEES RDO> DELETE SCHEDULE FOR NH_EMPLOYEES. 2 DELETE_TRANSFER Deletes a transfer definition. If a transfer has a schedule definition, DELETE TRANSFER also deletes the corresponding schedule definition. 3 Format (B)0DELETE TRANSFER qqq> transfer-name qqqq> . 4 transfer-name The transfer definition to be deleted. The transfer-name parameter is required. 3 More To issue the DELETE TRANSFER statement, the transfer definition you delete must be associated with your UIC or you must have the DROP transfer privilege or the OpenVMS BYPASS privilege. You must execute the DELETE TRANSFER statement outside of the scope of a transaction. If you issue this statement when a transaction is outstanding, Replication Option returns an error message. You can delete a transfer only if the transfer is in the suspended state. Refer to the STOP TRANSFER statement for information about how to suspend a transfer. When you delete a transfer definition, the associated target database does not change in any way. 3 Example The following example suspends the MA_EMPLOYEES transfer and then deletes its definition: RDO> STOP TRANSFER MA_EMPLOYEES RDO> DELETE TRANSFER MA_EMPLOYEES. 2 DEFINE_TRANSFER Creates a transfer definition and stores it in the transfer database. A transfer definition contains all the information necessary to select a set of records from the source database and to define a target database. A transfer definition also can contain the views to be defined on the target database and the command procedures to be executed before and after the execution of the transfer. A source database for extraction transfers can be Oracle Rdb, or a database accessed through one of the Rdb Transparent Gateways. For replication transfers, the source database must be an Oracle Rdb database. NOTE The DEFINE TRANSFER statement, unlike the SQL CREATE TRANSFER statement, cannot be used to define transfers to existing databases (including replication transfers with the NO DELETE attribute). It also does not provide a checkpoint clause. Furthermore, unlike the SQL CREATE TRANSFER statement, the RDO utility does not support the MIA character set attributes. It is possible to create a transfer definition using RDO and name a database containing MIA features. However, the character set attributes of the resulting target database might not be correct. Use of RDO is recommended only when you want to manipulate databases that use only the DEC_MCS character set for text data. 3 Format (B)0DEFINE TRANSFER qq> transfer-name qqwqqq> REPLICATION qqqqqqqqqwqqk tqqq> EXTRACTION qqqqqqqqqqu x mqqq> EXTRACTION ROLLUP qqqj x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqq> TO qq> file-spec qk mq> DESCRIPTION IS q> /* text */ qj x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqwqwq>qqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqwqk mq>target-db-param-clauseqj x tq>move-relations-clause qqqqqqqu x x x tq>move-views-clause qqqqqqqqqqqu x x x mq>move-relations-rollup-clauseqj x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqqqqqqqqqqqqqqqqqqqqqqqqqqk mqqq> transfer-file-options-clause qqj x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq END qqqwqqqqqqqqq>qqqqqqqqqwqqwqqqqqqq>qqqqqqwqqqqqqq> . mq> transfer-name qqj mq> TRANSFER qqj 4 transfer-name Identifies the transfer by name. The transfer name must be unique across all of the nodes at a given VAXcluster or VMScluster site because a single transfer database serves all nodes in a cluster environment. For example, you could have two users on the same server attempting to create a transfer called PERS_REC. One user would succeed while the other would receive an error message saying that the transfer already exists. To ensure that names are unique, you may wish to make the user identifier part of each transfer name. A valid transfer name has the following characteristics: o Has a length from 1 to 31 bytes (octets). o Can be formed using any of the set of ASCII characters: A B C ... Z 0 1 2 ... 9 _ $ a b c ... z Lower case letters may be used, but are treated as if they were uppercase. o Cannot include letters with diacritical marks (which are used in European languages for instance). o The first character of the name must either be a letter or the dollar sign ($). However, Oracle Corporation recommends that you do not use dollar signs in a transfer name; dollar signs are reserved for special use by Digital Equipment Corporation. The transfer-name parameter is required. 4 REPLICATION Specifies that Replication Option create a replication database at the target site. When a replication transfer executes, Replication Option creates a database at the target site during the initial execution and maintains a connection to that target database so the source can supply updates to the target. Subsequent transfers involve only those modifications that have been made to the selected records in the source database. (If the target and source database should become inconsistent with each other, you can use the REINITIALIZE TRANSFER statement to restore consistency.) In addition, the execution of a replication transfer generally creates special-purpose relations in the source database and the target database to handle updating. Because the source database is modified with the addition of these system relations, the transfer definer's account needs the DEFINE access right to the source database itself. Users are expected to access the replication target database only to retrieve data. Applications should not attempt to store, modify, or erase values in records of the replication database. Although data values should not be manipulated in a replication database, you can modify the target database by defining views and indexes, and adding access rights. 4 EXTRACTION Specifies that Replication Option create an extraction database at the target site. Because each extraction database is independent of the source database, users at the target directory can access extraction databases with read/write as well as read-only transactions. Each time an extraction mode transfer executes, Replication Option creates a new version of the target database and transfers a complete copy of the selected records to the target node. Indexes, constraints, and access rights are not transferred when the target database is created. Similarly, primary key and foreign key attributes for a particular relation are not transferred because key attributes are implemented as constraints. Once the target database has been created, you can define indexes, constraints, and triggers for it and modify the access rights. 4 EXTRACTION_ROLLUP Specifies that Replication Option create an extraction rollup database at the target site by transferring selected relations and fields from one or more source databases into a single target database. An extraction rollup database is created at the target site, and Replication Option reads data from the source databases and stores the data in a target database. Each time an extraction rollup transfer is executed, Replication Option creates a new version of the target database and transfers to it a complete copy of the selected records. The EXTRACTION ROLLUP option in the DEFINE TRANSFER statement has the following characteristics and limitations: o Replication Option issues an error message if you do not enter a MOVE RELATION clause or a SELECT FIELDS list in a move-relations-rollup-clause. o You must refer to each source database in the DEFINE TRANSFER statement by its database handle. o On the target database, relation names and field names must be unique. Consequently, all target relations of the same name must have the same definition, and all target fields of the same name must have the same data type. If the definitions or data types differ, Replication Option issues an error message and the transfer fails. o If any database specified in the transfer definition is on a node that is not available, Replication Option places the transfer in a waiting-to-retry state. Replication Option will retry the transfer at the time specified for retry in the schedule definition. o If any of the source nodes specified in the transfer definition fail during the transfer, the transfer will also fail. Replication Option will retry the transfer at the time specified for retry in the schedule definition. o If the transfer fails, the retry will start at the beginning, not where the transfer left off. Indexes, constraints, and access rights are not transferred when the target database is created. Similarly, primary key and foreign key attributes for a particular relation are not transferred because key attributes are implemented as constraints. Once the target database has been created, you can define indexes, constraints, and triggers for it and modify the access rights. 4 text A text string that allows you to associate a comment with the transfer definition. The text string, together with other parts of the transfer definition, appears in the SHOW TRANSFER DEFINITION display. The DESCRIPTION IS clause is optional. 4 file-spec Designates a file specification for the target database, which is an Oracle Rdb database. Replication Option uses the file specification to create and access the target database. You can use either a full or partial file specification or a logical name. The file-spec parameter is required. If you do not specify the node, device, or directory, Replication Option assumes the SYS$LOGIN of the user defining the transfer. If the file type is not .RDB, the transfer will fail during the creation of the target database. The default file type is .RDB. When you specify the name of a remote node as part of the file specification, you can include an access control list (ACL) for login. However, the most effective method of allowing access to a target node uses proxy accounts. If you use DECnet/OSI note that Replication Option expects node names in file specifications to be from one to six characters long. DECnet/OSI permits node names to be much longer than this. In order to use Replication Option in a DECnet/OSI environment, you must define and use short synonyms for the long node names. Node name synonyms can be registered either in a local or distributed name service database. For details on establishing node name synonyms, refer to the documentation for DECnet/OSI. Note that the file specification is resolved at run time. All logical names used for the file-spec parameter are resolved within the copy process after it executes the transfer definer's login initialization file, LOGIN.COM. If the target database name is a logical symbol name, when it is translated, the default directory is the one pointed to by SYS$LOGIN. Replication Option makes no attempt to verify whether a database or file of the same name already exists in the target directory. When you issue a duplicate file specification, Replication Option creates a second file with the same name, but a higher version number. If the database system (Oracle Rdb) returns an error while attempting to create a database in the target directory, the copy process writes the error in the copy process log file and returns the error status to the transfer monitor. 4 target-db-param-clause (B)0target-db-param-clause = qqqwqwq>qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqwqq> x tq> ALLOCATION IS qqqqqqqq> number-pages qq> PAGES qqqqu x x tq> PAGE SIZE IS qqq> page-blocks qqqqqq> BLOCKS qqqqqqu x x tq> NUMBER OF BUFFERS IS qq> number-buffers qqqqqqqqqqqu x x tq> NUMBER OF USERS IS qqqq> number-users qqqqqqqqqqqqqu x x tq> BUFFER SIZE IS qq> buffer-blocks qqq> BLOCKS qqqqqqu x x tq> EXTENT IS qqqqqqqqqqwq> ext-pages qqq> PAGES qqqwqqu x x x mq> (multi-vol-ext-clause) qj x x x tq> SNAPSHOT IS qqqqwq> ENABLED qwq> IMMEDIATE qqwqwqqqu x x x x mq> DEFERRED qqj x x x x x mq> DISABLED qqqqqq>qqqqqqqqqqqj x x x tq> SNAPSHOT ALLOCATION IS q> snp-pages q> PAGES qqqqqqu x x mq> SNAPSHOT EXTENT IS qw> ext-pages qqqq> PAGES qqqqwqj x x m> (multi-vol-ext-clause) qqqj x mqqqqqqqqqqqqqqqqqq MINIMUM OF qq> min-pages qqq> PAGES, qk lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mqq> MAXIMUM OF qq> max-pages qqq> PAGES, qk lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mqq> PERCENT GROWTH IS qqq> growth qqqq> 6 min-pages The minimum number of pages of each target database extent. The default is 100 pages. 6 max-pages The maximum number of pages of each target database extent. The default is 10,000 pages. 6 growth The percent of growth for each target database extent. The default is 20 percent growth. 4 move_relations_clause (B)0move-relations-clause = qwqq> MOVE RELATIONS ALL qqqqqqqqqqqqqqqqqqqqqqq>qqqqqqqqqqqwqqqq> x x mqwqq> MOVE RELATION qqwqqqqqqqqqqqqqqqwqq> rse qqqqqqk x x mq> /* text */ qj x x x lqqqqqqqqqqqqqqqqqqqqqqqq SELECT FIELDS qwqq> ALL qqqqqqqq>qqqqqqqwqqwqqj x mwq> select-field-name qwj x x mqqqqqqqq , context-variable qq> . qqq> field-name qqqqq> Allows you to name a specific field or group of fields you want moved to the target database. You can specify only one SELECT clause for each MOVE clause. Replication Option moves only the named fields to the target database. If you do not specify SELECT FIELDS ALL, the select-field-name clause is required. Replication Option supports COMPUTED_BY fields named in the select-field-name clause if the fields are defined using the value expressions shown in the value-expr syntax diagram in this section. If the fields are not defined by a supported value expression, you will receive a fatal error message. 4 move-views-clause (B)0move-views-clause = qqqq> MOVE VIEWS qqwqq> ALL qqqqqqqqqqqwqqq> mwq> view-name qqwqqj mqqqqqq , MOVE RELATION qqqqwqqqqqqqq>qqqqqqqqwq> rse qqqqwqqqqwq> x mq> / *text*/qqqqqj x x x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqk x x mq> INTO RELATION qqqq> relation-name qqqqqj x x x lqqqqqqqqqqqqqqqqqqqqqqqqq SELECT FIELDS qqwqq> select-field-name qqqqqwqwqj x mqqqqqqqqqq , context-variable qq> . qqq> field-name qqqqq> Allows you to name a specific field or group of fields you want moved to the target database. You can specify only one SELECT clause for each MOVE clause. Replication Option moves only the named fields to the target database. If you do not specify SELECT FIELDS ALL, the select-field-name clause is required. All fields that you name in the record selection expression (RSE) must also be named in the SELECT FIELDS clause. Replication Option supports COMPUTED_BY fields named in the select-field-name clause if the fields are defined using the value expressions shown in the value-expr syntax diagram in this section. If the fields are not defined by a supported value expression, you will receive a fatal error message. 4 transfer-file-options-clause (B)0transfer-file-options-clause qwqwqqqqqqqqqqqqqqqqqqqqqqqqq>qqqqqqqqqqqqqqqqqqqqqqqqqqqwqqqqqqq> x tqq> PROLOGUE FILE IS qqqq> prologue-file-spec qqqqqqqu x tqq> NOPROLOGUE qqqqqqqqqq>qqqqqqqqqqqqqqqqqqqqqqqqqqqu x tqq> EPILOGUE FILE IS qqqq> epilogue-file-spec qqqqqqqu x tqq> NOEPILOGUE qqqqqqqqqq>qqqqqqqqqqqqqqqqqqqqqqqqqqqu x tqq> LOG FILE IS qqqqqqqqq> log-file-spec qqqqqqqqqqqqu x mqq> NOLOG qqqqqqqqqqqqqqq>qqqqqqqqqqqqqqqqqqqqqqqqqqqu mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqq> relation-clause qq>qqqqqqqqqqqqqqqqqqqqk mq> first-clause qj x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mwqqqqqqq>qqqqqqqqwqwqqqqqqqq>qqqqqqqqqqwqqwqqqqqqqq>qqqqqqqqwqqq> mq> with-clause qj mq> reduce-clause qqj mq> sort-clause qqj The record selection expression (RSE) used to identify records from the source database that Replication Option includes in a record stream and transfers to the target database. The RSE specifies conditions that individual records must satisfy in order to be included in the transfer to the target database. Replication Option supports COMPUTED_BY fields named in an RSE if the fields are defined using the value expressions shown in the value-expr syntax diagram in this section. If the fields are not defined by a supported value expression, you will receive a fatal error message. In extraction, extraction rollup, and replication transfers, you can use a relation-clause and with-clause. In extraction and extraction rollup transfers, you can also use a first-clause, reduce-clause, and sort-clause. 5 first-clause (B)0first-clause = qqqq> FIRST qqqqqq> value-expr qqqqqqqqqqq> (B)0value-expr = qqqqqqqwqqqq> database-field qqqqqqwqq> tqqqq> quoted-string qqqqqqqu tqqqq> numeric-literal qqqqqu tqqqq> arithmetic-expr qqqqqu tqqqq> missing-value qqqqqqqu tqqqq> concat-expr qqqqqqqqqu tqqqq> ( value-expr ) qqqqqqu mqqqq> q qq> value-expr qqqj Specifies how many records are selected from the record stream formed by the record selection expression (RSE). You can only use the first-clause for an extraction or an extraction rollup transfer. If you specify a first-clause for a replication transfer, Replication Option issues an error message. 5 relation-clause (B)0relation-clause = q> context-variable q> IN wqqqqqqqq>qqqqqqqqwq> relation-name q> m> db-handle q> . j The context variables and relations to be included in the record stream or loop. If you specify a view name in the relation-clause, the moved view becomes a relation in the target database. The context-variable supplies a temporary name to identify the record stream. Once you have associated a context-variable with a relation, you use the context-variable to refer to fields from that relation. The db-handle is a host variable or name used to refer to a specific database you have invoked. In extraction or replication transfers, you should not use database handles in the RSE of a MOVE RELATION clause. Replication Option returns an error message if you include a database handle in the RSE. However, in an extraction rollup transfer, you must use database handles in the RSE to specify the relation or Replication Option will return an error message. 5 with-clause (B)0with-clause = qqqqqqqqqqqqq> WITH qqqqqqqqqq> conditional-expr qqqqqqqqqqq> (B)0conditional-expr = qwqqq> conditional-expr qq> AND qq> conditional-expr qqqwqqq> tqqq> conditional-expr qq> OR qqq> conditional-expr qqqu tqqqqqqqqqqqqqqqqqqqqqqqq> NOT qq> conditional-expr qqqu tqqq> value-expr1 qq> rel-oper qq> value-expr2 qqqqqqqqu tqqq> between-clause qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu tqqq> containing-clause qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu tqqq> matching-clause qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu tqqq> starting-with-clause qqqqqqqqqqqqqqqqqqqqqqqqqqqqu mqqq> missing-clause qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj The with-clause contains a conditional expression that allows you to specify conditions that must be true for a record to be included in a record stream. 5 reduce-clause (B)0reduce-clause = qqqqqqqqqqqqqq> REDUCED TO qqqwqqqqq> value-expr qqqwqqqqq> mqqqqqqqq , database-field qqqqqqwqq> tqqqq> quoted-string qqqqqqqu tqqqq> numeric-literal qqqqqu tqqqq> arithmetic-expr qqqqqu tqqqq> missing-value qqqqqqqu tqqqq> concat-expr qqqqqqqqqu tqqqq> ( value-expr ) qqqqqqu mqqqq> q qq> value-expr qqqj Allows you to eliminate duplicate values for fields in a record stream. You can use the reduce-clause for an extraction or an extraction rollup transfer. If you specify a reduce-clause for a replication transfer, Replication Option issues an error message. 5 sort-clause (B)0sort-clause = qqq> SORTED BY qqwqwqqqqqqqqqqqqqqqqqqwqqqqq> value-expr qqwqqq> x tqq> ASCENDING qqqqu x x mqq> DESCENDING qqqj x mqqqqqqqqqqqqqqqqqqqqqq , database-field qqqqqqwqq> tqqqq> quoted-string qqqqqqqu tqqqq> numeric-literal qqqqqu tqqqq> arithmetic-expr qqqqqu tqqqq> missing-value qqqqqqqu tqqqq> concat-expr qqqqqqqqqu tqqqq> ( value-expr ) qqqqqqu mqqqq> q qq> value-expr qqqj Allows you to sort the records in the record stream by the values of specific fields. You can sort the records according to a value expression called a sort key. The sort key determines the order of the records in the record stream. You can use the sort- clause for an extraction or an extraction rollup transfer. If you specify a sort-clause for a replication transfer, Replication Option issues an error message. Specifying ASCENDING (the default) causes the records to be sorted in ascending order. Specifying DESCENDING causes Oracle Rdb to sort the records in descending order. The value expression specifies the sort value. This value is called the sort key. 3 More After you issue the DEFINE TRANSFER statement, the transfer does not execute until one of the following events occurs: - The time specified in the corresponding DEFINE SCHEDULE statement arrives - You issue a START TRANSFER NOW statement You cannot alter a transfer using RDO. You must either drop the transfer and re-create it, or use the SQL ALTER TRANSFER statement. You must have READ privilege for the relations and views of a Oracle Rdb source database that you specify in a DEFINE TRANSFER statement. Replication Option returns an error message when you specify relations and views in a DEFINE TRANSFER statement for which you do not have READ privilege. Replication Option does not check for READ privilege for relations and views when you specify a database accessed through the Rdb Transparent Gateways. You must execute the DEFINE TRANSFER statement outside of the scope of a transaction. If you issue this statement when a transaction is outstanding, Replication Option returns an error message. You can refer to relations, fields, and views in a DEFINE TRANSFER statement either implicitly or explicitly. When you include either the MOVE RELATIONS ALL, SELECT FIELDS ALL, or MOVE VIEWS ALL clause, you refer to relations, fields, or views implicitly. Replication Option uses the current definitions of the relations, fields, and views in the source database and stores those names explicitly in the transfer definition. You refer to relations, fields, and views explicitly when you include the MOVE RELATION, SELECT FIELDS, or MOVE VIEWS clauses and supply specific relation, field, or view names. All fields that you name in the record selection expression (RSE) of the DEFINE TRANSFER statement must also be included in the SELECT FIELDS clause. If you do not name the fields explicitly in the SELECT FIELDS select-field-name statement or implicitly in the select-field-name clause, Replication Option returns an error message when the transfer executes, indicating that the field name is not found in the symbol table. Replication Option transfers those COMPUTED_BY fields that depend only on the values of a relation in which the field is defined. You cannot transfer views that contain unsupported COMPUTED_BY fields. If views that contain unsupported COMPUTED_ BY fields are specified in the move-views-clause of a DEFINE TRANSFER statement, the transfer definition fails. You need to redefine the transfer, excluding the views that refer to the unsupported COMPUTED_BY fields. Replication Option allows you to transfer views in two ways: o Using the move-views-clause Replication Option transfers the definition of the view when you specify MOVE VIEWS view-name or MOVE VIEWS ALL. You must also explicitly or implicitly name in the DEFINE TRANSFER statement all the relations, views, or fields on which the transferred view definitions are based. The transfer will fail if any underlying relations, views, or fields are not named. o Using the move-relations-clause Replication Option transfers a view by creating a relation in the target database containing the view's records when you use the MOVE RELATION clause. This method improves query performance in the target database. For example, you can achieve the effect of a CROSS clause by transferring a view that is a CROSS in the source. You specify the relations you wish to move in the move-relations- clause and the views in the move-views-clause of the DEFINE TRANSFER statement. When you are doing an extraction rollup transfer, you specify the relations you wish to move in the move-relations-rollup-clause of the DEFINE TRANSFER statement. The same clause can occur in a DEFINE TRANSFER statement no more than once. You cannot specify the same relation or view more than once in the move clauses. If a relation name or view name appears in more than one move clause, Replication Option returns an error. Individual move-relations clauses are separated by semicolons, as indicated in the syntax diagrams. You can implement the move- relations-clause in two ways: o Specify MOVE RELATIONS ALL o Specify a series of relations separated by semicolons The move-relations-clause has the following characteristics and limitations: o All fields in each move-relations-clause must reside in the same relation. o You cannot name the same relation in more than one MOVE clause of a single transfer definition. The move-relations-rollup-clause has the following characteristics and limitations: o All fields in each move-relations-rollup-clause must reside in the same relation. o You cannot name the same relation in more than one MOVE clause of a single transfer definition. o For each relation of a move-relations-rollup-clause that you enter, you can supply a target relation specification in the form of an INTO RELATION clause. You can create one or many relations in the target database from several source database relations by renaming the target relations in the transfer definition. o You cannot specify MOVE RELATIONS ALL or SELECT FIELDS ALL in a move-relations-rollup-clause. When you specify these clauses in the DEFINE TRANSFER statement, the transfer will fail at the time of definition. The format of record selection expressions (RSE) that you can include in a transfer definition for extraction and extraction rollup transfers is more limited than the RSE allowed by RDO. You cannot include the following expressions and clauses in the RSE of the MOVE clause of the DEFINE TRANSFER statement: o CROSS clause o ANY operator o UNIQUE operator o Host variable o Statistical expressions o FIRST FROM expression o Database key values o Segmented string expressions You can specify FIRST clauses, REDUCED clauses, and SORTED BY clauses in the RSE of both extraction and extraction rollup transfers. You can achieve the effect of a CROSS clause in an extraction or an extraction rollup transfer by transferring a relation, that is itself a view, defined in the source database as a cross of two or more relations. The next example shows an extraction transfer definition that specifies the FIRST, REDUCED, and SORTED BY clauses in the RSE. The transfer also achieves the capability of a CROSS clause by moving a view, CURRENT_SALARY. In the source database, CURRENT_ SALARY is a cross of the EMPLOYEES, SALARY_HISTORY, and JOB_ HISTORY relations. RDO> INVOKE DATABASE FILENAME PERSONNEL RDO> DEFINE TRANSFER SALARY_HISTORY EXTRACTION cont> TO NEWNODE::NEWDISK:[NEWDIR]EMP_SALARY cont> MOVE RELATION FIRST 1000 E IN EMPLOYEES cont> REDUCED TO E.LAST_NAME cont> SORTED BY ASCENDING E.LAST_NAME cont> SELECT FIELDS ALL; cont> MOVE RELATION C IN CURRENT_SALARY SELECT FIELDS ALL cont> LOG IS FIRSTDISK:[FIRSTDIR]EMP_SALARY.LOG cont> END. Because you cannot use certain expressions to identify required records, the resulting groups of records transferred to the extraction database might be larger than the number of extracted records users will actually use. However, local users on the target node can then include precise RSEs accessing the extraction database. The format of an RSE that you can include in the transfer definition for replication transfers is more limited than the RSE allowed by RDO. You cannot include the following forms of expressions or clauses in the RSE of the MOVE clause of the DEFINE TRANSFER statement: o FIRST clause o CROSS clause o REDUCED clause o SORTED BY clause o ANY operator o UNIQUE operator o Host variable o Statistical expressions o FIRST FROM expression o Database key values o Segmented string expression Because you cannot use certain expressions to identify required records, the resulting groups of records transferred to the replication database might be larger than the number of records users will actually use. However, local users on the target node can then include precise record selection expressions when using RDO to access the replication database. If a transfer fails during execution, the transfer will begin again at the next scheduled retry time if the failure results from a nonfatal error. This next transfer will start from the beginning to ensure consistency with any updates that might have been made to the source database. Replication Option transfers only definitions for the database, fields, and relations specified in the transfer definition. If the source database includes additional database entities such as indexes, constraints, or access control lists, these are not transferred to the target database. You must either directly access the individual target database and explicitly define these entities or run command procedures to define the entities after the transfer executes. When relations specified in the transfer definition are created in the target database, they are given the access control lists (ACLs) that have the Oracle Rdb default values. You can change the ACLs in the target database after it has been created. Replication Option does not support SQL ANSI-style privileges. Target databases that Replication Option creates use the default Oracle Rdb ACL-style privileges. SQL ANSI-style privileges assigned to a source database are not copied to or preserved on target databases during transfers. In a transfer definition, you can use logical symbol names to name the source database file, the target database file, the copy process log file, and the prologue and the epilogue command procedure files. However, Replication Option treats these file names differently: o Source database file logical names If the source file name is a logical symbol that translates to a standard OpenVMS file name specification, Replication Option performs the logical name translation. The SHOW TRANSFER DEFINITION statement shows the source file name in its translated form. The logical symbol can also translate into strings that, in turn, contain logical symbols. As long as the resulting string looks like a OpenVMS file specification and the logical symbol is not a concealed device name, the translation process is repeated. If the logical symbol translates into an Rdb Transparent Gateway access string (for example, /TYPE=VIDA/FILE=ACCESS_FILE/...), Replication Option does no further translations. Even if the VIDA name string contains logical symbol references, these references are not translated into OpenVMS file specifications. You can use a logical name in place of the string to identify an Rdb Transparent Gateway database. o Target database file logical name If the target database name is a logical name, it is not translated by Replication Option when it is stored in the transfer definition. o Copy process log file logical name Replication Option translates the log file logical name in the same way as source file logical names, with the following exceptions: o The log file specification is translated in RDO when the DEFINE TRANSFER statement is executed. o These log file names must be standard OpenVMS file specifications. Node names or version numbers are not allowed. o Prologue and epilogue command procedure file logical names Replication Option translates the prologue and epilogue file logical names in the same way as the source file logical name, with the following exceptions: o The prologue and epilogue file specifications are translated in RDO when the DEFINE TRANSFER statement is executed. o The log file names must be standard OpenVMS file specifications. Node names and version numbers are allowed. Replication Option expects node names in file specifications to be from one to six characters long. DECnet/OSI permits node names to be much longer than this. In order to use Replication Option in a DECnet/OSI environment, you must define and use short synonyms for the long node names. Node name synonyms can be registered either in a local or distributed name service database. For details on establishing node name synonyms, refer to the documentation for DECnet/OSI. Prior to Rdb/VMS Version 3.1, data values for text fields were sorted in ascending or descending order based on the ASCII character set. With Rdb/VMS Version 3.1 and higher (and Oracle Rdb Version 5.0 and higher), you can create databases that specify different sort sequences on a field-by-field basis. You can specify the default for the database as a whole. Replication Option has not enhanced transfer definitions to handle collation sequences in any way. In addition, target databases created by Replication Option do not have the collation sequence attributes defined. Sorting in a target database remains ASCII-based. Currently, there is no way that users can transfer default collation sequences for fields or databases. In an extraction transfer, you can change table definitions in the source database or definitions of columns on which the transferred tables are based. However, those changes are not reflected in the transfer definition. In replication transfers, you can make such changes until the initial transfer begins. Thereafter, any attempts to change or delete definitions for tables or columns in the replication transfer are not allowed, with the exception of the following four column attributes; these attributes can be modified even after the initial transfer begins: o Edit string o Default value for DATATRIEVE o Query name for DATATRIEVE o Query header However, note that if you do change the attributes listed in a source column, a comparable change is not made automatically to the target database column. If you want that to happen, you must make the change in both the source and the target databases. In both extraction and replication transfers, if you make changes that cause the source tables or columns to be incompatible with the transfer definitions, Replication Option detects these differences at the time of transfer execution. The transfer fails, the transfer status reflects the failure, and the transfer is suspended. However, with extractions or initial replications, the copy process does not detect changes to the data type of a field. For example, you can change a field from the data type CHAR to the data type INTEGER without causing a failure. 3 Examples Example 1 The following example defines a transfer, NH_EMPLOYEES, that creates an extraction database. The transfer definition selects New Hampshire employees' address records for transfer to the remote node. RDO> INVOKE DATABASE FILENAME PERSONNEL RDO> DEFINE TRANSFER NH_EMPLOYEES EXTRACTION cont> DESCRIPTION IS /* Employees who live in New Hampshire */ cont> TO NODE1::DISK1:[ADAMS]NH_EMP cont> MOVE RELATION E IN EMPLOYEES WITH E.STATE = "NH" cont> SELECT FIELDS E.EMPLOYEE_ID, cont> E.LAST_NAME, cont> E.FIRST_NAME, cont> E.MIDDLE_INITIAL, cont> E.ADDRESS_DATA_1, cont> E.ADDRESS_DATA_2, cont> E.CITY, cont> E.STATE, cont> E.POSTAL_CODE cont> LOG IS NH_EMPLOYEES.LOG cont> END. Example 2 This example shows an extraction from a remote source database to a local target database. The DEFINE TRANSFER statement specifies the transfer of all personnel records to the target node. RDO> INVOKE DATABASE FILENAME NODE1::DISK1:[DIR1]PERSONNEL RDO> DEFINE TRANSFER PERS_EXAMP EXTRACTION cont> DESCRIPTION IS /* Extraction of personnel records*/ cont> TO [LEARNER.PERS]PERS_COPY cont> MOVE RELATIONS ALL cont> LOG IS [LEARNER.PERS]PERS_EXAMP.LOG cont> END. Example 3 This example shows an extraction transfer from a remote source to a remote target database. The log file, PERS_EXAMP.LOG, is located on the source node. RDO> INVOKE DATABASE FILENAME NODE1::DISK1:[DIR1]PERSONNEL RDO> DEFINE TRANSFER PERS_EXAMP EXTRACTION cont> DESCRIPTION IS /* Extraction of personnel records*/ cont> TO NODE2::DISK2:[PROTO]PERS_TARGET cont> MOVE RELATIONS ALL cont> LOG IS PERS_EXAMP.LOG cont> END. Example 4 This example of a replication transfer definition sends the entire colleges relation and the entire degrees relation to the target database. The replication database can be accessed for information about employees' college and degree histories. The transfer definition includes some database parameters for the target database. RDO> INVOKE DATABASE FILENAME PERSONNEL RDO> DEFINE TRANSFER COLLEGE_INFO REPLICATION cont> DESCRIPTION IS /* Info about employees' colleges only */ cont> TO NODE1::DISK1:[BURTON]EMP_COLLEGE cont> NUMBER OF USERS IS 25 cont> SNAPSHOT ALLOCATION IS 150 PAGES cont> MOVE RELATION C IN COLLEGES cont> SELECT FIELDS ALL; cont> MOVE RELATION D IN DEGREES cont> SELECT FIELDS ALL cont> LOG IS COLLEGE_INFO.LOG cont> END. Example 5 This replication transfer specifies three fields from the CREDIT_ CARDS source database for transfer to the target database. The fields are CARD_NUM, EXPIRATION_DATE, and VALID. Only invalid credit card records are selected for the transfer. RDO> DEFINE TRANSFER BAD_CARDS REPLICATION cont> DESCRIPTION IS /* Invalid credit cards */ cont> TO NODE1::DISK1:[CREDIT]BAD_CARDS cont> MOVE RELATION C IN CARDS WITH C.VALID = "N" cont> SELECT FIELDS C.CARD_NUM, cont> C.EXPIRATION_DATE, cont> C.VALID cont> LOG IS BAD_CARDS.LOG cont> END. Example 6 The following example defines a replication transfer that sends the entire EMPLOYEES, JOB_HISTORY, SALARY_HISTORY, DEPARTMENTS, and JOBS relations. The definition also selects three views for transfer: CURRENT_INFO, CURRENT_JOB, and CURRENT_SALARY. RDO> INVOKE DATABASE FILENAME PERSONNEL RDO> DEFINE TRANSFER NH_PERSONNEL REPLICATION cont> TO NODE1::DISK1:[DBADMIN]NHP.RDB cont> MOVE RELATION E IN EMPLOYEES SELECT FIELDS ALL; cont> MOVE RELATION JH IN JOB_HISTORY SELECT FIELDS ALL; cont> MOVE RELATION SH IN SALARY_HISTORY SELECT FIELDS ALL; cont> MOVE RELATION D IN DEPARTMENTS SELECT FIELDS ALL; cont> MOVE RELATION J IN JOBS SELECT FIELDS ALL cont> MOVE VIEWS CURRENT_INFO, CURRENT_JOB, CURRENT_SALARY cont> LOG FILE IS DISK1:[DBADMIN]NHP.LOG cont> END. Example 7 The following example moves the CURRENT_JOB view defined in the source database as a CROSS of the EMPLOYEES relation and the JOB_ HISTORY relation. You can achieve the effect of a CROSS clause by transferring a view that is a CROSS in the source database. On the target database, the records selected by the view are created as a relation. RDO> INVOKE DATABASE FILENAME PERSONNEL RDO> DEFINE TRANSFER CJOB EXTRACTION cont> TO NODE1::DISK1:[RAMESH]JOB_DB cont> MOVE RELATION C IN CURRENT_JOB WITH C.JOB_CODE = "SEII" cont> SELECT FIELDS C.LAST_NAME, C.FIRST_NAME, C.ADDRESS cont> LOG FILE IS CJOB.LOG cont> END TRANSFER. Example 8 The following example shows an extraction rollup transfer that invokes several source databases: PERSONNEL, WORKERS, and STAFF. The transfer selects fields in the EMPLOYEES relations from the three databases identified by the database handles DB1, DB2, and DB3 and located on three different nodes and in the JOBS relation from DB1. Then the transfer moves these relations to a single target database, LOCAL_DB. RDO> INVOKE DATABASE DB1=FILENAME "NODE1::DISK1:[DIR1]PERSONNEL" RDO> INVOKE DATABASE DB2=FILENAME "NODE2::DISK2:[DIR2]WORKERS" RDO> INVOKE DATABASE DB3=FILENAME "NODE3::DISK3:[DIR1]STAFF" RDO> DEFINE TRANSFER LABOR EXTRACTION ROLLUP cont> TO NODE4::DISK4:[DIR4]LOCAL_DB cont> MOVE RELATION E IN DB1.EMPLOYEES WITH E.EMP_CODE= "A+" cont> INTO RELATION EXEMPT_EMPLOYEES cont> SELECT FIELDS E.EMP.ID,E.SALARY,E.JOB_CODE; cont> MOVE RELATION E IN DB2.EMPLOYEES WITH E.EMP_CODE= "A+" cont> INTO RELATION EXEMPT_EMPLOYEES cont> SELECT FIELDS E.EMP_ID,E.SALARY,E.JOB_CODE; cont> MOVE RELATION E IN DB3.EMPLOYEES WITH E.EMP_CODE= "A+" cont> INTO RELATION EXEMPT_EMPLOYEES cont> SELECT FIELDS E.EMP.ID,E.SALARY,E.JOB_CODE; cont> MOVE RELATION J IN DB1.JOBS WITH J.JOB_CODE= "J17" cont> INTO RELATION ENTRY_JOBS cont> SELECT FIELDS J.JOB_NAME,J.JOB_CODE cont> LOG FILE IS DISK4:[DIR4]LOCAL.LOG cont> END. Example 9 The following EMPLOYEES transfer creates an extraction database. The transfer selects records using a first-clause, with-clause, reduce-clause, and sort-clause. RDO> INVOKE DATABASE FILENAME PERSONNEL RDO> DEFINE TRANSFER EMPLOYEES EXTRACTION cont> TO NODE1::DISK1:[NELSON]EMPLOYEES_INFO cont> MOVE RELATION FIRST 10 E IN EMPLOYEES cont> WITH E.CITY = "BOSTON" cont> REDUCED TO E.LAST_NAME, E.FIRST_NAME, E.ADDRESS cont> SORTED BY DESCENDING E.LAST_NAME cont> SELECT FIELDS E.LAST_NAME, E.FIRST_NAME, E.ADDRESS cont> LOG FILE IS DISK1:[NELSON]EMPLOYEES.LOG cont> END TRANSFER. Example 10 The following extraction transfer includes two command files. The prologue command procedure establishes a connection to a remote node, and the epilogue command procedure terminates the connection. This example shows how to specify the prologue file and epilogue file; it does not show the command procedures. RDO> INVOKE DATABASE FILENAME NODE1::DISK1:[DBADMIN.PERS]PERSONNEL RDO> DEFINE TRANSFER PERS_SAMPLE EXTRACTION cont> TO PERS_COPY cont> MOVE RELATIONS ALL cont> PROLOGUE FILE IS DIALUP.COM cont> EPILOGUE FILE IS HANGUP.COM cont> LOG IS PERS_SAMPLE.LOG cont> END. 2 DEFINE_SCHEDULE Creates a schedule definition and stores it in the transfer database. The schedule definition specifies when and how often a transfer should execute. A transfer can have only one schedule definition associated with it. Replication Option returns an error if you attempt to define a schedule for a transfer that already has one. 3 Format (B)0DEFINE SCHEDULE qq> FOR qq> transfer-name qqqk lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mqqqwqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqk mqq> START qq> start-date-time qqqj x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mqqqwqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqk mqq> EVERY qqwq> every-delta-time qqqqqwqqj x mq> every-absolute-time qqj x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mqwqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwqk mq> RETRY q> count q> TIMES qwqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwj x mq> RETRY EVERY qq> delta-time qj x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mqq> END qwqqqqqqqqqqqqqqqqqqqwqwqqqqqqqqqqqqqwqqq> . mqq> transfer-name qj mq> SCHEDULE qj 4 transfer-name The transfer for which this schedule is being defined. The transfer must already exist when you create a schedule definition for it. The transfer-name parameter is required. 4 start-date-time The time to execute the initial transfer. You can specify an absolute or delta time. If you supply an absolute time, the initial transfer will be executed at the time specified. If you use a delta time, Replication Option uses the current time and the delta-time value to calculate the actual transfer time. The START clause is optional. If you do not include a START clause, the start time is set to the current time so that the transfer will execute as soon as the transfer schedule definition is processed. The start-date-time parameter uses the following absolute and delta-time formats. You can omit any of the trailing fields in the date or time. You can omit any of the fields in the middle of the format as long as you include the punctuation marks. For more information on date and time formats, see the entry on the $BINTIM OpenVMS system service in the OpenVMS documentation set. Absolute-time dd-mmm-yyyy hh:mm:ss.cc Delta time dddd:hh:mm:ss.cc In the absolute and delta time designations, the abbreviations have the following meanings: dddd Number of days dd Day of the month mmm Month yyyy Year hh Hours mm Minutes ss Seconds cc Hundredths of a second 4 every-delta-time Used to calculate the time to execute the next transfer. The EVERY clause is optional. If you specify the EVERY clause, you must specify either every-delta-time or every-absolute-time. If you omit the EVERY clause, the transfer occurs only once. The valid specification for every-delta-time is the delta format used by the $BINTIM OpenVMS system service. The delta time you specify is the time from the completion of the last transfer sequence until the start of the next one. A transfer sequence is the set of transfers from the first attempt until one of the following conditions is met: the execution is successful, the maximum number of retries specified in the RETRY clause has been reached, or a fatal error has occurred (one for which retries are not attempted). 4 every-absolute-time (B)0every-absolute-time = qqqqqwqqqqqq> DAY qqqqqqwqqwqqqqqqqqqqq>qqqqqqqqqwqwqqq> tqqqqqq> WEEK qqqqqu mqq> AT qq> at-time qqj x tqqqqqq> MONTH qqqqj x mqqwqqq> weekday qqqwqqqqqqqqqq>qqqqqqqqwqqwqqj x mq> AT qq>at-time qqj x mqqqqqqqqqqqqqqqq , DEFINE SCHEDULE FOR NH_EMPLOYEES cont> START 24-JUN-1988 01:24:00.00 <---- Absolute time cont> EVERY DAY AT 17:30 <---- Absolute time cont> RETRY 3 TIMES cont> RETRY EVERY 0 00:30:00 cont> END SCHEDULE. Example 2 This example uses a delta-time specification to have 36 hours (1 day plus 12 hours) between the completion of one transfer execution and the beginning of the next. The example uses two delta times, EVERY 1 12:00 and RETRY EVERY 0 03:00:00. EVERY 1 12:00 states that there will be 36 hours (1 day plus 12 hours) between the completion of the first transfer and the beginning of the next. If transfer execution does not succeed on the first attempt, the transfer schedule permits Replication Option to make up to five additional attempts to complete the transfer. RETRY EVERY 0 03:00:00 means Replication Option should retry the transfer three hours after a nonfatal failure until the transfer completes successfully or until the maximum of five retries has been attempted. If the transfer does not complete successfully after five retries, the next attempt will be 36 hours after the last failed attempt. RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES cont> START 15-MAY-1988 cont> EVERY 1 12:00 !<---- 1 day plus 12 hours cont> RETRY 5 TIMES cont> RETRY EVERY 0 03:00:00 !<---- 3 hours cont> END. Example 3 The following transfer schedule causes Replication Option to execute a transfer for the first time at 12 noon on the 15th of October 1988. Subsequent transfers will occur every day thereafter at 5:30 p.m. If an error occurs preventing a successful transfer, Replication Option will retry every 30 minutes until the transfer is successful or the maximum of three retries has been reached. RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES cont> START 15-OCT-1988 12:00 cont> EVERY DAY AT 17:30 !<---- Every day cont> RETRY 3 TIMES cont> RETRY EVERY 0 00:30:00 cont> END SCHEDULE. Example 4 The following schedule definition assumes that you want to execute the transfer immediately after you complete the schedule definition and, therefore, it contains no START clause. If the system time is 20-OCT-1988 16:00:00 when you complete the DEFINE SCHEDULE statement, the next execution of the NH_EMPLOYEES transfer will start on 20-NOV-1988 16:00:00. RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES cont> EVERY MONTH cont> RETRY 3 TIMES cont> RETRY EVERY 0 00:30:00 cont> END. Example 5 This example calls for the NH_EMPLOYEES transfer to execute at 3:00 p.m. every Wednesday. The schedule definition calls for a maximum of three retries occurring at intervals of 30 minutes. RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES cont> START 12-NOV-1988 15:00:00.00 cont> EVERY WEDNESDAY AT 15:00:00 !<---- Wednesdays at 3 p.m. cont> RETRY 3 TIMES cont> RETRY EVERY 0 00:30:00 cont> END. Example 6 The following example causes an initial transfer to execute on the 15th of July at 5 p.m., on every Monday after the 15th at 5 p.m., every Tuesday at 11 a.m., and every Friday at 11 a.m. Because a RETRY clause is not specified, even if a nonfatal failure occurs, the transfer will not execute until the next regularly scheduled time. RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES cont> START 15-JUL-1988 17:00 cont> EVERY MONDAY, TUESDAY AT 11:00, FRIDAY cont> END. Example 7 This example causes a transfer to start at midnight on July 15th and on the 15th of every month thereafter at 7 p.m. RDO> DEFINE SCHEDULE FOR NH_EMPLOYEES cont> START 15-JUL-1988 cont> EVERY MONTH AT 19:00 cont> END. 2 REINITIALIZE_TRANSFER Reinitializes a replication transfer. You use this statement when the source database and the replication target database are no longer consistent with each other. 3 Format (B)0REINITIALIZE TRANSFER qqqqqq> transfer-name qqq> 4 transfer-name The replication transfer that you want to reinitialize. The transfer-name parameter is required. 3 More If you want to reinitialize a particular transfer, the transfer definition must be associated with your UIC, or you must have the DBCTRL or ALTER transfer privilege, or the OpenVMS BYPASS privilege. You can reinitialize a transfer only when the transfer is in the suspended state. To suspend a transfer, first issue a STOP TRANSFER statement. You must execute the REINITIALIZE TRANSFER statement outside the scope of a transaction. If you issue this statement when a transaction is outstanding, Replication Option returns an error message. After you enter the REINITIALIZE statement, the transfer remains in the suspended state. You must then issue a START TRANSFER statement to restart the transfer. The REINITIALIZE TRANSFER statement has different effects depending on the type of replication transfer being reinitialized and whether the transfer is TO NEW or TO EXISTING: o For a standard replication transfer created with SQL to an existing database, REINITIALIZE TRANSFER forces the next execution of the transfer to drop all target tables and create new target tables rather than update the tables with changed data. o For a replication transfer created with the NO DELETE attribute using SQL, REINITIALIZE TRANSFER forces the next execution of the transfer to drop all rows in the target tables except those whose dbkey has been set to zero. Any row whose dbkey has not been set to zero is copied to the target database from the source database. o For a replication transfer specifying TO NEW FILENAME target-file-spec created with SQL, or for any RDO transfer definition, new versions of the target database files are created and all tables specified in the transfer definition and their corresponding rows will be copied from the source database to the target database. 3 Example This example places the CARS_LAX transfer in a suspended state and then reinitializes it. The schedule and definition for this replication transfer remain in place. Once the transfer has been reinitialized, you can restart it. RDO> STOP TRANSFER CARS_LAX RDO> REINITIALIZE TRANSFER CARS_LAX RDO> START TRANSFER CARS_LAX 2 START_TRANSFER Executes a transfer on demand, or changes the state of a transfer from the suspended state to the scheduled, unscheduled, or active state. 3 Format (B)0START TRANSFER qqqqq> transfer-name qqk lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj mqqqwqqqqqqqqqqqq>qqqqqqqqqqqqqqwqqqq> mqqq> NOW qqwqqqqqqqqqqqqwqqj tq> WAIT qqqqu mq> NOWAIT qqj 4 transfer-name The transfer to be started. The transfer-name parameter is required. 4 NOW Changes the transfer state to active and begins execution. If the transfer has a schedule defined for it, subsequent transfers occur as specified by that schedule. The NOW argument is optional. 4 WAIT_NOWAIT Specifies whether Replication Option returns control to RDO immediately after the transfer starts or waits until the transfer completes. You must use the NOW argument if you specify WAIT or NOWAIT. The default, NOWAIT, causes Replication Option to return control immediately to the RDO command mode while the transfer executes. With NOWAIT in effect, you can enter other RDO statements while the copy process completes the transfer of database records to the target database. The WAIT option ensures that the transfer completes before control is returned to RDO. 3 More If you want to start a transfer, the transfer definition must be associated with your UIC, or you must have the ALTER transfer privilege, or the OpenVMS BYPASS privilege. You can use the START TRANSFER statement without any qualifiers to change the state of a suspended transfer. Issuing the START TRANSFER statement places the transfer in the scheduled state if a schedule definition exists for the transfer. Execution then occurs at the next scheduled time. If a schedule definition does not exist, the transfer is placed in the unscheduled state and will execute only when you issue a START TRANSFER statement using the NOW qualifier or you define a schedule for the transfer. If you specify both the NOW and WAIT arguments and your transfer has an epilogue procedure, Replication Option waits for the epilogue procedure to finish before resuming execution. You cannot enter the START TRANSFER statement when a transaction is outstanding. You must terminate any outstanding transactions before issuing the START TRANSFER statement. You can use the START TRANSFER statement to initiate a transfer on demand by including the NOW option. The NOW option immediately places the transfer in the active state. This execute-on-demand feature is useful in batch processing environments when you want to initiate the transfer after another job has completed successfully, regardless of the transfer's schedule. When you define a one-time-only transfer schedule and specify a transfer time that has already passed, issuing a START TRANSFER statement changes the transfer status from suspended to scheduled. However, when you issue a SHOW TRANSFER STATUS statement, the "next transfer to be executed" phrase is not included. To avoid this problem and cause the transfer to execute, use the START TRANSFER NOW statement. Do not issue a START TRANSFER NOW WAIT statement when RDO is attached to a source database and the transfer is either a replication transfer that has not finished or a replication initialization transfer. Instead, issue a FINISH statement to detach from the database, and then enter the START TRANSFER NOW WAIT statement. Otherwise, the copy process waits indefinitely for you to release the source database. Because you specified that you want to wait for the copy process to complete, the transfer operation will never complete. 3 Examples Example 1 This example starts a transfer called ENROLL_SPANISH1. If this transfer has a schedule defined for execution one hour from now but the transfer is suspended, issuing the START TRANSFER statement only changes the transfer's state to scheduled. Execution of the transfer will not occur for another hour. RDO> START TRANSFER ENROLL_SPANISH1 Example 2 In this example, transfer ENROLL_SPANISH1 has been defined but has no schedule. You issue this START TRANSFER NOW statement because you want to execute the transfer immediately. Control returns to RDO as soon as the transfer begins. RDO> START TRANSFER ENROLL_SPANISH1 NOW 2 STOP_TRANSFER Places a transfer in the suspended state. Replication Option does not attempt to execute the transfer until you remove it from the suspended state using the START TRANSFER statement. If the transfer is in the active state, the STOP TRANSFER statement also stops the copy process associated with that transfer. 3 Format (B)0STOP TRANSFER qqqqqqq> transfer-name qqqqq> 4 transfer-name The transfer to be suspended. The transfer-name parameter is required. 3 More If you want to stop a particular transfer, the transfer definition must be associated with your UIC, or you must have ALTER or DROP transfer privilege, or the OpenVMS BYPASS privilege. You must terminate any outstanding transactions before you issue a STOP TRANSFER statement. If you want to stop a particular transfer, the transfer definition must be associated with your UIC. A transfer cannot occur until you remove it from the suspended state using the START TRANSFER statement. If the transfer is in the active state, the STOP TRANSFER statement also stops the copy process associated with that transfer. After you stop a currently executing extraction, extraction rollup, or initial replication transfer, you cannot access the partially created target database unless you restart the transfer. If a replication update transfer is executing and you stop the transfer, users of the target database can continue their work unaffected. Furthermore, stopping the transfer does not stop the capture of the changes in the source database (written to RDB$CHANGES). The changes are transferred to the target database when the transfer is restarted. No updates to the target database are missed as a result of stopping a replication transfer for which the target relations have already been created. However, since stopping a transfer does not stop the capture of record changes, changes continue to be written to RDB$CHANGES regardless of a transfer's state. Records are added to RDB$CHANGES even for transfers that are suspended for a long time. The number of records in RDB$CHANGES and the overall size of the database both continue to grow. 3 Example The following example places the EUROPE_PERS transfer in the suspended state. RDO> STOP TRANSFER EUROPE_PERS 2 RDO_ERRORS RDO$MSG 3 ABSACTIVE AIJ backup active or backup operations suspended on this node Explanation: After-image journal backup operations have already been suspended from this node. User Action: Examine the secondary message(s) or look in the database monitor log file (SYS$SYSTEM:*MON.LOG) for more information. 3 ABSNSUSPENDED AIJ backup operations not suspended on this node Explanation: After-image journal backup operations have not been suspended from this node. User Action: Examine the secondary message(s) or look in the database monitor log file (SYS$SYSTEM:*MON.LOG) for more information. 3 ABSSUSPENDED AIJ backup operations already suspended on this node Explanation: After-image journal backup operations have already been suspended from this node. User Action: Examine the secondary message(s) or look in the database monitor log file (SYS$SYSTEM:*MON.LOG) for more information. 3 ACCVIO access violation on read/write of user address Explanation: A readable parameter is not readable by the DBCS or a writeable parameter is not writeable by the DBCS. User Action: Pass good parameters to the DBCS. 3 ACENOTFND no matching access control entry found Explanation: In a protection statement that refers to an existing access control entry, there was no existing entry that matched the input. User Action: Use SHOW PROTECTION to see what the ACL currently looks like, and correct your statement. 3 ACLNOTIMP ACL not imported for Explanation: The ACL contained in the RBR file could not be imported to the named object (database/relation/field) User Action: If you really want it, you must either obtain the needed privileges (BYPASS) or import the database under the account of the former owner (which may not be sufficient anyway). If you do not care about the restoration of protections you can ignore the message or import the database using the NOACL parameter which will cause all privileges and protections in the RBR file to be ignored. 3 ACTMISMATCH journal is for database activation