Re: Multiple Homes and CONNECT

Thanks for the responses. I should back up for a minute and explain that I'm not really a database admin. I've been assigned to automate a procedure that our field people were using to collect information about the configuration of Oracle databases at customer sites. These would always be on Windows NT systems. The procedure involved running svrmgrl and submitting a list of standard queries, with the results being spooled to a file. Anyway, so I've written a VBScript now that can run svrmgrl and submit a file containing queries. The script also asks the user for the user ID, password, database, and Oracle Home to use for the connect (if there are multiple homes).

The two Oracle Homes on my system are not used for production, but include the databases that are installed automatically with Oracle when you install Oracle twice. When I installed Oracle the second time, the install asked me for a number of names to use including I believe a domain name and an instance name. I ended up with a global database name = Joseph.Two and an SID = Two.

> Try to set environmen variable
> SET ORACLE_SID=TWO
> at the command prompt and then run svrmgr and connect internal/oracle
> Marco Nicolazzo

This worked; after I did this I was able to connect with "connect internal/oracle_at_two". But I'm a little concerned about using this statement on a customer system -- would it affect their environment in a way that they might not like? On the other hand, the environment variable seems to have disappeared since I rebooted . . . So perhaps it's temporary anyway and nobody would mind?

Anyway, after rebooting I was inspired to try using Joseph.Two in the connect string, and this also worked, that is "connect internal/oracle_at_Joseph.Two". But if my script asks the user for the database name to use in the connect string, would the user even think of supplying the name in this form?

Also, I'm still not sure if the database setup I have on my system is a good test case. Perhaps if I made some of the database configuration changes mentioned in the other replies to my message, I would have a more "normal" configuration to test against?

> a) tnsping two --> is it ok ? if not check tnsnames.ora and listener.ora
> b) did you call the oraenv to change the SID ?
> c) Do not forget to declare the entry of two in the oratab
> B.Polarski

"tnsping two" was not able to connect successfully. However, "tnsping Joseph.Two" worked. Tnsnames.ora includes the following:

JOSEPH.TWO =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = mv-moralejf)(PORT = 1521))     )
    (CONNECT_DATA =
      (SERVICE_NAME = Joseph.Two)
    )
  )

Listener.ora includes the following:

SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =

      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = D:\Oracle\OraTwo)
      (PROGRAM = extproc)

      (GLOBAL_DBNAME = Joseph.Two)
      (ORACLE_HOME = D:\Oracle\OraTwo)
      (SID_NAME = Two)

Oraenv -- This is barely mentioned in the documentation. It appears to be a UNIX thing? The file doesn't exist on my system.

Oratab -- Also barely mentioned in the docs. I don't have such a file on my system. Perhaps also a UNIX thing?

> I has this problem. I has 2 instances and I can´t connect to one.
> You must create the instance alias with SQL Net easy
> and then change the listener file (in c:\orant\network\listener.ora)
> Then you must shutdown the PC.
> Juan miradna

I can't seem to find any info in the documentation about creating an instance alias with SQL Net easy. Also, I have SQL Net but I don't see a program called SQL Net easy.

My listener file seems to have similar SID_DESC info to your example, as shown previously in this message.

> Have you tried creating a database link from one SID to the other?
> Matt B.

Not sure how to do this . . . Would this be a "typical" thing for a customer to do?

Thanks again for any assistance. I'm almost completely ignorant of Oracle, and I'm haven't been finding things very successfully in the Oracle documentation!

Yours, Joseph Morales Received on Tue Jun 27 2000 - 00:00:00 CEST