ORA-00904: "MESSAGE_NUM": invalid identifier 
   刚开始看到的时候觉得很摸不清头脑，不知道问题所在，后来查看了oracle的文档
才知道其实是oracle的一个bug。这种情况的发生往往是我们使用了较高版本的oracle 
client去连接较低版本的oracle db所致，比如我们采用10g的客户端去连接9i的数据库，
当使用direct path load时就会报上面的错。在datastage中一种解决方案是重装oracle
client，一种是通过administrator修改oracle load option.

The extract-transform-load (ETL) system, or more informally, the "back room," is often estimated to consume 70 percent of the time and effort of building a data warehouse. But there hasn't been enough careful thinking about just why the ETL system is so complex and resource intensive. Everyone understands the three letters: You get the data out of its original source location (E), you do something to it (T), and then you load it (L) into a final set of tables for the users to query.

When asked about breaking down the three big steps, many designers say, "Well, that depends." It depends on the source, it depends on funny data idiosyncrasies, it depends on the scripting languages and ETL tools available, it depends on the skills of the in-house staff, and it depends on the query and reporting tools the end users have.

The "it depends" response is dangerous because it becomes an excuse to roll your own ETL system, which in the worst-case scenario results in an undifferentiated spaghetti-mess of tables, modules, processes, scripts, triggers, alerts, and job schedules. Maybe this kind of creative design approach was appropriate a few years ago when everyone was struggling to understand the ETL task, but with the benefit of thousands of successful data warehouses, a set of best practices is ready to emerge.

I have spent the last 18 months intensively studying ETL practices and ETL products. I have identified a list of 38 subsystems that are needed in almost every data warehouse back room. That's the bad news. No wonder the ETL system takes such a large fraction of the data warehouse resources. But the good news is that if you study the list, you'll recognize almost all of them, and you'll be on the way to leveraging your experience in each of these subsystems as you build successive data warehouses.

The 38 Subsystems

