In this article, well
continue on with the setup of Oracle as a data source for SQL Server. As
mentioned in Part
1, one of the requirements on the MSSQL side is that the version be of the Enterprise
or Developer editions. One major plus of Oracle over Microsoft is that Oracle
software has no expiration date, whereas the trial software from Microsoft has
a shelf-life of 180 days. One obstacle, which may be insurmountable (if doing
this on a personal computer), is meeting the system requirements for the
Enterprise Edition of MSSQL. The specific showstopper is the operating system
requirement, which is server class (2003 or 2008) across the board.
The simple workaround to
this requirement is to use Developer Edition,
which is equivalent to Enterprise Edition in almost every way. Developer Edition
is not free (it was for a while) and it is not available via download (it was
for a while). The bottom line is you have to order this edition and have it
shipped to you. The good news is that the cost is fairly low, and with a little
shopping around, you can find it online for less than what Microsoft lists it
($49.95 there versus $40.99 at Amazon).
The installation process for Developer Edition (as it is for all 2008 versions) involves quite a few more
Next clicks from the user (person installing), and it does seem to take a bit
longer than MSSQL 2005 installations. The end result should have the results as
seen in the screenshot below.
Another setup step is to
attach (within MSSQL) a pre-configured sample database. While youre at it, do
two: the normal AdventureWorks database and its BI or DW version (named AdventureWorksDW).
The installation files for the databases are located at an open
source site, and the 2005 version of the files work just fine with 2008.
The downloaded msi files dont actually install the databases, but what they do
is to place the main database and log files in a Data directory under your SQL
Server installation folder. Once the mdf and ldf files are staged, use SQL
Server Management Studio to attach the files. Pick a database file and MSSQL
figures out the rest for you. At the end, you should see the databases as such:
Now that everything is up
and running in MSSQL-land, youre ready to Create a
Publication from an Oracle Database.
Before going on with the
steps provided by Microsoft, it is worthwhile to create a linked server (a
database link in Oracle terms) to the Oracle database of interest. More than
likely, your setup is going to consist of an installation of Oracle and SQL
Server on the same computer/PC/notebook. We assume your Oracle installation is
squared away (i.e., you can SQL*Plus your way into the database and connect as
Scott or some other schema). What we dont know yet is if your MSSQL to Oracle
connection will work.
In a new query window in SQL
Server Management Studio (SSMS), run the following commands, replacing items as
shown via the comments. The two procedures can also be executed via the SSMS
interface, but what to use in some of the fields is a bit cryptic, so having a
T-SQL example to start with is useful (plus then you can go back into the
properties and see what was filled in where).
EXEC sp_addlinkedserver --name of the built-in stored proc
'OracleLinkedServer', --name of my linked server
'Oracle', --use Oracle here
'MSDAORA', --use this data source identifier
'ORCL' --ORCL is the name of my database
EXEC sp_addlinkedsrvlogin --name of the built-in stored proc
'OracleLinkedServer ', --same name from sp_addlinkedserver
false, --leave as false
'T42\Steve', --your server\user, or leave null
'Scott', --target schema in Oracle
'Tiger' --password of the schema/user
--now ready to test the connection via a select statement
SELECT * FROM
Your results should look
similar to what is shown below (minus changes Ive made in my version of the
Without getting too far into
other SQL Server database administration tasks, you may want to take backups of
the master and msdb databases. If you have problems at the end of the creation
process, removing linked servers (one related to publication, the other related
to distribution) requires some additional steps, and MSSQL forums are rife with
users complaining about not being able to drop a linked server. With the
backups of the two system databases, you will have an easier go of it in terms
of being able to start over.
In the set of steps shown in
Part 1 (repeated
below from MSDN) ...
· Create a
replication administrative user within the Oracle database using the supplied
· 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.
· 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.
· Configure the
Oracle database as a Publisher at the SQL Server Distributor.
...the last step results in
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
[creating the linked server].
In this example, with ORCL
as the name of my Oracle database (and is the publication source), I can expect
to see a linked server named ORCL when the setup is finished.
You have two options as to
how to configure an Oracle publisher: use SQL Server
Management Studio, or use Transact-SQL.
The T-SQL reference is fairly useless, so we will use the GUI interface (SSMS).
The next two major steps are to identify the Oracle publisher at the SQL Server
distributor, and create the publication from the Oracle database.
The distributor is nothing
more than a database within the SQL Server instance where were going to have
the replication data from Oracle published into. This process creates a
distribution database, named interestingly enough as distribution. The name
of this database can be changed later. The role of the distributor is to manage
the replication agents.
In the list of instructions
on how to identify the Oracle Publisher at the SQL Server Distributor, there is
no Distributor Properties option available after right-clicking the
Replication folder. What we do know, however, is that we want to configure a
distributor, create an Oracle publisher, and then create a publication from
Oracle (where we pick the articles or tables we want to subscribe to).
Right click Replication and
click Configure Distribution. Click Next on the Configure Distribution Wizard
Well use the same instance as the distribution repository, so click Next.
At the next window, have the
wizard configure the SQL Server Agent to start automatically. More than likely,
this will be the case anyway after a default or typical installation, but if
the agent is not set to start, then the running of scheduled snapshots (the
idea of scheduled refreshes in materialized views covered in Part 1) will not
The snapshot folder is
analogous to a materialized view log; in this example, the default location
will suffice, but for permanent or larger implementations, you may want to use
a different drive.
Use the default name of
distribution for the distribution database, and use the default locations for
the data and transaction log files (again with the caveat of placing these
files in better locations for a real world implementation).
Click Next on the Publishers
window (not shown), and then at the Configure Distribution window, select the
checkbox if you want a script created in addition to having the setup
If you elect to generate a
script, another window will appear (not shown) with the location and name of
the file (and you can choose the format of the file). Finally, we reach a
summary page, and click Finish to configure the distributor.
Hopefully, youll see the
same success window as shown below.
Upon completion of the
configuration, the right-click menu items on Replication will be different, and
from here, we can now follow the steps in the How to reference from MSDN. The
first step is to Add Oracle Publisher. From the properties option and selecting
the Publishers page, we get to the picture below.
Expand the Options on the
Connect to Server dialog, and fill in your information (example here is the
ORCL database with the MSSQLDIST user mentioned in Part 1).
In Connection Properties, we have a choice between Gateway and Complete as to the publisher type. You can
read about the differences in the MSDN note, but for now, stay with Complete.
From here, click Connect. If
no errors appear, the properties page is in focus and you will see ORCL (the
server can be a publisher within MSSQL, so thats why you see two entries).
Click OK to dismiss the
properties window. The process executes (shouldnt take more than a minute) and
you are returned to SMSS. The next (and last) major step is to create a
publication from Oracle.
Create a publication from Oracle
Weve already granted SELECT
on the tables of interest to our MSSQLDIST replication user, and in this step,
we actually select the table(s) to be replicated. For simplicitys sake, only
the EMP table (all columns, and no filters applied) will be used.
Continuing with the steps in
the MSDN guide, go through the start page, select the ORCL publisher, and then
decide between snapshot and transactional publication.
In this example, I selected
transactional (screenshot shows Snapshot, which is the default), and you will
have an option later to schedule this as well. In the Articles window, find the
EMP table owned by SCOTT, and expand the selection to see the columns. Note the
warning about the datatype conversion of the Oracle DATE field.
If you want, you can
de-select the HIREDATE column to make this demo as clean as possible. I am not
using any filtering, so Next is clicked in the subsequent window.
In checking the status of
the SQL Server Agent, mine is set to start automatically, and I ensured it has
administrator permissions by having created an MSSQL account and added it to
the Administrators built-in group. In my setup, I selected both options
(create a snapshot now, and then do it every hour on the hour).
In the next window, we have
to configure some security settings (not shown), and if you use a generic
MSSQL account with admin privileges, everything will work. On the other hand,
you can also elect to run this under the Agents settings, so either way, youre
In Security Settings, I used
the Agent, and upon return to the Agent Security window, the other agent fields
are now populated.
In the next window (Wizard
Actions, not shown), create the publication and optionally generate the script.
Finally, enter a name for the publication in the summary window, and click
If all goes will, you will
see the same success window shown below (with the exception of a generated
script if you didnt select that option).
In the last part of this
series, well take a look at the aftermath (in a good sense of the word) of all
See All Articles by Columnist Steve Callan