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.
Related
Assuming View1 is based on Table A,B and C on Server1.
Table A,B and C are replicated to Server2 using Transactional Replication.
View1 is created on Server2.
ASK:
So will View1 on both the servers reflect the same data (discounting the replication delay)?
If they do, then what are the other reasons we replicate Views?
If the script of a View is changed at Publisher, do the changes reflect on the subscriber?
So will View1 on both the servers reflect the same data (discounting the replication delay)?
Yes,the view in general queries the underlying tables
If they do, then what are the other reasons we replicate Views?
In simple terms ,if you want your view to be used by applications that access server2 you need to replicate view
If the script of a View is changed at Publisher, do the changes reflect on the subscriber?
Yes DDL Changes are supported..
From MSDN.
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 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.
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.
Is there a way to replicate a sql server database but not push out deletes to the subscribers?
You don't mention which version of SQL Server you're running, but Andy Warren wrote an article on configuring INSERT, UPDATE, and DELETE behaviour in SQL Server 2005. You can configure this through the GUI, using his instructions:
http://www.sqlservercentral.com/articles/Replication/3202/
It's tempting to 'intervene' in a normal replication and 'disarm' the subscriber's side delete stored procedures, but this leaves no option to recover from replication failure. If the replication tries to recover, a reinitialize may be needed and this will drop any 'stale' data that the replication agent considers deleted.
An alternative is to use a normal replication, and use a script that generates insert and update triggers on all tables in the subscriber database, that insert/update that data into yet a third database. This way the third DB will collect all the data that ever existed, the second DB can re-initialize it's subscription if it needs to (when you do, just remember that bulk inserts don't call the insert trigger and check for new data and add it to the third DB), and the first DB doesn't have to perform the extra work that the triggers are.
Do this....Drop the article. Create a new storedprocedure in the corresponding database that mimicks the system store procedure (sp_del...) and contains the same parameter but does nothing. Add the article again...and set the delete store procedure under the article's properties to the new delete stored procedure that you created....
Or you can select Do not replicate Delete Statements....I think that works but i haven't tried it.
We're having a problem with a merge replication. Our publisher runs SQL Server 2008, while our two subscribers run 2005. Our publisher is trying to send an ALTER TABLE Foo SET (LOCK_ESCALATION) command out to our subscribers. I think I remember reading that this command is new in SQL Server 2008, and if so, it makes sense that the command would fail on our 2005 servers. Our merge replication is set up for 2005 compatibility, however.
The schema script 'if object_id(N'[dbo].[Users]') is not null exec('ALTER TABLE [dbo].[Users] SET (LOCK_ESCALATION = TABLE)
')' could not be propagated to the subscriber.
Any ideas on why our publisher would be trying to do this?
Edit: Our 2008 server's compatibility level is set to "Sql Server 2005 (90)"
Its a new feature in sql 2008 so not supported in 2005. Depending on how complex your setup is you may want to consider have your database run in compatibility 90 (sql 2005) to make sure you dont add sql 2008 features to your database. Have had big issues with replication of schema data ever since it came about so always a bit reticent. I always try and make it act dumb and just manage data - had to support a merge system with 32 subscribers with merge replication and had big schema issues constantly when we pushed schema changes.
That said if it works as documented it shouldn't be trying to push your lock change. Check the subscriptions are marked as sql 2005 compatible. Its likely they haven't created an auto map of the setting from 2008 to 2005 in the way they did for data types (for example)
One of the SQL dev guys blogged on the new locking types a while back
This occurs because the incompatibility of this instruction with sql server 2005 and aparently when I do a schema change in a table that is replicating puts this instruction in the schema changes.
There are two ways: Remove and create again the suscription, not applicable when It's in production server. Second way is go to sysmergeschemachange table in the database and delete the row that has something like this:
The schema script 'if
object_id(N'[dbo].[Users]') is not
null exec('ALTER TABLE [dbo].[Users]
SET (LOCK_ESCALATION = TABLE) ')'
could not be propagated to the
subscriber.
I hope this helps.
Is there a built in way in SQL Server 2005 to audit things specifically like deleting a stored procedure? Is there a history table that I can query? We have a mystery sproc that has disappeared a few times now.
You can build this using DDL triggers:
http://msdn.microsoft.com/en-us/library/ms190989.aspx
Only if you use DDL triggers or use profiler to trace text "%DROP%PROC%procname%"
Note that in SQL Server 2008 they also now have AUDIT to replace Profiler Traces for auding activities. It is similar but has its own configuration UI and UI to view results
You can setup a profiler trace to capture the Audit Schema Object Management event and filter based on the database name you care about. Any time an object in the schema is created, dropped, edited it will fire an event in profiler that includes the person who did the change and the name of the stored procedure.
You will want at least these profiler columns:
ApplicationName - name of app user was running when they made change
DatabaseName - Databse containing the object changed
EventSubClass - Type of action shows Alter, Modify, Drop, Create etc
LoginName - user making change
ObjectName - object affected
[late one but adds details on how to see who made the change even before auditing system is put into place]
Others have already covered different ways you can start auditing data in order to monitor future changes but if you originally didn’t have any auditing system in place then it’s very difficult to find out who did what and when historically.
Only option is to try reading transaction log assuming database is in full recovery mode. Problem is that this is not supported by default. Options are:
Third party tools such as ApexSQL Log or Quest Toad
Undocumented functions such as DBCC LOG or fn_dblog
See these topics for more details:
How to view transaction log in SQL Server 2008
SQL Server Transaction Log Explorer/Analyzer
How to see query history in SQL Server Management Studio
I agree. It can be the SQL Server profiler with filters. The DDL triggers existed in SQL Server.
You could create something like this:
CREATE TRIGGER ddl_drop_procedure
ON DATABASE
FOR DROP_PROCEDURE
AS
RAISERROR ('You deleted a stored procedure',10, 1)
GO
The other option is to use third party tools like Auto Audit from codeplex, or apexSQL trigger.