About User Accounts For users to access your database, you must create user accounts and grant

appropriate database access privileges to those accounts. A user account is identified by a user name and defines the attributes of the user, including the following: Authentication method Password (encrypted) for database authentication Default tablespaces for permanent and temporary data storage Tablespace quotas Account status (locked or unlocked) Password status (expired or not)

When you create a user account, you must not only assign a user name, a password, and default tablespaces for the account, but you must also do the following:

Grant the appropriate system privileges, object privileges, and roles to the account. If the user will be creating database objects, give the user account a space usage quota on each tablespace in which the objects will be created.

Oracle recommends that you grant each user just enough privileges to perform his job,and no more. For example, a database application developer needs privileges to create and modify tables, indexes, views, and stored procedures, but does not need (and should not be granted) privileges to drop (delete) tablespaces or recover the database.

Predefined User Accounts In addition to the user accounts that you create, the database includes a number of user accounts that are automatically created upon installation. All databases include the administrative accounts SYS, SYSTEM, SYSMAN, and DBSNMP. Administrative accounts are highly privileged accounts, and should be used only by individuals authorized to perform administrative tasks such as starting and stopping the database, managing database memory and storage, creating and managing database users, and so on. You log in to Oracle Enterprise Manager Database Control (Database Control) with SYS, SYSTEM, or SYSMAN. The Management Agent of Database Control uses the DBSNMP account to monitor and manage the database. You assign the passwords for these accounts when you create the database with Oracle Database Configuration Assistant (DBCA). You must not delete these accounts. All databases also include internal accounts which are automatically created so that individual Oracle Database features or components can have their own schemas. An example is the WKSYS account, which is used by Oracle Ultra Search. All Oracle Ultra Search database objects are installed in the WKSYS schema. To protect these accounts from unauthorized access, they are initially locked and their passwords are expired. (A locked account is an account for which login is disabled.) You must not delete internal accounts, and you must not use them to log in to the database.

Your database may also include sample schemas,which provide a way for you to experiment without endangering production data. Each sample schema has a user account associated with it. For example, the hr user account owns the hr schema, which contains a set of simple tables for a human resources application. The sample schema accounts are also initially locked and have an expired password. As the database administrator, you are responsible for unlocking these accounts and assigning passwords to these accounts.

About Administrative Accounts and Privileges Administrative accounts and privileges enable you to perform administrative functions such as managing users, managing database memory, and starting up and shutting down the database

SYS and SYSTEM Users

The following administrative user accounts are automatically created when you install Oracle Database. They are both created with the password that you supplied upon installation, and they are both automatically granted the DBA role.

SYSTEM This account can perform all administrative functions except the following: Backup and recovery Database upgrade It is recommended that you log in with this account to perform day-today administrative tasks.

SYS This account can perform all administrative functions. All base (underlying) tables and views for the database data dictionary are stored in the SYS schema. These base tables and views are critical for the operation of Oracle Database. To maintain the integrity of the data dictionary, tables in the SYS schema are manipulated only by the database. They should never be modified by any user or database administrator. You must not create any tables in the SYS schema. The SYS user is granted the SYSDBA privilege, which enables a user to performhigh-level administrative tasks such as backup and recovery.

Creating a New User Account

You create a database user with the CREATE USER statement. To create a user, you must have the CREATE USER system privilege. Because it is a powerful privilege, a database administrator or security administrator is usually the only user who has the CREATE USER system privilege.

CREATE USER satya IDENTIFIED BY password DEFAULT TABLESPACE data_ts QUOTA 100M ON test_ts QUOTA 500K ON data_ts TEMPORARY TABLESPACE temp_ts PROFILE clerk;

GRANT CREATE SESSION TO satya;

A newly created user cannot connect to the database until you grant the user the CREATE SESSION system privileges. So, immediately after you create the user account, use the GRANT SQL statement to grant the user these privileges. If the user must access Oracle Enterprise Manager, you should also grant the user the SELECT ANY DICTIONARY privilege.

Specifying a User Name

Within each database, a user name must be unique with respect to other user names and roles. A user and role cannot have the same name. Furthermore, each user has an associated schema. Within a schema, each schema object must have a unique name. In the following , the text in bold shows how to create the user name.

CREATE USER satya IDENTIFIED BY password DEFAULT TABLESPACE data_ts QUOTA 100M ON test_ts QUOTA 500K ON data_ts TEMPORARY TABLESPACE temp_ts PROFILE clerk;

Assigning the User a Password

The connecting user must supply the correct password to the database to connect successfully. To specify a password for the user, use the IDENTIFIED BY clause in the CREATE USER statement.

CREATE USER satya IDENTIFIED BY password DEFAULT TABLESPACE data_ts QUOTA 100M ON test_ts QUOTA 500K ON data_ts TEMPORARY TABLESPACE temp_ts PROFILE clerk;

Assigning a Default Tablespace for the User

Each user should have a default tablespace. When a schema object is created in the users schema and the DDL statement does not specify a tablespace to contain the object, Oracle Database stores the object in the default users tablespace.

The default setting for the default tablespaces of all users is the SYSTEM tablespace. If a user does not create objects, and has no privileges to do so, then this default setting is fine. However, if a user is likely to create any type of object, then you should specifically assign the user a default tablespace, such as the USERS tablespace. Using a tablespace other

than SYSTEM reduces contention between data dictionary objects and user objects for the same data files. In general, do not store user data in the SYSTEM tablespace.

You can use the CREATE TABLESPACE SQL statement to create a permanent default tablespace other than SYSTEM to be used as the database default for permanent objects. By separating the user data from the system data, you reduce the likelihood of problems with the SYSTEM tablespace, which can in some circumstances cause the entire database to become nonfunctional. This default permanent tablespace is not used by system users, that is, SYS, SYSTEM whose default permanent tablespace is SYSTEM. A tablespace designated as the default permanent tablespace cannot be dropped. To accomplish this goal, you must first designate another tablespace as the default permanent tablespace. You can use the ALTER TABLESPACE SQL statement to alter the default permanent tablespace to another tablespace. Be aware that this will affect all users or objects created after the ALTER DDL statement commits.

You can also set a user default tablespace during user creation, and change it later with the ALTER USER statement. Changing the user default tablespace affects only objects created after the setting is changed. When you specify the default tablespace for a user, also specify a quota on that tablespace.

In the following CREATE USER statement, the default tablespace for user satya is data_ts, and his quota on that tablespace is 500K:

CREATE USER jward IDENTIFIED BY password DEFAULT TABLESPACE data_ts QUOTA 100M ON test_ts QUOTA 500K ON data_ts TEMPORARY TABLESPACE temp_ts PROFILE clerk;

TO CHANGE THE DEFAULT TABLESPACE OF A USER:

SQL>ALTER USER satya DEFAULT TABLESPACE USERS;

SQL>ALTER USER satya QUOTA 4m ON USERS;

Default Permanent Tablespace Oracle9i introduced the concept of a default temporary tablespace to prevent people accidentally using the SYSTEM tablespace for temporary segments. Oracle 10g takes this further by including a default permanent tablespace to prevent users having their default tablespace set to SYSTEM. The DEFAULT TABLESPACE clause in the CREATE DATABASE statement allows the the default tablespace to be created and named. If this parameter is not set during creation, or needs to be changed subsequently, it can be set using the following command. ALTER DATABASE DEFAULT TABLESPACE users; The current settings for the default tablespaces can be viewed using the following query.

COLUMN property_name FORMAT A30 COLUMN property_value FORMAT A30 COLUMN description FORMAT A50 SET LINESIZE 200 SELECT * FROM database_properties WHERE property_name like '%TABLESPACE';

PROPERTY_NAME PROPERTY_VALUE DESCRIPTION ------------------------------ ------------------------------------------------------------------DEFAULT_TEMP_TABLESPACE TEMP default temporary tablespace DEFAULT_PERMANENT_TABLESPACE USERS of default permanent tablespace

Name of Name

Assigning a Tablespace Quota for the User

You can assign each user a tablespace quota for any tablespace (except a temporary tablespace). Assigning a quota accomplishes the following: Users with privileges to create certain types of objects can create those objects in the specified tablespace. Oracle Database limits the amount of space that can be allocated for storage of a user's objects within the specified tablespace to the amount of the quota. By default, a user has no quota on any tablespace in the database. If the user has the privilege to create a schema object, then you must assign a quota to allow the user to create objects. At a minimum, assign users a quota for the default tablespace, and additional quotas for other tablespaces in which they can create objects.

The following CREATE USER statement assigns the following quotas for the test_ts and data_ts tablespaces:

CREATE USER satya IDENTIFIED BY password DEFAULT TABLESPACE data_ts QUOTA 100M ON test_ts QUOTA 500K ON data_ts TEMPORARY TABLESPACE temp_ts PROFILE clerk;

You can assign a user either individual quotas for a specific amount of disk space in each tablespace or an unlimited amount of disk space in all tablespaces. Specific quotas prevent a user's objects from using too much space in the database. You can assign quotas to a user tablespace when you create the user, or add or change quotas later. (You can find existing user quotas by querying the USER_TS_QUOTAS view.) If a new quota is less than the old one, then the following conditions remain true:

If a user has already exceeded a new tablespace quota, then the objects of a user in the tablespace cannot be allocated more space until the combined space of these objects is less than the new quota. If a user has not exceeded a new tablespace quota, or if the space used by the objects of the user in the tablespace falls under a new tablespace quota, then the user's objects can be allocated space up to the new quota

Restricting the Quota Limits for User Objects in a Tablespace

You can restrict the quota limits for user objects in a tablespace by using the ALTER USER SQL statement to change the current quota of the user to zero. After a quota of zero is assigned, the objects of the user in the tablespace remain, and the user can still create new objects, but the existing objects will not be allocated any new space. For example, you

could not insert data into one of this users exiting tables. The operation will fail with an ORA-1536 space quota exceeded for tables error.

Granting Users the UNLIMITED TABLESPACE System Privilege To permit a user to use an unlimited amount of any tablespace in the database, grant the user the UNLIMITED TABLESPACE system privilege. This overrides all explicit tablespace quotas for the user. If you later revoke the privilege, then you must explicitly grant quotas to individual tablespaces. You can grant this privilege only to users, not to roles. Before granting the UNLIMITED TABLESPACE system privilege, you must consider the consequences of doing so. Advantage: You can grant a user unlimited access to all tablespaces of a database with one statement. Disadvantages: The privilege overrides all explicit tablespace quotas for the user. You cannot selectively revoke tablespace access from a user with the UNLIMITED TABLESPACE privilege. You can grant selective or restricted access only after revoking the privilege.

Assigning a Temporary Tablespace for the User You should assign each user a temporary tablespace. When a user executes a SQL statement that requires a temporary segment, Oracle Database stores the segment in

the temporary tablespace of the user. These temporary segments are created by the system when performing sort or join operations. Temporary segments are owned by SYS, which has resource privileges in all tablespaces. In the following, the temporary tablespace of satya is temp_ts, a tablespace created explicitly to contain only temporary segments.

CREATE USER satya IDENTIFIED BY password DEFAULT TABLESPACE data_ts QUOTA 100M ON test_ts QUOTA 500K ON data_ts TEMPORARY TABLESPACE temp_ts PROFILE clerk;

To create a temporary tablespace, use the CREATE TEMPORARY TABLESPACE SQL statement. If you do not explicitly assign the user a temporary tablespace, then Oracle Database assigns the user the default temporary tablespace that was specified at database creation, or by an ALTER DATABASE statement at a later time. If there is no default temporary tablespace explicitly assigned, then the default is the SYSTEM tablespace or another permanent default established by the system administrator. Do not store user data in the SYSTEM tablespace. Assigning a tablespace to be used specifically as a temporary tablespace eliminates file contention among temporary segments and other types of segments. You can set the temporary tablespace for a user at user creation, and change it later using the ALTER USER statement. If you are logged in as user SYS, you can set a quota for the temporary tablespace, and other space allocations. (Only user SYS can do this, because all space in the temporary tablespace belongs to user SYS.) You can also establish

tablespace groups instead of assigning individual temporary tablespaces.

TEMPFILEs are not recorded in the database's control file.

SQL> CREATE USER scott DEFAULT TABLESPACE data TEMPORARY TABLESPACE temp;

SQL> ALTER USER scott TEMPORARY TABLESPACE temp;

About User Privileges and Roles

A privilege is a right to execute an SQL statement or to access another user's object. User privileges provide a basic level of database security. They are designed to control user access to data and to limit the kinds of SQL statements that users can execute. When creating a user, you grant privileges to enable the user to connect to the database, to run queries and make updates, to create schema objects, and more.

Privileges can be granted to both users and roles.

There are two main types of user privileges:

System privilegesA system privilege gives a user the ability to perform a particular action, or to perform an action on any schema objects of a particular type. For example, the system privilege CREATE TABLE permits a user to create tables in the schema associated with

