數據庫系統

前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇數據庫系統范文，相信會為您的寫作帶來幫助，發現更多的寫作思路和靈感。

數據庫系統范文第1篇

關鍵詞： 民航氣象數據庫系統；飛行安全；氣象資料入庫；維護

民航氣象數據庫系統是一個24小時連續運行的、規模龐大的實時聯機氣象信息系統。它是由北京等幾大氣象中心以及若干個空管中心、站氣象數據庫系統組成的分布式數據庫系統。它集數據上傳、分發、監控、共享等于一體，對民航氣象所需資料進行整理和分析，在保障航空飛行安全上有著極為重要的地位和作用。在民航氣象數據庫系統中，氣象資料入庫是尤為關鍵的一步，所有數據經過傳輸后最終都要分類進入各級數據庫中，資料共享亦須通過數據庫提取。本文主要針對“站”一級別的氣象資料入庫進行分析和討論。

本站所屬的氣象數據庫系統由通信機、數據庫分系統DB00、DB01及若干網絡通信設備組成。“氣象資料入庫”指的是氣象資料（報文、產品）在通過上級轉發到本地通信機后，進入數據庫分系統DB00和DB01并存儲的過程。在此存儲過程中，通信機和DB00、DB01之間通過MQ或FTP的方式傳遞氣象信息，其中MQ為主要傳輸方式。

針對氣象數據庫資料無法入庫，通常按照如下步驟進行分析和排查：

1 MQ傳輸問題

由于MQ的通訊是建立在系統網絡運行正常的基礎之上的，為保障其順利運行，首先要檢查網絡連接是否正常。可以使用ping命令，也可以采用FTP方式，在兩個主機之間嘗試進行數據傳輸，以判斷網絡是否正常；使用tracert命令對網絡通信節點進行逐級排查。其次，檢查隊列、通道的運行狀態。

1）查看MQ隊列管理器狀態：dspmq，正常狀態應顯示：Running；啟動方法為：strmqm。

2）查看通道狀態：showchl，正常狀態應顯示：Running；

2.4 磁盤空間使用率過高影響進程啟動

定時檢查DB00、DB01中/home磁盤空間使用率，如使用率超過70%，易導致重要進程如awos、cac等無法啟動?？梢允褂胐fm命令查看磁盤空間使用率，當/home使用率超過70%時，移除/home/mhdbs/data/backup文件夾中的歸檔文件；如發現awos、cac等進程在經上述處理后仍無法啟動，/home/mhmdbs/

Data下的awos、cac等文件夾中有大量資料積壓（正常情況下為空），說明資料積壓時間過長，超過系統進程判斷讀取時間，需將其手工轉移到/home/mhdbs/trash下相應的目錄中，再嘗試啟動相應進程。

3 操作系統時間問題

在氣象數據庫系統對資料的接收入庫操作中，如報文、產品的產生時間與本地系統接收時間基本一致，則判斷資料有效，準許其入庫并分門別類；如不一致，則判斷資料無效，并做丟棄處理。氣象數據庫系統以世界時UTC為標準，為避免氣象資料因時間錯誤而無法入庫，可以使用date命令對系統定時進行手動對時，但這需要維護人員定期對氣象數據庫系統時間進行檢查和操作。為了保證安全生產，提高維護效率，可在氣象數據庫系統中添加GPS自動校時功能。

可以采用一臺PC做GPS服務器與GPS時鐘時間同步，氣象數據庫系統作為客戶端與GPS服務器時間同步。因為通信機安裝的是LINUX系統，數據庫安裝的是AIX系統，因此有不同的客戶端搭建方式（關于GPS服務器在此暫不贅述）。

3.1 通信機系統

4 系統其他配置文件問題

針對大部分氣象資料入庫正常，而僅有某類資料無法入庫的情況，可以從存儲于通信機中的控制數據BSB（公報說明塊）中查找原因。

控制數據BSB用于決定氣象公報的處理原則，需要通過extract_bsb命令對其進行提取，使用vi命令編輯完成后，再用make_bsb命令對其進行編譯使用。在BSB中，參數channel_X

（X為1、2……）對應的線路號指明了轉發地址。當轉發地址不正確或者不完全時，會導致氣象資料因地址缺失而無法正常轉發或入庫。

線路號存儲于通信系統軟件的環境參數文件mssini.ini中，用ldt命令可以進行查看與對照。線路號與轉發地址一一對應，在進行配置文件檢查時，先查明此類氣象資料需轉發到哪些地方（如機場、本地數據庫等），再用ldt命令查看與轉發地址相對應的線路號，然后查看BSB中是否寫有所需的線路號，如有缺失，需用vi命令編輯補齊，各個線路號之間用“空格”分開。

