| 数据库文件是存储数据资源的重要形式，目前常用的数据库管理系统有SQL Server、Oracle、Informix、Sybase等，虽然各种数据库的具体维护方法不尽相同，但从共性管理的角度看，数据库例行维护一般包括以下内容。
|
|
|
|
|
| （1）数据库日志检查：在数据库系统中，对数据的任何更新操作（如增加、修改、删除），都要把相关操作的命令、执行时间、数据的更新等信息保存下来，这些被保存的信息就是数据库日志，即数据库日志是数据库系统中所有更新活动的操作序列。数据库系统根据事务处理来记录日志信息，日志内容包括：事务开始标记、事务的唯一标识、所操作数据项的唯一标识、数据项的写前值（数据插入操作不包含该项）、数据项的写后值（数据删除操作不包含该项）、事务提交或终止标记。任何数据库系统都遵循先写日志的原则，即在内存中被更新数据写入磁盘之前，要保证对应日志信息已经写入磁盘，存入日志文件。因此，数据库日志文件是数据恢复的重要基础。
|
|
|
| （2）数据库一致性检查：对数据库的物理和逻辑一致性进行检查，以SQL Server 2000数据库管理系统为例，系统提供数据库控制台命令DBCC，可用于数据库的一致性检查。DBCC语句分类如下表所示。
|
|
|
|
|
|
|
|
|
| 从应用可用性、系统资源占用和数据库性能指标三个方面监测数据库应用相关的服务，确保数据库运行正常。数据库的关键参数有数据库系统设计的文件存储空间、系统资源的使用率、配置情况、数据库当前的各种资源情况、监控数据库进程的状态、进程所占内存空间、可用性等。包括监控并分析数据库空间、使用状态、数据库I/O及数据库日志文件等工作。
|
|
|
| （1）数据库基本信息监测包括数据库的文件系统、碎片、死锁进程的监测，数据库可设置死锁检测进程执行的间隔时间，死锁检测进程负责监测、处理数据库系统中出现的死锁。
|
|
|
| 数据库管理员应当密切注意数据库系统中是否有死锁的发生。一旦有死锁存在，就应当查找原因，想办法避免死锁的发生。一般处理死锁的方法有两种：使用死锁预防措施，使系统永不进入死锁状态；或允许系统进入死锁状态，使用死锁检测与恢复机制进行恢复。
|
|
|
| （2）数据库表空间监测。Oracle数据库中提出了表空间的设计理念，Oracle中很多优化都是基于表空间的设计理念而实现的。设置表空间可以用来控制用户的空间使用配额，可以控制数据库所占用的磁盘空间。数据库管理员还可以将不同类型的数据放置到不同的表空间中，这样可以明显提高数据库输入／输出性能，有利于数据的备份与恢复等管理工作。数据库表空间监测。
|
|
|
|
|
|
|
|
|
| 数据库备份就是将数据库中的数据及数据库的物理和逻辑结构等相关数据字典信息，存放在其他的存储介质中进行保存。数据库的备份操作可以在脱机状态下进行，其他用户要断开和数据库的连接，不能访问数据库；也可以在联机状态下进行，允许其他用户同时操作数据库；既可以备份整个数据库，也可以只备份数据库的某些部分。对数据库备份方式的选择，与特有的应用系统、数据库的日志归档模式密切相关。
|
|
|
|
|
| 与数据库运行相关的故障一般包括事务故障、系统故障和介质故障。在各种故障发生以后，把数据库中的数据从错误状态恢复到某一已知的正确状态（也称为一致状态或完整状态），该过程称为数据库恢复。针对不同的故障情况，采取的恢复措施是不相同的。
|
|
|
| （1）事务故障：事务故障是指由于事务内部的逻辑错误（如运算溢出、数据输入错、记录找不到等）或系统错误（如并发事务发生死锁而被选中撤销等）所引起的，使事务在未达到规定的终点以前就被迫中止的任何事件。逻辑错误和系统错误都可能造成事务执行失败，逻辑错误指事务由于某些内部条件而无法继续正常执行，这样的内部条件包括非法输入、找不到数据、溢出或超出资源限制等；系统错误指系统进入一种状态，使得事务无法继续执行。但该事务可以在以后的某个时间重新执行。事务故障在事务处理过程中发生时，应撤销该事务对数据库的一切更新。一般采取的措施是反向扫描日志文件，对增、删、改的操作进行逆向操作，直至该事务开始为止。
|
|
|
| （2）系统故障：系统故障又称为软故障，是指使系统停止运转的任何事件，如特定类型的硬件错误（CPU故障）、软件故障、停电等事件，使得系统需要重新启动。这类故障影响正在运行的所有事务，但不破坏数据库。出现系统故障后，首先需要重新启动操作系统或DBMS，然后扫描日志文件，对重做队列中每个事务进行正向扫描日志文件，依据日志文件中的次序，重新执行登记操作。对撤销队列中每个事务进行反向扫描日志文件，依据日志文件中相反的次序，对每个更新操作执行逆操作，从而恢复原状。
|
|
|
| （3）介质故障：介质故障又称为硬故障，主要指外存故障，如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。出现介质故障后，必要时需重新安装修复系统，装入最新的备份副本，重新装入有关的日志文件副本，根据日志文件，重做最近备份以后提交的所有事务。
|
|
|
|
|
| 数据库维护人员根据用户需求和监测结果对数据库性能进行调整和优化，如执行空间释放、表的重构、索引重建、数据分片等操作。
|
|
|
|
|
| 事务日志文件记录着用户的各种数据库操作，对于用户操作频繁的数据库，其事务日志空间膨胀速度非常快，数据库维护人员需定期检查事务日志的大小，减少磁盘空间的耗用。以SQL Server2008数据库管理系统为例，压缩数据库。一般步骤如下。
|
|
|
| 在SQL2008中清除日志就必须在简单模式下进行，等清除动作完毕再调回到完全模式。
|
|
|
|
|
|
|
| 方案二：部分命令模式＋任务-收缩-文件（单个数据库）
|
|
|
|
|
| 右键-任务-收缩-文件-确定，数据库的日志只保留了1MB，如下图所示。
|
|
|
|
|
|
|
|
|
| 优点：清除日志所运行消耗的时间短，90GB的日志在几分钟左右即可清除完毕，做完之后做个完全备份在几分钟内即可完成。
|
|
|
| 缺点：此动作最好不要经常使用，因为它的运行会带来系统碎片。普通状态下LOG和DIFF的备份即可截断日志。
|
|
|
| 此语句使用的恰当环境：当系统的日志文件异常增大或者备份LOG时间太长可能影响生产的情况下使用。
|
|
|
|
|
| 对数据库中不断被更新的表，在经过一段事件的处理之后便出现以下问题：表中存在记录的转移，表的数据页中存在未回收的空间，表中的扩充不连续等；同时，数据字典中有关表的统计信息已不能准确反映表中数据的真实情况，优化器使用这些不准确的统计信息，就不能为相关SQL语句生成合理的执行计划。
|
|
|
| 对不断被更新的表，数据库管理员应当定期地或者在大批量的数据处理之后重新收集表的统计信息，检查表中数据及磁盘空间使用。如果发现大量记录的转移、未回收的空间，就需要重新构建表。在重构表时，首先需要导出表中数据，在删除并重建表后再装入数据。
|
|
|
|
|
| 索引是提高数据查询最有效的方法，正确的索引可能使效率提高很多，而无效的索引可能是浪费了数据库空间，甚至大大降低查询性能。针对有频繁的插入／更新／删除操作的表，表和索引将产生较多的碎片，索引将变得非聚簇，性能也将下降，严重的时候会产生索引阻塞等问题，为此需要进行索引重建。索引重建的方法一般有两类：一种是删除并重建索引，如采用DROP INDEX和CREATE INDEX或ALTER TABLE来删除并重建索引；另一种是在现有索引的基础上进行重新整理，如采用DBCC INDEXDEFRAG按照索引键的逻辑顺序，通过重新整理索引里的页来减少外部碎片，通过压缩索引页里的行并删除那些由此产生的不需要的页来减少内部碎片。
|
|
|
|
|
| 数据分片是将海量数据根据一定的规则分布在多个存储设备上，这样每个存储设备的数据量相对就会小很多，由此实现并行的读／写操作，满足读／写量大的系统的性能需求。系统分片的策略有很多，如按记录编号的特征、按数据的时间范围、基于检索表等。这些数据分片策略之中没有哪个有绝对的优势，选择哪种策略完全是根据系统的业务或数据特征来确定的。值得强调的是：数据分片在对系统的性能和伸缩性带来一定好处的同时，也会大大增加系统开发和维护的复杂度。因此，数据分片只在特殊需要的时候才做，它带来的维护复杂度会比集中存储的方式高出很多。
|
|
|
