Tuesday, March 20, 2012

Replication performance Problem with SQL Server -> Oracle9i

We are replicating from SQL server 2000 DB to Oracle 9i database using a 2 Mbps line. When there is a mass update on our DB, the same is replicated to the Oracle 9i side, but apparently the SQl Server sends as many update/delete requests to Oracle as the
number of rows affected on SQL side (17000). The update therefore takes enormous time on the Oracle side and the whole system on Oracle side freezes for hours till all the updates happen and then the single row updates take place in about 30 seconds time.
when we sneak into the execution on the Oracle side, it seems it commits for each of the rows it updates. we use OLEDB provider for Oracle. does this have any link with the Auto-commit settings or due to some other?..
This is normal. Replication breaks down set based operations to singletons
to ensure that data is consistent on both ends - the Publisher and
Subscriber.
You will get better performance using the Microsoft ODBC driver for Oracle
and the Microsoft OLE DB provider for Oracle
If you are using the Oracle OLE DB provider you should be selecting the
Allow InProcess option of your linked server.
"sunny" <anonymous@.discussions.microsoft.com> wrote in message
news:BEC3FC8A-34CB-4760-B145-08C94801FD39@.microsoft.com...
> We are replicating from SQL server 2000 DB to Oracle 9i database using a 2
Mbps line. When there is a mass update on our DB, the same is replicated to
the Oracle 9i side, but apparently the SQl Server sends as many
update/delete requests to Oracle as the number of rows affected on SQL side
(17000). The update therefore takes enormous time on the Oracle side and the
whole system on Oracle side freezes for hours till all the updates happen
and then the single row updates take place in about 30 seconds time. when we
sneak into the execution on the Oracle side, it seems it commits for each of
the rows it updates. we use OLEDB provider for Oracle. does this have any
link with the Auto-commit settings or due to some other?..

No comments:

Post a Comment