把表空间从字典托管模式升级成本地托管模式

　　表空间有数据字典和本地托管两种管理模式。如果采用数据字典来维护的话，发生在数据库的段上并关系到盘区分配的操作(如扩展一个表)，将会导致对数据字典的操作。如果有很多带有盘区的表被操作时，数据字典将会成这些操作的瓶颈资源。可见，如果采用数据字典来维护表空间的话，那么数据库要花的代价就会很大。

　　为了解决这个问题，改善表空间的管理性能，Oracle数据库又推出了一种全新的表空间管理模式，即本地托管的管理模式。如果把表空间设置为本地托管，则这些盘区管理操作都回被重新分配到数据文件的位图块上。如此的话，数据库的每个标空间都只包含自己的盘区信息，可以使用快速散列进程访问技术来访问相关系悉尼，而不是使用比较慢的、基于表的查询访问。最关键的是，此时如果有很多带有很多盘区的表被操作时，数据字典将不会成为其性能的瓶颈。可见，在同等条件下，本地托管的性能要比数据字典维护模式的性能要高。

　　一、本地托管模式的两个特性。

　　本地托管模式除了在管理上跟数据字典模式有一定的差异外，还提供了两个比较有特色的选项，分别为自动分配与统一分配选项。这连个选项主要用来控制将盘区分配到段中的视线方式。如把这个方式设置为自动分配的话，Oracle数据库系统会采用一个内部的算法(这个算法数据库管理员不用了解)，在段的大小发生调整时(如段大小增大时)自动增加盘区的大小。也就是说，使用自动分配选项的话，当表空间中的段增大时，数据库系统会根据一定的规则来确定合适的下一个盘区的尺寸。这个算法的主要原理就是以盘区数量和扩展比例来作为系数并结合其他的一些参数来进行模拟计算。自动分配盘区大小的优势是很明显的。因为在刚开始部署数据库系统的时候，由于各方面原因的限制，要设置一个合理的盘区大小具有一定的困难。而现在采用了自动分配的话，如果刚开始盘区尺寸设置的太小，则数据库会随着后续需求的表换，而自动增加表的下一盘区尺寸，从而可以减少表具有的全部盘区数量。这在很大程度上可以提高数据库的性能。另外，采用自动分配选项的话，还可以保证段的数量不会超出其可以控制的范围，因为数据库会自动根据实际情况来进行调整。

　　而如果采用统一的盘区管理策略，则表空间中的所有盘区都使用在创建表空间时指定的相等大小进行分配，而不会考虑到其他因素，如不会考虑在段创建语句中设定的存储子句。也不会随着一些应用情况的改变而调整盘区尺寸的大小。显然，如果采用统一分配策略的话，那么在表空间规划的时候，就需要为其设置一个合理的盘区尺寸。

　　那么有人会说，既然统一分配这么麻烦，不会自动调节，那就都用自动分配策略好了。其实不能够这么绝对。可以说两个管理选项各有各的优点。自动分配的有点就是即时在表空间建立时没有设置合理的盘区尺寸，那么在后续数据库也会根据一定的规则进行自我调整。而采用统一分配的好处就是以后若移动或者删除段时可以更好的重用表空间中的空闲盘区，由此产生碎片会很少，因为他们都是采用统一的大小。笔者的建议是，如果一开始根据数据库管理的经验，可以确定合适的表空间盘区尺寸的，那么最好采用统一的盘区管理策略。相反如果不能够确定的同时删除段的情况也发生不多时，则可以采用自动分配选项，以提高数据库的性能。

　　二、将表空间从字典托管模式升级为本地托管模式。

　　如果原有的表空间是字典托管模式的，那么可以在不重新建立表空间的情况下，升级到本地托管模式。这也就意味着原有表空间中的数据不会丢失。如对于SYSTEM系统表空间，数据库系统提供了一个表空间管理模式转换的应用程序(TableSpace_Migrate_TO_Local).通过这个应用程序可以在不格式化System表空间的情况下将表空间的管理模式从数据字典托管模式升级到本地托管模式。

　　不过像上面这种托管模式的转换方式其具有一定的局限性。如采用这种转换模式时，盘曲映射参数就会移入到表空间的数据文件中，必须为表空间中的每个段制定相关的存储子句。此时本地管理模式的两个管理特性(自动分配策略与盘区尺寸管理策略)就无法使用，从而也就无法有效的减少磁盘碎片，提高数据库的性能。所以采取这种升级模式的话，企业不会从升级中获得策略方面的改善，而且数据库性能的改善效果也会打折扣。

　　为此笔者推荐的方法是采取比彻底的升级方式。即先把需要转换的表空间中的段导出来进行备份;然后删除原先的表空间并重新建立(此时把表空间的托管方式设置为本地托管);最后再把原先的段导进去。这虽然需要删除原先大表空间，在操作上具有一定的风险。但是这种转换方式却可以带来比较高的性能。另外为了让这个方法万无一失，数据库管理员在进行操作时，最好能够先检查一下这个段的大小。这有利于在后续的操作中减少错误的发生。另外虽然可以通过种种方式把表空间的管理模式从数据字典托管方式升级到本地托管模式。但是最好还是在开始部署数据库系统的时候，就决定好要采用哪种托管模式。毕竟在后续进行调整，会增加一定的工作量与操作风险。而且也会增加数据碎片，影响数据库的性能。

　　三、对System表空间转换模式的限制。

　　在Oracle数据库中，表空间大致分为两类，分别为系统表空间(System表空间)与非系统表空间。由于System表空间中存储着数据库运行的基本参数。为此对其进行表空间升级的话，就需要注意一些限制条件。只有这些限制条件全部满足的情况下，数据库管理员才能够将系统表空间的托管方式从数据字典托管模式转换为本地托管模式。这些限制条件如下(以下只是一些典型的限制条件，而不包括全部)。

　　如必须以受限制的模式启动数据库。数据库正常启动时默认情况下不适受限制模式。如果要把System表空间模式转换为本地托管模式的话，那么必须重新启动数据库系统，并在启动的时候选择受限制模式。只有在这个模式下，才能够利用上面谈到过的TableSpace_Migrate_TO_Local应用程序来进行托管模式的转换。其次数据库中所有用户的默认临时表空间必须是不同于System的表空间。其实在数据库部署的时候，笔者多次强调过System表空间的独立性。在建立用户的时候，不要把用户的默认临时表空间设置为System表空间。这个建议在这个地方就起到作用了。另外还必须将计划进行读/写转换的所有表空间迁移到本地托管的表空间等等。

　　四、在升级过程中的注意事项。

　　无论采用数据库应用程序来进行升级，还是通过重建数据表空间来进行升级，笔者强烈建议各位数据库管理员，在进行表空间升级之前，最好要对数据库先进性完全备份的工作。因为无论采用哪种升级方式，都会有一定的风险。这就好像动手术一样，无论大小，都会有风险。就像以前新闻所报道的，一个接骨的手术都会导致人死亡。所以，在升级之前，先对数据库进行完全备份。那么即使升级失败的情况下，也可以利用备份文件把数据库还原到最新的点。

　　另外在表空间管理模式升级的过程中，需要暂时中断用户的连接。这个中断的时间需要多长，很难估计。因为很难保证在升级的过程中，不会出现一些意外情况。为此在数据库表空间升级过程中，为了保证用户仍然的日常应用，最好选择在用户使用人数比较少的时候。如果是一般的企业，那么可以选择晚上或者双休日来进行表空间的格式转换，以减少数据库系统的当机时间。

　　最后从目前的大部分应用来看，本地托管模式无论从性能上或者从安全上，都要比数据字典托管模式要来得强。为此数据库工程师如果不能够确定该采用哪种模式好的情况下，笔者建议在部署数据库系统的时候就可以选择采用本地托管模式，以免除后续升级的麻烦。撇开性能等方面的考虑，只从功能上来说，两个托管模式是没有多少区别的。他们的差异只体现在对表空间的管理方法与数据库的性能上，即数据库底层管理方面的内容。而对于数据库的应用层面没有影响。