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

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

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

關鍵詞：分布式計算；日志分析；Hadoop；集群；vmware

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

1 概述

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

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

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

日志文件記錄了日常操作的原始數據，數據極具價值。隨著時間的推移日志文件越來越大，分析難度也隨著增大。本系統(tǒng)的設計就是為了解決文本日志的分析，系統(tǒng)針對Web日志。本系統(tǒng)基于搭建好的Hadoop分布式架構，將數據先存入到HDFS文件系統(tǒng)中，運行mapreduce程序對日志文件進行過濾分析，最后將數據輸出到指定文件中。充分發(fā)揮了Hadoop分布式存儲和分布式計算的優(yōu)勢。 解決了海量數據日志文件的分析的難題，采用基于分布式結構的日志分析系統(tǒng)，提高了分析效率。

目標日志是由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）狀態(tài)代碼（請求是否成功及原因）。7）發(fā)送給客戶端的總字節(jié)數。

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

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

利用分布式的架構對日志文件進行分析，對日志文件進行過濾，按時間對日志數據進行分析。分析主要從頁面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部署的基本結構，MapReduce 模型中的 Master 的主控作業(yè)節(jié)點稱為 JobTracker，此框架下面的所有作業(yè)（Job）都是由 JobTracker 進行管理的，它是唯一存在的。TaskTracker，負責每一個具體任務的執(zhí)行。任務（Task）是具體執(zhí)行的基本單元，每一個作業(yè)被拆分成很多的任務，被分配到合適任務節(jié)點上去執(zhí)行，任務節(jié)點一邊執(zhí)行分配過來的任務，一邊向 JobTracker 匯報執(zhí)行任務的狀態(tài)，以此來幫助JobTracker 了解作業(yè)執(zhí)行的整體情況，向空閑節(jié)點分配新的任務等操作。

3.3 日志數據的HDFS存儲

圖2展示了HDFS的工作原理。首先client通過調用DistributedFileSystem的create方法來創(chuàng)建文件。DistributedFileSystem通過RPC調用NameNode在文件系統(tǒng)的名字空間里創(chuàng)建一個文件。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轉發(fā)給第二個datanode。

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

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

3.4 日志分析過程

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

4 結果分析

系統(tǒng)硬件環(huán)境的CPU為2.00GHz，內存為4G可用內存為3G，實驗時為三臺機器分配的內存情況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í)行過程的輸出，第一個任務map過程耗時2分31秒，reduce耗時9秒，整個任務耗時2分48秒。Map過程讀取的記錄為311965條。reduce讀取字節(jié)數為45431334，輸出字節(jié)數為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訪問狀態(tài)200次數為125，訪問狀態(tài)301次數為2，訪問狀態(tài)403次數為4，訪問狀態(tài)404次數為8，pv量最多的一天為2011年6月30日121次，最多的頁面為/favicon.ico訪問次數為7次，月流量為46698。也可以查看六月具體每一天的數據。圖8是單日統(tǒng)計數據，這一天的pv量為5，get方式請求為4，post方式請求次數為1，請求的狀態(tài)碼都為200即請求成功，總流量為1684字節(jié)。

5 小結

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

參考文獻：

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

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

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

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

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

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

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

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

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

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

0　引言

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

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

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

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

2　日志取證關鍵部件

2．1　日志收集

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

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

2．2　日志管理

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

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

2．3　日志數據關聯(lián)分析策略

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

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

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

(1)數據聚合

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

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

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

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

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

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

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

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

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

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

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

2．4　提交證據

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

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

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

1 EXT4文件系統(tǒng)的重要數據結構

以下的數據結構都來自2.6.28內核。

1.1 超級塊super_block

/include/linux/EXT4_fs.h

struct EXT4_super_block {

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

__le32 s_blocks_count; /* 文件塊數 */

__le32 s_r_blocks_count; /* 保留未用的文件塊數 */

__le32 s_free_blocks_count; /* 可用的文件塊數 */

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

__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; /* # 每一組節(jié)點數目 */

__le32 s_mtime; /* 最近被安裝到內存的時間 */

…………

/*150*/ __le32s_blocks_count_hi;/* 文件塊數的高32位 */

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

__le32s_free_blocks_count_hi;} /* 可用文件塊數高32位 */

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

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

1.2 組描述符 Group Descriptor

組描述符合超級塊一樣，記錄的信息與整個文件系統(tǒng)相關。當某一個組的超級塊或inode受損時，這些信息可以用于恢復文件系統(tǒng)。因此，為了更好的維護文件系統(tǒng)，每個塊組中都保存關于文件系統(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; /* 可用的文件塊數 */

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

__le16 bg_used_dirs_count; /* 使用中的目錄數 */

__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é)點數據結構

