A. 操作oracle數據時報樂觀鎖異常
戶A打開應用的界面，看到資料庫的某條記錄
b.用戶B打開應用的界面，看到同樣一條記錄
c. 用戶A對記錄做了修改
d. 對於web應用而言[假設沒有應用comet類似技術]，通常B不知道這個修改，這時B也對同樣這條記錄做修改，那B就有可能覆蓋A做的修改;
這個問題在資料庫中被稱為丟失更新問題
2.我自己對這個問題的理解過程是這樣的：
a. 不知道這個問題
我在做開發好長時間之後才意識到這個問題，意識到這個問題之後，我後來發現很長一段時間內都沒真正搞明白為什麼這是個問題-_- 而且我發現現在周圍的很多同事，尤其是新畢業的學生，其實也一直過了很長時間都沒明白這個問題，這說明吧不知道這個丟失更新問題是一個非常普遍的問題：)
b.用信號量以及操作之前再次驗證的方法解決
最開始的時候，測試發現了這樣一個問題，要求解決，我把操作系統的教科書搬來，對照著寫了一個信號量semaphore類[那時候還是jdk 1.4.2，jdk裡面沒有concurrent包]，花了好長時間測試這個semaphore的實現是正確的[重復發明輪子的血淚史..]，
然後用來控制這個操作，每次操作前獲取信號量，然後驗證，再做真正的資料庫操作。。。相當於在應用層每次都只做一件事。
c. 再次理解
再後來，我看了Tom的這本9i和10g的書，書中提到前面的丟失更新過程，大概有點明白為什麼這是個問題
.png
但是其實我有個疑問，對於資料庫中的記錄而言，A做的修改本來就有可能被B覆蓋的，為什麼這會是一個丟失更新問題呢? 正好項目裡面又出現了類似的情況，我仔細觀察了下，終於明白為什麼這是個問題，以及為什麼要使用對應的樂觀鎖悲觀鎖方案了。下面對此做詳細說明
3. 一個比較清楚的場景
下面這個假設的實際場景可以比較清楚的幫助我們理解這個問題：
假設當當網上用戶下單買了本書，這時資料庫中有條訂單號為001的訂單，其中有個status欄位是』有效』,表示該訂單是有效的;
後台管理人員查詢到這條001的訂單，並且看到狀態是有效的
用戶發現下單的時候下錯了，於是撤銷訂單，假設運行這樣一條SQL: update order_table set status = 『取消』 where order_id = 001;
後台管理人員由於在b這步看到狀態有效的，這時，雖然用戶在c這步已經撤銷了訂單，可是管理人員並未刷新界面，看到的訂單狀態還是有效的，於是點擊」發貨」按鈕，將該訂單發到物流部門，同時運行類似如下SQL，將訂單狀態改成已發貨:update order_table set status = 『已發貨』 where order_id = 001
如果當當的系統這樣實現，顯然不對了，肯定要挨罵了，明明已經取消了訂單，為什麼還會發貨呢?而且確實取消訂單的操作發生在發貨操作之前啊。 因為在這樣的實現下，後台管理人員無論怎麼做都有可能會出錯，因為他打開系統看到有效的訂單和他點發貨之間肯定有個時間差，在這個時間差的時候總是存在用戶取消訂單的可能。
4. 當時的詳細解決方法。幾年前當測試人員告訴我系統存在這個問題的時候，我的解決方法是這樣的， 首先，先把操作系統的教科書搬來，然後對照著了一個semaphore,然後反復測試各種情況證明寫的是正確的; 然後，
1. 獲取一個信號量，保證每次只能有一個線程進入下面的步驟
2. 檢查資料庫，看這條訂單是否狀態是有效的
a. 如果有效則繼續，進入發貨步驟 b) 如果無效則返回，釋放信號量，告訴用戶狀態已經發生改變
3. 發貨，釋放信號量
看到這里，也許很多人要罵我蠢了，直接把SQL語句改成下面這樣吧就可以了么? update order_table set status = 『已發貨』 where order_id = 001 and status = 『有效』 是的，的確是這樣。雖然我當時的項目的情況比和這個稍微復雜一點，涉及到多張表格，不能直接這么做，但當時的確不知道這個更新丟失問題，也沒想到合適的類似方式，於是就在應用層做了這么一個每次實際上只能有一個用戶在做真正的更新這樣一個方式來解決，這樣做的結果是，在應用層單獨做了類似這么一個鎖的機制。我記得當時的項目畢業答辯的時候，老師問我同步的這個問題不直接用資料庫的鎖的方案來解決?我當時胡亂回答了下，後來想起來，其實壓根沒理解老師的意思-_- 而且這樣做有一個問題，假設在特殊情況下，這條訂單被DBA直接修改了，沒有經過應用，那麼應用做這個操作也會是錯的，因為在2.a到3之前的這段時間，有可能正好是DBA直接修改的時候。那麼3做的操作也是不對的。 而且，現實情況是在後來的幾年開發過程中，我也的確在一些不同的項目代碼中看到，其他很多人也在使用類似的代碼解決測試人員告訴他們的這些同步問題-_-
5.正確而簡潔的解決方法
問題清楚了，也說明了我曾經使用的解決方案也是一個簡潔直接的解決方案，純粹是把簡單問題復雜化，下面說說實際有效的解決方案; 就這個丟失更新問題，可以通過資料庫的鎖來實現，基本兩種思路，一種是悲觀鎖，另外一種是樂觀鎖; 簡單的說就是一種假定這樣的問題是高概率的，最好一開始就鎖住，免得更新老是失敗;另外一種假定這樣的問題是小概率的，最後一步做更新的時候再鎖住，免得鎖住時間太長影響其他人做有關操作;
6. 樂觀鎖的方法
這里先說web開發中常用的樂觀鎖的方法：
1.很簡單，就是使用前面所說的這樣一條SQL，這其實是所謂使用」前鏡像」的方式來保證需要更新的數據是符合要求的，
update order_table set status = 『已發貨』 where order_id = 001 and status = 『有效』 Tom的書上舉的例子是對所有列做更新，所以他的SQL大致如下 Update table set col1 = newcol1value, col2 = newcol2value…. where col1 = oldcol1value and col2 = oldcol2value…. 這個我覺得需要根據應用具體分析，如果需要判斷所有的值，那就判斷所有的值，如果只關心其中一個或部分值，那隻需要取相關的值就好了，就比如這里的訂單的狀態
2.使用版本列[比如時間戳
這個方法比較簡單，也最常用，就是在資料庫表格中加一列last_modified_date，就是最後更新的時間，每次更新的時候都將這列設成systimestamp，當前系統時間;
然後每次更新的時候，就改成這樣 Update table set col = newvalue where id = ** and last_modified_date = old last_modified_date 這樣，就可以檢驗出資料庫的值是否在上次查看和這次更新的時候發生了變化，如果發生了變化，那麼last_modified_date就變化了，以後的更新就會返回更新了0行，系統就可以通知用戶數據發生了變化，然後選擇刷新數據或者其他流程。
至於這個last_modified_date的維護，可以選擇讓應用每次都維護這個值，或者是使用存儲過程來包裝更新的操作，或者是使用觸發器來更新相關的值。幾種方法各有利弊，比如應用維護需要保證每段相關代碼都正確的維護了這個值;存儲過程有一定的開銷，通常很多開發對寫存儲過程可能也不熟練;觸發器是簡單的實現，但是也是有開銷的。具體使用哪種方法需要根據實際情況具體取捨。
3.使用校驗或Hash值
這種方法和前面的方法類似，無非是根據其他有實際意義的列來計算出一個虛擬的列，我個人覺得TOM在介紹這個純粹是介紹了一種」奇技淫巧」，反正我是在實際過程中不知道哪裡會需要這樣的解決方案，或許也是因為我知道的太少了吧：)
4.使用Oracle 10g的ORA_ROWSCN
這個就是利用10g的一個ora_rowscn特性，可以對每行做精確追蹤，不過這個要求在create table的時候就指定相關參數，表格如果創建了以後就不能用alter table來修改了，因為這依賴於物理的實際存儲。 同樣，我覺得這也可以歸為」奇技淫巧」一類; 具體如果有興趣了解詳情的話，可以參考Tom的書
我們一直都在努力堅持原創.......請不要一聲不吭，就悄悄拿走。
我原創，你原創，我們的內容世界才會更加精彩！
【所有原創內容版權均屬TechTarget，歡迎大家轉發分享。但未經授權，嚴禁任何媒體(平面媒體、網路媒體、自媒體等)以及微信公眾號復制、轉載、摘編或以其他方式進行使用。】
微信公眾號
TechTarget
官方微博
TechTarget中國
相關資源：oracle樂觀鎖和悲觀鎖詳細教程_oracle的樂觀鎖-Oracle文檔類資源...
點擊閱讀全文
打開CSDN，閱讀體驗更佳
Oracle資料庫悲觀鎖與樂觀鎖_diweikang的博客
注:對於悲觀鎖是針對並發的可能性比較大,而一般在我們的應用中用樂觀鎖足以。 Oracle的悲觀鎖需要利用一條現有的連接,分成兩種方式,從SQL語句的區別來看,就是一種是for update,一種是for update nowait的形式。 1. 執行select xxx ...
ORACLE悲觀鎖和樂觀鎖_hongwei3344661的博客
1、無論是選擇悲觀鎖策略,還是樂觀鎖策略。如果一個對象被上了鎖,那麼該對象都會受這個鎖的控制和影響。 2、選擇悲觀鎖策略,還是樂觀鎖策略,這主要是由應用和業務需求來確定的。如果你的應用和業務經常會出現從我看到要修改的記錄的...
oracle 樂觀鎖和悲觀鎖詳細教程
詳細介紹了Oracle中樂觀鎖、悲觀鎖的原理及應用，並有實例
基於ORACLE的樂觀鎖實現原理
2019獨角獸企業重金招聘Python工程師標准>>> ...
繼續訪問
Oracle之悲觀鎖和樂觀鎖_hys21的博客
根據保護的對象不同,Oracle資料庫鎖可以分為以下幾大類:DML鎖(data locks,數據鎖),用於實現並發存取並保護數據的完整性;DDL鎖(dictionary locks,字典鎖),用於保護資料庫對象的結構,如表、索引等的結構定義;內部鎖和閂(internal locks ...
oracle樂觀鎖和悲觀鎖詳細教程_oracle的樂觀鎖-Oracle文檔類資源...
內部包含oracle網路網盤下載鏈接以及密碼。 oci.dll 12版本全部 資源是從Oracle官方網站下載,已測試可用 【白雪紅葉】JAVA學習技術棧梳理思維導圖.xmind 樂觀鎖行級鎖 分布式鎖 分區排隊 一致性 一致性演算法 paxos zab nwr raft gossip ...
Oracle創建悲觀鎖和樂觀鎖
為了得到最大的性能，一般資料庫都有並發機制，不過帶來的問題就是數據訪問的沖突。為了解決這個問題，大多數資料庫用的方法就是數據的鎖定。 考慮下面的情況。如果我們先查詢到數據，然後更新數據。這樣會出現這樣的情況。A線程查詢的時候，B線程也在查詢，當A線程准備更新的時候，B線程先獲得 了更新鎖，將這些行鎖定了。A只能等待B更新完。當B線程更新完釋放鎖的時候，A獲得鎖，這時A會識別出欄位已經
繼續訪問
Oracle並發控制中的樂觀鎖
資料庫的管理員要分散他們的資料庫，以便處理基於Web，B2B，電子商務的訪問，快速的硬碟讀寫以及更多的資源或許只能解決一部分問題。疲乏的鎖機制甚至會削弱擁有很好資源的應用性能。樂觀鎖可以大大改善具有較多事務處理的資料庫載入性能，比如基於web的客戶端訪問。 悲觀鎖引發的問題： 大多數Oracle開發者已經非常熟悉悲觀鎖，即在對數據進行更新之前給數據加鎖。使用熟悉的SELECT...FOR UP
繼續訪問
oracle樂觀鎖悲觀鎖學習筆記(更新中)_Evaron.Z的博客
首先解釋下樂觀鎖和悲觀鎖的含義 樂觀鎖:樂觀鎖就是認為數據一般情況下不會造成沖突,所以在數據進行提交更新的時候,才會正式對數據的沖突與否進行檢測,如果發現沖突了,則返回錯誤的信息。 悲觀鎖:悲觀鎖就是對數據的沖突採取一種悲觀的...
【Oracle】樂觀鎖和悲觀鎖_◣NSD◥的博客_oracle悲觀鎖...
樂觀鎖對應於生活中樂觀的人總是想著事情往好的方向發展,悲觀鎖對應於生活中悲觀的人總是想著事情往壞的方向發展。這兩種人各有優缺點,不能不以場景而定說一種人好於另外一種人。 悲觀鎖 ...
Oracle樂觀鎖悲觀鎖
1.樂觀鎖 當處理對象狀態時為了防止沖突 例：一個下訂單的狀態status a.更新status為1購買，b取得status為1，這時a要退貨把status改為2. 這時如果b還按1的狀態去處理，發貨了。就出錯了。 正確的做法為: 當b發貨時，為了處理並發臟讀，需要先根據原status狀態去更新status為3訂單處理中 int res = update...
繼續訪問
【轉】 Oracle中樂觀鎖定的四種實現方式
<br />Oracle中樂觀鎖定的四種實現方式<br /> <br />轉自 http://www.blogjava.net/lihao336/archive/2009/09/04/293934.html<br /> 更新前在應用中存儲所要操作行的「前映像」，更新時使用存儲的舊記錄來判斷當前值是否已經改變； 使用一個特殊的列，這個列由一個資料庫觸發器或應用程序代碼維護，可以告訴我們記錄的 「版本」； 使用一個校驗和或散列值，這是使用原來的數據計算得出的； 使用新增的 Oracle 10g 特性 ORA_R
繼續訪問
oracle的悲觀鎖和樂觀鎖
目錄 1 悲觀鎖 1.1 單表 for update 1.2 關聯表for update 1.3 解除for update 鎖的佔用 1.4 悲觀鎖缺點 2 樂觀鎖 2.1 比對法 2.2 版本戳 2.3 timestamp型 2.4 例子Demo 問select *from person for update或update perso...
繼續訪問
Oracle的悲觀鎖和樂觀鎖
為了得到最大的性能，一般資料庫都有並發機制，不過帶來的問題就是數據訪問的沖突。為了解決這個問題，大多數資料庫用的方法就是數據的鎖定。 數據的鎖定分為兩種方法，第一種叫做悲觀鎖，第二種叫做樂觀鎖。什麼叫悲觀鎖呢，悲觀鎖顧名思義，...
繼續訪問
oracle鎖機制之悲觀鎖與樂觀鎖以及for update用法
目錄 1 悲觀鎖 1.1 單表 for update 1.2關聯表for update 1.3 悲觀鎖缺點 2樂觀鎖 2.1 比對法 2.2版本戳 2.3timestamp型 2.4 例子Demo 1 悲觀鎖 所謂的悲觀鎖：顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次拿數據的時候都會上鎖。這樣別人拿數據的時候就要等待直到鎖的釋放。 資料庫行級...
繼續訪問
oracle的樂觀鎖和悲觀鎖
一、問題引出 ① 假設當當網上用戶下單買了本書，這時資料庫中有條訂單號為001的訂單，其中有個status欄位是』有效』,表示該訂單是有效的； ② 後台管理人員查詢到這條001的訂單，並且看到狀態是有效的； ③ 用戶發現下單的時候下錯了，於是撤銷訂單，假設運行這樣一條SQL: update order_table set status = 『取消』 whe
繼續訪問
Oracle鎖定：悲觀與樂觀鎖詳解
Oracle資料庫悲觀鎖與樂觀鎖是本文我們主要要介紹的內容。有時候為了得到最大的性能，一般資料庫都有並發機制，不過帶來的問題就是數據訪問的沖突。為了解決這個問題，大多數資料庫用的方法就是數據的鎖定…… 以下是代碼片段： select*fromtestwhereid=10也就是沒有for update這種鎖定數據的語句的話，就不會造成阻塞了。另外一種情況，就是當資料庫數據被鎖定的時候，也
繼續訪問
樂觀鎖與悲觀鎖——解決並發問題
引言 為什麼需要鎖（並發控制）？ 在多用戶環境中，在同一時間可能會有多個用戶更新相同的記錄，這會產生沖突。這就是著名的並發性問題。 典型的沖突有： 丟失更新：一個事務的更新覆蓋了其它事務的更新結果，就是所謂的更新丟失。例如：用戶A把值從6改為2，用戶B把值從2改為6，則用戶A丟失了他的更新。 臟讀：當一個事務讀取其它完成一半事務的記錄時，就會發生臟讀取。例如：用戶A,B看到的...
繼續訪問
樂觀鎖和悲觀鎖策略的區別與實現
樂觀鎖和悲觀鎖策略的區別與實現 1、無論是選擇悲觀鎖策略，還是樂觀鎖策略。如果一個對象被上了鎖，那麼該對象都會受這個鎖的控制和影響。如果這個鎖是個排它鎖，那麼其它會話都不...
繼續訪問
oracle的共享鎖不起作用,ORACLE中的樂觀鎖、悲觀鎖、共享鎖、排他鎖
一、引入在資料庫操作中，如果不同的用戶或者事務並發地訪問同一數據，可能就會破壞數據到完整性，這時候我們就可以用鎖來保證數據的一致性。二、概念1. 悲觀鎖就是很悲觀地任認為我每次要修改數據時，其他的操作總會來改變我要修改的數據，於是就將其加鎖。這樣一來，其他人只能等待我先放開鎖後才能操作數據。請看以下的示例。造數：CREATE TABLE test_yyw(id NUMBER(4),name VAR...
繼續訪問
oracle 鎖定 問題
鎖（lock）機制用於管理對共享資源的並發訪問。 資料庫中使用鎖是為了支持對共享資源進行並發訪問，與此同時還能提供數據完整性和一致性。 在Oracle中，你會了解到： ? 事務是每個資料庫的核心，它們是「好東西」。 ? 應該延遲到適當的時刻才提交。不要太快提交，以避免對系統帶來壓力。這是因為，如果事務很長或很大，一般不會對系統有壓力。相應的原則是：在必要時才提交，但是此前不要提
繼續訪問
最新發布 oracle資料庫加悲觀鎖,Oracle 悲觀鎖跟樂觀鎖
EMPNO ENAME SAL7782 CLARK 2450.007839 KING 5000.007934 MILLER 1300.00在SQLplus中模擬應用可能執行的綁定調用，可以利用下面命名：SQL> variable empno numberSQL> variable ename varchar2(20)SQL> var...
繼續訪問
Oracle 樂觀鎖、悲觀鎖
oracle有悲觀鎖也有樂觀鎖。 悲觀鎖比較安全一些，可以防止丟失更新，但是就是互相等待，影響效率。 一般會用樂觀鎖，即開始操作時，樂觀的認為數據不會被其他人更改，直到提交時才加鎖檢查。比如在操作的表上加一列，保存個時間戳，提交時檢查是不是最新的。不過樂觀鎖失敗的可能性比較大。 樂觀鎖，大多是基於數據版本（ Version ）記錄機制實現。
繼續訪問
oracle樂觀鎖實例
oracle 悲觀鎖和樂觀鎖
寫評論
評論
收藏
點贊
踩
分享
前往CSDN APP閱讀全文
閱讀體驗更佳
CSDN
成就一億技術人
前往
B. oracle自動分區插入時報ora-14400
oerr ora 14400
14400, 00000, "inserted partition key does not map to any partition"
// *Cause: An attempt was made to insert a record into, a Range or Composite
// Range object, with a concatenated partition key that is beyond
// the concatenated partition bound list of the last partition -OR-
// An attempt was made to insert a record into a List object with
// a partition key that did not match the literal values specified
// for any of the partitions.
// *Action: Do not insert the key. Or, add a partition capable of accepting
// the key, Or add values matching the key to a partition specification
你的分區定義得有問題或插入的關鍵字不對所致，沒有建預設分區或最大值和最小值定義不合理。
C. 關於oracle資料庫 ORA-01400 錯誤
數據表設置了關鍵欄位或者必填欄位，根據錯誤提示應該是身份證號是必填欄位，不能插入Null空值，所以要檢查插入資料庫的語句是不是身份證號是空(Null)。
D. ora-14400: 插入的分區關鍵字未映射到任何分區
Cause: An attempt was made to insert a record into, a Range or Composite Range object, with a concatenated partition key that is beyond the concatenated partition bound list of the last partition -OR- An attempt was made to insert a record into a List object with a partition key that did not match the literal values specified for any of the partitions.
Action: Do not insert the key. Or, add a partition capable of accepting the key, Or add values matching the key to a partition specification
E. 如何處理Ora-14400這個錯誤
違反唯一約束條件了，可能是你的主鍵值重復了，如果是SEQ_DICTPARAM.NEXTVAL生成的值在資料庫里已經存在，則會報這個錯誤 可以先看下當前序列生成的值是多少： select SEQ_DICTPARAM.NEXTVAL from al; 然後查看資料庫里這個欄位的最大值是多少
F. 如何處理Ora-14400這個錯誤
應該是你插入數據的日期不在你所劃分的任何一分區所要求的時間之內！
祝你愉快，滿意請採納哦
G. Oracle資料庫報 ora-14280 怎麼解決
你好！
請您在命令行里執行：
alter session set "_oracle_script"=true;
完後直接在命令行里刪除user 試試吧！
肯定可以！
望採納
H. Oracle資料庫 ORA
發生ORA-01555有以下幾種原因:
(1).查詢SQL執行時間過長，回滾段太小。
(2).系統頻繁進行DML操作，導致UNDO循環復寫很快。
(3).塊清除(8i以後很少發生)
下圖模擬了(1),(2)情況ORA-01555發生的過程
0:00
查詢開始
0:01
另一個會話UPDATE塊1000000，回滾信息記錄在回滾段上。
0:01
update會話commit。回滾段仍在那裡，但是會被復寫。
1:00
查詢仍在進行
在塊200000上
。。。。。期間進行了大量的DML操作，不斷向undo中寫入
4:00
查詢仍在進行
在塊600000上。
4:01
UNDO已滿，開始覆蓋，將0:01寫入的回滾段覆蓋。
4:30
查詢到1000000時
發現查詢開始已經被修改了，進入回滾段試圖找到那個塊的撤銷信息，從而得到一致讀。這時發現需要的信息已經不存在，ORA-01555出現，查詢失敗。
(3)發生的情況是:下一個session在塊修改後第一次訪問它時，需要檢查最後修改塊的事務是否仍被激活，一旦確定沒有激活就執行清除塊操作。為了清除塊，ORACLE需要訪問前一事務的回滾段，但是發現該回滾段已經被復寫，這時也會發生ORA-01555.
解決和預防的方法有:
(1).使用合適大小的事務，沒有提交太頻繁。
(2).增加更多的回滾段，延長undo區被復寫的時間。
(3).降低查詢的運行時間。(推薦做法)。
I. 我用的是oracle資料庫，ORA-01400: 無法將 NULL 插入 ("SYSTEM"."PIZZA"."FACET")
檢查是否插入SYSTEM用戶下PIZZA表的FACET欄位時，有null值。
如果確定要將null值插入到這個欄位，那麼必須刪除這個欄位上的not null 約束
J. 關於Oracle 分區實現和操作的幾個問題
1. 組合分區表的創建方式（"范圍-哈稀"），見附1
2. 樓主的需求，即"范圍-范圍分區"，在ORACLE 9i, 10g經過測試都是不能實現的
在附1的基礎上修改為"范圍-范圍"組合分區，創建時報錯：ORA-14151：無效的表分區方法
3. 關於sxdtgsh兄的回答，我測了
3.1 沒有maxvalue上限分區設置，在插入超出分區的數據時會報錯ORA-14400: 插入的分區關鍵字未映射到任何分區
3.2 按回答的語句創建分區表沒有問題，但數據無法按照樓主的需求分布
＝＝＝＝附1
附錄：創建"范圍-哈稀"組合分區表
CREATE TABLE TAB11 (ID NUMBER,DT DATE)
PARTITION BY RANGE (DT)
SUBPARTITION BY HASH (ID) SUBPARTITIONS 2 -- 自分區個數，可以不寫，由系統判斷
(
PARTITION Y2012 VALUES LESS THAN (TO_DATE('2013-01-01','YYYY-MM-DD'))
(
SUBPARTITION Y2012_H1
,SUBPARTITION Y2012_H2
)
,PARTITION Y2013 VALUES LESS THAN (TO_DATE('2014-01-01','YYYY-MM-DD'))
(
SUBPARTITION Y2013_H1
,SUBPARTITION Y2013_H2
)
,PARTITION YMAX VALUES LESS THAN (MAXVALUE)
(
SUBPARTITION YMAX_H1
,SUBPARTITION YMAX_H2
)
)
＝＝＝＝附2，請樓主檢查最後查詢的數據分布
create table T_TEST
(
ID NUMBER(20) NOT NULL,
TIME DATE NOT NULL
)
partition by range(TIME, ID) -- 按時間、ID范圍分區 這個例子是按年的
(
partition P_2012_10 values less than (to_date('2013-01-01','yyyy-MM-dd'), 10),
partition P_2012_20 values less than (to_date('2013-01-01','yyyy-MM-dd'), 20),
partition P_2012_MAX values less than (to_date('2013-01-01','yyyy-MM-dd'), MAXVALUE),
partition P_2013_10 values less than (to_date('2014-01-01','yyyy-MM-dd'), 10),
partition P_2013_20 values less than (to_date('2014-01-01','yyyy-MM-dd'), 20),
partition P_2013_MAX values less than (to_date('2014-01-01','yyyy-MM-dd'), MAXVALUE),
partition P_MAX values less than (MAXVALUE,MAXVALUE)
);
INSERT INTO T_TEST VALUES (1,TO_DATE('20121204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (12,TO_DATE('20121204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (32,TO_DATE('20121204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (2,TO_DATE('20131204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (12,TO_DATE('20131204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (33,TO_DATE('20131204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (3,TO_DATE('20141204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (23,TO_DATE('20141204 00:00:00','YYYYMMDD HH24:MI:SS'));
INSERT INTO T_TEST VALUES (43,TO_DATE('20151204 00:00:00','YYYYMMDD HH24:MI:SS'));
SELECT * FROM T_TEST;
SELECT * FROM T_TEST PARTITION(P_2012_10);
SELECT * FROM T_TEST PARTITION(P_2012_20);
SELECT * FROM T_TEST PARTITION(P_2012_MAX);
SELECT * FROM T_TEST PARTITION(P_2013_10);
SELECT * FROM T_TEST PARTITION(P_2013_20);
SELECT * FROM T_TEST PARTITION(P_2013_MAX);
SELECT * FROM T_TEST PARTITION(P_MAX);