1. Extract system. Source data adapters, push/pull/dribble job schedulers, filtering and sorting at the source, proprietary data format conversions, and data staging after transfer to ETL environment.
2. Change data capture system. Source log file readers, source date and sequence number filters, and CRC-based record comparison in ETL system.
3. Data profiling system. Column property analysis including discovery of inferred domains, and structure analysis including candidate foreign key — primary relationships, data rule analysis, and value rule analysis.
4. Data cleansing system. Typically a dictionary driven system for complete parsing of names and addresses of individuals and organizations, possibly also products or locations. "De-duplication" including identification and removal usually of individuals and organizations, possibly products or locations. Often uses fuzzy logic. "Surviving" using specialized data merge logic that preserves specified fields from certain sources to be the final saved versions. Maintains back references (such as natural keys) to all participating original sources.
5. Data conformer. Identification and enforcement of special conformed dimension attributes and conformed fact table measures as the basis for data integration across multiple data sources.
6. Audit dimension assembler. Assembly of metadata context surrounding each fact table load in such a way that the metadata context can be attached to the fact table as a normal dimension.
7. Quality screen handler. In line ETL tests applied systematically to all data flows checking for data quality issues. One of the feeds to the error event handler (see subsystem 8).
8. Error event handler. Comprehensive system for reporting and responding to all ETL error events. Includes branching logic to handle various classes of errors, and includes real-time monitoring of ETL data quality
9. Surrogate key creation system. Robust mechanism for producing stream of surrogate keys, independently for every dimension. Independent of database instance, able to serve distributed clients.
10. Slowly Changing Dimension (SCD) processor. Transformation logic for handling three types of time variance possible for a dimension attribute: Type 1 (overwrite), Type 2 (create new record), and Type 3 (create new field).
11. Late arriving dimension handler. Insertion and update logic for dimension changes that have been delayed in arriving at the data warehouse.
12. Fixed hierarchy dimension builder. Data validity checking and maintenance system for all forms of many-to-one hierarchies in a dimension.
13. Variable hierarchy dimension builder. Data validity checking and maintenance system for all forms of ragged hierarchies of indeterminate depth, such as organization charts, and parts explosions.
14. Multivalued dimension bridge table builder. Creation and maintenance of associative (bridge) table used to describe a many-to-many relationship between dimensions. May include weighting factors used for allocations and situational role descriptions.
15. Junk dimension builder. Creation and maintenance of dimensions consisting of miscellaneous low cardinality flags and indicators found in most production data sources.
16. Transaction grain fact table loader. System for updating transaction grain fact tables including manipulation of indexes and partitions. Normally append mode for most recent data. Uses surrogate key pipeline (see subsystem 19).
17. Periodic snapshot grain fact table loader. System for updating periodic snapshot grain fact tables including manipulation of indexes and partitions. Includes frequent overwrite strategy for incremental update of current period facts. Uses surrogate key pipeline (see subsystem 19).
18. Accumulating snapshot grain fact table loader. System for updating accumulating snapshot grain fact tables including manipulation of indexes and partitions, and updates to both dimension foreign keys and accumulating measures. Uses surrogate key pipeline (see subsystem 19).
19. Surrogate key pipeline. Pipelined, multithreaded process for replacing natural keys of incoming data with data warehouse surrogate keys.
20. Late arriving fact handler. Insertion and update logic for fact records that have been delayed in arriving at the data warehouse.
21. Aggregate builder. Creation and maintenance of physical database structures, known as aggregates, that are used in conjunction with a query-rewrite facility, to improve query performance. Includes stand-alone aggregate tables and materialized views.
22. Multidimensional cube builder. Creation and maintenance of star schema foundation for loading multidimensional (OLAP) cubes, including special preparation of dimension hierarchies as dictated by the specific cube technology.
23. Real-time partition builder. Special logic for each of the three fact table types (see subsystems 16, 17, and 18) that maintains a "hot partition" in memory containing only the data that has arrived since the last update of the static data warehouse tables.
24. Dimension manager system. Administration system for the "dimension manager" who replicates conformed dimensions from a centralized location to fact table providers. Paired with subsystem 25.
25. Fact table provider system. Administration system for the "fact table provider" who receives conformed dimensions sent by the dimension manager. Includes local key substitution, dimension version checking, and aggregate table change management.
26. Job scheduler. System for scheduling and launching all ETL jobs. Able to wait for a wide variety of system conditions including dependencies of prior jobs completing successfully. Able to post alerts.
27. Workflow monitor. Dashboard and reporting system for all job runs initiated by the Job Scheduler. Includes number of records processed, summaries of errors, and actions taken.
28. Recovery and restart system. Common system for resuming a job that has halted, or for backing out a whole job and restarting. Significant dependency on backup system (see subsystem 36).
29. Parallelizing/pipelining system. Common system for taking advantage of multiple processors, or grid computing resources, and common system for implementing streaming data flows. Highly desirable (eventually necessary) that parallelizing and pipelining be invoked automatically for any ETL process that meets certain conditions, such as not writing to the disk or waiting on a condition in the middle of the process.
30. Problem escalation system. Automatic plus manual system for raising an error condition to the appropriate level for resolution and tracking. Includes simple error log entries, operator notification, supervisor notification, and system developer notification.
31. Version control system. Consistent "snapshotting" capability for archiving and recovering all the metadata in the ETL pipeline. Check-out and check-in of all ETL modules and jobs. Source comparison capability to reveal differences between different versions.
32. Version migration system. development to test to production. Move a complete ETL pipeline implementation out of development, into test, and then into production. Interface to version control system to back out a migration. Single interface for setting connection information for entire version. Independence from database location for surrogate key generation.
33. Lineage and dependency analyzer. Display the ultimate physical sources and all subsequent transformations of any selected data element, chosen either from the middle of the ETL pipeline, or chosen on a final delivered report (lineage). Display all affected downstream data elements and final report fields affected by a potential change in any selected data element, chosen either in the middle of the ETL pipeline, or in an original source (dependency).
34. Compliance reporter. Comply with regulatory statutes to prove the lineage of key reported operating results. Prove that the data and the transformations haven't been changed. Show who has accessed or changed any such data.
35. Security system. Administer role-based security on all data and metadata in the ETL pipeline. Prove that a version of a module hasn't been changed. Show who has made changes.
36. Backup system. Backup data and metadata for recovery, restart, security, and compliance requirements.
37. Metadata repository manager. Comprehensive system for capturing and maintaining all ETL metadata, including all transformation logic. Includes process metadata, technical metadata, and business metadata.
38. Project management system. Comprehensive system for keeping track of all ETL development.

