泛型编程与C++标准库

Transcription

1 第 章. 什么是 Oracle 数据库 3 理解 Oracle 数据库和实例 数据库和实例是 Oracle 最为基础的两个概念, 只有很好地理解了什么是数据库, 什么是数据库实例, 才能更好地理解 Oracle 的其他概念 本章将会通过一些知识点来了解什么是数据库和数据库实例 通过本章的学习, 我们也会更加适应本书的风格. 什么是 Oracle 数据库 什么是 Oracle 数据库呢? 这是一个我经常问 DBA 的问题, 今天我要来回答这个问题 说到数据库, 它是数据的集合, 这一点就没必要在这里详细讨论了 大多数介绍数据库原理和数据库基础的教材要比我解释的专业得多 这里只讨论 什么是 Oracle 数据库 Oracle 数据库是甲骨文公司开发的一种关系型数据库管理系统, 也就是 RDBMS 在这里我必须插几句, 说说我对拉里 埃里森的崇拜之情 我曾经崇拜过乔布斯, 不过那是我对 80 年代发明苹果电脑的乔布斯的崇拜, 也许 iphone 是乔布斯人生辉煌的顶点, 但是我只崇拜发明了那台绿色字符的小电脑的乔布斯 ; 我也曾崇拜比尔 盖茨, 不过那是我对 DOS 3.0 的崇拜 但自从听说了拉里用锤子为办公室开辟网线通道的故事 ( 不管这个故事是不是真实的 ), 我就开始崇拜他了 用圣迹来命名一家公司和一个产品, 这不是我们这种凡夫俗子能够做到的 Oracle 也确实像圣迹一样, 深深地影响着

2 4 第 章理解 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 的系统上, 操作系统应该被调整为能

3 . 什么是 Oracle 数据库 5 够将绝大多数的资源都提供给 Oracle 数据库 这样,Oracle 的进程就能够最大可能地得到足够的系统资源 讨论这个似乎又有点跑题了, 其实不然, 只有充分了解 Oracle 的本质, 我们才不会神化 Oracle Oracle 的本质就是一款软件 一个程序, 那么它就具备程序的一切特征, 包括可能出现的 bug 但是 Oracle 不是一个简单的程序, 而是十分复杂的体系 首先,Oracle 需要将数据存储在数据文件中, 为了能够支持大量的并发用户访问数据库, 并且提高数据库的访问性能,Oracle 需要引入共享内存, 从而实现资源的共享 比如, 针对 SQL 引擎, 每个 SQL 最终将会被解析为一系列的执行步骤, 这就是我们常说的执行计划 如果同一个 SQL 执行多次, 每次都要重新生成执行计划, 那么效率就比较低下了,Oracle 引入了共享池来实现这方面的共享 同样, 如果一个数据块每次读取都要访问文件, 那么效率就不高了, 于是 Oracle 引入了 DB Cache 来缓存这些数据 同一个数据块可能被多个用户修改, 如果每次修改就要直接存盘, 那么效率也会降低, 于是 Oracle 设计了 DBWR 进程, 来专门负责将数据块写入文件 这似乎很复杂, 不过这一切对于架构师来说很好理解 架构设计的目的就是有效地将功能划分成不同的组成部分, 然后让这些部分能够很好地协同工作, 从而达到最好的效果, 因此架构师很容易做出类似的设计 实际上, 作为一个应用程序的 Oracle, 它的实现原理是十分朴实的, 并不像我们想象的那么神秘 前几天我碰到一个案例, 有个客户的 Oracle 数据库突然出现了故障,sqlplus 通过 sysdba 能够登录, 并且能够访问一些系统视图, 比如 v$session, 但如果使用普通用户登录就会被

4 6 第 章理解 Oracle 数据库和实例 挂起 通过 HANGANALYZE 工具分析, 没有发现任何异常 然而, 在检查 Oracle 后台进程的时 候, 我们发现所有的 Oracle 后台进程和绝大多数前台进程都消失了 客户很是不解, 为什么会这 样呢? 检查日志, 没有发现任何异常 于是我们使用 shutdown abort 关闭了实例, 并且进行了重 启 我们都觉得没有日志, 很难分析, 也就没有深入研究 第二天, 客户又找到了我, 说数据库又出现了昨天的情况, 这回所有的 Oracle 进程, 包括前 台进程 后台进程, 统统没有了, 而且没有任何的日志产生 我考虑了半天, 突然有所感悟, Oracle 的实例实际上也是一款应用软件, 由多个进程组成, 任何一个进程发现系统存在异常, 都 会第一时间记录日志, 如果问题十分严重, 就会关闭实例 我们可以使用 sysdba 账号登录系统, 并且能够在 HANGANALYZE 工具中看到会话的信息, 说明 Oracle 的共享内存还存在, 只是所有 的进程都没有了 这种情况只有一种可能, 就是所有的 Oracle 后台进程都是在同一个时间点被终 止的, 而且不是程序自己退出的 ( 因为程序自己退出, 应该有机会完成自己的退出业务逻辑, 比 如写日志记录故障 ), 而是被外力强行终止的 从上面的分析, 很自然就能联想到 Oracle 的后台进程很可能是被人为杀掉了 于是我做了一 个实验, 发现如果杀掉所有的后台进程,Oracle 的共享内存还是存在的, 并且能够通过 sysdba 账号访问, 普通用户登录由于缺乏后台进程的支持, 会被挂起 这个现象和客户目前碰到的问题 十分相似 发现这个问题的真相只有一个渠道, 就是从应用程序本质上去考虑, 这样才能得出所有的后 台进程都是在同一时间被终止的结论, 并找出其原因 只有外部力量的介入, 才有可能出现所有

5 . 什么是 Oracle 数据库 7 后台进程全部终止, 而共享内存还保持正常的现象, 这绝对不是某个 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 和

6 8 第 章理解 Oracle 数据库和实例 shutdown 命令去启动和关闭数据库 数据库是独立的, 从物理结构上看, 它是由一系列文件组成的, 包括参数文件 口令文件 控制文件 数据文件 日志文件等 一套完整的数据库, 只要其所有的文件都是完整的, 那么即 使数据库的 RDBMS 管理系统遭到破坏, 只要重新安装和数据库版本一致的 RDBMS 管理系统, 该数据库就可以重新启用 其实所谓重新启用, 本质上就是可以在某个实例中打开这个数据库, 供客户使用 另外需要注意的是,Oracle 数据库是一个 RDBMS 管理系统, 其本质是关系型数据库 关系 型数据库是十分适合 OLTP 应用的, 因为它存储的是一系列的关系, 各种关系以表的形式被存储 起来 比如, 春节前铁路网上售票系统崩溃, 有人分析这是由于铁路系统固步自封, 没有使用国 外某大厂商的产品, 而选用了通用 RDBMS 数据库产品所导致的性能问题, 如果选用了某国际知 名厂商的网状数据库, 就不会有问题了 这个说法看似有理, 实际上, 如果足够了解 RDBMS, 就知道其不值一驳了, 因为铁路售票系统是十分典型的 OLTP 应用 另外, 由于 Oracle 是行存储的 RDBMS 数据库, 这一特点也使其十分适合 OLTP 应用 从 Oracle 数据库的内部数据结构可以看出,Oracle 在行存储数据方面下足了功夫, 甚至连行锁都是设置在 行头中的 在行锁的性能方面,Oracle 的表现极为优秀, 这一点毋庸置疑 不过这种设计, 可能 不适合一些经常以列为访问对象的 OLAP 系统, 列压缩技术才是实现这类应用的最佳解决方案 因此如果有人宣称,Oracle 数据库在 OLAP 分析方面的性能高于 SYBASE IQ, 那一定不可信

7 .2 Oracle 数据库的物理结构 9.2 Oracle 数据库的物理结构 Oracle 数据库的物理结构从本质上来说就是一系列的文件 Oracle 数据库分为几个部分, 第一部分是 Oracle RDBMS 系统的安装目录, 也就是我们常说的 ORACLE_HOME ORACLE_HOME 包含了 Oracle 运行包的几乎所有的文件, 当对 ORACLE_HOME 执行 tar 命令, 并将其复制到一台具有相同操作系统的机器上后, 解开包配置一些环境变量就可以使用了, 一般来说都不需要做什么特殊的处理 不过由于我们安装操作系统时可能不会完全一致 ( 操作系统的小版本 补丁包 安装的可选包等 ), 因此针对通过 tar 命令复制过来的介质, 应在使用前做一次重新链接 Oracle 在 $ORACLE_HOME/bin 目录下, 提供了用于重新链接的工具, 只要进入该目录, 执行 : $relink all 就可以完成 Oracle 介质的重新链接 当然为了便于今后管理, 如果要复制一套 Oracle RDBMS 软件介质, 不能仅仅复制 ORACLE_HOME, 还需要创建 bdump udump 等目录, 为 Oracle 的前台和后台进程输出日志使用 除此之外, 还有一个十分重要的 Oracle 组件需要进行复制, 这就是 Inventory Inventory 是什么呢? 很多做了多年维护工作的 DBA, 可能仍然不太了解它 下面老白就和大家一起讨论 Inventory.2. Inventory 什么是 Inventory 呢?Inventory 是 Oracle 安装工具 OUI 用来管理 Oracle 安装目录的 Inventory 里注册了某个 ORACLE_HOME 下安装的数据库的组件及其版本 Oracle 数据库软件的升级 增

