Fixing "ORA-01017: invalid username/password" in Oracle DB

Yeah, that ORA-01017 error is annoying. You know the password is right, but Oracle disagrees. Let's kill this thing.

First, the most common fix: stop assuming passwords are case-insensitive

If you're on Oracle 12c or newer (including 19c, 21c), passwords are case-sensitive by default unless you explicitly set SEC_CASE_SENSITIVE_LOGON = FALSE. The culprit here is almost always a password like MyP@ssw0rd being typed as myp@ssw0rd or someone copying a password with a trailing space.

-- Check if case sensitivity is on:
SELECT name, value FROM v$parameter WHERE name = 'sec_case_sensitive_logon';

If it returns TRUE, then that's your problem. Do not bother changing that parameter — that's a band-aid. Reset the password with quotes to preserve case:

ALTER USER your_username IDENTIFIED BY "ExactPasswordWithCase";

Now try logging in again. Use double quotes around the password in the ALTER statement — that forces Oracle to store it exactly as typed. Without quotes, Oracle uppercases it.

Still failing? Check the listener and the connection string

Often you're connecting to the wrong database. Maybe the tnsnames.ora points to a different server, or you're using a service name that resolves to a different instance. Run this from the client machine:

tnsping your_service_name

It shows you the host, port, and SID or service name. If it's not what you expect, fix tnsnames.ora. Also check the listener log on the server — look for lines with ORA-01017. That log is at $ORACLE_HOME/network/log/listener.log. It'll show the exact username being tried.

When it's a database link

If the error pops up when you query across a db link — like SELECT * FROM table@my_link — then the link's password is stale. The db link stores encrypted credentials, and if you changed the user's password on the remote database, the link breaks silently.

-- Recreate the db link with the new password:
CREATE DATABASE LINK my_link
  CONNECT TO remote_user IDENTIFIED BY "new_password"
  USING 'remote_db';

Don't bother trying to alter the link — just drop and recreate it. Oracle doesn't give you a convenient way to update a link's password otherwise.

Less common variations

1. Password file mismatch

If you're using password file authentication for SYSDBA or SYSOPER, and you recently changed the SYS password, the password file (orapw<SID>.ora) might be out of sync. Recreate it with orapwd:

orapwd file=$ORACLE_HOME/dbs/orapwORCL password="new_sys_password" force=y

Don't forget the force=y — it overwrites the old file.

2. Squatter user accounts

Sometimes you create a user with the same name on two databases, but one database has a different password. The connection string might resolve to the wrong database. Verify by connecting directly with:

sqlplus username/password@(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=correct_host)(PORT=1521))(CONNECT_DATA=(SID=correct_sid)))

If that works, your tnsnames.ora is wrong.

3. Account lockout

After too many wrong attempts, Oracle locks the account. Check with:

SELECT username, account_status, lock_date FROM dba_users WHERE username = 'YOUR_USERNAME';

If it says LOCKED or EXPIRED & LOCKED, unlock it:

ALTER USER your_username ACCOUNT UNLOCK;

Prevention: don't let this happen again

• Use a password manager — or at least write down passwords with exact case. Lazy admins paste from notepad and include hidden spaces.
• Set SEC_CASE_SENSITIVE_LOGON = FALSE only if you must — it's a security downgrade, but it kills the case problem. I do this for legacy apps that hardcode passwords.
• Monitor failed logins with a quick query:

SELECT os_username, username, userhost, timestamp
  FROM dba_audit_trail
  WHERE returncode = '1017'
  ORDER BY timestamp DESC;

That shows you exactly who's failing and from where. If you see repeated failures from an app server, the app's connection string is wrong.

That's it. Nine out of ten ORA-01017 errors die with a password case check. The rest are db link or listener issues. Know your connection path, respect case sensitivity, and you're golden.