SQL Server数据库增强版备份体验_Mssql数据库教程

推荐：如何有效防止Java程序源码被人偷窥?
Java程序的源代码很容易被别人偷看，只要有一个反编译器，任何人都可以分析别人的代码。本文讨论如何在不修改原有程序的情况下，通过加密技术保护源代码。 一、为什么要加密? 对于传统的C或

老鸟说事：Microsoft SQL Server数据库增强版备份体验

在欧洲，有一首流传很广的民谚：

因为丢失一根铁钉，我们失去了一块马蹄铁；

因为失去一块马蹄铁，我们失去了一匹骏马；

因为失去一匹骏马，我们失去一名骑士；

因为失去一名骑士，我们输掉了一场战争……

在企业的经营中，细节决定成败，要规避一切潜在的风险，避免因为一些小的失误而造成重大损失，在企业运营越来越依靠IT支撑的今天，企业的关键应用，比如财务软件、CRM、OA、ERP等，一旦发生数据丢失，损失将非常惨重，想想财务数据的数据丢失的后果吧，工资无法正常发放；当年的财务总结没办法进行；盈利还是亏损无法计算；下一年的业务也无法正常开展；大客户可能因此拂袖而去。

数据已经不再是0101这样的二进制信息，而是人们的钱袋子，真正的真金白银。人们应该及时做好数据备份。

中小企业最常使用的数据库是微软的是SQL Server，本身带有自动备份功能，但多年来的经验告诉我，SQL自带的备份已经远远不能满足企业业务的连续性、安全性需求了。

SQL SERVER自带备份功能是一个简单的入门级的备份小工具，在非常简单的应用时，比如一两台SQL服务器，数据量又大，数据重要性一般的时候，SQL自带备份功能就可以胜任了。

但是当数据重要性非常高时，企业不能够承担数据丢失的风险时，那么就需要寻求更加专业、更加安全可靠的数据备份解决方案。因为SQL自带备份功能有以下不足和缺陷。经过反复的筛选和比较之后，本人找到一款在功能和性能上都能对SQL自带备份功能带来非常大改善的备份工具--爱数备份软件。下面是功能比较：

备份功能之比较

大家都知道，数据库备份有四种类型，分别应用于不同的场合，下面简要介绍一下。

1、完全备份

这是大多数人常用的方式，它可以备份整个数据库，包含用户表、系统表、索引、视图和存储过程等所有数据库对象。但它需要花费更多的时间和空间，所以，一般推荐一周或一月做一次完全备份。

2、事务日志备份

事务日志是一个单独的文件，它记录数据库的改变，备份的时候只需要复制自上次备份以来对数据库所做的改变，所以只需要很少的时间。为了使数据库具有鲁棒性，推荐每小时甚至更频繁的备份事务日志。

3、差异备份

也叫增量备份。它是只备份数据库一部分的另一种方法，它不使用事务日志，相反，它使用整个数据库的一种新映象。它比最初的完全备份小，因为它只包含自上次完全备份以来所改变的数据库。它的优点是存储和恢复速度快。推荐每天做一次差异备份。

4、文件备份

数据库可以由硬盘上的许多文件构成。如果这个数据库非常大，并且一个晚上也不能将它备份完，那么可以使用文件备份每晚备份数据库的一部分。由于一般情况下数据库不会大到必须使用多个文件存储，所以这种备份不是很常用。

如果你只做全备份，那么受限于全备份的大小和备份时间，不可能常做。而且只有全备份，不能将数据库恢复至某个时间点。所以，我们需要全备份 日志备份。比如每天一个全备份，每隔1小时或若干分钟一个日志备份。

说到差异备份，因为微软的差异备份记录的是上一次全备份以来发生的变化，所以，如果数据库的改动很频繁的话，没过多久，差异备份就会和全备份的大小接近，因此这种情况下就不合适了。因此，全备份 日志备份的方案适合绝大多数的用户。

备份文件传送至备机后，就可以高枕无忧了吗？不。作为DBA还需要检查备机上的备份文件是否能将数据库恢复至最新，如果采用日志备份，会不会因为丢失某一个日志备份文件而导致数据库不能恢复至最新？如何检查日志备份文件之间存在断档？

数据库在备份的时候，并不会检查数据页面的完整性，如果数据页坏了，备份作业仍会执行，而且不会报错，等到你发现数据页有错误的时候，你也很可能已经因为磁盘空间不足，而删除了早期的备份，而此时剩下的那些备份可能都是包含损坏的数据页，如果损坏的数据页是某个表的表头的话，那这个表你就再也没办法恢复了。