8 0 第 章理解 Oracle 数据库和实例 删组件, 都需要使用 Inventory 在一台服务器上,Oracle OUI 会创建一个全局的 Inventory, 全局 Inventory 的目录在 orainst.loc 文件中指定 根据操作系统的不同,oraInst.loc 所在的目录也不一 样 在 AIX 或者 LINUX 等系统中,oraInst.loc 存放在 /etc 目录下, 在有些操作系统中, 这个文件 存放在 /var/opt/oracle 目录下 orainst.loc 文件中包含下面的配置项目 : Inventory_loc=<oraInventory 所在目录 > inst_group=<oui 安装 ORACLE 的操作系统组 > 比如说, 老白的一台测试机上的 orainst.loc 内容是这样的 : Inventory_loc=/opt/oracle/oraInventory inst_group=oinstall 这里面有两个信息, 第一个是 Inventory 所在的目录位置, 第二个是安装 Oracle 的组的名称 这个 inst_group 参数十分重要, 它会在 link Oracle 映像的时候被使用, 如果这个参数设置错了, 那么 link 出来的 Oracle 映像就无法被正常使用了 在全局 Inventory 中定义了所有 Oracle HOME 的情况, 这个文件就是 ContentsXML 目录下的 Inventory.xml: <?xml version=".0" standalone="yes"?> <!-- Copyright (c) 200 Oracle Corporation. All rights Reserved --> <!-- Do not modify the contents of this file by hand. --> <Inventory> <VERSION_INFO> <SAVED_WITH> </SAVED_WITH> <MINIMUM_VER> </MINIMUM_VER> </VERSION_INFO> <HOME_LIST> <HOME NAME="Ora0gHome" LOC="/opt/oracle/product/0g" TYPE="O" IDX=""/> <HOME NAME="ora9i" LOC="/home/ora9i/product/9204" TYPE="O" IDX="2"/> </HOME_LIST> </Inventory> 比如上面的例子中, 老白的系统上有两个 Oracle Home, 一个是 9i 的一个是 0g 的

9 .2 Oracle 数据库的物理结构 在 ORACLE_HOME 下面也有一个 Inventory 目录, 这个目录就是我们平时说的 Local Inventory 这个 Inventory 是本地的, 每个 ORACLE_HOME 所独有的 它记录了本 ORACLE_HOME 中 OUI 安装的组件的信息 了解了 Inventory 的一些基础知识, 下面我们就要聊聊了解这些知识有什么好处了 假设这 么一个场景, 我们去给一个客户的数据库打补丁, 到了客户现场, 首先使用 opatch lsinventory 来 查看一下当前系统的情况 正常情况显示的数据是这样的 : Invoking OPatch Oracle Interim Patch Installer version Copyright (c) 2007, Oracle Corporation. All rights reserved. Oracle Home : /opt/oracle/product/0g Central Inventory : /opt/oracle/orainventory from : /etc/orainst.loc OPatch version : OUI version : OUI location : /opt/oracle/product/0g/oui Log file location : /opt/oracle/product/0g/cfgtoollogs/opatch/opatch _ -4-25AM.log LsInventory Output file location : /opt/oracle/product/0g/cfgtoollogs/opatch/lsinv/ lsinventory _-4-25am.txt Installed Top-level Products (4): Oracle Database 0g Oracle Database 0g Products Oracle Database 0g Release 2 Patch Set Oracle Database Vault There are 4 products installed in this Oracle Home. There are no Interim patches installed in this Oracle Home. 而不幸的是, 我们看到了这样的信息 : [oracle@ OPatch]$./opatch lsinventory Invoking OPatch Oracle Interim Patch Installer version Copyright (c) 2007, Oracle Corporation. All rights reserved. Oracle Home : /opt/oracle/product/0g Central Inventory : n/a from : OPatch version : OUI version :

10 2 第 章理解 Oracle 数据库和实例 OUI location : /opt/oracle/product/0g/oui Log file location : n/a OPatch cannot find a valid orainst.loc file to locate Central Inventory. OPatch failed with error code 04 和客户沟通了以后我们发现, 这套系统不是安装的, 而是开发商直接 tar 过来的 碰到这种 情况该怎么办呢? 在上面我们讲过, 每个 ORACLE HOME 下面都有本地 Inventory, 在本地的 Inventory 中也已经注册了所有的 Oracle 组件的信息, 那么我们就可以通过本地的 Inventory 来创 建全局的 Inventory 重建全局 Inventory 的方法很简单, 第一步我们首先要编辑一个 orainst.loc 文件, 使之指向我 们要创建全局 Inventory 的目录 Inventory_loc=/opt/oracle/oraInventory inst_group=oinstall 然后将目录转向 ORACLE_HOME 下的 oui/bin 目录 : $ cd $ORACLE_HOME/oui/bin 在该目录下执行下面的脚本就可以完成全局 Inventory 的创建 : %./runinstaller -silent -ignoresysprereqs -attachhome ORACLE_HOME="<Oracle_Home_Location>" ORACLE_HOME_NAME="<Name_Of _Oracle_Home>" 下面是老白重新创建自己测试机上的 Inventory 的命令 : oracle@ bin]$./runinstaller -silent -ignoresysprereqs -attachhome ORACLE_HOME="/opt/oracle/product/0g" ORACLE_HOME_NAME="ora0g" Starting Oracle Universal Installer... No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed. >>> Ignoring required pre-requisite failures. Continuing... The Inventory pointer is located at /etc/orainst.loc The Inventory is located at /opt/oracle/orainventory 'AttachHome' was successful.

11 .2 Oracle 数据库的物理结构 3 这个命令支持 Oracle 0.2, 对于 Oracle 9i 和 0. 的版本, 如果丢失了全局 Inventory, 那么 就需要从一个类似的平台克隆一个 Inventory 过来 克隆的具体方法由于篇幅有限, 在这里就不 做过多的描述了, 有兴趣的朋友可以参考 Metalink 上的下面几个文档 : Note "Cloning An Existing Oracle9i Release 2 (9.2.0.x) RDBMS Installation Using OUI" Note "Cloning An Existing Oracle0g Release (0..0.x) RDBMS Installation Using OUI" Note "Cloning An Existing Oracle0g Release 2 (0.2.0.x) RDBMS Installation Using OUI" Note "Cloning An Existing Oracleg Release (..0.x) RDBMS Installation Using OUI" 针对.2 以后的数据库, 这个命令有所区别 : %./runinstaller -silent -ignoresysprereqs -attachhome ORACLE_HOME="<Oracle_Home_Location>" 我们不需要指定 Oracle Home 的名字了 刚才的例子是单节点的, 在 RAC 环境下要稍微复杂一些 在本小节的最后一部分, 我们来 简单探讨一下重建 RAC 环境下的全局 Inventory 的方法 0g RAC 引入了 CRS, 因此我们在重建 Inventory 的时候, 至少需要修复两个 ORACLE_HOME, 一个是 RDBMS 的, 一个是 CRS 的 命令如下 :./runinstaller -silent -ignoresysprereqs -attachhome ORACLE_HOME="<0g Ora_Crs_Home Path>" ORACLE_HOME_NAME="<Name of oraclecrshome>" LOCAL_NODE='node' CLUSTER_NODES=node,node2 CRS=true./runInstaller -silent -ignoresysprereqs -attachhome ORACLE_HOME="<0g Oracle_Home Path>" ORACLE_HOME_NAME="<Name of oraclehome>" LOCAL_NODE='node' CLUSTER_NODES=node,node2.2.2 口令文件 口令文件一般来说放在 $ORACLE_HOME/dbs 目录下, 在 Windows 平台下面, 这个文件是在

