Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
CHAPTER 3 ■ FILES 103 Password Files The password file is an optional file that permits remote SYSDBA or administrator access to the database. When you attempt to start up Oracle, there is no database available that can be consulted to verify passwords. When you start up Oracle on the “local” system (i.e., not over the network, but from the machine the database instance will reside on), Oracle will use the OS to perform the authentication. When Oracle was installed, the person performing the installation was asked to specify the “group” for the administrators. Normally on UNIX/Linux, this group will be DBA by default and OSDBA on Windows. It can be any legitimate group name on that platform, however. That group is “special,” in that any user in that group can connect to Oracle “as SYSDBA” without specifying a username or password. For example, in my Oracle 10g Release 1 install, I specified an ora10g group. Anyone in the ora10g group may connect without a username/password: [ora10g@localhost ora10g]$ sqlplus / as sysdba SQL*Plus: Release 10.1.0.3.0 - Production on Sun Jan 2 20:13:04 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 USER is "SYS" That worked—I’m connected, and I could now start up this database, shut it down, or perform whatever administration I wanted to. However, suppose I wanted to perform these operations from another machine, over the network. In that case, I would attempt to connect using @tns-connect-string. However, this would fail: [ora10g@localhost admin]$ sqlplus /@ora10g_admin.localdomain as sysdba SQL*Plus: Release 10.1.0.3.0 - Production on Sun Jan 2 20:14:20 2005 Copyright (c) 1982, 2004, Oracle. All rights reserved. ERROR: ORA-01031: insufficient privileges Enter user-name: OS authentication won’t work over the network for SYSDBA, even if the very unsafe (for security reasons) parameter REMOTE_OS_AUTHENT is set to TRUE. So, OS authentication won’t work and, as discussed earlier, if you’re trying to start up an instance to mount and open a database, then there by definition is “no database” at the other end of the connection yet, in which to look up authentication details. It is the proverbial chicken and egg problem. Enter the password file. The password file stores a list of usernames and passwords that are allowed to remotely authenticate as SYSDBA over the network. Oracle must use this file to authenticate them and not the normal list of passwords stored in the database. So, let’s correct our situation. First, we’ll start up the database locally so we can set the REMOTE_LOGIN_PASSWORDFILE. Its default value is NONE, meaning there is no password file; there
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
- Page 97 and 98: 52 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 99 and 100: 54 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 101 and 102: 56 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 103 and 104: 58 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 105 and 106: 60 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 107 and 108: 62 CHAPTER 2 ■ ARCHITECTURE OVERV
- Page 110 and 111: CHAPTER 3 ■ ■ ■ Files In this
- Page 112 and 113: CHAPTER 3 ■ FILES 67 Without a pa
- Page 114 and 115: CHAPTER 3 ■ FILES 69 and even dat
- Page 116 and 117: CHAPTER 3 ■ FILES 71 all operatio
- Page 118 and 119: CHAPTER 3 ■ FILES 73 *.cluster_da
- Page 120 and 121: CHAPTER 3 ■ FILES 75 ops$tkyte@OR
- Page 122 and 123: CHAPTER 3 ■ FILES 77 • To maint
- Page 124 and 125: CHAPTER 3 ■ FILES 79 • Resource
- Page 126 and 127: CHAPTER 3 ■ FILES 81 3 l_dummy nu
- Page 128 and 129: CHAPTER 3 ■ FILES 83 Trace Files
- Page 130 and 131: CHAPTER 3 ■ FILES 85 _qerixAlloca
- Page 132 and 133: CHAPTER 3 ■ FILES 87 6 ( 7 TYPE O
- Page 134 and 135: CHAPTER 3 ■ FILES 89 A Brief Revi
- Page 136 and 137: CHAPTER 3 ■ FILES 91 Redundant Ar
- Page 138 and 139: CHAPTER 3 ■ FILES 93 (data from m
- Page 140 and 141: CHAPTER 3 ■ FILES 95 dictionary t
- Page 142 and 143: CHAPTER 3 ■ FILES 97 ■Note df i
- Page 144 and 145: CHAPTER 3 ■ FILES 99 “accidenta
- Page 146 and 147: CHAPTER 3 ■ FILES 101 So, at the
- Page 150 and 151: CHAPTER 3 ■ FILES 105 USER is "SY
- Page 152 and 153: CHAPTER 3 ■ FILES 107 Flashback L
- Page 154 and 155: CHAPTER 3 ■ FILES 109 of the requ
- Page 156 and 157: CHAPTER 3 ■ FILES 111 IMPDP, howe
- Page 158 and 159: CHAPTER 3 ■ FILES 113 tkyte@ORA10
- Page 160 and 161: CHAPTER 4 ■ ■ ■ Memory Struct
- Page 162 and 163: CHAPTER 4 ■ MEMORY STRUCTURES 117
- Page 164 and 165: CHAPTER 4 ■ MEMORY STRUCTURES 119
- Page 166 and 167: CHAPTER 4 ■ MEMORY STRUCTURES 121
- Page 168 and 169: CHAPTER 4 ■ MEMORY STRUCTURES 123
- Page 170 and 171: CHAPTER 4 ■ MEMORY STRUCTURES 125
- Page 172 and 173: CHAPTER 4 ■ MEMORY STRUCTURES 127
- Page 174 and 175: CHAPTER 4 ■ MEMORY STRUCTURES 129
- Page 176 and 177: CHAPTER 4 ■ MEMORY STRUCTURES 131
- Page 178 and 179: CHAPTER 4 ■ MEMORY STRUCTURES 133
- Page 180 and 181: CHAPTER 4 ■ MEMORY STRUCTURES 135
- Page 182 and 183: CHAPTER 4 ■ MEMORY STRUCTURES 137
- Page 184 and 185: CHAPTER 4 ■ MEMORY STRUCTURES 139
- Page 186 and 187: CHAPTER 4 ■ MEMORY STRUCTURES 141
- Page 188 and 189: CHAPTER 4 ■ MEMORY STRUCTURES 143
- Page 190 and 191: CHAPTER 4 ■ MEMORY STRUCTURES 145
- Page 192 and 193: CHAPTER 4 ■ MEMORY STRUCTURES 147
- Page 194 and 195: CHAPTER 4 ■ MEMORY STRUCTURES 149
- Page 196 and 197: CHAPTER 4 ■ MEMORY STRUCTURES 151
CHAPTER 3 ■ FILES 103<br />
Password Files<br />
The password file is an optional file that permits remote SYSDBA or administrator access to the<br />
database.<br />
When you attempt to start up <strong>Oracle</strong>, there is no database available that can be consulted<br />
to verify passwords. When you start up <strong>Oracle</strong> on the “local” system (i.e., not over the network,<br />
but from the machine the database instance will reside on), <strong>Oracle</strong> will use the OS to perform<br />
the authentication.<br />
When <strong>Oracle</strong> was installed, the person performing the installation was asked to specify<br />
the “group” for the administrators. Normally on UNIX/Linux, this group will be DBA by default<br />
<strong>and</strong> OSDBA on Windows. It can be any legitimate group name on that platform, however. That<br />
group is “special,” in that any user in that group can connect to <strong>Oracle</strong> “as SYSDBA” without<br />
specifying a username or password. For example, in my <strong>Oracle</strong> 10g Release 1 install, I specified<br />
an ora10g group. Anyone in the ora10g group may connect without a username/password:<br />
[ora10g@localhost ora10g]$ sqlplus / as sysdba<br />
SQL*Plus: Release 10.1.0.3.0 - Production on Sun Jan 2 20:13:04 2005<br />
Copyright (c) 1982, 2004, <strong>Oracle</strong>. All rights reserved.<br />
Connected to:<br />
<strong>Oracle</strong> <strong>Database</strong> 10g Enterprise Edition Release 10.1.0.3.0 - Production<br />
With the Partitioning, OLAP <strong>and</strong> Data Mining options<br />
SQL> show user<br />
USER is "SYS"<br />
That worked—I’m connected, <strong>and</strong> I could now start up this database, shut it down, or<br />
perform whatever administration I wanted to. However, suppose I wanted to perform these<br />
operations from another machine, over the network. In that case, I would attempt to connect<br />
using @tns-connect-string. However, this would fail:<br />
[ora10g@localhost admin]$ sqlplus /@ora10g_admin.localdomain as sysdba<br />
SQL*Plus: Release 10.1.0.3.0 - Production on Sun Jan 2 20:14:20 2005<br />
Copyright (c) 1982, 2004, <strong>Oracle</strong>. All rights reserved.<br />
ERROR:<br />
ORA-01031: insufficient privileges<br />
Enter user-name:<br />
OS authentication won’t work over the network for SYSDBA, even if the very unsafe (for<br />
security reasons) parameter REMOTE_OS_AUTHENT is set to TRUE. So, OS authentication won’t<br />
work <strong>and</strong>, as discussed earlier, if you’re trying to start up an instance to mount <strong>and</strong> open a<br />
database, then there by definition is “no database” at the other end of the connection yet, in<br />
which to look up authentication details. It is the proverbial chicken <strong>and</strong> egg problem. Enter<br />
the password file. The password file stores a list of usernames <strong>and</strong> passwords that are allowed<br />
to remotely authenticate as SYSDBA over the network. <strong>Oracle</strong> must use this file to authenticate<br />
them <strong>and</strong> not the normal list of passwords stored in the database.<br />
So, let’s correct our situation. First, we’ll start up the database locally so we can set the<br />
REMOTE_LOGIN_PASSWORDFILE. Its default value is NONE, meaning there is no password file; there