REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE in Oracle 10g

2 min read
Jun 18, 2007 12:00:00 AM

I’ve never really liked the idea of REMOTE_LOGIN_PASSWORDFILE=SHARED, probably just because I haven’t seen much use for it. As a result, I’ve never paid any attention to it. If you don’t recall the difference between EXCLUSIVE and SHARED settings for 9i, here is the quote from the documentation:

SHARED More than one database can use a password file. However, the only user recognized by the password file is SYS. EXCLUSIVE The password file can be used by only one database and the password file can contain names other than SYS.

As I said, I could never imagine the use case for a shared password file. If you have better ideas of a situation that is a good fit for shared password file, please share.

Migration Discoveries: The SHARED vs. EXCLUSIVE Mystery

Today, I was going through a migration strategy with a client, and we were reviewing init.ora parameters. I noticed that they used SHARED settings for their password file and was curious why. Apparently, there was no clear explanation for the SHARED setting and it was used more or less as exclusive — one file per instance.

Alex Fatkulin seemed to be curious too and did the RTFM part for me (good boy!) and, surprise! The EXCLUSIVE setting is not actually used in the same way starting with 10g.

10g and Beyond: Merged Functionality

It turned out that Oracle merged the SHARED and EXCLUSIVE password file features — now we can use a shared password file and store passwords for users other than SYS. REMOTE_LOGIN_PASSWORDFILE=SHARED is used for that. EXCLUSIVE still works for backwards compatibility but now it behaves just like SHARED.

Updated Reference from the Documentation

Here is the new reference from the docs:

  • NONE: Oracle ignores any password file. Therefore, privileged users must be authenticated by the operating system.
  • SHARED: One or more databases can use the password file. The password file can contain SYS as well as non-SYS users.

Note: The value EXCLUSIVE is supported for backward compatibility. It now has the same behavior as the value SHARED.

Conclusion: The Importance of Re-Reading the Manual

There are quite a few non-obvious behavior changes that are not well known but are in fact documented, so thorough RTFM-ing seems to be a good idea with every new release. For our part, we will try to post some of them here so stay tuned!

Oracle Database Consulting Services

Ready to optimize your Oracle Database for the future?

On this page

Ready to unlock value from your data?

With Pythian, you can accomplish your data transformation goals and more.