oracle 8 database administration volume 1 instruction guide phần 5 doc

Base Tables and Data Dictionary Views Base tables: - Normalized - Created with the sql.bsq script Data dictionary views: - Views simplify the base table information - Created with the

The data dictionary, located in the SYSTEM tablespace and owned by the

user SYS, contains two parts:

Base Tables

The foundation of the data dictionary is a set of base or underlying tables

The Oracle server writes and reads these tables Database users rarely access

them directly because they are normalized and the information is encoded

For example, you would query the IND$ table to get information about the

indexes that are defined in the database, or select from the OBJ$ table to

display the objects defined in the database

Never use DML commands such as INSERT, UPDATE, and DELETE to

update the base data dictionary tables directly, with the exception of the

AUD$ table (see the lesson “Auditing”)

5-4 Copyright  Oracle Corporation, 1998 All rights reserved.

Base Tables and Data Dictionary Views

Base tables:

- Normalized

- Created with the sql.bsq script

Data dictionary views:

- Views simplify the base table information

- Created with the catalog.sql script

Data Dictionary Views

The data dictionary views are created by running the catalog.sql script.

These views decode and summarize the information in the base data

dictionary tables Public synonyms are created on the data dictionary views

so that users can access them easily

Most users examine the data dictionary by selecting from the views rather

than the base tables

Data Dictionary View Categories

The data dictionary views are split into three categories In many cases the

views contain similar information and can be distinguished from each other

by their prefixes

The Prefix USER

These views are accessible by any user and generally refer to objects owned

owned by the user These views return a subset of the information in the

ALL_ views

The Prefix ALL

Views with the prefix ALL are accessible by any user and usually include the columnOWNER These views return information about objects to which the user has access viapublic or explicit grants of privileges and roles, including the objects that the user owns

The Prefix DBA

