SQL Server灾难恢复：重创历史性数据
作为一个数据库管理员和顾问，我见到许多的数据库只存储当前的数据快照，而不是数据在其生命周期中发生变化的每个历史时期的数据行。在大多数情况下，这对于数据库来说都是不错的，因为每个事务的一次迭代都会让你的数据库的规模比现在的尺寸大上100到1000倍。这是因为它需要保证数据库处在可管理的层面上，历史性的数据行通常不会存储，因此不容易重新创建。
金融行业则采用了相反的方式。不仅仅是存储数据的最近状态，它还存储了发生的每个事务，并且将条目还原到变化之前。这个方式意味着数据被写入，但是它永远不会发生变化。任何的历史时间点都可以轻松地显示出来，需要重新创建数据等其他操作。从纯粹的感觉出发，检索金融数据的变更并不像你存储在数据库中的其他数据那么频繁。就是说，你应该调查一下你需要检索哪些历史数据，以及那些类型的数据只需要你存储最新版本即可。
市场上也有此类工具，例如Lumigent Technologies公司的AuditDB和 Idera公司的 SQL compliance manager，它们都可以让你捕捉数据库中发生的每个变化的每个阶段。它用了非常大的空间来存储数据，只有用上面提到的工具，你才可以检索数据随着时间变化的不同状态——除非是你修改了你的应用程序来存储每个历史数据行。当然，还有其他的选择，例如使用触发器来捕捉每个数据变更，但是，还是这个问题，你的存储空间需要很大，因为使用触发器的时候对你的服务器的要求很大。
不使用工具或者修改你的应用程序来捕捉每个历史性数据行的话，你就剩下无尽的痛苦和无限的麻烦来尝试重新创建你的数据了。几年之前，我曾经接受了这样的任务，重新创建几年前的保健记录，以此来发现一些可疑的行为。那时候，上面提到的工具还不存在，我就尝试使用触发器，还有额外的存储需求，都无法选择。
重新创建每个历史性特定数据集合的视图的过程，是从归档备份磁带的检索开始的。让我们感到惊恐的是，我们被通知，每个月只有一盘磁带用于长期的存储，因此我们只能创建每个月一次的快照。当我们开始重新存储磁带的时候，我们再次郁闷地发现，有些磁带已经没法读了。那时候的数据库的规模只有10GB，但是需要一遍又一遍地重新储存，还有要捕捉到的数据的话，需要我们在适当的位置重新存储，因为这些是9GB磁盘驱动的时代，没有足够的存储空间。今天，10GB是个极小的数字。现在的数据库规模在100GB到500GB的范围。所以，即使是存在较大的驱动，整体的问题仍然存在。
我知道重新创建历史性数据的任务不是经常发生的情况，但是我也知道，我曾经面对过这样的挑战好几次。作为一名数据库管理员，保护数据并帮助你的公司尽可能地再次制造是你的责任。为了理解真正的需求和数据的重要性，你必须询问一些问题来帮助你判断需求。基于你学到的内容，在合适的地方采取措施将会保证你可以重新创建你需要的东西。
再一次提到，这里有3个选项考虑让你了解什么是可能的，什么是不可能的：
· 第三方工具，例如Lumigent的AuditDB 或者Idera的 SQL compliance manager
· 使用触发器或者修改其它应用程序
· 备份和重新存储的方法
根据你的选择，你需要理解什么是可能的，什么是不可能的。通过使用第三方工具，你可以重新创建每个发生的变化。这些工具构建在业务处理中，可以最小化对服务器和数据库的性能影响，它们可以让你有选择的捕捉重要的数据。使用触发器或者其它经过修改的应用程序是另一个很好的选择，但是如果你的系统非常繁忙，如果你用这样的方式的话，你的性能会受到很大的影响。
最后一种方式，使用备份和重新存储，需要进行调查以便你能够理解长期的备份存储。查明存储多长时间的备份，存储哪些类型的备份，以及你重新存储所有步骤的可能性。即使是一天只进行一次完全备份，你仍然有潜在的风险会丢失某一天的变更，于是你需要在那一天进行变更的恢复。在我所涉及的案例中，每个月都可能会发生很多很多的动作无法重新创建。
根据纸质的记录来重新创建计算机记录的日子一去不复返了。越来越多的信息只在线抓取。如果没有采取适当的措施的话，数据就会永远丢失，人们永远也不知道发生了什么。作为一个数据库管理员，你需要理解你的角色，保持系统在线，是你的数据的，实际上也是全公司的保护神。