struct EXT4_inode {

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

__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; /* 連接數目 */

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

__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節(jié)點用戶id高位 */

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

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

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;/* 節(jié)點擴展的創(chuàng)建時間(nsec

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

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

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

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

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

1.4 i節(jié)點的擴展信息的數據結構

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

__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 是在該文件中最近分配的塊的邏輯號。當然，他沒

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

/*

__le32 i_nEXT_alloc_goal;

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

struct semaphore truncate_sem;//元數據塊，數據的修改信息等

struct inode vfs_inode;

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

};

1.5 句柄handle_t數據結構

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

struct handle_s

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

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

int h_ref;//句柄中的參照數

int h_err;//出錯數

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

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

unsigned int h_jdata: 1; /* 日志數據 */

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

};

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

各種狀態(tài)為：

* RUNNING: 正在進行新的修改

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

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

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

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

* 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文件系統(tǒng)的read操作是由do_sync_read函數來實現(xiàn)的，write操作是由do_sync_write函數來實現(xiàn)的，以此類推。只要我們找到相關的函數就能分析EXT4文件系統(tǒng)是怎么實現(xiàn)讀寫操作的。

2.2 EXT4的寫操作

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

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

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

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

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

EXT4_file_write函數的分析如圖2。

3 結束語

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

參考文獻：

[1] 李善平,陳文智.邊學邊干LINUX內核指導[M].浙江：浙江大學出版社,2002.

[2] 涂健,孫輝.Linux2.6(內核下)EXT3文件系統(tǒng)的數據結構及性能分析[J].南昌水專學報,2004(6):8-10.

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

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

關鍵詞：AIX；SAP系統(tǒng)；Oracle數據庫；同構；數據遷移

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

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

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

源系統(tǒng)環(huá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數據庫控制文件

使用以下命令生成PRD數據庫控制文件

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服務，并確認SAP和ORACLE進程已停止

2.4 在目標系統(tǒng)T49上所作的準備工作（很重要：請注意是目標系統(tǒng)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文件傳至目標系統(tǒng)

用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數據庫，執(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數據庫能否正常啟動關閉

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 結束語

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

第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、用戶名、訪問時間、訪問網站的地址、返回類型、請求的字節(jié)數等內容。

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

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、用戶號、訪問時間、訪問地址、返回類型，請求的字節(jié)數這幾個關鍵字段。

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

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

(5) 按用戶分組統(tǒng)計訪問網站的頻率。以用戶訪問網站的頻率為參照衡量用戶上網的時長，盡可能從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) 按用戶分組統(tǒng)計資源的占用情況。分析帶寬的占用情況本來應該以秒為單位分別統(tǒng)計用戶流量，求均值后再排名，但這樣過于復雜。在這可以換一個思路，按用戶號統(tǒng)計流量，排序靠前流量越高的，占用的帶寬也較高?？墒褂萌缦旅畹玫綆捳加玫呐琶?/p>

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

GROUP BY uno

ORDER BY SUM(byte) DESC

排名中可知user1641用戶排名第一訪問量相當大，經查詢得知該用戶為教職工，上網時段為12:30:50~01:36:51，連續(xù)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].計算機研究與發(fā)展,2001(4).

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

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

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

關鍵詞：遠程教育；數據挖掘；個性化學習系統(tǒng)

中圖分類號：G434 文獻標識碼：A 文章編號：1007-9599 (2012) 12-0000-02

目前網絡遠程教育的普及使得優(yōu)質教學資源突破了時間和空間的局限性，使得終身學習成為可能。而當前網絡教育的開展，也出現(xiàn)了種種弊端：技術方面，多以教學資料呈現(xiàn)形式的轉換為主，只是書本搬家而缺少一定的交互模式；而其不同學習進度、不同興趣、個性化的學習需要基本不能得到一定的滿足，無法因材施教。因此，網絡教育需要強大的技術力量幫助學生迅速高效地搜尋到滿足其個性要求的教學資源，并對其學習整個進程進行正確指引與科學評價。本文試圖設計一種系統(tǒng)模型，利用數據挖掘技術來改進當前的網絡教育模式，對每一個學生都提供個性化的學習進程，達到一下學習要求：

學習系統(tǒng)可依照與當前登錄學生相似的學生的學習步驟自動的對其后續(xù)目標知識進行預測和推薦

