数据库之【体系结构篇】

今天我们来学习体系结构
 
我先来介绍本节的内容：
 
⊙ 描述Oracle 服务器的体系结构及其主要组件
⊙ 描述什么是ORACLE SERVER
⊙ 描述什么是ORACLE 实例
⊙ 描述ORACLE 的连接方法
⊙ ORACLE 的DML 执行流程
⊙ ORACLE 的RAC 和FAILOVER,负载均衡的概念

图一：

这张图是体系结构的图片

大家都见过吗
我们学习ORACLE 知识全部都是围绕这张图来逐步深入的。
我们现在就来分析这张图，ORACLE 主要体系结构包括:
⊙ 左上部分是用户进程，服务器进程
图二：

我们要访问数据库，那数据库的角色是（服务），而访问数据库的角色是(用户）
用户进程是提出请求的进程，所以用户段的进程是用户进程；来服务用户的服务端的进程叫服务器进程。
大家理解用户进程了吧
用户进程就象你的浏览器,IE或者sqlplus
大家想想还有什么客户端进程？
sqlplus是ORACLE的访问工具,plsqldev也是用户进程,客户端发出请求的进程是用户进程

好，我们来看图片右上部分
⊙ 右上部分是实例

实例部分是ORACLE 最难最复杂的地方，我们体系结构会深入学习里面的结构。
那我们真正的数据存放在哪儿呢？
正常的数据是存放在数据文件中，是datafile
也就是操作系统文件中
数据也可以存储在我们的存储
也可以本机的磁盘上
如果RAC，则需要配置共享存储
10G后，推出了ASM
ASM是什么意思？ Automatic Storage Manageme ，ASM称为自动存储管理
所以数据是存储在存储介质上
并以文件的形式保存，或者以裸设备形式保存，也就是文件系统或裸设备
我们将这些文件或设备理解成库文件，ASM是结合了裸设备和文件系统的优点
裸设备不好操作，ASM却方便维护，而且ASM有裸设备的特性

那我们来看数据库部分

裸设备什么特性
答：裸设备是不经过文件系统的
裸设备没有文件系统缓存
直接读写

我们来看上图
上图就是数据库的库文件部分
所以大家应该知道，ORACLE 数据库，ORACLE 实例，ORACLE 软件是一码事吗？
不是一码事
ORACLE数据库才是存放数据的地方，可能是磁盘柜、也可能是存储、也可能是本地磁盘；
而ORACLE实例主要是存放中间数据的内存
比如我们BUFFER CACHE
属于ORACLE实例
而只有安装了ORACLE软件，ORACLE实例和ORACLE数据库才能运行,ORACLE 就是由这3大组件组成

接下来会用一些生活化的故事来了解ORACLE 机制，了解ORACLE 为什么设计出这样一张图。
大家说ORACLE 数据库是用来做什么的？
存储和管理数据吧 ,但是没说出问题本质
数据库实例是提供数据服务的
比如我们在线交易系统，比机票销售系统，我们把这种系统叫OLTP，在线事务处理的服务。
还有的是做报表分析的，我们把这种系统叫OLAP，在线分析处理系统的服务。
不管是OLAP 还是OLTP，他们最终提供的都是服务 ,所以，实例的本质是"服务"

接下来，我们来学习第2个课题
那就是什么是ORACLE服务
我们现在各行各业都在抓服务，大家首先想到的是哪些服务行业？
 
电信、银行、保险、餐饮、娱乐服务.....
我们都有个切身体会，那就是有了好的服务，顾客才会选择它的产品。
比如我们要买房，还要看物业管理的水平

我们现在IT 界非常流行一个SOA（面向服务的体系结构）的概念
ORACLE 也同样提供了一个服务，它提供了数据存储和业务支持服务
 
那我们称ORACLE 的服务叫什么?
ORACLE的服务就叫ORACLE SERVICES

大家在控制面板的服务下看到了ORACLE SERVICES了吗
用过WINDOWS的人都知道
有个控制面板
控制面板里有个服务图标
我们WINDOWS的一些应用都是以服务的方式来实现的
 
我们可以看到各种ORACLE的services
linux也有服务
我们可以设置ORACLE启动和关闭的服务
init.d
LINUX下的服务要先建立的
比如service network start
那么我们可以把网络服务启动
service ftp start
那么可以把ftp服务启动
同样，我们可以设置ORACLE的启动和关闭服务
如果你安装了ORACLE数据库，并创建了ORACLE实例，还安装了ORACLE软件
ORACLE实例提供了服务
LISTENER也提供了服务
⊙ 一个ORACLE服务提供了开放的完整性的信息管理系统。
好，我们来看下服务概念的定义
PGA不是ORACLE软件
PGA也不属于实例
SGA才属于实例

⊙ ORACLE服务由一个实例和一个数据库组成
我们用一个生活中的例子来理解ORACLE服务

大家都去过图书馆吧?
图书馆存放的数据就是书
这书可以被学生借来看，或者被学生买来看，也可能是被采购员从外地采购来
图书馆是不是提供一个图书买卖和借阅的数据库系统？
但是我们知道大型图书馆一个城市就一个，学生们要想买书借书必须跑老远到图书馆去
 
这样的服务是不是不够周到便利
图书馆也可以卖书啊
大家说能不能提供更便捷的服务？
大家动下脑子
我们现在购物都不太喜欢去实体店了
可以开淘宝店吧
那精明的商家会怎么解决这个问题?
ORACLE想出了一种方法
精明的商家都会在各自的街道开有分店
方便客人买书
比如我们所有的书籍都能在上海图书馆能买到
但是我们不用老远跑到上海图书馆去买，我可以在自己行政区的图书馆去买，比如静安区静安书城店
那么静安区的顾客会去哪儿买书？
那么静安区的顾客就去静安区静安书城店提供的服务处买书
我们说提高服务质量，才有效益
这样服务是否更到位了
我们看看上海图书馆
上海图书馆大家去过吗
那静安店就是上海图书馆的分店
 
在ORACLE中就不叫分店
取了一个非常好听的名字

英文叫“instance”
中文名叫"实例"
静安书城分店的服务是上海图书馆实例化出来的
总店就叫数据库，是我们的数据文件
分店是我们的实例，是我们的中间环节的内存和进程
起用实例就是为了提供更好的服务
 
静安书城分店的书从图书馆进
为什么有实例就能更好的服务呢？
如果你要买一本书，那如果静安区的学生要买的书在静安书城店如果有货，那就会马上买到
是不是比去上海图书馆买更便利
因为学生离静安书城店可比在黄浦区的上海图书馆近。
那如果静安书店没有我要的书
静安书店缺货了，该怎么办？
从哪儿进货？
那就需要去上海图书馆去进货。
那就相当于，如果实例里没数据，就得去数据库进货
这叫物理读
如果实例有的数据，我们读出来，叫逻辑读
逻辑读显然比物理读块
因为实例的读是逻辑读
数据库库文件的读是物理读
大家说磁盘速度快，还是内存快？？
逻辑读就是内存读
所以，我们设置了实例，利用了内存来服务用户，就是为了方便为用户提供服务
而且，大家要注意，我们计算机中数据最终是在内存中执行的
为了更好的管理实例的内存，以及跟库文件的交互，需要有实例的进程来管理

所以实例光有数据不行，还得有管理员
 
这样才能组成一个完整的实例
懂了吗
所以大家后面会学习到实例其实就是内存+后台进程组成
那书的买卖和借阅就好比我们ORACLE的什么操作?
书的买卖和借阅就好比DELETE,INSERT,SELECT操作
DELETE,INSERT,SELECT,UPDATE统称为DML
我们叫数据维护语音

那静安书城店会有各个岗位的人负责进货、销售、库存管理等工作，
如何快速的进货也需要这个采购员采用不同的规则。
在进入下一阶段内容前，我先来给大家提个问题
我们前面有个静安图书分店
他是上海图书馆实例化的
是便于上海市静安区的群众去买书
那假设是松江地区的人
是不是要跑老远过来买书
又或是黄埔区的群众，该去哪儿买书呢
大家想想....
等会会讨论这个问题
就会牵扯出ORACLE非常重要的一个概念
 

我们先进入下一节内容
ORACLE实例如何来处理我们的SQL任务的

那静安书城店会有各个岗位的人负责进货、销售、库存管理等工作，
如何快速的进货也需要这个采购员采用不同的规则。
这个规则在我们ORACLE中叫什么？
这个规则有两种，叫RBO或CBO
听说过吗
进货的人，要怎么去上海图书馆
是不是有很多条路
走大路，走小路，做地铁。。。。
该走哪条路更节约时间
你要出发前是不是要评估下时间，哪种路线最节约时间
 
而且也节约成本
是不是要先评估？
错了哦
飞碟的成本最高
你既要看速度，还要看成本的呀
比如做地铁
或者骑自行车
或者开宝马
究竟选择什么线路，什么工具呢
需要去评估，评估完后，选择总成本最低的线路走
在ORACLE中，这个规则叫RBO和CBO
RBO,是基于规则优化
基于规则的评估的意思是哪种规则成本低是规定好的
比如宝马就是比自行车快
比如索引就比表块（其实不然）
那宝马就一定比自行车快吗？
堵车情况
去北京估计宝马走二环要开2个小时
所以RBO不太准确
需要CBO去分析现场的一些统计数据
CBO，就是基于成本的优化器
通常，我们计算成本是按IO的
也就是通常我们计算路线的成本是看公里数
路越远，成本越高
但是，这往往评估出来不准
所以CBO在10G后，默认会是IO+CPU成本模型
CPU通常是计算的成本
比如，我们同样的排序量
IO是一样
但是我们设置不同大小的排序区
那么排序中用CPU来计算的成本是不一样的

通常排序区越大，CPU比较次数越多
CPU成本越高
排序区越小，CPU比较的次数越少，成本越低
所以，排序并不是内存给的越多越好，在相同的IO排序量下，排序内存越好，可能性能越好
sort_area_size
知道这个参数吧
排序并不是内存给的越多越好，在相同的IO排序量下，排序内存越少，可能性能越好
所以，我们的成本运算模式可以有两类
o IO模型
o IO+CPU模型
懂了吗
深入的问题，我们课后讨论
我们看到上海图书馆和静安书城店都是为学生服务的
这个服务就是SERVER（服务）
如果这个服务是用ORACLE来处理，就是ORACLE SERVER
我们这里看到上海图书馆就是我们的DATABASE库文件
静安书城店是我们ORACLE的INSTANCE
那我们的ORACLE SERVER的概念是:
一个ORACLE SERVER就是一个DATABASE库文件加上一个INSTANCE
也就是上海图书馆的静安书城店提供的就是一个ORACLE SERVER。
这个问题你得好好看前面的内容
 
是我们的磁盘上的数据文件
怎么跟实例扯上了
你们数据库的数据难道不是INSERT进去的


现在我们重点来介绍ORACLE实例
我们现在明白ORACLE INSTANCE是一个数据库库文件进行实例化提供的服务，而它也是我们体系结构的核心。

那实例它由什么组成呢？
看到图了吗
实例=内存+后台进程
上面红框是内存
蓝框的是后台进程
看明白了吧
注意是后台进程，不是前台进程
知道什么是后台进程？什么是前台进程吗？

就好比男孩子追女孩子
男孩子是前台进程
要去追的时候就触发了追的进程
但是女孩子是守株待兔的
后台进程一直是等待别人追的状态
所以女孩子是可以理解成后台守护进程
比如我们在LINUX想让一个脚本后台执行
该怎么写？
加上nohup
加&也是对的
理解前台进程和后台进程的区别了吧
后台进程会定期触发
比如我们最著名的SMON后台进程，每3秒唤醒一次
LGWR，每3秒唤醒一次

进程介绍完，我们进入下一节
介绍内存
我们先休息下
后面我们来介绍内存结构
以及多实例的RAC，负载均衡,FAILOVER
我们休息5分钟吧
 
Жい掌&心ウ(598529320) 21:03:43
能不能先讲多实例的RAC，负载均衡,FAILOVER
下节课就讲这
需要设置参数的
优化模型
show parameter mode

接下来，我们先来分析实例的内存部分
我们先来分析实例的内存部分
大家看过变盒子的魔术吗？

盒子里打开，里面还是盒子
一层一层打开，里面越来越多的小盒子
 
ORACLE实例的内存结构就是这
这里主要讨论的是实例中的内存，那就是SGA
我先介绍下实例的特征
⊙ 一个实例只能访问一个数据库
数据库就好比总公司，比如上海图书馆
实例就好比分公司，比如静安图书分店
那如果分店有多个总公司，那分店获得的收益归谁？
那就乱套了
所以，一个实例只能属于一个数据库
一个分店某一个时刻只能由一家总公司
理解了吗
一个实例在某个时刻不能同属于多个数据库
一个分店某个时刻不能同属于多个图书馆
注意：我这里指的是同一时刻
那如果在不同时间段是否就可以？

比如静安书店2011年是上海图书馆的实例化
但是静安书店在2012年被SMG收购了

可以吧
在2012，静安书店属于SMG的实例化出来的
同样，一个实例，在某个时间段可以是第1个数据库，在另一个时间段，可以是第2个数据库
是否可以？
你在服务完一个数据库后，也完全可以服务另一个数据库
如果你2011年跟第1个老公结婚，2012年可以跟第2个老公结婚
重婚罪
所以你要跟第2个老公结婚，得先离婚
所以，实例跟第1个数据块解约后才可以第2个数据块的实例
所以，实例跟第1个数据库解约后才可以第2个数据库的实例

那实例和数据库如何解约，如何续约？
你把书店关门就算节约了？
你把书店关门就算解约了？

这里，我们通过一个文件来把实例和数据库关联起来
大家猜是什么文件？
是初始化文件和控制文件

实例和数据库是通过初始化参数和控制文件解约，和续约
懂了吧
我们数据库和实例是通过初始化文件和控制文件关联起来的
实例启动时，先读PFILE，然后读控制文件
如果实例先属于第1个数据库
那么先NOMOUNT 第1个数据库的PFILE（SPFILE）
然后MOUNT第1个数据库的控制文件
这样实例跟第1个数据库关联起来了
如果此时，该实例要跟第1个数据库解约，跟第2个数据库相关联，怎么办？

你关闭实例，NOMOUNT 第2个数据库的PFILE（SPFILE）
然后MOUNT第2个数据库的控制文件
懂了吗

那我们继续下一个知识点
那就是RAC和负载均衡，故障切换
那我们前面理解了静安书城店实例化一个上海图书馆，那是不是意味着我可以再开一个分店？
我们可以为上海图书馆开新的分店
如黄浦区黄浦书城店，录属于上海图书馆
这样，黄浦区的顾客就可以去黄浦书城店买书
ORACLE确实也能实现这样的功能
也就是一个数据库有多个实例化的实例
这就是我们RAC的功能
理解RAC了吧
有人问，RAC这么干有什么好处呢？
一个上海图书馆，开了多家分店，会有什么好处？
大家想想
我来分析下，大家看对不对
首先：
如果静安书店关门，我们是不是还可以去黄浦分店买书？
那顾客迁移到黄浦分店买书
我们叫故障迁移
英文叫FAILOVER
当某个实例故障了，用户可以切换到好的实例上
那RAC除了故障迁移的功能，还有什么好处呢?0
其次，可以提供更多的用户
我们RAC，会有更多的CPU，更多的硬件来支持
但是这不是RAC的初衷
RAC还有个重要的目的
那就是负载均衡
如果两个分店都没发生故障

两个店都正常营业，顾客是不是可以分流？
当然可以分流
 
顾客可以分流，那负载是不是减轻？
负载可以在两个节点间均衡
 
我们叫负载均衡
英文叫load balanced
大家听说过吧
有人用过F5吗
F5就是著名的负载均衡设备
那黄浦书城店和静安书城店两个实例是不是属于同一个服务?

他们是两个不同的服务
上海图书馆和黄浦书城店组合是第二个ORACLE服务
每个店和上海图书馆组合提供一个ORACLE服务
两个书城店关联同一个图书馆对外提供服
由于提供了2个服务,都可以买书，那我们就可以实现高可用性
也就是我可以选择静安店,也可以选择黄浦店
甚至实现真正的高可用性
高可用性简称HA
那什么是高可用性？
没人知道？
高可用性是就好比我的电脑有2个网卡，如果一个网卡坏了，另一个网卡仍然正常工作，不影响我们正常业务
ORACLE把真正的高可用性叫什么？
 
大家读一下real application cluster
简称RAC
这是我们现在广泛应用的ORACLE集群技术
通常一个数据库，有多个实例来服务
多个实例提供的服务组成一个RAC
比如有两个实例RAC1和RAC2
我们可以给两个实例各取一个服务名
比如RAC_svr1，RAC_srv2
我们可以用listener查看注册服务的情况
lsnrctl service
查看注册服务的情况
所以说，每个实例可以提供1个服务，甚至多个服务
实例的服务名由参数service_name来决定
比如实例LAOFANGKUAI，我可以提供两个服务
参数
service_name='www.laofangkuai.com','www.xiaofangkuai.com'
这里一个实例有几个服务？
是2个服务
两个分别是
www.laofangkuai.com
www.xiaofangkuai.com
一个实例可以提供1或者n个服务
一个数据库又可以有1个或者n个实例组成
RAC叫真正的应用集群


为什么叫"真正"的应用集群?
其实我觉得"真正"的意义又是ORACLE的一个嚼头
 
但是RAC确实跟一般的应用集群是不同的

比如一般的HA，像我们常用的HACMP
有用过的吗
是IBM的产品
它的高可用性跟RAC比有什么区别呢？
比如HACMP，我们可以配置IP，卷组等进行漂移
也就是一个节点损坏后，他的服务IP会漂移到能正常工作的节点
这个能正常工作的节点原先是休眠的
一旦一个节点损坏，会触发资源的飘移
比如A节点和B节点
A原来是活动的，B是休眠的
A的服务IP是192.168.1.1
但RAC两个节点之前都是活动的
但是A节点突然损坏，用户原来是连在192.168.1.1，而192.168.1.1是在A节点的
如果此时，能将IP 192.168.1.1漂移到B节点
然后激活B节点
那用户的业务是不是连到B节点了
这就是HACMP这类产品的高可用性
休眠的节点接管了故障节点的飘移资源
懂了吗
active-passive  跟active - active两个模式
对，像HACMP的，是active-passive
接管的资源可以多种
比如服务IP资源
用户原来连接到的IP是172.128.1.5
也可以接管卷组
等等资源
但是注意：他们接管是需要一些时间的
因为原来节点是休眠的
所以，ORACLE认为他们不叫真正的HA
认为RAC是真正的HA
RAC是active - active模式
RAC的每个节点都可以是活动的
节点损坏时，可以进行透明的切换到完好节点的实例
但是RAC切换也需要消耗一定的时间
大家明白了吗
我们只是普及教育，还没法深入细节
 
老方块培训(44793227) 21:45:41

我们刚才讲了HACMP和RAC关于故障的处理
RAC的故障处理，我们称为FAILOVER，故障迁移
HACMP，通常是资源接管
那RAC的负载均衡有什么特色呢？
下一个知识点是RAC的负载均衡
我来问大家一个问题
如果静安店有6个女生在排队
黄浦店有4个男生在排队
我们新的顾客会选择去哪个书店？
 
如果按人头算，应该选择4个男生的黄浦店吧
对于RAC,两个节点都在本地的，距离没有什么影响

如果按ORACLE实例的连接数来判断负载均衡的话，应该选择黄浦店
但是这种以连接数作为负载均衡的标准也不是完全准确的
我再来举个例子
如果实例提供的是厕所服务
黄浦店的厕所有6个男生在排队
静安店有4个女生在排队
假设是男女共用厕所
大家会去选择哪儿排队、
我会选择去黄浦店排队
男的速度快，负载低
而不是按连接数来判断负载的
是按真正的负载来计算负载均衡
所以，负载均衡有多个标准
ORACLE会提供多种负载均衡的技术
我刚才讲的是实例（服务端）负载均衡
LISTENER知道黄浦店和静安店的排队人数，性别情况，效率情况
通过LISTENER，就能实现实例（服务端）负载均衡
当然服务端负载均衡，你可以设置只看连接数
也可以设置基于真正负载的负载均衡
这些配置将在我们高中阶段介绍
当然，我们也可以设置客户端负载均衡
我们知道，通常每个实例所在的服务器都有个LISTENER
 
比如有黄浦店LISTENER
还有静安店LISTENER
我们前面通过LISTENER来判断该去黄埔店实例负载高还是静安店负载高
比如黄浦LISTENER中注册了两个实例的负载信息
黄浦店的厕所有6个男生在排队
静安店有4个女生在排队
那么基于服务端负载均衡能由黄浦LISTENER来判断，选择黄浦店的厕所
另外还有个静安的LISTENER
这两个LISTENER本身也有负载吧
我们客户端申请时，先连接到的是LISTENER，而不是实例
所以，除了实例有负载均衡，LISTENER本身也有负载均衡
LISTENER负载均衡，我们称为客户端负载均衡
如果静安的LISTENER有10个客户请求
黄埔的LISTENER有12个客户请求

那么第23位顾客要去申请LISTENER时，会选择哪个LISTENER
会选择静安的LISTENER
选择完静安的LISTENER后，再去做服务端负载均衡
好了，我们今天对体系结构做的一个很粗的介绍
希望大家对整个ORACLE架构有更深入的理解
今天的课就到这里
大家有疑问可以问
 


RAC 相同的用户名和密码不同实例能登上吗
RAC 相同的用户名和密码不同实例能登上吗

答：SYSDBA身份的密码是可以的
因为RAC每个实例都有自己的口令文件
比如第1个实例的SYS密码可以是LFK
第2个实例的SYS密码可以是XFK