SQL Server 2005复制到许多从属服务器-硬件复制或更改策略

一个常见的模型是将主数据库复制到另一个节点,然后让另一个节点处理从那里复制数据的问题。它可以减轻主服务器的负载,而且还有一个好处,那就是,如果您的报告系统的复制确实达到了最大限度,那么它根本不会影响您的实时数据库。

我只做了少量的复制主机,但是如果您添加了足够多的节点,使您的分发节点无法全部复制,那么扩展层次结构可能是明智的,这样您的分发服务器实际上就可以复制到其他分发服务器,然后复制到您报告的节点。

您可以从单个节点复制多少数据库取决于您的报告数据需要的最新程度(例如,每天只复制一次是否合适,或者是否需要复制第二次)以及一次复制多少数据。如果1分发服务器没有实际运行主服务的开销,那么它可以为多少节点供电,这可能值得进行一些实验。

根据您要插入的内容,对于SQL Server来说,每分钟100000次写入的负载相当轻。在 my book 我展示了一个例子,在一台具有简单硬件的机器上,每秒生成40000次写入(2.4米/分钟)。因此,一种方法可能是使用批处理更新、每个事务多次写入、表值参数、日志驱动器的优化磁盘配置等技术,查看如何改进主数据库的写入性能。

如果您已经在这方面做了尽可能多的工作,那么下一个问题是,您在做什么样的查询,需要10台报表服务器?即使对于相当大的网站来说,也似乎不寻常。在这方面,您也可以做很多优化工作,例如将聚合查询卸载到Analysis Services,或者提高磁盘吞吐量。虽然可以,但向上扩展通常比向外扩展更好。

我倾向于将复制视为“最后的解决方案”。一旦您尽可能地进行了优化,我将针对您的报告需求研究水平或垂直分区。一个原因是分区往往会导致更好的缓存利用率,因此总吞吐量更高。

如果您最终达到了无法逃避复制的地步,那么FYJHAM建议的分层方法绝对是合理的。

如果有帮助的话,我会在书中深入讨论这些问题: Ultra-Fast ASP.NET .

请检查您的发布服务器和分发服务器的事务日志文件是否没有过多的VLF(虚拟日志文件),具体如下(步骤8):

http://www.sqlskills.com/BLOGS/KIMBERLY/post/8-Steps-to-better-Transaction-Log-throughput.aspx

如果分发数据库与发布服务器数据库位于同一位置,请考虑将其移动到自己的专用服务器。