that user, and the system privilege CREATE USER permits a user to create database users.

Object privilegesAn object privilege gives a user the ability to perform a particular action on a specific schema object. Different object privileges are available for different types of schema objects. The privilege to select rows from the EMPLOYEES table or to delete rows from the DEPARTMENTS table are examples of object privileges.

A privileges can be assigned to a user or a role

The set of privileges is fixed, that is, there is no SQL statement like create privilege xyz...

1)System privileges There are quite a few system privileges: in Oracle 9.2, we count 157 of them, and 10g has even 173. Those can be displayed with

SQL>select name from system_privilege_map;

Few Examples of system privileges are create table, create tablespace, create user, delete any table, drop any table, drop any role, drop tablespace,drop user, grant any object privilege, grant any privilege, grant any role, select any table, update any table The most important system privileges are:

create session (A user cannot login without this privilege. If he tries, he gets an ORA-01045).

create table create view create procedure sysdba sysoper

2) Object privileges Privileges can be assigned to the following types of database objects:

Tables select, insert, update, delete, alter, debug, flashback, on commit refresh, query rewrite, references, all Views select, insert, update, delete, under, references, flashback, debug Sequence alter, select Packages, Procedures, Functions (Java classes, sources...) execute, debug Materialized Views delete, flashback, insert, select, update Directories read, write Libraries execute User defined types execute, debug, under Operators execute Index types execute

For a user to be able to access an object in another user's schema, he needs the according object privilege.

Object Privileges are

ALTER DELETE

Change the table definition with the ALTER TABLE statement. Remove rows from the table with the DELETE statement. Note: You must grant the SELECT privilege on the table along with the DELETE privilege. Create an index on the table with the CREATE INDEX statement. Add new rows to the table with the INSERT statement.

INDEX INSERT

REFERENCE Create a constraint that refers to the table. You cannot grant S this privilege to a role. SELECT UPDATE Query the table with the SELECT statement. Change data in the table with the UPDATE statement. Note: You must grant the SELECT privilege on the table along with the UPDATE privilege.

Grant Grant is use to grant privileges on tables, view, procedure to other users or roles

Examples

Suppose you own emp table. Now you want to grant select,update,insert privilege on this table to other user SAMI. grant select, update, insert on emp to sami; Suppose you want to grant all privileges on emp table to sami. Then

grant all on emp to sami;

Suppose you want to grant select privilege on emp to all other users of the database. Then

grant select on emp to public; Suppose you want to grant update and insert privilege on only certain columns not on all the columns then include the column names in grant statement. For example you want to grant update privilege on ename column only and insert privilege on empno and ename columns only. Then give the following statement

grant update (ename),insert (empno, ename) on emp to sami;

To grant select statement on emp table to sami and to make sami be able further pass on this privilege you have to give WITH GRANT OPTION clause in GRANT statement like this.

grant select on emp to sami with grant option;

REVOKE Use to revoke privileges already granted to other users.

For example to revoke select, update, insert privilege you have granted to Sami then give the following statement.

revoke select, update, insert on emp from sami;

To revoke select statement on emp granted to public give the following command.

revoke select on emp from public; To revoke update privilege on ename column and insert privilege on empno and ename columns give the following revoke statement.

revoke update, insert on emp from sami; Note :You cannot take back column level privileges. Suppose you just want to take back insert privilege on ename column then you have to first take back the whole insert privilege and then grant privilege on empno column.

LISTING INFORMATION ABOUT PRIVILEGES To see which table privileges are granted by you to other users. SELECT * FROM USER_TAB_PRIVS_MADE To see which table privileges are granted to you by other users SELECT * FROM USER_TAB_PRIVS_RECD; To see which column level privileges are granted by you to other users. SELECT * FROM USER_COL_PRIVS_MADE To see which column level privileges are granted to you by other users SELECT * FROM USER_COL_PRIVS_RECD; To see which privileges are granted to roles

SELECT * FROM USER_ROLE_PRIVS; ROLES: Managing privileges is made easier by using roles, which are named groups of related privileges. You create roles, grant system and object privileges to the roles, and then grant roles to users. You can also grant roles to other roles. Unlike schema objects, roles are not contained in any schema. A role is a group of Privileges. A role is very handy in managing privileges, Particularly in such situation when number of users should have the same set of privileges. . A role can be granted system or schema object privileges. A role can be granted to other roles (an indirect grant.) However, a role cannot be granted to itself and cannot be granted circularly. For example, role A cannot be granted to role B if role B has previously been granted to role A.

Table 71 lists three widely used roles that are predefined in Oracle Database. You can grant these roles when you create a user or at any time thereafter.

Table 71 Oracle Database Predefined Roles

CONNECT Enables a user to connect to the database. Grant this role to any user or application that needs database access. RESOURCE Enables a user to create, modify, and delete certain types of schema objects in the schema associated with that user. Grant this role only to developers and to other users that must create schema objects. This role grants a subset of the create object system privileges. For example,

it grants the CREATE TABLE system privilege, but does not grant the CREATE VIEW system privilege. It grants only the following privileges: CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE.

In addition, this role grants the UNLIMITED TABLESPACE system privilege, which effectively assigns a space usage quota of UNLIMITED on all tablespaces in which the user creates schema objects.

DBA Enables a user to perform most administrative functions, including creating users and granting privileges; creating and granting roles; creating, modifying, and deleting schema objects in any schema; and more. It grants all system privileges, but does not include the privileges to start up or shut down the database. This Role is by default granted to users SYS and SYSTEM.

Examples : For example you have four users :Sami, Scott, Ashi, Tanya in the database. To these users you want to grant select ,update privilege on emp table, select,delete privilege on dept table. To do this first create a role by giving the following statement create role clerks Then grant privileges to this role. grant select,update on emp to clerks; grant select,delete on dept to clerks; Now grant this clerks role to users like this

Syntax : GRANT role TO [user,] [role,] grant clerks to sami, scott, ashi, tanya ; Now Sami, Scott, Ashi and Tanya have all the privileges granted on clerks role. Suppose after one month you want grant delete on privilege on emp table all these users then just grant this privilege to clerks role and automatically all the users will have the privilege. grant delete on emp to clerks; If you want to take back update privilege on emp table from these users just take it back from clerks role. revoke update on emp from clerks; To Drop a role Drop role clerks;

To know the system privileges granted to a user or a role. desc dba_sys_privs;

SQL> select GRANTEE,PRIVILEGE from dba_sys_privs where GRANTEE='SYSTEM';

