Datastage7.5.2.1问题汇总

1、datastage7.5.2.1问题汇总 datastage7.5.2.1问题汇总 2010-08-14 16:59 环境：red hat linux as 4 update 8 x86_64 + datastage 7.5.2.1 + oracle 10g x86_64 + ms sql server 2005 如果你使用datastage7.5.x来做etl，那么建议你先看下一ibm官方公布的已修正的bug， 先备份$dshome/etc/operator.apt文件，使用vi编辑该文件，将dscapiop dscapiop 1修改为dscapiop dscapiop 1,保存退出！ 关闭

2、ds，重新启动！不知道为什么这么干！寻遍官方文档都没找到一点相关内容，上给出的解决办法，当前问题是解决了，但是依据是什么呢？ 会不会因此而产生其他的潜在问题？！ 在这里鄙视一下ds！ 12.job排错，开启详细日志输出 日志提示有警告，可是不知道是哪个stage提示警告，那么设置apt_dump_score = true，可以在log的警告信息中看到stage名称。 另外，还有一些选项用于log日志输出。 内存使用情况，apt_pm_player_memory = true cpu使用时间，apt_pm_player_timing = true 数据抽取条数，apt_record_counts

3、 = true 13.ds性能调优 详见官方文档。 apt_default_transport_block_size = 131072 改为 apt_default_transport_block_size = 1048576 apt_buffer_maximum_memory = 3145728 (3 mb) 改为 apt_buffer_maximum_memory = 6291456 (6 mb) apt_buffer_free_run = 0.5 改为 apt_buffer_free_run = 0.6 14.ds运行中发现的oracle db的问题 ds运行时，log日志报错，竟然都是

4、tns和ora的错误，尤其是并行多个job时，有job失败。 请寻求dba协助，做数据库的优化！ 15.ds中对oracle中特殊字符的处理（例如：# $） ds_enable_reserved_char_convert = true 处理特殊字符#，$ 16.transformer stage中的substr功能 transformer stage中的substr功能在抽取数据时，按字符对象截取字符，可是加载至目标库时，是按字节计算长度。 尤其是对含有中文的字段截取时，有些中文字符的最后一个字符被截成了乱码，在加载至目标表时报错， 可以在/home/dsadm/ascential/datastage/scratch文件夹下bad文件中找到出错的数据条目。、 建议： 对于含有中文的字段，目标表的字段长度尽可能的与源表字段长度一致。 17.从ms sql server 2005抽取数据至oracle时，中文乱码解决 nls为g