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

前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的好的日志文章主題范文，僅供參考，歡迎閱讀并收藏。

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

關(guān)鍵詞：分布式計算；日志分析；Hadoop；集群；vmware

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2013）34-7647-04

1 概述

日志文件是由系統(tǒng)或者應(yīng)用程序產(chǎn)生的，用于記錄系統(tǒng)和應(yīng)用程序的操作事件如各種服務(wù)的啟動、運行、關(guān)閉等信息。通過對日志文件的分析可以獲得很多有價值的數(shù)據(jù)也能實現(xiàn)對系統(tǒng)安全、性能等方面的監(jiān)控。Web日志[1]是由Web服務(wù)器產(chǎn)生的，隨著社交網(wǎng)絡(luò)的興起，Web2.0時代的到來，網(wǎng)站的用戶訪問量的成級數(shù)增長，產(chǎn)生的日志文件大幅增多。傳統(tǒng)的日志文件分析方式已經(jīng)無法滿足大數(shù)據(jù)量日志分析的需求。該文將以Web日志文件為例，利用Hadoop集群構(gòu)建一個分布式計算平臺為大數(shù)據(jù)日志文件的分析提供一個可行的解決方案，以提高了日志分析的效率，為進一步的大數(shù)據(jù)分析的提供參考。

現(xiàn)今日志文件分析方案是對大的日志文件先進行分割，然后對分割后的日志文件進行分析，分析方法采用文本分析及模式匹配等，最常見的是采用awk、python、perl。這種分析方式面對大數(shù)據(jù)的日志文件分析效率低下，耗時長。王瀟博提出了基于挖掘算法的日志分析方式，并設(shè)計了TAT系統(tǒng)[1]。對于Web分析除了對Web日志本身進行分析外還可以主動收集訪問信息，然后將信息存于關(guān)系型數(shù)據(jù)庫中。這種方式最常見的是Google Analytics、百度統(tǒng)計等。這種方式將會影響網(wǎng)站的性能，延長網(wǎng)站的加載時間。其次如果直接采用第三方的統(tǒng)計，還將會泄露網(wǎng)站的信息。當訪問量高時，基于關(guān)系型數(shù)據(jù)庫分析的方式將會受到數(shù)據(jù)庫性能的制約。錢秀檳，劉國偉，李錦川等人提出了基于模式匹配算法的Web應(yīng)用日志分析系統(tǒng)[2]。

2 Hadoop集群系統(tǒng)概述

日志文件記錄了日常操作的原始數(shù)據(jù)，數(shù)據(jù)極具價值。隨著時間的推移日志文件越來越大，分析難度也隨著增大。本系統(tǒng)的設(shè)計就是為了解決文本日志的分析，系統(tǒng)針對Web日志。本系統(tǒng)基于搭建好的Hadoop分布式架構(gòu)，將數(shù)據(jù)先存入到HDFS文件系統(tǒng)中，運行mapreduce程序?qū)?a href="http://www.baojiexiang.com/haowen/18744.html" target="_blank">日志文件進行過濾分析，最后將數(shù)據(jù)輸出到指定文件中。充分發(fā)揮了Hadoop分布式存儲和分布式計算的優(yōu)勢。 解決了海量數(shù)據(jù)日志文件的分析的難題，采用基于分布式結(jié)構(gòu)的日志分析系統(tǒng)，提高了分析效率。

目標日志是由Apache服務(wù)器產(chǎn)生的訪問日志。Apache采用默認安裝方式時，訪問日志access.log，存在于Apache安裝目錄的logs子目錄下。訪問日志access_log記錄了所有對Web服務(wù)器的訪問活動。下面是訪問日志中一個典型的記錄：

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

這行內(nèi)容由7項構(gòu)成1） 遠程主機的IP地址。2）瀏覽者的標識（空白用一個“-”占位符替代）3）記錄瀏覽者進行身份驗證時提供的名字（空白用一個“-”占位符替代）。 4）請求的時間。5） 請求類型（METHOD RESOURCE PROTOCOL）。6）狀態(tài)代碼（請求是否成功及原因）。7）發(fā)送給客戶端的總字節(jié)數(shù)。

3 系統(tǒng)的設(shè)計與實現(xiàn)

3.1 系統(tǒng)的基本目標

利用分布式的架構(gòu)對日志文件進行分析，對日志文件進行過濾，按時間對日志數(shù)據(jù)進行分析。分析主要從頁面pv、ip、請求狀態(tài)、流量等方面出發(fā)。每月PV總量、PV量最多的一天、每月每個url的pv、每月獨立IP、每天的流量、月總流量、每天的訪問狀態(tài)統(tǒng)計、每月的訪問狀態(tài)統(tǒng)計、每天的請求方式統(tǒng)計、每月的請求方式統(tǒng)計等等。

3.2 Hadoop部署

圖1介紹了Hadoop部署的基本結(jié)構(gòu)，MapReduce 模型中的 Master 的主控作業(yè)節(jié)點稱為 JobTracker，此框架下面的所有作業(yè)（Job）都是由 JobTracker 進行管理的，它是唯一存在的。TaskTracker，負責(zé)每一個具體任務(wù)的執(zhí)行。任務(wù)（Task）是具體執(zhí)行的基本單元，每一個作業(yè)被拆分成很多的任務(wù)，被分配到合適任務(wù)節(jié)點上去執(zhí)行，任務(wù)節(jié)點一邊執(zhí)行分配過來的任務(wù)，一邊向 JobTracker 匯報執(zhí)行任務(wù)的狀態(tài)，以此來幫助JobTracker 了解作業(yè)執(zhí)行的整體情況，向空閑節(jié)點分配新的任務(wù)等操作。

3.3 日志數(shù)據(jù)的HDFS存儲

圖2展示了HDFS的工作原理。首先client通過調(diào)用DistributedFileSystem的create方法來創(chuàng)建文件。DistributedFileSystem通過RPC調(diào)用NameNode在文件系統(tǒng)的名字空間里創(chuàng)建一個文件。DistributedFileSystem返回FSDataOutputStream給client。FSDataOutputStream封裝了一個DFSOutputStream來處理與datanodes和namenode之間的通訊。當client寫一個block數(shù)據(jù)的時候，DFSOutputStream把數(shù)據(jù)分成很多packet。FSDataOutputStream詢問namenode挑選存儲這個block以及它的副本的datanode列表。這個datanode列表組成了一個管道，在上圖管道由2個datanode組成（備份參數(shù)是2），這2個datanode的選擇有一定的副本放置策略。4、FSDataOutputStream把packet寫進管道的第一個datanode，然后管道把packet轉(zhuǎn)發(fā)給第二個datanode。

當管道里所有datanode都返回寫入成功，這個packet才算寫成功，發(fā)送應(yīng)答給FSDataOutputStream。開始下一個packet。如果某個datanode寫失敗了，首先管道關(guān)閉。運行正常的datanode上正在寫的block會有一個新ID（需要和namenode通信）。這樣失敗的datanode上的那個不完整的block在上報心跳的時候會被刪掉。失敗的datanode會被移出管道。block中剩余的packet繼續(xù)寫入管道的其他兩個datanode。同時namenode會標記這個block的副本個數(shù)少于指定值，然后block的副本會稍后在另一個datanode創(chuàng)建。

有些時候多個datanode會失敗。只要dfs.replication.min（缺省是1）個datanode成功了，整個寫入過程就算成功。缺少的副本會異步的恢復(fù)。當client完成了寫所有block的數(shù)據(jù)后，調(diào)用FSDataOutputStream的close方法關(guān)閉文件。最后FSDataOutputStream通知namenode寫文件結(jié)束。

3.4 日志分析過程

日志分析系統(tǒng)由客戶端和Hadoop服務(wù)器組成，客戶端調(diào)用Hadoop接口將日志文件存入HDFS并調(diào)用任務(wù)，這里的任務(wù)是按順序執(zhí)行的，在前一個任務(wù)執(zhí)行成功后才執(zhí)行下一個任務(wù)，每個任務(wù)都完成多件事，每個任務(wù)都調(diào)用map和reduce過程，最后一個任務(wù)將數(shù)據(jù)輸出到HDFS的文本文件，也可以將文件輸出到數(shù)據(jù)庫中，最后根據(jù)統(tǒng)計數(shù)據(jù)進行展示。如圖3。

4 結(jié)果分析

系統(tǒng)硬件環(huán)境的CPU為2.00GHz，內(nèi)存為4G可用內(nèi)存為3G，實驗時為三臺機器分配的內(nèi)存情況master為256M，slave1為336M，slave2為384M。軟件環(huán)境操作系統(tǒng)為rhel-server-6.0，JRE的版本：java-1.6.0。Hadoop版本：Hadoop-1.0.1。HDFS集群概況如圖4。

通過分析執(zhí)行過程的輸出，第一個任務(wù)map過程耗時2分31秒，reduce耗時9秒，整個任務(wù)耗時2分48秒。Map過程讀取的記錄為311965條。reduce讀取字節(jié)數(shù)為45431334，輸出字節(jié)數(shù)為3938231。任務(wù)二，map26秒，reduce，16秒，累計47秒。任務(wù)三，map28秒，reduce，18秒，累計耗時51秒。所有任務(wù)總耗時：4分16秒。從數(shù)據(jù)可以看出，使用vmware虛擬機進行構(gòu)建性能收到主機性能的影響，受限較多。但是，Hadoop架構(gòu)能有效對任務(wù)進行調(diào)度和分配，達到預(yù)期效果。

圖5可以看出任務(wù)輸出了三個目錄test-out1、test-out2、test-out3。每個任務(wù)輸出一個，前兩個目錄存放的是臨時的文件，test-ou3目錄存放的是結(jié)果文件。這些輸出的文件是根據(jù)日期來的，分為月匯總數(shù)據(jù)和每天的數(shù)據(jù)，這些文件存放了最終的結(jié)果。

圖6和圖7截取了六月份的部分數(shù)據(jù)。此文件存放了六月每個訪問頁面的pv總量，以及六月訪問數(shù)據(jù)的匯總。六月的pv總和為139，get方式為127，post方式為12，http訪問狀態(tài)200次數(shù)為125，訪問狀態(tài)301次數(shù)為2，訪問狀態(tài)403次數(shù)為4，訪問狀態(tài)404次數(shù)為8，pv量最多的一天為2011年6月30日121次，最多的頁面為/favicon.ico訪問次數(shù)為7次，月流量為46698。也可以查看六月具體每一天的數(shù)據(jù)。圖8是單日統(tǒng)計數(shù)據(jù)，這一天的pv量為5，get方式請求為4，post方式請求次數(shù)為1，請求的狀態(tài)碼都為200即請求成功，總流量為1684字節(jié)。

5 小結(jié)

分布式計算作為一項日趨成熟的技術(shù)，逐漸展露了其優(yōu)勢。Hadoop框架很好的將分布式文件系統(tǒng)HDFS和MapReduce編程模型進行了融合。使用Hadoop可以很便捷的搭建了一個分布式集群環(huán)境，它對分布式任務(wù)控制調(diào)度有很好的性能和伸縮性。以此實例為基礎(chǔ)可以進一步進行拓展，對大數(shù)據(jù)任務(wù)進行更深入和詳細的分析和挖掘，為各個領(lǐng)域的大數(shù)據(jù)處理提供參考。

參考文獻：

[1] 王瀟博.基于挖掘算法的日志分析系統(tǒng)設(shè)計與實現(xiàn)[D].北京：北京交通大學(xué)，2008：26-33.

[2] 錢秀檳，劉國偉，李錦川，等.Web 應(yīng)用日志分析系統(tǒng)分析與設(shè)計[J].計算機安全，2011，2011（6）.

[3] 肖立英，李建華，譚立球.Web日志挖掘技術(shù)的研究與應(yīng)用[J].計算機工程，2002，28（7）：276-277.

[4] 張彥超，劉云，張海峰，等.基于在線社交網(wǎng)絡(luò)的信息傳播模型[J].物理學(xué)報，2011，60（5）：60-66.

[5] 胡光民，周亮，柯立新.基于Hadoop的網(wǎng)絡(luò)日志分析系統(tǒng)研究[J].電腦知識與技術(shù)，2010， 6（22）：65-69.

[6] 辛大欣，劉飛.Hadoop集群性能優(yōu)化技術(shù)研究[J].電腦知識與技術(shù)，2011，7（22）.

[7] 韓亞.關(guān)系傳播：WEB2.0時代的傳播偏向[D].武漢：華中科技大學(xué)，2008：1-2.

[8] Mark Lutz.Python學(xué)習(xí)手冊[M].北京：機械工業(yè)出版社，2009：659-665.

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

關(guān)鍵詞：日志取證；關(guān)聯(lián)分析；特征關(guān)聯(lián)；序列關(guān)聯(lián)

0　引言

隨著信息技術(shù)的發(fā)展，計算機犯罪案件不斷涌現(xiàn)，計算機取證技術(shù)成為人們研究的熱點。計算機取證要解決的關(guān)鍵問題是如何從計算機犯罪現(xiàn)場挖掘犯罪方法、犯罪動機、犯罪工具，確定犯罪責(zé)任。日志文件是計算機和網(wǎng)絡(luò)系統(tǒng)用于記錄發(fā)生在計算機本地系統(tǒng)或者網(wǎng)絡(luò)中的事件的重要審計憑據(jù)，是計算機犯罪線索勘查取證的重要對象，是計算機犯罪中非常重要的線索和證據(jù)來源。分析日志數(shù)據(jù)能及時發(fā)現(xiàn)入侵者入侵行為，是提取犯罪證據(jù)的重要手段。然而，進行日志分析存在如下困難：日志文件本身并不安全，一旦攻擊者獲得root權(quán)限，就可以輕而易舉地修改、破壞或刪除系統(tǒng)所保存的日志記錄，從而使得日志分析失去意義；日志文件的格式與種類具有多樣性，需要統(tǒng)一格式或跨平臺操作；目前還沒有形成比較完善的日志分析策略。本文將從這幾個方面入手，提出了基于日志分析處理策略的取證模型。

1　日志關(guān)聯(lián)分析取證模型

日志關(guān)聯(lián)分析是指將所有系統(tǒng)中的日志以統(tǒng)一格式綜合在一起進行考慮。在網(wǎng)絡(luò)安全領(lǐng)域中，日志關(guān)聯(lián)分析是指對網(wǎng)絡(luò)全局的日志安全事件數(shù)據(jù)進行自動、連續(xù)分析，根據(jù)用戶定義的、可配置的規(guī)則來識別網(wǎng)絡(luò)威脅和復(fù)雜的攻擊模式，從而確定事件真實性、進行事件分級并對事件進行有效響應(yīng)。日志關(guān)聯(lián)分析可以用來提高安全操作的可靠性、效率以及可視化程度，并為安全管理和應(yīng)急響應(yīng)提供技術(shù)手段。

關(guān)聯(lián)分析需要采集各系統(tǒng)中的原始數(shù)據(jù)，將采集來的數(shù)據(jù)進行集中統(tǒng)一管理，根據(jù)有關(guān)知識進行分析后得到相應(yīng)的結(jié)果。一個典型的日志關(guān)聯(lián)分析系統(tǒng)應(yīng)包括如下部件：采集，數(shù)據(jù)庫，日志管理，知識庫，關(guān)聯(lián)分析，證據(jù)提交及證據(jù)庫。其關(guān)聯(lián)取證模型如圖1所示。日志采集負責(zé)從不同節(jié)點收集取證日志信息，日志管理模塊對日志信息進行安全存儲，關(guān)聯(lián)分析模塊對取證日志信息進行事件特征關(guān)聯(lián)、事件時間關(guān)聯(lián)和時間空間關(guān)聯(lián)，由日志更新方法和日志格式描述規(guī)則生成日志知識庫引擎，日志存儲服務(wù)器中的日志文件由知識庫引擎驅(qū)動生成日志知識數(shù)據(jù)庫，經(jīng)日志關(guān)聯(lián)分析方法處理得到分析結(jié)果存入證據(jù)庫并打印取證分析報表，并將分析結(jié)果反饋到各分布節(jié)點。

