好的日志文章精选(九篇)

前言：一篇好文章的诞生，需要你不断地搜集资料、整理思路，本站小编为你收集了丰富的好的日志文章主题范文，仅供参考，欢迎阅读并收藏。

第1篇：好的日志文章范文

关键词：分布式计算；日志分析；Hadoop；集群；vmware

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）34-7647-04

1 概述

日志文件是由系统或者应用程序产生的，用于记录系统和应用程序的操作事件如各种服务的启动、运行、关闭等信息。通过对日志文件的分析可以获得很多有价值的数据也能实现对系统安全、性能等方面的监控。Web日志[1]是由Web服务器产生的，随着社交网络的兴起，Web2.0时代的到来，网站的用户访问量的成级数增长，产生的日志文件大幅增多。传统的日志文件分析方式已经无法满足大数据量日志分析的需求。该文将以Web日志文件为例，利用Hadoop集群构建一个分布式计算平台为大数据日志文件的分析提供一个可行的解决方案，以提高了日志分析的效率，为进一步的大数据分析的提供参考。

现今日志文件分析方案是对大的日志文件先进行分割，然后对分割后的日志文件进行分析，分析方法采用文本分析及模式匹配等，最常见的是采用awk、python、perl。这种分析方式面对大数据的日志文件分析效率低下，耗时长。王潇博提出了基于挖掘算法的日志分析方式，并设计了TAT系统[1]。对于Web分析除了对Web日志本身进行分析外还可以主动收集访问信息，然后将信息存于关系型数据库中。这种方式最常见的是Google Analytics、百度统计等。这种方式将会影响网站的性能，延长网站的加载时间。其次如果直接采用第三方的统计，还将会泄露网站的信息。当访问量高时，基于关系型数据库分析的方式将会受到数据库性能的制约。钱秀槟，刘国伟，李锦川等人提出了基于模式匹配算法的Web应用日志分析系统[2]。

2 Hadoop集群系统概述

日志文件记录了日常操作的原始数据，数据极具价值。随着时间的推移日志文件越来越大，分析难度也随着增大。本系统的设计就是为了解决文本日志的分析，系统针对Web日志。本系统基于搭建好的Hadoop分布式架构，将数据先存入到HDFS文件系统中，运行mapreduce程序对日志文件进行过滤分析，最后将数据输出到指定文件中。充分发挥了Hadoop分布式存储和分布式计算的优势。 解决了海量数据日志文件的分析的难题，采用基于分布式结构的日志分析系统，提高了分析效率。

目标日志是由Apache服务器产生的访问日志。Apache采用默认安装方式时，访问日志access.log，存在于Apache安装目录的logs子目录下。访问日志access_log记录了所有对Web服务器的访问活动。下面是访问日志中一个典型的记录：

222.192.32.17 - - [30/Jun/2011：18：52：25 +0800] "GET /index.php？ img=pngWrench HTTP/1.1" 200 741

这行内容由7项构成1） 远程主机的IP地址。2）浏览者的标识（空白用一个“-”占位符替代）3）记录浏览者进行身份验证时提供的名字（空白用一个“-”占位符替代）。 4）请求的时间。5） 请求类型（METHOD RESOURCE PROTOCOL）。6）状态代码（请求是否成功及原因）。7）发送给客户端的总字节数。

3 系统的设计与实现

3.1 系统的基本目标

利用分布式的架构对日志文件进行分析，对日志文件进行过滤，按时间对日志数据进行分析。分析主要从页面pv、ip、请求状态、流量等方面出发。每月PV总量、PV量最多的一天、每月每个url的pv、每月独立IP、每天的流量、月总流量、每天的访问状态统计、每月的访问状态统计、每天的请求方式统计、每月的请求方式统计等等。

3.2 Hadoop部署

图1介绍了Hadoop部署的基本结构，MapReduce 模型中的 Master 的主控作业节点称为 JobTracker，此框架下面的所有作业（Job）都是由 JobTracker 进行管理的，它是唯一存在的。TaskTracker，负责每一个具体任务的执行。任务（Task）是具体执行的基本单元，每一个作业被拆分成很多的任务，被分配到合适任务节点上去执行，任务节点一边执行分配过来的任务，一边向 JobTracker 汇报执行任务的状态，以此来帮助JobTracker 了解作业执行的整体情况，向空闲节点分配新的任务等操作。

3.3 日志数据的HDFS存储

图2展示了HDFS的工作原理。首先client通过调用DistributedFileSystem的create方法来创建文件。DistributedFileSystem通过RPC调用NameNode在文件系统的名字空间里创建一个文件。DistributedFileSystem返回FSDataOutputStream给client。FSDataOutputStream封装了一个DFSOutputStream来处理与datanodes和namenode之间的通讯。当client写一个block数据的时候，DFSOutputStream把数据分成很多packet。FSDataOutputStream询问namenode挑选存储这个block以及它的副本的datanode列表。这个datanode列表组成了一个管道，在上图管道由2个datanode组成（备份参数是2），这2个datanode的选择有一定的副本放置策略。4、FSDataOutputStream把packet写进管道的第一个datanode，然后管道把packet转发给第二个datanode。

当管道里所有datanode都返回写入成功，这个packet才算写成功，发送应答给FSDataOutputStream。开始下一个packet。如果某个datanode写失败了，首先管道关闭。运行正常的datanode上正在写的block会有一个新ID（需要和namenode通信）。这样失败的datanode上的那个不完整的block在上报心跳的时候会被删掉。失败的datanode会被移出管道。block中剩余的packet继续写入管道的其他两个datanode。同时namenode会标记这个block的副本个数少于指定值，然后block的副本会稍后在另一个datanode创建。

有些时候多个datanode会失败。只要dfs.replication.min（缺省是1）个datanode成功了，整个写入过程就算成功。缺少的副本会异步的恢复。当client完成了写所有block的数据后，调用FSDataOutputStream的close方法关闭文件。最后FSDataOutputStream通知namenode写文件结束。

3.4 日志分析过程

日志分析系统由客户端和Hadoop服务器组成，客户端调用Hadoop接口将日志文件存入HDFS并调用任务，这里的任务是按顺序执行的，在前一个任务执行成功后才执行下一个任务，每个任务都完成多件事，每个任务都调用map和reduce过程，最后一个任务将数据输出到HDFS的文本文件，也可以将文件输出到数据库中，最后根据统计数据进行展示。如图3。

4 结果分析

系统硬件环境的CPU为2.00GHz，内存为4G可用内存为3G，实验时为三台机器分配的内存情况master为256M，slave1为336M，slave2为384M。软件环境操作系统为rhel-server-6.0，JRE的版本：java-1.6.0。Hadoop版本：Hadoop-1.0.1。HDFS集群概况如图4。

通过分析执行过程的输出，第一个任务map过程耗时2分31秒，reduce耗时9秒，整个任务耗时2分48秒。Map过程读取的记录为311965条。reduce读取字节数为45431334，输出字节数为3938231。任务二，map26秒，reduce，16秒，累计47秒。任务三，map28秒，reduce，18秒，累计耗时51秒。所有任务总耗时：4分16秒。从数据可以看出，使用vmware虚拟机进行构建性能收到主机性能的影响，受限较多。但是，Hadoop架构能有效对任务进行调度和分配，达到预期效果。

图5可以看出任务输出了三个目录test-out1、test-out2、test-out3。每个任务输出一个，前两个目录存放的是临时的文件，test-ou3目录存放的是结果文件。这些输出的文件是根据日期来的，分为月汇总数据和每天的数据，这些文件存放了最终的结果。

图6和图7截取了六月份的部分数据。此文件存放了六月每个访问页面的pv总量，以及六月访问数据的汇总。六月的pv总和为139，get方式为127，post方式为12，http访问状态200次数为125，访问状态301次数为2，访问状态403次数为4，访问状态404次数为8，pv量最多的一天为2011年6月30日121次，最多的页面为/favicon.ico访问次数为7次，月流量为46698。也可以查看六月具体每一天的数据。图8是单日统计数据，这一天的pv量为5，get方式请求为4，post方式请求次数为1，请求的状态码都为200即请求成功，总流量为1684字节。

5 小结

分布式计算作为一项日趋成熟的技术，逐渐展露了其优势。Hadoop框架很好的将分布式文件系统HDFS和MapReduce编程模型进行了融合。使用Hadoop可以很便捷的搭建了一个分布式集群环境，它对分布式任务控制调度有很好的性能和伸缩性。以此实例为基础可以进一步进行拓展，对大数据任务进行更深入和详细的分析和挖掘，为各个领域的大数据处理提供参考。

参考文献：

[1] 王潇博.基于挖掘算法的日志分析系统设计与实现[D].北京：北京交通大学，2008：26-33.

[2] 钱秀槟，刘国伟，李锦川，等.Web 应用日志分析系统分析与设计[J].计算机安全，2011，2011（6）.

[3] 肖立英，李建华，谭立球.Web日志挖掘技术的研究与应用[J].计算机工程，2002，28（7）：276-277.

[4] 张彦超，刘云，张海峰，等.基于在线社交网络的信息传播模型[J].物理学报，2011，60（5）：60-66.

[5] 胡光民，周亮，柯立新.基于Hadoop的网络日志分析系统研究[J].电脑知识与技术，2010， 6（22）：65-69.

[6] 辛大欣，刘飞.Hadoop集群性能优化技术研究[J].电脑知识与技术，2011，7（22）.

[7] 韩亚.关系传播：WEB2.0时代的传播偏向[D].武汉：华中科技大学，2008：1-2.

[8] Mark Lutz.Python学习手册[M].北京：机械工业出版社，2009：659-665.

第2篇：好的日志文章范文

关键词：日志取证；关联分析；特征关联；序列关联

0　引言

随着信息技术的发展，计算机犯罪案件不断涌现，计算机取证技术成为人们研究的热点。计算机取证要解决的关键问题是如何从计算机犯罪现场挖掘犯罪方法、犯罪动机、犯罪工具，确定犯罪责任。日志文件是计算机和网络系统用于记录发生在计算机本地系统或者网络中的事件的重要审计凭据，是计算机犯罪线索勘查取证的重要对象，是计算机犯罪中非常重要的线索和证据来源。分析日志数据能及时发现入侵者入侵行为，是提取犯罪证据的重要手段。然而，进行日志分析存在如下困难：日志文件本身并不安全，一旦攻击者获得root权限，就可以轻而易举地修改、破坏或删除系统所保存的日志记录，从而使得日志分析失去意义；日志文件的格式与种类具有多样性，需要统一格式或跨平台操作；目前还没有形成比较完善的日志分析策略。本文将从这几个方面入手，提出了基于日志分析处理策略的取证模型。

1　日志关联分析取证模型

日志关联分析是指将所有系统中的日志以统一格式综合在一起进行考虑。在网络安全领域中，日志关联分析是指对网络全局的日志安全事件数据进行自动、连续分析，根据用户定义的、可配置的规则来识别网络威胁和复杂的攻击模式，从而确定事件真实性、进行事件分级并对事件进行有效响应。日志关联分析可以用来提高安全操作的可靠性、效率以及可视化程度，并为安全管理和应急响应提供技术手段。

关联分析需要采集各系统中的原始数据，将采集来的数据进行集中统一管理，根据有关知识进行分析后得到相应的结果。一个典型的日志关联分析系统应包括如下部件：采集，数据库，日志管理，知识库，关联分析，证据提交及证据库。其关联取证模型如图1所示。日志采集负责从不同节点收集取证日志信息，日志管理模块对日志信息进行安全存储，关联分析模块对取证日志信息进行事件特征关联、事件时间关联和时间空间关联，由日志更新方法和日志格式描述规则生成日志知识库引擎，日志存储服务器中的日志文件由知识库引擎驱动生成日志知识数据库，经日志关联分析方法处理得到分析结果存入证据库并打印取证分析报表，并将分析结果反馈到各分布节点。

2　日志取证关键部件

2．1　日志收集

日志收集是安装在目标机器或网络的软件或硬件，它们根据取证策略收集有关被取证目标的日志详细情况。日志数据源可分为基于主机的日志数据源、基于网络的日志数据源、基于网络安全设备和软件的日志数据源。日志文件的分布是比较分散的，日志稽查取证往往从网络传输信源、信道、信宿的角度出发进行研究，其中信源是指数据传输的起点，信道是数据传输经过的中间途径，信宿是数据传输的目的地。常见的信源日志有PC上的各种客户端软件的日志，信道日志有网络节点的路由器日志、隔离设备如防火墙、IDS等设备的日志，信宿日志有各种网络服务器日志，如Web服务器日志E-Mail服务器日、Ftp服务器日志等。

