SQL Server calling Oracle, Can you hear me?

Leave a comment

This is the last post from my 2010 archives. I’m glad to pop these up on to my blog, if only to be able to reference them quickly if I need to mess around with any of these features. Now I’ve got to get cracking and generate some new content!

This is the 2nd blog posting addressing querying SQL Server from Oracle and vice versa. This post covers the vice versa part, from SQL Server to Oracle.

Assuming that SQL Server is working fine on your windows host, the first step is to install the Oracle client on the SQL Server host. Be sure to choose the Windows components, specifically Oracle OLEDB. That’s critical! Then configure the Oracle networking files appropriately for your target system. By this I mean adjusting the tnsnames.ora file if you are hard coding the Oracle database location, or ensuring that you have the correct LDAP.ORA setting if you use OID to look up Oracle locations. Here are some links for help with the if you have not configured Oracle client network files: 11G R2 docs on adjusting tnsnames using Oracle GUI tools, Ora FAQ on editing tnsnames.ora directly, Ora FAQ on editing ldap.ora directly.

Once the Oracle client is correctly configured, try a quick test with TNSPING from the command line to ensure that Oracle client can find the database with the tnsnames.ora or ldap.ora changes you made.

If things are OK at the Oracle client level, you must now restart SQL Server. This is because the Oracle client install updates the system PATH environment variable. The SQL Server service only checks this at startup time, so it needs a restart to get the updated value of PATH in order to find the Oracle client files.

The rest of this article addresses how to enable SQL queries executing within SQL Server to contact the Oracle database using something called a Linked Server. However, know that frequently people make Oracle data available in SQL Server by means of an SSIS job that queries Oracle and loads data into a table. By making a linked server, any sql session with appropriate permissions will be able to use the linked server.

You can create the linked server in T-SQL like this:

EXEC master.dbo.sp_addlinkedserver @server = 'ORA_LINKED_S', @srvproduct='Any string', @provider='OraOLEDB.Oracle', @datasrc='ORA_SID', @provstr='XXX'

In my testing, for Oracle data sources, it seemed that only the provider argument had to be precise in order to specify the OLEDB Oracle driver and the datasrc argument had to match the Oracle name as indicated in TNSNAMES.ORA or your LDAP server. The other values are descriptive for Oracle sources.

Then you need to provide the Oracle login information:

EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname='ORA_LINKED_S',@useself='False',@locallogin=NULL,@rmtuser='joe_user',@rmtpassword='joe_pwd'

You can also configure a Linked Server via the SQL Server Management Studio GUI. To do that, connect to your instance with Management Studio, then expand the Instance and then the Server Objects icon. Right click on the Linked Servers icon and select New Linked Server choice. This screen will allow you to input the values needed. Choose the Oracle Provider for OLEDB. You also need to provide the username and password for the user connecting to Oracle.

With the linked server in place, you can now query Oracle from within SQL Server.

Here again you have choices.

To query using native T-SQL, use this syntax:


Yes, that’s two dots before the word SCHEMA. In my testing, I had to do all upper case in order for the query to run. It’s possible if the remote Oracle objects were created with mixed case using quotations that you would have to match that case.

The other choice is to do pass through queries, which enable you to use Oracle SQL syntax that gets parsed at the remote Oracle database. You use the OPENQUERY function to do that.

select * from openquery(ORA_LINKED_S, 'select * from table_name where rownum < 10')

Note that in the above example the case was not important, provided the objects were not created with quotation marks and specific case in Oracle. Also, the above uses an Oracle specific syntax: rownum < 10. That rownum clause won't work in native T-SQL.

Here's a gotcha that we encountered in my shop when having 64-bit SQL Server 2008 running on 64-bit windows and running SSIS jobs that connected to a remote Oracle database. The solution to getting everything working was to install both 32 and 64 bit Oracle clients on the same machine. See this write up from sqlblogcasts.com for more details.

Oracle calling SQL Server, do you read me?

Leave a comment

Also from 2010 archives: two posts on hetergenous queries using SQL Server and Oracle. I’d hoped to do a 3rd on general issues that arise when keeping data in a remote system, but haven’t produced it yet…