參考文獻：

[1]劉竹濤，《科技風》，河北省科學技術協會，2009.17.

數據庫系統范文第2篇

關鍵詞:異構多數據庫;集成技術;模式消解;查詢處理;事務處理

中圖分類號:TP3文獻標識碼:A文章編號:1009-3044(2010)08-1795-02

Explore the Integration of Heterogeneous Multi-database System Technology

CHEN Fei

Abstract: Heterogeneous Multi-Database Integration System is a database research in the field hot and difficult issues. This article first integration of heterogeneous multi-database system design, and to further explore the implementation of the system integration technology, involving digestion pattern, query processing technology, and transaction processing technology.

Key words: Heterogeneous multi-database; integration technology; model digestion; query processing; transaction processing

異構多數據庫系統是指多個相關的數據庫系統的集合,可以實現數據的共享和透明訪問,每個數據庫系統在加入異構數據庫系統之前本身已經存在,并擁有自己的DBMS。異構多數據庫系統的集成目標在于實現不同數據庫之間的數據信息資源共享。它的成因也多種多樣,一般是在對舊系統進行擴建時比較常見。本文將重點探討異構多數據庫系統的集成技術。

1 異構多數據庫系統的集成設計

1.1 異構多數據庫的體系結構

異構MDBS的體系結構如圖1所示。

異構MDBS本身是一種Client/Server結構,多個異構MDBS的Client與MDBS交互作用,用戶可以通過異構MDBS對多個LDB進行存取操作。異構MDBS管理所有全局數據庫的控制信息,包括全局模式、全局事務的提交和控制等。每一個LDB通過一個驅動器(Driver)與MDBS連接,這個驅動器與LDB在一個站點上,異構MDBS與驅動器之間的通信構成一個通信子層CSS(Communication Subsystem)[1]。從異構MDBS的體系結構可以看出,異構MDBS對LDB沒有做任何改動,因此LDB上的用戶還可以對LDB進行直接訪問,LDB上原來的應用程序還可以直接運行于LDB之上。

1.2 集成設計的關鍵技術

建立異構多數據庫系統的集成時經常遇到的一項十分棘手的工作便是整合用戶原有的一些應用系統,而這些舊的應用系統往往是建立在異構的數據庫基礎之上。

首先,為給用戶提供一個統一的存取模式,在異構MDBS中只保留一個供用戶查詢及修改的全局數據模式,而這個全局模式是由各個異構的LDB數據模式通過模式消解得到的,這就是異構多數據庫系統集成中的模式消解技術。

其次,在異構MDBS中采用統一的全局查詢語言,因此需要把全局查詢語言分解和轉換為相應的LDB查詢語言交于LDB執行,然后合并各LDB查詢結果以產生最終的用戶查詢結果,這就是異構多數據庫系統集成中的查詢處理技術。

另外,由于異構MDBS中的事務是被分解為多個子任務,并由各LDB分別執行相應子任務來完成的,因此在異構MDBS中,存在著如何保持全局事務的可串行化執行、全局事務的原子性及各個LDB之間的數據一致性等問題,即異構多數據庫系統集成的事務管理技術[2]。

2 異構多數據庫系統的集成實現

2.1 模式消解技術

模式消解的目的是將一組不同的LDB模式轉換成一個統一的全局模式,通過對一組模式施行一組函數來實現的。其中每一個函數將一種LDB模式轉換成統一的模式。

消解可以通過重命名實體和屬性的方法來實現,該方法所解決的是實體命名和屬性命名的沖突,即在不同的LDB中,相同的概念有不同名稱或不同概念有相同名稱時出現的沖突。該方法是在異構MDBS中建立一個MDBS與LDB之間名稱對應關系的目錄。也可以通過一致化表示和屬性一致化來實現, 一個實體是由一系列屬性組成的,類似地,虛類也是由一系列屬性組成的,它的成員查詢部分決定了一個虛類的實現方法,每一個成員查詢對應一個LDB中的實體與異構MDBS中虛類的對應關系。因此每一個LDB中實體的屬性都要轉換成異構MDBS中相應的虛類的屬性。

2.2 查詢處理技術

異構MDBS中的查詢處理主要包括查詢分解、查詢轉換。在異構MDBS中,用戶可以根據全局模式用全局查詢語言對多個LDB同時進行查詢。一個全局查詢一般要經過三步處理:

1) 把全局查詢分解成多個子查詢,每一個子查詢對應一個LDB中的數據,分解后的子查詢仍用全局查詢語言表示的。

2) 每一個子查詢都轉換成相應的LDB的本地查詢語言并遞交到相應LDB中執行。