GRANTEE

PRIVILEGE

------------------------------ ---------------------------------------SYSTEM SYSTEM GLOBAL QUERY REWRITE CREATE MATERIALIZED VIEW

SYSTEM SYSTEM SYSTEM

CREATE TABLE UNLIMITED TABLESPACE SELECT ANY TABLE

SQL> select GRANTEE,PRIVILEGE from dba_sys_privs where GRANTEE='DBA';

GRANTEE

PRIVILEGE

------------------------------ ---------------------------------------DBA DBA DBA DBA DBA DROP ANY CUBE BUILD PROCESS CREATE CUBE ALTER ANY CUBE DIMENSION ALTER ANY MINING MODEL DROP ANY MINING MODEL

GRANTEE is the Name of the user to whom access was granted PRIVILEGE is the System privilege

To know the object privileges granted to a user or role, desc dba_tab_privs.

SQL> select GRANTEE,OWNER,TABLE_NAME,GRANTOR,PRIVILEGE from dba_tab_privs where GRANTEE='SYSTEM';

GRANTEE is the Name of the user to whom access was granted.

OWNER is the Owner of the object

TABLE_NAME is the Name of the object

GRANTOR is the Name of the user who performed the grant.

PRIVILEGE is the Privilege on the object

To know all the roles in the database query the dba_roles view.

Select * from dba_roles;

SYSDBA and SYSOPER System Privileges

SYSDBA and SYSOPER are administrative privileges required to perform high-level administrative operations such as creating, starting up, shutting down, backing up, or recovering the database. The SYSDBA system privilege is for fully empowered database administrators and the SYSOPER system privilege allows a user to perform basic operational tasks, but without the ability to look at user data. The SYSDBA and SYSOPER system privileges allow access to a database instance even when the database is not open. Control of these privileges is therefore completely outside of the database itself. This enables an administrator who is granted one of these privileges to connect to the database instance to start the database. You can also think of the SYSDBA and SYSOPER privileges as types of connections that enable you to perform certain database operations for

which privileges cannot be granted in any other way. For example, if you have the SYSDBA privilege, then you can connect to the database using AS SYSDBA. The SYS user is automatically granted the SYSDBA privilege upon installation. When you log in as user SYS, you must connect to the database as SYSDBA. Connecting as a SYSDBA user invokes the SYSDBA privilege. Oracle Enterprise Manager Database Control does not permit you to log in as user SYS without connecting as SYSDBA.

When you connect with SYSDBA or SYSOPER privileges, you connect with a default schema, not with the schema that is generally associated with your user name. For SYSDBA this schema is SYS; for SYSOPER the schema is PUBLIC. When you connect as user SYS, you have unlimited privileges on data dictionary tables. Be certain that you do not modify any data dictionary tables.

When you create a user account, you are also implicitly creating a schema for that user. A schema is a logical container for the database objects (such as tables, views, triggers, and so on) that the user creates. The schema name is the same as the user name, and can be used to unambiguously refer to objects owned by the user. For example, hr.employees refers to the table named employees in the hr schema. (The employees table is owned by hr.) The terms database object and schema object are used interchangeably.

Who Should Be Granted Privileges? You grant privileges to users so they can accomplish tasks required for their jobs. You should grant a privilege only to a user who requires that privilege to accomplish the necessary work. Excessive granting of unnecessary privileges can compromise security. For example, you never should grant SYSDBA or SYSOPER privilege to users who do not perform administrative tasks. A user can receive a privilege in two ways: You can grant privileges to users explicitly. For example, you can explicitly grant to user psmith the

privilege to insert records into the employees table. You also can grant privileges to a role (a named group of privileges), and then grant the role to one or more users. For example, you can grant the privileges to select, insert, update, and delete records from the employees table to the role named clerk, which in turn you can grant to users psmith and robert. Because roles allow for easier and better management of privileges, you should usually grant privileges to roles and not to specific users.

About ANY Privileges and the PUBLIC Role System privileges that use the ANY keyword enable you to set privileges for an entire category of objects in the database. For example, the CREATE ANY PROCEDURE system privilege permits a user to create a procedure anywhere in the database. The behavior of an object created by users with the ANY privilege is not restricted to the schema in which it was created. For example, if user JSMITH has the CREATE ANY PROCEDURE privilege and creates a procedure in the schema JONES, then the procedure will run as JONES. However, JONES may not be aware that the procedure JSMITH created is running as him (JONES). If JONES has DBA privileges, letting JSMITH run a procedure as JONES could pose a security violation. The PUBLIC role is a special role that every database user account automatically has when the account is created. By default, it has no privileges granted to it, but it does have numerous grants, mostly to Java objects. You cannot drop the PUBLIC role, and a manual grant or revoke of this role has no meaning, because the user account will always assume this role. Because all database user accounts assume the PUBLIC role, it does not appear in the DBA_ROLES and SESSION_ROLES data dictionary views. You can grant privileges to the PUBLIC role, but remember that this makes the privileges available to every user in the Oracle database. For this reason, be careful about granting privileges to the PUBLIC role, particularly powerful privileges such as the ANY privileges and system privileges. For example, if JSMITH has the CREATE PUBLIC SYNONYM privilege, he could redefine an interface that he knows everyone else uses, and then point to it with the PUBLIC SYNONYM that he created. Instead of accessing the correct interface, users would access the interface of JSMITH, which could possibly perform illegal activities such as stealing the login credentials of users. These types of privileges are very powerful and could pose a security

risk if given to the wrong person. Be careful about granting privileges using ANY or PUBLIC. As with all privileges, you should follow the principles of "least privilege" when granting these privileges to users. To protect the data dictionary (the contents of the SYS schema) against users who have one or more of the powerful ANY system privileges, set the O7_DICTIONARY_ ACCESSIBILITY initialization parameter to FALSE. You can set this parameter by using an ALTER SYSTEM statement.

to list all the users in the database query the dba_users view. this view also provides information about the default tablespace,temporary tablespace of that user,status of the account(whether its locked or open),date of account lock,when will the account expire etc.

How to grant all privileges in Oracle This is a short paper showing how to grant "all privileges" to a user in Oracle and more importantly what privileges are needed to do this. This was a posting I made to one of the newsgroups/mailing lists recently. This is for information only as it is useful to know BUT one important fact that should be highlighted here is that i cannot think of any circumstances or when ALL PRIVILEGES should be granted to anyone. It is simply unnecessary. Do the job correctly and find out the exact privileges needed for the job in hand and grant those. Granting all privileges is a security risk as it means the user having those privileges can do just about anything in your database. Remember use least privilege principle at all times and grant what is needed. Do not grant everything just to get the job done quickly. Here is the example code! Connected to: Personal Oracle9i Release 9.2.0.1.0 - Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.1.0 - Production SQL> SQL> sho user

