IBM DB2 大数据处理

（一）DB2删除大数据量表方法【http://www.voidcn.com/article/p-ktzlerzh-ys.html】

DB2不支持truncate语句,当用delete from table时候，会很慢很慢，笔者 做过一些测试对于数据量在百万上的，很慢。故找了几种解决办法：
第一种：
在D 盘建一个empty.del文件。然后通过import命令import from empty.del of del replace into [table_name]来清空表中的数据并重组表空间。
效率很快
第二种：
在建表时加选项not logged initially ，当清空表时通过alter table [name] activate not logged initially with empty table 。

3、

export to test.ixf of ixf messages log.txt select * from test where 1=2
import from test.ixf of ixf messages log1.txt replace into test

?

?

（二）数据转移【DB2中插入数据一般LOAD最快，其次是IMPORT，最后是INSERT。因为PROCEDURE中不能使用LOAD和IMPORT语句，所以在这里我只谈INSERT。】

1、Load

2、将写入的时候不记录日志。【INSERT的时候要考虑加快速度，你可以此表的日志功能取消，并且INSERT的时候不要一条一条记录去插入，可以一次同时插入几条或者几百条数据。】

3、import可以加commitcount

4、不相同的库可以考虑用datastage等工具

5、db2move时系统虽然会自动建表，但是也仅限于表，表上的视图和索引还需要自行创建

6、db2move是DB2数据转移命令,用于不同操作系统之间(如linux和windows)的数据转移.可以先用db2move export将数据导出,然后在另一个DB2里用db2move import或db2move load导入数据.

?

?

?

（四）DB2数据库进行大量数据处理时报事务日志已满【http://blog.sina.com.cn/s/blog_7155eb38010156se.html】

问题原因：今天在删除CP2_BEPS124表数据的时候，由于一次删除的记录有31W条，导致DB2直接报?The transaction log for the database is full这个错误，此时数据库已经不能进行查询意外的任何操作。

?

（五）大数据的存储和查询优化总结【http://nanquan.iteye.com/blog/1616220】

?

最近的项目里需要对大数据量的数据进行存储和查询,每天的基础数据大概在500w~1500w之间,?每1000w的数据大概会占用1.5GB~2GB的物理存储,这对我们的数据库设计,程序和服务器都是一个不小的挑战. ?数据库我们用的是DB2,下面是一些经验总结(不断更新中..):

1. 在大数据量的情况下,?如果 join的表只是为了数据过滤,则应该考虑用子查询替换join

2. 避免在索引键上做计算,即便这个计算很简单的,因为如果索引键上加上计算的话,将不能使用索引,严重影响查询效率

3. ?索引排序的选择,主要考虑查询和插入的性能. 如果一个列在程序里是成不断增长的,比如记录的创建时间,则应该考虑用倒序(desc),这样在插入数据时,新索引的建立不会影响到之前索引的位置. 所以,主键生成的策略也应该考虑到这一点,如果用UUID的话,因为字符串并不能保证顺序,左右在插入的时候,对索引的结构影响比较大; 而自动增长的主键则会避免这个情况,当是尽量避免使用纯sequence,因为这样既不方便数据的移植,也会有seqiemce循环的问题; 时间格式加上sequence混合生成主键,应该是一个不错的解决方案. 时间可以用yyyyMMddhh格式,这样的主键也可以比较直观的看出记录的创建时间.

3. 把能够通过索引迅速缩小查询范围的条件放到前面

4.?使用ike： like 'x%' 将会使用索引，而like '%x'将不能使用索引，而且因为like检索时,如果前面是固定的字符,那么,就可以跟索引键做对比,如果前面是不固定的字符(比如%),则无法利用索引. 且like的检索时间与字符串长度呈线性关系，使用VARCHAR代替CHAR可以去掉多余的空格，会加快检索

5. 如果可以,使用 fetch first only 或 limit 限制结果集大小,这样在大数据量的情况下,可以更快的返回数据.

6. 在一开始做大表设计的时候,就要充分考虑表的分区和扩展,比如使用时间字段作为分区字段. 分区字段要尽量保证数据的均匀,避免出现数据倾斜. 当然如果历史数据,不经常用到的话,还是优先考虑使用历史表来保存历史记录.

7. 如果查询和更新都比较频繁的话,可以考虑使用数据库读写分离技术的,不过如果查询对实时性要求比较高的话,这种查询还是应该在主节点(复制插入)上执行.?

8. 大数据的删除. 主表上为了提高查询性能,用了大概5-6个索引字段,导致在删除这个表的数据时,异常的慢,即使删除一条也需要大概20-30秒. 而我们有时候要删除的数据是千万级的,所以普通的delete几乎无法工作. 解决这个问题,我们换了一种思路,用update语句来将需要删除的数据与正常业务数据隔离,比如将需要删除的数据的业务时间改为2000年前或者如果专门有的是否删除字段就更好了. 然后删除的任务就可以慢慢来做了. 正好我们的表分区是通过业务时间来做的,这个时候,将2000年前的数据通过分离表分区来独立出来,再把这个表drop掉,数据就删除了.