Answered by:
Error 7333 (Cannot fetch a row using a bookmark from OLE DB provider "OraOLEDB.Oracle" for linked server)

Question
-
Hi,
we created a linked server from Windows 2008 / SQL Server 2008 (64 Bit) to Oracle 11G 64 Bit (11.2.0.1.0). The linked server is using the provider "Oracle Provider for OLE DB". The connection test is successful.
There is a job which is executing a stored procedure. When the job is executed the following error appears:
Executed as user: ...\.... PIT_APPLICATIONVERSION [SQLSTATE 01000] (Message 0) Cannot fetch a row using a bookmark from OLE DB provider "OraOLEDB.Oracle" for linked server "...@..." [SQLSTATE 42000] (Error 7333). The step failed.
Is this a known problem ?
Thanks and regards
F. L.
- Moved by Tom PhillipsModerator Wednesday, February 2, 2011 1:46 PM Possiblty better answer from TSQL forum (From:SQL Server Database Engine)
Answers
-
I found several similar posts about this problem. Some peoples are believing that the problem only is appearing on 32 Bit-Versions of this provider.
Funny. The Connect item I found, said explicitly said the issue is with 64-bit.
Is it possible to use a 32 Bit-Version on this 64 Bit - Windows/SQL-Server - System ?
You cannot use a 32-bit provider with 64-bit SQL Server.
Is it also possible to use the already integrated Oracle Provider from Microsoft.
Not really. That provider is very old, and supports only connections to Oracle 8.
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Links for SQL Server Books Online: SQL 2008, SQL 2005 and SQL 2000.
(Just click the link you need.)- Marked as answer by KJian_ Wednesday, February 9, 2011 9:39 AM
All replies
-
Some Googling on the error message lead me to https://connect.microsoft.com/SQLServer/feedback/details/125675/oracle-10-2-ole-db-provider-update-error-linked-server
where Microsoft says that they identified an issue in the Oracle provider, but an earlier version that you are using.In any case, the error message indicates that SQL Server attempts an operation against the Oracle provider, but this operation unexpectedly fails.
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Links for SQL Server Books Online: SQL 2008, SQL 2005 and SQL 2000.
(Just click the link you need.) -
Thanks for your advice Erland.
I found several similar posts about this problem. Some peoples are believing that the problem only is appearing on 32 Bit-Versions of this provider. Is it possible to use a 32 Bit-Version on this 64 Bit - Windows/SQL-Server - System ?
Is it also possible to use the already integrated Oracle Provider from Microsoft. Are there any limitations ?With regards
Florian -
I found several similar posts about this problem. Some peoples are believing that the problem only is appearing on 32 Bit-Versions of this provider.
Funny. The Connect item I found, said explicitly said the issue is with 64-bit.
Is it possible to use a 32 Bit-Version on this 64 Bit - Windows/SQL-Server - System ?
You cannot use a 32-bit provider with 64-bit SQL Server.
Is it also possible to use the already integrated Oracle Provider from Microsoft.
Not really. That provider is very old, and supports only connections to Oracle 8.
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Links for SQL Server Books Online: SQL 2008, SQL 2005 and SQL 2000.
(Just click the link you need.)- Marked as answer by KJian_ Wednesday, February 9, 2011 9:39 AM
-
We had been having this error intermittently for a SQL job that connects to a linked server. The linked server and server running the sql job both are running on SQL server 2016 enterprise edition. The SQL job would complete in 10mins normally. But some reason the job would keep running for more than 5 hours and then fail with error " Cannot fetch a row using a bookmark from OLE DB provider "SQLNCLI11" for linked server [SQLSTATE 42000] (Error 7333). The step failed"
We reached out to Microsoft Support for the issue. They gave us fix to disable TCP Chimney Offload in SQL server from where the SQL job was running and then reboot the server.
TCP Chimney Offload can be enabled or disabled in the following two locations:
1. The operating system
2. The advanced properties page of the network adapter
** TCP Chimney Offload will work only if it is enabled in both locations. By default, TCP Chimney Offload is disabled in both these locations. However, OEM installations may enable TCP Chimney Offload in the operating system, in the network adapter, or in both the operating system and the network adapter. After making the change our job has been running without any issues.
- Edited by sql3112 Wednesday, November 20, 2019 11:10 PM