We have a transactional replication setup using 3 SQL Servers, 1st as publisher, 2nd as distributor, and 3rd as subscriber.
We have an activity to change the location of the replicated DB (subscriber) using de-attach and attach method. During this activity, I will need to stop the SQL server and hence all replicated transactions will fail.
What's the proper way to pause the replication during this activity, so when I attach the DB again and start the SQL service, replication will resume normally.
Thanks
Please see the following link for details of how to accomplish this:
Start and Stop a Replication Agent
The above article doesn't appear to give information on stopping the distribution agent, this can be achieved by using the stored procs detailed in the link below:
Start/Stop SQL Server Replication Agent using TSQL
Related
I have read this great Remus Rusanu's article
http://rusanu.com/2009/08/05/asynchronous-procedure-execution/
How to implement this idea:
I have a big main table, user can mark 'as delete' records there (set field to 1)
I cannot use SQL Jobs because customers can use SQLExpress.
The idea is: when user 'delete' or 'undelete' records in big table need to send message to a queue.
An activation proc 'fire and forget' proc to execute real Delete statement for marked records in the main table - all or parts, it depends.
But need maximally to avoid blocking.... That's why the question:
How to execute real deletion when SQL Server has a lowest loading? or when database has a lowest activity?
How to detect these 'Low database loading' moments in the async proc?
There is no way to lync Service Broker activation directly to workload and only activate during 'low activity'.
I cannot use SQL Jobs because customers can use SQLExpress
While is true that SQL Server Express Edition lacks SQL Agent scheduling, there are work arounds using Service Broker conversation timers. See Scheduling Jobs in SQL Server Express (and part 2).
I want to create a stored procedure/ Job that will monitor all the SQL server Agent job. When any of the SQL Server Agent's jobs fail it will send and email with the job name to the admin.
What is the best way to create such a job that will monitor all jobs.
You can approach this issue in several ways. From top of my head you can use either a SSRS report scheduled for auto delivery. Or a SQL agent job that run periodically.
In both cases the an underlying stored procedure needs to be built that queries sysjobs and related tables in MSDB.
I have been looking into this project for a side-by-side upgrade solution. The most widely suggested/used solution is to do a full back of SQL Server 2000 database and restore on SQL Server 2008 with norecovery. Then restore the subsequent transaction log backups with norecovery. When we are ready to switch, change SQL Server 2000 to read-only mode, backup the tail-log and restore it on SQL Server 2008 with recovery. Then bring SQL Server 2008 online.
But, can't the upgrade be done with transactional replication where SQL Server 2000 is the publisher and SQL Server 2008 is the subscriber. Script all objects such as logins, indexes, etc and apply to SQL Server 2008. When we are ready to switch, we will stop replication, delete all replication jobs, and switch all apps to connect to SQL Server 2008. I haven't found anyone that suggests this method. Is there anything wrong with it?
The method of data migration you describe is possible to perform using SQL Server Replication.
There is nothing wrong with this method or any other data migration method for that matter, so long as the choice you decide upon addresses the specific requirements of your project/application platform.
That said the method you describe is certainly more technically involved in both the configuration and implementation of the actual migration steps. If you can accept downtime, a simple backup and restore process is certainly going to be much more straight forward. Log shipping would also be another simpler migration method.
So far, you know that the replication method could work in theory. Now is the time to build out a working solution in test in order to validate your data migration strategy and to practice the implementation process.
If you aren't replicating otherwise, creating a replication subscription will change your schema and a few settings.
For example, you may end up with GUIDs generated for all your rows just to facilitate the replication.
Caution - transactional replication will turn off all IDENTITY columns at the subscriber (the transactional replication SPs actually depend on this fact, as they insert into the IDENTITY columns without first specifying IDENTITY_INSERT ON). I can only confirm this is the case when the subscriber is SQL 2000 as well - perhaps the subscriber on 2008 will behave differently.
For this reason, transactional replication with SQL 2K doesn't really give you a hot standby. We had to do a fair bit of SQL tweaking (re-instating the IDENTITY columns & re-writing the replication SPs with IDENTITY_INSERT wrappers) to get ourselves a situation where the subscriber actually works as a hot standby, ready to have applications pointed at it. But it certainly wouldn't work out of the box =)
Yes, it will work, provided that you transfer the other objects over.
I have done replication on my SQL Server 2005 database.
Now i want to show the status from my GUI.(Can be C# or else)
Is there is any method or API by which i can monitor the status of replication.
This is for client confirmation that replication is working.
Thanks
Way something like this.
http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server-replication/11698/How-to-get-the-replication-status-using-RMO-in
A great option is this: How to Programmatically Monitor Replication (via T-SQL):
http://msdn.microsoft.com/en-us/library/ms147874(SQL.90).aspx
And here's the SQL Server 2008 R2 version for anyone looking at this as well:
http://msdn.microsoft.com/en-us/library/ms147874(SQL.100).aspx
Using these special procedures can be a tiny bit of a pain from within T-SQL (as you'll commonly want to export their output into temp tables or table variables to 'filter it' an additional bit or what-not), but most devs will find this kind of interaction MUCH easier to deal with than using RMOs.
I like to use tracer tokens posted at regular intervals and then monitoring their status as they flow from publisher to distributor to subscriber. This can be done programatically with sp_posttracertoken at the publisher and checking the tracer token tables in the distributor. Hope this helps.
Monitoring Replication with Replication Monitor
Microsoft SQL Server Replication
Monitor is a graphical tool that
allows you to monitor the overall
health of a replication topology.
Replication Monitor provides detailed
information on the status and
performance of publications and
subscriptions...
How to: Start Replication Monitor (Replication Monitor)
How can we find out that if a replication job or normal replication is running at a particular time. Please,help to figure out.
Assuming you are referring to Microsoft SQL Server Replication, here is a quick method to observe replication status.
In the database hosting the publication go to Object Explorer tree view:
1. Open Local Publications folder under Replication
2. Right Click on a publication select Log Reader Status
The log reader agent will be reading the transaction log and populating the distribution database with the changes that need to be pushed to subscriber.
An active log agent will show in the status window messages such as:
63 transactions with 439 command were delivered
Nevertheless, this diagram explains pretty quickly how the transactional replication works.
Replication Architecture (BOL: http://msdn.microsoft.com/en-us/library/ms151176.aspx)
In MS SQL if you need to programatically check a job status (for example from a monitoring tool) you can fire off the following query. For push replication the target would be the replication distributor (or the publisher if you haven't scaled out distribution). For pull replication the target would be the replication subscriber.
EXEC msdb..sp_help_job #job_name='<job name here>', #job_aspect = N'job'
You can find the job name under the SQL server agent for the distributor/subscriber.
You're looking for column 26 ("current_execution_status"), which will be "1" if the job is currently running.
In order to monitor replication you need to use the Replication Monitor tool.
The following article describes how to use this tool.
http://msdn.microsoft.com/en-us/library/ms151780(SQL.90).aspx
Cheers, John
sp_distcounters tells you the current status.
If the count of delivered commands changes for a given subscription then your replication is working, else not.