Database Management System (DBMS)

SQL* Report
SQL*Plus can be used to generate reports. Through the use of SELECT statements you can perform queries into the
ORACLE database and then alter the display to create polished reports. Some elements of a report over which you have
control are: titles, column headings, subtotals and grand totals, reformatting of numbers and text and column
computations. Getting SQL*Plus to produce reports according to your needs requires only a few simple commands.
The script is made up of both SQL and SQL*Plus commands. How can you tell the difference? Beginning with the
SELECT statement and ending with the semi-colon is SQL which talks to the ORACLE database. The remaining
commands are SQL*Plus which are used to format the results of the query into a report.
NOTE: If you are using telnet through pigseye to access ORACLE, you may have difficulty viewing on your screen the
reports you produce. Table(s) mentioned in the SELECT statement are printed following the generation of the report.
This may prevent your seeing the report because there is no scroll bar to scroll back up to see the report. When you
begin your SQL*Plus session, issue the following command:
SQL>SET PAUSE 'More. . .'
SQL>SET PAUSE ON
Setting PAUSE ON will cause SQL*Plus to display one full screen of information and then it waits for you to press
enter before it displays the next screen. More� will appear in the lower left corner until you press enter.
Suppose we want an annual salary report. We want all employees from the EMPLOYEE listed on the report, their job
title, department number and annual salary. We want employees grouped by department. We want subtotals of annual
salary for each department, then a total annual salary at the end of the report. Sound a bit intimidating? Don't worry,
we'll build this report in small steps and explain each line as we go. The best place to start is with your SELECT
statement. Once you are sure it returns the information you need, then you can begin adding SQL*Plus commands to
format the report.

How should we write the SELECT statement that will return the data needed, grouped as we want it?
SQL>SELECT DEPTNO, NAME, JOB, SALARY*12
FROM EMPLOYEE
ORDER BY DEPTNO;
DEPTNO NAME JOB SALARY*12

10 Wilson Clrk 20400

10 Chen Mngr 34800

30 Reed Anlt 42000

30 Watson Mngr 54000

40 Smith Slsm 30000

40 Allen Mngr 45600

40 Schwartz Slsm 51000

50 Turner Clrk 21600

Now we begin building the report

With the SQL*Plus command SPOOL, we can store query results in a file to be edited or printed later. We will call this
file repfile. Since only SQL commands are usually stored in the buffer, we need to begin by setting up a buffer that will
store our SQL*Plus commands along with the SQL commands. The command to set up this buffer looks like this:
SQL> SET BUFFER <name>
I will use 'a' for my buffer name.
SQL>SET BUFFER a
Then issue the INPUT command so that we may begin putting our file into the buffer.
SQL>i
1 SPOOL repfile
2 SELECT DEPTNO, NAME, JOB, SALARY*12
3 FROM EMPLOYEE
4 ORDER BY DEPTNO;
5 SPOOL OUT
Hit enter twice to return to the SQL> prompt.
Save the query as empreport. Don't confuse this file with repfile. Empreport will contain the SQL SELECT statement
and SQL*Plus commands that produce the report. Repfile will contain the report produced by empreport.
SQL>save empreport
Now run empreport. Since this file begins with a SQL*Plus command, we must use the start or @ command.
SQL>@empreport
The results table looks the same on the screen as previously, but the file repfile now contains the results table. SPOOL
<file_name> tells SQL*Plus to store the query results, formatted as you specify, in the file <file_name>. If you do not
follow the file name with a period and an extension, the default file extension LST will be added. This file is stored in
your directory on csis. You may use WS-FTP to copy it to your computer later. SPOOL OFF turns spooling off. You
may receive an error message telling you there is no default destination and to identify your printer. Ignore this message.
Your result file is being saved. SPOOL can also be used to send results to a printer.

Let's add a title at the top of the report.

