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数据库无响应故障，简单地讲就是数据库实例不能响应客户端发起的请求，客户端提交一个SQL后，就一直处于等待数据库实例返回结果的状态。更严重的现象是客户端根本不能连接到数据库，发起一个连接请求后，一直处于等待状态。Oracle数据库无响应故障怎么处理呢?下面跟我一起来学习Oracle数据库无响应故障的处理方法吧!

无响应的故障现象一般有以下几种：

1.Oracle的进程在等待某个资源或事件

这种现象一般可以从V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等动态视图中检查进程正在等待的资源或事件，而被等待的资源或事件，一直都不能被获取，甚至是很长时间都不可获得。如果这个正在等待的进程持有了其他的资源，则会引起其他的进程等待，这样就很可能引起实例中大范围的会话发生等待。由于进程在等待资源或事件时，通常都处于SLEEP状态，消耗的CPU资源非常少(在等待latch时要稍微多消耗一些CPU资源)，所以从OS来看，CPU的消耗并不高，甚至是非常低。

这种因为等待而引起的个别进程Hang，相对比较容易处理。

2. OracleProcess Spins

所谓Spin，就是指Oracle进程中的代码在执行某个过程时，陷入了循环。在V$SESSION视图中，往往可以看到Hang住的会话，一直处于“ACTIVE”状态。对于这样的会话，用“alter system kill session ‘sid,serial#’”命令也不能完全断开会话，会话只能被标记为“killed”，会话会继续消耗大量的CPU。进程Spins由于是在做循环，CPU的消耗非常大，从OS上明显可以看到这样的进程，通常会消耗整个CPU的资源。

而对于这样的Hang住的会话，处理起来相对比较复杂，并且为了从根本上解决问题，需要超过DBA日常维护所需要的技能。

从故障范围来看，无响应故障可以分为以下几种情况：

1. 单个或部分会话(进程)Hang住

这种情况属于小范围的故障，业务影响相对较小，一般来说只会影响业务系统的个别模块。在一个多应用系统的数据库上面，如果Hang住的会话比较多，则影响的可能是其中的一个应用系统。这里有一个例外，如果Hang住的进程是系统后台进程，如pmon、smon等，则影响的范围就非常大了，最终甚至会影响整个数据库及所有应用系统。还有值得注意的是，即使是少部分会话Hang住，也要及时处理，否则极有可能会扩散到整个系统。

2. 单个数据库实例Hang住

这种情况造成的影响非常大。在这个实例上的所有应用系统均受到严重影响，并且在找到根源并最终解决问题之前，数据库实例往往须要重启。

3. OPS或RAC中的多个实例或所有实例都Hang住

在这种情况下，即使是OPS或RAC，都已经没办法提供高可用特性了。使用这个数据库的所有应用系统将不能继续提供服务，这种情况往往须要重启。

无响应故障成因分析

Oracle数据库无响应，一般主要由以下几种原因引起：

1. 数据库主机负载过高，严重超过主机承受能力

比如应用设计不当，数据库性能低下，活动会话数的大量增加，导致数据库主机的负载迅速增加，数据库不能正常 *** 作，并最终Hang住主机物理内存严重不足，引起大量的换页，特别是在SGA中的内存被大量换出到虚拟内存时，数据库实例往往就会Hang住。

2. 日常维护不当、不正确的 *** 作引起数据库Hang住

比如归档日志的存储空间满，导致数据库不能归档，引起数据库Hang住在一个大并发的繁忙的系

统上，对DML *** 作比较多的大表进行move、增加外键约束等 *** 作也可能使系统在短时间内负载大幅升高，并引起数据库系统Hang住不正确的资源计划(Resource Plan)配置，使进程得不到足够的CPU等。

3. Oracle数据库的Bug

几乎每个版本都存在着会导致数据库系统Hang住的Bug，这些Bug会在一些特定的条件下触发，特别是在RAC数据库中，引起数据库Hang住的Bug比较多。

4. 其他方面的一些原因

比如在RAC数据库中，如果一个节点退出或加入到RAC的过程中，当进行Resource Reconfiguration时，会使系统冻结一段时间，也有可能使系统Hang住。

以上所描述的几种常见的会导致Oracle数据库实例Hang住的原因中，大部分的情况是可以避免的，只要维护得当，一般不会出现这种故障。对于Oracle数据库Bug所导致的数据库无响应故障，由于是在特定的情况下才会触发，所以如果能够尽量对数据库打上最新版本的补丁，并且熟悉当前版本中会导致系统Hang住的Bug以及触发条件，就能够最大限度地避免这种故障的发生，提高系统的可用性。

那么，在数据库Hang住的情况下，如何去分析并发现导致问题的根源?一方面，由于系统Hang住会导致业务系统不可用，为了能够尽快地恢复业务，须快速地判断问题所在，然后Kill掉引起故障的会话和进程，或者数据库实例不得不重启以迅速恢复业务但另一方面，如果只是重启数据库或Kill会话和进程来解决问题，在很多情况下是治标不治本的办法，在以后故障随时可能会出现。如何在二者之间进行抉择呢?对于数据库Hang故障的处理，首先是尽可能地收集到系统Hang住时的状态数据，然后尽快地恢复业务，恢复业务后分析收集到的数据，找到数据库系统Hang住的真正原因，然后再进行相应的处理。下一节将详细描述数据库系统Hang住后的处理流程。

无响应故障处理流程

对于Oracle无响应故障的处理，我们可以按下图所示的流程进行。

值得注意的是，上图并不是一个完整的Oracle数据库故障处理流程图，只是处理Oralce数据库无响应这一类特定的故障的流程，只列出了针对这一特定类型故障处理时的关键处理点。不过既然是故障，所以这类故障的处理流程与其他故障的处理流程，有着非常相似的地方。

下面是整个流程的详细说明：

1. 在出现数据库无响应故障后，首先确认系统的影响范围，如上节所描述的'，是部分业务系统或模块还是所有的业务系统都受影响，是不是整个实例或多个实例都无响应。同时应询问系统维护和开发人员，受影响的系统在出现故障前是否有过变动，包括主机硬件、 *** 作系统、网络、数据库以及应用等。有时一个细小的变动就可能导致出现数据库Hang住这样严重的故障。曾经遇到一个库，应用只是修改了一个SELECT语句就导致了数据库Hang住。

2. 为了避免由于网络、数据库监听或客户端因素影响分析，建议都登录到主机上进行 *** 作。

3. 如果主机不能登录(为了避免干扰流程主线，这里不讨论如网络问题这样也会导致不能连接的故障)，尝试关闭出现问题的业务系统，甚至是所有的业务系统。如果关闭了所有的业务系统之后，仍然不能连接，则只有考虑重新启动数据库主机。在数据库主机重新启动后，使用 *** 作系统工具或OSW等长期监控 *** 作系统的资源使用，同时监控Oracle数据库的性能和等待等。

4. 登录上主机后，先用top、topas等命令简单观察一下系统。看看系统的CPU使用、物理内存和虚拟内存的使用、IO使用等情况。

5. 使用SQLPLUS连接数据库，如果不能连接，则只能从 *** 作系统上观察系统中是否有异常的现象，比如占用CPU过高的进程。使用gdb、dbx等debugger工具对数据库进行system state dump使用strace、truss等工具检查异常进程的系统调用使用pstack、procstack等工具察看异常进程的call stack等。

6. 使用SQLPLUS连接上数据库后，进行hanganalyze、system state dump等 *** 作或检查等待事件、异常会话等正在执行的SQL等待。

7. 找到故障产生的原因，如果暂时找不到原因，尽量收集数据。

8.确良如果应用急须恢复，可通过Kill会话、重启数据库实例等方式，先恢复应用。

9. 根据最终诊断结果，对数据库升级打补丁，或者修改应用等方式从根本上解决问题。

怎样避免数据库出现无响应故障

作为Oracle数据库DBA，除了处理故障之外，更重要的是如何预防故障的发生。根据前面对数据库无响应故障的成因分析，在日常的维护工作中，须做到以下几点：

1. 进行正确的维护 *** 作

很多的数据库无响应故障都是由于不正确的维护 *** 作引起的。应避免在业务高峰期做大的维护 *** 作，比如像move、加主外键约束等会长时间锁表的 *** 作。如果的确需要，尽量使用正确的 *** 作方法。比如用ONLINE方式重建索引建主键、唯一键约束时先建索引，然后在建约束时指定新建的索引，等等。也就是保证系统的并发性、可伸缩性，避免系统串行 *** 作的出现。

2. 优化应用设计，优化数据库性能

为避免性能问题导致在业务高峰期数据库不能及时有效处理来自业务的请求，甚至于完全Hang住。对于数据库中存在串行访问的部分进行优化，比如latch、enqueue，还包括不合理的sequence设计等。特别是在RAC数据库中，严重串行访问等待往往更容易引起严重的性能问题。优化应用设计，使数据库具有更好的可伸缩性和并行处理能力，能够有效地避免性能问题引起的数据库Hang住。

3. 利用监控系统随时监控系统负载

遇到系统负载过高，内存不足，OS中虚拟内存换页很频繁等情况时，及时采取措施监控Oracle数据库的核心进程，如pmon、smon等，看是否有异常，如过高的CPU消耗。出现异常应立即处理监控归档空间和日志切换监控数据库中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。

4. 为数据库打上补丁

很多的无响应故障是由于Oracle的Bug引起的，数据库DBA应关注当前版本中有哪些Bug会导致数据库Hang住，尽量为数据库打上解决这些Bug的补丁。

---