在可利用的数据源中，各级各类日志包含丰富的证据信息，由于关联分析需要将多个安全设备上的报警信息集中到一处进行分析，因此需要在各安全设备上设置，由将安全设备上的信息传输到中心数据库。传输的数据有可能是完整的日志数据，也可能是在本地搜集信息并经简单分析的结果。

2．2　日志管理

产生系统日志的软件通常为应用系统而不是操作系统，所产生的日志记录容易遭到恶意的破坏或修改。系统日志通常存储在系统未经保护的目录中，并以文本方式存储，未经加密和校验处理，没有防止恶意篡改的有效保护机制。因此，日志文件并不一定是可靠的，入侵者可能会篡改日志文件，从而不能被视为有效的证据。由于日志是直接反映入侵者痕迹的，在计算机取证中扮演着重要的角色，入侵者获取系统权限窃取机密信息或破坏重要数据后往往会修改或删除与其相关的日志信息，甚至根据系统的漏洞伪造日志以迷惑系统管理员的审计。

有效的日志数据分析是建立在日志文件本身安全的基础上的，因此建立一个安全的日志文件管理体制是必要的。图2为日志管理模块。各分布节点的原始日志文件经压缩、加密和MD5签名后，通过VPN被分别传输给专用日志服务器和第三方公认服务器，服务器利用收到的MAC完成对取证日志信息完整性检验，并将通过完整性验证的具有取证价值的日志信息存入相应的远程日志库和公证日志库。考虑到日志文件本身的安全，虚框内部分用两块网卡进行物理隔离。

2．3　日志数据关联分析策略

系统日志是对系统的运行状况按时间顺序所作的简单记录，仅反映本系统的某些特定事件的操作情况，并不完全反映用户的全部活动情况。用户的网络活动会在很多的系统日志中留下痕迹，如防火墙日志、IDS日志、操作系统日志等，这些不同的日志存在的某种联系反映了该用户的活动情况。只有将多个系统的日志结合起来分析，才能准确反映用户的活动情况。

为了能够为关联分析建立一致的分析方法，可使用IDMEF格式对犯罪入侵事件关联进行建模。在XML文档中，一种称为文档类型定义的格式被用来描述IDMEF数据。当然，关联功能并不直接处理XML格式表示的事件，而是针对一系列预先准备好的日志数据，一般来说这些数据存储在日志数据库中。

日志关联分析模块如图3所示。日志关联分析可以细分为以下三个步聚：

(1)数据聚合

将数据库中来自多个设备的不同数据集中的数据归整于一个数据集中，这样能在任意时间观察到所有设备的事件。通过删除重复数据、归类相似数据等方式来压缩数据量，可以将数据保持在一个关联引擎可以处理的范围内。

(2)事件特征关联

从多个日志源采集过来的数据，经过聚合和规范化等操作后，已经可用来进行关联分析。在计算机取证中，我们挖掘电子证据数据项之间存在的关联，并在关联中查找、发现并分析计算机犯罪行为在不同位置、各个目标、行为意图方面的一些联系和规律，提取犯罪行为之间的关联特征(特征可能是经过预处理的统计特征)，挖掘不同犯罪形式的特征、同一事件的不同证据间的联系，为进一步侦察分析和破案提供线索。

基本的数据挖掘算法并不考虑专业领域的知识，结果会产生一些对实际应用无用的规则，并且算法的效率不能满足要求。Apriori算法在日志关联取证中有两个致命的弱点：第一，多次扫描日志数据库极大地加重了I/O负载，因为每次k循环的侯选集Ck中的每个元素都必须扫描日志数据库一次来验证其是否 加入Lk。如一个频繁大项集包含10个项，就至少需要扫描事务数据库10遍。第二，由Lk-1、产生k-侯选集Ck是指数增长的，如104的L－频繁项集就可能产生接近107个元素的2一侯选集，如此大的候选集对取证时间和主存空间都是一种挑战，达不到取证的实时性要求。

针对上述两个问题，作者对算法改进如下：对事件主次属性进行约束，对支持度和置信度阀值设置进行修改。经过这样的处理之后，可以有效缩短证据的分析提取时间。

第一，对事件主次属性的约束。日志记录中各个属性的重要性不同，有的属性对描述数据起着关键作用，有的属性只提供辅助信息。比如在描述网络连接的记录中，每一条记录表示一个连接，一个网络连接可以被一个五元组惟一地标识，即。网络连接的关键属性可以定义为五元组集合，日志记录主要涉及主体、对象和操作行为，可以用三元组来惟一地表示，Telnet记录的Shell命令的关键属性可以用二元组来表示。那么我们就可以用关键属性作为衡量关联规则r是否有趣的标准，即I(r)=f(IA(r)，s(r)，c(r))，当模式r含有主属性，则IA=I，否则IA=0。通过关键属性和参考属性的约束，减少“无趣”规则的产生，即规定，当算法产生一条新的规则时，其中必须至少包括一个关键属性或者参考属性。

第二，修改支持度和置信度阀值设置。一种思想是将支持度修改为相对支持度。所谓相对支持度是针对某一个变量而言的。如果定义si是变量Ai的相对支持度，并且变量值对Ai=Vij在整个记录集中一共出现了Nij次，那么如果包含Ai=Vij的规则覆盖实例的个数超过Si*Nij个，那么我们认为这条规则满足支持度约束。这种方法应用在计算机取证分析中，需要有一定的先验知识，能够对每个变量Ai设定出合理的相对支持度阀值。另一种思想借鉴了在文献[1]中提出的一种在多层次概念上挖掘关联规则的算法，即对同一层次上不同频繁度属性进行多级挖掘，其主要思路是：先设置一定的支持度和置信度阀值，对出现频率高的属性值进行挖掘，得到相关的模式；然后不断降低支持度和置信度阀值挖掘出现频率低的属性相关的模式。在降低阀值设置的挖掘过程中，我们需要对那些“旧”的属性值的参与加以限制，避免高频率属性值相关模式的大量产生，淹没低频率属性值模式。这里我们作这样的限制：候选项目集必须包括至少一个“新”的属性值；每次循环计算挖掘得到的模式必须具有“新”的属性值。整个过程在阀值降到指定的最低值时终止，这个最低值可以是所有关键属性值中出现频率最低的属性值的阀值。

(3)事件序列关联

入侵行为往往没有明显的字符串匹配特征，其中任何单独的一条报文或者命令都看似正常，但一系列按时间顺序排列的报文或者命令就构成了一次攻击，而且这种攻击序列在一次攻击中只出现一次。序列模式挖掘比关联规则挖掘粒度更大。以某种序列攻击的多个样本作为训练源，可以挖掘出在一个样本中只出现一次，而在多个样本中频繁出现的攻击行为的特征序列。

考虑到网络事件在时间和空间上的相关性，可在网络连接记录中加入时间的统计属性，生成序列规则。如：端口扫描攻击中的TCP SYN扫描，不是进行一次完整的TCP连接，而是只发送一个SYN数据包，如收到SYN/ACK表示商品处于侦听状态，如收到RST表示端口没有处于侦听状态。如果先收到SYN，回应SYN/ACK后，未收到ACK应答，查看历史发现短时间内还有来自相同地址、相同类型的数据包，就有理由认为对方正在进行端口扫描攻击。口令暴力攻击也具有明显的时序特征。比如说使用某一个用户名自A地址登录，出现多次登录失败，比较历史记录发现从B地址登录的同一用户，极少出现登录失败情况。则可以初步判定从地址A发来的登录信息在进行口令探测。

通过对这种基于时间和空间的事件序列的分析，可以得到一些计算机犯罪的意图信息，进而可以发现已经发生的，或者可能发生的计算机犯罪行为和企图。

2．4　提交证据

关联分析的目标是综合分析不同安全设备和应用系统中的日志数据，为取证提供及时、相关并且准确的关联数据。这些关联数据将存入相应证据库，并以特定格式的报告形式提交。

第3篇：好的日志文章范文

关键词：EXT4；日志；句柄；i节点

中图分类号：TP391文献标识码：A文章编号：1009-3044(2011)14-3443-04

The Analysis of Linux EXT4 File System

LU Ya-wen

(Hangzhou Vocational College of Science and Technology, Hangzhou 310016, China)

Abstract: Compared with EXT3 file system, the theory and data structure of EXT4 file system was introduced.By analyzing the WRITE operation,the procedcure of EXT4 file system was explained,and the study will supply some references for users who choosing core of Linux.

Key words: EXT4; daily record; handle; inode

EXT4文件系统是日志文件系统，100%兼容EXT3文件系统，与EXT3文件系统相比的主要区别是它能快速更新文件存储。计算机开始从磁盘上读取或写入数据都必须保证文件系统中文件与目录的一致性，所有日志文件中的数据均以数据块的形式存放在存储设备中,当磁盘分区时文件系统即被创建,按照文件形式、目录形式支持存储数据，组织数据的使用。EXT4提供并使用了一个通用日志层 (jbd) [1]，该层既可在文件系统中使用，还能够应用到其它设备中，对NVRAM设备，EXT4就能支持。当由于软件或硬件错误导致文件系统崩溃时， EXT4使用与e2fsck同样代码来修复崩溃的文件系统,因此在出现数据崩溃时，EXT4具有和EXT3同样的防止数据丢失的优点[2]。但是,上述这些优点不是EXT4独有的,但只有EXT4才尽数具备,这正是EXT4的优势。

1 EXT4文件系统的重要数据结构

以下的数据结构都来自2.6.28内核。

1.1 超级块super_block

/include/linux/EXT4_fs.h

struct EXT4_super_block {

/*00*/ __le32 s_inodes_count; /* 节点数目 */

__le32 s_blocks_count; /* 文件块数 */

__le32 s_r_blocks_count; /* 保留未用的文件块数 */

__le32 s_free_blocks_count; /* 可用的文件块数 */

/*10*/ __le32 s_free_inodes_count; /* 可用的节点数 */

__le32 s_first_data_block; /* 第一个数据块的索引 */

__le32 s_log_block_size; /* 数据块大小 */

__le32 s_log_frag_size; /* 文件碎片大小 */

/*20*/ __le32 s_blocks_per_group; /* 每一组文件块的数目 */

__le32 s_frags_per_group; /* 每一组碎片数目 */

__le32 s_inodes_per_group; /* # 每一组节点数目 */

__le32 s_mtime; /* 最近被安装到内存的时间 */

…………

/*150*/ __le32s_blocks_count_hi;/* 文件块数的高32位 */

__le32s_r_blocks_count_hi;/*保留未用的文件块数高32位*/

__le32s_free_blocks_count_hi;} /* 可用文件块数高32位 */

合适的特定设备和不适合的特定设备的不同是在，如果在不合适的特定设备中有一位设备是内核无法识别的，内核将会拒绝启动文件系统。在EXT4中，e2fsck的要求更加严格，如果他既不能在合适的特定设备中，也不能在不合适的特定设备中识别出一个设备 ，他一定会终止程序并且不会将它所不能识别的设备模块化。

与日志相关的数据结构，只有在EXT4文件系统中才会起作用，同样在EXT3文件系统中也有定义，但是在EXT4文件系统中配合日志文件数据结构才能起到日志文件的功能。

1.2 组描述符 Group Descriptor

组描述符合超级块一样，记录的信息与整个文件系统相关。当某一个组的超级块或inode受损时，这些信息可以用于恢复文件系统。因此，为了更好的维护文件系统，每个块组中都保存关于文件系统的备份信息。

struct EXT4_group_desc

{__le32 bg_block_bitmap; /* 文件块位图所在的块的索引*/

__le32 bg_inode_bitmap; /* 存放文件节点位图的块的索引*/

__le32 bg_inode_table; /* 文件节点表在外存中的第一个块的索引*/

__le16 bg_free_blocks_count; /* 可用的文件块数 */

__le16 bg_free_inodes_count; /* 可用的节点数 */

__le16 bg_used_dirs_count; /* 使用中的目录数 */

__u16 bg_flag;/*用于32位地址对齐*/

__u32 bg_reserved[3];

__le32bg_block_bitmap_hi; /*文件块位图所在的块的索引的高32位*/

__le32bg_inode_bitmap_hi; /*存放文件节点位图的块的索引高32位*/

__le32bg_inode_table_hi;};/*文件节点表在外存中的第一个块的索引高32位*/

1.3i节点数据结构

