读完tom大师写的Export One-One前六章,随笔写了一些概念,有一些简单的实验
读Export-One-One
1. 锁存器 和排队是轻量的序列化设备
2. 数据库块缓冲存储器
3. 共享池中的库高速缓存器
4. 一个进程持有锁存器在不正常的情况下,突然死掉 ,死掉的进程有PMON去清除
5. 更新一个表中的行,oracle获得两个锁 一个是行级锁(TX(事务锁)),一个是表级锁TM[主要是防止其他用户做DDL操作,修改表结构]
6. 手工封锁和用户自定义封锁
(1) select for update 是最常用的手工封锁的方法,避免放生丢失更新(一个会话将重写另一个会话的更改),
(2)也可以用LOCK TBALE 语句来手工封锁,不过这种方法比较粗糙,它只是锁定表,而不锁定行。那么这种方法经常用在大批量更行数据时。锁定整个表
Oracle中的多版本特性 --- 解决高度并行性的控制(读一致性)
8. 事务隔离等级
a. 脏读: 允许读一个没有提交的,或“ 脏” 的数据, 数据的完整性被破坏。
b. 非重复读取: 一个会话在T1时间读取一个行,并试图在T2时间再次读取该行,然而,该行可能已经被修改,可能已经消失,也可能被更新。
c. 幻想读:如果在时间T1执行了一个查询,并在时间T2再次执行查询,附件的行可能已经添加到数据库了,结果不一致,已经的读取的数据没有改变,但有更多的数据满足这个查询
d. READ UNCOMMITTED 隔离等级 : 允许脏读,写阻塞读,读阻塞写
e. READ COMMITTED 隔离等级: 声明一个事务只可以读取在事务开始之前的提交的数据
f. REPEATABLE READ 隔离等级:
i. 获得一致性的答案: 给定查询的结果必须和有关时间点是一致的。大多数数据库(不包括Oracle)借助行级,共享读取锁定来获得,一个共享读取锁定防止其他会话修改已经读取的数据,从而降低了并行度,在Oracle中,使用多版本,可获得与查询开始执行的时间点上一致的答案,其他的数据库使用共享锁定(查询时表中的行被锁定)
ii. 预防丢失更新 : 大多数数据库是使用SELECT FOR UPDATE 和共享锁定来实现。在Oracle中,如果需要REPEATABLE READ 不是用select for update 物理的串行化对表的访问,实际上需要将隔离等级设置为SERIALIZABLE
g. SERIALIZABLE 隔离等级
9.
10. Oracle 把PL/SQL匿名块视为语句。Oracle把存储过程看作是一条原子语句。
11. 完整性约束
a. 默认情况下,完整性约束检查在SQL语句执行完以后进行,为什么不在SQL语句执行期间检查呢?
因为在同一时间只有一条语句处理数据才是正常的。
下面演示一下完整性约束的延迟和即时性
[autosys@pderptest ~]$ sqlplus /nolog
SQL*Plus: Release 9.2.0.7.0 - Production on Sat Oct 17 19:52:44 2009
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
SQL> conn jk/aaaaaaaa
Connected.
SQL> create table p(pk int primary key);
Table created.
SQL> create table p1 (fk int constraint p1_fk references p(pk)
2 deferrable --表示p1表可以延迟
3 initially immediate
4 );
Table created.
SQL> insert into p values(1);
1 row created.
SQL> insert into p1 values(1);
1 row created.
SQL> update p set pk=2;
update p set pk=2
*
ERROR at line 1:
ORA-02292: integrity constraint (JK.P1_FK) violated - child record found
SQL> set constraint p1_fk deferred; --设置p1表的约束为延迟
Constraint set.
SQL> update p set pk=2;
1 row updated.
这里没有报错,本质上已经违反约束
那么,我们设置为即时检查约束,
SQL> set constraint p1_fk immediate;
SET constraint p1_fk immediate
*
ERROR at line 1:
ORA-02291: integrity constraint (JK.P1_FK) violated - parent key not found
我们看到,事务是任然是P1_FK约束为deferred运行。马上检查完整
SQL> update p1 set fk=2;
1 row updated.
SQL> set constraint p1_fk immediate;
Constraint set.
SQL> commit;
Commit complete.
SQL>
12. 重做和回滚
a. 重做: 对数据库来说,这些事事物日志,只是用来恢复。在实例和介质出现故障时,Oracle将使用归档重做日志和联机重做日志,把数据库恢复到"事故"发生前的那一刻。
b. Oracle有两种重做日志文件,即联机和归档。每个Oracle数据库至少有两个联机重做日志,他们循环写入,第一个写满,写第二个。归档重做日志文件只是复制旧的,写满了的联机重做日志文件,当联机重做日志文件写满时,ARCH进程会把联机重做日志文件复制到另一个位置。归档重做日志文件是Oracle数据库事务的历史记录。当硬盘出现故障和一些物理错误时,Oracle会利用归档重做日志文件和其他的一些文件一起当作数据库的备份来恢复数据库到事故发生前的状态。Oracle在Commit时,必须等待LGWR把所有没有写入的缓冲重做信息写到硬盘上。
c. SCN: SCN是Oracle用来保证事务顺序并从失败中恢复的简单定时机制,SCN也能保证数据库的一致性和检查点机制
d. Commit时,所做的“块清除”,就是在Commit提交进程期间,会重新访问某些事物修改过的块,清除掉存储在数据库块头中的与锁定有关的信息、简单的说,就是清除了数据块上的事务信息。Commit是一个“平均响应时间”的操作。
e. 每行commit是事务完成一次提交耗时的三倍,行越多,额外开销就越少
13. NOLOGGING模式下的操作
a. 索引创建和alter(重建索引)
b. 经 */* + append */ 提示,使用“直接路径插入” 批量的insert
c. LOB操作(大对象更新不必记录到日志中)
d. 用create table as select 创建表
e. 各种ALTER table 操作,例如MOVE 和 SPLIT
f. Truncated (但不需要nologging语句),因为总是在nologging模式中执行
不使用NOLOGGING模式
SQL> set timing on
SQL> select * from redo_size
2 ;
VALUE
----------
29310912 --创建表前的redo的大小
已用时间: 00: 00: 00.03
SQL> create table a as select * from all_objects;
表已创建。
已用时间: 00: 00: 45.71
SQL> select * from redo_size;
VALUE
----------
37800216 --创建表后的redo的大小
已用时间: 00: 00: 00.01
SQL> select (37800216 - 29310912 )/1024/1024 || 'M' from dual;
(37800216-29310912)/
--------------------
8.09603118896484375M --产生的redo大小为
已用时间: 00: 00: 00.01
SQL>
使用NOLOGGIN模式
SQL> drop table t;
表已删除。
已用时间: 00: 00: 00.47
SQL> selet * from redo_size;
SP2-0734: 未知的命令开头 "selet * fr..." - 忽略了剩余的行。
SQL> select * from redo_size;
VALUE
----------
37819340
已用时间: 00: 00: 00.01
SQL> create table t
2 nologging
3 as
4 select * from all_objects;
表已创建。
已用时间: 00: 00: 45.66
SQL> select * from redo_size;
VALUE
----------
46359304
已用时间: 00: 00: 00.01
SQL> select (46359304-37819340)/1024/1024 ||'M' from dual;
(46359304-37819340)/1
---------------------
8.144344329833984375M
为什么比不用nologging产生的redo还多呢?
我的数据库是归档模式
SQL> show user;
USER 为 "SYS"
SQL> archive log list;
数据库日志模式 存档模式
自动存档 启用
存档终点 /u01/app/oracle/archivelog
最早的联机日志序列 22
下一个存档日志序列 24
当前日志序列 24
书上说在非归档模式下,nologging模式和非nologging模式没有区别。
14. 会话长时间等待,最有可能碰到这样的提示“切换日志文件”,切换日志文件设置检查点或归档没有完成。解决会话长时间等待的方法:
a. 让DBWR变得更快。通过启用ASYNC I/O ,或者使用多个DBWR进程。
b. 增加更多的重做日志文件。消除了系统的“暂停”,缺点是消耗了更多的硬盘、
c. 重新创建大的的重做日志文件
15. 块清除的原因
SQL> create table a2 (x char(2000) default 'x',y char(2000) default 'y' , z char(2000) default 'z');
表已创建。
SQL> insert into a2 select 'x','y','z' from all_objects where rownum <500;
已创建499行。
SQL> commit;
提交完成。
这是每块一行的数据(8k的数据库)
现在测试select操作产生的重做
SQL> select * from redo_size;
VALUE
----------
3296948
SQL> select * from a2 where x=y;
未选定行
SQL> select * from redo_size;
VALUE
----------
3297124
SQL> select 3297124 - 3296948 from dual;
3297124-3296948
---------------
176
看到产生了176字节的重做,这代表了完全扫描A2表期间修改的块头,所产生的重做日志,那么在某一刻,DBWR将把这些修改过的块再次写入硬盘中。现在,我们再次运行本次查询
SQL> select * from redo_size;
VALUE
----------
3297124
SQL> select * from a2 where x=y;
未选定行
SQL> select * from redo_size;
VALUE
----------
3297124
SQL>
会看到没有产生redo信息。块全部是干净的
16. 日志竞争的原因 (等待把重做缓冲刷新到硬盘上)
a. 应用程序的原因是提交频率太高
b. 把重做放到了运行慢的设备上,硬盘性能差,应该去购买新的硬盘了
c. 把重做文件和其他文件放到了同一设备上,重做是设计用来在专用设备上大量连续写入。
d. 用缓冲方式安装设备(双缓冲)
e. 用慢的技术放置重做。Raid-5 ,读取性能好,写入性能差
17. 数据库表
a. 堆组织表 堆就是一片空间,并且以某种随机的方式使用
b. 索引组织表 : 表存储在索引结构中,在索引组织表中,根据主关键字,以排序的方式来存储数据。
c. 聚族表:许多表连接在一起存储、包含相同聚族码值的所有数据将物理上在一起。
d. 嵌套表
e. 临时表:每个会话只能看到自己分配的区域,不能看到其他会话创建的数据
f. 对象表:她是堆组织表,索引组织表和临时表的特例,并且也可能包括嵌套表作为结构的一部分。
18. 数据库表存储参数术语
a. 高水标记: 开始在创建的表的第一个块上。全表扫描时,Orace将扫描高水位标记一下的块,即使他们不包含数据,这将影响全表扫描的性能。尤其是高水位标记下的块都是空的(产生于delete操作时,高水位标记不移动,最好使用truncate删除)
b. 自由列表(freelist)Oracle中用来跟踪高水位标记以下的空闲的块对象。每个对象至少有一个freelist与她相关,当块被使用,Oracle将根据需要放置或取走freelist
19. PCTUSED,PCTFREE 的理解
1. PCTUSED,PCTFree 使用相当关键,一方面可以避免行迁移,另一方面可以避免浪费空间。
2. 高PCTfree ,低PCTUSED---用于许多将要更新的数据,并且更新行经常会增加行的大小,这样插入后在块上保留了许多空间 (高PCTFREE) 在块返回列表freelist中,块几乎是空的(低PCTUSED)
3. 低PCTFREE,高PCTUSED -- 用于对表只使用Insert 和 Delete ,或者Update ,但Update是使行变小
20. 散列聚族
1. 散列聚族虫开始就需要分配空间。
21. 嵌套表
1. 嵌套表的列存储在RAW列中,如果使用嵌套表,确保嵌套表是是索引组织表。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7551038/viewspace-617238/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/7551038/viewspace-617238/