針對學生的學習過程進行過程性考核，并依據成績動態(tài)改變學生的學習與練習進程，對此學生的掌握不好的地方進行再次督學

本文依據以上目標，構建了基于Web的個性化學習系統(tǒng)模塊（Web-based Personalized Learning Core System 下文簡稱WPLCS）來滿足遠程教育中學習者個性化學習的迫切需要。

在該系統(tǒng)核心算法的選型上鎖定了數據挖掘技術來構建WPLCS。下面圖1便是基于網絡的個性化學習系統(tǒng)核心模塊（Web-based Personalized Learning Core System）數據挖掘引擎的基本架構：

數據挖掘技術是從多樣的、無序的數據中，抽取提煉出有用的信息的過程。因此數據挖掘技術被廣泛商用。但在教育領域中應用此技術，就不能簡單的套用一些商用模式，因為電子商務中的服務器端在進行數據挖掘時只需知道大量的用戶在訪問了A頁面后又去訪問了B或者C頁面，證明他們對B、C頁面有潛在的興趣，從而向訪問過A頁面的用戶的客戶端動態(tài)的推薦B、C頁面，以此來達到個性化引導客戶訪問的目的。

而在網絡教育中，若系統(tǒng)鎖定學生感興趣的知識和關注知識頁面的時長等信息，不但可以依據此信息靈活地改變練習和考核進程，還可重構網站結構減少網絡響應時長。與此同時，在設計網絡課程的頁面時，力圖使嵌有某些特定知識頁面和網絡課程中的知識點形成映射關系，也就使得系統(tǒng)能夠清楚標記出學生對于知識的掌握情況。從而在數據挖掘過程中能夠做到以知識點為導向。

WPLCS利用數據處理模塊將系統(tǒng)的用戶訪問日志文件和數據庫構建出一個學生基本特征數據倉庫，再在此數據倉庫的基礎上，利用多種數據挖掘算法進行挖掘從而形成學生個性化數據挖掘庫。

數據預處理

本階段首要找準挖掘數據源，本文遴選出系統(tǒng)服務器中的日志文件和系統(tǒng)數據庫數據作為數據源。抽取數據源數據形成挖掘庫，即學生特征數據倉庫。

服務器訪問日志的預處理

學生從登錄到系統(tǒng)服務器開始，便在此服務器上留下相應的日志文件。它包括登錄學生的IP、URL、Cookie等信息。首先抽取網絡日志中的信息，再清洗數據缺值等臟數據，最后識別學生的IP及登錄Cookie值，合并同一個學生的訪問路徑請求，將時間跨度大的URL進行相應的區(qū)分和記錄。

構建數據挖掘庫

匹配系統(tǒng)數據庫預處理后的數據和服務器訪問日志預處理得到的數據，構建出數據挖掘庫，即學生特征數據倉庫（學習者標識、個人信息、學業(yè)信息、偏好信息等）。

數據挖掘

綜合考慮不同數據挖掘算法有不同的特點和弊端以及前文所述的個性化學習的要求，在選擇數據挖掘算法時，本文選取了序列模式、聚類、關聯(lián)規(guī)則發(fā)現(xiàn)等不同算法，并將其有機結合。為了精確匹配當前學生特征模式與規(guī)則前項，力爭較高的推薦準確率，采取了基于關聯(lián)規(guī)則的挖掘方式進行學習頁面推薦；為了得到更高的推薦覆蓋率，采用基于聚類分析進行推薦。綜合了兩種數據挖掘算法的優(yōu)勢，從而改善了推薦的測度。本文將學生特征數據倉庫中的數據傳送到數據挖掘核心模塊來進行數據挖掘，得到的數據再存放到學生個性化數據倉庫來完成整個數據挖掘的全過程。

關聯(lián)規(guī)則發(fā)現(xiàn)

關聯(lián)規(guī)則發(fā)現(xiàn)，即尋找數據項之間的聯(lián)系規(guī)則。在服務器訪問日志數據的預處理過程中，將學生訪問的頁面路徑組成了學生訪問session集，我們可以利用關聯(lián)規(guī)則挖掘得到學生訪問請求間的關聯(lián)規(guī)則。其中比較簡單的一種規(guī)則為：訪問了A頁面的學習者中，有60％又訪問過B頁面。得到這種初始化關聯(lián)規(guī)則后，再通過用戶訪問頁面與知識點的一一映射關系，我們就可以推理出更加實用的規(guī)則模式，即確定在學習過A知識點的學習者中有60％的人對B知識點表現(xiàn)出一定興趣。得到這種有用規(guī)則后我們即可對所有訪問A頁面的學習者的頁面上加上B頁面的推薦鏈接，方便學習者導航。

