DBA必讀：Oracle資料庫審計七宗罪

　　【TechTarget中國原創】 Oracle難懂的許可策略最讓人頭痛。著名技術顧問、作家Robert Sheldon介紹了七個可能導致Oracle審查及昂貴審查費用的行為。

　　Oracle的許可策略極其含糊和難懂。一次失誤就可能讓你付出成千上萬美元的審查費用。但是，由於有大量的管理包和預安裝選擇，因此Oracle軟體很容易讓人使用錯誤;所以在實踐中你很容易違反規範和遇到上大麻煩。

　　一定不要幻想Oracle不會對你採取措施。根據最新的Flexera/IDC報告，在過去1年半至2年時間裡有63%的受訪組織遭受過一家軟體供應商的審查，其中有56%的組織被迫支援額外費用，還有許多組織損失上百萬美元。Oracle常常將自己置於一種凌駕於各個軟體供應商之上的頂級審查者位置，熱衷於揮動手中的大棒，控制客戶的應用保證在限定範圍內，而不管他們是否理解其中的許可規則。

　　想象一下，有85%的受訪組織違反了他們的軟體許可協議，這樣你就會很清晰目前的狀況。你的公司可能就是其中一個違規者，特別是如果公司恰好在使用Oracle產品。即便如此，你可能還是不清楚到底問題出現在哪裡。下面我們介紹可能導致這些爭議性Oracle審查及後續高昂許可費的七個最常見(通常也是最致命)的行為。

　　缺少許可清單

　　跟蹤軟體的許可文件是一件很棘手的工作。除了Oracle許可與服務協議(OLSA)，你還應該檢查全部訂單歷史、續訂日期、折扣產品及其他與軟體採購相關的資訊。如果簽署了舊版本的OLSA，你還需要跟蹤一些發生過變更的產品名稱及指標。

　　對於完全理解自己購買什麼產品及產品允許使用的範圍，許可資訊的可用性是非常重要的。例如，完全版(Full Use, FU)許可與專用應用完全版(Application-Specific Full Use, ASFU)許可就有很大的差別。如果不跟蹤這些資訊，那麼很多方面都可能出現不確定性，其中包括OLSA與各種附加條款發生衝突時合同條款的優先順序順序。

　　不清楚產品安裝在什麼位置

　　與瞭解允許做什麼同樣重要的是要了解自己實際上是怎麼做的。但是，很少組織有關於所實現產品的完整清單，更不用說產品的版本資訊了。讓問題複雜化的是你可以在未獲得許可的情況下隨意使用其他可選軟體包和管理軟體包。

　　具體到Oracle軟體上，它的挑戰在於產品的可選軟體包和管理軟體包已經隨主產品安裝了，而且預設是啟用的。企業版產品更是如此。管理員可以隨意使用這些特性，即使還沒有獲得這些特性的許可。對於在多個位置中大量伺服器上部署軟體的組織而言，違反規範的可能性呈指數級增長趨勢。

　　指標誤讀

　　在軟體應用了正確度量指標之後，要確定軟體的正確使用是一個很有難度的工作。例如，在一臺伺服器上安裝一個產品時，一位管理員可能可能會同時使用處理器數量(Processor)和指定使用者數量(Named User Plus, NUP)指標。而另一位管理員則可能會混淆新舊指標，如併發使用者數量(Concurrent Users)與NUP。

　　許多與指標誤用相關的問題都源於計數錯誤。例如，一個使用處理器數量指標的組織可能沒有計算核心數量或已佔用插槽數，或者核心數量無法與每一個處理器的總數圓整。在使用NUP指標時，許多公司會低估實際數量，而沒有計算最小需求或和間接使用者數量，如透過菊鏈應用訪問軟體的使用者。在處理Oracle產品時，可以肯定的一點是沒有任何一個指標是很簡單的。

　　虛擬化管理混亂

