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

时间:2012-03-29 14:01:28

标签: sql sql-server-2008

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

- 数据库大小约为130Gb。

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

- 我们目前在系统中有102,247个表。

-Microsoft SQL Server 2k8 r2

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

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

我们想为每个架构中的每个重要表引入一个“Changeset”。基本上持有一组数据,然后保存任何修改/不同的数据 - 每X分钟。这最初必须是一个SQL工作,但我想知道什么是最好的方法。

基本上我会运行一个脚本,将“备份”表插入到我们希望保留备份的表的每个模式中。

然后每隔X分钟运行一个作业,循环遍历每个模式并插入当前 - 然后在发现更改时插入新的/更改的数据。 (基于行的modifiedDate)然后在自我覆盖之前保留此更改日志大约一个月。

我们仍然有更大的备份,但我们不需要保留更长的保留期。我的观点是,检查已更改数据和执行插入的最佳和最有效的方法是什么。

我的直觉是:

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的想法是什么?

1 个答案:

答案 0 :(得分:1)

我的第一个回应是考虑将每个客户保留在他们自己的数据库中,而不是在大型数据库中保留他们自己的架构。这样做的主要好处是:

  1. 对单个数据库的元数据的压力要小得多
  2. 您可以按照您喜欢的任何时间表为每位客户执行备份
  3. 当某个客户具有较高的活动时,您可以轻松移动它们
  4. 我在以前的工作中管理了这样一个系统已有好几年了,管理500个数据库并不比管理10个更复杂,而且与应用程序的唯一区别在于连接字符串的数据库部分(实际上更容易进行查询)适应比模式前缀更好。

    如果你真的致力于让每个人都在一个数据库中,那么你可以考虑做的是将重要的表存储在他们自己的文件组中的每个模式中,并将所有内容移出主文件组。现在,您可以单独备份这些文件组,并且仅基于完整的主备份和单个文件组备份的零碎还原,您可以将该客户的架构在线放在另一个位置,并检索您之后的数据(可能是复制它)使用导入/导出,BCP或简单DML查询转移到主数据库),而不必完全还原整个数据库。将所有用户数据移出主文件组可以最大限度地缩短恢复初始备份所需的时间,并使您恢复特定客户的文件组。虽然这会使您的备份/恢复策略变得更复杂,但它确实实现了我相信之后的目标。

    另一种选择是使用故意延迟的自定义日志传送实现。我们暂时将这些日志发送到报告服务器,但在应用它们之前等待了12个小时。这样我们可以保护客户免受脚部攻击,然后需要恢复 - 如果他们在错误发生后的12小时内联系我们,我们可能已经在报告服务器上在线进行了“提前搞砸”数据,这使得它变得微不足道在主服务器上修复它。它也是报告服务器的两倍,用于查看超过12小时数据的报告,从主服务器上带来大量负载。

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