Showing posts with label merge. Show all posts
Showing posts with label merge. Show all posts

Monday, March 26, 2012

Restoring the replication environment

Is it possible to restoring the master db ? This is to
restore the merge agents settings, without creating the
merge agents again? If any one got an answer for this
please reply asap.
Binoy,
replication agents and the master database are two separate issues. In
master there is sysservers and sysxlogins, both of which are relevant to the
replication setup. However, you are concerned about the merge agent jobs and
parameters which are in msdb (sysjobs, MSagent_profiles, MSagent_parameters
etc). For a good set of details on the replication backup strategy, you can
have a look in BOL for 'replication, backup and restore
operations,Strategies for Backing Up and Restoring Merge Replication'.
HTH,
Paul Ibison

Wednesday, March 21, 2012

Restoring replication

I have a problem that needs tip: Our main replica server need to be restored.
It has been the main server within a network using merge replications between
around 10 servers with publications and push/pull subscriptions. Now listen
the server was stolen and I need to restore (I got the all the *.mdf files on
a separate ghost-disk) the server. I need some good advice on how to restore
properly. I have also backup-files from all replica-databases plus master
database and distribution database. But I have not any backup on the
MSDB-database. Suggestions?
Best wishes
Basically you are hosed. All of your merge agent job information is gone.
You will have to drop your publications and subscriptions and rebuild from
scratch.
Hilary Cotter
Looking for a SQL Server replication book?
Now available for purchase at:
http://www.nwsu.com/0974973602.html
"Mats" <Mats@.discussions.microsoft.com> wrote in message
news:787985FB-1CA8-47E3-8B00-0575443082D4@.microsoft.com...
>I have a problem that needs tip: Our main replica server need to be
>restored.
> It has been the main server within a network using merge replications
> between
> around 10 servers with publications and push/pull subscriptions. Now
> listen
> the server was stolen and I need to restore (I got the all the *.mdf files
> on
> a separate ghost-disk) the server. I need some good advice on how to
> restore
> properly. I have also backup-files from all replica-databases plus master
> database and distribution database. But I have not any backup on the
> MSDB-database. Suggestions?
> --
> Best wishes

restoring replicated database

Hi,
I've restored a merge replicated database (publisher) on a new server
without replication.
Now i observe that there are some default replication procedures named
*_pal in my restored database. What is the way of deleting these
replication procedures. What will be the impact of the same.
Regds,
amit
Amit,
these procedures will need cleaning up by hand. sp_removedbreplication will
remove many system objects but these procs sometimes remain. You can
hand-craft a script to delete them (using information_schema.routines) or
just do it manually.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul thanks for you reply. We have configured this restored database
for replication and it has created new *pal. procedures. Is it ok if we
delete the earlier *pal procedure now?
|||Yes
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||thanks, but can you just let me know if there would be any impact if i
keep the old procedures instead of deleting them as i would not like to
change the system configuration if there is not impact.
|||If you mean problems caused by name conflicts and the like, I think the
complexity of the name ensures this isn't the case. I have seen systems that
have accumulated orphaned procs like this over several years and the DBAs
didn't even notice they were there.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql

Restoring Publisher

We are testing SQL 2K Merge replication on a server and we need to restore
from a backup that was created right after the publication was setup. Do we
need to re-run the snapshot before we can re-create a subscriber? Thanks.
David
David,
if you want to reinitialize the subscriber, this will be necessary. In this
case, changes made on the subscriber since your backup will be lost. If you
just want to get things working again, and want to retain the recent
subscriber changes, you can restore the publisher database and synchronize
with the subscriber (assuming all this is on the same server).
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||At this point, I don't care about the subscriber changes because we only
have 1 test anonymous laptop subscription. But in real production I
would want to know what can be done. For example, what if the publisher
crashes and we have to restore from a backup. Can the subscribers
simply synchronize with their changes against this newly restored
publisher? If so, do I have to re-run the snapshot? Thanks.
David
*** Sent via Developersdex http://www.codecomments.com ***
|||David,
as long as you have a recent backup in merge, you can restore and
synchronize. Changes are associated with generation numbers in the metadata
which is effectively working as a logical clock. This means that they'll
pick up all the changes made after they last synchronized with the
subscriber, from wherever they originated.
Cheers,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
sql

Tuesday, March 20, 2012

Restoring Merge Repolication... HELP!

Hi,
I accidentaly remove a publication, I need to restore it!!!
What Date Base I must restore?
I Restore de Distribution database and only restore de Agents but not de
publication.
restore the publication database into another database with the
keep_replication switch. Then script it out and run it in the original
database.
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
"Nicols Donoso" <Nicols Donoso @.discussions.microsoft.com> wrote in message
news:31ADDAF0-6E01-443A-891D-D33AB4EC1A67@.microsoft.com...
> Hi,
> I accidentaly remove a publication, I need to restore it!!!
> What Date Base I must restore?
> I Restore de Distribution database and only restore de Agents but not de
> publication.
>
>

Restoring Merge Publication

I'm looking for a little help in preparing a disaster recovery staragey for
merge replication. We are desigining a replication topology that includes
publishers, named Republishers and several hundred anonymous merge
subscribers.
The "top tier" publisher will only talk to named subscribers, so its
recovery via a restore and then synchronizing with the named subscribers
should be fine. The problem I see is with the "tier 2" (republisher with
anonymous subscriptions to it) may not be recoverable according to the
excerpt below from the books online.
The situation would be Anonymous sub updates a record, it is replicated to
the "tier 2" box. The "Tier 2" box dies and is restored from several days
earlier. This "tier 2" republisher is synchonized with the "top tier"
publisher bringing it fairly current. The Anonymous subscriber now
synchronizes again with the restore tier 2 box.
Does it resend it's update? What specifically is missing on anoymous
subscribers that will cause an issue?
Any insight is appreciated!!!
"Caution If you synchronize with a subscription database, you must
synchronize with one that has a global subscription (that is, a subscription
having an assigned priority value) to guarantee correct convergence behavior.
Do not synchronize the publication database with a subscription database that
has an anonymous subscription. Because anonymous subscriptions do not have
enough meta data to apply changes to the publication database, such
synchronization could lead to the non-convergence of data."
Dear Brain,
If i understand ur questation then i suggest that doing replication is not
the best best thing and it take lot of time for replication and as u
mentioned u r going for 2 tier and if replication fails then it is a problem
for u.
So i tell u i had faced the same problem and i created a job and a cursor in
which i update all my tables every 2 hour mintues in the cursor i mentioned
that when the updation is complete in one database then it shift to other
changing the ip address of the server.
U can also update all the datebase server at a time. I had 1500 tables and 8
remotes location and it take only one hour to update.
if i had did wrong then feel free to tell me to update my knowledge.
from sufian
"Brian Reuter" wrote:

> I'm looking for a little help in preparing a disaster recovery staragey for
> merge replication. We are desigining a replication topology that includes
> publishers, named Republishers and several hundred anonymous merge
> subscribers.
> The "top tier" publisher will only talk to named subscribers, so its
> recovery via a restore and then synchronizing with the named subscribers
> should be fine. The problem I see is with the "tier 2" (republisher with
> anonymous subscriptions to it) may not be recoverable according to the
> excerpt below from the books online.
> The situation would be Anonymous sub updates a record, it is replicated to
> the "tier 2" box. The "Tier 2" box dies and is restored from several days
> earlier. This "tier 2" republisher is synchonized with the "top tier"
> publisher bringing it fairly current. The Anonymous subscriber now
> synchronizes again with the restore tier 2 box.
> Does it resend it's update? What specifically is missing on anoymous
> subscribers that will cause an issue?
> Any insight is appreciated!!!
>
> "Caution If you synchronize with a subscription database, you must
> synchronize with one that has a global subscription (that is, a subscription
> having an assigned priority value) to guarantee correct convergence behavior.
> Do not synchronize the publication database with a subscription database that
> has an anonymous subscription. Because anonymous subscriptions do not have
> enough meta data to apply changes to the publication database, such
> synchronization could lead to the non-convergence of data."
>