oracle 数据库体系结构
- - Oracle - 数据库 - ITeye博客 任何硬件平台或操作系统下的ORACLE体系结构都是相同的，包括如下四个方面：. 数据文件，日志文件，控制文件，参数文件. 表空间、段、区间、数据块. 共享池，数据缓冲区，日志缓冲区，PGA. 用户进程、服务器进程、后台进程.
oracle 数据库体系结构
标签：
oracle
数据库
体系结构
| 发表时间：2014-05-10 22:22 | 作者：sanmao6139
出处：http://www.iteye.com
任何硬件平台或操作系统下的ORACLE体系结构都是相同的，包括如下四个方面：
物理结构
数据文件，日志文件，控制文件，参数文件。
逻辑结构
表空间、段、区间、数据块。
内存结构
共享池，数据缓冲区，日志缓冲区，PGA。
进程
用户进程、服务器进程、后台进程。
SGA是共享内存区，PGA是私有内存区，用户对数据库发起的无论查询还是更新的任何操作，都是PGA预先处理，然后接下来才进入实例区域，
由SGA和系列后台进程共同完成用户发起的请求。
PGA的作用主要是三点
保存用户的连接信息，如会话属性，绑定变量等；
保存用户权限等重要信息；
做部分排序操作，如果放不下，就到临时表中完成，就是在磁盘中完成排序。
SGA
library cache
最主要的功能就是存放用户提交的SQL语句及相关的解析树（解析树也就是对SQL语句中所涉及的所有对象的展现）、执行计划、用户提交的PL/SQL程序块（包括匿名程序块、存储过程、包、函数等）以及它们转换后能够被Oracle执行的代码等。
也存放了很多的数据库对象的信息，包括表、索引等。有关这些数据库对象的信息都是从dictionary cache中获得的。如果用户对library cache中的对象信息进行了修改，比如为表添加了一个列等，则这些修改会返回到dictionary cache中。
软解析实验
alter system flush shared_pool; --- 禁止在公司测试环境使用
select owner,name,type,kept,sharable_mem,pins,locks,LOADS from v$db_object_cache where name like '%dba_data_files%'
SQL> select * from dba_data_files t where t.file_id=2;
已用时间: 00: 00: 00.04
执行计划
----------------------------------------------------------
Plan hash value: 1869944940
------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 812 | 4 (0)| 00:00:01 |
| 1 | VIEW | DBA_DATA_FILES | 2 | 812 | 4 (0)| 00:00:01 |
| 2 | UNION-ALL | | | | | |
| 3 | NESTED LOOPS | | 1 | 395 | 2 (0)| 00:00:01 |
| 4 | MERGE JOIN CARTESIAN | | 1 | 380 | 1 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 70 | 1 (0)| 00:00:01 |
|* 6 | TABLE ACCESS BY INDEX ROWID | FILE$ | 1 | 31 | 1 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | I_FILE1 | 1 | | 0 (0)| 00:00:01 |
|* 8 | FIXED TABLE FIXED INDEX | X$KCCFE (ind:1) | 1 | 39 | 0 (0)| 00:00:01 |
| 9 | BUFFER SORT | | 1 | 310 | 1 (0)| 00:00:01 |
|* 10 | FIXED TABLE FULL | X$KCCFN | 1 | 310 | 0 (0)| 00:00:01 |
| 11 | TABLE ACCESS CLUSTER | TS$ | 1 | 15 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 471 | 2 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 1 | 456 | 1 (0)| 00:00:01 |
| 15 | MERGE JOIN CARTESIAN | | 1 | 365 | 1 (0)| 00:00:01 |
| 16 | NESTED LOOPS | | 1 | 55 | 1 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID| FILE$ | 1 | 16 | 1 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | I_FILE1 | 1 | | 0 (0)| 00:00:01 |
|* 19 | FIXED TABLE FIXED INDEX | X$KCCFE (ind:1) | 1 | 39 | 0 (0)| 00:00:01 |
| 20 | BUFFER SORT | | 1 | 310 | 1 (0)| 00:00:01 |
|* 21 | FIXED TABLE FULL | X$KCCFN | 1 | 310 | 0 (0)| 00:00:01 |
|* 22 | FIXED TABLE FIXED INDEX | X$KTFBHC (ind:1) | 1 | 91 | 0 (0)| 00:00:01 |
| 23 | TABLE ACCESS CLUSTER | TS$ | 1 | 15 | 1 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - filter("F"."SPARE1" IS NULL)
7 - access("F"."FILE#"=2)
8 - filter("FE"."FENUM"=2)
10 - filter("FNNAM" IS NOT NULL AND "FNFNO"=2 AND "FNTYP"=4 AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("FNFLG",4)<>4)
12 - access("F"."TS#"="TS"."TS#")
17 - filter("F"."SPARE1" IS NOT NULL)
18 - access("F"."FILE#"=2)
19 - filter("FE"."FENUM"=2)
21 - filter("FNNAM" IS NOT NULL AND "FNFNO"=2 AND "FNTYP"=4 AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("FNFLG",4)<>4)
22 - filter("HC"."KTFBHCAFNO"=2)
24 - access("HC"."KTFBHCTSN"="TS"."TS#")
统计信息
----------------------------------------------------------
151 recursive calls
1 db block gets
32 consistent gets
0 physical reads
0 redo size
1179 bytes sent via SQL*Net to client
338 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> /
已用时间: 00: 00: 00.00
执行计划
----------------------------------------------------------
Plan hash value: 1869944940
------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 2 | 812 | 4 (0)| 00:00:01 |
| 1 | VIEW | DBA_DATA_FILES | 2 | 812 | 4 (0)| 00:00:01 |
| 2 | UNION-ALL | | | | | |
| 3 | NESTED LOOPS | | 1 | 395 | 2 (0)| 00:00:01 |
| 4 | MERGE JOIN CARTESIAN | | 1 | 380 | 1 (0)| 00:00:01 |
| 5 | NESTED LOOPS | | 1 | 70 | 1 (0)| 00:00:01 |
|* 6 | TABLE ACCESS BY INDEX ROWID | FILE$ | 1 | 31 | 1 (0)| 00:00:01 |
|* 7 | INDEX UNIQUE SCAN | I_FILE1 | 1 | | 0 (0)| 00:00:01 |
|* 8 | FIXED TABLE FIXED INDEX | X$KCCFE (ind:1) | 1 | 39 | 0 (0)| 00:00:01 |
| 9 | BUFFER SORT | | 1 | 310 | 1 (0)| 00:00:01 |
|* 10 | FIXED TABLE FULL | X$KCCFN | 1 | 310 | 0 (0)| 00:00:01 |
| 11 | TABLE ACCESS CLUSTER | TS$ | 1 | 15 | 1 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 471 | 2 (0)| 00:00:01 |
| 14 | NESTED LOOPS | | 1 | 456 | 1 (0)| 00:00:01 |
| 15 | MERGE JOIN CARTESIAN | | 1 | 365 | 1 (0)| 00:00:01 |
| 16 | NESTED LOOPS | | 1 | 55 | 1 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID| FILE$ | 1 | 16 | 1 (0)| 00:00:01 |
|* 18 | INDEX UNIQUE SCAN | I_FILE1 | 1 | | 0 (0)| 00:00:01 |
|* 19 | FIXED TABLE FIXED INDEX | X$KCCFE (ind:1) | 1 | 39 | 0 (0)| 00:00:01 |
| 20 | BUFFER SORT | | 1 | 310 | 1 (0)| 00:00:01 |
|* 21 | FIXED TABLE FULL | X$KCCFN | 1 | 310 | 0 (0)| 00:00:01 |
|* 22 | FIXED TABLE FIXED INDEX | X$KTFBHC (ind:1) | 1 | 91 | 0 (0)| 00:00:01 |
| 23 | TABLE ACCESS CLUSTER | TS$ | 1 | 15 | 1 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
6 - filter("F"."SPARE1" IS NULL)
7 - access("F"."FILE#"=2)
8 - filter("FE"."FENUM"=2)
10 - filter("FNNAM" IS NOT NULL AND "FNFNO"=2 AND "FNTYP"=4 AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("FNFLG",4)<>4)
12 - access("F"."TS#"="TS"."TS#")
17 - filter("F"."SPARE1" IS NOT NULL)
18 - access("F"."FILE#"=2)
19 - filter("FE"."FENUM"=2)
21 - filter("FNNAM" IS NOT NULL AND "FNFNO"=2 AND "FNTYP"=4 AND
"INST_ID"=USERENV('INSTANCE') AND BITAND("FNFLG",4)<>4)
22 - filter("HC"."KTFBHCAFNO"=2)
24 - access("HC"."KTFBHCTSN"="TS"."TS#")
统计信息
----------------------------------------------------------
0 recursive calls
1 db block gets
7 consistent gets
0 physical reads
0 redo size
1179 bytes sent via SQL*Net to client
338 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
DICTIONARY CACHE
在内存中存放ORACLE数据库中常用的数据字典的信息，若此区域太小，当ORACLE需要某些数据字典信息，如对某用户的权限设置等信息时， 如果该信息不能在DICTIONARY CACHE中找到，则必须先通过物理读从ORACLE数据库的数据文件中得到该信息，然后再将该内存区域的部分信息替换出去
DB Buffer Cache
存放Oracle系统最近使用过的数据块。让他们能够在内存中进行操作。在这个级别里没有系统文件，用户数据文件，临时数据文件，回滚段文件之分。也就是任何文件的数据块都有可能被缓冲。数据库的任何修改都在该缓冲里完成，并由DBWR进程将修改后的数据写入磁盘。
刷新DB Buffer Cache实验
SQL> create table test_buffer as select * from dba_objects;
表已创建。
SQL> exec dbms_stats.gather_table_stats(user,'test_buffer');
表已分析。
SQL> select blocks,empty_blocks from dba_tables where table_name='TEST_BUFFER' and owner='SYS';
BLOCKS EMPTY_BLOCKS
---------- ------------
688 79
SQL> select count(*) from x$bh;
COUNT(*)
----------
8835
SQL> select count(*) from x$bh where state = 0;
COUNT(*)
----------
29
SQL> alter system set events = 'immediate trace name flush_cache';
系统已更改。
SQL> select count(*) from x$bh where state = 0;
COUNT(*)
----------
8832
SQL> set autotrace traceonly
SQL> select count(*) from test_buffer;
执行计划
----------------------------------------------------------
Plan hash value: 2550671572
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 154 (2)| 00:00:02 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TEST_BUFFER | 50081 | 154 (2)| 00:00:02 |
--------------------------------------------------------------------------
统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
693 consistent gets
689 physical reads
0 redo size
410 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> /
执行计划
----------------------------------------------------------
Plan hash value: 2550671572
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 154 (2)| 00:00:02 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| TEST_BUFFER | 50081 | 154 (2)| 00:00:02 |
--------------------------------------------------------------------------
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
693 consistent gets
0 physical reads
0 redo size
410 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
Redo Log Buffer
重做日志文件的缓冲区，对数据库的任何修改都按顺序被记录在该缓冲，然后由LGWR进程将它写入Redo log files。这些修改信息包含DML语句以及DDL语句。 重做日志缓冲区的存在是因为内存到内存的操作比较内存到硬盘的速度快很多，所以重作日志缓冲区可以加快数据库的操作速度，但是考虑的数据库的一致性与可恢复性，数据在重做日志缓冲区中的滞留时间不会很长。
PMON(processes Mointor)
是进程监视器。如果执行某些更新语句，未提交时进程崩溃，这时PMON会自动回滚该操作，无需人工执行rollback命令。除此之外还可以干预后台进程，比如RECO异常失败了，此时PMON会重启RECO进程，如果遇到LGWR进程失败这种严重的问题，PMON会做出中止实例这个激烈的动作，用于防止数据错乱。
SMON(System Monitor)
系统监视器，与PMON不同的是，SMON关注的是系统级的操作而非单个进程，重点工作在于实例恢复，除此以外还有清理临时表空间、清理回滚段空间、合并空闲空间等。
CKPT(Checkpoint Process)
检查点进程。由Oracle的fast_start_mttr_target参数控制，用于触发DBWR从数据缓冲中写出数据到磁盘。CKPT执行越频繁，DBWR写出最频繁，性能越低，但数据库异常恢复的时候会越快。
RECO(Distributed Database Recovery)
用于分布式数据库恢复
DBWRn(Database Block Writer)
数据库块写入器是Oracle最核心的进程之一，负责把数据从数据缓存区写到磁盘，改进程和CKPT相辅相成，因为是CKPT促成DBWR去写的。不过DBWR也和LGWR密切相关，因为DBWR要想把数据缓存区数据写到磁盘时，必须通知LGWR先完成日志缓存区写到磁盘的动作后，方可开工。
LGWR(Log Writer)
日志写入器，就是将日志缓存区的数据从内存写到磁盘的redo文件中。Redo的记录可以用来做数据库的异常恢复，只要保护好这些redo文件和后续对于的归档文件，从理论上来讲，即使数据文件都被删光了，可以根据这些日志将曾经发生的事情全部重做一遍，从而保证数据库的安全。LGWR必须记录下所有从数据缓存区写到数据文件的动作，工作任务相当繁重。由于要顺序记录情况下保留的日志才有意义，多进程难以保证顺序，因此只能采用单线程。为了适应工作高强度的日志记录工作，LGWR制定了5条规则：
–每隔三秒钟，LGWR运行一次；
–任何commit触发LGWR运行一次；
–DBWR要把数据从数据缓存写到磁盘，触发LGWR运行一次；
–日志缓存区满三分之一或记录慢1MB，触发LGWR运行一次；
–联机日志文件切换也将触发LGWR。
ARCn(Archive Process)
归档进程，它的作用是在LGWR写日志写到需要覆盖重写的时候，触发ARCH进程去转移日志文件，复制出去形成归档日志文件。
总结：
1. PGA是用来排序的，当PGA空间不够时只有用磁盘排序，如果一个大排序不仅非常耗CPU，而且会影响其他的排序，就是影响其他的功能慢。想想我们系统中的排序，排序在设计或开发阶段就很随意，大的排序也不避讳。
2. DBWR写磁盘的前提条件是保证对应的redo已经写到磁盘，我们可以把最繁忙的进程LGWR写redo log放到最快的磁盘上，同时也可以提高commit的速度。
3. 避免循环commit提交。LGWR是单线程的顺序写，如果有大量的循环提交，那log buffer基本没有用处，大量commit排队提交，commit慢了造成锁释放慢，在系统大并发下，性能是不是有问题。
4. 如有一个很大的数据库，数据量庞大，访问量非常高，而共享池很小，会产生很多SQL硬解析，因为解析的SQL很快就被挤出共享池。
5. 如果你诊断一个数据库共享池总不够用，进一步发现硬解析很高，那就要用变量。
6. 上班时间导入数据和大量操作数据有什么影响?产生大量的redo，会影响其他功能慢。导出也会影响性能，以后再讲。
7. 在用as of timestap恢复数据的时候，发生快照失效，原因是什么，undo中没有改记录的改动了。如何解决，可以增大undo_retention，也可以增大undo表空间大小。
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
相关 [oracle 数据库 体系结构] 推荐：
【Oracle】物理体系结构
- - CSDN博客推荐文章一、ORACLE 物理体系结构. PGA: 私有内存区，仅供当前发起用户使用. 用户登录后的session信息会保存在PGA. 执行排序，如果内存不够，oracle会在临时表空间中完成. SGA: 包含共享池，数据缓冲区，日志缓冲区以及一些相关的进程. DATABASE: 数据最终存放的地方，其中一块区域是日志存放区.
Oracle的体系结构概览
- - CSDN博客数据库推荐文章声明：版本11gR2，CentOS5.8. (从11g开始password项里变为空了，以免被破解). 实例=内存（sga）+后台进程（background）. 查看内存，可以通过以下视图. 后台进程，可以通过下面视图查看. 我们只关心paddr不等于0的就可以了，等于0的都是没启用. 参数文件spfilesid.ora,initsid.ora.
Oracle 发布 NoSQL 数据库
- 冷月 - 博客园新闻频道 Oracle 作为全球最大的关系型数据库提供商，在其产品链条中，也加入了 NoSQL 数据库这一环，而且这个新的数据库名字很霸气，就叫 NoSQL Database，想起了当年新浪微博更换 weibo.com 域名之时的一个笑话：. 原来有三家人做面包，张三家的面包叫三张牌面包，李四家的牌子叫李四牌面包，王五家出品的是王五牌面包，而突然有一天，张三家的面包改名了，叫面包牌面包.
Oracle数据库备份
- - Oracle - 数据库 - ITeye博客（一)、导出/导入(EXPORT/IMPORT). EXPORT/IMPORT是用来将ORACLE中数据移出/移入数据库. 1、EXPORT将数据库中数据备份成一个二进制系统文件称为“导出转储文件”(EXPORT. DUMP FILE)，并将重新生成数据库写入文件中. a.用户模式：导出用户所有对象以及对象中的数据；.
Oracle数据库资源管理
- - 技术改变世界 创新驱动中国 - 《程序员》官网一般来说，Oracle数据库都属于中大型的系统，这类系统的用户会话(Session)，小则一两百，多则上千，这些用户会话要求Oracle数据库执行的任何指令都需要耗费系统资源，而系统资源毕竟是宝贵且有限的，一旦突然涌进大量的用户会话，对于有限的资源可能会略显不足. 但这些会话必定有轻重缓急之分，对于重要且紧急的用户会话需求理当获得多一点的系统资源，对于一些不重要或不紧急的用户会话，则可以使用较少的系统资源慢慢处理.
Oracle 数据库导入导出
- - CSDN博客推荐文章使用 exp/imp 导入导出. 开始exp/imp之前, 有以下几点需要注意：. 1)此部分以 oracle 10g为例. 2)exp, imp 是操作系统下一个可执行的文件，存放在/ORACLE_HOME/bin目录下. 所以之间cmd 命令模式下执行就行了. (不需要先连接进sqlplus).
[Oracle] 数据库安全之 - Vault
- - CSDN博客推荐文章Oracle用了整整一本书来阐述Valut，有兴趣的童鞋可以参考http://docs.oracle.com/cd/E11882_01/server.112/e23090/toc.htm，我个人觉得并不需要对它进行太深入的了解，只有知道有这么一回事就好了. 从宏观方面看，Vault属于Oracle数据库安全领域中-访问控制的部分，可参考《 [Oracle] 数据安全概述》.
Oracle数据库分析函数详解
- - MySQLOPS 数据库与运维自动化技术分享Oracle数据库分析函数详解. 原创文章，转载请注明： 文章地址 Oracle数据库分析函数详解.
Oracle数据库日常检查
- - Oracle - 数据库 - ITeye博客看数据库是否处于归档模式，并启动了自动归档进程. 执行df –k，检查有没有使用率超过80%的文件系统，特别是存放归档日志的文件系统. 检查alert_SID.log有无报错信息(ORA-600、ORA-1578)、ORA-60. 用imp工具生成建表脚本，看能否正常完成. 如果最大可用块(max_chunk)与总大小(total_space)相比太小，要考虑接合表空间碎片或重建某些数据库对象.