Hi all,
I am planning replication around a large SQL Database Server; 3 databases need to be replicated for reporting purposes.
My plan was to use Transaction Replication, as the Reporting database will be mostly read-only. However, we must add a whole bunch of additional, historical data to some of the tables of the reporting database that does not exist in the Publisher. I understand that changes can be made to subscriptions in Transaction Replication scenarios, ideally when the changes are few and far between. (Merge replication is excessive for our purposes.)
I don't want the additional historical data to be propagated back to the publisher. Is it possible that data is written to a subscriber in a Transactional Replication scenario without writing these updates to the Publisher? Given the nature of the data, there will not be conflicts between the historical data and the new changes applied from the publisher.
Any help would be much appreciated!
Thanks,
FarazWhile you are flirting at the edge of what works well, at least what you've described is possible. I'm pretty sure that Microsoft does not recommend it, I'm not sure if they support it, but I have done it under very limited circumstances for very specific purposes.
This is not for the faint of heart. You need to think things out carefully. It might pay you to find someone experienced in replication that you can contract to help set things up and shake out the problems.
-PatP|||Thanks for the reply. We won't be using transactional replication. In fact, from my understanding, one of the goals of replication is ensuring that data consistency is maintained between publishers and subscribers; in our case, we don't actually want the data to be consistent. Hence, we'll go forth with a less elegant, but far simpler solution.
Thanks again!
-Farazsql
Showing posts with label reporting. Show all posts
Showing posts with label reporting. Show all posts
Friday, March 23, 2012
Replication Question
I have continuous transactional replication running from a production server to a reporting server. Both servers are SQL 2000. A week or so ago, a new column was added to a table being replicated, both production and reporting servers. I need to get that field included in the replication. Can this be done without having to drop the subscription, adding the field, re-create the subscription and then re-creating a snapshot?Go to BOL. Look up sp_repladdcolumn. Here is part of what it says:
sp_repladdcolumn
Adds a column to an existing table article that has been published. Allows the new column to be added to all publishers that publish this table, or just add the column to a specific publication that publishes the table. This stored procedure is executed at the Publisher on the publication database.|||Thank you!
sp_repladdcolumn
Adds a column to an existing table article that has been published. Allows the new column to be added to all publishers that publish this table, or just add the column to a specific publication that publishes the table. This stored procedure is executed at the Publisher on the publication database.|||Thank you!
Replication Question
I have continuous transactional replication running from a production server
to a reporting server. Both servers are SQL 2000. A week or so ago, a new
column was added to a table being replicated (on both production and
reporting servers). I need to get that field included in the replication.
Can this be done without having to drop the subscription, adding the field,
re-create the subscription and then re-creating a snapshot?
Message posted via http://www.droptable.com"cynault via droptable.com" <u7602@.uwe> wrote in message
news:61851d6b86210@.uwe...
> I have continuous transactional replication running from a production
server
> to a reporting server. Both servers are SQL 2000. A week or so ago, a
new
> column was added to a table being replicated (on both production and
> reporting servers). I need to get that field included in the replication.
> Can this be done without having to drop the subscription, adding the
field,
> re-create the subscription and then re-creating a snapshot?
>
Not if the column has already been added.
But look up sp_repladdcolumn for future reference.
> --
> Message posted via http://www.droptable.com|||Thank you!
Message posted via http://www.droptable.com|||Thank you!
Message posted via http://www.droptable.com
to a reporting server. Both servers are SQL 2000. A week or so ago, a new
column was added to a table being replicated (on both production and
reporting servers). I need to get that field included in the replication.
Can this be done without having to drop the subscription, adding the field,
re-create the subscription and then re-creating a snapshot?
Message posted via http://www.droptable.com"cynault via droptable.com" <u7602@.uwe> wrote in message
news:61851d6b86210@.uwe...
> I have continuous transactional replication running from a production
server
> to a reporting server. Both servers are SQL 2000. A week or so ago, a
new
> column was added to a table being replicated (on both production and
> reporting servers). I need to get that field included in the replication.
> Can this be done without having to drop the subscription, adding the
field,
> re-create the subscription and then re-creating a snapshot?
>
Not if the column has already been added.
But look up sp_repladdcolumn for future reference.
> --
> Message posted via http://www.droptable.com|||Thank you!
Message posted via http://www.droptable.com|||Thank you!
Message posted via http://www.droptable.com
Replication Question
I have continuous transactional replication running from a production server
to a reporting server. Both servers are SQL 2000. A week or so ago, a new
column was added to a table being replicated (on both production and
reporting servers). I need to get that field included in the replication.
Can this be done without having to drop the subscription, adding the field,
re-create the subscription and then re-creating a snapshot?
--
Message posted via http://www.sqlmonster.com"cynault via SQLMonster.com" <u7602@.uwe> wrote in message
news:61851d6b86210@.uwe...
> I have continuous transactional replication running from a production
server
> to a reporting server. Both servers are SQL 2000. A week or so ago, a
new
> column was added to a table being replicated (on both production and
> reporting servers). I need to get that field included in the replication.
> Can this be done without having to drop the subscription, adding the
field,
> re-create the subscription and then re-creating a snapshot?
>
Not if the column has already been added.
But look up sp_repladdcolumn for future reference.
> --
> Message posted via http://www.sqlmonster.com|||Thank you!
--
Message posted via http://www.sqlmonster.comsql
to a reporting server. Both servers are SQL 2000. A week or so ago, a new
column was added to a table being replicated (on both production and
reporting servers). I need to get that field included in the replication.
Can this be done without having to drop the subscription, adding the field,
re-create the subscription and then re-creating a snapshot?
--
Message posted via http://www.sqlmonster.com"cynault via SQLMonster.com" <u7602@.uwe> wrote in message
news:61851d6b86210@.uwe...
> I have continuous transactional replication running from a production
server
> to a reporting server. Both servers are SQL 2000. A week or so ago, a
new
> column was added to a table being replicated (on both production and
> reporting servers). I need to get that field included in the replication.
> Can this be done without having to drop the subscription, adding the
field,
> re-create the subscription and then re-creating a snapshot?
>
Not if the column has already been added.
But look up sp_repladdcolumn for future reference.
> --
> Message posted via http://www.sqlmonster.com|||Thank you!
--
Message posted via http://www.sqlmonster.comsql
Monday, March 12, 2012
replication over a wan
Howdy kids. We are moving our servers to a new location here shortly. One of
the servers is a replicated reporting box. There is an internal ongoing
debate on if we should move this box or not. I have a 25 gig database. The
two buildings are about 40 miles apart from each other. The replication
configuration is as follows:
Transactional.
Remote Distributor. (on the Subscriber)
NOT immediate updating.
Are there any issues with this type of configuration over a WAN? Any gotchas
that wouldn't be had on a local network that could happen here?
SQL2K SP3
TIA, ChrisR
If your subscriber (and consequently your distributor) goes down your tlog
on your publisher will balloon like a balloon. This ballooning tlog will
cause performance problems on the publisher, and can eat up all your space
on the publisher. I would advise you to use a local distributor - preferably
a distributor on the same box as the publisher.
Also you have to check your effective bandwidth of your WAN. Low bandwidth
can cause log reader performance problems leading to ballooning tlogs.
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
"ChrisR" <bla@.noemail.com> wrote in message
news:uwfPwhiCFHA.328@.tk2msftngp13.phx.gbl...
> Howdy kids. We are moving our servers to a new location here shortly. One
of
> the servers is a replicated reporting box. There is an internal ongoing
> debate on if we should move this box or not. I have a 25 gig database. The
> two buildings are about 40 miles apart from each other. The replication
> configuration is as follows:
> Transactional.
> Remote Distributor. (on the Subscriber)
> NOT immediate updating.
> Are there any issues with this type of configuration over a WAN? Any
gotchas
> that wouldn't be had on a local network that could happen here?
> --
> SQL2K SP3
> TIA, ChrisR
>
|||Thanks Hillary. If I switch to a Local Distributor, should I switch from a
Pull to Push Subscription as well? It would make sense to me, what do you
think?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:e#XCZQjCFHA.3936@.TK2MSFTNGP09.phx.gbl...
> If your subscriber (and consequently your distributor) goes down your tlog
> on your publisher will balloon like a balloon. This ballooning tlog will
> cause performance problems on the publisher, and can eat up all your space
> on the publisher. I would advise you to use a local distributor -
preferably[vbcol=seagreen]
> a distributor on the same box as the publisher.
> Also you have to check your effective bandwidth of your WAN. Low bandwidth
> can cause log reader performance problems leading to ballooning tlogs.
> --
> 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
> "ChrisR" <bla@.noemail.com> wrote in message
> news:uwfPwhiCFHA.328@.tk2msftngp13.phx.gbl...
One[vbcol=seagreen]
> of
The
> gotchas
>
|||Your choice of push or pull is irrelevant in this case.
Use push when you have small numbers of subscribers, you want a central
point of administration on your publisher, and your subscribers are normally
online and well connected.
Use pull when you have large numbers of subscribers, you don't care about a
central point of administration because you are using replication monitor
group, and your subscribers are not always connected.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Now available on Amazon.com
http://www.amazon.com/gp/product/off...?condition=all
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"ChrisR" <bla@.noemail.com> wrote in message
news:%23PqR59jCFHA.4052@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> Thanks Hillary. If I switch to a Local Distributor, should I switch from a
> Pull to Push Subscription as well? It would make sense to me, what do you
> think?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:e#XCZQjCFHA.3936@.TK2MSFTNGP09.phx.gbl...
tlog[vbcol=seagreen]
space[vbcol=seagreen]
> preferably
bandwidth[vbcol=seagreen]
> One
ongoing[vbcol=seagreen]
> The
replication
>
the servers is a replicated reporting box. There is an internal ongoing
debate on if we should move this box or not. I have a 25 gig database. The
two buildings are about 40 miles apart from each other. The replication
configuration is as follows:
Transactional.
Remote Distributor. (on the Subscriber)
NOT immediate updating.
Are there any issues with this type of configuration over a WAN? Any gotchas
that wouldn't be had on a local network that could happen here?
SQL2K SP3
TIA, ChrisR
If your subscriber (and consequently your distributor) goes down your tlog
on your publisher will balloon like a balloon. This ballooning tlog will
cause performance problems on the publisher, and can eat up all your space
on the publisher. I would advise you to use a local distributor - preferably
a distributor on the same box as the publisher.
Also you have to check your effective bandwidth of your WAN. Low bandwidth
can cause log reader performance problems leading to ballooning tlogs.
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
"ChrisR" <bla@.noemail.com> wrote in message
news:uwfPwhiCFHA.328@.tk2msftngp13.phx.gbl...
> Howdy kids. We are moving our servers to a new location here shortly. One
of
> the servers is a replicated reporting box. There is an internal ongoing
> debate on if we should move this box or not. I have a 25 gig database. The
> two buildings are about 40 miles apart from each other. The replication
> configuration is as follows:
> Transactional.
> Remote Distributor. (on the Subscriber)
> NOT immediate updating.
> Are there any issues with this type of configuration over a WAN? Any
gotchas
> that wouldn't be had on a local network that could happen here?
> --
> SQL2K SP3
> TIA, ChrisR
>
|||Thanks Hillary. If I switch to a Local Distributor, should I switch from a
Pull to Push Subscription as well? It would make sense to me, what do you
think?
"Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
news:e#XCZQjCFHA.3936@.TK2MSFTNGP09.phx.gbl...
> If your subscriber (and consequently your distributor) goes down your tlog
> on your publisher will balloon like a balloon. This ballooning tlog will
> cause performance problems on the publisher, and can eat up all your space
> on the publisher. I would advise you to use a local distributor -
preferably[vbcol=seagreen]
> a distributor on the same box as the publisher.
> Also you have to check your effective bandwidth of your WAN. Low bandwidth
> can cause log reader performance problems leading to ballooning tlogs.
> --
> 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
> "ChrisR" <bla@.noemail.com> wrote in message
> news:uwfPwhiCFHA.328@.tk2msftngp13.phx.gbl...
One[vbcol=seagreen]
> of
The
> gotchas
>
|||Your choice of push or pull is irrelevant in this case.
Use push when you have small numbers of subscribers, you want a central
point of administration on your publisher, and your subscribers are normally
online and well connected.
Use pull when you have large numbers of subscribers, you don't care about a
central point of administration because you are using replication monitor
group, and your subscribers are not always connected.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Now available on Amazon.com
http://www.amazon.com/gp/product/off...?condition=all
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"ChrisR" <bla@.noemail.com> wrote in message
news:%23PqR59jCFHA.4052@.TK2MSFTNGP15.phx.gbl...[vbcol=seagreen]
> Thanks Hillary. If I switch to a Local Distributor, should I switch from a
> Pull to Push Subscription as well? It would make sense to me, what do you
> think?
>
> "Hilary Cotter" <hilary.cotter@.gmail.com> wrote in message
> news:e#XCZQjCFHA.3936@.TK2MSFTNGP09.phx.gbl...
tlog[vbcol=seagreen]
space[vbcol=seagreen]
> preferably
bandwidth[vbcol=seagreen]
> One
ongoing[vbcol=seagreen]
> The
replication
>
Wednesday, March 7, 2012
Replication Monitoring
What would be a best practice for monitoring Replication?
I have Transactional Replication going from the Production database (SQL00) to the Reporting database (SQL03).
Are there some Alerts I need to make sure I have setup to notify me?
Should I do a Validate Subscription once a week or so?
What would you do to have peace of mind that your reporting database is exactly in sync with your production database?
Thanx!
This depends on the stability of your links. If you are well connected, i.e. have highly reliable links set up the replication alerts to alert you when your job fails.
If your links are somewhat unstable set up the replication alerts to alert you when a job fails, but make sure you click on the response tab, and set a threshold to be alerted at, i.e. once per day, hour, etc.
You can schedule validations using sp_publication_validation. Use this proc in conjunction with the Replication: Subscriber has failed data validation alert.
How frequently you wish to run a validation depends on what you are doing. In general with a read only subscriber I never feel the need to run one. Your comfort level (or your bosses') might vary from mine.
With an updateable subscriber (immediate, queued, or merge) you might feel the need to run validations more often.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"JLS" <jlshoop@.hotmail.com> wrote in message news:%23juwUyqjEHA.2764@.TK2MSFTNGP11.phx.gbl...
What would be a best practice for monitoring Replication?
I have Transactional Replication going from the Production database (SQL00) to the Reporting database (SQL03).
Are there some Alerts I need to make sure I have setup to notify me?
Should I do a Validate Subscription once a week or so?
What would you do to have peace of mind that your reporting database is exactly in sync with your production database?
Thanx!
I have Transactional Replication going from the Production database (SQL00) to the Reporting database (SQL03).
Are there some Alerts I need to make sure I have setup to notify me?
Should I do a Validate Subscription once a week or so?
What would you do to have peace of mind that your reporting database is exactly in sync with your production database?
Thanx!
This depends on the stability of your links. If you are well connected, i.e. have highly reliable links set up the replication alerts to alert you when your job fails.
If your links are somewhat unstable set up the replication alerts to alert you when a job fails, but make sure you click on the response tab, and set a threshold to be alerted at, i.e. once per day, hour, etc.
You can schedule validations using sp_publication_validation. Use this proc in conjunction with the Replication: Subscriber has failed data validation alert.
How frequently you wish to run a validation depends on what you are doing. In general with a read only subscriber I never feel the need to run one. Your comfort level (or your bosses') might vary from mine.
With an updateable subscriber (immediate, queued, or merge) you might feel the need to run validations more often.
Hilary Cotter
Looking for a book on SQL Server replication?
http://www.nwsu.com/0974973602.html
"JLS" <jlshoop@.hotmail.com> wrote in message news:%23juwUyqjEHA.2764@.TK2MSFTNGP11.phx.gbl...
What would be a best practice for monitoring Replication?
I have Transactional Replication going from the Production database (SQL00) to the Reporting database (SQL03).
Are there some Alerts I need to make sure I have setup to notify me?
Should I do a Validate Subscription once a week or so?
What would you do to have peace of mind that your reporting database is exactly in sync with your production database?
Thanx!
Replication Monitor Reporting Error
I am continually having problems with the replication monitor reporting
erronous errors. I have read in the past that this can be resolved by
restarting SQL, but that does not solve my problem because SQL is restarted
nightly on all SQL servers with the commands listed below....
REM Stop SQL Server Agent
net stop sqlserveragent
REM Stop SQL Server
net stop MSSQLServer
REM Start SQL Server
net Start MSSQLServer
REM Start SQL Server Agent
net start sqlserveragent
I am at a loss. I have 17 SQL servers and the problem does not exist on all
of them, but where the error is being reported, it is always the same servers.
HELP!!!
Larry...
Which agent is generating the error.
Normally you can use sp_MSloadresetstatus to fix this problem. I'm not
totally sure if this the name of the proc but do a search like this
select name from master.dbo.sysobjects where name like '%load%' and name
like '%status%' and type='p' and it will show up
"Larry" <Larry@.discussions.microsoft.com> wrote in message
news:AFFB37CD-AB2A-4451-ADFB-53DDBBED8348@.microsoft.com...
>I am continually having problems with the replication monitor reporting
> erronous errors. I have read in the past that this can be resolved by
> restarting SQL, but that does not solve my problem because SQL is
> restarted
> nightly on all SQL servers with the commands listed below....
> REM Stop SQL Server Agent
> net stop sqlserveragent
> REM Stop SQL Server
> net stop MSSQLServer
> REM Start SQL Server
> net Start MSSQLServer
> REM Start SQL Server Agent
> net start sqlserveragent
> I am at a loss. I have 17 SQL servers and the problem does not exist on
> all
> of them, but where the error is being reported, it is always the same
> servers.
> HELP!!!
> Larry...
|||Hilary,
I ran sp_MSload_replication_status, on both the Master dB and the dB
reporting the error, but the pesky red X did not clear up. Any other ideas?
Larry...
erronous errors. I have read in the past that this can be resolved by
restarting SQL, but that does not solve my problem because SQL is restarted
nightly on all SQL servers with the commands listed below....
REM Stop SQL Server Agent
net stop sqlserveragent
REM Stop SQL Server
net stop MSSQLServer
REM Start SQL Server
net Start MSSQLServer
REM Start SQL Server Agent
net start sqlserveragent
I am at a loss. I have 17 SQL servers and the problem does not exist on all
of them, but where the error is being reported, it is always the same servers.
HELP!!!
Larry...
Which agent is generating the error.
Normally you can use sp_MSloadresetstatus to fix this problem. I'm not
totally sure if this the name of the proc but do a search like this
select name from master.dbo.sysobjects where name like '%load%' and name
like '%status%' and type='p' and it will show up
"Larry" <Larry@.discussions.microsoft.com> wrote in message
news:AFFB37CD-AB2A-4451-ADFB-53DDBBED8348@.microsoft.com...
>I am continually having problems with the replication monitor reporting
> erronous errors. I have read in the past that this can be resolved by
> restarting SQL, but that does not solve my problem because SQL is
> restarted
> nightly on all SQL servers with the commands listed below....
> REM Stop SQL Server Agent
> net stop sqlserveragent
> REM Stop SQL Server
> net stop MSSQLServer
> REM Start SQL Server
> net Start MSSQLServer
> REM Start SQL Server Agent
> net start sqlserveragent
> I am at a loss. I have 17 SQL servers and the problem does not exist on
> all
> of them, but where the error is being reported, it is always the same
> servers.
> HELP!!!
> Larry...
|||Hilary,
I ran sp_MSload_replication_status, on both the Master dB and the dB
reporting the error, but the pesky red X did not clear up. Any other ideas?
Larry...
Saturday, February 25, 2012
Replication Maintanance Issues!
Hi Guys/Gals,
Need some comments/ideas on the following scenario:
Current Situation:
-I have a PROD DB and a REPORTING DB( Separte Physical Servers).
-PROD DB replicates (Transactional) to REPORTING DB. ( Using only Replication Wizard to set up, quite easy)
-DB is for running shopfloor(manufacturing) applications, thus needs to be minimum downtime.
-Retention period for PROD DB data is 3 months ,Reporting DB is 3 years.
Future Problem that I will encounter:
-Purging of data in PROD DB will be replicated into Reporting.
-Schema change in PROD DB need to delete existing Publication before able to change schema.
-After schema change, need to recreate publication and rerun snapshot.
Questions:
-How to prevent the purging to be replicated to Reporting?
Switching off Replication when Purging takes place will not help. The only solution
I am thinking of is to alter the store procedure for replication during purging.
Is there any other "CLEANER" hassle free way?
- How to cater shema changes better?
Currently the data is not alot, but down the road, it might go to Terabytes, by then running a
snapshot will cost us alot. Is there any way not to redo a snapshot for this scenario?
Please give your comments/ideas/ .
Thanks.--> another thing I miss out, doing a snapshot again would clear any data
Reporting DB has stored. e.g. Prod DB( 3 months data) , Reporting DB(1 year data), do snapshot....all gone.|||Anyone...any suggestions?|||Patrick, have you thought about replication without snapshot? That will minimize the impact of snapshoting on publications.
Changing replication stored procs sounds the best way to avoid data changes on the subscribers. But it could go wild if you have a lot of sprocs to modify.|||replication without snapshot..hmmm...I'll check it out...
no idea as of how not to have a snapshot for now....can u give some highlights...
Anybody else? I'm sure other ppl would have the same senario as me....|||there was a thread a few days back that was talking about transactional replication without snapshot. check it out:
http://www.dbforums.com/showthread.php?p=3665793#post3665793
SQL Magazine also has an article on this.
I have used this technique for years. The key is to ensure publisher and subscriber are in sync without snapshoting. make sure no one can do transactions in the servers. break replication, dropping subscriber, articles etc, while the publisher and subscriber dbs are not modified. At the end when you reset up replication, click on the option that says "subscriber already has the data".
Need some comments/ideas on the following scenario:
Current Situation:
-I have a PROD DB and a REPORTING DB( Separte Physical Servers).
-PROD DB replicates (Transactional) to REPORTING DB. ( Using only Replication Wizard to set up, quite easy)
-DB is for running shopfloor(manufacturing) applications, thus needs to be minimum downtime.
-Retention period for PROD DB data is 3 months ,Reporting DB is 3 years.
Future Problem that I will encounter:
-Purging of data in PROD DB will be replicated into Reporting.
-Schema change in PROD DB need to delete existing Publication before able to change schema.
-After schema change, need to recreate publication and rerun snapshot.
Questions:
-How to prevent the purging to be replicated to Reporting?
Switching off Replication when Purging takes place will not help. The only solution
I am thinking of is to alter the store procedure for replication during purging.
Is there any other "CLEANER" hassle free way?
- How to cater shema changes better?
Currently the data is not alot, but down the road, it might go to Terabytes, by then running a
snapshot will cost us alot. Is there any way not to redo a snapshot for this scenario?
Please give your comments/ideas/ .
Thanks.--> another thing I miss out, doing a snapshot again would clear any data
Reporting DB has stored. e.g. Prod DB( 3 months data) , Reporting DB(1 year data), do snapshot....all gone.|||Anyone...any suggestions?|||Patrick, have you thought about replication without snapshot? That will minimize the impact of snapshoting on publications.
Changing replication stored procs sounds the best way to avoid data changes on the subscribers. But it could go wild if you have a lot of sprocs to modify.|||replication without snapshot..hmmm...I'll check it out...
no idea as of how not to have a snapshot for now....can u give some highlights...
Anybody else? I'm sure other ppl would have the same senario as me....|||there was a thread a few days back that was talking about transactional replication without snapshot. check it out:
http://www.dbforums.com/showthread.php?p=3665793#post3665793
SQL Magazine also has an article on this.
I have used this technique for years. The key is to ensure publisher and subscriber are in sync without snapshoting. make sure no one can do transactions in the servers. break replication, dropping subscriber, articles etc, while the publisher and subscriber dbs are not modified. At the end when you reset up replication, click on the option that says "subscriber already has the data".
Subscribe to:
Posts (Atom)