If you've survived to the end of this list, congratulations! Here are the important observations I'd like you to carry away: It's really difficult to argue that any of these subsystems are unnecessary as this list makes it really clear that without dividing up the task (perhaps 38 ways), the descent into chaos is inevitable. The industry is ready to define best-practices goals and implementation standards for each of these 38 subsystems, and it would be a tremendous contribution for the ETL tool vendors to provide wizards or serious templates for each of these 38 subsystems. We have a lot to talk about. Maybe 38 more columns!

Ralph Kimball founder of the Kimball Group, teaches dimensional data warehouse design through Kimball University and critically reviews large data warehouse projects. He has four best-selling data warehousing books in print, including the newly released The Data Warehouse ETL Toolkit (Wiley, 2004).

校验选项 (参数 -V 或 --verify):
--nomd5[|=0x1]             不使用MD5分类校验文件
--nofiles[|=0x10000]         不校验包中的文件
--nodeps[|=0x20000]         不校验包的依赖关系
--noscript[|=0x40000]         不执行校验脚本(任何脚本)
-a, --all                 查询/校验所有包
-f, --file               查询/校验包所含的文件
-g, --group               查询/校验组内的包
-p, --package             查询/校验一个包文件(例如一个二进制的 *.rpm 文件)
--querytags               显示已知的查询标签
--specfile               查询规格文件
--whatrequires             查询/校验指定包的依赖关系
--whatprovides             查询/校验指定包的被依赖关系

签名选项:
--addsign                 往包内增加一个签名
--resign                 签名一个包(去除当前签名)
-K, --checksig             校验包的签名
--nogpg[&=~0x4]             忽略任何GPG的签名
--nomd5[&=~0x2]             不校验文件的MD5的校验数

数据库选项:
--initdb                 初始化数据库
--rebuilddb               从已安装包的头信息中重建数据库的反转列表

安装/升级/卸载选项:
--allfiles[|=0x40]           安装所有文件， 忽略找不到的配置项里面的部分
--allmatches[|=0x2]         卸载所有和项匹配的包。(如果中指定多个包则会产生一个错误信息)
--badreloc[|=0x8]           在非重定位包中重定位文件
-e, --erase=+       卸载包
--excludedocs[|=0x20]         不安装文档
--excludepath=         带引导组件的忽略文件
--force[|=0x74]             --replacepkgs --replacefiles的快捷方式
-F, --freshen=+   在已安装的情况下升级包
-h, --hash[|=0x2]           为安装包打上哈希标记(最好带-v选项)
--ignorearch[|=0x2]         不校验包的体系
--ignoreos[|=0x1]           不校验包的操作系统
--ignoresize[|=0x180]         安装之前不检查磁盘空间
--includedocs             安装文档
--install=+       安装包
--justdb[|=0x8]             升级数据库，但是不修改文件系统
--nodeps                 不校验包的依赖关系
--noorder[|=0x8]           不重新记录包的安装信息到依赖性中
--noscripts[|=0xff0000]       不执行包的脚本
--notriggers[|=0x990000]       不执行被该安装包触发的任何脚本
--oldpackage[|=0x40]         升级到该包的一个旧版本
                      (--force 升级的时候，该操作自动执行)
--percent[|=0x1]           打印包的安装进度
--prefix=             如果允许重定位，则重定位包到
--relocate==       从路径到重定位文件
--repackage[|=0x400]         重新打包保存下来的卸载包的文件
--replacefiles[|=0x30]       安装时用包文件替换已安装文件
--replacepkgs[|=0x4]         如果包已经存在，那么重新安装
--test[|=0x1]             不安装包，但是要检测能否正常运行
-U, --upgrade=+   升级包

所有rpm模式的通用选项:
--version                 打印所使用的rpm的版本信息
--quiet                 提供少量详细信息输出
-v, --verbose             提供更多的详细信息输出
--define=' '       使用值来定义宏
--eval=+             打印+的宏扩展
-r, --root=           使用作为顶层目录(默认: "/")
--macros=         读入来代替默认的宏文件
--rcfile=         读入来代替默认的rpmrc文件
--showrc                 显示最终的rpmrc和macro配置