　　Oracle許可中最大的問題之一是虛擬化，這個方面非常容易違反規定，如果Oracle決定審查，那麼很可能讓你就不得不簽下支票。其中一個挑戰是Oracle只支援硬體分割，而不支援像VMWare那樣的軟體分割。因此，你必須為所有訪問Oracle產品的處理器和核心購買許可。但是，人們通常都沒有這樣做。相反，有一些組織會購買邏輯分割槽許可，但是沒有計算底層硬體的物理處理器。在建立一個虛擬環境時，你需要計算整個系統架，其中包括虛擬機器、叢集和儲存。一個小小的錯漏都能夠讓你被迫支付高於原始許可費的費用。

　　容錯管理不當

　　此外，一些組織在實現災難恢復和高可用性時也可能違反規範。例如，他們可能沒有為故障恢復叢集節點或映象與備用伺服器購買許可，通常只是因為他們認為這些元件不需要購買許可。另外，他們還可能使用了不同的指標去計算不同節點的許可。

　　還有許多組織沒有計算故障修復伺服器的維護作業，或者在完成一次故障恢復之後忘記從輔助節點切換回主節點。此外，他們可能會忘記為備份伺服器的可選軟體包和管理軟體包購買許可了。而且，叢集環境也可能會加重違規程度，如指標應用錯誤和虛擬化不當。

　　許可證濫用

　　無論原因是否相同，總之有許多組織都在未獲得許可的情況下使用Oracle軟體。最典型的例子是無限許可協議(Unlimited License Agreement, ULA)，它通常都被解釋為自助軟體許可，意思是給你許可權在任何需要的位置上使用任何軟體。然而，ULA限制了你可以使用的產品、使用這些產品的位置及使用的期限。

　　但是，ULA還不是唯一的陷阱。某個組織可能在未升級許可的前提下修改了一個Oracle應用程式，然後一臺伺服器上執行多個產品版本，但是隻有一個許可證，或者在安裝特定軟體版本時違反了硬體限制規定。事實上，你可能會發現自己有許多個在未獲得許可情況下使用Oracle產品的方式，如果被Oracle發現，這種情況可能導致高昂的罰款。

　　最後一個問題是在完全沒有購買任何許可的前提下安裝產品，當然這不是少出現的問題。非生產環境或許是最容易出現問題的地方。Oracle認為，就像生產環境一樣，所有人都應該為開發、測試和預生產環境購買許可證。你必須計算使用者數、處理器數、版本數、管理軟體包及所有內建可選軟體包。千萬不要被Oracle Technology Network (OTN)許可所迷惑。它並不人們想象的那樣可以隨意而為。

　　然後，還有其他一些位置可能出現問題，如非人操作的裝置。它們並不需要真人去操作，但是它們仍然要遵守Oracle的許可規定，並且會像其他使用者一樣計算許可證。此外，如果不小心，資料傳輸也可能落入許可黑洞。觸發工人批處理的使用者也必須計算許可，傳輸普通檔案的使用者(或裝置)也一樣。即使是透過一個多路基礎架構傳輸資料，也要求購買使用者許可。

　　不要成為盜竊的犧牲品

　　人們很容易違反Oracle軟體的許可規定，特別是在分散式環境部署許多Oracle產品的時候。這裡介紹的七種行為只是所有情況的一部分。Oracle故意搞得讓人很容易犯錯，然後這家公司又樂於把它的快樂建立在你的痛苦上。顯然，如果你的組織在執行Oracle產品，那麼你一定要持續監控所有平臺上執行所有Oracle軟體。任何疏忽都可能千萬一次審查噩夢，讓你的組織不得不承擔原本想象不到的天文許可費用。如果這不是盜竊，那是什麼?

　　

　　bncsm/

　　dxbrdsm/

　　zhdy/

　　dxbkyzym/

　　zmyqd/

　　zqzz/

　　dxbhycm/

　　bjdxbyy/

　　http://run.gmw.cn/blog-1873077-69970.html