Maclean写的Oracle入门书

 试读目录：

第一章 Oracle数据库源流考

第二章 Oracle体系架构漫谈

第一章 Oracle数据库源流考

1. Oracle数据库源流考
2. Oracle数据库今后的大势

Oracle数据库源流考

如果对Oracle软件发展历程不感兴趣，可以跳过本章节

Oracle之名源于甲骨文CEO 拉里·埃里森在20世纪70年代在一间名为Ampex的软件公司，为中央情报局设计的一套代号为Oracle的数据库软件，拉里·埃里森是当时的程序员之一。

1970年当时还就职于国际商业机器公司(IBM)的Edgar F. Codd发表了名为《A Relational Model of Data for Large Shared Data Banks》的文章，最早提出了关系型模型(Relational Model)。 这篇文章启发了拉里·埃里森开发一个RDBMS数据库的想法。

Edgar F. Codd在1981年获得图灵奖，

他还设计了能够自我复制的计算机

书刊和媒体常将Oracle描述为第一个RDBMS软件，但这个提法是错误的。因为实际上IBM的一个实验室” San Jose Research Laboratory”在1974年以研究为目的开发了一套名为”IBM SYSTEM R”的数据库软件，SYSTEM R同样受到Edgar F. Codd的启发。 SYSTEM R是第一个RDBMS软件，也是第一次采用SQL语言的软件。SYSTEM R有过少量客户例如Pratt & Whitney(U.S.-based aerospace manufacturer with global service operations)。 可惜的是IBM由于商业利益问题(为了保护其 IMS/DB产品的营收)，而拒绝大规模采用关系型模型，直到IBM发现RDBMS已经成为市场主流，则悔之晚矣。最终在RDBMS市场上被Oracle这个后起之秀甩到了身后。

一般认为SYSTEM R是第一个RDBMS软件，但没有广泛的商业发行。 而Oracle Database是第一个商业发行的RDBMS软件。

拉里·埃里森从 Ed Oates(甲骨文的另一个联合创始人)那里获得了一份IBM的研究杂志，这份杂志上介绍的SYSTEM R系统引起了拉里的兴趣。一开始拉里希望让Oracle的产品能与SYSTEM R相兼容，但IBM封闭守旧的做法让这种想法泡汤了。

到了70年代末的1977年，拉里和Bob Miner 以及Ed Oates创立了软件开发实验室(Software Development Laboratories (SDL))， 1979年更名为 Relational Software, Inc. (RSI)， 到1982年更名为Oracle Systems Corporation沿用至今，1986年Oracle上市时年收入暴增到5500万美元，甲骨文传奇从此为世人熟识。

 左起为Ed Oates，Bruce Scott，Bob Miner，Larry Ellison 

到今天(2013年)Oracle已经发展成世界第二大独立软件公司，2011年的年收入达到268亿美元，拥有10万名员工，总部位于美国加州红木城。

 美国加州红木城Oracle总部

1989年Oracle进入中国，1991年7月甲骨文公司在北京建立独资公司——北京甲骨文软件系统有限公司。

进入中国之初Oracle数据库并没有大规模占领市场，90年代中国的RDBMS市场还是Sybase和Informix时代。Maclean有幸与一位在国内维护过Oracle 6的老前辈共事过，在那个中国IT的洪荒时代Oracle没有留下太多的印记。

在1992年发行的Oracle 版本6中提出了RAC的雏形OPS- Oracle Parallel Server，而在Oracle 7中提出了MPP OPS，较为流行的版本是7.3.4。1997年发行版本Oracle 8，但由于bug太多，市场反应平平。  在1年后1998年，响应互联网的发展提出了8i，这里的i即为Internet互联网。之后Oracle的版本号都是数字加一个字母的组合，字母代表了这个版本的特性指向。  例如版本10和11采用G – GRID，意为网格计算。而版本12则开始采用C-Cloud，那是因为云计算在市场中大热。

从8i开始国内的一些电信运营商大规模采用Oracle作为其业务核心数据库，少数最为重要的系统已经不满足于HACMP所实现的高可用，纷纷采用OPS来实现更高的可用性。就算到现在(2013年)，据Maclean所知仍有极少数版本8i的数据库运行在 电信运营商、码头公司等机构充当一些历史库环境，在陈旧的机房中那一台台过时的小型机里，屏幕上黑底绿字的终端里一串串字符飘过，虽然经历近15年的服役，但8i的稳健令人敬佩。

国内的第一代Oracle DBA在这样的大背景下出现，这些老前辈十分值得我们这些后来者致敬，在因特网不发达的年代除了购买Oracle License附赠的手册Manual和少数基本教材之外，你很难找到更多有用的材料；这种材料匮乏的环境，就需要DBA本人花费更多的精力去尝试测试各种功能和问题。 在此maclean向国内的第一代DBA致以敬意。

 Oracle 3的用户手册

 关于Oracle的版本历史，在初版中不在鏖述，今后可能再次完善。

