[20160519]淺談行業分工.txt

lfree發表於2016-05-19

[20160519]淺談行業分工.txt

--我的部落格很少談及非技術的東西,這個話題只是最近幾個月我遇到一些問題的思考.

--以前看人家老外分工很細,真的很羨慕,不像我們國內dba就是一個打雜的,什麼可能都做,特別是做運維的.
--隨著公司的人員原來越多,我們內部分工也越來越細,我們分成多個組,硬體,軟體,資料庫,網路.這本來是一件好事,
--作為某個組,可以充分發揮自己的特長,做好自己的本分工作.

--不像以前,一個專案,我給從硬體裝置採購開始,跟售前談購買這些裝置是否滿足需求,買回伺服器上架,安裝作業系統,網路開通等等細節
--工作,配置資料庫,這些許多事情都有我親自負責,這樣下來確實很累.重要的是別人無法幫助你,遇到許多問題都要自己解決協調.

--但是我不得不從一件事情說起.

--這個一個分院門診的專案,實際上就是把本部的專案移植到分院,而且僅僅使用門診部分.要不是同事在年終總結會上提及,我個人甚至不
--知道這個工作已經結束.因為我全程都沒有參與這項工作.

--事情是這樣,前一段時間(一個月)星期六,分院的伺服器出現了ora-4030錯誤,這個問題很明顯程式本來就存在大量非繫結變數語句出現
--這個問題是遲早的事情,實際上當時的情況甚至無法正常關閉資料庫,只能shutdown abort關閉.我是正常上班開始介入檢查資料庫:

--這才有了這篇blog: [20160307]訪問外網伺服器問題.txt  http://blog.itpub.net/267265/viewspace-2050520/

--摘抄alert資訊:
System parameters with non-default values:
  processes                = 1500
  sessions                 = 2272
  sga_target               = 512M
  control_files            = "/u01/app/oracle/oradata/XXXxxx/control01.ctl"
  control_files            = "/u01/app/oracle/oradata/XXXxxx/control02.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  log_archive_format       = "%t_%s_%r.dbf"
  db_recovery_file_dest    = "/u01/app/oracle/fast_recovery_area"
  db_recovery_file_dest_size= 41220M
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=XXXxxxXDB)"
  audit_file_dest          = "/u01/app/oracle/admin/XXXxxx/adump"
  audit_trail              = "DB"
  db_name                  = "XXXX"
  open_cursors             = 300
  pga_aggregate_target     = 2505M
  diagnostic_dest          = "/u01/app/oracle"

--可以發現sga_target=512M,而實際上共享池460M,資料快取僅僅剩下16M. 這樣的資料庫什麼用,再看看
--processes=1500,pga_aggregate_target=2505M,明顯不合理,這臺機器記憶體僅僅8G.而這個機器高峰會話僅僅不到10X.
--更要命的是啟動核心是:

# cat /proc/version
Linux version 2.6.18-348.el5xen (mockbuild@ca-build56.us.oracle.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Wed Jan 9 08:32:18 PST 2013

--使用的是xen核心,這導致我無法開啟hugepage引數,執行sysctl -p會報錯.

# sysctl -p
...
error: "vm.nr_hugepages" is an unknown key
error: "vm.hugetlb_shm_group" is an unknown key

--也就是講資料庫配置根本不合理,而這些操作應該在應用前配置好,這些明視訊記憶體在許多問題.

1.比如外網的訪問問題
2.資料庫配置問題,還有許多引數設定不是很合理問題.
3.裡面一大堆不需要的服務根本不需要啟動,比如sendmail.而這些都沒有做,而這些後續的調整我們非常麻煩.
4.剩下的資料庫最佳化工作.

--實際上資料庫最佳化工作才是我的噩夢,估計他們建立的模板不是從正式的伺服器匯入的,而是使用測試環境,我已經在正式的伺服器上建
--立了許多索引,這個最佳化讓我想起某個夏天調優的經歷,而這個專案對於我來講就是一個豆腐渣工程,如果要給它加一個字首的話,就是豆
--腐渣中的豆腐渣,垃圾中的垃圾.

--講了這麼多廢話,實際上我想說的是對於行業分工是建立在團隊各個組都有"精英"的情況,如果每個組都能做好自己的工作才能做好的整
--個工作,而國內許多團隊根本不具備這樣的條件.換一個話,團隊之間除了分工,還必須具有良好的溝通協調能力,而不是相互之間相互推
--來推去.每個組都必須學習自己工作之外的一些知識,而不是僅僅侷限於自己的工作.

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-2102914/,如需轉載,請註明出處,否則將追究法律責任。

相關文章