-
Title
Debugger error: Unable to find RAC connection information. -
Description
When trying to debug, an error noting problems with the RAC connection is received, but Toad is connected already and does not seem to have other problems.
Error message:
"Unable to find RAC connection information" -
Cause
A) The issue may be due to the load balancing setting in tnsnames.ora file. The control process of the debugger requires a 2nd session and Toad can't connect because of the load balancing parameter in the tnsnames.ora file.
B) Needs additional privileges.
-
Resolution
Debugging on a RACDuring debugging, Toad creates two background sessions for handling debugger calls: target and debug sessions. These sessions MUST be on the same instance as the main Toad session.To enable debugging you must:• Have an additional entry in your TNSNames.ora file for the connected instance.Or• Connect directly to an instance of the cluster without letting the server assign one.Or• Have Oracle version 11g Release 2 or newerAndo Have the SELECT privilege on GV$LISTENER_NETWORK and GV$INSTANCEAndo Have EZCONNECT specified in the NAMES.DIRECTORY_PATH parameter of SQLNET.OraToad accomplishes debugging as follows:• Queries the data dictionary to find the current instance name• Searches the TNSNames.ora file for the first entry that matches SERVICE_NAME or INSTANCE_NAME.• Uses the secondary TNSNames entry when creating the background debugger sessions.If the preceding query and TNSNames search fails, and the database version is 11.2 or newer, Toad will attempt to find the TNSInfo in GV$LISTENER_NETWORK. If the information is found here, a TNS EZConnect string can be created, and Toad will use that to connect the debug session.====================RESOLUTION 1:
Add SELECT privilege on GV$LISTENER_NETWORK and GV$INSTANCE if on Oracle 11g R2 database server. (NOTE: The permission is case sensitive for Toad to pick up properly.) Also add EZCONNECT in the NAMES.DIRECTORY_PATH parameter of the SQLNET.ora file.RESOLUTION 2:
Create additional entries in all tnsnames.ora for each RAC nodes, without load balancing. If you use ASP, change ASPs for all Agents for all nodes to connect using this entry.Example:
RAC, two nodes, OracleHome installed on shared drivetnsnames.ora:
RAC_FGL1 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = node1)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RAC)
(INSTANCE_NAME=inst1)
)
)
RAC_FGL2 =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = node2)(PORT = 1522))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RAC)
(INSTANCE_NAME=inst2)
)
)
Agent Oracle_RAC1 on node1 is configured to connect via RAC_FGL1, Oracle_RAC2 on node2 is connecting via RAC_FGL2 entry.RESOLUTION 3:
Modify existing SQLNET.ORA file and take out the LDAP paramater :
NAMES.DIRECTORY_PATH= (LDAP, TNSNAMES, EZCONNECT, ONAMES, HOSTNAME)RESOLUTION 4:
Please, check with the DBA to see if there is an LDAP server in this environment.
If so, place the RAC entries from the tnsnames.ora file from the local machine into the LDAP server.RESOLUTION 5:
Connect using TNS, instead of using Direct connect.RESOLUTION 6:
View the below solution for possible Toad issue:
https://support.quest.com/toad-for-oracle/kb/53059 -
Additional Information
INSTANCE_NAME can be identified by connecting to your RAC and executing SQL statement:
select inst_id, instance_number, instance_name, host_name from GV$INSTANCE;Remove "ADDRESS_LIST" and "SERVER = DEDICATED" for the instances