情况如下： 有一个交易密集型数据库 - 用于日常交易和报告。
我想知道我是否可以隔离这两个操作和两个独立的数据库，以便报告可以在一个数据库中运行，而所有事务都可以在另一个数据库中发生。这将提高 OLTP SQL 数据库的性能。
我已经了解了一些选项，例如镜像、日志传送、复制、快照、集群 - 但想讨论实现所需结果的最佳策略。
请告知实施此策略的最佳解决方案，或您可能有的任何其他想法/建议。
【问题讨论】：
标签： sql-server database performance reporting
我认为这是一个经典的前后端分离的教科书案例。
对于与我合作过的项目和人员，强烈一致认为两者应该分开。
在一种情况下，存在三层数据库：
前端事务速度非常关键，甚至该层被分解为多个数据库，每个制造区域一个数据库。交易是由需要非常快速响应的设备执行的。
我们使用来自前端数据库的数据以及面向客户和管理的数据库以每小时的频率为后端报告存储库构建记录，因为管理层需要较短的信息延迟来进行运营和工程决策。如果我们能够以 15 分钟的间隔进行一次信息编译，我们就会做到这一点。根据项目，该后端存储库可以是 Oracle 或 Sybase IQ。
但是，设备执行的前端事务需要参考一些元信息。设备所需的响应时间不会冒被某人在后端存储库上运行大量即席查询而中断的风险，这种查询很频繁。
因此，创建了一个中间层桥接数据库，其中包含来自后端存储库的夜间信息摘要。
架构设计非常重要，可以优化所有数据库的响应和性能。您必须确保您的数据库记录是通用键索引和离散时间索引。
对于一个充满机器人和设备的制造工厂，分为制造区域，每个区域都有一个前端事务数据库。每个区域数据库都需要有一个通用密钥调度程序。什么时候 执行一批操作所需的设备，beginOp 事件向调度程序请求离散键。一个操作周期可能需要几秒钟、几天或几周。每当一台设备需要对其运行状态执行交易时，它都会包含该通用密钥。一个操作可以有子操作和子子操作等 - 但每个此类操作都需要从其区域调度程序获取一个通用密钥。
commonality-key dispatcher 只是数据库中的 beginOp 表，带有一个自动增量键。任何设备共享相同的开始操作，由于细致的流程排序策略，它能够从表中推断/获取该通用键。
对于我们可以确保整个楼层上没有两个操作可以在同一 100 毫秒开始的区域，不需要调度程序，因为我们可以简单地使用 beginOp 事件的日期时间，其中 datetime 函数数据库服务器是自然/自发的密钥分配器。
讨论 commonality-key 的原因是因为所需的事务响应非常快，您不希望设备之间不必要地相互通信，只是为了告诉对方它们正在记录相同操作的事件.机器人和设备只需使用它们持有的通用密钥执行交易。
每小时编译插入后端存储库的信息，方便地使用commonity+area的组合键，构建事件的层次结构。
好的，这真的很极端。在某些地区，交易非常频繁，以至于我们有一个 FIFO 数据库。我们引入了第四层数据库。为了获得最佳事务响应，我们必须将数据库大小保持在 1GB 以下。存在将旧事务清空到第四层数据库的事务管道过程。我发现创建一个新数据库池更容易（并且响应更好），因此每当它的大小达到 1GB 时，它就会被移出并立即用池中的新数据库替换 - 让机器执行每小时编译加入数据库。因此，我们只能依靠现有的元数据数据库来存放通用键调度程序表和一些元数据表。
回想起来，人们可能会认为通用键调度程序表和元数据表可以存放在中间层桥接数据库中，但由于数据库管理流程是自动化的和千篇一律的，因此创建一个新流程会更干净而不是修改管理中间层桥接数据库的进程。这些管理例程已在全球范围内使用，因此您不能随意更改它们而不会对公司的财务业绩造成严重破坏或冒犯维护它们的相应数据层架构师。
经理们需要大量的组织技能才能将所有这些整合在一起。因此，事务性数据设计不仅仅是一种技术技能，而是一种流程规划技能，需要很多人相互碰撞，直到你做对为止。
【讨论】：
您要求的是完全标准的 - OLAP 和 OLTP 不会在重负载场景中混合使用。
您使用 SQL Server。查看 SSAS（SQL Server 分析处理）以构建多维数据集（与 SQL 不同的方法），然后您可以据此进行报告。
如果您不希望这样做，那么镜像是下一个最佳解决方案 - 您可以将镜像置于只读模式以进行报告，它还为您提供了一个备份，以便在主服务器出现故障时激活；）总是不错。
集群不是问题——它允许您将数据库移动到另一个节点，但它根本不能解决性能问题。日志文件传送、复制 - 很好，虽然我会使用镜像、只读副本用于报告、将数据加载到 SSAS 中。
【讨论】：
我们有一个读/写集群，它复制（使用事务复制）到“只读”服务器（不是物理只读的，网络应用程序只是对它们执行读取）。我们对报告做同样的事情，而且这个规模非常好。
在此配置中，我们有多个站点、32 台以上的服务器和几个报告服务器，插入、更新和读取量非常大。
我们主要将报告服务用于内部报告。报告不会影响我们的核心业务，我想这是您最关心的问题。
【讨论】：