Oracle数据库空间管理和规划

本文希望通过系统地介绍这方面的有关概念 让大家能更好地规划使用数据空间 正确使用Oracle提供的有关功能特性 提高应用的执行效率

数据库空间的有效使用和维护不仅是数据库管理的重要工作 也是大多数开发人员所关心的内容 因为它直接关系到数据库性能的发挥 同时数据碎片是经常令人头疼的问题 碎片不仅造成空间的浪费 更重要的是会直接影响应 用程序的响应速度

Oracle提供了不少方法用于数据空间的使用 监控和维护 同时也在各版本中陆续对这方面的功能进行了增强 目的在于简化这方面工作的复杂度 提高应用的运行效率

一 相关概念

数据库的空间在逻辑上分为多个表空间 每个表空间则由系统中的一个或多个物理数据文件构成 Oracle存储数据的基本单位是块 其大小在建库时由DB_BLOCK_SIZE参数确定 一个或多个连续的块构成一个区片（EXTENT） 它作为数据对象存储的基本单位来使用 在Oracle中 每个基本数据对象使用的空间称为段（Segment） 段存放在唯一的表空间上 每个段实际上是一系列区片（更为准确地是数据块）的集合 每个简单数据对象对应一个段 对于分区对象如分区表 索引 则每个（子）分区对应一个段 由各个（子）分区共同构成一个完整的数据对象 因此 可以把表空间看作桶 里面放著许多段 一个段只能放在一个桶中 而不能跨越多个桶

二 表空间的使用

表空间碎片的产生

由于同一个表空间中存放有多个数据段 各个数据段可以有不同的区片尺寸 不同段的区片可以交叉存放 当这些段中的区片经过分配（如创建表） 释放（如删除表）后 就可能使表空间中原本连续的空闲数据块变成不连续 而区片必须由连续的数据块构成 这时 当某一段需要分配新的区片时 就有可能出现虽然表空间空闲数据块的总和大于所需区片的大小 但却无法找到一串连续的块来供此区片分配使用 这种情况就称为表空间的Extent Fragmentation 我们经常会遇到这种情况 明明从DBA_FREE_SPACE中计算表空间还有几百MB 但其中的某一个表却无法再扩展几个MB的空间

消除表空间碎片

Oracle在段的区片分配上为用户提供了很大的灵活性 然而如果未能正确使用创建表空间和数据对象的各个可选择参数 则在最后将不可避免的要面对区片碎片的问题 Oracle 的Bhaskar Himatsingka 和 Juan Loaiza 为此提出了SAFE（Simple Algorithm for Fragmentation Elimination ）配制规则 通过遵循这套规则 区片级碎片可以完全的避免 而实际上 Oracle i引入的新特性 Local Managed Tablespace就是SAFE规则在Oracle Server的内置实现 SAFE原则概括起来包括

对每个表空间上的段使用相同的区片尺寸 段参数INITIAL=NEXT PCTINCREASE= 可以通过使用Create Tablespace 的 MINIMUM EXTENT 子句来确保分配的区片是此参数的倍数

仅在表空间级指定INITIAL NEXT参数 在创建数据段时不要指定这些参数

区片的大小根据段大小来确定 原则是均衡顺序扫描的效率和空间的利用率 同时确保段的区片数目控制在 之下 根据此原则 在进行相应测试之后 确定以下区片选取规则

段大小(Oracle ) 区片大小(Oracle ) 段大小(Oracle ) 区片大小(Oracle ) &M K &M K M G M M G M &G M &G M

有此数据库中可以只使用三种区片大小的表空间 在对象创建之前需对其大小进行评估 并放到相应的表空间中

Oracle 引入了本地管理表空间 它在管理和性能上都优于传统的字典管理表空间 它已融合了规则 要使用此特性 在CREATE TABLESPACE语句中指定EXTENT MANAGEMENT LOCAL子句

段的区片数目上限应在 之下 DML *** 作在此区片数目范围内不会有明显的性能差异 但某些DDL *** 作的速度则与区片的数目关系较大 因此合理的区片数目应保持在 之下 对于持续不断扩展的段 应监控区片数目 在必要时移至其它表空间

