DataStage问题处理大全Word文档下载推荐.docx
《DataStage问题处理大全Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《DataStage问题处理大全Word文档下载推荐.docx（24页珍藏版）》请在冰豆网上搜索。
举例说明：
指定4个分区，则group以2,048bytes来创建；
对于动态hashfile，group的大小由GROUP.SIZE参数来决定，以2,048bytes为单元，GROUP.SIZE允许的值只有1和2，所以动态hashfile中的group大小只能是2,048或者4,096bytes。
Record是数据存贮的的逻辑单元，它可以被逻辑地描述为一组fields或者被物理地描述为recordheader、keyvalue和数据分区。
每个record都有一个通过hash算法产生的KeyValue以确定此record所在的group
文件的group的数目在静态hashfile中称为modulo/modulus，在动态HashFile中称为currentmodulus。
在没有外界干涉的情况下，静态hashfile中的group的数目保持常量，而动态hashfile中的group数目受动态地存贮数据量的大小而改变，这是静态hash和动态hash的首要的区别。
我们统计file中的group从1数起，而DataStageHashFile是按照group的起始地址来引用group的。
每个hashfile都有一个header，groups从文件开始偏移header的大小的位置开始。
我们可以通过LIST.READU这样的命令得到group的地址（十六进制给出）。
DataStageHashFile工具uvfixfile和filepeek可以以十进制或十六进制计算地址。
当group创建后（CREATE.FILE），group存在的文件section称为primarygroupbuffer。
Primarygroupbuffers紧挨着fileheader连续排列，这样文件的对比只需要文件header和primarygroupbuffer，这样大大提高记录读取的速度。
但世界并不完美，有时候分配给group的记录不能被放入primarygroupbuffer，这样group处于"
溢出"
（overflow）的状态，第二个groupbuffer进行分配，并且daisy-chainedtoprimarygroupbuffer，分配原则如下：
•静态文件中紧接最后一个primarygroup
•动态文件中，在OVER.30中（primarygroupbuffers在DATA.30部分中）
静态和动态hashfile之间唯一真正的区别在于primarybuffers存在于DATA.30文件中，而溢出group和oversizedrecordbuffer存在于OVER.30文件中，由于DATA.30的大小随时间改变而改变，这是必须的。
有溢出（Overflow）说明文件没有调整到最优，可能是由于group太少，或者没有选择最适合的hash算法，或者只是因为keyvalues/structuress不能用hash算法充分操作。
ANALYZE.FILE是一个调试Hashfile的工具，可以报告"
badlyoverflowed"
的情况，意味着即使在一个Secondarygroupbuffer中仍然没有足够的空间来存贮所有分配给这个group的数据。
"
group是多于一个secondarygroupbuffer。
经验显示约90％的brokenfile在groupbuffer的连接上断开。
DataStagehashfile在groupbuffer的连接很脆弱，这是因为：
•由于group被锁住直到整个group处理进或出memory，这样性能很受影响。
•如果secondarygroupbuffer距离它连接的之前的buffer很远的距离，磁盘查询的延时将增加。
在这些延时中，文件系统容易受到外部事件的伤害，例如停电。
在动态文件中memory中的header信息会同物理文件一起丢失。
所以如果溢出（overflow）越少，处理文件的风险就越小。
办法就是减少溢出。
在group中，增加记录，从group的开始处占据空间。
记录是用向前和向后指针"
daisychained"
的，没有group自己的存贮界定，如groupheader或者trailer。
FreeSpace作为一个有"
freespace"
的header的"
record"
存在，可以有对于一个的freespace存在于group中，例如一个record从文件中删除，它实际通过有它的freespace被标志为删除。
每个record都把从文件开始的偏移量作为它的地址，例如group在0x2000地址，那么group中的第一个record的地址就是0x2000。
动态hashfile的魅力在于它可以随需求动态增长，自动加倍文件大小，重新分配数据，把溢出文件（OVER）中的数据移入数据文件（DATA）中。
由于Hashfile其特有的存贮机制，需要注意DataStage设计中其使用和误用的地方。
要想在hashfile中查找一条记录，需要知道其key值。
数据都是连续字符存贮，字段分隔符是@AM（系统变量），每个字段都按照数据本来的数据排列，这样看来hashfile几乎同sequentialfile一样，字段由其所在的位置定位而非字段名字。
实际上，由于数据是以文本字符串形式存贮，你只需要知道key和字段长度位置即可。
在hashfile中不要使用受限的ASCII字符，这些字符可能会被作为内部数据分隔符。
此外，由于每条记录都是一条文本字符串存贮的，所以hashfile中的每条记录都允许有自己的结构，hashfile成为非一致结构的自由格式文件。
Hashfile在DataStage中以下主要用法：
通过primarykey的非大量的lookupDataStage®
可以将Hashlookup放入cache内存（Lookup不是Join）。
Lookup使用hey值在hashfile中指定查询的row.如果使用ODBC/OCIstages来做lookup，由于缺少memorycache的能力performance会差。
此外,许多job都作ODBC/OCILookup，数据库查询将会饱和。
阶段性的关联性文件也就是转换job为另外一个job准备的关联数据。
通过hashfile很容易完成。
非固定不变的中间结果文件.Hashfiles奇妙的存贮机制是它用于关联lookup的原因。
如果数据不需要关联lookup，由于写入sequentialfile的appending方式，sequentialfile是最好的选择。
Hashfile需要检测可用空间，然后决定写入数据文件还是溢出文件。
在DataStage设计中误用的地方：
1，存贮固定不变的生产数据在ETL工具中。
Hashfile是应该用于丢出数据或者随意使用的中间结果暂存的文件，而非需要可以从被破坏的状态下恢复或者备份的文件。
2，把绝大多数row从未被关联到的HashfilePreload到内存中。
如果处理的数据量不能超过关联的数据量，Preloading到内存既浪费时间由浪费内存。
3，每条记录可能只被Lookup一次的HashfilePreloading到内存。
4，使用SQL接口（UV/ODBC,UV/SQL命令）访问hashfile。
Hashfile没有第二个索引支持任何关系型数据库的查询。
虽然其内部的engine可以支持这类的操作，我们知道DataStage的大部分东西都是以HashFile存放的，你可以用UVSQL访问他们，但是别试图在你的ETL工具中建造起一个数据库，这也违背了ETL工具将数据展现为图形界面开发处理的初衷。
也许这方面的操作，很多人没有遇到，或者不知道如何使用，在后面会有相关的介绍，比如我最近遇到hashfile中数据删除问题，就采用了这样的方式。
当然我不会总是用UVSQL访问DataStage的数据库和hashfile（那样也太累太蠢了）。
继续hashFile可能使用不当的地方。
5，企图欺骗HashFile，改变hashfile的元数据，使用一组不同的字段（即使这些字段都在hashfile的表定义中）找到某条记录。
这种方式是关系型数据的优势，但不是用于hashfile。
DataStage会读取hashfile中记录的全部内容（全部表定义字段）到内存中，所以必须要使用完整的元数据来定义hashfile，不能像操作RDB一样不同的jobstage使用不同的表定义来获取记录。
6，多个job并行往同一个hashfile中写入数据。
尤其是选择Allowingstagewritecache的时候，需要及其小心DataStage处理并行的方式。
多实例的Job如果使用writecache的方式写hashfile会将数据放入缓冲区（buffer），会造成清洗缓冲点（flushpoint）的争用，这样就会当实例数增加到一定的数据，运行效率开始下降的分界点。
例如，可能由于磁盘的拥堵和争用，4个实例运行的时间可能会比8个实例运行的时间短。
对于不同server配置，分界点也会不同，需要测试去找到较好的实例数目。
7，同样，一个job中同时读写同一个hashfile，不要选择"
AllowingStageWriteCache"
属性。
8，为了帮助DataStage可以以交易模式（transactionalmode）使用，在hashfile中加入了行锁机制。
但是这个属性最好不要在ETL中使用，它会导致性能极度丧失。
DataStage对hashfile使用脏读写隔离级别和顺序执行的方式，比依赖锁机制避免污染数据而并行执行几个进程的方式要好很多。
此外，我们可以用HashFile玩些小把戏，得到些额外的收获。
找点时间填东西了
sorry,comingsoon...
1，我们都知道可以利用hash去除重复记录，对于键值一样的多条记录只保留最后一条写入的记录。
其实这个类似table的update操作，也可以利用此功能进行hash中的数据更新。
利用这个功能时候，容易犯错误的是，有时候键值看似一样的数据存在两条或者多条，这是由于hashfile对于传入的字段字段中存在空字符串。
这也做lookup时应该注意的问题。
2，DataStage中hash设置有两种方式：
Useaccountname/usedirectorypath
Useaccountname中如果不选accountname，系统都会指向此hash目前所在的accountname（Projectname），这样如果移植到别的项目时候，hash会指向移植的项目，hash文件会建立在此项目的默认目录下，同时写入VOC。
如果要删除此hashfile，只删除其物理文件不行，需要用TCLcommand，如在Adminitrator中：
DELETE.FILEhashfilename;
清空的话用CLEAR.FILEhashfilename;
如果选择userdiretorypath，可以在选定的路径下，直接删除路径下的物理文件和路径就可以删除hash文件了。
DataStage---lookup和join的区别[转]
关于lookup和join的区别，不同工具有类似的方式和原理，但功能特点各有不同。
首先lookup典型的1对N关联，而join可以N对M。
此外lookup一般是左外连接（假设主表在左的设计思路），join则可以分开指定内或左外或者右外或者全外连接。
lookup通常可以全部或部分缓冲进入内存，join则不一定，不同工具的做法差别挺大。
lookup其实不少工具并不需要sort，因为是通过lookupkey类似hash索引来定位，而join则分mergejoin和hashjoin，mergesort做数据仓库的时候很吃亏的，因为数据需要先排序才能join，以数据仓库的大数据这么join几次后就开销很大了，通常etl工具本身所实现的方式都是sortmerge。
hashjoin那就不需要将数据排序后关联，而现在最新的oracle,db2,teradata都有hashjoin的方式来提高性能，sql2005好像也有了，iq就不是很清楚，其他的就更不清楚了。
实际项目中，工具中的join未必比数据库快，还是要具体项目看，当然工具的好处是可以join异构数据源。
但是往往etl工具作lookup比在db里面join效率要高。
讲到这里就可以清楚了，工具很多时候都在推荐lookup。
在偶做过的项目中，N对M的关联其实并不多，基本上都可以用lookup来实现。
lookup的一些差别就是体现在lookup实现的复杂程度、性能和维护工作量。
这块的技巧性也比较强。
DataStage---方法小结ing[转]
datastage怎样调用存储过程
1。
可以选择编写一个自定义Routine然后通过Transformer去实现或者建立存储过程，然后在Database组件里的BeforeAfter里用数据库语句去调用就可以了
还有一个选择就是运行自定的shell脚本去调用，这种方法要用到jobsequence中的运行命令的组件
2。
datastage有专门调用存储过程的stage
-------------------------------------------------------------------------------------------------------
实现是日期加1
DateToString（DateFromDaysSince（1,StringToDate（DSLink4.sjrq,"
%yyyy%mm%dd"
））,"
）
TransfomerfunctiontoLeftPadastring?
Notsureifthereisoneavailable.IthinkitisavailableintheserverjobusingtheFMTfunction.
ButwhatwedidwasusetheSTR,LENandconcatenationoperator（:
）toachievethedesiredresult.
STR（"
0"
10-LEN（Input_Column））:
Input_Column
DataStage如何解决"
jobisbeingaccessedbyanotheruser"
错误
由于网络连接失败或客户端崩溃造成Job被锁定的解决方法
当某一个用户在DataStageDesigner中打开一个job，该job就被锁定。
当其他用户试图打开同一个job或者jobsequence，在designer中会得到如下信息"
job[job名称]isbeingaccessedbyanotheruser"
。
顺便提一下，这点Informatica比DS作的更友好一些，当试图打开某一个正在被其他用户编辑的mapping的时候，除了警告信息，Informatica还会告知当前编辑该Job的IP和User。
如果正在编辑某个job，发生网络连接中断（不小心碰掉了网线），或者客户端崩溃（我用XPSP2+DS751，每个星期总要发生个两三回，尤其是在编辑复杂的jobsequence时）。
重新启动客户端，试图打开刚才被编辑的Job很可能就被提示"
jobisbeingaccessedbyanotheruser"
首先确定在DataStageAdministrator中对该project设置了权限"
EnablejobAdministrationinDirector"
，否则Director中部分菜单按钮不能访问
打开DataStageDirector，找到被锁定的Job,菜单Job->
ClearStatusFile。
会得到提示"
Thiswillremovealljobstatusinformationfrom[job名称].Areyousureyouwanttocontinue?
，选择"
Yes"
菜单Job->
Cleanupresources，此时会有JobResources对话框出现。
下边list中卫当前锁，在ItemId列找到被锁定的job，记下PID/User#列对应的PID
Telnet到DataStage服务器，执行如下命令
ps-ef|grepdsapi_slave
注意输出的前三列是用户名,ID1,ID2格式
在ID1列找到前面记下的PID，执行如下命令
kill-9ID2
有空研究下windows下如何定位，加以更新
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
IfuaretryingtoopenaJobintheDatastageDesigneranditsays:
"
th
jobisaccessedbyanotheruser"
itcudbeduetotworeasons:
1.）ChkifyoualreadyhavethatjobopeninadifferentwDesignerWindow.
2）Ifnot,thenthejobislocked.
Youcanrealsethelockinvariousdifferentways.
1.）Goto->
Manager->
tools->
Releasejob（ushudhaveadministratorprev）
2.）UseDS.TOOLScommandintheDataStageAdministratortochkandreleas
ErrorinLinkcollector-Stagedoesnotsupportin-processactive-to-activeinputsoroutputs
TogetridoftheerrorjustgototheJobProperties->
PerformanceandselectEnablerowbuffer.
ThenselectInterprocesswhichwillletthelinkcollectorruncorrectly.
Buffersizesetto128Kbshouldbefine,howeverit'
sagoodideatoincreasethetimeout.
Datastage对于超过2000的长字段的处理
对于超过2000的长字段的处理（Datastage版本：
DataStage7.5.2）：
说明：
对于小于等于2000的字段，用odbc就可以实现，当超过2000时odbc实现就会报错
解决方法：
Database源和目标都需选用DynamicRDMBS
在做数据抽取时，一般从数据库Date类型默认转换成timestamp，如果用DynamicRDMBS，那么必须改为Date类型，抽取时间即当前时间Oconv（Date（）,"
D4-YMD[4,2,2]"
）DSJobStartDate都会失效，他们插入数据库的都是为空值，一般应该设置为@DATE
DataStage在RedHatLinuxEnterprise3上安装详细步骤
（一）
安装前确保oracle10g已安装好，并能正常使用。
安装方法见：
用root用户进入系统，
升级tar版本为1.19，如果比这个版本高，则不用升级
解压tar-1.19.tar
进入解压后的目录
./configure
make
makeinstall
完成之后查看tar版本tar--version
若为1.19,则进行下一步操作。
mkdir-p/app/dsadm
groupadddstage
useradd-gdstage-mdsadm
chown-Rdsadm.dstage/app/dsadm/
解压datastage.tar.gz
将解压后的目录/home复制到/app/dsadm
cp-r/home/app/dsadm/
进入/app/dsadm/home/ivan/
执行./install.sh-admindsad
升级会员 