3) 子查詢的結果返回并組合成最終的查詢結果。

通過查詢分解以后,每個子查詢只對應一個LDB,但子查詢的查詢語言還是全局查詢語言。如果全局查詢語言和LDB的本地查詢語言不同,還要通過查詢轉換把全局查詢語言轉換成本地查詢語言。查詢轉換不僅要考慮轉換的正確性,還要考慮轉換的可行性。有些全局查詢語句可能無法轉換成相應的目標查詢語句(例如目標語言中無此相應的功能),則需要LDB傳回與此查詢相關的數據,在后處理中由異構MDBS完成查詢功能。因此在查詢轉換中還需要一個過濾器,由它檢查和識別那些不能在LDB中執行的查詢語句。

不同的查詢分解對應不同的系統性能,為達到優化系統性能的目的,還需要全局優化器和本地優化器。一個全局查詢的開銷是各個LDB查詢的開銷加上后處理的開銷再加通信開銷。

2.3 事務處理技術

一個MDBS是建立在多個分布異構多數據庫之上的,它為用戶提供一個統一的存取數據的接口,其中的每一個LDB都是自治的,由一個本地的DBMS來管理,它的局部事務不為MDBS所知,因此在MDBS中保持事務的一致性和原子性是非常困難的。

由于LDB上的局部事務不受GTM的控制,所以GTM只能控制全局事務的執行順序。但在某些情況下,即使全局事務嚴格串行執行也不能保證全局的可串行化,如下例:

設有兩個站點Sl、S2,Sl上有數據a和b,S2上有數據c和d。T1和T2是兩個只讀的全局事務:

T1:r1(a)r1(c)

T2:r2(b)r2(d)

另外還有T3、T4分別為S1、S2上的局部事務:

T3:w3(a)w3(c)

T4:w3(b)w3(d)

雖然已經嚴格保證了全局事務Tl、T2的順序執行,但是從執行結果上來看卻是這樣的:Sl上的執行順序為T1、T3、T2,而S2是執行順序為T2、T4、T1,在這種情況下,全局事務的可串行性沒有得到保證。上面的主要問題在于局部事務與全局事務發生了沖突,但是由于GTM不知道局部事務的執行情況,因此也無法發現這種沖突,這是異構MDBS中控制全局事務可串行化執行所面臨的主要問題。

為了避免出現上面的情況,可以采用不允許無沖突的事務(如T1、T2)在相同的站點上執行的方法。主要思想是GTM在每一個站點上只運行相互之間有沖突的事務,如果兩個要在同一個站點上執行的事務之間沒有沖突,則GTM對它們進行修改使之產生沖突。一種可行的方法是在每一個站點上設一個特殊的數據,稱之為令牌,使無沖突的兩個全局事務在令牌上發生沖突。每個LDB上只有一個令牌,不同的LDB上的令牌不同,只有全局事務才可以存取令牌。每一個站點上執行的事務都要執行讀令牌和寫令牌操作,這個令牌數據的讀寫操作保證了全局事務的可串行化執行。

3 結束語

總之,基于單一數據庫產品開發的系統已經難以適應新應用的需要,許多應用不可避免地涉及多個不同異構數據庫系統,需要聯合使用。對于用戶而言,面對所有這些復雜的分布異構特性,他們希望屏蔽掉各種層次的異構特性,他們不必知道各物理數據庫系統的分布及數據庫的結構組成和操作方法,也不必自己去進行數據轉換和結果匯總,只需通過簡便的全局訪問方法得到一個綜合結果,這就是異構多數據庫集成技術的主要研究內容,也是其意義所在。

參考文獻:

數據庫系統范文第3篇

關鍵詞：數據庫；數據庫系統；分布式；分布式數據庫；安全

中圖分類號：TP311.133.1文獻標志號：A 文章編號：1009-3044(2009)04-0769-02

Analysis of Security Strategy on DDBS

JIANG Wen-bin, ZHANG Ren-jin, ZHANG Fang-xia

(Guizhou Normal University Mathematic and Computer Institue, Guizhou Normal University the multi-media Computer Assisted Instruction Institue, Guiyang 550001, China)

Abstract: As the combination of computer network and database system Distributed Database is becoming the share center of information resource in the Internet situation and its security is very important. Aiming at the secure requests of Distributed Database System, on the base of analysing system frame and possible attacking. It discusses user authentication, secret communication, access control, content ciphertext, cryptosystem, key and distributed affair management, audit track, fault repair in the security police and security mechanism.

Key words: database; database system; distributed; distributed database system; security