对于特别大的数据段应控制在 G G（Oracle 为 G G）之间 它们应存放到单独的表空间上 同时对于这些特大段应考虑使用分区拉提高性能

用户的临时表空间应使用TEMPORARY类型

当系统的事务规模比较均衡时可以对回滚段使用OPTIMAL参数 否则应避免制定OPTIMAL参数 而定期监控回滚段的大小 并在必要时重建

临时段和回滚段绝对不要将用户数据存放到SYSTEM表空间 它是专为永远不会Drop和Truncate的系统数据对象而设计的

创建表空间时指定数据文件的大小应=区片整数倍+ 数据块 对于Local Managed Tablespace则为区片整数倍+ K

当表空间使用统一的区片大小时 不要对其进行空间整理 重整的结果不仅耗费精力而且可能会使性能变差 对于未使用统一的区片尺寸的表空间应通过Export/Import重整

i 提供了Alter Table …Move [Tablespace…]命令可用于快速重整表 Alter Index …Rebuild…[Tablespace…] 命令可用于快速重建索引

有关使用单个区片的误导

在许多关于碎片整理的文档中建议在Export时使用Compress=Y选项 将表中的所有数据调整到一个区片中 期望在Import后获得良好性能 由此让许多人产生一个观点 认为当表中数据全部存放到一个区片中时 可以获得良好性能 实际上单区片段只在以下条件成立时 才具有优越性

数据主要以（全段）扫描方式访问

段所对应的数据块在物理磁盘上连续存放 Oracle可以发布较大的顺序磁盘读 *** 作

通过对这两条进行分析可以发现 一方面数据库中大部分表是通过索引来访问 另一方面现在的数据库文件一般在物理上使用了RAID 或RAID + 技术 数据以条带化方式分布到多个物理磁盘上 逻辑上的单个区片和多区片在物理上并无本质上的区别 另外 从Oracle的角度来看 管理几百个区片的段是非常轻松的并不会有性能的下降 由此可见将整个段放到一个区片中并无明显好处 而这种做法却会导致表空间碎片的产生

三 表数据段的使用

表空间的组织

Heap表的空间由一系列区片链接而成 每个数据块除块头外其余部分可用于存放数据 在创建表时可以指定以下参数

PCTFREE 块中保留用于UPDATE *** 作的空间百分比 当数据占用的空间达到此上限时 新的数据将不能再插入到此块中

PCTUSED 指定块中数据使用空间的最低百分比 当一个块在达到PCTFREE 之后经历了一些DELETE *** 作 在其空间使用下降到PCTUSED后便可以重新被用于INSERT数据 这就是PCTFREE/PCTUSED参数的含义

调整PCTFREE PCTUSED参数的目标一方面是提高性能 另一方面则主要是提高空间使用效率 避免出现块中存在有许多未用的空间 但却无法找到一个块可以被用于插入新数据行的情况发生

PCTFREE的使用

在Oracle中表的每一行数据由唯一的ROWID标记 而Oracle支持的数据类型中有一些长度是可变的 如VARCHAR 当对这些数据进行UPDATE时 如果块中的可用空间不能容纳UPDATE后的数据行时 Oracle将会把此行移到其它数据块 同时保留此数据行的ROWID不变 并在原有块中建一指针指向行迁移后的位置 在这种情况下读取一行数据将需要访问 个数据块 从而导致性能下降 PCTFREE保留的空间就是为确保更改后的数据行可以仍存放于原有数据块中 避免行迁移的情况发生

由此 如果PCTFREE设置不足时可能产生行迁移 而另一方面如果PCTFREE设置过高 将会造成空间浪费 因此正确设置PCTFREE需要对表中数据的使用进行分析 对于数据长度不会变化或极少更新的情况 可以采用较小的PCTFREE 对于其它大多数情况应采用稍大的PCTFREE（PCTFREE的缺省值是 如果不好估计需预留的空间 可以使用 的范围） 不要为节约块中的空间而使用较小的PCTFREE值

PCTUSED的使用

当块的使用的空间下降到PCTUSED后 此块被重新放回空闲链表（Freelist）中 作为后续Insert的候选块 同样 设置PCTUSED需要视数据行的特性和Insert Update Delete的模式而定 但必须遵守的原则是 db_block_size * （ PCTFREE PCTUSED）必须比行的长度大

对于数据行长度变化较大的情况 应使用最大行长度来计算PCTUSED 并且应使用较低的PCTUSED值 因为在执行Insert时 如果数据块的可用空间不能装下一行数据 当块的使用的空间是在PCTUSED之上 Oracle将把此块从Freelist中移走 当块的使用的空间是在PCTUSED之下 Oracle将会扩展段空间 因此 PCTUSED如果设得过高 将导致段的不断扩展

lishixinzhi/Article/program/Oracle/201311/18776

因为oracle中的内容非常多，常用的只是很小很小一部分。

很有可能你碰到一个问题，大家都没有使用过的地方。

那么必须要查看oracle文档。

而oracle文档是全英文的，oracle只有白皮书有中文翻译，另外可能有一些资料，在oracle公司内部有一点点非正式的翻译，不外传的。

其余的只能看英文文档，文档内容非常多，比如11G的文档，html格式的，基本没图片，就将近2G。

而且如果有问题咨询oracle工作人员，邮件等都是纯英文的。

ORA-1555通常是一个偶然出现的错误。有时在发生了该错误以后，重新运行该任务就有可能不再碰到类似的错误。这个错误最麻烦的是它并不会立刻发生，运行时间长的任务在错误失败以前可能已经运行了一段时间了(可能几个小时)。只是简单地重新运行该任务并不能保证它能成功，可能在运行了一段时间以后仍然失败。

1 原因分析

ORA-1555错的根本原因是因为oracle要保证读一致性。读一致性是指当有多个用户对一个数据块内的行进行修改时，这些块变“脏”或处于变化之中直到被确认。在被确认以前，它们对事务中的所有语句都是可见的，但是对别的事务或语句而言是不可见的。一旦确认以后，对所有后继的事务或语句就都是可见的了。但在事务被确认前的语句不能看到修改，因为这些修改还未发生。

例如，事务T 1(如对某大表的exp *** 作)在2 2 ：0 0开始而事务T 2(如对同一大表的update *** 作)在2 2 ：0 1时开始，因为T 1需遍历一个很大的表，其读取要花很长的时间，而T 2可能对同一个表中的数据进行基于索引的更新 *** 作。这样， T2可能在几秒钟之内完成，而T 1可能要运行很长时间，假定4 0分钟。当T 1到达T 2做过修改的地方时(根据当前的S C N时间戳可以识别出新作的改变)，尽管T 2所进行的写已经被确认，但为了保证读一致性,它不会读到修改后的数据,它只访问在2 2 ：0 0时的数据，在2 2 ：0 1时所做的改变不能被读取 。T 1从回滚段中读取改变前的数据以保证读一致性。但因为事务T2已经提交，T2事务使用的回滚段oracle认为已经可以重新利用，当回滚段太少或事务较密集时，oracle有可能会用新事务覆盖掉原来T2事务的回滚段，这时T1事务读到被T2修改过的数据时，再从回滚段中就无法找到修改前的数据，这时就会报ORA-1555,snapshot too old错。

下面我们可以结合实例来将此过程回溯一遍：

(1)事务T1在22点开始执行了对某一个大表Test1的exp *** 作(Test1表数据量可能有几千万甚至更多)，那么按照经验，此 *** 作可能需要执行40分钟左右或更长

(2)事务T2在22点01分开始执行对Test1表某行的update *** 作，并且 *** 作条件上有索引(将col1为00的行，col2值由90修改为100)，故此 *** 作很快完成，比如5秒钟完成 *** 作并commit

(3)此时事务T2已经执行完毕，而事务T1还在执行中

(4)当事务T1需要将col1为00的行导出为dmp文件时，Oracle为了保证读一致性，即T1导出的必须是22点时数据库表的值，故col1为00的行对于T1任务来说值仍然为90，而非100

(5)由于T2事务在22点02分前就已经做完(提交)，并且T2认为回滚段是可以重新利用的

(6)如果此时由于回滚段太少或业务量较密集，oracle就可能会重新利用刚才T2事务所使用的回滚段。这时T1事务读到此处时，就会造成无法找到回滚段中修改前的数据，产生错误。

数据库一致性(Database Consistency)是指事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。

保证数据库一致性是指当事务完成时，必须使所有数据都具有一致的状态。在关系型数据库中，所有的规则必须应用到事务的修改上，以便维护所有数据的完整性。

保证数据库的一致性是数据库管理系统的一项功能.比如有两个表(员工/职位),员工表中有员工代码、姓名、职位代码等属性，职位表中有职位代码、职位名称、职位等级等属性。你在其中员工表中进行了插入 *** 作，你插入了一个新员工的信息，而这个新员工的职位是公司新创建的一个职位。如果没有一致性的保证，就会出现有这么一个员工，但是不知道他到底担当什么职责！这个只是它的一个小小方面。

读一致性也是数据库一致性的一个重要方面，在实际中，我们会遇到这种情况：我们对一个表中的某些数据进行了更新 *** 作，但是还没有进行提交，这时另外一个用户读取表中数据。这个时候就出现了读一致性的问题：到底是读什么时候的数据呢？是更新前的还是更新后的？在DBMS中设有临时表，它用来保存修改前的值，在没有进行提交前读取数据，会读取临时表中的数据，这样一来就保证了数据是一致的。(当前用户看到的是更新后的值)

但是还有一种情况：用户user1对表进行了更新 *** 作，用户user2在user1还没有进行提交前读表中数据，而且是大批量的读取(打个比方：耗时3分钟)而在这3分钟内user1进行了提交 *** 作，那又会产生什么影响呢？这个时候怎么保证读写一致性呢？这个时候DBMS就要保证有足够大的临时表来存放修改前的数值，以保证user2读取的数据是修改前的一致数据。然后下次再读取时候就是更新后的数据了。

个人认为：从逻辑上来说：当数据库存在没有结束的事务时，数据库就是不一致的。所以要保持数据库的一致性，就是要确保某一时刻没有事务在数据库上执行即可。例如一般说的数据库一致性备份，就需要在数据库关闭之后再进行。当然从物理存储结构考虑一致性的问题会比较复杂一些，因为涉及到很多文件的修改等问题，例如Oracle中的各类SCN的设置。总的来说，可以简单得认为：所有事务结束后数据库就是一致的。

所以说：数据库的一致性的前提是首先要保证事务的一致性。事务的一致性则需要通过并发控制、锁、隔离性等限制进行保证，具体工作机制可以参见前文，这里就不再研究了。

对于Oracle的一致性检测，只需在mount到open阶段，运行命令recover database即可，DBMS就可以把在线日子文件同步到数据库文件中去。这样Oracle数据库才能正常打开使用。

读完整性，撤销记录，事务

为了维护多版本数据一致性模型，当一个表的数据被更新（写）的同时也在被查询（读）时，Oracle必须创建一个维持读完整性的数据集。当更新发生时，被更新数据的原始值被记录在数据库的undo records中。在事务中的更新 *** 作没有被提交之前，用户查询正在被修改的记录时只能看到她们的原始值。Oracle结合SGA中以及撤销记录中的信息为查询表数据的用户构建了一个 维持读完整性的视图[此视图非彼视图]。

当事务提交后，事务中对数据的修改才被永久记录。在用户事务提交后执行的语句九只能查询到提交后的数据了。

事务是Oracle实现读完整性的关键。事务是一组SQL语句（这组语句或者被一起提交，或者都不被提交），事务的作用是：决定了为查询用户生成的保持读完整性的视图的起始点

控制着被一个事务修改过的数据何时可以被数据库中其它进行读写 *** 作的事务看到

---