USER is "SYSTEM" SQL> select * from system_privilege_map 2 where name like '%PRIV%'; PRIVILEGE NAME PROPERTY ---------- ---------------------------------------- ----------167 GRANT ANY PRIVILEGE 0 -244 GRANT ANY OBJECT PRIVILEGE

SQL> SQL> -- Create a new user with just create session (to log on) and grant SQL> -- any privilege to, well grant all privileges. SQL> create user emil identified by emil; User created. SQL> grant create session, grant any privilege to emil; Grant succeeded. SQL> -- because we want to test this privilege create a second user to SQL> -- test it with SQL> create user zulia identified by zulia; User created. SQL> -- connect as emil and grant all privileges to Zulia SQL> connect emil/emil@sans Connected. SQL> grant all privileges to zulia; Grant succeeded. SQL> -- connect as system and find out if it worked. SQL> connect system/manager@sans Connected. SQL> select count(*),grantee 2 from dba_sys_privs 3 where grantee in ('MDSYS','EMIL','ZULIA') 4* group by grantee SQL> /

COUNT(*) GRANTEE ---------- -----------------------------2 EMIL 139 MDSYS 139 ZULIA SQL> We used MDSYS as a checkpoint as MDSYS has all privileges granted to it by default in a default installation of Oracle. The privilege you need therefore is GRANT ANY PRIVILEGE.

Setting a Default Role for the User A role is a named group of related privileges that you grant as a group to users or other roles. A default role is automatically enabled for a user when the user creates a session. You can assign a user zero or more default roles. You cannot set default roles for a user in the CREATE USER statement. When you first create a user, the default role setting for the user is ALL, which causes all roles Note: If your SYSTEM tablespace is locally managed, then users must be assigned a specific default (locally managed) temporary tablespace. They may not be allowed to default to using the SYSTEM tablespace because temporary objects cannot be placed in locally managed permanent tablespaces

What is profile? A profile is a set of limits on database resources and password access to the database

Specifying a Profile for the User

You can specify a profile when you create a user. If you do not specify a profile, then Oracle Database assigns the user a default profile.

The following example demonstrates how to assign a user a profile.

CREATE USER satya IDENTIFIED BY password DEFAULT TABLESPACE data_ts QUOTA 100M ON test_ts QUOTA 500K ON data_ts TEMPORARY TABLESPACE temp_ts PROFILE clerk; If you assign the profile to a user, then that user cannot exceed these limits. Prerequisites To create a profile, you must have the CREATE PROFILE system privilege. To specify resource limits for a user, you must:

Create a profile that defines the limits using the CREATE PROFILE statement Assign the profile to the user using the CREATE USER or ALTER USER statement Enable resource limits dynamically with the ALTER SYSTEM statement or with the initialization parameter RESOURCE_LIMIT. This parameter does not apply to password resources. Password resources are always enabled.

RESOURCE_LIMIT Property Parameter type Default value Modifiable Range of values Description Boolean false ALTER SYSTEM true | false

RESOURCE_LIMIT determines whether resource limits are enforced in database profiles. Values:

TRUE Enables the enforcement of resource limits FALSE Disables the enforcement of resource limits

profile Specify the name of the profile to be created. Use profiles to limit the database resources available to a user for a single call or a single session. Oracle Database enforces resource limits in the following ways:

If a user exceeds the CONNECT_TIME or IDLE_TIME session resource limit, then the database rolls back the current transaction and ends the session. When the user process next issues a call, the database returns an error. If a user attempts to perform an operation that exceeds the limit for other session resources, then the database aborts the operation, rolls back the current statement, and immediately returns an error. The user can then commit or roll back the current transaction, and must then end the session. If a user attempts to perform an operation that exceeds the limit for a single call, then the database aborts the operation, rolls back the current statement, and returns an error, leaving the current transaction intact.

UNLIMITED When specified with a resource parameter, UNLIMITED indicates that a user assigned this profile can use an unlimited amount of this resource. When specified with a password parameter, UNLIMITED indicates that no limit has been set for the parameter.

DEFAULT Specify DEFAULT if you want to omit a limit for this resource in this profile. A user assigned this profile is subject to the limit for this

resource specified in the DEFAULT profile. The DEFAULT profile initially defines unlimited resources. You can change those limits with the ALTER PROFILE statement. Any user who is not explicitly assigned a profile is subject to the limits defined in the DEFAULT profile. Also, if the profile that is explicitly assigned to a user omits limits for some resources or specifies DEFAULT for some limits, then the user is subject to the limits on those resources defined by the DEFAULT profile. resource_parameters SESSIONS_PER_USER Specify the number of concurrent sessions to which you want to limit the user.

CPU_PER_SESSION Specify the CPU time limit for a session, expressed in hundredth of seconds.

CPU_PER_CALL Specify the CPU time limit for a call (a parse, execute, or fetch), expressed in hundredths of seconds.

CONNECT_TIME Specify the total elapsed time limit for a session, expressed in minutes.

IDLE_TIME Specify the permitted periods of continuous inactive time during a session, expressed in minutes. Long-running queries and other operations are not subject to this limit.

PRIVATE_SGA

Specify the amount of private space a session can allocate in the shared pool of the system global area (SGA), expressed in bytes. Note: This limit applies only if you are using shared server architecture. The private space for a session in the SGA includes private SQL and PL/SQL areas, but not shared SQL and PL/SQL areas.

password_parameters Use the following clauses to set password parameters. Parameters that set lengths of time are interpreted in number of days. For testing purposes you can specify minutes (n/1440) or even seconds (n/86400).

FAILED_LOGIN_ATTEMPTS Specify the number of failed attempts to log in to the user account before the account is locked. CREATE PROFILE app_user2 LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LIFE_TIME Specify the number of days the same password can be used for authentication. If you also set a value for PASSWORD_GRACE_TIME, the password expires if it is not changed within the grace period, and further connections are rejected. If you do not set a value for PASSWORD_GRACE_TIME, its default of UNLIMITED will cause the database to issue a warning but let the user continue to connect indefinitely. CREATE PROFILE app_user2 LIMIT PASSWORD_LIFE_TIME 60

PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX

These two parameters must be set in conjunction with each other. PASSWORD_REUSE_TIME specifies the number of days before which a password cannot be reused. PASSWORD_REUSE_MAX specifies the number of password changes required before the current password can be reused. For these parameter to have any effect, you must specify an integer for both of them.

If you specify an integer for both of these parameters, then the user cannot reuse a password until the password has been changed the password the number of times specified for PASSWORD_REUSE_MAX during the number of days specified for PASSWORD_REUSE_TIME. For example, if you specify PASSWORD_REUSE_TIME to 30 and PASSWORD_REUSE_MAX to 10, then the user can reuse the password after 30 days if the password has already been changed 10 times.

If you specify an integer for either of these parameters and specify UNLIMITED for the other, then the user can never reuse a password. If you specify DEFAULT for either parameter, then Oracle Database uses the value defined in the DEFAULT profile. By default, all parameters are set to UNLIMITED in the DEFAULT profile. If you have not changed the default setting of UNLIMITED in the DEFAULT profile, then the database treats the value for that parameter as UNLIMITED. If you set both of these parameters to UNLIMITED, then the database ignores both of them.

PASSWORD_LOCK_TIME Specify the number of days an account will be locked after the specified number of consecutive failed login attempts.

PASSWORD_GRACE_TIME

Specify the number of days after the grace period begins during which a warning is issued and login is allowed. If the password is not changed during the grace period, the password expires.

PASSWORD_VERIFY_FUNCTION The PASSWORD_VERIFY_FUNCTION clause lets a PL/SQL password complexity verification script be passed as an argument to the CREATE PROFILE statement. Oracle Database provides a default script, but you can create your own routine or use third-party software instead.

For function, specify the name of the password complexity verification routine. Specify NULL to indicate that no password verification is performed.

If you specify expr for any of the password parameters, the expression can be of any form except scalar subquery expression. Examples

Creating a Profile: Example The following statement creates the profile new_profile: CREATE PROFILE new_profile LIMIT PASSWORD_REUSE_MAX 10 PASSWORD_REUSE_TIME 30; Setting Profile Resource Limits: Example The following statement creates the profile app_user: CREATE PROFILE app_user LIMIT SESSIONS_PER_USER CPU_PER_SESSION CPU_PER_CALL CONNECT_TIME UNLIMITED UNLIMITED 3000 45

LOGICAL_READS_PER_SESSION DEFAULT LOGICAL_READS_PER_CALL PRIVATE_SGA COMPOSITE_LIMIT 15K 5000000; 1000

If you assign the app_user profile to a user, the user is subject to the following limits in subsequent sessions:

The user can have any number of concurrent sessions. In a single session, the user can consume an unlimited amount of CPU time. A single call made by the user cannot consume more than 30 seconds of CPU time. A single session cannot last for more than 45 minutes. In a single session, the number of data blocks read from memory and disk is subject to the limit specified in the DEFAULT profile. A single call made by the user cannot read more than 1000 data blocks from memory and disk. A single session cannot allocate more than 15 kilobytes of memory in the SGA. In a single session, the total resource cost cannot exceed 5 million service units. The formula for calculating the total resource cost is specified by the ALTER RESOURCE COST statement. Since the app_user profile omits a limit for IDLE_TIME and for password limits, the user is subject to the limits on these resources specified in the DEFAULT profile.

Setting Profile Password Limits: Example The following statement creates the app_user2 profile with password limits values set: CREATE PROFILE app_user2 LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LIFE_TIME 60 PASSWORD_REUSE_TIME 60

PASSWORD_REUSE_MAX 5 PASSWORD_VERIFY_FUNCTION verify_function PASSWORD_LOCK_TIME 1/24 PASSWORD_GRACE_TIME 10;

This example uses the default Oracle Database password verification function, verify_function. Deleting User Accounts When you drop a user account, Oracle Database removes the user account and associated schema from the data dictionary. It also immediately drops all schema objects contained in the user schema, if any. A user that is currently connected to a database cannot be dropped. To drop a connected user, you must first terminate the user sessions using the SQL statement ALTER SYSTEM with the KILL SESSION clause. You can find the session ID (SID) by querying the V$SESSION view. Example 23 shows how to query V$SESSION and displays the session ID, serial number, and user name for user ANDY. Example 23 Querying V$SESSION for the Session ID of a User SELECT SID, SERIAL#, USERNAME FROM V$SESSION; SID SERIAL# USERNAME ------- --------------- ----------------------

127 55234 ANDY ... Example 24 shows how to stop the session for user andy. Example 24 Killing a User Session ALTER SYSTEM KILL SESSION '127, 55234'; You can drop a user from a database using the DROP USER statement. To drop a user and all the user schema objects (if any), you must have the DROP USER system privilege. Because the DROP USER system privilege is powerful, a security administrator is typically the only type of user that has this privilege. If the schema of the user contains any dependent schema objects, then use the CASCADE option to drop the user and all associated objects and foreign keys that depend on the tables of the user successfully. If you do not specify CASCADE and the user schema contains dependent objects, then an error message is returned and the user is not dropped. Before dropping a user whose schema contains objects, thoroughly investigate which objects the schema contains and the implications of dropping them. You can find the objects owned by a particular user by querying the DBA_OBJECTS view. Example 25 shows how to find the objects owned by user andy. Example 25 Finding Objects Owned by a User

SELECT OWNER, OBJECT_NAME FROM DBA_OBJECTS WHERE OWNER LIKE 'ANDY'; Notes: If a user schema and associated objects must remain but the user must be denied access to the database, then revoke the CREATE SESSION privilege from the user. Do not attempt to drop the SYS or SYSTEM user. Doing so corrupts your database.

A user that is currently connected to a database cannot be dropped. To drop a connected user, you must first terminate the user sessions using the SQL statement ALTER SYSTEM with the KILL SESSION clause. You can find the session ID (SID) by querying the V$SESSION view. Example 23 shows how to query V$SESSION and displays the session ID, serial number, and user name for user ANDY. Example 23 Querying V$SESSION for the Session ID of a User SELECT SID, SERIAL#, USERNAME FROM V$SESSION; SID SERIAL# USERNAME ------- --------------- ---------------------127 55234 ANDY ... Example 24 shows how to stop the session for user ANDY

(Enter the user name in capital letters.) Pay attention to any unknown cascading effects. For example, if you intend to drop a user who owns a table, then check whether any views or procedures depend on that particular table. Example 26 drops the user andy and all associated objects and foreign keys that depend on the tables owned by andy. Example 26 Dropping a User Account DROP USER andy CASCADE;

