5

I am connecting to Oracle DB using sysdba:

sqlplus / as sysdba

What is the default password for sysdba user. I tried in net and found out the default password is change_on_install but it is not working for me.

I am interested to know if Oracle DB maintains some file or DB table where it stores the passwords.

3
  • 3
    SYSDBA isn't a username, it's a connection option. Normally, you connect to SQL*Plus using sqlplus user/password or sqlplus sys/sys_password as sysdba. If you're logged into the machine running Oracle, and the user you're logged in has suitable privileges on the machine (normally membership of a certain group), you can log in without a username and password, by writing sqlplus / as sysdba. This logs you in as the user SYS.
    – Luke Woodward
    Mar 27 '13 at 14:58
  • 2
    Just a friendly tip: if you're not sure you know what you're doing, connecting as SYS (which is analogous to a "root"-type account in a unix system) is a recipe for disaster. The best thing you can do is create a lower-privileged user, then login as that user. Mar 28 '13 at 5:39
7

SYSDBA is not a user, it is a system privilege. When you connect as / you are connecting to the SYS user. You don't need a password when you connect as you are - as long as it's a local connection from an OS account in the DBA group.

You haven't said what happens when you try to connect, or why you think you need a password; possibly that is that failing (in which case giving the error message would be helpful) and giving you a SQL*Plus login prompt, maybe indicating you aren't in that group.

Passwords are stored within the DB, the exact location depends on version; but they're stored hashed (of course) so you're not going to be able to get the actual passwords in plaintext (without a lot of time and effort anyway).

0
3

Oracle stores password for SYS and internal user's password in PWD###.ora file, where ### is your DB service Name/SID. I found a nice tutorial on orapwd utility to change password for SYS:

Lost Oracle SYS and SYSTEM password?

1

I had the same issue and then I realized that I was trying to login as root. I installed the database as "oracle" user but then I opened the other terminal which was root by default. so login as "oracle" or whatever user you used to login and it should work.

1

This is an old entry and it should be updated. Password complexity is a concern when changing the SYS/SYSTEM passwords on 19C and above. Oracle 19C has a more complex password complexity requirement and when changing the SYS/SYSTEM password on an upgraded database, you should follow the 19C complexity requirements. This is especially important for AWS RDS, Oracle on-prem cloud and Oracle public cloud (OCI) implementations where the database service is used. You could conceivable continue to use password complexity that is less than what 19C and above call for, however there are numerous consequences. The most obvious consequence is that doing things like setting up a DataGuard instance will fail, since some of the cloud SDKs test for 19C complexity requirements prior to passing the PUT call to the REST API service (aka you get a beautiful python error - or something to that effect).

I make this post since I ran into this issue last week when attempting to provision a DataGuard instance from a 19.6.0.0 database that had been upgraded from 12.x. Long story short, the provisioning failed, and after a long chase it was determined when working with Oracle Support that I had to address the client's not having touched the SYS/SYSTEM password after upgrading from 12.x.

1
  • This is useful information, but I don't see how it answers the original question. You may want to consider posting a separate question/answer pair addressing the issue you are referring to -- it will make it easier to find for those experiencing such problems.
    – mustaccio
    Jun 10 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.