1 问题现象：
之前做的kettle 连接某个oracle数据库 做表抽取
脚本的表输入信息如下图：
执行时（脚本上传到linux机器 用sh命令执行的）表输入报的错误信息：
但是在机器里面用sqlplus 命令登录却可以成功：
2 解决过程：
出现问题后，一开始联系 源数据系统 厂家 看是不是他们那边数据库做了 限制。
经过他们查看，他们那边没有做限制。这边也查不到原因 后来参照别的系统 发现
134.64.197.198 是rac一个节点的浮动地址 对应的sid是 iprandb1。而iprandb 是rac的service-name。rac的service-name与sid不一样。
源系统的 响应服务的实例情况：
[[email protected] ~]$ lsnrctl status
LSNRCTL for Linux: Version 11.2.0.4.0 - Production on 10-SEP-2014 17:35:09
Copyright (c) 1991, 2013, Oracle. All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.4.0 - Production
Start Date 28-JAN-2014 04:29:12
Uptime 225 days 13 hr. 5 min. 56 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /opt/app/11.2.0/grid/network/admin/listener.ora
Listener Log File /opt/app/grid/diag/tnslsnr/iprandb1/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.17.178)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=172.16.17.181)(PORT=1521))) 172.16.17.181对应 ip134.64.197.198
Services Summary...
Service "iprandb" has 1 instance(s).
Instance "iprandb1", status READY, has 1 handler(s) for this service...
Service "iprandbXDB" has 1 instance(s).
Instance "iprandb1", status READY, has 1 handler(s) for this service...
The command completed successfully
之前sqlplus 命令用 iprandb 可以 可能是因为@后面就是要放着 服务名 service-name
可能 jdbc的连接方式 要求填的数据库名 更细点 要求到sid
把kettle的表输入脚本 里面的database name 由iprandb改为iprandb1 就好了
因为涉及到源系统和平台配置的好几个厂家 所以问题拖的时间 很长，在此做记录。
3 了解rac：
之前对rac了解很少 只是听过这个东西，所以 借这个机会 大概了解下这个东西。
rac 是Oracle Real Application Cluster的简写 ，意思是实时应用集群， 是 Oracle数据库支持网格计算环境的核心技术。
自己的理解就是 可以实现负载均衡 和 集群里面某个节点 down 之后 可以立即切换到其它 节点 不影响 基于该数据库的上层应用的正常运行。
一个节点 出现问题后 能够 自动的转到另一个节点上 的这个功能 是因为有 vip 这个东西 全称 virtual ip 他是浮动的ip 可以自动转换。
然后再说下
Oracle RAC services 很多人可能都没搞清楚 oracle服务名 与sid名的区别
（以下内容转载自http://blog.csdn.net/leshami/article/details/8124232 ）
一、services与service_name
services
对于客户端应用程序而言，仅仅需要关心的是数据库提供了哪些服务，而不需要知道它到底连接是哪个数据库或者那个实例。
因此在数据库服务器端我们可以创建一个或多个services供客户端时所用，是一个或多个service_name的统称。
对于这些提供的服务，Oracle会将其注册到监听器以供外部建立连接。
可以通过lsnrctl status [listener_name] 查看当前的服务下有多少个实例为其响应该服务。
也可以通过lsnrctl service [listener_name] 查看更详细的信息，包括当前的连接状况，ip，端口号等。
service_name
指客户端连接到实例的服务名。在Oracle 8i时就有提出service_name的概念，通常用于代替tnsnames.ora中的ORACLE_SID。
9i之后，Oracle推荐使用service_name而不是SID。
可以通过定义多不不同的服务名来区分不同的用户连接，该参数缺省的格式为db_name.domain_name。
下面是一个客户端的tnsnames.ora，两个不同的连接标识符下一个使用了ORACLE_SID，一个使用SERVICE_NAME，两种方式都可行。
SYBO2SZ_SID=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.168.7.2)
(PORT=1915)
)
(CONNECT_DATA=
(ORACLE_SID=SYBO2SZ) #此处使用了ORACLE_SID=<>，也可以直接使用SID=<>
)
)
SYBO2SZ=
(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=192.168.7.2)
(PORT=1915)
)
(CONNECT_DATA=
(SERVICE_NAME=SYBO2SZ) #Oracle 9i之后推荐使用SERVICE_NAME
)
)
二、使用services的益处
如前所述，可以为同一个数据库创建多个不同的services来为不同的客户端分组提供服务。对于单实例而言，尽管可以为其创建多个不同的services，然而提供这些服务始
终是单数据库单实例，因此性能体现的并不明显。
而对于多实例的情形下，能够在不同的时段或根据不同的商业逻辑规则来决定将不同的服务分布到不同的实例，以及可以为
services设定首选实例，备用实例。一旦首选实例出现单点故障，则services会自动failover到备用实例。
假如定义当前RAC数据库有3个节点srv1，srv2，srv3
有两个不同的service分别sales.2gotrade.com和settlement.2gotrade.com在当前数据库运行
则sales部门通过sales.2gotrade.com服务名来建立连接，settlement部门通过settlement.2gotrade.com服务名来建立连接。
其次sales部分的负载通常运行在srv1，srv2，而其对应的备用节点则为srv3，即当节点srv1，srv2失败后，所有基于sales的连接与负载都将转移到节点srv3。
假定settlement部门负载通常较小，因此设定首选节点为srv3，备用节点为srv1，则节点srv3单点故障后，则所有settlement部门连接与负载都将转移到srv1。
所有连接到当前的两个部门无需关心当前连接的是哪个数据库与那个节点上的实例。
从上面的描述可知
各节点连接对于客户端而言是透明的，用户根本无需关心连接到的数据库以及实例，撇开了复杂的后台配置。
另外， 1个 service-name 也可以对应多个不同的sid，就像上面 问题 说的那个情况。