|
表空间有数据字典和本地托国两种管理模式如果采用数据字典来维护的话发生在数据库的段上并关系到盘区分配的操作(如扩展一个表)将会导致对数据字典的操作如果有很多带有盘区的表被操作时数据字典将会成这些操作的瓶颈资源可见如果采用数据字典来维护表空间的话那么数据库要花的代价就会很大 为了解决这个问题改善表空间的管理性能Oracle数据库又推出了一种全新的表空间管理模式即本地托管的管理模式如果把表空间设置为本地托管则这些盘区管理操作都回被重新分配到数据文件的位图块上如此的话数据库的每个标空间都只包含自己的盘区信息可以使用快速散列进程访问技术来访问相关系悉尼而不是使用比较慢的基于表的查询访问最关键的是此时如果有很多带有很多盘区的表被操作时数据字典将不会成为其性能的瓶颈可见在同等条件下本地托管的性能要比数据字典维护模式的性能要高 一本地托管模式的两个特性 本地托管模式除了在管理上跟数据字典模式有一定的差异外还提供了两个比较有特色的选项分别为自动分配与统一分配选项这连个选项主要用来控制将盘区分配到段中的视线方式如把这个方式设置为自动分配的话Oracle数据库系统会采用一个内部的算法(这个算法数据库管理员不用了解)在段的大小发生调整时(如段大小增大时)自动增加盘区的大小也就是说使用自动分配选项的话当表空间中的段增大时数据库系统会根据一定的规则来确定合适的下一个盘区的尺寸这个算法的主要原理就是以盘区数量和扩展比例来作为系数并结合其他的一些参数来进行模拟计算自动分配盘区大小的优势是很明显的因为在刚开始部署数据库系统的时候由于各方面原因的限制要设置一个合理的盘区大小具有一定的困难而现在采用了自动分配的话如果刚开始盘区尺寸设置的太小则数据库会随着后续需求的表换而自动增加表的下一盘区尺寸从而可以减少表具有的全部盘区数量这在很大程度上可以提高数据库的性能另外采用自动分配选项的话还可以保证段的数量不会超出其可以控制的范围因为数据库会自动根据实际情况来进行调整 而如果采用统一的盘区管理策略则表空间中的所有盘区都使用在创建表空间时指定的相等大小进行分配而不会考虑到其他因素如不会考虑在段创建语句中设定的存储子句也不会随着一些应用情况的改变而调整盘区尺寸的大小显然如果采用统一分配策略的话那么在表空间规划的时候就需要为其设置一个合理的盘区尺寸 那么有人会说既然统一分配这么麻烦不会自动调节那就都用自动分配策略好了其实不能够这么绝对可以说两个管理选项各有各的优点自动分配的有点就是即时在表空间建立时没有设置合理的盘区尺寸那么在后续数据库也会根据一定的规则进行自我调整而采用统一分配的好处就是以后若移动或者删除段时可以更好的重用表空间中的空闲盘区由此产生碎片会很少因为他们都是采用统一的大小笔者的建议是如果一开始根据数据库管理的经验可以确定合适的表空间盘区尺寸的那么最好采用统一的盘区管理策略相反如果不能够确定的同时删除段的情况也发生不多时则可以采用自动分配选项以提高数据库的性能 二将表空间从字典托管模式升级为本地托管模式 如果原有的表空间是字典托管模式的那么可以在不重新建立表空间的情况下升级到本地托管模式这也就意味着原有表空间中的数据不会丢失如对于SYSTEM系统表空间数据库系统提供了一个表空间管理模式转换的应用程序(TableSpace_Migrate_TO_Local)通过这个应用程序可以在不格式化System表空间的情况下将表空间的管理模式从数据字典托管模式升级到本地托管模式 不过像上面这种托管模式的转换方式其具有一定的局限性如采用这种转换模式时盘曲映射参数就会移入到表空间的数据文件中必须为表空间中的每个段制定相关的存储子句此时本地管理模式的两个管理特性(自动分配策略与盘区尺寸管理策略)就无法使用从而也就无法有效的减少磁盘碎片提高数据库的性能所以采取这种升级模式的话企业不会从升级中获得策略方面的改善而且数据库性能的改善效果也会打折扣 为此笔者推荐的方法是采取比彻底的升级方式即先把需要转换的表空间中的段导出来进行备份;然后删除原先的表空间并重新建立(此时把表空间的托管方式设置为本地托管);最后再把原先的段导进去这虽然需要删除原先大表空间在操作上具有一定的风险但是这种转换方式却可以带来比较高的性能另外为了让这个方法万无一失数据库管理员在进行操作时最好能够先检查一下这个段的大小这有利于在后续的操作中减少错误的发生另外虽然可以通过种种方式把表空间的管理模式从数据字典托管方式升级到本地托管模式但是最好还是在开始部署数据库系统的时候就决定好要采用哪种托管模式毕竟在后续进行调整会增加一定的工作量与操作风险而且也会增加数据碎片影响数据库的性能 三对System表空间转换模式的限制 在Oracle数据库中表空间大致分为两类分别为系统表空间(System表空间)与非系统表空间由于System表空间中存储着数据库运行的基本参数为此对其进行表空间升级的话就需要注意一些限制条件只有这些限制条件全部满足的情况下数据库管理员才能够将系统表空间的托管方式从数据字典托管模式转换为本地托管模式这些限制条件如下(以下只是一些典型的限制条件而不包括全部) 如必须以受限制的模式启动数据库数据库正常启动时默认情况下不适受限制模式如果要把System表空间模式转换为本地托管模式的话那么必须重新启动数据库系统并在启动的时候选择受限制模式只有在这个模式下才能够利用上面谈到过的TableSpace_Migrate_TO_Local应用程序来进行托管模式的转换其次数据库中所有用户的默认临时表空间必须是不同于System的表空间其实在数据库部署的时候笔者多次强调过System表空间的独立性在建立用户的时候不要把用户的默认临时表空间设置为System表空间这个建议在这个地方就起到作用了另外还必须将计划进行读/写转换的所有表空间迁移到本地托管的表空间等等 四在升级过程中的注意事项 无论采用数据库应用程序来进行升级还是通过重建数据表空间来进行升级笔者强烈建议各位数据库管理员在进行表空间升级之前最好要对数据库先进性完全备份的工作因为无论采用哪种升级方式都会有一定的风险这就好像动手术一样无论大小都会有风险就像以前新闻所报道的一个接骨的手术都会导致人死亡所以在升级之前先对数据库进行完全备份那么即使升级失败的情况下也可以利用备份文件把数据库还原到最新的点 另外在表空间管理模式升级的过程中需要暂时中断用户的连接这个中断的时间需要多长很难估计因为很难保证在升级的过程中不会出现一些意外情况为此在数据库表空间升级过程中为了保证用户仍然的日常应用最好选择在用户使用人数比较少的时候如果是一般的企业那么可以选择晚上或者双休日来进行表空间的格式转换以减少数据库系统的当机时间 最后从目前的大部分应用来看本地托管模式无论从性能上或者从安全上都要比数据字典托管模式要来得强为此数据库工程师如果不能够确定该采用哪种模式好的情况下笔者建议在部署数据库系统的时候就可以选择采用本地托管模式以免除后续升级的麻烦撇开性能等方面的考虑只从功能上来说两个托管模式是没有多少区别的他们的差异只体现在对表空间的管理方法与数据库的性能上即数据库底层管理方面的内容而对于数据库的应用层面没有影响 |