聚類

聚類，即將數據劃分到不同的類中，類間的差別盡可能的大，類內的差別盡可能的小，聚類分析實現(xiàn)并不知曉將要劃分成幾個類，而是利用系統(tǒng)服務器自動化、智能化的計算而得。產生出不同的類后，某學生的特征模式一旦符合某個類后，系統(tǒng)推薦引擎會自動將此學生未來可能訪問的頁面鏈接推薦給學生。由此就可以智能化地將處在不同學習階段的學生匹配到此類本該獲得的學習和考核進程。

序列模式

與關聯(lián)規(guī)則發(fā)現(xiàn)相仿，序列模式是將數據間的關聯(lián)性與時間相聯(lián)系。在實際挖掘過程中，我們可以得到下列序列模式：在學習過B和C兩個知識點的學生中有81％的學生在若干天后進行A知識的學習，并且在此過程中大量地頻繁訪問A2、A5、A7、B2等知識，而且對這些知識點的掌握情況開始下滑。因此我們可以及時干預在此時間段所有學習過C、B知識點的學生，將一定量的練習和測試推薦給他們，幫其熟練掌握上述知識，從而達到因時施教的目的。

作為一種新的教學手段——基于Web的網絡教育，當前正方興未艾。本文旨在通過計算機數據挖掘技術構建出一個智能化的基于網絡的個性化學系統(tǒng)，以此來輔助完成對不同學生的個性化教學。從而充分發(fā)揮網絡教育的優(yōu)勢。

參考文獻：

[1]W.H.Inmon 《Building the Data Warehouse》 John Wiley & Sons，Inc. 1996

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

關鍵詞:校園網絡安全;安全防御機制;蜜罐;蜜網

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

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

1 蜜罐的定義及分類

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

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

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

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

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

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

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

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

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

2 蜜罐的配置模式

1) 誘騙服務(deception service)

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

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

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

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

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

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

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

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

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

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

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

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

4 實驗過程及結果分析

為了驗證該系統(tǒng),虛擬蜜罐宿主機被連接到校園網的物理網絡環(huán)境中,并為其分配一個真實的分配給物理計算機的IP 地址,在這里我們給其分配的IP 地址為192.168.40.7。所有實現(xiàn)虛擬蜜罐系統(tǒng)的軟件都將運行在Linux9.0 操作系統(tǒng)下。圖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)。

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

每個樣本定義了每個模擬的操作系統(tǒng)的性能。“特征(personality)”這就是操作系統(tǒng)在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 端口。應該說,這些服務都是入侵者在相應的操作系統(tǒng)中希望找到的。在樣本中,你可以為端口規(guī)定明確的行為,也可以定義為一般的行為。兩個樣本中將TCP 和UDP 的缺省行為定義為reset,因此在一般情況下,對于TCP 來講將用RST(連接復位)去響應任意的連接企圖,對于UDP,將用ICMP 端口不可達去響應。對于定義為open 行為的端口,對于TCP 將用ACK 響應,而UDP 將什么也不響應。從樣本中可以看出,Windows系統(tǒng)的NetBIOS 端口處于打開狀態(tài);當一個機器與這個蜜罐的80 端口連接時,該蜜罐用IIS 仿真程序perl 腳本與客戶機進行交互;另外Linux 系統(tǒng)的mail 和FTP服務被激活。上面的兩個樣本分別被綁定在不同的IP 地址上。

5 結論

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

參考文獻:

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

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

1.1　典型的研究計劃

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

1.2　相關標準

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

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

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

1.3　國內圖書館數字資源訪問統(tǒng)計的研究和應用

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

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

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

2.1　WEB日志方式

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

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

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

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

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

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

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

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

2.2　資源提供商提供

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

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

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

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

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

2.3　通過網絡proxy

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

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

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

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

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

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

(2)建立數據庫；

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

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

(5)顯示方式的選擇。可以用Windows的表格系統(tǒng)，也可以自行編制表格顯示。

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

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

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

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

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

必須提供的數據元素是：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3　圖書館數字資源的后評估，應該結合多種評估途徑展開

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

4.4　用戶隱私的問題

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

【參考文獻】

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日志方法.計算機應用與軟件.2004(2):105-107

8　梁玉環(huán)，李村合，索紅光.基于JSP的網站訪問統(tǒng)計系統(tǒng)的設計與實現(xiàn).計算機應用研究.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篇：好的日志文章范文