爱数的解决方案：

自动将完全备份和日志备份完整有机结合起来，并自动将日志文件组织一个文件包里，不用担心丢失和遭病毒破坏，不用担心日志断档。

高级的循环备份功能，可以自动设置多久执行一次全备份，以及每个全备份下面带多少个增量备份点。比如：每周执行一次完整备份，保留三个完全备份；每个全备份下面带有30个增量备份，这样，既保证了数据库备份的完整性，又保证了数据备份的速度和效率。

恢复功能之比较

SQL自带备份：

为了将数据库尽可能的恢复到最新，你可能会每隔10分钟（甚至1分钟）执行一次日志备份，那么万一数据库坏了，在恢复的时候，手动恢复成百上千个日志文件，就非常非常麻烦~~~

爱数的解决方案：

将完整备份与日志备份自动组织，抽象成一个一个时间点，只要选择时间点便可以轻松到该备份时间点。

备份的完整性充分保障，不用担心日志断档，不用手动恢复成百上千个日志文件，节省大量的恢复的时间，在数据发生后能够迅速恢复应用，减少企业的损失。

备份管理之比较

如果你所在公司有很多的数据库服务器（就像我所在的公司），而且磁盘空间有限，那么你不得不经常登录服务器来删除旧的备份文件，如果哪天忘了，或者五一十一长假，磁盘空间用完了，就麻烦了。

所以你需要定期执行DBCC检查，来尽早发现数据库页面的完整性。在未作完DBCC检查之前，你不能删除旧的备份，以防止新的备份存在问题。所以，删除备份文件的工作变的有些麻烦。

你可能知道SQL Server提供了数据库维护计划。没错，使用它可以定期做备份，执行DBCC检查，但这一切仅限于本机操作。为了使数据库可靠，你还是需要自己把本地备份传送至备机。

爱数的解决方案：

利用集中式管理工具的帮助，系统管理员可对全网的备份策略进行统一管理，备份服务器可以监控所有机器的备份作业，也可以修改备份策略，具有自动删除老数据功能，多种加密算法，保护数据隐私，三种压缩模式，可以将数据量大大减小，自有文件格式，病毒冰冻技术，详细的日志与报表，保障用户的可省阅性。

系统支撑功能之比较

在网络条件不好的时候？如果数据库备份文件的传送在某一时刻停止了，你多久才能发现？公司值晚班的同事有权限检查数据库的备份情况吗？系统崩溃了，SQL的运行也成了空中楼阁。

服务器被盗，或者遭遇火灾、地震或者其它自然灾害，那SQL的数据丢失更加成为必然。SQL自带备份对以上这些情况毫无办法。

爱数的解决方案：网络不稳定时可以自动重联；具有系统备份功能；高性价比、易实施的远程数据备份

总体来说爱数优势还比较多：

完全备份＋日志备份整合非常优秀，实现了数据库小粒度的增量备份。

按时间点的恢复，我们不用考虑恢复到数据库崩溃前需要恢复哪些日志文件。

可以设置保留最新N个全备份的版本，自动删除老版本的备份数据。

每个全备份带有N个日志备份。恢复灵活性很大。

可以设置备用的备份目的地，这样就不用担心放假时备份空间被消耗掉。

可以将备份数据加密、压缩等。

可以将数据备份到异地，甚至远程的FTP服务器。

更低的TCO。

详细比较：

SQL Server自带备份功能

的不足与缺陷 爱数SQL Server备份选件的优势

备份功能 日志管理太复杂 自动组织备份文件与日志

恢复功能 手动恢复大量日志文件太麻烦，无法满足恢复的时间要求

要是某个日志丢失形成断档，就会造成数据无法正常恢复 将完整备份与日志备份自动组织，抽象成一个一个时间点，用户只要选择时间点便可以轻松、快速的恢复

备份管理 无法自动删除过期老文件

无法加密

无法压缩

易被病毒感染 具有自动删除老数据功能

多种加密算法，保护数据隐私

三种压缩模式，可以将数据量大大减小

自有文件格式，病毒冰冻技术

详细的日志与报表

系统支撑功能 网络不稳定 网络不稳定时可以自动重联

系统崩溃 具有系统备份功能

电脑、服务器被盗

火灾、地址及其它自然灾害 高性价比、易实施的远程数据备份

分享：如何快速生成100万不重复的8位编号
最近在论坛看到有人问，如何快速生成100万不重复的8位编号，对于这个问题，有几点是需要注意的： 1． 如何生成8位随机数，生成的数越随机，重复的可能性当然越小 2． 控制不重复