oracle資料庫設計
Ⅰ 大型Oracle資料庫如何設計
超大型系統的特點為： 1、處理的用戶數一般都超過百萬，有的還超過千萬，資料庫的數據量一般超過1TB; 2、系統必須提供實時響應功能，系統需不停機運行，要求系統有很高的可用性及可擴展性。 為了能達到以上要求，除了需要性能優越的計算機和海量存儲設備外，還需要先進的資料庫結構設計和優化的應用系統。 一般的超大型系統採用雙機或多機集群系統。下面以資料庫採用Oracle 8.0.6並行伺服器為例來談談超大型資料庫設計方法： 確定系統的ORACLE並行伺服器應用劃分策略 資料庫物理結構的設計 系統硬碟的劃分及分配 備份及恢復策略的考慮 二、Oracle並行伺服器應用劃分策略 Oracle並行伺服器允許不同節點上的多個INSTANCE實例同時訪問一個資料庫，以提高系統的可用性、可擴展性及性能。Oracle並行伺服器中的每個INSTANCE實例都可將共享資料庫中的表或索引的數據塊讀入本地的緩沖區中，這就意味著一個數據塊可存在於多個INSTANCE實例的SGA區中。那麼保持這些緩沖區的數據的一致性就很重要。Oracle使用 PCM( Parallel Cache Management)鎖維護緩沖區的一致性，Oracle同時通過I DLM(集成的分布式鎖管理器)實現PCM 鎖,並通過專門的LCK進程實現INSTANCE實例間的數據一致。 考慮這種情況：INSTANCE1對BLOCK X塊修改，這時INSTANCE2對BLOCK X塊也需要修改。Oracle並行伺服器利用PCM鎖機制，使BLOCK X從INSTANCE 1的SGA區寫入資料庫數據文件中，又從數據文件中把BLOCK X塊讀入INSTANCE2的SGA區中。發生這種情況即為一個PING。PING使原來1個MEMORY IO可以完成的工作變成2個DISK IO和1個 MEMORY IO才能夠完成,如果系統中有過多的PING，將大大降低系統的性能。 Oracle並行伺服器中的每個PCM鎖可管理多個數據塊。PCM鎖管理的數據塊的個數與分配給一個數據文件的PCM鎖的個數及該數據文件的大小有關。當INSTANCE 1和INSTANCE 2要操作不同的BLOCK，如果這些BLOCK 是由同一個PCM鎖管理的,仍然會發生PING。這些PING稱為FALSE PING。當多個INSTANCE訪問相同的BLOCK而產生的PING是TRUE PING。 合理的應用劃分使不同的應用訪問不同的數據，可避免或減少TRUE PING;通過給FALSE PING較多的數據文件分配更多的PCM鎖可減少 FALSE PING的次數，增加PCM鎖不能減少TRUE PING。 所以，Oracle並行伺服器設計的目的是使系統交易處理合理的分布在INSTANCE實例間，以最小化PING，同時合理的分配PCM鎖，減少FALSE PING。設計的關鍵是找出可能產生的沖突，從而決定應用劃分的策略。應用劃分有如下四種方法： 1、根據功能模塊劃分，不同的節點運行不同的應用 2、根據用戶劃分，不同類型的用戶運行在不同的節點上 3、根據數據劃分，不同的節點訪問不同的數據或索引 4、根據時間劃分，不同的應用在不同的時間段運行 應用劃分的兩個重要原則是使PING最小化及使各節點的負載大致均衡。 三、資料庫物理結構的設計 資料庫物理結構設計包括確定表及索引的物理存儲參數，確定及分配資料庫表空間，確定初始的回滾段，臨時表空間，redo log files等，並確定主要的初始化參數。物理設計的目的是提高系統的性能。整個物理設計的參數可以根據實際運行情況作調整。 表及索引數據量估算及物理存儲參數的設置 表及索引的存儲容量估算是根據其記錄長度及估算的最大記錄數確定的。在容量計算中考慮了數據塊的頭開銷及記錄和欄位的頭開銷等等。
Ⅱ 資料庫是什麼Oracle又是啥玩意
經常會有人問我資料庫是幹啥的，其實一開始我是拒絕回答的，因為我也不能做到通俗易懂的表達出來，畢竟我接觸這個概念也沒有多長時間，但隨著問的人多了，我覺得是時候腦補一下我的第一堂課了，萬一哪天冒出來個貨跟你掰扯這事兒，你沒分分鍾給他說清，最後弄個丟里兒丟面兒，好尷尬呀。
資料庫，說白了就是按照數據結構來組織、存儲和管理數據的倉庫，這些數據是結構化的，並可為多種應用服務。也就是說，資料庫是使用計算機伺服器來存儲數據的，專門用來提供各種數據服務。可以這樣想像，過去一個公司的所有財務數據都是放在保險櫃裡面，而現在我們就可以針對這些財務數據搭建一個資料庫放在某台計算機或伺服器上面;再比如，企業或事業單位的人事部門常常要把本單位職工的基本情況(職工號、姓名、年齡、性別、籍貫、工資、簡歷等)存放在表中，這張表就可以看成是一個資料庫。有了這個"數據倉庫"我們就可以根據需要隨時查詢某職工的基本情況，也可以查詢工資在某個范圍內的職工人數等等。這些工作如果都能在計算機上自動進行，那我們的人事管理就可以達到極高的水平。此外，在財務管理、倉庫管理、生產管理中也需要建立眾多的這種"資料庫"，使其可以利用計算機實現財務、倉庫、生產的自動化管理。最常見的資料庫有：銀行儲蓄系統、手機話費系統、美容美發會員系統、超市會員積分系統、水電費系統、機票或火車票系統等，這些都需要後台資料庫基礎設施的支撐。舉了這么多例子，應該是把資料庫說明白了，至少能在大腦裡面有個概念，知道這個東西是幹啥的。
現在大數據被炒的紅得發紫，而大數據的基礎也是數據，由此可見，數據是一個企業的核心資源，說它是企業的立身之本、發展之基都不為過，因此，維護資料庫的資料庫管理員(DBA)是企業不可或缺的。
目前市面上的資料庫產品有很多，單從規模上分可分為大型、中型、小型幾種，典型的資料庫產品如下：
大型資料庫：Oracle、DB2、Sybase;
中型資料庫：Mysql、SQLServer、Infomix;
小型資料庫：Access、VisualFoxpro。在眾多的資料庫產品中，Oracle資料庫一直處於行業領導先地位，也是當今最流行的關系型資料庫。Oracle可翻譯成"甲骨文"，它是一家以資料庫為主業的全球化公司，是全球第二大軟體公司(第一名是微軟公司)，目前Oracle在資料庫軟體市場已經排名第一，資料庫軟體市場份額達到48.6%，遙遙領先於第二名佔有率僅為20.7%的IBM公司的DB2。在中國市場上的計算機專業系統後台所使用的資料庫尤以Oracle資料庫居多。但是購買Oracle資料庫需要很大一筆費用，一般的大型企業使用，需要有專業人員進行管理和維護，中小企業承擔不起。中小企業為了節省成本，一般使用MySQL、PostgreSQL這類免費開源的資料庫，所以Oracle資料庫相關的工作崗位一般是在大型企業中。
對於為什麼選擇Oracle資料庫，而不是其他的資料庫?
第一，是因為Oracle資料庫占據最大的市場份額，並且越來越大，市場需要很多Oracle資料庫方面的人才，中國有句老話說"做對事，選對人"，是同樣的道理;第二，是很多非Oracle資料庫的老系統正往Oracle資料庫遷移，其他資料庫市場佔有率在減少，其他資料庫工作者有面臨失業的風險;第三，Oracle有大量的官方學習文檔，還有部分中文文檔，可以有效地進行學習;第四，Oracle有大量的從業人員，有共同方向的朋友可以互相幫助，不再是孤膽英雄;第五，是可以很容易地從Oracle官方網站下載功能齊全的資料庫最新版本進行學習，可以讓你了解資料庫方面的最新發展趨勢等。
在此說明，以後的所有內容都是基於Oracle11g資料庫產品的，下面我們就簡單介紹一下Oracle11g的系列產品：
企業版(EnterpriseEdition)此版本包含了資料庫的所有組件，並且能夠通過購買選項和程序包來進一步對其增強。
能支持例如大業務量的在線事務處理OLTP(On-LineTransactionProcessing聯機事務處理系統)環境、查詢密集的數據倉庫和要求苛刻的互聯網應用程序。
標准版1(StandardEditionOne)此版本為工作組、部門級和互聯網、內聯網應用程序提供了前所未有的易用性和性價比。從針對小型商務的單伺服器環境到大型的分布式部門環境，該版本包含了構建重要商務應用程序所必需的全部工具。它僅許可在最高容量為2個處理器的伺服器上使用，支持Windows/Linux/UNIX操作系統，並支持64位平台操作系統。
標准版(StandardEdition)此版本提供了StandardEditionOne所不具有的易用性、能力和性能，並且利用真正的應用集群(RAC)提供了對更大型計算機和服務集群的支持。它可以在最高容量為4個處理器的單台伺服器上、或者在一個支持最多4個處理器的集群上使用，可支持Windows、Linux和UNIX操作系統，並支持64位平台操作系統。
簡化版此版本支持與標准版1、標准版和企業版完全兼容的單用戶開發和部署。通過將Oracle資料庫獲獎的功能引入到個人工作站中，該版本提供了結合世界上最流行的資料庫功能的資料庫，並且該資料庫具有桌面產品通常具有的易用性和簡單性，可支持Linux和Windows操作系統。
從存儲結構上來說，目前流行的資料庫主要包含以下兩種：
RDBMS：關系型資料庫，是指採用了關系模型來組織數據的資料庫;
NoSQL資料庫，是指那些非關系型的、分布式的資料庫。簡單來說，關系模型指的就是二維表格模型，而一個關系型資料庫就是由二維表及其之間的聯系所組成的一個數據組織。
關系型資料庫優點：
1、容易理解
二維表結構是非常貼近邏輯世界的一個概念，關系模型相對網狀、層次等其他模型來說更容易理解。
2、使用方便
通用的SQL語言使得操作關系型資料庫非常方便。
3、易於維護
豐富的完整性大大減低了數據冗餘和數據部移植的概率。
4、事務安全
所有關系型資料庫都不同程度的遵守事物的四個基本屬性，因此對於銀行、電信、證券等交易型業務是不可或缺的。
關系型資料庫的瓶頸：
1、高並發讀寫需求
網站的用戶並發性非常高，往往達到每秒上萬次讀寫請求，對於傳統型資料庫來說，硬碟I/O是一個很大的瓶頸。
2、海量數據的高效率讀寫
互聯網上每天產生的數據量是巨大的，對於關系型資料庫來說，在一張包含海量數據的表中查詢，效率是非常低的。
3、高擴展性和可用性
在基於WEB的結構中，資料庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，資料庫卻沒有辦法像WEBServer和APPLICATIONServer那樣簡單的通過添加更多的硬體和服務節點來擴展性能和負載能力。對於很多需要提供24小時不間斷服務的網站來說，對資料庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移。
NoSQL資料庫
NoSQL一詞首先是CarloStrozzi在1998年提出的。2009年再次提出了NoSQL一詞，用於指那些非關系型的、分布式的，且一般不保證遵循ACID原則的數據存儲系統。
NoSQL具有以下特點：
1、可以彌補關系型資料庫的不足
2、針對某些特定的需求而設計，可以具有極高的性能
3、大部分都是開源的，由於成熟度不夠，存在潛在的穩定性和維護性問題。
關系型資料庫適用於結構化數據，而非關系型資料庫適用於非結構化數據，二者優勢互補，相得益彰。
Oracle資料庫未來的發展方向是提供結構化、非結構化、半結構化的解決方案，實現關系型資料庫和NoSQL共存互補。值得強調的是，目前關系型資料庫仍是主流資料庫。
雖然NoSQL資料庫打破了關系型資料庫存儲的觀念，可以很好地滿足WEB2.0時代數據的存儲要求，但NoSQL資料庫也有自己的缺陷。在現階段的情況下，可以將關系型資料庫和NoSQL資料庫結合使用，相互彌補各自的不足。
關於資料庫及其代表產品Oracle今天就介紹這么多，有興趣的可以繼續深挖，希望我的介紹能讓你對資料庫有一個更深入的認識。如果有志於在這方面發展的話，就讓我們一起跟往事乾杯從頭再來。
Ⅲ Oracle資料庫基本知識
Oracle資料庫基本知識
Oracle Database，又名OracleRDBMS，或簡稱Oracle。是甲骨文公司的一款關系資料庫管理系統。本文為大家分享的是Oracle資料庫的基本知識，希望對大家有所幫助!
它是在資料庫領域一直處於領先地位的產品。可以說Oracle資料庫系統是目前世界上流行的關系資料庫管理系統，系統可移植性好、使用方便、功能強，適用於各類大、中、小、微機環境。它是一種高效率、可靠性好的適應高吞吐量的資料庫解決方案。
介紹
ORACLE資料庫系統是美國ORACLE公司(甲骨文)提供的以分布式資料庫為核心的一組軟體產品，是目前最流行的客戶/伺服器(CLIENT/SERVER)或B/S體系結構的資料庫之一。比如SilverStream就是基於資料庫的一種中間件。ORACLE資料庫是目前世界上使用最為廣泛的資料庫管理系統，作為一個通用的資料庫系統，它具有完整的數據管理功能;作為一個關系資料庫，它是一個完備關系的產品;作為分布式資料庫它實現了分布式處理功能。但它的所有知識，只要在一種機型上學習了ORACLE知識，便能在各種類型的機器上使用它。
Oracle資料庫最新版本為OracleDatabase 12c。Oracle資料庫12c引入了一個新的多承租方架構，使用該架構可輕松部署和管理資料庫雲。此外，一些創新特性可最大限度地提高資源使用率和靈活性，如Oracle Multitenant可快速整合多個資料庫，而Automatic Data Optimization和Heat Map能以更高的密度壓縮數據和對數據分層。這些獨一無二的技術進步再加上在可用性、安全性和大數據支持方面的主要增強，使得Oracle資料庫12c 成為私有雲和公有雲部署的理想平台。
就業前景
從就業與擇業的角度來講，計算機相關專業的大學生從事oracle方面的技術是職業發展中的最佳選擇。
其一、就業面廣：ORACLE幫助拓展技術人員擇業的廣度，全球前100強企業99家都在使用ORACLE相關技術，中國政府機構，大中型企事業單位都能有ORACLE技術的工程師崗位，大學生在校期間興趣廣泛，每個人興趣特長各異，不論你想進入金融行業還是電信行業或者政府機構，ORACLE都能夠在你的職業發展中給你最強有力的支撐，成為你最貼身的金飯碗。
其二、技術層次深：如果期望進入IT服務或者產品公司，Oracle技術能夠幫助提高就業的深度。Oracle技術已經成為全球每個IT公司必選的軟體技術之一，熟練掌握Oracle技術能夠為從業人員帶來技術應用上的優勢，同時為IT技術的深入應用起到非常關鍵的作用。掌握 Oracle技術，是IT從業人員了解全面信息化整體解決方案的基礎。
其三、職業方向多：Oracle資料庫管理方向、Oracle開發及系統架構方向、Oracle數據建模數據倉庫等方向。
Oracle資料庫漏洞分析：無需用戶名和密碼進入你的資料庫
一般性的資料庫漏洞，都是在成功連接或登錄資料庫後實現入侵;本文介紹兩個在2012年暴露的Oracle漏洞，通過這兩種漏洞的結合，可以在不掌握用戶名/密碼的情況下入侵Oracle，從而完成對數據的竊取或者破壞。這兩個漏洞就是CVE-2012-1675和CVE-2012-3137。
引言
國內外很多重要的系統都採用Oracle作為數據存儲的資料庫;在Oracle中存儲著企業或政府大量敏感的信息，在金錢或政治的誘導下，內外部黑客會想法利用管理、網路、主機或資料庫的自身漏洞嘗試入侵到資料庫中，以達到自身的目的。
本文的作者通過對Oracle倆種漏洞的組合研究，設計了一套在不掌握用戶名/密碼的方式入侵到Oracle中;這種方法，比傳統的需要登錄到資料庫中的入侵方法，具有更大的安全隱患和破壞性。
本文希望通過對這兩個漏洞和攻擊方法的介紹，能夠引起相關人員的重視，完善對資料庫安全的措施。
1、概要介紹
本文提供的方法是基於漏洞CVE-2012-1675和CVE-2012-3137對oracle資料庫的攻擊測試的方法。
CVE-2012-1675漏洞是Oracle允許攻擊者在不提供用戶名/密碼的'情況下，向遠程“TNS Listener”組件處理的數據投毒的漏洞。攻擊者可利用此漏洞將資料庫伺服器的合法“TNS Listener”組件中的數據轉向到攻擊者控制的系統，導致控制遠程組件的資料庫實例，造成組件和合法資料庫之間的中間人攻擊、會話劫持或拒絕服務攻擊。
CVE-2012-3137漏洞是Oracle Database 10g/11g身份驗證協議實現中存在一個設計缺陷，攻擊者無需認證即可遠程獲取資料庫用戶密碼哈希相關數據，從而可以離線暴力破解用戶密碼，進一步控制資料庫系統。
我們通過如下的步驟和過程可以實現對Oracle的入侵：
(1)利用CVE-2012-1675進行TNS劫持，在監聽下利用遠程注冊，注冊同名資料庫實例;
(2)新登陸的用戶，在TNS的負載均衡策略下，有可能流量登錄到偽造的監聽服務上;
(3)該監聽服務對用戶的登陸過程進行監控，並將相關數據流量轉發到真實的資料庫上;
(4)利用CVE-2012-3137獲得通訊過程中的認證相關信息;
(5)對認證相關信息進行離線的暴力破解，獲得登陸的密碼;
(6)試用破解的用戶名/密碼登陸Oracle，完成對Oracle中數據的訪問;
2、通過CVE-2012-1675進行TNS劫持
該漏洞存在於Oracle的所有版本，並且Oracle至今僅是發布了警告性通知，並未提供解決方案。
要想利用CVE-2012-1675漏洞做TNS劫持，首先需要了解TNS機制。如下圖所示oracle 通過在本地解析網路服務名到目標主機IP地址，服務埠號，目標資料庫名，把這些信息發送到oracle伺服器端監聽程序，最後再由監聽程序遞送DBMS。
其中關鍵點在於監聽會按照目標資料庫名遞送到名稱正確的資料庫。那麼如果一個監聽下有2個同名資料庫。監聽將自動按照負載均衡把這次訪問發送到負載低的資料庫上，進行連接訪問。資料庫注冊到監聽的方法就決定了，能否同時注冊同名資料庫在同一個監聽下。注冊方式分為本地注冊和遠程注冊，通過修改參數可以調整為遠程注冊。
下面是一段可用的TNS劫持的過程：
1.在劫持機上創建一個和目標資料庫實例同名的資料庫實例。
2.在劫持機上修改 tnsnames.ora 文件
添加
listener_name=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=目標機器IP)(PORT=目標機器埠)))
3.在劫持機上用SQL*Plus 順序執行下面步驟。
1.$ sqlplus / as sysdba
2. SQL> ALTER SYSTEM SETREMOTE_LISTENER='LISTENER_NAME';
3. SQL> ALTER SYSTEM REGISTER;
4.多個客戶端，向資料庫發起登錄。會劫持到一部分客戶端的登錄信息。
最終達到效果如下圖所示：
按照猜想同一個監聽下有2個同名實例。客戶端訪問監聽，監聽按照客戶端中的資料庫名信息分配資料庫，由於監聽下有2個同名資料庫，客戶端鏈接很可能會被分配到劫持者的資料庫實例下，再通過配置劫持者的本地監聽把客戶端請求指回原資料庫。結構圖如下：
測試客戶端鏈接196次。目標資料庫實例獲得113次，劫持資料庫實例獲得83次基本滿足負載均衡的假設。(註上面實例是local server 下面實例是 remote server)
通過以上方式我們可以截獲約一半左右客戶端發送到伺服器的合法鏈接。其中獲得了伺服器IP、埠號、資料庫位置、實例名、登錄用戶名等一系列明文信息和4組密文信息(AUTH_SESSKEY，AUTH_SESSKEY_CLIENT，AUTH_PASSWORD，AUTH_VFR_DATA)。
3、通過CVE-2012-3137進行密碼破解
CVE-2012-3137受影響的資料庫版本有11.2.0.3，11.2.0.2，11.1.0.7,有使用了SHA-1加密演算法的10.2.0.5和10.2.0.4，還有使用了SHA-1的10.2.0.3(運行在z/OS下)版本。
雖然這個漏洞在11.2.0.3中已經解決，但是僅僅資料庫客戶端和伺服器都升級到11.2.0.3並且sqlnet.ora文件中增加SQLNET.ALLOWED_LOGON_VERSION=12才有效。
正如CVE-2012-3137所描述Oracle為了防止第三方通過網路獲取登錄信息包。而對密碼進行了加密處理。本部分只以oracle11.1密碼如何破解為例進行說明。
在發起連接之後(oracle牽手完成)，客戶端和伺服器經過協商確定要使用的驗證協議。要完成這個任務，客戶端首先向資料庫發送一個包。包中包含客戶端主要信息和所請求的加密方式。資料庫確認加密方式有效後，發送一個確認服務包如下圖所示：
在通過安全網路服務完成任何所要求的協議之後，資料庫用戶被O3logon(oracle驗證方式) 進行驗證，這個協議執行一個序列來向資料庫證明客戶端擁有密碼。為了避免網路第三方截獲到密碼。首先客戶端發送用戶名到資料庫來表明用戶身份。資料庫端根據加密協議，其中96位的作為資料庫端密鑰，20位的作為偏移量，它對每個連接都是不同的。一個典型的資料庫端發給客戶端的密鑰如下：
AUTH_SESSKEY.....COCDD89FIGODKWASDF……………………
客戶端根據加密演算法向伺服器端發送96位的客戶端密鑰和64位的密碼密鑰。伺服器端計算客戶端傳入的密碼密鑰。如果計算後密碼密文和資料庫中存儲的16位密碼密文一致則驗證通過。
根據這個過程可知上面TNS劫持包中取得的加密信息：AUTH_SESSKEY，AUTH_SESSKEY_CLIENT，AUTH_PASSWORD，AUTH_VFR_DATA這四個值是解密的關鍵。我們把他們按照SHA1,MD5，AES192進行一系列處理。最終通過數據字典碰撞得到密碼明文。
下面這段網上公布的一段示例代碼，這段代碼與筆者的思路不完全相同，但也能大概地說明這個漏洞的攻擊過程：
import hashlib
from Crypto.Cipher import AES
def decrypt(session,salt,password):
pass_hash= hashlib.sha1(password+salt)
key =pass_hash.digest() + 'x00x00x00x00'
decryptor= AES.new(key,AES.MODE_CBC)
plain =decryptor.decrypt(session)
returnplain
session_hex ='6EAAB5422553A7598143E78767'
salt_hex = 'A7193E546377EC56639E'
passwords = ['test','password',''oracle','demo']
for password in passwords:
session_id= decrypt(session_hex.decode('hex'),salt_hex.decode('hex'),password)
print'Decrypted session_id for password "%s" is %s' %(password,session_id.encode('hex'))
ifsession_id[40:] == 'x08x08x08x08x08x08x08x08':
print'PASSWORD IS "%s"' % password
break
4、建議的預防措施
根據以上兩段分析，我們可以有如下的預防措施：
(1)在條件許可的情況下，對Oracle進行補丁升級，對Oracle打cpuoct2012-1515893補丁;注意對於cpuoct2012-1515893補丁要求伺服器端和應用伺服器端同時升級，否則應用系統將無法訪問Oracle;
(2)若無法對Oracle升級，要購買或安裝具備虛擬補丁功能的資料庫安全產品，防止對CVE-2012-3137和CVE-2012-1675的利用;
(3)建立足夠強健的口令，不要使用8位以下密碼，或者字典庫中的口令。
;Ⅳ 求助各位大蝦，本科畢業設計做Oracle資料庫
主要從幾個不同方面設計ORACLE資料庫優化方案：
一.資料庫優化自由結構OFA(Optimal flexible Architecture)
二、充分利用系統全局區域SGA（SYSTEM GLOBAL AREA)
三、資料庫設計中的優化策略
數據應當按兩種類別進行組織：頻繁訪問的數據和頻繁修改的數據。對於頻繁訪問但是不頻繁修改的數據，內部設計應當物理不規范化。對於頻繁修改但並不頻繁訪問的數據，內部設計應當物理規范化。
四、合理設計和管理表
1、利用表分區
分區將數據在物理上分隔開，不同分區的數據可以制定保存在處於不同磁碟上的數據文件里。
2、避免出現行連接和行遷移
3、控制碎片
4、別名的使用
別名是大型資料庫的應用技巧，就是表名、列名在查詢中以一個字母為別名，查詢速度要比建連接錶快1.5倍。
5、回滾段的交替使用
五、索引Index的優化設計
1、管理組織索引
索引可以大大加快資料庫的查詢速度，索引把表中的邏輯值映射到安全的RowID，因此索引能進行快速定位數據的物理地址。
六、多CPU和並行查詢PQO(Parallel Query Option)方式的利用
七、實施系統資源管理分配計劃
ORACLE 提供了Database Resource Manager（DRM,資料庫資源管理器）來控制用戶的資源分配，DBA可以用它分配用戶類和作業類的系統資源百分比。在一個OLDP系統中，可給聯機用戶分配75%的CPU資源，剩下的25%留給批用戶。另外，還可以進行CPU的多級分配。除了進行CPU資源分配外，DRM還可以對資源用戶組執行並行操作的限制。
八、使用最優的資料庫連接和SQL優化方案
九、充分利用數據的後台處理方案減少網路流量
1、合理創建臨時表或視圖
2、資料庫打包技術的充分利用
利用資料庫描述語言編寫資料庫的過程或函數，然後把過程或函數打成包在資料庫後台統一運行包即可。
3、數據復制、快照、視圖，遠程過程調用技術的運用
Ⅳ 求大神！用Oracle完成一個資料庫應用系統的設計全過程
//資料庫連接池 單例模式
import java.sql.Connection;
import java.sql.SQLException;
import com.mchange.v2.c3p0.ComboPooledDataSource;
import com.mchange.v2.c3p0.DataSources;
public final class ConnectionManager {
private static ConnectionManager instance;
private ComboPooledDataSource ds;
private ConnectionManager() throws Exception {
ds = new ComboPooledDataSource();
ds.setDriverClass("oracle.jdbc.driver.OracleDriver");
ds.setJdbcUrl("jdbc:oracle:thin:@127.0.0.1:1521:orcl");
ds.setUser("test");
ds.setPassword("testtest");
//初始化時獲取三個連接，取值應在minPoolSize與maxPoolSize之間。Default: 3 initialPoolSize
ds.setInitialPoolSize(3);
//連接池中保留的最大連接數。Default: 15 maxPoolSize
ds.setMaxPoolSize(10);
//// 連接池中保留的最小連接數。
//ds.setMinPoolSize(1);
//當連接池中的連接耗盡的時候c3p0一次同時獲取的連接數。Default: 3 acquireIncrement
ds.setAcquireIncrement(1);
//每60秒檢查所有連接池中的空閑連接。Default: 0 idleConnectionTestPeriod
ds.setIdleConnectionTestPeriod(60);
//最大空閑時間,25000秒內未使用則連接被丟棄。若為0則永不丟棄。Default: 0 maxIdleTime
ds.setMaxIdleTime(25000);
//連接關閉時默認將所有未提交的操作回滾。Default: false autoCommitOnClose
ds.setAutoCommitOnClose(true);
//定義所有連接測試都執行的測試語句。在使用連接測試的情況下這個一顯著提高測試速度。注意：
//測試的表必須在初始數據源的時候就存在。Default: null preferredTestQuery
ds.setPreferredTestQuery("select sysdate from al");
// 因性能消耗大請只在需要的時候使用它。如果設為true那麼在每個connection提交的
// 時候都將校驗其有效性。建議使用idleConnectionTestPeriod或automaticTestTable
// 等方法來提升連接測試的性能。Default: false testConnectionOnCheckout
ds.setTestConnectionOnCheckout(true);
//如果設為true那麼在取得連接的同時將校驗連接的有效性。Default: false testConnectionOnCheckin
ds.setTestConnectionOnCheckin(true);
//定義在從資料庫獲取新連接失敗後重復嘗試的次數。Default: 30 acquireRetryAttempts
ds.setAcquireRetryAttempts(30);
//兩次連接中間隔時間，單位毫秒。Default: 1000 acquireRetryDelay
ds.setAcquireRetryDelay(1000);
//獲取連接失敗將會引起所有等待連接池來獲取連接的線程拋出異常。但是數據源仍有效
//保留，並在下次調用getConnection()的時候繼續嘗試獲取連接。如果設為true，那麼在嘗試
//獲取連接失敗後該數據源將申明已斷開並永久關閉。Default: false breakAfterAcquireFailure
ds.setBreakAfterAcquireFailure(true);
// <!--當連接池用完時客戶端調用getConnection()後等待獲取新連接的時間，超時後將拋出
// SQLException,如設為0則無限期等待。單位毫秒。Default: 0 -->
// <property name="checkoutTimeout">100</property>
// <!--c3p0將建一張名為Test的空表，並使用其自帶的查詢語句進行測試。如果定義了這個參數那麼
// 屬性preferredTestQuery將被忽略。你不能在這張Test表上進行任何操作，它將只供c3p0測試
// 使用。Default: null-->
// <property name="automaticTestTable">Test</property>
// <!--JDBC的標准參數，用以控制數據源內載入的PreparedStatements數量。但由於預緩存的statements
// 屬於單個connection而不是整個連接池。所以設置這個參數需要考慮到多方面的因素。
// 如果maxStatements與maxStatementsPerConnection均為0，則緩存被關閉。Default: 0-->
// <property name="maxStatements">100</property>
// <!--maxStatementsPerConnection定義了連接池內單個連接所擁有的最大緩存statements數。Default: 0 -->
// <property name="maxStatementsPerConnection"></property>
// <!--c3p0是非同步操作的，緩慢的JDBC操作通過幫助進程完成。擴展這些操作可以有效的提升性能
// 通過多線程實現多個操作同時被執行。Default: 3-->
// <property name="numHelperThreads">3</property>
// <!--用戶修改系統配置參數執行前最多等待300秒。Default: 300 -->
// <property name="propertyCycle">300</property>
}
public static final ConnectionManager getInstance() {
if (instance == null) {
try {
instance = new ConnectionManager();
} catch (Exception e) {
e.printStackTrace();
}
}
return instance;
}
public synchronized final Connection getConnection() {
try {
return ds.getConnection();
} catch (SQLException e) {
e.printStackTrace();
}
return null;
}
protected void finalize() throws Throwable {
DataSources.destroy(ds); //關閉datasource
super.finalize();
}
}
//調用資料庫連接池
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;
public class TestC3p0 {
public TestC3p0() {
// TODO 自動生成構造函數存根
}
public static void main(String[] args) {
// TODO 自動生成方法存根
ConnectionManager cm = ConnectionManager.getInstance();
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
String sql = "select sysdate from al";
for (int i = 0; i < 10000; i++) {
try {
conn = cm.getConnection();
System.out.println(conn);
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
rs.next();
System.out.println(rs.getString(1));
} catch (Exception ex) {
ex.printStackTrace();
} finally {
if (rs != null) {
try {
rs.close();
} catch (Exception e) {
}
}
if (stmt != null) {
try {
stmt.close();
} catch (Exception e) {
}
}
if (conn != null) {
try {
conn.close();
} catch (Exception e) {
}
}
}
try {
System.out.println(cm.ds.toString());
Thread.sleep(10000);
} catch (Exception e) {
// TODO: handle exception
}
}
}
}
Ⅵ 為什麼傳統行業幾乎都用Oracle，而互聯網行業幾乎都不用Oracle呢
其實早期得互聯網公司曾經不僅是Oracle 客戶，還都是大客戶，最典型的代表有兩個，一個是亞馬遜，一個是阿里巴巴，後來兩者都紛紛去掉了O，可見並不是什麼ZZ因素，一定有一些原因，我們一起來逐步撥開看看：
1.Oracle資料庫到底是為什麼設計的？
Oracle資料庫的理論源於1970年的一個論文， "A Relational Model of Data for Large Shared Data Banks". 在這個論文中，提出了一個資料庫的經典模型，也就是今天所謂的關系行資料庫 Relational Database. 這個論文，在當時驗證了關系模型的一些優勢。後來IBM基於這個論文開發了一個東西，叫SQL語言。 但是很奇怪的是，IBM沒有更快的基於SQL語言去開發一個資料庫，而Oracle在1979年第一個開發了商業級支持SQL語言的資料庫產品。 當時，資料庫主要處理的一個核心問題，就是幾個特點ACID，鑒於篇幅，我們無法論述其中的意思，但是其中最有意思的就是一致性的C。什麼意思呢，就是以銀行交易為例，你如果在取錢的一瞬間查詢余額有500，這個時候你取款，但是你恰好也告訴你家人在同一時間查詢，如果查詢到有500，他們也同時取款，會不會都成功呢？這個一致性的問題，對於銀行要求是強一致性，也就是不能有半點差錯。
2. 互聯網時代需要的資料庫是什麼？
到了互聯網時代，情況突然變了。比如我們都喜歡的知乎，微博這些信息流的App。 如果我發帖的瞬間，同時可能有很多人都在發帖，如果我們的App在全世界都在用，瞬間的用量峰值可能會因為某個熱點事件突然變得很高，這個和上世紀80年代的企業級應用完全不同，即便是銀行，我們還是可以保證當時的峰值大概有多少，因為營業點和ATM機的數量也是有限的，那時候你無法在手機上直接處理任何一筆交易。但是互聯網的到來改變了一切，這個峰值不僅難以預估，而且可能和平時的平均值差別巨大。這樣為了確保一個峰值，就去購買峰值所需的Oracle的License數量可能特別大。（Oracle是按照一個類似CPU數量或者用戶數量來確定價格，你可以簡單理解為用的峰值越高，你需要買的license越貴），這是一筆巨大的花費不說，而且還有另外一個問題。
3. 互聯網時代的應用需求不同。
在我之前的一個回答裡面寫道了, 亞馬遜工程師在優化自身的資料庫的時候， 他們發現「：」 大約70%的操作是鍵值類型的，其中只使用主鍵，只返回一行。大約20%的用戶會返回一組行，但仍然只對單個表進行操作。「這是一個偉大的發現——70%的操作竟然都沒有使用關系資料庫的核心功能！為什麼會這樣呢？因為互聯網時代的應用發生了變化。我舉個例子，你如果設計一個類似亞馬遜的電商網站的購物車，你允許客戶把自己想買的東西放在裡面。但是你設想一下，如果突然某個暢銷的產品被賣家下架了，但是這個產品被很多的客戶放在購物車里，你回想一下，銀行交易需要確保的那種強一致性，在這里有必要麼？如果你想強一致性，就需要這個商品下架的時候，清空每一個曾經加入購物車的這個商品。這樣任何一個修改產品的操作，都可能有無數個關聯的交易在那裡等著更新，可能商品的目錄更新這個事情，就會變得巨慢無比，而且毫無意義。為什麼說毫無意義呢，比如我在9點購物車放了一部手機，到10點商家賣光了，把這個產品下架了，這個時候如果商家只是在自己店面的頁面更新，但是你的購物車並不實時更新，即使最差的情況是什麼呢，就是10點的同時，你提交了一個購買的請求，這個購買的請求是需要保持一致性的，這個時候商家會返回一個失敗，因為這個商品不存在。你再刷新一看，哦，賣光了。。。你的用戶體驗絲毫不受影響。再比如互聯網的微博，如果我發一個微博就發上去，更新的時候，我不需要強一致性更新，那麼可能和我距離近的朋友第一時間看到了，距離遠的朋友可能稍晚一些看到了，有關系么？基本沒什麼影響，這些叫做分布式處理的方式在互聯網應用非常普遍。
4. 互聯網時代有了更多選擇
一方面開源資料庫逐步成熟，MySQL， Postgre這些後期之輩，陸續成熟且有越來越多的程序員能夠熟練掌握，並且利用開源實現接近商業資料庫的能力；另外一個方面，雲廠商的出現讓這個門檻更低，你不敢保證MySQL使用達到商業資料庫的可靠性，你可以藉助雲廠商的產品，比如亞馬遜雲計算的託管資料庫Aurora（兼容MySQL），這里非廣告，只是告訴大家這種雲廠商的產品讓你用開源，性能和商業資料庫接近，並且價格低廉，且無需運維或者很少運維成本，這樣的情況下，中小互聯網廠商就更多採用雲廠商的託管開源資料庫，自然不用Oracle這么昂貴的產品。
5. 數據發生了變化
前面講到微博這種信息流的數據格式很明顯和銀行交易類的關系格式有重大區別。其實互聯網時代，日誌，物聯網等產生了更多奇怪的數據格式，比如時序數據，一個物聯網的溫度計，可能每一毫秒鍾發一個溫度信息，你如果拿關系資料庫去存，可能很快就爆表了。。。但是物聯網就是這樣，而且這種數據幾乎從不更改，就是按照時間序列一直存。比如股票交易所的大盤數據也是類似，這種特殊數據格式帶來的需求在過去可能用關系資料庫湊合一下就可以了，但是今天，越來越多的不同類型格式需求，就需要按需設計和採用不同的資料庫。這些資料庫因為有雲的託管，你也不太需要運維，這樣採用的成本也不高，比如亞馬遜aws的Timestream資料庫，官方號稱兩百萬次寫入1KB的數據，價格才一美金，於是，越來越多的企業開始按需去採用專門構建的資料庫，而且大量採用雲上託管，這些都不是Oracle資料庫可以做的。
所以，各方面的綜合因素，導致今天的Oracle跟不上時代，也就逐步被慢慢取代了。前幾天，看到Gartner的全球資料庫市場排名，亞馬遜AWS取代了Oracle在全球資料庫廠商的位置，一個時代就這樣慢慢的被改變了，不知道我當時在Oracle 10g某個Package裡面的代碼是否還在？
Ⅶ 資料庫oracle實驗，隨便設計一個資料庫系統，急
這是讓我們幫你做作業嗎？
Ⅷ 設計一個oracle資料庫！
首先下載ORACLE安裝包
才能下載
根據自己電腦的硬體情況選擇適合的安裝版本安裝方法沒有跟其它的軟體安裝沒有什麼特別的地方，其中要注意的是SYS的密碼
：（1）需求分析階段：需求收集和分析，得到數據字典和數據流圖。
（2）概念結構設計階段：對用戶需求綜合、歸納與抽象，形成概念模型，用E-R圖表示。（3）邏輯結構設計階段：將概念結構轉換為某個DBMS所支持的數據模型。（4）資料庫物理設計階段：為邏輯數據模型選取一個最適合應用環境的物理結構。（5）資料庫實施階段：建立資料庫，編制與調試應用程序，組織數據入庫，程序試運行。（6）資料庫運行和維護階段：對資料庫系統進行評價、調整與修改。