2　日志取證關(guān)鍵部件

2．1　日志收集

日志收集是安裝在目標機器或網(wǎng)絡(luò)的軟件或硬件，它們根據(jù)取證策略收集有關(guān)被取證目標的日志詳細情況。日志數(shù)據(jù)源可分為基于主機的日志數(shù)據(jù)源、基于網(wǎng)絡(luò)的日志數(shù)據(jù)源、基于網(wǎng)絡(luò)安全設(shè)備和軟件的日志數(shù)據(jù)源。日志文件的分布是比較分散的，日志稽查取證往往從網(wǎng)絡(luò)傳輸信源、信道、信宿的角度出發(fā)進行研究，其中信源是指數(shù)據(jù)傳輸?shù)钠瘘c，信道是數(shù)據(jù)傳輸經(jīng)過的中間途徑，信宿是數(shù)據(jù)傳輸?shù)哪康牡?。常見的信源日志有PC上的各種客戶端軟件的日志，信道日志有網(wǎng)絡(luò)節(jié)點的路由器日志、隔離設(shè)備如防火墻、IDS等設(shè)備的日志，信宿日志有各種網(wǎng)絡(luò)服務(wù)器日志，如Web服務(wù)器日志E-Mail服務(wù)器日、Ftp服務(wù)器日志等。

在可利用的數(shù)據(jù)源中，各級各類日志包含豐富的證據(jù)信息，由于關(guān)聯(lián)分析需要將多個安全設(shè)備上的報警信息集中到一處進行分析，因此需要在各安全設(shè)備上設(shè)置，由將安全設(shè)備上的信息傳輸?shù)街行臄?shù)據(jù)庫。傳輸?shù)臄?shù)據(jù)有可能是完整的日志數(shù)據(jù)，也可能是在本地搜集信息并經(jīng)簡單分析的結(jié)果。

2．2　日志管理

產(chǎn)生系統(tǒng)日志的軟件通常為應(yīng)用系統(tǒng)而不是操作系統(tǒng)，所產(chǎn)生的日志記錄容易遭到惡意的破壞或修改。系統(tǒng)日志通常存儲在系統(tǒng)未經(jīng)保護的目錄中，并以文本方式存儲，未經(jīng)加密和校驗處理，沒有防止惡意篡改的有效保護機制。因此，日志文件并不一定是可靠的，入侵者可能會篡改日志文件，從而不能被視為有效的證據(jù)。由于日志是直接反映入侵者痕跡的，在計算機取證中扮演著重要的角色，入侵者獲取系統(tǒng)權(quán)限竊取機密信息或破壞重要數(shù)據(jù)后往往會修改或刪除與其相關(guān)的日志信息，甚至根據(jù)系統(tǒng)的漏洞偽造日志以迷惑系統(tǒng)管理員的審計。

有效的日志數(shù)據(jù)分析是建立在日志文件本身安全的基礎(chǔ)上的，因此建立一個安全的日志文件管理體制是必要的。圖2為日志管理模塊。各分布節(jié)點的原始日志文件經(jīng)壓縮、加密和MD5簽名后，通過VPN被分別傳輸給專用日志服務(wù)器和第三方公認服務(wù)器，服務(wù)器利用收到的MAC完成對取證日志信息完整性檢驗，并將通過完整性驗證的具有取證價值的日志信息存入相應(yīng)的遠程日志庫和公證日志庫?？紤]到日志文件本身的安全，虛框內(nèi)部分用兩塊網(wǎng)卡進行物理隔離。

2．3　日志數(shù)據(jù)關(guān)聯(lián)分析策略

系統(tǒng)日志是對系統(tǒng)的運行狀況按時間順序所作的簡單記錄，僅反映本系統(tǒng)的某些特定事件的操作情況，并不完全反映用戶的全部活動情況。用戶的網(wǎng)絡(luò)活動會在很多的系統(tǒng)日志中留下痕跡，如防火墻日志、IDS日志、操作系統(tǒng)日志等，這些不同的日志存在的某種聯(lián)系反映了該用戶的活動情況。只有將多個系統(tǒng)的日志結(jié)合起來分析，才能準確反映用戶的活動情況。

為了能夠為關(guān)聯(lián)分析建立一致的分析方法，可使用IDMEF格式對犯罪入侵事件關(guān)聯(lián)進行建模。在XML文檔中，一種稱為文檔類型定義的格式被用來描述IDMEF數(shù)據(jù)。當然，關(guān)聯(lián)功能并不直接處理XML格式表示的事件，而是針對一系列預(yù)先準備好的日志數(shù)據(jù)，一般來說這些數(shù)據(jù)存儲在日志數(shù)據(jù)庫中。

日志關(guān)聯(lián)分析模塊如圖3所示。日志關(guān)聯(lián)分析可以細分為以下三個步聚：

(1)數(shù)據(jù)聚合

將數(shù)據(jù)庫中來自多個設(shè)備的不同數(shù)據(jù)集中的數(shù)據(jù)歸整于一個數(shù)據(jù)集中，這樣能在任意時間觀察到所有設(shè)備的事件。通過刪除重復(fù)數(shù)據(jù)、歸類相似數(shù)據(jù)等方式來壓縮數(shù)據(jù)量，可以將數(shù)據(jù)保持在一個關(guān)聯(lián)引擎可以處理的范圍內(nèi)。

(2)事件特征關(guān)聯(lián)

從多個日志源采集過來的數(shù)據(jù)，經(jīng)過聚合和規(guī)范化等操作后，已經(jīng)可用來進行關(guān)聯(lián)分析。在計算機取證中，我們挖掘電子證據(jù)數(shù)據(jù)項之間存在的關(guān)聯(lián)，并在關(guān)聯(lián)中查找、發(fā)現(xiàn)并分析計算機犯罪行為在不同位置、各個目標、行為意圖方面的一些聯(lián)系和規(guī)律，提取犯罪行為之間的關(guān)聯(lián)特征(特征可能是經(jīng)過預(yù)處理的統(tǒng)計特征)，挖掘不同犯罪形式的特征、同一事件的不同證據(jù)間的聯(lián)系，為進一步偵察分析和破案提供線索。

基本的數(shù)據(jù)挖掘算法并不考慮專業(yè)領(lǐng)域的知識，結(jié)果會產(chǎn)生一些對實際應(yīng)用無用的規(guī)則，并且算法的效率不能滿足要求。Apriori算法在日志關(guān)聯(lián)取證中有兩個致命的弱點：第一，多次掃描日志數(shù)據(jù)庫極大地加重了I/O負載，因為每次k循環(huán)的侯選集Ck中的每個元素都必須掃描日志數(shù)據(jù)庫一次來驗證其是否 加入Lk。如一個頻繁大項集包含10個項，就至少需要掃描事務(wù)數(shù)據(jù)庫10遍。第二，由Lk-1、產(chǎn)生k-侯選集Ck是指數(shù)增長的，如104的L－頻繁項集就可能產(chǎn)生接近107個元素的2一侯選集，如此大的候選集對取證時間和主存空間都是一種挑戰(zhàn)，達不到取證的實時性要求。

針對上述兩個問題，作者對算法改進如下：對事件主次屬性進行約束，對支持度和置信度閥值設(shè)置進行修改。經(jīng)過這樣的處理之后，可以有效縮短證據(jù)的分析提取時間。

第一，對事件主次屬性的約束。日志記錄中各個屬性的重要性不同，有的屬性對描述數(shù)據(jù)起著關(guān)鍵作用，有的屬性只提供輔助信息。比如在描述網(wǎng)絡(luò)連接的記錄中，每一條記錄表示一個連接，一個網(wǎng)絡(luò)連接可以被一個五元組惟一地標識，即。網(wǎng)絡(luò)連接的關(guān)鍵屬性可以定義為五元組集合，日志記錄主要涉及主體、對象和操作行為，可以用三元組來惟一地表示，Telnet記錄的Shell命令的關(guān)鍵屬性可以用二元組來表示。那么我們就可以用關(guān)鍵屬性作為衡量關(guān)聯(lián)規(guī)則r是否有趣的標準，即I(r)=f(IA(r)，s(r)，c(r))，當模式r含有主屬性，則IA=I，否則IA=0。通過關(guān)鍵屬性和參考屬性的約束，減少“無趣”規(guī)則的產(chǎn)生，即規(guī)定，當算法產(chǎn)生一條新的規(guī)則時，其中必須至少包括一個關(guān)鍵屬性或者參考屬性。

第二，修改支持度和置信度閥值設(shè)置。一種思想是將支持度修改為相對支持度。所謂相對支持度是針對某一個變量而言的。如果定義si是變量Ai的相對支持度，并且變量值對Ai=Vij在整個記錄集中一共出現(xiàn)了Nij次，那么如果包含Ai=Vij的規(guī)則覆蓋實例的個數(shù)超過Si*Nij個，那么我們認為這條規(guī)則滿足支持度約束。這種方法應(yīng)用在計算機取證分析中，需要有一定的先驗知識，能夠?qū)γ總€變量Ai設(shè)定出合理的相對支持度閥值。另一種思想借鑒了在文獻[1]中提出的一種在多層次概念上挖掘關(guān)聯(lián)規(guī)則的算法，即對同一層次上不同頻繁度屬性進行多級挖掘，其主要思路是：先設(shè)置一定的支持度和置信度閥值，對出現(xiàn)頻率高的屬性值進行挖掘，得到相關(guān)的模式；然后不斷降低支持度和置信度閥值挖掘出現(xiàn)頻率低的屬性相關(guān)的模式。在降低閥值設(shè)置的挖掘過程中，我們需要對那些“舊”的屬性值的參與加以限制，避免高頻率屬性值相關(guān)模式的大量產(chǎn)生，淹沒低頻率屬性值模式。這里我們作這樣的限制：候選項目集必須包括至少一個“新”的屬性值；每次循環(huán)計算挖掘得到的模式必須具有“新”的屬性值。整個過程在閥值降到指定的最低值時終止，這個最低值可以是所有關(guān)鍵屬性值中出現(xiàn)頻率最低的屬性值的閥值。

(3)事件序列關(guān)聯(lián)

入侵行為往往沒有明顯的字符串匹配特征，其中任何單獨的一條報文或者命令都看似正常，但一系列按時間順序排列的報文或者命令就構(gòu)成了一次攻擊，而且這種攻擊序列在一次攻擊中只出現(xiàn)一次。序列模式挖掘比關(guān)聯(lián)規(guī)則挖掘粒度更大。以某種序列攻擊的多個樣本作為訓(xùn)練源，可以挖掘出在一個樣本中只出現(xiàn)一次，而在多個樣本中頻繁出現(xiàn)的攻擊行為的特征序列。

考慮到網(wǎng)絡(luò)事件在時間和空間上的相關(guān)性，可在網(wǎng)絡(luò)連接記錄中加入時間的統(tǒng)計屬性，生成序列規(guī)則。如：端口掃描攻擊中的TCP SYN掃描，不是進行一次完整的TCP連接，而是只發(fā)送一個SYN數(shù)據(jù)包，如收到SYN/ACK表示商品處于偵聽狀態(tài)，如收到RST表示端口沒有處于偵聽狀態(tài)。如果先收到SYN，回應(yīng)SYN/ACK后，未收到ACK應(yīng)答，查看歷史發(fā)現(xiàn)短時間內(nèi)還有來自相同地址、相同類型的數(shù)據(jù)包，就有理由認為對方正在進行端口掃描攻擊?？诹畋┝粢簿哂忻黠@的時序特征。比如說使用某一個用戶名自A地址登錄，出現(xiàn)多次登錄失敗，比較歷史記錄發(fā)現(xiàn)從B地址登錄的同一用戶，極少出現(xiàn)登錄失敗情況。則可以初步判定從地址A發(fā)來的登錄信息在進行口令探測。

通過對這種基于時間和空間的事件序列的分析，可以得到一些計算機犯罪的意圖信息，進而可以發(fā)現(xiàn)已經(jīng)發(fā)生的，或者可能發(fā)生的計算機犯罪行為和企圖。

2．4　提交證據(jù)

關(guān)聯(lián)分析的目標是綜合分析不同安全設(shè)備和應(yīng)用系統(tǒng)中的日志數(shù)據(jù)，為取證提供及時、相關(guān)并且準確的關(guān)聯(lián)數(shù)據(jù)。這些關(guān)聯(lián)數(shù)據(jù)將存入相應(yīng)證據(jù)庫，并以特定格式的報告形式提交。

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

關(guān)鍵詞：EXT4；日志；句柄；i節(jié)點

中圖分類號：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文件系統(tǒng)是日志文件系統(tǒng)，100%兼容EXT3文件系統(tǒng)，與EXT3文件系統(tǒng)相比的主要區(qū)別是它能快速更新文件存儲。計算機開始從磁盤上讀取或?qū)懭霐?shù)據(jù)都必須保證文件系統(tǒng)中文件與目錄的一致性，所有日志文件中的數(shù)據(jù)均以數(shù)據(jù)塊的形式存放在存儲設(shè)備中,當磁盤分區(qū)時文件系統(tǒng)即被創(chuàng)建,按照文件形式、目錄形式支持存儲數(shù)據(jù)，組織數(shù)據(jù)的使用。EXT4提供并使用了一個通用日志層 (jbd) [1]，該層既可在文件系統(tǒng)中使用，還能夠應(yīng)用到其它設(shè)備中，對NVRAM設(shè)備，EXT4就能支持。當由于軟件或硬件錯誤導(dǎo)致文件系統(tǒng)崩潰時， EXT4使用與e2fsck同樣代碼來修復(fù)崩潰的文件系統(tǒng),因此在出現(xiàn)數(shù)據(jù)崩潰時，EXT4具有和EXT3同樣的防止數(shù)據(jù)丟失的優(yōu)點[2]。但是,上述這些優(yōu)點不是EXT4獨有的,但只有EXT4才盡數(shù)具備,這正是EXT4的優(yōu)勢。

1 EXT4文件系統(tǒng)的重要數(shù)據(jù)結(jié)構(gòu)

以下的數(shù)據(jù)結(jié)構(gòu)都來自2.6.28內(nèi)核。

1.1 超級塊super_block

/include/linux/EXT4_fs.h

struct EXT4_super_block {

/*00*/ __le32 s_inodes_count; /* 節(jié)點數(shù)目 */

__le32 s_blocks_count; /* 文件塊數(shù) */

__le32 s_r_blocks_count; /* 保留未用的文件塊數(shù) */

__le32 s_free_blocks_count; /* 可用的文件塊數(shù) */

/*10*/ __le32 s_free_inodes_count; /* 可用的節(jié)點數(shù) */

__le32 s_first_data_block; /* 第一個數(shù)據(jù)塊的索引 */

__le32 s_log_block_size; /* 數(shù)據(jù)塊大小 */

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

/*20*/ __le32 s_blocks_per_group; /* 每一組文件塊的數(shù)目 */

__le32 s_frags_per_group; /* 每一組碎片數(shù)目 */

__le32 s_inodes_per_group; /* # 每一組節(jié)點數(shù)目 */

__le32 s_mtime; /* 最近被安裝到內(nèi)存的時間 */

…………

/*150*/ __le32s_blocks_count_hi;/* 文件塊數(shù)的高32位 */

__le32s_r_blocks_count_hi;/*保留未用的文件塊數(shù)高32位*/

__le32s_free_blocks_count_hi;} /* 可用文件塊數(shù)高32位 */

合適的特定設(shè)備和不適合的特定設(shè)備的不同是在，如果在不合適的特定設(shè)備中有一位設(shè)備是內(nèi)核無法識別的，內(nèi)核將會拒絕啟動文件系統(tǒng)。在EXT4中，e2fsck的要求更加嚴格，如果他既不能在合適的特定設(shè)備中，也不能在不合適的特定設(shè)備中識別出一個設(shè)備 ，他一定會終止程序并且不會將它所不能識別的設(shè)備模塊化。

與日志相關(guān)的數(shù)據(jù)結(jié)構(gòu)，只有在EXT4文件系統(tǒng)中才會起作用，同樣在EXT3文件系統(tǒng)中也有定義，但是在EXT4文件系統(tǒng)中配合日志文件數(shù)據(jù)結(jié)構(gòu)才能起到日志文件的功能。

