Hello,
I have a replication error related to the schema script of a procedure that
is
not longer on the list of articles to replicate from the publisher and also
it is
not part of the replicated store procedures in the replicas.
I someone has an idea what could it be the problem. Please let me know.
Thanks,
Car.
What is the error message you are getting.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Car" <Car@.discussions.microsoft.com> wrote in message
news:ECA4299C-6D87-4F2B-B4C5-93039FCC0165@.microsoft.com...
> Hello,
> I have a replication error related to the schema script of a procedure
> that
> is
> not longer on the list of articles to replicate from the publisher and
> also
> it is
> not part of the replicated store procedures in the replicas.
> I someone has an idea what could it be the problem. Please let me know.
> Thanks,
> Car.
|||I delete the subscriptions and recreate them and I don't have any more this
message It was something like comErrorException(0x80004005). However when I
delete an article from the publisher. It does not work. it is not letting me
to do the schema changes I used to do before.
"Hilary Cotter" wrote:
> What is the error message you are getting.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Car" <Car@.discussions.microsoft.com> wrote in message
> news:ECA4299C-6D87-4F2B-B4C5-93039FCC0165@.microsoft.com...
>
>
Showing posts with label related. Show all posts
Showing posts with label related. Show all posts
Friday, March 30, 2012
Monday, March 26, 2012
Replication enhancement in Yukon
Hi ,
Some info is required related to the same .
Any article please .
Thanks
ARR
Have a look here. This is where you can find a lot of 2005 related
information.
http://www.microsoft.com/sql/2005/default.asp
Andrew J. Kelly SQL MVP
"Aju" <ajuonline@.yahoo.com> wrote in message
news:O5D0lE4BFHA.3504@.TK2MSFTNGP12.phx.gbl...
> Hi ,
> Some info is required related to the same .
> Any article please .
>
> Thanks
> ARR
>
Some info is required related to the same .
Any article please .
Thanks
ARR
Have a look here. This is where you can find a lot of 2005 related
information.
http://www.microsoft.com/sql/2005/default.asp
Andrew J. Kelly SQL MVP
"Aju" <ajuonline@.yahoo.com> wrote in message
news:O5D0lE4BFHA.3504@.TK2MSFTNGP12.phx.gbl...
> Hi ,
> Some info is required related to the same .
> Any article please .
>
> Thanks
> ARR
>
Replication enhancement in Yukon
Hi ,
Some info is required related to the same .
Any article please .
Thanks
ARRHave a look here. This is where you can find a lot of 2005 related
information.
http://www.microsoft.com/sql/2005/default.asp
Andrew J. Kelly SQL MVP
"Aju" <ajuonline@.yahoo.com> wrote in message
news:O5D0lE4BFHA.3504@.TK2MSFTNGP12.phx.gbl...
> Hi ,
> Some info is required related to the same .
> Any article please .
>
> Thanks
> ARR
>
Some info is required related to the same .
Any article please .
Thanks
ARRHave a look here. This is where you can find a lot of 2005 related
information.
http://www.microsoft.com/sql/2005/default.asp
Andrew J. Kelly SQL MVP
"Aju" <ajuonline@.yahoo.com> wrote in message
news:O5D0lE4BFHA.3504@.TK2MSFTNGP12.phx.gbl...
> Hi ,
> Some info is required related to the same .
> Any article please .
>
> Thanks
> ARR
>
Replication enhancement in Yukon
Hi ,
Some info is required related to the same .
Any article please .
Thanks
ARRHave a look here. This is where you can find a lot of 2005 related
information.
http://www.microsoft.com/sql/2005/default.asp
--
Andrew J. Kelly SQL MVP
"Aju" <ajuonline@.yahoo.com> wrote in message
news:O5D0lE4BFHA.3504@.TK2MSFTNGP12.phx.gbl...
> Hi ,
> Some info is required related to the same .
> Any article please .
>
> Thanks
> ARR
>sql
Some info is required related to the same .
Any article please .
Thanks
ARRHave a look here. This is where you can find a lot of 2005 related
information.
http://www.microsoft.com/sql/2005/default.asp
--
Andrew J. Kelly SQL MVP
"Aju" <ajuonline@.yahoo.com> wrote in message
news:O5D0lE4BFHA.3504@.TK2MSFTNGP12.phx.gbl...
> Hi ,
> Some info is required related to the same .
> Any article please .
>
> Thanks
> ARR
>sql
Replication Design, Comments?
Ok, I think I have a working solution. I've worked the past
few days finding a lot of issues (not replication related) which
caused my headaches with replication, ie the @.@.servername was
null, and when creating a stored procedure snapshot it
would complain about unqualified inserts. Learned a neat
trick from Paul on how to do verbose logging. The developers
are looking at their stored procedures.
Merge Replication will be used.
I found that they had used identity columns as primary Key values.
Changed the columns to be 'not for replication'.
Tommorow I will be finding out if they have any DRI (Foreign Key
constraints that need to be marked 'not for replication'.
So far, I've created a Merge publication for the data, and it
appears to be functional.
I have also setup a snapshot publication for the stored procedures.
In addition to having the unqualifed insert issue I made the
mistake of checking 'all sp' instead of just selecting the
stored procedures they created (i was adding the replication
added routines by mistake).
If down the road they change a stored procedure, can I just
reinitialize this subscription to get the up-to-date routines?
I am replicating these because the standby server will be
the live server in case of the primary going offline.
I set the schedule on this subscription(sp) to only run
on demand.
Both machines are on the same backbone, so Bandwidth isn't
an issue.
Since I just found out about the possbible Foreign Key
issue (already created a snapshot, but not the subscription)
I am assuming that I will need to re-do the publication once
the foreign key constraints are marked 'not for replication'?
Thanks for the help. It has been an educational week.
Dave
You will have to drop the pub in order to change it to "not for replication"
(at least if using EM).
"David Gresham" <gresham@.panix.com> wrote in message
news:d5ruoa$6ms$1@.reader1.panix.com...
.....
> Since I just found out about the possbible Foreign Key
> issue (already created a snapshot, but not the subscription)
> I am assuming that I will need to re-do the publication once
> the foreign key constraints are marked 'not for replication'?
|||David,
on the changes to stored procedure point, I'd recommend using transactional
replication, which'll then give you the posibility of using sp_addscriptexec
for a change to a specific SP - and will avoid the need to reinitialize all
procedures.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
few days finding a lot of issues (not replication related) which
caused my headaches with replication, ie the @.@.servername was
null, and when creating a stored procedure snapshot it
would complain about unqualified inserts. Learned a neat
trick from Paul on how to do verbose logging. The developers
are looking at their stored procedures.
Merge Replication will be used.
I found that they had used identity columns as primary Key values.
Changed the columns to be 'not for replication'.
Tommorow I will be finding out if they have any DRI (Foreign Key
constraints that need to be marked 'not for replication'.
So far, I've created a Merge publication for the data, and it
appears to be functional.
I have also setup a snapshot publication for the stored procedures.
In addition to having the unqualifed insert issue I made the
mistake of checking 'all sp' instead of just selecting the
stored procedures they created (i was adding the replication
added routines by mistake).
If down the road they change a stored procedure, can I just
reinitialize this subscription to get the up-to-date routines?
I am replicating these because the standby server will be
the live server in case of the primary going offline.
I set the schedule on this subscription(sp) to only run
on demand.
Both machines are on the same backbone, so Bandwidth isn't
an issue.
Since I just found out about the possbible Foreign Key
issue (already created a snapshot, but not the subscription)
I am assuming that I will need to re-do the publication once
the foreign key constraints are marked 'not for replication'?
Thanks for the help. It has been an educational week.
Dave
You will have to drop the pub in order to change it to "not for replication"
(at least if using EM).
"David Gresham" <gresham@.panix.com> wrote in message
news:d5ruoa$6ms$1@.reader1.panix.com...
.....
> Since I just found out about the possbible Foreign Key
> issue (already created a snapshot, but not the subscription)
> I am assuming that I will need to re-do the publication once
> the foreign key constraints are marked 'not for replication'?
|||David,
on the changes to stored procedure point, I'd recommend using transactional
replication, which'll then give you the posibility of using sp_addscriptexec
for a change to a specific SP - and will avoid the need to reinitialize all
procedures.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
Friday, March 23, 2012
Replication Cleanup in high volume database
We're having intermittent performance problems on a SQL 2005 SP1 system that
we suspect is related to transactional replication. There may be overlap
with Jack Griffith's thread "Replication system disk performance severly
degrades after 1 month", but I'm not sure.....
While troubleshooting the problem, we attempted to make things better by
clearing out any transactions that had already been replicated to the
subscriber (EXEC dbo.sp_MSdistribution_cleanup @.min_distretention = 0,
@.max_distretention = 0). BAD, BAD, BAD!!!!! Setting @.max_distretention = 0
marked our subscription as inactive and we had to rebuild the subscriber
database to get it back in sync with the publisher.
I estimate add/update 2-4 million rows a day in our publication database.
The distribution database has grown to 9GB in < a week.
I have not altered any of the database cleanup jobs as of yet. The current
Distribution Cleanup job runs every 10 min and is taking 6-15 minutes to run.
We observe a tremendous number of disk reads on the Distribution database
disks. When we experience performance issues, we also see a HUGE number of
memory pages lasting ~ 15 seconds and occuring exactly every 2 minutes.
Restarting the SQLServer service seems to clear up the performance issues for
several hours.
* msrepl_commands rowcount approaches 35 million rows and
msrepl_transactions approaches 6 million rows. With a high volume in
transactional replication, should there be any indexes on the tables?
* While tracing through the MS SPs, I found that sp_MSdelete_dodelete only
deletes the top 5000 rows from MSrepl_transactions. In a high volume
transactional state, this might not keep up. Can this be changed safely?
* What other parameters can be changed to keep the transactions only as long
as they are needed but yet not mark the subscription as inactive?
Thanks!
If you have a few subscribers use raid 10, if you have a large number use
raid 5.
Set max_distretention to 3 days. This will only pool undistributed commands
for up to 3 days.
the setting for only deleting 5000 rows at a time is by design. If you
choose to modify it to something higher make sure you make the modification
to the end of
sp_MSdelete_publisherdb_trans as well.
The appropriate indexes are in place on msrepl_commands and
msrepl_transactions. You might want to defrag these indexes to see if that
helps or update statistics.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"RL" <RL@.discussions.microsoft.com> wrote in message
news:71F2956A-5B80-4918-993F-F8CF3AD2C0D5@.microsoft.com...
> We're having intermittent performance problems on a SQL 2005 SP1 system
> that
> we suspect is related to transactional replication. There may be overlap
> with Jack Griffith's thread "Replication system disk performance severly
> degrades after 1 month", but I'm not sure.....
> While troubleshooting the problem, we attempted to make things better by
> clearing out any transactions that had already been replicated to the
> subscriber (EXEC dbo.sp_MSdistribution_cleanup @.min_distretention = 0,
> @.max_distretention = 0). BAD, BAD, BAD!!!!! Setting @.max_distretention =
> 0
> marked our subscription as inactive and we had to rebuild the subscriber
> database to get it back in sync with the publisher.
> I estimate add/update 2-4 million rows a day in our publication database.
> The distribution database has grown to 9GB in < a week.
> I have not altered any of the database cleanup jobs as of yet. The
> current
> Distribution Cleanup job runs every 10 min and is taking 6-15 minutes to
> run.
> We observe a tremendous number of disk reads on the Distribution database
> disks. When we experience performance issues, we also see a HUGE number
> of
> memory pages lasting ~ 15 seconds and occuring exactly every 2 minutes.
> Restarting the SQLServer service seems to clear up the performance issues
> for
> several hours.
>
> * msrepl_commands rowcount approaches 35 million rows and
> msrepl_transactions approaches 6 million rows. With a high volume in
> transactional replication, should there be any indexes on the tables?
> * While tracing through the MS SPs, I found that sp_MSdelete_dodelete only
> deletes the top 5000 rows from MSrepl_transactions. In a high volume
> transactional state, this might not keep up. Can this be changed safely?
> * What other parameters can be changed to keep the transactions only as
> long
> as they are needed but yet not mark the subscription as inactive?
> Thanks!
|||Thanks Hilary. We have one subscriber and are using RAID 10 as recommended.
The max_distretention is set to 72 hours already. The distribution database
was just rebuilt a week ago, so it only has 4 days of deletes in it, so i'm
not sure an index defrag will help.
Why do we need to keep 3 days worth of commands that have already been
replicated? Any suggestions on how to make the distribution cleanup job run
more efficiently? It's running at least 50% of the time now. Is it possible
we're just outpacing what replication was designed for? In my stress testing
before moving to SQL 2005 x64, replication was the weak performance link.
Thanks,
Rob
"Hilary Cotter" wrote:
> If you have a few subscribers use raid 10, if you have a large number use
> raid 5.
> Set max_distretention to 3 days. This will only pool undistributed commands
> for up to 3 days.
> the setting for only deleting 5000 rows at a time is by design. If you
> choose to modify it to something higher make sure you make the modification
> to the end of
> sp_MSdelete_publisherdb_trans as well.
> The appropriate indexes are in place on msrepl_commands and
> msrepl_transactions. You might want to defrag these indexes to see if that
> helps or update statistics.
>
> --
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "RL" <RL@.discussions.microsoft.com> wrote in message
> news:71F2956A-5B80-4918-993F-F8CF3AD2C0D5@.microsoft.com...
>
>
|||I like to keep 3 days around in case I leave on a Friday night of a long
weekend when I come back on Tuesday I can still restart failed distribution
agents without them going expired on me.
The problem is that if you delete too many rows at a time the locks will
escalate to table level locks and your log reader agents will fail.
I have a friend who was in a similar situation as yours (Wachovia bank IIRC
in NYC) and he manually deleted rows in large batches. Reverse engineer to
the procs to see what to delete and stop your log reader agents while doing
this.
I also worked on a similar problem in Philly where the backlog was something
similar and we were able to get through everything in 2 hours.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"RL" <RL@.discussions.microsoft.com> wrote in message
news:1F28BAE1-FD52-470F-9B35-E596A2544D46@.microsoft.com...[vbcol=seagreen]
> Thanks Hilary. We have one subscriber and are using RAID 10 as
> recommended.
> The max_distretention is set to 72 hours already. The distribution
> database
> was just rebuilt a week ago, so it only has 4 days of deletes in it, so
> i'm
> not sure an index defrag will help.
> Why do we need to keep 3 days worth of commands that have already been
> replicated? Any suggestions on how to make the distribution cleanup job
> run
> more efficiently? It's running at least 50% of the time now. Is it
> possible
> we're just outpacing what replication was designed for? In my stress
> testing
> before moving to SQL 2005 x64, replication was the weak performance link.
> Thanks,
> Rob
> "Hilary Cotter" wrote:
sql
we suspect is related to transactional replication. There may be overlap
with Jack Griffith's thread "Replication system disk performance severly
degrades after 1 month", but I'm not sure.....
While troubleshooting the problem, we attempted to make things better by
clearing out any transactions that had already been replicated to the
subscriber (EXEC dbo.sp_MSdistribution_cleanup @.min_distretention = 0,
@.max_distretention = 0). BAD, BAD, BAD!!!!! Setting @.max_distretention = 0
marked our subscription as inactive and we had to rebuild the subscriber
database to get it back in sync with the publisher.
I estimate add/update 2-4 million rows a day in our publication database.
The distribution database has grown to 9GB in < a week.
I have not altered any of the database cleanup jobs as of yet. The current
Distribution Cleanup job runs every 10 min and is taking 6-15 minutes to run.
We observe a tremendous number of disk reads on the Distribution database
disks. When we experience performance issues, we also see a HUGE number of
memory pages lasting ~ 15 seconds and occuring exactly every 2 minutes.
Restarting the SQLServer service seems to clear up the performance issues for
several hours.
* msrepl_commands rowcount approaches 35 million rows and
msrepl_transactions approaches 6 million rows. With a high volume in
transactional replication, should there be any indexes on the tables?
* While tracing through the MS SPs, I found that sp_MSdelete_dodelete only
deletes the top 5000 rows from MSrepl_transactions. In a high volume
transactional state, this might not keep up. Can this be changed safely?
* What other parameters can be changed to keep the transactions only as long
as they are needed but yet not mark the subscription as inactive?
Thanks!
If you have a few subscribers use raid 10, if you have a large number use
raid 5.
Set max_distretention to 3 days. This will only pool undistributed commands
for up to 3 days.
the setting for only deleting 5000 rows at a time is by design. If you
choose to modify it to something higher make sure you make the modification
to the end of
sp_MSdelete_publisherdb_trans as well.
The appropriate indexes are in place on msrepl_commands and
msrepl_transactions. You might want to defrag these indexes to see if that
helps or update statistics.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"RL" <RL@.discussions.microsoft.com> wrote in message
news:71F2956A-5B80-4918-993F-F8CF3AD2C0D5@.microsoft.com...
> We're having intermittent performance problems on a SQL 2005 SP1 system
> that
> we suspect is related to transactional replication. There may be overlap
> with Jack Griffith's thread "Replication system disk performance severly
> degrades after 1 month", but I'm not sure.....
> While troubleshooting the problem, we attempted to make things better by
> clearing out any transactions that had already been replicated to the
> subscriber (EXEC dbo.sp_MSdistribution_cleanup @.min_distretention = 0,
> @.max_distretention = 0). BAD, BAD, BAD!!!!! Setting @.max_distretention =
> 0
> marked our subscription as inactive and we had to rebuild the subscriber
> database to get it back in sync with the publisher.
> I estimate add/update 2-4 million rows a day in our publication database.
> The distribution database has grown to 9GB in < a week.
> I have not altered any of the database cleanup jobs as of yet. The
> current
> Distribution Cleanup job runs every 10 min and is taking 6-15 minutes to
> run.
> We observe a tremendous number of disk reads on the Distribution database
> disks. When we experience performance issues, we also see a HUGE number
> of
> memory pages lasting ~ 15 seconds and occuring exactly every 2 minutes.
> Restarting the SQLServer service seems to clear up the performance issues
> for
> several hours.
>
> * msrepl_commands rowcount approaches 35 million rows and
> msrepl_transactions approaches 6 million rows. With a high volume in
> transactional replication, should there be any indexes on the tables?
> * While tracing through the MS SPs, I found that sp_MSdelete_dodelete only
> deletes the top 5000 rows from MSrepl_transactions. In a high volume
> transactional state, this might not keep up. Can this be changed safely?
> * What other parameters can be changed to keep the transactions only as
> long
> as they are needed but yet not mark the subscription as inactive?
> Thanks!
|||Thanks Hilary. We have one subscriber and are using RAID 10 as recommended.
The max_distretention is set to 72 hours already. The distribution database
was just rebuilt a week ago, so it only has 4 days of deletes in it, so i'm
not sure an index defrag will help.
Why do we need to keep 3 days worth of commands that have already been
replicated? Any suggestions on how to make the distribution cleanup job run
more efficiently? It's running at least 50% of the time now. Is it possible
we're just outpacing what replication was designed for? In my stress testing
before moving to SQL 2005 x64, replication was the weak performance link.
Thanks,
Rob
"Hilary Cotter" wrote:
> If you have a few subscribers use raid 10, if you have a large number use
> raid 5.
> Set max_distretention to 3 days. This will only pool undistributed commands
> for up to 3 days.
> the setting for only deleting 5000 rows at a time is by design. If you
> choose to modify it to something higher make sure you make the modification
> to the end of
> sp_MSdelete_publisherdb_trans as well.
> The appropriate indexes are in place on msrepl_commands and
> msrepl_transactions. You might want to defrag these indexes to see if that
> helps or update statistics.
>
> --
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "RL" <RL@.discussions.microsoft.com> wrote in message
> news:71F2956A-5B80-4918-993F-F8CF3AD2C0D5@.microsoft.com...
>
>
|||I like to keep 3 days around in case I leave on a Friday night of a long
weekend when I come back on Tuesday I can still restart failed distribution
agents without them going expired on me.
The problem is that if you delete too many rows at a time the locks will
escalate to table level locks and your log reader agents will fail.
I have a friend who was in a similar situation as yours (Wachovia bank IIRC
in NYC) and he manually deleted rows in large batches. Reverse engineer to
the procs to see what to delete and stop your log reader agents while doing
this.
I also worked on a similar problem in Philly where the backlog was something
similar and we were able to get through everything in 2 hours.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"RL" <RL@.discussions.microsoft.com> wrote in message
news:1F28BAE1-FD52-470F-9B35-E596A2544D46@.microsoft.com...[vbcol=seagreen]
> Thanks Hilary. We have one subscriber and are using RAID 10 as
> recommended.
> The max_distretention is set to 72 hours already. The distribution
> database
> was just rebuilt a week ago, so it only has 4 days of deletes in it, so
> i'm
> not sure an index defrag will help.
> Why do we need to keep 3 days worth of commands that have already been
> replicated? Any suggestions on how to make the distribution cleanup job
> run
> more efficiently? It's running at least 50% of the time now. Is it
> possible
> we're just outpacing what replication was designed for? In my stress
> testing
> before moving to SQL 2005 x64, replication was the weak performance link.
> Thanks,
> Rob
> "Hilary Cotter" wrote:
sql
Wednesday, March 7, 2012
Replication - DB2 as publisher - SQL 2005 as subscriber
I have been looking for a way to replicate data from a DB2 system running on an AIX machine. I found some information related to doing this with SQL2000, but not with 2005. Can this be done - preferably without writing our own provider.
Thanks in advance
I have the same problem. I am trying to replicate data from DB2/AS400 to SQL Server 2005. I am able to connect to DB2 through SQL Analyzer and can query DB2 tables but I don’t know how to replicate data. I have done my research and people told me that it can’t be done but couldn’t find any article or book (I also went to book store) which could tell me the way how to do it. If you find any thing please post it here.
Thanks
|||You have to use something like Data Mirror for this or code your own solution.|||But then what about Heterogeneous Replication. Is it just for Oracle to and from SQL Server?Replication - DB2 as publisher - SQL 2005 as subscriber
I have been looking for a way to replicate data from a DB2 system running on an AIX machine. I found some information related to doing this with SQL2000, but not with 2005. Can this be done - preferably without writing our own provider.
Thanks in advance
I have the same problem. I am trying to replicate data from DB2/AS400 to SQL Server 2005. I am able to connect to DB2 through SQL Analyzer and can query DB2 tables but I don’t know how to replicate data. I have done my research and people told me that it can’t be done but couldn’t find any article or book (I also went to book store) which could tell me the way how to do it. If you find any thing please post it here.
Thanks
|||You have to use something like Data Mirror for this or code your own solution.|||But then what about Heterogeneous Replication. Is it just for Oracle to and from SQL Server?Replication - DB2 as publisher - SQL 2005 as subscriber
I have been looking for a way to replicate data from a DB2 system running on an AIX machine. I found some information related to doing this with SQL2000, but not with 2005. Can this be done - preferably without writing our own provider.
Thanks in advance
I have the same problem. I am trying to replicate data from DB2/AS400 to SQL Server 2005. I am able to connect to DB2 through SQL Analyzer and can query DB2 tables but I don’t know how to replicate data. I have done my research and people told me that it can’t be done but couldn’t find any article or book (I also went to book store) which could tell me the way how to do it. If you find any thing please post it here.
Thanks
|||You have to use something like Data Mirror for this or code your own solution.|||But then what about Heterogeneous Replication. Is it just for Oracle to and from SQL Server?
Subscribe to:
Posts (Atom)