Internet的高速發展推動著分布式數據庫的發展，另一方面它也增加了分布式數據庫安全問題的復雜性。如何保證開放網絡環境中分布式數據庫系統的安全是一個復雜的問題，需要進行認真分析研究。分布式數據庫面臨著兩大類安全問題：一類安全問題研究抗擊單站點故障、網絡故障等自然因素故障，即研究在發生了障時如何使系統仍能可靠運行或從故障中恢復。另一類安全問題研究抗擊來自于本機或網絡上的人為攻擊，即研究在有黑客攻擊時如何保證庫存數據和通信報文的保密性和可靠性。數據庫最突出的特點是之一是數據共享，數據共享給數據庫應用帶來了眾多的好處；但給數據庫特別是網絡化的開放環境與基于網絡的分布式數據庫系統的安全帶來了嚴重的問題，如何保證分布式數據庫的安全問題己經成為數據庫領域的重要課題之一。

1 分布式數據庫構建與應用概述

1.1 分布式數據庫的定義和特點

分布式數據庫系統是由若干個站集合而成，這些站（節點）在通訊網絡中互聯在一起，每個站都擁有各自的數據庫、中央處理機，以及各自的局部數據庫管理系統，因此分布式數據庫系統可看作是一系列集中式數據庫系統的聯合。它們在邏輯上屬于同一系統，但在物理結構上是分散的。分布式數據庫系統使用計算機網絡，將地理位置分散，而管理又需要不同程度集中的多個邏輯單位（通常是集中式數據庫系統）聯接起來，共同組成一個統一的數據庫系統，因此分布式數據庫系統可以看成是：計算機網絡與數據庫系統的有機結合。它應該具有如下的特點：

1) 物理分布性：分布式數據庫系統中的數據不是存儲在一個站點上，而是分散存儲在由計算機網絡聯結起來的多個站點上。所以分布式數據庫系統的數據具有物理分布性，這是與集中式數據庫系統的最大差別之一。

2) 邏輯整體性：分布式數據庫系統中的數據物理上是分散在各個站點中，但這些分散的數據邏輯上卻是一個整體，它們被分布式數據庫系統的所有用戶(全局用戶)共享，并由一個分布式數據庫管理系統統一管理。這是分布式數據庫的“邏輯整體性”特點，也是與分散式數據庫的最大區別。區別一個數據庫系統是分散式還是分布式，只要判斷該數據庫系統是否支持全局應用（數據在邏輯

上統一管理，在物理上分散存儲）。因此，分布式數據庫系統中就有了全局數據庫(GDB-Global Database)和局部數據庫(LDB-Local Database)的概念。全局數據庫由全局數據庫管理系統進行管理，所謂全局是從整個系統角度出發研究問題。局部數據庫由局部數據庫管理系統進行管理，所謂局部是從各個站點的角度出發研究問題。

3)站點自治性：站點自治性也稱場地自治性，各站點上的數據由本地的DBMS管理，具有自治處理能力，完成本站點的應用(局部應用)，這是分布式數據庫系統與多處理機系統的區別。

1.2 體系結構圖

圖1為體系結構圖。

1.3 分布式數據庫運行過程

用戶欲訪問分布式數據庫系統，首先要由任意一個站點登錄，進行身份驗證，系統確認用戶的合法身份后接受用戶提出的事務處理請求，并把用戶事務經用戶接口轉換后由編譯層進行語法、語義分析、授權檢查、事務分解等操作，而后交事務管理層監督執行。分解得到的訪問本地數據的子事務，由本地數據庫管理系統具體執行，訪問遠程數據的子事務，則通過通訊系統交給遠程的事務管理層，由遠程事務管理層監督遠程數據庫管理系統具體執行。子事務的分解和異步執行過程對用戶是透明的。這樣通過分布式數據庫系統把物理上分布的數據在邏輯上統一起來了。

2 分布式數據庫系統的主要安全隱患

在一個支持場地自治性的分布式數據庫系統中，數據的安全性可完全由局部數據庫系統負責。但是，一旦遠程場地用戶被授權訪問局部數據，則局部場地就不能確保數據的完整性。因為數據可能被拷貝到網絡中的其它場地上而超出原有數據庫系統的控制范圍。因此，需要考慮接收場地安全性保護和網絡的安全性。為了保證數據在分布環境下的安全性，不應該在非安全的通訊線路上傳遞保密數據，也不允許將保密數據傳遞給不安全的場地。