廠商提供給用戶的軟件補丁的形式多為編譯后的庫函數，所以安裝軟件補丁實際上就是把這些庫函數拷貝到相應目錄，并在需要時進行聯(lián)接操作。軟件公司一般在一段時間后會把針對某一版本的所有補丁進行整理：合并融合，解決沖突，進行整體測試，并使文件拷貝和聯(lián)接操作自動執(zhí)行，得到一個軟件補丁“包”。不同的公司使用不同的名稱，現(xiàn)在一般計算機用戶都熟悉的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后新發(fā)現(xiàn)的Bug，其相應補丁當然會收錄到下一個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）。安全補丁用來修復軟件的易受攻擊性(vulnerability)或通常說的安全漏洞。這類問題本來不屬于軟件錯誤，在正常使用中不會出現(xiàn)任何問題。但是別有用心的人可以通過運行非常精巧設計的代碼，繞過數據庫系統(tǒng)的安全管理機制，達到非授權存取的目的。

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

利弊及時機選擇

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

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

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

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

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

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

安裝PSR

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

1. 收集信息

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

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

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

2. 做出判斷

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

3. 制訂實施計劃

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

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

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

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

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

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

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

4. 實施操作

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

5. 檢查操作結果并記錄備案

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

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

下面給出一個在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月。而按照文檔內的提示在metalink中檢索得到的此文檔的最新版本完成日期是2006年4月。使用文件比較工具進行比較，兩個版本沒有實質性差別，只有語句措詞的修改，但是養(yǎng)成總是檢索最新文檔的習慣有益無害。

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

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

1. 檢查數據庫表空間和初始化參數是否需要調整。

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

2. 關閉數據庫，停止listener和agent等進程。

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

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

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

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

4.更新數據庫數據字典

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

$ sqlplus /nolog

SQL> CONNECT / AS SYSDBA

SQL> STARTUP UPGRADE

SQL> SPOOL patch.log

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

執(zhí)行結束后，關閉重定向：

SQL> SPOOL OFF

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

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

SQL> SHUTDOWN

SQL> STARTUP

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

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

$ cd $ORACLE_HOME/install

$ ./ changePerm.sh

個別補丁管理工具opatch

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

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

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

10g(10.1和10.2)版本中，opatch作為一個標準工具，在軟件安裝時自動安裝。（安裝在$ORACLE_HOME/OPatch下。）而對于9.2版，需要從metalink下載opatch。無論數據庫是哪一個版本，系統(tǒng)中是否已經安裝opatch，在使用之前，應從metalink下載最新版本的opatch。很遺憾，由于系統(tǒng)實現(xiàn)的問題，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（卸載個別補?。sinventory（對inventory進行列表）、query（顯示某一個別補丁的詳細信息）、version（顯示opatch版本信息）。在opatch目錄下，有用戶使用指南文件（Users_Guide.txt），其中有詳細的命令格式和使用示例，讀者可以參考。Opatch執(zhí)行操作時，除在屏幕輸出結果外，還生成日志文件。日志文件的路徑和文件名格式如下：

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

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

4. 個別補丁安裝實例

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

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

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

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

$ $ORACLE_HOME/OPatch/opatch apply

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

$ $ORACLE_HOME/OPatch/opatch lsinventory

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

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

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

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

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

$ $ORACLE_HOME/OPatch/opatch lsinventory -detail

安全補丁CPU

一個CPU內包含了對多個安全漏洞的修復，并且也包括相應必需的非安全漏洞的補丁。CPU是累積型的，只要安裝最新的CPU即可，其中包括之前的所有CPU的內容。事實上，在CPU之前的安全漏洞修改除去個別例外也被包括在CPU中。Oracle公司只對處于標準技術支持和延長支持期間的產品提供CPU更新，對處于維持支持范圍的產品不提供新的CPU。（對于9.2以前的版本，只對處于ECS和EMS期間的版本提供CPU更新。）一般對當前補丁發(fā)行版及前一個版本提供CPU，但也有只限于當前補丁發(fā)行版的例外情形。也就是說，一般需要先安裝最新PSR后才可能安裝CPU。由于是累積型的定期，所以對于某一平臺的某一版本，如果兩次CPU期間沒有發(fā)現(xiàn)新的安全漏洞，則新的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，解壓縮到與其它個別補丁相同的目錄下。檢查其發(fā)行說明時，發(fā)現(xiàn)要求opatch版本比現(xiàn)已安裝版本要高，下載安裝指定版本opatch。進入子目錄5225797（這是此安全補丁的補丁號），執(zhí)行apply命令。

$ $ORACLE_HOME/OPatch/opatch apply