在大型数据库中归档/备份表和更改的最佳方法

Question

我对大型多模式数据库有一个有趣的问题和要求。

- 数据库大小约为130Gb。

- 它是一个多模式数据库，每个客户都有一个模式。

- 我们目前在系统中有102247个表格。

- 微软的SQL Server 2K8 R2

这是由于客户的定制要求，所有使用单一定义前端。 我们遇到的问题是我们的数据库备份成为天文数据并且为恢复丢失/丢失/不正确的数据而执行数据库恢复是一场噩梦。最初的产品没有定义审计跟踪，我们没有对存储数据进行“更改”，我们只有1个版本的数据。

丢失数据返回基本上意味着恢复完整的130GB备份并加载差异/事务文件以获取数据。

我们想为每个模式中的每个重要表格引入一个'Changeset'。基本上保存一组数据，然后保存任何修改/不同的数据 - 每X分钟数。这将最初是一个SQL工作，但我想知道什么是最好的方法。

本质上，我会运行一个脚本，将'备份'表插入到我们希望保留备份的表的每个模式中。

然后每X分钟运行一次作业以遍历每个模式并插入当前数据 - 然后插入新数据/更改后的数据，因为它会发现更改。 （基于该行的修改日期）然后它将在自我覆盖之前保留这个更新日志大约一个月。

我们仍然有我们较大的备份，但我们不需要保留较长的保留期。我的观点是，检查更改的数据并执行插入操作的最好和最有效的方法是什么？

我的直觉是：

INSERT INTO BACKUP_table (UNIQUE ID, col1,col2,col3) 
select col1,col2,col3 from table where and ModifiedDate < DATEADD(mi,+90,Current_TimeStamp) 

*粗糙SQL

这必须是在一个循环要经过所有模式并运行此。许多表格不会改变数据。

这是一个很好的方法吗？

SO想什么？

Answer 1

我的第一个回应是考虑将每个客户保留在他们自己的数据库中，而不是将他们自己的模式保存在海量数据库中。到这样做的主要好处是：

元数据

1. 更强调单个数据库
2. 您可以在任何时间表你喜欢
3. 当某个客户有你的高活性每个客户执行备份可以轻松地将它们

我管理好几年了这样的系统，在我以前的工作和管理500个数据库没有复杂得多，管理10，和你的应用程序的唯一区别是连接字符串的数据库部分（这实际上更容易使查询适应比架构前缀）。

如果你真的致力于使每个人都在一个数据库中，那么你可以考虑做什么是存储自己的文件组中每个架构内的重要的表，并移动所有的东西主文件组中。现在，你可以备份独立的文件组的基础上，仅全主备份和个人文件组备份的段落还原，您可以在其他位置联机只是客户的模式，并获取你后的数据（也许将其复制到使用导入/导出，BCP，或简单的DML查询），而不必完全恢复整个数据库中的主数据库。移动所有用户数据从主文件组的最小化才能恢复初始备份，让你到恢复客户的具体文件组的时间。虽然这使得您的备份/恢复策略稍微复杂一些，但它确实能够实现我相信的目标。

另一种选择是使用自定义日志传送实现与有意延迟。我们通过将我们的日志发送到报告服务器来做了一段时间，但是在应用之前等待了12个小时。这给了我们客户的保护搬起石头砸自己的脚，然后需要恢复 - 如果他们12小时自己的错误之内与我们联系，我们可能已经有了“前螺杆式”在线数据在报表服务器上，使得它琐碎将其修复到主服务器上。对于查看12小时以前的数据的报告，它还作为报告服务器的两倍，从主服务器上带走大量负载。

您也可以考虑change data capture，但您显然需要测试性能以及对其余工作负载的影响。此解决方案还取决于您使用的SQL Server版本，因为它不适用于标准，Web，Workgroup等。