對于分布式數據庫安全問題擴展地來說，應該保障數據庫數據的完整性，包括數據的物理完整性、邏輯完整性和元素完整性；保障數據庫數據的保密性：身份鑒別、推理防范、數據庫系統的可審計性等；保障數據庫數據的可靠性，就是防止和減少因為軟、硬件系統的錯誤所造成的數據庫惡性破壞，和及時修復軟、硬件系統的錯誤所造成的數據庫惡性破壞。對于第一類由單站點故障、網絡故障等自然因素引起，這類故障通?？衫镁W絡提供的安全性來實現安全防護，所以說網絡安全是分布式數據庫安全的基礎；對于另一類來自本機或網絡上的人為攻擊，主要有：

1) 黑客的攻擊：為了竊取數據或擾亂系統正常運行，黑客對分布式數據庫系統主要采取以下攻擊方式：

竊聽：黑客在網絡信道上監聽客戶-數據庫服務器或服務器-服務器之間的報文來竊取數據。

重發攻擊：黑客把竊聽到的報文又重發給客戶或服務器，重發的報文或保持原樣或做了修改，以擾亂系統正常運行甚至修改數據庫中數據。重發攻擊可以是針對站點間的數據通信過程，也可以是針對站點間的身份驗證過程。

假冒攻擊：黑客可以發送報文使客戶或服務器通訊端口堵塞，然后再假冒該客戶或服務器擾亂分布式數據庫系統內其它站點的正常運行甚至非法訪問數據。

越權攻擊：黑客本身是分布式數據庫系統的合法用戶，但他利用訪問控制方面的安全漏洞越權訪問非授權數據。

迂回攻擊：黑客利用網絡協議、操作系統的安全漏洞繞過分布式數據庫系統直接訪問數據庫文件。在上述各種過程中，為了實施更有效的攻擊，黑客往往還借助于破譯工具，采用密碼分析方法對得到的密文進行解密或纂攻。

2) 計算機病毒的攻擊：病毒的種類迅速增加，病毒的機制越來越復雜化，破壞性和攻擊性越來越強。

3) 網絡安全環境的脆弱性：包括操作系統安全的脆弱性，數據庫管理系統安全的脆弱性，網絡協議的脆弱性等。

4) 數據庫應用系統的不安全性：包括非法用戶使用應用系統存取數據，授權用戶超越權限訪問存取非授權信息等等。

3 解決分布式數據庫安全問題的關健技術

如何保證開放網絡環境中分布式數據庫系統的安全是一個非常復雜的問題，需要進行認真分析研究。針對上述開放式網絡環境下分布式數據庫系統的安全隱患，總結解決這些問題的身份驗證、保密通信、訪問控制和審計、庫文加密、密碼體制與密鑰管理、分布事務管理和故障恢復等關鍵技術。

3.1 身份驗證

為了防止各種假冒攻擊，在執行真正的數據訪問操作前，要在客戶和數據庫服務器之間進行雙向身份驗證：用戶登錄進人分布式數據庫系統，進行數據訪問操作前要進行身份驗證，以便確認該用戶的真實身份，從而進一步決定該用戶的訪問權限；此外，由于分布式數據庫系統服務器與服務器之間要完成傳輸數據、協調分布式事務處理等功能，因此它們之間也要相互驗證身份。

3.2 在通訊雙方之間建立保密信道

保密通信客戶一服務器、服務器一服務器之間身份驗證成功后，就可以進行數據傳輸了，為了對抗報文竊聽和報文重發攻擊，需要在通訊雙方之間建立保密信道，對數據進行加密傳輸。在分布式數據庫系統中，由于傳輸的數據量往往很大，加解密算法的速度對系統性能影響也就大，而非對稱密碼體制運算復雜、速度慢，對稱密碼體制速度快，所以一般采用對稱密碼算法來進行加解密。因此，建立保度信道的過程就是約定會話密鑰，用會話密鑰來加解密數據的過程。通常這一過程也可以和身份驗證結合在一起。

3.3 訪問控制和審計

在通常的數據庫管理系統中，為了抗擊越權攻擊，任何用戶不能直接操作庫存數據。用戶的數據訪問請求先要送訪問控制模塊審查，然后系統的訪問控制模塊有訪間權限的用戶去完成相應的數據操作。訪問控制主要有兩種形式：自主訪問授權控制和強制訪問授權控制。其中自主訪問授權控制由管理員設置訪問控制表，此表規定用戶對數據對象能夠進行的操作或不能進行的操作;而強制訪問授權控制先給系統內的用戶和數據對象分別授予安全級別，根據用戶、數據對象之間的安全級別關系限定用戶的操作權限。

3.4 庫文加密

在分布式數據庫系統中，為了對抗黑客利用網絡協議、操作系統安全漏洞繞過數據庫的安全機制而直接訪問數據庫文件，有必要對庫文進行加密。只要保管好密鑰，并且加密算法具有一定的強度，即使黑客得到了數據庫文件，他們也難以知道明文，這樣使得重要數據受系統安全漏洞因素的威脅減小。

