Download Troubleshooting Oracle Publishers

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