struct EXT4_inode {

__le16 i_mode; /* 文件模式，表示文件类型以及存取权限 */

__le16 i_uid; /* 所属用户的id的低16位 */

__le32 i_size; /* 节点字节大小 */

__le32 i_atime; /* 节点存取时间 */

__le32 i_ctime; /* 节点创建时间 */

__le32 i_mtime; /* 节点修改时间 */

__le32 i_dtime; /* 节点时间 */

__le16 i_gid; /* 组标志的低16位 */

__le16 i_links_count; /* 连接数目 */

__le32 i_blocks; /* I节点文件块数 */

__le32 i_flags; /* 文件标志 */

union {

struct {

__le32l_i_reserved1;

} linux1;

struct {

__le32h_i_translator;

} hurd1;

struct {

__le32m_i_reserved1;

} masix1;

} osd1; /* OS dependent 1 */

__le32 i_block[EXT4_N_BLOCKS];/* 文件块索引数组，数组大小15*/

__le32 i_generation; /* 文件修改 (for NFS) */

__le32 i_file_acl; /* 文件 ACL */

__le32 i_dir_acl; /* 目录 ACL */

__le32 i_faddr; /* 碎片地址 */

union {

struct {

__le8 l_i_frag; /* 碎片号 */

__le8 l_i_fsize; /* 碎片大小 */

__le16 i_pad1;

__le16 l_i_uid_high; /* I节点用户id高位 */

__le16 l_i_gid_high; /* I节点组号高位 */

__le32 l_i_reserved2;

} linux2;//1级间接指针数据结构

struct {

__le8 h_i_frag; /* 碎片号 */

__le8 h_i_fsize; /* 碎片大小 */

__le16 h_i_mode_high;

__le16 h_i_uid_high;

__le16 h_i_gid_high;

__le32 h_i_author;

} hurd2; //直接指向物理块的节点的数据结构的补充

struct {

__le8 m_i_frag; /* 碎片号 */

__le8 m_i_fsize; /* 碎片大小 */

__le16 m_pad1;

__le32 m_i_reserved2[2];

} masix2;//2级间接指针数据结构

} osd2; /* OS dependent 2 */

__le16i_EXTra_isize;

__le16i_pad1;

__le32i_ctime_EXTra;/* 节点扩展的创建时间(nsec

__le32i_mtime_EXTra;/* 扩展的修改时间(nsec

__le32i_atime_EXTra;/* 扩展的存储时间(nsec

__le32i_crtime; /* 文件创建时间*/

__le32i_crtime_EXTra;};/* 扩展文件创建时间 (nsec

上述结构体中有两个联合体，是为了节省空间考虑，因为i节点的索引有三种情况前12个直接指向物理块，第13个是一级间接指针，第14个是二级间接指针，第15个是三级间接指针，将这三种情况都写在一个联合体中，根据实际的情况选择节点号，根据节点的类型来选择用联合体中的那个数据结构。与EXT3不同的是，在 EXT4 文件系统中，增加了5个项，用于扩充索引节点，通过这个结构解决了这对于对精度要求很高的程序的要求。

1.4 i节点的扩展信息的数据结构

这个结构体是日志式文件系统所特有的，用来支持完成日志文件的各种操作[3]。也是2.6内核与2.4内核的不同之处。i节点文件块组是包含一系列文件节点的块组。包含了节点的生命期，它通常用于为分配文件块的决定。我们将文件的数据块放到他的i节点块的附近，新的节点放到它的父目录节点的附近。存放i节点大小的栈不在内存中而在外存上。在缩减的过程中，节点的大小被虚拟文件系统调用EXT4_truncate函数而设置成新的大小，但是文件系统不会将节点的磁盘大小设为0，除非这样的缩减真的执行了。目的在于节点的大小总是表示正在使用的文件的块数。当节点数据写入的时候我们要重新改写节点磁盘的大小来代替节点的大小[4]。只有在缩减的进行时节程执点的大小和节点所在的磁盘空间的大小才会不一样，其他情况都应该是一致的。只有在执行文件块增长或缩减的时候存放节点大小的栈才会被改动。

struct EXT4_inode_info {

__le32 i_data[15];

__le32 i_flags; //i节点标志

#ifdef EXT4_FRAGMENTS

__le32 i_faddr; //第一个碎片的索引

__le8 i_frag_no;//碎片数目

__le8 i_frag_size;//碎片大小

#endif

__le32 i_file_acl;

__le32 i_dir_acl;

__le32 i_dtime;

__le32 i_block_group;//i节点文件块组

__le32 i_state; /* EXT3的动态的状态标志 */

__le32 i_nEXT_alloc_block;

/* i_nEXT_alloc_block 是在该文件中最近分配的块的逻辑号。当然，他没

有命名，我们用这个来决定相关的分配请求所分配的文件块的逻辑号。

/*

__le32 i_nEXT_alloc_goal;

/* i_nEXT_alloc_goal是下一个分配块号的物理标志。他是与此文件分配的文件块号最相近的物理块号。当用户请求分配一个新的物理块的时候将这个物理块分配给用户*/

struct semaphore truncate_sem;//元数据块，数据的修改信息等

struct inode vfs_inode;

/*虚拟文件系统的节点，通过这个数据可以将日志文件系统EXT4和linux文件系统的顶层虚拟文件系统连接起来*/

};

1.5 句柄handle_t数据结构

此结构是EXT4文件系统用来实现日志式文件操作的有利的数据结构。

struct handle_s

{ transaction_t *h_transaction;//文件操作过程

int h_buffer_credits;//要被弄脏的缓冲区的数目

int h_ref;//句柄中的参照数

int h_err;//出错数

struct list_head h_jcb;// 磁盘操作的头节点

unsigned int h_sync: 1; /* sync-on-close */

unsigned int h_jdata: 1; /* 日志数据 */

unsigned int h_aborted: 1; /* 句柄中致命的错误 */

};

transaction_t 类型是日志系统的一个内容。它记录下了数据在各种状态下的改变情况。

各种状态为：

* RUNNING: 正在进行新的修改

* LOCKED: 修改在进行但是句柄不接受这样的改变

* RUNDOWN: 修改在整理中但是还没有完成对缓冲区的修改。

* FLUSH: 所有的修改完成了但是我们还没有写到磁盘上。

* COMMIT: 所有的数据都在磁盘上，写操作执行

* FINISHED: 完成保持准备接受下一次修改

2 EXT4的文件操作

2.1 EXT的文件操作的数据结构

struct file_operations EXT3_file_operations = {

.llseek = generic_file_llseek,

.read = do_sync_read,

.write = do_sync_write,

.aio_read = generic_file_aio_read,

.aio_write = EXT3_file_write,

.readv = generic_file_readv,

.writev = generic_file_writev,

.ioctl = EXT3_ioctl,

.mmap = generic_file_mmap,

.open = EXT3_open_file,

.release = EXT3_release_file,

.fsync = EXT3_sync_file,

.sendfile = generic_file_sendfile,

};

这个结构体说明了EXT4文件系统的read操作是由do_sync_read函数来实现的，write操作是由do_sync_write函数来实现的，以此类推。只要我们找到相关的函数就能分析EXT4文件系统是怎么实现读写操作的。

2.2 EXT4的写操作

以下分析写操作的过程，因为日志式的文件的写操作和其他的文件系统有很大的不同所以以写操作为例：

图1是写操作执行时各个函数嵌套的顺序图。

① file->f_op->write即调用EXT4文件系统中的write操作，在operation结构的解释中指出write操作用do_sync_write操作完成。

② filp->f_op->aio_write即调用EXT4文件系统中的aio_write操作，在operation结构的解释中指出aio_write操作用EXT4_file_write操作完成。

LINUX中写操作是通过sys_write系统调用来实现的，在sys_write函数中完成对文件file 的读入，判断正确后调用了vfs_write函数进一步判断文件的模式是否为写是否与其他写操作冲突，如果判断正确后调用file->f_op->write，这个调用其实是去调用EXT3文件系统中的write操作（即do_sync_write）再调用aio_write（即EXT4_file_write）来完成读写制定大小的文件内容到缓冲区中包括对日志的写。

EXT4_file_write函数的分析如图2。

3 结束语

本文讨论的对象是Linux操作系统中EXT4内核程序，介绍了EXT4的主要数据结构，并通过分析写操作来解释日志的工作方式。日志文件系统提高了文件系统的效率，但是也增加了系统的开销。2.6.28内核中的EXT4文件系统比2.4内核做了较多的改动，如前面介绍的节点的扩展信息，和Htree结构的修正（文中没有介绍），NTFS文件系统的修正等。总体来说EXT4文件系统是比较完善的日志文件系统。

参考文献：

[1] 李善平,陈文智.边学边干LINUX内核指导[M].浙江：浙江大学出版社,2002.

[2] 涂健,孙辉.Linux2.6(内核下)EXT3文件系统的数据结构及性能分析[J].南昌水专学报,2004(6):8-10.

[3] 李巍.Ext―扩展文件系统的研究[J].信息系统工程,2010(8):133-136.

第4篇：好的日志文章范文

关键词：AIX；SAP系统；Oracle数据库；同构；数据迁移

中图分类号：TP315 文献标识码：A 文章编号：1007-9599 （2012） 15-0000-02

1 系统环境描述

目标系统T49已经搭建完毕，使用现有的T49环境来完成PRD的数据迁移。

源系统环境（生产系统）

OS：AIX 5.3

DB：ORACLE 9.2.0.3

SAPSID：PRD

DBSID：PRD

目标系统环境（测试系统）

OS：AIX 5.3

DB：ORACLE 9.2.0.3

SAPSID：T49

DBSID：T49

R/3 Version：4.6C

Kernel：46D_EXT

2 迁移前的准备工作

2.1 备份PRD数据库控制文件

使用以下命令生成PRD数据库控制文件

sqlplus/nolog

connect/as sysdba

alter database backup controlfile to trace resetlogs

生成的文件名及路径为：

/oracle/PRD/saptrace/usertrace/PRD_ora_xxxxx.trc

2.2 创建NFS

将T49系统的/oracle/T49使用NFS到PRD系统，NFS文件系统命名为：rmtt49

2.3 分别停止源系统及目标系统的SAP服务，并确认SAP和ORACLE进程已停止

2.4 在目标系统T49上所作的准备工作（很重要：请注意是目标系统T49，切勿搞错！）

（1）删除垃圾文件及清除日志文件

#cd /oracle/T49/saparch

#rm *.dbf

#cd /oracle/T49/saparch/cntrl

#rm cntrlT49.dbf

（2）删除T49上/oracle/sapdata1-sapdata6及日志文件

#cd /oracle/T49

#rm-rf sapdata1

……

#rm-rf sapdata6

#rm-rf mirrlogA

……

#rm-rf origlogB

3 开始迁移

从源主机PRD拷贝数据文件日志文件到目标主机T49

（1）用oracle用户拷贝源主机PRD上的sapdata1-sapdata6（6个目录）到T49上

在目标主机T49上：

用root用户在根目录下mount，

#cd

#mount/rmtt49

#su–orat49（用orat49用户）

#cd/rmtt49

#cp-Rp sapdata1/oracle/T49&（&表示用后台）

……

#cp-Rp sapdata6/oracle/T49&

查看后台拷贝进程

ps–ef|grep cp

（2）从源主机PRD上把mirrlogA、mirrlogB、origlogA、origlogB拷贝到目标主机T49上

#cd/rmtt49

#cp–Rp mirrlogA/oracle/T49

……

#cp–Rp origlogB/oracle/T49

（3）传输并修改生成的controlfile

在/oracle/PRD下面

cd/oracle/PRD/saptrace/usertrace

用ftp工具把PRD_ora_xxxxx.trc文件传至目标系统

用Text Editor编辑PRD_ora_xxxxx.trc文件（修改结束后可改名存为db.sql）

把所有PRD改为T49

把REUSE改为SET

把从文件头到startup nomount（包括startup nomount这一行的内容，注意：是第二个startup nomount）的内容删除，把此文件最后一个

“CHARACTER SET WE8DEC

；”

以后的内容全部删除，然后存盘。

4 恢复工作（在目标主机T49上的操作）

（1）把修改好的db.sql文件放在T49上的/oracle/T49/的目录下，并改变此文件的权限

#chmod 777 db.sql

（2）启动oracle数据库，执行db.sql文件

#su–orat49

#sqlplus/nolog

SQL>connect /as sysdba；

SQL>startup nomount；

SQL>@db.sql；

SQL>recover database using backup controlfile；（执行这条命令会提示要求输入一个文件名称，这个文件是在T49上的/oracle/T49/origlogA或/oracle/T49/origlogB中的八个文件之一：log_g11m1.dbf---log_g18m1.dbf的其中一个

格式：/oracle/T49/origlogA/log_g11m1.dbf

SQL>alter database open resetlogs；

SQL>commit；

SQL>shutdown

（3）检查目标主机T49的oracle数据库能否正常启动关闭

SQL>startup

初始化sapr3的密码和创建OPS$t49adm用户。

System需密码初始化

SQL>Alter user system identified by manager；

Orat49>sapdba->m->d->y

