Oracle感慨(转)
? 一轉眼接觸ORACLE已經一年了,在這一年中收獲多多,感慨多多,我記得是2004年11月底開始學習ORACLE的,當時選擇方向也是幾經波折,還好現在的處境不是非常的艱難,前途似乎還有想象中的光明。
???? 畢業已經兩年半,開始半年主要是接觸Sybase,當時公司后臺使用的Sybase SQL 11,由于人手比較少,管理也不很嚴格,所以我經常有機會光顧他,在那里我學會了怎樣備份,恢復數據庫,怎樣寫SQL代碼處理公司的業務邏輯,那個時候想的也很簡單,理解也非常膚淺,覺得數據庫的作用就是存數據,取數據,封裝業務邏輯,當然現在很多時候我也這么認為。
?????? 很快到了2004年,公司開始使用SQL SERVER 2000,我有機會接觸這個Sybase的孿生兄弟了,我的工作除了用PB編寫前臺那些笨拙的界面,還負責整個數據庫的維護與管理,這時我已經不滿足建個數據庫就可以使用,寫個SQL腳本就可以運行,我將更多的精力投放在很多內部的運做機制上,比如索引的結構是怎樣的,利用索引定位數據,他是怎么從根頁到中間層到葉接點在到數據頁的,DML對索引有什么影響,什么情況下會造成頁分割,填充因子又有什么作用。DML和COMMIT有什么關系,數據庫提出先寫日志是怎樣一種情況,結合CHECKPOINT考慮各種斷電情況對數據一致性的影響,使用日志備份恢復時為什么總是出現LSN太早的問題,日志傳輸的原理是什么,數據文件是否可以分散到多個磁盤來均衡IO,RAID0的使用是否使得文件組顯得多余。各種LOCKS的概念,對數據庫的影響,鎖升級,事務隔離級別,等等等等,通過對這些概念的理解與實踐,我慢慢感覺到數據庫的博大精深,這個時候數據庫的每個操作不在是個簡單的動作,引用李小龍的話:在我剛開始學武時,我覺得一拳就是一拳,一腳就是一腳,而經過一段時間的提升,我覺得一拳不在是普通的一拳,一腳也不在是普通的一腳,但最后,我覺得一拳還是那么一拳,一腳還是那么一腳。可惜筆者現在還是停留在第二個層次,向第三個無招勝有招,草木為劍的境界的過度,還需要時間。同時在這段時間,我還學習java,寫些簡單的聊天程序,打好了一個大致的框架,但最后還是以一個蹩腳的掃雷游戲而告終。
???? 到了11月底,考慮換工作,本來想做Java的,但網上招聘的要求太高,或以沒有實際的項目經驗為由將我拘之門外,有些公司給人的感覺是比爾蓋茨進來了也只有刷馬桶的份。也搜索了下DBA之類的職位,很少有專門做SQL SERVER和Sybase的,但做Oracle的還是蠻多的,既然Java找不到,SQL也不招,自己又不想干回以前的PB,索性來個猛料,學Oracle,在數據庫這條路上已經投入這么多了,為什么不能將他當成自己的主業呢?就這樣我開始接觸Oracle了,比我想象中的要順利的多,因為我在SQL SERVER中已經做的很多了,我知道數據庫的存儲結構,內存體系,鎖存資源,熟悉數據庫的各個動作以及與他們打交道的方式,這些在SQL SERVER中已經理解的非常透徹了,現在換到ORACLE,同是RDBMS,兩者竟然有些地方如此的相似(當然差別也是巨大的),比如事務的提交,都是先寫日志,刷新日志緩存的內容到日志文件,數據不立刻反映到數據文件,隨著事務的堆積,到一定限度時,由checkpoint進行同步,啟動時照樣是根據日志最末尾的檢查點標記為起點進行實例恢復,他們都要保證連續的事務日志來進行日志恢復。不同的是Oracle維護自己的SCN號碼,對數據的前映象以回滾段的方式來記錄,在數據塊上存在事務鏈表來關聯事務與回滾段塊之間的聯系,而SQL SERVER中是以LSN來代替SCN,當然他的數據前映象是記錄在日志文件中,沒有回滾段的概念。在比如存儲結構上,兩者都是以文件的形式,將數據分布到不同磁盤,以均衡磁盤IO,一個體現在表空間,一個體現在文件組,這兩個都可以作為備份的單元來使用.
?
???? ORACLE中對象以數據塊的方式存儲,以盤區為單位進行擴展,本地管理表空間中以數據文件頭幾個數據塊的位圖映象來表示空間的使用情況,SQL SERVER是以頁來存儲對象(1頁8K,相當于塊),以盤區來擴展,以全局分配映射頁來維護盤區的使用情況,這不是異曲同工嗎?在內存的使用上兩者都維護自己的緩沖鏈表,根據緩存頁的TCH計數器來判斷熱塊冷塊,以決定內存不足時將哪些數據塊flush,但ORACLE將更多的管理權限開放給了DBA,可以劃分不同塊大小的緩沖區,以滿足不同的查詢需求,我們公司現在的OLTP系統有些表多半是單行的索引讀取事務,我將他們劃在2K的BLOCK區域,而有些表是晚上跑報表的,我將他們劃在32K的BLOCK區,他們之間互不干擾,有著自己獨立的LRU鏈表,運行的非常好。在學習中通過這些相同與不同,體驗兩個DBMS之間的優劣,進步是非常快的,當然剛開始也有一種眼高手低的狀態,很長一段時間我不知道坐在ORACLE面前要干什么,概念理論想通了卻不會查詢基本的視圖,敲不出基礎的命令,甚至還在CSDN上發貼問表空間的建立語句怎么寫。這一切已經過去,我現在已經熟悉很多命令了,并被公司的人稱為命令狂人,可以說SQL SERVER是我數據庫的基礎,雖然現在不使用他,但ORACLE的學習也使我對SQL的理解更加深刻,個人感覺SQL SERVER封裝了太多的東西,易用,便于管理,這樣留給DBA的空間就比較少了,大家都知道在ORACLE中你可以dump出數據塊,內存區,控制文件來進行內部結構的研究,這些在SQL SERVER中是沒有的,我就見過有人通過對數據塊的深入研究,發現了ORACLE數據文件的內部存儲格式,從而他寫出工具,可以物理的硬解析數據文件,獲取里面的數據。
??? 對于這兩個DBMS誰好誰壞,我不想說,感覺沒有什么意義,網上有很多精彩的討論,你如果有興趣,可以看看這位猛將兄的發貼
??? http://blog.dev-club.com/bscy/archive/2005/10/17/2840.html
???
???? 很快我憑借自己的這么點資本找到了工作,在一家負責移動業務的通信技術公司擔任DBA,這個時候有了實際的工作環境,學習起來更加得心應手了,知識的鞏固來源于實踐,這個真的沒錯,以前的那些概念,以點成線,以線成面,清晰的展現在腦海中,抹之不去,這就是實際工作的感覺。在公司負責編寫了核心的存儲過程包,為研發的代碼員們做SQL TUNING,維護在線的RAC體系數據庫,幫助測試部門搭建數據庫環境,為工程部處理業務數據,還幫助SQA部門調整SQL SERVER,有次他們的一個哥們問:你也會SQL SERVER啊,不是做ORACLE的嗎?偶告訴他我通曉各個RDBMS(有點不要臉),逗的他哈哈大笑。
???
??? 對于ORACLE的學習,我分為3個部分,1是PL/SQL編程,2是數據庫的性能調整,3是備份與恢復體系,其他的高級特性根據自己的業務需求去啃。
?
??? 對于1,上手比較快,但寫出高質量的語句不是很容易的事,還有一些比較高級的PL/SQL編程也是很有學頭的。
???
??? 對于2,我覺得是最難的一塊,我在這部分做了那些可以參考下面鏈接?
???? ?http://blog.dev-club.com/bscy/archive/2005/09/05/2463.html
???? 對于3,如果你只是想做個稱職的DBA,保證數據庫的正常運行,你不必專研太多,了解備份恢復的方法,考慮好備份方案,及時的實施就可以了,如果你喜歡扮演力挽狂瀾的英雄,喜歡為別人提供技術支持處理各種災難現場,那就準備熬夜,仔細的梳理SCN,CHECKPOINT,控制文件,數據文件頭,日志文件,事務的COMMIT,ROLLBACK,UNDO之間的關系,不能有絲毫的模糊與不明確,針對各種災難現場進行模擬實驗,我的BLOG上有很多這方面的模擬實驗和概念的理解,有興趣可以交流下。
????作為一名DB工作者,嚴謹是必須的,程序寫不出來,自己慢慢調整,數據庫起不來,數據邏輯錯誤,這個損失可是巨大的,很多企業多DB的重視程度不夠,對DBA的輕視也讓我感到心寒,多上下國外的網站,就能感受到明顯的差別,下面這個鏈接是著名的Thomas Kyte, Jonathan Lewis針對Donald K.Burleson, Mike Ault這幫蠢材提出的一些誤導觀念的激烈反擊,從這可以看出世界狂人們的嚴謹態度
??? http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:35336203098853
????現在2005年就快結束,偶的本命年,呵呵,寫下這篇流水帳,感慨一下,上海的冬天真冷,風大,祝各位工作愉快,新年快樂(不算早吧,呵呵)。
轉載于:https://www.cnblogs.com/zping/archive/2008/08/12/1265914.html
總結
以上是生活随笔為你收集整理的Oracle感慨(转)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 插入一个新列
- 下一篇: 关于需求和架构的典型问题