SQL>get empreport
1 spool repfile
2 select deptno, name, job, salary*12
3 from employee
4 order by deptno;
5 spool off
We need to add a line after line 1. LIST line 1, then use the INPUT command to enter the title.
SQL>l1
1*Spool repfile
SQL>i
2 ttitle 'Employee Annual Salaries|As of Nov-6-1997'
Hit enter twice to get back to the SQL> prompt.
LIST the file.
SQL>l
1 spool repfile
2 ttitle 'Employee Annual Salaries|As of Nov-6-1997'
3 select deptno, name, job, salary*12
4 from employee
5 order by deptno;
6 spool off
LIST line 6. Use the INPUT command to add the following line.
SQL>l6
6*Spool off
SQL>i
7 ttitle off
Hit enter twice.
Save your query file. Remember to end the command with replace.
SQL>save empreport replace
Run the file.
SQL> @empreport
Thu Nov 06 page 1
Employee Annual Salaries
As of Nov-6-1997

DEPTNO NAME JOB SALARY*12

10 Wilson Clrk 20400

10 Chen Mngr 34800

30 Reed Anlt 42000

30 Watson Mngr 54000

40 Smith Slsm 30000

40 Allen Mngr 45600

40 Schwartz Slsm 51000

50 Turner Clrk 21600

Notice the current date and page number are placed on the report. The TTITLE command instructs SQL*Plus to place
your title at the top of the page. Your title is what you typed within single quotes in the TTITLE command. The vertical
line is the heading separator. It tells SQL*Plus that there should be a break wherever the | is placed. The vertical bar in
our TTITLE command instructs SQL*Plus to place the text before the bar on one line and the text after the bar on the
next line. Notice we included an instruction at the end of the file to turn TTITLE off.

Users, Roles & Privileges

A role is a set or group of privileges that can be granted to users or another role. This is a great way for database
administrators to save time and effort.
Administration of large numbers of objects can be difficult. Oracle roles allow you to localize the administration of
objects. Oracle roles are most helpful when large numbers of users will need the same system and object privileges
(which we discussed earlier in this chapter).
Think of an Oracle role like a database user that nobody uses. You create the Oracle role using the create role command.
You then grant the Oracle role all of the common privileges that users will require to do their work, like the ability to
select, insert, update and delete data from various tables.
Once the Oracle role is all setup, you only need grant the Oracle role to users and all the privileges will be transferred
along with that grant. Later, you can add additional privileges to the role if required.
Using roles has several benefits, including:
* Reducing the number of grants and thereby making it easier to manage security.
* Dynamically changing the privileges for many users with a single grant or revoke.
* Selectively enabling or disabling depending on the application.
Roles can be used for most system and object privileges. Privileges granted through a role cannot be used for creating an
object (views, packages, procedures, and functions). You need to grant privileges directly to the user for this.
CREATING USER
Use the CREATE USER statement to create and configure a database user, which is an account through which you can
log in to the database, and to establish the means by which Oracle Database permits access by the user.
You can enable a user to connect to the database through a proxy application or application server.
You must have the CREATE USER system privilege. When you create a user with the CREATE USER statement, the
user's privilege domain is empty. To log on to Oracle Database, a user must have the CREATE SESSION system
privilege. Therefore, after creating a user, you should grant the user at least the CREATE SESSION system privilege.
Syntax:
CREATE USER username
IDENTIFIED {BY password | EXTERNALLY | GLOBALLY AS 'external_name'}
options;
options:
DEFAULT TABLESPACE tablespace
TEMPORARY TABLESPACE tablespace
QUOTA int {K | M} ON tablespace
QUOTA UNLIMITED ON tablespace
PROFILE profile_name
PASSWORD EXPIRE
ACCOUNT {LOCK|UNLOCK}

username
Specify the name of the user to be created. This name can contain only characters from your database character set and
must follow the rules described in the section "Schema Object Naming Rules ". Oracle recommends that the user name
contain at least one single-byte character regardless of whether the database character set also contains multibyte
characters.

IDENTIFIED Clause
The IDENTIFIED clause lets you indicate how Oracle Database authenticates the user.