1.2 組描述符 Group Descriptor

組描述符合超級塊一樣，記錄的信息與整個文件系統(tǒng)相關(guān)。當某一個組的超級塊或inode受損時，這些信息可以用于恢復(fù)文件系統(tǒng)。因此，為了更好的維護文件系統(tǒng)，每個塊組中都保存關(guān)于文件系統(tǒng)的備份信息。

struct EXT4_group_desc

{__le32 bg_block_bitmap; /* 文件塊位圖所在的塊的索引*/

__le32 bg_inode_bitmap; /* 存放文件節(jié)點位圖的塊的索引*/

__le32 bg_inode_table; /* 文件節(jié)點表在外存中的第一個塊的索引*/

__le16 bg_free_blocks_count; /* 可用的文件塊數(shù) */

__le16 bg_free_inodes_count; /* 可用的節(jié)點數(shù) */

__le16 bg_used_dirs_count; /* 使用中的目錄數(shù) */

__u16 bg_flag;/*用于32位地址對齊*/

__u32 bg_reserved[3];

__le32bg_block_bitmap_hi; /*文件塊位圖所在的塊的索引的高32位*/

__le32bg_inode_bitmap_hi; /*存放文件節(jié)點位圖的塊的索引高32位*/

__le32bg_inode_table_hi;};/*文件節(jié)點表在外存中的第一個塊的索引高32位*/

1.3i節(jié)點數(shù)據(jù)結(jié)構(gòu)

struct EXT4_inode {

__le16 i_mode; /* 文件模式，表示文件類型以及存取權(quán)限 */

__le16 i_uid; /* 所屬用戶的id的低16位 */

__le32 i_size; /* 節(jié)點字節(jié)大小 */

__le32 i_atime; /* 節(jié)點存取時間 */

__le32 i_ctime; /* 節(jié)點創(chuàng)建時間 */

__le32 i_mtime; /* 節(jié)點修改時間 */

__le32 i_dtime; /* 節(jié)點時間 */

__le16 i_gid; /* 組標志的低16位 */

__le16 i_links_count; /* 連接數(shù)目 */

__le32 i_blocks; /* I節(jié)點文件塊數(shù) */

__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];/* 文件塊索引數(shù)組，數(shù)組大小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節(jié)點用戶id高位 */

__le16 l_i_gid_high; /* I節(jié)點組號高位 */

__le32 l_i_reserved2;

} linux2;//1級間接指針數(shù)據(jù)結(jié)構(gòu)

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; //直接指向物理塊的節(jié)點的數(shù)據(jù)結(jié)構(gòu)的補充

struct {

__le8 m_i_frag; /* 碎片號 */

__le8 m_i_fsize; /* 碎片大小 */

__le16 m_pad1;

__le32 m_i_reserved2[2];

} masix2;//2級間接指針數(shù)據(jù)結(jié)構(gòu)

} osd2; /* OS dependent 2 */

__le16i_EXTra_isize;

__le16i_pad1;

__le32i_ctime_EXTra;/* 節(jié)點擴展的創(chuàng)建時間(nsec

__le32i_mtime_EXTra;/* 擴展的修改時間(nsec

__le32i_atime_EXTra;/* 擴展的存儲時間(nsec

__le32i_crtime; /* 文件創(chuàng)建時間*/

__le32i_crtime_EXTra;};/* 擴展文件創(chuàng)建時間 (nsec

上述結(jié)構(gòu)體中有兩個聯(lián)合體，是為了節(jié)省空間考慮，因為i節(jié)點的索引有三種情況前12個直接指向物理塊，第13個是一級間接指針，第14個是二級間接指針，第15個是三級間接指針，將這三種情況都寫在一個聯(lián)合體中，根據(jù)實際的情況選擇節(jié)點號，根據(jù)節(jié)點的類型來選擇用聯(lián)合體中的那個數(shù)據(jù)結(jié)構(gòu)。與EXT3不同的是，在 EXT4 文件系統(tǒng)中，增加了5個項，用于擴充索引節(jié)點，通過這個結(jié)構(gòu)解決了這對于對精度要求很高的程序的要求。

1.4 i節(jié)點的擴展信息的數(shù)據(jù)結(jié)構(gòu)

這個結(jié)構(gòu)體是日志式文件系統(tǒng)所特有的，用來支持完成日志文件的各種操作[3]。也是2.6內(nèi)核與2.4內(nèi)核的不同之處。i節(jié)點文件塊組是包含一系列文件節(jié)點的塊組。包含了節(jié)點的生命期，它通常用于為分配文件塊的決定。我們將文件的數(shù)據(jù)塊放到他的i節(jié)點塊的附近，新的節(jié)點放到它的父目錄節(jié)點的附近。存放i節(jié)點大小的棧不在內(nèi)存中而在外存上。在縮減的過程中，節(jié)點的大小被虛擬文件系統(tǒng)調(diào)用EXT4_truncate函數(shù)而設(shè)置成新的大小，但是文件系統(tǒng)不會將節(jié)點的磁盤大小設(shè)為0，除非這樣的縮減真的執(zhí)行了。目的在于節(jié)點的大小總是表示正在使用的文件的塊數(shù)。當節(jié)點數(shù)據(jù)寫入的時候我們要重新改寫節(jié)點磁盤的大小來代替節(jié)點的大小[4]。只有在縮減的進行時節(jié)程執(zhí)點的大小和節(jié)點所在的磁盤空間的大小才會不一樣，其他情況都應(yīng)該是一致的。只有在執(zhí)行文件塊增長或縮減的時候存放節(jié)點大小的棧才會被改動。

struct EXT4_inode_info {

__le32 i_data[15];

__le32 i_flags; //i節(jié)點標志

#ifdef EXT4_FRAGMENTS

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

__le8 i_frag_no;//碎片數(shù)目

__le8 i_frag_size;//碎片大小

#endif

__le32 i_file_acl;

__le32 i_dir_acl;

__le32 i_dtime;

__le32 i_block_group;//i節(jié)點文件塊組

__le32 i_state; /* EXT3的動態(tài)的狀態(tài)標志 */

__le32 i_nEXT_alloc_block;

/* i_nEXT_alloc_block 是在該文件中最近分配的塊的邏輯號。當然，他沒

有命名，我們用這個來決定相關(guān)的分配請求所分配的文件塊的邏輯號。

/*

__le32 i_nEXT_alloc_goal;

/* i_nEXT_alloc_goal是下一個分配塊號的物理標志。他是與此文件分配的文件塊號最相近的物理塊號。當用戶請求分配一個新的物理塊的時候?qū)⑦@個物理塊分配給用戶*/

struct semaphore truncate_sem;//元數(shù)據(jù)塊，數(shù)據(jù)的修改信息等

struct inode vfs_inode;

/*虛擬文件系統(tǒng)的節(jié)點，通過這個數(shù)據(jù)可以將日志文件系統(tǒng)EXT4和linux文件系統(tǒng)的頂層虛擬文件系統(tǒng)連接起來*/

};

1.5 句柄handle_t數(shù)據(jù)結(jié)構(gòu)

此結(jié)構(gòu)是EXT4文件系統(tǒng)用來實現(xiàn)日志式文件操作的有利的數(shù)據(jù)結(jié)構(gòu)。

struct handle_s

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

int h_buffer_credits;//要被弄臟的緩沖區(qū)的數(shù)目

int h_ref;//句柄中的參照數(shù)

int h_err;//出錯數(shù)

struct list_head h_jcb;// 磁盤操作的頭節(jié)點

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

unsigned int h_jdata: 1; /* 日志數(shù)據(jù) */

unsigned int h_aborted: 1; /* 句柄中致命的錯誤 */

};

transaction_t 類型是日志系統(tǒng)的一個內(nèi)容。它記錄下了數(shù)據(jù)在各種狀態(tài)下的改變情況。

各種狀態(tài)為：

* RUNNING: 正在進行新的修改

* LOCKED: 修改在進行但是句柄不接受這樣的改變

* RUNDOWN: 修改在整理中但是還沒有完成對緩沖區(qū)的修改。

* FLUSH: 所有的修改完成了但是我們還沒有寫到磁盤上。

* COMMIT: 所有的數(shù)據(jù)都在磁盤上，寫操作執(zhí)行

* FINISHED: 完成保持準備接受下一次修改

2 EXT4的文件操作

2.1 EXT的文件操作的數(shù)據(jù)結(jié)構(gòu)

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,

};

這個結(jié)構(gòu)體說明了EXT4文件系統(tǒng)的read操作是由do_sync_read函數(shù)來實現(xiàn)的，write操作是由do_sync_write函數(shù)來實現(xiàn)的，以此類推。只要我們找到相關(guān)的函數(shù)就能分析EXT4文件系統(tǒng)是怎么實現(xiàn)讀寫操作的。

2.2 EXT4的寫操作

以下分析寫操作的過程，因為日志式的文件的寫操作和其他的文件系統(tǒng)有很大的不同所以以寫操作為例：

圖1是寫操作執(zhí)行時各個函數(shù)嵌套的順序圖。

① file->f_op->write即調(diào)用EXT4文件系統(tǒng)中的write操作，在operation結(jié)構(gòu)的解釋中指出write操作用do_sync_write操作完成。

② filp->f_op->aio_write即調(diào)用EXT4文件系統(tǒng)中的aio_write操作，在operation結(jié)構(gòu)的解釋中指出aio_write操作用EXT4_file_write操作完成。

LINUX中寫操作是通過sys_write系統(tǒng)調(diào)用來實現(xiàn)的，在sys_write函數(shù)中完成對文件file 的讀入，判斷正確后調(diào)用了vfs_write函數(shù)進一步判斷文件的模式是否為寫是否與其他寫操作沖突，如果判斷正確后調(diào)用file->f_op->write，這個調(diào)用其實是去調(diào)用EXT3文件系統(tǒng)中的write操作（即do_sync_write）再調(diào)用aio_write（即EXT4_file_write）來完成讀寫制定大小的文件內(nèi)容到緩沖區(qū)中包括對日志的寫。

EXT4_file_write函數(shù)的分析如圖2。

3 結(jié)束語

本文討論的對象是Linux操作系統(tǒng)中EXT4內(nèi)核程序，介紹了EXT4的主要數(shù)據(jù)結(jié)構(gòu)，并通過分析寫操作來解釋日志的工作方式。日志文件系統(tǒng)提高了文件系統(tǒng)的效率，但是也增加了系統(tǒng)的開銷。2.6.28內(nèi)核中的EXT4文件系統(tǒng)比2.4內(nèi)核做了較多的改動，如前面介紹的節(jié)點的擴展信息，和Htree結(jié)構(gòu)的修正（文中沒有介紹），NTFS文件系統(tǒng)的修正等。總體來說EXT4文件系統(tǒng)是比較完善的日志文件系統(tǒng)。

參考文獻：

[1] 李善平,陳文智.邊學(xué)邊干LINUX內(nèi)核指導(dǎo)[M].浙江：浙江大學(xué)出版社,2002.

[2] 涂健,孫輝.Linux2.6(內(nèi)核下)EXT3文件系統(tǒng)的數(shù)據(jù)結(jié)構(gòu)及性能分析[J].南昌水專學(xué)報,2004(6):8-10.

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

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

關(guān)鍵詞：AIX；SAP系統(tǒng)；Oracle數(shù)據(jù)庫；同構(gòu)；數(shù)據(jù)遷移

中圖分類號：TP315 文獻標識碼：A 文章編號：1007-9599 （2012） 15-0000-02

1 系統(tǒng)環(huán)境描述

目標系統(tǒng)T49已經(jīng)搭建完畢，使用現(xiàn)有的T49環(huán)境來完成PRD的數(shù)據(jù)遷移。

源系統(tǒng)環(huán)境（生產(chǎn)系統(tǒng)）

OS：AIX 5.3

DB：ORACLE 9.2.0.3

SAPSID：PRD

DBSID：PRD

目標系統(tǒng)環(huán)境（測試系統(tǒng)）

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數(shù)據(jù)庫控制文件

使用以下命令生成PRD數(shù)據(jù)庫控制文件

sqlplus/nolog

connect/as sysdba

alter database backup controlfile to trace resetlogs

生成的文件名及路徑為：

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

2.2 創(chuàng)建NFS

將T49系統(tǒng)的/oracle/T49使用NFS到PRD系統(tǒng)，NFS文件系統(tǒng)命名為：rmtt49

2.3 分別停止源系統(tǒng)及目標系統(tǒng)的SAP服務(wù)，并確認SAP和ORACLE進程已停止

2.4 在目標系統(tǒng)T49上所作的準備工作（很重要：請注意是目標系統(tǒng)T49，切勿搞錯?。?/p>

（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拷貝數(shù)據(jù)文件日志文件到目標主機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文件傳至目標系統(tǒng)

用Text Editor編輯PRD_ora_xxxxx.trc文件（修改結(jié)束后可改名存為db.sql）

把所有PRD改為T49

把REUSE改為SET

把從文件頭到startup nomount（包括startup nomount這一行的內(nèi)容，注意：是第二個startup nomount）的內(nèi)容刪除，把此文件最后一個

“CHARACTER SET WE8DEC

；”

以后的內(nèi)容全部刪除，然后存盤。

4 恢復(fù)工作（在目標主機T49上的操作）

（1）把修改好的db.sql文件放在T49上的/oracle/T49/的目錄下，并改變此文件的權(quán)限

#chmod 777 db.sql

（2）啟動oracle數(shù)據(jù)庫，執(zhí)行db.sql文件

#su–orat49

#sqlplus/nolog

SQL>connect /as sysdba；

SQL>startup nomount；

SQL>@db.sql；

SQL>recover database using backup controlfile；（執(zhí)行這條命令會提示要求輸入一個文件名稱，這個文件是在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數(shù)據(jù)庫能否正常啟動關(guān)閉

SQL>startup

初始化sapr3的密碼和創(chuàng)建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 結(jié)束語

本文以SAP系統(tǒng)同構(gòu)遷移為例，講述系統(tǒng)遷移的一種方法。通過以上方法，能快速地進行ORACLE數(shù)據(jù)遷移；該方案在實踐中得到了驗證，遷移后的測試系統(tǒng)運行效果良好。

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

關(guān)鍵詞：數(shù)據(jù)挖掘;日志分析;聚類挖掘

中圖分類號：TP311.131文獻標識碼：A文章編號：16727800（2011）012016802

作者簡介：李卿(1987-)，女，江西吉安人，安徽理工大學(xué)碩士研究生，研究方向為計算機應(yīng)用技術(shù)。1研究思路

源數(shù)據(jù)為user.txt和log.txt兩個文本文件。user.txt 為用戶分組文件，共1703條記錄，以下是其中一條記錄：

用戶名 用戶組

user253 104

其中，102為研究生組、103為本科生組、104為教職工組、105為辦公用戶組。

log.txt為用戶上網(wǎng)日志文件，是全校所有用戶在2006年11月10日12:28:48至2006年11月11日04:59:58時段內(nèi)的上網(wǎng)記錄，共389348條記錄，以下是其中一條記錄：

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

包含了用戶的IP、用戶名、訪問時間、訪問網(wǎng)站的地址、返回類型、請求的字節(jié)數(shù)等內(nèi)容。

參照數(shù)據(jù)挖掘的過程，按以下幾個步驟展開數(shù)據(jù)挖掘工作：①數(shù)據(jù)準備：對用戶信息文件和日志文件進行數(shù)據(jù)處理，將源數(shù)據(jù)轉(zhuǎn)換成適宜進行數(shù)據(jù)挖掘的數(shù)據(jù)；②數(shù)據(jù)挖掘：對處理后的數(shù)據(jù)采用聚類的方法進行數(shù)據(jù)挖掘；③結(jié)果分析與表示：對前面步驟中獲得的信息進行總結(jié)與評價。

2數(shù)據(jù)準備