3.5 密碼體制與密鑰管理

在分布式數據庫系統中，身份驗證、保密信道、庫文加密等都用到加解密算法，但是它們的應用背景是有區別的：身份驗證僅需傳輸少量控制信息；保密通信除了傳遞少量控制信息外，通常還傳遞大量的數據信息；庫文加密涉及不同粒度的數據對象，而且還要考慮數據庫的插人、刪除、更改數據密鑰等操作。

3.6 全局視圖機制

和集中式數據庫一樣，分布式數據庫環境中同樣可定義視圖，實現數據的獨立和安全性，這是，視圖的作用更加顯著，因為分布式數據庫非常大而且復雜，用戶數目也非常大。利用視圖，可以將用戶分組，只向用戶提有關數據。

3.7 安全審核

檢測是否有人的最佳方式是建立恰當的警報系統。如SQL SERVER2000建立的警報系統方法是通過啟用“FAlLED LOGIN(失敗的登錄)” 選項 (“選SERVER PROPERTIES [服務器屬性]”l“SECURITY(安全)”選項卡)，你就可以看到何時有不受歡迎的訪問者正在濃度訪問你的系統。當有一個僅使用幾個賬戶的封裝CM應用程序時，這特別有用。

3.8 分布事務管理

在分布式數據庫系統中，分布事務管理的目的在于保證事務的正確執行及執行結果有性主要解決系統可靠性、事務并發控制及系統資源的有效利用等問題。分布事務首先要分解為多個子事務到各個站點上去執行，各個服務器之間還必須采取合理的算法進行分布式并發控制和提交，以保證事務的完整性。

3.9 故障恢復

在數據庫系統中盡管采取了很多措施和手段保證數據庫系統的正常運行，然而計算機系統中的軟、硬件的故障及操作的失誤和人為的破壞仍是不可避免的，這經常造成數據庫不能正常的執行，出現錯誤，數據的全部或部分遭到破壞。因此數據庫系統必須具有把數據庫系統從故障狀態恢復到一個已知的正確狀態。分布式事務的兩段提交協議(2PC協議)是一種用于故障恢復的方法，在系統運行日志無丟失的情況下，對任何故障均有一定的恢復能力。

4 結束語

從分布式數據庫安全的研究來看，目前存在幾種方向，一是從一般數據庫安全理論出發，將其理論放在分布式數據庫的具體環境下進行考察,然后進行修正；二是從數據庫安全的焦點問題入手，主要研究分布式數據庫中這些問題的實現，三是著重分析分布式數據庫的安全風險而缺乏對具體實施的關注。這些研究思路同分布式數據庫安全需求的滿足還存在一定的距離，這方面的工作還有待進一步的研究。

參考文獻：

[1] 邵佩英.分布式數據庫系統及其應用[M].北京:科學出版社,2005.

[2] 鞠海玲,寧洪,鄭若忠,等.分布式數據庫安全關鍵技術[J].微型電腦應用,1999,15(9):6-8.

[3] 鞠海玲,寧洪,鄭若忠,等.分布式數據庫安全機制[J].計算機工程與應用,2000,36(3):98-100.

[4] 鄭振媚,于戈,郭敏.分布式數據庫[M].北京:科學出版社,l999.

[5] 吳江,李太勇,吳曉知.分布式數據庫系統中的安全策略研究[J].網絡安全技術與運用,2006,2(4):98-102.

[6] Brink Knight.SQL Server 2000 for Experienced DBAS[M].北京:清華大學出版社,2003.

數據庫系統范文第4篇

【關鍵詞】 民航氣象 數據庫

一、引言

呼倫貝爾機場民航氣象數據庫系統，主要由數據庫服務器、WEB應用服務器、通信服務器、預報平臺工作站，監控終端等組成，軟件主要有AIX操作系統、LINUX操作系統、ORACLE數據庫、MQ通信中間件等。該系統自2008年5月運行，設備運行穩定可靠，系統故障較少。但在實際使用過程中，也出現過無法進行數據交換的故障，下面筆者對以下兩例故障進行分析。

二、常見故障及維修

2.1網絡傳輸設備故障

故障現象：2013年11月7日，值班人員發現數據庫中資料不能及時更新，中心交換服務器有大量消息積壓且通道章臺顯示為Running，MQ消息傳輸延時較長。