Using Data Dictionary Views to Find Information About Users and Profiles Table 21 lists data dictionary views that contain information about database users and profiles. For detailed information about these views, see Oracle Database Reference. See Also: Oracle Database Administrator's Guide for more information about terminating sessions Table 21 Data Dictionary Views That Display Information about Users and Profiles View Description ALL_OBJECTS Describes all objects accessible to the current user ALL_USERS Lists users visible to the current user, but does not describe them DBA_PROFILES Displays all profiles and their limits DBA_TS_QUOTAS Describes tablespace quotas for users

DBA_OBJECTS Describes all objects in the database DBA_USERS Describes all users of the database DBA_USERS_WITH_DEFPWD Lists all user accounts that have default passwords PROXY_USERS Describes users who can assume the identity of other users RESOURCE_COST Lists the cost for each resource in terms of CPUs for each session, reads for each session, connection times, and SGA USER_PASSWORD_LIMITS Describes the password profile parameters that are assigned to the user USER_RESOURCE_LIMITS Displays the resource limits for the current user USER_TS_QUOTAS Describes tablespace quotas for users USER_OBJECTS Describes all objects owned by the current user USER_USERS Describes only the current user

V$SESSION Lists session information for each current session, includes user name V$SESSTAT Lists user session statistics V$STATNAME Displays decoded statistic names for the statistics shown in the V$SESSTAT view The following sections present examples of using these views. These examples assume

that the following statements have been run: CREATE PROFILE clerk LIMIT SESSIONS_PER_USER 1 IDLE_TIME 30 CONNECT_TIME 600; CREATE USER jfee IDENTIFIED BY password DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp_ts QUOTA 500K ON users PROFILE clerk; CREATE USER dcranney IDENTIFIED BY password DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp_ts QUOTA unlimited ON users; CREATE USER userscott IDENTIFIED BY password;

Using Resource PROFILES You can set up limits on the system resources used by setting up profiles with defined limits on resources. Profiles are very useful in large, complex organizations with many users. It allows you to regulate the amount of resources used by each database user by creating and assigning profiles to users. Using Oracle8 password attributes where added into profiles as well. Creation of PROFILES

Profiles are a named set of resource limits. By default, when you create a user, they are given the default profile. The default profile provides unlimited use of all resources. The syntax to create a profile follows: >---CREATE PROFILE profile LIMIT resource_parameters| password_parameters--;-> Resource_parameters (you can specify multiple paramters per command): [SESSIONS_PER_USER n|UNLIMITED|DEFAULT] [CPU_PER_SESSION n|UNLIMITED|DEFAULT] [CPU_PER_CALL n|UNLIMITED|DEFAULT] [CONNECT_TIME n|UNLIMITED|DEFAULT] [IDLE_TIME n|UNLIMITED|DEFAULT] [LOGICAL_READS_PER_SESSION n|UNLIMITED|DEFAULT] [LOGICAL_READS_PER_CALL n|UNLIMITED|DEFAULT] [COMPOSITE_LIMIT n|UNLIMITED|DEFAULT] [PRIVATE_SGA n [K|M]|UNLIMITED|DEFAULT] Password_parameters (Oracle8 and above): [FAILED_LOGIN_ATTEMPTS expr|UNLIMITED|DEFAULT] [PASSWORD_LIFE_TIME expr|UNLIMITED|DEFAULT] [PASSWORD_REUSE_TIME expr|UNLIMITED|DEFAULT] [PASSWORD_REUSE_MAX expr|UNLIMITED|DEFAULT] [PASSWORD_LOCK_TIME expr|UNLIMITED|DEFAULT] [PASSWORD_GRACE_TIME expr|UNLIMITED|DEFAULT] [PASSWORD_VERIFY_FUNCTION function_name|NULL|DEFAULT] Restrictions on password parameters: * Expr must resolve to either an integer value or an integer number of days * If PASSWORD_REUSE_TIME is set to an integer value, PASSWORD_REUSE_MAX must be set to UNLIMITED. * If PASSWORD_REUSE_MAX is set to an integer value, PASSWORD_REUSE_TIME must be set to UNLIMITED. * If both PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX are set to UNLIMITED, then Oracle uses neither of these password resources. * If PASSWORD_REUSE_MAX is set to DEFAULT and PASSWORD_REUSE_TIME is set to UNLIMITED, then Oracle uses the PASSWORD_REUSE_MAX value defined in the DEFAULT profile.

* If PASSWORD_REUSE_TIME is set to DEFAULT and PASSWORD_REUSE_MAX is set to UNLIMITED, then Oracle uses the PASSWORD_REUSE_TIME value defined in the DEFAULT profile. * If both PASSWORD_REUSE_TIME and PASSWORD_REUSE_MAX are set to DEFAULT, then Oracle uses whichever value is defined in the DEFAULT profile. For example: CREATE PROFILE enduser LIMIT CPU_PER_SESSION 60000 LOGICAL_READS_PER_SESSION 1000 CONNECT_TIME 30 PRIVATE_SGA 102400 CPU_PER_CALL UNLIMITED COMPOSITE LIMIT 60000000 FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LIFE_TIME 90 PASSWORD_REUSE_TIME 180 PASSWORD_LOCK_TIME 3 PASSWORD_GRACE_TIME 3 Verify_function_one ; You can assign a profile to a user when you create the user or by altering the user. The syntax to alter the profile for a user is: ALTER USER PROFILE profile; For example: ALTER USER scott PROFILE appuser; You must have the CREATE PROFILE system privilege to create a profile. To alter a profile you must be the creator of the profile or have the ALTER PROFILE system privilege. To assign a profile to a user, you must have the CREATE USER or ALTER USER system privilege. Profiles and Resource Limits The default cost assigned to a resource is unlimited. By setting resource limits, you can prevent users from performing operations that will tie up the system and prevent other users from performing operations. You can use resource limits for security to ensure that users log off the system and do not leave the session connected for long periods of time.

You can also assign a composite cost to each profile . The system resource limits can be enforced at the session level, the call level or both. The session level is from the time the user logs into the database until the user exits. The call level is for each SQL command issued. Session level limits are enforced for each connection. When a session level limit is exceeded, only the last SQL command issued is rolled back and no further work can be performed until a commit, rollback or exit is performed. Table 7.15 lists the system resources which can be regulated at the session level. One thing to note if you use parallel query option (PQO) is that the resources are applied to each new session, not accumulated over all of the sessions that a parallel operation uses. TABLE 7.15: RESOURCES REGULATED AT THE SESSION LEVEL SYSTEM RESOURCE CPU_PER_SESSION SESSIONS_PER_USER CONNECT_TIME IDLE_TIME LOGICAL_READS_PER_SESSIO N PRIVATE_SGA DEFINITION total CPU time in hundreds of seconds number of concurrent sessions for a user allowed connection time in minutes inactive time on the server in minutes number of data blocks read including both physical and logical reads from memory and disk bytes of SGA used in a database with the multithreaded server (in K or M)

