Showing posts with label dbs. Show all posts
Showing posts with label dbs. Show all posts

Monday, March 26, 2012

principal db in "principal, synchronizing" state, the mirror in "restoring"

We have mirroring setup for 5 dbs, 4 of which are synchronized and 1 which is in "synchronizing" state on the principal and "restoring" state on the mirror. Mirroring for all dbs has been working fine for the past several months and we have a witness that has allowed automatic failover in the past without problems.

This database has several bulk inserts performed throughout the day and am sure there is some latency due to the size of these transactions.

Not sure as to why this is happening all of a sudden, but the db in question has been in this state for the past 12 hrs. I checked the mirroring status on the principal and it states that it is "synchronizing: data is being transferred from principal to mirror", but the mirror server states that db is in "restoring" state. Can anyone suggest as to how I can get the database on the mirroring server to get back to "mirror, synchronizing/restoring..." state? Or suggest on how I can troubleshoot this?

Thanks in advance.

Have you tried pulling up the Database Mirroring Monitor, to see what it shows? Do you have Unsent Log or Unrestored Log? Does the I/O subsystem on the mirror have comparable I/O capacity to the Principal?

Monday, February 20, 2012

Preventing subscrition expiration?

How can I prevent a subscription to a transactional publication from expiring?
Here's a brief overview of our situation. We have 2 db's on one server. One
of the db's is used for update, the other is used for search and retrieval
(read-only). Both db's have tables that are fulltext indexed. We would like
to be able to set up transactional replication so that updates can be applied
"on demand" without requiring that the indexes be rebuilt.
We've been successful at getting transactional replication to support this
scenario ... for a few days at a time! We have the need to go an extended
period of time (up to 2-3 weeks in extreme cases) without synchronizing,
however, it appears that the subscription expires and requires
re-synchronizing after 3 days.
The db that is getting updated is not very large (500mb) and only one user
performs updates on it. We have plenty of storage available, so space is not
a problem. I just need to figure out how to prevent to subscription from
expiring so that we can truly replicate "on-demand".
Thanks
MT
P.S. – we've ordered the recommended book on replication but it is not
scheduled to arrive until next week.
Hi MT,
If you right-click the publication in EM, you will see an option to change
the subscription expiration properties. You can set the hours to 32767
(about 3.7 years). The other option is to select the "Subscriptions never
expire, but they can be deactivated until they are reinitalized." This can
lead to other issues and I would opt for the former and not the later.
-Jose
"MTurner" <MTurner@.discussions.microsoft.com> wrote in message
news:F0F83E80-607C-482F-B3F5-CDCB797C63B2@.microsoft.com...
> How can I prevent a subscription to a transactional publication from
> expiring?
> Here's a brief overview of our situation. We have 2 db's on one server.
> One
> of the db's is used for update, the other is used for search and retrieval
> (read-only). Both db's have tables that are fulltext indexed. We would
> like
> to be able to set up transactional replication so that updates can be
> applied
> "on demand" without requiring that the indexes be rebuilt.
> We've been successful at getting transactional replication to support this
> scenario ... for a few days at a time! We have the need to go an extended
> period of time (up to 2-3 weeks in extreme cases) without synchronizing,
> however, it appears that the subscription expires and requires
> re-synchronizing after 3 days.
> The db that is getting updated is not very large (500mb) and only one user
> performs updates on it. We have plenty of storage available, so space is
> not
> a problem. I just need to figure out how to prevent to subscription from
> expiring so that we can truly replicate "on-demand".
> Thanks
> MT
> P.S. - we've ordered the recommended book on replication but it is not
> scheduled to arrive until next week.
>
|||You'll also need to change the transaction retention
period, and the history retention period.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Thanks - I think this is the piece of the puzzle that I've been missing.
I hate to ask but I'm not finding anything in books on-line - how do you
change the retention periods?
Thanks again
"Paul Ibison" wrote:

> You'll also need to change the transaction retention
> period, and the history retention period.
> Rgds,
> Paul Ibison SQL Server MVP, www.replicationanswers.com
> (recommended sql server 2000 replication book:
> http://www.nwsu.com/0974973602p.html)
>
|||Right-click on the replication monitor and select the distributor
properties - you'll see the settings there.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)