Hi friends, Good Morning
Hey there is a question, i have two servers where replication is implemented, The two servers is used to take backup on dailybasis, on one server we take differential backup, and on second server we take transactional backup on same time, when we restore the backups on the opposite servers (backup taken on 1st server will be restored on 2nd server and 2nd server backup will be restored on 1st server)what are contents u find difference in the dataIs that how you implemented replication? By crossing the restores?|||Take a look - it will help you to know more details about backuping for replicated databases
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/replsql/replbackup_8enn.asp
Showing posts with label transactional. Show all posts
Showing posts with label transactional. Show all posts
Thursday, March 8, 2012
Saturday, February 25, 2012
Backups
Hi All,
We have setup Transactional Replication with queued updating subscribers option. Our Servers are in Failover cluster with windows 2000 AS. We are doing Full and Transactional log backups as usual. Can any one suggest what are the recovery scenarios, in ca
se of Publisher (if it is completely down, I mean all clusters are down) and User interactions to Subscriber immediately, so that data is more than of Publisher db.
Please provide us valuable suggestions.
Thanks,
John.
I'm not exactly sure what your question is. You loose me with this statement
:
"so that data is more than of Publisher db. "
With queued Updating, your Subscriber is essentially a mirror of your
Publisher's data. If your Publisher goes offline permanently you will lose
transactions that are on your publisher and haven't made their way back to
the Subscriber.
So, its not too hard to clone your Subscriber to rebuild your Publisher. To
do this you would have to drop your subscriber, copy the subscriber schema
and data to the publisher, re run your publication scripts on your new
publisher, and do a no-sync subscription.
If your Publisher goes offline for an extended period your chance of
bringing it back on line without conflicts increases. With Queued Updating
the conflict view only lets you view conflicts, not resolve them.
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:1D2A989A-5347-4E74-AAD6-707E9EC9CE70@.microsoft.com...
> Hi All,
> We have setup Transactional Replication with queued updating subscribers
option. Our Servers are in Failover cluster with windows 2000 AS. We are
doing Full and Transactional log backups as usual. Can any one suggest what
are the recovery scenarios, in case of Publisher (if it is completely down,
I mean all clusters are down) and User interactions to Subscriber
immediately, so that data is more than of Publisher db.
> Please provide us valuable suggestions.
> Thanks,
> John.
>
|||The best suggestion I have is to look in BOL for the article about the
"synch with backup" option that can be used. This will not only walk you
through these scenarios, but explain how to create coherent, multi-server
backups.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
We have setup Transactional Replication with queued updating subscribers option. Our Servers are in Failover cluster with windows 2000 AS. We are doing Full and Transactional log backups as usual. Can any one suggest what are the recovery scenarios, in ca
se of Publisher (if it is completely down, I mean all clusters are down) and User interactions to Subscriber immediately, so that data is more than of Publisher db.
Please provide us valuable suggestions.
Thanks,
John.
I'm not exactly sure what your question is. You loose me with this statement
:
"so that data is more than of Publisher db. "
With queued Updating, your Subscriber is essentially a mirror of your
Publisher's data. If your Publisher goes offline permanently you will lose
transactions that are on your publisher and haven't made their way back to
the Subscriber.
So, its not too hard to clone your Subscriber to rebuild your Publisher. To
do this you would have to drop your subscriber, copy the subscriber schema
and data to the publisher, re run your publication scripts on your new
publisher, and do a no-sync subscription.
If your Publisher goes offline for an extended period your chance of
bringing it back on line without conflicts increases. With Queued Updating
the conflict view only lets you view conflicts, not resolve them.
"John" <anonymous@.discussions.microsoft.com> wrote in message
news:1D2A989A-5347-4E74-AAD6-707E9EC9CE70@.microsoft.com...
> Hi All,
> We have setup Transactional Replication with queued updating subscribers
option. Our Servers are in Failover cluster with windows 2000 AS. We are
doing Full and Transactional log backups as usual. Can any one suggest what
are the recovery scenarios, in case of Publisher (if it is completely down,
I mean all clusters are down) and User interactions to Subscriber
immediately, so that data is more than of Publisher db.
> Please provide us valuable suggestions.
> Thanks,
> John.
>
|||The best suggestion I have is to look in BOL for the article about the
"synch with backup" option that can be used. This will not only walk you
through these scenarios, but explain how to create coherent, multi-server
backups.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com
Backups
I have transactional replication topology where each component is on
its own server. I currently backup the t-logs every 15 minutes with a
differential at noon and a full back up at midnight.
Is it necessary for me to create the exact same backup strategy at the
distributor and subscriber? Or would a full backup with less frequent
t-log backups be sufficient for the distribution and subscription
databases?As you did not mention which version of your SQL Server, I'll post 2
choices.
There is an article about "Strategies for Backing Up and Restoring
Transactional Replication" for SQL Server 2000 in Books Online. You may want
to check it out?
http://msdn2.microsoft.com/en-us/library/aa237094(SQL.80).aspx
And this is for SQL Server 2005:
http://msdn2.microsoft.com/en-us/library/ms152560.aspx
--
Ekrem Önsoy
"NC3" <ncoleman3@.yahoo.com> wrote in message
news:1191534232.786974.23060@.o80g2000hse.googlegroups.com...
>I have transactional replication topology where each component is on
> its own server. I currently backup the t-logs every 15 minutes with a
> differential at noon and a full back up at midnight.
> Is it necessary for me to create the exact same backup strategy at the
> distributor and subscriber? Or would a full backup with less frequent
> t-log backups be sufficient for the distribution and subscription
> databases?
>
its own server. I currently backup the t-logs every 15 minutes with a
differential at noon and a full back up at midnight.
Is it necessary for me to create the exact same backup strategy at the
distributor and subscriber? Or would a full backup with less frequent
t-log backups be sufficient for the distribution and subscription
databases?As you did not mention which version of your SQL Server, I'll post 2
choices.
There is an article about "Strategies for Backing Up and Restoring
Transactional Replication" for SQL Server 2000 in Books Online. You may want
to check it out?
http://msdn2.microsoft.com/en-us/library/aa237094(SQL.80).aspx
And this is for SQL Server 2005:
http://msdn2.microsoft.com/en-us/library/ms152560.aspx
--
Ekrem Önsoy
"NC3" <ncoleman3@.yahoo.com> wrote in message
news:1191534232.786974.23060@.o80g2000hse.googlegroups.com...
>I have transactional replication topology where each component is on
> its own server. I currently backup the t-logs every 15 minutes with a
> differential at noon and a full back up at midnight.
> Is it necessary for me to create the exact same backup strategy at the
> distributor and subscriber? Or would a full backup with less frequent
> t-log backups be sufficient for the distribution and subscription
> databases?
>
Subscribe to:
Posts (Atom)