数据库和数据库管理系统
数据库就是结构化的数据仓库。人们时刻都在和数据打交道，如：存储在个人掌上电脑（PDA）中的数据、家庭预算电子数据表等等。对于少量、简单的数据，如果它们与其它数据之间的关联较少或没有关联的情况下，他们可以简单的存放在文件中，当然如果所有的数据结构都很简单，那么数据库管理系统就没什么用了。
但是企业数据都是相关联的。如：职员表链接到名称和地址的记录，订单记录需要与库存信息相对应，海运记录需要与信用额度相对应，等等。通常来说，不可能使用普通的记录文件来管理大量的、复杂的系列数据，如：银行的客户数据，或者生产厂商的生产控制数据。普通记录文件没有系统结构来系统的反映数据间的复杂关系，它也不能强制定义个别数据对象。
数据库管理系统(DBMSs)，或者数据库管理器,已经发展了近二十年，来解决上面提到的这些需求。数据库管理器是近似于文件系统的软件系统，通过它，应用程序和用户可以取得所需的数据。然而，它们又不象文件系统，它们定义了所管理的数据之间的结构和约束关系。并且，数据库管理器提供了一些基本的数据管理函数：
► 数据安全: 在商业上，数据库必须是一个可以存储数据的安全的地方。数据库管理器必须提供有效的备份和恢复能力，来确保在灾难和错误后，数据能够尽快的可以被应用所访问。
► 数据安全: 对于一个企业来说，它把关键的和重要的数据存放在数据库中，数据库管理系统必须能够防止未授权的数据访问。
► 数据共享: 一个数据库必须允许多个应用和用户同时进行数据访问，而且不影响数据的完整性。例如：如果两个用户试图同时修改同一条记录，两个修改操作都必须被处理，并且产生一个可理解的干净的结果。
► 数据组织: 基于文件的数据的主要优势就在于它利用了数据结构。数据库的结构使开发者避免了针对每一个应用都需要重新定义数据逻辑关系的过程。
数据库数据模型
数据库管理系统的发展已经经历了一个漫长复杂的过程。人们提出了许多数据模型，并一一实现。其中比较重要的三个就是：
► 分级模型: 在一个分级的数据库中，数据项间具有父项与子项的关系。例如：一个顾客的记录包括名称和地址信息，它可能就是一系列订单记录的父项，每个订单记录包含了关于这个订单的详细信息。
► 网络模型: 在一个网络数据库中，数据项之间有更多的相互关系。这些关系通常用来描述一个图形形状，或者网络中形成刀片结构的那些节点和它们之间的关系。
► 关系模型: 在关系型数据库中，数据项保存在行中，文件就象是一个表。关系被描述成不同数据表间的匹配关系。一个区别关系模型和网络及分级型数据库的重要一点就是数据项关系可以被动态的描述或定义，而不需要因为结构被改变而卸载然后重新加载数据库。
关系模型
早在1980年，数据库市场就被关系型数据库管理系统所占领。关系模型的成功并不在意料之外。这个模型基于一个可靠的基础，它可以简单并恰当的将数据项描述成为表（table）中的记录行(raw)。关系模型第一次广泛的推行是在1980年中，是因为一种标准的数据库访问程序语言被开发出来，它被称作结构查询语言（SQL）。
今天，成千上万使用关系型数据库的应用程序已经被开发出来，包括跟踪客户端处理的银行系统，仓库货物管理系统，客户关系管理(CRM)系统，以及人力资源管理系统。由于数据库保证了数据的完整性，企业通常将他们的关键业务数据存放在数据库中。因此保护数据库避免错误以及灾难已经成为企业所关注的重点。
数据库备份和恢复
一致性和实时性
一个一致性的数据库就是指数据处理响应完成了的数据库。例如：一个会计数据库，当它的记入借方与相应的贷方记录相匹配的情况下，它就是数据一致的。
一个实时的数据库就是指所有的事务全部执行完毕后才响应。如果一个正在运行数据库管理的系统崩溃了，而对事务的处理结果还存在缓存中而没有写入到磁盘文件中的情况，当系统重新启动时，系统数据就是非实时性的。
数据库日志被用来在灾难发生后恢复数据库时保证数据库的一致性和实时性。
数据库恢复
正规的数据库备份是最基本和有效的数据库容灾技术。数据库备份和恢复技术与我们在“错误！未找到引用源”中讲述的文件系统的备份和恢复是不同的。
数据库事务
如果要明白备份恢复技术，明白数据库事务的种类是很有用的。一个事务就是一个事务活动所引起的一系列的数据库操作。例如，一个会计事务可能是由以下部分组成：
读取借方数据
减去借方记录中的借款数量
重写借方记录
读取贷方记录
在贷方记录上的数量加上从借方扣除的数量
重写贷方记录
写一条单独的记录来描述这次操作，以便日后审计
所有这些操作组成了一个事务，描述了一个业务动作。在上述例子中，无论借方的动作或是贷方的动作哪一个没有被执行，数据库都不会反映该业务执行正确。
数据库管理系统在数据库操作时强迫进行事务定义，这意味着或者一个事务定义的应用的全部操作结果都反映在数据库中，或者都没有反映在数据库中，即使数据库在事务执行过程中崩溃的情况下。
事务定义是关系数据库中最重要的关系之一。上述例子包含了两个数据库操作：从借方数据中扣除资金，并且在贷方记录中加入这部分资金。如果系统在执行事务的过程中崩溃，如果此时已修改完毕借方数据，但还没有修改贷方数据，资金就会在此时物化。把这两个步骤合并成一个事务命令，这样在数据库系统执行时，要么全部完成，要么全部不完成，但当只完成一步时，系统是不会对已作的这一步做出响应的。
数据库崩溃恢复
一个运行着数据库系统的计算机随时都可能宕机。然而“已借未贷”或“已贷未借”的情况都可能出现。当系统崩溃后重启时，数据库管理系统必须允许这种可能性的发生，也就是说，在磁盘数据文件中可能包含一些部分完成的事务，在应用能够访问数据库数据之前，这些必须全部被检出。
防止上述情况发生的基本技术就是保存一份连续日志，记录将做的和完成的操作。当需要修复损坏的数据库时，数据库系统重新应用这些日志，寻找那些将要执行但未完成的任务。如果任何类似的事务的已经在数据库中反映，这一定是颠倒的，并且数据库必须回滚。
使用这种日志重新应用的技术，数据库系统可以避免宕机所带来的已接受事务（应用已确认执行完毕的事务）的丢失。数据修复时，那些在宕机时处理结果还存在缓存中的已接受事务，结果会存放到磁盘文件中。未接受事务（还没有被应用确认的事务）会被回滚，消除它所带来的对其他数据的影响。为了帮助解释数据库日志如何工作，Figure 1-1描述了一个简单的数据库管理组件。
文件系统缓存和数据库恢复
如果使用文件作为数据库的数据存储方式会给我们的讨论增加一些额外的复杂性，因为文件管理系统有它自己的缓存。如果一个数据库系统在宕机后立刻重新启动，那么它所包含的文件可能并没有实时刷新到存储中，这是由于在系统宕机时，文件系统的缓存没有写入到存储的原因 。在这种情况下，数据库恢复进程必须重新应用数据日志刷新。也就是说，在系统宕机的情况下已接受事务也不会丢失。
归档日志
大多数的数据库都支持数据库日志归档，支持企业保存一个长时间的数据刷新历史。如果所有的基于一次全备份时间点之后的归档数据全部可用，那么就可以通过以下步骤恢复成为一个最新的数据库。
恢复备份拷贝
在已经恢复的数据库上重新应用所有的归档日志。
在已经恢复的数据库上重新应用数据库日志。
这也许是一个灾难后完全丧失服务能力数据中心的唯一恢复数据方法。在这个工作过程步骤中，数据库全备份数据和归档日志必须快速的传送到灾难恢复中心。为了实现完全的实时数据库恢复，镜像或复制当前的数据库日志到恢复中心也是必需的，就如我们在“错误！未找到引用源”中描述的那样。
数据库备份技术
就如前面对恢复作用的描述，一个数据库的数据库备份必须必须是一个数据库的完整的映像，在这个映像的时间点上，没有部分完成的事务存在。这可以通过数据库的离线备份来实现，因为在这种情况下，没有事务需要处理。这种方式的缺点在于，在备份过程中，没有应用能够使用数据库。数据库在线的时候也可以进行备份，在这种情况下，备份程序要确保不管数据访问多么活跃，都能够得到一个完整的数据拷贝。
离线数据备份
如果备份时数据库不可以被应用所访问，那么我们称这种备份为离线备份或冷备份。冷备份可以通过关闭数据库然后进行文件备份来实现。离线数据库备份是简单的，也是被认为有效的备份技术。但是逐渐的，企业发现把他们的数据库停下来，然后进行备份，这种方式完全不切实际。而且，在一些老的数据库管理系统中，冷备份拷贝不能用来进行前滚，因为它们与数据库日志不同步。在新的数据库设计中，已经解决了冷备份拷贝与数据库日之间的同步问题，所以前面的问题也就逐渐不成为问题了。
在线数据库备份
现在大多数的数据库都可以在应用进行数据访问时进行数据备份。在备份活跃数据库时有两种基本技术，被称作逻辑的和物理的在线分别备份。
大多数数据库管理系统都支持逻辑在线备份。例如：被包含在Oracle数据库的RMAN工具和Sybase数据库的“dump database”命令。逻辑在线备份之所以这么命名，是因为它拷贝了数据库的逻辑单元，而不是存储设备列表或是存储逻辑单元的文件。逻辑数据库备份工具通常和恢复、修复工具放在一起，因此产生有问题备份的几率较小。逻辑数据库备份的主要缺点就是他无法利用存储设备的快照技术来减少对应用的影响。因为在一个逻辑数据库备份的过程中，系统性能会大大的降低，因此它对总是处在活跃状态的数据库并不合适。
1
2
3
下一页>>