下附 Oracle Database 发行历史年表：

如果你读过oracle的一些内部trace( trace是指对进程运行的追踪，后面我们会详细介绍)，那么会了解到 1988年这个特殊的年头，实际上Oracle的源代码在1988年左右被彻底重写过，换句话说现在版本的Oracle  代码主要源流是Oracle 6和Oracle 7。

在Oracle 6是中首次实现了行级锁定，首次实现了数据库热备份，Oracle公司从Belmont移到加利福尼亚的redwood  shores，并引入了PL/SQL。

Oracle数据库未来的发展大势

近几年随着 云计算和大数据 2个概念被持续被炒热，因此Oracle的版本特性也不断在往这2个流行词上靠。 实际上甲骨文对于 云cloud概念的热棒还是最近几年的事情，  早几年 拉里·埃里森曾嘲讽 “我完全搞不懂那帮家伙在说些什么，简直就是一派胡扯。这（云计算）到底是指什么？省省这种愚蠢的概念吧。”   但拉里无愧为经历数十年IT风云的运作老手，发觉大势不对，马上扭过头来鼓吹自家的云计算技术。 实际上将Oracle 10g中G所指的Grid Computing 网格运算 调换一下称谓，忽悠成cloud computing ，则在大量应用场景中都无不妥。

随着Enterprise Manager 12c Cloud Control的发行，世人惊叹甲骨文以惊人的速度撞入云计算的怀抱；及至2013年Oracle Database 12c发布， 又提出了众多与云计算相关的特性， 例如 多租户的Multitenant Architecture、灵活自动存储管理Flex ASM和 灵活集群 flex cluster。

Flex Cluster原名Big Cluster ,由于不管是OPS还是RAC 均是share disk共享磁盘架构，这大大限制了Oracle Cluster集群的扩展能力，在过去4节点以上的RAC是很少见的。

reference:

http://zh.wikipedia.org/wiki/%E7%94%B2%E9%AA%A8%E6%96%87%E5%85%AC%E5%8F%B8
http://en.wikipedia.org/wiki/Oracle_Corporation

第二章  自学Oracle数据库的自由之翼

1. 从哪里开始？
2. 孤岛危机  哪里找资源/材料？
3. 如何读文档
4. 注意事项
5. 如何实践？
6. 关于安装和补丁
7. 关于BUG和意外表现unexpected behavior

关于从哪里开始学习， 自来都有争议，有同学推荐 从备份恢复入手 =》到concept 概念 再到 管理手册， 而有同学推荐 从 concept概念入手 再到备份恢复概念和管理手册； 又有的同学建议 直接从OCA、OCP的学生手册入手。

这里说的 备份恢复手册、概念手册、管理手册 均指Oracle官方文档的一部分， Oracle数据库官方文档是任何人都可以阅读的文档， 文档本身也是公开 可以下载的。

Oracle Database 11.2 官方文档目录： http://www.oracle.com/pls/db112/homepage

11.2的 Database concept 概念文档： http://docs.oracle.com/cd/E11882_01/server.112/e25789/toc.htm

11.2的 Oracle Database Backup and Recovery User’s Guide 备份恢复手册： http://docs.oracle.com/cd/E11882_01/backup.112/e10642/toc.htm

11.2 的Oracle administrator guide管理员手册 http://docs.oracle.com/cd/E11882_01/server.112/e25494/toc.htm

Oracle Database 10.2的官方文档目录：　http://www.oracle.com/pls/db102/homepage

10.2的 Database concept 概念文档 ：  http://docs.oracle.com/cd/B19306_01/server.102/b14220/toc.htm

Oracle Database Backup and Recovery Basics  http://docs.oracle.com/cd/B19306_01/backup.102/b14192/toc.htm

8i到9i的文档 也可以在文档归档网站 http://tahiti.oracle.com/ 上找到

为什么要读文档？  不读文档Oracle的一个小领域就能让你困惑到十万个为什么， 读了文档 的话可以减少到一百个为什么。

在Maclean看来这几种方法各有优缺点 ：

从concept入手 堪称最为根红苗正的路线，未入门的同学如能将concept啃下来可以说大有裨益的， 但对于绝大多数同学而言 由于没有oracle实践动手能力， concept的大段原理概念将学得异常枯燥乏味， 和学 财会、法律背书无异， 往往越读越觉得空虚，越读越觉得没有实际运用价值。

基于备份恢复手册为里程起点的学习有一定的实践优势， 因为简单的备份恢复过程是很容易理解和重复实践的， 同学们可以从实践中获得信心。但由于缺少基础原理知识，很难深入理解

如我从前所说，学习一些Oracle的知识所花费的时间是有限的，而重复学习才是浪费时间的。但避免重复学习又与Oracle技术的深邃似乎是矛盾的，例如Oracle中一个Buffer Pool管理的知识领域，可以有上百个知识点，实际我们在OCP乃至OCM的培训中仅仅谈及十多个知识点而已，这样的限制主要是受限于课时和实际学习收益。

