Showing posts with label publications. Show all posts
Showing posts with label publications. Show all posts

Wednesday, March 7, 2012

Looking for table / view that will tell me if I need to reinitialize subscription

I have kind of unique situation. I am running Merge replication. In one of my publications I am only publishing procedures/functions/views. By design, these do not change that often, but when a programmability object changes, it is scripted in a way so that:

1. The article is dropped from the publication

2. the object is then changed

3. The article is added back to the publication

My question is: Is there a table or view that the subscriber or publisher can see that could tell me if reinitialization needs to occur. I am looking at adding an automated script at the subscriber that makes the determiniation and automatically reinitializes the subscription. My alternative is to force the subscriber to reinitialize every time when synchronizing with this publication, even if nothing has changed because the process has to be automated.

Thanks,

Bill

Are you using SQL 2000 and 2005? In SQL 2005, you don't need to drop/recreate articles in order to change the schema. You can directly do ALTER TABLE/VIEW/FUNCTION. For more info, please take a look at BOL http://msdn2.microsoft.com/en-us/library/ms151870.aspx.

Peng

|||I am using 2005, but that will not work, as the publication only contains programmability objects, the underlying base tables are in another publication.|||Not sure what you mean by that will not work. What Peng means is that when you need to change one your progammability article like stored proc or view etc, you can just run alter view or alter proc ... and this DDL action will be replicated when using SQL 2005. so you dont need to drop the article, alter it and readd it. Hence you will not even need to reinitialize your subscriptions.|||When you execute a DDL statement against a view that: is in a publication without any tables in that publication, the query will run but will not complete execution.|||This is a known issue and the workaround is to add a dummy table in that publication.|||When you say create a dummy table, what exactly do you mean? Is this just the "real" table name with one column or something else?|||

Correct, create a non-necessary table that means absolutely nothing. i.e.

create table dbo.t1 (col1 int primary key, col2 int)

Add this as an article to your publication, then your DDL statements should work.

Looking for suggestions Cluster or Mirror

Hello,

We currently have one instance of SQL2k5 SP1. We have a couple of publications, and 30 subscribers, on the instance and are considering going to either a cluster environment or db mirroring. Currently our instance seems to be busy and I am wondering if clustering really gives it a performance boost. What are your thoughts/suggestions on going to a cluster environment versus just db mirroring? Can mirroring be used for real-time failover as we need to add that as well? Thanks in advance.

John

Fail-over clustering and database mirroring are both high availability solutions that don't have any direct effect on performance. Fail-over clustering relies on shared external storage between the nodes (which is a potential single point of failure), and requires higher-end hardware in most cases. It works at the instance level. Failing over a node in the cluster typically takes 1-2 minutes on a large, active database instance.

Database mirroring works at the database level(not the instance level). There are two copies of the data (one on the Principle and one on the Mirror), so you need twice the storage space. Only the Principal database is available to service clients. If you want automatic fail-over with DB Mirroring, you need a Witness Server. You have to be running in Synchronous mode with Saftey turned on to get automatic fail-over with DB Mirroring. Database fail-over with mirroring is more like 10-15 seconds.

If you are doing Replication, it will might be easier to do fail-over clustering.

|||

here are some resources that may be helpful in your decision-making:

Failover Clustering white paper:

http://www.microsoft.com/downloads/details.aspx?FamilyID=818234dc-a17b-4f09-b282-c6830fead499&DisplayLang=en

Database Mirroring:

http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirfaq.mspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/technologies/dbm_best_pract.mspx

SQL Server 2005 High Availability Resources:

http://www.microsoft.com/technet/prodtechnol/sql/themes/high-availability.mspx

Looking for suggestions Cluster or Mirror

Hello,

We currently have one instance of SQL2k5 SP1. We have a couple of publications, and 30 subscribers, on the instance and are considering going to either a cluster environment or db mirroring. Currently our instance seems to be busy and I am wondering if clustering really gives it a performance boost. What are your thoughts/suggestions on going to a cluster environment versus just db mirroring? Can mirroring be used for real-time failover as we need to add that as well? Thanks in advance.

John

Fail-over clustering and database mirroring are both high availability solutions that don't have any direct effect on performance. Fail-over clustering relies on shared external storage between the nodes (which is a potential single point of failure), and requires higher-end hardware in most cases. It works at the instance level. Failing over a node in the cluster typically takes 1-2 minutes on a large, active database instance.

Database mirroring works at the database level(not the instance level). There are two copies of the data (one on the Principle and one on the Mirror), so you need twice the storage space. Only the Principal database is available to service clients. If you want automatic fail-over with DB Mirroring, you need a Witness Server. You have to be running in Synchronous mode with Saftey turned on to get automatic fail-over with DB Mirroring. Database fail-over with mirroring is more like 10-15 seconds.

If you are doing Replication, it will might be easier to do fail-over clustering.

|||

here are some resources that may be helpful in your decision-making:

Failover Clustering white paper:

http://www.microsoft.com/downloads/details.aspx?FamilyID=818234dc-a17b-4f09-b282-c6830fead499&DisplayLang=en

Database Mirroring:

http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirror.mspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/dbmirfaq.mspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/technologies/dbm_best_pract.mspx

SQL Server 2005 High Availability Resources:

http://www.microsoft.com/technet/prodtechnol/sql/themes/high-availability.mspx