这是我期望你永久不要面临的一个使命：永久都不需求从头创立不同时刻点上的数据，以此来弄清一个可疑的动作或则和提醒丢掉或许被偷的数据。大多数的数据库都在中心数据层上存储数据，上面只为终端用户和数据库办理员显现数据的最近状况。这就意味着你只能看到***版别的数据，你无法辨认在数据生命周期中不同时刻点上特定数据的下落。

作为一个数据库办理员和参谋，我见到许多的数据库只存储当时的数据快照，而不是数据在其生命周期中产生改变的每个前史时期的数据行。在大多数状况下，这关于数据库来说都是不错的，由于每个事务的一次迭代都会让你的数据库的规划比现在的尺度大上100到1000倍。这是由于它需求确保数据库处在可办理的层面上，前史性的数据行一般不会存储，因而不容易从头创立。

金融职业则采用了相反的办法。不仅仅是存储数据的最近状况，它还存储了产生的每个事务，而且将条目复原到改变之前。这个办法意味着数据被写入，可是它永久不会产生改变。任何的前史时刻点都可以轻松地显现出来，需求从头创立数据等其他操作。从朴实的感觉动身，检索金融数据的改变并不像你存储在数据库中的其他数据那么频频。就是说，你应该查询一下你需求检索哪些前史数据，以及那些类型的数据只需求你存储***版别即可。

市场上也有此类东西，例如Lumigent Technologies公司的AuditDB和 Idera公司的 SQL compliance manager，它们都可以让你捕捉数据库中产生的每个改变的每个阶段。它用了十分大的空间来存储数据，只要用上面说到的东西，你才可以检索数据跟着时刻改变的不同状况——除非是你修正了你的应用程序来存储每个前史数据行。当然，还有其他的挑选，例如运用触发器来捕捉每个数据改变，可是，仍是这个问题，你的存储空间需求很大，由于运用触发器的时分对你的服务器的要求很大。

不运用东西或许修正你的应用程序来捕捉每个前史性数据行的话，你就剩余无尽的苦楚和无限的费事来测验从头创立你的数据了。几年之前，我从前接受了这样的使命，从头创立几年前的保健记载，以此来发现一些可疑的行为。那时分，上面说到的东西还不存在，我就测验运用触发器，还有额定的存储需求，都无法挑选。

从头创立每个前史性特定数据调集的视图的进程，是从归档备份磁带的检索开端的。让咱们感到惊慌的是，咱们被告诉，每个月只要一盘磁带用于长时间的存储，因而咱们只能创立每个月一次的快照。当咱们开端从头存储磁带的时分，咱们再次抑郁地发现，有些磁带现已无法读了。那时分的数据库的规划只要10GB，可是需求一遍又一遍地从头储存，还有要捕捉到的数据的话，需求咱们在恰当的方位从头存储，由于这些是9GB磁盘驱动的年代，没有满足的存储空间。今日，10GB是个极小的数字。现在的数据库规划在100GB到500GB的规模。所以，即使是存在较大的驱动，全体的问题依然存在。

我知道从头创立前史性数据的使命不是常常产生的状况，可是我也知道，我从前面临过这样的应战好几次。作为一名数据库办理员，维护数据并协助你的公司尽或许地再次制作是你的职责。为了了解真实的需求和数据的重要性，你有必要问询一些问题来协助你判别需求。依据你学到的内容，在适宜的当地采纳办法将会确保你可以从头创立你需求的东西。

再一次说到，这里有3个选项考虑让你了解什么是或许的，什么是不或许的：

第三方东西，例如Lumigent的AuditDB 或许Idera的 SQL compliance manager

运用触发器或许修正其它应用程序

备份和从头存储的办法

依据你的挑选，你需求了解什么是或许的，什么是不或许的。通过运用第三方东西，你可以从头创立每个产生的改变。这些东西构建在事务处理中，可以最小化对服务器和数据库的功能影响，它们可以让你有挑选的捕捉重要的数据。运用触发器或许其它通过修正的应用程序是另一个很好的挑选，可是假如你的体系十分繁忙，假如你用这样的办法的话，你的功能会遭到很大的影响。

***一种办法，运用备份和从头存储，需求进行查询以便你可以了解长时间的备份存储。查明存储多长时刻的备份，存储哪些类型的备份，以及你从头存储避实就虚过程的或许性。即使是一天只进行一次彻底备份，你依然有潜在的危险会丢掉某一天的改变，所以你需求在那一天进行改变的康复。在我所触及的事例中，每个月都或许会产生许多许多的动作无法从头创立。

依据纸质的记载来从头创立计算机记载的日子一去不复返了。越来越多的信息只在线抓取。假如没有采纳恰当的办法的话，数据就会永久丢掉，人们永久也不知道产生了什么。作为一个数据库办理员，你需求了解你的人物，坚持体系在线，是你的数据的，实际上也是全公司的维护神。

【修改引荐】

1. SQLServer灾祸康复
2. 两种SQL Server灾祸康复办法
3. mdf文件问题SQL Server灾祸康复技巧
4. SQL Server数据库的集群规划