此階段對用戶信息文件和日志文件進行數(shù)據(jù)預(yù)處理和數(shù)據(jù)清洗，將源數(shù)據(jù)轉(zhuǎn)換成適宜進行數(shù)據(jù)挖掘的數(shù)據(jù)。數(shù)據(jù)的預(yù)處理是將普通文本形式的源數(shù)據(jù)轉(zhuǎn)換成方便挖掘的數(shù)據(jù)庫文件；數(shù)據(jù)清洗則根據(jù)需求對預(yù)處理后的數(shù)據(jù)進行屬性和記錄的刪減。

2.1數(shù)據(jù)預(yù)處理

利用SQL Sever的“數(shù)據(jù)導(dǎo)入\導(dǎo)出任務(wù)”將user.txt中的數(shù)據(jù)導(dǎo)入新建的數(shù)據(jù)庫dm中，采用默認命名user，將用戶名和用戶組命名為"uno"和"ugroup"，設(shè)置uno為主鍵。采用相同的方法將log.txt轉(zhuǎn)換成log表，各字段名為：ip、uno、non、time、port、get、url、http、type、byte、tcp。

2.2數(shù)據(jù)清洗

(1)去除user表中不合法的數(shù)據(jù)。對user表進行分組，得出研究生組的記錄有299條，本科生組有731條，教職工組有569條，辦公用戶組有89條，4組共1688條，與總記錄數(shù)有出入?？芍渲写嬖诓缓戏〝?shù)據(jù)，使用SQL語句去除。

(2)去除log表中多余的字段。log表中并非所有的字段信息都有用，只需保留用戶的IP、用戶號、訪問時間、訪問地址、返回類型，請求的字節(jié)數(shù)這幾個關(guān)鍵字段。

(3)統(tǒng)計上網(wǎng)用戶信息。提取整個時段內(nèi)上網(wǎng)用戶和用戶組信息，并剔除不合法的記錄，得到一個擁有341條記錄的uno_ugroup表。說明有341人上網(wǎng)，此表作為挖掘模型的一個輸入表。

(4)按小時統(tǒng)計各時段的在線人數(shù)。日志按秒記錄用戶的訪問信息，需篩選出每秒操作的用戶數(shù)，按小時分組統(tǒng)計每個時間段的在線人數(shù)，如圖1所示。

(5) 按用戶分組統(tǒng)計訪問網(wǎng)站的頻率。以用戶訪問網(wǎng)站的頻率為參照衡量用戶上網(wǎng)的時長，盡可能從log表中剔除一些以url以gif、jpg、css、js、swf結(jié)尾的間接訪問記錄，并使用如下命令可得出訪問排名：

SELECT uno,COUNT(uno) AS 訪問頻率 FROM log

GROUP BY uno

ORDER BY COUNT(uno) DESC圖1在線人數(shù)時段分布圖

從排名中可知用戶user1775訪問操作最頻繁，經(jīng)查詢易知該用戶為本科生,上網(wǎng)時段為13:07:19~13:50:46和17:26:57~23:17:36，該同學(xué)整個晚上的時間都在網(wǎng)上。

(6) 按用戶分組統(tǒng)計資源的占用情況。分析帶寬的占用情況本來應(yīng)該以秒為單位分別統(tǒng)計用戶流量，求均值后再排名，但這樣過于復(fù)雜。在這可以換一個思路，按用戶號統(tǒng)計流量，排序靠前流量越高的，占用的帶寬也較高?？墒褂萌缦旅畹玫綆捳加玫呐琶?/p>

SELECT uno,SUM(byte) AS 上網(wǎng)總流量 FROM log

GROUP BY uno

ORDER BY SUM(byte) DESC

排名中可知user1641用戶排名第一訪問量相當大，經(jīng)查詢得知該用戶為教職工，上網(wǎng)時段為12:30:50~01:36:51，連續(xù)7小時在線，視頻下載操作頻繁。

3數(shù)據(jù)挖掘

利用SQL Sever 2005的SSAS組件對上網(wǎng)用戶進行聚類挖掘。將2.3中生成的uno_ugroup表加到其數(shù)據(jù)源中，在挖掘結(jié)構(gòu)中新建聚類挖掘模型，設(shè)置如圖2所示：

圖2聚類挖掘模型設(shè)置

對模型處理完成后，可在挖掘模型查看器的分類剖面圖中，看到具體的參數(shù)情況，如圖3所示：

圖3分類剖面圖

同時可以看到各類別的概率，如圖4所示：

圖4分類特征

4結(jié)果分析與表述

通過數(shù)據(jù)準備和挖掘，可以得出本校網(wǎng)絡(luò)用戶的上網(wǎng)情況如下：

(1)工作日在線人數(shù)不多，人數(shù)分布按教職工、研究生、本科生、辦公用戶降序排序。

(2)上網(wǎng)有兩個高峰時段：13:07:19~13:50:46和17:26:57~23:17:36。午飯時間和晚飯時間的在線人數(shù)較少。

(3)個別用戶上網(wǎng)時間較長，可通過其訪問網(wǎng)站的頻率衡量其在線時長的排名。

(4)個別用戶占用網(wǎng)絡(luò)帶寬較為嚴重，網(wǎng)絡(luò)訪問數(shù)據(jù)量大的原因通常是訪問視頻文件造成的。

網(wǎng)絡(luò)管理員可以根據(jù)以上情況對訪問網(wǎng)絡(luò)的行為為進行相應(yīng)的管理與限制，如對視頻下載操作進行合適的限定，對上網(wǎng)時間較長的用戶加以關(guān)注，提醒同學(xué)合理安排時間等。

5結(jié)束語

本文對校園網(wǎng)日志中的在線人群分布、用戶訪問網(wǎng)站的頻率、訪問量等情況進行了分析，使用了SQL Sever 2005中的聚類挖掘算法進行數(shù)據(jù)挖掘，得到了較為明顯的分析結(jié)果。日志中有一些字段并未利用，日后還可以利用SQL Sever中的其他挖掘算法，對數(shù)據(jù)進行更進一步的清洗和挖掘。參考文獻：

[1]韓家煒,夢小峰,王靜,等.Web挖掘研究[J].計算機研究與發(fā)展,2001(4).

[2]方杰，朱京紅.日志挖掘中的數(shù)據(jù)預(yù)處理[J].計算機技術(shù)與發(fā)展,2010(4).

[3]孫峰.數(shù)據(jù)挖掘在SQL Sever 2005中的應(yīng)用[J].硅谷,2010(5).

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

關(guān)鍵詞：電子商務(wù)；Web挖掘；客戶行為

中圖分類號：F224-39

文獻標識碼：A

文章編號：167Z-3198(2009)08-0237-02

1 電子商務(wù)中客戶的重要性

營銷學(xué)上有個著名的公式；100－1＝0，即一個企業(yè)即使有100個客戶對其感到很滿意，但是只要有一個客戶對持否定態(tài)度，企業(yè)的盛名就可能立即化為0，盡管這個觀點有點夸大其實，但是至少它說明了一個問題，即：客戶滿意的重要性。

市場經(jīng)濟體制下，公司的目標就是為企業(yè)持股者爭取利潤的最大化，而公司的利潤從何而來――客戶。換句話說，為客戶服務(wù)能創(chuàng)造長期的利益，而長期的利益又能夠滿足持股者的目的需求。雖然，使客戶滿意需要花更多的錢，同時也需要更長的周期，但是長周期加上大量的資金意味著企業(yè)更多的利益。所以，客戶對企業(yè)的重要性是越來越突出。即使在電子商務(wù)領(lǐng)域這個遵循市場經(jīng)濟體制的網(wǎng)上交易體系。這一重要性也是同樣符合的。

如今Google、Amazon、Yahoo、MSN等一些Web公司都要求員工運用Web挖掘技術(shù)來了解客戶行為，并根據(jù)挖掘出的信息數(shù)據(jù)及模式設(shè)計更加符合客戶需求的服務(wù)和產(chǎn)品。也就是說利用Web挖掘可以了解客戶行為，其分析的數(shù)據(jù)結(jié)果可提供給企業(yè)參考，做出合適的調(diào)整策略。

2　客戶行為的Web挖掘

2.1　挖掘數(shù)據(jù)來源

在挖掘過程中，關(guān)鍵性步驟是提供合適的挖掘?qū)ο蟆Ｔ陔娮由虅?wù)中，客戶行為挖掘的數(shù)據(jù)源，主要有以下幾種：

(1)服務(wù)器日志文件。

Web服務(wù)器日志文件記錄了客戶每次登錄瀏覽網(wǎng)站的行為信息，包括了IP地址、時間、頁面等，是Web挖掘的主要數(shù)據(jù)源。

(2)Cookies日志文件。

Cookies是服務(wù)器為自動跟蹤網(wǎng)站瀏覽者而在客戶端生成的標志，用于存儲類似于購物手推車狀態(tài)信息或者瀏覽者所訪問的電子商務(wù)網(wǎng)站的頁面信息或交易信息等。

(3)客戶信息。

客戶信息指客戶通過Web頁在屏幕上輸入的、要提交給服務(wù)器的相關(guān)信息。在電子商業(yè)網(wǎng)站須進行信用授權(quán)才能進行交易，因此客戶大量的個人資料會傳到網(wǎng)站上。對這些信息組織序化后，存儲到數(shù)據(jù)倉庫中可作為長期分析客戶消費趨勢的來源。

2.2　挖掘過程

對客戶行為的Web挖掘并不是雜亂無序的，一般其過程可分為三個階段：

(1)數(shù)據(jù)的預(yù)處理；

預(yù)處理主要對用戶訪問日志(包含用戶的訪問日志、引用日志和日志)進行過濾、反蜘蛛化、客戶驗證、會話和路徑補全等處理，形成用戶會話文件。

①過濾：收集完數(shù)據(jù)后，首要的步驟便是過濾出不想要的記錄，為分析做準備。

②反蜘蛛化：所謂蜘蛛，就是搜索引擎對萬維網(wǎng)的掃描建立索引的半自動化程序。蜘蛛的行為與人的行為不同(要比客戶的全面)，在數(shù)據(jù)處理中要把蜘蛛的行為和客戶的行為區(qū)分開來，并過濾掉蜘蛛行為在服務(wù)器上的記錄。

③客戶驗證：在會話之前必須識別客戶，一是識別出同一客戶在一次瀏覽中為建立會話而發(fā)出的頁面請求，另一目的是識別在多次站點瀏覽的同一客戶，使我們能夠分析客戶在數(shù)天，數(shù)月或是數(shù)年中的行為。

④會話；會話指客戶在一次訪問中訪問的所有Web頁面，通過這些可以反映出訪問者對網(wǎng)站什么地方有興趣或關(guān)心。

⑤路徑補全；客戶在瀏覽網(wǎng)時可能出現(xiàn)頁面后退現(xiàn)象，導(dǎo)致路徑損失，所以需要根據(jù)客戶訪問前后頁面進行推理，補全訪問路徑。

(2)模式發(fā)現(xiàn)：

模式發(fā)現(xiàn)是對數(shù)據(jù)預(yù)處理所形成的用戶會話文件，利用數(shù)據(jù)挖掘的一些有效算法，例如統(tǒng)計分析、關(guān)聯(lián)規(guī)則、聚類、分類等。來發(fā)現(xiàn)隱藏的模式、規(guī)則。

①統(tǒng)計分析：統(tǒng)計方法是從電子商務(wù)網(wǎng)站中抽取知識的最常用的方法。可以根據(jù)選擇的特征來分析網(wǎng)頁此特征的點擊次數(shù)，根據(jù)獲得的數(shù)據(jù)結(jié)果來調(diào)整網(wǎng)站。

②關(guān)聯(lián)規(guī)則：根據(jù)關(guān)聯(lián)規(guī)則，可以從客戶訪問網(wǎng)站的行為中找出相關(guān)性。利用這些相關(guān)性，可以改進電子商務(wù)網(wǎng)站的結(jié)構(gòu)，例如哪些產(chǎn)品可以擺在一起或捆綁銷售。

③聚類和分類：聚類規(guī)則是從一組數(shù)據(jù)項中聚集出相似特征的一個聚類，可分為用戶聚類和網(wǎng)頁聚類。而分類規(guī)則是找出描述并區(qū)分數(shù)據(jù)類或概念的模型，并使用模型預(yù)測類標記未知的對象類。

(3)模式分析：

在這個階段，主要是對挖掘出來的模式、規(guī)則進行分析，找出用戶感興趣的模式，并輔助理解。最常見的模式分析方法是采用sQL查詢語句進行分析。另一種分析方法是先將數(shù)據(jù)導(dǎo)入并提供可視化的結(jié)果輸出。

3　Web挖掘的應(yīng)用

網(wǎng)絡(luò)個性化服務(wù)是目前電子商務(wù)商業(yè)運作和發(fā)展的新方向，它根據(jù)用戶興趣、愛好、習(xí)慣，以及各個用戶之間的相關(guān)性等向用戶在線推薦商品，提供瀏覽建議，通過不定期調(diào)整網(wǎng)站的結(jié)構(gòu)方便用戶訪問。動態(tài)地為用戶定制個性化的網(wǎng)站等。

如今，許多商家一直在尋求識別有利可圖的市場分割和追蹤網(wǎng)絡(luò)使用者的行為習(xí)慣，其目的是提醒用戶他們可能感興趣的產(chǎn)品的實用性。這就出現(xiàn)了像亞馬遜網(wǎng)站那樣的一種新模式，根據(jù)某一特殊用戶可能感興趣的問題提出所需信息。對于被特征化的用戶，運用一些客戶分類、挖掘技術(shù)，讓他們了解所感興趣產(chǎn)品的預(yù)報。

網(wǎng)絡(luò)個性化服務(wù)的本質(zhì)就是以客戶為中心提供Web服務(wù)。首先，客戶瀏覽訪問電子商務(wù)網(wǎng)站的資源；其次，系統(tǒng)分析客戶行為特性，創(chuàng)建訪問模型；最后，根據(jù)所獲取的信息知識調(diào)整服務(wù)，系統(tǒng)進行推薦來滿足不同用戶的個性化需求。通過客戶與系統(tǒng)不斷的交互，最終為客戶提供個性化服務(wù)。

4　Web挖掘面臨的問題

Web挖掘給電子商務(wù)帶來新機遇的同時，也帶來潛在的問題――隱私安全問題。網(wǎng)絡(luò)的特點使得我們在網(wǎng)站上留下的信息幾乎都可以被全世界獲得。事實上，對用戶數(shù)據(jù)的采集和挖掘，有些時候利用了用戶的注冊信息和登記信息，這包括客戶姓名、性別、地址、出生年月、電話號碼、購物習(xí)慣、收入、信用卡號碼、電子郵件及經(jīng)常訪問的Web站點地址等私人信息。如果這些信息的利用未得到客戶的允許，則會涉及到隱私權(quán)問題并產(chǎn)生糾紛。

如何對客戶隱私進行保護，我們可以從三個方面著手：第一，立法進行強制性規(guī)范；第二，對涉及隱私的網(wǎng)上數(shù)據(jù)采取技術(shù)防范；第三，行業(yè)自律，不隨意泄露客戶信息，禁止買賣數(shù)據(jù)等。

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

關(guān)鍵詞:校園網(wǎng)絡(luò)安全;安全防御機制;蜜罐;蜜網(wǎng)

中圖分類號:TP393文獻標識碼:A文章編號:1009-3044(2009)33-9234-03

