Oracle SQL Plus The Definitive Guide- P36 pdf

< previous page page_317 next page >
Page 317
script can be found in the DBS directory, underneath the Oracle home directory. On Windows NT, the full path and
filename for the script is:
C: \ORANT\DBS\POPBLD. SQL
On Unix systems, the script will be in the SQL*Plus product's admin directory. For example, under HP-UX, and
running Oracle 7.3.3, the full path and filename for the script is:
$ORACLE_HOME/sqlplus/admin/pupbld. sql
In some instances, the SQL*Plus directory will be named plusXX instead of sqlplus. The XX in the name represents the
Oracle version number, so with Oracle 7.1, the directory would be named plus71.
PUPBLD.SQL should be executed while logged in as user SYSTEM. Executing it while logged in as some other user
will result in the profile table being created in the wrong schema, and may also result in a few privilege violations as it
tries to create public synonyms. The following example shows the script being executed:
SQL> @c:\orant\dbs\pupbld
drop synonym product_user_profile
*
ERROR at line 1:
ORA-01434: private synonym to be dropped does not exist

date_value from product_user_profile

*
ERROR at line 3:
ORA-00942: table or view does not exist

drop table product_user_profile

*
ERROR at line 1:
ORA-00942: table or view does not exist

alter table product_profile add (long_value long)
*
ERROR at line 1:
ORA-00942: table or view does not exist


Table created.
View created.
Grant succeeded.
Synonym created.
Synonym created.
Synonym created.
Table created.

< previous page page_317 next page >
< previous page page_318 next page >
Page 318
Grant succeeded.
View created.
Grant succeeded.
Synonym created.
0 rows updated.
SQL>
Do not be alarmed by the error messages. They are nothing to worry about and are simply the result of the way Oracle wrote the script. If
you now were to run the script again, you would see a different set of errors. Any errors returned because an object already exists, or
because an object does not exist, may safely be ignored.
Limiting Access to Commands
To limit access to a command, you simply need to insert a row into the PRODUCT_PROFILE table. This row tells SQL*Plus which
command to disable and for what user. To reenable a command, simply delete the row with the restriction. The following sections show
you how to do this.

Commands that can be disabled
There is a specific list of commands that may be disabled using the product user profile. These are listed in Table 9-2.
Table 9-2. Commands You Can Disable Using the Product User Profile
SQL*Plus SQL PL/SQL
CONNECT ALTER BEGIN
COPY ANALYZE DECLARE
EDIT AUDIT
EXECUTE CREATE
EXIT DELETE
GET DROP
HOSTa GRANT
QUIT INSERT
PASSWORD LOCK
RUN NOAUDIT
SAVE RENAME
SETb REVOKE
SPOOL SELECT
STARTc SET ROLE
SET TRANSACTION

(table continued on next page)

< previous page page_318 next page >
< previous page page_319 next page >
Page 319
Table 9-2. Commands You Can Disable Using the Product User Profile (continued)
SQL*Plus SQL PL/SQL
TRUNCATE
UPDATE
a Disabling HOST also disables $, !, or any other operating-system-specific shortcut for executing a host command.

b Disabling the SET command takes SET ROLE and SET TRANSACTION with it. That's because SQL*Plus simply looks at
the first word to see if it matches the entry in the profile table.
c Disabling the START command also disables @ and @@.

Disabling a command
To disable a command for a user, insert a row into the PRODUCT_PROFILE table. You should normally log in as SYSTEM, and your
INSERT statement should look like this:
INSERT INTO product_profile
(product, userid, attribute, char_value)
VALUES (SQL*Plus,USERNAME, COMMAND_NAME,DISABLED);
where:
SQL*Plus
This is a constant. It identifies the product to which the restriction applies, in this case SQL*Plus. It should always be mixed-case, exactly
as shown here.
USERNAME
The username of the user you are restricting. It should always be uppercase. You can wildcard this using the wildcard characters that are
used with the LIKE predicate, the percent sign and the underscore. A value of % would make the restriction apply to all users.
COMMAND_NAME
This is the name of the command you wish to disable. It should always be uppercase.
DISABLED
The keyword DISABLED must be stored in the CHAR_VALUE field.
Fields in the PRODUCT_PROFILE table other than the four listed above are not used by SQL*Plus. They should be left alone, and will
default to NULL. The following example will disable the DELETE command for the user named SCOTT:
INSERT INTO product_profile
(product, userid, attribute, char_value)
VALUES (SQL*Plus, SCOTT, DELETE, DISABLED);
You can wildcard the USERID field to disable a command for a number of users at once. You can even disable a command across the
board for all users. The follow-

< previous page page_319 next page >

