記錄於今年5月的一次面試，最近熊熊太忙了，一直沒有上博客，先發一篇面試總結，謹以紀念即將遠去的2013年。
昨日去了某業內知名地圖軟件公司面試，是上週投的簡歷，週一就收到了HR的電話通知，約在週三的下午2點，郵件裏很清晰的寫出瞭如何坐車等等，HR還算專業~
週三中午，熊熊整裝出發，輕裝簡行，連筆記本都沒帶，結果坐車想當然了，坐到了十五號線望京站下車（郵件裏寫的是13號線望京西，唉，習慣了），結果下車以後沒有要坐的那趟車，自己還想當然的坐上了421，又遠了兩站地，趕緊下車，知道坐錯了，到馬路對面打了個車，趕到了方恆國際，打車費還花了11大洋，心疼喲~
坐電梯上了16樓，公司還真不小，前臺不太禮貌，唉，有點得瑟，讓熊熊簽了個到，就讓一邊坐着等着，看到來面試的人真不少，大部分都是開發，趴在桌子上做筆試題，熊熊有年頭沒這樣了，嘿嘿~
過了一會兒，一個女孩（應該就是給我電話的HR）下來跟我說，要面試我的經理正在趕回來的路上，要熊熊稍等十幾分鍾，還很客氣的給熊熊倒了杯水，蠻專業，我喜歡~
等了相近20分鐘，一個30多歲的男子過來問我是不是張小熊，回答是以後，他坐下來跟我說，我就是負責公司運維的經理，咱們簡單聊聊，於是簡單的讓熊熊做了一個自我介紹，關於神碼那裏，熊熊寫的是運維經理，他就想當然的認爲是做運維方面的管理工作，第一次不專業~
然後就開始問了熊熊一些具體問題，下面一一列出對話（那個經理簡稱A）
A：你知道數據庫的三大範式嗎？
熊：額，這個真沒研究過，不知道（這裏確實是熊熊功課不夠，師太還特意囑咐過熊熊，很多DBA面試會考三大範式，但是熊熊懶得去看）
A：那你知道數據庫的ACID原則嗎？
熊：ACID原則？沒聽過，我沒研究過這個（這裏第二次丟人，不過ACID原則確實沒聽過，後來百度才知道，是事務的幾個基本原則，其實很easy）
A：（有點不耐煩感覺），那你都研究什麼？
熊：我只研究如何做好事情，不去考量這些純概念性的東西，純概念的東西跟基礎是兩個東西，我不看這些不代表我基礎不紮實
A：那你說一下事務的基本原理吧
熊：事務？事務具有完整性，也就是說事務只能被提交或者被回滾，不會中斷；事務具有獨立性，每個事務都是唯一的；DML操作需要保證事務的一致性，並且事務是一直存在的，除非提交或者回滾。（後來才知道，這就是所謂的ACID原則，虧熊熊其實很瞭解，但是不知道，丟人）
A：那你來說一下，如果讓你管數據庫，你怎麼管？
熊：你說的這個太泛泛，能具體一點嗎？
A：假設有20臺Oracle數據庫，30臺MySQL數據庫，你怎麼管？
熊：這裏面涉及到了什麼技術，Oracle有沒有RAC集羣？幾個節點？20臺服務器肯定是好幾個項目，有沒有單點的機器，單點的機器有沒有災備系統？用的是DG還是GG，MySQL集羣是主從還是cluster還是主主從？
A：假設這些都用到
熊：（感覺丫第二次不專業，於是語氣有點急了），不可能，沒有任何一個項目能用到所有的技術，就算是假設，那麼假設必須在可實現的基礎上纔有意義，你怎麼可能一個項目又用DG又用GG，有必要嗎？
A：你別緊張（其實熊熊沒有緊張，是有點激動），你就泛泛說說
熊：OK，既然這樣，我們先拋開MySQL不談，只談Oracle，有幾個節點的RAC，存儲用的什麼模式，是FC還是iSCSI？如果是單點，是否有災備？ DG還是GG，如果是DG，是10g還是11g？備份採用什麼？標準RMAN技術還是NBU或者TSM這種備份軟件？這些都要考慮到啊
A：RMAN是什麼？（第三次感覺丫不專業，如果真心知道RMAN技術，不應該這麼問，這麼問，感覺丫都不懂RMAN）
熊：Oracle內部的一個強大的備份工具啊，可以支持熱備，包括克隆數據庫等等，很多強大功能
A：OK，我們繼續，那還有其他方向嗎
熊：剛纔說到的是讓數據庫如何穩定、可靠的運行，這些僅僅是數據庫層面還不夠，我們的存儲性能如何，網絡背綁帶寬如何，包括我的中間件用的什麼，比如WLS、WAS、Jboss還是tomcat？像tomcat經常會遇到內存溢出的問題，那就需要具體去研究
A：等等，你一個數據庫管理員，還要關心Tomcat內存溢出？
熊：（真急了）你也太不專業了吧，作爲一個運維部門領導，難道你的網站慢了，客戶問你，你只對你的DBA說，看看數據庫有沒有問題，然後DBA告訴你，我數據庫這邊沒問題，你看看別的問題吧，那樣的話，這個DBA充其量只能算合格，絕對不夠優秀
A：（估計是有點頭疼）恩恩，你答的不錯，請問你有什麼要問我的？
熊：每個DBA都需要知道自己的職責和權限，如果我真有幸加盟貴公司，我想知道數據庫這塊可以操作的權限
A：（很隨意的）你說了算（再一次感覺不專業，不過已經習慣了）
熊：這不是誰說了算的問題，很多東西必須在一開始設計好，已經上線的項目也就罷了，最簡單的一個例子，一個新上線的項目，數據庫的設計到底由開發來牽頭，還是DBA還設計？
A：這個，一開始肯定是開發權限比較高
熊：那這樣的系統是一個打補丁的系統，以後會有一堆問題要解決，運維會淪落爲技術支持部門，而沒有自己的思想，既然能事前解決，爲什麼不一開始就把這些設計好？
A：（沉思了一會兒，估計是以前從來沒想過這些）嗯，你說的有道理，也可以試試
熊：OK，我沒啥其他問題了
A：那你等一下，我們有個數據庫專家要給你面試一些更深入的技術
熊：好的，歡迎討論
——————————————我是華麗的分隔符——————————
過了十幾分鍾，接到一個電話（以下簡稱B）
熊：喂，您好
B：你是來XX面試的吧，剛纔那個經理跟你說有個面試是吧？
熊：嗯，是的，您說
B：那我簡單跟你溝通一下
熊：好的，您說
B：你是OCM是吧，那你工作中用過RAC和DG嗎？
熊：（鄙視拿OCM說事的人，OCM現在看來就是個屁）RAC和DG這些也太基礎了吧，肯定用過啊
B：很基礎嗎？
熊：嗯，這些技術確實很基礎，沒啥特別難的，只要知道原理
B：那你工作中用過幾個節點的RAC最多
熊：4個節點，因爲再多也沒有太大意義，除非是支付寶那種海量存儲架構，因爲每增加一個節點，運維成本成幾何倍數增長
B：爲什麼這麼說？
熊：很簡單，因爲每增加一個節點，OCR進程都要複製一份OCR信息到那個節點，Voting Disk也要增加這個節點的信息，而且，對於新增的節點，每個原有節點的歸檔都要同步到此節點，運維風險還是很高的（這裏熊熊說的不一定對哈，但是個人感覺應該是這樣的，歡迎指正）
B：那DG你用過嗎
熊：我們現在不是很推薦用DG，因爲如果是10g的DG，那麼那臺備機沒有任何意義，只是單純的備機（10g只能到mount狀態），如果是11g的話，還能open read only，這樣做成查詢庫還有點意義，我們現在更多使用GG
B：什麼東西？
熊：GG，GoldenGate，你沒用過嗎
B：嗯，沒有，我沒用過
熊：（有點小鄙視），GG實現的同步方式比DG更安全快捷，而且從成本上來說，如果你Oracle是付費的，也不會在乎GG這點花銷，如果你Oracle都不是付費的，又何必在乎GG，有新的技術，而且很好，我們爲什麼不用？
B：那你就說說DG有幾種方式？
熊：是幾種安裝配置方法還是有幾種模式
B：就是幾種模式
熊：那就是三種了，最大性能，最大保護，最大可用，默認爲最大性能
B：那麼最大性能模式是物理DG還是邏輯DG
熊：生產庫肯定都是物理DG啊，否則要DG幹啥，除非你read only做報表庫，但是10g這樣搞沒意義啊，起不到災備的效果啊
B：ok，那你對SQL性能優化這塊做過嗎？
熊：是SQL應用方面的性能優化還是SQL方面的數據庫優化？
B：有區別嗎？
熊：（再一次鄙視他）當然有，如果是從數據庫層面考慮，可能是該SQL的書寫不規範；沒有采用綁定變量導致SQL沒有緩存到buffer cache中，大量硬解析；SQL沒有很好的採用索引，或者索引設計不規範；如果是SQL本身，那麼可能是表設計就有問題，比如where條件的排序等等，各種可能。
B：那麼如果一個SQL，數據量小的時候查詢很快，數據量大了查詢很慢，是什麼原因？
熊：這個有可能是沒有走索引，或者索引設計不合理；而且，如果是單表，數據量大了是什麼概念，超過1000W？做沒做分區，有米有分區索引？表設計有沒有問題，查詢的列是熱點列嗎？
B：那麼如何判斷一個SQL有問題，有哪些工具優化？
熊：從開發角度，如果用比較規範的SQL寫法，PL/SQL develop和toad工具都很不錯，從DBA角度，查詢SQL是否不合理，從AWR、ASH、ADDM以及RDA等報告中，如果該SQL不合理，一定會在top事件中反應出來，通過不同的等待事件，具體問題具體分析
B：你沒聽懂我意思，我是說，你如何判斷一條SQL有問題，比如我給你一條SQL，你怎麼判斷他有問題？
熊：那我可以爲這條SQL做一個執行計劃來看一下他是如何來執行的，或者抓一下trace
B：trace？
熊：就是用tkprof抓一下trc啊，瞬時的
B：還有其他方法嗎？
熊：通過動態性能視圖可以找到這條SQL產生問題的事件原因
B：還有嗎？
熊：還要什麼，這樣已經很清楚了，你能很清楚的知道SQL的執行計劃，知道哪裏不合理，還需要什麼？
B：OK，我跟領導反應一下，然後一會兒應該會有其他領導面試你，你稍等一下
熊：好的
——————————————又一次見到我了，親——————————
又過了十幾分鍾，熊熊以爲會有新的人來面試，結果又是那個HR小姑娘，跟熊熊說，那今天就先到這裏，我們會在一週到兩週內通知您是否進行復試
以熊熊多年的經驗，這麼說應該90%就是掛了，唉，掛了也好，這種公司，估計進去了也是做不到自己想做的事情，浪費生命~