概述
任何硬件平台或操作系统下的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先完成日志缓存区写到磁盘的动作后，方可开工。
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表空间大小。
最后
以上就是潇洒裙子为你收集整理的oracle 数据库体系结构的全部内容，希望文章能够帮你解决oracle 数据库体系结构所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复