OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P26 pptx

The first command queries DBA_USERS and determines the default and temporary tablespaces for the user JOHN, created in Figure 6-1.. To change a user’s temporary tablespace which will aff

In the first example in the figure, a username JOHN is created This was entered in lowercase, but is converted to uppercase, as can be seen in the first query The second example uses double quotes to create the user with a name in lowercase The third and fourth examples use double quotes to bypass the rules on characters and reserved words; both of these would fail without the double quotes If a username includes lowercase letters or illegal characters or is a reserved word, then double quotes must always be used to connect to the account subsequently

TIP It is possible to use nonstandard usernames, but this may cause dreadful

confusion Some applications rely on the case conversion; others always use double quotes It is good practice to always use uppercase and only the standard characters

A username can never be changed after creation If it is necessary to change it, the account must be dropped and another account created This is a drastic action, because all the objects in the user’s schema will be dropped along with the user

Default Tablespace and Quotas

Every user account has a default tablespace This is the tablespace where any schema

objects (such as tables or indexes) created by the user will reside It is possible for a user to create (own) objects in any tablespace on which they have been granted a quota, but unless another tablespace is specified when creating the object, it will go into the user’s default tablespace

There is a database-wide default tablespace that will be applied to all user accounts

if a default tablespace is not specified when creating the user The default can be set when creating the database and changed later with:

ALTER DATABASE DEFAULT TABLESPACE tablespace_name ;

If a default tablespace is not specified when creating the database, it will be set to the SYSTEM tablespace

TIP After creating a database, do not leave the default tablespace as SYSTEM;

this is very bad practice as nonsystem users could potentially fill up this tablespace, thus hampering the operation of the data dictionary and consequently the entire database Change it as soon as you can

A quota is the amount of space in a tablespace that the schema objects of a user are

allowed to occupy You can create objects and allocate extents to them until the quota

is reached If you have no quota on a tablespace, you cannot create any objects at all Quotas can be changed at any time by an administrator user with sufficient privileges

If a user’s quota is reduced to below the size of their existing objects (or even reduced

to zero), the objects will survive and will still be usable, but they will not be permitted

to get any bigger

Figure 6-2 shows how to investigate and set quotas

The first command queries DBA_USERS and determines the default and temporary

tablespaces for the user JOHN, created in Figure 6-1 DBA_USERS has one row for

every user account in the database User JOHN has picked up the database defaults

for the default and temporary tablespaces, which are shown in the last query against

DATABASE_PROPERTIES

The two ALTER USER commands in Figure 6-2 give user JOHN the capability to

use up to 10MB of space in the USERS tablespace, and an unlimited amount of space

in the EXAMPLE tablespace The query against DBA_TS_QUOTAS confirms this; the

number “–1” represents an unlimited quota At the time the query was run, JOHN

had not created any objects, so the figures for BYTES are zeros, indicating that he is

not currently using any space in either tablespace

EXAM TIP Before you can create a table, you must have both permission to

execute CREATE TABLE and quota on a tablespace in which to create it

TIP Most users will not need any quotas, because they will never create

objects They will only have permissions against objects owned by other

schemas The few object-owning schemas will probably have QUOTA

UNLIMITED on the tablespaces where their objects reside

Temporary Tablespace

Permanent objects (such as tables) are stored in permanent tablespaces; temporary

objects are stored in temporary tablespaces A session will need space in a temporary

tablespace if it needs space for certain operations that exceed the space available in

the session’s PGA Remember that the PGA is the program global area, the private

memory allocated to the session Operations that need temporary space (in memory

Figure 6-2

Managing user

quotas

if possible, in a temporary tablespace if necessary) include sorting rows, joining tables, building indexes, and using temporary tables Every user account is assigned a

temporary tablespace, and all user sessions connecting to the account will share this temporary tablespace

The query against DBA_USERS in Figure 6-2 shows user JOHN’s temporary tablespace, which is the database default temporary tablespace This is shown by the last query in Figure 6-2, against DATABASE_PROPERTIES

Space management within a temporary tablespace is completely automatic Temporary objects are created and dropped as necessary by the database A user does not need to be granted a quota on their temporary tablespace This is because the objects in it are not actually owned by them; they are owned by the SYS user, who has an unlimited quota on all tablespaces

EXAM TIP Users do not need a quota on their temporary tablespace.

To change a user’s temporary tablespace (which will affect all future sessions that connect to that account), use an ALTER USER command:

ALTER USER username TEMPORARY TABLESPACE tablespace_name;

TIP If many users are logging on to the same user account, they will share the

use of one temporary tablespace This can be a performance bottleneck, which may be avoided by using temporary tablespace groups

Profile

A user’s profile controls their password settings and provides a limited amount of control over resource usage Use of profiles is detailed in the later section “Create and Manage Profiles.”

Profiles are a useful way of managing passwords and resources but can really only apply in an environment where every application user has their own database user account For example, if many users connect to the same database user account, you would not want the password to be invalidated by one of them, because that would lock out everyone else Similarly, resource usage will often need to be managed on a per-session basis rather than for the account as a whole

Account Status

