Sql server 报告数据库的最佳解决方案

情况如下： 有一个事务密集型数据库，用于日常事务和报告

我想知道是否可以隔离这两个操作和两个独立的数据库，以便报告可以从一个数据库运行，所有事务都可以在另一个数据库中发生。这将提高OLTP SQL数据库的性能

我已经介绍了一些选项，如镜像、日志传送、复制、快照、群集，但我想讨论实现所需结果的最佳策略

---

请建议实施此策略的最佳解决方案，或您可能有的任何其他想法/建议。

您所要求的完全是标准的-OLAP和OLTP不会在重负载场景中混合使用

您可以使用SQL Server。查看SSAS（SQL Server分析处理）以获得构建多维数据集的内容（与SQL不同的方法），然后根据这些多维数据集进行报告

如果您不这样做，那么镜像是下一个最佳解决方案—您可以将镜像以只读模式联机以进行报告，并且它还为您提供了一个备份，以便在主服务器出现故障时激活；）总是好的

---

集群不是问题——它允许您将数据库移动到另一个节点，但根本不能解决性能问题。日志文件传送、复制-很好，不过我会使用镜像、只读拷贝进行报告，并将数据加载到SSAS中。

我认为这是一个典型的教科书式的前端和后端数据库分离案例

对于与我共事的项目和人员，双方达成了强烈的一致意见，认为应将两者分开

在一个案例中，有三层数据库：

前端交易中期总结

供前端事务参考的存储库

后端信息存储库

前端事务处理速度非常关键，甚至将该层分解为多个数据库，每个制造区域一个数据库。交易由需要快速响应的设备执行

来自前端数据库的数据与面向客户和管理层的数据库一起用于以每小时一次的频率为后端报告存储库构建记录，因为管理层需要较短的信息延迟来进行运营和工程决策。如果我们能每隔15分钟进行一次信息汇编，我们早就完成了。根据项目的不同，后端存储库可以是Oracle或Sybase IQ

然而，设备执行的前端事务需要参考一些元信息。设备所需的响应时间不能冒被在后端存储库上运行大量临时查询的人中断的风险，这是经常发生的

因此，创建了一个中间层桥接数据库，它由来自后端存储库的夜间信息摘要组成

用公共密钥设计的模式 模式设计对于优化所有数据库的响应和性能非常重要。您必须确保数据库记录是公共密钥索引和离散时间索引

对于充满机器人和设备的制造工厂，划分为制造区域，每个区域都有一个前端事务数据库。每个区域数据库都需要一个公共密钥调度器。什么时候 beginOp事件是执行一批操作所需的一种设备，它向调度器请求一个离散密钥。操作周期可能需要几秒钟、几天或几周。每当一台设备需要在其运行状态下执行事务时，它都包含该公共密钥。一个操作可以有子操作和子操作等，但每个操作都需要从其区域调度器获取公共密钥

公共密钥调度器只是数据库中带有自动递增密钥的beginOp表。任何共享同一开始操作的设备，由于采用了细致的工艺排序策略，因此能够从表中推断/获得通用性密钥

对于可以确保整个楼层上没有两个操作可以在100毫秒内启动的区域，不需要调度程序，因为我们可以简单地使用beginOp事件的日期时间，其中数据库服务器的datetime函数是自然/自发的密钥调度程序

之所以讨论公共密钥，是因为所需的事务响应非常快，您不希望设备之间不必要地相互通信，只是为了告诉对方它们正在记录相同操作的事件。机器人和设备只需使用其持有的通用密钥执行事务

每小时编译信息以插入后端存储库，方便地使用Commonity+area的复合键来构建事件的层次结构

前端管道数据库 好吧，这真是太极端了。在某些地区，交易如此频繁，以至于我们有一个FIFO数据库。我们引入了第四层数据库。为了获得最佳的事务响应，我们必须将数据库大小保持在1GB以下。存在将旧事务清空到第四层数据库的事务管道过程。我发现创建一个新数据库池更容易（而且响应更好），这样每当它的大小达到1GB时，它就会被移出并立即替换为池中的一个新数据库——让执行每小时编译的机器连接数据库。因此，我们只能依靠现有的元数据数据库来容纳带有一些元数据表的公共密钥调度表

回顾一下，可以认为公共密钥调度器表和元数据表可以容纳在中间层桥接数据库中，但由于数据库MA