Oracle的体系结构研讨.doc

Oracle的体系结构研讨

53
2020年5月29日
文档仅供参考

第1章
Oracle的体系结构
这一章的内容是比较枯燥的,但它是理解以后章节的基础。如果有读者在开始时有些内容没有完全理解也不用太着急,能够继续学习后面的内容,等使用了一段时间Oracle系统之后,一些概念就变得容易理解了。
1.1 Oracle引入复杂的体系结构的原因
数据库管理系统引入非常复杂的内存和外存体系结构的主要原因是有效地管理稀有的系统资源。资源不足不只是数据库管理系统所面正确。其实,在我们五千年的人类发展历史中,我们的祖先们一直在同资源不足作斗争。历史上粮食和土地等一直都是稀有资源,还记得我们的祖先们用什么方法来管理这些稀有资源的吗?用战争,我们的先民们为粮食而战,为土地而战;我们当代人类为石油而战,为市场而战,为金钱而战。
那么在Oracle数据库中什么是稀有资源?它们又是如何来管理的呢?如果读者接触过数据库或读过相关的书,应该还有印象,数据库的数据量和输入/输出量都是相当大的,而这些数据一般都存在硬盘(外存)上,因此硬盘为数据库的一类资源。为了方便介绍, 图1-1给出了硬盘的内部结构示意图。

图 1-1
从图1-1能够看出,所有硬盘上数据的访问都是靠硬盘的旋转和磁头的移动来完成的,这种旋转和移动是机械运动。因为在计算机中所有数据的修改操作必须在内存中进行,因此内存也是数据库的一类资源。表1-1给出内存和外存的简单比较以帮助读者理解本书的内容。
表 1-1

内 存
外存(硬盘)
数据访问速度
很快
很慢
存储的数据
临时
永久
价钱
很贵
相当便宜

从表1-1的比较可知,内存的数据访问速度要比外存(硬盘)快得多。这是因为内存的数据访问是电子速度,而硬盘的数据访问主要取决于机械速度。也就是说,如果一个数据库管理系统能够使绝大多数(如90%以上)数据操作在内存中完成,那么这一数据库管理系统的效率将非常高。可是由于内存中的数据在断电或出现系统故障时会消失,因此数据库管理系统还必须保证,所有的数据改动都必须及时写到硬盘上,以保障不会丢失数据;即使数据库崩溃之后,所有提交过的数据都能得到完全恢复。尽管能够经过加大内存来提高数据库管理系统的效率,但在大多数情况下信息系统的开发和维护经费都是有限的。
经过以上的讨论,读者应该意识到,在数据库管理系统中最宝贵的稀有资源是内存。为了高效地使用内存这种稀有资源,同时保证不会丢失任何数据库中的数据,Oracle数据库管理系统引入了一个非常复杂的体系结构。
1.2 Oracle数据库中常见的术语
为了讲解容易,在详细讨论Oracle体系结构之前,先介绍一下相关的名词和术语。在这里只给出实用的解释,并不追求学术上的严谨。
l 进程(process):一段在内存中正在运行的程序。如果没有学过计算机操作系统相关课程,能够把进程想象成能够自动完成某些特定任务的任何东西,如训练有素的狗狗、跑龙套的等。
l 后台进程(background process):进程的一种,在内存中运行时,不占显示,而且它的优先级比前台进程低。能够只有一个前台进程,但能够有多个后台进程。
l 缓冲区(buffer):一段用来临时存储数据的内存区。
l 主机(host):计算机系统的另一个称呼。
l 服务器(server):一台在网络中向其它计算机系统提供一项或多项服务的主机。
l 客户机(client):一台使用由服务器(server)提供服务的计算机系统。
1.3 Oracle数据库管理系统的体系结构
为了能使Oracle数据库管理系统满足商业用户的要求,Oracle引入了如图1-2所示的复杂的体系结构。