You can combine the CPU_PER_SESSION, LOGICAL_READS_PER_SESSION, CONNECT_TIME, and PRIVATE_SGA to create a COMPOSITE LIMIT. Call-level limits are enforced during the execution of each SQL statement. When a call-level limit is exceeded, the last SQL command issued is rolled back. All the previous statements issued are still valid and the user can continue to execute other SQL statements. The following system resources can be regulated at the call level: * CPU_PER_CALL for the CPU time for the SQL statement * LOGICAL_READS_PER_CALL for the number of data blocks read for the SQL statement The assignment of a cost to a resource can be performed with the ALTER RESOURCE COST command. Resource limits that you set explicitly for a

user take precedence over the resource costs in an assigned profile. The command line syntax for this command is: >-ALTER RESOURCE COST ---------------------------------------------------;--> |-[CPU_PER_SESSION n|UNLIMITED|DEFAULT]-----------| |-[CONNECT_TIME n|UNLIMITED|DEFAULT]--------------| |-[LOGICAL_READS_PER_SESSION n|UNLIMITED|DEFAULT]-| |-[PRIVATE_SGA n [K|M]|UNLIMITED|DEFAULT]--------| For example, ALTER RESOURCE COST CONNECT_TIME 100; Use of resource limits is set in the database initialization parameter RESOURCE_LIMIT=TRUE. By default this parameter is set to false. This parameter can be changed interactively with an ALTER SYSTEM command. The DBA_PROFILES view provides information on all the profiles and the resource limits for each profile. The RESOURCE_COST view shows the unit cost associated with each resource. Each user can find information on his resources and limits in the USER_RESOURCE_LIMITS view. Table 7.16 gives a description of these data dictionary views. Table 7.16: Data dictionary views for resources. DBA_PROFILES Column Profile Resource_name Limit RESOURCE_COST Column Resource_name Unit_cost Definition name of the resource cost assigned Definition the name given to the profile the name of the resource assigned to the profile the limit placed on the profile

USER_RESOURCE_LIMITS Column Resource_name Limit Definition the name of the resource the limit placed on the user

Listing All Users and Associated Information To find all users and their associated information as defined in the database, query the DBA_USERS view. For detailed information on the DBA_USERS view, see Oracle Database Reference. For example: SELECT USERNAME, PROFILE, ACCOUNT_STATUS, AUTHENTICATION_TYPE FROM DBA_USERS; USERNAME PROFILE ACCOUNT_STATUS AUTHENTICATION_TYPE --------------- --------------- --------------- ------------------SYS DEFAULT OPEN PASSWORD SYSTEM DEFAULT OPEN PASSWORD USERSCOTT DEFAULT OPEN PASSWORD JFEE CLERK OPEN GLOBAL DCRANNEY DEFAULT OPEN EXTERNAL

Listing All Tablespace Quotas Use the DBA_TS_QUOTAS view to list all tablespace quotas specifically assigned to each user. (For detailed information on this view, see Oracle Database Reference.) For example: SELECT * FROM DBA_TS_QUOTAS;

TABLESPACE USERNAME BYTES MAX_BYTES BLOCKS MAX_BLOCKS

---------- --------- -------- ---------- ------- ---------USERS JFEE 0 512000 0 250 USERS DCRANNEY 0 -1 0 -1 When specific quotas are assigned, the exact number is indicated in the MAX_BYTES column. This number is always a multiple of the database block size, so if you specify a tablespace quota that is not a multiple of the database block size, then it is rounded up accordingly. Unlimited quotas are indicated by -1. Listing All Profiles and Assigned Limits The DBA_PROFILE view lists all profiles in the database and associated settings for each limit in each profile. (For detailed information on this view, see Oracle Database Reference.) For example: SELECT * FROM DBA_PROFILES ORDER BY PROFILE;

PROFILE RESOURCE_NAME RESOURCE_TYPE LIMIT ----------------- ------------------------- ------------- -------------CLERK COMPOSITE_LIMIT KERNEL DEFAULT CLERK FAILED_LOGIN_ATTEMPTS PASSWORD DEFAULT CLERK PASSWORD_LIFE_TIME PASSWORD DEFAULT CLERK PASSWORD_REUSE_TIME PASSWORD DEFAULT CLERK PASSWORD_REUSE_MAX PASSWORD DEFAULT CLERK PASSWORD_VERIFY_FUNCTION PASSWORD

To find the default profile values, run the following query: SELECT * FROM DBA_PROFILES WHERE PROFILE = 'DEFAULT';

Viewing Memory Use for Each User Session To find the memory use for each user session, query the V$SESSION view. (For detailed information on this view, see Oracle Database Reference. The following query lists all current sessions, showing the Oracle Database user and current User Global Area (UGA) memory use for each session: SELECT USERNAME, VALUE || 'bytes' "Current UGA memory" FROM V$SESSION sess, V$SESSTAT stat, V$STATNAME name WHERE sess.SID = stat.SID AND stat.STATISTIC# = name.STATISTIC# AND name.NAME = 'session uga memory';

To see the maximum UGA memory allocated to each session since the instance started, replace 'session uga memory' in the preceding query with 'session uga memory max'.

DBMS PROCEDURES FOR USERS.

set long 100000 select dbms_metadata.get_ddl('USER','SATYA') from dual;

the above query is used to get the DDL stmt that was used to create the user 'SATYA'

set long 100000 select dbms_metadata.get_granted_ddl( 'SYSTEM_GRANT', 'SATYA' ) from dual;

THE ABOVE CMD GIVES THE LIST OF SYSTEM PRIVILEGES GRANTED TO THE USER.

set long 100000 select dbms_metadata.get_granted_ddl( 'OBJECT_GRANT', 'SATYA' ) from dual;

TO KNOW THE OBJECT PRIVILEGES GRANTED TO THE USER.

set long 100000 select dbms_metadata.get_granted_ddl( 'ROLE_GRANT','SATYA') from dual;

TO KNOW THE ROLES GRANTED TO A USER.