By Hope Foley, SQL Server DBA, Perpetual Technologies, Inc
By Hope Foley, SQL Server DBA, Perpetual Technologies, Inc
By Hope Foley, SQL Server DBA, Perpetual Technologies, Inc
BFF (Best Friends Forever)? Not quite. More like two kids on the DBMS playground
that would just as soon throw spitballs at each other as play nice together.
However, with the release of SQL Server 2005, it has become easier than ever to
coexist with rival Oracle.
In this article, I provide an overview of some of the new and old ways to
successfully exchange data between Oracle and SQL Server 2005 instances. The
sharing of data between the two is becoming a very widely desired process, in part
due to the licensing of the reporting tool for SQL Server. SQL Server Reporting
Services (SSRS) is a free component with a valid license of SQL Server (although
you must have per-processor licensing to use Internet reporting). In many cases,
data is ported over solely to run reports. Some simply need to retrieve data that is
partially in SQL and partially in Oracle. Whatever the reason, with more and more
database shops containing both products, the need is greater than ever to share
data between the two unlikely playmates.
There are three common ways to get data from Oracle into SQL Server:
1. SQL Server Integration Services (SSIS) – pump data from Oracle into SQL
Server databases
3. Linked server – run queries directly from SQL Server to Oracle databases
after linking
SSIS is a data integration tool that also is included free with a license of SQL Server
(except for the Express version). It is the replacement for what was previously
referred to as Data Transformation Services (DTS). Essentially, SSIS is a very
powerful enterprise-class extract, transform and load (ETL) tool. It allows you to
move data from Oracle or other sources into SQL Server in a few simple steps,
although additional steps can be added to cleanse the data in countless ways prior
to loading it into SQL Server. The Oracle client is a prerequisite installation on the
server you are going to import the data into or the location where you will be
running your SSIS package. In addition, a valid userid/password for the Oracle
database is required. You are now ready to begin setting up your SSIS package.
2. Move a data flow task into the control flow design pane. Double-click on this
task and it will bring you into the data flow pane. Here you will create the
tasks to move your Oracle data.
3. Move an OLE DB source task into the design pane. Double-click it and
configure a connection to your Oracle database (Figure 1). You will supply
either the table or view you want to copy or you can supply a SQL command
to pull portions of the data. You can then add any cleansing tasks needed to
the data or directly copy it into SQL Server. The only thing needed now is a
destination for your data. You can put it in numerous formats or into a SQL
Server database.
4. Move an OLE DB Destination task into the pane, connect the source task to
the destination task, and then configure the destination. You now have an
SSIS package to copy data from Oracle (see Figure 2). It can be deployed
and scheduled to run at regular intervals in an SQL Agent job.
Figure 2. What the SSIS package will look like from Data Flow pane.
Replication
Replication has been in place within SQL Server since version 6.0. New in SQL
Server 2005 is the ability to set up an Oracle publisher (with Oracle versions 8.0.5
and higher). Replication, in a nutshell, is a method to copy data and objects
between servers and keep them synchronized. A media metaphor is used: first, the
data and objects to be copied are contained in an article. A publication can then
contain one or more articles. Next, there is a subscriber, which is an instance of
SQL Server that can access that publication. The subscriber requests the publication
through a subscription. Finally, there is also a distributor, which handles the
passing of the subscription from the publisher to the subscribers.
There are three types of replication that can occur in SQL Server: merge,
transactional, and snapshot. Merge replication allows for updates to occur at the
subscribers and publisher; the data is then synchronized between all. This can
create conflicts but there are numerous methods to handle those conflicts.
Transactional replication only allows for changes at the publisher. The incremental
changes are then propagated down to the subscribers in near real time. Snapshot
replication copies all data from the publication to the subscribers at specified
intervals and does not monitor changes. Snapshot works well only when needing to
copy small amounts of data infrequently and when high latency is not an issue.
Replicating with an Oracle database only allows for snapshot and transactional
replication.
Here are the steps to set up an Oracle publisher in SQL Server:
1. Ensure that you have a separate distributor set up to aid in the replication.
3. Grant select permissions to the replication admin user implicitly (i.e., not
through a role).
4. Install the latest Oracle client on the distributor, stop/start the SQL instance,
and verify connectivity.
Linked servers
Linked servers are a third method to access Oracle information with SQL Server.
Once linked servers are set up, you have the ability to run distributed queries
against Oracle via SQL Server. To use this method, an Oracle client must be
installed on your SQL Server machine and a valid Oracle user/password is needed.
Setting up the linked server is simple; simply run the following command:
EXEC sp_addlinkedserver
@server = 'Name of Linked server’,
@srvproduct = 'Oracle',
@provider = 'MSDAORA',
@datasrc = 'Data Source Name'
GO
Then you must add the login for the linked server:
EXEC sp_addlinkedsrvlogin
@rmtsrvname = 'Name of Linked Server',
@useself = 'false',
@locallogin = 'Local SQL login',
@rmtuser = 'Oracle User',
@rmtpassword = 'Oracle Password'
You then can query the Oracle database using full syntax. For example:
While Oracle and SQL Server may never be BFF, you can use these methods to
access Oracle data from within SQL Server. Your data comes together, your
customers are happy, and the world is a better place. And besides, if these two old
rivals did become best friends, what would Oracle and SQL Server DBAs have to
argue about?