Querying SQL Server from within Oracle and vice-versa is a messy little corner of the database world. . This post will address the setup needed to query SQL Server from Oracle. The next will approach querying Oracle from SQL Server.

Notes on configuring an Oracle database to query a remote SQL Server database follow. For more detailed information, see the Hetergeneous Connectivity section of the Oracle database documentation. It’s important to know that you can either use the ODBC support that comes with the basic Oracle database license for connecting to 3rd party databases. Or you can pay extra for a specific gateway tailored for your target 3rd party database. The Oracle Database Gateway for ODBC User’s guide, discusses specifics about exactly what support is provided with the default no extra cost gateway. This article discusses the no extra cost ODBC gateway.

Note that the no extra cost option that ships with 11G is called DG4ODBC (database gateway for ODBC). It replaces the HSODBC (heterogeneous services ODBC) program that shipped with 10G and earlier. Also note that I was unable to get DG4ODBC working with Oracle DB release on Windows. When I upgraded to, DG4ODBC worked fine.

Connecting to SQL Server from an Oracle database is easier when the Oracle system runs on Windows. That’s because SQL Server client software must be installed on the Oracle host, as well as an ODBC driver for SQL Server. Installing both is straightforward on Windows. Simply install SQL Server client using the file sqlncli.msi, or run the SQL Server database installer and just select the SQL client choices. Doing either takes care of both the native connectivity and the ODBC driver. On unix you will either have to purchase a commercial ODBC driver for SQL Server which comes bundled with the native connectivity like Data Direct or use some of the open source offerings such as Free TDS for the native connectivity and Unix ODBC for the odbc layer.

After you put the SQL Server connectivity software in place, you then need to create an ODBC data source to your remote SQL Server. On windows, this is done via Control Panel – Administrator Tools – Data Sources (ODBC). On unix, you will be configuring text files specific to the odbc driver software you have installed.

At this point, you can verify if connectivity from your host to SQL Server is working without using Oracle. For example on Windows, click the Test Data Source button within the ODBC DSN set up screen. And on unix, there likely will be a command line utility with which you can test connectivity.

With connectivity in place, the next steps are about describing to Oracle your ODBC data source. These steps will be the same on unix and windows since they take place at the Oracle level.

The first part of describing to Oracle your ODBC source is specifying a database gateway. As stated above, we will illustrate using the no extra cost ODBC gateway. You create an initDG4ODBC.ora file that gets put in the $ORACLE_HOME/hs/admin directory. You’ll need these 3 parameters at a minimum:

# Substitute MYDATASOURCE with whatever you called the SQL Server in your ODBC entry.

There is another step to telling Oracle about your remote SQL Server. You must create an entry in the listener.ora file. It will reference the initDG4ODBC.ora file. The program name will be DG4ODBC.

(ORACLE_HOME = C:\oracle\product\11.1.0\db_1)

Once you’ve installed SQL Server client, ODBC driver and configured the $ORACLE_HOME/hs/network\initDG4ODBC.ora and listener.ora files, you are ready to create a database link that connects to the remote SQL Server. This link can then be referenced by SQL statements to get data.


Querying against this link immediately creates case-sensitivity issues. SQL Server will need the correct case for the fields and tables that you query. For example the query below generates an error.

SQL> select name from sysobjects@MYDATASOURCE;
select name from sysobjects@MYDATASOURCE
ERROR at line 1:
ORA-00904: "NAME": invalid identifier

But this gets the case correct:

select "name" from sysobjects

You can use Oracle SQL functionality provided the DGODBC can convert it successfully.

For example, this will work:

SQL> select column_name from all_tab_columns@MYDATASOURCE where table_name = 'TBLSTATS';

Oracle has mapped its data dictionary view to the native SQL Server one.

You can also send SQL statements directly to the remote SQL Server without having them checked in Oracle first using the DBMS_HS_PASSTHROUGH pl/sql API. This means your syntax can be in SQL Server T-SQL syntax. You can execute a subset of DDL statements with the DBMS_HS_PASSTHROUGH.EXECUTE_IMMEDIATE command.