< previous page page_320 next page >
Page 320
ing statement inserts a row into the PRODUCT_PROFILE table that will disable the SQL*Plus HOST command for
everyone:
INSERT INTO product_profile
(product, userid, attribute, char_value)
VALUES (SQL*Plus,%,HOST,DISABLED);
Be careful when using wildcards other than %. You have to be sure you know which users you are affecting when you
create the restriction, and you have to worry about the possibility that you might create a new username in the future
that inadvertently matches some existing restriction. Wildcards also make it difficult to remove a restriction for just one
of the users who meet the criteria. For example, you might use % to disable DELETE for all usernames starting with J.
If you later decide that JONES needs DELETE access, but JASON and JENNIFER don't, you have to rethink
everything.
Re-enabling a command
To remove a restriction you have created, simply delete that row from the PRODUCT_PROFILE table. For example, to
once again allow all users to issue the HOST command, issue the following command:
DELETE
FROM product_profile
WHERE product=SQL*Plus
AND userid=%
AND char_value=HOST
Limiting Access to Roles
You disable roles for a user in much the same way that you disable commands. The primary reason to disable a role is
that a user might have a role for purposes of running an application, but you do not want the user to have that role when
issuing ad-hoc commands from SQL*Plus.
Disabling a role
To disable a role for a user, log in as SYSTEM and insert a row into the PRODUCT_PROFILE table, as follows:
INSERT INTO product_profile
(product, userid, attribute, char_value)
VALUES (SQL*Plus,USERNAME,ROLES,ROLE_NAME);

where:
SQL*Plus
Is a constant. It identifies the product to which the restriction applies, in this case SQL*Plus. It should always be mixed-
case, exactly as shown here.

< previous page page_320 next page >
< previous page page_321 next page >
Page 321
USERNAME
Is the username of the user you are restricting. It should always be uppercase. You can wildcard the username when
restricting a role, but you must be very careful when doing so.
ROLES
Instead of a command, the keyword ROLES in this field tells SQL*Plus that you are restricting a role.
ROLE_NAME
Is the name of the role to disable.
Fields in the PRODUCT_PROFILE table that are not listed above should be left alone, and will default to NULL. The
following example will disable the PAYROLL_ADMINISTRATOR role for the user named SCOTT:
INSERT INTO product_profile
(product, userid, attribute, char_value)
VALUES (SQL*Plus,SCOTT,ROLES,PAYROLL_ADMINISTRATOR);
You can wildcard the username when disabling a role, but you must be very careful when doing this. SQL*Plus
translates all the role restrictions for a user into a single SET ROLE command like this:
SET ROLE ALL EXCEPT role, role, role
If any one of those roles is not valid for the user in question, the command will fail and none of the roles will disabled.
If you wildcard the username when disabling a role, you must be absolutely certain either that each user has been
granted the role in question, or that the role has been granted to PUBLIC.
Re-enabling a role
The method for removing a role restriction is the same as that used to remove a command restrictiondelete the row from
the PRODUCT_PROFILE table. For example, to allow SCOTT to be a PAYROLL_ADMINISTRATOR when logged
in using SQL*Plus, issue the following DELETE command:

DELETE
FROM product_profile
WHERE product=SQL*Plus
AND userid=SCOTT
AND command=ROLES
AND char_value=PAYROLL_ADMINISTRATOR
You normally need to be logged in as SYSTEM to delete from the PRODUCT_PROFILE table.

< previous page page_321 next page >
< previous page page_322 next page >
Page 322
Reporting on the Product User Profile
The following sections show you two different ways to look at the product user profile. The first section provides a
script you can run to generate a report showing all the restrictions currently defined in the PRODUCT_PROFILE table.
The second section provides a script that will show you the restrictions for a particular user, which you can specify.
You should run these scripts while logged in as the SYSTEM user. If you run them while logged in as anyone else, you
will see only the restrictions that apply to you.
Listing all restrictions
The following script will generate a report showing all the command and role restrictions defined in the
PRODUCT_PROFILE table:
SET ECHO OFF
SET PAGESIZE 50
SET LINESIZE 60
SET NEWPAGE 0
SET FEEDBACK OFF
SET TRIMSPOOL ON

TTITLE LEFT Product User profile Report -
RIGHT Page FORMAT 9999 SQL.PNO SKIP 6
BTITLE OFF

COLUMN userid FORMAT A12 HEADING User
COLUMN sort_by NOPRINT
COLUMN command FORMAT A15 HEADING Disabled¦Commands
COLUMN role FORMAT A30 HEADING Disabled¦Roles

BREAK ON userid SKIP 1

PROMPT You are about to generate a product user profile report.
ACCEPT PUP_REPORT_FILE -
PROMPT Enter the filename for the report output: -
DEFAULT PUP_REPORT.LIS

SPOOL &&PUP_REPORT_FILE
SET TERMOUT OFF

SELECT userid, 1 sort_by, attribute command, role
FROM product_profile
WHERE product = SQL*Plus
AND attribute <> ROLES
AND char_value = DISABLED
UNION
SELECT userid, 2 sort_by, command, char_value role
FROM product_profile
WHERE product = SQL*Plus

< previous page page_322 next page >
< previous page page_323 next page >
Page 323
AND attribute = ROLES

ORDER BY userid, sort_by, command, role
;

SPOOL OFF
SET TERMOUT ON