图 1-2
以上这个复杂的体系结构主要包括Oracle服务器(server)(而服务器又是由Oracle实例(instance)和Oracle数据库(database)组成),还包括一些其它的关键文件、用户进程和服务器进程等。
Oracle服务器(server)由Oracle实例(instance)和Oracle数据库(database)两大部分组成。它是一个数据库管理系统,提供了一致、开放和多样的信息管理的方法和途径。服务器中的一些结构并不在处理SQL语句时使用,它们是为了改进数据库系统的效率或数据的恢复等而设计的。
1.4 Oracle服务器(server)
Oracle服务器(server)能够有以下3种安装方式。
(1)基于主机方式:在此种配置下,用户直接在安装了数据库的计算机上登录Oracle数据库。
(2)客户端-服务器(client-server)(两层模型)方式:数据库和客户终端分别安装在不同的计算机上,用户经过网络从个人计算机(客户端)上访问数据库。
(3)客户端-应用服务器-服务器(client- application server-server)(三层模型):用户首先从自己的个人计算机登录应用服务器,再经过应用服务器访问真正的数据库。
1.5 Oracle实例(instance)
Oracle实例(instance)是一种访问数据库的机制,它是由内存结构(SGA)和一些后台进程(5个进程)组成的。它的内存结构也称为系统全局区(system global area,SGA)。系统全局区是实例的最基本的部件之一。实例的后台进程中有5个是必须的,即这5个后台进程中的任何一个没有启动,实例将自动关闭。这5个后台进程分别是SMON、PMON、DBWR、LGWR和CKPT。在OCP考题中有时可能会问哪些后台进程是可选的?除了这5个都是可选的。实例一启动就分配系统全局区和启动所需的后台进程。这里应该指出的是,每个实例只能操作一个数据库,而且它不能够操作其它的数据库。可是反过来是不成立的,因为一个数据库能够同时被几个实例操作(在Oracle集群中)。
系统全局区(SGA)中包含了以下几个内存结构:共享池(shared pool)、数据库高速缓冲区(database buffer cache)、重做日志缓冲区(redo log buffer)和其它的一些结构(如锁和统计数据)等。
1.6 Oracle数据库
Oracle数据库是数据的一个集合,Oracle把这些数据作为一个完整的单位来处理。Oracle数据库也叫做物理(外存)结构,它为数据库信息提供了真正的物理存储,它是由以下3类操作系统文件组成的。
(1)控制文件(control files):包含了维护和校验数据库一致性所需的信息。
(2)重做日志文件(redo log files):包含了当系统崩溃后进行恢复所需记录的变化信息。
(3)数据文件(data files):包含了数据库中真正的数据。
1.7 Oracle其它的关键文件
除了以上3类数据库文件之外,Oracle服务还需要其它的一些文件,这些文件不属于数据库。其中包括:
l 初始化参数文件(parameter files):定义了实例的特性,如系统全局区中一些内存结构的大小、DBWR的个数。
l 密码文件(password files):包含了数据库管理员或操作员用户在启动和关闭实例时所需的密码。虽然Oracle数据库提供了相当完善的安全管理机制,可是在Oracle数据库没有开启时如何验证要启动数据库的人是真正的数据库管理员或操作员呢?这就是Oracle引入密码文件的原因。
l 归档重做日志文件(archived redo log files):是重做日志文件的脱机备份。在系统崩溃后进行恢复时可能需要这些文件。
1.8 建立与Oracle实例的连接
Oracle实例(instance)是用Oracle的STARTUP命令启动的(该命令将在后面的章节中详细介绍)。它的启动就意味着SGA的所有内存结构都已生成,所有必须的后台进程都已在内存中运行。那么此时用户又是如何使用Oracle数据库呢?
用户在向Oracle数据库发出SQL命令之前必须与实例(instance)建立连接。用户启动一个工具如SQL*Plus,或运行一个利用Oracle工具开发的应用程序,如用Oracle Forms开发的应用程序时,这个工具或应用程序就被作为一个用户进程来执行。用户进程是不能直接访问数据库的。
在专用连接的情况下(也是默认),当一个用户登录Oracle服务器时(如在SQL*Plus的提示下输入用户名和密码),如果登录成功(即用户名和密码都准确无误),Oracle就在服务器所运行的计算机上创立一个服务器进程。在这种连接下,该服务器进程只能为这个用户进程提供服务。用户进程与服务器进程是一对一的关系。用户进程向服务器进程发请求,服务器进程对数据库进行实际的操作并把所得的结果返回给用户进程。就仿佛一个大富豪想炒股票,但又不懂股票市场的运作,于是她请了一位股票经纪人。这位富豪就相当于用户进程,而股票经纪人就相当于服务器进程,股票市场就相当于Oracle数据库。
一个用户每次登录Oracle服务器,如果成功,该用户就与Oracle服务器建立了连接,而这种连接又叫做会话。一个会话始于用户成功地登录Oracle服务器,终止于用户退出或非正常终止连接。一个数据库用户可能同时有多个会话存在,即用相同的用户名和密码同时登录多次。
1.9 各种不同的连接方式
连接是用户进程与Oracle服务器之间的通信路径。与Oracle服务器(server)的3种安装方式相对应,一个数据库用户可能用以下3种方式之一与Oracle服务器连接。
(1)基于主机方式:此时的用户进程与服务器进程是在同一台计算机的相同的操作系统上的,用户进程与Oracle服务器之间的通信路径是经过操作系统内部进程通信(inter process communication,IPC)机制来建立的。
(2)客户端-服务器(client-server)(两层模型)方式:用户进程与Oracle服务器之间的通信是经过网络协议(如TCP/IP)来完成的。
(3)客户端-应用服务器-服务器(client- application server- server)(三层模型):用户的个人计算机经过网络与应用服务器或网络服务器通信,而这个应用服务器或网络服务器又是经过网络与运行数据库的计算机相连的。例如,用户使用浏览器经过网络运行NT服务器上的应用程序,而NT服务器又从运行在UNIX主机上的Oracle数据库中提取数据。
以上所介绍的连接是用户进程与服务器进程的一对一的连接,也称为专用服务器连接(dedicated server connection)。除了这种连接外,在联机事务处理(online transaction processing,OLTP)系统的配置时还有另外的一种连接,它在Oracle 9i之前的版本中称为多线程(MTS)连接,在Oracle 9i或以后的版本中称为共享服务器(shared server)连接。有关这种连接在Oracle的网络和调优的书籍中介绍。
1.10 服务器进程
当Oracle创立一个服务器进程的同时要为该服务器进程分配一个内存区,这个内存区称为程序全局区(program global area,PGA)。与SGA不同,PGA是一个私有的内存区,是不能共享的,是只属于一个进程的。它随着进程的创立而被分配,随着进程的终止而被回收。在专用服务器进程的配置情况下,程序全局区包括了以下结构:
(1)排序区(sort area):用于处理SQL语句所需的排序。
(2)游标状态区(cursor state):用于指示会话当前所使用的SQL语句的处理状态。
(3)会话信息区(session information):包括了会话的用户权限和优化统计信息。
(4)堆栈区(stack space):包括了其它的会话变量。
如果是共享服务器进程或多线程的配置,以上这些结构除了堆栈区外大部分将存在SGA中。如果有large pool,它们就会被存在large pool,否则它们就会被存在共享池中。
1.11 Oracle执行SQL查询语句的步骤
如果用户在SQL*Plus下输入了如下的查询语句:SELECT * FROM dept;,那么Oracle又是如何来处理这个语句的呢?SQL语句的执行主要由用户进程与服务器进程来完成,其它的一些进程可能要辅助完成这一过程。查询语句与其它的SQL语句有所不同,如果一个查询语句执行成功,它要返回查询的结果。而其它的SQL语句只是返回执行成功或失败的信息。查询语句的处理主要包括以下3个阶段:编译(parse)、执行(execute)和提取数据(fetch)。
l 编译(parse):在进行编译时,服务器进程会将SQL语句的正文放入共享池(shared pool)的库高速缓存(library cache)中并将完成以下处理:
Ø 首先在共享池中搜索是否有相同的SQL语句(正文),如果没有就进行后续的处理。
Ø 检查该SQL语句的语法是否正确。
Ø 经过查看数据字典来检查表和列的定义。
Ø 对所操作的对象加编译锁(parse locks)以便在编译语句期间这些对象的定义不能被改变。
Ø 检查所引用对象的用户权限。
Ø 生成执行该SQL语句所需的优化的执行计划(执行步骤)。
Ø 将SQL语句和执行计划装入共享的SQL区。
以上的每一步操作都是在处理正确时才进行后续的处理。如果不正确,就返回错误。
l 执行(execute):Oracle服务器进程开始执行SQL语句是因为它已获得了执行SQL语句所需的全部资源和信息。
l 提取数据(fetch):Oracle服务器进程选择所需的数据行,并在需要时将其排序,最后将结果返回给用户(进程)。
1.12 共享池(shared pool)
SGA中的共享池(shared pool)是由库高速缓存(library cache)和数据字典高速缓存(data dictionary cache)两部分所组成。服务器进程将SQL(也可能是PL/SQL)语句的正文和编译后的代码(parsed code)以及执行计划都放在共享池(shared pool)的库高速缓存中。在进行编译时,服务器进程首先会在共享池中搜索是否有相同的SQL或PL/SQL语句(正文),如果有就不进行任何后续的编译处理,而是直接使用已存在的编译后的代码和执行计划。
U 提示:
库高速缓存包含了共享SQL区和共享PL/SQL区两部分,它们分别存放SQL和PL/SQL语句以及相关的信息。
要想共享SQL或PL/SQL语句,第一,库高速缓存(library cache)要足够大,因为只有这样要共享的SQL或PL/SQL语句才不会很快地淘汰出内存。第二,SQL或PL/SQL语句要是能共享的通用代码(generic code),因为Oracle是经过比较SQL或PL/SQL语句的正文来决定两个语句是否相同的,只有当两个语句的正文完全相同时Oracle才重用已存在的编译后的代码和执行计划。这里经过以下的实例来进一步解释这一点。读者猜如下的两个SQL语句是否相同?

