Oracle感慨(转)
一转眼接触ORACLE已经一年了，在这一年中收获多多，感慨多多，我记得是2004年11月底开始学习ORACLE的，当时选择方向也是几经波折，还好现在的处境不是非常的艰难，前途似乎还有想象中的光明。
毕业已经两年半，开始半年主要是接触Sybase，当时公司后台使用的Sybase SQL 11,由于人手比较少，管理也不很严格，所以我经常有机会光顾他，在那里我学会了怎样备份，恢复数据库，怎样写SQL代码处理公司的业务逻辑，那个时候想的也很简单，理解也非常肤浅，觉得数据库的作用就是存数据，取数据，封装业务逻辑，当然现在很多时候我也这么认为。
很快到了2004年，公司开始使用SQL SERVER 2000，我有机会接触这个Sybase的孪生兄弟了，我的工作除了用PB编写前台那些笨拙的界面，还负责整个数据库的维护与管理，这时我已经不满足建个数据库就可以使用，写个SQL脚本就可以运行，我将更多的精力投放在很多内部的运做机制上，比如索引的结构是怎样的，利用索引定位数据，他是怎么从根页到中间层到叶接点在到数据页的，DML对索引有什么影响，什么情况下会造成页分割，填充因子又有什么作用。DML和COMMIT有什么关系，数据库提出先写日志是怎样一种情况，结合CHECKPOINT考虑各种断电情况对数据一致性的影响，使用日志备份恢复时为什么总是出现LSN太早的问题，日志传输的原理是什么，数据文件是否可以分散到多个磁盘来均衡IO，RAID0的使用是否使得文件组显得多余。各种LOCKS的概念，对数据库的影响，锁升级，事务隔离级别，等等等等，通过对这些概念的理解与实践，我慢慢感觉到数据库的博大精深，这个时候数据库的每个操作不在是个简单的动作，引用李小龙的话：在我刚开始学武时，我觉得一拳就是一拳，一脚就是一脚，而经过一段时间的提升，我觉得一拳不在是普通的一拳，一脚也不在是普通的一脚，但最后，我觉得一拳还是那么一拳，一脚还是那么一脚。可惜笔者现在还是停留在第二个层次，向第三个无招胜有招，草木为剑的境界的过度，还需要时间。同时在这段时间，我还学习java，写些简单的聊天程序，打好了一个大致的框架，但最后还是以一个蹩脚的扫雷游戏而告终。
到了11月底，考虑换工作，本来想做Java的，但网上招聘的要求太高，或以没有实际的项目经验为由将我拘之门外，有些公司给人的感觉是比尔盖茨进来了也只有刷马桶的份。也搜索了下DBA之类的职位，很少有专门做SQL SERVER和Sybase的，但做Oracle的还是蛮多的，既然Java找不到，SQL也不招，自己又不想干回以前的PB，索性来个猛料，学Oracle，在数据库这条路上已经投入这么多了，为什么不能将他当成自己的主业呢？就这样我开始接触Oracle了，比我想象中的要顺利的多，因为我在SQL SERVER中已经做的很多了，我知道数据库的存储结构，内存体系，锁存资源，熟悉数据库的各个动作以及与他们打交道的方式，这些在SQL SERVER中已经理解的非常透彻了，现在换到ORACLE，同是RDBMS，两者竟然有些地方如此的相似（当然差别也是巨大的），比如事务的提交，都是先写日志，刷新日志缓存的内容到日志文件，数据不立刻反映到数据文件，随着事务的堆积，到一定限度时，由checkpoint进行同步，启动时照样是根据日志最末尾的检查点标记为起点进行实例恢复，他们都要保证连续的事务日志来进行日志恢复。不同的是Oracle维护自己的SCN号码，对数据的前映象以回滚段的方式来记录，在数据块上存在事务链表来关联事务与回滚段块之间的联系，而SQL SERVER中是以LSN来代替SCN，当然他的数据前映象是记录在日志文件中，没有回滚段的概念。在比如存储结构上，两者都是以文件的形式，将数据分布到不同磁盘，以均衡磁盘IO，一个体现在表空间，一个体现在文件组，这两个都可以作为备份的单元来使用.
ORACLE中对象以数据块的方式存储，以盘区为单位进行扩展，本地管理表空间中以数据文件头几个数据块的位图映象来表示空间的使用情况，SQL SERVER是以页来存储对象（1页8K，相当于块），以盘区来扩展，以全局分配映射页来维护盘区的使用情况，这不是异曲同工吗？在内存的使用上两者都维护自己的缓冲链表，根据缓存页的TCH计数器来判断热块冷块，以决定内存不足时将哪些数据块flush，但ORACLE将更多的管理权限开放给了DBA，可以划分不同块大小的缓冲区，以满足不同的查询需求，我们公司现在的OLTP系统有些表多半是单行的索引读取事务，我将他们划在2K的BLOCK区域，而有些表是晚上跑报表的，我将他们划在32K的BLOCK区，他们之间互不干扰，有着自己独立的LRU链表，运行的非常好。在学习中通过这些相同与不同，体验两个DBMS之间的优劣，进步是非常快的，当然刚开始也有一种眼高手低的状态，很长一段时间我不知道坐在ORACLE面前要干什么，概念理论想通了却不会查询基本的视图，敲不出基础的命令，甚至还在CSDN上发贴问表空间的建立语句怎么写。这一切已经过去，我现在已经熟悉很多命令了，并被公司的人称为命令狂人，可以说SQL SERVER是我数据库的基础，虽然现在不使用他，但ORACLE的学习也使我对SQL的理解更加深刻，个人感觉SQL SERVER封装了太多的东西，易用，便于管理，这样留给DBA的空间就比较少了，大家都知道在ORACLE中你可以dump出数据块，内存区，控制文件来进行内部结构的研究，这些在SQL SERVER中是没有的，我就见过有人通过对数据块的深入研究，发现了ORACLE数据文件的内部存储格式，从而他写出工具，可以物理的硬解析数据文件，获取里面的数据。
对于这两个DBMS谁好谁坏，我不想说，感觉没有什么意义，网上有很多精彩的讨论，你如果有兴趣，可以看看这位猛将兄的发贴
http://blog.dev-club.com/bscy/archive/2005/10/17/2840.html
很快我凭借自己的这么点资本找到了工作，在一家负责移动业务的通信技术公司担任DBA，这个时候有了实际的工作环境，学习起来更加得心应手了，知识的巩固来源于实践，这个真的没错，以前的那些概念，以点成线，以线成面，清晰的展现在脑海中，抹之不去，这就是实际工作的感觉。在公司负责编写了核心的存储过程包，为研发的代码员们做SQL TUNING，维护在线的RAC体系数据库，帮助测试部门搭建数据库环境，为工程部处理业务数据，还帮助SQA部门调整SQL SERVER，有次他们的一个哥们问：你也会SQL SERVER啊，不是做ORACLE的吗？偶告诉他我通晓各个RDBMS（有点不要脸），逗的他哈哈大笑。
对于ORACLE的学习，我分为3个部分，1是PL/SQL编程，2是数据库的性能调整，3是备份与恢复体系，其他的高级特性根据自己的业务需求去啃。
对于1，上手比较快，但写出高质量的语句不是很容易的事，还有一些比较高级的PL/SQL编程也是很有学头的。
对于2，我觉得是最难的一块，我在这部分做了那些可以参考下面链接
http://blog.dev-club.com/bscy/archive/2005/09/05/2463.html
对于3，如果你只是想做个称职的DBA，保证数据库的正常运行，你不必专研太多，了解备份恢复的方法，考虑好备份方案，及时的实施就可以了，如果你喜欢扮演力挽狂澜的英雄，喜欢为别人提供技术支持处理各种灾难现场，那就准备熬夜，仔细的梳理SCN，CHECKPOINT，控制文件，数据文件头，日志文件，事务的COMMIT，ROLLBACK，UNDO之间的关系，不能有丝毫的模糊与不明确，针对各种灾难现场进行模拟实验，我的BLOG上有很多这方面的模拟实验和概念的理解，有兴趣可以交流下。
作为一名DB工作者，严谨是必须的，程序写不出来，自己慢慢调整，数据库起不来，数据逻辑错误，这个损失可是巨大的，很多企业多DB的重视程度不够，对DBA的轻视也让我感到心寒，多上下国外的网站，就能感受到明显的差别，下面这个链接是著名的Thomas Kyte, Jonathan Lewis针对Donald K.Burleson, Mike Ault这帮蠢材提出的一些误导观念的激烈反击，从这可以看出世界狂人们的严谨态度
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:35336203098853
现在2005年就快结束，偶的本命年，呵呵，写下这篇流水帐，感慨一下，上海的冬天真冷，风大，祝各位工作愉快，新年快乐（不算早吧，呵呵）。
