分类： Oracle
2012-11-07 10:36:43
什么是Oracle数据库呢？这是一个我经常问DBA的问题，今天我要来回答这个问题。说到数据库，它是数据的集合，这一点就没必要在这里详细讨论了。大多数介绍数据库原理和数据库基础的教材要比我解释的专业得多。这里只讨论“什么是Oracle数据库”。Oracle数据库是甲骨文公司开发的一种关系型数据库管理系统，也就是RDBMS。在这里我必须插几句，说说我对拉里·埃里森的崇拜之情。我曾经崇拜过乔布斯，不过那是我对80年代发明苹果电脑的乔布斯的崇拜，也许iPhone是乔布斯人生辉煌的顶点，但是我只崇拜发明了那台绿色字符的小电脑的乔布斯；我也曾崇拜比尔·盖茨，不过那是我对DOS 3.0的崇拜。但自从听说了拉里用锤子为办公室开辟网线通道的故事（不管这个故事是不是真实的），我就开始崇拜他了。用圣迹来命名一家公司和一个产品，这不是我们这种凡夫俗子能够做到的。Oracle也确实像圣迹一样，深深地影响着全世界。
Oracle RDBMS是一款十分优秀的关系型数据库产品，Oracle从头到尾都是一个RDBMS，是针对OLTP系统进行设计的，这一点从它底层的块结构就可以看出。Oracle在大并发量和海量数据关系型检索方面具有十分优越的性能，但是它并不擅长OLAP，因为它不支持列压缩存储（当然，从exadata开始，Oracle也能够支持混合列压缩，这是一种行存储和列压缩的混合模式，目前只在exadata数据库一体机上实现）。与其他关系型数据库相比，Oracle在某些方面更为优秀，但也有其不足的地方，因此它绝对不是万能的。优势和劣势都是与生俱来的，这是由Oracle数据库的基本架构和数据存储的基础结构所决定的，优化只能解决局部性的问题，有限度地提升其性能，但是绝对无法完全掩盖结构性问题带来的负面影响。Oracle的优势在于大并发量下的高吞吐能力，因此很适合大型企业级应用。但是如果我们在一个并发量和数据量都不是很大的系统中，对Oracle和MS SQL Server进行比较，就不难发现Oracle并没有多大的优势，甚至在某些方面还不如后者。
再往更为本质的方面去探讨，Oracle是一个RDBMS系统，也是一款应用软件。Oracle数据库除了将数据存储于文件中外，还通过一个被称为实例的后台机制向外提供服务，这两部分我们将在随后的两节中详细介绍，这里不做过多的描述。我们在这里仅仅讨论作为应用程序的Oracle RDBMS系统，它必须依赖于某个操作系统或硬件体系。和我们自己编写的程序一样，Oracle必须适应于某个操作系统，并充分利用操作系统提供的资源，反过来，操作系统也必须能够将资源提供给Oracle数据库使用。在一个仅仅运行Oracle RDBMS的系统上，操作系统应该被调整为能够将绝大多数的资源都提供给Oracle数据库。这样，Oracle的进程就能够最大可能地得到足够的系统资源。
讨论这个似乎又有点跑题了，其实不然，只有充分了解Oracle的本质，我们才不会神化Oracle。Oracle的本质就是一款软件、一个程序，那么它就具备程序的一切特征，包括可能出现的bug。
但是Oracle不是一个简单的程序，而是十分复杂的体系。首先，Oracle需要将数据存储在数据文件中，为了能够支持大量的并发用户访问数据库，并且提高数据库的访问性能，Oracle需要引入共享内存，从而实现资源的共享。比如，针对SQL引擎，每个SQL最终将会被解析为一系列的执行步骤，这就是我们常说的执行计划。如果同一个SQL执行多次，每次都要重新生成执行计划，那么效率就比较低下了，Oracle引入了共享池来实现这方面的共享。同样，如果一个数据块每次读取都要访问文件，那么效率就不高了，于是Oracle引入了DB Cache来缓存这些数据。同一个数据块可能被多个用户修改，如果每次修改就要直接存盘，那么效率也会降低，于是Oracle设计了DBWR进程，来专门负责将数据块写入文件。这似乎很复杂，不过这一切对于架构师来说很好理解。架构设计的目的就是有效地将功能划分成不同的组成部分，然后让这些部分能够很好地协同工作，从而达到最好的效果，因此架构师很容易做出类似的设计。
实际上，作为一个应用程序的Oracle，它的实现原理是十分朴实的，并不像我们想象的那么神秘。前几天我碰到一个案例，有个客户的Oracle 9.2.0.6数据库突然出现了故障，sqlplus通过sysdba能够登录，并且能够访问一些系统视图，比如v$session，但如果使用普通用户登录就会被挂起。通过HANGANALYZE工具分析，没有发现任何异常。然而，在检查Oracle后台进程的时候，我们发现所有的Oracle后台进程和绝大多数前台进程都消失了。客户很是不解，为什么会这样呢？检查日志，没有发现任何异常。于是我们使用shutdown abort关闭了实例，并且进行了重启。我们都觉得没有日志，很难分析，也就没有深入研究。
第二天，客户又找到了我，说数据库又出现了昨天的情况，这回所有的Oracle进程，包括前台进程、后台进程，统统没有了，而且没有任何的日志产生。我考虑了半天，突然有所感悟，Oracle的实例实际上也是一款应用软件，由多个进程组成，任何一个进程发现系统存在异常，都会第一时间记录日志，如果问题十分严重，就会关闭实例。我们可以使用sysdba账号登录系统，并且能够在HANGANALYZE工具中看到会话的信息，说明Oracle的共享内存还存在，只是所有的进程都没有了。这种情况只有一种可能，就是所有的Oracle后台进程都是在同一个时间点被终止的，而且不是程序自己退出的（因为程序自己退出，应该有机会完成自己的退出业务逻辑，比如写日志记录故障），而是被外力强行终止的。
从上面的分析，很自然就能联想到Oracle的后台进程很可能是被人为杀掉了。于是我做了一个实验，发现如果杀掉所有的后台进程，Oracle的共享内存还是存在的，并且能够通过sysdba账号访问，普通用户登录由于缺乏后台进程的支持，会被挂起。这个现象和客户目前碰到的问题十分相似。
发现这个问题的真相只有一个渠道，就是从应用程序本质上去考虑，这样才能得出所有的后台进程都是在同一时间被终止的结论，并找出其原因。只有外部力量的介入，才有可能出现所有后台进程全部终止，而共享内存还保持正常的现象，这绝对不是某个bug能产生的结果。排除了bug的影响，我们才能把主要精力集中在正确的方向上。
到这里，对于这个案例的分析就接近尾声了，本节并没有很深入地介绍“什么是Oracle”，而是更加直接地介绍了Oracle的本质。Oracle在本质上就是一组应用软件，它也具备所有应用软件所具备的特征。了解这一点，是我们今后解决任何问题的基础。任何看似妖异的现象，都离不开Oracle作为应用软件的本质，都无法违背应用软件所遵循的规律。
作为应用程序的Oracle，必须依赖于其运行的系统环境，Oracle数据库的处理能力和性能也依赖于主机硬件、存储、网络和操作系统等因素，因此作为DBA不能仅仅就Oracle而论Oracle，还必须熟悉Oracle运行所依赖的环境。作为应用程序的Oracle，会和操作系统中的其他进程竞争有限的系统资源，因此，在数据库服务器上做一些比较大的操作时，一定要谨慎，因为这些操作可能会使Oracle数据库出现问题。
Oracle不仅是特殊的应用程序，更是庞大的数据库管理系统，它包含了一个RDBMS管理系统和其他一系列应用程序。Oracle的核心——RDBMS管理系统包含在$ORACLE_HOME/bin/oracle映像、$ORACLE_HOME/lib/libclntsh.so等中，而sqlplus、exp等则是一些Oracle数据库的工具。tnslsnr是Oracle的网络连接部件，用于连接客户端到RDBMS。这些应用程序都被安装在ORACLE HOME目录下。
通过上述应用程序，RDBMS管理系统及其工具，用户就可以创建、管理数据库。另外，用户还可以通过sqlplus工具，使用create database命令去创建一个数据库，也可以使用startup和shutdown命令去启动和关闭数据库。
数据库是独立的，从物理结构上看，它是由一系列文件组成的，包括参数文件、口令文件、控制文件、数据文件、日志文件等。一套完整的数据库，只要其所有的文件都是完整的，那么即使数据库的RDBMS管理系统遭到破坏，只要重新安装和数据库版本一致的RDBMS管理系统，该数据库就可以重新启用。其实所谓重新启用，本质上就是可以在某个实例中打开这个数据库，供客户使用。
另外需要注意的是，Oracle数据库是一个RDBMS管理系统，其本质是关系型数据库。关系型数据库是十分适合OLTP应用的，因为它存储的是一系列的关系，各种关系以表的形式被存储起来。比如，春节前铁路网上售票系统崩溃，有人分析这是由于铁路系统固步自封，没有使用国外某大厂商的产品，而选用了通用RDBMS数据库产品所导致的性能问题，如果选用了某国际知名厂商的网状数据库，就不会有问题了。这个说法看似有理，实际上，如果足够了解RDBMS，就知道其不值一驳了，因为铁路售票系统是十分典型的OLTP应用。
另外，由于Oracle是行存储的RDBMS数据库，这一特点也使其十分适合OLTP应用。从Oracle数据库的内部数据结构可以看出，Oracle在行存储数据方面下足了功夫，甚至连行锁都是设置在行头中的。在行锁的性能方面，Oracle的表现极为优秀，这一点毋庸置疑。不过这种设计，可能不适合一些经常以列为访问对象的OLAP系统，列压缩技术才是实现这类应用的最佳解决方案。因此如果有人宣称，Oracle数据库在OLAP分析方面的性能高于SYBASE IQ，那一定不可信。