select * from emp where sal >= 1500; 和select * from emp where sal >= 1501;

答案是不相同的(在Oracle默认的配置下,Oracle 8i和Oracle 9i以及更高的版本能够经过重新设置CURSOR_SHARING参数来修改默认配置,有兴趣的读者可参阅Oracle调优方面的书籍)。
能够经过使用绑定变量的方式来重写以上的SQL语句,如下:

select * from emp where sal >= &v_sal;

这个语句就是能够共享的通用代码,因为变量不是在编译阶段而是在运行阶段赋值的。引入库高速缓存(library cache)的目的是共享SQL或PL/SQL代码。那么Oracle又是怎样有效地管理库高速缓存(library cache)的呢?Oracle是使用一个称为LRU(least recently used)的队列(list)或算法(algorithm)来实现对库高速缓存的管理的。LRU队列的算法大致如下:刚使用的内存块(的地址)放在LRU队列的头上(最前面),当一个服务器进程需要库高速缓存的内存空间而又没有空闲的内存空间时,该进程就从LRU队列的尾部(最后面)获得所需的内存块,这些内存块一旦被使用,它们(的地址)就立即放在LRU队列的最前面。这样那些长时间没使用过的内存块将自然地移到LRU队列的尾部而被最先使用。
从以上的讨论可知,为了能够共享SQL或PL/SQL的代码,库高速缓存要足够大,因为这样那些能够共享的SQL或PL/SQL代码才不会被很快地淘汰出内存。不过Oracle并没有给出直接设置库高速缓存大小的方法,只能经过设置共享池的大小来间接地设置库高速缓存的大小。
介绍完了库高速缓存,接下来将介绍数据字典高速缓存(data dictionary cache)。当Oracle在执行SQL语句时,服务器进程将把数据文件、表、索引、列、用户和其它的数据对象的定义和权限的信息放入数据字典高速缓存。如果在这之后,有进程(用户)需要同样的信息,如表和列的定义,那么所有的这些信息将从数据字典高速缓存中获得。因为以上所说的这些信息都是存在Oracle数据库的数据字典中,这也可能就是该部分内存叫做数据字典高速缓存的原因。
表和列的定义等重用的机会要比SQL语句大,因此为了能达到共享这些信息的目的,数据字典高速缓存应该尽可能设置得大一些。不过与库高速缓存一样,Oracle并没有给出直接设置数据字典高速缓存大小的方法,只能经过设置共享池的大小来间接地设置数据字典高速缓存的大小。在Oracle 9i之前的版本,能够经过修改参数文件中的SHARED_POOL_ SIZE的值来改变共享池的大小,但一定要重新启动Oracle数据库。在Oracle 9i或以后的版本中,也能够使用类似于例1-1的命令来改变共享池的大小:
例1-1
SQL> ALTER SYSTEM SET SHARED_POOL_SIZE = 32M;
系统已更改。