Views with the prefix DBA give information on all the objects in the database and usuallyinclude the column OWNER These views are queried by the database administrator orany user granted the system privilege SELECT ANY TABLE (see the lesson “Managing

5-5 Copyright  Oracle Corporation, 1998 All rights reserved.

Data Dictionary Views

5-6 Copyright  Oracle Corporation, 1998 All rights reserved.

Data Dictionary: Views Examples and Categories

dictionary

dict_columns

Data Dictionary Views:

Examples and Categories

To get an overview of the data dictionary views, their columns, and the

dynamic performance views, you can query the DICTIONARY or

-tables accessible to the user ALL_NESTED_TABLES Description of nested tables in tables

accessible to the user ALL_OBJECT_TABLES Description of all object tables

accessible to the user ALL_PART_TABLES

ALL_TABLES Description of relational tables accessible

to the user ALL_UPDATABLE_COLUMNS Descriptionofallupdatablecolumns

DBA_ALL_TABLES Description of all object and relational

tables in the database DBA_NESTED_TABLES Description of nested tables contained in

all tables DBA_OBJECT_TABLES Description of all object tables in the

database

There is a synonym DICT for the data dictionary view DICTIONARY

SVRMGR>SELECT column_name, comments

2> FROM dict_columns

3> WHERE table_name=’DBA_TABLES’;

COLUMN_NAME COMMENTS

-

TABLE_NAME Name of the table

TABLESPACE_NAME Nameofthetablespacecontainingthetable

CLUSTER_NAME Name of the cluster, if any, to which the table

belongs IOT_NAME Name of the index-only table, if any, to which

the overflow entry belongs

Note

For a detailed description of the views and their columns, see the Oracle8

Server reference manual.

Constructing the Data Dictionary

After database creation, the catalog.sql and catproc.sql scripts must be run

as the user SYS They are located in the $ORACLE_HOME/rdbms/admin

directory on UNIX and in the %ORACLE_HOME%\rdbms80\admin

directory on NT

The catalog.sql Script

The catalog.sql script creates the views on the base tables, views on the

dynamic performance views and their synonyms It starts scripts, such as

those to create views and objects for the Server Manager utility, for auditing,

for the Export and Import utility, and for the partitioning and object options

It runs the standard.sql script, which creates the basic PL/SQL environment.

The standard.sql script declares types, exceptions, and subprograms, which

are automatically available to every PL/SQL program For example, it

declares the built-in function named BITAND, which returns the result of

the bit operation and of its arguments:

function BITAND (LEFT binary_integer, RIGHT binary_integer)

Runs all scripts required for PL/SQL on the server

Creating Data Dictionary Views

The catproc.sql Script

The catproc.sql script establishes the usage of the PL/SQL functionality In

addition, it creates several PL/SQL packages that are used to extend the

RDBMS functionality The catproc.sql script also creates additional views

for the advanced queuing option, tablespace point-in-time recovery, and the

use of LOBs

Note

You may use additional scripts to support other extended Oracle

functionality, as discussed in the next section

Using Administrative Scripts

The $ORACLE_HOME/rdbms/admin directory on UNIX (or

%ORACLE_HOME%\rdbms80\admin on NT ) contains administrative

scripts, which can be separated into four categories of files:

• utl*.sql

• cat*.sql

• dbms*.sql

• prvt*.plb

The utl*.sql Scripts

The utl*.sql scripts must be run when the database needs additional views

and tables

For example, the script utlsampl.sql creates and populates the sample tables

EMP, DEPT, SALGRADE, and BONUS under the user SCOTT

5-9 Copyright  Oracle Corporation, 1998 All rights reserved.

Catalog and data dictionary information

Database package specifications

Views and tables for database utilities Wrapped database package code

The following naming conventions exist

for the sql scripts:

Convention Description

The cat*.sql Scripts

The cat*.sql scripts create data dictionary views.

In addition to the catalog.sql and catproc.sql scripts, there are scripts that

create information for Oracle utilities For example, the catrman.sql script

creates recovery catalog tables and views for the Recovery Manager The

catnormn.sql script drops these tables and views.

The dbms*.sql and prvt*.plb Scripts

The dbms*.sql and prvt*.plb scripts contain information about predefined

Oracle packages (see the next section), which extend the Oracle

functionality by providing stored database procedures and functions These

programs simplify the task of administering the database

Most SQL scripts are run during the execution of the catproc.sql script A

few additional scripts must be executed by the database administrator An

example is the dbmspool.sql script enables you to display the sizes of objects

in the shared pool and mark them for keeping or unkeeping in order to

reduce shared pool fragmentation

Note

Most of these scripts must be executed under the user SYS The database

administrator should examine the scripts to find out which user account must

be used to run the scripts

Administering Stored Procedures and Packages

Users can store PL/SQL program units in the database and execute them

using Oracle tools such as SQL*Plus, Server Manager, or Enterprise

Manager, or to execute them from an Oracle application Stored procedures,

including procedures and functions, and packages are examples of PL/SQL

program units

Stored procedures and packages are database objects that are created and

removed from the schema of a user with a CREATE or DROP command

Packages are very useful for administrative tasks

In the example, the DBMS_SESSION.SET_ROLE procedure is executed

using SQL*Plus and Server Manager, and from an Oracle application

SET_ROLE begin

end;

SGA

Stored program units provide the following advantages:

• They are stored in the shared pool and reduce disk retrieval

procedures and functions

Note

This section presents an overview of the stored procedures to enable you to

administer the stored units Developing and maintaining stored procedures

and packages is covered in detail in the course PL/SQL Program Units.

A stored procedure is a procedure or function that is created and stored in

the data dictionary as a schema object It consists of a set of SQL and

PL/SQL constructs Once created and compiled, it is a named object that can

be executed without recompiling Additionally, dependency information is

stored in the data dictionary to verify the validity of each stored procedure

The user can also include stored functions in SQL expressions They are

used in the same manner as built-in Oracle functions such as UPPER and

SUBSTR

Procedures and functions provide parameters that can be input only (IN),

output only (OUT), or both input and output parameters (IN OUT) The IN

mode is the default

5-11 Copyright  Oracle Corporation, 1998 All rights reserved.

What Are Stored Procedures?

• Are procedures or functions

• Are stored in the data dictionary

• Can be used by many users

• Can accept and return parameters

• Can be used in SQL functions

A package usually has a specification and a body stored separately in the

database:

• The specification is the interface to the application and declares the

types, variables, constants, exceptions, cursors, and subprograms

available for use

The functionality of a package is similar to that of stored procedures Once

written and compiled, the contents can be shared by many applications.One

major benefit is that the first time a package construct is called, the whole

package is loaded into memory

5-12 Copyright  Oracle Corporation, 1998 All rights reserved.

What Are Packages?

• Group logically related PL/SQL types,

items, and subprograms

• Have two parts:

– A specification

– A body

• Allow Oracle to read multiple objects

into memory at once

5-13 Copyright  Oracle Corporation, 1998 All rights reserved.

Procedure A declaration

Procedure B definition

Local variable

create or replace package body dbms_session wrapped 0

abcd abcd abcd abcd

In the example, the DBMS_SESSION package specification is located in the

dbmsutil.sql script and the package body is located in the prvtutil.plb script.

The package body in the prvtutil.plb script (plb, PL/SQL binary, is the

default extension) has been created with the Wrapper Oracle utility

The PL/SQL Wrapper hides application internals by converting PL/SQL

source code into mnemonics

1 Because this is not an additional functionality, it is not required to run

the two scripts to create the database packages

parameter value, the name of the role, in SQL*Plus or in Server

Manager:

SVRMGRL>execute DBMS_SESSION.SET_ROLE('APP1');

Statement processed.

This generates the SET ROLE command, appending the text APP1 to

"SET ROLE " and then executing as an SQL command This command

enables or disables roles and will be covered in detail in the lesson

“Managing Roles.”

The packages described in the slide are examples of Oracle-supplied

packages

DBMS_SPACE, DBMS_UTILITY, DBMS_ROWID, DBMS_SESSION,

and DBMS_LOB are created during the execution of the catproc.sql script.

DBMS_SPACE, DBMS_UTILITY, DBMS_ROWID, and

DBMS_SESSION are defined by the scripts dbmsutil.sql and prvtutil.plb,

while DBMS_LOB is defined by dbmslob.sql and prvtlob.plb.

Another utility, the DBMS_SHARED_POOL package, keeps objects in the

shared pool so that they will not be aged out with the normal LRU

algorithm It is created by running the dbmspool.sql script.

5-15 Copyright  Oracle Corporation, 1998 All rights reserved.

Oracle-Supplied Packages

• DBMS_LOB—Provides routines for operations on

BLOB and CLOB datatypes

• DBMS_SESSION—Generates SQL commands like

ALTER SESSION or SET ROLE

• DBMS_UTILITY—Provides various utility routines

• DBMS_SPACE—Provides segment space

availability information

• DBMS_ROWID—Provides ROWID information

• DBMS_SHARED_POOL—Keeps and unkeeps

information in the shared pool

Examples for Package Procedures

Note

Most of the Oracle supplied packages are explained in detail in

Oracle-supplied Oracle8 Server Application Developer’s Guide and in

Oracle8 PL/SQL User’s Guide and Reference.

Package Package procedures

SET_SQL_TRACE SET_NLS

DBMS_UTILITY ANALYZE_SCHEMA

COMPILE_SCHEMA DB_VERSION

FREE_BLOCKS DBMS_SHARED_POOL KEEP

UNKEEP

Obtaining Information

Dependencies

Oracle automatically records dependencies among objects in the data

dictionary For example, a procedure can be dependent on a view, and a view

again is dependent on a table If the table on which the view is built is

dropped, Oracle sets the STATUS column of the data dictionary view

DBA_OBJECTS for the dependent view and procedure to INVALID

All schema objects in a database have a status of VALID or INVALID

when referenced

case of procedures, functions, and packages, this means compiling the

object In the case of views, this means that the view must be reparsed If

these objects are still invalid after recompiling, syntax errors may have

occurred

5-16 Copyright  Oracle Corporation, 1998 All rights reserved.

Obtaining Information About

Query the data dictionary view DBA_OBJECTS to obtain information about

the owner, name, type, and status of the objects in the database

SVRMGR> SELECT object_name, object_type, status

2> FROM dba_objects WHERE object_name like ’DBMS_%’

- -

DBMS_APPLICATION_INF PACKAGE VALID

DBMS_APPLICATION_INF PACKAGE BODY VALID

The execution of the DESCRIBE command in the Server Manager utility

with only the package name, without a procedure or function name, shows

all procedures and functions of the DBMS_SESSION package:

svrmgr> describe dbms_session

package dbms_session is

- OVERVIEW

This package provides access to SQL "alter session"

statements, and other session information from, stored

procedures.

- PROCEDURES AND FUNCTIONS

procedure set_role(role_cmd varchar2);

Equivalent to SQL "SET ROLE ".

Input arguments:

role_cmd

This text is appended to "set role " and then executed as

SQL.

procedure set_sql_trace(sql_trace boolean);

Equivalent to SQL "ALTER SESSION SET SQL_TRACE "

Input arguments:

sql_trace

TRUE or FALSE Turns tracing on or off.

procedure set_nls(param varchar2, value varchar2);

After the execution of DDL commands such as ALTER TABLE ADD,

RENAME, DROP, and CREATE OR REPLACE, the status of the dependent

objects changes to INVALID

Also, loading dependent views and stored procedures with the Import utility

may lead to INVALID object status, because the Import utility may not be

able to create the dependent objects after creating the referenced objects

The Oracle server automatically recompiles an invalid view or PL/SQL

program unit the next time it is used In addition, the user can force the

Oracle server to recompile a view, stored procedure, or package by using the

appropriate SQL command

Note

• Using the Import utility is covered in more detail in the lesson “Loading

5-17 Copyright  Oracle Corporation, 1998 All rights reserved.