I currently have SQL Server Transactional replication running. Server A (Publisher & Distributor) to Server B (Subscriber). Everything is working great. I just need to know whether i can add a table to the subscriber only in that database? will it affect my replication? must the databases be the exact same in terms of schema etc?
I need to add a table that's not part of the publishers published articles on Server B(Subscriber).
I just need to know whether i can add a table to the subscriber only
in that database?
Yes, you can. It won't affect to the replication, but, for example, if you create table dbo.A on subscriber database first and later you'll create table with the same name and schema on publisher database you can lost data in table dbo.A on subscriber because by default new articles on the subscriber will be drop if exists within initialize process.
You can change this behavior in publication properties.
must the databases be the exact same in terms of schema etc?
No, it must not. In transaction replication you can replicate either whole tables or some columns of those tables.
Related
I have a specific requirement in Transactional Replication, but I am not sure whether it is achievable or not. Could you please help me out if there is any possible way to achieve the same.
Requirement:
As per the requirement, there will be two databases. One is the publication database and another is subscription database.
I want to replicate some of the tables (articles) of the publication database to the subscription database. But what I want is to replicate data only. Because I want to keep those tables (replicating tables) to always present in the subscription database, they may be the empty table initially and when replication starts, these tables may get their data from publication database.
But I don't want the replication to create these tables for me in subscription database. I want to use already created tables. They will have the same schema as publication database tables.
When you configure a publication, you can set the properties for articles. One of the article properties is called Action if name in use. You can set that to the option Keep existing object unchanged.
I don't have much experience on SQL replication(SQL Server 2014). My client have a replication process which was created by his previous contractor. It worked well and suddenly it stopped replicating DDL statements couple of days ago. We have not done any change related to replication. When I checked data, subscriber has received up to date data. Only DDL statements have the problem. It uses transactional replication.
When I searched on web it says that the "Replicate schema changes" option need to set as true on Publication Properties.In my case it was already set to true.
Is there anyway for me to fix this and again have DDL statements to replicate as earlier?
Thank you
SQL Server Replication does support schema changes, but not all of them. In your case, CREATE PROCEDURE is not a supported schema change. Why? It's not an article yet, and not marked for replication, thus it cannot be replicated - replication has no way of knowing whether or not you would want that object replicated.
However, if you create the stored proc, then create an article for it, then issue an ALTER PROCEDURE, you will see the change replicated.
Please see article Make Schema Changes on Publication Databases:
Replication supports a wide range of schema changes to published objects. When you make any of the following schema changes on the appropriate published object at a Microsoft SQL Server Publisher, that change is propagated by default to all SQL Server Subscribers:
ALTER TABLE
ALTER TABLE SET LOCK ESCALATION should not be used if schema change replication is enabled and a topology includes SQL Server 2005 or SQL Server Compact 3.5 Subscribers.
ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER
ALTER TRIGGER can be used only for data manipulation language [DML] triggers because data definition language [DDL] triggers cannot be replicated.
Please ensure you read the whole article, to be fully aware of what can be replicated, and under what circumstances.
How do you preserve the File Group on the Subscriber of a Merge Replication Publication?
I created identical databases with 3 filegroups for various groups of tables, assigned to the appropriate filegroups when the tables were created.
The first time I created a publication (populated publishing database first, data went into correct filegroups) the tables on the subscriber were all dropped and recreated in the default filegroup of the subscriber.
OK, so I changed the "Action if name is in use" property to Truncate data in destination tables on initialization: snapshot ran fine, subscriber sync failed because it said it could not execute the script to add the rowguid column to the tables.
So what is the best way to keep the filegroups from changing? I want the data to go into the desired file groups when it is pushed by the publisher to the subscriber.
After yet more research, it turns out there is a flag in the the Article Properties called "Copy file group associations" which is set to FALSE by default.
It wouldn't let me just change it, had to rebuild the publication, but doing so and setting the FLAG to true recreated the tables with the desired Filegroups on the subscription databases and after snapshot creation, the subscriptions pushed and the data flowed into the correct filegroups. Sweet!
I have the following questions about how transactional replication handles the following. For the sake of example, assume database 'A' is being replicated (via transactional replication) to database 'B'.
If a table in database ‘A’ is dropped, will the table get dropped in ‘B’?
If a table in ‘A’ is renamed, what happens to the table in ‘B’?
If we drop a column in a table in database ‘A’, what will happen to the column in the same table in database ‘B’?
If we rename a column in a table in database ‘A’, what will happen to the column in the same table in database ‘B’?
Is replicating stored procs, views and UDF’s are optional?
Is there any way to avoid all the stored process being created in database ‘B’ as a result of it being the subscriber of a replication?
a. If not, can we at least dictate what schema they are created in?
Most of your questions are answered here: Frequently asked questions for Replication Administrators
You cannot drop a table that is replicated. You have to first drop the article.
You cannot rename a table that is replicated. You have to first drop the article.
Issuing ALTER TABLE … DROP COLUMN at the Publisher, will result in the command being replicated to the Subscriber.
You cannot rename a column "whilst" it is being replicated. You need to remove it from replication first.
Yes, it's optional.
What do you mean by created?
All of these items can be tested very easily by creating a very simple Replication topology on a test server. I suggest you do so in order to both plan for and practice your changes.
Background information
Let's say I have two database servers, both SQL Server 2008.
One is in my LAN (ServerLocal), the other one is on a remote hosting environment (ServerRemote).
I have created a database on ServerLocal and have an exact copy of that database on ServerRemote. The database on ServerRemote is part of a web application and I would like to keep it's data up-to-date with the data in the database ServerLocal.
ServerLocal is able to communicate with ServerRemote, this is one-way traffic. Communication from ServerRemote to ServerLocal isn't available.
Current solution
I thought it would be a nice solution to use replication. So I've made ServerLocal a publisher and subscriptions are pushed to the ServerRemote. This works fine, when a snapshot is transfered to ServerRemote the existing data will be purged and the ServerRemote database is once again an exact replica of the database on ServerLocal.
The problem
Records that exist on ServerRemote that don't exist on ServerLocal are removed. This doesn't matter for most of my tables but in some of my tables I'd like to keep the existing data (aspnet_users for instance), and update the records if necessary.
What kind of replication fits my problem?
Option C: Transactional replication.
I've done this before where you have data in a subscription database and don't want it overwritten by the snapshot. You can set your initial snapshot to not delete the existing records and either don't create the records that are in the publisher (assume they are there) or create the records that are in the publisher (assume they are not there).
Take a look at what would be correct for your situation or leave a comment with more details on how you get your data in the subscriber originally. I'm not too familiar with aspnet_users and what that is. Transactional replication only helps if you don't want the data in the subscriber back at the publisher. If you want that you'll have to do merge replication.