可是所改变共享池的大小受限于SGA_MAX_SIZE参数。这个参数将在以后的章节中详细地介绍。
N 注意:
在本书中采用如下的约定:
l SQL>为SQL*Plus的提示符。
l 没有阴影的内容为要输入的SQL语句或SQL*Plus命令等。如在例1-1中要输入ALTER SYSTEM SET SHARED_POOL_SIZE = 32M;。
l 阴影中的内容为系统显示(输出)的结果。如在例1-1中的”系统已更改。”。
U 提示:
即使把共享池设置得足够大而且所使用的SQL或PL/SQL语句也是能共享的代码,Oracle也并不能一定使用内存(共享池)中的代码。例如当有用户修改了某个对象的定义之后,所有使用这个对象的内存(共享池)中的代码全部被Oracle设置为无效,因此在使用时必须重新编译。
1.13 数据库高速缓冲区(database buffer cache)
---和库高速缓存(libarary cache)不一样
如果用户发出了以下的SQL语句:SELECT * FROM emp,Oracle又是怎样提取数据库中的数据呢?服务器进程将首先在数据库高速缓冲区(database buffer cache)中搜寻所需的数据,如果找到了就直接使用而不进行磁盘操作,如果没找到就将进行磁盘操作把数据文件中的数据读入到数据库高速缓冲区中。
从以上的讨论可知,为了能够共享数据库中的数据,数据库高速缓冲区要足够的大,因为这样那些能够共享的数据才不会被很快地淘汰出内存。Oracle也是使用一个叫做LRU(least recently used)的队列(list)或算法(algorithm)来实现对数据库高速缓冲区的管理。能够使用参数文件中的DB_BLOCK_SIZE和DB_BLOCK_BUFFERS两个参数来设置数据库高速缓冲区的大小。其中DB_BLOCK_SIZE为Oracle数据块(内存缓冲区)的大小,在Oracle数据库中内存和外存的数据块的大小是相同的。DB_BLOCK_BUFFERS为内存缓冲区的个数。数据库高速缓冲区大小为这两个参数的乘积。可是DB_BLOCK_SIZE的值是在创立数据库时设定的,如果要改变该参数的值一般需要重建数据库。因此多数情况下只能经过改变DB_BLOCK_BUFFERS的值来调整数据库高速缓冲区大小。但一定得重新启动Oracle数据库。在Oracle 9i或以后的版本中,Oracle引入了另一个参数DB_CACHE_SIZE,这个参数是一个动态参数,即能够在数据库运行时动态地改变该参数。能够使用类似于 例1-2的命令来改变数据库高速缓冲区的大小:
例1-2
SQL> ALTER SYSTEM SET DB_CACHE_SIZE = 48M;
系统已更改。
1.14 内存缓冲区顾问(v$db_cache_advice)
Oracle 9i或以后的版本还提供了一个称为内存缓冲区顾问(v$db_cache_advice)的工具来帮助获得调整数据库高速缓冲区的统计信息。内存缓冲区顾问一共有3种状态:
(1)ON:该工具打开,为该工具分配内存并进行统计信息的收集。要有一定的内存和CPU开销。
(2)READY:该工具关闭,为该工具分配内存但不进行统计信息的收集,因此没有CPU的开销。
(3)OFF:该工具关闭,不为该工具分配内存也不进行统计信息的收集,因此既没有内存的开销也没有CPU开销。
能够经过修改初始化参数DB_CACHE_ADVICE的值来改变该工具的状态。这一参数是一个动态参数,因此能够使用ALTER SYSTEM命令来修改。例如能够利用类似于例1-3的SQL语句来查看它的状态:
例1-3
SQL> select id, name, block_size, advice_status
2 from v$db_cache_advice;

