| Groups | Blog | Home |
sql server replication : Replication generating snapshot - locking?
Hi,
We are looking at implementing Transactional replication for our production. The initial set up did not work for us becuase the generation of snapshot was having serious slowing down of production. We cannot take our site down just for generating multiple 40G database's snapshots. My questions for Transactional Replication: 1. Is taking down the production db a requirement for replication? 2. Can the locking/slowing down of snapshot generation be avoided? 3. How can we avoid the slowing down when generating snapshot? 4. Do we have to generate a snapshot everytime when we take production down (for compiles, regular maintenance)
Which version of SQL Server?
4. Once replication is setup and running, you won't need another snapshot unless you have to reinitialize something. -- Mike http://www.solidqualitylearning.com Disclaimer: This communication is an original work and represents my sole views on the subject. It does not represent the views of any other person or entity either by inference or direct reference. [quoted text, click to view] "Saher" <Saher@discussions.microsoft.com> wrote in message news:3A73111D-99F9-418F-B623-182E9871FC31@microsoft.com... > Hi, > We are looking at implementing Transactional replication for our > production. > > The initial set up did not work for us becuase the generation of snapshot > was having serious slowing down of production. We cannot take our site > down > just for generating multiple 40G database's snapshots. > > My questions for Transactional Replication: > 1. Is taking down the production db a requirement for replication? > 2. Can the locking/slowing down of snapshot generation be avoided? > 3. How can we avoid the slowing down when generating snapshot? > 4. Do we have to generate a snapshot everytime when we take production > down > (for compiles, regular maintenance) > > Any help/advice is greatly appreciated.
SQL 2000 Enterprise edition.
What about schema changes? Do I not need another snapshot when schema is changed? [quoted text, click to view] "Michael Hotek" wrote:
> Which version of SQL Server? > > 4. Once replication is setup and running, you won't need another snapshot > unless you have to reinitialize something. > > -- > Mike > http://www.solidqualitylearning.com > Disclaimer: This communication is an original work and represents my sole > views on the subject. It does not represent the views of any other person > or entity either by inference or direct reference. > > > "Saher" <Saher@discussions.microsoft.com> wrote in message > news:3A73111D-99F9-418F-B623-182E9871FC31@microsoft.com... > > Hi, > > We are looking at implementing Transactional replication for our > > production. > > > > The initial set up did not work for us becuase the generation of snapshot > > was having serious slowing down of production. We cannot take our site > > down > > just for generating multiple 40G database's snapshots. > > > > My questions for Transactional Replication: > > 1. Is taking down the production db a requirement for replication? > > 2. Can the locking/slowing down of snapshot generation be avoided? > > 3. How can we avoid the slowing down when generating snapshot? > > 4. Do we have to generate a snapshot everytime when we take production > > down > > (for compiles, regular maintenance) > > > > Any help/advice is greatly appreciated. > >
If you are using SQL 2005 have a look at the initialize from backup option.
With SQL 2000 you could use the concurrent snapshot option, but I don't believe this will work for a database as large as 40g. 1) not at all, but there will be substantial locking unless you use the concurrent snapshot option. I recommend you either restore a copy of the backup on your subscriber(s), or you find a quiet time to generate the snapshot and use the option to 'use the snapshot files from the following folder' option when creating your pull subscription. You can then copy the snapshot to the subscriber and apply it there. 2) No, the concurrent option does not generate the locks that the default option does, but it takes much longer to generate and apply. 3) Restore from a backup of the publication database on the subscriber and fix constraints, identity columns, and triggers there for not for replication. If you can't do this during a quiet period on the publisher there will be sync issues which you will have to resolve, i.e. data in the publisher which is not in the subscriber between the time you did the backup and created the subscription. 4) No, the only time you need to is when you are creating new subscribers or reinitializing. -- Hilary Cotter Director of Text Mining and Database Strategy RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. This posting is my own and doesn't necessarily represent RelevantNoise's positions, strategies or opinions. 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 [quoted text, click to view] "Saher" <Saher@discussions.microsoft.com> wrote in message news:3A73111D-99F9-418F-B623-182E9871FC31@microsoft.com... > Hi, > We are looking at implementing Transactional replication for our > production. > > The initial set up did not work for us becuase the generation of snapshot > was having serious slowing down of production. We cannot take our site > down > just for generating multiple 40G database's snapshots. > > My questions for Transactional Replication: > 1. Is taking down the production db a requirement for replication? > 2. Can the locking/slowing down of snapshot generation be avoided? > 3. How can we avoid the slowing down when generating snapshot? > 4. Do we have to generate a snapshot everytime when we take production > down > (for compiles, regular maintenance) > > Any help/advice is greatly appreciated.
[quoted text, click to view]
>>4) No, the only time you need to is when you are creating new subscribers or reinitializing. What about schema changes? Don't you need one when you create new tables or modify the current structure? TIA [quoted text, click to view] "Hilary Cotter" wrote:
> If you are using SQL 2005 have a look at the initialize from backup option. > With SQL 2000 you could use the concurrent snapshot option, but I don't > believe this will work for a database as large as 40g. > > 1) not at all, but there will be substantial locking unless you use the > concurrent snapshot option. I recommend you either restore a copy of the > backup on your subscriber(s), or you find a quiet time to generate the > snapshot and use the option to 'use the snapshot files from the following > folder' option when creating your pull subscription. You can then copy the > snapshot to the subscriber and apply it there. > 2) No, the concurrent option does not generate the locks that the default > option does, but it takes much longer to generate and apply. > 3) Restore from a backup of the publication database on the subscriber and > fix constraints, identity columns, and triggers there for not for > replication. If you can't do this during a quiet period on the publisher > there will be sync issues which you will have to resolve, i.e. data in the > publisher which is not in the subscriber between the time you did the backup > and created the subscription. > 4) No, the only time you need to is when you are creating new subscribers or > reinitializing. > -- > Hilary Cotter > Director of Text Mining and Database Strategy > RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. > > This posting is my own and doesn't necessarily represent RelevantNoise's > positions, strategies or opinions. > > 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 > > > > "Saher" <Saher@discussions.microsoft.com> wrote in message > news:3A73111D-99F9-418F-B623-182E9871FC31@microsoft.com... > > Hi, > > We are looking at implementing Transactional replication for our > > production. > > > > The initial set up did not work for us becuase the generation of snapshot > > was having serious slowing down of production. We cannot take our site > > down > > just for generating multiple 40G database's snapshots. > > > > My questions for Transactional Replication: > > 1. Is taking down the production db a requirement for replication? > > 2. Can the locking/slowing down of snapshot generation be avoided? > > 3. How can we avoid the slowing down when generating snapshot? > > 4. Do we have to generate a snapshot everytime when we take production > > down > > (for compiles, regular maintenance) > > > > Any help/advice is greatly appreciated. > >
Yes, but normally its only the table(s) which you are modifying.
-- Hilary Cotter Director of Text Mining and Database Strategy RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. This posting is my own and doesn't necessarily represent RelevantNoise's positions, strategies or opinions. 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 [quoted text, click to view] "Saher" <Saher@discussions.microsoft.com> wrote in message news:EC8B5DDB-F088-45E8-8D57-43EB09F2D6D0@microsoft.com... >>>4) No, the only time you need to is when you are creating new subscribers >>>or > reinitializing. > > What about schema changes? Don't you need one when you create new tables > or > modify the current structure? > > TIA > > > "Hilary Cotter" wrote: > >> If you are using SQL 2005 have a look at the initialize from backup >> option. >> With SQL 2000 you could use the concurrent snapshot option, but I don't >> believe this will work for a database as large as 40g. >> >> 1) not at all, but there will be substantial locking unless you use the >> concurrent snapshot option. I recommend you either restore a copy of the >> backup on your subscriber(s), or you find a quiet time to generate the >> snapshot and use the option to 'use the snapshot files from the following >> folder' option when creating your pull subscription. You can then copy >> the >> snapshot to the subscriber and apply it there. >> 2) No, the concurrent option does not generate the locks that the default >> option does, but it takes much longer to generate and apply. >> 3) Restore from a backup of the publication database on the subscriber >> and >> fix constraints, identity columns, and triggers there for not for >> replication. If you can't do this during a quiet period on the publisher >> there will be sync issues which you will have to resolve, i.e. data in >> the >> publisher which is not in the subscriber between the time you did the >> backup >> and created the subscription. >> 4) No, the only time you need to is when you are creating new subscribers >> or >> reinitializing. >> -- >> Hilary Cotter >> Director of Text Mining and Database Strategy >> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. >> >> This posting is my own and doesn't necessarily represent RelevantNoise's >> positions, strategies or opinions. >> >> 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 >> >> >> >> "Saher" <Saher@discussions.microsoft.com> wrote in message >> news:3A73111D-99F9-418F-B623-182E9871FC31@microsoft.com... >> > Hi, >> > We are looking at implementing Transactional replication for our >> > production. >> > >> > The initial set up did not work for us becuase the generation of >> > snapshot >> > was having serious slowing down of production. We cannot take our site >> > down >> > just for generating multiple 40G database's snapshots. >> > >> > My questions for Transactional Replication: >> > 1. Is taking down the production db a requirement for replication? >> > 2. Can the locking/slowing down of snapshot generation be avoided? >> > 3. How can we avoid the slowing down when generating snapshot? >> > 4. Do we have to generate a snapshot everytime when we take production >> > down >> > (for compiles, regular maintenance) >> > >> > Any help/advice is greatly appreciated. >> >> >>
Yes, generate new snapshot?
How do we take care of schema changes? ( tables, index..) [quoted text, click to view] "Hilary Cotter" wrote:
> Yes, but normally its only the table(s) which you are modifying. > > -- > Hilary Cotter > Director of Text Mining and Database Strategy > RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. > > This posting is my own and doesn't necessarily represent RelevantNoise's > positions, strategies or opinions. > > 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 > > > > "Saher" <Saher@discussions.microsoft.com> wrote in message > news:EC8B5DDB-F088-45E8-8D57-43EB09F2D6D0@microsoft.com... > >>>4) No, the only time you need to is when you are creating new subscribers > >>>or > > reinitializing. > > > > What about schema changes? Don't you need one when you create new tables > > or > > modify the current structure? > > > > TIA > > > > > > "Hilary Cotter" wrote: > > > >> If you are using SQL 2005 have a look at the initialize from backup > >> option. > >> With SQL 2000 you could use the concurrent snapshot option, but I don't > >> believe this will work for a database as large as 40g. > >> > >> 1) not at all, but there will be substantial locking unless you use the > >> concurrent snapshot option. I recommend you either restore a copy of the > >> backup on your subscriber(s), or you find a quiet time to generate the > >> snapshot and use the option to 'use the snapshot files from the following > >> folder' option when creating your pull subscription. You can then copy > >> the > >> snapshot to the subscriber and apply it there. > >> 2) No, the concurrent option does not generate the locks that the default > >> option does, but it takes much longer to generate and apply. > >> 3) Restore from a backup of the publication database on the subscriber > >> and > >> fix constraints, identity columns, and triggers there for not for > >> replication. If you can't do this during a quiet period on the publisher > >> there will be sync issues which you will have to resolve, i.e. data in > >> the > >> publisher which is not in the subscriber between the time you did the > >> backup > >> and created the subscription. > >> 4) No, the only time you need to is when you are creating new subscribers > >> or > >> reinitializing. > >> -- > >> Hilary Cotter > >> Director of Text Mining and Database Strategy > >> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. > >> > >> This posting is my own and doesn't necessarily represent RelevantNoise's > >> positions, strategies or opinions. > >> > >> 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 > >> > >> > >> > >> "Saher" <Saher@discussions.microsoft.com> wrote in message > >> news:3A73111D-99F9-418F-B623-182E9871FC31@microsoft.com... > >> > Hi, > >> > We are looking at implementing Transactional replication for our > >> > production. > >> > > >> > The initial set up did not work for us becuase the generation of > >> > snapshot > >> > was having serious slowing down of production. We cannot take our site > >> > down > >> > just for generating multiple 40G database's snapshots. > >> > > >> > My questions for Transactional Replication: > >> > 1. Is taking down the production db a requirement for replication? > >> > 2. Can the locking/slowing down of snapshot generation be avoided? > >> > 3. How can we avoid the slowing down when generating snapshot? > >> > 4. Do we have to generate a snapshot everytime when we take production > >> > down > >> > (for compiles, regular maintenance) > >> > > >> > Any help/advice is greatly appreciated. > >> > >> > >> > >
I have a bunch of tables to be added to my publisher that need to be
replicated. How can I do that without creating a new snapshot? [quoted text, click to view] "Saher" wrote:
> Yes, generate new snapshot? > > How do we take care of schema changes? ( tables, index..) > > "Hilary Cotter" wrote: > > > Yes, but normally its only the table(s) which you are modifying. > > > > -- > > Hilary Cotter > > Director of Text Mining and Database Strategy > > RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. > > > > This posting is my own and doesn't necessarily represent RelevantNoise's > > positions, strategies or opinions. > > > > 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 > > > > > > > > "Saher" <Saher@discussions.microsoft.com> wrote in message > > news:EC8B5DDB-F088-45E8-8D57-43EB09F2D6D0@microsoft.com... > > >>>4) No, the only time you need to is when you are creating new subscribers > > >>>or > > > reinitializing. > > > > > > What about schema changes? Don't you need one when you create new tables > > > or > > > modify the current structure? > > > > > > TIA > > > > > > > > > "Hilary Cotter" wrote: > > > > > >> If you are using SQL 2005 have a look at the initialize from backup > > >> option. > > >> With SQL 2000 you could use the concurrent snapshot option, but I don't > > >> believe this will work for a database as large as 40g. > > >> > > >> 1) not at all, but there will be substantial locking unless you use the > > >> concurrent snapshot option. I recommend you either restore a copy of the > > >> backup on your subscriber(s), or you find a quiet time to generate the > > >> snapshot and use the option to 'use the snapshot files from the following > > >> folder' option when creating your pull subscription. You can then copy > > >> the > > >> snapshot to the subscriber and apply it there. > > >> 2) No, the concurrent option does not generate the locks that the default > > >> option does, but it takes much longer to generate and apply. > > >> 3) Restore from a backup of the publication database on the subscriber > > >> and > > >> fix constraints, identity columns, and triggers there for not for > > >> replication. If you can't do this during a quiet period on the publisher > > >> there will be sync issues which you will have to resolve, i.e. data in > > >> the > > >> publisher which is not in the subscriber between the time you did the > > >> backup > > >> and created the subscription. > > >> 4) No, the only time you need to is when you are creating new subscribers > > >> or > > >> reinitializing. > > >> -- > > >> Hilary Cotter > > >> Director of Text Mining and Database Strategy > > >> RelevantNOISE.Com - Dedicated to mining blogs for business intelligence. > > >> > > >> This posting is my own and doesn't necessarily represent RelevantNoise's > > >> positions, strategies or opinions. > > >> > > >> 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 > > >> > > >> > > >> > > >> "Saher" <Saher@discussions.microsoft.com> wrote in message > > >> news:3A73111D-99F9-418F-B623-182E9871FC31@microsoft.com... > > >> > Hi, > > >> > We are looking at implementing Transactional replication for our > > >> > production. > > >> > > > >> > The initial set up did not work for us becuase the generation of > > >> > snapshot > > >> > was having serious slowing down of production. We cannot take our site > > >> > down > > >> > just for generating multiple 40G database's snapshots. > > >> > > > >> > My questions for Transactional Replication: > > >> > 1. Is taking down the production db a requirement for replication? > > >> > 2. Can the locking/slowing down of snapshot generation be avoided? > > >> > 3. How can we avoid the slowing down when generating snapshot? > > >> > 4. Do we have to generate a snapshot everytime when we take production > > >> > down > > >> > (for compiles, regular maintenance) > > >> > > > >> > Any help/advice is greatly appreciated. > > >> > > >> > > >> > > > >
Don't see what you're looking for? Try a search.
|
April 2003
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |