1、解决实时数据同步，请参阅：
10年积累的成都网站建设、网站设计经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先建设网站后付款的网站建设流程，更有王屋免费网站建设让你可以放心的选择与我们合作。
Sql Server 2008 数据库实时同步复制
网页链接
2、监控，请参阅 ：sql server profile怎么监控跟踪性能语句
网页链接
具体步骤如下：
1.首先使用下面的命令，将有关的跟踪标志启用。
SQL codeDBCC TRACEON (3605,1204,1222,-1)
说明：
3605
将DBCC的结果输出到错误日志。
1204 返回参与死锁的锁的资源和类型，以及受影响的当前命令。
1222
返回参与死锁的锁的资源和类型，以及使用了不符合任何 XSD 架构的 XML 格式的受影响的当前命令(比1204更进一步,SQL
2005及以上可用)。
-1 以全局方式打开指定的跟踪标记。
以上跟踪标志作用域都是全局，即在SQL
Server运行过程中，会一直发挥作用，直到SQL Server重启。
如 果要确保SQL Server在重启后自动开启这些标志，可以在SQL
Server服务启动选项中，使用 /T 启动选项指定跟踪标志在启动期
间设置为开。(位于SQL Server配置管理器-SQL
Server服务-SQL Server-属性-高级-启动参数)
在运行上面的语句后，当SQL
Server中发生死锁时，已经可以在错误日志中看到了，但还不够直观(和其它信息混在一起)。（SSMS
- SQL Server实例 -
管理 - SQL Server日志）
2.建表，存放死锁记录
SQL codeUSE [Cole] --Cole是我的示例数据库，你可以根据实际情况修改。 GO
CREATE TABLE DeadLockLog ( id int IDENTITY (1, 1) NOT NULL, LogDate DATETIME, ProcessInfo VARCHAR(10), ErrorText VARCHAR(MAX) )
GO
3.建立JOB
新建一个JOB（假设名称为DeadLockJob）,在"步骤"中新建一步骤，随便写一个步骤名称，数据库为"Cole",在"命令"栏中输入以下语句：
SQL code--新建临时表 IF OBJECT_ID('tempdb.dbo.#ErrorLog') IS Not Null
DROP TABLE #ErrorLog
CREATE TABLE #ErrorLog (Id int IDENTITY (1, 1) NOT NULL, a DATETIME, b VARCHAR(10), c VARCHAR(MAX)) --将当前日志记录插入临时表
INSERT INTO #ErrorLog EXEC master.dbo.sp_readerrorlog --将死锁信息插入用户表
insert DeadLockLog
select a, b, c from #ErrorLog where id = (select MAX(id) from #ErrorLog WHERE c Like '%Deadlock encountered%')
DROP TABLE #ErrorLog
4.新建警报
在"新建警报"窗体的"常规"选项卡中,进行以下设置：
名称：可根据实际自行命名，这里我用DeadLockAlert
类型：选择"SQL
Server性能条件警报"
对象：SQLServer:Locks
计数器：Number of
Deadlocks/sec
实例：_Total
计数器满足以下条件时触发警报：高于
值：0
在"响应"选项卡中，选中"执行作业"，并选择步骤3中我们新建的作业(即DeadlockJob)
到这里为止，我们已经完成了全部步骤，以后，你就可以随时查询DeadLockLog表，来显示死锁信息了。
自定义性能监控
在这一点上，我假定你已经阅读了，或者至少浏览了所有监控步骤的建议。我猜你也许读了一些，但那些真正不适合于你。既然大部分的SQLServer安装稍微有点不同，那么这是有意义的。因此我建议你为你特定的环境自定义这个监控，添加或删除一些步骤使其更适合你的需求。
使用Word或Excel维护你的监控列表
当你对你的每一个SQLServer进行监控时，你需要一个方法去记录结果。当你有大量的选项时，从这一系列的文章里复制适合的监控列表到你的Word或Excel文档作为起点是比较快速的方法。你可能要为每个服务器创建一个单独的监控列表。如果你决定为你的监控表格使用Excel的话，你能输入所有的监控列表项目作为行，每一个监控的服务器作为单独的列。这样你能快速的查看每个SQLServer的结果。
设置SQLServer和数据库的优先级
如果你管理大量的SQLServer和数据库，你也许不知道从哪儿开始性能监控。理论上，你应该设置SQLServer和数据库的优先级，一些需要立即进行最多的性能监控，而其他的则不必进行那么多的监控。这会帮助你决定从哪儿开始。最可能的是，你将不会立即监控全部。相反，要在能监控的时候监控，按照从最重要到最不重要的顺序进行。
谨记性能监控的关键
当对SQLServer进行监控的时候
，记住目的是分辨并纠正容易的问题。但是，正如你所料，你将可能也分辨出一些更难于解决的问题。为了帮助你更好的管理有限的时间，你现在需要着眼于那些容易的问题，把困难的问题留到容易的问题先解决完之后。所以在你执行监控和分辨问题时，按照难易程度分类设置它们的优先级，将困难的问题留待你有足够时间处理它们的时候。
不要过早行动
当你执行监控时，你可能会急于对偶然遇到的问题进行纠正和修改。大多数情况下，那样做可能不是问题。但理论上，最好先执行监控，然后基于你的发现，决定正式动手解决你分辨出的问题，然后系统地实现它们。
一个推荐步骤，但或许会招来很多疑问
理想情况下，如有很多的时间，在服务器上执行一个性能基准是一个好的想法，然后执行监控，做任何需要的更改，再执行另一个性能基准去看看有什么情况发生。这会立即让你知道你所做的是否有帮助，大多数情况下，没有做正确的事。虽然这个建议被强烈的推荐，也许从时间来看不很实际。但如果你有时间的话，应该认真考虑。
另一个推荐步骤，但或许也会招来很多疑问
在执行监控之后，你也许发现在单个的SQLServer上所有需要的更改仅只有一两个，但在其他SQLServer上，也许需要做一打的更改。如果有那么的更改要做，不要立刻全部实现它们，仅仅一次一个或几个的更改也许是一个明智的选择。这样，你能够看看每个或每批更改对服务器产生的效果。如果你一次做了很多的更改，那么遇到问题时，你将不会知道是由哪个更改引起的问题，这要求你回滚所有的更改，然后一个一个的测试它们直到找到问题所在为止。
这个建议不会有太多疑问
如果你要做更改的服务器是有紧要事务的生产服务器，你要对你做的更改倍加小心。理论上，你应该在生产服务器应用更改之前在测试用的SQLServer上测试所有的更改。如果你不实践，那么每次仅做一个更改，确信如果有任何问题你知道怎样回滚更改。另外，试着选取一天中不很忙的时候做更改，万一有问题的话。
有一个取消计划
你因监控而做出的大多数更改应该能够很容易的回滚。但一些也许不那么容易。在那些情况下，你需要有一个万一需要的取消计划。例如，在你做出任何关键的更改之前备份系统和用户数据库。那样，即使出现问题，你也能将你的服务器恢复到更改之前的状态。我不是吓唬你不要做更改，但你总应该有所准备。
记录所有更改
当你基于性能监控做出更改时，确定你对所有的更改做了记录。这样，即使后来有什么问题，你也能更容易的找出错误所在。最容易记录下你的更改的方法可能就是把它们添加到你的监控表格里，或者其他你用来收集监控信息的文档里。
每年都要执行SQLServer的性能监控
许多SQLServer（并非全部）随着时间而改变。设置改变，打了SP补丁，甚至数据也改变了。所有的这些都会影响性能。确定你SQLServer最优性能的最好方法是做一个手工的性能监控。
你要闲着没事，系统的性能监控器里sql server的每个参数都可以看看啊，这要写可以写一本书了。
系统
内存: 可用字节数，page\sec
processor: processor time
physical disk:disk time
需要的话还有网络流量
至于sqlserver的监控，至少有
full scans/sec
cache hit ratio
transaction/sec
user connection
lock
number of dead lock/sec
query...
