Order Number: AA-JD84E-TE VAX Data Distributor VAX Data Distributor VAX Data Distributor Release Notes Release Notes Release Notes November 1990 November 1990 November 1990 This document contains the release notes for VAX Data Distributor Version 2.2. VMS OPERATING SYSTEM: OPERATING SYSTEM: OPERATING SYSTEM: VAX Data Distributor Version 2.2 SOFTWARE VERSION: SOFTWARE VERSION: SOFTWARE VERSION: Digital Equipment Corporation Digital Equipment Corporation Digital Equipment Corporation __________ Copyright ©1988, 1989, 1990 The following are trademarks of Digital Equipment Corporation: ALL-IN-1, CDD/Plus, DEC, DEC/CMS, DECdecision, DECdtm, DECforms, DECintact, DEC/MMS, DECnet, DECtp, DECtrace, DECwindows, MicroVAX, ULTRIX, UNIBUS, VAX, VAX ACMS, VAX Ada, VAX BASIC, VAX C, VAX CDD, VAXcluster, VAX COBOL, VAX DATATRIEVE, VAX DBMS, VAXELN, VAX FMS, VAX FORTRAN, VAX Pascal, VAX RALLY, VAX Rdb/ELN, VAX Rdb/VMS, VAX RMS, VAX SPM, VAXstation, VAX TEAMDATA, VIDA, VMS, VT, and the DIGITAL Logo. The following are third-party trademarks: IBM is a registered trademark and DB2 is a trademark of International Business Machines Corporation; IDMS/R is a trademark of Cullinet Software, Inc.; ORACLE is a trademark of the ORACLE Corporation. This document was prepared using VAX DOCUMENT, Version 1.2 Contents Contents Contents PREFACE vi PREFACE vi PREFACE vi CHAPTER 1 GENERAL INFORMATION 1-1 CHAPTER 1 GENERAL INFORMATION 1-1 CHAPTER 1 GENERAL INFORMATION 1-1 1.1 INSTALLATION PROCESS 1-1 1.1 INSTALLATION PROCESS 1-1 1.1 INSTALLATION PROCESS 1-1 1.1.1 Requirements for Installing Data Distributor 1-1 1.1.1 Requirements for Installing Data Distributor 1-1 1.1.1 Requirements for Installing Data Distributor 1-1 1.1.2 Changing the Internal Structure of a Transfer 1.1.2 Changing the Internal Structure of a Transfer 1.1.2 Changing the Internal Structure of a Transfer Database 1-2 Database 1-2 Database 1-2 1.1.3 Changing the Internal Structure of a Source 1.1.3 Changing the Internal Structure of a Source 1.1.3 Changing the Internal Structure of a Source Database 1-2 Database 1-2 Database 1-2 1.1.4 Changing the Internal Structure of a Target 1.1.4 Changing the Internal Structure of a Target 1.1.4 Changing the Internal Structure of a Target Database 1-2 Database 1-2 Database 1-2 1.2 WHERE TO FIND ONLINE HELP AND ERROR MESSAGE 1.2 WHERE TO FIND ONLINE HELP AND ERROR MESSAGE 1.2 WHERE TO FIND ONLINE HELP AND ERROR MESSAGE DOCUMENTATION 1-3 DOCUMENTATION 1-3 DOCUMENTATION 1-3 1.2.1 Getting Help on Data Distributor Statements 1-3 1.2.1 Getting Help on Data Distributor Statements 1-3 1.2.1 Getting Help on Data Distributor Statements 1-3 1.2.2 Error Messages 1-3 1.2.2 Error Messages 1-3 1.2.2 Error Messages 1-3 CHAPTER 2 NEW AND CHANGED FEATURES 2-1 CHAPTER 2 NEW AND CHANGED FEATURES 2-1 CHAPTER 2 NEW AND CHANGED FEATURES 2-1 2.1 TRANSFERS TO EXISTING DATABASES 2-1 2.1 TRANSFERS TO EXISTING DATABASES 2-1 2.1 TRANSFERS TO EXISTING DATABASES 2-1 2.2 NEW AND CHANGED TABLE DEFINITIONS 2-1 2.2 NEW AND CHANGED TABLE DEFINITIONS 2-1 2.2 NEW AND CHANGED TABLE DEFINITIONS 2-1 2.2.1 Target Database Table Definitions 2-2 2.2.1 Target Database Table Definitions 2-2 2.2.1 Target Database Table Definitions 2-2 2.2.2 Transfer Database Table Definitions 2-3 2.2.2 Transfer Database Table Definitions 2-3 2.2.2 Transfer Database Table Definitions 2-3 2.3 TARGET DOMAIN DESCRIPTION CHANGES 2-3 2.3 TARGET DOMAIN DESCRIPTION CHANGES 2-3 2.3 TARGET DOMAIN DESCRIPTION CHANGES 2-3 2.4 NEW AND CHANGED TARGET INDEX DEFINITIONS 2-4 2.4 NEW AND CHANGED TARGET INDEX DEFINITIONS 2-4 2.4 NEW AND CHANGED TARGET INDEX DEFINITIONS 2-4 2.5 RDB/VMS VERSION 4.0 CHANGES AFFECTING DATA 2.5 RDB/VMS VERSION 4.0 CHANGES AFFECTING DATA 2.5 RDB/VMS VERSION 4.0 CHANGES AFFECTING DATA DISTRIBUTOR 2-5 DISTRIBUTOR 2-5 DISTRIBUTOR 2-5 2.5.1 Default Database and Table Protection 2-5 2.5.1 Default Database and Table Protection 2-5 2.5.1 Default Database and Table Protection 2-5 2.5.2 New SIGNED BYTE Datatype 2-6 2.5.2 New SIGNED BYTE Datatype 2-6 2.5.2 New SIGNED BYTE Datatype 2-6 2.6 REPLICATION TRANSFERS PERFORMANCE OPTION 2-6 2.6 REPLICATION TRANSFERS PERFORMANCE OPTION 2-6 2.6 REPLICATION TRANSFERS PERFORMANCE OPTION 2-6 2.7 LIMITING CONCURRENT TRANSFERS ON A CPU 2-8 2.7 LIMITING CONCURRENT TRANSFERS ON A CPU 2-8 2.7 LIMITING CONCURRENT TRANSFERS ON A CPU 2-8 iii iii iii Contents Contents Contents 2.8 DEC RDBACCESS FOR VMS, ORACLE SERVER SOFTWARE 2.8 DEC RDBACCESS FOR VMS, ORACLE SERVER SOFTWARE 2.8 DEC RDBACCESS FOR VMS, ORACLE SERVER SOFTWARE SUPPORT 2-9 SUPPORT 2-9 SUPPORT 2-9 CHAPTER 3 PROBLEMS CORRECTED 3-1 CHAPTER 3 PROBLEMS CORRECTED 3-1 CHAPTER 3 PROBLEMS CORRECTED 3-1 3.1 INCONSISTENT REPLICATED DATA WHEN TRIGGERS ARE 3.1 INCONSISTENT REPLICATED DATA WHEN TRIGGERS ARE 3.1 INCONSISTENT REPLICATED DATA WHEN TRIGGERS ARE INVOLVED 3-1 INVOLVED 3-1 INVOLVED 3-1 3.2 RETRYING LOCK CONFLICT AND DEADLOCK ERRORS 3-1 3.2 RETRYING LOCK CONFLICT AND DEADLOCK ERRORS 3-1 3.2 RETRYING LOCK CONFLICT AND DEADLOCK ERRORS 3-1 3.3 SERIAL EXECUTION OF REINITIALIZED REPLICATION 3.3 SERIAL EXECUTION OF REINITIALIZED REPLICATION 3.3 SERIAL EXECUTION OF REINITIALIZED REPLICATION TRANSFERS 3-2 TRANSFERS 3-2 TRANSFERS 3-2 3.4 BAD SQL TRANSFER DEFINITION FROM VIDA FOR DB2 3-3 3.4 BAD SQL TRANSFER DEFINITION FROM VIDA FOR DB2 3-3 3.4 BAD SQL TRANSFER DEFINITION FROM VIDA FOR DB2 3-3 3.5 INCORRECT EPILOGUE STATUS CODES 3-4 3.5 INCORRECT EPILOGUE STATUS CODES 3-4 3.5 INCORRECT EPILOGUE STATUS CODES 3-4 CHAPTER 4 KNOWN PROBLEMS AND RESTRICTIONS 4-1 CHAPTER 4 KNOWN PROBLEMS AND RESTRICTIONS 4-1 CHAPTER 4 KNOWN PROBLEMS AND RESTRICTIONS 4-1 4.1 USING LIB$DT_INPUT_FORMAT TO CHANGE DATE INPUT 4.1 USING LIB$DT_INPUT_FORMAT TO CHANGE DATE INPUT 4.1 USING LIB$DT_INPUT_FORMAT TO CHANGE DATE INPUT FORMAT 4-1 FORMAT 4-1 FORMAT 4-1 4.2 RESTRICTIONS FOR EXTRACTION, EXTRACTION ROLLUP, 4.2 RESTRICTIONS FOR EXTRACTION, EXTRACTION ROLLUP, 4.2 RESTRICTIONS FOR EXTRACTION, EXTRACTION ROLLUP, AND REPLICATION TRANSFERS 4-2 AND REPLICATION TRANSFERS 4-2 AND REPLICATION TRANSFERS 4-2 4.2.1 Data Distributor Version 2.2 CREATE TRANSFER 4.2.1 Data Distributor Version 2.2 CREATE TRANSFER 4.2.1 Data Distributor Version 2.2 CREATE TRANSFER Statement Syntax Change and Existing Command Statement Syntax Change and Existing Command Statement Syntax Change and Existing Command Procedures 4-2 Procedures 4-2 Procedures 4-2 4.2.2 Transfer Schedule Defined for Time Before 4.2.2 Transfer Schedule Defined for Time Before 4.2.2 Transfer Schedule Defined for Time Before Transfer Execution 4-2 Transfer Execution 4-2 Transfer Execution 4-2 4.2.3 Transfer Completion Status After a Transfer Is 4.2.3 Transfer Completion Status After a Transfer Is 4.2.3 Transfer Completion Status After a Transfer Is Stopped 4-3 Stopped 4-3 Stopped 4-3 4.2.4 Data Definition Changes After a Transfer Is 4.2.4 Data Definition Changes After a Transfer Is 4.2.4 Data Definition Changes After a Transfer Is Defined 4-3 Defined 4-3 Defined 4-3 4.2.5 Information Retrieval from a Transfer 4.2.5 Information Retrieval from a Transfer 4.2.5 Information Retrieval from a Transfer Database 4-4 Database 4-4 Database 4-4 4.3 RESTRICTION FOR EXTRACTION AND EXTRACTION ROLLUP 4.3 RESTRICTION FOR EXTRACTION AND EXTRACTION ROLLUP 4.3 RESTRICTION FOR EXTRACTION AND EXTRACTION ROLLUP TRANSFERS ONLY 4-5 TRANSFERS ONLY 4-5 TRANSFERS ONLY 4-5 4.3.1 SQL Does Not Translate Logical Names 4.3.1 SQL Does Not Translate Logical Names 4.3.1 SQL Does Not Translate Logical Names Referencing Source Databases 4-6 Referencing Source Databases 4-6 Referencing Source Databases 4-6 4.4 RESTRICTION FOR EXTRACTION TRANSFERS ONLY 4-6 4.4 RESTRICTION FOR EXTRACTION TRANSFERS ONLY 4-6 4.4 RESTRICTION FOR EXTRACTION TRANSFERS ONLY 4-6 iv iv iv Contents Contents Contents 4.4.1 Views Containing Computed_By Columns Cannot 4.4.1 Views Containing Computed_By Columns Cannot 4.4.1 Views Containing Computed_By Columns Cannot Become Tables 4-7 Become Tables 4-7 Become Tables 4-7 4.5 RESTRICTIONS FOR EXTRACTION ROLLUP TRANSFERS ONLY 4-7 4.5 RESTRICTIONS FOR EXTRACTION ROLLUP TRANSFERS ONLY 4-7 4.5 RESTRICTIONS FOR EXTRACTION ROLLUP TRANSFERS ONLY 4-7 4.5.1 Column Names for Like Tables Must Be 4.5.1 Column Names for Like Tables Must Be 4.5.1 Column Names for Like Tables Must Be Identical 4-7 Identical 4-7 Identical 4-7 4.5.2 SQL Privileges Can Restrict Access to Source 4.5.2 SQL Privileges Can Restrict Access to Source 4.5.2 SQL Privileges Can Restrict Access to Source Tables 4-8 Tables 4-8 Tables 4-8 4.6 RESTRICTIONS FOR REPLICATION TRANSFERS ONLY 4-9 4.6 RESTRICTIONS FOR REPLICATION TRANSFERS ONLY 4-9 4.6 RESTRICTIONS FOR REPLICATION TRANSFERS ONLY 4-9 4.6.1 Restriction on Fields Named in an Rdb/VMS RDO 4.6.1 Restriction on Fields Named in an Rdb/VMS RDO 4.6.1 Restriction on Fields Named in an Rdb/VMS RDO RSE 4-9 RSE 4-9 RSE 4-9 4.6.2 Restriction on Columns Named in an SQL Select 4.6.2 Restriction on Columns Named in an SQL Select 4.6.2 Restriction on Columns Named in an SQL Select Expression 4-10 Expression 4-10 Expression 4-10 4.6.3 Deleting Transfer Definitions 4-10 4.6.3 Deleting Transfer Definitions 4-10 4.6.3 Deleting Transfer Definitions 4-10 4.6.4 Restriction on Two-Way Replication Transfers 4-11 4.6.4 Restriction on Two-Way Replication Transfers 4-11 4.6.4 Restriction on Two-Way Replication Transfers 4-11 4.7 RESTRICTIONS FOR TRANSFERRING INTO AN EXISTING 4.7 RESTRICTIONS FOR TRANSFERRING INTO AN EXISTING 4.7 RESTRICTIONS FOR TRANSFERRING INTO AN EXISTING DATABASE 4-13 DATABASE 4-13 DATABASE 4-13 4.7.1 Transferring a Table to an Existing Database 4.7.1 Transferring a Table to an Existing Database 4.7.1 Transferring a Table to an Existing Database Containing the Same Table Name 4-13 Containing the Same Table Name 4-13 Containing the Same Table Name 4-13 4.7.2 No Extraction Rollup Into Existing Databases 4-14 4.7.2 No Extraction Rollup Into Existing Databases 4-14 4.7.2 No Extraction Rollup Into Existing Databases 4-14 4.7.3 No Union of Source and Target Data 4-15 4.7.3 No Union of Source and Target Data 4-15 4.7.3 No Union of Source and Target Data 4-15 4.7.4 No DEFINE TRANSFER Into an Existing Database 4-15 4.7.4 No DEFINE TRANSFER Into an Existing Database 4-15 4.7.4 No DEFINE TRANSFER Into an Existing Database 4-15 4.8 CLUSTER RESTRICTIONS 4-15 4.8 CLUSTER RESTRICTIONS 4-15 4.8 CLUSTER RESTRICTIONS 4-15 4.8.1 Load Balancing in a Cluster 4-15 4.8.1 Load Balancing in a Cluster 4-15 4.8.1 Load Balancing in a Cluster 4-15 TABLES TABLES TABLES 2-1 Columns for the RDB$VINTAGE Table 2-2 2-1 Columns for the RDB$VINTAGE Table 2-2 2-1 Columns for the RDB$VINTAGE Table 2-2 2-2 Columns for the RDBVMS$TRANSFER_OWNER Table 2-3 2-2 Columns for the RDBVMS$TRANSFER_OWNER Table 2-3 2-2 Columns for the RDBVMS$TRANSFER_OWNER Table 2-3 2-3 New Columns for the DDAL$TRANSFERS Table 2-3 2-3 New Columns for the DDAL$TRANSFERS Table 2-3 2-3 New Columns for the DDAL$TRANSFERS Table 2-3 2-4 New Columns for the DDAL$TRANSFER_VIEWS Table 2-3 2-4 New Columns for the DDAL$TRANSFER_VIEWS Table 2-3 2-4 New Columns for the DDAL$TRANSFER_VIEWS Table 2-3 2-5 New Domain Descriptions 2-4 2-5 New Domain Descriptions 2-4 2-5 New Domain Descriptions 2-4 2-6 Indexes for the RDB$CHANGES Table 2-7 2-6 Indexes for the RDB$CHANGES Table 2-7 2-6 Indexes for the RDB$CHANGES Table 2-7 2-7 Equivalence Names for Index Logicals 2-8 2-7 Equivalence Names for Index Logicals 2-8 2-7 Equivalence Names for Index Logicals 2-8 3-1 Corrected Status Codes 3-4 3-1 Corrected Status Codes 3-4 3-1 Corrected Status Codes 3-4 v v v Contents Contents Contents 4-1 Transfer Database Tables 4-5 4-1 Transfer Database Tables 4-5 4-1 Transfer Database Tables 4-5 vi vi vi _____________________________________________________________________ Preface Preface Preface This manual describes new and changed features, problems corrected in this release, and current restrictions. It also discusses general information about VAX Data Distributor Version 2.2 that can help you use the product. VAX Data Distributor software is referred to as Data Distributor throughout this document. ___________________________________________________________________ Intended Audience Intended Audience Intended Audience This manual is intended for all Data Distributor users. ___________________________________________________________________ Product Compatibility Product Compatibility Product Compatibility Information about the versions of the operating system and related software that are compatible with this version of Data Distributor is included in the , which ___ ____ ___________ ____________ _____ VAX Data Distributor Installation Guide accompanies the Data Distributor media kit. For information on the compatibility of other software products with this version of Data Distributor, refer to the System Support Addendum (SSA) that comes with the Software Product Description (SPD). You can use the SPD/SSA to verify which versions of your operating system are compatible with this version of Data Distributor. vi vi vi Preface Preface Preface ___________________________________________________________________ Structure Structure Structure This manual contains four chapters: Chapter 1 Provides general information about Data Distributor. Chapter 2 Describes new and changed features in Data Distributor. Chapter 3 Describes software problems that have been corrected in Data Distributor. Chapter 4 Describes software restrictions in effect for Data Distributor. ___________________________________________________________________ Related Manuals Related Manuals Related Manuals The other manuals in the Data Distributor documentation set are: o -Describes how to in- ___ ____ ___________ ____________ _____ VAX Data Distributor Installation Guide stall Data Distributor. o -Provides information, guidelines, ___ ____ ___________ ________ VAX Data Distributor Handbook and examples for distributing all or portions of VAX Rdb/VMS, VIDA, or RdbAccess for ORACLE database products in a network. For further information on topics covered in this document, refer to the following manuals: o ___ _______ ___ _________ ______ VAX Rdb/VMS SQL Reference Manual Describes the statements, the interactive, dynamic, and module language interfaces, and the syntax for SQL, the structured query language interface for Rdb/VMS. It provides full de- scriptions of Data Distributor statements used with interactive SQL. o ___ _______ ___ ___ ___ _________ ______ VAX Rdb/VMS RDO and RMU Reference Manual vii vii vii Preface Preface Preface Provides full descriptions of Data Distributor statements used with the Relational Database Operator utility (RDO) of Rdb/VMS. The documentation in the reference manual is provided for your convenience. It documents the same statements found in Chapter 9 of the . ___ ____ ___________ ________ VAX Data Distributor Handbook o ____ ___ ___ ________ VIDA for DB2 Overview Describes how VIDA provides transparent access to DB2 data. The document contains an overview of the products that serve as interfaces for creating relational databases on a VAX system. Data Distributor lets you extract databases created by VIDA for DB2. o ___ _________ ___ ____ ______ ______ ________ DEC RdbAccess for VMS, ORACLE Server Handbook Describes how DEC RdbAccess for VMS, ORACLE Server software provides transparent access to data stored in ORACLE databases. ___________________________________________________________________ Conventions Conventions Conventions In examples, an implied carriage return occurs at the end of each line, unless otherwise noted. You must press the RETURN key at the end of a line of input. This manual uses the following conventions: Color In printed manuals, color in examples shows user input. $ The dollar sign represents the DIGITAL Command Language prompt. This symbol indicates that the DCL interpreter is ready for input. viii viii viii Preface Preface Preface ___________________________________________________________________ References to Products References to Products References to Products The Data Distributor documentation to which this manual belongs often refers to products by their abbreviated names: o VAX CDD/Plus software is referred to as CDD/Plus. o VAX Rdb/VMS software is referred to as Rdb/VMS. o VIDA with IDMS/R software is referred to as VIDA, unless dif- ferentiation from the VIDA for DB2 product is necessary. o VIDA for DB2 software is referred to as VIDA, unless differen- tiation from the VIDA with IDMS/R product is necessary. o DEC RdbAccess for VMS, ORACLE Server software is referred to as RdbAccess for ORACLE. ix ix ix Chapter 1 Chapter 1 Chapter 1 General Information General Information General Information This chapter contains information about the Data Distributor installation process and other general topics. 1.1 Installation Process 1.1 Installation Process 1.1 Installation Process This section contains information about the installation of Data Distributor Version 2.2. 1.1.1 Requirements for Installing Data Distributor 1.1.1 Requirements for Installing Data Distributor 1.1.1 Requirements for Installing Data Distributor The following requirements must be met before Data Distributor Version 2.2 can be installed: o VMS Version 5.3 or higher must be installed on your standalone system or on your VAXcluster. o VAX Rdb/VMS Version 4.0 or higher must be installed on your system. o Database conversion required by the VAX Rdb/VMS Version 4.0 installation must be performed. You can find instructions about database conversion in the for ___ _______ ____________ _____ VAX Rdb/VMS Installation Guide Version 4.0. General Information 1-1 General Information 1-1 General Information 1-1 1.1.2 Changing the Internal Structure of a Transfer Database 1.1.2 Changing the Internal Structure of a Transfer Database 1.1.2 Changing the Internal Structure of a Transfer Database Customers who convert from Data Distributor Version 2.1 to 2.2 must perform a conversion procedure on their existing transfer databases. The conversion procedure adds new data definitions to the transfer database to support the Version 2.2 features. The DDAL$CONVERT_TR_DB.COM procedure has been modified to do the necessary conversion to Version 2.2. 1.1.3 Changing the Internal Structure of a Source Database 1.1.3 Changing the Internal Structure of a Source Database 1.1.3 Changing the Internal Structure of a Source Database If you upgrade to Data Distributor Version 2.2 from an earlier release, there are no special Data Distributor conversion re- quirements for source databases. However, you may need to con- vert source databases to conform with the latest version of VAX Rdb/VMS. Refer to the for conver- ___ _______ ____________ _____ VAX Rdb/VMS Installation Guide sion requirements. 1.1.4 Changing the Internal Structure of a Target Database 1.1.4 Changing the Internal Structure of a Target Database 1.1.4 Changing the Internal Structure of a Target Database Data Distributor Version 2.2 has added columns to its RDB$VINTAGE table and has introduced a new table, RDBVMS$TRANSFER_OWNER. Databases that were the targets of transfers in earlier ver- sions of Data Distributor need to be converted to the Version 2.2 format. You need not take any special action to perform this conversion. When you execute a transfer using Version 2.2, the copy process converts the target database automatically. However, you must convert existing target databases to the latest Rdb/VMS format before executing transfers using Data Distributor Version 2.2. For information on converting Rdb/VMS databases, see the ___ VAX . _______ ____________ _____ Rdb/VMS Installation Guide 1-2 General Information 1-2 General Information 1-2 General Information 1.2 Where to Find Online Help and Error Message Documentation 1.2 Where to Find Online Help and Error Message Documentation 1.2 Where to Find Online Help and Error Message Documentation This section describes how to access Data Distributor online help and error message documentation. 1.2.1 Getting Help on Data Distributor Statements 1.2.1 Getting Help on Data Distributor Statements 1.2.1 Getting Help on Data Distributor Statements Data Distributor provides an online version of these release notes, which are installed on your system in the SYS$HELP di- rectory. The file is called DDAL022.RELEASE_NOTES. In Rdb/VMS Version 4.0, the SQL help topic Data_Distributor Release_Notes includes the location of the online release notes file. Help information on Data Distributor commands is part of SQL HELP for Rdb/VMS. After you type HELP at the SQL> prompt, specify a Data Distributor statement by entering DATA_DISTRIBUTOR and the statement name. For example, to find help on the CREATE TRANSFER statement, type HELP DATA_DISTRIBUTOR CREATE_TRANSFER at the SQL> prompt. For a complete list of Data Distributor help topics, type HELP DATA_DISTRIBUTOR. 1.2.2 Error Messages 1.2.2 Error Messages 1.2.2 Error Messages Data Distributor error message information is contained in a file that you can view on line by using the DCL TYPE command or print by using the DCL PRINT command. The DDAL$MSG.DOC error message file is located in the SYS$HELP directory. General Information 1-3 General Information 1-3 General Information 1-3 Chapter 2 Chapter 2 Chapter 2 New and Changed Features New and Changed Features New and Changed Features This chapter describes new and changed features for VAX Data Distributor Version 2.2. 2.1 Transfers to Existing Databases 2.1 Transfers to Existing Databases 2.1 Transfers to Existing Databases A common aspect of all Data Distributor transfers prior to Version 2.2 is that the target database is created and maintained by Data Distributor. With Version 2.2, you now have a choice: you can direct Data Distributor to create a new database as before, or you can specify a database that already exists. This feature is documented in Chapter 8 of the . ___ ____ ___________ ________ VAX Data Distributor Handbook 2.2 New and Changed Table Definitions 2.2 New and Changed Table Definitions 2.2 New and Changed Table Definitions In order to manage transfers into existing databases, the tables maintained by Data Distributor in target and in transfer databases have been augmented. This section outlines those changes. For a complete description of the augmented tables, refer to Appendix A in the . ___ ____ ___________ ________ VAX Data Distributor Handbook New and Changed Features 2-1 New and Changed Features 2-1 New and Changed Features 2-1 2.2.1 Target Database Table Definitions 2.2.1 Target Database Table Definitions 2.2.1 Target Database Table Definitions The RDB$VINTAGE table in target databases has been changed to include new columns. In addition, for transfers to existing databases, a new table, RDBVMS$TRANSFER_OWNER, has been added. Table 2-1 lists the columns found in the RDB$VINTAGE table, shows the datatype, and indicates whether the column is new for Data Distributor Version 2.2. __________________________________________________________________ Table 2-1: Columns for the RDB$VINTAGE Table Table 2-1: Columns for the RDB$VINTAGE Table Table 2-1: Columns for the RDB$VINTAGE Table __________________________________________________________________ Name Datatype New for V2.2? Name Datatype New for V2.2? Name Datatype New for V2.2? RDB$VINTAGE_TSER INTEGER No RDB$VINTAGE_TIMESTAMP DATE No RDBVMS$VINTAGE_TRANSFER_ CHAR(20) Yes NODE RDBVMS$VINTAGE_TRANSFER_ VARCHAR(402) Yes ADDR RDBVMS$VINTAGE_TRANSFER_ CHAR(31) Yes NAME RDBVMS$VINTAGE_TRANSFER_ SMALLINT Yes ID RDBVMS$VINTAGE_TRANSFER_ CHAR(1) Yes __________________________________________________________________ BUSY The RDBVMS$TRANSFER_OWNER table keeps track of which transfers own which objects in the target database. Table 2-2 lists the columns found in the RDBVMS$TRANSFER_OWNER table, shows the datatype, and indicates whether the column is new for Data Distributor Version 2.2. 2-2 New and Changed Features 2-2 New and Changed Features 2-2 New and Changed Features __________________________________________________________________ Table 2-2: Columns for the RDBVMS$TRANSFER_OWNER Table Table 2-2: Columns for the RDBVMS$TRANSFER_OWNER Table Table 2-2: Columns for the RDBVMS$TRANSFER_OWNER Table __________________________________________________________________ Name Datatype New for V2.2? Name Datatype New for V2.2? Name Datatype New for V2.2? RDBVMS$TRANSFER_OWNER_ID SMALLINT Yes RDBVMS$TRANSFER_OBJECT_ SMALLINT Yes TYPE RDBVMS$TRANSFER_OBJECT_ CHAR(31) Yes __________________________________________________________________ NAME 2.2.2 Transfer Database Table Definitions 2.2.2 Transfer Database Table Definitions 2.2.2 Transfer Database Table Definitions Data Distributor's transfer database includes columns added to ex- isting tables. Table 2-3 and Table 2-4 show only the new columns, not the entire table definitions. __________________________________________________________________ Table 2-3: New Columns for the DDAL$TRANSFERS Table Table 2-3: New Columns for the DDAL$TRANSFERS Table Table 2-3: New Columns for the DDAL$TRANSFERS Table __________________________________________________________________ Name Datatype New for V2.2? Name Datatype New for V2.2? Name Datatype New for V2.2? DDAL$TRANSFER_TO_ CHAR(1) Yes __________________________________________________________________ EXISTING __________________________________________________________________ Table 2-4: New Columns for the DDAL$TRANSFER_VIEWS Table Table 2-4: New Columns for the DDAL$TRANSFER_VIEWS Table Table 2-4: New Columns for the DDAL$TRANSFER_VIEWS Table __________________________________________________________________ Name Datatype New for V2.2? Name Datatype New for V2.2? Name Datatype New for V2.2? __________________________________________________________________ DDAL$TARGET_VIEW_NAME CHAR(31) Yes 2.3 Target Domain Description Changes 2.3 Target Domain Description Changes 2.3 Target Domain Description Changes The description for three domains has changed for Data Distributor Version 2.2. Table 2-5 lists the three domains, the table each is found in, and the new description. New and Changed Features 2-3 New and Changed Features 2-3 New and Changed Features 2-3 _____________________________________________________________________ Table 2-5: New Domain Descriptions Table 2-5: New Domain Descriptions Table 2-5: New Domain Descriptions _____________________________________________________________________ Domain Table Description Domain Table Description Domain Table Description RDB$VINTAGE_ RDB$VINTAGE Vintage timestamp TIMESTAMP RDB$VINTAGE_ RDB$VINTAGE Vintage transaction serialization TSER number DDAL$DBKEY user[1] Database key of a source database row _____________________________________________________________________ [1]The copy process adds the DDAL$DBKEY column to each user table created in the target database for a replication transfer. Database key values contained in this column provide Data Distributor with information about the corresponding row in the source database. _____________________________________________________________________ 2.4 New and Changed Target Index Definitions 2.4 New and Changed Target Index Definitions 2.4 New and Changed Target Index Definitions Multiple rows can now appear in the RDB$VINTAGE table in the target database. This occurs when several transfers target the same existing database. The column RDBVMS$VINTAGE_TRANSFER_ID in the RDB$VINTAGE table contains a unique numeric value that identifies each trans- fer. To ensure that each transfer has a unique value, there is a sorted index on the RDB$VINTAGE table, based on the column RDBVMS$VINTAGE_TRANSFER_ID, that does not allow duplicates. The name of this index is RDBVMS$VINTAGE_INDEX1. For replication transfers, Data Distributor also creates an in- dex in the target database for each table copied from a source database. Each copied table contains an additional column, DDAL$DBKEY, which stores the database key of the row as it ex- ists in the source database. The name of the index depends on whether the transfer is to a new or existing database. 2-4 New and Changed Features 2-4 New and Changed Features 2-4 New and Changed Features o If the copied table is created by a transfer to a new database (Data Distributor creates the target database), the index name takes the form DDAL$DBKEY_INDEXn, for example, DDAL$DBKEY_ INDEX1, DDAL$DBKEY_INDEX2,... o If the copied table is created by a transfer to an existing database, the index name also includes the unique transfer ID. For example, an index for a replication transfer into an existing database where the transfer has an ID value of 3 may be named DDAL$DBKEY_INDEX1_3. 2.5 Rdb/VMS Version 4.0 Changes Affecting Data Distributor 2.5 Rdb/VMS Version 4.0 Changes Affecting Data Distributor 2.5 Rdb/VMS Version 4.0 Changes Affecting Data Distributor Apart from specific support for Data Distributor Version 2.2 features, there are a few changes and additions in Rdb/VMS Version 4.0 that affect Data Distributor. 2.5.1 Default Database and Table Protection 2.5.1 Default Database and Table Protection 2.5.1 Default Database and Table Protection Rdb/VMS Version 4.0 has changed the default database and table protection when new databases are created. One change also affects the protection given to databases and tables created by Data Distributor transfers. Data Distributor does not copy source database protection at- tributes to the target databases. Instead, it lets Rdb/VMS apply whatever are its defaults. In Rdb/VMS systems prior to Version 4.0, public accounts ([*,*]) were by default given virtually unlimited access to the database. If the target database is on a system running such a version of Rdb/VMS, that behavior will continue to be in effect. If the target database is on a sys- tem running Rdb/VMS 4.0, the public by default gets no access privileges to the database or to tables within the database. New and Changed Features 2-5 New and Changed Features 2-5 New and Changed Features 2-5 NOTE NOTE NOTE If you are a Data Distributor customer who has used Version 2.1 or earlier, beware of the effect of this protection change. If your target database users or applications rely on the default access protection of Rdb/VMS, you will have to take steps to deal with the change. You can use epilogue files to change database protection after a transfer has taken place. 2.5.2 New SIGNED BYTE Datatype 2.5.2 New SIGNED BYTE Datatype 2.5.2 New SIGNED BYTE Datatype Rdb/VMS Version 4.0 has added a new datatype called, SIGNED BYTE. In VAX SQL, it is called a TINYINT. Data Distributor supports this new datatype. Data Distributor supports the transfer of columns having this datatype to systems that support it. When creating transfers be- tween two systems running different versions of Rdb/VMS, be aware that one system might not support the SIGNED BYTE datatype. If you attempt such a transfer, the transfer definition is accepted but the transfer fails upon execution. You can determine the reason for the failure by examining the error message in the copy process log file associated with the transfer. 2.6 Replication Transfers Performance Option 2.6 Replication Transfers Performance Option 2.6 Replication Transfers Performance Option Data Distributor Version 2.2 includes an option for adding indexes to Data Distributor's RDB$CHANGES table in a replicated source database. Certain classes of applications can realize overall performance benefits from this option. Enabling and disabling of this option will be done by logical name definition. This section presents a brief overview of the indexing option. For a full description, refer to Chapter 6, section 6.14, of the ___ VAX . ____ ___________ ________ Data Distributor Handbook 2-6 New and Changed Features 2-6 New and Changed Features 2-6 New and Changed Features You have the option of automatically adding two sorted indexes for the RDB$CHANGES table in a replicated source database. See Table 2-6. __________________________________________________________________ Table 2-6: Indexes for the RDB$CHANGES Table Table 2-6: Indexes for the RDB$CHANGES Table Table 2-6: Indexes for the RDB$CHANGES Table __________________________________________________________________ Index based on column Index based on column Index based on column RDBVMS$CHANGES_INDEX1 RDB$TRANSACTION_TSER RDB$TRANSACTION_TID RDB$TRANSACTION_SEQUENCE RDBVMS$CHANGES_INDEX2 RDB$TRANSACTION_TID __________________________________________________________________ RDB$TRANSACTION_SEQUENCE You can enable or disable indexing by defining one of the follow- ing logical names. DDAL$CHANGES_INDEX_transfer_name DDAL$CHANGES_INDEX_transfer_name DDAL$CHANGES_INDEX_transfer_name DDAL$CHANGES_INDEX DDAL$CHANGES_INDEX DDAL$CHANGES_INDEX Table 2-7 shows the equivalence names that you can use for these logical names. New and Changed Features 2-7 New and Changed Features 2-7 New and Changed Features 2-7 __________________________________________________________________ Table 2-7: Equivalence Names for Index Logicals Table 2-7: Equivalence Names for Index Logicals Table 2-7: Equivalence Names for Index Logicals __________________________________________________________________ String Meaning String Meaning String Meaning CREATE_ON_UPDATE Create indexes during the replication update cycle, if necessary. DROP Drop indexes during replication initializa- tion, reinitialization, update or deletion. NONE No indexing desired. Queries will assume indexes don't exist. USE Create indexes during replication initial- ization or reinitialization, if necessary. During replication update, assume RDB$CHANGES __________________________________________________________________ is indexed. 2.7 Limiting Concurrent Transfers on a CPU 2.7 Limiting Concurrent Transfers on a CPU 2.7 Limiting Concurrent Transfers on a CPU Data Distributor has a built-in limit to the number of concurrent transfers it will attempt to execute. That number is 20. This limit is enforced by Data Distributor's transfer monitor since it is responsible for starting up the copy processes. This limit does not guarantee that 20 transfers will run concurrently. System resources may lower the limit to less than 20. A system manager can now limit the number of concurrent transfers that can be executed on a given CPU by defining a system-wide logical name, DDAL$MAX_COPY_PROCESS. For a full description of this feature, refer to Chapter 6, sec- tion 6.15, of the . ___ ____ ___________ ________ VAX Data Distributor Handbook 2-8 New and Changed Features 2-8 New and Changed Features 2-8 New and Changed Features 2.8 DEC RdbAccess for VMS, ORACLE Server Software Support 2.8 DEC RdbAccess for VMS, ORACLE Server Software Support 2.8 DEC RdbAccess for VMS, ORACLE Server Software Support Data Distributor Version 2.2 now supports ORACLE databases as source databases for extraction and extraction rollup transfers. Data Distributor uses RdbAccess for ORACLE as its interface to ORACLE. New and Changed Features 2-9 New and Changed Features 2-9 New and Changed Features 2-9 Chapter 3 Chapter 3 Chapter 3 Problems Corrected Problems Corrected Problems Corrected The following notes describe problems in Data Distributor that have been corrected in the current release. 3.1 Inconsistent Replicated Data When Triggers Are Involved 3.1 Inconsistent Replicated Data When Triggers Are Involved 3.1 Inconsistent Replicated Data When Triggers Are Involved A problem exists in earlier versions of Data Distributor involving the replication of tables on which triggers are defined. It is possible to create triggers that cause a row to be modified more than once. For example, the insertion of a row could activate a trigger that then alters a column within that same row. Data Distributor did not correctly handle this type of self- modifying behavior. The result was that the row transferred to the target database would be missing some of the changes that had occurred. This problem is corrected in the current version of Data Distributor. 3.2 Retrying Lock Conflict and Deadlock Errors 3.2 Retrying Lock Conflict and Deadlock Errors 3.2 Retrying Lock Conflict and Deadlock Errors In prior versions of Data Distributor, a transfer would be sus- pended with a severe error if a copy process received either of the following two status codes: RDB$_LOCK_CONFLICT Problems Corrected 3-1 Problems Corrected 3-1 Problems Corrected 3-1 RDB$_DEADLOCK Retrying the transfer required manual intervention even if you had an appropriately-defined schedule for the transfer. This problem occurred in all transfer types: extraction, extraction rollup, or replication. Transfers that receive the RDB$_LOCK_CONFLICT or RDB$_DEADLOCK status codes are now automatically retried if retry is defined in the transfer schedule. 3.3 Serial Execution of Reinitialized Replication Transfers 3.3 Serial Execution of Reinitialized Replication Transfers 3.3 Serial Execution of Reinitialized Replication Transfers The initial execution of a replication transfer copies source database tables to a target database. Subsequent executions of this replication transfer copy only the source table updates to the target tables. In certain circumstances you might want to reinitialize a replication transfer to recreate the source tables in the target in their entirety instead of only copying the updates. Data Distributor now permits parallel execution of multiple reini- tialized transfers that use the same source database. In prior versions of Data Distributor, such transfers executed one af- ter the other because they performed the same logic as initial replication transfers. Initial replication transfers (replication transfers that are ex- ecuted for the first time) must store a portion of the transfer definition in special system tables in a source database. This must be done with exclusive access to the database. Therefore sev- eral initial replication transfers using the same source database will continue, as in the past, to execute serially. With the release of Data Distributor Version 2.2, when a transfer is reinitialized and rerun, Data Distributor checks to see if the transfer is already stored in the source database and if that definition is unchanged. If so, then exclusive access to that database is not needed. 3-2 Problems Corrected 3-2 Problems Corrected 3-2 Problems Corrected When several reinitialized transfers using the same database are run concurrently, it is possible for them to receive lock conflict errors unless the database has already been manually opened from all nodes that access it. Opening a database manually is done using the RMU/OPEN command of Rdb/VMS. 3.4 Bad SQL Transfer Definition from VIDA for DB2 3.4 Bad SQL Transfer Definition from VIDA for DB2 3.4 Bad SQL Transfer Definition from VIDA for DB2 In Data Distributor Version 2.1, you could not use VAX SQL to successfully create and execute extraction transfers from a VIDA for DB2 database. Data Distributor to accept the transfer ________ appeared definition. However, examination of the transfer definition using the SQL SHOW TRANSFER DEFINITION FOR transfer-name statement would have revealed a blank on the "From" line where "/TYPE=VIDA2... (VIDA access control string)" should have appeared. Execution of this transfer would fail. A copy process log file showing the error may have look like the following (note that the name of the source database is missing): 15:07:35 %DDAL-I-ATTACHSDB, attaching to source database ----- 11-JUL-1990 15:07:35.99 ----- Error ----------- %RDB-E-BAD_DB_FORMAT, -RMS-F-SYN, file specification syntax error You could successfully define and execute this type of transfer using the RDO interface. This problem has been corrected in VAX SQL Version 4.0, which coincides with Data Distributor Version 2.2. Problems Corrected 3-3 Problems Corrected 3-3 Problems Corrected 3-3 3.5 Incorrect EPILOGUE Status Codes 3.5 Incorrect EPILOGUE Status Codes 3.5 Incorrect EPILOGUE Status Codes In Version 2.1 of the , prologue ____ ___________ ________ Data Distributor Handbook and epilogue failure codes are listed with the wrong val- ues in Appendix B, Table B-3, on page B-5. These codes also are incorrectly defined in the Data Distributor procedure SYS$MANAGER:DDAL$EPILOGUE.COM. Consequently, prologue and epilogue failures were not correctly reported in the transfer status. This has been corrected for Data Distributor Version 2.2, in both the and the command procedure. The correct values are ________ Handbook also shown in Table 3-1. _____________________________________________________________________ Table 3-1: Corrected Status Codes Table 3-1: Corrected Status Codes Table 3-1: Corrected Status Codes Incorrect Correct Incorrect Correct Incorrect Correct _____________________________________________________________________ Code Code Explanation Code Code Explanation Code Code Explanation 0126C423 0126C44B Prologue failed, copy aborted, but retrying 0126C42B 0126C453 Prologue failed, copy aborted, and not retry- ing 0126C433 0126C45B Epilogue failed but retrying _____________________________________________________________________ 0126C43B 0126C463 Epilogue failed and not retrying 3-4 Problems Corrected 3-4 Problems Corrected 3-4 Problems Corrected Chapter 4 Chapter 4 Chapter 4 Known Problems and Restrictions Known Problems and Restrictions Known Problems and Restrictions This chapter documents restrictions currently in effect for Data Distributor and one VMS restriction that affects both interactive SQL and the RDO utility of Rdb/VMS. 4.1 Using LIB$DT_INPUT_FORMAT to Change Date Input Format 4.1 Using LIB$DT_INPUT_FORMAT to Change Date Input Format 4.1 Using LIB$DT_INPUT_FORMAT to Change Date Input Format In the discussion of the CREATE SCHEDULE statement in Chapter 9 of the , the Usage Notes describe how to ___ ____ ___________ ________ VAX Data Distributor Handbook change the default date and time format (established before VMS Version 5.0) to a date and time format that complies with the LIB$ international date and time formatting routines of VMS Version 5.0 and higher. (Refer to the Usage Notes for the DEFINE TRANSFER statement in Chapter 10 for information about changing the date and time format in RDO.) A problem exists with the LIB$CONVERT_DATE_STRING function of the VMS Version 5.3 Run-Time Library. Rdb/VMS uses the function in precompiled programs, SQL module language, and the RDO and SQL interactive interfaces to convert dates to internal format. When the logical name LIB$DT_INPUT_FORMAT is used to change the date input format, the run-time library sometimes causes an access vi- olation that probably prevents the precompiler or module language compiler from continuing, but does not cause any loss of data from Known Problems and Restrictions 4-1 Known Problems and Restrictions 4-1 Known Problems and Restrictions 4-1 interactive SQL. The access violation is shown in the following example: %SQL-F-DATCONERR, Data conversion error -SYSTEM-F-ACCVIO, access violation, ... 4.2 Restrictions for Extraction, Extraction Rollup, and Replication 4.2 Restrictions for Extraction, Extraction Rollup, and Replication 4.2 Restrictions for Extraction, Extraction Rollup, and Replication Transfers Transfers Transfers This section documents the restrictions that apply equally well to extraction, extraction rollup, and replication transfers. 4.2.1 Data Distributor Version 2.2 CREATE TRANSFER Statement Syntax 4.2.1 Data Distributor Version 2.2 CREATE TRANSFER Statement Syntax 4.2.1 Data Distributor Version 2.2 CREATE TRANSFER Statement Syntax Change and Existing Command Procedures Change and Existing Command Procedures Change and Existing Command Procedures The TO clause in the CREATE TRANSFER statement now requires that you specify whether the transfer is to a new or existing target database. CREATE TRANSFER syntax prior to Version 2.2 required the keyword TO with the target-file-spec parameter. Version 2.2 now requires the keywords TO NEW FILENAME with the target-file- spec parameter. Therefore, you must edit any existing command procedures that specify the keyword TO by adding the additional keywords NEW FILENAME. This restriction applies only to the SQL CREATE TRANSFER state- ment, to the RDO DEFINE TRANSFER statement. The syntax for not not not the DEFINE TRANSFER statement has not changed for Data Distributor Version 2.2. 4.2.2 Transfer Schedule Defined for Time Before Transfer Execution 4.2.2 Transfer Schedule Defined for Time Before Transfer Execution 4.2.2 Transfer Schedule Defined for Time Before Transfer Execution 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 4-2 Known Problems and Restrictions 4-2 Known Problems and Restrictions 4-2 Known Problems and Restrictions this problem and cause the transfer to execute, use the START TRANSFER NOW statement. 4.2.3 Transfer Completion Status After a Transfer Is Stopped 4.2.3 Transfer Completion Status After a Transfer Is Stopped 4.2.3 Transfer Completion Status After a Transfer Is Stopped When you issue a STOP TRANSFER statement for a transfer in the active state, the state changes to suspended. However, the last transfer completion status is not updated and does not reflect the incomplete transfer. 4.2.4 Data Definition Changes After a Transfer Is Defined 4.2.4 Data Definition Changes After a Transfer Is Defined 4.2.4 Data Definition Changes After a Transfer Is Defined In an extraction transfer, you can change table definitions in the source database or definitions of fields 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 ini- tial transfer begins. Thereafter, any attempts to change or delete definitions for tables or columns in the replication transfer are not allowed. In both extraction and replication transfers, if you make changes that cause the source tables or columns to be incompatible with the transfer definitions, Data Distributor detects these dif- ferences 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 pro- cess does not detect changes to the data type of a field. For example, you can change a field from the data type TEXT to the data type LONGWORD without causing a failure. Known Problems and Restrictions 4-3 Known Problems and Restrictions 4-3 Known Problems and Restrictions 4-3 4.2.5 Information Retrieval from a Transfer Database 4.2.5 Information Retrieval from a Transfer Database 4.2.5 Information Retrieval from a Transfer Database Within Data Distributor, the transfer monitor creates a transfer database. Only one of the tables in this database has an associ- ated index. When many transfers are defined and when many tables with many columns are included in the transfer definitions, a significant portion of the time it takes for a transfer to exe- cute can be attributed to the time it takes to look up a transfer definition. In the current version of Data Distributor, you can determine the length of time spent during transfer execution to read the transfer definition from the transfer database. Data Distributor records a message in the copy process log file for each transfer that notes the time the copy process begins reading the transfer definition. The next message records the time the copy process attaches to the source database. The difference between the two times is the total time spent reading the transfer definition. If you find that reading the transfer definition takes too long, you can add indexes to the transfer database tables to improve reading speed. This enhancement may be done automatically in a future release of Data Distributor. The decision to index a table depends on whether the number of data rows in the table has become or is expected to become large. You should optimize access to the transfer database for data retrieval because data storage occurs less frequently. The Data Distributor tables in a transfer database are shown in Table 4-1. The first two or three of these tables frequently contain the most data rows. Therefore, you may decide to index the first three tables only. Digital recommends that you name any index you add by using the table name and appending the suffix "_INDEX". Simple sorted indexes are sufficient. 4-4 Known Problems and Restrictions 4-4 Known Problems and Restrictions 4-4 Known Problems and Restrictions __________________________________________________________________ Table 4-1: Transfer Database Tables Table 4-1: Transfer Database Tables Table 4-1: Transfer Database Tables Possible Index Possible Index Possible Index __________________________________________________________________ Table Name Based on Column Duplicates Allowed? Table Name Based on Column Duplicates Allowed? Table Name Based on Column Duplicates Allowed? DDAL$TRANSFER_FIELDS DDAL$TRANSFER_NAME Yes DDAL$RELATION_NAME Yes DDAL$TRANSFER_RELATIONS DDAL$TRANSFER_NAME No DDAL$TRANSFER_VIEWS DDAL$TRANSFER_NAME No DDAL$INVOKE_TIME DDAL$TRANSFER_NAME No DDAL$ROLLUP_DATABASES DDAL$TRANSFER_NAME No DDAL$TRANSFERS_STATUS DDAL$TRANSFER_NAME No __________________________________________________________________ DDAL$TRANSFER_SCHEDULE DDAL$TRANSFER_NAME No There are two tables not shown in Table 4-1. DDAL$TRANSFERS is the one table that is automatically indexed by Data Distributor. The second table is DDAL$TRANSFER_DATABASE, which contains a single row and needs no index. 4.3 Restriction for Extraction and Extraction Rollup Transfers Only 4.3 Restriction for Extraction and Extraction Rollup Transfers Only 4.3 Restriction for Extraction and Extraction Rollup Transfers Only This section describes a restriction that applies to extraction and extraction rollup transfers only. Known Problems and Restrictions 4-5 Known Problems and Restrictions 4-5 Known Problems and Restrictions 4-5 4.3.1 SQL Does Not Translate Logical Names Referencing Source 4.3.1 SQL Does Not Translate Logical Names Referencing Source 4.3.1 SQL Does Not Translate Logical Names Referencing Source Databases Databases Databases When you create an extraction or extraction rollup transfer and you want to use a source database that requires the /TYPE access string, you must first enter a DECLARE SCHEMA statement for that database. One method of referencing the source database is to define a logical name, as shown in the following example: $ DEFINE SOURCE_DB "/TYPE=VIDA2/DATABASE=SHIPPING..." $ SQL SQL> DECLARE SCHEMA FILENAME SOURCE_DB; SQL> CREATE TRANSFER FROM_SHIPPING TYPE IS EXTRACTION ... However, SQL does not translate the logical name into the access string when the source schema is declared by referring to a logi- cal name. Using the previous example, examination of the transfer definition will show "From ... SOURCE_DB", instead of "From ... /TYPE=VIDA2/DATABASE=SHIPPING...". The transfer will fail to execute properly unless the SOURCE_DB logical name is defined when the copy process runs. A copy process runs as a detached process using the same VMS account that you use to create the transfer. Therefore, the SOURCE_DB logical name will be properly translated if you define it in your LOGIN.COM file. The logical name can also be defined in your group or system logical name tables. The logical name "SOURCE_DB" is used here as an example; you can use any name you want. 4.4 Restriction for Extraction Transfers Only 4.4 Restriction for Extraction Transfers Only 4.4 Restriction for Extraction Transfers Only This section describes a restriction that applies to extraction transfers only. 4-6 Known Problems and Restrictions 4-6 Known Problems and Restrictions 4-6 Known Problems and Restrictions 4.4.1 Views Containing Computed_By Columns Cannot Become Tables 4.4.1 Views Containing Computed_By Columns Cannot Become Tables 4.4.1 Views Containing Computed_By Columns Cannot Become Tables In extraction transfers, you can specify a view name in the MOVE TABLES clause of the CREATE TRANSFER statement. The view in the source database becomes a real table, with data of its own, in the target database. However, if a view contains computed_by columns, Data Distributor cannot materialize the view as a table. Execution of the trans- fer can fail with the message "%RDMS-I-BUGCHKDMP, generating bugcheck dump file" and the bugcheck dump showing an exception at RDMS$$DSDI_BAD_CODE. 4.5 Restrictions for Extraction Rollup Transfers Only 4.5 Restrictions for Extraction Rollup Transfers Only 4.5 Restrictions for Extraction Rollup Transfers Only This section describes restrictions that applies to extraction rollup transfers only. 4.5.1 Column Names for Like Tables Must Be Identical 4.5.1 Column Names for Like Tables Must Be Identical 4.5.1 Column Names for Like Tables Must Be Identical A restriction that applies to extraction rollup transfers (created using the interactive SQL) states that column names of like tables must be identical. SQL lets you create an extraction rollup transfer of like tables that differ only in the column names. For example, the following fragment shows a transfer definition of this type: MOVE TABLES SELECT PLAYER_ID FROM DB1.PLAYERS UNION ALL SELECT PLAYER_CODE FROM DB2.PLAYERS INTO ALL_PLAYERS The PLAYERS table in the two source schemas are identical: o They have the same number of columns. o The columns are defined in the same order. Known Problems and Restrictions 4-7 Known Problems and Restrictions 4-7 Known Problems and Restrictions 4-7 o The data definitions for each column (data type, length, scale) are the same. They differ only in the two column names they each use, namely PLAYER_ID and PLAYER_CODE. If you create such a transfer, the definition is accepted by SQL and stored in the transfer database. When a Data Distributor copy process executes the transfer, the transfer fails. The copy process log then logs the following error messages: o DDAL-E-RDBERR, RDB-E-OBSOLETE_METADATA o RDMS-F-BAD_SYM The messages indicate that the PLAYER_CODE column name caused the error. Extraction rollup transfers must use like column names for trans- fers to succeed. 4.5.2 SQL Privileges Can Restrict Access to Source Tables 4.5.2 SQL Privileges Can Restrict Access to Source Tables 4.5.2 SQL Privileges Can Restrict Access to Source Tables Users with only the SQL SELECT privilege for source databases cannot execute extraction rollup transfers. The following example illustrates this restriction. You want to define an extraction rollup transfer on two source databases, DB1 and DB2. Assume that you have the SELECT privilege on database DB2 and assume that you have the SELECT privilege for all the tables in DB2. If you enter the following transfer definition, you will receive the error message shown at the end of the example. 4-8 Known Problems and Restrictions 4-8 Known Problems and Restrictions 4-8 Known Problems and Restrictions SQL> DECLARE DB1 SCHEMA FILENAME PERS1; SQL> DECLARE DB2 SCHEMA FILENAME PERS2; SQL> CREATE TRANSFER ERP_1 TYPE IS EXTRACTION ROLLUP cont> MOVE TABLES cont> SELECT FIRST.* cont> FROM DB1.EMPLOYEES FIRST WHERE FIRST.STATE = "NH" cont> UNION ALL cont> SELECT SECOND.* cont> FROM DB2.EMPLOYEES SECOND WHERE SECOND.STATE = "MA" cont> INTO NEW_MA_NH_EMPS cont> TO NEW FILENAME DISK1:[DIR1]PERS3 cont> LOG FILE IS DISK1:[DIR1]PERS3.LOG cont> COMMENT IS "Pull test all local" cont> ; %RDB-E-NO_PRIV, privilege denied by database facility This is an SQL enforced restriction that is present in Rdb/VMS V4.0. Use the RDO interface to work around this problem. 4.6 Restrictions for Replication Transfers Only 4.6 Restrictions for Replication Transfers Only 4.6 Restrictions for Replication Transfers Only This section contains restrictions for replication transfers only. 4.6.1 Restriction on Fields Named in an Rdb/VMS RDO RSE 4.6.1 Restriction on Fields Named in an Rdb/VMS RDO RSE 4.6.1 Restriction on Fields Named in an Rdb/VMS RDO RSE 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, Data Distributor returns an error message when the transfer executes. The message indicates that the field name is not found in the symbol table. Known Problems and Restrictions 4-9 Known Problems and Restrictions 4-9 Known Problems and Restrictions 4-9 4.6.2 Restriction on Columns Named in an SQL Select Expression 4.6.2 Restriction on Columns Named in an SQL Select Expression 4.6.2 Restriction on Columns Named in an SQL Select Expression All columns that you name in a select expression of the CREATE TRANSFER statement must also be included in the SELECT column-name clause. If you do not name the columns explicitly in the SELECT column-name statement or implicitly in the SELECT ALL clause, Data Distributor returns an error message when the transfer executes. The message indicates that the column name is not found in the symbol table. 4.6.3 Deleting Transfer Definitions 4.6.3 Deleting Transfer Definitions 4.6.3 Deleting Transfer Definitions When a replication transfer definition is created, Data Distributor stores that definition in the transfer database. When the transfer runs for the first time, Data Distributor stores that definition in the source database as well. In Data Distributor Version 1.0, a problem arose when you attempted to delete a replication transfer while the RDO utility was attached to the source database. To delete a replication transfer definition, you first had to start a transaction. Before you could start a transaction, you had to attach to a database. However, if you attached to the source database that contained the transfer definition, the copy process, which needed exclusive access to the source database containing the definition, could not delete the transfer definition. To avoid this problem, before you deleted a replication transfer, you had to attach to a database other than the source database for the replication transfer definition you intended to delete. For Data Distributor Version 1.1, Version 2.0, and Version 2.1, because the copy process still needs to have exclusive access to the source database, you must detach from the source database before you issue the DROP TRANSFER statement for a replication transfer. But, for Data Distributor Version 1.1, Version 2.0, and Version 2.1, you need not attach to another database to delete a replication transfer. 4-10 Known Problems and Restrictions 4-10 Known Problems and Restrictions 4-10 Known Problems and Restrictions If the source database is inaccessible or no longer exists and you need to delete the transfer, you can work around the problem as follows: 1. Create a new database with the same name and fields or rela- tions as the inaccessible source database. 2. Locate this new database at the address where the old one was. 3. Reinitialize and then start the transfer. These steps will enter the transfer definition in the source database. After the definition has been entered into the RDB$TRANSFER_ RELATIONS relation in the source database, stop the transfer. Then issue a DROP TRANSFER statement in SQL or a DELETE TRANSFER statement in RDO to remove the unwanted transfer definition. 4.6.4 Restriction on Two-Way Replication Transfers 4.6.4 Restriction on Two-Way Replication Transfers 4.6.4 Restriction on Two-Way Replication Transfers Two-way transfers enable two databases to exchange data. A trans- fer definition created on each database uses the other database as a target. If the transfers defined on each database are the repli- cation type, in certain circumstances the copy process will issue an error message and fail to execute the second transfer. Consider the following example. You have two databases, PERS1 and PERS2, neither of which has been created or accessed by a transfer. You define a replication transfer, XFER1, from PERS1 into PERS2 and execute it. Database PERS2 now contains the table RDB$VINTAGE. Known Problems and Restrictions 4-11 Known Problems and Restrictions 4-11 Known Problems and Restrictions 4-11 SQL> DECLARE SCHEMA FILE PERS1; SQL> CREATE TRANSFER XFER1 TYPE IS REPLICATION cont> MOVE TABLES * cont> TO EXISTING FILENAME DISK2:[DIR2]PERS2 WITH NO CHECKING cont> LOG FILE IS DISK1:[DIR1]XFER1.LOG cont> ; SQL> START TRANSFER XFER1 NOW; SQL> FINISH; Next, you define a second transfer, XFER2, from PERS2 into PERS1. SQL> DECLARE SCHEMA FILENAME PERS2; SQL> CREATE TRANSFER XFER2 TYPE IS REPLICATION cont> MOVE TABLES * cont> TO EXISTING FILENAME DISK1:[DIR1]PERS1 WITH NO CHECKING cont> LOG FILE IS DISK2:[DIR2]XFER2.LOG cont> ; SQL> FINISH; This causes the copy process to attempt to create the RDB$VINTAGE table twice, which generates the following error message: ----- 17-SEP-1990 15:13:42.47 ----- Error ------------------------- %DDAL-E-MISGBLFLD, local field RDB$VINTAGE_TSER not matched to a global field You can avoid this problem using one of the following methods: o Specify all the tables you want moved and avoid using the wildcard character (*) in the MOVE TABLES clause. This is documented in Chapters 9 and 10 of the ___ ____ ___________ VAX Data Distributor . ________ Handbook o If you know that you want to define a two-way replication transfer, define both transfers at the same time. The names of the tables to be moved in each transfer are stored immediately, and because the RDB$VINTAGE table has not yet been created, it is not stored as part of either transfer definition. 4-12 Known Problems and Restrictions 4-12 Known Problems and Restrictions 4-12 Known Problems and Restrictions 4.7 Restrictions for Transferring Into an Existing Database 4.7 Restrictions for Transferring Into an Existing Database 4.7 Restrictions for Transferring Into an Existing Database This section documents the restrictions that apply to transfers that use an existing database as a target. 4.7.1 Transferring a Table to an Existing Database Containing the 4.7.1 Transferring a Table to an Existing Database Containing the 4.7.1 Transferring a Table to an Existing Database Containing the Same Table Name Same Table Name Same Table Name If you define a transfer to an existing database and specify a table name in the transfer definition that already exists in the target database, SQL checks to determine if the table was created by the current transfer. o If the transfer owns the table, then the transfer definition is valid. o If the transfer does not own the table, SQL issues an error message and the transfer fails. You must use the INTO keyword with the table-name parameter to rename the duplicated table. However, in SQL Version 4.0, SQL looks for the source table name in the target database instead of the table name specified in the INTO table-name clause. Because the source table name does exist but does not belong to the current transfer, SQL issues an error message declaring that the transfer does not own the table. The following example illustrates this situation. Assume that EMP_ COLLEGES in the target database PERS_1 is not owned by transfer XYZ. Known Problems and Restrictions 4-13 Known Problems and Restrictions 4-13 Known Problems and Restrictions 4-13 SQL> DECLARE SCHEMA FOR FILENAME "PERSONNEL"; SQL> CREATE TRANSFER XYZ TYPE IS REPLICATION cont> MOVE TABLES cont> SELECT * FROM COLLEGES INTO EMP_COLLEGES cont> TO EXISTING FILENAME DISK1:[DIR1]PERS_1 cont> LOG FILE IS DISK1:[DIR1]XYZ.LOG cont> ; %SQL-F-TRANOTOWNER, This transfer is not the owner of table EMP_COLLEGES You can resolve this problem by using the WITH NO CHECKING quali- fier with the CREATE TRANSFER statement, as shown in the following example: SQL> DECLARE SCHEMA FOR FILENAME "PERSONNEL"; SQL> CREATE TRANSFER XYZ TYPE IS REPLICATION cont> MOVE TABLES cont> SELECT * FROM COLLEGES INTO EMP_COLLEGES cont> TO EXISTING FILENAME DISK1:[DIR1]PERS_1 WITH NO CHECKING cont> LOG FILE IS DISK1:[DIR1]XYZ.LOG cont> ; 4.7.2 No Extraction Rollup Into Existing Databases 4.7.2 No Extraction Rollup Into Existing Databases 4.7.2 No Extraction Rollup Into Existing Databases You cannot create an extraction rollup transfer into an existing database. If you need to merge disparate tables into one physical database, you can do so by defining several transfers into an existing database. If you also require the union of data from several like tables, which currently exist in separate databases, you can do the same and then use a view to accomplish the union. 4-14 Known Problems and Restrictions 4-14 Known Problems and Restrictions 4-14 Known Problems and Restrictions 4.7.3 No Union of Source and Target Data 4.7.3 No Union of Source and Target Data 4.7.3 No Union of Source and Target Data If the source and target databases have tables of identical defi- nition, it might seem natural to transfer data from the source table into the target table. This is not permitted in Data Distributor. Instead you must transfer the source table into the target database under a new name, thereby keeping the two sets of data separated. 4.7.4 No DEFINE TRANSFER Into an Existing Database 4.7.4 No DEFINE TRANSFER Into an Existing Database 4.7.4 No DEFINE TRANSFER Into an Existing Database DEFINE TRANSFER is the RDO equivalent of SQL's CREATE TRANSFER statement. The DEFINE TRANSFER statement has not been changed to support transfers to existing databases. 4.8 Cluster Restrictions 4.8 Cluster Restrictions 4.8 Cluster Restrictions This section documents the restrictions that apply to cluster installations of Data Distributor. 4.8.1 Load Balancing in a Cluster 4.8.1 Load Balancing in a Cluster 4.8.1 Load Balancing in a Cluster When there are multiple transfers defined in a cluster transfer database, each node's transfer monitor is supposed to participate in the scheduling activity for transfers. However, sometimes one node does all the work. For example, assume that three transfers have been defined, but none has a schedule definition. Transfer monitors are running on Nodes A, B, and C, and each is hibernating. If, on Node A, you define schedules for the three transfers, only the transfer monitor on Node A becomes aware of the new schedules. Therefore, all transfer operations are done by Node A. Known Problems and Restrictions 4-15 Known Problems and Restrictions 4-15 Known Problems and Restrictions 4-15 If, on Node B, you issue a START TRANSFER statement from SQL or RDO, the transfer monitor on Node B subsequently participates in the scheduling of existing transfers. Similarly, you can issue a START TRANSFER statement from Node C to further balance the work load. 4-16 Known Problems and Restrictions 4-16 Known Problems and Restrictions 4-16 Known Problems and Restrictions