Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

104
CHAPTER 3 ■ FILES
are no “remote SYSDBA logins.” It has two other settings: SHARED (more than one database can
use the same password file) and EXCLUSIVE (only one database uses a given password file).
We’ll set ours to EXCLUSIVE, as we want to use it for only one database (i.e., the normal use):
SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;
System altered.
This setting cannot be changed dynamically while the instance is up and running, so we’ll
have to restart for this to take effect. The next step is to use the command-line tool (on UNIX
and Windows) named orapwd:
[ora10g@localhost dbs]$ orapwd
Usage: orapwd file= password= entries= force=
where
file - name of password file (mand),
password - password for SYS (mand),
entries - maximum number of distinct DBA and OPERs (opt),
force - whether to overwrite existing file (opt),
There are no spaces around the equal-to (=) character.
to create and populate the initial password file. The command we’ll use is
$ orapwd file=orapw$ORACLE_SID password=bar entries=20
That created a password file named orapwora10g in my case (my ORACLE_SID is ora10g).
That is the naming convention for this file on most UNIX platforms (see your installation/OS
admin guide for details on the naming of this file on your platform), and it resides in the
$ORACLE_HOME/dbs directory. On Windows, this file is named PW%ORACLE_SID%.ora and is located
in the %ORACLE_HOME%\database directory.
Now, currently the only user in that file is in fact the user SYS, even if there are other
SYSDBA accounts on that database (they are not in the password file yet). Using that knowledge,
however, we can for the first time connect as SYSDBA over the network:
[ora10g@localhost dbs]$ sqlplus sys/bar@ora10g_admin.localdomain as sysdba
SQL*Plus: Release 10.1.0.3.0 - Production on Sun Jan 2 20:49:15 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to an idle instance.
SQL>
We have been authenticated, so we are in—we can now successfully start up, shut down,
and remotely administer this database using the SYSDBA account. Now, we have another user,
OPS$TKYTE, who has been granted SYSDBA, but will not be able to connect remotely yet:
[ora10g@localhost dbs]$ sqlplus 'ops$tkyte/foo' as sysdba
SQL*Plus: Release 10.1.0.3.0 - Production on Sun Jan 2 20:51:07 2005
Copyright (c) 1982, 2004, Oracle. All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.1.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> show user