Oracle体系结构分析
这篇文章主要讲解了“Oracle体系结构分析”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“Oracle体系结构分析”吧!
创新互联建站是一家专注于网站制作、网站建设与策划设计,铁山港网站建设哪家好?创新互联建站做网站,专注于网站建设十余年,网设计领域的专业建站公司;建站业务涵盖:铁山港等地区。铁山港做网站价格咨询:028-86922220
一、什么是Oracle数据库?
众所周知,Oracle DataBase是一款关系型数据库管理系统(不了解何谓关系型数据库的童鞋自行google,baidu),同类的产品还有MySQL,sqlServer等,很多时候,我们会把那个承载我们核心数据的系统笼统地成为数据库服务器,但从严格意义上来讲Oracle DataBase是由两个部分组成:
实例:实例是数据库启动时初始化的一组进程和内存结构
数据库:数据库则指的是用户存储数据的一些物理文件
正因为如此我们一般才会说 关闭和启动实例,加载卸载数据库,就是这个道理。
从实例和数据库的概念上来看,我们能知道,实例暂时的,它不过是一组逻辑划分的内存结构和进程结构,它会随着数据库的关闭而消失,而数据库它其实就是一堆物理文件(控制文件,数据文件,日志文件等等),它是永久存在的(除非磁盘损坏)。数据库和实例通常是一对一的,这种结构我们成为单实例体系结构;当然还有一些复杂的分布式的结构,一个数据库可以对多个实例,像Oracle的RAC(有兴趣的童鞋可以了解下)。
二、交互流程
下面是从网上找的一张图,描述了单实例体系结构大致的交互流程
1.用户和用户进程交互
用户进程可以是一般的客户端软件,像Oracle的sqlplus,sql developer,或者是一些驱动程序等等都属于用户进程。
2.用户进程和服务器进程交互
服务器进程有时会称为前台进程,当然是相对于后台进程(后面会提到的数据库写入器,日志写入器等)来说的,服务器进程的主要作用就是处理连接到当前实例的用户进程的请求,对客户端发来的sql进行执行并返回执行结果。在专有服务器结构中,用户进程和服务器进程是一对一的,也就是说,当监听程序监听到客户端来了一个请求,会为其分配一个对应的服务器进程。还有一种结构为共享服务器,这种结构就不是一个用户进程对应一个服务器进程了,会通过调度程序进行协调处理,关于共享服务器连接,本文就不在赘述了。
3.服务器进程和实例进程交互
4.实例和数据库进程交互
上面描述了一些我们在进行数据库连接操作的时候,大致的交互流程是什么样的。下面,我们就来看看Oracle 的实例内存结构
三、实例内存结构和进程结构
(由于内存结构和进程结构关系较紧密,进程会作用到对应的内存区域,比如数据库写入器作用到数据库缓冲区缓存中,日志写入器会作用到日志缓冲区,所以内存结构和进程结构会相互配合地进行描述)
oracle实例内存结构由两部分组成SGA(系统全局区)和PGA(用户全局区)组成,SGA是一块共享的内存区域,也是最大的一块内存区域;PGA则是用户会话专有的内存区域,每个会话在服务器端都有一块专有的内存区域就是PGA。本文主要对SGA进行分析描述。SGA组成如下
数据库缓冲区缓存&数据库写入器
缓冲区缓存 是Oracle用来执行sql 的工作区域,在更新数据时,用户会话不会直接去更新磁盘上的数据,想想,如果允许这么做,那么频繁的磁盘IO对于系统性能的影响是毁灭性的。所以,实际的处理流程是这样的:
1
SQL>alter system checkpoint; |
检查点可强制DBWn写入脏缓冲区,当数据库崩溃后,由于大量脏缓冲区未写入数据文件,在重新启动时,需要由SMON进行实例恢复,实例恢复需要提取和应用重做日志记录,提取的位置就是从上次检查点发起的位置开始的(检查点之前的数据已经被强制写入到数据文件中去了),这个位置称为RBA(redo byte address),CKPT会不断将这个位置更新到控制文件中去(以确定实例恢复需要从哪儿开始提取日志记录)。
MMON(Manageability Monitor)
数据库的自我监视和自我调整的支持进程。实例在运行中,会收集大量有关实例活动和性能的统计数据,这些数据会收集到SGA中,MMON定期从SGA中捕获这些统计数据,并将其写入到数据字典中,便于后续对这些快照进行分析。(默认情况,MMON每隔一个小时收集一次快照)
ARCn(Archiver)
归档进程,这个进程是可选的,如果数据库配置为归档模式,这个进程就是必须的。所谓归档,就是将重做日志文件永久保存(生产库一般都会配置为归档模式)到归档日志文件中。归档日志文件和重做日志文件作用是一样的,只不过重做日志文件会不短被重写,而归档日志文件则保留了关于数据更改的完整的历史记录。
至此,Oracle基础的内存结构和进程结构我们已大概了解,来看下完成的进程和内存的交互情况,可以根据前面的理解将整个交互流程串联一下。
四、Oracle存储结构
针对Oracle存储结构将分别从物理存储结构和逻辑存储结构两个维度来进行阐述。
物理存储结构
所谓外部文件,意味着这些文件从严格意义上来讲并不属于Oracle数据库的一部分。
控制文件:
控制文件虽小,但作用重大,它包含指向数据库其余部分的指针(包括重做日志文件,数据文件,归档日志文件等的位置),存储重要的序列号和时间戳,存储RMAN备份的详细信息。控制文件一旦受损,那实例会立马终止,一般对数据文件的保护采用多路复用机制,就是冗余多份在不同物理位置。
重做日志文件
重做日志文件的作用在讲解内存和进程结构的时候有提到过,重做日志按时间顺序存储应用于数据库的一连串的变更向量(包含联机重做日志文件和归档日志文件)。由SMON在数据库启动时自动执行的实例恢复 和 磁盘损坏所要求的提取备份恢复都会应用到重做日志进行相应的数据恢复
重做日志文件也建议进行多路复用,一个数据库至少要有两组重做日志文件。一组供LGWR进行写入,日志文件是固定大小,业务高峰期会很快写满,写满之后会切换到第二组上,在配置为归档模式的数据库中,这时由归档进程(ARCn)开始将第一组的内容进行归档备份,如此循环地进行写入和归档。需要注意的是,在归档进程还未对当前组的日志归档完毕前,是不允许LGWR对其进行重写的。
数据文件
数据文件存储着实际的数据,DBWn会将数据库缓冲区中的内容写入到这类文件中去,数据文件的大小和数量是不受限制的。Oracle从10g开始,创建一个数据库至少需要两个数据文件,一个用于SYSTEM表空间,该表空间用来存储数据字典;一个用于SYSAUX表空间,这个表空间用来存储一些数据字典的辅助数据。
数据文件由一个个的Oracle块组成,这是Oracle的I/O基础单元,与操作系统块是不同的概念,Oracle块要比操作系统块大,这当然有处于性能的一些考虑,但我们考虑这样一种情况,当用户使用操作系统命令进行数据文件的备份的时候(假设1个Oracle块=8个操作系统块),已经复制了4个操作系统块,然后CPU被DBWn抢占了,DBWn又重新对这个Oracle块进行了更新,这时,当复制命令又得到了CPU时间去复制剩余的4个块的时候,就造成了整个Oracle块的数据不一致,所以,这也是在执行这种备份(用户自行备份)的时候,需要做一些额外处理,比如将表空间置为备份模式的原因。当然,使用RMAN是不存在这样的问题的,RMAN的备份机制是肯定可以得到数据一致的块的。(这块内容作了解即可)
对于数据文件的保护,一般可进行定期备份,或者使用RAID也可以。
实例参数文件
这个文件存储了数据库所需的一些参数设置,比如各个内存区域的大小,可允许的最大进程数,最大会话数,控制文件的位置,数据库的名称等等,参数文件也是实例启动时首先要加载的文件。
口令文件
一般称为外部口令文件。一般的用户名和口令是存放在数据字典中,不会存放在这个文件中。在一些特殊场景下,比如实例还未启动,这时,我可能需要以管理员的身份登入系统去执行一些恢复或者启动操作,然而此时,数据字典由于实例还没启动是不存在的,这时就需要外部口令文件进行用户身份的验证。
归档日志文件
ARCn将联机重做日志文件会备份归档到这类文件中去,归档日志文件保留了数据更改的完整历史信息。
逻辑存储结构
Oracle将其物理结构从逻辑存储结构中抽象出来,物理机构是系统管理员能看到的,逻辑结构则是用户所能感知到的。比较典型的逻辑结构就是 "段"和"表空间"。
段:
段就是包含所有数据的逻辑结构,比较典型的段就是"表",称为表段,还有索引段,撤销段等等。
表空间
表空间从逻辑上是多个段的结合,在物理上是多个数据文件的集合,相当于在段和数据文件的对应中加入了一个中间层来解决这种多对多的关系。
在早期的一些数据库设计中,段和数据文件是一对一的关系,一个段一个数据文件,这种设计有很多弊端,首先,段的数量是不固定的,有可能一个系统中上千张表,那就得需要上千个数据文件,系统管理员要管理这么多文件肯定会抓狂的;还有一种情况就是某些历史表可能特别大,大到底层系统对单个文件的限制,用一个数据文件去承载的话肯定是不行的。表空间则完美解决了这样的问题。
还有一些逻辑结构如区间和Oracle块(Oracle块前面有提到过,区间则为块的集合),下面通过一张图对Oracle的存储结构进行整体的宏观的认识,进一步加深些理解
感谢各位的阅读,以上就是“Oracle体系结构分析”的内容了,经过本文的学习后,相信大家对Oracle体系结构分析这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是创新互联,小编将为大家推送更多相关知识点的文章,欢迎关注!
名称栏目:Oracle体系结构分析
标题网址:http://scyanting.com/article/jhgegg.html