（4）启动目标主机T49上的sap

切换到sap用户

#su–t49adm

启动sap

#./startsap

用下面的命令来查看sap和oracle进程是否正常

#ps-ef|grep ora

#ps-ef|grep sap

（5）在目标主机T49上，先删除旧的license，安装新的license

#su–t49adm

#saplicense–get

#saplicense–show

#saplicense–delete

#saplicense–install

5 结束语

本文以SAP系统同构迁移为例，讲述系统迁移的一种方法。通过以上方法，能快速地进行ORACLE数据迁移；该方案在实践中得到了验证，迁移后的测试系统运行效果良好。

第5篇：好的日志文章范文

关键词：数据挖掘;日志分析;聚类挖掘

中图分类号：TP311.131文献标识码：A文章编号：16727800（2011）012016802

作者简介：李卿(1987-)，女，江西吉安人，安徽理工大学硕士研究生，研究方向为计算机应用技术。1研究思路

源数据为user.txt和log.txt两个文本文件。user.txt 为用户分组文件，共1703条记录，以下是其中一条记录：

用户名 用户组

user253 104

其中，102为研究生组、103为本科生组、104为教职工组、105为办公用户组。

log.txt为用户上网日志文件，是全校所有用户在2006年11月10日12:28:48至2006年11月11日04:59:58时段内的上网记录，共389348条记录，以下是其中一条记录：

10.10.35.18 user1378 - [10/Nov/2006:12:28:48 +0800] "GET HTTP/1.0" 200 6170 TCP_MISS:DIRECT

包含了用户的IP、用户名、访问时间、访问网站的地址、返回类型、请求的字节数等内容。

参照数据挖掘的过程，按以下几个步骤展开数据挖掘工作：①数据准备：对用户信息文件和日志文件进行数据处理，将源数据转换成适宜进行数据挖掘的数据；②数据挖掘：对处理后的数据采用聚类的方法进行数据挖掘；③结果分析与表示：对前面步骤中获得的信息进行总结与评价。

2数据准备

此阶段对用户信息文件和日志文件进行数据预处理和数据清洗，将源数据转换成适宜进行数据挖掘的数据。数据的预处理是将普通文本形式的源数据转换成方便挖掘的数据库文件；数据清洗则根据需求对预处理后的数据进行属性和记录的删减。

2.1数据预处理

利用SQL Sever的“数据导入\导出任务”将user.txt中的数据导入新建的数据库dm中，采用默认命名user，将用户名和用户组命名为"uno"和"ugroup"，设置uno为主键。采用相同的方法将log.txt转换成log表，各字段名为：ip、uno、non、time、port、get、url、http、type、byte、tcp。

2.2数据清洗

(1)去除user表中不合法的数据。对user表进行分组，得出研究生组的记录有299条，本科生组有731条，教职工组有569条，办公用户组有89条，4组共1688条，与总记录数有出入。可知其中存在不合法数据，使用SQL语句去除。

(2)去除log表中多余的字段。log表中并非所有的字段信息都有用，只需保留用户的IP、用户号、访问时间、访问地址、返回类型，请求的字节数这几个关键字段。

(3)统计上网用户信息。提取整个时段内上网用户和用户组信息，并剔除不合法的记录，得到一个拥有341条记录的uno_ugroup表。说明有341人上网，此表作为挖掘模型的一个输入表。

(4)按小时统计各时段的在线人数。日志按秒记录用户的访问信息，需筛选出每秒操作的用户数，按小时分组统计每个时间段的在线人数，如图1所示。

(5) 按用户分组统计访问网站的频率。以用户访问网站的频率为参照衡量用户上网的时长，尽可能从log表中剔除一些以url以gif、jpg、css、js、swf结尾的间接访问记录，并使用如下命令可得出访问排名：

SELECT uno,COUNT(uno) AS 访问频率 FROM log

GROUP BY uno

ORDER BY COUNT(uno) DESC图1在线人数时段分布图

从排名中可知用户user1775访问操作最频繁，经查询易知该用户为本科生,上网时段为13:07:19~13:50:46和17:26:57~23:17:36，该同学整个晚上的时间都在网上。

(6) 按用户分组统计资源的占用情况。分析带宽的占用情况本来应该以秒为单位分别统计用户流量，求均值后再排名，但这样过于复杂。在这可以换一个思路，按用户号统计流量，排序靠前流量越高的，占用的带宽也较高。可使用如下命令得到带宽占用的排名：

SELECT uno,SUM(byte) AS 上网总流量 FROM log

GROUP BY uno

ORDER BY SUM(byte) DESC

排名中可知user1641用户排名第一访问量相当大，经查询得知该用户为教职工，上网时段为12:30:50~01:36:51，连续7小时在线，视频下载操作频繁。

3数据挖掘

利用SQL Sever 2005的SSAS组件对上网用户进行聚类挖掘。将2.3中生成的uno_ugroup表加到其数据源中，在挖掘结构中新建聚类挖掘模型，设置如图2所示：

图2聚类挖掘模型设置

对模型处理完成后，可在挖掘模型查看器的分类剖面图中，看到具体的参数情况，如图3所示：

图3分类剖面图

同时可以看到各类别的概率，如图4所示：

图4分类特征

4结果分析与表述

通过数据准备和挖掘，可以得出本校网络用户的上网情况如下：

(1)工作日在线人数不多，人数分布按教职工、研究生、本科生、办公用户降序排序。

(2)上网有两个高峰时段：13:07:19~13:50:46和17:26:57~23:17:36。午饭时间和晚饭时间的在线人数较少。

(3)个别用户上网时间较长，可通过其访问网站的频率衡量其在线时长的排名。

(4)个别用户占用网络带宽较为严重，网络访问数据量大的原因通常是访问视频文件造成的。

网络管理员可以根据以上情况对访问网络的行为为进行相应的管理与限制，如对视频下载操作进行合适的限定，对上网时间较长的用户加以关注，提醒同学合理安排时间等。

5结束语

本文对校园网日志中的在线人群分布、用户访问网站的频率、访问量等情况进行了分析，使用了SQL Sever 2005中的聚类挖掘算法进行数据挖掘，得到了较为明显的分析结果。日志中有一些字段并未利用，日后还可以利用SQL Sever中的其他挖掘算法，对数据进行更进一步的清洗和挖掘。参考文献：

[1]韩家炜,梦小峰,王静,等.Web挖掘研究[J].计算机研究与发展,2001(4).

[2]方杰，朱京红.日志挖掘中的数据预处理[J].计算机技术与发展,2010(4).

[3]孙峰.数据挖掘在SQL Sever 2005中的应用[J].硅谷,2010(5).

第6篇：好的日志文章范文

关键词：电子商务；Web挖掘；客户行为

中图分类号：F224-39

文献标识码：A

文章编号：167Z-3198(2009)08-0237-02

1 电子商务中客户的重要性

营销学上有个著名的公式；100－1＝0，即一个企业即使有100个客户对其感到很满意，但是只要有一个客户对持否定态度，企业的盛名就可能立即化为0，尽管这个观点有点夸大其实，但是至少它说明了一个问题，即：客户满意的重要性。

市场经济体制下，公司的目标就是为企业持股者争取利润的最大化，而公司的利润从何而来――客户。换句话说，为客户服务能创造长期的利益，而长期的利益又能够满足持股者的目的需求。虽然，使客户满意需要花更多的钱，同时也需要更长的周期，但是长周期加上大量的资金意味着企业更多的利益。所以，客户对企业的重要性是越来越突出。即使在电子商务领域这个遵循市场经济体制的网上交易体系。这一重要性也是同样符合的。

如今Google、Amazon、Yahoo、MSN等一些Web公司都要求员工运用Web挖掘技术来了解客户行为，并根据挖掘出的信息数据及模式设计更加符合客户需求的服务和产品。也就是说利用Web挖掘可以了解客户行为，其分析的数据结果可提供给企业参考，做出合适的调整策略。

2　客户行为的Web挖掘

2.1　挖掘数据来源

在挖掘过程中，关键性步骤是提供合适的挖掘对象。在电子商务中，客户行为挖掘的数据源，主要有以下几种：

(1)服务器日志文件。

Web服务器日志文件记录了客户每次登录浏览网站的行为信息，包括了IP地址、时间、页面等，是Web挖掘的主要数据源。

(2)Cookies日志文件。

Cookies是服务器为自动跟踪网站浏览者而在客户端生成的标志，用于存储类似于购物手推车状态信息或者浏览者所访问的电子商务网站的页面信息或交易信息等。

(3)客户信息。

客户信息指客户通过Web页在屏幕上输入的、要提交给服务器的相关信息。在电子商业网站须进行信用授权才能进行交易，因此客户大量的个人资料会传到网站上。对这些信息组织序化后，存储到数据仓库中可作为长期分析客户消费趋势的来源。

2.2　挖掘过程

对客户行为的Web挖掘并不是杂乱无序的，一般其过程可分为三个阶段：

(1)数据的预处理；

预处理主要对用户访问日志(包含用户的访问日志、引用日志和日志)进行过滤、反蜘蛛化、客户验证、会话和路径补全等处理，形成用户会话文件。

①过滤：收集完数据后，首要的步骤便是过滤出不想要的记录，为分析做准备。

②反蜘蛛化：所谓蜘蛛，就是搜索引擎对万维网的扫描建立索引的半自动化程序。蜘蛛的行为与人的行为不同(要比客户的全面)，在数据处理中要把蜘蛛的行为和客户的行为区分开来，并过滤掉蜘蛛行为在服务器上的记录。

③客户验证：在会话之前必须识别客户，一是识别出同一客户在一次浏览中为建立会话而发出的页面请求，另一目的是识别在多次站点浏览的同一客户，使我们能够分析客户在数天，数月或是数年中的行为。

④会话；会话指客户在一次访问中访问的所有Web页面，通过这些可以反映出访问者对网站什么地方有兴趣或关心。

⑤路径补全；客户在浏览网时可能出现页面后退现象，导致路径损失，所以需要根据客户访问前后页面进行推理，补全访问路径。

(2)模式发现：

模式发现是对数据预处理所形成的用户会话文件，利用数据挖掘的一些有效算法，例如统计分析、关联规则、聚类、分类等。来发现隐藏的模式、规则。

①统计分析：统计方法是从电子商务网站中抽取知识的最常用的方法。可以根据选择的特征来分析网页此特征的点击次数，根据获得的数据结果来调整网站。

②关联规则：根据关联规则，可以从客户访问网站的行为中找出相关性。利用这些相关性，可以改进电子商务网站的结构，例如哪些产品可以摆在一起或捆绑销售。

③聚类和分类：聚类规则是从一组数据项中聚集出相似特征的一个聚类，可分为用户聚类和网页聚类。而分类规则是找出描述并区分数据类或概念的模型，并使用模型预测类标记未知的对象类。

(3)模式分析：

在这个阶段，主要是对挖掘出来的模式、规则进行分析，找出用户感兴趣的模式，并辅助理解。最常见的模式分析方法是采用sQL查询语句进行分析。另一种分析方法是先将数据导入并提供可视化的结果输出。

3　Web挖掘的应用

网络个性化服务是目前电子商务商业运作和发展的新方向，它根据用户兴趣、爱好、习惯，以及各个用户之间的相关性等向用户在线推荐商品，提供浏览建议，通过不定期调整网站的结构方便用户访问。动态地为用户定制个性化的网站等。

如今，许多商家一直在寻求识别有利可图的市场分割和追踪网络使用者的行为习惯，其目的是提醒用户他们可能感兴趣的产品的实用性。这就出现了像亚马逊网站那样的一种新模式，根据某一特殊用户可能感兴趣的问题提出所需信息。对于被特征化的用户，运用一些客户分类、挖掘技术，让他们了解所感兴趣产品的预报。

网络个性化服务的本质就是以客户为中心提供Web服务。首先，客户浏览访问电子商务网站的资源；其次，系统分析客户行为特性，创建访问模型；最后，根据所获取的信息知识调整服务，系统进行推荐来满足不同用户的个性化需求。通过客户与系统不断的交互，最终为客户提供个性化服务。

4　Web挖掘面临的问题

Web挖掘给电子商务带来新机遇的同时，也带来潜在的问题――隐私安全问题。网络的特点使得我们在网站上留下的信息几乎都可以被全世界获得。事实上，对用户数据的采集和挖掘，有些时候利用了用户的注册信息和登记信息，这包括客户姓名、性别、地址、出生年月、电话号码、购物习惯、收入、信用卡号码、电子邮件及经常访问的Web站点地址等私人信息。如果这些信息的利用未得到客户的允许，则会涉及到隐私权问题并产生纠纷。