举一个例子来说 花费2个课时 掌握60%的知识点，并因此而能解决 80%的问题 ， 与 花费10个课时掌握100%的知识点并解决95%的问题，大多数人会选择前者， 因为前者是 适宜大众和经济实惠的。但问题大多数培训和教材仅仅告知 学习者有 这60%的知识点需要掌握，而并不告知大家这仅仅是60%的知识点，仍有40%的问题存在。

所以在Maclean看来 掌握基础是必要的， 此外也有必要让自己知晓尚未覆盖的那些内容。 这样当我们遇到一些需要复杂原理解释的问题时，我们会明确了解到自己的思考局限，如果问题真的超出了我们认知的范围，则知道如何进一步去探索这个问题。另一个附加的好处是，如果我们再次针对这个领域深入学习，则知道应当从哪里开头。

 第三章  Oracle数据库体系架构漫谈

如果说宇宙的终极意义是42，那么对于Oracle数据库而言其终极意义可能是云端中的盛水的玻璃容器。

要使一个初学者充分了解Oracle数据库的体系架构是困难的，因为这里面充满了 各种术语、机制、数据结构和算法； 实际上任何一个发展超过10年的平台软件都会发展出一种对初学者来说诡异难解的”脾性”来。 初学者学习这些软件技术若浅尝辄止难免不倒胃口，但你不妨想一想，人类的那些美食如牡蛎、茶叶、黑啤酒，难道你尝一口就非常喜欢吗？ 法国人吃蜗牛，瑞典人喝接骨木液，难道一开始你就能接受吗？ 而Unix、C语言、Oracle数据库正是与这些东西相似的东西，你尝着尝着便上瘾了，欲罢不能。 这也是为什么Oracle圈子总是新人偏少，都是我们这帮老家伙的原因。

Oracle这30多岁的中年老男人生于Unix之中，长于C语言之手，难免沾染了Unix和C的坏秉性；如果对这老男人做个全身透视，无非看到一堆C语言头文件中定义的struct结构和函数算法，对我们这些惯用Windows的小年轻而言未免口味过重。

Unix和C比之Oracle虚长几岁，做起事来有若干原则，这里一一披露：

• 小即是美。
• 让程序只做好一件事。
• 尽可能早地建立原型。
• 可移植性比效率更重要。
• 数据应该保存为文本文件。
• 尽可能地榨取软件的全部价值。
• 使用shell脚本来提高效率和可移植性。
• 避免使用可定制性低下的用户界面。
• 所有程序都是数据的过滤器

Oracle在Unix和C的基础上又订了若干准则，这样就建立起Oracle的世界:

• 世界由 一组后台进程和一堆共享内存组成，世界的别名叫instance，中文名实例

• 有好几个后台进程 ，他们有自己的名字，有一个叫SMON，还有一个叫PMON，他们是这个世界最早的工人，今后的世界里还有他们。 每个后台进程完成一项或者多项维护工作： 例如SMON ，它的工作很低贱，包括清理临时空间、回滚事务、维护回滚段等等，有时DBA叫它”保洁员”，但世界正常运行不能少了它。 一般后台进程只做自己的工作，不在其位则不谋其政。

• 有一种叫前台进程或者服务进程的家伙会登陆到世界，他们进入世界后折腾各种查询和更改。有的达到临时性目的后就退出了，被称作”短连接”； 有的来了就不走，工作休息都在世界里的，被称作”长连接”。 Oracle比较偏爱 “长连接”，因为在Oracle里连接是昂贵的。长短连接不是Oracle说了算，是应用程序设计和部署决定的。

• 前台进程/服务进程一般是自助式的服务的，例如要从磁盘上读一张表，那么除非申请了并行，否则就是它自行完成。例如前台进程自己生成了临时的数据段且它要回退自身的操作(例如create table做了一半被CTRL+C cancel掉)，那么它自己去清理残局，除非它意外死亡了，否则别人不会代劳。
• 世界中有三件事无法避免：　死亡　，性能损耗 和 实例重启； 但死亡并不可怕，如果个别进程的死亡能换来整个系统不挂起，或者数据不讹误(corruption)，那么死亡完全值得。
• 死亡在世界里是常事，死亡的原因大概有下面几种：
  • 当进程使用到非法的地址，或者收到意外的信号(signal)； 这种情况一般会出现ORA-7445的事件或者说错误号
  • 当进程发现如果它进一步工作，可能导致数据逻辑讹误时。一般会出现ORA-600的事件或者说错误号
  • 前台进程的死亡率很高，特别是在世界的初始版本中 例如 10.1 ，10.2.0.1~10.2.0.3和11.2.0.1。每一个新世界都引入几百个新鲜事务，其中有多达几十个是默认打开的，它们是全新的且仅仅经过有限的压力测试，恰好使用到它们的前台进程可能进入程序的exception意外中， 以报出ORA-600错误并生成trace后自行终结terminate结束