通过popt alias/exec 实现的选项:
--scripts                 列出包中的所有安装/卸载脚本
--setperms               在包中设置文件的权限
--setugids               在包中设置文件的用户/组关系
--conflicts               列出此包的兼容性
--obsoletes               列出安装此包需要卸载的别的包
--provides               列出此包提供的兼容性
--requires               列出此包所需要的兼容性
--info                   列出包中的叙述信息
--changelog               列出该包的变更日志
--triggers               列出包中的触发脚本
--last                   根据安装时间列出包，最近时间的优先
--filesbypkg               列出每个包的所有文件
--redhatprovides           根据所包含的提供的兼容性查找包名(需要安装包rpmdb-redhat)
--redhatrequires           根据所依赖的包的兼容性查找包名(需要安装包rpmdb-redhat)
--buildpolicy=       设置包的根目录(例如，压缩man手册)
--with=             打开打包的配置
--without=           关闭打包的配置
帮助选项:
-?, --help               显示该帮助信息
--usage                 显示用法摘要
******************************************************
1.如何不安装但是获取rpm包中的文件
使用工具rpm2cpio和cpio
rpm2cpio xxx.rpm | cpio -vi
rpm2cpio xxx.rpm | cpio -idmv
rpm2cpio xxx.rpm | cpio --extract --make-directories
参数i和extract相同，表示提取文件。v表示指示执行进程
d和make-directory相同，表示根据包中文件原来的路径建立目录
m表示保持文件的更新时间。

2.如何查看与rpm包相关的文件和其他信息
下面所有的例子都假设使用软件包mysql-3.23.54a-11
1.我的系统中安装了那些rpm软件包
rpm -qa 讲列出所有安装过的包
如果要查找所有安装过的包含某个字符串sql的软件包
rpm -qa |grep sql

3.如何获得某个软件包的文件全名
rpm -q mysql 可以获得系统中安装的mysql软件包全名，从中可以获得
当前软件包的版本等信息。这个例子中可以得到信息mysql-3.23.54a-11

4.一个rpm包中的文件安装到那里去了？
rpm -ql 包名
注意这里的是不包括.rpm后缀的软件包的名称
也就是说只能用mysql或者mysql-3.23.54a-11而不是mysql-3.23.54a-11.rpm。
如果只是想知道可执行程序放到那里去了，也可以用which，比如
which mysql

5.一个rpm包中包含那些文件
一个没有安装过的软件包，使用rpm -qlp ****.rpm
一个已经安装过的软件包，还可以使用rpm -ql ****.rpm

6.如何获取关于一个软件包的版本，用途等相关信息？
一个没有安装过的软件包，使用rpm -qip ****.rpm
一个已经安装过的软件包，还可以使用rpm -qi ****.rpm