ID NAME BLOCK_SIZE ADV
---------- -------------------- ---------- ---
3 DEFAULT 4096 ON
3 DEFAULT 4096 ON
3 DEFAULT 4096 ON
3 DEFAULT 4096 ON
3 DEFAULT 4096 ON
…
已选择20行。

此时,例1-3的显示结果表明了内存缓冲区顾问是在开启状态。
U 提示:
显示结果中的…表示省略了一些行的显示。
之后能够使用类似于例1-4的命令将内存缓冲区顾问(v$db_cache_advice)工具关闭:
例1-4
SQL> alter system set db_cache_advice = off;
系统已更改。

这时能够再使用类似于例1-5的SQL语句来查看它的状态:
例1-5
SQL> select id, name, block_size, advice_status
2 from v$db_cache_advice;

ID NAME BLOCK_SIZE ADV
---------- -------------------- ---------- ---
3 DEFAULT 4096 OFF
3 DEFAULT 4096 OFF
3 DEFAULT 4096 OFF
3 DEFAULT 4096 OFF
3 DEFAULT 4096 OFF
…
已选择20行。

此时,例1-5的显示结果表明已成功地关闭了内存缓冲区顾问(详细地介绍该工具的使用已超出了本书的范围,有兴趣的读者可参阅Oracle 9i/10g调优方面的书籍)。
1.15 重做日志缓冲区(redo log buffer)
从理论上来讲,如果数据库不会崩溃,根本没有必要引入重做日志缓冲区(redo log buffer)。引入重做日志缓冲区的主要目的(在Oracle 8i之前的版本中也是惟一的目的)就是数据的恢复。Oracle在使用任何DML或DDL操作改变数据之前都将恢复所需的信息,即在写数据库高速缓冲区之前,先写入重做日志缓冲区。
与执行查询语句有所不同,Oracle在执行DML语句时只有编译(parse)和执行(execute)两个阶段(P15页DQL)。以下是Oracle执行UPDATE语句的步骤:
(1)如果数据和回滚数据不在数据库高速缓冲区中,Oracle服务器进程将把它们从数据文件中读到数据库高速缓冲区中。
(2)Oracle服务器进程在要修改的数据行上加锁(行一级的锁)。
(3)Oracle服务器进程将数据的变化信息和回滚所需的信息都记录在重做日志缓冲 区中。
(4)Oracle服务器进程将回滚所需的原始值和对数据所做的修改都写入数据库高速 缓冲区(database buffer cache)。之后在数据库高速缓冲区中所有的这些数据块都将被标为脏缓冲区,因为此时内外存的数据是不同的(不一致的)。
Oracle处理INSERT或DELETE语句的步骤与处理UPDATE语句的步骤大致相同。
N 注意:
有关回滚数据在本书的后面章节中还要介绍,读者也能够参阅笔者的另一本书<从实践中学习Oracle/SQL>一书12.20节的258～259页。
1.16 大型池(large pool)和Java池(Java pool)
除了以上所介绍的内存结构之外,SGA中还有可能包含large pool和Java pool两个可选的内存结构。
引入large pool的主要目的应该是提高效率。large pool是一个相对比较简单的内存结构,与shared pool不同的是它没有LRU队列。在多线程(MTS)或共享服务器(shared server)连接时,Oracle服务器进程的PGA的大部分区域(也叫UGA)将放入large pool(stack space 除外)。另外在大规模I/O及备份和恢复操作时可能使用该区。能够经过设置参数LARGE_POOL_SIZE的值来配置large pool的大小。该参数也是一个动态参数。
引入Java pool的目的是能够编译Java语言的命令。如果要使用Java语言就必须设置Java pool。Java语言在Oracle数据库中的存储与PL/SQL语言几乎完全相同。能够经过设置参数JAVA_POOL_SIZE的值来配置Java pool的大小。其数字的单位是字节(bytes)。在Oracle 9i中Java pool的默认大小为24MB。
1.17 内存缓冲区大小的设定
在Oracle 9i之前的版本中,只能经过设置初始化参数文件中的一些参数来间接地设置SGA的大小,如DB_BLOCK_BUFFERS、LOG_BUFFER、SHARED_POOL_SIZE等。而且所有的这些参数都是静态的,即当修改完初始化参数文件中这些参数的值之后必须重新启动Oracle数据库。
在Oracle 9i以后的版本中,SGA为动态的。SGA中的内存缓冲区,如数据库高速缓冲区(database buffer cache)和共享池(shared pool)等都能够动态地增加和减少。Oracle是利用所谓的区组(granule)来管理SGA的内存的。区组(granule)就是一片连续的虚拟内存区。区组是Oracle分配和回收内存区的基本单位。
区组的大小取决于所估计的SGA的大小。如果SGA的尺寸小于128MB,区组的大小就是4MB。如果SGA的尺寸大于或等于128MB,区组的大小就为16MB。Oracle数据库一旦启动,SGA中的每个内存缓冲区就会获得所需的区组。SGA中至少包括3个区组:一个是SGA固定区(其中包含了重做日志缓冲区);一个是数据库高速缓冲区;一个是共享池。
Oracle数据库管理员可经过ALTER SYSTEM SET命令来分配和回收区组。但总的内存大小不能超过参数SGA_MAX_SIZE所设定的值。该参数的单位是字节。
动态分配和回收内存的最大好处是在调整内存缓冲区大小时不需要重新启动数据库。这一点对那些24小时运营7天营业的商业数据库是至关重要的。
1.18 内存缓冲区信息的获取
能够使用例1-6的命令来获得参数SGA_MAX_SIZE的值:
例1-6
SQL> show parameter

