IT Certification 考試資訊

日期: 2009 年 12 月 9 日

  • 調查:Oracle 11g版本選用情況仍不樂觀

    在本年度數據庫技術應用技術問卷調查中，我們持續對Oracle數據庫用戶的版本情況做了調查，以便更好地分析Oracle數據庫用戶版本保有及升級更新狀況。

              如何我們回顧06年的數據，進而再對比上面08年和07年的調查數據，可以發現，在06到07年裡，Oracle數據庫的市場使用進一步增加，在2006年的受訪用戶中，有15 %沒有使用Oracle數據庫，2007年這一數字降低到11%。

            分析2008年的調查數據，只有4.7%的客戶升級到了Oracle 11g版本，而在2007年，這些“敢於吃螃蟹”的人僅僅有0.2%。考慮到11g版本的推出時間和推廣力度，2008年的Oracle 11g版本佔有量比例的確不算高。

            記者就此採訪ITPUB社區的一位數據庫專家，他認為：“08年升級到11g用戶應該主要是8i，9i產品的用戶，他們已經有升級計劃，趕上最新的版本11g推出，所以就直接跳過了10g數據庫，直接到11g上去了;這一比例中，應該不會有或者說很少有10g的用戶轉化過來的。”

           筆者註意到，甲骨文對Oracle 11g的推廣也開始採用新的思路和方法，在2008年到2009年，Oracle在大力推廣數據庫選件(database options),這些多樣化的功能特性，是針對不同用戶對數據庫的特殊需求所提供的，大部分都集成在高版本的數據庫產品中。這種推廣和銷售模式，有將產品和功能分拆開來賣的意味。

      　再來看Oracle 10g的情況。 Oracle 10g的佔有量已經高達44.2%，相比2007年增長了近5個百分點，已經成為最主要的使用數據庫版本。 2007年，在數據庫版本上，Oracle 10g獲得了市場和用戶的廣泛認同，使用的比例占到39.8%，而2006年的數字僅為27.9%，有幾乎12個百分點的比較大的增長;在2007年，Oracle 10g的用戶使用也首次超過了Oracle 9i，在2006年使用Oracle 9i的用戶比例高達47%，這個數字在2007年下降了9個百分點。這一變化可能受到Oracle 9i的退出計劃影響，但是毋庸置疑的是，Oracle 10g已經得到了大規模普及和採用。

            在2008年的調查結果中，另外一個比較有趣是數據是“沒有使用Oracle數據庫”的用戶比例，2008年沒有使用Oracle數據庫的用戶達到13.6%，而在07年這一比例只有11%;無獨有偶，本次調查涉及SQL Server，DB2，Oracle數據庫的這一數據時，未使用的比例都略有上升。 Itpub社區的一位數據庫分析師認為，這是開源數據庫使用量增長的結果，導致商業數據庫用戶都在不同程度的流失，特別是在當前經濟形式日趨嚴峻的形勢下，開源數據庫的吸引力會進一步加強。

    看來，商業數據庫廠商需要推出更加靈活的授權許可和服務模式，進一步降低企業的IT投資成本，才能保住用戶，以免流失。

  • DBA 2.0的時代與Oracle促進的變革

    前幾天我們討論的關於DBA 2.0的話題，實際上也正是Oracle在後9i時代不斷促進的變革，而變革的主要工具之一就正是全新的OEM（Grid/Database Control）。所以我嘗試將這個話題做一個最後的總結。既然我們開始了DBA 2.0的討論，那麼DBA 2.0是從何開始的，又可以如何界定呢？

        普遍的認為，DBA 2.0開始於Oracle Database 10g的時代，由於Oracle 10g引入了大量的新特性，使得DBA的工作發生了質的變化。 比如，ASM的引入使得DBA不得不更加深入的介入存儲的管理和維護；Clusterware的引入，使得DBA不得不深入了解和維護Cluster軟件；如果在加上Oracle的OEL（Oracle Enterprise Linux）和最近推出的Exadata以及HP Oracle Database Machine，那麼現在主機、操作系統、OS都需要一個Oracle DBA深層次的介入和管理。

        而在傳統的數據庫層面，數據庫的自動管理與自我維護性則不斷提高。 Grid Control/Database Control可以幫助我們更好的監控和管理數據庫，AWR（自動工作負載信息庫）使得信息的收集實現自動化，ADDM（自動數據庫診斷監控程序）使得數據庫可以根據AWR等信息進行自動的性能分析和診斷，SQL Advisor、SPM（SQL Plan Management）可以幫助我們進行SQL的調整和建議……

        總結一下那就是，在傳統的數據庫層面，Oracle不斷在強化自動化管理，提高數據庫的自我管理性，減少用戶的干預和工作量；而在數據庫之外，更後端，DBA需要不斷向系統、存儲甚至網絡領域延伸，在前端，DBA則需要不斷向應用層面進行擴展。

    （更多…）

  • 基於Oracle 高級複製功能的數據庫同步研究與應用

    摘要：隨著數據庫的廣泛使用和網絡的迅速發展，數據庫同步技術的研究一直是一個熱點。本文介紹了Oracle 的高級複製功能的相關概念及提供的功能。接著分析比較了幾種網絡間數據庫同步方法，並總結了基於Oracle 高級複製功能的同步的優勢。最後通過一個具體的數據庫同步需求，介紹一種基於Oracle高級複製功能的數據庫同步方案的具體實現。

    1．引言
    數據庫系統是現代企業運作和管理自動化系統的重要組成部分。在Internet 飛速發展的今天，數據庫一方面向集中化，大型化方向發展，但應用卻在向著分散化，小型化的方向延伸。對於越來越多的企業分支機構和辦公人員，他們需要隨時查詢和更新數據庫，而他們所需要操作的一般並不是數據庫的全部，而往往只是與之緊密相關的少量數據，但少量的數據必須與企業中心數據庫同步更新。如何根據實際情況有效地解決數據庫系統的數據同步問題已成為企業或系統的整個數據庫系統應用的核心環節。

    點擊下載：Oracle高級複製功能的數據庫同步研究與應用

  • 學習Java語言的重要含義

    1. Java是目前使用最為廣泛的網絡編程語言之一。它具有簡單，面向對象，穩定，與平台無關，解釋型，多線程，動態等特點。

         2.簡單Java語言簡單是指這門語言既易學有好用。不要將簡單誤解為這門語言很乾癟。你可能很贊同這樣的觀點英語要比阿了伯語言容易學。但這並不意味著英語就不能表達丰富的內容和深刻的思想，許多文學若貝爾獎的作品都是英文寫的。如果你學習過C++語言，你會感覺Java很眼熟，因為Java中許多基本語句的語法和C++一樣，像常用的循環語句，控制語句等和C++幾乎一樣，但不要誤解為Java是C++的增強版，Java和C++是兩種完全不同的語言，他們各有各的優勢，將會長期並存下去，Java語言和C++語言已成為軟件開發者應當掌握的語言。如果從語言的簡單性方面看，Java要比C++簡單，C++中許多容易混淆的概念，或者被Java棄之不用了，或者以一種更清楚更容易理解的方式實現，例如， Java不再有指針的概念。

         3.面向對象基於對象的編程更符合人的思維模式，使人們更容易編寫程序。在實際生活中，我們每時每刻都與對像在打交道。我們用的鋼筆，騎的自行車，乘的公共汽車等。而我們經常見到的卡車，公共汽車，轎車等都會涉及以下幾個重要的物理量可乘載的人數，運行速度，發動機的功率，耗油量，自重，輪子數目等。另外，還有幾個重要的功能加速功能，減速功能，剎車，轉彎功能等。我們也可以把這些功能稱作是他們具有的方法，而物理量是它們的狀態描述。僅僅用物理量或功能不能很好的描述它們。在現實生活中，我們用這些共有的屬性和功能給出一個概念機動車類。一個具體的轎車就是機動車類的一個實例對象.Java語言與其它面向對象語言一樣，引入了類的概念，類是用來創建對象的模板，它包含被創建的對象的狀態描述和方法的定義。

         4.與平台無關與平台無關是Java語言最大的優勢。其它語言編寫的程序面臨的一個主要問題是操作系統的變化，處理器升級以及核心系統資源的變化，都可能導致程序出現錯誤或無法運行。 Java的虛擬機成功地解決了這個問題，Java編寫的程序可以在任何安裝了Java虛擬機JVM的計算機上正確的運行，Sun公司實現了自己的目標“一次寫成，處處運行”。

         5.解釋型我們知道C，C++等語言，都是只能對特定的CPU芯片進行編譯，生成機器代碼，該代碼的運行就和特定的CUP有關。例如，在C語言中，我們都碰到過類似下面的問題int型變量的值是10 ，那麼下面代碼的輸出結果是什麼呢printf（“%d，%d”，x，x=x+1 ）如果上述語句的計算順序是從左到右，結果是10，11但是，有些機器會從右到左計算，那麼結果就是11，11.Java不像C++，它不針對特定的CPU芯片進行編譯，而是把程序編譯為稱做字節碼的一個“中間代碼”。字節碼是很接近機器碼的文件，可以在提供了Java虛擬機JVM的任何系統上被解釋執行。 Java被設計成為解釋執行的程序，即翻譯一句，執行一句，不產生整個的機器代碼程序。翻譯過程如果不出現錯誤，就一直進行到完畢，否則將在錯誤處停止執行。同一個程序，如果是解釋執行的，那麼它的運行速度通常比編譯為可執行的機器代碼的運行速度慢一些。但是，對Java來說，二者的差別不太大，Java的字節碼經過仔細設計，很容易便能使用JIT即時編譯方式編譯技術將字節碼直接轉化成高性能的本地機器碼，Sun公司在Java 2發行版中提供了這樣一個字節碼編譯器——JIT（Just In Time），它是Java虛擬機的一部分。 Java運行系統在提供JIT的同時仍具有平台獨立性，因而“高效且跨平台”對Java來說不再矛盾。如果把Java的程序比做“漢語”的話，字節碼就相當於“世界語”，世界語不和具體的“國家”關，只要這個“國家”提供了“翻譯”，就可以再快速地把世界語翻譯成本地語言。

         6.多線程Java的特點之一就是內置對多線程的支持。多線程允許同時完成多個任務。實際上多線程使人產生多個任務在同時執行的錯覺，因為，目前的計算機的處理器在同一時刻只能執行一個線程，但處理器可以在不同的線程之間快速地切換，由於處理器速度非常快，遠遠超過了人接收信息的速度，所以給人的感覺好像多個任務在同時執行。 C++沒有內置的多線程機制，因此必須調用操作系統的多線程功能來進行多線程程序的設計。

         7.安全當你準備從網絡上下載一個程序時，你最大的擔心是程序中含有惡意的代碼，比如試圖讀取或刪除本地機上的一些重要文件，甚至該程序是一個病毒程序等。當你使用支持Java的瀏覽器時，你可以放心地運行Java的小應用程序Java Applet ，不必擔心病毒的感染和惡意的企圖，Java小應用程序將限制在Java運行環境中，不允許它訪問計算機的其它部分。

         8.動態Java程序的基本組成單元就是類，有些類是自己編寫的，有一些是從類庫中引入的，而類又是運行時動態裝載的，這就使得Java可以在分佈環境中動態地維護程序及類庫，而不像C++那樣，每當其類庫升級之後，相應的程序都必須重新修改，編譯。

  • 寫Java程序的三十個基本規則

    (1)類名首字母應該大寫。字段、方法以及對象(句柄)的首字母應小寫。對於所有標識符，其中包含的所有單詞都應緊靠在一起，而且大寫中間單詞的首字母。例如： ThisIsAClassName
     thisIsMethodOrFieldName
    若在定義中出現了常數初始化字符，則大寫static final基本類型標識符中的所有字母。這樣便可標誌出它們屬於編譯期的常數。
    Java包(Package)屬於一種特殊情況：它們全都是小寫字母，即便中間的單詞亦是如此。對於域名擴展名稱，如com，org，net或者edu等，全部都應小
    寫(這也是Java 1.1和Java 1.2的區別之一)。
    (2)為了常規用途而創建一個類時，請採取“經典形式”，並包含對下述元素的定義：
    　equals()
    　hashCode()
    　toString()
    　clone()(implement Cloneable)
    　implement Serializable
    (3)對於自己創建的每一個類，都考慮置入一個main()，其中包含了用於測試那個類的代碼。為使用一個項目中的類，我們沒必要刪除測試代碼。若進行了任何形式的改動，可方便地返回測試。這些代碼也可作為如何使用類的一個示例使用。
    (4)應將方法設計成簡要的、功能性單元，用它描述和實現一個不連續的類接口部分。理想情況下，方法應簡明扼要。若長度很大，可考慮通過某種方式將其分割成較短的幾個方法。這樣做也便於類內代碼的重複使用(有些時候，方法必須非常大，但它們仍應只做同樣的一件事情)。

    (5)設計一個類時，請設身處地為客戶程序員考慮一下(類的使用方法應該是非常明確的)。然後，再設身處地為管理代碼的人考慮一下(預計有可能進行哪些形式的修改，想想用什麼方法可把它們變得更簡單)。
    (6)使類盡可能短小精悍，而且只解決一個特定的問題。下面是對類設計的一些建議：
    1.一個複雜的開關語句：考慮採用“多形”機制
    2.數量眾多的方法涉及到類型差別極大的操作：考慮用幾個類來分別實現
    3.許多成員變量在特徵上有很大的差別：考慮使用幾個類。
    (7)讓一切東西都盡可能地“私有”——private。可使庫的某一部分“公共化”(一個方法、類或者一個字段等等)，就永遠不能把它拿出。若強行拿出，就可能破壞其他人現有的代碼，使他們不得不重新編寫和設計。若隻公佈自己必須公佈的，就可放心大膽地改變其他任何東西。在多線程環境中 ，隱私是特別重要的一個因素——只有private字段才能在非同步使用的情況下受到保護。
    (8)謹惕“巨大對象綜合症”。對一些習慣於順序編程思維、且初涉OOP領域的新手，往往喜歡先寫一個順序執行的程序，再把它嵌入一個或兩個巨大的對象裡。根據編程原理，對象表達的應該是應用程序的概念，而非應用程序本身。
    (9)若不得已進行一些不太雅觀的編程，至少應該把那些代碼置於一個類的內部。
    (10)任何時候只要發現類與類之間結合得非常緊密，就需要考慮是否採用內部類，從而改善編碼及維護工作(參見第14章14.1.2小節的“用內部類改進代碼”)。

    （更多…）