Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

0

积分

1

好友

10

主题
1#
发表于 2014-4-15 22:27:43 | 查看: 7186| 回复: 3
11.2.0.3RAC环境归档满 导致数据库不能操作,由于客户着急,有同事将其中一台shutdown了 我去了以后发现归档满,就删除归档文件,然后再去启动节点1后 导致scanip监听不能用,本地服务连接没有问题,plsql去连接报错 ora-12541 奇怪的是有的可以连接,有的不可以!
4#
发表于 2014-4-16 20:09:46
ORA-12541 with failover using a Client lower than 11.2 to SCAN Listener (Doc ID 1365631.1)

APPLIES TO:

Oracle Net Services - Version 11.2.0.2 to 11.2.0.2 [Release 11.2]
Information in this document applies to any platform.
SYMPTOMS

When testing fail over capabilities OR when a failover condition occurs, you notice that clients connecting through the 11.2 SCAN Listener address fail to re-establish the connection with an ORA-12541 "TNS:no listener" error.
The clients are 11.1 or lower and might include 11.1 or lower JDBC Thin Clients / drivers.

CHANGES

Fail over testing or actual fail over condition with an 11.2 RAC environment and active-active nodes.

CAUSE

Client versions 11.1 and lower cannot use SCAN connectivity without losing fail over functionality.
This is due to the fact that only 11.2 has the capabilities to use all the IP addresses used by the single Scan name.
Anything lower than 11.2 will not be able to switch to the surviving address in the event of a failure of one node, and this will result in the Client remaining with the single IP address that is down.

SCAN was only introduced in 11.2 so this is an expected limitation.

This is also true and applies to JDBC Thin clients and not just Oracle*Net clients.


SOLUTION

1. If the Client is 11.2, the the connection can be made to the SCAN address with all RAC functionality available at the target end.
For example (assuming the SCAN hostname is SCAN-common and port 1521):


PROD =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL=TCP)(HOST=SCAN-common.domain)(PORT=1521))
      (CONNECT_DATA = (SERVER=DEDICATED)(SERVICE_NAME=ORCL))
   )



2. If the Client is 11.1 or lower, the Local VIP addresses need to be used (original 11.1 and lower failover and load balancing method).
For example:


PROD =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL=TCP)(HOST=VIP1.domain)(PORT=1521))
      (ADDRESS = (PROTOCOL=TCP)(HOST=VIP2.domain)(PORT=1521))
      (CONNECT_DATA = (SERVER=DEDICATED)(SERVICE_NAME=ORCL))
   )


* NOTE: This note is intended for Client fail over assistance and the default settings for the REMOTE_LISTENER and LOCAL_LISTENER (Database) parameters will still be set to the SCAN address and local VIP node addresses respectively.

回复 只看该作者 道具 举报

3#
发表于 2014-4-16 20:09:25
ORA-12541 with failover using a Client lower than 11.2 to SCAN Listener (Doc ID 1365631.1)

APPLIES TO:

Oracle Net Services - Version 11.2.0.2 to 11.2.0.2 [Release 11.2]
Information in this document applies to any platform.
SYMPTOMS

When testing fail over capabilities OR when a failover condition occurs, you notice that clients connecting through the 11.2 SCAN Listener address fail to re-establish the connection with an ORA-12541 "TNS:no listener" error.
The clients are 11.1 or lower and might include 11.1 or lower JDBC Thin Clients / drivers.

CHANGES

Fail over testing or actual fail over condition with an 11.2 RAC environment and active-active nodes.

CAUSE

Client versions 11.1 and lower cannot use SCAN connectivity without losing fail over functionality.
This is due to the fact that only 11.2 has the capabilities to use all the IP addresses used by the single Scan name.
Anything lower than 11.2 will not be able to switch to the surviving address in the event of a failure of one node, and this will result in the Client remaining with the single IP address that is down.

SCAN was only introduced in 11.2 so this is an expected limitation.

This is also true and applies to JDBC Thin clients and not just Oracle*Net clients.


SOLUTION

1. If the Client is 11.2, the the connection can be made to the SCAN address with all RAC functionality available at the target end.
For example (assuming the SCAN hostname is SCAN-common and port 1521):


PROD =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL=TCP)(HOST=SCAN-common.domain)(PORT=1521))
      (CONNECT_DATA = (SERVER=DEDICATED)(SERVICE_NAME=ORCL))
   )



