课程目标
1.Oracle数据库概述
•实例：一组Oracle后台进程/线程以及一个共享内存区，这些内存由同一个计算机上运行的线程/进程所共享。
2. Oracle体系结构
任何硬件平台或操作系统下的ORACLE体系结构都是相同的，
包括如下四个方面：
数据文件，日志文件，控制文件，参数文件。
表空间、段、区间、数据块。
数据文件：select name from v$datafile; 控制文件：select name from v$controlfile; 日志文件：select member from v$logfile; 参数文件：$oracle_home/dbs/initSID.ora(从spfile转换，create pfile from spfile;) 归档日志文件：show parameter log_archive_dest 查看归档模式：archive log list SGA: show sga/show parameter sga/v$sgastat PGA: show parameter pga/v$pgastat 进程:ps –ef |grep oracle
2.1 SGA与PGA
SGA是共享内存区，PGA是私有内存区，用户对数据库发起的无论查询还
是更新的任何操作，都是PGA预先处理，然后接下来才进入实例区域，
由SGA和系列后台进程共同完成用户发起的请求。
PGA的作用主要是三点
2.2 Shared Pool
library cache最主要的功能就是存放用户提交的SQL语句及相关的解析树（解析树也就是对SQL语句中所涉及的所有对象的展现）、执行计划、用户提交的PL/SQL程序块（包括匿名程序块、存储过程、包、函数等）以及它们转换后能够被Oracle执行的代码等。
library cache也存放了很多的数据库对象的信息，包括表、索引等。有关这些数据库对象的信息都是从dictionary cache中获得的。如果用户对library cache中的对象信息进行了修改，比如为表添加了一个列等，则这些修改会返回到dictionary cache中。
•DB Dictionary Cache
DICTIONARY CACHE在内存中存放ORACLE数据库中常用的数据字典的信息，若此区域太小，当ORACLE需要某些数据字典信息，如对某用户的权限设置等信息时， 如果该信息不能在DICTIONARY CACHE中找到，则必须先通过物理读从ORACLE数据库的数据文件中得到该信息，然后再将该内存区域的部分信息替换出去。
存放Oracle系统最近使用过的数据块。让他们能够在内存中进行操作。在这个级别里没有系统文件，用户数据文件，临时数据文件，回滚段文件之分。也就是任何文件的数据块都有可能被缓冲。数据库的任何修改都在该缓冲里完成，并由DBWR进程将修改后的数据写入磁盘。
实验1：软解析-测试清理共享池后，执行计划对比
SQL> set autotrace traceonly SQL> set linesize 2000 SQL> select * from dba_data_files t where t.file_id=2;
执行计划 ---------------------------------------------------------- Plan hash value: 1284839659 ------------------------------------------------------------------------------------------------------ | 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 | 399 | 2 (0)| 00:00:01 | | 4 | MERGE JOIN CARTESIAN | | 1 | 381 | 1 (0)| 00:00:01 | | 5 | NESTED LOOPS | | 1 | 71 | 1 (0)| 00:00:01 | |* 6 | TABLE ACCESS BY INDEX ROWID | FILE$ | 1 | 32 | 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 | 18 | 1 (0)| 00:00:01 | |* 12 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| 00:00:01 | | 13 | NESTED LOOPS | | 1 | 473 | 2 (0)| 00:00:01 | | 14 | MERGE JOIN CARTESIAN | | 1 | 455 | 1 (0)| 00:00:01 | | 15 | MERGE JOIN CARTESIAN | | 1 | 364 | 1 (0)| 00:00:01 | | 16 | NESTED LOOPS | | 1 | 54 | 1 (0)| 00:00:01 | |* 17 | TABLE ACCESS BY INDEX ROWID| FILE$ | 1 | 15 | 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 | BUFFER SORT | | 1 | 91 | 1 (0)| 00:00:01 | |* 23 | FIXED TABLE FIXED INDEX | X$KTFBHC (ind:1) | 1 | 91 | 0 (0)| 00:00:01 | | 24 | TABLE ACCESS CLUSTER | TS$ | 1 | 18 | 1 (0)| 00:00:01 | |* 25 | 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) 23 - filter("HC"."KTFBHCAFNO"=2) 25 - access("HC"."KTFBHCTSN"="TS"."TS#") 统计信息 ---------------------------------------------------------- 276 recursive calls 1 db block gets 50 consistent gets 0 physical reads 0 redo size 1172 bytes sent via SQL*Net to client 338 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 10 sorts (memory) 0 sorts (disk) 1 rows processed
SQL>alter system flush shared_pool; --- (测试清理共享池后的执行计划禁止在公司测试环境执行) SQL>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;
执行计划 ---------------------------------------------------------- Plan hash value: 1284839659 ------------------------------------------------------------------------------------------------------ | 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 | 399 | 2 (0)| 00:00:01 | | 4 | MERGE JOIN CARTESIAN | | 1 | 381 | 1 (0)| 00:00:01 | | 5 | NESTED LOOPS | | 1 | 71 | 1 (0)| 00:00:01 | |* 6 | TABLE ACCESS BY INDEX ROWID | FILE$ | 1 | 32 | 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 | 18 | 1 (0)| 00:00:01 | |* 12 | INDEX UNIQUE SCAN | I_TS# | 1 | | 0 (0)| 00:00:01 | | 13 | NESTED LOOPS | | 1 | 473 | 2 (0)| 00:00:01 | | 14 | MERGE JOIN CARTESIAN | | 1 | 455 | 1 (0)| 00:00:01 | | 15 | MERGE JOIN CARTESIAN | | 1 | 364 | 1 (0)| 00:00:01 | | 16 | NESTED LOOPS | | 1 | 54 | 1 (0)| 00:00:01 | |* 17 | TABLE ACCESS BY INDEX ROWID| FILE$ | 1 | 15 | 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 | BUFFER SORT | | 1 | 91 | 1 (0)| 00:00:01 | |* 23 | FIXED TABLE FIXED INDEX | X$KTFBHC (ind:1) | 1 | 91 | 0 (0)| 00:00:01 | | 24 | TABLE ACCESS CLUSTER | TS$ | 1 | 18 | 1 (0)| 00:00:01 | |* 25 | 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) 23 - filter("HC"."KTFBHCAFNO"=2) 25 - access("HC"."KTFBHCTSN"="TS"."TS#") 统计信息 ---------------------------------------------------------- 858 recursive calls 1 db block gets 165 consistent gets 0 physical reads 0 redo size 1172 bytes sent via SQL*Net to client 338 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 13 sorts (memory) 0 sorts (disk) 1 rows processed
•DB Buffer Cache
存放Oracle系统最近使用过的数据块。让他们能够在内存中进行操作。在这个级别里没有系统文件，用户数据文件，临时数据文件，回滚段文件之分。也就是任何文件的数据块都有可能被缓冲。数据库的任何修改都在该缓冲里完成，并由DBWR进程将修改后的数据写入磁盘。
实验2：刷新DB Buffer Cache
X$BH --- Buffer状态
alter system set events = 'immediate trace name flush_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语句。 重做日志缓冲区的存在是因为内存到内存的操作比较内存到硬盘的速度快很多，所以重作日志缓冲区可以加快数据库的操作速度，但是考虑的数据库的一致性与可恢复性，数据在重做日志缓冲区中的滞留时间不会很长。
2.3 数据库进程
- PMON
PMON(processes Mointor)，是进程监视器。如果执行某些更新语句，未提交时进程崩溃，这时PMON会自动回滚该操作，无需人工执行rollback命令。除此之外还可以干预后台进程，比如RECO异常失败了，此时PMON会重启RECO进程，如果遇到LGWR进程失败这种严重的问题，PMON会做出中止实例这个激烈的动作，用于防止数据错乱。
- SMON
SMON(System Monitor)，系统监视器，与PMON不同的是，SMON关注的是系统级的操作而非单个进程，重点工作在于实例恢复，除此以外还有清理临时表空间、清理回滚段空间、合并空闲空间等。
- CKPT
CKPT(Checkpoint Process)，检查点进程。由Oracle的fast_start_mttr_target参数控制，用于触发DBWR从数据缓冲中写出数据到磁盘。CKPT执行越频繁，DBWR写出最频繁，性能越低，但数据库异常恢复的时候会越快。
- RECO
RECO(Distributed Database Recovery)用于分布式数据库恢复。适用于两阶段提交场景。
- DBWR
DBWRn(Database Block Writer)数据库块写入器是Oracle最核心的进程之一，负责把数据从数据缓存区写到磁盘，改进程和CKPT相辅相成，因为是CKPT促成DBWR去写的。不过DBWR也和LGWR密切相关，因为DBWR要想把数据缓存区数据写到磁盘时，必须通知LGWR先完成日志缓存区写到磁盘的动作后，方可开工。
- LGWR
- ARCn
ARCn(Archive Process)归档进程，它的作用是在LGWR写日志写到需要覆盖重写的时候，触发ARCH进程去转移日志文件，复制出去形成归档日志文件。
2.4 各类型SQL的操作流程
SELECT语句操作流程：
DELETE的运作流程：
3 COMMIT做了什么
实验3.1：是不是事务越大，commit时间越长？如插入10万条数据后commit的时间比插入100条数据后commit所耗的时间要长吗？
SQL> create table test(x int); SQL> set timing on SQL> insert into test select rownum from dual connect by level <= 100; 已用时间: 00: 00: 00.12 SQL> commit; 已用时间: 00: 00: 00.00 SQL> create table test1(x int); SQL> insert into test1 select rownum from dual connect by level <= 1000000; 已创建1000000行。 已用时间: 00: 00: 00.89 SQL> commit; 已用时间: 00: 00: 00.01
实验3.2：
循环提交的问题，先得说commit开销的两个因素：
1.显然会增加与数据库的往返通信，如果每个记录都提交，生成的往返通信量就会大得多。
2.每次提交时，必须等到redo写至磁盘。就会导致等待，这种等待称为日志文件同步(log file sync)。
SQL>create table test(x int); SQL>set timing on SQL>declare a number; begin for i in 1.. 100000 loop execute immediate 'insert into test values(:a)'using i; commit; end loop; end; / SQL>truncate table test; SQL>declare a number; begin for i in 1.. 100000 loop execute immediate 'insert into test values(:a)'using i; end loop; commit; end; /
思考：
1.在执行一条update语句提交后，数据会写到数据文件中吗？
2.在执行一条update语句后一直未提交，数据会写到数据文件中吗？
4 一致性查询及一致性读原理
Select * from test where object_id = 2;
如果8点钟可以查询出两条记录，假设一下，如果此查询很慢，从8点开始查，9点才能结束。在此期间不巧被删了一条数据，请问最终返回的结果是一条数据还是两条数据？
假设我有4个户头，户1余额为1000元，户2余额为2000元，户3余额为3000元，户4余额为4000元，总计是1万元。现在查询账号的总余额，从户1开始已经读完户3，就在此时户1转了1000元到户4，此时户4是5000，如果此时户4读当前的余额，那总余额为1000+2000+3000+5000=11000。现在可以给出结论是查8点的数据还是9点的数据吧。
一致读的原理：及时查询的记录由查询的这一时间点决定，后面即使变化了，也要根据回滚段保存的前镜像记录，取得那个时间点的数据。
数据库是怎么保证一致读呢？
首先了解以下两个前提：
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表空间大小。
6 课后作业：
结合体系结构做一次性能调优
创建一张表，向表中插入10万条数据，开发人员的实现如下所示：
create table t (x int); alter system flush shared_pool; create or replace procedure proc1 as begin for i in 1.. 100000 loop execute immediate ‘insert into t values(‘||i||’)’; commit; end loop; end; /
•找出优化点，并分析出原因，执行的时间