BY password
The BY password clause lets you creates a local user and indicates that the user must specify password to log on to the
database. Passwords can contain only single-byte characters from your database character set regardless of whether the
character set also contains multibyte characters.
Passwords must follow the rules described in the section "Schema Object Naming Rules ", unless you are using the
Oracle Database password complexity verification routine. That routine requires a more complex combination of
characters than the normal naming rules permit. You implement this routine with the UTLPWDMG.SQL script, which
is further described in Oracle Database Security Guide.

EXTERNALLY Clause
Specify EXTERNALLY to create an external user. Such a user must be authenticated by an external service, such as an
operating system or a third-party service. In this case, Oracle Database relies on the login authentication of the operating
system to ensure that a specific operating system user has access to a specific database user.

GLOBALLY Clause
The GLOBALLY clause lets you create a global user. Such a user must be authenticated by the enterprise directory
service. The external_name string can take one of two forms:
• The X.509 name at the enterprise directory service that identifies this user. It should be of the form
CN=username,other_attributes, where other_attributes is the rest of the user's distinguished name (DN) in the
directory.
• A null string (' ') indicating that the enterprise directory service will map authenticated global users to the
appropriate database schema with the appropriate roles.
You can control the ability of an application server to connect as the specified user and to activate that user's roles using
the ALTER USER statement.
DEFAULT TABLESPACE Clause
Specify the default tablespace for objects that the user creates. If you omit this clause, then the user's objects are stored
in the database default tablespace. If no default tablespace has been specified for the database, then the user's objects are
stored in the SYSTEM tablespace.
Restriction on Default Tablespaces
You cannot specify a locally managed tablespace, including an undo tablespace, or a dictionary-managed temporary
tablespace as a user's default tablespace.

TEMPORARY TABLESPACE Clause

Specify the tablespace or tablespace group for the user's temporary segments. If you omit this clause, then the user's
temporary segments are stored in the database default temporary tablespace or, if none has been specified, in the
SYSTEM tablespace.
• Specify tablespace to indicate the user's temporary tablespace.
• Specify tablespace_group_name to indicate that the user can save temporary segments in any tablespace in the
tablespace group specified by tablespace_group_name.
Restrictions on Temporary Tablespace
• The tablespace must be a temporary tablespace and must have a standard block size.
• The tablespace cannot be an undo tablespace or a tablespace with automatic segment-space
management.

QUOTA Clause
Use the QUOTA clause to allow the user to allocate up to integer bytes of space in the tablespace. This quota is the
maximum space in the tablespace the user can allocate.
A CREATE USER statement can have multiple QUOTA clauses for multiple tablespaces.
UNLIMITED lets the user allocate space in the tablespace without bound.

PROFILE Clause
Specify the profile you want to assign to the user. The profile limits the amount of database resources the user can use. If
you omit this clause, then Oracle Database assigns the DEFAULT profile to the user.
PASSWORD EXPIRE Clause
Specify PASSWORD EXPIRE if you want the user's password to expire. This setting forces the user or the DBA to
change the password before the user can log in to the database.

ACCOUNT Clause
Specify ACCOUNT LOCK to lock the user's account and disable access. Specify ACCOUNT UNLOCK to unlock the
user's account and enable access to the account.

Examples
Creating a Database User: Example
If you create a new user with PASSWORD EXPIRE, then the user's password must be changed before the user attempts
to log in to the database. You can create the user sidney by issuing the following statement:
CREATE USER sidney
IDENTIFIED BY out_standing1
DEFAULT TABLESPACE example
QUOTA 10M ON example
TEMPORARY TABLESPACE temp
QUOTA 5M ON system
PROFILE app_user
PASSWORD EXPIRE;

The user sidney has the following characteristics:

• The password out_standing1
• Default tablespace example, with a quota of 10 megabytes
 • Temporary tablespace temp
• Access to the tablespace SYSTEM, with a quota of 5 megabytes
• Limits on database resources defined by the profile app_user
• An expired password, which must be changed before sidney can log in to the database

Creating External Database Users: Examples

The following example creates an external user, who must be identified by an external source before accessing the
database:
CREATE USER app_user1
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE example
QUOTA 5M ON example
PROFILE app_user;

