May 5, 2011

Cannot create an instance of OLE DB provider “OraOLEDB.Oracle” for linked server

Filed under: SQL Server, Troubleshooting — fullparam @ 3:20 am

You know you’re dealing with something annoying when Google suggestions cannot wait to auto complete your error message!
Yet this is how I spent a good three hours of my life on earth, just chasing forums & blog posts, even translating a Russian one into English.
I needed that Oracle data, dammit. Sufficient to say that none of the suggestions worked, I kept receiving “Cannot create an instance of OLE DB provider “OraOLEDB.Oracle” for linked server”

Ok, lets go back to the start and list the environment.
Using my local SQL Server 2008 Express R2 on my Win7 x64 workstation, I had to query a Oracle g10 Database on one of my VMWare box.
Yes, you could use the MSDAORA provider by Microsoft for Oracle DBs, but this provider is deprecating and does not exist in x64 flavor.

It all started when i downloaded the ODAC pack for Oracle g10 (ODAC10203x64.zip). This fails to install: Java(TM) 2 Platform Standard Edition binary has stopped working
At least there are a few confirmations that it’s save to use the OLEDB Oracle g11 driver, which uses an “Xcopy” deployment. So I download ODAC112030Xcopy_x64.zip and extract it. Grab an oracle login here via bugmenot. As of Sep 2012, this is still the latest version.
Fair enough, it contains clear instructions and installs easily. I get the provider in the list of providers on my SQL server management studio – Awesome, i thought I was done!

Not so, not by a longshot, now the pain was just starting! First I went into the properties of the provider set the AllowInProcess to enabled.
Now attempting to link the server failed with the error message that I have decided to best be the title of this post. Now this post is not going to list all the possible causes there are, hell I never really want to touch this subject again after today, but I want to “broadcast” the thing that made it ultimately work for me.

Let me just say that I’ve attempted each suggestion that I found sensible, those that I think everyone else that has this issue should repeat are as below:
1.) Set NTFS permission to the install directly to Authenticated Users with Read/Execute.
2.) Enable AllowInProcess for the Provider as outlined above.
3.) Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC\MTxOCI and remove the three values there (create a backup export if you are so inclined). This step I am the least certain about, however why would you want to reference these 3 completely outdated dll’s in the registry?)
4.) Create the Sub folder NETWORK\ADMIN in your install directory and copy a working tnsnames.ora into it(Maybe from another machine that has the full feature Oracle SQL Developer installed)

Nothing helped – so what does one do at such a point? Unleash the furry of Procmon.exe!
This tool from Sysinternals/Mark Russinovich is the best, and my only regret that day was not launching it earlier instead of scouring Google and going insane.
I’ve limited Procmon to just sqlservr.exe, as it’s the SQL Service itself that loads/handles the providers and not the ssms.exe. Also of note is that the sqlservr.exe is a 64bit process while the management studio is still just 32bit. As the server service is loading the provider, and the service process is 64bit, the provider must also be available in 64 bit format.

The ODAC112021Xcopy_x64.zip was installed to C:\Oracle.
What Procmon showed me however is that sqlservr is attempting to find the oci.dll in any folder but his! (It iterates through the %Path% sysvariable). When it finally gives up on find the dll, the SQL Service is in a unstable shape and the only way to stop the service was to kill it via taskmgr/procexp.
Clearly I can see that the “xcopy” deployment – while not giving me any error messages – it also did not set the PATH variable!
And this is what this post is really about… adding C:\Oracle and C:\Oracle\Bin to the Path variable or maybe it’s about
employing investigative tools earlier in the process instead of relying on your search engine skills.

sqlservr.exe can now find the relevant DLL’s. The OCI.DLL in the root and the OraOLEDB11.DLL in the Bin subfolder.
At this point I could query the database! If you did my steps as above and you still get the same error, I strongly suggest using Procmon.exe as I have instead of jumping to the next search result.

I’ve left out the part where it initially could not find the tnsnames.ora file and it attempted to connect via the default oracle port instead of the custom one, and as an additional note if sqlservr cannot locate the tnsnames.ora in the first attempt, it’s not going to retry again until you restart the SQL service. I was actually surprised to even see the port connection attempt in procmon, it seems this tool just keeps getting better.

So this is what I’ve done on my “Day off” from work…. I hope you were reading this while at work yourself and can get back to the real work & fun stuff, writing queries!



  1. Sounds like my issue exactly. Only, where do I set this “path’ variable?

    Comment by Eric — October 7, 2011 @ 2:35 pm

  2. Awesome! Adding C:\Oracle and C:\Oracle\Bin to the Path variable is the fix to my issue. Thank you for sharing.

    Comment by Joan — December 15, 2011 @ 8:33 pm

  3. This line was very helpful ….
    it’s not going to retry again until you restart the SQL service.
    can you plesae elaborate on this line below ?
    I was actually surprised to even see the port connection attempt in procmon, it seems this tool just keeps getting better.

    Comment by DVP Rao — October 16, 2012 @ 2:11 am

    • Well, procmon is a tool to monitor processes, which files and registry they access. It seems in the later versions they also show when they connect to network ports. Meaning you can almost just use this tool instead of a also having to run a traffic sniffer.

      Comment by fullparam — October 16, 2012 @ 4:10 pm

  4. Thanks for sharing, this helped me a lot in the exact same situation.

    Comment by gurba — January 16, 2013 @ 9:03 am

  5. Thank you, thank you, thank you!!! This was the line:
    “and as an additional note if sqlservr cannot locate the tnsnames.ora in the first attempt, it’s not going to retry again until you restart the SQL service”

    Comment by Jeff — August 29, 2013 @ 4:25 am

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: