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

核心提示： 为此笔者推荐的方法是采取比彻底的升级方式，即先把需要转换的表空间中的段导出来进行备份;然后删除原先的表空间并重新建立(此时把表空间的托管方式设置为本地托管);最后再把原先的段导进去，把表空间从字典托管模式升级成本地托管模式(3)，这虽然需要删除原先大表空间，在操作上具有一定的风险，他们的差异只体

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

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

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

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

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

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

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

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