7.某个程序是哪个软件包安装的，或者哪个软件包包含这个程序
rpm -qf `which 程序名` 返回软件包的全名
rpm -qif `which 程序名` 返回软件包的有关信息
rpm -qlf `which 程序名` 返回软件包的文件列表
注意，这里不是引号，而是`，就是键盘左上角的那个键。
也可以使用rpm -qilf，同时输出软件包信息和文件列表

8.某个文件是哪个软件包安装的，或者哪个软件包包含这个文件
注意，前一个问题中的方法，只适用与可执行的程序，而下面的方法，不仅可以
用于可执行程序，也可以用于普通的任何文件。前提是知道这个文件名。
首先获得这个程序的完整路径，可以用whereis或者which，然后使用rpm -qf例如：
# whereis ftptop
ftptop: /usr/bin/ftptop /usr/share/man/man1/ftptop.1.gz
# rpm -qf /usr/bin/ftptop
proftpd-1.2.8-1
# rpm -qf /usr/share/doc/proftpd-1.2.8/rfc/rfc0959.txt
proftpd-1.2.8-1

总结：
获得软件包相关的信息用rpm -q，q表示查询query，后面可以跟其他选项，比如
i 表示info，获得软件包的信息；
l 表示list，获得文件列表；
a 表示all，在所有包中执行查询；
f 表示file，根据文件进行相关的查询；
p 表示package，根据软件包进行查询
需要的查询条件可以使用grep产生，或者从"` `"中的命令行产生

9.关于rpm软件包的一些相关知识
1.什么是rpm
rpm 即RedHat Package Management，是RedHat的发明之一

10.为什么需要rpm
在一个操作系统下，需要安装实现各种功能的软件包。这些软件包一般都有各自的
程序，但是同时也有错综复杂的依赖关系。同时还需要解决软件包的版本，以及安装，
配置，卸载的自动化问题。为了解决这些问题，RedHat针对自己的系统提出了一个
较好的办法来管理成千上百的软件。这就是RPM管理系统。在系统中安装了rpm管理系统
以后，只要是符合rpm文件标准的打包的程序都可以方便的安装，升级，卸载

11.是不是所有的linux都使用rpm
任何系统都需要包管理系统，因此很多linux都使用rpm系统。但rpm系统是为RH专门
但是TL,Mandrake等系统也都使用rpm。由于rpm的源程序可以在别的系统上进行编译，
所以有可能在别的系统上也使用rpm
除了rpm，其他一些系统也有自己的软件包管理程序，例如debian的deb包，
slakware也都有自己的包管理系统

12.rpm包的文件名为什么那么长
rpm包的文件名中包含了这个软件包的版本信息，操作系统信息，硬件要求等等。
比如mypackage-1.1-2TL.i386.rpm，其中mypackage是在系统中登记的软件包的名字
1.1是软件的版本号，2是发行号，TL表示用于TL操作系统，还可能是RH等。i386表示
用于intel x86平台，还可能是sparc等。

13.软件包文件名中的i386,i686是什么意思
rpm软件包的文件名中，不仅包含了软件名称，版本信息，还包括了适用的硬件架构
的信息。
i386指这个软件包适用于intel 80386以上的x86架构的计算机(AI32)
i686指这个软件包适用于intel 80686以上(奔腾pro以上)的x86架构的计算机(IA32)
noarch指这个软件包于硬件架构无关，可以通用。
i686软件包的程序通常针对CPU进行了优化，所以，向后兼容比较用以，i386的包在
x86机器上都可以用。向前一般不兼容。不过现在的计算机，奔腾pro以下的CPU已经很少
用，通常配置的机器都可以使用i686软件包

14.不同操作系统发行的rpm包可否混用？
对于已经编译成二进制的rpm包，由于操作系统环境不同，一般不能混用。
对于以src.rpm发行的软件包，由于需要安装时进行本地编译，所以通常可以在不同
系统下安装。

15.使用rpm时遇到的一些特殊问题
Q 我用rpm -e **.rpm无法删除rpm包
A 包名不要包括rpm，
rpm -e 包名，可以包含版本号等信息，但是不可以有后缀.rpm

Q 在MS的系统下有没有读RPM文件的工具？
A wincmd with rpm plugins.....

Q 是否可以通过ftp安装安装升级rpm包？
A 可以。rpm -ivh ftp://xxxxxxxx/PATH2SomeRPM

Q rpm安装时已有的包版本过高怎么办？
A 有时由于安装的软件包太老，而系统中相关的软件包版本比较新，所以可能需要
安装的包依赖的一些文件会找不到。这时有两种解决办法，
第一是在系统文件中找到和需要的文件功能相同或相似的文件，做一个符号链接到
需要的目录下。
第二是下载安装新版本的软件包。
 
 

走了～～
　　怅然若失的观众～～
(一切已成昨日残梦，只待追忆。)



剩下的～～～朋友们看看像什么
　　像不像苍茫的宇宙？
　　　　
　　不知道是巧合
　　还是摄影师有着同样的感觉。。所以拍了这张照片
(除去抹不净的回忆，仿佛什么也没有发生过)




在当地居民的护送下，盛装出行，
　　护送作品的原始形态。。。
　　　　去哪里？　　付诸流水
(最后的一段旅程)



(记住这个画面。时间仿佛已经停止，一个月的时光凝聚在潺潺流淌的溪水边。远处围观的人群，近处沉思的男子，对于一个世界的消失，做着不同的凭吊和评价。而僧人手中缓缓流逝的细沙，已不再有那惊艳的容貌，那些漫天飞舞的佛，那些欣欣向荣的生命，那些宏伟的庙宇，那些千姿百态的繁华。一切都随风飘入溪水，沉淀，褪色，永不再返。)




(又或者说，所有的繁华已属于流水，外人不再得见呢？)

　　整个过程将近一个月，每日作画几小时，展出到6月8 日，然后他们将作品清空，付诸流水。以此象征生命的瞬间。

　　他们用的沙子好像是藏医所用的一种药物，作画的过程却实在是很震撼，虽然有表演的成分，但依旧觉得了不起。尤其是最后的付诸流水，看画面的时候就觉得生命的短暂易逝，后来看文字介绍，这也是他们的初衷之一。

　　整个作品是为了展现生命的短暂易逝，而最后的结果也证明了这一点，引起了我们的思考。但实际上，它的意义远大与此。

　　从艺术的角度看，整幅图画结构严谨，色彩丰富，借助沙粒这种富有层次感和厚重感的媒介，将宗教的意义表现得十分到位。无论是端坐正中的佛，还是围绕在佛周围的神态各异的生灵，还是围绕在世界周围那一圈缥缈的气，都恰到好处的拥有了各自的神采，又和谐的构成了圆满的世界。更令人叹服的是，这种独特的创作手法限制了太大的改动的可能，因此整个图画是一气呵成，就像僧侣们将自己脑中的烂熟的世界观默写出来一般。

　　而从行为的角度看，僧侣本身的创作过程也契合了图画的意图。漫长的创作，成功后短暂的喜悦，然后是毫不犹豫的毁灭。似乎在告诫我们做事的道理，漫长的付出和坚持，短暂的收获，失去的痛苦。

　　当然，我不知道他们心里有没有痛苦，面对精妙的画卷，竟然能伸出那把刷子，境界的确不一样。

　　但从表情看，周围的观众是痛苦的，那恋恋不舍的眼神说明了一切。

　　我也是痛苦的，于是想把它记住，所以花费了近一个小时来贴这篇日志，希望看到的人，能驻足慢慢地翻看，静静的思考。

　　繁华，不过是一掬细沙！

(ok,注意看他们在干什么.)



(看看，周围人们的眼神，不知道他们是怎么想的？
有没有些心痛的感觉，　　还是，欣慰。。。)



(这下明白了吧！)







装殓，艺术品的生命完结了
　　但可能他们留给人们心里的那种感念
　　才是这件作品真正的生命
　　也才，刚刚开始
(及尽繁华，不过一掬细沙。)



(人们从来没有庆祝过生，但对于消亡，却总是有隆重的仪式。)

(工具已经付出了许多)





(不苟言笑的孩子)



(自始至终一丝不苟的创作者)






(完成图，完美的画面，繁华的世界，多看一会儿吧，记住它。英文叫做：mandala)


他们的意思是：时间记录了一切，我们只能是做过这件事情，留下一点痕迹，但这些只是一瞬间的精彩，生命亦是如此。七八十年晃眼而过，回头看看只有那么一点痕迹。
　　
　　人死前的一瞬间一定很复杂。




　展出延续到6月8号。
然后就是简单但是庄严的仪式，也是这次作品的最后完结！

(成功之后的庆祝)

(当一切已趋近完美，人可以做的事情也趋近于无。)







(微笑的佛像)



（精致得难以置信的细节）

3.16





(延续的人生，膨胀的世界)









(由于光线和角度的原因，观众始终以朦胧和模糊的影子出现，如同世界的旁观者。)



3.20
(完成的日子终于到来，辉煌的成就，瑰丽的画卷，以一种强迫的姿态占据每一个人的视界和心灵，乃至灵魂。)

3.12
(近距离观察，清楚地看到沙粒铺垫的厚重质感。)



(逐步显现的最后的圣堂)

(这个，不知道是否就是人，在佛的眼里，与其它生灵平等。)

(这一张可以清除的看到，细沙如何汇聚成世界.)













3.5





(接下来这一组图片，是围绕在佛周围的芸芸众生，每一种生命都跃然沙上)