隨著基于計算機網(wǎng)絡(luò)技術(shù)的現(xiàn)代教育手段應(yīng)用的日益廣泛, 各地建設(shè)校園網(wǎng)的熱情空前高漲。校園網(wǎng)的普及對加快信息處理、合理配置教育資源、充分利用優(yōu)質(zhì)教育資源、提高工作效率、減輕勞動強度、實現(xiàn)資源共享都起到了不可估量的作用,信息安全問題也日益突出。 作為從局域網(wǎng)基礎(chǔ)上發(fā)展起來的校園網(wǎng)也面對這樣的安全問題。 因此, 解決網(wǎng)絡(luò)安全問題刻不容緩。網(wǎng)絡(luò)與信息安全技術(shù)的核心問題是對計算機系統(tǒng)和網(wǎng)絡(luò)進行有效地防護。網(wǎng)絡(luò)安全涉及面很廣, 從技術(shù)層面上講主要包括防火墻技術(shù)、入侵檢測技術(shù)、病毒防護技術(shù)、數(shù)據(jù)加密和認證技術(shù)、蜜罐技術(shù)等, 這些安全技術(shù)中, 大多數(shù)技術(shù)都是在攻擊者對網(wǎng)絡(luò)進行攻擊時對系統(tǒng)進行被動的防護。而可以采取主動的方式的蜜罐技術(shù)就是用特有的特征吸引攻擊者, 同時對攻擊者的各種攻擊行為進行分析并找到有效的對付方法。結(jié)合蜜罐構(gòu)建的網(wǎng)絡(luò)安全防御系統(tǒng), 可使網(wǎng)絡(luò)防御者化被動為主動, 更好地研究入侵者的行為和動機, 從而更好地保護校園網(wǎng)絡(luò)。

1 蜜罐的定義及分類

“蜜罐”的思想最早由Clifford Stoll 于1988 年6 月提出,作者在跟蹤黑客的過程中,利用了一些包含虛假信息的文件作為黑客“誘餌”來檢測入侵。明確提出蜜罐是Lance Spitzner 給出的定義:蜜罐是一種安全資源,其價值在于被探測、攻擊或者摧毀。蜜罐是一種預(yù)先配置好的系統(tǒng),系統(tǒng)內(nèi)含有各種偽造而且有價值的文件和信息,用于引誘黑客對系統(tǒng)進行攻擊和入侵。蜜罐系統(tǒng)可以記錄黑客進入系統(tǒng)的一切信息,同時還具有混浠黑客攻擊目標的功能,可以用來保護服務(wù)主機的正常運行。蜜罐系統(tǒng)收集到的信息可以作為跟蹤、研究黑客現(xiàn)有技術(shù)的重要資料,可以用來查找并確定黑客的來源;還可以用來分析黑客攻擊的目標,對可能被攻擊的系統(tǒng)提前做好防護工作。

蜜罐在編寫新的IDS特征庫、發(fā)現(xiàn)系統(tǒng)漏洞、分析分布式拒絕服務(wù)(DDOS)攻擊等方面是很有價值的。蜜罐本身并不直接增強網(wǎng)絡(luò)的安全性,將蜜罐和現(xiàn)有的安全防衛(wèi)手段如入侵檢測系統(tǒng)(IDS)、防火墻(Firewall)、殺毒軟件等結(jié)合使用,可以有效提高系統(tǒng)安全性。

按照蜜罐實現(xiàn)時,允許操作系統(tǒng)與入侵者交互的復(fù)雜程度,蜜罐系統(tǒng)可以劃分為低交互級蜜罐系統(tǒng)、中交互級蜜罐系統(tǒng)和高交互級蜜罐系統(tǒng)。

1) 低交互級蜜罐系統(tǒng):典型的低交互級蜜罐僅提供一些簡單的虛擬服務(wù),例如在特定的端口監(jiān)聽記錄所有進入的數(shù)據(jù)包。這類蜜罐沒有向入侵者提供可以遠程登錄的真實操作系統(tǒng),因此風(fēng)險最低,但是蜜罐所扮演的角色是非常被動的,就象一個單向連接,只有信息從外界流向本機,而沒有回應(yīng)信息發(fā)出,無法捕捉到復(fù)雜協(xié)議下的通訊過程,所能收集到的信息有限。

2) 中交互級蜜罐系統(tǒng):中交互級蜜罐系統(tǒng)也不提供真實的操作系統(tǒng),但是卻為入侵者提供了更多復(fù)雜的誘騙進程,模擬了更多更復(fù)雜的特定服務(wù),使攻擊者誤認為是一個真正的操作系統(tǒng),能夠收集更多數(shù)據(jù)。但同時也增加了蜜罐的風(fēng)險,因此要確保在模擬服務(wù)和漏洞時不產(chǎn)生新的真實漏洞,而給黑客攻擊真實系統(tǒng)的機會。

3) 高交互級蜜罐系統(tǒng):高交互蜜罐提供了真實的操作系統(tǒng)和服務(wù),可以了解黑客運行的全部動作,獲得更多有用信息,但遭受攻擊的可能性大,引入了更高風(fēng)險,結(jié)構(gòu)較復(fù)雜。高交互蜜罐系統(tǒng)部署的代價最高,需要系統(tǒng)管理員的連續(xù)監(jiān)控。不可控制的蜜罐對任何組織來說沒有任何意義甚至可能成為網(wǎng)絡(luò)中最大的安全隱患。

從具體實現(xiàn)的角度,可以分為物理蜜罐和虛擬蜜罐。

1) 物理蜜罐:物理蜜罐通常是一臺或多臺真實的在網(wǎng)絡(luò)上存在的主機,這些主機上運行著真實的操作系統(tǒng),擁有自己的IP 地址,提供真實的網(wǎng)絡(luò)服務(wù)來吸引攻擊。

2) 虛擬蜜罐:虛擬蜜罐通常用的是虛擬的機器、虛擬的操作系統(tǒng),它會響應(yīng)發(fā)送到虛擬蜜罐的網(wǎng)絡(luò)數(shù)據(jù)流,提供模擬的網(wǎng)絡(luò)服務(wù)等。

2 蜜罐的配置模式

1) 誘騙服務(wù)(deception service)

誘騙服務(wù)是指在特定的IP服務(wù)端口幀聽并像應(yīng)用服務(wù)程序那樣對各種網(wǎng)絡(luò)請求進行應(yīng)答的應(yīng)用程序。DTK就是這樣的一個服務(wù)性產(chǎn)品。DTK吸引攻擊者的詭計就是可執(zhí)行性,但是它與攻擊者進行交互的方式是模仿那些具有可攻擊弱點的系統(tǒng)進行的,所以可以產(chǎn)生的應(yīng)答非常有限。在這個過程中對所有的行為進行記錄,同時提供較為合理的應(yīng)答,并給闖入系統(tǒng)的攻擊者帶來系統(tǒng)并不安全的錯覺。例如,當我們將誘騙服務(wù)配置為FTP服務(wù)的模式。當攻擊者連接到TCP/21端口的時候,就會收到一個由蜜罐發(fā)出的FTP的標識。如果攻擊者認為誘騙服務(wù)就是他要攻擊的FTP,他就會采用攻擊FTP服務(wù)的方式進入系統(tǒng)。這樣,系統(tǒng)管理員便可以記錄攻擊的細節(jié)。

2) 弱化系統(tǒng)(weakened system)

只要在外部因特網(wǎng)上有一臺計算機運行沒有打上補丁的微軟Windows或者Red Hat Linux即行。這樣的特點是攻擊者更加容易進入系統(tǒng),系統(tǒng)可以收集有效的攻擊數(shù)據(jù)。因為黑客可能會設(shè)陷阱,以獲取計算機的日志和審查功能,需要運行其他額外記錄系統(tǒng),實現(xiàn)對日志記錄的異地存儲和備份。它的缺點是“高維護低收益”。因為,獲取已知的攻擊行為是毫無意義的。

3) 強化系統(tǒng)(hardened system)

強化系統(tǒng)同弱化系統(tǒng)一樣,提供一個真實的環(huán)境。不過此時的系統(tǒng)已經(jīng)武裝成看似足夠安全的。當攻擊者闖入時,蜜罐就開始收集信息,它能在最短的時間內(nèi)收集最多有效數(shù)據(jù)。用這種蜜罐需要系統(tǒng)管理員具有更高的專業(yè)技術(shù)。如果攻擊者具有更高的技術(shù),那么,他很可能取代管理員對系統(tǒng)的控制,從而對其它系統(tǒng)進行攻擊。

4) 用戶模式服務(wù)器(user mode server)

用戶模式服務(wù)器實際上是一個用戶進程,它運行在主機上,并且模擬成一個真實的服務(wù)器。在真實主機中,每個應(yīng)用程序都當作一個具有獨立IP地址的操作系統(tǒng)和服務(wù)的特定是實例。用戶模式服務(wù)器這樣一個進程就嵌套在主機操作系統(tǒng)的應(yīng)用程序空間中,當INTERNET用戶向用戶模式服務(wù)器的IP地址發(fā)送請求,主機將接受請求并且轉(zhuǎn)發(fā)到用戶模式服務(wù)器上。這種模式的成功與否取決于攻擊者的進入程度和受騙程度。它的優(yōu)點體現(xiàn)在系統(tǒng)管理員對用戶主機有絕對的控制權(quán)。即使蜜罐被攻陷,由于用戶模式服務(wù)器是一個用戶進程,那么Administrator只要關(guān)閉該進程就可以了。另外就是可以將FIREWALL,IDS集中于同一臺服務(wù)器上。當然,其局限性是不適用于所有的操作系統(tǒng)。

3 蜜罐Honeypot 的在校園網(wǎng)中的實現(xiàn)

本人首先研究了宜興技師學(xué)院的網(wǎng)絡(luò)環(huán)境和面臨的安全威脅,分析了校園網(wǎng)的特殊性及校園網(wǎng)的安全需求, 根據(jù)校園網(wǎng)的需求和特點, 再結(jié)合宜興技師學(xué)院網(wǎng)絡(luò)的硬件設(shè)施和學(xué)院的具體情況, 提出了我院的網(wǎng)絡(luò)安全解決方案,構(gòu)建了本院的蜜罐系統(tǒng),取名為:HoneypotMe。我們設(shè)計該蜜罐系統(tǒng)的目的是為了研究和驗證蜜罐在校園網(wǎng)安全領(lǐng)域所起的作用,通過實踐加深對蜜罐思想的理解,并進一步在實際環(huán)境中使用它來加強網(wǎng)絡(luò)的安全性。

我們在校園網(wǎng)中搭建了如下的試驗平臺, HoneypotMe 的系統(tǒng)結(jié)構(gòu)及虛擬網(wǎng)絡(luò)拓撲結(jié)構(gòu)如圖1 所示。HoneypotMe 是由虛擬網(wǎng)絡(luò)、虛擬蜜罐、防火墻、虛擬蜜罐的日志及分析系統(tǒng)、入侵檢測系統(tǒng)及被動探測系統(tǒng)幾部分組成的綜合系統(tǒng)。

這里的虛擬蜜罐系統(tǒng)建立的是一個虛擬的網(wǎng)絡(luò)和主機環(huán)境。它通過模擬操作系統(tǒng)的TCP/IP 棧來建立蜜罐,可模擬各種不同的操作系統(tǒng)及設(shè)備,如Linux,Windows 2000,Windows NT,Cisco Switch等。它采用的方式是使用與Nmap 或Xprobe 相同的指紋(fingerprint)數(shù)據(jù)庫來模擬操作系統(tǒng),以響應(yīng)針對虛擬蜜罐的網(wǎng)絡(luò)請求,這樣可以愚弄像Xprobe 或Nmap 這樣的TCP/IP 棧指紋識別工具。另一方面,這個系統(tǒng)也可以模擬虛擬網(wǎng)絡(luò)拓撲,在模擬的網(wǎng)絡(luò)配置中包含路由器,并且包含路由器的連接特性,比如反應(yīng)時間、包丟失和帶寬等。這樣可以愚弄traceroute 這類工具,使網(wǎng)絡(luò)流量看起來遵循了所模擬的網(wǎng)絡(luò)拓撲。在我們的系統(tǒng)中,不僅通過棧指紋愚弄和吸引攻擊者以探測攻擊,而且還建立了一些模擬的服務(wù),讓它們來與攻擊者進行交互作用。不同的系統(tǒng)平臺上通過腳本模擬著不同的服務(wù),例如:在模擬的Windows 系統(tǒng)上打開NetBIOS端口,在模擬的 Linux 系統(tǒng)中激活mail 和FTP,而模擬的Cisco 路由器有一個標準的Telnet 端口,這樣可使建立起來的網(wǎng)絡(luò)環(huán)境看上去更加真實可信。每個被模擬的計算機系統(tǒng)都有一個IP 地址與之綁定,這些被綁定的地址是一些未被分配網(wǎng)絡(luò)地址。這樣配置起來的系統(tǒng)靈活多變,與真實的生產(chǎn)性系統(tǒng)混合在一起,更增加其誘捕和欺騙作用。圖3.9 虛線框中所示就是為實驗環(huán)境設(shè)計的虛擬蜜罐的網(wǎng)絡(luò)拓撲圖。Honeyd 是一個構(gòu)建虛擬蜜罐的軟件,可以利用它實現(xiàn)我們構(gòu)建虛擬蜜罐的目標。另外,作為一個開放源代碼解決方案,可為開發(fā)利用提供方便,比如,可編寫其它的服務(wù)腳本以擴充系統(tǒng)的功能等。為了防止由于攻擊者對蜜罐系統(tǒng)的破壞,使蜜罐系統(tǒng)癱瘓,可使用防火墻來保護該蜜罐系統(tǒng)。防火墻被配置成允許任何連接進入到幾個虛擬蜜罐中,但是嚴格控制到系統(tǒng)本身的訪問,本系統(tǒng)選用IPTables 來保護宿主OS 的外部IP 地址。收集和分析攻擊者的信息是HoneypotMe 能力的一項重要體現(xiàn)。由于蜜罐沒有生產(chǎn)性的活動,沒有任何正常流量會流向它正在監(jiān)視的幾個IP 地址。這使得分析它捕捉到的信息極其簡單,因此它捕捉到的任何東西很可能是具有敵意的。Honeyd軟件有生成日志的功能,日志全面描述了什么系統(tǒng)什么時候正在探測什么端口。IDS 能對已知的攻擊發(fā)出警報,同時可將所有網(wǎng)絡(luò)流量記錄到一個文件或數(shù)據(jù)庫中。為了獲得分析數(shù)據(jù)包捕獲的更詳細的信息,在HoneypotMe 蜜罐系統(tǒng)中安裝和配置了Snort 入侵檢測系統(tǒng)。Snort 收集到的信息一方面記錄到Snort 的日志文件中,另一方面記錄到Mysql 數(shù)據(jù)庫中以便觀察和統(tǒng)計分析之用。另外,我們打算利用被動探測詳細地分析攻擊者的特征。這就需要捕獲原始數(shù)據(jù)包供被動探測工具使用?？衫肧nort 入侵檢測系統(tǒng)獲取Tcpdump 這樣的二進制日志記錄格式以作為被動探測工具的輸入數(shù)據(jù),獲取攻擊者更詳細的信息以實現(xiàn)隱蔽探測。

正如我們所看到的,蜜罐系統(tǒng)使用許多獨立的工具和腳本創(chuàng)建,在其中還包括一些日志文件和數(shù)據(jù)庫供分析之用。開發(fā)圖形用戶界面來配置、管理蜜罐以及集中管理所有信息來源是我們的目標。蜜罐收集了許多來自不同來源的信息,將它們存儲到多個日志文件和數(shù)據(jù)庫中。用GUI 來分析這些文件和使所收集的數(shù)據(jù)相關(guān)聯(lián)是會有很大的幫助的,這樣的話管理員就不需要記住存儲數(shù)據(jù)的所有文件。另一個很主要的優(yōu)點是其外觀,在基于web 的GUI 上表示信息比訪問日志文件清晰整潔的多。目前,我們僅實現(xiàn)了在web 界面上瀏覽Honeyd 日志的功能。

4 實驗過程及結(jié)果分析