如何对客户隐私进行保护，我们可以从三个方面着手：第一，立法进行强制性规范；第二，对涉及隐私的网上数据采取技术防范；第三，行业自律，不随意泄露客户信息，禁止买卖数据等。

第7篇：好的日志文章范文

关键词:校园网络安全;安全防御机制;蜜罐;蜜网

中图分类号:TP393文献标识码:A文章编号:1009-3044(2009)33-9234-03

随着基于计算机网络技术的现代教育手段应用的日益广泛, 各地建设校园网的热情空前高涨。校园网的普及对加快信息处理、合理配置教育资源、充分利用优质教育资源、提高工作效率、减轻劳动强度、实现资源共享都起到了不可估量的作用,信息安全问题也日益突出。 作为从局域网基础上发展起来的校园网也面对这样的安全问题。 因此, 解决网络安全问题刻不容缓。网络与信息安全技术的核心问题是对计算机系统和网络进行有效地防护。网络安全涉及面很广, 从技术层面上讲主要包括防火墙技术、入侵检测技术、病毒防护技术、数据加密和认证技术、蜜罐技术等, 这些安全技术中, 大多数技术都是在攻击者对网络进行攻击时对系统进行被动的防护。而可以采取主动的方式的蜜罐技术就是用特有的特征吸引攻击者, 同时对攻击者的各种攻击行为进行分析并找到有效的对付方法。结合蜜罐构建的网络安全防御系统, 可使网络防御者化被动为主动, 更好地研究入侵者的行为和动机, 从而更好地保护校园网络。

1 蜜罐的定义及分类

“蜜罐”的思想最早由Clifford Stoll 于1988 年6 月提出,作者在跟踪黑客的过程中,利用了一些包含虚假信息的文件作为黑客“诱饵”来检测入侵。明确提出蜜罐是Lance Spitzner 给出的定义:蜜罐是一种安全资源,其价值在于被探测、攻击或者摧毁。蜜罐是一种预先配置好的系统,系统内含有各种伪造而且有价值的文件和信息,用于引诱黑客对系统进行攻击和入侵。蜜罐系统可以记录黑客进入系统的一切信息,同时还具有混浠黑客攻击目标的功能,可以用来保护服务主机的正常运行。蜜罐系统收集到的信息可以作为跟踪、研究黑客现有技术的重要资料,可以用来查找并确定黑客的来源;还可以用来分析黑客攻击的目标,对可能被攻击的系统提前做好防护工作。

蜜罐在编写新的IDS特征库、发现系统漏洞、分析分布式拒绝服务(DDOS)攻击等方面是很有价值的。蜜罐本身并不直接增强网络的安全性,将蜜罐和现有的安全防卫手段如入侵检测系统(IDS)、防火墙(Firewall)、杀毒软件等结合使用,可以有效提高系统安全性。

按照蜜罐实现时,允许操作系统与入侵者交互的复杂程度,蜜罐系统可以划分为低交互级蜜罐系统、中交互级蜜罐系统和高交互级蜜罐系统。

1) 低交互级蜜罐系统:典型的低交互级蜜罐仅提供一些简单的虚拟服务,例如在特定的端口监听记录所有进入的数据包。这类蜜罐没有向入侵者提供可以远程登录的真实操作系统,因此风险最低,但是蜜罐所扮演的角色是非常被动的,就象一个单向连接,只有信息从外界流向本机,而没有回应信息发出,无法捕捉到复杂协议下的通讯过程,所能收集到的信息有限。

2) 中交互级蜜罐系统:中交互级蜜罐系统也不提供真实的操作系统,但是却为入侵者提供了更多复杂的诱骗进程,模拟了更多更复杂的特定服务,使攻击者误认为是一个真正的操作系统,能够收集更多数据。但同时也增加了蜜罐的风险,因此要确保在模拟服务和漏洞时不产生新的真实漏洞,而给黑客攻击真实系统的机会。

3) 高交互级蜜罐系统:高交互蜜罐提供了真实的操作系统和服务,可以了解黑客运行的全部动作,获得更多有用信息,但遭受攻击的可能性大,引入了更高风险,结构较复杂。高交互蜜罐系统部署的代价最高,需要系统管理员的连续监控。不可控制的蜜罐对任何组织来说没有任何意义甚至可能成为网络中最大的安全隐患。

从具体实现的角度,可以分为物理蜜罐和虚拟蜜罐。

1) 物理蜜罐:物理蜜罐通常是一台或多台真实的在网络上存在的主机,这些主机上运行着真实的操作系统,拥有自己的IP 地址,提供真实的网络服务来吸引攻击。

2) 虚拟蜜罐:虚拟蜜罐通常用的是虚拟的机器、虚拟的操作系统,它会响应发送到虚拟蜜罐的网络数据流,提供模拟的网络服务等。

2 蜜罐的配置模式

1) 诱骗服务(deception service)

诱骗服务是指在特定的IP服务端口帧听并像应用服务程序那样对各种网络请求进行应答的应用程序。DTK就是这样的一个服务性产品。DTK吸引攻击者的诡计就是可执行性,但是它与攻击者进行交互的方式是模仿那些具有可攻击弱点的系统进行的,所以可以产生的应答非常有限。在这个过程中对所有的行为进行记录,同时提供较为合理的应答,并给闯入系统的攻击者带来系统并不安全的错觉。例如,当我们将诱骗服务配置为FTP服务的模式。当攻击者连接到TCP/21端口的时候,就会收到一个由蜜罐发出的FTP的标识。如果攻击者认为诱骗服务就是他要攻击的FTP,他就会采用攻击FTP服务的方式进入系统。这样,系统管理员便可以记录攻击的细节。

2) 弱化系统(weakened system)

只要在外部因特网上有一台计算机运行没有打上补丁的微软Windows或者Red Hat Linux即行。这样的特点是攻击者更加容易进入系统,系统可以收集有效的攻击数据。因为黑客可能会设陷阱,以获取计算机的日志和审查功能,需要运行其他额外记录系统,实现对日志记录的异地存储和备份。它的缺点是“高维护低收益”。因为,获取已知的攻击行为是毫无意义的。

3) 强化系统(hardened system)

强化系统同弱化系统一样,提供一个真实的环境。不过此时的系统已经武装成看似足够安全的。当攻击者闯入时,蜜罐就开始收集信息,它能在最短的时间内收集最多有效数据。用这种蜜罐需要系统管理员具有更高的专业技术。如果攻击者具有更高的技术,那么,他很可能取代管理员对系统的控制,从而对其它系统进行攻击。

4) 用户模式服务器(user mode server)

用户模式服务器实际上是一个用户进程,它运行在主机上,并且模拟成一个真实的服务器。在真实主机中,每个应用程序都当作一个具有独立IP地址的操作系统和服务的特定是实例。用户模式服务器这样一个进程就嵌套在主机操作系统的应用程序空间中,当INTERNET用户向用户模式服务器的IP地址发送请求,主机将接受请求并且转发到用户模式服务器上。这种模式的成功与否取决于攻击者的进入程度和受骗程度。它的优点体现在系统管理员对用户主机有绝对的控制权。即使蜜罐被攻陷,由于用户模式服务器是一个用户进程,那么Administrator只要关闭该进程就可以了。另外就是可以将FIREWALL,IDS集中于同一台服务器上。当然,其局限性是不适用于所有的操作系统。

3 蜜罐Honeypot 的在校园网中的实现

本人首先研究了宜兴技师学院的网络环境和面临的安全威胁,分析了校园网的特殊性及校园网的安全需求, 根据校园网的需求和特点, 再结合宜兴技师学院网络的硬件设施和学院的具体情况, 提出了我院的网络安全解决方案,构建了本院的蜜罐系统,取名为:HoneypotMe。我们设计该蜜罐系统的目的是为了研究和验证蜜罐在校园网安全领域所起的作用,通过实践加深对蜜罐思想的理解,并进一步在实际环境中使用它来加强网络的安全性。

我们在校园网中搭建了如下的试验平台, HoneypotMe 的系统结构及虚拟网络拓扑结构如图1 所示。HoneypotMe 是由虚拟网络、虚拟蜜罐、防火墙、虚拟蜜罐的日志及分析系统、入侵检测系统及被动探测系统几部分组成的综合系统。

这里的虚拟蜜罐系统建立的是一个虚拟的网络和主机环境。它通过模拟操作系统的TCP/IP 栈来建立蜜罐,可模拟各种不同的操作系统及设备,如Linux,Windows 2000,Windows NT,Cisco Switch等。它采用的方式是使用与Nmap 或Xprobe 相同的指纹(fingerprint)数据库来模拟操作系统,以响应针对虚拟蜜罐的网络请求,这样可以愚弄像Xprobe 或Nmap 这样的TCP/IP 栈指纹识别工具。另一方面,这个系统也可以模拟虚拟网络拓扑,在模拟的网络配置中包含路由器,并且包含路由器的连接特性,比如反应时间、包丢失和带宽等。这样可以愚弄traceroute 这类工具,使网络流量看起来遵循了所模拟的网络拓扑。在我们的系统中,不仅通过栈指纹愚弄和吸引攻击者以探测攻击,而且还建立了一些模拟的服务,让它们来与攻击者进行交互作用。不同的系统平台上通过脚本模拟着不同的服务,例如:在模拟的Windows 系统上打开NetBIOS端口,在模拟的 Linux 系统中激活mail 和FTP,而模拟的Cisco 路由器有一个标准的Telnet 端口,这样可使建立起来的网络环境看上去更加真实可信。每个被模拟的计算机系统都有一个IP 地址与之绑定,这些被绑定的地址是一些未被分配网络地址。这样配置起来的系统灵活多变,与真实的生产性系统混合在一起,更增加其诱捕和欺骗作用。图3.9 虚线框中所示就是为实验环境设计的虚拟蜜罐的网络拓扑图。Honeyd 是一个构建虚拟蜜罐的软件,可以利用它实现我们构建虚拟蜜罐的目标。另外,作为一个开放源代码解决方案,可为开发利用提供方便,比如,可编写其它的服务脚本以扩充系统的功能等。为了防止由于攻击者对蜜罐系统的破坏,使蜜罐系统瘫痪,可使用防火墙来保护该蜜罐系统。防火墙被配置成允许任何连接进入到几个虚拟蜜罐中,但是严格控制到系统本身的访问,本系统选用IPTables 来保护宿主OS 的外部IP 地址。收集和分析攻击者的信息是HoneypotMe 能力的一项重要体现。由于蜜罐没有生产性的活动,没有任何正常流量会流向它正在监视的几个IP 地址。这使得分析它捕捉到的信息极其简单,因此它捕捉到的任何东西很可能是具有敌意的。Honeyd软件有生成日志的功能,日志全面描述了什么系统什么时候正在探测什么端口。IDS 能对已知的攻击发出警报,同时可将所有网络流量记录到一个文件或数据库中。为了获得分析数据包捕获的更详细的信息,在HoneypotMe 蜜罐系统中安装和配置了Snort 入侵检测系统。Snort 收集到的信息一方面记录到Snort 的日志文件中,另一方面记录到Mysql 数据库中以便观察和统计分析之用。另外,我们打算利用被动探测详细地分析攻击者的特征。这就需要捕获原始数据包供被动探测工具使用。可利用Snort 入侵检测系统获取Tcpdump 这样的二进制日志记录格式以作为被动探测工具的输入数据,获取攻击者更详细的信息以实现隐蔽探测。

正如我们所看到的,蜜罐系统使用许多独立的工具和脚本创建,在其中还包括一些日志文件和数据库供分析之用。开发图形用户界面来配置、管理蜜罐以及集中管理所有信息来源是我们的目标。蜜罐收集了许多来自不同来源的信息,将它们存储到多个日志文件和数据库中。用GUI 来分析这些文件和使所收集的数据相关联是会有很大的帮助的,这样的话管理员就不需要记住存储数据的所有文件。另一个很主要的优点是其外观,在基于web 的GUI 上表示信息比访问日志文件清晰整洁的多。目前,我们仅实现了在web 界面上浏览Honeyd 日志的功能。

4 实验过程及结果分析

为了验证该系统,虚拟蜜罐宿主机被连接到校园网的物理网络环境中,并为其分配一个真实的分配给物理计算机的IP 地址,在这里我们给其分配的IP 地址为192.168.40.7。所有实现虚拟蜜罐系统的软件都将运行在Linux9.0 操作系统下。图3.9 的虚线部分显示出我们要模拟的虚拟网络结构及各个虚拟蜜罐。从图中可以看出虚拟蜜罐1(IP 地址为192.168.40.56)、虚拟蜜罐2(IP 地址为192.168.40.57)、虚拟蜜罐3(IP 地址为192.168.40.58)和虚拟蜜罐4(IP 地址为192.168.40.59)与虚拟蜜罐宿主机处于同一个网段。从这个网段通过一个IP 地址为192.168.40.123 的路由器(路由器1)模拟一个地址空间为10.0.1.0/24 的网络,在这个网段中包括两个虚拟蜜罐:虚拟蜜罐5(10.0.1.51)和虚拟蜜罐6(10.0.1.52)。从这个网段通过一个IP 地址为10.0.1.100 的路由器(路由器2)又增加了另一个地址范围为10.1.0.0/16 的网络,在此网络中分布了两个蜜罐虚拟蜜罐7(10.1.0.51)和虚拟蜜罐8(10.1.0.52)。