故障分析及處理過程：值班機務員仔細查看交換機、路由器、基帶貓工作指示燈顯示正常，使用ping命令測試到民航華北氣象中心的傳輸鏈路通信質量，發現ICMP丟失現象比較頻繁。檢查DB00、DB01服務器傳輸正常。聯系氣象中心確認對方交換服務器運行正常，可以排除對方數據庫故障的情況。聯系本單位技術保障部們=門檢查更換傳輸線路，確認本地線路正常。聯系網絡公司確認北京至本地的數據傳輸正常，這樣可以排除北京至本地網絡線路故障的可能性。聯系北京網控中心臨時更換ATM傳輸端口，確認ATM網絡數據傳輸正常。這樣故障點初步判斷在路由器、交換機、基帶貓三個方面，通過監控終端ping通信機、及服務器不存在丟包現象，所以交換機可以排除。更換備用路由器，故障依舊。所以初步判斷故障點應該在基帶貓，由于基帶貓沒有備件，拆開基帶貓后，檢查Modem電源模塊輸出電壓不穩，經過搶修以后更換電源模塊，數據鏈路恢復正常，丟包現象消失，MQ消息傳輸正常。

2.2通信機故障

故障現象：2015年7月12日，14：50分左右，值班機務員發現通過CMTS客戶端發現無法清除AB報，ping北京服務器及本地服務器均正常；使用telnet命令無法登陸通信機。在19：30左右，再次出現以上情況，重啟恢復；在24：00左右再次出現以上情況。

故障分析及處理過程：根據以往處理經驗，由于硬盤滿，無法提供存儲空間及程序運行空間，易出現類似情況， 重啟通信機后，設備恢復，通過查看硬盤空間，硬盤空間充足。

通過查看通信機目錄，在comm/receive/caac 目錄下面一個未處理的氣象預報文件； 刪除該未處理的文件，未發生通信機死機情況，判斷通信機死機與該未處理的文件有關；太極公司技術人員聯系，得到證實，由于文件處理后，程序未刪除掉，會再次調用程序處理，這樣重復處理，后逐漸占用更大的內存空間，直至內存沾滿，每次死機間隔時間在4小時左右，也大概消耗與機器的內存量相符 。

2.3報文的轉發

故障現象：2015年8月10日，本場數據庫無法收到其他機場的氣象情報。08：05 （北京時）預報員通過在藍波終端發請求報的方式請求所需的實況及預報報文 。值班機務員在設備巡視中，發現民航氣象數據庫系統MQ線路轉發了某地機場的氣象情報，值班機務員立即進行排查。

故障分析及處理過程：機務員通過對通信系統$HOME/ COMM/history/的留底文件進行檢查，確認了請求報所請求的報文被通過MQ線路所轉發。為了進一步分析轉發的原因，仔細對通信系統BSB控制數據進行檢查，檢查結果正常，控制數據無誤，在存儲轉發參數設置為N。對數據庫系統各個進程進行檢查，檢查結果正常，對轉報機藍波終端軟件進行檢查，發現發送的RQM請求報的請求地址包含本地地址。

藍波終端發送RQM請求報：報文內容如下：

GG ZBBBYPYX，ZBBBYZYX，ZNNNYMYX，

RQM/SAZXXX，ZMMM FC=

請求地址為：ZBBBYPYX，ZBBBYZYX，ZNNNYMYX，發送請求報時，錯誤增加本地數據庫請求地址，紅色字體部分 。故障原因分析為本地數據庫收到請求報后，將本地數據庫ZXXX、ZMMM最新時次報文收集，以公報形式附加本地報頭發送到轉報機，轉報機收到報文后，再次將報文發送至ZNNNYMYX（本地數據庫），數據庫系統收到的這份報，由于報頭是本地的報頭，并且時次是最新的，于是數據庫系統做存儲轉發處理，通過MQ線路，轉發至華北地區氣象中心民航氣象數據庫。

三、小結

對于維修人員來說，設備出現故障之后要沉著冷靜分析，平時多看業務維修手冊，對系統有整體的把握，熟悉數據的處理流程，有利于快速判斷故障點，分析故障原因，必要時向廠家尋求技術支持，可達到事半功倍的效果，要善于對故障進行記錄、歸納、總結。通過實踐的學習，經驗的積累，這樣就可以快速的解決設備故障，為維修帶來方便。從而保證設備的正常運轉，充分發揮設備的作用。

數據庫系統范文第5篇

基于廣域網的數據庫訪問帶來的非法訪問、黑客攻擊、數據的截取、篡改等安全問題，在傳統的數據庫訪問方式中加入加密和認證安全技術以及防火墻技術，形成新的數據庫訪問結構。而新加入的模塊以的形式在起作用。從而達到安全訪問數據庫的目的。

一、數據庫安全訪問系統結構