The user app_user1 has the following additional characteristics:

• Default tablespace example
• Default temporary tablespace example
• 5M of space on the tablespace example and unlimited quota on the temporary tablespace of the database
• Limits on database resources defined by the app_user profile

To create another user accessible only by an operating system account, prefix the user name with the value of the
initialization parameter OS_AUTHENT_PREFIX. For example, if this value is "ops$", you can create the externally
identified user external_user with the following statement:
CREATE USER ops$external_user
IDENTIFIED EXTERNALLY
DEFAULT TABLESPACE example
QUOTA 5M ON example
PROFILE app_user;

Creating a Global Database User: Example

The following example creates a global user. When you create a global user, you can specify the X.509 name that
identifies this user at the enterprise directory server:
CREATE USER global_user
IDENTIFIED GLOBALLY AS 'CN=analyst, OU=division1, O=oracle, C=US'
DEFAULT TABLESPACE example
QUOTA 5M ON example;

Privileges
A privilege is a right to execute an SQL statement or to access another user's object. In Oracle, there are two types of
privileges: system privileges and 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...

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
select name from system_privilege_map
Executing this statement, we find privileges like create session, drop user, alter database, see system privileges.
System privileges can be audited.
Arguably, 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

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
• Packeges, 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
• Indextypes
execute
For a user to be able to access an object in another user's schema, he needs the according object privilege.
Object privileges can be displayed using all_tab_privs_made or user_tab_privs_made.

Public
If a privilege is granted to the special role public, this privilege can be executed by all other users. However, sysdba
cannot be granted to public.

Grant Privileges (on Tables) to Roles

You can grant roles various privileges to tables. These privileges can be any combination of select, insert, update, delete,
references, alter, and index. Below is an explanation of what each privilege means.
Privilege Description
Select Ability to query the table with a select statement.
Insert Ability to add new rows to the table with the insert statement.
Update Ability to update rows in the table with the update statement.
Delete Ability to delete rows from the table with the delete statement.
References Ability to create a constraint that refers to the table.
Alter Ability to change the table definition with the alter table statement.
Index Ability to create an index on the table with the create index statement.

The syntax for granting privileges on a table is:

grant privileges on object to role_name

For example, if you wanted to grant select, insert, update, and delete privileges on a table called suppliers to a role
named test_role, you would execute the following statement:
grant select, insert, update, delete on suppliers to test_role;

You can also use the all keyword to indicate that you wish all permissions to be granted. For example:
grant all on suppliers to test_role;

Grant Privileges (on Functions/Procedures) to Roles

When dealing with functions and procedures, you can grant roles the ability to execute these functions and procedures.
The Execute privilege is explained below:
Privilege Description
Ability to compile the function/procedure.
Execute Ability to execute the function/procedure
directly.

The syntax for granting execute privileges on a function/procedure is:

grant execute on object to role_name;

For example, if you had a function called Find_Value and you wanted to grant execute access to the role named
test_role, you would execute the following statement:
grant execute on Find_Value to test_role;

Granting the Role to a User

Now, that you've created the role and assigned the privileges to the role, you'll need to grant the role to specific users.
The syntax to grant a role to a user is:
GRANT role_name TO user_name;

For example:
GRANT test_role to smithj;
This example would grant the role called test_role to the user named smithj.

Revoke Privileges (on Tables) to Roles

Once you have granted privileges, you may need to revoke some or all of these privileges. To do this, you can execute a
revoke command. You can revoke any combination of select, insert, update, delete, references, alter, and index.

The syntax for revoking privileges on a table is:

revoke privileges on object from role_name;

For example, if you wanted to revoke delete privileges on a table called suppliers from a role named test_role, you
would execute the following statement:
revoke delete on suppliers from test_role;

If you wanted to revoke all privileges on a table, you could use the all keyword. For example:
revoke all on suppliers from test_role;

Revoke Privileges (on Functions/Procedures) to Roles