我们知道虚拟蜜罐系统是一个完全被配置起来的计算机系统,它在配置文件中描述每一个引用。

每个样本定义了每个模拟的操作系统的性能。“特征(personality)”这就是操作系统在IP 堆栈层要模拟的东西,可利用Nmap 指纹数据库里相同的描述作为它的OS 类型。在样本windows 里,特征为“Windows NT 4.0 Server SP5-SP6”,在linux样本里,它的特征为“Linux 2.4.16 C 2.4.18”。注意,特征并不影响所模拟的服务的行为,仅仅修改IP 栈的行为。对于所模拟的服务,必须根据想要模拟的OS 的类型选择不同的脚本。换句话说就是,如果特征是Windows,不要绑定一个模拟的Apache 脚本到HTTP 端口,而是绑定一个IIS 脚本到HTTP 端口。应该说,这些服务都是入侵者在相应的操作系统中希望找到的。在样本中,你可以为端口规定明确的行为,也可以定义为一般的行为。两个样本中将TCP 和UDP 的缺省行为定义为reset,因此在一般情况下,对于TCP 来讲将用RST(连接复位)去响应任意的连接企图,对于UDP,将用ICMP 端口不可达去响应。对于定义为open 行为的端口,对于TCP 将用ACK 响应,而UDP 将什么也不响应。从样本中可以看出,Windows系统的NetBIOS 端口处于打开状态;当一个机器与这个蜜罐的80 端口连接时,该蜜罐用IIS 仿真程序perl 脚本与客户机进行交互;另外Linux 系统的mail 和FTP服务被激活。上面的两个样本分别被绑定在不同的IP 地址上。

5 结论

总之蜜罐技术是灵活的,我们可以按照自己的实现目标来构建自己的蜜罐系统。在这里我们利用虚拟蜜罐框架来构建我们校园网的蜜罐,以实现蜜罐的欺骗和诱骗功能。为了控制黑客的行为,防止黑客对蜜罐系统的破坏和利用,在蜜罐系统中加入了防火墙,并选用了Linux 2.4 自带的内核包过滤的工具iptables。为了了解黑客的行为,在蜜罐系统中加入了信息收集和统计分析功能。通过开发web 接口的日志文件查询工具,使蜜罐管理员能够方便快捷地查询虚拟蜜罐框架收集的日志信息。为了获得更详细的黑客攻击和扫描信息并及时得到报警,使用入侵检测系统Snort 来满足我们的需求。最终,为了获取黑客自身的信息而又不被其发现,我们使用被动探测工具p0f 来获取黑客的操作系统指纹。这是实现隐蔽探测的一个很好的思路,即利用蜜罐来引诱攻击者的扫描和攻击,然后使用被动探测工具探查攻击者的信息。这也是我们构建蜜罐系统的一个创新点。综上所述,我们构建的蜜罐系统是一个实现了欺骗和诱骗、行为控制、入侵检测、被动探测、数据分析等功能的综合性蜜罐系统。

参考文献:

[1] 夏明,赵小敏.基于蜜罐技术的病毒样本采集系统的设计和实现[J].信息网络安全,2008(10).

第8篇：好的日志文章范文

1.1　典型的研究计划

美国和欧盟针对图书馆数字资源的访问统计已经展开了一些针对性的研究计划，比如，由美国研究图书馆协会资助的E-Metric项目、美国多个机构（包括ARL、JISC、NISO等）资助的COUNIER项目、欧盟Telematics for Libraries Programme支持的EQUINOX项目等，这些项目多为研究制定描述电子信息服务和资源的统计指标和绩效测度及其方法。

1.2　相关标准

在相关的标准方面，面对新的信息环境和图书馆形态，一些组织开始尝试将新的电子资源绩效评估标准融入原有相关标准／指南的框架。例如NISO在2004年批准了图书馆和信息提供者信息服务和利用的测度和统计数据字典(NISO Z39.7-2004 Information Services and Use:Metrics & statistics for libraries and infomation providers--Data Dictionary)，该标准在传统图书馆工作的基础上，还特别增加了网络服务、网络资源、网络运行的新的测度方法，这套数据字典将逐渐纳入美国图书馆统计工作，成为美国图书馆统计工作的参考依据，

ICOLC1998年制定的《网上索引、文摘和全文资源使用统计测度指南》(Guidelines for Statistical MeaSures of Usage of Web-Based Indexed，Abstracted and Full Text Resources)提供了一套网络化信息资源使用的绩效测度指南。2001年的修订版明确了网络信息使用数据统计的最基本要求，并提供在隐私、保密、获取、传递和报告形式方面的指导。

ISO ISO/CD 11620也在传统服务统计指标的基础上，结合ICOLC和COUNTER的研究，进行了图书涫数字资源测度及其定义、方法的描述。

1.3　国内图书馆数字资源访问统计的研究和应用

国内随着公共图书馆、大学图书馆、科学图书馆系统图书馆评估工作的进行，图书馆界开始逐步重视对图书馆数字馆藏、图书馆数字化信息服务的评估。

参考文献2中提出了数字资源后评估的概念，但是对图书馆数字资源访问统计等后评估的方法和指标体系尚未全面展开评论。一些图书馆自行开发了基于jsp或者asp的图书馆网站访问统计软件，一些数字图书馆系统，如清华同方的TPI、北京拓尔思的TRS、浙江天宇的CGRS等等也提供了相应的统计功能，但是尚没有一款商业化的软件针对图书馆的各种类型的数字资源提供一揽子的访问统计方案。

2　图书馆数字资源访问统计的方式

2.1　WEB日志方式

web服务器在工作时，时刻将WWW访问的结果记录在一些log（日志）文件中，通过对服务器日志的分析可以得到以下信息

(1)通过对访问时间进行统计，可以得到服务器在某些时段的访问情况；

(2)对访问者的IP进行统计，从中可以判断主要是那些用户在访问Web服务器；

(3)对访问请求的错误进行统计和分析，可以找出有问题的页面加以改正；

(4)对访问者清求的URL进行统计，就可以判断出读者对那些页面的内容最感兴趣，对哪些页面的内容不感兴趣。

各种web服务器日志文件的格式和内容大致相同。根据W3C的际准[2]，一般Web日志都包括诸如用户的IP地址、请求时间、方法（GET/POST等）、被请求网页或文件的URL、发送／接收字节数、协议版本等信息。表1列出了几种不同类型的Web日志。

但这些日志文件信息量很大，用户难以直接从log文件获得直观的结果。对日志文件的分析，可以借助一些商业性的或者源代码开放的软件完成。其中比较好的开放源代码的日志分析软件有：AWStats、webalizer等。

从日志文件提供的信息进行统计和分析，就可以对整个网站有一个数字化、精确的认识，从而对网站的设计和内容进行改善和调整，使图书馆网站更好地为读者提供服务。

2.2　资源提供商提供

数据库的使用情况属于后评估指标，主要用于更新、续订数据库时使用，一般在图书馆购买资源提供商的数字资源时，应该要求由出版商或数据库商提供使用报告，再据此进行各类分析。

目前出版商／数据库商提供的统计报告常用的相关统计指标有：

①检索次数(searfh/query)：用户在某一个数据库中提出检索式的次数。

②登录次数(session/sign on)：用户打开某个数据库的次数。

③下载文摘／全文(abstract/fulltext page/image)：用户在某一个数据库中下载到本地客户机中的文摘或全文篇数。

2.3　通过网络proxy

服务器(Proxy Server)是一种服务器软件，它的主要功能有：设置用户验证和记帐功能，可按用户进行记帐，没有登记的用户无权通过服务器访问Internet网，可以对用户的访问时间、访问地点、信息流量进行统计。

目前服务器软件产品十分成熟，功能也很强大，可供选择的服务器软件很多。主要的服务器软件有WinGate公司的WinGate Pro、微软公司的Microsoft Proxy、Netscape的Netscape Proxy、Sybergen Netwo rks公司的SyGate等，这些软件不仅可以为局域网内的PC机提供服务，还可以为基于Novell网络的用户，甚至UNLX的用户提供服务。目前绝大部分Intemet的应用都可以通过方式实现。大多数服务器软件产品具有登记内部网用户访问外部网的日志记录，有些产品还可以直接将日志记录到数据库中。根据日志记录文件或数据库，可以统计内部网每个用户的网络流量以及上网时间，甚至可以按服务网络类型（如：HTTP、SMTP、FTP等）分别进行统计。

2.4　利用脚本语言自行开发

通过web服务器的日志可以获得用户访问图书馆网站信息的情况，但是，这种方式需要对日志的格式进行了解，然后用相应的工具软件或者进行一定的开发来完成。还有一种获取网站访问情况的方法是利用asp或者isp等网络脚本语言，利用它们内置的server、session、request对象等获取相关的信息，获取数据进行统计。比如：利用Jsp我们可以用Jsp的内置request对象的获取参数方法request.get Parameter("userid")，获取用户名；用(request.get Remote Addr)获取访问者的IP地址；通过request.get Header("User-Agent")获取包含浏览器和操作系统的信息，然后用字符串分割substring()方法来分别得到浏览器和操作系统；通过Jsp的内置对象session的方法session，get Creation-Time()返回Session被创建的时间，而session.get Last Accessed Time()则返回当前Session对象最后被客户发送的时间，两者之差为停留时间。

主要分以下几个开发步骤：

(1)确定将要统计的信息；

(2)建立数据库；

(3)实时的访问信息纪录，记录每次点击的信息，包括页面信息、用户信息、访问IP、访问时间；

(4)实时信息的分类存储；

(5)显示方式的选择。可以用Windows的表格系统，也可以自行编制表格显示。

利用这种方法相对比较简单，但是可获得的统计指标也有限。

除了上述几种统计方式外，还有基于路由器的流量统计、基于防火墙的流量统计、基于以太网广播特性的流量统计。但是这些方法所提供的简单流量的统计功能，不能完全满足图书馆数字资源访问统计的目标。

3　图书馆数字资源访问统计的指标

3.1　国际图书馆联盟的统计指标指南

国际图书馆联盟认为，信息资源提供商对他们提供的特定的电子信息资源所提供的统计数据应该满足以下的最低需求。

必须提供的数据元素是：

a)会话(session)数量（或者登陆数量）number of sessions。为了满足政府机构和专业组织的报告的需要，应该提供会话数量或者登陆数量。在没有国界的网络环境中，会话数量的统计是一个粗糙的指标。

b)提问数(number of queries)，即经过分类的提问数量。一次检索是一次独立的知识查询。典型地，一次检索被记录为向服务器提交的一个检索表单，之后的浏览行为或者选定一个单独条目的行为没有表现为额外的检索，除非通过提交二次检索。立即进行重复的检索、双击或者其他用户的无意识行为都不应计入其内。

c)菜单的选择数(number of menu selections)，如果数据的显示需要通过使用菜单来进行浏览，则应该提供这个指标（如一个电子期刊网站提供的基于音序和主体的菜单选择）。

d)全文的数量（打开的、下载的或者提供给用户的全文，这些全文都是由服务器控制的而不是由浏览器控制的）：

期刊文章－按照期刊名称列出刊名和issn；

电子书——按照书名列出书名和isbn；

参考资料——按照改资源的内容单元（如字典的定义、百科全书的文章、传记等）；

非文本型资源——按照自愿的文献类型（如图像、音频、视频等）。

上述的每个数据元素应该按照每个特定的数据库提供商、按照每一组机构的IP地址或其他特别的元素（如账号），以及机构名称、协会名称和时间跨度（每月或者每年）分组描述，供应商还应该提供每天、每小时的统计数据，并且还应该可以动态地集成几个月或者某一段时间的数据，而不用限制是当年数据还是由供应商限定的时间段。

3.2　E-Metrics推荐的统计指标

为了了解图书馆数字资源的使用情况，确定数字资源的花费是否合理，MRL的E-Metrics项目推荐的指标如下：

(1)用户可检索的电子资源。包括：R1电子全文期刊种数、R2电子参考资源种数、R3电子书的种数。