數據庫安全訪問用來提供用戶身份認證和數據庫訪問服務并提供了網絡傳輸加密服務。所有的客戶方的數據庫訪問請求都通過數據庫安全訪問進行轉發。客戶方數據訪問用于接收所有的客戶應用數據庫訪問請求(包括數據庫客戶的連接建立和連接斷開請求)，并負責向數據庫客戶傳送數據庫訪問的結果。數據庫訪問請求是按照協議格式化為數據報提供給數據加密/認證客戶端，而數據庫訪問結果是按照協議

格式由數據加密/認證客戶端提供。數據加密認證客戶端完成客戶端的數據加密和認證工作，同服務器端的數據加密/認證服務器一起完成強大的數據加密功能保障數據安全。數據加密/認證服務器接收通過廣域網(或者是局域網)傳輸的客戶端發出的數據庫訪問請求數據報，這個請求是經過數據加密/認證客戶端加密的。解密后的數據傳遞給數據庫訪問服務器。然后將數據庫訪問服務器返回的結果加密通過網絡回送客戶端。

二、安全訪問的作用

1、安全訪問的中間件特點

數據庫安全訪問處在應用和數據庫之間，起一個數據庫中間件的作用和結構?？梢栽谙到y中，對數據庫的訪問請求進行控制管理，配合數據庫的特點，達到發揮最大數據庫性能的目的。

2、安全訪問的作用

之所以稱為是因為系統接收數據庫應用的數據庫訪問請求，把請求映射到系統對于數據庫的訪問，而系統不對這些請求進行過于復雜的處理。而數據庫系統可以只接受的訪問請求，起到隔離和安全保護作用。另一個重要特點是，可以加入到己經開發應用的信息系統中，極大提高原有系統的安全性能而不需要重新開發。

3、安全訪問的防火墻作用

現在網絡的一個現狀是黑客的攻擊廣泛存在。后果是竊取信息、使系統癱瘓或者造成網絡堵塞。數據庫安全訪問可以起應用級網關類別的防火墻作用，服務器而不是數據庫暴露在廣域網中，對數據庫的訪問都是通過服務器來完成。防火墻是網絡安全的屏障，一個防火墻（作為阻塞點、控制點）能極大地提高一個內部網絡的安全性，并通過過濾不安全的服務而降低風險。

三、安全訪問系統采用的技術

1、安全訪問系統采用SSL加密認證技術

為了保護敏感數據在傳送過程中的安全，全球許多知名企業采用SSL（SecuritySocketLayer）加密機制。SSL運行在TCP/IP層之上、應用層之下，為應用程序提供加密數據通道，適用于商業信息的加密。

系統中的數據加密和身份認證及簽名采用SSL技術來完成，系統中的數據加密和身份認證及簽名采用SSL技術來完成。應用程序通常使用IPC (Interporcess Communications Facility)與不同層次的安全協議打交道，在不同傳輸層協議中工作。

2、安全訪問系統形成多層結構

為了克服由于傳統客戶/服務器模型的這些缺陷給系統應用帶來的影響，一種新的結構出現了，這就是三層(N層)客戶/服務器模型。三層客戶/服務器結構構建了一種分割式的應用程序。主要分為三層:用戶服務層，業務處理層，數據服務層。系統中由于安全訪問的加入而形成多層結構，安全形成獨立的一層，與其它層通過標準的數據庫訪問接口，這就提供了極大的靈活性，這也很大程度上降低了數據安全訪問的設計復雜性。

3、安全訪問系統采用ODBC技術

(OpenDatabaseConnectivity，開放數據庫互連)是微軟公司開放服務結構(WOSA，WindowsOpenServicesArchitecture)中有關數據庫的一個組成部分，它建立了一組規范，并提供了一組對數據庫訪問的標準API（應用程序編程接口）。

ODBC之所以能夠操作眾多的數據庫，是由于當前絕大部分數據庫全部或部分地遵從關系數據庫概念。ODBC基本思想是提供獨立程序來提取數據信息，并具有向應用程序輸入數據的方法。ODBC接口的優勢之一為互操作性，程序設計員可以在不指定特定數據源情況下創建ODBC應用程序。

4、安全訪問系統對于應用的透明性

對于應用的透明性是指對應數據庫應用來說，采用或者不采用數據庫安全訪問，對于數據庫的訪問方法沒有區別。對應用的透明性是通過采用標準的數據庫訪問技術來達到的，數據庫應用的每一個數據庫訪問操作經過訪問系統映射為同樣的數據庫訪問實施于數據庫，對API調用進行一對一的映射，所以原來開發系統不需要改動。也為系統的方案設計提供了靈活性。

5、安全訪問系統中數據的壓縮傳輸