Once you have granted execute privileges on a function or procedure, you may need to revoke these privileges from a
role. To do this, you can execute a revoke command.
The syntax for the revoking privileges on a function or procedure is:
revoke execute on object from role_name;

If you wanted to revoke execute privileges on a function called Find_Value from a role named test_role, you would
execute the following statement:
revoke execute on Find_Value from test_role;

Passing On Privileges
To grant privileges on table and to make it be able further pass on this privilege you have to give WITH GRANT
OPTION clause in GRANT statement like this.

Syntax is :
grant select on [table name] to [user name] with grant option;

For Example :
grant select on emp to shonu with grant option;

Creating a Role
To create a role, you must have CREATE ROLE system privileges.

The syntax for creating a role is:

CREATE ROLE role_name [ NOT IDENTIFIED | IDENTIFIED {BY password | USING [schema.] package |
EXTERNALLY | GLOBALLY } ;

Note: If both the NOT IDENTIFIED and IDENTIFIED phrases are omitted in the CREATE ROLE statement, the role
will be created as a NOT IDENTIFIED role.
The role_name phrase is the name of the new role that you are creating. This is how you will refer to the grouping of
privileges.
The NOT IDENTIFIED phrase means that the role is immediately enabled. No password is required to enable the role.
The IDENTIFIED phrase means that a user must be authorized by a specified method before the role is enabled.
The BY password phrase means that a user must supply a password to enable the role.
The USING package phrase means that you are creating an application role - a role that is enabled only by applications
using an authorized package.
The EXTERNALLY phrase means that a user must be authorized by an external service to enable the role. An external
service can be an operating system or third-party service.
The GLOBALLY phrase means that a user must be authorized by the enterprise directory service to enable the role.

For example:
CREATE ROLE test_role;
This first example creates a role called test_role.

CREATE ROLE test_role IDENTIFIED BY test123;

This second example creates the same role called test_role, but now it is password protected with the password of
test123.

The SET ROLE statement

The SET ROLE statement allows you to enable or disable a role for a current session.
When a user logs into Oracle, all default roles are enabled, but non-default roles must be enabled with the SET ROLE
statement.
The syntax for the SET ROLE statement is:
SET ROLE ( role_name [ IDENTIFIED BY password ] | ALL [EXCEPT role1, role2, ... ] | NONE );
The role_name phrase is the name of the role that you wish to enable.
The IDENTIFIED BY password phrase is the password for the role to enable it. If the role does not have a password,
this phrase can be omitted.
The ALL phrase means that all roles should be enabled for this current session, except those listed in the EXCEPT
phrase.
The NONE phrase disables all roles for the current session. (including all default roles)

For example:
SET ROLE test_role IDENTIFIED BY test123;
This example would enable the role called test_role with a password of test123.

Setting a role as DEFAULT Role

A default role means that the role is always enabled for the current session at logon. It is not necessary to issue the SET
ROLE statement. To set a role as a DEFAULT role, you need to issue the ALTER USER statement.

The syntax for setting a role as a DEFAULT role is:

ALTER USER user_name DEFAULT ROLE ( role_name | ALL [EXCEPT role1, role2, ... ] | NONE );

The user_name phrase is the name of the user whose role you are setting as DEFAULT.
The role_name phrase is the name of the role that you wish to set as DEFAULT.
The ALL phrase means that all roles should be enabled as DEFAULT, except those listed in the EXCEPT phrase.
The NONE phrase disables all roles as DEFAULT.

For example:
ALTER USER smithj DEFAULT ROLE test_role;
This example would set the role called test_role as a DEFAULT role for the user named smithj.

ALTER USER smithj DEFAULT ROLE ALL;

This example would set all roles assigned to smithj as DEFAULT.

ALTER USER smithj DEFAULT ROLE ALL EXCEPT test_role;

This example would set all roles assigned to smithj as DEFAULT, except for the role called test_role.

Dropping a Role
It is also possible to drop a role. The syntax for dropping a role is:
DROP ROLE role_name;

For example:
DROP ROLE test_role;
This drop statement would drop the role called test_role that we defined earlier.