資料庫方案
❶ 資料庫的容災方案有哪幾種，分別有什麼優點和缺點！
簡單的說幾句吧。其實這個解決方案呢，主要是要先考慮成本問題，其他的，技術問題其實都很容易解決，但是企業應用上，最大的限制就是成本。下面以ORACLE資料庫為例，簡單說說。希望對你有所幫助。(資料庫類型並不重要，解決方案都是大同小異。)
1、基於存儲層的容災復制方案
這種技術的復制機制是通過基於SAN的存儲區域網進行復制，復制針對每個IO進行，復制的數據量比較大；系統可以實現數據的同步或非同步兩種方式的復制。對大數據量的系統來說有很大的優勢(每天日誌量在60G以上),但是對主機、操作系統、資料庫版本等要求一致，且對絡環境的要求比較高。
2、基於邏輯卷的容災復制方案
這種技術的機制是通過基於TCP/IP的網路環境進行復制，由操作系統進程捕捉邏輯卷的變化進行復制。其特點與基於存儲設備的復制方案比較類似，也可以選擇同步或非同步兩種方式，對主機的軟、硬體環境的一致性要求也比較高，對大數據量的應用比較有優勢。其目標系統如果要實現可讀，需要創建第三方鏡像。個人認為這種技術和上面提到的基於存儲的復制技術比較適合於超大數據量的系統，或者是應用系統的容災復制。
3、基於oracle redo log的邏輯復制方式
使用這種方式的主要有一些第三方的軟體，以及oracle自己的DATAGUARD 中的logical Standby。目前，國外已經有了很多比較成熟的產品及成功案例，國內也有類似的產品， 但在產品的成熟程度和成功案例上跟國外還有一定的差距。
使用oracle以外的獨立進程，捕捉redo log file 的信息，將其翻譯成sql語句，再通過網路傳輸到目標端資料庫，在目標端資料庫執行同樣的sql。如果其進程趕不上oracle日誌切換，也可以捕捉歸檔日誌中的內容。也有的產品在源端以事務為單位，當一個事務完成後，再把它傳輸到目標端。所有的產品一般都是以表為單位進行復制，同時也支持大部分DDL的復制(主要在oracle9i環境中)。
資料庫的吞吐量太大時，其實據會有較大的延遲，當資料庫每天的日量達到60G或更大時，這種方案的可行性交差；實施的過程可能會有一些停機時間，來進行數據的同步和配置的激活；復制環境建立起來以後，對資料庫結構上的一些修改需要按照規定的操作流程進行，有一定的維護成本。
❷ 資料庫建設方案及數據質量檢查標准
1 .制定調查資源整合方案
通過合理編碼方式理順各類數據間的關系，保證不同類別數據的緊密性，完整體現地學資料數據的多源性和空間性。
2.資料庫建設標准
根據資源整合方案，利用關系資料庫技術和空間資料庫技術，建立CO2地質儲存調查資料庫，有效儲存和管理各種空間數據和屬性數據，保證數據間的邏輯合理性，達到充分利用調查數據，並快速輸出數據的目的。
3.數據質量檢查標准及方法
根據資源整合方案，制定數據質量標准，開發相應質量檢查軟體，對數據進行質量檢查，確保入庫數據的有效性和合法性。
❸ 資料庫建設
（一）數據准備
1.數據收集
1∶25萬遙感地質填圖數據包含影像數據和矢量數據兩種格式，影像數據主要包括：TM原始影像、SPOT原始影像、SAR原始影像、TM與SPOT融合影像、TM與SAR融合影像、信息增強分類處理後的整幅影像或影像子區；矢量數據主要包括：航磁等值線影像、1∶25萬地形圖、地質圖、航磁解譯地質圖、遙感解譯單元圖、遙感解譯地質圖。現以新疆瓦石峽地區、內蒙古阿龍山地區為例，具體情況如下：
（1）瓦石峽地區
TM衛星影像
SAR衛星影像
航磁等值線（TIF）影像
航磁解譯地質圖
地質圖
遙感解譯影像單元圖
遙感解譯地質圖
（2）阿龍山地區
TM衛星影像
SPOT衛星影像
航磁等值線（TIF）影像
地質圖
航磁解譯地質圖
遙感解譯地質圖
2.數據預處理
1）影像數據處理，主要針對原始影像數據
（1）將TM原始影像、SPOT原始影像、SAR原始影像、航磁等值線（.JPG）數據格式轉換為ERDAS的.IMG格式。
（2）對轉換後的IMG文件進行投影轉換。投影系採用6度分帶的橫軸墨卡托（Transverse Mercator）投影，投影參數為：
Units：Meters
Scale Factor：1.0
Longitude Of Center：123 00 00
Latitude Of Center：0 00 00
False Easting：500 KM
False Northing：0 KM
Xshift：0
Yshift：0
橢球（spheroid）體採用克拉索夫（Krasovsky）橢球，參數為：
SemiMajor：6378245.0000 Meters
SemiMinor：6356863.0188 Meters
坐標系採用大地坐標，度量單位為米，這樣可以在GIS系統中方便的量算特徵的長度和面積。
（3）圖像坐標糾正
參照地形圖選擇同名點，對影像數據進行坐標精校正。同名點的選擇不少於12個。
2）矢量數據處理
工作主要針對地質圖、航磁解譯地質圖、遙感解譯單元圖、遙感解譯地質圖。
（1）數據分層
根據圖面特徵信息內容和制圖要求，每幅矢量圖按特徵類型劃分為點、線、面（區）三個圖層。劃分的依據是遙感地質解譯圖件的信息不完全等同於其他地質調查圖件，它表現的內容主要是：從影像圖中判讀出的地層、岩石影像單元及構造界線，但各種地質特徵的單位、時代、分類、度量、結構、方向等的描述不是十分具體，因此在屬性定義上比較一致，對一個圖件不需要產生基於同一特徵類型的專題圖層，因此按矢量特徵類型劃分較為合理、簡便。
（2）圖件掃描矢量化
將地質、影像單元等圖件掃描成 TIF影像文件，按照分層要求，將每個圖件數字化為點、線、面三個圖層文件。處理的圖件和產生的矢量圖層文件見表3-1至3-7。
表3-1 矢量圖層表
1∶25萬遙感地質填圖方法和技術
c.面特徵：由於影像單元圖的面特徵描述有其特殊之處，有時遵照地層、岩石的分類方法國家標准，但絕大部分是按照影像顏色、紋理等劃分和稱謂，因此進行分類編碼十分困難，有待進一步研究解決。
以上編碼方法是在每種特徵類型組合最大值和預留一定的擴充餘地的基礎上編制的，編碼方案參照國標：GB958—89區域地質圖圖例（1∶5萬）
（6）屬性定義
說明：由於地質代號的組成方式極為復雜，使用了上下角標、希臘字元、拉丁字母等，而這些字元和格式在純文本的屬性欄位中是不能完全或准確表達的，因此在錄入時對地質代號進行了一些簡化。
例如：Pt2xh簡化為Pt2xh
簡化為An1—3
（二）建立資料庫
GIS空間資料庫有兩種存儲形式：一是基於文件索引的傳統空間資料庫管理體系；二是採用商用關系資料庫的解決方案，二者各有千秋。第一種結構是對應用的集成，而數據是鬆散的，雖不利於數據的集中管理，但對不同系統平台之間共享數據提供了很大方便，特別是數據較少的小型應用系統。這種結構的另外一個可取之處是方案簡單，工作量小，不需要資料庫方面的專業知識。第二種結構既是應用的集成，也是數據的集成，並且提供所有的RDBMS的數據和安全管理優勢，但它需要專用的空間數據引擎，對其他軟體使用數據是一個極大的限制，必須進行數據的導入導出和格式轉換，並且要求使用者對RDBMS有一定的操作和管理經驗。
由於本集成系統採用的是ARC/INFO和ERDAS軟體，它們之間只能達到文件方式的數據共享，雖然ARC/INFO 8提供了GeoDataBase這種關系資料庫管理模式，實現真正的空間數據集中管理和RDBMS所有的數據管理能力，但為了滿足兩個軟體之間數據的交互處理，本系統採用文件索引形式的資料庫。在數據完備的基礎上，建庫工作需以下兩個步驟：
（1）首先創建基於項目的不同格式、不同類型的目錄樹工作區，把所有數據文件分類保存在這個工作區中，工作區框架以瓦石峽幅數據為例（圖3-5）。
（2）然後在 ARC/INFO 的 ARCMAP中新建一個 MAP DOCUMENT（以下簡稱為文檔），添加所有數據文件到文檔中。文檔中每個數據文件都被稱為一個 LAYER（以下簡稱為層），每個矢量層可以有它自己的環境，文檔可以保存環境的變化。使用者只需打開這個文檔即可調用項目所有的數據文件，並且恢復到上一次工作時的狀態。
圖3-5 數據分層結構圖
在MAP DOCUMENT這種集成的數據環境下，使用者可以採用ARC/INFO 8的ARCEDITOR、ARCMAP參照影像圖層進行矢量化的解譯工作，對已形成的圖件直接進行圖形和屬性編輯，進行輔助解譯的空間分析，對各種圖件進行疊加比較，使用文字標簽或屬性欄位標注特徵，按照分類符號化特徵，製作專題圖，列印輸出圖件報表等，實現一系列與遙感解譯有關的功能和操作。
由於ARC/INFO提供的地質圖式圖例和符號不能滿足我國的地質成圖要求，因此制圖軟體採用地質行業較為通用的MAPGIS。通過ARCTOOLS工具將最終的解譯成果矢量地質圖轉換為ARC/INFO的標准交換格式E00，提交給MAPGIS形成繪圖文件，出版印刷。具體的實施方案和技術流程見「成果圖件製作方法研究」一節。
❹ 關於資料庫安全及其防範方案的分析
關於資料庫安全及其防範方案的分析
隨著網路的不斷發展，數據的共享日益加強，數據的安全保密越來越重要。為了計算機資料庫整體安全性的控制，需要做好很多細節性的工作，並根據具體應用環境的安全需要來分析安全薄弱環節，並制定統一的安全管理策略加以實施，以保證其最高的安全性。
1.資料庫安全環境的分析
隨著時代的發展，我國的計算機信息安全標准也在不斷提升。在當下的資料庫系統安全控制模塊中，我國資料庫安全分為不同的等級。但是總體來說，我國的資料庫安全性是比較低的，這歸結於我國數據技術體系的落後。為了更好的健全計算機資料庫體系，進行資料庫安全體系的研究是必要的。我國現有的一系列數據安全理論是落後於發達國家的。這體現在很多的應用領域，比如電力領域、金融領域、保險領域等。很多軟體都是因為其比較缺乏安全性而得不到較大范圍的應用，歸根結底是資料庫安全性級別比較低。
為了滿足現階段資料庫安全工作的需要，進行相關標準的深化研究是必要的。這需要對資料庫安全進行首要考慮，且需要考慮到方方面面，才更有利於資料庫保密性的控制，從而保證這些數據存儲與調用的一致性。
在當前資料庫安全控制過程中，首先需要對這些數據進行可用性的分析，從而有利於避免資料庫遭到破壞，更有利於進行資料庫的損壞控制及其修復。其次為了保證資料庫的安全性、效益性，也離不開對資料庫整體安全性方案的應用。最後必須對資料庫進行的一切操作進行跟蹤記錄，以實現對修改和訪問資料庫的用戶進行追蹤，從而方便追查並防止非法用戶對資料庫進行操作。
2.資料庫安全策略的更新
為了滿足現階段資料庫安全性方案的應用，進行身份的鑒別是必要的。所謂的身份鑒別就是進行真實身份及其驗證身份的配比，這樣可以避免欺詐及其假冒行為的發生。身份鑒別模式的應用，表現在用戶使用計算機系統進行資源訪問時。當然在一些特定情況下，也要進行身份鑒別，比如對某些稀缺資源的訪問。
身份鑒別通常情況下可以採用以下三種方法：一是通過只有被鑒別人自己才知道的信息進行鑒別，如密碼、私有密鑰等；二是通過只有被鑒別人才擁有的信物進行鑒別，如IC 卡、護照等；三是通過被鑒別人才具有的生理或者行為特徵等來進行鑒別，如指紋、筆跡等。
在當前訪問控制模塊中，除了進行身份鑒別模式的應用外，還需要進行信息資源的訪問及其控制，這樣更有利於不同身份用戶的許可權分配。這就需要進行訪問級別的控制，針對各個系統的內部數據進行操作許可權的控制，進行自主性及其非自主性訪問的控制，滿足資料庫的安全需要。實現用戶對資料庫訪問許可權進行控制，讓所有的用戶只能訪問自己有許可權使用的數據。當某一個用戶具有對某些數據進行訪問的許可權時，他還可以把對這些數據的操作許可權部分或者全部的轉移給其他用戶，這樣其他的用戶也獲得了對這些數據的訪問權。
為了更好的進行資料庫的安全管理，審計功能的應用也必不可少。這需要就資料庫的數據進行統一性的操作。這樣管理員更加方便對資料庫應用情況進行控制，審計功能也有利於對資料庫的操作行為進行控制，更有利於控制用戶對資料庫的訪問。攻擊檢測是通過升級信息來分析系統的內部和外部所有對資料庫的攻擊企圖，把當時的攻擊現場進行復原，對相關的攻擊者進行處罰。通過這種方法，可以發現資料庫系統的安全隱患，從而來改進以增加資料庫系統的安全性。
在資料庫數據處理過程中，可以進行一些合法查詢模式的應用，當需要調取保密數據時，就需要應用推理分析模塊。這是資料庫安全性方案控制過程中的重難點，而通過這種簡單的推理分析方法調取保密數據，是得不到有效解決的。但是我們可以使用以下幾種方法來對這種推理進行控制：數據加密的基本思想就是改變符號的排列方式或按照某種規律進行替換，使得只有合法的用戶才能理解得到的數據，其他非法的用戶即使得到了數據也無法了解其內容。
通過對加密粒度的應用，更有利於進行資料庫加密性的控制。其分為幾種不同的應用類型等級。在當前應用模塊中，需要進行數據保護級別的分析，進行適當的加密粒度的分析。更有利於滿足資料庫級別加密的需要。該加密技術的應用針對的是整體資料庫，從而針對資料庫內部的表格、資料等加密。採用這種加密粒度，加密的密鑰數量較少，一個資料庫只需要一個加密密鑰，對於密鑰的管理比較簡單。但是，由於資料庫中的數據能夠被許多的用戶和應用程序所共享，需要進行很多的數據處理，這將極大的降低伺服器的運行效率，因此這種加密粒度只有在一些特定的情況下才使用。
表級加密也是比較常用的方法，這種方法應用於資料庫內部的數據加密。針對具體的存儲數據頁面進行加密控制。這對於系統的運行效率的提升具備一定的幫助，不會影響系統的運行效率。這種方法需要應用到一些特殊工具進行處理，比如解釋器、詞法分析器等，進行核心模塊的控制，進行資料庫管理系統源代碼的控制及其優化。但是其難以確保資料庫管理系統的整體邏輯性，也存在缺陷。記錄級加密；這種加密技術的加密粒度是表格中的每一條記錄，對資料庫中的每一條記錄使用專門的函數來實現對數據的加密、解密。通過這種加密方法，加密的粒度更加小巧，具有更好的選擇性和靈活性。欄位級加密；這種加密技術的加密粒度是表格中的某一個或者幾個欄位。通過欄位級的加密粒度只需要對表格中的敏感列的數據進行加密，而不需要對表格中的所有的數據進行加密。
選擇加密演算法也是比較常見的數據加密方法。它是數據加密的核心部分。對於資料庫的整體安全性的控制具有直接性的影響。通過對加密演算法的分析，得知其分為公共密鑰加密及其對稱加密。在數據加密模塊中，需要進行密文及其明文的區分，從而進行明文及其密文的轉換，也就是普遍意義上的密碼。密碼與密鑰是兩個不同的概念。後者僅是收發雙方知道的信息。在數據加密技術中，對密鑰進行管理主要包括以下幾個方面，產生密鑰。產生怎樣的密鑰主要取決於使用什麼樣的演算法。若產生的密鑰強度不一樣就稱這種演算法實現的是非線性的密鑰空間，若產生的密鑰強度一樣就稱這種演算法實現的是線性的密鑰空間。分配密鑰、傳遞密鑰：分配密鑰就是產生一個密鑰並且將這個密鑰分配給某個用戶使用的過程。
密鑰的傳遞分為不同的應用形式，集中式與分散式。所謂的集中式就是進行密鑰整體式的傳遞；所謂的分散式就是對密鑰的多個部分進行劃分，以秘密的方法給用戶進行傳遞。通過將整體方法與分散方法應用到存儲模塊中，更好的滿足現階段資料庫整體安全性的需要。對於密鑰的備份可以使用和對密鑰進行分散存儲一樣的方式進行，以避免太多的人知道密鑰；而銷毀密鑰需要有管理和仲裁機制，以防止用戶對自己的操作進行否認。
3.結束語
隨著計算機，特別是網路的不斷發展，數據的共享日益加強，數據的安全保密越來越重要。本文詳細闡述了資料庫的安全防範，分別從數據分析、用戶鑒別、訪問許可權控制、審計、數據加密等環節逐一剖析資料庫安全。為了計算機資料庫整體安全性的控制，需要做好很多細節性的工作，並根據具體應用環境的安全需要來分析安全薄弱環節，並制定統一的安全管理策略加以實施，以保證其最高的安全性。
❺ 誰知道資料庫優化設計方案有哪些
本文首先討論了基於第三範式的資料庫表的基本設計，著重論述了建立主鍵和索引的策略和方案，然後從資料庫表的擴展設計和庫表對象的放置等角度概述了資料庫管理系統的優化方案。
關鍵詞： 優化（Optimizing） 第三範式（3NF） 冗餘數據（Rendant Data） 索引（Index） 數據分割（Data Partitioning） 對象放置（Object Placement）
1 引言
資料庫優化的目標無非是避免磁碟I/O瓶頸、減少CPU利用率和減少資源競爭。為了便於讀者閱讀和理解，筆者參閱了Sybase、Informix和Oracle等大型資料庫系統參考資料，基於多年的工程實踐經驗，從基本表設計、擴展設計和資料庫表對象放置等角度進行討論，著重討論了如何避免磁碟I/O瓶頸和減少資源競爭，相信讀者會一目瞭然。
2 基於第三範式的基本表設計
在基於表驅動的信息管理系統（MIS）中，基本表的設計規范是第三範式（3NF）。第三範式的基本特徵是非主鍵屬性只依賴於主鍵屬性。基於第三範式的資料庫表設計具有很多優點：一是消除了冗餘數據，節省了磁碟存儲空間；二是有良好的數據完整性限制，即基於主外鍵的參照完整限制和基於主鍵的實體完整性限制，這使得數據容易維護，也容易移植和更新；三是數據的可逆性好，在做連接（Join）查詢或者合並表時不遺漏、也不重復；四是因消除了冗餘數據（冗餘列），在查詢（Select）時每個數據頁存的數據行就多，這樣就有效地減少了邏輯I/O，每個Cash存的頁面就多，也減少物理I/O；五是對大多數事務(Transaction)而言，運行性能好；六是物理設計(Physical Design)的機動性較大，能滿足日益增長的用戶需求。
在基本表設計中，表的主鍵、外鍵、索引設計佔有非常重要的地位，但系統設計人員往往只注重於滿足用戶要求，而沒有從系統優化的高度來認識和重視它們。實際上，它們與系統的運行性能密切相關。現在從系統資料庫優化角度討論這些基本概念及其重要意義：
（1）主鍵(Primary Key)：主鍵被用於復雜的SQL語句時，頻繁地在數據訪問中被用到。一個表只有一個主鍵。主鍵應該有固定值（不能為Null或預設值，要有相對穩定性），不含代碼信息，易訪問。把常用（眾所周知）的列作為主鍵才有意義。短主鍵最佳（小於25bytes），主鍵的長短影響索引的大小，索引的大小影響索引頁的大小，從而影響磁碟I/O。主鍵分為自然主鍵和人為主鍵。自然主鍵由實體的屬性構成，自然主鍵可以是復合性的，在形成復合主鍵時，主鍵列不能太多，復合主鍵使得Join*作復雜化、也增加了外鍵表的大小。人為主鍵是，在沒有合適的自然屬性鍵、或自然屬性復雜或靈敏度高時，人為形成的。人為主鍵一般是整型值（滿足最小化要求），沒有實際意義，也略微增加了表的大小；但減少了把它作為外鍵的表的大小。
（2）外鍵（Foreign Key）：外鍵的作用是建立關系型資料庫中表之間的關系（參照完整性），主鍵只能從獨立的實體遷移到非獨立的實體，成為後者的一個屬性，被稱為外鍵。
（3）索引(Index)：利用索引優化系統性能是顯而易見的，對所有常用於查詢中的Where子句的列和所有用於排序的列創建索引，可以避免整表掃描或訪問，在不改變表的物理結構的情況下，直接訪問特定的數據列，這樣減少數據存取時間；利用索引可以優化或排除耗時的分類*作；把數據分散到不同的頁面上，就分散了插入的數據；主鍵自動建立了唯一索引，因此唯一索引也能確保數據的唯一性（即實體完整性）；索引碼越小，定位就越直接；新建的索引效能最好，因此定期更新索引非常必要。索引也有代價：有空間開銷，建立它也要花費時間，在進行Insert、Delete和Update*作時，也有維護代價。索引有兩種：聚族索引和非聚族索引。一個表只能有一個聚族索引，可有多個非聚族索引。使用聚族索引查詢數據要比使用非聚族索引快。在建索引前，應利用資料庫系統函數估算索引的大小。
① 聚族索引（Clustered Index）：聚族索引的數據頁按物理有序儲存，佔用空間小。選擇策略是，被用於Where子句的列：包括范圍查詢、模糊查詢或高度重復的列（連續磁碟掃描）；被用於連接Join*作的列；被用於Order by和Group by子句的列。聚族索引不利於插入*作，另外沒有必要用主鍵建聚族索引。
② 非聚族索引（Nonclustered Index）：與聚族索引相比，佔用空間大，而且效率低。選擇策略是，被用於Where子句的列：包括范圍查詢、模糊查詢（在沒有聚族索引時）、主鍵或外鍵列、點（指針類）或小范圍（返回的結果域小於整表數據的20%）查詢；被用於連接Join*作的列、主鍵列（范圍查詢）；被用於Order by和Group by子句的列；需要被覆蓋的列。對只讀表建多個非聚族索引有利。索引也有其弊端，一是創建索引要耗費時間，二是索引要佔有大量磁碟空間，三是增加了維護代價（在修改帶索引的數據列時索引會減緩修改速度）。那麼，在哪種情況下不建索引呢？對於小表（數據小於5頁）、小到中表（不直接訪問單行數據或結果集不用排序）、單值域（返回值密集）、索引列值太長（大於20bitys）、容易變化的列、高度重復的列、Null值列，對沒有被用於Where子語句和Join查詢的列都不能建索引。另外，對主要用於數據錄入的，盡可能少建索引。當然，也要防止建立無效索引，當Where語句中多於5個條件時，維護索引的開銷大於索引的效益，這時，建立臨時表存儲有關數據更有效。
批量導入數據時的注意事項：在實際應用中，大批量的計算（如電信話單計費）用C語言程序做，這種基於主外鍵關系數據計算而得的批量數據（文本文件），可利用系統的自身功能函數（如Sybase的BCP命令）快速批量導入，在導入資料庫表時，可先刪除相應庫表的索引，這有利於加快導入速度，減少導入時間。在導入後再重建索引以便優化查詢。
（4）鎖：鎖是並行處理的重要機制，能保持數據並發的一致性，即按事務進行處理；系統利用鎖，保證數據完整性。因此，我們避免不了死鎖，但在設計時可以充分考慮如何避免長事務，減少排它鎖時間，減少在事務中與用戶的交互，杜絕讓用戶控制事務的長短；要避免批量數據同時執行，尤其是耗時並用到相同的數據表。鎖的徵用：一個表同時只能有一個排它鎖，一個用戶用時，其它用戶在等待。若用戶數增加，則Server的性能下降，出現「假死」現象。如何避免死鎖呢？從頁級鎖到行級鎖，減少了鎖徵用；給小表增加無效記錄，從頁級鎖到行級鎖沒有影響，若在同一頁內競爭有影響，可選擇合適的聚族索引把數據分配到不同的頁面；創建冗餘表；保持事務簡短；同一批處理應該沒有網路交互。
（5）查詢優化規則：在訪問資料庫表的數據(Access Data)時，要盡可能避免排序（Sort）、連接(Join)和相關子查詢*作。經驗告訴我們，在優化查詢時，必須做到：
① 盡可能少的行；
② 避免排序或為盡可能少的行排序，若要做大量數據排序，最好將相關數據放在臨時表中*作；用簡單的鍵（列）排序，如整型或短字元串排序；
③ 避免表內的相關子查詢；
④ 避免在Where子句中使用復雜的表達式或非起始的子字元串、用長字元串連接；
⑤ 在Where子句中多使用「與」（And）連接，少使用「或」(Or)連接；
⑥ 利用臨時資料庫。在查詢多表、有多個連接、查詢復雜、數據要過濾時，可以建臨時表（索引）以減少I/O。但缺點是增加了空間開銷。
除非每個列都有索引支持，否則在有連接的查詢時分別找出兩個動態索引，放在工作表中重新排序。
3 基本表擴展設計
基於第三範式設計的庫表雖然有其優越性（見本文第一部分），然而在實際應用中有時不利於系統運行性能的優化：如需要部分數據時而要掃描整表，許多過程同時競爭同一數據，反復用相同行計算相同的結果，過程從多表獲取數據時引發大量的連接*作，當數據來源於多表時的連接*作；這都消耗了磁碟I/O和CPU時間。
尤其在遇到下列情形時，我們要對基本表進行擴展設計：許多過程要頻繁訪問一個表、子集數據訪問、重復計算和冗餘數據，有時用戶要求一些過程優先或低的響應時間。
如何避免這些不利因素呢？根據訪問的頻繁程度對相關表進行分割處理、存儲冗餘數據、存儲衍生列、合並相關表處理，這些都是克服這些不利因素和優化系統運行的有效途徑。
3.1 分割表或儲存冗餘數據
分割表分為水平分割表和垂直分割表兩種。分割表增加了維護數據完整性的代價。
水平分割表：一種是當多個過程頻繁訪問數據表的不同行時，水平分割表，並消除新表中的冗餘數據列；若個別過程要訪問整個數據，則要用連接*作，這也無妨分割表；典型案例是電信話單按月分割存放。另一種是當主要過程要重復訪問部分行時，最好將被重復訪問的這些行單獨形成子集表（冗餘儲存），這在不考慮磁碟空間開銷時顯得十分重要；但在分割表以後，增加了維護難度，要用觸發器立即更新、或存儲過程或應用代碼批量更新，這也會增加額外的磁碟I/O開銷。
垂直分割表（不破壞第三範式），一種是當多個過程頻繁訪問表的不同列時，可將表垂直分成幾個表，減少磁碟I/O（每行的數據列少，每頁存的數據行就多，相應佔用的頁就少），更新時不必考慮鎖，沒有冗餘數據。缺點是要在插入或刪除數據時要考慮數據的完整性，用存儲過程維護。另一種是當主要過程反復訪問部分列時，最好將這部分被頻繁訪問的列數據單獨存為一個子集表（冗餘儲存），這在不考慮磁碟空間開銷時顯得十分重要；但這增加了重疊列的維護難度，要用觸發器立即更新、或存儲過程或應用代碼批量更新，這也會增加額外的磁碟I/O開銷。垂直分割表可以達到最大化利用Cache的目的。
總之，為主要過程分割表的方法適用於：各個過程需要表的不聯結的子集，各個過程需要表的子集，訪問頻率高的主要過程不需要整表。在主要的、頻繁訪問的主表需要表的子集而其它主要頻繁訪問的過程需要整表時則產生冗餘子集表。
注意，在分割表以後，要考慮重新建立索引。
3.2 存儲衍生數據
對一些要做大量重復性計算的過程而言，若重復計算過程得到的結果相同（源列數據穩定，因此計算結果也不變），或計算牽扯多行數據需額外的磁碟I/O開銷，或計算復雜需要大量的CPU時間，就考慮存儲計算結果（冗餘儲存）。現予以分類說明：
若在一行內重復計算，就在表內增加列存儲結果。但若參與計算的列被更新時，必須要用觸發器更新這個新列。
若對表按類進行重復計算，就增加新表（一般而言，存放類和結果兩列就可以了）存儲相關結果。但若參與計算的列被更新時，就必須要用觸發器立即更新、或存儲過程或應用代碼批量更新這個新表。
若對多行進行重復性計算（如排名次），就在表內增加列存儲結果。但若參與計算的列被更新時，必須要用觸發器或存儲過程更新這個新列。
總之，存儲冗餘數據有利於加快訪問速度；但違反了第三範式，這會增加維護數據完整性的代價，必須用觸發器立即更新、或存儲過程或應用代碼批量更新，以維護數據的完整性。
3.3 消除昂貴結合
對於頻繁同時訪問多表的一些主要過程，考慮在主表內存儲冗餘數據，即存儲冗餘列或衍生列（它不依賴於主鍵），但破壞了第三範式，也增加了維護難度。在源表的相關列發生變化時，必須要用觸發器或存儲過程更新這個冗餘列。當主要過程總同時訪問兩個表時可以合並表，這樣可以減少磁碟I/O*作，但破壞了第三範式，也增加了維護難度。對父子表和1：1關系表合並方法不同：合並父子表後，產生冗餘表；合並1：1關系表後，在表內產生冗餘數據。
4 資料庫對象的放置策略
資料庫對象的放置策略是均勻地把數據分布在系統的磁碟中，平衡I/O訪問，避免I/O瓶頸。
⑴ 訪問分散到不同的磁碟，即使用戶數據盡可能跨越多個設備，多個I/O運轉，避免I/O競爭，克服訪問瓶頸；分別放置隨機訪問和連續訪問數據。
⑵ 分離系統資料庫I/O和應用資料庫I/O。把系統審計表和臨時庫表放在不忙的磁碟上。
⑶ 把事務日誌放在單獨的磁碟上，減少磁碟I/O開銷，這還有利於在障礙後恢復，提高了系統的安全性。
⑷ 把頻繁訪問的「活性」表放在不同的磁碟上；把頻繁用的表、頻繁做Join*作的表分別放在單獨的磁碟上，甚至把把頻繁訪問的表的欄位放在不同的磁碟上，把訪問分散到不同的磁碟上，避免I/O爭奪；
⑸ 利用段分離頻繁訪問的表及其索引（非聚族的）、分離文本和圖像數據。段的目的是平衡I/O，避免瓶頸，增加吞吐量，實現並行掃描，提高並發度，最大化磁碟的吞吐量。利用邏輯段功能，分別放置「活性」表及其非聚族索引以平衡I/O。當然最好利用系統的默認段。另外，利用段可以使備份和恢復數據更加靈活，使系統授權更加靈活。
❻ 資料庫規劃一般要包含那些內容
總體數據規劃主要從三個方面去規劃：1、管理方面、2、技術方面 3、用戶方面。
總體規劃的內容包括：戰略的業務規劃、戰略的信息技術規劃、戰略的數據規劃。
❼ 目前主流的分布式資料庫系統實現方案有哪些
（1）方案一（資料庫保存所有伺服器索引信息）
全對稱結構，沒有中央伺服器
web方案：
只從本地資料庫檢索符合條件的記錄，給出結果
每次檢索都要從本地伺服器的海量數據中進行
資料庫方案：
資料庫保存所有伺服器的索引內容
緩存命中率高的記錄，減少檢索時間
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每個結點一萬條記錄
web伺服器：同時一百線程在本地資料庫伺服器檢索
資料庫伺服器：每次接收一百個查詢請求；每個請求要從一百萬條索引中檢索（最壞的情況）；緩沖機制可以稍微減輕負擔
數據更新操作：
同時更新所有資料庫/只更新本地，伺服器間相互同步
方案二（資料庫保存本地索引及少量緩沖）
每高校作為一個結點
所有結點全對稱結構，網路中沒有一個中央伺服器
web方案：
接收到請求時同時多線程向其它伺服器同時搜索（伺服器壓力問題？）
資料庫方案：
資料庫保存本地數據
資料庫保存一定量緩沖數據，
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用
則每個web伺服器同時發起一萬個線程向其它數據伺服器搜索（oops!）
每個資料庫伺服器會同時接收到一萬個查詢請求（oops！）
採用學習過程只能少量減少查詢請求和web伺服器搜索線程
數據更新操作：
只更新本地
方案三（中央伺服器方案一）
每高校一個結點
每結點結構相同，連接到同一個中央伺服器
web方案
每個查詢向中央伺服器進行，由中央伺服器實行檢索，中央伺服器返回檢索結果
資料庫方案
中央資料庫保存所有索引信息
每結點可以只用小型資料庫保存本地用戶和其它信息即可
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每結點資料記錄一萬條
web伺服器：同時發起一百個進程向中央資料庫查詢
資料庫伺服器（中央）：同時接收一萬條查詢請求並返回大容量結果
資料庫伺服器（結點）：少量工作
數據更新操作：
只更新中央伺服器
方案四（中央伺服器方案二）
每高校一個結點
每結點結構相同，連接到同一中央伺服器
web方案：
每個查詢向中央伺服器進行，由中央伺服器根據查詢內容進行轉發到結點資料庫，再由結點資料庫返回結果
資料庫方案：
中央伺服器保存各結點分類信息，根據頁面請求的分類轉發查詢到相應伺服器
伺服器負載分析：
伺服器負載假設：
一百個結點，每結點一百人同時使用，每結點資料記錄一萬條，每結點一百個類別
web伺服器：同時一百個進程向中央資料庫查詢
資料庫伺服器（中央）：同時接收一萬條請求並轉發
資料庫伺服器（結點）：從中央伺服器接收查詢請求，最壞情況下每結點接收到一萬條查詢請求
數據更新操作：
只更新本地伺服器
分類變化時更新中央伺服器
❽ oracle資料庫中什麼叫方案
schema，一組對象的集合，通常一個schema就是用戶名，下面集結這個用戶下的所有對象
❾ oracle資料庫遷移方案 文檔怎麼寫
Oracle 資料庫遷移文檔可以按如下格式進行寫：
一、需求分析：
資料庫所有文件（數據文件、日誌文件、臨時文件、控制文件）都存放在光纖存儲中，但是光纖存儲使用時間過長，超過3年，經常出現一些問題，而且光纖存儲需要廠家維護，維護方面不是很方便，需要將資料庫文件遷移到nas存儲中。
二、操作步驟：
1：具體需求
2：保存現有數據文件、控制文件、臨時文件、日誌文件位置
3：停止監聽，並關閉資料庫
4：移動所有數據文件、控制文件、臨時文件、日誌文件到新的位置
5：啟動資料庫到nomount狀態，並更改控制文件位置，關閉資料庫
6：啟動資料庫到mount狀態
7：更改數據文件、臨時文件、日誌文件位置
7：打開資料庫
8：重啟驗證