為了驗證該系統(tǒng),虛擬蜜罐宿主機被連接到校園網(wǎng)的物理網(wǎng)絡(luò)環(huán)境中,并為其分配一個真實的分配給物理計算機的IP 地址,在這里我們給其分配的IP 地址為192.168.40.7。所有實現(xiàn)虛擬蜜罐系統(tǒng)的軟件都將運行在Linux9.0 操作系統(tǒng)下。圖3.9 的虛線部分顯示出我們要模擬的虛擬網(wǎng)絡(luò)結(jié)構(gòu)及各個虛擬蜜罐。從圖中可以看出虛擬蜜罐1(IP 地址為192.168.40.56)、虛擬蜜罐2(IP 地址為192.168.40.57)、虛擬蜜罐3(IP 地址為192.168.40.58)和虛擬蜜罐4(IP 地址為192.168.40.59)與虛擬蜜罐宿主機處于同一個網(wǎng)段。從這個網(wǎng)段通過一個IP 地址為192.168.40.123 的路由器(路由器1)模擬一個地址空間為10.0.1.0/24 的網(wǎng)絡(luò),在這個網(wǎng)段中包括兩個虛擬蜜罐:虛擬蜜罐5(10.0.1.51)和虛擬蜜罐6(10.0.1.52)。從這個網(wǎng)段通過一個IP 地址為10.0.1.100 的路由器(路由器2)又增加了另一個地址范圍為10.1.0.0/16 的網(wǎng)絡(luò),在此網(wǎng)絡(luò)中分布了兩個蜜罐虛擬蜜罐7(10.1.0.51)和虛擬蜜罐8(10.1.0.52)。

我們知道虛擬蜜罐系統(tǒng)是一個完全被配置起來的計算機系統(tǒng),它在配置文件中描述每一個引用。

每個樣本定義了每個模擬的操作系統(tǒng)的性能?！疤卣?personality)”這就是操作系統(tǒng)在IP 堆棧層要模擬的東西,可利用Nmap 指紋數(shù)據(jù)庫里相同的描述作為它的OS 類型。在樣本windows 里,特征為“Windows NT 4.0 Server SP5-SP6”,在linux樣本里,它的特征為“Linux 2.4.16 C 2.4.18”。注意,特征并不影響所模擬的服務(wù)的行為,僅僅修改IP 棧的行為。對于所模擬的服務(wù),必須根據(jù)想要模擬的OS 的類型選擇不同的腳本。換句話說就是,如果特征是Windows,不要綁定一個模擬的Apache 腳本到HTTP 端口,而是綁定一個IIS 腳本到HTTP 端口。應(yīng)該說,這些服務(wù)都是入侵者在相應(yīng)的操作系統(tǒng)中希望找到的。在樣本中,你可以為端口規(guī)定明確的行為,也可以定義為一般的行為。兩個樣本中將TCP 和UDP 的缺省行為定義為reset,因此在一般情況下,對于TCP 來講將用RST(連接復(fù)位)去響應(yīng)任意的連接企圖,對于UDP,將用ICMP 端口不可達去響應(yīng)。對于定義為open 行為的端口,對于TCP 將用ACK 響應(yīng),而UDP 將什么也不響應(yīng)。從樣本中可以看出,Windows系統(tǒng)的NetBIOS 端口處于打開狀態(tài);當一個機器與這個蜜罐的80 端口連接時,該蜜罐用IIS 仿真程序perl 腳本與客戶機進行交互;另外Linux 系統(tǒng)的mail 和FTP服務(wù)被激活。上面的兩個樣本分別被綁定在不同的IP 地址上。

5 結(jié)論

總之蜜罐技術(shù)是靈活的,我們可以按照自己的實現(xiàn)目標來構(gòu)建自己的蜜罐系統(tǒng)。在這里我們利用虛擬蜜罐框架來構(gòu)建我們校園網(wǎng)的蜜罐,以實現(xiàn)蜜罐的欺騙和誘騙功能。為了控制黑客的行為,防止黑客對蜜罐系統(tǒng)的破壞和利用,在蜜罐系統(tǒng)中加入了防火墻,并選用了Linux 2.4 自帶的內(nèi)核包過濾的工具iptables。為了了解黑客的行為,在蜜罐系統(tǒng)中加入了信息收集和統(tǒng)計分析功能。通過開發(fā)web 接口的日志文件查詢工具,使蜜罐管理員能夠方便快捷地查詢虛擬蜜罐框架收集的日志信息。為了獲得更詳細的黑客攻擊和掃描信息并及時得到報警,使用入侵檢測系統(tǒng)Snort 來滿足我們的需求。最終,為了獲取黑客自身的信息而又不被其發(fā)現(xiàn),我們使用被動探測工具p0f 來獲取黑客的操作系統(tǒng)指紋。這是實現(xiàn)隱蔽探測的一個很好的思路,即利用蜜罐來引誘攻擊者的掃描和攻擊,然后使用被動探測工具探查攻擊者的信息。這也是我們構(gòu)建蜜罐系統(tǒng)的一個創(chuàng)新點。綜上所述,我們構(gòu)建的蜜罐系統(tǒng)是一個實現(xiàn)了欺騙和誘騙、行為控制、入侵檢測、被動探測、數(shù)據(jù)分析等功能的綜合性蜜罐系統(tǒng)。

參考文獻:

[1] 夏明,趙小敏.基于蜜罐技術(shù)的病毒樣本采集系統(tǒng)的設(shè)計和實現(xiàn)[J].信息網(wǎng)絡(luò)安全,2008(10).

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

1.1　典型的研究計劃

美國和歐盟針對圖書館數(shù)字資源的訪問統(tǒng)計已經(jīng)展開了一些針對性的研究計劃，比如，由美國研究圖書館協(xié)會資助的E-Metric項目、美國多個機構(gòu)（包括ARL、JISC、NISO等）資助的COUNIER項目、歐盟Telematics for Libraries Programme支持的EQUINOX項目等，這些項目多為研究制定描述電子信息服務(wù)和資源的統(tǒng)計指標和績效測度及其方法。

1.2　相關(guān)標準

在相關(guān)的標準方面，面對新的信息環(huán)境和圖書館形態(tài)，一些組織開始嘗試將新的電子資源績效評估標準融入原有相關(guān)標準／指南的框架。例如NISO在2004年批準了圖書館和信息提供者信息服務(wù)和利用的測度和統(tǒng)計數(shù)據(jù)字典(NISO Z39.7-2004 Information Services and Use:Metrics & statistics for libraries and infomation providers--Data Dictionary)，該標準在傳統(tǒng)圖書館工作的基礎(chǔ)上，還特別增加了網(wǎng)絡(luò)服務(wù)、網(wǎng)絡(luò)資源、網(wǎng)絡(luò)運行的新的測度方法，這套數(shù)據(jù)字典將逐漸納入美國圖書館統(tǒng)計工作，成為美國圖書館統(tǒng)計工作的參考依據(jù)，

ICOLC1998年制定的《網(wǎng)上索引、文摘和全文資源使用統(tǒng)計測度指南》(Guidelines for Statistical MeaSures of Usage of Web-Based Indexed，Abstracted and Full Text Resources)提供了一套網(wǎng)絡(luò)化信息資源使用的績效測度指南。2001年的修訂版明確了網(wǎng)絡(luò)信息使用數(shù)據(jù)統(tǒng)計的最基本要求，并提供在隱私、保密、獲取、傳遞和報告形式方面的指導(dǎo)。

ISO ISO/CD 11620也在傳統(tǒng)服務(wù)統(tǒng)計指標的基礎(chǔ)上，結(jié)合ICOLC和COUNTER的研究，進行了圖書涫數(shù)字資源測度及其定義、方法的描述。

1.3　國內(nèi)圖書館數(shù)字資源訪問統(tǒng)計的研究和應(yīng)用

國內(nèi)隨著公共圖書館、大學(xué)圖書館、科學(xué)圖書館系統(tǒng)圖書館評估工作的進行，圖書館界開始逐步重視對圖書館數(shù)字館藏、圖書館數(shù)字化信息服務(wù)的評估。

參考文獻2中提出了數(shù)字資源后評估的概念，但是對圖書館數(shù)字資源訪問統(tǒng)計等后評估的方法和指標體系尚未全面展開評論。一些圖書館自行開發(fā)了基于jsp或者asp的圖書館網(wǎng)站訪問統(tǒng)計軟件，一些數(shù)字圖書館系統(tǒng)，如清華同方的TPI、北京拓爾思的TRS、浙江天宇的CGRS等等也提供了相應(yīng)的統(tǒng)計功能，但是尚沒有一款商業(yè)化的軟件針對圖書館的各種類型的數(shù)字資源提供一攬子的訪問統(tǒng)計方案。

2　圖書館數(shù)字資源訪問統(tǒng)計的方式

2.1　WEB日志方式

web服務(wù)器在工作時，時刻將WWW訪問的結(jié)果記錄在一些log（日志）文件中，通過對服務(wù)器日志的分析可以得到以下信息

(1)通過對訪問時間進行統(tǒng)計，可以得到服務(wù)器在某些時段的訪問情況；

(2)對訪問者的IP進行統(tǒng)計，從中可以判斷主要是那些用戶在訪問Web服務(wù)器；

(3)對訪問請求的錯誤進行統(tǒng)計和分析，可以找出有問題的頁面加以改正；

(4)對訪問者清求的URL進行統(tǒng)計，就可以判斷出讀者對那些頁面的內(nèi)容最感興趣，對哪些頁面的內(nèi)容不感興趣。

各種web服務(wù)器日志文件的格式和內(nèi)容大致相同。根據(jù)W3C的際準[2]，一般Web日志都包括諸如用戶的IP地址、請求時間、方法（GET/POST等）、被請求網(wǎng)頁或文件的URL、發(fā)送／接收字節(jié)數(shù)、協(xié)議版本等信息。表1列出了幾種不同類型的Web日志。

但這些日志文件信息量很大，用戶難以直接從log文件獲得直觀的結(jié)果。對日志文件的分析，可以借助一些商業(yè)性的或者源代碼開放的軟件完成。其中比較好的開放源代碼的日志分析軟件有：AWStats、webalizer等。

從日志文件提供的信息進行統(tǒng)計和分析，就可以對整個網(wǎng)站有一個數(shù)字化、精確的認識，從而對網(wǎng)站的設(shè)計和內(nèi)容進行改善和調(diào)整，使圖書館網(wǎng)站更好地為讀者提供服務(wù)。

2.2　資源提供商提供

數(shù)據(jù)庫的使用情況屬于后評估指標，主要用于更新、續(xù)訂數(shù)據(jù)庫時使用，一般在圖書館購買資源提供商的數(shù)字資源時，應(yīng)該要求由出版商或數(shù)據(jù)庫商提供使用報告，再據(jù)此進行各類分析。

目前出版商／數(shù)據(jù)庫商提供的統(tǒng)計報告常用的相關(guān)統(tǒng)計指標有：

①檢索次數(shù)(searfh/query)：用戶在某一個數(shù)據(jù)庫中提出檢索式的次數(shù)。

②登錄次數(shù)(session/sign on)：用戶打開某個數(shù)據(jù)庫的次數(shù)。

③下載文摘／全文(abstract/fulltext page/image)：用戶在某一個數(shù)據(jù)庫中下載到本地客戶機中的文摘或全文篇數(shù)。

2.3　通過網(wǎng)絡(luò)proxy

服務(wù)器(Proxy Server)是一種服務(wù)器軟件，它的主要功能有：設(shè)置用戶驗證和記帳功能，可按用戶進行記帳，沒有登記的用戶無權(quán)通過服務(wù)器訪問Internet網(wǎng)，可以對用戶的訪問時間、訪問地點、信息流量進行統(tǒng)計。

目前服務(wù)器軟件產(chǎn)品十分成熟，功能也很強大，可供選擇的服務(wù)器軟件很多。主要的服務(wù)器軟件有WinGate公司的WinGate Pro、微軟公司的Microsoft Proxy、Netscape的Netscape Proxy、Sybergen Netwo rks公司的SyGate等，這些軟件不僅可以為局域網(wǎng)內(nèi)的PC機提供服務(wù)，還可以為基于Novell網(wǎng)絡(luò)的用戶，甚至UNLX的用戶提供服務(wù)。目前絕大部分Intemet的應(yīng)用都可以通過方式實現(xiàn)。大多數(shù)服務(wù)器軟件產(chǎn)品具有登記內(nèi)部網(wǎng)用戶訪問外部網(wǎng)的日志記錄，有些產(chǎn)品還可以直接將日志記錄到數(shù)據(jù)庫中。根據(jù)日志記錄文件或數(shù)據(jù)庫，可以統(tǒng)計內(nèi)部網(wǎng)每個用戶的網(wǎng)絡(luò)流量以及上網(wǎng)時間，甚至可以按服務(wù)網(wǎng)絡(luò)類型（如：HTTP、SMTP、FTP等）分別進行統(tǒng)計。

2.4　利用腳本語言自行開發(fā)

通過web服務(wù)器的日志可以獲得用戶訪問圖書館網(wǎng)站信息的情況，但是，這種方式需要對日志的格式進行了解，然后用相應(yīng)的工具軟件或者進行一定的開發(fā)來完成。還有一種獲取網(wǎng)站訪問情況的方法是利用asp或者isp等網(wǎng)絡(luò)腳本語言，利用它們內(nèi)置的server、session、request對象等獲取相關(guān)的信息，獲取數(shù)據(jù)進行統(tǒng)計。比如：利用Jsp我們可以用Jsp的內(nèi)置request對象的獲取參數(shù)方法request.get Parameter("userid")，獲取用戶名；用(request.get Remote Addr)獲取訪問者的IP地址；通過request.get Header("User-Agent")獲取包含瀏覽器和操作系統(tǒng)的信息，然后用字符串分割substring()方法來分別得到瀏覽器和操作系統(tǒng)；通過Jsp的內(nèi)置對象session的方法session，get Creation-Time()返回Session被創(chuàng)建的時間，而session.get Last Accessed Time()則返回當前Session對象最后被客戶發(fā)送的時間，兩者之差為停留時間。

主要分以下幾個開發(fā)步驟：

(1)確定將要統(tǒng)計的信息；

(2)建立數(shù)據(jù)庫；

(3)實時的訪問信息紀錄，記錄每次點擊的信息，包括頁面信息、用戶信息、訪問IP、訪問時間；

(4)實時信息的分類存儲；

(5)顯示方式的選擇?？梢杂肳indows的表格系統(tǒng)，也可以自行編制表格顯示。

利用這種方法相對比較簡單，但是可獲得的統(tǒng)計指標也有限。

除了上述幾種統(tǒng)計方式外，還有基于路由器的流量統(tǒng)計、基于防火墻的流量統(tǒng)計、基于以太網(wǎng)廣播特性的流量統(tǒng)計。但是這些方法所提供的簡單流量的統(tǒng)計功能，不能完全滿足圖書館數(shù)字資源訪問統(tǒng)計的目標。

3　圖書館數(shù)字資源訪問統(tǒng)計的指標

3.1　國際圖書館聯(lián)盟的統(tǒng)計指標指南

國際圖書館聯(lián)盟認為，信息資源提供商對他們提供的特定的電子信息資源所提供的統(tǒng)計數(shù)據(jù)應(yīng)該滿足以下的最低需求。

必須提供的數(shù)據(jù)元素是：

a)會話(session)數(shù)量（或者登陸數(shù)量）number of sessions。為了滿足政府機構(gòu)和專業(yè)組織的報告的需要，應(yīng)該提供會話數(shù)量或者登陸數(shù)量。在沒有國界的網(wǎng)絡(luò)環(huán)境中，會話數(shù)量的統(tǒng)計是一個粗糙的指標。

b)提問數(shù)(number of queries)，即經(jīng)過分類的提問數(shù)量。一次檢索是一次獨立的知識查詢。典型地，一次檢索被記錄為向服務(wù)器提交的一個檢索表單，之后的瀏覽行為或者選定一個單獨條目的行為沒有表現(xiàn)為額外的檢索，除非通過提交二次檢索。立即進行重復(fù)的檢索、雙擊或者其他用戶的無意識行為都不應(yīng)計入其內(nèi)。

c)菜單的選擇數(shù)(number of menu selections)，如果數(shù)據(jù)的顯示需要通過使用菜單來進行瀏覽，則應(yīng)該提供這個指標（如一個電子期刊網(wǎng)站提供的基于音序和主體的菜單選擇）。

d)全文的數(shù)量（打開的、下載的或者提供給用戶的全文，這些全文都是由服務(wù)器控制的而不是由瀏覽器控制的）：

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

電子書——按照書名列出書名和isbn；

參考資料——按照改資源的內(nèi)容單元（如字典的定義、百科全書的文章、傳記等）；

非文本型資源——按照自愿的文獻類型（如圖像、音頻、視頻等）。

