Easy Workaround for Oracle Linked Server Problem with TIMESTAMP(6) Column

I've got a lot of SQL servers at work. And those servers link to a lot of other servers. MySQL, Oracle, SQL 2005, 2008, etc.
For the most part linked servers are frowned on from my perspective but I can't keep people from getting things done so they do get setup. Most of the time the four part naming convention works just fine although MySQL in particular seems to need OPENQUERY Oracle never has... until today.

For some reason running a query against an 11g R1 Oracle DB kept returning this:
Msg 7354, Level 16, State 1, Line 1557
The OLE DB provider "OraOLEDB.Oracle" for linked server "XYZSERVER01" supplied invalid metadata for column "CREATEDDATE". The data type is not supported.

The column type in Oracle was timestamp(6) and no matter of cast or convert would avoid the problem. Selecting without the offending column still produced the error. I was about to start looking for newer OraOLEDB drivers when I thought about the MySQL issue. I also did a little checking and found this KB:
SELECT
*
FROM OPENQUERY(XYZSERVER, 'SELECT COUNT(foobar) FROM XYZSCHEMA.XYZTABLE')

Worked great; problem solved :)

I'm also going to pose the solution to the forum post below as it seems to be related...
http://social.msdn.microsoft.com/Forums/en/transactsql/thread/fd1cb0c8-efb5-4a94-b00d-b2aeb91dd771

MS DTC Problems With Oracle Linked Server & Windows 2008 x64 R2 Cluster (Server: Msg 7391, Level 16, State 1)

If you are getting this error (Server: Msg 7391, Level 16, State 1) trying to run a transaction using a linked Oracle server then I may have the fix you're looking for. I had to troubleshoot a problem with a new Windows 2008 Enterprise R2 x64 cluster today that was a real pain.

To get things ready normally you need to at least do the following:

• install the Oracle drivers & reboot
• set "allow in process" on the provider in SQL
• ensure the default DTC is the clustered resource
• enabled DTC for network access and set correct authentication.

Normally things would work at this point. No such luck today though! No matter what I did I couldn't get a specific stored procedure a user wrote to without firing off the "unable to enlist" error. Other DTC transactions worked just fine.

The solution was simple (but tricky for non-Oracle DBAs); I had to install the "Oracle Services for Microsoft Transaction Server 11.1.0.7.0" service and reboot.
Now, I *could* have re-written the query but since it was already working on another QA box and the user is going to be re-working the whole solution shortly I didn't see much point. Plus I wanted to know HOW or IF it could be made to work on this cluster! ;)

Hope this helps someone else out there!
-A