* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Troubleshooting Oracle Publishers
Survey
Document related concepts
Concurrency control wikipedia , lookup
Tandem Computers wikipedia , lookup
Microsoft Access wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Team Foundation Server wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Clusterpoint wikipedia , lookup
Relational model wikipedia , lookup
Database model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Transcript
Table of Contents Heterogeneous Database Replication Non-SQL Server Publishers Oracle Publishing Overview Glossary of Terms for Oracle Publishing Configure an Oracle Publisher Script to Grant Oracle Permissions Manage Oracle Tablespaces Design Considerations and Limitations for Oracle Publishers Administrative Considerations for Oracle Publishers Performance Tuning for Oracle Publishers Data Type Mapping for Oracle Publishers Backup and Restore for Oracle Publishers Objects Created on the Oracle Publisher Troubleshooting Oracle Publishers Non-SQL Server Subscribers Oracle Subscribers IBM DB2 Subscribers Other Non-SQL Server Subscribers Heterogeneous Database Replication 3/24/2017 • 1 min to read • Edit Online SQL Server supports the following heterogeneous scenarios for transactional and snapshot replication: Publishing data from Oracle to SQL Server. Publishing data from SQL Server to non- SQL Server Subscribers. Heterogeneous replication to non-SQL Server subscribers is deprecated. Oracle Publishing is deprecated. To move data, create solutions using change data capture and SSIS. Cau t i on This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Publishing Data from Oracle You can use SQL Server to publish data from Oracle with most of the same features and ease-of-use as SQL Server snapshot and transactional replication. Publishing data from Oracle is ideal for the following scenarios: SCENARIO DESCRIPTION Microsoft .NET Framework application deployments Develop with Microsoft Visual Studio and SQL Server while operating on data replicated from a non- SQL Server database. Data warehousing staging servers Keep SQL Server staging databases synchronized with a nonSQL Server database. Migration to SQL Server Test your application in real time against SQL Server while replicating the source system's changes. Switch to SQL Server when satisfied with the migration. For more information, see Oracle Publishing Overview. Publishing Data to Non-SQL Server Subscribers The following non- SQL Server databases are supported as Subscribers to snapshot and transactional publications: Oracle for all platforms that Oracle supports. IBM DB2 for AS400, MVS, Unix, Linux, and Windows. For more information, see Non-SQL Server Subscribers. Non-SQL Server Publishers 3/24/2017 • 1 min to read • Edit Online Publishing data from non- SQL Server sources allows you to consolidate data in Microsoft SQL Server. SQL Server can subscribe to snapshot or transactional data published from an Oracle database. For more information about publishing from Oracle, see Oracle Publishing Overview. Heterogeneous replication to non-SQL Server subscribers is deprecated. Oracle Publishing is deprecated. To move data, create solutions using change data capture and SSIS. Cau t i on This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Publishing from non- SQL Server databases is ideal for the following scenarios: SCENARIO DESCRIPTION Microsoft .NET Framework application deployments Develop with Microsoft Visual Studio and SQL Server while operating on data replicated from a non- SQL Server database. Data warehousing staging servers Keep SQL Server staging databases synchronized with a nonSQL Server database. Migration to SQL Server Test your application in real time against SQL Server while replicating the source system's changes. Switch to SQL Server when satisfied with the migration. See Also Heterogeneous Database Replication Oracle Publishing Overview 3/24/2017 • 1 min to read • Edit Online Beginning with Microsoft SQL Server 2005, you can include Oracle Publishers in your replication topology, starting with Oracle version 9i. Publishing servers can be deployed on any Oracle supported hardware and operating system. The feature is built on the well-established foundation of SQL Server snapshot replication and transactional replication, providing similar performance and usability. Oracle Publishing is deprecated. Heterogeneous replication to non-SQL Server subscribers is deprecated. To move data, create solutions using change data capture and SSIS. Cau t i on This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Snapshot Replication for Oracle Oracle snapshot publications are implemented in a manner similar to SQL Server snapshot publications. When the Snapshot Agent runs for an Oracle publication, it connects to the Oracle Publisher and processes each table in the publication. When processing each table, the agent retrieves the table rows and creates schema scripts, which are then stored on the publication's snapshot share. The entire set of data is created each time the Snapshot Agent runs, so change tracking triggers are not added to the Oracle tables as they are with transactional replication. Snapshot replication provides a convenient way to migrate data with minimal impact on the publishing system. Transactional Replication for Oracle Oracle transactional publications are implemented using the transactional publishing architecture of SQL Server; however, changes are tracked using a combination of database triggers on the Oracle database and the Log Reader Agent. Subscribers to an Oracle transactional publication are automatically initialized using snapshot replication; subsequent changes are tracked and delivered to Subscribers as they occur via the Log Reader Agent. When an Oracle publication is created, triggers and tracking tables are created for each published table within the Oracle database. When data changes are made to the published tables, the database triggers on the tables fire and insert information into the replication tracking tables for each modified row. The Log Reader Agent on the SQL Server Distributor then moves the data change information from the tracking tables to the distribution database on the Distributor. Finally, as in standard transactional replication, the Distribution Agent moves changes from the Distributor to the Subscribers. See Also Configure an Oracle Publisher Glossary of Terms for Oracle Publishing Heterogeneous Database Replication Glossary of Terms for Oracle Publishing 3/24/2017 • 2 min to read • Edit Online You should be familiar with the following Oracle terms when configuring and administering Oracle publishing. For a complete list of Oracle terms, see the Oracle online documentation. Index Organized Tables (IOT) A table whose data is physically sorted on disk in index order; it is similar to a Microsoft SQL Server table with a clustered index. An IOT is replicated to a Subscriber as a table with a clustered index. Instance An Oracle database is associated with an instance. The instance comprises the memory and background processes supporting the database. An Oracle instance always maps to a single database, whereas an instance of SQL Server can contain many databases. There are circumstances in which an Oracle database can have multiple instances. Oracle Listener Handles incoming network traffic for an Oracle database instance. When you configure network connectivity to an Oracle database, you specify the protocol through which traffic is sent and the port on which the Listener listens for traffic. The Listener is typically configured to run on the same computer as the Oracle database instance and can be configured to serve one or more instances. ROWID A pointer to the location of a specific row in a database. Because retrieving rows using the ROWID is faster than using a table scan or index, replication uses the ROWID temporarily during processing of published table changes. Sequence A database object that is used to generate unique numbers. Replication uses sequences to order changes made to published tables. SQL*Plus An application used to access and query Oracle databases. It is similar to SQL Server sqlcmd. Synonym An alias for an object. The special public synonym MSSQLSERVERDISTRIBUTOR is automatically created when an Oracle Publisher is configured. The synonym references the HREPL_Distributor table and provides a logical pointer to the SQL Server Distributor that services the Publisher. After an Oracle database has been published, subsequent attempts to configure this Publisher to use a different SQL Server Distributor will fail, because this public synonym identifies the particular Distributor already configured to service the Publisher. Tablespace A unit of database storage that is roughly equivalent to a filegroup in SQL Server. TNS Service Name TNS (Transparent Network Substrate) is a communication layer used by Oracle databases. The TNS Service Name is the name by which an Oracle database instance is known on a network. You assign a TNS Service Name when you configure connectivity to the Oracle database. Replication uses the TNS Service name to identify the Publisher and to establish connections. User schema A user schema can be thought of as a database user who owns a particular set of database objects. The replication administrative user schema owns all objects created by the SQL Server replication process in the Oracle database, with the exception of the MSSQLSERVERDISTRIBUTOR public synonym. See Also Configure an Oracle Publisher Objects Created on the Oracle Publisher Non-SQL Server Publishers Oracle Publishing Overview Configure an Oracle Publisher 3/24/2017 • 8 min to read • Edit Online Publications from Oracle Publishers are created in the same way typical snapshot and transactional publications are created, but prior to creating a publication from an Oracle Publisher, you must complete the following steps (steps one, three, and four are described in detail in this topic.): 1. Create a replication administrative user within the Oracle database using the supplied script. 2. For the tables that you will publish, grant SELECT permission directly on each of them (not through a role) to the Oracle administrative user you created in step one. 3. Install the Oracle client software and OLE DB provider on the Microsoft SQL Server Distributor, and then stop and restart the SQL Server instance. If the Distributor is running on a 64 bit platform, you must use the 64 bit version of the Oracle OLE DB provider. 4. Configure the Oracle database as a Publisher at the SQL Server Distributor. For a list of objects that can be replicated from an Oracle database, see Design Considerations and Limitations for Oracle Publishers. NOTE You must be a member of the sysadmin fixed server role to enable a Publisher or Distributor and to create an Oracle publication or a subscription from an Oracle publication. Creating the Replication Administrative User Schema within the Oracle Database Replication agents connect to the Oracle database and perform operations in the context of a user schema that you must create. This schema must be granted a number of permissions, which are listed in the next section. This schema owns all objects created by the Microsoft SQL Server replication process on the Oracle Publisher, with the exception of a public synonym, MSSQLSERVERDISTRIBUTOR. For more information about the objects created in the Oracle database, see Objects Created on the Oracle Publisher. NOTE Dropping the MSSQLSERVERDISTRIBUTOR public synonym and the configured Oracle replication user with the CASCADE option removes all replication objects from the Oracle Publisher. A sample script has been provided to aid in the setup of the Oracle replication user schema. The script is available in the following directory after installation of SQL Server: <drive>:\\Program Files\Microsoft SQL Server\<InstanceName>\MSSQL\Install\oracleadmin.sql. It is also included in the topic Script to Grant Oracle Permissions. Connect to the Oracle database using an account with DBA privileges and execute the script. This script prompts for the user and password for the replication administrative user schema as well as the default tablespace in which to create the objects (the tablespace must already exist in the Oracle database). For information about specifying other tablespaces for objects, see Manage Oracle Tablespaces. Choose any user name and strong password, but make note of both because you will be prompted for this information later when you configure the Oracle database as a Publisher. It is recommended that the schema be used only for objects required by replication; do not create tables to be published in this schema. Creating the User Schema Manually If you create the replication administrative user schema manually, you must grant the schema the following permissions, either directly or through a database role. CREATE PUBLIC SYNONYM and DROP PUBLIC SYNONYM CREATE PROCEDURE CREATE SEQUENCE CREATE SESSION You must also grant the following permissions to the user directly (not through a role): CREATE ANY TRIGGER. This is required only both snapshot and transactional replication. CREATE TABLE CREATE VIEW Installing and Configuring Oracle Client Networking Software on the SQL Server Distributor You must install and configure Oracle client networking software and the Oracle OLE DB provider on the SQL Server Distributor, so that the Distributor can make connections to the Oracle Publisher. After installing the software, set the appropriate permissions on the folders in which the software is installed, and then stop and restart the SQL Server instance to ensure that all settings are updated (permissions are described later, in the section "Setting Directory Permissions"). NOTE The Oracle client networking software must be the most recent version available. Oracle recommends that users install the most recent versions of client software. The client software is therefore often a more recent version than the database software. The most straightforward way to install and configure the client networking software is to use the Oracle Universal Installer and Net Configuration Assistant on the Oracle Client disk. In the Oracle Universal Installer, you will supply the following information: INFORMATION DESCRIPTION Oracle Home This is the path to the install directory for the Oracle software. Accept the default (C:\oracle\ora90 or similar) or enter another path. For more information about the Oracle Home, see the section "Considerations for Oracle Home" later in this topic. Oracle home name An alias for the Oracle home path. Installation type In Oracle 10g, select the Administrator installation option. After the Oracle Universal Installer is complete, use the Net Configuration Assistant to configure network connectivity. You must supply four pieces of information to configure network connectivity. The Oracle database administrator configures the network configuration when setting up the database and listener and should be able to provide this information if you do not have it. You must do the following: ACTION DESCRIPTION Identify the database There are two methods for identifying the database. The first method uses the Oracle System Identifier (SID) and is available in every Oracle release. The second method uses the Service Name, which is available starting with Oracle release 8.0. Both methods use a value that is configured when the database is created and it is important that the client networking configuration use the same naming method that the administrator used when configuring the listener for the database. Identify a network alias for the database You must specify a network alias, which is used to access the Oracle database. You also supply this alias when you identify the Oracle database as a Publisher at the SQL Server Distributor. The network alias is essentially a pointer to the remote SID or Service Name that was configured when the database was created; it has been referred to by several names in different Oracle releases and products, including Net Service Name and TNS Alias. SQL*Plus prompts for this alias as the "Host String" parameter when you log in. Select the network protocol Select the appropriate protocols you would like to support. Most applications use TCP. Specify the host information to identify the database listener The host is the name or DNS alias of the computer on which the Oracle listener is running, which is typically the same computer on which the database resides. For some protocols, you must provide additional information. For example, if you select TCP, you must supply the port on which the listener is listening for connection requests to the target database. The default TCP configuration uses port 1521. Setting Directory Permissions The account under which the SQL Server service on the Distributor runs must be granted read and execute permissions for the directory (and all subdirectories) in which the Oracle client networking software is installed. Testing Connectivity Between the SQL Server Distributor and the Oracle Publisher Near the end of the Net Configuration Assistant there might be an option to test the connection to the Oracle Publisher. Before you test the connection, ensure that the Oracle database instance is online and that the Oracle Listener is running. If the test is unsuccessful, contact the Oracle DBA responsible for the database to which you are trying to connect. After you have made a successful connection to the Oracle Publisher, attempt to log in to the database using the account and password associated with the replication administrative user schema you created. The following must be performed while running under the same Windows account that the SQL Server service uses: 1. Click Start, and then click Run. 2. Type cmd and click OK. 3. At the command prompt, type: sqlplus <UserSchemaLogin>/<UserSchemaPassword>@<NetServiceName> For example: sqlplus replication/$tr0ngPasswerd@Oracle90Server 4. If the networking configuration was successful, the login will succeed and you will see a SQL prompt. 5. If you experience problems connecting to the Oracle database, see the section "The SQL Server Distributor cannot connect to the Oracle database instance" in Troubleshooting Oracle Publishers. Considerations for Oracle Home Oracle supports side-by-side installation of application binaries, but only one set of binaries can be used by replication at a given time. Each set of binaries is associated with an Oracle Home; the binaries are in the directory %ORACLE_HOME%\bin. You must ensure that the correct set of binaries (specifically the latest version of the client networking software) is used when replication makes connections to the Oracle Publisher. Log into the Distributor with the accounts used by the SQL Server service and the SQL Server Agent service and set the appropriate environment variables. The %ORACLE_HOME% variable should be set to refer to the installation point you specified when you installed the client networking software. The %PATH% must include the %ORACLE_HOME% \bin directory as the first Oracle entry that is encountered. For information about setting environment variables, see the Windows documentation. Configuring the Oracle Database as a Publisher at the SQL Server Distributor Oracle Publishers always use a remote Distributor; you must configure an instance of SQL Server to act as a Distributor for your Oracle Publisher (an Oracle Publisher can only use one Distributor, but a single Distributor can service more than one Oracle Publisher). After a Distributor is configured, identify the Oracle database instance as a Publisher at the SQL Server Distributor through SQL Server Management Studio, Transact-SQL, or Replication Management Objects (RMO). For more information about configuring a Distributor, see Configure Distribution. NOTE An Oracle Publisher cannot have the same name as its SQL Server Distributor or the same name as any of the SQL Server Publishers using the same Distributor. When you identify the Oracle database as a Publisher, you must choose an Oracle publishing option: Complete or Oracle Gateway. After a Publisher is identified, this option cannot be changed without dropping and reconfiguring the Publisher. The Complete option is designed to provide snapshot and transactional publications with the complete set of supported features for Oracle publishing. The Oracle Gateway option provides specific design optimizations to improve performance for cases where replication serves as a gateway between systems. After the Oracle Publisher is identified at the SQL Server Distributor, replication creates a linked server with the same name as the TNS service name of the Oracle database. This linked server can be used only by replication. If you need to connect to the Oracle Publisher over a linked server connection, create another TNS service name, and then use this name when calling sp_addlinkedserver (Transact-SQL). To configure an Oracle Publisher and create a publication, see Create a Publication from an Oracle Database. See Also Administrative Considerations for Oracle Publishers Data Type Mapping for Oracle Publishers Glossary of Terms for Oracle Publishing Oracle Publishing Overview Script to Grant Oracle Permissions 3/24/2017 • 3 min to read • Edit Online The script provided in this topic is used during the configuration of an Oracle database that will publish data using Microsoft SQL Server replication. This script is also available in the following directory after installation: <drive>:\\Program Files\Microsoft SQL Server\<InstanceName>\MSSQL\Install\oracleadmin.sql. For more information about configuring the Oracle database, see Configure an Oracle Publisher. NOTE This script includes the statement GRANT CREATE ANY TRIGGER TO &&AdminLogin; , which is required for the triggers used by transactional replication. If you will use only snapshot replication, remove this line from the script. To run the script from the Oracle SQL*Plus utility 1. On the SQL Server Distributor, open a Command Prompt window. 2. To use SQL*PLUS to connect to the Oracle database and execute the oracleadmin.sql script from its default install directory, type the following syntax: sqlplus system/P@$$W0rd@orcl @"c:\Program Files\Microsoft SQL Server\ <InstanceName>\MSSQL\Install\oracleadmin.sql" In this example, the built-in Oracle account system is used to connect to an Oracle database with a network name of "orcl". 3. When prompted, specify the user name, user password, and default table space. --*********************************************************************** -- Copyright (c) 2003 Microsoft Corporation --- File: -- oracleadmin.sql --- Purpose: -- PL/SQL script to create a database user with the required -- permissions to administer SQL Server publishing for an Oracle -- database. --- &&ReplLogin == Replication user login -- &&ReplPassword == Replication user password -- &&DefaultTablespace == Tablespace that will serve as the default -- tablespace for the replication user. -- The replication user will be authorized to allocate UNLIMITED space -- on the default tablespace, which must already exist. --- Notes: --- This script must be run from an Oracle login having the -- authorization to create a new user and grant unlimited tablespace on -- any existing tablespace. The login must also be able to grant to the -- newly created login the following authorizations: --- create public synonym -- drop public synonym -- create sequence -- create procedure -- create procedure -- create session -- create table -- create view --- Additionally, the following properties are also required for -- transactional publications. --- create any trigger --- All of the privileges may be granted through a role, with the -- exception of create table, create view, and create any trigger. -- These must be granted explicitly to the replication user login. -- In the script, all grants are granted explicitly to the replication -- user. --- In addition to these general grants, a table owner must explicitly -- grant select authorization to the replication user on a table before -- the table can be published. -*********************************************************************** ACCEPT ReplLogin CHAR PROMPT 'User to create for replication: '; ACCEPT ReplPassword CHAR PROMPT 'Replication user passsword: ' HIDE; ACCEPT DefaultTableSpace CHAR DEFAULT 'SYSTEM' PROMPT 'Default tablespace: '; -- Create the replication user account CREATE USER &&ReplLogin IDENTIFIED BY &&ReplPassword DEFAULT TABLESPACE &&DefaultTablespace QUOTA UNLIMITED ON &&DefaultTablespace; -- It is recommended that only the required grants be granted to this -- user. --- The following 5 privileges are granted explicitly, but could be -- granted through a role. GRANT CREATE PUBLIC SYNONYM TO &&ReplLogin; GRANT DROP PUBLIC SYNONYM TO &&ReplLogin; GRANT CREATE SEQUENCE TO &&ReplLogin; GRANT CREATE PROCEDURE TO &&ReplLogin; GRANT CREATE SESSION TO &&ReplLogin; -- The following privileges must be granted explicitly to the -- replication user. GRANT CREATE TABLE TO &&ReplLogin; GRANT CREATE VIEW TO &&ReplLogin; -- The replication user login needs to be able to create a tracking -- trigger on any table that is to be published in a transactional -- publication. The CREATE ANY privilege is used to obtain the -- authorization to create these triggers. To replicate a table, the -- table owner must additionally explicitly grant select authorization -- on the table to the replication user. --- NOTE: CREATE ANY TRIGGER is not required for snapshot publications. GRANT CREATE ANY TRIGGER TO &&ReplLogin; See Also Configure an Oracle Publisher Manage Oracle Tablespaces 3/24/2017 • 1 min to read • Edit Online A tablespace is a unit of database storage that is roughly equivalent to a file group in Microsoft SQL Server. Tablespaces allow storage and management of database objects within individual groups. For more information, see the Oracle documentation. When you configure a table as part of an Oracle publication, you can optionally specify an existing Oracle tablespace to be used when storing replication logging information. If unspecified, the tablespace for the replication objects is the default tablespace associated with the replication administrative user schema that was configured when configuring the Publisher. To specify a tablespace for an article logging table: Specify a tablespace in the Article Properties dialog box. For more information about accessing this dialog box, see View and Modify Publication Properties. Use sp_changearticle (Transact-SQL). To use sp_changearticle, specify the following: The name of the Oracle Publisher for the parameter @publisher. The name of the Oracle publication for the parameter @publication. The name of the article for the parameter @article. A value of 'tablespace' for the parameter @property. The name of the tablespace for the parameter @value. See Also Configure an Oracle Publisher Objects Created on the Oracle Publisher Design Considerations and Limitations for Oracle Publishers 3/24/2017 • 8 min to read • Edit Online Publishing from an Oracle database is designed to work nearly identically to publishing from a Microsoft SQL Server database. However, you should be aware of the following limitations and issues: The Oracle Gateway option provides improved performance over the Oracle Complete option; however, this option cannot be used to publish the same table in multiple transactional publications. A table can appear in at most one transactional publication and any number of snapshot publications. If you need to publish the same table in multiple transactional publications, choose the Oracle Complete option. Replication supports publishing tables, indexes, and materialized views. Other objects are not replicated. There are some small differences between the storage and processing of data in Oracle and SQL Server databases that affect replication. There are a number of differences in how transactional replication features are supported when using an Oracle Publisher. Support for Publishing Objects from Oracle Replication supports replicating the following objects from Oracle databases: Tables Index-organized tables Indexes Materialized views (they are replicated as tables) The following can be present on published tables but are not replicated: Domain-based indexes Function-based indexes Defaults Check constraints Foreign keys Storage options (tablespaces, clusters, etc.) The following objects cannot be replicated: Nested tables Views Packages, package bodies, procedures, and triggers Queues Sequences Synonyms For information about supported data types, see Data Type Mapping for Oracle Publishers. Differences between Oracle and SQL Server Oracle has different maximum size limits for some objects. Any objects created in the Oracle publication database should adhere to the maximum size limits for the corresponding objects in SQL Server. For information about limits in SQL Server, see Maximum Capacity Specifications for SQL Server. By default Oracle object names are created in upper case. Ensure that you supply the names of Oracle objects in upper case when publishing them through a SQL Server Distributor if they are upper case on the Oracle database. Failure to specify the objects in the correct case may result in an error message indicating that the object cannot be found. Oracle has a slightly different SQL dialect from SQL Server; row filters should be written in Oraclecompliant syntax. Considerations for Large Objects Large object (LOB) data is not stored in the article log table; updates to LOB data are always retrieved directly from the published table. Updates are replicated in transactional publications only if the operation affecting the LOB fires the replication trigger on the replicated table. Oracle triggers fire when rows containing LOBs are inserted or deleted; however updates to LOB columns do not fire triggers. An update to a LOB column will be replicated immediately only if a non-LOB column of the same row is also updated in the same Oracle transaction. If not, the LOB column will be refreshed at the Subscriber when the next update to a non-LOB column in the same row occurs. Ensure that this behavior is acceptable for your application. To replicate updates to LOB columns in transactional publications, consider one of the following strategies when writing the application: Delete and reinsert the row(s) within a transaction instead of updating the row: specify the new LOB when re-inserting the row. Because delete and insert both fire triggers, the row will be replicated. Include a non-LOB column in the row update in addition to the LOB column, or update a non-LOB column of the row as part of the same Oracle transaction. In both cases, the update of the non-LOB column ensures that the trigger fires. For more information about LOBs, see Data Type Mapping for Oracle Publishers. Unique Indexes and Constraints For both snapshot and transactional replication, columns contained in unique indexes and constraints (including primary key constraints) must adhere to certain restrictions. If they do not adhere to these restrictions, the constraint or index is not replicated. The maximum number of columns allowed in an index on SQL Server is 16. All columns included in unique constraints must have supported data types. For more information about data types, see Data Type Mapping for Oracle Publishers. All columns included in unique constraints must be published (they cannot be filtered). Columns involved in unique constraints or indexes should not be null. Also consider the following issues: Oracle and SQL Server treat NULL differently: Oracle permits multiple rows with NULL values for columns that allow NULL and are included in unique constraints or indexes. SQL Server enforces uniqueness by only permitting a single row with a NULL value for the same column. You cannot publish a unique constraint or index that allows NULL because a constraint violation would occur on the Subscriber if the published table contains multiple rows with NULL values for any of the columns included in the index or constraint. When testing for uniqueness, trailing blanks in a field are ignored by SQL Server but not by Oracle. As in SQL Server transactional replication, tables in Oracle transactional publications require a primary key; the primary key must be unique based on the rules specified above. If the primary key does not adhere to the rules outlined in the previous bullets, the table cannot be published for transactional replication. Differences between Oracle Publishing and Standard Transactional Replication An Oracle Publisher cannot have the same name as: its SQL Server Distributor; any of the SQL Server Publishers that use the Distributor; or any Subscribers that receive the publication. Publications serviced by the same Distributor must each have a unique name. A table published in an Oracle publication cannot receive replicated data. Therefore, Oracle publishing does not support: publications with immediate updating or queued updating subscriptions; or topologies in which publication tables also act as subscription tables, such as peer-to-peer and bidirectional replication. Primary key to foreign key relationships in the Oracle database are not replicated to Subscribers. However, the relationships are maintained in the data as changes are delivered. Standard transactional publications support tables of up to 1000 columns. Oracle transactional publications support 995 columns (replication adds five columns to each published table). Collate clauses are added to the CREATE TABLE statements to enable case sensitive comparisons, which is important for primary keys and unique constraints. This behavior is controlled with the schema option 0x1000, which is specified with the @schema_option parameter of sp_addarticle (Transact-SQL). If you use stored procedures to configure or maintain an Oracle Publisher, do not put the procedures inside an explicit transaction. This is not supported over the linked server used to connect to the Oracle Publisher. If you create a pull subscription to an Oracle publication with a wizard, you must use the New Subscription Wizard supplied with SQL Server 2005 and later versions. For previous versions of SQL Server, you can, however, use the stored procedure and SQL-DMO interfaces to setup pull subscriptions to Oracle publications. If you use stored procedures to propagate changes to Subscribers (the default), be aware that the MCALL syntax is supported, but it has different behavior when the publication is from an Oracle Publisher. Typically MCALL provides a bitmap that shows which columns were updated at the Publisher. With an Oracle publication, the bitmap always shows that all columns were updated. For more information about using stored procedures, see Specify How Changes Are Propagated for Transactional Articles. Transactional Replication Feature Support Oracle publications do not support all of the schema options that SQL Server publications support. For more information on schema options, see sp_addarticle (Transact-SQL). Subscribers to Oracle publications cannot use immediate updating or queued updating subscriptions, or be nodes in a peer-to-peer or bidirectional topology. Subscribers to Oracle publications cannot be automatically initialized from a backup. SQL Server supports two types of validation: binary and rowcount. Oracle Publishers support rowcount validation. For more information, see Validate Replicated Data. SQL Server offers two snapshot formats: native bcp-mode and character-mode. Oracle Publishers support character mode snapshots. Schema changes to published Oracle tables are not supported. To make schema changes, first drop the publication, make the changes, and then re-create the publication and any subscriptions. NOTE If the schema changes and the subsequent drop and re-creation of the publication and subscriptions are performed at a time when no activity is occurring on the published tables, you can specify the option 'replication support only' for the subscriptions. This allows them to be synchronized without having to copy a snapshot to each Subscriber. For more information, see Initialize a Transactional Subscription Without a Snapshot. Replication Security Model The security model for Oracle publishing is the same as the security model for standard transactional replication, with the following exceptions: The account under which the Snapshot Agent and Log Reader Agent make connections from the Distributor to the Publisher is specified through one of the following methods: The @security_mode parameter of sp_adddistpublisher (Transact-SQL) (you also specify values for @login and @password if Oracle Authentication is used) In the Connect to Server dialog box in SQL Server Management Studio, which you use when you configure the Oracle Publisher at the SQL Server Distributor. In standard transactional replication, the account is specified with sp_addpublication_snapshot (Transact-SQL) and sp_addlogreader_agent (Transact-SQL). The account under which the Snapshot Agent and Log Reader Agent make connections cannot be changed with sp_changedistpublisher (Transact-SQL) or through a property sheet, but the password can be changed. If you specify a value of 1 (Windows Integrated Authentication) for the @security_mode parameter of sp_adddistpublisher (Transact-SQL): The process account and password used for both the Snapshot Agent and Log Reader Agent (the @job_login and @job_password parameters of sp_addpublication_snapshot (Transact-SQL) and sp_addlogreader_agent (Transact-SQL)) must be the same as the account and password used to connect to the Oracle Publisher. You cannot change the @job_login parameter through sp_changepublication_snapshot (TransactSQL) or sp_changelogreader_agent (Transact-SQL), but the password can be changed. For more information about replication security, see Security and Protection (Replication). See Also Administrative Considerations for Oracle Publishers Configure an Oracle Publisher Oracle Publishing Overview Administrative Considerations for Oracle Publishers 3/24/2017 • 2 min to read • Edit Online After an Oracle Publisher is configured and the replication change tracking mechanisms are in place, administrators of the Oracle database system can still use standard Oracle database utilities and perform typical system administration tasks. However, you should be aware of the effects on the published data of performing certain administrative tasks. With the exception of dropping or modifying a column that is published for replication, or dropping or modifying any replication objects, these considerations do not apply to snapshot publications. Importing and loading data Triggers are used in change tracking for transactional publications on Oracle. Changes to published tables can be replicated to Subscribers only if the replication triggers fire when an update, insert, or delete occurs. The Oracle utilities Oracle Import and SQL*Loader both have options that affect whether triggers will fire when rows are inserted into replicated tables with these utilities. Oracle Import With Oracle Import, you can set the option ignore to 'y' or 'n' (the default is 'n'). If ignore is set to 'n', the table is dropped and re-created during import. This removes replication triggers and disables replication. If ignore is set to 'y', import will attempt to load the rows into the existing table, which fires the replication triggers. Therefore, ensure ignore is set to 'y' when importing into a replicated table with the Import tool. SQL*Loader With SQL*Loader, you can set the option direct to 'true' or 'false' (the default is 'false'). If direct is set to 'false', rows are inserted using conventional INSERT statements, which fire replication triggers. If direct is set to 'true', the load is optimized, and triggers are not fired. Therefore, ensure direct is set to 'false' when loading into a replicated table with the SQL*Loader tool. Making changes to published objects The following actions require no special considerations: Rebuilding indexes on published tables. Adding user triggers to a published table. The following action requires you to stop all activity on the published tables: Moving a published table. The following actions require you to drop the publication, perform the operation, and then recreate the publication: Truncating a published table. Renaming a published table. Adding a column to a published table. Dropping or modifying a column that is published for replication. Performing non-logged operations. Dropping or modifying replication objects You must drop and reconfigure the Publisher if you drop or modify any Publisher level tracking tables, triggers, sequences, or stored procedures. For a partial list of these objects, see Objects Created on the Oracle Publisher. For information about dropping and reconfiguring the Publisher, see the section "Changes are made that require reconfiguration of the Publisher" in the topic Troubleshooting Oracle Publishers. See Also Configure an Oracle Publisher Design Considerations and Limitations for Oracle Publishers Oracle Publishing Overview Performance Tuning for Oracle Publishers 3/24/2017 • 1 min to read • Edit Online The Oracle publishing architecture is similar to the Microsoft SQL Server publishing architecture; therefore the first step in tuning Oracle replication for performance requires following the general tuning recommendations found in Enhance General Replication Performance. In addition there are two options for Oracle Publishers that are performance related: Specifying the appropriate publishing option: Oracle or Oracle Gateway. Configuring the transaction set job to process changes on the Publisher at an appropriate interval. Specifying the Appropriate Publishing Option The Oracle Gateway option provides improved performance over the Oracle Complete option; however, this option cannot be used to publish the same table in multiple transactional publications. A table can appear in at most one transactional publication and any number of snapshot publications. If you need to publish the same table in multiple transactional publications, choose the Oracle Complete option. Specify this option when identifying the Oracle Publisher at the SQL Server Distributor. For more information, see Create a Publication from an Oracle Database. Configuring the Transaction Set Job Changes to published Oracle tables are processed in groups called transaction sets. To ensure transactional consistency, each transaction set is committed as a single transaction at the distribution database. If the transaction set becomes too large, it cannot be processed efficiently as a single transaction. By default, transaction sets are created only by the Log Reader Agent. If, during periods of high change activity, the Log Reader Agent does not run or cannot connect from the SQL Server Distributor to the Oracle Publisher, transaction sets can become unmanageably large. To prevent this problem, ensure that transaction sets are created at regular intervals, even if the Log Reader Agent does not run or cannot connect to the Oracle Publisher. Transaction sets can be created with the Xactset job (an Oracle database job installed by replication), which uses the same mechanism that the Log Reader Agent does to create sets. Each time the job runs, a new transaction set is created. The next time that the Log Reader Agent runs, the agent processes any sets that have been created. If there are still pending changes after all existing transaction sets have been processed, the Log Reader Agent creates and processes one or more additional transaction sets. To configure the transaction set job, see Configure the Transaction Set Job for an Oracle Publisher (Replication Transact-SQL Programming). See Also Configure an Oracle Publisher Oracle Publishing Overview Data Type Mapping for Oracle Publishers 3/24/2017 • 3 min to read • Edit Online Oracle data types and Microsoft SQL Server data types do not always match exactly. Where possible, the matching data type is selected automatically when publishing an Oracle table. In cases that a single data type mapping is not clear, alternative data type mappings are provided. For information about how to select alternative mappings, see the "Specifying Alternative Data Type Mappings" section later in this topic. The following table shows how data types are mapped by default between Oracle and SQL Server when data is moved from the Oracle Publisher to the SQL Server Distributor. The Alternatives column indicates whether alternative mappings are available. ORACLE DATA TYPE SQL SERVER DATA TYPE ALTERNATIVES BFILE VARBINARY(MAX) Yes BLOB VARBINARY(MAX) Yes CHAR([1-2000]) CHAR([1-2000]) Yes CLOB VARCHAR(MAX) Yes DATE DATETIME Yes FLOAT FLOAT No FLOAT([1-53]) FLOAT([1-53]) No FLOAT([54-126]) FLOAT No INT NUMERIC(38) Yes INTERVAL DATETIME Yes LONG VARCHAR(MAX) Yes LONG RAW IMAGE Yes NCHAR([1-1000]) NCHAR([1-1000]) No NCLOB NVARCHAR(MAX) Yes NUMBER FLOAT Yes NUMBER([1-38]) NUMERIC([1-38]) No NUMBER([0-38],[1-38]) NUMERIC([0-38],[1-38]) Yes NVARCHAR2([1-2000]) NVARCHAR([1-2000]) No ORACLE DATA TYPE SQL SERVER DATA TYPE ALTERNATIVES RAW([1-2000]) VARBINARY([1-2000]) No REAL FLOAT No ROWID CHAR(18) No TIMESTAMP DATETIME Yes TIMESTAMP(0-7) DATETIME Yes TIMESTAMP(8-9) DATETIME Yes TIMESTAMP(0-7) WITH TIME ZONE VARCHAR(37) Yes TIMESTAMP(8-9) WITH TIME ZONE VARCHAR(37) No TIMESTAMP(0-7) WITH LOCAL TIME ZONE VARCHAR(37) Yes TIMESTAMP(8-9) WITH LOCAL TIME ZONE VARCHAR(37) No UROWID CHAR(18) No VARCHAR2([1-4000]) VARCHAR([1-4000]) Yes Considerations for Data Type Mapping Keep the following data type issues in mind when replicating data from an Oracle database. Unsupported Data Types The following data types are not supported; columns that have these types cannot be replicated: Object types XML types Varrays Nested tables Columns that use REF The DATE Data Type Dates in SQL Server range from 1753 A.D. to 9999 A.D., whereas dates in Oracle range from 4712 B.C. to 4712 A.D. If a column of type DATE contains values that are out of range for SQL Server, select the alternative data type for the column, which is VARCHAR(19). FLOAT and NUMBER Types The scale and precision specified during the mapping of FLOAT and NUMBER data types depends upon the scale and precision specified for the column using the data type in the Oracle database. Precision is the number of digits in a number. Scale is the number of digits to the right of the decimal point in a number. For example, the number 123.45 has a precision of 5 and a scale of 2. Oracle allows numbers to be defined with a scale greater than the precision, such as NUMBER(4,5), but SQL Server requires the precision to be equal to or greater than the scale. To ensure there is no data truncation, if the scale is greater than the precision at the Oracle Publisher, the precision is set equal to the scale when the data type is mapped: NUMBER(4,5) would be mapped as NUMERIC(5,5). NOTE If you do not specify a scale and precision for NUMBER, SQL Server defaults to using the maximum scale (8) and precision (38). We recommend that you set a specific scale and precision in Oracle for better storage and performance when the data is replicated. Large Object Types Oracle supports up to 4 gigabytes (GB), whereas SQL Server supports up to 2 GB. Data replicated above 2 GB is truncated. If an Oracle table includes a BFILE column, the data for the column is stored in the file system. The replication administrative user account must be granted access to the directory in which the data is stored using the following syntax: GRANT READ ON DIRECTORY <directory_name> TO <replication_administrative_user_schema> For more information about large objects types, see the section "Considerations for Large Objects" in Design Considerations and Limitations for Oracle Publishers. Specifying Alternative Data Type Mappings Typically, the default data type mapping is appropriate, but for many Oracle data types, you can select a data type mapping from a set of alternative mappings, rather than using the default. There are two ways to specify alternative mappings: Override the default on a per-article basis using stored procedures or the New Publication Wizard. Globally change the default for all future articles using stored procedures (defaults are not changed for existing articles). To specify alternative data type mappings, see Specify Data Type Mappings for an Oracle Publisher. See Also Configure an Oracle Publisher Design Considerations and Limitations for Oracle Publishers Oracle Publishing Overview Backup and Restore for Oracle Publishers 3/24/2017 • 1 min to read • Edit Online THIS TOPIC APPLIES TO: SQL Server (starting with 2016) Warehouse Parallel Data Warehouse Azure SQL Database Azure SQL Data Follow these guidelines when backing up and restoring: Ensure the Log Reader Agent does not run and that other database activity on the published tables does not occur while the Publisher is being backed up. Backup up the Publisher and Distributor at the same time. If the Publisher or Distributor must be restored, reinitialize all subscriptions. To restore a Subscriber from a backup (without having to reinitialize subscriptions), the transactions delivered to the distribution database after the last subscription database backup was completed must still be available. The length of time transactions are available depends on distribution retention settings. For information on these settings, see Subscription Expiration and Deactivation. If the Publisher or Distributor becomes out of sync as the result of a database restore, the replication agents log error messages. At this point, you must drop and recreate all relevant publications and subscriptions: 1. Script the definition of the publications and subscriptions. For more information, see Scripting Replication. If the definition of the publications has changed between the versions of the Publisher and Distributor states, you will need to modify the scripts. 2. Drop the publications and subscriptions. 3. Run the scripts created in step 1. If the Publisher must be dropped and reconfigured, drop the MSSQLSERVERDISTRIBUTOR public synonym and the configured Oracle replication user with the CASCADE option to remove all replication objects from the Oracle Publisher. See Also Back Up and Restore Replicated Databases Configure an Oracle Publisher Oracle Publishing Overview Objects Created on the Oracle Publisher 3/24/2017 • 2 min to read • Edit Online Microsoft SQL Server replication installs database objects on the Oracle Publisher to enable change tracking and forwarding ( SQL Server does not install any binary files on the Oracle Publisher). The following table lists the objects that are created at the Oracle Publisher when it is identified as a Publisher at the SQL Server Distributor. The object descriptions are provided for informational purposes only. These objects should not be modified. OBJECT NAME OBJECT TYPE DESCRIPTION HREPL_ArticleNlog_V Table Change tracking table used to store information as changes are made to the published table. A change tracking table is created for each published table. HREPL_Changes Table Table used internally by the Xactset Job to determine the number of changes waiting to be assigned to a transaction set. For more information about this job, see Performance Tuning for Oracle Publishers. HREPL_Distributor Table Distributor status table used to maintain information about the SQL Server Distributor associated with the Oracle Publisher. HREPL_Event Table Event table used for synchronizing snapshots and row count requests. HREPL_Mutex Table Table used to ensure that the Oracle package procedure PopulatePollTable is not executed concurrently by both the Log Reader Agent and the database job. HREPL_Poll Table Table used to identify log table entries associated with sets of changes to published tables. HREPL_PublishedTables Table Table containing an entry for each article in a transactional publication. HREPL_Publisher Table Publisher status table used for maintaining Publisher specific information. HREPL_SchemaFilter Table Table containing schemas that are not displayed when publishing through the New Publication Wizard. HREPL_XactsetCreateTimes Table Table identifying the create time associated with each transaction set. OBJECT NAME OBJECT TYPE DESCRIPTION HREPL_XactsetJob Table Table with current parameter settings for the Xactset Job. HREPL_Pollid Sequence Sequence used to generate poll IDs. HREPL_Seq Sequence Sequence used to order change commands. HREPL_Stmt Sequence Sequence used to generate statement IDs. HREPL Package and Package Body Package of Publisher support code that is created at the Publisher. MSSQLSERVERDISTRIBUTOR Public Synonym Public synonym for the HREPL_Distributor table. If you configure a Distributor to use with an Oracle Publisher, and this synonym already exists in the database, it is dropped and recreated. Dropping the public synonym and the configured Oracle replication user with the CASCADE option removes all replication objects from the Oracle Publisher. HREPL_Len_I_J_K Function Function defined outside the Oracle publishing package code, used to query for the length of a LONG column (used when generating parameterized commands for tables with published LONG columns). A function is created for each published table with a LONG column. HREPL_DropPublisher Procedure Procedure defined outside the Oracle publishing package code, used to drop the Oracle Publisher. HREPL_ExecuteCommand Procedure Procedure defined outside the Oracle publishing package code, used to execute a command at the Publisher. HREPL_ArticleN_Trigger_Row Trigger Trigger generated for each published table, used to track row changes. HREPL_ArticleN_Trigger_Stmt Trigger Trigger generated for each published table, used to track statement level changes. HREPL_Article_I_J View View created for each published table, used to query the published table. OBJECT NAME OBJECT TYPE DESCRIPTION HREPL_Log_I_J_K View View created for each published table, used to query the change tracking table. See Also Configure an Oracle Publisher Glossary of Terms for Oracle Publishing Oracle Publishing Overview Troubleshooting Oracle Publishers 3/24/2017 • 12 min to read • Edit Online This topic lists a number of issues that might arise when configuring and using an Oracle Publisher. An Error Is Raised Regarding Oracle Client and Networking Software The account under which Microsoft SQL Server runs on the Distributor must be granted read and execute permissions for the directory (and all subdirectories) in which the Oracle client networking software is installed. If the permissions are not granted or the Oracle client components are not installed properly, you will receive the following error message: "Connection to server failed with [Microsoft OLE DB Provider for Oracle]. Oracle client and networking components were not found. These components are supplied by Oracle Corporation and are part of the Oracle Version 7.3.3 or later client software installation. Provider is unable to function until these components are installed." If an appropriate Oracle client has been installed at the Distributor, ensure that SQL Server was stopped and then restarted after the client installation completed. This is required in order for SQL Server to recognize the client components. If you have verified that permissions are granted and that components are installed correctly, but this error persists, verify that the registry settings at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI are correct: For Oracle 10g, the correct settings are OracleOciLib = oci.dll OracleSqlLib = orasql10.dll OracleXaLib = oraclient10.dll For Oracle 9i, the correct settings are OracleOciLib = oci.dll OracleSqlLib = orasql9.dll OracleXaLib = oraclient9.dll The SQL Server Distributor Cannot Connect to the Oracle Database Instance If the SQL Server Distributor cannot connect to the Oracle Publisher, ensure that: The necessary Oracle software is installed on the Distributor. The Oracle database is online and you can connect to it using a tool like SQL*Plus. The login replication uses to connect to the Oracle Publisher has sufficient permissions. For more information, see Configure an Oracle Publisher. The TNS names defined during configuration of the Oracle Publisher are listed in the tnsnames.ora file. The correct Oracle Home and path are used. Even if you have only one set of Oracle binaries installed on the SQL Server Distributor, ensure that the environment variables related to the Oracle Home are set properly. If you change environment variable values, you must stop and restart SQL Server for the change to take effect. For more information about configuring and testing connectivity, see "Installing and Configuring Oracle Client Networking Software on the SQL Server Distributor" in Configure an Oracle Publisher. The Oracle Publisher Is Associated with Another Distributor An Oracle Publisher can only be associated with one SQL Server Distributor. If a different Distributor is associated with the Oracle Publisher, it must be dropped before another Distributor can be used. If the Distributor is not dropped first, you will receive one of the following error messages: "Oracle server instance '<OraclePublisherName>' has been previously configured to use '<SQLServerDistributorName>' as its Distributor. To begin using '<NewSQLServerDistributorName>' as its Distributor, you must remove the current replication configuration on the Oracle server instance, which will delete all publications on that server instance." "Oracle server '<OracleServerName>' is already defined as publisher '<OraclePublisherName>' on distributor '<SQLServerDistributorName>.<DistributionDatabaseName>'. Drop the publisher or drop the public synonym '<SynonymName>' to recreate." When an Oracle Publisher is dropped, the replication objects in the Oracle database are automatically cleaned up. However, manual cleanup of the Oracle replication objects is necessary in some cases. To manually clean up Oracle replication objects created by replication: 1. Connect to the Oracle publisher with DBA permissions. 2. Issue the SQL command DROP PUBLIC SYNONYM MSSQLSERVERDISTRIBUTOR; . 3. Issue the SQL command DROP USER <replication_administrative_user_schema>``CASCADE; . SQL Server Error 21663 Is Raised Regarding the Lack of a Primary Key Articles in transactional publications must have a valid primary key. If they do not have a valid primary key, you will receive the following error message when you attempt to add an article: "No valid primary key found for source table [<TableOwner>].[<TableName>]" For information about requirements for primary keys, see the section "Unique Indexes and Constraints" in the topic Design Considerations and Limitations for Oracle Publishers. SQL Server Error 21642 Is Raised Regarding a Duplicate Linked Server Login When an Oracle Publisher is initially configured, a linked server entry is created for the connection between the Publisher and the Distributor. The linked server has the same name as the Oracle TNS service name. If you attempt to create a linked server with the same name, the following error message is shown: "Heterogeneous publishers require a linked server. A linked server named '<LinkedServerName>' already exists. Please remove linked server or choose a different publisher name." This error can occur if you attempt to create the linked server directly or if you have previously dropped the relationship between the Oracle Publisher and the SQL Server Distributor, and you are now attempting to reconfigure it. If you receive this error while attempting to reconfigure the Publisher, drop the linked server with sp_dropserver (Transact-SQL). If you need to connect to the Oracle Publisher over a linked server connection, create another TNS service name, and then use this name when calling sp_addlinkedserver (Transact-SQL). For information about creating TNS service names, see the Oracle documentation. SQL Server Error 21617 Is Raised Oracle publishing uses the Oracle application SQLPLUS to download the package of Publisher support code to the Oracle database. Before attempting to configure the Oracle Publisher, SQL Server verifies that SQL\PLUS is accessible through the system path on the Distributor. If SQL*PLUS cannot be loaded, the following error message is shown: "Unable to run SQL*PLUS. Make certain that a current version of the Oracle client code is installed at the distributor." Try to locate SQL*PLUS on the Distributor. For an Oracle 10g client install, the name of this executable is sqlplus.exe. It is typically installed in %ORACLE_HOME%/bin. To verify that the path of SQL*PLUS appears in the system path, examine the value of the system variable Path: 1. Right-click My Computer, and then click Properties. 2. Click the Advanced tab, and then click Environment variables. 3. In the Environment Variables dialog box, in the System variables list, select the Path variable, and then click Edit. 4. In the Edit System Variable dialog box: if the path to the folder that contains sqlplus.exe is not present in the Variable value text box, edit the string to include it. 5. Click OK on each open dialog box to exit and save changes. If you cannot locate sqlplus.exe on the Distributor, install a current version of the Oracle client software at the Distributor. For more information, see Configure an Oracle Publisher. SQL Server Error 21620 Is Raised If you are connecting to an Oracle database earlier than version 8.1, Oracle publishing requires that the Oracle client software installed on the Distributor be from version 9. If you are connecting to an Oracle database that is version 8.1 or later, we recommend that the Oracle client software be version 10 or later. Before attempting to configure the Oracle Publisher, Oracle publishing verifies that the version of SQL*PLUS accessible through the system path on the Distributor is version 9 or later. If it is not, the following error message is shown: "The version of SQL*PLUS that is accessible through the system Path variable is not current enough to support Oracle publishing. Make certain that a current version of the Oracle client code is installed at the distributor." If you have multiple versions of the Oracle client software installed on the Distributor, make sure that the most current version is at least version 9 and that the system path variable refers first to this version (references to other versions can appear as long as the most recent appears first). For more information about editing the system path variable, see the section "SQL Server Error 21617 is Raised" earlier in this topic. SQL Server Error 21624 or Error 21629 Is Raised For 64-bit Distributors, Oracle publishing uses the Oracle OLEDB Provider for Oracle (OraOLEDB.Oracle). Make sure that the Oracle OLEDB provider is installed and registered on the Distributor. If the provider is not installed and registered, one or both of the following error messages is shown: "Unable to locate the registered Oracle OLEDB provider, OraOLEDB.Oracle, at distributor '%s'. Make certain that a current version of the Oracle OLEDB provider is installed and registered at the distributor." "The CLSID registry key indicating that the Oracle OLEDB Provider for Oracle, OraOLEDB.Oracle, has been registered is not present at the distributor. Make certain that the Oracle OLEDB provider is installed and registered at the distributor." If you are using Oracle client software version 10g, the provider is OraOLEDB10.dll; for version 9i, it is OraOLEDB.dll. The provider is installed in %ORACLE_HOME%\BIN (for example, C:\oracle\product\10.1.0\Client_1\bin). If you determine that the Oracle OLEDB provider is not installed on the Distributor, install it from the Oracle client software install disc provided by Oracle. For more information, see Configure an Oracle Publisher. If the Oracle OLEDB provider is installed, make sure that it is registered. To register the provider DLL, execute the following command from the directory in which the DLL is installed, and then stop and restart the SQL Server instance: 1. regsvr32 OraOLEDB10.dll or regsvr32 OraOLEDB.dll . SQL Server Error 21626 or Error 21627 Is Raised To verify that the Oracle publishing environment is configured properly, SQL Server tries to connect to the Oracle Publisher with the login credentials you specified during configuration. If the SQL Server Distributor cannot connect to the Oracle Publisher, the following error message is shown: "Unable to connect to Oracle database server '%s' using the Oracle OLEDB provider OraOLEDB.Oracle." If this error message is shown, verify connectivity to the Oracle database by running SQL*PLUS directly using the same login and password specified during configuration of the Oracle Publisher. For more information, see the section "The SQL Server Distributor Cannot Connect to the Oracle Database Instance" earlier in this topic. SQL Server Error 21628 Is Raised For 64-bit Distributors, Oracle publishing uses the Oracle OLEDB Provider for Oracle (OraOLEDB.Oracle). SQL Server creates a registry entry to allow the Oracle provider to run in process with SQL Server. If there is a problem reading or writing this registry entry, the following error message is shown: "Unable to update the registry of distributor '%s' to allow Oracle OLEDB provider OraOLEDB.Oracle to run in process with SQL Server. Make certain that current login is authorized to modify SQL Server owned registry keys." Oracle publishing requires the registry entry to exist and to be set to 1 for 64 bit Distributors. If the entry does not exist, SQL Server will attempt to create it. If the entry exists, but is set to 0, the setting will not be changed; the configuration of the Oracle Publisher will fail. To view and modify the registry setting: 1. Click Start, and then click Run. 2. In the Run dialog box, type regedit, and then click OK. 3. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<InstanceName>\Providers. Included under Providers should be a folder named OraOLEDB.Oracle. Within this folder should be the DWORD value name AllowInProcess, with a value of 1. 4. If you determine that AllowInProcess is set to 0, update the registry entry to 1: a. Right-click the entry, and then click Modify. b. In the Edit String dialog box, type 1 in the Value data field. SQL Server Error 21684 Is Raised If the administrative user account does not have sufficient privileges, the following error message is shown: "The permissions associated with the administrator login for Oracle publisher '%s' are not sufficient." To verify the permissions granted to the user, execute the following query: output should be similar to the following: SELECT * from session_privs . The PRIVILEGE -----------------CREATE SESSION CREATE TABLE CREATE PUBLIC SYNONYM DROP PUBLIC SYNONYM CREATE VIEW CREATE SEQUENCE CREATE PROCEDURE CREATE TRIGGER You Encounter Permissions Issues for the Replication User Schema The replication user schema must have the permissions described in "Creating the User Schema Manually" in Configure an Oracle Publisher. Oracle Error ORA-01000 Replication uses cursors on the Oracle Publisher during the process of adding articles to a publication. It is possible to exceed the maximum number of cursors available on the Publisher during this process. If this occurs, the following error is raised: "ORA-01000: maximum open cursors exceeded" To avoid this problem, ensure that the max_open_cursors setting in the Oracle databases is set to a sufficiently high number (at least 1000). For more information about this setting, see the Oracle documentation. Oracle Error ORA-01555 The following Oracle database error is not related to snapshot replication; it is related to how Oracle constructs read-consistent views of data: "ORA-01555: Snapshot too old" Using objects known as rollback segments, Oracle constructs read-consistent views of data as of the point in time a SQL statement is issued. A "snapshot too old" error might occur when rollback information is overwritten by other concurrent sessions. Prior to Oracle 9i, the recommended method of reducing the frequency of this error was to increase the size and/or number of rollback segments, and to assign large transactions to a specific rollback segment. In Oracle 9i, Oracle introduced the UNDO tablespace concept, which replaces the rollback segment. To prevent the "snapshot too old" error in Oracle 9i, it is recommended that you: Create an UNDO tablespace with an appropriate amount of free space. Set the retention guarantee on the tablespace (Oracle 10G and greater). Configure the Oracle initialization parameters UNDO_MANAGEMENT and UNDO_RETENTION. For further details about avoiding the "snapshot too old" error, consult the Oracle documentation. Oracle Error ORA-22285 If a table includes a BFILE column, the data for the column is stored in the file system. The replication administrative user account must be granted access to the directory in which the data is stored using the following syntax: GRANT READ ON DIRECTORY <directory_name> TO <replication_administrative_user_schema> If access is not granted, the following error is raised by the Log Reader Agent: "ORA-22285: non-existent directory or file for FILEOPEN operation" Changes Are Made That Require Reconfiguration of the Publisher Changes to replication metadata tables or procedures require that you drop and reconfigure the Publisher. To reconfigure the Publisher, you must drop the Publisher and configure it again using SQL Server Management Studio, Transact-SQL, or RMO. For information about configuring the Publisher, see Configure an Oracle Publisher. To drop an Oracle Publisher (SQL Server Management Studio) 1. Connect to the Distributor for the Oracle Publisher in SQL Server Management Studio and expand the server node. 2. Right-click Replication, and then click Distributor Properties. 3. On the Publishers page of the Distributor Properties dialog box, clear the check box for the Oracle Publisher. 4. Click OK. To drop an Oracle Publisher (Transact-SQL) Execute sp_dropdistpublisher. For more information, see sp_dropdistpublisher (Transact-SQL). See Also Configure an Oracle Publisher Oracle Publishing Overview Non-SQL Server Subscribers 3/24/2017 • 4 min to read • Edit Online The following non- SQL Server Subscribers can subscribe to snapshot and transactional publications using push subscriptions. Subscriptions are supported for the two most recent versions of each database listed using the most recent version of the OLE DB provider listed. Heterogeneous replication to non-SQL Server subscribers is deprecated. Oracle Publishing is deprecated. To move data, create solutions using change data capture and SSIS. Cau t i on This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. DATABASE OPERATING SYSTEM PROVIDER Oracle All platforms that Oracle supports Oracle OLE DB provider (supplied by Oracle) IBM DB2 MVS, AS400, Unix, Linux, Windows excluding 9.x Microsoft Host Integration Server (HIS) OLE DB provider For information about creating subscriptions to Oracle and IBM DB2, see Oracle Subscribers and IBM DB2 Subscribers. Considerations for Non-SQL Server Subscribers Keep the following considerations in mind when replicating to non- SQL Server Subscribers: General Considerations Replication supports publishing tables and indexed views as tables to non- SQL Server Subscribers (indexed views cannot be replicated as indexed views). When creating a publication in the New Publication Wizard and then enabling it for non-SQL Server Subscribers using the Publication Properties dialog box, the owner of all objects in the subscription database is not specified for non- SQL Server Subscribers, whereas for Microsoft SQL Server Subscribers, it is set to the owner of the corresponding object in the publication database. If a publication will have SQL Server Subscribers and non- SQL Server Subscribers, the publication must be enabled for non- SQL Server Subscribers before any subscriptions to SQL Server Subscribers are created. By default, scripts generated by the Snapshot Agent for non- SQL Server Subscribers use non-quoted identifiers in the CREATE TABLE syntax. Therefore, a published table named 'test' is replicated as 'TEST'. To use the same case as the table in the publication database, use the -QuotedIdentifier parameter for the Distribution Agent. The -QuotedIdentifier parameter must also be used if published object names (such as tables, columns, and constraints) include spaces or words that are reserved words in the version of the database at the non- SQL Server Subscriber. For more information about this parameter, see Replication Distribution Agent. The account under which the Distribution Agent runs must have read access to the install directory of the OLE DB provider. By default for non- SQL Server Subscribers, the Distribution Agent uses a value of [(default destination)] for the subscription database (the -SubscriberDB parameter for the Distribution Agent): For Oracle, a server has at most one database, so it is not necessary to specify the database. For IBM DB2, the database is specified in the DB2 connection string. For more information, see Create a Subscription for a Non-SQL Server Subscriber. If the SQL Server Distributor is running on a 64 bit platform, you must use the 64 bit version of the appropriate OLE DB provider. Replication moves data in Unicode format regardless of the collation/code pages used on the Publisher and Subscriber. It is recommended that you choose a compatible collation/code page when replicating between Publishers and Subscribers. If an article is added to or deleted from a publication, subscriptions to non- SQL Server Subscribers must be reinitialized. The only constraints supported for all non- SQL Server Subscribers are: NULL, and NOT NULL. Primary key constraints are replicated as unique indexes. The value NULL is treated differently by different databases, which affects how a blank value, an empty string, and a NULL are represented. This in turn affects the behavior of values inserted into columns with unique constraints defined. For example, Oracle allows multiple NULL values in a column that is considered unique, whereas SQL Server allows only a single NULL value in a unique column. An additional factor is how NULL values, empty strings, and blank values are treated when the column is defined as NOT NULL. For information about addressing this issue for Oracle Subscribers, see Oracle Subscribers. Replication-related metadata (transaction sequence table) is not deleted from non- SQL Server subscribers when the subscription is removed. Conforming to the Requirements of the Subscriber Database Published schema and data must conform to the requirements of the database at the Subscriber. For example, if a non- SQL Server database has a smaller maximum row size than SQL Server, you must ensure that the published schema and data do not exceed this size. Tables replicated to non- SQL Server Subscribers will adopt the table naming conventions of the database at the Subscriber. DDL is not supported for non-SQL Server Subscribers. For more information about schema changes, see Make Schema Changes on Publication Databases. Replication Feature Support SQL Server offers two types of subscriptions: push and pull. Non- SQL Server Subscribers must use push subscriptions, in which the Distribution Agent runs at the SQL Server Distributor. SQL Server offers two snapshot formats: native bcp-mode and character-mode. Non- SQL Server Subscribers require character mode snapshots. Non- SQL Server Subscribers cannot use immediate updating or queued updating subscriptions, or be nodes in a peer-to-peer topology. Non- SQL Server Subscribers cannot be automatically initialized from a backup. See Also Heterogeneous Database Replication Subscribe to Publications Oracle Subscribers 3/24/2017 • 6 min to read • Edit Online Beginning with SQL Server 2005, SQL Server supports push subscriptions to Oracle through the Oracle OLE DB provider supplied by Oracle. Configuring an Oracle Subscriber To configure an Oracle Subscriber, follow these steps: 1. Install and configure Oracle client networking software and the Oracle OLE DB provider on the SQL Server Distributor, so that the Distributor can make connections to the Oracle Subscriber. The Oracle client networking software should be the most recent version available. Oracle recommends that users install the most recent versions of client software. The client software is therefore often a more recent version than the database software. The most straightforward way to install the software is to use the Oracle Universal Installer on the Oracle Client disk. In the Oracle Universal Installer, you will supply the following information: INFORMATION DESCRIPTION Oracle Home This is the path to the install directory for the Oracle software. Accept the default (C:\oracle\ora90 or similar) or enter another path. For more information about the Oracle Home, see the section "Considerations for Oracle Home" later in this topic. Oracle home name An alias for the Oracle home path. Installation type In Oracle 10g, select the Runtime or Administrator installation option. 2. Create a TNS name for the Subscriber. TNS (Transparent Network Substrate) is a communication layer used by Oracle databases. The TNS Service Name is the name by which an Oracle database instance is known on a network. You assign a TNS Service Name when you configure connectivity to the Oracle database. Replication uses the TNS Service name to identify the Subscriber and to establish connections. After the Oracle Universal Installer is complete, use the Net Configuration Assistant to configure network connectivity. You must supply four pieces of information to configure network connectivity. The Oracle database administrator configures the network configuration when setting up the database and listener and should be able to provide this information if you do not have it. You must do the following: ACTION DESCRIPTION Identify the database There are two methods for identifying the database. The first method uses the Oracle System Identifier (SID) and is available in every Oracle release. The second method uses the Service Name, which is available starting with Oracle release 8.0. Both methods use a value that is configured when the database is created and it is important that the client networking configuration use the same naming method that the administrator used when configuring the listener for the database. ACTION DESCRIPTION Identify a network alias for the database You must specify a network alias, which is used to access the Oracle database. The network alias is essentially a pointer to the remote SID or Service Name that was configured when the database was created; it has been referred to by several names in different Oracle releases and products, including Net Service Name and TNS Alias. SQL*Plus prompts for this alias as the "Host String" parameter when you log in. Select the network protocol Select the appropriate protocols you would like to support. Most applications use TCP. Specify the host information to identify the database listener The host is the name or DNS alias of the computer on which the Oracle listener is running, which is typically the same computer on which the database resides. For some protocols, you must provide additional information. For example, if you select TCP, you must supply the port on which the listener is listening for connection requests to the target database. The default TCP configuration uses port 1521. 3. Create a snapshot or transactional publication, enable it for non- SQL Server Subscribers, and then create a push subscription for the Subscriber. For more information, see Create a Subscription for a Non-SQL Server Subscriber. Setting directory permissions The account under which the SQL Server service on the Distributor runs must be granted read and execute permissions for the directory (and all subdirectories) where the Oracle client networking software is installed. Testing connectivity between the SQL Server Distributor and the Oracle Publisher Near the end of the Net Configuration Assistant there might be an option to test the connection to the Oracle Subscriber. Before you test the connection, ensure that the Oracle database instance is online and that the Oracle Listener is running. If the test is unsuccessful, contact the Oracle DBA responsible for the database to which you are trying to connect. After you have made a successful connection to the Oracle Subscriber, attempt to log in to the database using the same account and password as you configured for the Distribution Agent for the subscription: 1. Click Start, and then click Run. 2. Type cmd and click OK. 3. At the command prompt, type: sqlplus <UserSchemaLogin>/<UserSchemaPassword>@<NetServiceName> For example: sqlplus replication/$tr0ngPasswerd@Oracle90Server 4. If the networking configuration was successful, the login will succeed and you will see a SQL prompt. Considerations for Oracle Home Oracle supports side-by-side installation of application binaries, but only one set of binaries can be used by replication at a given time. Each set of binaries is associated with an Oracle Home; the binaries are in the directory %ORACLE_HOME%\bin. You must ensure that the correct set of binaries (specifically the latest version of the client networking software) is used when replication makes connections to the Oracle Subscriber. Log into the Distributor with the accounts used by the SQL Server service and the SQL Server Agent service and set the appropriate environment variables. The %ORACLE_HOME% variable should be set to refer to the installation point you specified when you installed the client networking software. The %PATH% must include the %ORACLE_HOME% \bin directory as the first Oracle entry that is encountered. For information about setting environment variables, see the Windows documentation. NOTE If you have more than one Oracle home on the SQL Server Distributor, ensure that the Distribution Agent is using the most recent Oracle OLE DB provider. In some cases, Oracle does not update the OLE DB provider by default when you update the client components on the SQL Server Distributor. Uninstall the old OLE DB provider and install the latest OLE DB provider. For more information about installing and uninstalling the provider, see the Oracle documentation. Considerations for Oracle Subscribers In addition to the considerations covered in the topic Non-SQL Server Subscribers, consider the following issues when replicating to Oracle Subscribers: Oracle treats both empty strings and NULL values as NULL. This is important if you define a SQL Server column as NOT NULL, and are replicating the column to an Oracle Subscriber. To avoid failures when applying changes to the Oracle Subscriber, you must do one of the following: Ensure that empty strings are not inserted into the published table as column values. Use the –SkipErrors parameter for the Distribution Agent if it is acceptable to be notified of failures in the Distribution Agent history log and to continue processing. Specify the Oracle error code 1400 (-SkipErrors1400). Modify the generated create table script, removing the NOT NULL attribute from any character columns that may have associated empty strings, and supply the modified script as a custom create script for the article using the @creation_script parameter of sp_addarticle. Oracle Subscribers support a schema option of 0x4071. For more information about schema options, see sp_addarticle (Transact-SQL). Mapping Data Types from SQL Server to Oracle The following table shows the data type mappings that are used when data is replicated to a Subscriber running Oracle. SQL SERVER DATA TYPE ORACLE DATA TYPE bigint NUMBER(19,0) binary(1-2000) RAW(1-2000) binary(2001-8000) BLOB bit NUMBER(1) char(1-2000) CHAR(1-2000) char(2001-4000) VARCHAR2(2001-4000) char(4001-8000) CLOB SQL SERVER DATA TYPE ORACLE DATA TYPE date DATE datetime DATE datetime2(0-7) TIMESTAMP(7) for Oracle 9 and Oracle 10; VARCHAR(27) for Oracle 8 datetimeoffset(0-7) TIMESTAMP(7) WITH TIME ZONE for Oracle 9 and Oracle 10; VARCHAR(34) for Oracle 8 decimal(1-38, 0-38) NUMBER(1-38, 0-38) float(53) FLOAT float FLOAT geography BLOB geometry BLOB hierarchyid BLOB image BLOB int NUMBER(10,0) money NUMBER(19,4) nchar(1-1000) CHAR(1-1000) nchar(1001-4000) NCLOB ntext NCLOB numeric(1-38, 0-38) NUMBER(1-38, 0-38) nvarchar(1-1000) VARCHAR2(1-2000) nvarchar(1001-4000) NCLOB nvarchar(max) NCLOB real REAL smalldatetime DATE smallint NUMBER(5,0) smallmoney NUMBER(10,4) SQL SERVER DATA TYPE ORACLE DATA TYPE sql_variant N/A sysname VARCHAR2(128) text CLOB time(0-7) VARCHAR(16) timestamp RAW(8) tinyint NUMBER(3,0) uniqueidentifier CHAR(38) varbinary(1-2000) RAW(1-2000) varbinary(2001-8000) BLOB varchar(1-4000) VARCHAR2(1-4000) varchar(4001-8000) CLOB varbinary(max) BLOB varchar(max) CLOB xml NCLOB See Also Non-SQL Server Subscribers Subscribe to Publications IBM DB2 Subscribers 3/24/2017 • 8 min to read • Edit Online THIS TOPIC APPLIES TO: SQL Server (starting with 2008) Azure SQL Database Azure SQL Data Warehouse Parallel Data Warehouse SQL Server supports push subscriptions to IBM DB2/AS 400, DB2/MVS, and DB2/Universal Database through the OLE DB providers that are included with Microsoft Host Integration Server. Configuring an IBM DB2 Subscriber To configure an IBM DB2 Subscriber, follow these steps: 1. Install the latest version of the Microsoft OLE DB Provider for DB2 on the Distributor: If you are using SQL Server Enterprise Edition, on the SQL Server Downloads Web page, in the Related Downloads section, click the link to the latest version of the Microsoft SQL Server Feature Pack. On the Microsoft SQL Server Feature Pack Web page, search for Microsoft OLE DB Provider for DB2. If you are using SQL Server Standard Edition, install the latest version of the Microsoft Host Integration Services (HIS) server, which includes the provider. In addition to installing the provider, we recommend that you install the Data Access Tool, which is used in the next step (it is installed by default with the download for SQL Server Enterprise Edition. For more information about installing and using the Data Access Tool, see the provider documentation or the HIS documentation. 2. Create a connection string for the Subscriber. The connection string can be created in any text editor, but we recommend that you use the Data Access Tool. To create the string in the Data Access Tool: a. Click Start, Programs, Microsoft OLE DB Provider for DB2, and then Data Access Tool. b. In the Data Access Tool, follow the steps to provide information about the DB2 server. When you complete the tool, a universal data link (UDL) is created with an associated connection string (the UDL is not actually used by replication, but the connection string is). c. Access the connection string: right-click the UDL in the Data Access Tool and select Display Connection String. The connection string will be similar to (line breaks are for readability): Provider=DB2OLEDB;Initial Catalog=MY_SUBSCRIBER_DB;Network Transport Library=TCP;Host CCSID=1252; PC Code Page=1252;Network Address=MY_SUBSCRIBER;Network Port=50000;Package Collection=MY_PKGCOL; Default Schema=MY_SCHEMA;Process Binary as Character=False;Derive Parameters=False;Units of Work=RUW;DBMS Platform=DB2/NT; Persist Security Info=False;Connection Pooling=True; Most of the options in the string are specific to the DB2 server you are configuring, but the Process Binary as Character and Derive Parameters options should always be set to False . A value is required for the Initial Catalog option to identify the subscription database. The connection string will be entered in the New Subscription Wizard when you create the subscription. 3. Create a snapshot or transactional publication, enable it for non- SQL Server Subscribers, and then create a push subscription for the Subscriber. For more information, see Create a Subscription for a Non-SQL Server Subscriber. 4. Optionally, specify a custom creation script for one or more articles. When a table is published, a CREATE TABLE script is created for that table. For non- SQL Server Subscribers, the script is created in the Transact-SQL dialect, and it is then translated to a more generic SQL dialect by the Distribution Agent before being applied at the Subscriber. To specify a custom creation script, either modify the existing Transact-SQL script or create a complete script that uses the DB2 SQL dialect; if a DB2 script is created, use the bypass_translation directive so that the Distribution Agent will apply the script at the Subscriber without translation. Scripts can be modified for a number of reasons, but the most common reason is to alter data type mappings. For more information, see the "Data Type Mapping Considerations" section in this topic. If you modify the Transact-SQL script, changes should be restricted to data type mapping changes (and the script should not contain any comments). If more substantial changes are required, create a DB2 script. To modify an article script and supply it as a custom creation script a. After the snapshot has been generated for the publication, navigate to the snapshot folder for the publication. b. Locate the .sch file with the same name as the article, such as MyArticle.sch . c. Open this file using Notepad or another text editor. d. Modify the file and save it to a different directory. e. Execute sp_changearticle , specifying the file path and name for the creation_script property. For more information, see sp_changearticle (Transact-SQL). To create an article script and supply it as a custom creation script f. Create an article script using the DB2 SQL dialect. Ensure the first line of the file is bypass_translation, with nothing else on the line. g. Execute sp_changearticle, specifying the file path and name for the creation_script property. Considerations for IBM DB2 Subscribers In addition to the considerations covered in the topic Non-SQL Server Subscribers, consider the following issues when replicating to DB2 Subscribers: The data and indexes for each replicated table are assigned to a DB2 tablespace. The page size of a DB2 tablespace controls the maximum number of columns and the maximum row size of the tables belonging to the tablespace. Ensure that the tablespace associated with replicated tables is appropriate based on the number of replicated columns and the maximum row size of the tables. Do not publish tables to DB2 Subscribers using transactional replication if one or more primary key columns in the table is of data type DECIMAL(32-38, 0-38) or NUMERIC(32-38, 0-38). Transactional replication identifies rows using the primary key; this can result in failures because these data types are mapped to VARCHAR(41) at the Subscriber. Tables with primary keys that use these data types can be published using snapshot replication. If you want to pre-create tables at the Subscriber, rather than having replication create them, use the replication support only option. For more information, see Initialize a Transactional Subscription Without a Snapshot. SQL Server allows longer table names and column names than DB2: If the publication database includes tables with names longer than those supported on the DB2 version at the Subscriber, specify an alternative name for the destination_table article property. For more information about setting properties when creating a publication, see Create a Publication and Define an Article. It is not possible to specify alternative column names. You must ensure that published tables do not include column names longer than those supported on the DB2 version at the Subscriber. Mapping Data Types from SQL Server to IBM DB2 The following table shows the data type mappings that are used when data is replicated to a Subscriber running IBM DB2. SQL SERVER DATA TYPE IBM DB2 DATA TYPE bigint DECIMAL(19,0) binary(1-254) CHAR(1-254) FOR BIT DATA binary(255-8000) VARCHAR(255-8000) FOR BIT DATA bit SMALLINT char(1-254) CHAR(1-254) char(255-8000) VARCHAR(255-8000) date DATE datetime TIMESTAMP datetime2(0-7) VARCHAR(27) datetimeoffset(0-7) VARCHAR(34) decimal(1-31, 0-31) DECIMAL(1-31, 0-31) decimal(32-38, 0-38) VARCHAR(41) float(53) DOUBLE float FLOAT geography IMAGE geometry IMAGE hierarchyid IMAGE image VARCHAR(0) FOR BIT DATA* into INT SQL SERVER DATA TYPE IBM DB2 DATA TYPE money DECIMAL(19,4) nchar(1-4000) VARCHAR(1-4000) ntext VARCHAR(0)* numeric(1-31, 0-31) DECIMAL(1-31,0-31) numeric(32-38, 0-38) VARCHAR(41) nvarchar(1-4000) VARCHAR(1-4000) nvarchar(max) VARCHAR(0)* real REAL smalldatetime TIMESTAMP smallint SMALLINT smallmoney DECIMAL(10,4) sql_variant N/A sysname VARCHAR(128) text VARCHAR(0)* time(0-7) VARCHAR(16) timestamp CHAR(8) FOR BIT DATA tinyint SMALLINT uniqueidentifier CHAR(38) varbinary(1-8000) VARCHAR(1-8000) FOR BIT DATA varchar(1-8000) VARCHAR(1-8000) varbinary(max) VARCHAR(0) FOR BIT DATA* varchar(max) VARCHAR(0)* xml VARCHAR(0)* See the next section for more information about mappings to VARCHAR(0). Data Type Mapping Considerations Consider the following data type mapping issues when replicating to DB2 Subscribers: When mapping SQL Server char, varchar, binary and varbinary to DB2 CHAR, VARCHAR, CHAR FOR BIT DATA, and VARCHAR FOR BIT DATA, respectively, replication sets the length of the DB2 data type to be the same as that of the SQL Server type. This allows the generated table to be successfully created at the Subscriber, as long as the DB2 page size constraint is large enough to accommodate the maximum size of the row. Ensure that the login used to access the DB2 database has permissions to access table spaces of a sufficient size for the tables being replicated to DB2. DB2 can support VARCHAR columns as large as 32 kilobytes (KB); therefore it is possible that some SQL Server large object columns can be appropriately mapped to DB2 VARCHAR columns. However, the OLE DB provider that replication uses for DB2 does not support mapping SQL Server large objects to DB2 large objects. For this reason, SQL Server text, varchar(max), ntext, and nvarchar(max) columns are mapped to VARCHAR(0) in the generated create scripts. The length value of 0 must be changed to an appropriate value prior to applying the script to the Subscriber. If the data type length is not changed, DB2 will raise error 604 when the table create is attempted at the DB2 Subscriber (error 604 indicates that the precision or length attribute of a data type is not valid). Based upon your knowledge of the source table that you are replicating, determine whether it is appropriate to map a SQL Server large object to a variable length DB2 item, and specify an appropriate maximum length in a custom creation script. For information about specifying a custom creation script, see step 5 in the section "Configuring an IBM DB2 Subscriber" in this topic. NOTE The specified length for the DB2 type, when combined with other column lengths, cannot exceed the maximum row size based upon the DB2 table space that the table data is assigned to. If there is no appropriate mapping for a large object column, consider using column filtering on the article so that the column is not replicated. For more information, see Filter Published Data. When replicating SQL Server nchar and nvarchar to DB2 CHAR and VARCHAR, replication uses the same length-specifier for the DB2 type as for the SQL Server type. However, the data type length might too small for the generated DB2 table. In some DB2 environments, a SQL Server char data item is not restricted to single-byte characters; the length of a CHAR or VARCHAR item must take this into account. You must also take into account shift in and shift out characters if they are needed. If you are replicating tables with nchar and nvarchar columns, you might need to specify a larger maximum length for the data type in a custom creation script. For information about specifying a custom creation script, see step 5 in the section "Configuring an IBM DB2 Subscriber" in this topic. See Also Non-SQL Server Subscribers Subscribe to Publications Other Non-SQL Server Subscribers 3/24/2017 • 1 min to read • Edit Online For a list of non- SQL Server Subscribers supported by Microsoft, see Non-SQL Server Subscribers. This topic includes information about requirements for ODBC drivers and OLE DB providers. ODBC Driver Requirements The ODBC driver: Must be ODBC level-1 compliant. Must be thread-safe Distributor environment. Must be transaction capable. Must support the Data Definition Language (DDL). Cannot be read-only. Must support long table names such as MSreplication_subscriptions. Replicating Using OLE DB Interfaces OLE DB providers must support these objects for transactional replication: DataSource object Session object Command object Rowset object Error object DataSource Object Interfaces The following interfaces are required to connect to a data source: IDBInitialize IDBCreateSession IDBProperties If the provider supports the IDBInfo interface, Microsoft SQL Server uses the interface to retrieve information such as the quoted identifier character, maximum SQL statement length, and maximum number of characters in table and column names. Session Object Interfaces The following interfaces are required: IDBCreateCommand ITransaction ITransactionLocal IDBSchemaRowset Command Object Interfaces The following interfaces are required: ICommand ICommandProperties ICommandText ICommandPrepare IColumnsInfo IAccessor ICommandWithParameters IAccessor is necessary to create parameter accessors. If the provider supports IColumnRowset, SQL Server uses that interface to determine whether a column is an identity column. Rowset Object Interfaces The following interfaces are required: IRowset IAccessor IColumnsInfo An application should open a rowset on a replicated table that is created in the subscription database. IColumnsInfo and IAccessor are needed to access data in the rowset. Error Object Interfaces Use the following interfaces to manage errors: IErrorRecords IErrorInfo Use ISQLErrorInfo if it is supported by the OLE DB provider. For more information about the OLE DB provider, see the documentation supplied with your OLE DB provider. See Also Non-SQL Server Subscribers