Maclean写的Oracle入门书

Maclean写的Oracle入门书

 

maclean liu3

 

 试读目录:

第一章 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数据库的想法。

 

150px-Edgar_F_Codd (1)

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万美元,甲骨文传奇从此为世人熟识。

 

larry bob miner

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

 

 

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

 

 800px-Oracle_Fountain_(6532480)

 美国加州红木城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 3 user guide

 

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

 

下附 Oracle Database 发行历史年表:

 

版本号 发行年份 距离前一个版本发行的时间 发行公司 内核编程语言
Oracle 1 1978 没有实际发行 Software Development Laboratories (SDL) 汇编
Oracle 2 1979 1 Relational Software, Inc. 汇编
Oracle 3 1983 4 Oracle Corporation C
Oracle 4 1984 1 Oracle Corporation C
Oracle 5 1985 1 Oracle Corporation C
Oracle 6 1988 3 Oracle Corporation C
Oracle 7 1992 4 Oracle Corporation C
Oracle 8 1997 5 Oracle Corporation C
Oracle 8i 1999 2 Oracle Corporation C
Oracle 9iR1 2001 2 Oracle Corporation C
Oracle 9iR2 2002 1 Oracle Corporation C
Oracle 10gR1 2004(存疑,wiki为2003,oracle lifetime为2004) 1 Oracle Corporation C
Oracle 10GR2 2005 2 Oracle Corporation C
Oracle 11gR1 2007 2 Oracle Corporation C
Oracle 11gR2 2009 2 Oracle Corporation C
Oracle 12cR1 2013 4 Oracle Corporation C
Oracle 12cR2 未知 未知 Oracle Corporation C

 

如果你读过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是很少见的。

 

 

flex cluster  ORA

 


 

 

 

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结束

 

 

 

关注dbDao.com的新浪微博

扫码关注dbDao.com 微信公众号:

Comments

  1. 刘大,这是要出书啦?

  2. loryliu says:

    这只是试读章节呀,木有全部的么。好想看第二章 自学Oracle数据库的自由之翼的全部哟。。。。。

  3. zengmuansha says:

    “基础始终不扎实” 多介绍基础 让我们读者能扎实扎实下

  4. 求师傅领进门

  5. 刘大是应该写书了,那么多案例和原理,整理出来就是本有深度的精彩O BOOK了

Speak Your Mind

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569