2. If the Client is 11.1 or lower, the Local VIP addresses need to be used (original 11.1 and lower failover and load balancing method).
For example:


PROD =
   (DESCRIPTION =
      (ADDRESS = (PROTOCOL=TCP)(HOST=VIP1.domain)(PORT=1521))
      (ADDRESS = (PROTOCOL=TCP)(HOST=VIP2.domain)(PORT=1521))
      (CONNECT_DATA = (SERVER=DEDICATED)(SERVICE_NAME=ORCL))
   )


* NOTE: This note is intended for Client fail over assistance and the default settings for the REMOTE_LISTENER and LOCAL_LISTENER (Database) parameters will still be set to the SCAN address and local VIP node addresses respectively.

回复 只看该作者 道具 举报

2#
发表于 2014-4-16 20:09:10
ODM FINDING:

please check:
        Bug 10385510 - JDBC TCPS connections via SCAN listeners fail when one of the listeners is down (Doc ID 10385510.8)

        JDBC TCPS Connections Do Not Failover For SCAN Listeners (Doc ID 1289244.1)

JDBC thin 11.2.0.1 and 11.2.0.2 connections over TCPS fail with the following error when one of the SCAN
listeners and associated VIP are disabled/stopped and do not fail over to the
other available SCAN listeners.

IO Error: The Network Adapter could not establish the connection
ORA-12541: TNS No Listener

JDBC TCP connections and sqlplus/OCI connections work as expected and failover correctly.

CAUSE

JDBC TCPS connections do not failover using SCAN listeners.
The following bug addresses the problem:
Bug 10385510 - JDBC TCPS CONNECTIONS DO NOT FAILOVER USING SCAN LISTENERS



SOLUTION

Apply patch 10385510

or

Upgrade to JDBC 11.2.0.3 or higher where the issue is fixed.


Intermittent ORA-12541 when Connecting via SCAN listener in RAC (Doc ID 1547757.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later
Information in this document applies to any platform.
SYMPTOMS

When using scan name to connect to a RAC database RACPROD on a 2 node production cluster, intermittently getting ORA-12541: "TNS:no listener".

CAUSE

Case I. An instance named RACPROD is running on the TEST server, its remote_listener is wrongly set to <SCAN>:1521 which is pointing to the production cluster, causing it registered with scan listeners. Client connections made via LISTENER_SCAN<n> are diverted to this instance. With IP 127.0.0.1 registered, this is no listener listener on this IP, hence error ORA-12541 reported.


[grid@srvprod1 ~]$ lsnrctl services LISTENER_SCAN1

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 16-APR-2013 17:45:20

Copyright (c) 1991, 2010, Oracle. All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))
Services Summary...
Service "RACPROD" has 3 instance(s).
  Instance "RACPROD", status READY, has 1 handler(s) for this service...
    Handler(s):
    "DEDICATED" established:44 refused:0 state:ready
    REMOTE SERVER
    (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=1521)))                        <<<< this is the problem.
Instance "RACPROD1", status READY, has 1 handler(s) for this service...
   Handler(s):
   "DEDICATED" established:53 refused:0 state:ready
    REMOTE SERVER
    (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.1.1)(PORT=1521)))
Instance "RACPROD2", status READY, has 1 handler(s) for this service...
   Handler(s):
   "DEDICATED" established:80 refused:0 state:ready
   REMOTE SERVER
   (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.1.2)(PORT=1521)))



Case II. Another possible cause for ORA-12541 for client connection using the <SCAN>:1521 from a client machine, while the scan listeners running fine on the cluster is the network setup blocking the connection.A simple test like the following will show the error:

$ telnet <SCAN> 1521
Trying 10.1.1.10...
Connected to scan.example.com (10.1.1.10). Connection refused
Trying 10.1.1.11...
Connected to scan.example.com (10.1.1.11). Connection refused
Trying 10.1.1.12...
Connected to scan.example.com (10.1.1.12). Connection refused
In this case, ORA-12541 is constantly reported for the connections made from client machine, when the same connection string has no issue from the cluster node itself.

SOLUTION

Case I. Unset the remote_listener for the single instance RACPROD on the TEST server. If the remote_listener is required, set it to proper value, not pointing to the production cluster.

alter system set remote_lisetener='' scope=both;


Case II. Please engage network admin to modify the network configuration and allow connection to the SCAN IP from outside the cluster nodes.

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-21 10:11 , Processed in 0.049191 second(s), 21 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569