oracle rac etl,ETL技术工具kettle入门笔记(一) 之kettle连接oracle rac 报listener does not currently know of sid错误的解...

本文记录了一次通过Kettle连接Oracle RAC数据库时遇到的问题,表现为使用服务名连接失败,但通过SID能成功。经过排查发现是服务名与SID的区别导致的,最终通过修改数据库名称为SID解决了问题。同时,文章介绍了Oracle RAC的基本概念,包括其负载均衡和故障切换功能,以及服务名和服务实例的关系,强调了在连接Oracle数据库时使用服务名而非SID的推荐做法。
摘要由CSDN通过智能技术生成

1 问题现象:

之前做的kettle 连接某个oracle数据库 做表抽取

脚本的表输入信息如下图:

a100c936cbc2a4488668bbc1ac8a4310.png

执行时(脚本上传到linux机器 用sh命令执行的)表输入报的错误信息:

219355c704fa4cdac5c4cb7f282fc891.png

但是在机器里面用sqlplus 命令登录却可以成功:

a4121136009993a343ce68f9624a2bf0.png

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 可以 [email protected] 服务名 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,就像上面 问题 说的那个情况。

原文:http://blog.csdn.net/xiaohai798/article/details/39958597

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值