基于Oracle11g的集装箱码头TOS系统

摘要：随着集装箱码头业务量的增长，在码头TOS（Tape Operating System）数据库应用中，经常会有一些几十GB，上百GB的数据表。年吞吐量越大的码头，TOS系统的数据增长量越大。这些大数据量表的设计，维护及其备份都是TOS系统数据库管理中的重点及其难点。本文就从设计、维护及其备份方面探讨一下大数据量表的管理，并利用Oracle11g的最新特性，为码头用户提供更加智能、高效的大数据清理及转储解决方案。

关键词：TOS；数据仓库；数据清理；数据转储 

一、引言

随着集装箱码头生产系统生产数据的增长，系统的运行速度会随之下降。数据量的增长，会降低数据库检索及插入新数据的效率。对于数据清理及转储的传统方式，首先我们需要先把历史数据先备份下来，然后在删除对应的数据库表记录。为了保证数据的一致性，我们在做数据清理前还需要将数据库的表空间进行锁定；同时还要将需要清理及转储的表对应的触发器禁止掉。集装箱码头是24小时运营的。停产将导致给码头带来一定的经济损失。那么如何保证在不中断用户业务的前提下，能够将软件系统的历史数据进行清理并保证数据可恢复呢？用户对数据清理及转储的需求是什么？基于Oracle11g的转储原理，能给用户带来什么样的好处？本文将围绕这些问题进行讨论，并介绍采用这种方式后，数据转储的整个过程。

二、数据转储原理及方式

Oracle8i以后推出了分区选项。分区将表分离在若干不同的表空间上，用分而治之的方法来支撑元先膨胀的大表，组大表在物理一级的可管理性.将大表分割成较小的分区可以改善表的维护、备份、恢复、事务及查询性能。采用表分区将数据按时间隔离。然后根据时间段，对历史数据进行清理。当表中的数据量不断增大，查询数据的速度就会变慢，应用程序的性能就会下降，这时就该考虑对表进行分区。对表进行分区之后，在逻辑上表仍然是一张完整的表，只是将表中的数据在物理上存放到多个表空间上，这样查询数据时，不至于每次都扫描整张表。因此，我们只需要按表记录时间做分区。清理及转储时，只需要将不需要的历史数据按年进行drop即可。执行的时间快，而且不需要对表空间进行锁定和禁止表触发器。用户完全体验不到数据库有任何变化。用户也无需中断当前生产作业。

我们在数据清理和转储前可以有选择的对将被清理的数据进行数据备份。本文建议可以采用以下2种方式：（1）将数据备份到磁带机上或对应的其它存储设备上。在需要的时候，导入到临时数据库。（2）将需要转储数据迁移到数据仓库。用户可对数据仓库的数据查询、数据的挖掘、处理。（3）可以自动化、智能化的对数据进行清理及转储。对于非关键数据和关键数据，可以分别根据月份、年份清理相关的数据。

三、数据分区

3.1分区的依据

单表输入容量超过2GB的情况下应该进行分区；对包含历史数据输入的表应该进行分区，所谓包含历史数据是指新的数据将会被放到最新的分区里面。一个典型的例子是一个表只有当前月份的数据可以更新，但是其余月份的处于只读状态。

3.2分区的好处

增强可用性：如果表的一个分区由于系统故障而不能使用，表的其余分区可以使用；减少关闭时间：如果系统故障只影响表的一部份分区，那么只有这部份分区需要修复，可能比整个大表修复花的时间更少；维护轻松：如果需要得建表，独产管理每个公区比管理单个大表要轻松得多；均衡I/O：可以把表的不同分区分配到不同的磁盘来平衡I/O改善性能；改善性能：对大表的查询、增加、修改等操作可以分解到表的不同分区来并行执行，可使运行速度更快，在数据仓库的TP查询特别有用；分区对用户透明：最终用户感觉不到分区的存在。

3.3分区的方法

四、TOS历史数据的清理及转储过程

TOS历史数据的清理及转储过程分为四步：（1）选择需要转储的数据。可以按年或按月进行清理。非关键数据建议按月进行清理，关键生产数据建议按年进行清理。比如：当前是2014年1月份。用户希望码头生产系统只保留12个月的数据。因此，我们可以把时间小于2013年01月之前的数据清除掉。（2）导出转储数据在删除前，使用oracle自带的expdp和exp工具导出对应的数据。如果出现误操作或用户希望对清理后的数据查询时，对数据进行恢复。（3）数据清理（4）数据恢复，用户如果希望对转储后的数据进行查询，可以利用oracle数据库自带的工具Impdp和Imp，在服务端或客户端两种方式将备份出来的数据导入指定数据库进行数据恢复。

参考文献

[1]Jujay.一个利用传输表空间和分区交换技术进行数据迁移的案例.ATAGURE.2012，(12)

[2]Luocs.Oracle分区扩展-3分区表的索引维护.LuocusTechnologyBlog.2013，(1)

[3]KarenReliford.OracleDatabase11gNewFeaturesforTablePartitioning.DatabaseJournal.2010，(1)