(2)对网络资源和服务的使用情况。包括：U1电子参考事务的数量、U2登录电子数据库的数量（会话session数）、U3电子数据库的提问和检索数量、U4电子数据库的请求条数、U5对图书馆网站和书目的远程访问次数。

(3)网络资源和相关设备的花费。包括：C1全文电子期刊的成本、C2电子参考资源的成本、C3电子书的成本、C4图书馆对书目设备、网络环境等相关设备的花费、C5对书目设备、网络环境等相关设备的外部花费。

(4)图书馆数字化活动。包括：D1数字馆藏的大小、D2数字馆藏的使用、D3数字馆藏建设和管理的成本。

E-Metrics的统计指标，既考虑了数字资源和数字化服务的访问量，还考虑了数字资源及其支持成本，便于从成本／效益的角度进行分析。

3.3　我国图书馆常用的数字资源访问统计指标

对于图书馆数字资源访问统计的指标，在我们常见的统计分忻工作中，统计指标围绕什么被使用？谁在使用？如何使用？什么时候使用？为什么使用？哪些资料经常被下载？哪些资料被检索最频繁？资料检索来自哪些单位？哪个单位使用量最多等问题，通常采用数字资源提供商提供的访问统计数据与对图书馆网站及自建数字资源的访问统计相结合的方式，除了资源提供商提供的数据外，往往采用网站访问流量、访问者的IP、网站点击次数、数字资源的点击次数、下载的篇数等指标。

与国外相比，我国图书馆的数字资源访问统计指标设定相对比较粗略，没有统一的、针对各种类型数字资源的一致的标准，而且统计指标往往仅仅反映了访问情况，未能与数字资源的购买和管理成本挂钩进行成本／效益分析。

4　图书馆数字资源访问统计存在的问题

4.1　资料库不在馆内，正确及时的统计数据不易取得

随着各个图书馆在数字资源建设方面的积累和发展，图书馆数字资源的来源多样，既有通过远程镜像或者资源提供商服务器访问的数据，也有在本地镜像的数据，还有图书馆自建的数字资源。尤其对于资料库不在馆内的情况，需要厂商配合协助，但是最大的问题在于没有办法从厂商那里得到充分的数据，或是厂商提供的数据不标准，或是提供的资料不是图书馆想要的，而且由于统计数据是由资源提供商提供，其客观性和真实性的保障机制弱。这样，正确及时的统计数据不易取得。

4.2　缺乏标准的统计指标

由于资源来源多样，统计指标不规范，不同的系统提供的统计报告五花八门，没有统一指标。统计指标定义混乱、不明确，例如“search”在大多数系统内被定义为用户发送检索式的次数，但有些数据库却用“query”来表示同样含义的指标，而CSA数据库则同时使用了“search”和“query”，二者的含义和区别并不明确。没有一致、标准、科学的统计指标体系，对用户访问统计的分析及其对图书馆决策的支持可信度就会降低。同时对于数字资源的访问统计指标还应该结合每种数字资源的类型、考虑数字资源服务的研究人员规模等参数。

4.3　图书馆数字资源的后评估，应该结合多种评估途径展开

图书馆数字资源的访问统计，是图书馆数字资源后评估的方法之一，目前的图书馆数字资源的访问统计存在统计指标不一致、不标准的问题，而且网站访问统计不能确定是否与使用者的目的相符，无法完全反映使用者真正的使用状况，因而，图书馆数字资源的后评估可以结合数字资源的访问统计、用户使用调查、用户访谈等方式完成。

4.4　用户隐私的问题

图书馆数字资源访问统计的数据主要来自web server的log files，目前法律上并无相关条文规定log file资料的处理，但由于其中包含使用者的IP地址，应该与图书馆的流通记录一样，加以保密。不论图书馆决定如何分析log file的数据，对于收集何种数据、谁能判读数据以及如何使用数据等，都应有详细的规定和说明，以免一时大意触犯子个人隐私权。未经个人用户同意，不能收集用户的个人信息，也不能将所收集的统计信息用于分析和识别用户个人信息。如果为提供特定服务必须采集用户的个人信息，必须向用户告知他的权利、个人信息用途及其保护方式，只有在用户知情同意的情况下才能基于该服务明确相关的个人信息。并且必须对合法采集的用户个人信息必须进行安全保管，未经用户同意不得公开，不得将个人信息转给第三方，而且服务中止后，必须立即删除。

【参考文献】

1　arl.org/stats/newmeas/emetrics/index.html

2　projectcounter.org/index.html

3　equinox.dcu.ie/

4　niso.org/emetrics/index.cfm

5，9　ICOLC.GUIDELINES FOR STATISTICAL MEASURES OF USAGE OF WEB-BASED INFORMATION RESOURCES ＜library.yale.edu/consortia/2001 webstats.htm

6　libraryjoumal.com/article/CA411564?display=Features News & industry

7　张川，肖金升，周振，胡运发.具有访问时间完整性的web日志方法.计算机应用与软件.2004(2):105-107

8　梁玉环，李村合，索红光.基于JSP的网站访问统计系统的设计与实现.计算机应用研究.2004(4):166-167

10　詹丽萍.E-Metrics在数位图书馆使用评估的应用.p105.lib.nctu.edu.tw/2001conference/pdf/1-1.pdf

11　张晓林、宛玲、徐引篪、宋小冬、王欣.国家科学效字图书馆数字资源采购的技术要求.中国图书馆学报.2004(7)，14-19

12　索传军.论述字馆藏的质量评价.中国图书馆学报，2004，30(152):43-46

第9篇：好的日志文章范文

厂商提供给用户的软件补丁的形式多为编译后的库函数，所以安装软件补丁实际上就是把这些库函数拷贝到相应目录，并在需要时进行联接操作。软件公司一般在一段时间后会把针对某一版本的所有补丁进行整理：合并融合，解决冲突，进行整体测试，并使文件拷贝和联接操作自动执行，得到一个软件补丁“包”。不同的公司使用不同的名称，现在一般计算机用户都熟悉的Windows Service Pack就是这样的补丁包。Oracle公司给出的补丁包的名称是Patch Set，安装Patch Set后的版本称Patch Set Release(PSR)。

Oracle公司对处于标准技术支持的产品不定期地提供PSR，例如在完成本文时，版本10.2的最新PSR是10.2.0.2；版本10.1的最新PSR是10.1.0.5;版本9.2的最新（也极可能是最终）PSR是9.2.0.8。

在安装最新PSR后新发现的Bug，其相应补丁当然会收录到下一个PSR中。PSR是累积型的，即下一个PSR中会包括当前PSR中所有补丁和新发现Bug的补丁。同时存在几个PSR时，只需安装最新版本一次就可以了。但是由于PSR的发行有一定间隔，如果这些Bug对用户有比较大的影响，那么Oracle公司也会向用户公开和提供这些补丁，这些补丁被称为个别补丁（Interim Patch，one-off patch 或 Patch Set Exception）。而对于最终补丁发行版而言，由于不再有下一个PSR，所以当发现影响系统的新Bug时，个别补丁成为惟一选择。

此外，Oracle公司还定期安全补丁，称之为CPU（Critical Patch Updates）。安全补丁用来修复软件的易受攻击性(vulnerability)或通常说的安全漏洞。这类问题本来不属于软件错误，在正常使用中不会出现任何问题。但是别有用心的人可以通过运行非常精巧设计的代码，绕过数据库系统的安全管理机制，达到非授权存取的目的。

另外还存在一类补丁：诊断用补丁（diagnostic patch）。顾名思义，这类补丁不是用来解决问题的，而是用来寻找问题的原因的。这类补丁只在Oracle技术支持部门要求安装时，才需要安装。在得到需要的诊断信息后，应立即卸载这一补丁。

利弊及时机选择

负责管理支撑大型应用系统的数据库的DBA会容易理解安装软件补丁的代价。安装PSR需要停止数据库服务，关闭数据库，对于许多应用系统安排这样的停机时间本身就是一件比较困难的事情。事实上，更为严重的是由于安装PSR可能“引入”新的Bug，反而影响应用系统的正常运行。软件补丁本来是修正Bug，怎么会带来新的Bug？虽然有些让人匪夷所思，但很不幸这是现实存在的。

对于每一个PSR，其中都包括了少则几百多则上千个严重Bug的修正。即便是如此，在PSR后，很快就又会在安装PSR后的数据库中发现一些新问题。其中一部分Bug是以前就一直存在的只是以前没有发现，而现在偶尔被发现，或者是由于PSR修正了某一错误从而将其“激活”或容易发现。但是确实有一些Bug是由这一PSR造成的，Oracle技术支持部门称其为倒退（Regression）。对于每一PSR，在metalink中有两个重要的与之有关的文档，一个是“List of fixes added in XXXX”，是这一PSR修复的Bug的清单，是一本“功德簿”；另一个是“Known issues and alerts affecting XXXX”，是安装PSR后发现的问题，可以称其为“悔过簿”。由于大型软件的复杂性，Bug几乎是不可避免的。重要的是能够及时提供信息，DBA可以结合自己系统的情况做出正确的判断。读者不必因为知道还存在着Bug，就对Oracle数据库产品失去信心。PSR修复的上千个Bug中绝大多数是在一些很少见的环境中，或者是若干个组件的复杂组合使用的情形中发生的。

如果系统在运行中出现过某种问题，由Oracle技术支持部门或第三方的专家确认原因是PSR中的某一Bug，这样就必须尽早安装;如果系统一直运行正常，并且在PSR已发现的问题中涉及的组件或功能（如Logical Standby, JVM，RAC等）在系统中并不使用，此时可以选择安装也可以选择不安装。

另一个需要考虑的因素是安装补丁的时机。上述这些考虑的一个重要前提是系统已经投入运行，担心“倒退”的Bug影响系统。如果系统还处在开发和测试阶段，不需要有任何犹豫，安装最新的PSR，并在此基础上测试应用系统是否工作正常。如果发现异常，要及时请Oracle技术支持部门确认是否新Bug，如果是请其提供个别补丁。目的就是在一个尽可能完善稳定的数据库平台上测试应用系统。我们可以把这种安装补丁的策略概括为“补丁补新不补旧”。

以上都是针对PSR的安装，对于个别补丁，由于补丁修复的Bug单一，容易判断是否需要安装。需要注意的是，如果在当前PSR之上安装了若干个个别补丁，那么在下一个PSR后，在安装下一个PSR之前，需要卸载所有个别补丁。为便于管理，现在Oracle技术支持部门要求必须使用工具opatch安装管理个别工具，而尽量避免手动拷贝文件等操作。

最后是安全补丁安装的判断。虽然安全漏洞这个词看上去让人觉得非常严重，但是还要冷静综合分析这些漏洞在系统中的危害程度。事实上，不安装安全补丁的危险性可能远远小于始终不渝地使用scott/tiger这样人人都知道的用户名和口令的“标准缺省”做法。

安装PSR

使用oui工具安装PSR时只需要用鼠标做几个选择就可以进入自动执行的阶段，操作过程本身非常简单。但是如果要求必须一次安装成功；要求必须在凌晨2点到4点这个有限的停机时间段完成操作；要求安装过程不出差错，以后出现问题时能够完全排除此次操作失误的可能性，那么就需要在启动oui之前做一些准备工作。

1. 收集信息

有关PSR的信息中，一个最重要的文档就是软件补丁说明，这个文件相当于技术手册中的安装指南和发行说明。文件本身包含在下载的软件补丁文件之中，文件名是patchnote.htm或README.html。需要注意的一个问题是在软件补丁文件之中找到的这一Patch Set Notes可能不是最新版，可以根据文件内的提示信息在metalink中检索最新版。

另外两个重要文件就是前面已经提及的“功德簿”和“悔过簿”，相对于“功德簿”更应该仔细阅读“悔过簿”中的每一项内容。另外，在Patch Set Notes的已知问题（Known Issues）一节内列出了安装PSR后出现的一些问题。

除去这三个主要文件外，还应在metalink中检索，寻找是否还有其他涉及这一PSR的技术文章，寻找其他用户在安装这一PSR时或安装后遇到问题时所发的救助的帖子，前车之鉴更应重视。

2. 做出判断

在认真阅读收集到的文章之后，根据自己系统的实际情况，做出是立即安装PSR，或是等待下一PSR的决定。如果是暂缓安装，则要记录原因，以便以后跟踪Bug的修复进程。

3. 制订实施计划

在决定安装PSR后，需要制订一个实施计划。在计划中不仅要包括正常的操作步骤，更要考虑在出现意外时的应急处理（如果安装PSR失败，则在正常应用开始时间之前，要恢复系统到安装之前的状态）。如果可能，在对正式系统开始实施之前，应在测试系统中进行演练和应用处理的测试，保证在安装PSR后不会影响应用系统的运行。

