程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> Oracle數據庫 >> Oracle數據庫基礎 >> 教你如何從調優強迫症中恢復過來

教你如何從調優強迫症中恢復過來

編輯:Oracle數據庫基礎

性能調優專家Gaja Krishna Vaidyanatha想要幫助那些受到他們稱之為“調優強迫症”(CTD)困擾的數據庫管理員們擺脫痛苦。Vaidyanatha是DBPerfMan.com咨詢公司的所有人,他還是幾本Oracle書籍的作者,其中有《Oracle性能調優101》創造了許多術語來描述那些數據庫管理員們都在使用的一些偶然發現的技術。在下個月奧蘭朵召開的IOUG Live! 2005會議演講中,Vaidyanatha會談論一些他用來探明性能問題的特殊方法。SearchOracle.com與Vaidyanatha進行了討論並且提前對他的陳述作個介紹。

調優強迫症是否意味著數據庫管理員可以有效地工作呢?還是不能呢?

GKV:數據庫管理員如果得了調優強迫症的話,就不能有效地工作了。我在2001年裡推薦過的一些方法中,我發明了“調優強迫症”這個詞。我正在編寫我的第一本書,在十一月的一個漆黑的夜晚,我問我自己該如何輕松地表達這個問題——數據庫管理員們對性能調整、調整、調整,卻看著不想關的事情。現在很多人都使用了這個詞語,但是這個意思卻實際上發生了變化。我聽見人們使用它來表達沒有做某些事情的意思。這個表述的全部想法就是幫助人們去戰勝它——不僅僅是對Oracle 10g,而且包括所有的Oracle版本。

有沒有一些數據庫管理員應該遵循的標准?數據庫管理員如何才能知道什麼時候性能已經是足夠好了?

GKV:你得定義響應時間目標。一旦響應時間目標達到了,性能就足夠好了。這就是問題的症結所在——人們沒有定義目標,他們認為性能調優具有只有調優的魔法才具有的一種令人深陷其中的魔力。我對於性能管理的推理就是你已經得到了有關這個問題的精確的證據。這也是驅使你去解決問題的關鍵——並不緊緊是遵循一大堆的最好的實踐方案。你不能物品的干洗名單進行調整。我的底線是:讓我們找出問題所在。讓我們用數學來驅動我們的所作所為,而不是某些觀點或者專家的令人迷惑的技術。

什麼是最常見的性能問題?

GKV:一個查詢運行得太慢或者一個任務運行得太慢。問題是什麼導致了這麼慢。很多人都沒有花時間去找出原因。他們把時間花費在改變事情,你可以更改八件事情,然後問題就消失了。你是解決了它,還是把它偽裝過去了?問題還會回來的。如果你沒有使用數學,解決方案就是不可重復的,你也不能使用一個一致的方法來解決性能問題。它總是或者成功,或者失敗、測試、糾正錯誤。

什麼是數學的方法?

GKV:使用底層的追蹤方法去找出應用程序將時間花在了哪裡。寫一個追蹤語句並對其進行分析。之後,事情就很簡單了。你可以發現你花了78%的時間在I/O上,那麼你就會問自己為什麼花了那麼長時間在這上面。

你在不同的Oracle版本中看到了不同的問題出現嗎?

GKV:是的。你一定會遇到某些事情在一個版本中運行良好,但是同樣的應用程序在升級之後就不工作了,就是因為數據庫管理系統發生了變化,優化器計劃也改變了。有時候引入一些新的參數。有上百個參數擺弄,這一點通常是好事,但是一旦人們開始管理上百個數據庫,人們就不會有時間去擺弄上百個東西了。優化器正在逐漸成熟,取代了調整這些參數的一部分工作。大多數的時間裡,在不同的版本之間,問題的存在是因為bug,或者缺乏某項應用程序需要的功能。

10g中有哪些用來解決特定的性能問題的以前版本中沒有的特性?

GKV:很多個特性,一些處理數據收集,例如10g中的歷史收集——自動負載倉庫。作為數據收集的一部分,還有另外一個特性,活動會話歷史,它是流入AWR的一個輸入流。一旦你開始收集數據,你需要某些種類的分析引擎,現在這就是可用的了——它叫做自動數據庫診斷監控器。那些都是Oracle的一些新東西,可以幫助你來了解是什麼花費了時間,而不是僅僅看著比率。人們總是希望能夠找到尚方寶劍並且改變它,但是尚方寶劍實際上是不存在的。都是邏輯的、可重復的、精確的方法——由響應時間驅動。10g為數據庫管理員提供了收集和分析的功能,用這些功能數據庫管理員可以走上了解核心問題的正確道路。

什麼是最常見的調優誤區或者錯誤的概念?

GKV:很多人都試圖調整數據庫環境自身,而不是首先看看應用程序。這就是尚方寶劍中的一部分。數據庫是簡單的——改變參數並重新啟動,你就完成了一次修改。應用程序的調整會花費更多的力氣——找出應用程序的組件就是造成問題阻塞的開端,然後是找出問題所在的實際工作,然後是分析它,最後再解決它。整個過程要遵守規則,並且耗費體力,但是不是一個長期的拉鋸戰。如果你夢想揮舞著魔法棒,你就不會贊成這種方法。你之前曾試過,並且也期望現在能夠發生同樣的事情,但是參數不一樣了,或者它們因為不再有關系而產生作用。查看響應時間的努力背後的基本目標就是讓人們看看正確的數據,讓人們摒棄查看洗衣單的老方法。用人力去每天看100個數據庫是不可能的。即使是你說,“所以我們使用監控軟件啊,”那麼,如果它拋出100個警告,哪一個才是最重要的?問問自己有沒有遇到性能問題,也就是有沒有遇到響應時間問題,從這個角度出發再來看看。

最好的分析就像你去看醫生。你說你的右腳疼。如果醫生說他需要對你做一個徹底的掃描並且化驗血液,你就會想,為什麼我們不先看看我的右腳呢?你也許會置疑醫生的人品。這就是古老的方法。我會在每次出現問題的時候都做血液測試、CT掃描,還有MRI。我們不需要只是因為腳疼就做徹底的血液化驗。這就是我們想要說的。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved