Monthly Archives: September 2011

ITPUB名人堂访谈已经开展了三期，很荣幸我可以成为第三期的嘉宾。感谢hwayw对于访谈问题的精心准备。 第一期嘉宾是《让Oracle跑得更快》的作者谭怀远 － alantany。 第二期嘉宾是号称百科全书，数年如一日每日一篇技术blog的杨长老杨廷琨 － yangtingkun。 以下是对于我的访谈内容，ITPUB链接参看 － 《ITPUB名人堂》第3期－对话嘉宾：张乐奕先生。 hwayw： 您有曾经在甲骨文供职的经历，如果现在有人想到您曾经工作过的甲骨文公司工作，需要做哪些准备？有什么好的建议给大家？ Kamus: 实事求是地说，甲骨文公司在中国的技术力量并不是中国Oracle从业领域中最强的， 很多Oracle技术高手都不在甲骨文公司，这应该算是比较奇怪的事情，不过这里并没有什么别的意思，之所以提到这个，是想说如果要求职甲骨文，那么技术面试并不会很难，相反要求的可能会有一些英文读写，不过如果应聘的是国内的Team，那么对于英文的要求也是不高的，另外如果有甲骨文员工推荐那么成功率会高很多。据我所知，甲骨文（中国）公司对于传统的数据库领域要求的技术人员并不多（因为已经接近饱和），而通常需求的是较新的产品，比如Goldengate，比如Exadata，比如融合中间件的一系列产品，另外对于懂技术又懂业务（比如OracleEBS套件，BI套件等）的顾问也是很欢迎的。如果你在第三方服务公司已经工作了几年并且已经成为这个公司的技术骨干，那么应该完全可以胜任甲骨文（中国）的技术职位，去试一下吧，没有想象中那么困难。只是如果仅仅是通过网上投简历，那么在浩如烟海的简历中，HR是不是可以筛选到你，这要看运气，这也是为什么说如果有Oracle员工推荐成功率会高很多的原因。 hwayw： 凭借您这么多年的工作经历，ORACLE在大型数据库的应用中主要有哪些应用呢？有哪些优点，以及哪些方面优于其它数据库，ORACLE数据库主要应用的功能是哪些？比如存储过程？还有哪些呢？，现在一般哪些公司用这个呢，银行？还是？能否列举几个实例？ Kamus: 我觉得这个问题需要改一下，可能已经不能说主要有哪些应用采用Oracle数据库了，倒是应该反过来问，有哪些应用不选Oracle数据库呢？ 据我所知，除了四大银行核心系统采用IBM大机，这是Oracle数据库没有进入的领域（实际上很多稍小的银行核心系统也是采用Oracle数据库），之外几乎没有Oracle数据库不涉猎的，当然一些大客户的系统非常多，也绝不仅仅是只采用Oracle一家的产品，比如电信行业的BI目前应该就是被IBM垄断的。另外，现在如火如荼的电子商务（Web网站）领域，也大量采用MySQL等开源数据库，甚或是如MongoDB这样NoSQL数据库，但是通常在重要的订单生成及支付环节，还是在使用Oracle数据库。 提到Oracle数据库的优点，这是见仁见智的问题，每个数据库产品在技术上都有自己的优点，我就不再品评技术上的优劣，非技术的原因其实也有很大关系，我觉得之所以Oracle数据库受欢迎，是因为其采用了免费下载的方式，迅速获得了大量技术人员的熟悉和支持，这一点跟Windows在国内的发展其实可以相提并论，说得更实在一些，盗版成就市场。我一直认为其它厂商也完全应该仿效这种模式，免费下载，免费测试，商业使用再付费。另外，每2年一次的大版本升级，也让Oracle数据库始终走在技术前沿，不管如何，混个脸熟，这是必须的。 hwayw： 在您工作的大型企业，您用得最多的灾难备份的技术或者方法是哪种呢？还有就是您工作的经历，出现过哪些数据丢失或者数据恢复，或者是某个数据服务器损坏令您印象比较深刻，谈谈您在处理完这些故障后的感想？ Kamus: 目前灾备技术仍然大量使用Oracle的Dataguard，如果说RAC也算是灾备的一种，那么就更加普遍了。如果Goldengate也算作灾备，那么近两年来在Oracle的大力推动下，也成为很多客户的选择。 数据丢失及恢复案例中，印象较为深刻的一次，是我们的一个客户在我们的建议下，准备为没有任何备份的数据库添加RMAN备份策略，但是由于空间问题，需要先添加一些磁盘，在Linux操作系统上，添加了一块磁盘，然后重启了主机，想当然的将最后一块磁盘格式化了（意思是之前有/dev/sda和/dev/sdb，添加了新硬盘以后，认为新硬盘必然是/dev/sdc，因此就直接格式化了/dev/sdc，并且创建了文件系统），但是实际上新加的盘是在机器重启以后被认成/dev/sda，而原先的sda和sdb则变成了sdb和sdc，所以格式化/dev/sdc的命令就直接将一个包含了大量数据的ASM磁盘格式化掉了。没有任何备份，磁盘被格式化，非常悲惨的一次事件。最后虽然我们通过一系列手段将大部分数据救回，但是客户也为此损失了大量财力人力和时间。 之所以印象深刻，是因为这个案例是在实施灾备的过程中破坏了数据，就好比在买保险的路上被车撞了，它告诉我们灾难时刻存在，一分一秒都可能碰上，细心＋技术可以避免一些问题，但是只有完善的灾备才可以救命于水火，试想如果你的机房部署在2001年9月11日的纽约双子大厦，仅此一份，没有异地备份，前一秒可能还在洋洋自得，系统性能调整的多好，业务又得到长足发展，后一秒一切都化为乌有，再细心再有技术也于事无补。 hwayw： 现在有越来越多的人对DBA的未来担忧，随着数据库版本的升级，系统越来越稳定，功能越来越齐全，将来的DBA工作是否会被稳定的软件系统所取代，您对此有何看法？您觉得DBA的前景如何？ Kamus:…