在Oracle数据库中，其表空间管理主要有两种模式，分别为“字典托管”模式和“本地托管”模式。这两种模式虽然对于终端用户来说，可能没有明显的差异。但是从数据库工程师角度来讲，其差异是非常巨大的。最重要的一点，如果采用本地托管模式的话，从性能上来讲要优于字典托管模式。在这篇文章中，笔者就给大家介绍一下，如何通过这个管理模式的转变来提高Oracle数据库的性能，以及转换时注意的内容。

　　一、转换过程中的注意点及实现方法

　　如上图所示，Oracle数据库中表空间可以分为系统System表空间和非系统表空间。这两种表空间都支持字典托管模式和本地托管模式。但是由于系统表空间的特殊性，将其从字典托管模式转换到本地托管模式时，有一些特别需要注意的内容。笔者等一下会特别强调这一方面的事项。

　　根据经验，笔者发现在Oracle11G或者10G数据库中执行表空间的转换，主要有“迁移”和“重建”两种方法。不过笔者这里并不建议采用迁移的方案。因为通过迁移的方式将表空间从字典托管模式转换为本地托管模式的时候，盘区映射将会移入到表空间的数据文件头中。注意，此时系统是不能够使用自动分配或者统一盘区尺寸管理。也就是说，无法使用本地托管模式的优势，无法有效的减少碎片。在这种情况下，还必须为表空间中的每个段指定存储语句。不过迁移方法也并不是一无用处，其能够在一定程度上带来性能的提升。不过其提升的效果没有“重建数据库”的方法那么好。另外特别重要的是，数据库系统将无法从迁移总获得策略方面的优势。如无法像本地托管模式那样对盘区进行有效的操作。

　　所以笔者这里建议大家采用的是“重建数据库”法。虽然这个方法在操作上要比迁移方法复杂一点，但是最终带来的效果还是蛮客观的。这也就是说，产出要大于投入。其实这个重建数据库的过程也就是四个步骤。

　　第一步：导出表空间中的段。在Oracle数据库中，可以在命令行模式下使用Expdb等语句将数据库中已有的段导出来。如果数据库管理员对于命令行不熟悉的话，也可以借助其管理控制台来导出所有的数据段。

　　第二步：删除原有的表空间。如果数据库管理员仍然需要用到原来的服务器，那么就需要将这个服务器上原有的表空间删除。注意，这里采用的不是迁移方案。所以不是像操作系统升级一样，在原版本的功能上进行升级。而是彻底的删除之后，再重新安装。为了减少文件碎片影响转换后的效果，最好对相关的磁盘分区再采取格式化的操作。尽量提供一个干净的环境。

　　第三步：重建建立表空间。在建立表空间的时候，可以采用关键字management local来说明要创建的是本地托管表空间。在重新创建表空间的时候，笔者有一个小小的建议。即在创建表空间之前，最好能够先分析一下数据段的大小。然后尽可能的巴一个单独的表空间分割成几个不同大小的盘区，以容纳不同大小的段。这可以有效的减少碎片，从后提高数据库的性能。虽然这个分析数据段的过程在这个转换过程中并不是必需的。但是这个过程本来就是为了提高数据库的性能，所以在这个过程中同时考虑数据段的大小，可以提到1加1大于2的效果。所以笔者还是非常推荐这么做的。

　　第四步：重新导入段。表空间建立好之后，再将刚才导出的段再导入到数据库中。这种重建的方法就相当于一开始采用的就是本地托管表空间。为此可以避免因为“字典托管”模式而造成的不兼容现象。也就是说，可以将本地托管模式的优势发挥到最有效的状况。

　　　为此只要条件允许(如有这方面的技术人才或者能够容忍一段时间内的停机)，笔者建议采用重建表空间的方式来实现管理方式的转换。另外如果企业资金比较雄厚的话，为了缩短这个停机时间，可以用新的服务器来进行转换。即在新的服务器上部署好Oracle数据库系统，并创建好本地托管表空间。然后再将数据从旧的服务器导出，然后导入到新的服务器即可。此时根据数据量多少，其停机的时间可以控制在比较短的时间之内。

　　二、系统表空间的转换

　　系统表空间也可以支持字典管理模式与本地托管表空间管理模式。为了提高系统表空间的性能，笔者建议也最好将系统表空间转换到本地托管表空间模式。不过这个转换的过程跟其他非系统表空间转换的方式有所差异。注意Oracle系统虽然没有明文限制对于系统表空间不能够使用导出、导入手段来重建表空间。但是根据Oracle数据库专家的使用反馈，发现这种方法对于系统表空间不是很有效。也就是说，在导入导出重建的过程中，经常会遇到各种各样难以理解的问题。为此对于系统表空间来说，不能够采用这种方法来进行转换。

　　为了解决这个系统表空间的转换问题，Oracle系统专门设计了一个程序包，用来完成系统表空间的管理模式的转换。这个程序报的名字是：Tablespace_Migrate_To_Local。调用这个系统提供的程序包，可以完成对系统表空间从字典托管模式到本地托管模式的转换。

　　不过再采用这个程序包的时候，有一些限制必须要遵守。即在执行这个操作之前，需要遵守一些限制条件。主要需要注意以下几个内容。

　　一是数据库的启动模式，要采用受限制的模式来启动数据库。二是必须要将计划进行读写转换的所有表空间迁移到本地托管表空间。三是数据库中所有用户的默认临时表空间必须是不同于System表空间。通常情况下，只要数据库部署恰当，这些条件都能够一一满足。但是如果有些数据库管理员，在刚开始设计数据库的时候，就不注重设计的合理性，则可能会遇到问题。如在创建用户的时候，将系统表空间作为用户的默认临时表空间。这在技术上没有限制，也是可以的。但是在遇到这个转换的作业时，问题就体现出来了。总之在转换系统表空间之前，需要确认要转换的目标数据库能够满足这些条件。

　　对于非系统表空间，如用户表空间在转换过程中，就没有这么多的限制。

　　三、转换后可以带来性能的提升

　　本地托管模式相比字典托管模式而言，其主要的优势体现在以下两个选项上：自动分配和统一管理机制。自动分配是指根据一定的算法，在段大小增长时增加盘区的尺寸。此时如果数据表已经被定义为具有不恰当的较小盘区尺寸的时候(由于企业的数据增长具有不确定性，这种情况会精经常发生)，数据库会自动增加表的下一盘区尺寸。通过这种机制，就可以减少表的全部盘区数量，从而有效的降低碎片，提高数据库的性能。

　　而统一管理机制，主要是用来解决存储字句的问题。在统一盘区管理机制中，表空间的所有盘区都使用在创建表空间时指定的相等大小进行分配，所有就需要考虑在段创建时再存储语句中如何指定存储子句。这里需要注意的是，如果采用迁移的方案，将表空间从字典托管模式转移到本地托管模式，是无法享受到这个策略优势的。

　　总之，在部署数据库过程中，尽量采用本地托管模式。而在转换的过程中，则尽量采用重建表空间的方式来进行。这么做的目的只有一个，就是给本地托管模式创造一个干净的环境，在最大程度上发挥本地托管模式的优点。