该命令将显示出参数文件中能够设置的全部参数。另外也能够使用例1-7的命令来获得SGA的相关信息:
例1-7
SQL> show sga

Total System Global Area bytes
Fixed Size    453432 bytes
Variable Size  71303168 bytes
Database Buffers  50331648 bytes
Redo Buffers    667648 bytes

也能够先使用例1-8和例1-9的SQL*Plus命令来格式化显示输出:
例1-8
SQL> col name for a20
例1-9
SQL> col value for a25

之后,利用数据字典v$parameter使用例1-10的SQL查询语句来获得参数SGA_MAX_SIZE的值:
例1-10
SQL> select name, type, value
2   from v$parameter
3   where name = 'sga_max_size';

NAME    TYPE VALUE
-------------------- ---------- ----------
sga_max_size     6

介绍完了SGA的各个部分内存缓冲区之后,下面开始详细地讨论Oracle的主要后台进程。
1.19 重做日志写进程(LGWR)及快速
提交(fast commit)
重做日志写进程(LOG writer,LGWR)负责将重做日志缓冲区的记录顺序地写到重做日志文件中。为了更好地理解LOG writer的操作原理,在这里先介绍一下Oracle提交(commit)语句是如何工作的。
Oracle服务器是使用了一种称为快速提交(fast commit)的技术,该技术既能保证Oracle系统的效率又能保证在系统崩溃的情况下所有提交的数据能够得到恢复。为此Oracle系统引入了系统变化数(system change number,SCN)。无论任何时候只要某个事务(transaction)被提交,Oracle服务器都将产生一个SCN(号码)并将其赋予该事务的所有数据行。在同一个数据库中SCN是单调递增的而且是惟一的。为了避免在进行一致性检验时操作系统时钟可能引发的问题,Oracle服务器将SCN作为Oracle的内部时间戳来保证数据文件中的数据的同步和数据的读一致性。
当在SQL*Plus中发了commit语句之后,Oracle的内部操作步骤如下:
(1)服务器进程将把提交的记录连同所产生的SCN(号码)一起写入重做日志缓冲区中。
(2)重做日志写进程(LGWR)将把重做日志缓冲区中一直到所提交的记录(包括该记录)的所有记录连续地写到重做日志文件中。在此之后,Oracle服务器就能够保证即使在系统崩溃的情况下所有提交的数据也能够得到恢复。
(3)Oracle通知用户(进程)提交已经完成。
(4)服务器进程将修改数据库高速缓冲区中的相关数据的状态并释放资源和打开 锁等。
此时可能这些数据并未被写到数据文件中,这时这些数据缓冲区被标为脏缓冲区,因为相同的数据在内外存中为不同的版本。数据库高速缓冲区中的数据是由DBWR写到数据文件中的。
曾有不少学生问过这样一个问题:”为什么不同时写两个数据文件呢?”Oracle的这种解决方案的最大好处是在保证不丢失数据的同时数据库的效率不会受到很大影响。因为重做日志文件中的记录是以最紧凑的格式存放的,因此它的I/O量要比对数据文件的操作少得多。另外LGWR是顺序地将重做日志缓冲区中的记录写到重做日志文件中的,这样其I/O速度要比将数据块写到数据文件中快得多。
重做日志写进程(LGWR)要在下列情况下将重做日志缓冲区的记录(内存)顺序地写到重做日志文件(外存)中:
l 当某个事务被提交时。
l 当重做日志缓冲区中变化的记录超过一兆字节(1MB)时。
l 当重做日志缓冲区中所存的记录已超过缓冲区容量的1/3。
l 在DBWR将数据库高速缓冲区中修改过的数据块写到数据文件之前。
l 每3秒钟。
因为在进行数据库恢复时需要重做日志数据,因此重做日志写进程(LGWR)只有在重做日志数据写到重做日志文件(磁盘)上时才能确定提交已经完成。在Oracle 8i之前的版本中,重做日志数据的惟一目的和用处就是数据库恢复。Oracle在Oracle 8i的版本中引入了一个叫做重做日志挖掘器(logminer)的工具。该工具能够将重做日志文件或归档重做日志文件中的数据转换成用户能理解的正文信息。在Oracle 8i中,该工具只有命令行操作方式。Oracle 9i加强了此工具的功能并引入了一个称为日志挖掘浏览器(logminer viewer)的图形界面。
1.20 数据库写进程(DBWR/DBWn)
在本章开始时曾介绍过数据库的典型操作就是大规模的输入/输出(I/O)。因此为了提高Oracle系统的效率,一要减少I/O量,这可能是Oracle引入LGWR的原因之一;二要减少I/O次数,这可能是Oracle引入数据库写进程(DBWR/DBWn)的主要原因。
U 提示:
在Oracle的英文书中有些将”数据库写进程”用DBWR表示,有些将它用DBWn表示。这是因为在一个Oracle实例中能够启动多个数据库写进程,特