安装PSR的计划大致有以下几个部分：停止数据库服务关闭数据库；备份DBMS软件和数据库以备恢复之用；安装PSR软件；更新数据库数据字典升级PSR版本；正常启动数据库开始数据库服务。

看似简单的关闭数据库的操作，在系统构成复杂时也会变得不容易。另外，如果夜间作业时间不允许在完成数据库完全备份之后再安装PSR，则安装PSR的日期应该选择在例行的数据库完全备份的下一个晚上，只备份重做日志。

在安装PSR之前备份DBMS软件的目的是，由于安装PSR会对许多程序和库函数进行更新，如果安装PSR中途失败（虽然可能性非常小），有可能造成DBMS软件出现不一致。另外一种可能的情形是，在安装PSR，更新数据字典后，测试应用系统时，出现了某种异常，原因不明，最终决定放弃PSR。如果操作之前没有备份，则此时只有重新安装软件一种选择（PSR不同于完整软件安装，在oui中无法单独卸载PSR软件）。

对文件、目录和文件系统的备份，最简单的方式可以使用cp、tar、dump等命令完成。如果希望缩短文件拷贝时间，可以考虑分区备份的方法。分区备份常用的命令是dd。但是，分区拷贝比文件拷贝速度快的前提是良好的分区设计：Oracle软件单独占一个大小适中（如4GB）的分区，这样扇区拷贝才会体现优势，这也就是为什么在安装软件时，Oracle建议单独使用一个分区安装软件的原因之一。

在制定实施计划时，应认真阅读Patch Set Notes中有关操作前准备工作一节。在这节内会介绍对于一些特殊系统构成，如果你的系统属于文档中提到的构成，一定要首先阅读文内提示的相关技术文章，找到正确的安装步骤。

使用oui, PSR软件安装完成后，一定不要忘记更新数据字典这一步骤。如果在这一ORACLE_HOME下生成了多个数据库，则每个数据库都必须更新数据字典。

4. 实施操作

制订一个详细的计划后，实施操作就可以“照本宣科”，是一个简单的体力劳动。要认识到“忙中出错”的概率远比“急中生智”大得多，操作时尽量减少失误的可能性。例如，需要执行的复杂命令，尽可能从一个文件拷贝到终端执行，而不要现场输入。另外，在实施过程中， 要记录各个阶段实际的执行时间，以供以后制订类似计划时参考。

5. 检查操作结果并记录备案

执行一个操作，操作是否成功，一定要进行检查，不能简单认为没有出错信息就是成功。要知道验证的方法。除去极个别极费时间的验证（分区备份的内容是否可以成功恢复系统，必须恢复分区，启动数据库，测试应用系统后才能确认），其余操作都应进行验证。所有屏幕输出信息和日志文件都应保留，作为安装报告的附件提交给上级或客户。

在屏幕输出或日志文件中出现异常/错误信息时，应即时分析，决定马上采取的措施。出现严重错误时，可能需要重新执行某一SQL程序，或者重新安装PSR。所以在制订实施计划时应在时间上留出异常情况处理的时间。

下面给出一个在Linux平台上安装10.1的PSR的实例，给从未安装PSR的读者有一个感性认识。

操作系统是RHEL AS4.0 Update3，Oracle的当前版本是10.1.2。在metalink中检索，找到10.1版的最新PSR10.1.0.5。下载压缩文件。在压缩文件中找到Patch Set Notes，该文档的完成日期是2006年1月。而按照文档内的提示在metalink中检索得到的此文档的最新版本完成日期是2006年4月。使用文件比较工具进行比较，两个版本没有实质性差别，只有语句措词的修改，但是养成总是检索最新文档的习惯有益无害。

根据Patch Set Notes中的说明，有一些特殊系统构成需要额外的步骤，本例中由于全部没有涉及到，所以可以按标准步骤执行。

另外，检查“Known issues and alerts affecting 10.1.0.5”文档后，发现10.1.0.5引入的影响最大的一个Bug是执行SELECT MAX()在某些特定条件下结果不正确。而这一Bug可以通过设置事件（event）关闭FIRST ROW优化而避免。最后的结论是这一BUG不会对本系统有影响，可以安装PSR10.1.0.5。

1. 检查数据库表空间和初始化参数是否需要调整。

System表空间要求有一定未使用空间:初始化参数SHARED_POOL_SIZE 和 JAVA_POOL_SIZE不能低于最小值150MB。

2. 关闭数据库，停止listener和agent等进程。

3. 解压缩下载文件至某一目录，执行oui。

在压缩文件中附带的oui的版本要比已经安装的版本高，应总是使用新版本的oui。在oui窗口中，要求选择本次安装的软件的位置，正确的位置是解压缩目录下的子目录Disk1/stage/， 选中products.xml即可开始文件拷贝。

要注意窗口中会出现本次安装的日志文件的文件路径和文件名。文件的位置是在Oracle的inventory所在目录的子目录logs中，文件名由前缀InstallActions和安装日期时间组成，如: InstallActions2006-08-30-11-32-48AM.log。

正常结束后，退出oui。打开日志文件，检索是否出现error 或“ORA-”的错误信息。本次安装产生的日志文件内，没有任何此类的信息，表明PSR软件安装成功。如果此时再次启动oui，点击“已安装软件”，则可以看到在原有的10.1.0.2软件之下，新出现了10.1.0.5一项，这也证实PSR软件安装成功。

4.更新数据库数据字典

更新数据字典时，必须以特殊的升级方式打开数据库。

$ sqlplus /nolog

SQL> CONNECT / AS SYSDBA

SQL> STARTUP UPGRADE

SQL> SPOOL patch.log

SQL> @?/rdbms/admin/catpatch.sql

执行结束后，关闭重定向：

SQL> SPOOL OFF

打开文件patch.log检查是否有错误“ORA-”。（这一文件在启动sqlplus时的当前目录中，当然也可以在“SPOOL patch.log”语句中显式指定文件路径。）如果出现错误要分析原因，在解决问题后，需要再次执行catpatch.sql程序。

更新数据字典时，由于对某些PL/SQL包删除后又重新生成，造成相关PL/SQL包的状态为异常（invalid）。在以后调用这些包时，检测到其状态为非法，会自动执行编译命令，使状态成为正常（valid）。虽然不会出错，但会造成个别处理第一次执行时变慢。显然，与其留到应用系统运行时再一个个编译，不如之前集中一次重编译所有异常包。

SQL> SHUTDOWN

SQL> STARTUP

SQL> @?/rdbms/admin/utlrp.sql

最后，根据Known Issues中的指示，完成与本系统有关的操作。例如，修改Pro*C的配置文件。这里执行一个修改文件存取权限的“后操作”，以便非同组用户和程序可以存取客户端工具和库函数。

$ cd $ORACLE_HOME/install

$ ./ changePerm.sh

个别补丁管理工具opatch

如前所述，在一个PSR后发现的新BUG，只能把其补丁收入到下一个PSR中。如果对数据库有实质性影响，则这一补丁以个别补丁的形式向用户提供。个别补丁是与某一个特定的PSR关联，是安装在这一PSR之上的。另外，如同其名字表明的，个别补丁只是单一Bug的补丁，不会包含其他个别补丁，即不是累积型的。

在9.2版之前，安装个别补丁的操作完全是手工的。这种手工方式的缺点不仅在于加重DBA的负担，容易造成操作失误，更严重的是无法对已安装的个别补丁进行管理。

为解决手工方式的缺陷，从9.2版开始，Oracle公司设计实现了个别补丁安装管理工具opatch。opatch使用一个称为inventory的系统数据结构（严格说是与oui共享inventory）,集中管理所有已安装的个别补丁；个别补丁的安装和卸载都使用opatch命令完成，冲突检测也由opatch在安装时自动完成；提供列表命令可以很方便得到已安装个别补丁的信息。

10g(10.1和10.2)版本中，opatch作为一个标准工具，在软件安装时自动安装。（安装在$ORACLE_HOME/OPatch下。）而对于9.2版，需要从metalink下载opatch。无论数据库是哪一个版本，系统中是否已经安装opatch，在使用之前，应从metalink下载最新版本的opatch。很遗憾，由于系统实现的问题，10.2使用的opatch与之前版本（10.1和9.2）使用的opatch不兼容，不能混用，这一点必须注意。

opatch是使用perl编写的脚本程序（其中也使用JAVA API）。编程使用的perl版本是5.6版，虽然在5.6之前的版本中也可运行，但应尽可能安装5.6或以上的版本的perl。对于DBA来说一个好消息是，如果安装9.2版软件时保留了HTTP服务器，则在$ORACLE_HOME/Apache下会自动安装perl。（10g会自动安装配置perl和opatch。）

opatch命令格式为：

opatch < command > [< command_options >] [ -h[elp] ]

命令有：apply（安装个别补丁）、rollback（卸载个别补丁）、lsinventory（对inventory进行列表）、query（显示某一个别补丁的详细信息）、version（显示opatch版本信息）。在opatch目录下，有用户使用指南文件（Users_Guide.txt），其中有详细的命令格式和使用示例，读者可以参考。Opatch执行操作时，除在屏幕输出结果外，还生成日志文件。日志文件的路径和文件名格式如下：

$ORACLE_HOME/.patch_storage/< patch_id >/< action >-< patch_id >_< mm-dd-yyyy_hh-mi-ss >.log

其中“patch_id”是Oracle技术支持部门为个别补丁分配的编号。

4. 个别补丁安装实例

沿用安装PSR实例中的环境。在安装PSR10.1.0.5后，检索metalink，发现若干在其之上的个别补丁。选择其中之一安装。

个别补丁Patch 4518443修复BUG4518443，这一BUG的主要问题是TNS LISTENER在注册ONS（Oracle Notification Services）的同时如果创建子进程，那么LISTENER会挂起（HANGUP）。

安装时，首先，从metalink下载补丁的压缩文件p4518443_10105_LINUX.zip。将此文件解压缩至某一目录中。解压缩后，这一补丁的所有文件都在子目录4518443下，目录名就是个别补丁的补丁号，opatch依据目录名获得信息，所以一定不要重命名子目录。

然后，在终端窗口中，执行cd命令移动到4518443子目录中，执行以下命令：

$ $ORACLE_HOME/OPatch/opatch apply

对inventory列表，确认安装操作：

$ $ORACLE_HOME/OPatch/opatch lsinventory

执行卸载命令时，也必须使4518443子目录成为当前目录。其中，Rollback命令需要两个参数：-id给出个别补丁号；-ph 给出个别补丁解压缩后的路径。

$ $ORACLE_HOME/OPatch/opatch rollback -id 4518443 -ph /…/4518443

随后再对inventory列表，则会看到这一个别补丁已经被移去。

4. 使用opatch显示已安装的版本信息

不需要启动数据库，执行加选项的对inventory的列表命令，可以得到已安装的软件的各个组件的详细版本信息。

$ $ORACLE_HOME/OPatch/opatch lsinventory -detail

安全补丁CPU

一个CPU内包含了对多个安全漏洞的修复，并且也包括相应必需的非安全漏洞的补丁。CPU是累积型的，只要安装最新的CPU即可，其中包括之前的所有CPU的内容。事实上，在CPU之前的安全漏洞修改除去个别例外也被包括在CPU中。Oracle公司只对处于标准技术支持和延长支持期间的产品提供CPU更新，对处于维持支持范围的产品不提供新的CPU。（对于9.2以前的版本，只对处于ECS和EMS期间的版本提供CPU更新。）一般对当前补丁发行版及前一个版本提供CPU，但也有只限于当前补丁发行版的例外情形。也就是说，一般需要先安装最新PSR后才可能安装CPU。由于是累积型的定期，所以对于某一平台的某一版本，如果两次CPU期间没有发现新的安全漏洞，则新的CPU与前一版本完全相同。

在以下网址中可以找到CPU的信息，但是很遗憾，只有技术支持签约用户才可以从metalink下载补丁文件。

省略/technology/deploy/security/alerts.htm

Oracle公司制定的CPU的日期大约在一月、四月、七月和十月的最接近15的星期二。

对于每一个CPU，附有相应的说明文档（Critical Patch Update Note），其中介绍安装过程和注意事项，在安装之前应认真阅读此文档。同样也存在文档“Oracle Critical Patch Update MM YYYY Known Issues for Oracle Database”，其中列出了说明文档中没有给出的新信息。

在安装时，首先下载压缩文件p5225797_10105_LINUX.zip，解压缩到与其它个别补丁相同的目录下。检查其发行说明时，发现要求opatch版本比现已安装版本要高，下载安装指定版本opatch。进入子目录5225797（这是此安全补丁的补丁号），执行apply命令。

$ $ORACLE_HOME/OPatch/opatch apply