Every user account has a certain status, as listed in the ACCOUNT_STATUS column of DBA_USERS There are nine possibilities:

• OPEN The account is available for use.

• LOCKED This indicates that the DBA deliberately locked the account No

user can connect to a locked account

• EXPIRED This indicates that the password lifetime has expired Passwords

can have a limited lifetime No user can connect to an EXPIRED account until

the password is reset

• EXPIRED & LOCKED Not only has the account been locked, but its

password has also expired

• EXPIRED (GRACE) This indicates that the grace period is in effect A

password need not expire immediately when its lifetime ends; it may be

configured with a grace period during which users connecting to the account

have the opportunity to change the password

• LOCKED (TIMED) This indicates that the account is locked because of failed

login attempts An account can be configured to lock automatically for a

period after an incorrect password is presented a certain number of times

• EXPIRED & LOCKED (TIMED)

• EXPIRED (GRACE) & LOCKED

• EXPIRED (GRACE) & LOCKED (TIMED)

To lock and unlock an account, use these commands:

ALTER USER username ACCOUNT LOCK ;

ALTER USER username ACCOUNT UNLOCK ;

To force a user to change their password, use this command:

ALTER USER username PASSWORD EXPIRE;

This will immediately start the grace period, forcing the user to make a password

change at their next login attempt (or one soon after) There is no such command as

“alter unexpire.” The only way to make the account fully functional again is to

reset the password

Authentication Methods

A user account must have an authentication method: some means whereby the

database can determine if the user attempting to create a session connecting to the

account is allowed to do so The simplest technique is by presenting a password that

will be matched against a password stored within the database, but there are

alternatives The possibilities are

• Operating system authentication

• Password file authentication

• Password authentication

• External authentication

• Global authentication

The first two techniques are used only for administrators; the last requires an LDAP directory server The LDAP directory server may be the Oracle Internet Directory, shipped as a part of the Oracle Application Server

Operating System and Password File Authentication

To enable operating system and password file authentication (the two go together) for

an account, you must grant the user either the SYSDBA or the SYSOPER privilege:

GRANT [sysdba | sysoper ] TO username ;

Granting either (or both) of these privileges will copy the user’s password from the data dictionary into the external password file, where it can be read by the instance even if the database is not open It also allows the instance to authenticate users by checking whether the operating system user attempting the connection is a member

of the operating system group that owns the Oracle Home installation Following database creation, the only user with these privileges is SYS

To use password file authentication, the user can connect with this syntax using SQL*Plus:

CONNECT username / password [@db_alias] AS [ SYSOPER | SYSDBA ] ;

Note that password file authentication can be used for a connection to a remote database over Oracle Net

To use operating system authentication, the user must be first logged on to the database server after being authenticated as an operating system user with access to the Oracle binaries before connecting with this syntax using SQL*Plus:

CONNECT / AS [ SYSOPER | SYSDBA ] ;

The operating system password is not stored by Oracle, and therefore there are no issues with changing passwords

The equivalent of these syntaxes is also available when connecting with Database Control, by selecting SYSDBA from the Connect As drop-down box on the Database Control login window To determine to whom the SYSDBA and SYSOPER privileges have been granted, query the view V$PWFILE_USERS Connection with operating system or password file authentication is always possible, no matter what state the instance and database are in, and is necessary to issue STARTUP or SHUTDOWN commands

A third privilege that operates in the same manner as SYSDBA and SYSOPER is SYSASM This is a privilege that is only applicable to ASM instances and is detailed

in Chapter 20

TIP All user sessions must be authenticated There is no such thing as an

“anonymous” login, and some authentication method must be used

Password Authentication

The syntax for a connection with password authentication using SQL*Plus is

CONNECT username / password [@db_alias] ;

Or with Database Control, select NORMAL from the Connect As drop-down box

When connecting with password authentication, the instance will validate the

password given against that stored with the user account in the data dictionary For

this to work, the database must be open; it is therefore logically impossible to issue

STARTUP or SHUTDOWN commands when connected with password authentication

The user SYS is not permitted to connect with password authentication; only password

file, operating system, or LDAP authentication is possible for SYS

Usernames are case sensitive but are automatically converted to uppercase unless

specified within double quotes In previous releases of the database, passwords were

not case sensitive at all With release 11g, passwords are case sensitive and there is no

automatic case conversion It is not necessary to use double quotes; the password will

always be read exactly as entered

When a connection is made across a network, release 11g will always encrypt it

using the AES algorithm before transmission To use encryption for the ongoing traffic

between the user process and the server process requires the Advanced Security Option,

but password encryption is standard

Any user can change their user account password at any time, or a highly privileged

user (such as SYSTEM) can change any user account password The syntax (whether

you are changing your own password or another one) is

ALTER USER username IDENTIFIED BY password ;

External Authentication

If a user account is created with external authentication, Oracle will delegate the

authentication to an external service; it will not prompt for a password If the Advanced

Security Option has been licensed, then the external service can be a Kerberos server, a

RADIUS server, or (in the Windows environment) the Windows native authentication

service When a user attempts to connect to the user account, rather than authenticating

the user itself, the database instance will accept (or reject) the authentication according

to whether the external authentication service has authenticated the user For example,

