以SQL Server 2005为例，它可以将某些系统事件和用户自定义的事件记录到SQLServer错误日志和Windows应用程序日志中。这两种日志都会自动标上时间。
（1）在事件查看器中查看服务器的运行情况
SQL Server 2005服务器的启动、关闭和暂停动作，都会产生一个事件记录，这个记录会记在Windows的事件查看器中。如果在SQL Server 2005服务器设置的安全性中，设置登录审核，那么符合登录审核条件的事件记录，也会记录在Windows的事件查看器中，下面介绍查看SQL Server 2005事件记录的办法。 ① 在计算机的【开始】菜单中单击【管理工具】，再单击【事件查看器】。 ② 在打开的【事件查看器】对话框中，选择【事件查看器（本地）】，再单击【应用程序】选项，则右边的列表框里可以看到所有的事件记录列表。 ③ 选择其中一个事件，将弹出如图1所示的事件属性对话框，从中可以看到事件的详细内容。这里是审核成功信息。通过这一项可以看出是否有黑客成功入侵。图1 事件属性对话框 ④ 事件查看器中有可能记录了各种不同应用程序的事件记录，如果只想查看和SQLServer有关的事件记录，可以右击应用程序，在弹出的快捷菜单中选择【查看】中的【筛选】选项。在这里可以筛选事件类型、事件来源、类别、事件时间等。 在事件查看器的安全性系统中，也会记载着与SQL Server 2005相关的事件记录，不要忘记查看它们。在Windows应用程序日志中，不仅记录数据库启动停止和身份审核信息，还会完整地记录Windows操作系统上发生的事件，以及SQL Server和SQL Server代理中的事件。
（2）SQL Server 2005的新增功能
与以往的版本相比较，SQL Server 2005支持通过日志查看器查看SQL Server的日志。具体方法为使用SQL Server Management Studio进行查看，步骤如下。 ① 启动【SQL Server Management Studio】并连接到SQL Server服务器上。 ② 在【对象资源管理器】中，展开【实例名】→【管理】→【SQL Server日志】，可以看到SQL Server的日志存档。 ③ 双击某一个日志存档，打开如图2所示的【日志文件查看器】窗口，可以查看日志的具体内容。
图2 日志文件查看器窗口
2. Oracle
Oracle数据库在企业级别中的应用十分广泛，尤其是在金融、电力、银行、交通等支柱产业。究其原因是这些领域往往需要大量的数据存储，一般是以数据仓库的方式和数据库集群的方式进行数据库服务器的分布式处理，对于数据库的分布式处理是一种多级数据处理过程，每一层次在运行的过程中会产生大量的日志积累，如何有效地利用这些遗留下来的日志数据以发现有价值的信息，或者从历史日志中发现数据库的异常操作？ 从目前来看，分析Oracle日志的唯一方法是使用Oracle公司提供的Log Miner进行，Oracle数据库的所有更改都记录在日志中，但是原始的日志信息非专业技术人员根本无法看懂，而Log Miner就是让普通人看懂日志信息的工具。由此而言，它和tkprof差不多，一个是用来分析日志信息，另一个则是格式化跟踪文件。通过对日志的分析可以达到下面目的：查明数据库的逻辑更改；侦查并更正用户的误操作；执行事后审计；执行变化分析。 不仅如此，日志中记录的信息还包括数据库的更改历史、更改类型（INSERT、UPDATE、DELETE、DDL等）、更改对应的SCN号以及执行这些操作的用户信息等Log Miner在分析日志时，将重构等价的SQL语句和UNDO语句（分别记录在V$LOGMNR_CONTENTS视图的SQL_REDO和SQL_UNDO中）。这里需要注意的是等价语句，而并非原始SQL语句。例如，最初执行的是“delete a where c1 <>‘cyx’;”，而Log Miner重构的是等价的6条DELETE语句。因此，需意识到V$LOGMNR_CONTENTS视图中显示的并非是原版的现实，这从数据库角度是很容易理解的，它记录的是元操作，因为同样是“delete a where c1 <>‘cyx’;”语句，在不同的环境中，实际删除的记录数可能各不相同，因此记录这样的语句实际上并没有什么实际意义，Log Miner重构的是在实际情况下转化成元操作的多个单条语句。
DB2数据库日志分循环日志和归档日志。数据库安装成功后系统默认为循环日志。使用循环日志时，一旦日志目录中最后一个主日志文件被写满，就会将新的事务写到第一个日志文件中，从而覆盖现有的日志数据，依次会覆盖旧的日志文件，因此循环日志不能使用向前回滚的方法恢复数据库。使用循环日志免去了总需要进行日志归档备份或磁盘空间不够的麻烦，但由于不能使用向前回滚的方法恢复数据库，一旦发生故障，会造成丢失大量数据的风险，在一些关键性系统，均采用归档日志的方式。 与循环日志记录相比，当最后一个日志文件写满时，归档日志记录过程会创建一个新的日志文件。这样将来的事务就不会覆盖现有的日志文件。当初始化数据库时，系统会在日志目录中分配一定数量、指定大小的主日志文件。这个数量及目录位置由数据库配置参数控制。当主日志文件都写满时，如一个多数据处理的事务过程，就会创建辅助日志文件，直到创建了最大数量的辅助日志文件为止。一旦达到了这个数量，就会发出一个错误，指出没有更多的可用日志文件，所有数据库事务活动停止，无法对数据库数据进行处理。对于主日志和辅日志个数的定义，没有具体的标准，都是根据具体应用及环境合理定义数据库使用归档日志方法，当数据库崩溃或发生故障时，可以使用之前完整的数据库备份，然后使用归档日志的前滚操作，通过前滚到日志结尾，将数据库恢复到时间点状态或最近的一致状态，从而恢复数据库。 从DB2版本8.2开始，系统支持三种方式的归档日志：一是将归档日志存放到磁盘上；二是将归档日志存放到TSM服务器；三是第三方厂商提供的产品。 ▲ - The end -
