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

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

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

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

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

1 概述

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

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

2 Hadoop集群系統概述

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

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

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

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

3 系統的設計與實現

3.1 系統的基本目標

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

3.2 Hadoop部署

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

3.3 日志數據的HDFS存儲

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

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

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

3.4 日志分析過程

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

4 結果分析

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

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

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

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

5 小結

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

參考文獻：

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

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

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

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

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

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

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

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

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

關鍵詞：日志取證；關聯分析；特征關聯；序列關聯

0　引言

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

1　日志關聯分析取證模型

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

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

2　日志取證關鍵部件

2．1　日志收集

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

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

2．2　日志管理

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

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

2．3　日志數據關聯分析策略

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

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

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

(1)數據聚合

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

(2)事件特征關聯

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

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

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

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

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

(3)事件序列關聯

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

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

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

2．4　提交證據

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

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

關鍵詞：EXT4；日志；句柄；i節點

中圖分類號：TP391文獻標識碼：A文章編號：1009-3044(2011)14-3443-04

The Analysis of Linux EXT4 File System

LU Ya-wen

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

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

Key words: EXT4; daily record; handle; inode

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

1 EXT4文件系統的重要數據結構

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

1.1 超級塊super_block

/include/linux/EXT4_fs.h

struct EXT4_super_block {

/*00*/ __le32 s_inodes_count; /* 節點數目 */

__le32 s_blocks_count; /* 文件塊數 */

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

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

/*10*/ __le32 s_free_inodes_count; /* 可用的節點數 */

__le32 s_first_data_block; /* 第一個數據塊的索引 */

__le32 s_log_block_size; /* 數據塊大小 */

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

/*20*/ __le32 s_blocks_per_group; /* 每一組文件塊的數目 */

__le32 s_frags_per_group; /* 每一組碎片數目 */

__le32 s_inodes_per_group; /* # 每一組節點數目 */

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

…………

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

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

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

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

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

1.2 組描述符 Group Descriptor

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

struct EXT4_group_desc

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

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

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

__le16 bg_free_blocks_count; /* 可用的文件塊數 */

__le16 bg_free_inodes_count; /* 可用的節點數 */

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

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

__u32 bg_reserved[3];

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

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

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

1.3i節點數據結構

struct EXT4_inode {

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

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

__le32 i_size; /* 節點字節大小 */

__le32 i_atime; /* 節點存取時間 */

__le32 i_ctime; /* 節點創建時間 */

__le32 i_mtime; /* 節點修改時間 */

__le32 i_dtime; /* 節點時間 */

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

__le16 i_links_count; /* 連接數目 */

__le32 i_blocks; /* I節點文件塊數 */

__le32 i_flags; /* 文件標志 */

union {

struct {

__le32l_i_reserved1;

} linux1;

struct {

__le32h_i_translator;

} hurd1;

struct {

__le32m_i_reserved1;

} masix1;

} osd1; /* OS dependent 1 */

__le32 i_block[EXT4_N_BLOCKS];/* 文件塊索引數組，數組大小15*/

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

__le32 i_file_acl; /* 文件 ACL */

__le32 i_dir_acl; /* 目錄 ACL */

__le32 i_faddr; /* 碎片地址 */

union {

struct {

__le8 l_i_frag; /* 碎片號 */

__le8 l_i_fsize; /* 碎片大小 */

__le16 i_pad1;

__le16 l_i_uid_high; /* I節點用戶id高位 */

__le16 l_i_gid_high; /* I節點組號高位 */

__le32 l_i_reserved2;

} linux2;//1級間接指針數據結構

struct {

__le8 h_i_frag; /* 碎片號 */

__le8 h_i_fsize; /* 碎片大小 */

__le16 h_i_mode_high;

__le16 h_i_uid_high;

__le16 h_i_gid_high;

__le32 h_i_author;

} hurd2; //直接指向物理塊的節點的數據結構的補充

struct {

__le8 m_i_frag; /* 碎片號 */

__le8 m_i_fsize; /* 碎片大小 */

__le16 m_pad1;

__le32 m_i_reserved2[2];

} masix2;//2級間接指針數據結構

} osd2; /* OS dependent 2 */

__le16i_EXTra_isize;

__le16i_pad1;

__le32i_ctime_EXTra;/* 節點擴展的創建時間(nsec

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

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

__le32i_crtime; /* 文件創建時間*/

__le32i_crtime_EXTra;};/* 擴展文件創建時間 (nsec

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

1.4 i節點的擴展信息的數據結構

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

struct EXT4_inode_info {

__le32 i_data[15];

__le32 i_flags; //i節點標志

#ifdef EXT4_FRAGMENTS

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

__le8 i_frag_no;//碎片數目

__le8 i_frag_size;//碎片大小

#endif

__le32 i_file_acl;

__le32 i_dir_acl;

__le32 i_dtime;

__le32 i_block_group;//i節點文件塊組

__le32 i_state; /* EXT3的動態的狀態標志 */

__le32 i_nEXT_alloc_block;

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

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

/*

__le32 i_nEXT_alloc_goal;

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

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

struct inode vfs_inode;

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

};

1.5 句柄handle_t數據結構

此結構是EXT4文件系統用來實現日志式文件操作的有利的數據結構。

struct handle_s

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

int h_buffer_credits;//要被弄臟的緩沖區的數目

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

int h_err;//出錯數

struct list_head h_jcb;// 磁盤操作的頭節點

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

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

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

};

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

各種狀態為：

* RUNNING: 正在進行新的修改

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

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

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

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

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

2 EXT4的文件操作

2.1 EXT的文件操作的數據結構

struct file_operations EXT3_file_operations = {

.llseek = generic_file_llseek,

.read = do_sync_read,

.write = do_sync_write,

.aio_read = generic_file_aio_read,

.aio_write = EXT3_file_write,

.readv = generic_file_readv,

.writev = generic_file_writev,

.ioctl = EXT3_ioctl,

.mmap = generic_file_mmap,

.open = EXT3_open_file,

.release = EXT3_release_file,

.fsync = EXT3_sync_file,

.sendfile = generic_file_sendfile,

};

這個結構體說明了EXT4文件系統的read操作是由do_sync_read函數來實現的，write操作是由do_sync_write函數來實現的，以此類推。只要我們找到相關的函數就能分析EXT4文件系統是怎么實現讀寫操作的。

2.2 EXT4的寫操作

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

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

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

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

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

EXT4_file_write函數的分析如圖2。

3 結束語

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

參考文獻：

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

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

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

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

關鍵詞：AIX；SAP系統；Oracle數據庫；同構；數據遷移

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

1 系統環境描述

目標系統T49已經搭建完畢，使用現有的T49環境來完成PRD的數據遷移。

源系統環境（生產系統）

OS：AIX 5.3

DB：ORACLE 9.2.0.3

SAPSID：PRD

DBSID：PRD

目標系統環境（測試系統）

OS：AIX 5.3

DB：ORACLE 9.2.0.3

SAPSID：T49

DBSID：T49

R/3 Version：4.6C

Kernel：46D_EXT

2 遷移前的準備工作

2.1 備份PRD數據庫控制文件

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

sqlplus/nolog

connect/as sysdba

alter database backup controlfile to trace resetlogs

生成的文件名及路徑為：

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

2.2 創建NFS

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

2.3 分別停止源系統及目標系統的SAP服務，并確認SAP和ORACLE進程已停止

2.4 在目標系統T49上所作的準備工作（很重要：請注意是目標系統T49，切勿搞錯！）

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

#cd /oracle/T49/saparch

#rm *.dbf

#cd /oracle/T49/saparch/cntrl

#rm cntrlT49.dbf

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

#cd /oracle/T49

#rm-rf sapdata1

……

#rm-rf sapdata6

#rm-rf mirrlogA

……

#rm-rf origlogB

3 開始遷移

從源主機PRD拷貝數據文件日志文件到目標主機T49

（1）用oracle用戶拷貝源主機PRD上的sapdata1-sapdata6（6個目錄）到T49上

在目標主機T49上：

用root用戶在根目錄下mount，

#cd

#mount/rmtt49

#su–orat49（用orat49用戶）

#cd/rmtt49

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

……

#cp-Rp sapdata6/oracle/T49&

查看后臺拷貝進程

ps–ef|grep cp

（2）從源主機PRD上把mirrlogA、mirrlogB、origlogA、origlogB拷貝到目標主機T49上

#cd/rmtt49

#cp–Rp mirrlogA/oracle/T49

……

#cp–Rp origlogB/oracle/T49

（3）傳輸并修改生成的controlfile

在/oracle/PRD下面

cd/oracle/PRD/saptrace/usertrace

用ftp工具把PRD_ora_xxxxx.trc文件傳至目標系統

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

把所有PRD改為T49

把REUSE改為SET

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

“CHARACTER SET WE8DEC

；”

以后的內容全部刪除，然后存盤。

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

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

#chmod 777 db.sql

（2）啟動oracle數據庫，執行db.sql文件

#su–orat49

#sqlplus/nolog

SQL>connect /as sysdba；

SQL>startup nomount；

SQL>@db.sql；

SQL>recover database using backup controlfile；（執行這條命令會提示要求輸入一個文件名稱，這個文件是在T49上的/oracle/T49/origlogA或/oracle/T49/origlogB中的八個文件之一：log_g11m1.dbf---log_g18m1.dbf的其中一個

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

SQL>alter database open resetlogs；

SQL>commit；

SQL>shutdown

（3）檢查目標主機T49的oracle數據庫能否正常啟動關閉

SQL>startup

初始化sapr3的密碼和創建OPS$t49adm用戶。

System需密碼初始化

SQL>Alter user system identified by manager；

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

（4）啟動目標主機T49上的sap

切換到sap用戶

#su–t49adm

啟動sap

#./startsap

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

#ps-ef|grep ora

#ps-ef|grep sap

（5）在目標主機T49上，先刪除舊的license，安裝新的license

#su–t49adm

#saplicense–get

#saplicense–show

#saplicense–delete

#saplicense–install

5 結束語

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

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

關鍵詞：數據挖掘;日志分析;聚類挖掘

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

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

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

用戶名 用戶組

user253 104

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

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

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

包含了用戶的IP、用戶名、訪問時間、訪問網站的地址、返回類型、請求的字節數等內容。

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

2數據準備

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

2.1數據預處理

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

2.2數據清洗

(1)去除user表中不合法的數據。對user表進行分組，得出研究生組的記錄有299條，本科生組有731條，教職工組有569條，辦公用戶組有89條，4組共1688條，與總記錄數有出入。可知其中存在不合法數據，使用SQL語句去除。

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

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

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

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

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

GROUP BY uno

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

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

(6) 按用戶分組統計資源的占用情況。分析帶寬的占用情況本來應該以秒為單位分別統計用戶流量，求均值后再排名，但這樣過于復雜。在這可以換一個思路，按用戶號統計流量，排序靠前流量越高的，占用的帶寬也較高。可使用如下命令得到帶寬占用的排名：

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

GROUP BY uno

ORDER BY SUM(byte) DESC

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

3數據挖掘

利用SQL Sever 2005的SSAS組件對上網用戶進行聚類挖掘。將2.3中生成的uno_ugroup表加到其數據源中，在挖掘結構中新建聚類挖掘模型，設置如圖2所示：

圖2聚類挖掘模型設置

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

圖3分類剖面圖

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

圖4分類特征

4結果分析與表述

通過數據準備和挖掘，可以得出本校網絡用戶的上網情況如下：

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

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

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

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

網絡管理員可以根據以上情況對訪問網絡的行為為進行相應的管理與限制，如對視頻下載操作進行合適的限定，對上網時間較長的用戶加以關注，提醒同學合理安排時間等。

5結束語

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

數據預處理

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

服務器訪問日志的預處理

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

構建數據挖掘庫

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

數據挖掘

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

關聯規則發現

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

聚類

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

序列模式

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

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

參考文獻：

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

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

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

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

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

1 蜜罐的定義及分類

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

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

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

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

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

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

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

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

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

2 蜜罐的配置模式

1) 誘騙服務(deception service)

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

2) 弱化系統(weakened system)

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

3) 強化系統(hardened system)

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

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

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

3 蜜罐Honeypot 的在校園網中的實現

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

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

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

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

4 實驗過程及結果分析

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

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

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

5 結論

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

參考文獻:

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

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

1.1　典型的研究計劃

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

1.2　相關標準

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

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

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

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

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

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

2　圖書館數字資源訪問統計的方式

2.1　WEB日志方式

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

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

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

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

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

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

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

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

2.2　資源提供商提供

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

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

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

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

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

2.3　通過網絡proxy

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

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

2.4　利用腳本語言自行開發

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

主要分以下幾個開發步驟：

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

(2)建立數據庫；

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

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

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

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

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

3　圖書館數字資源訪問統計的指標

3.1　國際圖書館聯盟的統計指標指南

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

必須提供的數據元素是：

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

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

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

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

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

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

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

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

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

3.2　E-Metrics推薦的統計指標

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

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

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

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

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

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

3.3　我國圖書館常用的數字資源訪問統計指標

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

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

4　圖書館數字資源訪問統計存在的問題

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

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

4.2　缺乏標準的統計指標

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

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

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

4.4　用戶隱私的問題

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

【參考文獻】

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

2　projectcounter.org/index.html

3　equinox.dcu.ie/

4　niso.org/emetrics/index.cfm

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

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

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

8　梁玉環，李村合，索紅光.基于JSP的網站訪問統計系統的設計與實現.計算機應用研究.2004(4):166-167

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

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

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

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

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

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

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

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

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

利弊及時機選擇

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

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

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

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

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

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

安裝PSR

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

1. 收集信息

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

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

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

2. 做出判斷

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

3. 制訂實施計劃

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

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

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

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

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

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

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

4. 實施操作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.更新數據庫數據字典

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

$ sqlplus /nolog

SQL> CONNECT / AS SYSDBA

SQL> STARTUP UPGRADE

SQL> SPOOL patch.log

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

執行結束后，關閉重定向：

SQL> SPOOL OFF

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

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

SQL> SHUTDOWN

SQL> STARTUP

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

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

$ cd $ORACLE_HOME/install

$ ./ changePerm.sh

個別補丁管理工具opatch

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

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

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

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

opatch是使用perl編寫的腳本程序（其中也使用JAVA API）。編程使用的perl版本是5.6版，雖然在5.6之前的版本中也可運行，但應盡可能安裝5.6或以上的版本的perl。對于DBA來說一個好消息是，如果安裝9.2版軟件時保留了HTTP服務器，則在$ORACLE_HOME/Apache下會自動安裝perl。（10g會自動安裝配置perl和opatch。）

opatch命令格式為：

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

命令有：apply（安裝個別補丁）、rollback（卸載個別補丁）、lsinventory（對inventory進行列表）、query（顯示某一個別補丁的詳細信息）、version（顯示opatch版本信息）。在opatch目錄下，有用戶使用指南文件（Users_Guide.txt），其中有詳細的命令格式和使用示例，讀者可以參考。Opatch執行操作時，除在屏幕輸出結果外，還生成日志文件。日志文件的路徑和文件名格式如下：

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

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

4. 個別補丁安裝實例

沿用安裝PSR實例中的環境。在安裝PSR10.1.0.5后，檢索metalink，發現若干在其之上的個別補丁。選擇其中之一安裝。

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

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

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

$ $ORACLE_HOME/OPatch/opatch apply

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

$ $ORACLE_HOME/OPatch/opatch lsinventory

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

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

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

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

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

$ $ORACLE_HOME/OPatch/opatch lsinventory -detail

安全補丁CPU

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

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

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

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

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

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

$ $ORACLE_HOME/OPatch/opatch apply