Forum Stats

  • 3,768,266 Users
  • 2,252,770 Discussions
  • 7,874,511 Comments

Discussions

Unable to install Oracle 10g under VMWare due to ORA-12154 error

608338
608338 Member Posts: 6
edited Sep 5, 2008 2:44AM in Database Installation
Hi,

I'm unable to install Oracle 10g (10.0.2.0 from original CD) on Windows 2003 Server and CentOS 5.2. At the moment during an installation process when a database instance is created I've got ORA-12154: TNS:listener does not currently know of service requested in connect descriptor. When I ignore that error I'm later unable to connect a database using SQL Plus (SQL Developer works). I tried many different options with configuration without any success.
I tried on the fresh systems (win & linux) working under VMWare with the same result. I wasn't able to find any bug related with vmware and mentioned error. It's a little bit similar to [that thread|http://forums.oracle.com/forums/thread.jspa?threadID=689272], but have the same issue also with two cpus.
It's very strange for me, because the installer should know how to create required files (tnsnames.ora and others) for its purposes.

Thanks for your help
Marcin

Answers

  • Paul M.
    Paul M. Member Posts: 10,947
    SQL Developer works
    Then the DB is up and running. Does the following work ?

    $ export ORACLE_SID=<your SID>
    $ sqlplus / as sysdba
    Paul M.
  • 608338
    608338 Member Posts: 6
    Thanks for your reply!

    As a quick answer I can say yes, I was able to connected to my Oracle instance with sqlplus. But I have to confirm it which I will able to do only tomorrow.

    But in the meantime there are two things which I don't understand.

    1. After my first post it was checked that on a physical machine (not the vmware one) Oracle installer throws the same error during an installation process (so it's not a problem with vmware). Is the any known problem with that CD version (10.2.0.1.0)? It didn't work on both Linux and Windows.

    2. On the machine with Windows 2003 I wasn't able to connect to the database from both localhost (with Oracle) and remote machine with SQL Plus from Oracle 9 (which works now). But when I entered a wrong password (even from a remote machine) I've got the reply that user/password is wrong - so sqlplus was able to connect listener and check a password. Only with good credentials database returned ORA-12154. So it looked as a problem with database itself, not only with SQL Plus (unfortunately that machine was reformated to the Linux one). Was it possible that after installation some important system variables aren't set by the installer during/after installation (which could be relate to the first question)?
  • Paul M.
    Paul M. Member Posts: 10,947
    ORA-12154 error normally shows up when tnsnames.ora is not present (where it should be), or has syntax errors. Error details follow :
    $ oerr ora 12154
    12154, 00000, "TNS:could not resolve the connect identifier specified"
    // *Cause:  A connection to a database or other service was requested using
    // a connect identifier, and the connect identifier specified could not
    // be resolved into a connect descriptor using one of the naming methods
    // configured. For example, if the type of connect identifier used was a
    // net service name then the net service name could not be found in a 
    // naming method repository, or the repository could not be
    // located or reached.
    // *Action:
    //   - If you are using local naming (TNSNAMES.ORA file):
    //      - Make sure that "TNSNAMES" is listed as one of the values of the
    //        NAMES.DIRECTORY_PATH parameter in the Oracle Net profile
    //        (SQLNET.ORA)
    //      - Verify that a TNSNAMES.ORA file exists and is in the proper
    //        directory and is accessible.
    //      - Check that the net service name used as the connect identifier
    //        exists in the TNSNAMES.ORA file.
    //      - Make sure there are no syntax errors anywhere in the TNSNAMES.ORA
    //        file.  Look for unmatched parentheses or stray characters. Errors
    //        in a TNSNAMES.ORA file may make it unusable.
    //   - If you are using directory naming:
    //      - Verify that "LDAP" is listed as one of the values of the
    //        NAMES.DIRETORY_PATH parameter in the Oracle Net profile
    //        (SQLNET.ORA).
    //      - Verify that the LDAP directory server is up and that it is
    //        accessible.
    //      - Verify that the net service name or database name used as the
    //        connect identifier is configured in the directory.
    //      - Verify that the default context being used is correct by
    //        specifying a fully qualified net service name or a full LDAP DN
    //        as the connect identifier
    //   - If you are using easy connect naming:
    //      - Verify that "EZCONNECT" is listed as one of the values of the
    //        NAMES.DIRETORY_PATH parameter in the Oracle Net profile
    //        (SQLNET.ORA).
    //      - Make sure the host, port and service name specified
    //        are correct.
    //      - Try enclosing the connect identifier in quote marks.
    // 
    //   See the Oracle Net Services Administrators Guide or the Oracle
    //   operating system specific guide for more information on naming.
    $ 
    You're speaking of "installation", but your DB is running, so the installation should have succeeded. Did you create it afterwards ?

    Did you try using Net Configuration Assistant ? (netca command on Linux)
  • 608338
    608338 Member Posts: 6
    Paul M. wrote:
    You're speaking of "installation", but your DB is running, so the installation should have succeeded. Did you create it afterwards ?
    I have selected on option to create the first instance during (just after) the installation process. I would assume that installer passes on all required settings to that subprogram.
    Did you try using Net Configuration Assistant ? (netca command on Linux)
    Yes, I was playing a few hours with that tool under Windows 2003 and manually editing *.ora files. Without any result :(.


    Today I have checked an ability to connect to my server with sql*plus and in fact I am able to connect to it (from local and remote machine), but only on "normal" user (I have never checked with normal user before). When I try to login to as sys/system I have got ORA-12154 (login as sys via sql developer still works).

    Do you have an idea why it's not possible to login only on sys via sql*plus (especially with that error message)?
  • Paul M.
    Paul M. Member Posts: 10,947
    When I try to login to as sys/system I have got ORA-12154
    Trying to understand....

    Just for the moment let's forget sys user and let's speak of Sql*Plus only.

    From the same remote machine, and using the same connection string you're able to connect as "normal" user, and not as SYSTEM. Is it really so ?
  • 608338
    608338 Member Posts: 6
    edited Sep 4, 2008 6:22PM
    Paul M. wrote:
    From the same remote machine, and using the same connection string you're able to connect as "normal" user, and not as SYSTEM. Is it really so ?
    It's strange for me as well, but from remote Windows machine, with sql*plus from Oracle 9 (AFAIR sql*plus from Oracle 10 has the same problem), connection configured in tnsnames.ora (sorry for snipsets only, but on that machine national locales are set and messages aren't in English).

    $ sqlplus [email protected]
    <good password>
    Oracle Database 10g Release 10.2.0.1.0 - Production
    SQL>

    $ sqlplus [email protected] (also [email protected])
    <good password>
    ERROR:
    ORA-12154: TNS:could not resolve service name

    $ sqlplus [email protected]
    <wrong password>
    ERROR:
    ORA-01017: invalid username/password; logon denied
  • 529937
    529937 Member Posts: 958
    Are the connections you attempted all from the same host?
  • 608338
    608338 Member Posts: 6
    user21123 wrote:
    Are the connections you attempted all from the same host?
    Yes. All three commands were executed one by one from the same command prompt window.
This discussion has been closed.