Hi Guys! I work in Govern Department Bank. We just have many experiences about Replication, meanly Transactional. All evolution about Client-Server architecture in the past, make some choice:  Many Distribution application at many sites located in many cities linked through Wan (frame relay – 98 kbps to 512 kbps)  Each site has one Domain controller Server, with SQL 2000 Standard, 2 processor and 1 Gbyte of Memory. Many Databases that belongs each other to your own application and share some tables. Now we need put all information together at central Server. Let’s take a look:  We have many databases : Ddes950, Ddes033, etc  Many tables that become at each other Database needs to plus at one table, I mean, if one table at site Ag002,Ag003, Ag004,…, call T999xxx01, we need to add to one central. The distributed table has different PK row at each other! Transactional replication can do this administration? How can I do that without truncate central table after every snapshot initialize schema? How can I control synchronisms and snapshots ? How can I control schema changes? Could Microsoft replication support many publication to one subscriber? What about Oracle solutions? Can we plus together with Microsoft SQL Server? Please, if anyone has any information or Scene like that situation, please send me and share these with us!!! Thanks Krisnamourt -- Message posted via http://www.sqlmonster.com
Paul, It's more complicated! I follow that article example, and make some experiences like that, but here I have more to worry: The total table is something like 100. The table at publisher just have many rows, I mean, some table have 3 millions rows or more, so the Initial SnapShot will required at firts charge, so How can I coordinate this ? That's the point!!! I do another experience with snapshot files manipulations, so the syncronism isn't the problem, but Initial snapshot schema is... Sds! [quoted text, click to view] Paul Ibison wrote: >It sounds like a multiple publishers and central subscriber topology is what >you need. Here is an article on setting it up etc : > http://www.replicationanswers.com/CentralSubscriberArticle.asp > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via SQLMonster.com http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-replication/200612/1
Paul, It's more complicated! I follow that article example, and make some experiences like that, but here I have more to worry: The total table is something like 100. The table at publisher just have many rows, I mean, some table have 3 millions rows or more, so the Initial SnapShot will required at firts charge, so How can I coordinate this ? That's the point!!! I do another experience with snapshot files manipulations, so the syncronism isn't the problem, but Initial snapshot schema is... Sds! [quoted text, click to view] Paul Ibison wrote: >It sounds like a multiple publishers and central subscriber topology is what >you need. Here is an article on setting it up etc : > http://www.replicationanswers.com/CentralSubscriberArticle.asp > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via http://www.sqlmonster.com
Paul, It's more complicated! I follow that article example, and make some experiences like that, but here I have more to worry: The total table is something like 100. The table at publisher just have many rows, I mean, some table have 3 millions rows or more, so the Initial SnapShot will required at firts charge, so How can I coordinate this ? That's the point!!! I do another experience with snapshot files manipulations, so the syncronism isn't the problem, but Initial snapshot schema is... Sds! [quoted text, click to view] Paul Ibison wrote: >It sounds like a multiple publishers and central subscriber topology is what >you need. Here is an article on setting it up etc : > http://www.replicationanswers.com/CentralSubscriberArticle.asp > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via http://www.sqlmonster.com
I'm not too sure which part of your setup is more complicated than that in the article. You have a lot of tables and a lot of records but the methodology should be exactly the same, assuming the data is all partitioned. Are you saying that the data isn't partitioned ie there is some overlap of data across the various publishers? Cheers, Paul Ibison SQL Server MVP, www.replicationanswers.com .
Let me explain more: When I create Publisher and subscriber with “keep the existing table unchangedâ€, we need initial load too. When I maked for one publisher ok, but when another publisher make the same, It don´t plus row one by one, It truncate the table and plus its own snapshot. THAT’S THE POINT! Every time , the process make the same! What's the magic? Please , tell me :) I would need to do the load process in separated way?, I mean: 1. I’ll create the publish and subscriber , without any load. 2. Stop the distribution agent and let log reader agent run 3. Start and finish the load by DTS or BCP. 4. Start distribution agent again. Pretty !!! If I’ll do in this way, work fine, but It’s more hard to do and to manage. Sds! Kris [quoted text, click to view] Paul Ibison wrote: >I'm not too sure which part of your setup is more complicated than that in >the article. >You have a lot of tables and a lot of records but the methodology should be >exactly the same, assuming the data is all partitioned. Are you saying that >the data isn't partitioned ie there is some overlap of data across the >various publishers? > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via http://www.sqlmonster.com
Let me explain more: When I create Publisher and subscriber with “keep the existing table unchangedâ€, we need initial load too. When I maked for one publisher ok, but when another publisher make the same, It don´t plus row one by one, It truncate the table and plus its own snapshot. THAT’S THE POINT! Every time , the process make the same! What's the magic? Please , tell me :) I would need to do the load process in separated way?, I mean: 1. I’ll create the publish and subscriber , without any load. 2. Stop the distribution agent and let log reader agent run 3. Start and finish the load by DTS or BCP. 4. Start distribution agent again. Pretty !!! If I’ll do in this way, work fine, but It’s more hard to do and to manage. Sds! Kris [quoted text, click to view] Paul Ibison wrote: >I'm not too sure which part of your setup is more complicated than that in >the article. >You have a lot of tables and a lot of records but the methodology should be >exactly the same, assuming the data is all partitioned. Are you saying that >the data isn't partitioned ie there is some overlap of data across the >various publishers? > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via SQLMonster.com http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-replication/200612/1
Let me explain more: When I create Publisher and subscriber with “keep the existing table unchangedâ€, we need initial load too. When I maked for one publisher ok, but when another publisher make the same, It don´t plus row one by one, It truncate the table and plus its own snapshot. THAT’S THE POINT! Every time , the process make the same! What's the magic? Please , tell me :) I would need to do the load process in separated way?, I mean: 1. I’ll create the publish and subscriber , without any load. 2. Stop the distribution agent and let log reader agent run 3. Start and finish the load by DTS or BCP. 4. Start distribution agent again. Pretty !!! If I’ll do in this way, work fine, but It’s more hard to do and to manage. Sds! Kris [quoted text, click to view] Paul Ibison wrote: >I'm not too sure which part of your setup is more complicated than that in >the article. >You have a lot of tables and a lot of records but the methodology should be >exactly the same, assuming the data is all partitioned. Are you saying that >the data isn't partitioned ie there is some overlap of data across the >various publishers? > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via SQLMonster.com http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-replication/200612/1
I still think something is set up incorrectly as this can work fine. The initial publication has article properties which are the default ie it uses a 'drop table' as the initial script. The subsequent publications use the option to "keep the existing table unchanged". Run the snapshots for these subsequent publications without subscribing to test - there should be no drop statement or truncate or delete statements in the snapshot folder and the data should still be in BCP data files like usual. If you have something different to this (ie a drop etc) then please double-check the article properties as something is seriously awry. If you have an article set up with "keep the existing table unchanged" and yet there is a drop/truncate/delete, please script up your publication and table and I'd like to reproduce it. Cheers, Paul Ibison SQL Server MVP, www.replicationanswers.com .
Paul, I apologize for my mistake! When I created the article, I marked the flag about Initial Schema. That's the point of my mistake. I maked new two publisher to one central database/table an did exactly the way you talk and...cheer...work fine!!!! The subscriber table plus each rows about two publisher. Thanks! [quoted text, click to view] Paul Ibison wrote: >I still think something is set up incorrectly as this can work fine. The >initial publication has article properties which are the default ie it uses >a 'drop table' as the initial script. The subsequent publications use the >option to "keep the existing table unchanged". Run the snapshots for these >subsequent publications without subscribing to test - there should be no >drop statement or truncate or delete statements in the snapshot folder and >the data should still be in BCP data files like usual. If you have something >different to this (ie a drop etc) then please double-check the article >properties as something is seriously awry. If you have an article set up >with "keep the existing table unchanged" and yet there is a >drop/truncate/delete, please script up your publication and table and I'd >like to reproduce it. > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via SQLMonster.com http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-replication/200612/1
Paul, I apologize for my mistake! When I created the article, I marked the flag about Initial Schema. That's the point of my mistake. I maked new two publisher to one central database/table an did exactly the way you talk and...cheer...work fine!!!! The subscriber table plus each rows about two publisher. Thanks! [quoted text, click to view] Paul Ibison wrote: >I still think something is set up incorrectly as this can work fine. The >initial publication has article properties which are the default ie it uses >a 'drop table' as the initial script. The subsequent publications use the >option to "keep the existing table unchanged". Run the snapshots for these >subsequent publications without subscribing to test - there should be no >drop statement or truncate or delete statements in the snapshot folder and >the data should still be in BCP data files like usual. If you have something >different to this (ie a drop etc) then please double-check the article >properties as something is seriously awry. If you have an article set up >with "keep the existing table unchanged" and yet there is a >drop/truncate/delete, please script up your publication and table and I'd >like to reproduce it. > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via SQLMonster.com http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server-replication/200612/1
Paul, I apologize for my mistake! When I created the article, I marked the flag about Initial Schema. That's the point of my mistake. I maked new two publisher to one central database/table an did exactly the way you talk and...cheer...work fine!!!! The subscriber table plus each rows about two publisher. Thanks! [quoted text, click to view] Paul Ibison wrote: >I still think something is set up incorrectly as this can work fine. The >initial publication has article properties which are the default ie it uses >a 'drop table' as the initial script. The subsequent publications use the >option to "keep the existing table unchanged". Run the snapshots for these >subsequent publications without subscribing to test - there should be no >drop statement or truncate or delete statements in the snapshot folder and >the data should still be in BCP data files like usual. If you have something >different to this (ie a drop etc) then please double-check the article >properties as something is seriously awry. If you have an article set up >with "keep the existing table unchanged" and yet there is a >drop/truncate/delete, please script up your publication and table and I'd >like to reproduce it. > Cheers, > Paul Ibison SQL Server MVP, www.replicationanswers.com . -- Message posted via http://www.sqlmonster.com
Don't see what you're looking for? Try a search.
|