12 4 第 章理解 Oracle 数据库和实例 $ORACLE_HOME/database 目录下 Oracle 数据库的口令文件存放有超级用户的口令及其他特权用户的用户名 / 口令 在创建一 个数据库的时侯, 在 $ORACLE_HOME/dbs 目录下会自动创建一个与之对应的口令文件 此文件 是进行初始数据库管理工作的基础 在此之后, 管理员也可以根据需要, 使用工具 ORAPWD 手 工创建口令文件 默认安装下, 最初的口令文件中只包含 sys 账号的信息, 我们来看看老白的测试库的信息 : [oracle@ dbs]$ strings orapworcl ]\[Z ORACLE Remote Password file INTERNAL 87C5F4BF47942D0E 4CCF4A082AD3F32 这时候如果想把 system 账号设置为 sysdba 权限, 我们来看看口令文件有什么变化 : [oracle@ dbs]$ sqlplus '/as sysdba' SQL*Plus: Release Production on Fri May 6 2:8:25 20 Copyright (c) 982, 2007, Oracle. All Rights Reserved. Connected to: Oracle Database 0g Enterprise Edition Release Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Real Application Testing options SQL> grant sysdba to system; Grant succeeded. SQL> exit Disconnected from Oracle Database 0g Enterprise Edition Release Production With the Partitioning, Oracle Label Security, OLAP, Data Mining and Real Application Testing options [oracle@ dbs]$ strings orapworcl ]\[Z ORACLE Remote Password file INTERNAL 87C5F4BF47942D0E 4CCF4A082AD3F32 SYSTEM 697FFAEA6387CE 这个文件中包含了 system 这个账号 同样我们也可以给其他账号分配 sysdba 权限 比如我

13 .2 Oracle 数据库的物理结构 5 们授予 scott 账号 sysdba 权限, 授权后, 在口令文件中就保留了 scott 账号的密码信息 这样 scott 账号就可以在数据库没有启动时进行鉴权了 我们可以使用 orapwd 工具重建口令文件, 重建的方法十分简单, 我们就不在本节中多说了.2.3 参数文件 参数文件一般来说放在 $ORACLE_HOME/dbs 目录下, 在 Windows 平台下面, 这个文件是在 $ORACLE_HOME/database 目录下 早期的 Oracle 数据库的参数文件称为 PFILE, 从 Oracle 9i 开始, 引入了服务器参数文件 spfile 和 pfile 不同,spfile 采用了一种二进制的方式, 同时保留 了对原有的文本参数文件的支持 在 $ORACLE_HOME/dbs 下存放 spfile 文件 ( 如果是 NT, 则是 在 $ORACLE_HOME/database 下 ) Oracle 启动的时候会按照如下顺序查找参数文件 : $ORACLE_HOME/dbs/SPFILE.ORA $ORACLE_HOME/dbs/spfile.ora $ORACLE_HOME/dbs/init.ora 实际上,spfile 也不完全是二进制的, 只是在原有的 pfile 基础上加入了一些二进制的管理和 校验信息, 直接编辑 spfile, 可以取出其中的参数配置的所有信息 在数据库启动的时候, 数据库会根据搜索路径自动查找参数文件 如果找不到参数文件, 数 据库启动会失败 如果需要, 可以使用下面的方法指定一个启动参数文件 : 修改 : sqlplus /nolog sql>connect sys/... as sysdba; sql>startup pfile=$oracle_home/dbs/init.ora; 采用服务器参数文件后, 参数文件的修改就相对容易了一些 可以通过 Oracle 提供的指令

14 6 第 章理解 Oracle 数据库和实例 ALTER SYSTEM SET <PARAMETER>=<VALUE> SCOPE='SPFILE'; 对于习惯于修改文件的人, 可以使用下面方法实现类似 8i 的参数修改 首先通过下列语句 创建一个文本的参数文件 sql>create pfile='...' from spfile; 生成参数文件后可以手工修改 但是每次修改后要使用下面语句生成新的 spfile SQL>CREATE SPFILE='...' FROM PFILE='...';.2.4 控制文件 控制文件是 Oracle 数据库中十分重要的文件,Oracle 数据库启动时, 首先会去读参数文件, 读了参数文件, 实例所需要的共享内存区和后台进程就可以启动了, 这就是数据库实例启动的 nomount 阶段 完成这个步骤以后, 就需要通过参数文件中的 control_files 参数, 找到数据库的 控制文件, 然后打开控制文件, 对控制文件进行校验 这就是 Oracle 数据库实例启动过程中的 Mount 阶段 控制文件中包含了 Oracle 数据库中十分重要的信息, 其中包括整个数据库的物理结构 所有 数据文件 REDO LOG 文件等的信息 当然控制文件中还包含了一些其他的重要信息, 比如归 档模式下的日志归档情况 rman 备份时的 catalog 信息等 要想了解控制文件中包含哪些内容, 可以通过下面的语句进行查询 : Select type,record_size,records_total,records_used from v$controlfile_record_section; TYPE RECORD_SIZE RECORDS_TOTAL RECORDS_USED DATABASE 92 CKPT PROGRESS REDO THREAD 04 REDO LOG

15 .2 Oracle 数据库的物理结构 7 DATAFILE FILENAME TABLESPACE TEMPORARY FILENAME RMAN CONFIGURATION LOG HISTORY OFFLINE RANGE ARCHIVED LOG BACKUP SET BACKUP PIECE BACKUP DATAFILE BACKUP REDOLOG DATAFILE COPY BACKUP CORRUPTION COPY CORRUPTION DELETED OBJECT PROXY COPY BACKUP SPFILE DATABASE INCARNATION 我们可以看到, 控制文件中包含了数据库信息 CKPT 进程信息 REDO 信息 数据文件 和表空间信息等重要的数据库信息, 也包含了日志切换的历史信息和 RMAN 备份的 CATALOG 信息.2.5 在线日志文件 在线日志文件即 REDO LOG 文件, 在线 这两个字是用于和归档日志区分的 在线日志 是数据库中十分重要的文件, 主要用于记录数据库的变更信息 Oracle 使用在线日志文件记录 数据库变更信息的目的是, 当数据库实例宕掉的时候, 可以通过在线日志文件中记录的信息进 行恢复 在线日志文件的存在, 解决了数据库实例突然宕掉或者服务器宕机后的系统恢复问题 有了 在线日志文件, 就不用害怕 Oracle 数据库突然宕掉后数据库实例无法自动修复了, 因为它的固有 机制可以确保数据库完整恢复

16 8 第 章理解 Oracle 数据库和实例.2.6 数据文件 数据文件是存储 Oracle 数据库中的数据的, 也是 Oracle 数据库中最为核心的文件 Oracle 数据库中的表 索引等都是记录在数据文件中的 其中系统表空间包含的数据文件里保存了数据 库的元数据 (metadata), 这部分数据是十分关键的, 如果 metadata 出现故障, 那么我们在访问 数据库的数据时就会发生问题 数据文件中还有一类特殊的文件, 即临时文件, 一般来说, 临时文件属于临时表空间 临时 文件是 Oracle 存放临时性数据的, 比如排序数据 临时表 一旦数据库重启, 临时文件将会丢失 因此, 我们不能把永久性的表和索引存放在临时文件中.2.7 归档日志文件 归档日志文件是用于长期保存的, 它是在线日志的离线拷贝版本, 当在线日志切换的时候, ARCH 进程就会将这个刚刚关闭的在线日志文件的内容复制到磁盘上, 长期保存 归档日志的主 要用途是用于数据库的恢复操作 进行数据库完全恢复或者不完全恢复的时候, 需要将备份的数 据文件恢复到硬盘上, 然后通过归档日志将其前滚到所需要的时间点 在设置了逻辑复制的环境中, 归档日志也有可能用来进行挖掘, 从而生成 LCR( 逻辑变化 记录 ), 因此在配置了 STREAMS GOLDENGATE 等逻辑复制的环境中, 归档日志需要在磁盘 上存储更长的时间, 以便于逻辑复制使用 在这种环境中, 保留 5 日以上的归档日志是十分必 要的, 如果你的存储空间足够大, 请给予归档日志更大的存储空间, 并且这些归档日志的删除 策略也要做适当的调整, 不能由备份软件自动删除, 而是要通过一个定时任务, 删除几天前的

17 .3 实例和多实例数据库 9 数据.3 实例和多实例数据库 如果有人问 多实例数据库和 RAC 是什么关系? 我想能够正确回答出来的人不会太多 要回答好这个问题, 首先需要知道什么是 Oracle 实例,Oracle 实例和 Oracle 数据库之间存在什么关系 大多数 DBA 都学习过实例的概念, 实例是访问 Oracle 数据库的通道, 包含共享内存和后台进程 一个 Oracle 实例一次只能打开一个 Oracle 数据库, 而一个 Oracle 数据库可以同时被多个实例打开 被多实例打开的 Oracle 数据库, 必须是一个 RAC 数据库 更进一步讲,RAC 应该是 Oracle RDBMS 的一个选件, 但其实 RAC 数据库的说法并不严谨, 不过我们大可不必过分纠结于此问题 本节将较为全面地介绍多实例数据库.3. 什么是数据库实例在实际的开发应用中, 关于 Oracle 数据库, 经常听见有人说建立一个数据库 建立一个实例 (Instance) 启动一个实例之类的话 其实问他们什么是数据库 什么是实例, 很可能他们会说 数据库就是实例, 实例就是数据库啊, 没有什么区别 我只能说虽然他们使用了很长时间的 Oracle 数据库, 也算积累了一定的经验, 不过基础的概念还是不太清楚 我们都知道, 数据库就是存储数据的一种媒介, 数据都是按照某种格式存储在某些特定的文件中的 我们比较早接触过的数据库, 比如说 DBASE FOXBASE 之类的, 实际上更多地表现为一种记录管理系统, 在文件中按照既定的格式存储了一些数据记录 早期开发 DBASE 应用的

18 20 第 章理解 Oracle 数据库和实例 程序员可能还记得, 最初的 DBASE 数据库都是单机环境的, 因此在开发时不用考虑互斥和锁的 问题, 只需要按照业务要求处理记录就行了 后来有了 NOVELL 网,FOXBASE 得到了广泛的 应用 老白最早学习 NOVELL 网的时候也很困惑, 对于 FOXBASE 能够在 NOVELL 网上运行感 到十分神秘, 后来明白了实际上 NOVELL 网为 FOXBASE 数据库提供了一个共享文件系统, FOXBASE 正是通过 NOVELL 的共享文件系统在多个网络终端之间同步, 这样一来在 NOVELL 网上的 FOXBASE 应用就十分容易理解了 在 FOXBASE 里, 我们通过 LOCK TABLE 命令来锁 定某张表, 然后再对其进行访问和修改, 这样就可以避免多用户环境下的冲突问题了 刚才似乎扯得有点远了, 反过头来, 我们再来认识 Oracle 数据库 Oracle 数据库是一种支持 高并发的 RDBMS 系统, 因此 Oracle 也需要解决在大量并发用户下的一致性访问问题 Oracle 数 据库对外提供的访问方式并不是应用程序直接打开数据文件来操作数据库, 而是通过一种 TWO-TASK 的模式提供服务 在这种架构下, 应用无法直接访问数据库, 而必须通过一种被称 为实例 (Instance) 的逻辑结构去访问数据库 于是我们需要了解一个十分重要的新概念 实例 那么什么是实例呢? 官方的说法, 实例 指的就是操作系统中一系列的进程以及为这些进程所分配的内存块 如果用更容易理解的方式来 解释, 那就是说 Oracle 数据库的实例是我们访问 Oracle 数据库的通道 下面我们先来了解一些数据库实例的基础概念 在一个数据库实例中, 包含了 Oracle 的共享 内存和一系列的后台进程, 一个实例在同时只能打开一个数据库, 而一个数据库可以同时被多个 实例打开, 当然了, 这种情况就是我们常说的 RAC Oracle 数据库的实例必须依赖于某个特定

19 .3 实例和多实例数据库 2 的 ORACLE_HOME, 启动实例需要的所有的程序和相关的文件 ( 除了数据库外 ) 都包含在 $ORACLE_HOME 中 除此之外, 每个实例都有自己独立的 SID 在同一个 ORACLE_HOME 下, 允许启动多个实例, 但是这些实例必须拥有不同的 SID 另外, 一个非 RAC 的数据库是不允许 被多个实例打开的, 因为实例 mount 独立数据库的时候, 是以排他的方式进行的 一个 RAC 的 数据库, 只允许同一个 RAC 集群中的多个实例打开, 非相同集群的节点是无法打开同一个数据 库的 通过上面的介绍, 我们了解了实例 数据库 ORACLE_HOME SID 这些概念之间的关系, 下面我们进一步来了解实例 在 Oracle 中, 我们可以启动一个 Oracle 的实例, 这个时候虽然有 了进程还有 SGA 等一系列的内存块, 但是并没有把数据库文件读取进来 实例启动后, 为访问 Oracle 数据库的应用提供了一个基础的环境 这个基础环境包含了一组共享内存, 后者又包含了 Oracle 数据库的一系列内部数据结构, 也包括了 Oracle 数据库的 SQL 和数据字典缓冲 ( 共享池 中的库缓存和字典缓存 ), 还有数据块缓冲 (DB Cache) 在一个启动了 Oracle 实例的 UNIX 系 统上, 使用 ipcs 命令可以看到共享内存的情况 : [oracle@ ~]$ ipcs Shared Memory Segments key shmid owner perms bytes nattch status 0x9a8837b oracle Semaphore Arrays key semid owner perms nsems 0x03c3d oracle 我们可以看到,Oracle 用户分配了一组共享内存和信号灯, 这和我们在 UNIX 下编写具有共 享内存的应用程序并无不同 实例启动时首先会装载参数文件, 根据参数文件中定义的内存相关

20 22 第 章理解 Oracle 数据库和实例 参数创建共享内存和信号灯, 然后将参数文件装载到共享内存中被称为 ksppi 的内存区域, 同时 将当前实例的参数装载到一个独立的区域 ksppsv 根据参数文件, 启动进程完成 SGA 中内 存结构的初始化工作, 然后启动相关的后台进程 这个过程完成后, 数据库实例启动的第一步 nomount 就完成了 实例启动到 nomount 后, 所有的共享内存和后台进程就都已经装载完毕 于是, 系统根据参 数文件中控制文件的位置, 打开控制文件, 并对控制文件进行校验, 如果这个步骤没有发现问题, 就完成了 mount 步骤 数据库实例 mount 完成后, 通过对控制文件 UNDO 和 REDO 等进行比对分析后, 发现数 据库状态是一致的, 数据库实例就可以打开数据库了 数据库打开后, 数据库实例就可以提供对 外服务了 数据库实例启动过程在很多书中都有十分详细的介绍, 因此本节就不再赘述 数据库实例启 动后, 应用程序就可以通过数据库实例来访问数据库了 应用要访问 Oracle 数据库, 可以通过三种方式 : 第一种方式是应用进程直接访问数据库实例 的共享内存, 第二种方式是通过 beq 协议在本机上访问, 第三种方式是通过网络协议访问 第一 种方式使用的场合很少, 我们不做讨论 下面着重讨论通过第二种和第三种方式访问数据库 首先, 后两种访问数据库的方式都是基于 two-task 结构的, 都需要在数据库服务器上建立一 个服务进程 (server 进程, 或者前台进程 ) 来为客户端应用服务 ( 在这里我们只讨论独立服务器 模式, 共享服务器模式十分类似, 我们将在后面进行专题描述 ) two-task 架构下访问数据库, 首

21 .3 实例和多实例数据库 23 先需要在服务器端创建一个进程, 这个进程启动时先要映射共享内存, 然后才能够通过共享内存中的内部数据结构完成会话的初始化工作 在本机上不经过 SQL*Net 连接数据库, 前台进程和用户进程之间通过 IPC 机制进行通信, 通信协议就是著名的 Bequeath 协议, 简称 BEQ 协议 而如果通过 SQL*Net 连接数据库, 那么就需要使用网络协议 现在 TCP/IP 协议已经成为使用最为广泛的协议, 因此我们主要面对的是 TCP/IP 协议, 而 0 多年前, 著名的 SPX 协议 DECnet 协议 Token Ring 协议等都曾经是 DBA 进程配置的协议 使用 SQL*Net 协议的前台进程和用户进程之间的通信采用 Socket 通信 实际上, 在服务器上, 我们也可以使用 SQL*Net 连接数据库, 只不过我们很少会去这样做, 因为 BEQ 协议在效率上高于 Socket 通信 除了使用的协议不同, 在本机上通过 BEQ 协议连接数据库实例和通过 SQL*Net 连接数据库实例还有什么不同吗? 很多 DBA 可能会感觉有所不同, 因为在本机上直接连接数据库协议, 前台进程是 shell 进程产生的子进程 ; 而通过 SQL*Net 连接数据库实例,server 进程是 LISTENER(tnslsnr) 产生的子进程, 如果监听器进程的属性不同, 那么产生的子进程会和 shell 直接产生的子进程有所不同 这一点不同在早期的 Oracle 版本中确实存在, 而自从 $ORACLE_HOME/bin/oracle 这个映像文件被设定为 s 属性后, 这个问题就不存在了 Oracle 映像通过 s 属性可以将子进程的属性转为 Oracle 用户 不过使用 BEQ 协议和网络协议在服务进程方面还是有所不同的,BEQ 协议通过 IPC 通信, 因此不需要使用 Socket, 而通过网络协议 (SQL*Net) 连接, 客户进程最初连接的是 tnslsnr 进程,

22 24 第 章理解 Oracle 数据库和实例 tnslsnr 进程接受了连接请求后, 为其创建一个子进程, 然后通知客户端进程重新连接到子进程上 继续工作 在这个时候, 就存在一个 Socket 重定向的问题 监听器产生子进程时会为新的连接 分配一个未被使用的端口号, 这个子进程启动后就在该端口上侦听, 同时监听器会通知客户端进 程, 要求其重定向到新的端口号 此时客户端进程会关闭老的 Socket, 并打开一个新的 Socket, 完成登录操作 可能有些 DBA 对上面的讨论感到有些迷茫了, 怎么讨论实例的问题, 一下子又转到了监听 器的工作机制上了, 这些知识对于 DBA 又有什么作用呢? 我们刚才一直在强调实例是客户端访 问数据库的通道, 因此讨论客户端如何通过监听器连接数据库就十分有意义了 首先第一点, 现在很多客户对系统安全性要求很高, 因此服务器上大量的网络端口是被封掉 的, 只有必须使用的才会被开放 那么对于 Oracle 数据库来说, 我们只需要开放监听器所需要的 端口就可以了吗? 事实上不是这样的, 除了开放类似 52 的监听端口外, 我们还需要开放一些 高端口, 这些端口将被用于 Socket 重定向 可能很多用户在客户端连接数据库的过程中经常会碰到 TNS-2535 之类的错误, 开始的时 候总是从网络超时的角度去分析, 不过这样分析往往很难找到真正的故障原因 这类问题在一个 存在防火墙的环境中, 往往是由于在防火墙环境下的 Socket 重定向引起的, 特别是在有 NAT 功 能的防火墙上, 这类问题很容易出现 客户端连接的是一个 NAT 翻译后的 IP 地址, 而重定向的 时候, 监听器要求客户端连接到真实的 IP 地址上, 这样就会出现连接超时导致的失败 这种情 况一般的解决方案是使用 connect manager(cman), 老白也曾经碰到过几个这样的客户, 最后

23 .3 实例和多实例数据库 25 都是通过 CMAN 来彻底解决问题的.3.2 多实例数据库多实例数据库的概念同样经常让 DBA 感到迷惑 多实例数据库可以说是 RAC 的另外一种称呼,Oracle RAC 的特点就是多个数据库实例可以同时打开相同的数据库, 进行并发的操作 多实例数据库是 Oracle 高可用架构和高可扩展性架构的核心技术, 多个实例同时打开数据库进行读写, 可以避免某个实例故障导致的系统不可用, 同时多实例实现负载分担, 也可以减轻某个实例的工作负载, 从而提高整体吞吐能力 Oracle RAC 是多实例数据库的正式名称,RAC 具有很多激动人心的特性, 但是实施 RAC 也有一些潜在的风险 在实施之前, 我们必须认真地了解 RAC 的一些基本概念 RAC 多实例数据库架构有几个基础 第一个基础是共享存储, 多台服务器 ( 一般来说我们称之为节点 ) 可以同时并发读写相同的文件 如果没有这个基础,RAC 就无从谈起 我们可以使用很多技术来实现共享存储, 最为普遍使用的就是存储局域网络 SAN, 通过光纤交换机连接的共享存储, 一组 lun 可以同时被多个服务器节点访问 除了 SAN 外, 以 NETAPP 为代表的基于 TCP/IP 的存储解决方案也是 RAC 的可选方案, 通过 ISCSI 或者 NFS 共享文件系统, 同样可以满足 RAC 对于共享存储的需要 在底层的可共享硬件的基础上, 对于裸设备或者除了 NFS 外的非共享文件系统,RAC 还需要依赖于操作系统提供的并发存储支持, 允许软件并发访问底层存储 比如说 IBM 的 HACMP 提供的并发 VG 的支持, 允许同一个 VG 在多个节点上同时被激活 另外在此基础上的集群文件系统 (CFS) 也是实施部署 RAC 的不错的平台 从 0g 开始,Oracle

24 26 第 章理解 Oracle 数据库和实例 也提供了一个自己的共享存储解决方案 ASM, 在底层提供共享的存储硬件的基础上,Oracle 可 以不使用第三方的共享存储解决方案, 仅仅使用自己的 ASM 技术, 实现类似 HACMP 并发 VG 或者赛门铁克 CFS 的功能 除了共享存储外,RAC 还需要依赖于 CLUSTERWARE 在 0g 之前,RAC 必须使用各个厂 商提供的 CLUSTERWARE, 比如 IBM 的 HACMP HP 的 MC/SG 和 TRU64 CLUSTER 另外也 可以使用第三方厂商提供的 CLUSTERWARE, 比如赛门铁克的 STORAGE FOUNDATION 中的 CLUSTER 组件 从 Oracle 0g 开始,RAC 完全可以脱离第三方的 CLUSTERWARE, 而使用 ORACLE 自己的 CRS CRS 是 Cluster Ready Services 的简称,CRS 提供了 RAC 数据库系统所必 需的运行环境 而且从 0g 开始,RAC 数据库 (RAC RDBMS) 必须依赖于 CRS, 无论你是否安 装了第三方的 CLUSTERWARE,RAC RDBMS 的底层堆栈只能在 CRS 的基础上运行 这里有一个读者很容易混淆的概念, 就是 CRS 和 RAC 之间的区别 很多 DBA 认为 CRS 就 是 RAC,RAC 就是 CRS, 实际上这是一个十分错误的认知 RAC 更严格地说是 RAC RDBMS, RAC 只是 Oracle RDBMS 的一个选件, 安装并启用了 RAC 功能的数据库我们称之为 RAC RDBMS, 这是一个多实例的关系型数据库系统 而 CRS 只是一个 CLUSTER 的组件, 它提供了 RAC RDBMS 运行所必需的底层集群环境 CRS 本身也不提供共享存储系统, 它只提供了 CLUSTER 的节点管理 健康性检查以及一系列 CLUSTER 应用 ( 比如 VIP ONS 等应用 ), 真正 在 RAC 中提供共享存储的是 ASM HACMP 或者 CFS 等技术 一个多实例的数据库系统, 必须运行在 CLUSTERWARE 环境中, 同时 CLUSTERWARE 也

25 .3 实例和多实例数据库 27 对 RDBMS 的运行情况进行一定限度的监控 以 0g CRS 为例,RAC RDBMS 启动时必须依赖 CLUSTERWARE 环境, 但是反过来,CRS 可以不知道 RAC RDBMS 的存在, 也就是说一个 RAC 数据库实例可以不经过在 CRS 的 OCR 中注册而独立启动, 而不会影响 RDBMS 的正常功能 但是如果 CRS 不知道这个数据库的存在, 那么这个数据库及其实例就都不在其监控之中, 一旦某个数据库实例出现故障,CRS 也不会做出相应的反应, 比如重启节点等 多实例数据库系统的一个很重要的特性是多个实例可以并发对同一个数据进行读写, 这一点也是 RAC 十分核心的功能 不过在多实例数据库环境中, 每个实例都拥有自己独立的 SGA, 为了确保数据库的一致性,Oracle RAC 系统需要使用一个被称为缓冲区融合 (CACHE FUSION) 的技术来实现多个节点上的缓冲区的一致性访问 因此, 在多实例数据库中修改数据, 需要一些额外的成本 除了 Oracle 锁 (ENQUEUE) 被扩展为全局资源外, 如果一个 BUFFER 在多个实例中被访问, 那么这个 BUFFER 也就会成为全局 BUFFER 对于全局 BUFFER 的访问, 其开销是要比普通的 BUFFER 大一些的, 因为每次访问都需要向某个 BUFFER 的 MASTER 节点咨询该 BUFFER 的情况, 并由 MASTER 节点来授权对该 BUFFER 的各种访问 在早期的 Oracle RDBMS 版本中, 某个 BUFFER 的 MASTER 节点从该 BUFFER 被装载到被换出, 是不会发生变化的 这样一种机制, 导致了某个 BUFFER 的 MASTER 节点不一定是访问这个 BUFFER 最多的节点, 从而也导致了一些不必要的网络包用来处理 MASTER 节点和访问节点之间的交互请求信息 从 开始,Oracle 提供了一种新的机制, 即动态 REMASTER 机制 DRM, 这个机制的出发点是某个资源的 MASTER 节点不是一成不变的, 而是根据该资源被某个节点的访问频率的改变,

26 28 第 章理解 Oracle 数据库和实例 自动进行动态的 REMASTER 这种技术的出发点是十分好的, 在一个设计良好的系统中, 或者 在一个负载并不是很高的多实例系统中,DRM 能够发挥很好的作用 很多从 9i 升级到 0g 的系 统, 升级后都发现 RAC INTERCONNECT 的流量以及 GES/GCS 的相关指标都有所改善 不过对 于一些比较繁忙 写操作很多的系统,DRM 技术可能导致很多的问题 比如说, 节点启动时 RECOVERY 的性能大幅度下降,OPEN 数据库很慢, 或者在一个错误节点上执行了一个大批量 数据修改操作时, 大量的 REMASTER 可能导致系统短暂 HANG 住 多实例数据库的特性对于 DBA 分析数据库故障, 以及进行优化处理都提出了一个新的要求 就是我们在分析某个事件或者问题时, 不能局限于某个实例, 而要将思路拓宽到所有实例 比如 说我们发现某个操作被 HANG 住时, 不仅仅要分析本实例上面可能存在的 BLOCKER, 而且要 将分析的范围扩大到其他所有的实例, 才有可能找到问题的根源 为了实现多实例数据库技术,Oracle 的很多组件都带有实例特性 Oracle 的所有数据文件都 是所有实例共享的, 一般来说必须将数据文件存放在所有实例都可以访问的存储系统上 有些 DBA 就可能有疑问了, 如果某个数据文件, 只有某个实例才会去访问 ( 比如这个数据文件相关 的表空间上的表, 被限制为只在某个实例上访问 ), 那么这个文件也必须要在所有节点上共享吗? 回答当然是肯定的 虽然说在正常情况下, 只有某个节点才会访问这个数据文件, 但是一旦这个 实例宕了, 其他节点要替这个节点做 RECOVERY 的时候, 这个文件就必须被其他节点访问了 在维护 RAC 数据库的时候,DBA 经常会犯的一个错误就是在添加裸设备的时候, 往往只注意了 在要添加的节点上修改文件的 OWNER 属性, 而忘记了在其他节点上修改属性 一旦其他节点读

27 .3 实例和多实例数据库 29 取了这个文件, 发现这个文件无法访问, 那么在其他节点的 SGA 中, 这个文件就变成无法访问了 这个时候哪怕我们修改了文件属性, 在 SGA 中的文件状态还是无法改变的 有的 DBA 想通过设置文件 OFFLINE/ONLINE 来解决这个问题, 不过这个办法好像也是无效的 对于这个问题, Oracle 官方建议一般是重启其他的几个实例 但是在一个 24 7 的生产系统中, 重启实例是灾难性的, 这种情况下执行一下 ALTER SYSTEM CHECK DATAFILES; 可以让实例重新校验所有 ONLINE 文件的状态, 恢复文件的可用性 多实例的数据库中, 每个实例拥有一组独立的在线日志记录, 也就是我们常说的 REDO THREAD 每个实例独立生成在线日志信息, 并且拥有独立的 LGWR 进程用于写入在线日志文件 但是在 RAC 数据库环境中, 在线日志文件也必须是所有节点都能够共同访问的 原因也是一样的, 当进行实例恢复的时候, 由于相关的数据被写在多个在线日志文件中, 因此必须用到所有的 REDO LOG THREAD 中的在线日志文件, 才能够完成恢复 当我们在数据库上增加一个新的实例的时候, 必须为这个实例创建一组新的在线日志记录, 同时激活这个 REDO LOG THREAD 反过来, 要从数据库中删除一个实例的时候, 我们必须关闭这个 THREAD, 否则无论这个实例是否被使用, 数据库恢复的时候, 仍然会需要使用这个 THREAD 的日志 在这种情况下关闭某个 THREAD 后重新做一次全库备份, 会少很多麻烦事 如果你真的碰到了这种情况, 而那个实例的在线日志文件还没删除, 那么可以找找数据库恢复所需要的 CHANGE# 是否在在线日志中存在, 如果存在, 你也可以直接恢复这个在线日志来解决这个问题 在使用 UNDO 自动管理的模式下, 每个实例都需要使用独立的 UNDO 表空间, 这些表空间

28 30 第 章理解 Oracle 数据库和实例 的数据文件也必须存放在所有实例都能够访问的共享存储上, 其原因我们在前面已经多次提到, 不再重复了 在多实例数据库环境中, 临时表空间是可以多个实例共享的, 不过能够共享的仅仅是临时表 空间, 临时段是不能共享的 在一个临时表空间上, 每个实例必须拥有自己独立的临时段 当临 时表空间满的时候, 如果其他实例的临时段有空闲空间, 那么这个实例可以从其他实例的临时段 中偷取一个 EXTENT, 用于扩展自己的临时段.4 数据库后台进程 数据库的进程可以简单地分为前台进程和后台进程, 前台进程是 Oracle 客户端访问数据库而 创建的影子进程, 后台进程是维持 Oracle 数据库正常运行所必需的 本节我们将探讨各类数据库 进程之间是如何分工协作, 并实现高效访问的.4. 进程结构 进程是操作系统中的一种机制, 它可使用操作系统中的资源完成某个特定的任务 一个进程 通常有其专用的存储区和特定的功能 Oracle 进程体系结构的设计目的是尽可能地使用系统的资 源, 使访问者获得最大的吞吐量和最短的响应时间 Oracle 实例有两种类型 : 单进程实例和多进程实例 单进程 Oracle( 又称单用户 Oracle) 是 一种数据库系统, 一个进程执行全部 Oracle 代码 Oracle 数据库和用户应用程序无法实现进程分 离, 所以 Oracle 代码和用户数据库应用程序都是通过单进程执行

29 .4 数据库后台进程 3 在单进程环境下的 Oracle 实例, 仅允许一个用户存取, 例如在 MS-DOS 上运行 Oracle 多进程 Oracle 实例 ( 又称多用户 Oracle) 使用多个进程来执行 Oracle 的不同部分, 对应于每一个连接的用户都有一个进程 在多进程系统中, 进程分为两类 : 用户进程 ( 又称前台进程 ) 和 Oracle 后台进程 当用户运行一个应用程序时, 如 PRO*C 程序或 Oracle 工具 ( 如 SQL*Plus), 系统会为用户运行的应用建立一个用户进程, 该进程通过某种方式启动一个服务器进程 ( 前台进程 ), 用于处理连接到该实例的用户进程的请求 如果应用和 Oracle 在同一台机器上运行, 而不通过网络, 那么用户进程和服务器进程之间可以通过 BEQ 协议通信, 从而降低系统开销 然而, 当应用和 Oracle 运行在不同的机器上时, 用户进程使用 TCP/IP 协议, 通过服务器进程访问 Oracle, 可执行下列任务 对应用所发出的 SQL 语句进行语法分析和执行 从磁盘 ( 数据文件 ) 中读入必要的数据块到 SGA 的共享数据库缓冲区 ( 该块不在缓冲区时 ) 将结果返回给应用程序处理 为了使系统性能最好并能够协调多个用户, 多进程系统使用了一些附加进程, 称为后台进程 在许多操作系统中, 后台进程是在实例启动时自动建立的 一个 Oracle 实例可以包含许多后台进程, 但它们不是一直存在的 后台进程的名称为 : DBWR, 数据库写入程序 ; LGWR, 日志写入程序 ; CKPT, 检查点 ;

30 32 第 章理解 Oracle 数据库和实例 SMON, 系统监控 ; PMON, 进程监控 ; ARCH, 归档 ; RECO, 恢复 ; LCKn, 封锁 ; Dnnn, 调度进程 ; Snnn, 服务器 每个后台进程与 Oracle 数据库的不同组件进行交互, 完成特定的功能 比如,DBWR 负责 脏数据存盘工作,LGWR 负责将 LOG BUFFER 中的数据写入在线日志文件.4.2 后台进程的功能作介绍 Oracle 的后台进程负责管理和维护 Oracle 实例 每个后台进程都负责一项独立的工作 这些 后台进程互相协作, 完成 Oracle 的公共职能 它们之间会互相监控, 一旦发现核心的后台进程出 现异常, 会主动关闭实例 下面依次介绍主要后台进程的功能. DBWR 进程 DBWR 进程执行将数据块缓冲区写入数据文件的工作, 是负责缓冲存储区管理的一个 Oracle 后台进程 在修改 DB Cache 中的某个缓冲区时, 会将它标志为 DIRTY,DBWR 的主要任务 是将这些标为 DIRTY 的缓冲区写入磁盘, 使缓冲区保持 CLEAN 由于缓冲区填入数据库 或被用户进程弄脏, 未用的缓冲区数目会减少, 最终可能导致用户进程从磁盘读入块到内存存储

31 .4 数据库后台进程 33 区时无法找到未用的缓冲区 DBWR 将管理缓冲存储区, 使用户进程总能得到未用的缓冲区 Oracle 采用 LRU 算法 ( 最近最少使用算法 ) 保持内存中的数据块是最近使用的, 使 I/O 最小 下列情况预示 DBWR 要将弄脏的缓冲区写入磁盘 当服务器进程将一缓冲区移入 DIRTY 链, 此 DIRTY 链达到临界长度时, 该服务器进程将通知 DBWR 进行写入操作 这个临界长度是数据库隐含参数 _DB_BLOCK_WRITE_BATCH 值的一半 服务器进程在 LRU 表中查找可用的数据块缓冲时, 如果在查找了参数 _DB_BLOCK_MAX_SCAN_CNT 所定义数量的缓冲区后, 仍没有查到未用的缓冲区, 那么它将会停止查找, 并通知 DBWR 进行数据写入 DBWR 每次休眠时都会设置定时器, 如果出现超时 ( 每次 3 秒 ),DBWR 将通知自身 当出现检查点时,LGWR 将通知 DBWR 进行写入操作 在前两种情况下,DBWR 将 DIRTY 链中的块写入磁盘, 每次可写的块数由初始化参数 _DB_BLOCK_WRITE_BATCH 所指定 如果 DIRTY 链中没有该参数指定块数的缓冲区,DBWR 将从 LRU 表中查找另外一个 DIRTY 缓冲区 如果 DBWR 在 3 秒内未活动, 则出现超时 在这种情况下,DBWR 对 LRU 表查找指定数目的缓冲区, 将所找到的任何弄脏的缓冲区写入磁盘 每当出现超时,DBWR 就查找一个新的缓冲区组 每次由 DBWR 查找的缓冲区的数目是寝化参数 DB-BLOCK-WRITE-BATCH 值的两倍 如果数据库空运转, 最终 DBWR 会将全部缓冲区存储区写入磁盘 在出现检查点时,LGWR 指定一修改缓冲区表必须写入到磁盘, 而 DBWR 负责将指定的缓

32 34 第 章理解 Oracle 数据库和实例 冲区写入磁盘 在某些平台上, 如果有多个 CPU, 那么一个实例可设置多个 DBWR 在这样的实例中,DB Cache 被分为多个区, 每个 DBWR 管理一个或者几个 DB Cache 分区 这种结构可以让一些数据 块写入一个磁盘, 另一些数据块写入其他磁盘, 从而提升并发写入的性能 参数 DB_WRITERS 可以控制 DBWR 进程的个数 2. LGWR 进程 LGWR 进程是负责管理日志缓冲区的一个 Oracle 后台进程, 它将日志缓冲区写入磁盘上的 日志文件 LGWR 进程将自上次写入磁盘以来的全部 REDO LOG ENTRY 写入到 REDO LOG 文 件中 触发 LGWR 写操作的条件如下 当用户进程提交一事务时写入一个提交记录 每 3 秒将日志缓冲区输出 当日志缓冲区的已满 /3 时, 将日志缓冲区输出 当 DBWR 将修改缓冲区写入磁盘时, 则将日志缓冲区输出 LGWR 进程同步地写入到活动的镜象在线日志文件组 如果组中一个文件被删除或不可用, LGWR 可继续地写入该组的其他文件, 而数据库实例可以继续运行 日志缓冲区是一个循环缓冲区 当 LGWR 将日志缓冲区的日志项写入日志文件后, 服务器 进程即可将新的日志项写入到该日志缓冲区 LGWR 的写入速度很快, 以确保日志缓冲区总有空 间可写入新的日志项

33 .4 数据库后台进程 35 注意当需要更多的日志缓冲区时,LWGR 会在一个事务提交前就将日志项写出, 而这些日志项仅当后续事务提交后才永久化 Oracle 使用快速提交机制, 当用户发出 COMMIT 语句时, 一条 COMMIT 记录立即被放入日志缓冲区, 但相应的数据缓冲区改变被延迟, 直到更有效时才将它们写入数据文件 提交时, 将事务赋给一个系统变更号 (SCN), 它同事务日志项一起被记录在日志中 3. CKPT 进程 CKPT 进程在检查点出现时, 对全部数据文件的文件头进行修改, 并在控制文件中记录该检查点 在早期版本中, 该任务由 LGWR 执行 然而, 在检查点明显地降低系统性能时, 可使 CKPT 进程运行, 将原来由 LGWR 进程执行的检查点的工作分离出来, 由 CKPT 进程执行 从 Oracle 8 开始,CKPT 进程被独立出来, 它不再将块写入磁盘, 该工作转由 DBWR 完成 在 Oracle 7 中, 可以通过初始化参数 CHECKPOINT_PROCESS 来控制是否启用 CKPT 进程协助 LGWR, 它的默认值是 FALSE; 另外, 如果数据文件的数量很多, 那么启用 CKPT 会对性能有一定的提升 4. SMON 进程 SMON 进程负责在实例启动时执行实例恢复, 并清理不再使用的临时段 在具有并行服务器选项的环境下,SMON 对有故障的 CPU 或实例进行实例恢复 从 Oracle 9i 开始, 事务回滚操作的默认行为也是由 SMON 来负责处理的 虽然 SMON 本身不做恢复操作, 而是启用并行进程来处理, 但是它起到整体协调的作用 SMON 进程有规律地被唤醒, 并检查是否有工作要完成, 如

34 36 第 章理解 Oracle 数据库和实例 有需要, 就做相应的处理, 否则继续休眠 5. PMON 进程 PMON 进程在用户进程出现故障时执行进程恢复, 负责清理存储区和释放该进程所使用的资 源 比如, 某个进程死掉了,PMON 要重置活动事务表的状态, 释放锁资源, 将该故障的进程 ID 从活动进程表中移去 PMON 还周期性地检查调度进程 (DISPATCHER) 和服务器进程的状 态, 如果发现这些后台进程死掉, 就需要重新启动 PMON 有规律地被呼醒, 检查是否有需要完 成的工作 6. RECO 进程 RECO 进程是启用分布式选项时才会存在的进程, 而且 DISTRIBUTED\ TRANSACTIONS 参数大于 0 当然, 分布式事务在绝大多数系统中是默认安装的, 因此一般来说, 总是能在数据 库实例中看到这个进程 RECO 进程能够自动解决分布式事务中的故障 一个结点的 RECO 后台 进程能够自动连接到包含错误的分布式事务的其他数据库中, 在解决了所有的故障后, 将这个全 局事务从 2pc_pending 等相关的表中删除 当数据库服务器的 RECO 后台进程试图同一远程服务器建立通信时, 如果远程服务器不可 用, 或者网络连接不能建立,RECO 将在一定时间间隔后自动重连 7. ARCH 进程 ARCH 进程将已填满的在线日志文件复制到指定的存储设备 当日志为 ARCHIVELOG 使用 方式并可自动归档时,ARCH 进程才存在 8. LCKn 进程 LCKn 进程在具有并行服务器选件的环境下使用, 可多至 0 个进程 (LCK0,LCK,,

35 .4 数据库后台进程 37 LCK9), 用于实例间的封锁 9. Dnnn 进程 ( 调度进程 ) Dnnn 进程允许用户进程共享有限的服务器进程 (SERVER PROCESS) 没有调度进程时, 每个用户进程需要一个专用服务进程 ( DEDICATED SERVER PROCESS) 多线索服务器 (MULTI-THREADED SERVER) 可支持多个用户进程 如果系统具有大量用户, 多线索服务器可以很好地支持, 尤其在客户 / 服务器环境中 在一个数据库实例中可建立多个调度进程 对每种网络协议至少建立一个调度进程 数据库管理员根据操作系统中每个进程可连接数目的限制决定启动的调度程序的最优数, 在实例运行时可增加或删除调度进程 多线索服务器需要 SQL*Net 版本 2 或更高的版本 在多线索服务器的配置下, 一个网络接收器进程等待客户应用连接请求, 并将每一个发送到一个调度进程 如果不能将客户应用连接到一调度进程时, 网络接收器进程将启动一个专用服务器进程, 该网络接收器进程不是 Oracle 实例的组成部分, 而是处理与 Oracle 有关的网络进程的组成部分 在实例启动时, 该网络接收器被打开, 为用户连接到 Oracle 建立一通信路径, 然后每一个调度进程把连接请求的调度进程的地址传给它的接收器 当一个用户进程作连接请求时, 网络接收器进程分析请求并决定该用户是否可使用一调度进程 如果是, 该网络接收器进程返回该调度进程的地址, 之后用户进程直接连接到该调度进程 有些用户进程不能调度进程通信 ( 如果使用 SQL*Net 以前的版本 ), 网络接收器进程不能将此类用户连接到一调度进程 在这种情况下, 网络接收器将建立一个专用服务器进程和一种合适的连接

36 38 第 章理解 Oracle 数据库和实例.4.3 哪些后台进程可以杀 在很多情况下我们需要杀死后台进程 比如, 系统出现了大量挂起的现象, 而通过 HANGANALYZE 工具分析, 我们发现元凶是一个后台进程, 那么是否要通过杀掉这个进程来解 决问题, 就要十分谨慎了 因为有些后台进程是不能随便杀的, 一旦杀掉就可能导致数据库实例 崩溃 因此, 有些 DBA 给自己定了一条金科玉律, 就是后台进程绝对是不能杀的 其实这种做法过于保守了, 只要你足够了解后台进程的主要功能, 就可以十分安全地管理后 台进程了 本节老白将以 Oracle 0g 和 g 为例, 和大家讨论究竟哪些后台进程是可以杀的 首先我们来看六大核心进程 其实 Oracle 并没有核心进程这个概念, 这是老白自己的归纳总 结 那么哪几个后台进程可以称为六大核心进程呢?pmon smon dbwr lgwr reco 和 ckpt 这 六个进程是所有 Oracle 数据库必不可少的, 其中 ckpt 进程出现得较晚, 其他五个进程是老白使 用 Oracle 数据库以来就一直存在的系统进程 这些进程无论哪个出现故障, 都会导致数据库实例 崩溃 因此, 这些进程是无论如何都不能杀的 如果我们杀掉其中某个进程, 在 ALERT LOG 中 就会发现各种错误 在某个 shell 中, 杀掉 ckpt 进程 : [oracle@localhost ~]$ ps -ef grep ckpt grid Sep25? 00:00:00 asm_ckpt_+asm oracle Sep25? 00:00:22 ora_ckpt_orcl oracle :48 pts/4 00:00:00 grep ckpt [oracle@localhost ~]$ kill 执行了上述命令后, 我们发现 ALERT LOG 中出现了 : Mon Sep 26 08:48:3 20 System state dump requested by (Instance=, osid=5342 (PMON)), summary=[abnormal Instance termination].

37 .4 数据库后台进程 39 况呢? System State dumped to trace file /u0/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_diag_5365.trc Mon Sep 26 08:48:32 20 PMON (ospid: 5342): terminating the Instance due to error 469 Mon Sep 26 08:48:32 20 ORA-092 : opitsk aborting process Dumping diagnostic data in directory=[cdmp_ ], requested by (Instance=, osid=5342 (PMON)), summary=[abnormal Instance termination]. Instance terminated by PMON, pid = 5342 可以看到, 由于 ckpt 出现故障,pmon 进程将实例关闭了 如果杀掉 pmon 又会出现什么情 Mon Sep 26 08:52:58 20 Shutting down Instance (abort) License high water mark = 4 USER (ospid: 224): terminating the Instance Instance terminated by USER, pid = 224 Mon Sep 26 08:52:59 20 Instance shutdown complete 我们看到, 当 pmon 被杀掉后, 一个前台进程执行了 shutdown abort 操作, 终结了实例 (Instance terminated by User) 可以看出, 虽然 pmon 是监控进程的后台进程, 但是一旦重要的后台进程出 现故障,pmon 会自动关闭实例 反过来所有的 Oracle 进程, 包括前台进程和后台进程, 也在监 视 pmon, 一旦发现 pmon 异常, 会立即关闭实例 这种相互监控的机制也是大型系统中最为常 用的方法 下面我们来看看 0g 新增加的 MMAN 进程,MMAN(Memory Manager ) 进程是 0g 新引 入的进程, 主要目的是实现共享内存自动管理的功能, 自动调整共享内存各个组件的大小 Mon Sep 26 :09:52 20 Errors in file /opt/oracle/admin/orcl/bdump/orcl_pmon_626.trc: ORA-00822: MMAN process terminated with error Mon Sep 26 :09:52 20 PMON: terminating Instance due to error 822 Instance terminated by PMON, pid = 626 可以看到, 一旦 MMAN 进程出现故障, 数据库实例就会崩溃 看样子 MMAN 是继六大核

38 40 第 章理解 Oracle 数据库和实例 心进程之后的第七个不可杀的核心进程 PSP0 进程在 0g 中开始引入, 主要功能是启动其他的 Oracle 进程 这个进程也是一个十分 关键的核心进程, 一旦出现问题, 将导致数据库实例故障 Errors in file /opt/oracle/admin/orcl/bdump/orcl_pmon_3249.trc: ORA-00490: PSP process terminated with error Mon Sep 26 4:4:55 20 PMON: terminating Instance due to error 490 Instance terminated by PMON, pid = 3249 至此, 我们已经看到了八个关键核心进程 下面我们来看一下 cjq0 进程 它是一个任务队列的调度进程, 负责从 job$ 表中找到需要执 行的任务, 并分配 job 进程执行, 如果 job 进程不足, 会自动产生新的 job 进程 ( 在 job_queue_processes 参数限制范围内 ) 下面来看看杀掉这个进程会有什么结果 Mon Sep 26 09:07:8 20 Restarting dead background process CJQ0 Mon Sep 26 09:07:8 20 CJQ0 started with pid=25, OS id=2226 可以看出 cjq 进程如果被杀掉,cjq0 进程会被重启 既然 cjq0 都可以杀, 那么 cjq0 产生的 JXXX 进程我们就不用做实验了, 肯定是能杀的了 其实老白也是经常杀掉 JOB 进程的, 在某些系统中, 经常会有一些 JOB 进程占用大量的系统资 源, 从而导致数据库性能问题 这时, 为了恢复 OLTP 应用的性能, 杀掉 JOB 进程是最简单的方 法 不过在杀掉 JOB 进程之前一定要做仔细的分析, 如果 JOB 进程中正在做一个数据量很大的 大型修改事务, 那么杀掉这个 JOB, 可能会导致大量的回滚操作, 从而对系统性能产生更为不利 的影响

39 .4 数据库后台进程 4 下一个我们要来研究的是 arch 进程, 在 Oracle 0g 中,arch 进程一般是 arc0, arc,... 我们 来杀掉一个 arch 进程, 看看会有什么结果 Mon Sep 26 09:56:27 20 ARCH: Detected ARCH process failure ARCH: STARTING ARCH PROCESSES ARC0: Archival started ARCH: STARTING ARCH PROCESSES COMPLETE ARC0 started with pid=6, OS id=6646 ARC0: Becoming the 'no FAL' ARCH ARC0: Becoming the 'no SRL' ARCH 可以看出,arc0 进程被杀掉后, 会自动重启, 而数据库实例没有发生故障 因此 arch 进程如 果出现故障, 在必要情况下, 我们是可以杀掉该进程的 下面我们来看一下 QMON 进程,QMON 进程是队列监控同步进程 (QMNC) 和队列服务进 程 (QXXX) 的统称 Mon Sep 26 09:0:46 20 Restarting dead background process CJQ0 Mon Sep 26 09:0:46 20 CJQ0 started with pid=25, OS id=2347 从上面的测试可以看出,QMON 进程是可以杀的, 杀掉 QMON 进程的后果是相关进程重启 MMON 和 M000 是 Oracle 0g 引入的新后台进程,MMON 是管理监控进程,M000 是 MMON 的 SLAVE 进程, 协助 MMON 进程工作 如果这些进程出现故障会有什么结果呢? Mon Sep 26 0::39 20 Restarting dead background process MMON MMON started with pid=, OS id=860 MMON 进程是可以自动重启的, 当然也在可杀范围内了 类似的 MMNL 进程也是 AWR 新增的进程, 主要作用是将 AWR 数据从内存中刷新到表中 这个进程如果被杀掉也是可以自动重启的 在这里我们就不一一列出实验数据了 :

40 42 第 章理解 Oracle 数据库和实例 DISPATCHER 进程 DXXX: 如果被杀掉,ALERT 会报错, 不会导致实例宕机, 根据需要进 行重启 共享服务进程 SXXX: 如果被杀掉, 不会导致实例宕机, 根据需要进行重启 并行进程 PXXX/PZXX: 并行进程, 如果被杀掉, 不会导致实例宕机, 进程根据需要进行重 启 高级队列从属进程 QXXX: 如果被杀掉, 不会导致实例宕机, 进程根据需要进行重启 如果 存在高级队列操作, 杀掉此类进程要十分慎重 Oracle 0g 引入了 ASM 后, 也新增了一些和 ASM 有关的进程 首先 ASM 实例具有一系列 的后台进程, 其次,RDBMS 为了访问 ASM 也新增了一系列的后台进程 我们来看看 ASM 实例 的后台进程 ASM 实例也拥有类似 RDBMS 实例的核心进程, 另外 ASM 实例新增了一些其他的后台进程, 下面我们做一个简单的了解 ASMB: 当数据库实例使用 SPFILE 时启动的 ASM 后台进程 这个进程是十分关键的, 一 旦出现故障将导致 ASM 实例宕机 RBAL:DISKGROUP 做 rebalance 的后台进程, 该进程一旦有故障将导致 ASM 实例宕掉 DBW0:DB writes, 和 RDBMS 的 DB WRITER 类似, 不过是将 ASM CACHE 中的数据写入 磁盘, 该进程一旦有问题将导致 ASM 实例故障 SMON: 恢复进程, 类似于 RDBMS 的 SMON 进程, 处理 DISKGROUP 的恢复操作, 一旦

41 .4 数据库后台进程 43 有问题将导致 ASM 实例故障 CKPT:Checkpoint 进程, 类似于 RDBMS 的 CKPT 进程, 一旦有问题将导致 ASM 实例故障 PSP0: 启动其他 ASM 实例进程的进程, 一旦有问题将导致 ASM 实例故障 GMON: 群组监控进程, 用于节点监控和状态表的维护, 一旦有问题将导致 ASM 实例故障 ora_asmb: 特殊的 ASM 前台进程 KATE:Konductor or ASM Temporary Errands, 用来执行 ONLINE 磁盘的临时任务进程 VKTM: 管理快速计时器的进程 PING: 计量网络延时的进程 DIA?: 类似于数据库的 diag 进程 DIAG: 类似于数据库的 diag 进程 LGWR:Log writer, 和数据库类似, 处理磁盘组的 REDO 信息 LMON: 锁监控进程, 类似于数据库的 LMON 进程 LMS?: 锁监控 SLAVE 进程, 类似于数据库的 LMS 进程 MMAN:SGA 自动调整进程, 类似于数据库的 MMAN b???: 用于离线磁盘的 SLAVE 进程 x???: 磁盘组重配置后删除磁盘的 SALVE 进程

42 44 第 章理解 Oracle 数据库和实例 pz??: 用于 GLOBAL VIEW 查询的并行 SLAVE 进程 Oracle g 在后台进程方面有了较多的改变, 这种改变有时候甚至让我们感觉 Oracle 数据库 变陌生了, 需要重新认识 Oracle g 的后台进程结构 下面是新增的后台进程 ACMS(atomic controlfile to memory service), 这是每个实例都有的代理进程, 在 RAC 环境 下, 对控制进程事务的提交和回退起到辅助作用 DBRM(database resource manager), 用于资源管理和资源计划相关的任务 DIA0 (diagnosability process 0), 目前只有 0, 没有其他进程, 用于数据库的挂起检测和 死锁处理 DIAG(diagnosability), 进行诊断 DUMP, 执行全局 oradebug 命令 EMNC(event monitor coordinator), 用于数据库事件管理和发布的进程 FBDA(flashback data archiver process), 闪回区归档进程, 用于将跟踪表的历史记录写入归 档日志, 管理闪回数据区的空间 GTX0-j (global transaction), 在 RAC 环境中为 XA 全局事务提供透明的服务, 只在 RAC 环 境中出现 系统会根据 XA 事务的负载情况确定启动几个这种进程 KATE, 当磁盘离线时代理 ASM metadata 的 I/O MARK, 当写入一个离线磁盘出错时记录这个 ALLOCATION UNIT 为过期状态 SMCO(space management coordinator), 执行空间管理有关的作业, 比如空间预分配和空间 回收 可以动态生成 Wnnn SLAVE 进程

43 .4 数据库后台进程 45 VKTM(virtual keeper of time), 每秒更新一次时间, 在高优先级情况下可以提供 20 毫秒的基准时间计数 DSKM(slave diskmon), 用于 RDBMS 和 ASM 实例之间的联系通道 Master Diskmon 守护进程处理 I/O 隔离信息,I/O 资源管理计划将 Transaction Commit Cache 信息传输到 SAGE 存储, 也用来在节点和 SAGE 存储服务器之间实现 skgxp ANT 协议 如果没有配置 SAGE 存储,diskmon slave 进程会在实例启动后自动关闭.4.4 是谁在执行 SQL 是谁在执行 SQL? 这个问题看似很简单, 不过要认真考虑起来, 却也不那么简单 很多工作了 7 8 年的 DBA 可能还真的没有认真考虑过这个问题 最初, 老白一直以为是 Oracle 的后台进程在执行 SQL, 然后将执行的结果返回给客户端进程 直到学习了 TWO TASK 这个概念后, 才知道在客户端连接到数据库时,Oracle 会创建一个服务进程 (Server Process),Oracle 的客户端通过和该进程通信来完成 SQL 的执行 现在回头一想, 如果是 Oracle 的后台进程来执行 SQL, 那么在一个大型的数据库系统中, 会有数千甚至上万个客户端在访问数据库, 光凭几个 Oracle 后台进程是肯定无法完成这个任务的, 这样就会出现瓶颈 从这个角度来看, 服务进程应该是执行 SQL 的 最佳人选 了 在独立服务器模式下, 每个 Oracle 会话都拥有一个独立的服务进程, 如果让它来担当执行 SQL 的角色, 那么就不会出现资源瓶颈了 事实上,Oracle 也是这样安排的,TWO TASK 的服务器端的服务进程, 担当的就是这样一个

44 46 第 章理解 Oracle 数据库和实例 角色 客户端要执行的 SQL, 通过 SQL*Net 或者 BEQ( 客户端和数据库服务器运行在同一台服 务器上时, 可以不通过 SQL*Net, 而直接通过 IPC 通信协议 BEQ 来通信 ) 发送给服务进程, 由 它来完成 SQL 的执行 我们可以更加深入地理解一下这方面的概念 先要问大家一个问题, 执行 SQL 的主体是什 么? 可能很多 DBA 会觉得有些迷惑了, 怎么什么简单的问题到了老白这里都变得那么不确定了 呢? 执行 SQL 的主体是会话 (Session) 呀, 执行 SQL 的呼叫是由会话发起的, 会话是 Oracle 数 据库用户进行 SQL 操作的唯一渠道 那么下一个问题又来了, 会话又是什么呢? 搞过网络编程的朋友可能早就听说过会话这个概 念了 两个网络设备要进行通信, 必须先建立起一个会话, 这个会话就是承载所有通信工作的逻 辑载体 再往前追溯, 会话的概念来自通信行业, 不过 Oracle 会话的本质更类似于网络设备之间 的通信 大家都知道网络通信有面向连接的协议, 也有面向无连接的协议 面向连接的协议一般 适用于上下文和状态十分关键的应用场合 Oracle 的会话正是具有这样的特征, 所以采用面向连 接的通信协议, 目前最常用的就是 TCP/IP 协议 出于安全考虑, 在建立会话之初,Oracle 需要 通过安全认证, 这也就是我们常见的 数据库登录,Oracle 的术语称为 LOGON 在 LOGON 的 时候, 首先 Oracle 客户端通过 SQL*Net 协议或者 BEQ 协议创建一个服务进程 如果通过 SQL*Net 协议, 客户端首先要和监听器通过 TCP/IP SPX 等面向连接的网络协议建立通信会话, 由监听 器创建一个服务进程, 客户端进程将网络通信会话重定向到这个服务进程, 随后, 客户端进程和 服务进程建立通信会话 大家可能注意到了, 老白在这里说了很多次 通信会话, 这么说就是

45 .4 数据库后台进程 47 为了区别与 Oracle 的会话 和客户端通信的服务进程也就是 Oracle 术语中所说的前台进程, 客户端和前台进程建立了通信会话并不等于说 Oracle 的会话已经建立了, 会话是一个更为虚拟的概念 大家先不要着急, 等老白一步一步地进行剖析 客户端和服务进程完成通信会话的握手后, 首先将 LOGON 所需要的信息发送给前台进程 前台进程收到这些信息后, 执行一个被称为 LOGON 的操作, 校验用户和权限 这个校验工作可以有多种方式, 最常见的是通过 SYSTEM 表空间中的 USER$ 表中保存的用户名和密码进行校验 Oracle 还支持其他方式的用户名 密码校验方式, 比如操作系统校验 外部安全设备校验 (LDAP) 完成 LOGON 操作后, 系统会在数据库服务器的 SGA 中创建一个会话的数据结构, 这个数据结构被称为 SESSION STATE OBJECT, Oracle 内部数据结构为 ksuse 在 Oracle RAC 日记 中, 老白曾介绍过这个结构, 具体如图 - 所示

46 48 第 章理解 Oracle 数据库和实例 STATE OBJECT type=4, session state obj 指向 PROCESS STATE OBJ SID 事件 SO 的地址 用于死锁检测的信息 等待事件及历史等待 SQL 和 PL/SQL 的 SO 图 - oracle 用户 图 - 显示的是 SESSION STATE OBJECT 的信息, 这个信息只包含了会话的基础信息, 会 话相关的数据结构十分复杂, 已经超出了本书的讨论范围, 因此不做更多的描述 会话建立后, 就成为客户进程和数据库实例之间的沟通渠道和桥梁, 执行客户端对数据库的 操作, 包括执行 SQL 不过会话是一个逻辑结构, 必须依赖于其容器 服务进程 ( 也叫前台进 程 ) 在独立服务器模式下, 每个会话对应一个独立的服务进程,Oracle 也提供了一种共享服务 器模式, 在这种模式下, 一个服务进程可以为多个会话服务, 换句话说, 一个服务进程可以成为 多个会话的容器

47 .4 数据库后台进程 49 在共享服务器模式下, 一般会配有一个或者多个调度进程 (DISPATCHER, 比如 D000) 和一组服务进程, 这些服务进程的最大数量受到 max_shared_servers 参数控制 当监听进程接收到来自客户端的连接请求时, 不是创建独立的服务进程, 而是使用现有的服务进程池来提供服务 监听进程首先会和调度进程通信, 找到可用的服务进程, 调度进程会将这个服务进程及其通信端口号发送给监听进程, 监听进程将网络通信连接重定向到这个服务进程, 完成客户端和服务进程之间的握手 在共享服务器模式下, 由于多个会话共享一个服务进程, 因此服务进程作为共享资源, 也可能成为一个瓶颈 如果使用同一个服务进程的几个共享会话中有一个执行了时间很长 开销很大的 SQL, 那么其他会话将会处于等待状态 共享服务器模式在早期的数据库系统中的使用是比较广泛的, 因为早期的服务器内存资源有限, 如果使用独立服务器模式, 内存资源将会十分紧张, 而使用共享服务器模式可以在内存资源有限的情况下, 支持大量的数据库会话 在目前内存资源十分充裕的情况下, 共享服务器模式的应用就越来越少了, 一个进程为一个会话服务, 可以有效地提高系统总体的吞吐能力 不过, 共享服务器模式也并不是完全没有了用武之地, 尤其是现在服务器性能有了大幅提高, 对于某些没有使用连接池的, 以短连接为主的应用来说, 如果执行的大多数是开销较小的 SQL, 那么使用共享服务器模式可以避免由于应用软件使用短连接而导致的数据库连接风暴, 因为这种数据库连接避免了频繁启动和关闭服务进程带来的性能问题 共享服务器模式还用于数据库连接穿透 NAT 防火墙 我们经常会碰到这样的应用场合, 客

48 50 第 章理解 Oracle 数据库和实例 户端在防火墙外, 而服务器在防火墙内, 出于安全考虑, 数据库服务器的服务 IP 通过 NAT 解释 为外网的 IP, 提供给防火墙外的客户端使用 不过 SQL*Net 连接在穿透防火墙时往往会出现问 题, 由于 SQL*Net 在连接时首先连接监听器, 然后由 LISTNER 分配一个服务进程, 再将连接重 定向到服务进程 正是这种重定向操作, 会导致客户端出现 TNS-2535 之类的错误 为了解 决这个问题,Oracle 提供了一个技术, 叫做 Connect Manager(CMAN), CMAN 是一个 SQL*Net 的代理 当外网的客户端要连接数据库服务器时, 首先不连接监听, 而是连接 CMAN,CMAN 作为代理, 接受客户端的连接, 然后将 SQL*Net 包进行转发 为了避免连接过程中出现的重定 向问题,CMAN 采用了预先连接的连接池技术,CMAN 在启动时就建立了一个连接池, 并和数 据库的服务进程建立了连接 因此客户端通过 CMAN 连接数据库时, 不需要建立新的网络连接, 就可以穿透 NAT 的防火墙 为了提高 CMAN 的效率,CMAN 连接池使用了共享服务器技术, 这 样一个服务进程就可以为多个通过 CMAN 连接的客户端提供会话服务 从上面的讨论中, 我们了解了会话及其容器服务进程之间的关系 会话是依赖于其服务进程 的, 一旦服务进程出现故障, 会话也将会出现故障 因此, 如果想要终止某个会话正在进行的操 作, 有两种办法, 一是杀死该会话, 我们可以通过 ALTER SESSION KILL 命令杀死这个会话 ; 此外, 也可以直接杀死会话对应的服务进程