This is an Oracle database error, indicating that the Designer client was not able to connect to the database. Are you able to connect to the same database using SQL*Plus installed in the same ORACLE home as Designer?
Simply restarting the service doesn't help - same behaviour to me once in two weeks.
The only thing that works is restarting the machine. Check if you use NTS authentication.
Could be that you have problems with the domain controller/active directory that
can cause in such authentication failures.
Just to workaround this problem (in the case of this authentication method) you
can create a local os user, add him to ORA_DBA group and start your oracle
client in the context of this local user ("runas").
No other idea to solve this problem. I'm sure when the system is well configured,
then there is one process which has lost communication with the authentication
Please check the sqlnet.ora file. Change the following entry and try, this will work.
Original Entry - SQLNET.AUTHENTICATION_SERVICES= (NTS)
Modified Entry - SQLNET.AUTHENTICATION_SERVICES= (NONE)
I'm no Oracle expert, but from what can make out the NTS option makes the Oracle client attempt to use your current Windows domain credentials to authenticate you with the Oracle server. This could fail for a couple of reasons:
- The Oracle server is not configured to support Windows authentication
- The credentials you use to login to your local machine are not sufficient to allow you to login to the server.
In my case, it was the later. Despite the fact that I had told the client to use a different user name and password, it was still attempting to login using my domain credentials first. This failed because I was logged on to my local machine using my normal domain credentials rather than my administrator account.
Replacing the line:
in sqlnet.ora resolved the issue by disabling local support for authenticating using Windows credentials.
About the error ORA-12638, I could solve it by using the parameter SQLNET.AUTHENTICATION_SERVICES = NONE.
However, the consequence is that it's no more possible to connect as sysdba without password. The following statement return the error ORA-01031:
connect / as sysdba
I've ever heard that in RAC it's necessary to be able to connect as sysdba with the statement above.
Best regards ,
Here is something really strange. I had the same problem so I changed the file specifying NONE but this gave me a different credential error so I changed the file back to NTS. I resaved the file, rebooted the box and voila everything started working OK.
I had this problem on 3 other servers (we are running SAP) and on everyone of these servers I merely added a comment line to the file, rebooted and it fixed every system.
It would be nice to know what causes this problem to all of a sudden pop up when these databases have been running for several months without any similar issues.
I have had a similar problem. And the solution worked well too. I am slighly curious to know more on what would this mean.
"The consequence is that it's no more possible to connect as sysdba without password. The following statement return the error ORA-01031:
connect / as sysdba "
Does this also mean that it would not be possible to connect to the database from a remote machine in anyway?
Reasons why would you not keep it SQLNET.AUTHENTICATION_SERVICES= (NONE) or
I am not a expert on oracle but here are my ideas.
connect / as sysdba will work fine only when u have logged into the system with an OS administrator level account and when the
The entry SQLNET.AUTHENTICATION_SERVICES= (NONE) in the sqlnet.ora file sets it to no authentication methods. A valid database username and password will be required to connect to the database.
I repeatedly see the solution to the ora-12638 error as changing your sqlnet.ora file to remove NTS authentication mode, however, what happens when you have some databases which ARE set up for OS (windows) authentication?
A client has one sqlnet.ora. Our standard is to set that up as SQLNET.AUTHENTICATION_SERVICES= (NTS). In this way, we had hoped that when a userid/password was provided, Oracle would use it.... and when OS authentication was appropriate, Oracle would use that. This works 97 percent of the time, however, the 3 percent kills us.
Oracle seems to go the OS authentication route even though an oracle id and password is supplied. Why is this?