上述的每個數(shù)據(jù)元素應(yīng)該按照每個特定的數(shù)據(jù)庫提供商、按照每一組機構(gòu)的IP地址或其他特別的元素（如賬號），以及機構(gòu)名稱、協(xié)會名稱和時間跨度（每月或者每年）分組描述，供應(yīng)商還應(yīng)該提供每天、每小時的統(tǒng)計數(shù)據(jù)，并且還應(yīng)該可以動態(tài)地集成幾個月或者某一段時間的數(shù)據(jù)，而不用限制是當年數(shù)據(jù)還是由供應(yīng)商限定的時間段。

3.2　E-Metrics推薦的統(tǒng)計指標

為了了解圖書館數(shù)字資源的使用情況，確定數(shù)字資源的花費是否合理，MRL的E-Metrics項目推薦的指標如下：

(1)用戶可檢索的電子資源。包括：R1電子全文期刊種數(shù)、R2電子參考資源種數(shù)、R3電子書的種數(shù)。

(2)對網(wǎng)絡(luò)資源和服務(wù)的使用情況。包括：U1電子參考事務(wù)的數(shù)量、U2登錄電子數(shù)據(jù)庫的數(shù)量（會話session數(shù)）、U3電子數(shù)據(jù)庫的提問和檢索數(shù)量、U4電子數(shù)據(jù)庫的請求條數(shù)、U5對圖書館網(wǎng)站和書目的遠程訪問次數(shù)。

(3)網(wǎng)絡(luò)資源和相關(guān)設(shè)備的花費。包括：C1全文電子期刊的成本、C2電子參考資源的成本、C3電子書的成本、C4圖書館對書目設(shè)備、網(wǎng)絡(luò)環(huán)境等相關(guān)設(shè)備的花費、C5對書目設(shè)備、網(wǎng)絡(luò)環(huán)境等相關(guān)設(shè)備的外部花費。

(4)圖書館數(shù)字化活動。包括：D1數(shù)字館藏的大小、D2數(shù)字館藏的使用、D3數(shù)字館藏建設(shè)和管理的成本。

E-Metrics的統(tǒng)計指標，既考慮了數(shù)字資源和數(shù)字化服務(wù)的訪問量，還考慮了數(shù)字資源及其支持成本，便于從成本／效益的角度進行分析。

3.3　我國圖書館常用的數(shù)字資源訪問統(tǒng)計指標

對于圖書館數(shù)字資源訪問統(tǒng)計的指標，在我們常見的統(tǒng)計分忻工作中，統(tǒng)計指標圍繞什么被使用？誰在使用？如何使用？什么時候使用？為什么使用？哪些資料經(jīng)常被下載？哪些資料被檢索最頻繁？資料檢索來自哪些單位？哪個單位使用量最多等問題，通常采用數(shù)字資源提供商提供的訪問統(tǒng)計數(shù)據(jù)與對圖書館網(wǎng)站及自建數(shù)字資源的訪問統(tǒng)計相結(jié)合的方式，除了資源提供商提供的數(shù)據(jù)外，往往采用網(wǎng)站訪問流量、訪問者的IP、網(wǎng)站點擊次數(shù)、數(shù)字資源的點擊次數(shù)、下載的篇數(shù)等指標。

與國外相比，我國圖書館的數(shù)字資源訪問統(tǒng)計指標設(shè)定相對比較粗略，沒有統(tǒng)一的、針對各種類型數(shù)字資源的一致的標準，而且統(tǒng)計指標往往僅僅反映了訪問情況，未能與數(shù)字資源的購買和管理成本掛鉤進行成本／效益分析。

4　圖書館數(shù)字資源訪問統(tǒng)計存在的問題

4.1　資料庫不在館內(nèi)，正確及時的統(tǒng)計數(shù)據(jù)不易取得

隨著各個圖書館在數(shù)字資源建設(shè)方面的積累和發(fā)展，圖書館數(shù)字資源的來源多樣，既有通過遠程鏡像或者資源提供商服務(wù)器訪問的數(shù)據(jù)，也有在本地鏡像的數(shù)據(jù)，還有圖書館自建的數(shù)字資源。尤其對于資料庫不在館內(nèi)的情況，需要廠商配合協(xié)助，但是最大的問題在于沒有辦法從廠商那里得到充分的數(shù)據(jù)，或是廠商提供的數(shù)據(jù)不標準，或是提供的資料不是圖書館想要的，而且由于統(tǒng)計數(shù)據(jù)是由資源提供商提供，其客觀性和真實性的保障機制弱。這樣，正確及時的統(tǒng)計數(shù)據(jù)不易取得。

4.2　缺乏標準的統(tǒng)計指標

由于資源來源多樣，統(tǒng)計指標不規(guī)范，不同的系統(tǒng)提供的統(tǒng)計報告五花八門，沒有統(tǒng)一指標。統(tǒng)計指標定義混亂、不明確，例如“search”在大多數(shù)系統(tǒng)內(nèi)被定義為用戶發(fā)送檢索式的次數(shù)，但有些數(shù)據(jù)庫卻用“query”來表示同樣含義的指標，而CSA數(shù)據(jù)庫則同時使用了“search”和“query”，二者的含義和區(qū)別并不明確。沒有一致、標準、科學(xué)的統(tǒng)計指標體系，對用戶訪問統(tǒng)計的分析及其對圖書館決策的支持可信度就會降低。同時對于數(shù)字資源的訪問統(tǒng)計指標還應(yīng)該結(jié)合每種數(shù)字資源的類型、考慮數(shù)字資源服務(wù)的研究人員規(guī)模等參數(shù)。

4.3　圖書館數(shù)字資源的后評估，應(yīng)該結(jié)合多種評估途徑展開

圖書館數(shù)字資源的訪問統(tǒng)計，是圖書館數(shù)字資源后評估的方法之一，目前的圖書館數(shù)字資源的訪問統(tǒng)計存在統(tǒng)計指標不一致、不標準的問題，而且網(wǎng)站訪問統(tǒng)計不能確定是否與使用者的目的相符，無法完全反映使用者真正的使用狀況，因而，圖書館數(shù)字資源的后評估可以結(jié)合數(shù)字資源的訪問統(tǒng)計、用戶使用調(diào)查、用戶訪談等方式完成。

4.4　用戶隱私的問題

圖書館數(shù)字資源訪問統(tǒng)計的數(shù)據(jù)主要來自web server的log files，目前法律上并無相關(guān)條文規(guī)定log file資料的處理，但由于其中包含使用者的IP地址，應(yīng)該與圖書館的流通記錄一樣，加以保密。不論圖書館決定如何分析log file的數(shù)據(jù)，對于收集何種數(shù)據(jù)、誰能判讀數(shù)據(jù)以及如何使用數(shù)據(jù)等，都應(yīng)有詳細的規(guī)定和說明，以免一時大意觸犯子個人隱私權(quán)。未經(jīng)個人用戶同意，不能收集用戶的個人信息，也不能將所收集的統(tǒng)計信息用于分析和識別用戶個人信息。如果為提供特定服務(wù)必須采集用戶的個人信息，必須向用戶告知他的權(quán)利、個人信息用途及其保護方式，只有在用戶知情同意的情況下才能基于該服務(wù)明確相關(guān)的個人信息。并且必須對合法采集的用戶個人信息必須進行安全保管，未經(jīng)用戶同意不得公開，不得將個人信息轉(zhuǎn)給第三方，而且服務(wù)中止后，必須立即刪除。

【參考文獻】

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　張川，肖金升，周振，胡運發(fā).具有訪問時間完整性的web日志方法.計算機應(yīng)用與軟件.2004(2):105-107

8　梁玉環(huán)，李村合，索紅光.基于JSP的網(wǎng)站訪問統(tǒng)計系統(tǒng)的設(shè)計與實現(xiàn).計算機應(yīng)用研究.2004(4):166-167

10　詹麗萍.E-Metrics在數(shù)位圖書館使用評估的應(yīng)用.p105.lib.nctu.edu.tw/2001conference/pdf/1-1.pdf

11　張曉林、宛玲、徐引篪、宋小冬、王欣.國家科學(xué)效字圖書館數(shù)字資源采購的技術(shù)要求.中國圖書館學(xué)報.2004(7)，14-19

12　索傳軍.論述字館藏的質(zhì)量評價.中國圖書館學(xué)報，2004，30(152):43-46

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

廠商提供給用戶的軟件補丁的形式多為編譯后的庫函數(shù)，所以安裝軟件補丁實際上就是把這些庫函數(shù)拷貝到相應(yīng)目錄，并在需要時進行聯(lián)接操作。軟件公司一般在一段時間后會把針對某一版本的所有補丁進行整理：合并融合，解決沖突，進行整體測試，并使文件拷貝和聯(lián)接操作自動執(zhí)行，得到一個軟件補丁“包”。不同的公司使用不同的名稱，現(xiàn)在一般計算機用戶都熟悉的Windows Service Pack就是這樣的補丁包。Oracle公司給出的補丁包的名稱是Patch Set，安裝Patch Set后的版本稱Patch Set Release(PSR)。

Oracle公司對處于標準技術(shù)支持的產(chǎn)品不定期地提供PSR，例如在完成本文時，版本10.2的最新PSR是10.2.0.2；版本10.1的最新PSR是10.1.0.5;版本9.2的最新（也極可能是最終）PSR是9.2.0.8。

在安裝最新PSR后新發(fā)現(xiàn)的Bug，其相應(yīng)補丁當然會收錄到下一個PSR中。PSR是累積型的，即下一個PSR中會包括當前PSR中所有補丁和新發(fā)現(xiàn)Bug的補丁。同時存在幾個PSR時，只需安裝最新版本一次就可以了。但是由于PSR的發(fā)行有一定間隔，如果這些Bug對用戶有比較大的影響，那么Oracle公司也會向用戶公開和提供這些補丁，這些補丁被稱為個別補?。↖nterim Patch，one-off patch 或 Patch Set Exception）。而對于最終補丁發(fā)行版而言，由于不再有下一個PSR，所以當發(fā)現(xiàn)影響系統(tǒng)的新Bug時，個別補丁成為惟一選擇。

此外，Oracle公司還定期安全補丁，稱之為CPU（Critical Patch Updates）。安全補丁用來修復(fù)軟件的易受攻擊性(vulnerability)或通常說的安全漏洞。這類問題本來不屬于軟件錯誤，在正常使用中不會出現(xiàn)任何問題。但是別有用心的人可以通過運行非常精巧設(shè)計的代碼，繞過數(shù)據(jù)庫系統(tǒng)的安全管理機制，達到非授權(quán)存取的目的。

另外還存在一類補?。涸\斷用補丁（diagnostic patch）。顧名思義，這類補丁不是用來解決問題的，而是用來尋找問題的原因的。這類補丁只在Oracle技術(shù)支持部門要求安裝時，才需要安裝。在得到需要的診斷信息后，應(yīng)立即卸載這一補丁。

利弊及時機選擇

負責(zé)管理支撐大型應(yīng)用系統(tǒng)的數(shù)據(jù)庫的DBA會容易理解安裝軟件補丁的代價。安裝PSR需要停止數(shù)據(jù)庫服務(wù)，關(guān)閉數(shù)據(jù)庫，對于許多應(yīng)用系統(tǒng)安排這樣的停機時間本身就是一件比較困難的事情。事實上，更為嚴重的是由于安裝PSR可能“引入”新的Bug，反而影響應(yīng)用系統(tǒng)的正常運行。軟件補丁本來是修正Bug，怎么會帶來新的Bug？雖然有些讓人匪夷所思，但很不幸這是現(xiàn)實存在的。

對于每一個PSR，其中都包括了少則幾百多則上千個嚴重Bug的修正。即便是如此，在PSR后，很快就又會在安裝PSR后的數(shù)據(jù)庫中發(fā)現(xiàn)一些新問題。其中一部分Bug是以前就一直存在的只是以前沒有發(fā)現(xiàn)，而現(xiàn)在偶爾被發(fā)現(xiàn)，或者是由于PSR修正了某一錯誤從而將其“激活”或容易發(fā)現(xiàn)。但是確實有一些Bug是由這一PSR造成的，Oracle技術(shù)支持部門稱其為倒退（Regression）。對于每一PSR，在metalink中有兩個重要的與之有關(guān)的文檔，一個是“List of fixes added in XXXX”，是這一PSR修復(fù)的Bug的清單，是一本“功德簿”；另一個是“Known issues and alerts affecting XXXX”，是安裝PSR后發(fā)現(xiàn)的問題，可以稱其為“悔過簿”。由于大型軟件的復(fù)雜性，Bug幾乎是不可避免的。重要的是能夠及時提供信息，DBA可以結(jié)合自己系統(tǒng)的情況做出正確的判斷。讀者不必因為知道還存在著Bug，就對Oracle數(shù)據(jù)庫產(chǎn)品失去信心。PSR修復(fù)的上千個Bug中絕大多數(shù)是在一些很少見的環(huán)境中，或者是若干個組件的復(fù)雜組合使用的情形中發(fā)生的。

如果系統(tǒng)在運行中出現(xiàn)過某種問題，由Oracle技術(shù)支持部門或第三方的專家確認原因是PSR中的某一Bug，這樣就必須盡早安裝;如果系統(tǒng)一直運行正常，并且在PSR已發(fā)現(xiàn)的問題中涉及的組件或功能（如Logical Standby, JVM，RAC等）在系統(tǒng)中并不使用，此時可以選擇安裝也可以選擇不安裝。

另一個需要考慮的因素是安裝補丁的時機。上述這些考慮的一個重要前提是系統(tǒng)已經(jīng)投入運行，擔(dān)心“倒退”的Bug影響系統(tǒng)。如果系統(tǒng)還處在開發(fā)和測試階段，不需要有任何猶豫，安裝最新的PSR，并在此基礎(chǔ)上測試應(yīng)用系統(tǒng)是否工作正常。如果發(fā)現(xiàn)異常，要及時請Oracle技術(shù)支持部門確認是否新Bug，如果是請其提供個別補丁。目的就是在一個盡可能完善穩(wěn)定的數(shù)據(jù)庫平臺上測試應(yīng)用系統(tǒng)。我們可以把這種安裝補丁的策略概括為“補丁補新不補舊”。

以上都是針對PSR的安裝，對于個別補丁，由于補丁修復(fù)的Bug單一，容易判斷是否需要安裝。需要注意的是，如果在當前PSR之上安裝了若干個個別補丁，那么在下一個PSR后，在安裝下一個PSR之前，需要卸載所有個別補丁。為便于管理，現(xiàn)在Oracle技術(shù)支持部門要求必須使用工具opatch安裝管理個別工具，而盡量避免手動拷貝文件等操作。

最后是安全補丁安裝的判斷。雖然安全漏洞這個詞看上去讓人覺得非常嚴重，但是還要冷靜綜合分析這些漏洞在系統(tǒng)中的危害程度。事實上，不安裝安全補丁的危險性可能遠遠小于始終不渝地使用scott/tiger這樣人人都知道的用戶名和口令的“標準缺省”做法。

安裝PSR

使用oui工具安裝PSR時只需要用鼠標做幾個選擇就可以進入自動執(zhí)行的階段，操作過程本身非常簡單。但是如果要求必須一次安裝成功；要求必須在凌晨2點到4點這個有限的停機時間段完成操作；要求安裝過程不出差錯，以后出現(xiàn)問題時能夠完全排除此次操作失誤的可能性，那么就需要在啟動oui之前做一些準備工作。

1. 收集信息

有關(guān)PSR的信息中，一個最重要的文檔就是軟件補丁說明，這個文件相當于技術(shù)手冊中的安裝指南和發(fā)行說明。文件本身包含在下載的軟件補丁文件之中，文件名是patchnote.htm或README.html。需要注意的一個問題是在軟件補丁文件之中找到的這一Patch Set Notes可能不是最新版，可以根據(jù)文件內(nèi)的提示信息在metalink中檢索最新版。

