记录于今年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:假设有20Oracle数据库,30MySQL数据库,你怎么管?

熊:这里面涉及到了什么技术,Oracle有没有RAC集群?几个节点?20台服务器肯定是好几个项目,有没有单点的机器,单点的机器有没有灾备系统?用的是DG还是GGMySQL集群是主从还是cluster还是主主从?

A:假设这些都用到

熊:(感觉丫第二次不专业,于是语气有点急了),不可能,没有任何一个项目能用到所有的技术,就算是假设,那么假设必须在可实现的基础上才有意义,你怎么可能一个项目又用DG又用GG,有必要吗?

A:你别紧张(其实熊熊没有紧张,是有点激动),你就泛泛说说

熊:OK,既然这样,我们先抛开MySQL不谈,只谈Oracle,有几个节点的RAC,存储用的什么模式,是FC还是iSCSI?如果是单点,是否有灾备? DG还是GG,如果是DG,是10g还是11g备份采用什么?标准RMAN技术还是NBU或者TSM这种备份软件?这些都要考虑到啊

ARMAN是什么?(第三次感觉丫不专业,如果真心知道RMAN技术,不应该这么问,这么问,感觉丫都不懂RMAN

熊:Oracle内部的一个强大的备份工具啊,可以支持热备,包括克隆数据库等等,很多强大功能

AOK,我们继续,那还有其他方向吗

熊:刚才说到的是让数据库如何稳定、可靠的运行,这些仅仅是数据库层面还不够,我们的存储性能如何,网络背绑带宽如何,包括我的中间件用的什么,比如WLSWASJboss还是tomcattomcat经常会遇到内存溢出的问题,那就需要具体去研究

A:等等,你一个数据库管理员,还要关心Tomcat内存溢出?

熊:(真急了)你也太不专业了吧,作为一个运维部门领导,难道你的网站慢了,客户问你,你只对你的DBA说,看看数据库有没有问题,然后DBA告诉你,我数据库这边没问题,你看看别的问题吧,那样的话,这个DBA充其量只能算合格,绝对不够优秀

A:(估计是有点头疼)恩恩,你答的不错,请问你有什么要问我的?

熊:每个DBA都需要知道自己的职责和权限,如果我真有幸加盟贵公司,我想知道数据库这块可以操作的权限

A:(很随意的)你说了算(再一次感觉不专业,不过已经习惯了)

熊:这不是谁说了算的问题,很多东西必须在一开始设计好,已经上线的项目也就罢了,最简单的一个例子,一个新上线的项目,数据库的设计到底由开发来牵头,还是DBA还设计?

A:这个,一开始肯定是开发权限比较高

熊:那这样的系统是一个打补丁的系统,以后会有一堆问题要解决,运维会沦落为技术支持部门,而没有自己的思想,既然能事前解决,为什么不一开始就把这些设计好?

A:(沉思了一会儿,估计是以前从来没想过这些)嗯,你说的有道理,也可以试试

熊:OK,我没啥其他问题了

A:那你等一下,我们有个数据库专家要给你面试一些更深入的技术

熊:好的,欢迎讨论

——————————————我是华丽的分隔符——————————

过了十几分钟,接到一个电话(以下简称B

熊:喂,您好

B:你是来XX面试的吧,刚才那个经理跟你说有个面试是吧?

熊:嗯,是的,您说

B:那我简单跟你沟通一下

熊:好的,您说

B:你是OCM是吧,那你工作中用过RACDG吗?

熊:(鄙视拿OCM说事的人,OCM现在看来就是个屁)RACDG这些也太基础了吧,肯定用过啊

B:很基础吗?

熊:嗯,这些技术确实很基础,没啥特别难的,只要知道原理

B:那你工作中用过几个节点的RAC最多

熊:4个节点,因为再多也没有太大意义,除非是支付宝那种海量存储架构,因为每增加一个节点,运维成本成几何倍数增长

B:为什么这么说?

熊:很简单,因为每增加一个节点,OCR进程都要复制一份OCR信息到那个节点,Voting Disk也要增加这个节点的信息,而且,对于新增的节点,每个原有节点的归档都要同步到此节点,运维风险还是很高的(这里熊熊说的不一定对哈,但是个人感觉应该是这样的,欢迎指正)

B:那DG你用过吗

熊:我们现在不是很推荐用DG,因为如果是10gDG,那么那台备机没有任何意义,只是单纯的备机(10g只能到mount状态),如果是11g的话,还能open read only,这样做成查询库还有点意义,我们现在更多使用GG

B:什么东西?

熊:GGGoldenGate,你没用过吗

B:嗯,没有,我没用过

熊:(有点小鄙视),GG实现的同步方式比DG更安全快捷,而且从成本上来说,如果你Oracle是付费的,也不会在乎GG这点花销,如果你Oracle都不是付费的,又何必在乎GG,有新的技术,而且很好,我们为什么不用?

B:那你就说说DG有几种方式?

熊:是几种安装配置方法还是有几种模式

B:就是几种模式

熊:那就是三种了,最大性能,最大保护,最大可用,默认为最大性能

B:那么最大性能模式是物理DG还是逻辑DG

熊:生产库肯定都是物理DG啊,否则要DG干啥,除非你read only做报表库,但是10g这样搞没意义啊,起不到灾备的效果啊

Bok,那你对SQL性能优化这块做过吗?

熊:是SQL应用方面的性能优化还是SQL方面的数据库优化?

B:有区别吗?

熊:(再一次鄙视他)当然有,如果是从数据库层面考虑,可能是该SQL的书写不规范;没有采用绑定变量导致SQL没有缓存到buffer cache中,大量硬解析;SQL没有很好的采用索引,或者索引设计不规范;如果是SQL本身,那么可能是表设计就有问题,比如where条件的排序等等,各种可能。

B:那么如果一个SQL,数据量小的时候查询很快,数据量大了查询很慢,是什么原因?

熊:这个有可能是没有走索引,或者索引设计不合理;而且,如果是单表,数据量大了是什么概念,超过1000W做没做分区,有米有分区索引?表设计有没有问题,查询的列是热点列吗?

B:那么如何判断一个SQL有问题,有哪些工具优化?

熊:从开发角度,如果用比较规范的SQL写法,PL/SQL developtoad工具都很不错,从DBA角度,查询SQL是否不合理,从AWRASHADDM以及RDA等报告中,如果该SQL不合理,一定会在top事件中反应出来,通过不同的等待事件,具体问题具体分析

B:你没听懂我意思,我是说,你如何判断一条SQL有问题,比如我给你一条SQL,你怎么判断他有问题?

熊:那我可以为这条SQL做一个执行计划来看一下他是如何来执行的,或者抓一下trace

Btrace

熊:就是用tkprof抓一下trc啊,瞬时的

B:还有其他方法吗?

熊:通过动态性能视图可以找到这条SQL产生问题的事件原因

B:还有吗?

熊:还要什么,这样已经很清楚了,你能很清楚的知道SQL的执行计划,知道哪里不合理,还需要什么?

BOK,我跟领导反应一下,然后一会儿应该会有其他领导面试你,你稍等一下

熊:好的

——————————————又一次见到我了,亲——————————

又过了十几分钟,熊熊以为会有新的人来面试,结果又是那个HR小姑娘,跟熊熊说,那今天就先到这里,我们会在一周到两周内通知您是否进行复试

以熊熊多年的经验,这么说应该90%就是挂了,唉,挂了也好,这种公司,估计进去了也是做不到自己想做的事情,浪费生命~