Restore these settings to their defaults
TTITLE OFF
CLEAR COLUMNS
SET PAGESIZE 14
SET LINESIZE 80
SET MEWPAGE 1
SET FEEDBACK ON
SET TRIMSPOOL OFF
When you run the script, you will be prompted for a filename, and the report output will be sent to that file. Here's an
example showing how to run the script:
SQL> @report_product_profile
You are about to generate a product user profile report.
Enter the filename for the report output: c:\a\profile.lis
SQL>
When you look in the file, you will see that the report looks like this:
Product User Profile Report Page 1



Disabled Disabled
User Commands Roles

GEORGE BEGIN
DECLARE

EXECUTE
HR_ADMINISTRATOR
PAYROLL_ADMINISTRATOR
JONATHAN BEGIN
DECLARE
DELETE
EXECUTE
HOST
SET ROLE
JEFF HOST
Listing restrictions for a particular user
To find out what restrictions apply to any one user, you must keep in mind that the USERID field in the
PRODUCT_PROFILE table may contain wildcards. The fol-

< previous page page_323 next page >
< previous page page_324 next page >
Page 324
lowing script will prompt you for a username, then display a list of all the disabled commands and roles for that user.
The queries involved use the LIKE operator to account for any possible wildcards.
SET ECHO OFF
SET FEEDBACK OFF
SET VERIFY OFF

BTITLE OFF
SET HEADING OFF
SET PAGESIZE 9999
SET NEWPAGE 1

ACCEPT user_to_show -
PROMPT Show the product profile for which user?

TTITLE LEFT restriction_heading SKIP 2
COLUMN restriction_type_heading NOPRINT NEW_VALUE restriction_heading
COLUMN sort_by NOPRINT
COLUMN restriction FORMAT A30
BREAK ON restriction_type_heading SKIP PAGE

SELECT User ¦¦ UPPER(&&user_to_show)
¦¦ is restricted from executing the following commands:
restriction_type_heading,
1 sort_by, , attribute restriction
FROM product_profile
WHERE product = SQL*Plus
AND attribute <> ROLES
AND char_value = DISABLED
AND UPPER (&&user_to_show) LIKE userid
UNION
SELECT User ¦¦ UPPER(&&user_to_show)
¦¦ has the following roles disabled:
restriction_type_heading,
2 sort_by, , char_value restriction
FROM product_profile
WHERE product = SQL*Plus
AND attribute = ROLES
AND ( UPPER(&&user_to_show) LIKE userid
OR userid = PUBLIC)
UNION
SELECT User ¦¦ UPPER(&&user_to_show)
¦¦ does not exist.
restriction_type_heading,

3 sort_by, , restriction
FROM dual
WHERE NOT EXISTS (
SELECT username
FROM all_users
WHERE username = UPPER (&&user_to_show))
ORDER BY sort_by, restriction
;

< previous page page_324 next page >
< previous page page_325 next page >
Page 325
Restore these settings to their defaults.
SET HEADING ON
SET PAGESIZE 14
SET FEEDBACK ON
SET VERIFY ON
TTITLE OFF
CLEAR BREAKS
CLEAR COLUMNS
The following example shows how to run the script and what the output looks like:
SQL> @show_product_profile
Show the product profile for which user? george
User GEORGE is restricted from executing the following commands:
BEGIN
DECLARE
EXECUTE
User GEORGE has the following roles disabled:
HR_ADMINISTRATOR
PAYROLL_ADMINISTRATOR

The script will even tell you whether or not the user really exists. It is possible to create entries in the
PRODUCT_PROFILE table for users who do not exist. It is also possible to drop a user, leaving orphan entries in the
profile. The following example demonstrates this:
SQL> @show_product_profile
Show the product profile for which user? Jonathan
User JONATHAN is restricted from executing the following commands:
BEGIN
DECLARE
DELETE
EXECUTE
HOST
SET ROLE
User JONATHAN does not exist.

< previous page page_325 next page >
< previous page page_326 next page >
Page 326
10
Administration with SQL*Plus
In this chapter:
Connecting for Administrative Purposes
Starting and Stopping a Database
Looking at Your Database
Database Backup and Recovery

Beginning with the release of Oracle8i, SQL*Plus has been enhanced to allow you to perform several administrative
functions that previously required the use of Server Manager. Using SQL*Plus, you can now perform the following
tasks:
Start up or shut down an Oracle instance
Turn archive log mode on and off

View memory usage of the System Global Area (SGA)
Look at the settings for various initialization parameters
Initiate media recovery for a database
Server Manager is still around, at least in the initial release of Oracle8i, but Oracle's strategy is to make SQL*Plus the
sole command-line interface to Oracle. Look for Server Manager to be desupported in some future release.
Connecting for Administrative Purposes
In order to start up, shut down, change archive log settings, or recover an Oracle database, you must log into the
database in a way that is different from your normal approach. Usually you connect as yourself, but to do many of the
tasks described in this chapter, you need to log in either as an operator or as a database administrator. The section titled
Connecting in an Administrative Role, later in this chapter, shows you how to do this. In addition to logging in
correctly, you must have the system privileges needed for the task you are performing. These are described next.

< previous page page_326 next page >