另外兩個重要文件就是前面已經(jīng)提及的“功德簿”和“悔過簿”，相對于“功德簿”更應(yīng)該仔細閱讀“悔過簿”中的每一項內(nèi)容。另外，在Patch Set Notes的已知問題（Known Issues）一節(jié)內(nèi)列出了安裝PSR后出現(xiàn)的一些問題。

除去這三個主要文件外，還應(yīng)在metalink中檢索，尋找是否還有其他涉及這一PSR的技術(shù)文章，尋找其他用戶在安裝這一PSR時或安裝后遇到問題時所發(fā)的救助的帖子，前車之鑒更應(yīng)重視。

2. 做出判斷

在認真閱讀收集到的文章之后，根據(jù)自己系統(tǒng)的實際情況，做出是立即安裝PSR，或是等待下一PSR的決定。如果是暫緩安裝，則要記錄原因，以便以后跟蹤Bug的修復(fù)進程。

3. 制訂實施計劃

在決定安裝PSR后，需要制訂一個實施計劃。在計劃中不僅要包括正常的操作步驟，更要考慮在出現(xiàn)意外時的應(yīng)急處理（如果安裝PSR失敗，則在正常應(yīng)用開始時間之前，要恢復(fù)系統(tǒng)到安裝之前的狀態(tài)）。如果可能，在對正式系統(tǒng)開始實施之前，應(yīng)在測試系統(tǒng)中進行演練和應(yīng)用處理的測試，保證在安裝PSR后不會影響應(yīng)用系統(tǒng)的運行。

安裝PSR的計劃大致有以下幾個部分：停止數(shù)據(jù)庫服務(wù)關(guān)閉數(shù)據(jù)庫；備份DBMS軟件和數(shù)據(jù)庫以備恢復(fù)之用；安裝PSR軟件；更新數(shù)據(jù)庫數(shù)據(jù)字典升級PSR版本；正常啟動數(shù)據(jù)庫開始數(shù)據(jù)庫服務(wù)。

看似簡單的關(guān)閉數(shù)據(jù)庫的操作，在系統(tǒng)構(gòu)成復(fù)雜時也會變得不容易。另外，如果夜間作業(yè)時間不允許在完成數(shù)據(jù)庫完全備份之后再安裝PSR，則安裝PSR的日期應(yīng)該選擇在例行的數(shù)據(jù)庫完全備份的下一個晚上，只備份重做日志。

在安裝PSR之前備份DBMS軟件的目的是，由于安裝PSR會對許多程序和庫函數(shù)進行更新，如果安裝PSR中途失敗（雖然可能性非常?。锌赡茉斐蒁BMS軟件出現(xiàn)不一致。另外一種可能的情形是，在安裝PSR，更新數(shù)據(jù)字典后，測試應(yīng)用系統(tǒng)時，出現(xiàn)了某種異常，原因不明，最終決定放棄PSR。如果操作之前沒有備份，則此時只有重新安裝軟件一種選擇（PSR不同于完整軟件安裝，在oui中無法單獨卸載PSR軟件）。

對文件、目錄和文件系統(tǒng)的備份，最簡單的方式可以使用cp、tar、dump等命令完成。如果希望縮短文件拷貝時間，可以考慮分區(qū)備份的方法。分區(qū)備份常用的命令是dd。但是，分區(qū)拷貝比文件拷貝速度快的前提是良好的分區(qū)設(shè)計：Oracle軟件單獨占一個大小適中（如4GB）的分區(qū)，這樣扇區(qū)拷貝才會體現(xiàn)優(yōu)勢，這也就是為什么在安裝軟件時，Oracle建議單獨使用一個分區(qū)安裝軟件的原因之一。

在制定實施計劃時，應(yīng)認真閱讀Patch Set Notes中有關(guān)操作前準備工作一節(jié)。在這節(jié)內(nèi)會介紹對于一些特殊系統(tǒng)構(gòu)成，如果你的系統(tǒng)屬于文檔中提到的構(gòu)成，一定要首先閱讀文內(nèi)提示的相關(guān)技術(shù)文章，找到正確的安裝步驟。

使用oui, PSR軟件安裝完成后，一定不要忘記更新數(shù)據(jù)字典這一步驟。如果在這一ORACLE_HOME下生成了多個數(shù)據(jù)庫，則每個數(shù)據(jù)庫都必須更新數(shù)據(jù)字典。

4. 實施操作

制訂一個詳細的計劃后，實施操作就可以“照本宣科”，是一個簡單的體力勞動。要認識到“忙中出錯”的概率遠比“急中生智”大得多，操作時盡量減少失誤的可能性。例如，需要執(zhí)行的復(fù)雜命令，盡可能從一個文件拷貝到終端執(zhí)行，而不要現(xiàn)場輸入。另外，在實施過程中， 要記錄各個階段實際的執(zhí)行時間，以供以后制訂類似計劃時參考。

5. 檢查操作結(jié)果并記錄備案

執(zhí)行一個操作，操作是否成功，一定要進行檢查，不能簡單認為沒有出錯信息就是成功。要知道驗證的方法。除去極個別極費時間的驗證（分區(qū)備份的內(nèi)容是否可以成功恢復(fù)系統(tǒng)，必須恢復(fù)分區(qū)，啟動數(shù)據(jù)庫，測試應(yīng)用系統(tǒng)后才能確認），其余操作都應(yīng)進行驗證。所有屏幕輸出信息和日志文件都應(yīng)保留，作為安裝報告的附件提交給上級或客戶。

在屏幕輸出或日志文件中出現(xiàn)異常/錯誤信息時，應(yīng)即時分析，決定馬上采取的措施。出現(xiàn)嚴重錯誤時，可能需要重新執(zhí)行某一SQL程序，或者重新安裝PSR。所以在制訂實施計劃時應(yīng)在時間上留出異常情況處理的時間。

下面給出一個在Linux平臺上安裝10.1的PSR的實例，給從未安裝PSR的讀者有一個感性認識。

操作系統(tǒng)是RHEL AS4.0 Update3，Oracle的當前版本是10.1.2。在metalink中檢索，找到10.1版的最新PSR10.1.0.5。下載壓縮文件。在壓縮文件中找到Patch Set Notes，該文檔的完成日期是2006年1月。而按照文檔內(nèi)的提示在metalink中檢索得到的此文檔的最新版本完成日期是2006年4月。使用文件比較工具進行比較，兩個版本沒有實質(zhì)性差別，只有語句措詞的修改，但是養(yǎng)成總是檢索最新文檔的習(xí)慣有益無害。

根據(jù)Patch Set Notes中的說明，有一些特殊系統(tǒng)構(gòu)成需要額外的步驟，本例中由于全部沒有涉及到，所以可以按標準步驟執(zhí)行。

另外，檢查“Known issues and alerts affecting 10.1.0.5”文檔后，發(fā)現(xiàn)10.1.0.5引入的影響最大的一個Bug是執(zhí)行SELECT MAX()在某些特定條件下結(jié)果不正確。而這一Bug可以通過設(shè)置事件（event）關(guān)閉FIRST ROW優(yōu)化而避免。最后的結(jié)論是這一BUG不會對本系統(tǒng)有影響，可以安裝PSR10.1.0.5。

1. 檢查數(shù)據(jù)庫表空間和初始化參數(shù)是否需要調(diào)整。

System表空間要求有一定未使用空間:初始化參數(shù)SHARED_POOL_SIZE 和 JAVA_POOL_SIZE不能低于最小值150MB。

2. 關(guān)閉數(shù)據(jù)庫，停止listener和agent等進程。

3. 解壓縮下載文件至某一目錄，執(zhí)行oui。

在壓縮文件中附帶的oui的版本要比已經(jīng)安裝的版本高，應(yīng)總是使用新版本的oui。在oui窗口中，要求選擇本次安裝的軟件的位置，正確的位置是解壓縮目錄下的子目錄Disk1/stage/， 選中products.xml即可開始文件拷貝。

要注意窗口中會出現(xiàn)本次安裝的日志文件的文件路徑和文件名。文件的位置是在Oracle的inventory所在目錄的子目錄logs中，文件名由前綴InstallActions和安裝日期時間組成，如: InstallActions2006-08-30-11-32-48AM.log。

正常結(jié)束后，退出oui。打開日志文件，檢索是否出現(xiàn)error 或“ORA-”的錯誤信息。本次安裝產(chǎn)生的日志文件內(nèi)，沒有任何此類的信息，表明PSR軟件安裝成功。如果此時再次啟動oui，點擊“已安裝軟件”，則可以看到在原有的10.1.0.2軟件之下，新出現(xiàn)了10.1.0.5一項，這也證實PSR軟件安裝成功。

4.更新數(shù)據(jù)庫數(shù)據(jù)字典

更新數(shù)據(jù)字典時，必須以特殊的升級方式打開數(shù)據(jù)庫。

$ sqlplus /nolog

SQL> CONNECT / AS SYSDBA

SQL> STARTUP UPGRADE

SQL> SPOOL patch.log

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

執(zhí)行結(jié)束后，關(guān)閉重定向：

SQL> SPOOL OFF

打開文件patch.log檢查是否有錯誤“ORA-”。（這一文件在啟動sqlplus時的當前目錄中，當然也可以在“SPOOL patch.log”語句中顯式指定文件路徑。）如果出現(xiàn)錯誤要分析原因，在解決問題后，需要再次執(zhí)行catpatch.sql程序。

更新數(shù)據(jù)字典時，由于對某些PL/SQL包刪除后又重新生成，造成相關(guān)PL/SQL包的狀態(tài)為異常（invalid）。在以后調(diào)用這些包時，檢測到其狀態(tài)為非法，會自動執(zhí)行編譯命令，使狀態(tài)成為正常（valid）。雖然不會出錯，但會造成個別處理第一次執(zhí)行時變慢。顯然，與其留到應(yīng)用系統(tǒng)運行時再一個個編譯，不如之前集中一次重編譯所有異常包。

SQL> SHUTDOWN

SQL> STARTUP

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

最后，根據(jù)Known Issues中的指示，完成與本系統(tǒng)有關(guān)的操作。例如，修改Pro*C的配置文件。這里執(zhí)行一個修改文件存取權(quán)限的“后操作”，以便非同組用戶和程序可以存取客戶端工具和庫函數(shù)。

$ cd $ORACLE_HOME/install

$ ./ changePerm.sh

個別補丁管理工具opatch

如前所述，在一個PSR后發(fā)現(xiàn)的新BUG，只能把其補丁收入到下一個PSR中。如果對數(shù)據(jù)庫有實質(zhì)性影響，則這一補丁以個別補丁的形式向用戶提供。個別補丁是與某一個特定的PSR關(guān)聯(lián)，是安裝在這一PSR之上的。另外，如同其名字表明的，個別補丁只是單一Bug的補丁，不會包含其他個別補丁，即不是累積型的。

在9.2版之前，安裝個別補丁的操作完全是手工的。這種手工方式的缺點不僅在于加重DBA的負擔(dān)，容易造成操作失誤，更嚴重的是無法對已安裝的個別補丁進行管理。

為解決手工方式的缺陷，從9.2版開始，Oracle公司設(shè)計實現(xiàn)了個別補丁安裝管理工具opatch。opatch使用一個稱為inventory的系統(tǒng)數(shù)據(jù)結(jié)構(gòu)（嚴格說是與oui共享inventory）,集中管理所有已安裝的個別補??；個別補丁的安裝和卸載都使用opatch命令完成，沖突檢測也由opatch在安裝時自動完成；提供列表命令可以很方便得到已安裝個別補丁的信息。

10g(10.1和10.2)版本中，opatch作為一個標準工具，在軟件安裝時自動安裝。（安裝在$ORACLE_HOME/OPatch下。）而對于9.2版，需要從metalink下載opatch。無論數(shù)據(jù)庫是哪一個版本，系統(tǒng)中是否已經(jīng)安裝opatch，在使用之前，應(yīng)從metalink下載最新版本的opatch。很遺憾，由于系統(tǒng)實現(xiàn)的問題，10.2使用的opatch與之前版本（10.1和9.2）使用的opatch不兼容，不能混用，這一點必須注意。

opatch是使用perl編寫的腳本程序（其中也使用JAVA API）。編程使用的perl版本是5.6版，雖然在5.6之前的版本中也可運行，但應(yīng)盡可能安裝5.6或以上的版本的perl。對于DBA來說一個好消息是，如果安裝9.2版軟件時保留了HTTP服務(wù)器，則在$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執(zhí)行操作時，除在屏幕輸出結(jié)果外，還生成日志文件。日志文件的路徑和文件名格式如下：

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

其中“patch_id”是Oracle技術(shù)支持部門為個別補丁分配的編號。

4. 個別補丁安裝實例

沿用安裝PSR實例中的環(huán)境。在安裝PSR10.1.0.5后，檢索metalink，發(fā)現(xiàn)若干在其之上的個別補丁。選擇其中之一安裝。

個別補丁Patch 4518443修復(fù)BUG4518443，這一BUG的主要問題是TNS LISTENER在注冊O(shè)NS（Oracle Notification Services）的同時如果創(chuàng)建子進程，那么LISTENER會掛起（HANGUP）。

安裝時，首先，從metalink下載補丁的壓縮文件p4518443_10105_LINUX.zip。將此文件解壓縮至某一目錄中。解壓縮后，這一補丁的所有文件都在子目錄4518443下，目錄名就是個別補丁的補丁號，opatch依據(jù)目錄名獲得信息，所以一定不要重命名子目錄。

然后，在終端窗口中，執(zhí)行cd命令移動到4518443子目錄中，執(zhí)行以下命令：

$ $ORACLE_HOME/OPatch/opatch apply

對inventory列表，確認安裝操作：

$ $ORACLE_HOME/OPatch/opatch lsinventory

執(zhí)行卸載命令時，也必須使4518443子目錄成為當前目錄。其中，Rollback命令需要兩個參數(shù)：-id給出個別補丁號；-ph 給出個別補丁解壓縮后的路徑。

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

隨后再對inventory列表，則會看到這一個別補丁已經(jīng)被移去。

4. 使用opatch顯示已安裝的版本信息

不需要啟動數(shù)據(jù)庫，執(zhí)行加選項的對inventory的列表命令，可以得到已安裝的軟件的各個組件的詳細版本信息。

$ $ORACLE_HOME/OPatch/opatch lsinventory -detail

安全補丁CPU

一個CPU內(nèi)包含了對多個安全漏洞的修復(fù)，并且也包括相應(yīng)必需的非安全漏洞的補丁。CPU是累積型的，只要安裝最新的CPU即可，其中包括之前的所有CPU的內(nèi)容。事實上，在CPU之前的安全漏洞修改除去個別例外也被包括在CPU中。Oracle公司只對處于標準技術(shù)支持和延長支持期間的產(chǎn)品提供CPU更新，對處于維持支持范圍的產(chǎn)品不提供新的CPU。（對于9.2以前的版本，只對處于ECS和EMS期間的版本提供CPU更新。）一般對當前補丁發(fā)行版及前一個版本提供CPU，但也有只限于當前補丁發(fā)行版的例外情形。也就是說，一般需要先安裝最新PSR后才可能安裝CPU。由于是累積型的定期，所以對于某一平臺的某一版本，如果兩次CPU期間沒有發(fā)現(xiàn)新的安全漏洞，則新的CPU與前一版本完全相同。

在以下網(wǎng)址中可以找到CPU的信息，但是很遺憾，只有技術(shù)支持簽約用戶才可以從metalink下載補丁文件。

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

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

對于每一個CPU，附有相應(yīng)的說明文檔（Critical Patch Update Note），其中介紹安裝過程和注意事項，在安裝之前應(yīng)認真閱讀此文檔。同樣也存在文檔“Oracle Critical Patch Update MM YYYY Known Issues for Oracle Database”，其中列出了說明文檔中沒有給出的新信息。

在安裝時，首先下載壓縮文件p5225797_10105_LINUX.zip，解壓縮到與其它個別補丁相同的目錄下。檢查其發(fā)行說明時，發(fā)現(xiàn)要求opatch版本比現(xiàn)已安裝版本要高，下載安裝指定版本opatch。進入子目錄5225797（這是此安全補丁的補丁號），執(zhí)行apply命令。

$ $ORACLE_HOME/OPatch/opatch apply