⑴ oracle 資料庫導入怎麼做 有圖片最好 謝謝
1 建立一個新表，並規定其欄位和欄位長度
2 寫控制文件，依照新表格式寫好源數據文件
3 ！退出，通過控制文件將源數據導入新表
OK
現在不方便截圖，只能這么簡單的描述了。。。
⑵ 資料庫軟體的Oracle
Oracle來歷
70年代 一間名為Ampex的軟體公司，正為中央情報局設計一套名叫Oracle的資料庫，Ellison是程序員之一。Oracle是世界領先的信息管理軟體開發商，因其復雜的關系資料庫產品而聞名。Oracle資料庫產品為財富排行榜上的前1000家公司所採用，許多大型網站、銀行、證券、電信等都選用了Oracle系統。
1977年艾利森與女上司Robert Miner創立「軟體開發實驗室」（Software Development Labs），當時IBM發表「關系資料庫」的論文，艾利森以此造出新資料庫，名為甲骨文。
1978年公司遷往矽谷，更名為「關系式軟體公司」 (RSI)，兩年後，共有8名員工，年收入少於100萬美金。最先提出「關系資料庫」的IBM採用RSI的資料庫。1982年再更名為甲骨文(Oracle)。
1984年三年內，先後進軍加拿大、荷蘭、英國、奧地利、日本、德國、瑞士、瑞典、澳大利亞、芬蘭、法國、香港、挪威、西班牙。1986年上市時，年收入暴升至5500萬美元，同年3月招股，集資3150萬美元。1987年年收入達到 1.31 億美元，甲骨文一年後成為世界第四大軟體公司。兩年內再進軍墨西哥、巴西、中國、塞普勒斯、馬來西亞、新加坡及紐西蘭。一年後，收入再升一倍至2.82億美元。1990年甲骨文兩年內揮軍進入智利、希臘、韓國、葡萄牙、土耳其、委內瑞拉、台灣、比利時、阿根廷、哥倫比亞、哥斯大黎加及菲律賓等地，但是當年甲骨文的業績首次發生虧損，市值急跌80%，艾利森首次安排資深管理人員參與經營。
1992年旗艦產品Oracle 7面世，使該公司業務重新步上軌道，年收入達到11.79億美元。曾被視為甲骨文接班人、但後來被踼出局的Raymond Lane擔任營運總監。1995年艾利森宣布PC已死，把全數產品推向互聯網發展，並另組「網路計算機公司」（Network Computer），銷售「網路計算機」，最終被淘汰收場。2000年科網接近尾聲時，推出E-Business Suite，搶占應用產品市場，與昔日的生意夥伴構成嚴重利益沖突。同期微軟及IBM數據技術提升，此後Oracle新增訂單數目的佔有率，在兩年內下跌6.6%，業務倒退10%。2003年敵意收購仁科軟體公司，引起業界哄動。兩公司的爭議新聞層出不窮。同年美國司法部落案阻止甲骨文收購。 2009年4月20日，甲骨文公司宣布將以每股9.50美元，總計74億美金收購太陽計算機系統公司。
Oracle發展歷程
Oracle在1979年的夏季發布了可用於DEC公司的PDP-11計算機上的商用ORACLE產品，這個資料庫產品整合了比較完整的sql實現，其中包括子查詢、連接及其他特性。但不得不說，軟體不是很穩定，並缺少事務處理這樣的重要功能。出於市場策略，公司宣稱這是該產品的第二版，但卻是實際上的第一版。之所以被命名為第2版而不是第1版，是因為Ellison認為潛在的客戶更願意購買第2個版本，而不是初始版本。（雖然這樣做有些不太誠實，還是要承認這是個十分高明的技巧。還有一些公司把自己賣給客戶的版本叫做1.0 ，學學1979年的ORACLE吧！）多年以後的今天，ORACLE公司聲稱是他們第一個提供了第一個SQL關系型資料庫管理系統。
1983年3月，發布了ORACLE第三版。Miner和Scott歷盡艱辛用C語言重新寫就這一版本。C語言當時推出不久，用它來寫ORACLE軟體也是具有一定的風險的，但除此之外，別無他法。很快就證明了這樣做是多麼的正確：C編譯器便宜而又有效，還有很好的移植性。從現在起，ORACLE產品有了一個關鍵的特性：[可移植性]。ORACLE第三版還推出了SQL語句和事務處理的「原子性」--SQL語句要麼全部成功，要麼全部失敗，事務處理要麼全部提交，要麼全部回滾。ORACLE第3版還引入了非阻塞查詢，使用存儲在Before Image File中的數據來查詢和回滾事務，從而避免了讀鎖定（read lock）的使用（雖然通過使用表級鎖定限制了它的吞吐量）。同樣是1983年，IBM發布了姍姍來遲的Database 2（DB2），但只可在MVS上使用。不管怎麼說，ORACLE已經佔取了先機。 在開發第三版還沒有結束的時候，Scott離開了ORACLE。當時用C語言改寫ORACLE的壓力很大，無休止的軟體調試終於讓Scott不堪重負，選擇了一走了之。把剩下的重擔交給了Miner一個人。在出售了自己的4%的股票之後，Scott 後來創建了Gupta公司（現更名為Centura Software）和PointBase公司（提供百分之百純Java嵌入式資料庫），都是開發和資料庫相關的產品。多年後有人問到他的4%的ORACLE股票的時候，Scott，這個曾經給ORACLE寫出第一行代碼的技術高手，也只能報以一笑了。如果能堅持下來，那是一筆幾億美金的財富。不過當時的Scott沒有那麼多的想法，他只是太累了。
1984年10月，ORACLE發布了第四版產品。產品的穩定性總算得到了得到了一定的增強，用Miner的話說，達到了「工業強度」。但是還不夠令人滿意，用戶對產品的抱怨似乎永無休止。這一版增加了讀一致性（Read Consistency），這是資料庫的一個關鍵特性，可以確保用戶在查詢期間看到一致的數據。也就是說，當一個會話正在修改數據時，其他的會話將看不到該會話未提交的修改。可以看到，在ORACLE第四版之前，產品始終是不穩定的，但是ORACLE的這群銷售人員，主要是Ellison，他在宣傳ORACLE的時候總是要誇大其詞，但他就是有能力把軟體賣出去，而且，還賣得很好，不得不承認，這的確有些神奇。讓我們看看1984年軟體市場的情形，在資料庫市場上的霸主是Asnton-Tale公司，他們的拳頭產品是剛推出不久的dBase III（確切的說dBase是PC上的資料庫軟體霸主），剛剛成為全球第三大的獨立軟體公司（第一和第二分別是微軟、Lotus，ORACLE在當時還排不上號），這一年，也是蘋果公司Macintosh誕生的年度，Steven Jobs用這個拳頭產品挑戰老大哥IBM。同樣在這一年中，ORACLE公司的開發人員剛剛把產品移植到PC上。這是最好的年代，也是最壞的年代。數以千計的小公司在軟體領域里爭斗不休，新公司如雨後春筍般成立，ORACLE如何才能於不敗之地？
在1985年，ORACLE發布了5.0版。有用戶說，這個版本算得上是ORACLE資料庫的穩定版本。這也是首批可以在Client/Server模式下運行的的RDBMS產品，在技術趨勢上，ORACLE資料庫始終沒有落後。這意味著運行在桌面PC機（客戶機）上的商務應用程序能夠通過網路訪問資料庫伺服器。1986年發布的5.1版還支持分布式查詢，允許通過一次性查詢訪問存儲在多個位置的數據。
1988年發布第6版，由於過去的版本在性能上屢受詬病，Miner帶領著工程師對資料庫核心進行了重新的改寫。引入了行級鎖（row-level locking）這個重要的特性，也就是說，執行寫入的事務處理只鎖定受影響的行，而不是整個表。這個版本引入了還算不上完善的PL/SQL（Proceral Language extension to SQL）語言。第6版還引入了聯機熱備份功能，使資料庫能夠在使用過程中創建聯機的備份，這極大地增強了可用性。同時在這一年，ORACLE開始研發ERP軟體。
1997年，Oracle推出了面向網路計算的資料庫Oracle8
1999年，Oracle正式提供世界上第一個Internet資料庫Oracle8i。
2001年6月，Oracle又推出了新一代Internet電子商務基礎架構Oracle9i。
2004年，Oracle發布oralce10g。
2007年7月12日，甲骨文公司在美國紐約宣布推出資料庫Oracle 11g，。
2013年7月8日，最新一代的全球領先的資料庫Oracle Database 12c全面上市，這是Oracle資料庫的最新版本。
⑶ Oracle系統的結構
ORACLE資料庫系統為具有管理ORACLE資料庫功能的計算機系統。每一個運行的ORACLE資料庫與一個ORACLE實例（INSTANCE）相聯系。一個ORACLE實例為存取和控制一資料庫的軟體機制。每一次在資料庫伺服器上啟動一資料庫時，稱為系統全局區（SYSTEM GLOBAL AREA）的一內存區（簡稱SGA）被分配，有一個或多個ORACLE進程被啟動。該SGA 和 ORACLE進程的結合稱為一個ORACLE資料庫實例。一個實例的SGA和進程為管理資料庫數據、為該資料庫一個或多個用戶服務而工作。
在ORACLE系統中，首先是實例啟動，然後由實例裝配（MOUNT）一資料庫。在松耦合系統中，在具有ORACLE PARALLEL SERVER 選項時，單個資料庫可被多個實例裝配，即多個實例共享同一物理資料庫。
進程結構和內存結構
進程是操作系統中的一種機制，它可執行一系列的操作步。進程是由多個線程組成的。在有些操作系統中使用作業(JOB)或任務(TASK)的術語。一個進程通常有它自己的專用存儲區。ORACLE進程的體系結構設計使性能最大。
ORACLE實例有兩種類型：單進程實例和多進程實例。
單進程ORACLE（又稱單用戶ORACLE）是一種資料庫系統，一個進程執行全部ORACLE代碼。由於ORACLE部分和客戶應用程序不能分別以進程執行，所以ORACLE的代碼和用戶的資料庫應用是單個進程執行。
在單進程環境下的ORACLE 實例，僅允許一個用戶可存取。例如在MS-DOS上運行ORACLE 。
多進程ORACLE實例（又稱多用戶ORACLE）使用多個進程來執行ORACLE的不同部分，對於每一個連接的用戶都有一個進程。
在多進程系統中，進程分為兩類：用戶進程和ORACLE進程。當一用戶運行一應用程序，如PRO*C程序或一個ORACLE工具（如SQL*PLUS），為用戶運行的應用建立一個用戶進程。ORACLE進程又分為兩類：伺服器進程和後台進程。伺服器進程用於處理連接到該實例的用戶進程的請求。當應用和ORACELE是在同一台機器上運行，而不再通過網路，一般將用戶進程和它相應的伺服器進程組合成單個的進程，可降低系統開銷。然而，當應用和ORACLE運行在不同的機器上時，用戶進程經過一個分離伺服器進程與ORACLE通信。它可執行下列任務：
對應用所發出的SQL語句進行語法分析和執行。
從磁碟（數據文件）中讀入必要的數據塊到SGA的共享資料庫緩沖區（該塊不在緩沖區時），將結果返回給應用程序處理。
系統為了使性能最好和協調多個用戶，在多進程系統中使用一些附加進程，稱為後台進程。在許多操作系統中，後台進程是在實例啟動時自動地建立。一個ORACLE實例可以有許多後台進程，後台進程的名字為：
DBWR資料庫寫入程序
LGWR日誌寫入程序
ARCH歸檔
RECO 恢復
LCKn 封鎖 。
⑷ 遇到大規模oracle壞塊該怎麼處理
最近一兩個月，一直有場景化運維、場景化大數據分析的聲音圍繞在耳畔，以Gdevops全球敏捷運維峰會杭州站上新炬網路執行副總裁程永新的「 一切沒有場景驅動的運維平台建設都是假大空！ 」最為振聾發聵。我們一直在談技術，談原理，談內核，總以為「懂了」這些的人，就勢必能廣闊天地大有所為。
技術固然重要，但偏離了業務/應用場景的技術，無法呈現業務價值的技術就非常不重要。
技術也應該是場景驅動的，對於運維技術人員來說，離開場景學習的所謂高深技術，只是浪費時間。所以新同事進入一個新團隊後，能使技術更好發揮作用的環境、流程的考核會占據了另外的三分之二。
今天來談談Oracle壞塊問題。 壞塊問題，相信做過兩三年Oracle維護、支持的DBA都會遇到過，即使從來沒遇到過的，看過Oracle 官方文檔的甚至是會度娘或者谷哥的，應該也知道基本的處理手段。
這是我內部分享的一個簡單思維導圖，如果有遺漏，歡迎在後面評論補充。
面試的時候通常是這么問的：你了解Oracle壞塊么？壞塊為什麼會產生？描述一下你處理過的壞塊案例細節？如果你負責的好幾個資料庫都突然發生了壞塊，你會怎麼做？
通常，前面幾個問題的回答都不會太差。但是最後一個問題的回答，鮮有能出眾的。原因在於面太窄，思維太窄。如果這個時候你還要一個個庫的去看alert日誌，那麼顯然就走錯了方向。
現實情況就是，我們的資料庫可能是五六十套，或者上百套，你一套套庫的去看這些日誌里的報錯的塊，再根據塊找到對象，確定是表還是索引，再去用壞塊的修復手段去修復…….那麼，所有人都會被你害了。
我們經歷過，花了兩天的時間，都沒修復完一個庫中幾萬個壞塊的情況，在其他大牛還在哼哧哼哧做恢復的時候，我向領導提議啟用了新的方案，在大老闆沒有完全失去耐性的情況下恢復了業務。
真正正確的做法是，如果確定壞塊數量為數眾多，趕緊停業務，切災備，後面再補數據。 災備是干什麼吃的，養庫千日，用庫一時，就在這個時候了！
非常可惜的是，大多數來面試的DBA會非常糾結於用block recover，還是用dbms_repair，還是用BBED，還是……
那麼，什麼時候往上申報，要切災備？
且不談許多公司的災備形同虛設，關鍵時候不敢切的事情。就算這些災備都是實實在在可用的，恐怕也不是說切立即就能切的，切災備涉及到應用、網路、主機、存儲等多方面的調整。
那麼多久應該切呢？ 一般的企業從故障處理開始，預估2小時之內不能讓業務恢復正常運行的，應該申報切災備。當然，如果是金融行業，特別是證券基金行業，1分鍾之內故障還沒恢復，就要知會證監會，半個小時沒有恢復就會受到同行業通報，所以要切就應該在這個時間之內申報。
問題又回到了原點。你得先有規劃，作為企業的重要系統，你得先建設災備環境，而且是有效的災備，並且應該事先有一個災備切換預案。
作為DBA來說，動作敏捷的檢查資料庫的情況，並及時匯報非常重要。其實這里，又想說自動運維平台了。通過簡單的按鈕點點，就能快速知道告警日誌里的壞塊涉及什麼對象，是不是就好很多呢？
繼續往回看，面試的問題是什麼？是多個資料庫同時發現大量壞塊。
作為一個經驗豐富的運維管理人員，第一反應應該是，為什麼會同時發生呢？顯然是由於外因導致的。因此做好容災切換，業務恢復使用的第一時間，應該去看看這些資料庫共同的基礎是不是同樣的存儲、同樣的存儲管理軟體、卷管理軟體。
依我的經驗，大部分多個庫同時出現壞塊，都壞在存儲管理軟體身上。
有一次是Storage Foundation做卷復制的時候出現了軟體bug，IBM、Oracle、symentec等眾多廠家在「問題作戰室」里整整呆了一個月，各家公司二線、三線出具各種證據自己沒問題，最後最後才找到蛛絲馬跡，揪出來。
還有一次稍微容易些，存儲軟體狀態恢復後壞塊沒有恢復，一個個系統通過fsck命令來進行的修復。你說，這是什麼類型的壞塊呢？
作為有經驗的DBA，要解決問題，但不要急著去敲命令，站在更高點的位置來看待問題，可能會事半功倍。
很不幸的前兩天，某個朋友公司核心資料庫「莫名奇妙」地遇到中止了。原因不方便說，但是據說等故障恢復完之後，朋友已經抽了好幾包煙了。
我們先來看看，是由於LGWR終止了資料庫（ 註：做了一些脫敏處理 ）。
但是，重啟資料庫卻發現資料庫啟動不了，發現眾多數據文件發生了壞塊，資料庫根本不能open：
同時伴隨著類似的內部錯誤：
怎麼破？通過當天的資料庫備份結合歸檔進行恢復，遠遠比去修復壞塊要快。
⑸ 在Oracle中資料庫、表空間、表之間的關系
在oracle中，表空間是存儲概念上的，建立表空間需要有對應的數據文件，數據文件建立好之後直接會把一定的磁碟空間分配給它，這樣可以對資料庫的存儲空間進行有效的管理。然後在建表的時候指定對應的表空間，該表的數據就會都存在表空間對應的數據文件上，和Mysql那種每個表一個文件的方式比起來，存儲的可控性更強。
oracle和mysql不同，不存在mysql中那種資料庫的概念，而是實例的概念，當然，也可以在實例里建立不同的user來區分，每個user對應的表都是相對獨立的，比如兩個user下可以分別建同名的表，但又可以通過授權來交互使用。
建資料庫是在安裝oracle之後執行dbca建立實例。
建表空間語句是 CREATE TABLESPACE TBS_DEFAULT DATAFILE
'/app/oradata/sys_tbs/tbs_default.dbf' size 500M
LOGGING
EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
/
這里主要是需要指定對應的datafile。
建表基本都一樣，例如
create table (col_1 number(8),col_2 char(2),col_3 date)
tablespace tbs_default
/
資料庫就不要刪除了，這方面你看下關於user操作的語句就可以了。
drop tablespace tbs_name including contents and datafiles;--刪除表空間及數據文件
drop table tab_name purge; -- 刪除表。
⑹ orcal資料庫簡介
是Oracle吧，
Oracle資料庫的體系結構
Oracle資料庫包括Oracle資料庫伺服器和客戶端。
Oracle資料庫伺服器：
Oracle Server是一個對象一關系資料庫管理系統。它提供開放的、全面的、和集成的信息管理方法。每個Server由一個 Oracle DB和一個 Oracle Server實例組成。它具有場地自治性（Site Autonomy）和提供數據存儲透明機制，以此可實現數據存儲透明性。每個 Oracle資料庫對應唯一的一個實例名SID，Oracle資料庫伺服器啟動後，一般至少有以下幾個用戶：Internal，它不是一個真實的用戶名，而是具有SYSDBA優先順序的Sys用戶的別名，它由DBA用戶使用來完成資料庫的管理任務，包括啟動和關閉資料庫；Sys，它是一個 DBA用戶名，具有最大的資料庫操作許可權；System，它也是一個 DBA用戶名，許可權僅次於 Sys用戶。
客戶端：
為資料庫用戶操作端，由應用、工具、SQL* NET組成，用戶操作資料庫時，必須連接到一伺服器，該資料庫稱為本地資料庫（Local DB）。在網路環境下其它伺服器上的 DB稱為遠程資料庫（Remote DB）。用戶要存取遠程 DB上的數據時，必須建立資料庫鏈。
Oracle資料庫的體系結構包括物理存儲結構和邏輯存儲結構。由於它們是相分離的，所以在管理數據的物理存儲結構時並不會影響對邏輯存儲結構的存取。
1.邏輯存儲結構
它由至少一個表空間和資料庫模式對象組成。這里，模式是對象的集合，而模式對象是直接引用資料庫數據的邏輯結構。模式對象包括這樣一些結構：表、視圖、序列、存儲過程、同一詞、索引、簇和資料庫鏈等。邏輯存儲結構包括表空間、段和范圍，用於描述怎樣使用資料庫的物理空間。而其中的模式對象和關系形成了資料庫的關系設計。
數據塊（Block）：是資料庫進行UO操作的最小單位，它與操作系統的塊不是一個概念。oracle資料庫不是以操作系統的塊為單位來請求數據，而是以多個Oracle資料庫塊為單位。
段（Segment）：是表空間中一個指定類型的邏輯存儲結構，它由一個或多個范圍組成，段將佔用並增長存儲空間。
其中包括：
數據段：用來存放表數據；．
索引段：用來存放表索引；
臨時段：用來存放中間結果；
回滾段：用於出現異常時，恢復事務。
范圍（Extent）：是資料庫存儲空間分配的邏輯單位，一個范圍由許多連續的數據塊組成，范圍是由段依此分配的，分配的第一個范圍稱為初始范圍，以後分配的范圍稱為增量范圍。
⑺ 操作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
成就一億技術人
前往
⑻ oracle 資料庫如何建表
建表方法：
(1)在cmd里邊更具需要進行創建
(2)在sql developer中進行創建，而對於在可視化界面sqldeveloper中創建時，也有兩種方式，即一種是使用命令直接進行創建，另外一種是使用可視化界面按鈕進行點擊創建