oracle数据库存储空间的最小存储单位是

您好，Oracle数据库存储空间的最小存储单位是数据块（Data Block）。数据块是Oracle数据库中最基本的存储单位，是在磁盘上分配和管理存储空间的最小单位。每个数据块的大小是固定的，通常为多个字节的倍数，例如8KB、16KB等。在Oracle数据库中，数据块是由Oracle引擎自动管理的，它们被用来存储表、索引、视图、存储过程等数据库对象的数据。数据块的大小是根据应用程序需要和数据库性能进行权衡而确定的，一般来说，较小的数据块可以提高数据库的并发性和响应速度，但也会增加系统开销和存储空间的浪费。

除了数据块，Oracle数据库还有其他存储单位，例如段（Segment）、表空间（Tablespace）等。段是由数据库对象占用的一组数据块组成的逻辑单位，例如表、索引、视图等。表空间是由一个或多个数据文件组成的逻辑存储单元，它用于存储数据库对象的数据和元数据。在Oracle数据库中，表空间是分配和管理存储空间的最高级别单位，它可以跨多个物理设备和 *** 作系统文件系统。

ORACLE数据库中 表是最基本的内容 可以说 表设计的好坏直接跟数据库的性能相关 所以 在设计表的时候 除了要遵循其固有的数据库准则之外 还需要看个人的数据库管理经验 下面我就把这些经验分享一下 或许对大家有所帮助 一 表该存放在哪里? 我们都知道 在ORACLE数据库中 使利用空间这个概念来管理表对象的 在数据库创建的时候 数据库中已经建立了一些表空间 那么当我们新建立表的时候 这个新表的位置该放在什么地方呢?这就好像吃饭时的坐的位置一样 是有讲究的 一般来说 我们在新建表的时候 至少要遵循如下建议 一是在数据库创建的时候 在数据库中已经有了一个SYSTEM的表空间 一般情况下 这个表空间中 只包含数据字典及Oracle系统对象 如果我们将我们的表建立在这个空间上的话 那是要降低数据库的性能的 所以 一般我们是不建议用户把表格建立在这个空间上 但是 若我们不只一个人维护数据库 如有八个人共同设计数据库系统时 如何才能保证其他用户不在SYSTEM表空间中建立数据库表格呢?最好的办法就是通过权限控制 如我们可以给每个数据库设计人员指定一个默认的表空间 让他们只能在这个表空间中建立表格 如此的话 就能防止他们在SYSTEM表空间中建立自己的数据表格 从而对数据库的运行性能产生不良影响 所以 若给每个用户设置默认表空间的话 那么用户在建立具体的表时 不用具体指定表空间了 二是我们在为某个应用设计数据库的时候 最好先对表的空间进行规划 一般情况下 不要把数据表随意的分散到不同的表空间中去 如我们在为一个ERP系统设计数据库的时候 若把采购部门相关的表跟销售部门相关的表放到两个不同的表空间中去 这是不明智的做法 这么处理的话 会降低某些数据库管理和维护 *** 作的效率 如数据的备份与恢复 *** 作而且 也无法集中管理属于某个特定应用的数据 所以 我们一般建议 在规划数据库表空间的时候 把相同应用的表放在同一个表空间中去 如果要区分不同部门或者不同模块的表的话 我们可以在表的命名上动脑子 如我们在设计ERP系统的数据库中 可以根据其应用模块的不同 在前面加上前缀来进行识别 如跟系统基本配置相关的表 我们可以用AD为前缀而跟销售部门相关的表 我们可以加上SA前缀等等 如此的话 这些表具体是属于哪个模块的 就一清二楚了 完全没有必要为此设置不同的表空间 这是ORACLE数据库初学者经常会犯的错误 主要是对ORACLE表空间的定义不是很熟悉所导致的 二 对预计存储数量比较大的表时 要给与额外的重视 有些表非常的大 我们这边说的大 不一定是说结构复杂 而是指在这个表格中 预期会存储比较多的数据 为了提高对这个表格的处理效率 我们在事先要做出一定的安排 否则的话 后续对这些大表进行查询 插入等 *** 作的话 速度会很慢 所以 我们就有必要在数据库设计的时候 先预先估计一下表的数据存储量 把一些数据量大的表格 做一些额外的设置 如在ERP软件的数据库设置中 一般来说 产品数据与物料清单数据这两个表的数据量会比较大而从长远看的话 销售订单 采购订单 生产订单 记账凭证等这种单据类相关的表格其数据量也会比较大 一年两年可能感觉不出来 但是 到十年后 这个纪录数量就会很庞大 而像ERP系统这种大型的信息化管理项目 用个几十年时很正常的事情 而且 为了记录的完整性 也不建议用户把以前的数据删除 所以 为这种应用进行数据库设计的时候 要充分考虑这些大表的性能问题 具体的来说 设计大表的时候 可以考虑遵循如下的建议 一是不要为大表设置存储的限制 在ORACLE数据库中 可以为每张表格设置存储配额限制 如此的话 表最大容量就不能超过这个限制 对于一些数据容量比较小的表格 这么设置时合理的 可以提高空间的利用率 但是 若数据量比较大的话 就不建议事先设置表的存储空间了 如ERP系统的销售订单表 其刚开始可能记录量很小 第一年预计只有 G的记录容量 但是 估计在十年后 这个记录容量就会达到 G了 在这种情况下 我们怎么来给其设置存储空间呢?一开就设置 G空间 这也是不合理的 而且 设置存储空间 就意味着有可能产生存储碎片 从而影响到数据查询的效率 所以 在数据库表的设计过程中 若某些应用的表可能会有比较大的数据容量时 建议不要对其存储空间做出任何的限制 二是要为这大表分配足够的临时空间 如我们使用ERP系统时 要查询产品资料信息 我们都知道 产品信息的话 有些企业这个纪录数非常的庞大 而且在查询时 我们还会经常的进行排序 *** 作 如有时候会按照产品编码对查询出来的数据进行排序 当记录少的话 还好但是 当记录多的话 这个排序动作 要求具有比较大的临时存储空间 所以 当某个表预计会有很大的记录数量的时候 我们就要给其分配足够多的临时空间 临时空间的存储参数设置取决于临时表空间的默认储存参数设置 我们可以更改这些参数 以达到我们对要求 若没有给大表分配足够多的临时空间的话 则排序的动作将会很慢 而且很可能不成功 三是要考虑将表与表的索引分离存放 大表所对应的索引通常也比较大 一般来说 索引的数量是随着表记录的数量增加而增加 两者是接近于一个正比例的关系 所以 通常表的记录容量大的时候 索引数量也会很庞大 针对这种情况 我们考虑突破我们上面讲的表空间的规则定义 而考虑把表和他的索引分别存储于不同的表空间中 甚至在条件允许的情况下 分别存储于不同的硬盘中 这么做的好处是什么呢?最大的好处是让索引比较容易的获得所需要的连续的存储空间 从而提高输入输入的效率 通俗的说 就是可以提高数据的查询效率 如不这么处理的话 查询大容量的记录的话 数据库可能需要花费 秒而如此设计的话 就可能把时间缩短为 秒 这是一个很明显的性能改善 三 如何给表命名? 上面我在讲如何为表分配存储空间的时候 已经讲到过这方面的问题 下面 我就将对这个问题进行详细的描述 以帮助数据库管理员掌握一套好的数据库命名规则 首先 毋庸置疑的 在为标命名的时候 要遵循ORACLE数据库的基本命名规则 如不能以数字开头为表命名 如不能利用数据库的关键字为表命名 如表的名字不能重复等等 这些是最基本的要求 就不用我多费口舌了 除了要遵循这些基本的命名规则外 在实际工作中 为了数据库后续的维护等方面出发 我们还是要遵循一些额外的规则 这些规则跟ORACLE定义的规则不同 我们所讲的规则没有约束力 可以说 只是业界的一些共识而已 你若不怎么处理 ORACLE数据库也不会说你错误 只是后续维护的时候 会比较麻烦而已 一是在对数据库命名的时候 最好能跟体现表的分类关系 如最常见的 我们在设计数据库的时候 表都是按系统的具体模块来区分的 如根据前端系统要求的不同 数据库的表大致可以分为系统基本配置表 销售模块表 采购模块表 报表模块表等等 我们可以根据这些模块的不同 分别给与不同的前缀来区分 这么做的好处是很明显的 如一看到表最大名字 就可以知道这个表是属于哪个应用的 哪个模块的 这无疑可以提高数据库设计与前台软件开发的效率 同时 数据库中默认的排序规则是按名字来排序的 所以 为表格设置类别前缀的话 可以把同一类的表格排在一起 方便我们察看 二是对表格命名的时候 要考虑可读性 而不能随便阿狗阿猫的乱取名字 最常见的是 那些刚学数据库的人 在表命名的时候 如要建几张测试表 就会随便命名如TEST TEST 之类的 虽然这只是测试 但是 也不符合我们的命名过则 要做测试的话 那就以TEST开头 然后后面加上具体要测试的内容 如此的话 我们才可以通过表的名字知道该表具体的用途 而不用打开表去看里面具体的结构或者注释才能知道我们需要的信息 所以 在设计表的名字的时候 还要关注一下其的可读性 lishixinzhi/Article/program/Oracle/201311/18317

为了保持其最强大和最灵活数据库的地位 Oracle在最近发布的几个版本里一直都在创建新的机制来对表格和索引的存储进行简化和分块 从Oracle i开始 Oracle开始在tablespace内部将对象管理进行自动化 第一个增强的地方原来叫做本地管理tablespace（或者简写作LMT） 在LMT里 Oracle将tablespace里的信息从数据字典的表格空间里移出去 而直接将其保存到tablespace自身里 这在Oracle i里已经成为了一个事实的标准 因为它减轻了数据字典的负担

表格空间的第二个主要增强的是自动分段空间管理（ASSM） 它首次出现在Oracle i里 有了ASSM 链接列表freelist被位图所取代 它是一个二进制的数组 能够迅速有效地管理存储扩展和剩余区块（free block） 因此能够改善分段存储本质

管理空间的两种方法

让我们从比较这两种空间管理开始

本地管理tablespace（LMT）——LMT是通过把EXTENT MANAGEMENT LOCAL子句添加到tablespace的定义句法而实现的 和原来由字典管理的tablespace（DMT）不同 LMT会将扩展管理自动化 并保持Oracle DBA不会被用来指定管理扩展大小的NEXT存储参数 这个原则唯一的例外是在NEXT和MINEXTENTS一起用在表格创建的时候

自动区段空间管理（ASSM）——ASSM的tablespace是通过将SEGMENT SPACE MANAGEMENT AUTO子句添加到tablespace的定义句法里而实现的 通过使用位图freelist取代传统单向的链接列表freelist ASSM的tablespace会将freelist的管理自动化 并取消为独立的表格和索引指定PCTUSED FREELISTS和FREELIST GROUPS存储参数的能力

Oracle值得赞扬的地方是 这两个空间管理的方法都是可选的特性 而且Oracle的老手可能仍会使用更加详细的方法 只要他们愿意的话 要注意 位图区段管理在Oracle i里是可选的 而且只能在tablespace这一层实现 这一点是十分重要的 原有的系统还能够继续使用传统方法来管理freelist

位图freelist挑战传统的空间管理

在我讨论位图freelist和传统的空间管理之前 让我们看看位图freelist是如何实现的 我会从使用区段空间管理自动参数创建tablespace开始

create tablespace　 a *** _lmt_tsdatafile　 c:\oracle\oradata\diogenes\a *** _lmt dbf size　 mEXTENT MANAGEMENT LOCAL　 Turn on LMTSEGMENT SPACE MANAGEMENT AUTO Turn on ASSM

    一旦你定义好了tablespace 那么表格和索引就能够使用各种方法很容易地被移动到新的tablespace里 下面就是我进行创建的代码

create table　 new_custtablespace　 as *** _lmt_tsas　 select * from customeralter index cust_name_idx rebuild tablespace as *** _lmt_ts　

    要注意 当表格或者索引被分配到这个tablespace以后 用于独立对象的PCTUSED的值会被忽略 而Oracle i会使用位图数组来自动地管理tablespace里表格和索引的freelist 对于在LMT的tablespace内部创建的表格和索引而言 这个NEXT扩展子句是过时的 因为由本地管理的tablespace会管理它们 但是 INITIAL参数仍然是需要的 因为Oracle不可能提前知道初始表格加载的大小 对于ASSM而言 INITIAL最小的值是三个区块

关于一个万能的方法对于Oracle来说是否是最好的方法还有一些争论 在大型数据库里 单独的对象设置会带来性能和存储上的巨大不同 PCTFREE的问题

PCTFREE参数是用来指定数据块剩余空间大小的 这一空间为将来数据行的扩展而保留 如果PCTFREE设置得不得当 SQL的更新声明就可能导致大量的数据行碎片和断链

数据行在刚保存的时候还很小 而在后来进行了扩展 在这种情况下 PCTFREE的设置就显得尤其重要了 在这样的系统里 通常会把PCTFREE设置成等于 这就告诉Oracle要为数据行今后的扩展保留 ％的数据区段空间

PCTUSED的问题

对PCTUSED不正确的设置（例如设得太小了）会导致SQL插入声明性能的急剧下降 如果数据区块剩余空间不是很多 那么在SQL插入 *** 作的过程中就会产生过量的I/O 这是因为被重新使用的Oracle数据区块会被迅速地填满 从极端的角度来看 没有正确地设置PCTUSED会导致数据区块的剩余空间要比表格数据行的平均长度小 在这样的情况下 Oracle会五次尝试从freelist链取回区块 在五次尝试以后 Oracle会提升表格的水位 并为插入 *** 作腾出五个新的数据块

有了Oracle i的ASSM PCTUSED就不再控制表格数据块的重新链接阙值了 但是你必须依靠Oracle的判断来确定区块在什么时候会有足够的剩余空间放置到freelist里

尽管有了本地管理的tablespace和ASSM之后Oracle i会忽略PCTUSED FREELISTS和FREELIST GROUPS等参数 但是当它们用于表格定义的时候 Oracle还是不会给出错误信息

SQL>create table test_table (c number) tablespace a *** _test pctfree pctused storage ( freelists next m ) Table created

    如果你不记得带有ASSM的本地管理tablespace会略掉任何为PCTUSED NEXT和FREELISTS所指定的值的话 这将是一个十分严重的问题

使用ASSM的一个巨大优势是 位图freelist肯定能够减轻缓冲区忙等待（buffer busy wait）的负担 这个问题在Oracle i以前的版本里曾是一个严重的问题 现在让我们来仔细看看这个特性

在没有多个freelist的时候 每个Oracle表格和索引在表格的头部都曾有一个数据块 用来管理对象所使用的剩余区块 并为任何SQL插入声明所创建的新数据行提供数据块 当数据缓冲内的数据块由于被另一个DML事务处理锁定而无法使用的时候 缓冲区忙等待就会发生 当你需要将多个任务插入到同一个表格里的时候 这些任务就被强制等待 而同时Oracle会在同时分派剩余的区块 一次一个

有了ASSM之后 Oracle宣称显著地提高了DML并发 *** 作的性能 因为（同一个）位图的不同部分可以被同时使用 这样就消除了寻找剩余空间的串行化 根据Oracle的测试结果 使用位图freelist会消除所有分段头部（对资源）的争夺 还能获得超快的并发插入 *** 作（图A）

= ) window open( /sql/UploadFiles_ / / jpg )src= if(this width >)this width = if(this height >) this height = border= >

图A Oracle公司对使用位图freelist进行SQL插入 *** 作的测试结果

ASSM的局限性

尽管ASSM显示出了令人激动的特性并能够简化Oracle DBA的工作 但是Oracle i的位图分段管理还是有一些局限性的

一旦DBA被分配之后 它就无法控制tablespace内部的独立表格和索引的存储行为

大型对象不能够使用ASSM 而且必须为包含有LOB数据类型的表格创建分离的tablespace

你不能够使用ASSM创建临时的tablespace 这是由排序时临时分段的短暂特性所决定的

只有本地管理的tablespace才能够使用位图分段管理

lishixinzhi/Article/program/Oracle/201311/17754

---