if using Kerberos, the database will check that the user does have a valid Kerberos token

Without the Advanced Security Option, the only form of external authentication

that can be used is operating system authentication This is a requirement for SYSDBA

and SYSOPER accounts (as already discussed) but can also be used for normal users

The technique is to create an Oracle user account with the same name as the operating

system user account but prefixed with a string specified by the instance parameter OS_

AUTHENT_PREFIX This parameter defaults to the string OPS$ To check its value, use

a query such as

On Linux or Unix, external operating system authentication is very simple

Assuming that the OS_AUTHENT_PREFIX is on default and that there is an operating system user called jwatson, then create an oracle user and grant the CREATE SESSION privilege as follows:

create user ops$jwatson identified externally;

grant create session to ops$jwatson;

A user logged on to Unix as jwatson will be able to issue the command:

sqlplus /

from an operating system prompt, and will be connected to the database user account ops$jwatson

Under Windows, when Oracle queries the operating system to identify the user, Windows will usually (depending on details of Windows security configuration) return the username prefixed with the Windows domain Assuming that the Windows logon

ID is John Watson (including a space) and that the Windows domain is JWACER (which happens to be the machine name) and that the OS_AUTHENT_PREFIX is on default, the command will be

create user "OPS$JWACER\JOHN WATSON" identified externally;

Note that the username must be in uppercase, and because of the illegal characters (a backslash and a space) must be enclosed in double quotes

TIP Using external authentication can be very useful, but only if the users

actually log on to the machine hosting the database Users will rarely do this,

so the technique is more likely to be of value for accounts used for running maintenance or batch jobs

Global Authentication

An emerging standard for identity management makes use of LDAP servers An LDAP-compliant directory server, the Oracle Internet Directory, is distributed by Oracle

Corporation as part of Oracle Application Server A global user is a user who is defined within the LDAP directory, and global authentication is a means of delegating user

authentication to the directory

There are two techniques for global authentication:

• The users can be defined in the directory, and also in the database A user will be connected to a user account with the same name as the user’s common name

in the directory

• The users can be defined only in the directory The database will be aware

of the users’ global names but connects all users to the same database user account

Neither of these techniques requires the user to present a password to the database The connection will happen without any prompts if the directory accounts and the database user accounts are set up correctly

Creating Accounts

The CREATE USER command has only two mandatory arguments: a username and

a method of authentication Optionally, it can accept a clause to specify a default

tablespace and a temporary tablespace, one or more quota clauses, a named profile,

and commands to lock the account and expire the password A typical example (with

line numbers added) would be

1 create user scott identified by tiger

2 default tablespace users temporary tablespace temp

3 quota 100m on users, quota unlimited on example

4 profile developer_profile

5 password expire

6 account unlock;

Only the first line is required; there are defaults for everything else Taking the

command line by line:

1 Provide the username, and a password for password authentication

2 Provide the default and temporary tablespaces

3 Set up quotas on the default and another tablespace

4 Nominate a profile for password and resource management

5 Force the user to change his password immediately

6 Make the account available for use (which would have been the default)

Every attribute of an account can be adjusted later with ALTER USER commands,

with the exception of the name To change the password:

alter user scott identified by lion;

To change the default and temporary tablespaces:

alter user scott default tablespace store_data temporary tablespace temp;

To change quotas:

alter user scott quota unlimited on store_data, quota 0 on users;

To change the profile:

alter user scott profile prod_profile;

To force a password change:

alter user scott password expire;

To lock the account:

alter user scott account lock;

Having created a user account, it may be necessary to drop it:

This command will only succeed if the user does not own any objects: if the schema

is empty If you do not want to identify all the objects owned and drop them first, they can be dropped with the user by specifying CASCADE:

drop user scott cascade;

To manage accounts with Database Control, from the database home page take the Schema tab and then the Users link in the Security section This will show all the user accounts in the database Figure 6-3 shows these, sorted in reverse order of creation

To change the sort order, click the appropriate column header

The first “user” in the figure is PUBLIC This is a notional user to whom privileges can be granted if you wish to grant them to every user The CREATE button will present a window that prompts for all the user account attributes The DELETE button will drop

an account, with the CASCADE option if necessary—but it will give an “Are you sure?” prompt before proceeding

To adjust the attributes of an account, select it and click EDIT This will take you to the Edit User window, shown in Figure 6-4 This interface can be used to change all

Figure 6-3 Users shown by Database Control

aspects of the account except for tablespace quotas, which have their own tabs It also

has tabs for granting and revoking privileges and roles

Exercise 6-1: Create Users In this exercise, you will create some users to be

used for the remaining exercises in this chapter It is assumed that there is a permanent

tablespace called STOREDATA and a temporary tablespace called TEMP If these don’t

exist, either create them or use any other suitable tablespaces

1 Connect to your database with SQL*Plus as a highly privileged user, such as

SYSTEM or SYS

2 Create three users:

create user sales identified by sales

default tablespace storedata password expire;

create user webapp identified by oracle

default tablespace storedata quota unlimited on storedata;

create user accounts identified by oracle;

Figure 6-4 The Edit User Database Control window