Tài liệu ORACLE8i- P5 doc

Listing 4.2: Listing the Hot Blocks in the Database Buffer Cache COLUMN segment_name FORMAT a30COLUMN file_name FORMAT a60SET LINES 132 SELECT * FROMSELECT a.tch, a.file#, a.dbablk, b.se

Now, grant select on the dba_data_files view to scott.

SQL> grant select on dba_data_files to scott;

Grant succeeded

SQL> connect scott/tigerConnected

SQL> alter procedure get_all_bytes compile;

Procedure altered

SQL> set serveroutput onSQL> exec get_all_bytesTotal bytes: 141557760PL/SQL procedure successfully completed

Now, create a procedure that runs with the rights of the owner Create the procedure as SYS because it owns the tables

We could also create an account and grant each table to it directly.SQL> connect sys/change_on_install

Connected

CREATE OR REPLACE PROCEDURE get_all_bytesAUTHID DEFINER

AStotal_bytes NUMBER;

BEGINSELECT SUM(bytes) INTO total_bytes FROM dba_data_files;

DBMS_OUTPUT.PUT_LINE(‘Total bytes: ‘||total_bytes);

END;

/Procedure created

SQL> grant execute on get_all_bytes to scott;

Grant succeeded

SQL> connect scott/tigerConnected

SQL> set serveroutput onSQL> exec sys.get_all_bytesTotal bytes: 249561088

Using the Oracle Data Dictionary

Now that you know what the data dictionary is and how it came to be, we urge younot to stop here! Don’t fall into the trap of being a DBA who doesn’t know how to useyour data dictionary to effectively manage your database Unfortunately, many DBAsare not comfortable with the data dictionary’s tables and views and don’t use themregularly This may be because they learned to administer the database itself through

a GUI tool such as Oracle’s Enterprise Manager, which reduces the need to refer tothese tables You’ll be a better DBA, however, when you know how to navigate a pro-ductive course through the data dictionary and its contents

Appendix H is a quick reference to all the data dictionary and dynamic mance views

perfor-NOTE Beyond its maintenance as a result of Oracle’s DDL operations, the data nary is also used during recursive SQL operations When you execute a SQL statement,Oracle goes recursively through the data dictionary to make sure that your SQL statement

dictio-is valid Among the items checked are the presence of the object in the SQL statement (forexample, do the tables being inserted into really exist?), and whether the columns in thatobject in fact exist Often, when you see ORA-type errors, it’s because something in therecursive table lookups didn’t work out You may have entered an invalid column or objectname, and the recursive lookups failed to find it

In this section, we introduce you to some of the common data dictionary views;

you’ll encounter these and others throughout this book Then we end the chapterwith some typical uses for data dictionary information; you can tailor these for use inyour day-to-day administrative tasks

Using the X$ Tables

You won’t often need to look at the X$ tables They are only minimally documented

by Oracle, and they change from version to version of Oracle The X$ tables may differslightly across various Oracle releases For a complete list of the X$ tables, you can traverse the V$FIXED_TABLE view (which also contains the V$, GV$ and other datadictionary items)

This section covers a few of the more commonly used X$ tables and a description

of their purpose, in addition to occasions when you can find them useful You’ll seethem used in other chapters of this book, as well

USING THE ORACLE DATA DICTIONARY

P A R T

I

• X$BH allows you to track the usage of the database buffer cache.

• X$KCBFWAIT allows you to track buffer busy waits to specific database

datafiles

• X$KSMLRU lists the ten largest allocations in the shared pool You’ll see an

example shortly

• X$KSPPI, together with X$KSPPCV, helps you find hidden Oracle parameters.

Made for the pirate in all of us! Arrrrrghhhhh…

• X$KSPPCV, along with X$KSPPI, helps you to find hidden Oracle parameters.

There’s an example coming up

X$BH

The X$BH table offers a great deal of potentially interesting information for the DBA.This view allows you to track the usage of the database buffer cache For each buffer

in the cache, you can see the file and block address that the buffer represents

NOTE With the new touch-point algorithm in Oracle8i (which replaces the old LRUalgorithm), we can tell how often a particular block has been “touched,” or used, by thedatabase Thus, we now have a mechanism to determine which blocks in the database aretruly hot

Some of the more useful columns in the X$BH table include the following:

ADDR Buffer address

STATE Current state of the buffer:

0 - Free (never been used)

1 - Either available or being used, depending on the status of theIRBA_SEQ column (if IRBA_SEQ=0, it is available; otherwise it isbeing used)

3 - In useIRBA_SEQ If > 0, this is the type of operation being conducted on the block If

0, the block is available for use

TS# Tablespace number to which the block is assigned You can reference

the TS$ data dictionary view (using columns TS# and NAME) to get thename of the associated tablespace

FILE# The absolute file number to which the block is assigned You can

ref-erence the DBA_DATA_FILES column FILE_ID to get the name of thedatafile or the tablespace name associated with the datafile

DBABLK Block’s assigned number within the assigned datafile

TCH This is the “touch” counter, which is incremented each time the

buffer is touched Gives an indication of how “hot” (popular) theblock is

Listing 4.2 is the code for a report that tells us which database blocks are the hotblocks It provides the name of the segment and the datafile in which it belongs Beaware that this query can take some time to complete, depending on the size of yourdatabase buffer cache and the number of overall segments, as well as the number ofdatafiles in your database

Listing 4.2: Listing the Hot Blocks in the Database Buffer Cache

COLUMN segment_name FORMAT a30COLUMN file_name FORMAT a60SET LINES 132

SELECT * FROM(SELECT a.tch, a.file#, a.dbablk, b.segment_name, c.file_nameFROM x$bh a, dba_extents b, dba_data_files c

WHERE a.file#=b.file_idAND a.dbablk >= b.block_idAND a.dbablk < b.block_id+b.blocksAND a.file#=c.file_id

ORDER BY 1 DESC)WHERE rownum < 20;

X$KCBFWAIT

The X$KCBFWAIT table provides with a list of files that are experiencing a great ber of buffer busy waits Using the following query, you can determine which

num-datafiles are experiencing the worst wait problems:

SELECT count, file#, nameFROM x$kcbfwait, v$datafileWHERE indx + 1 = file#

ORDER BY count desc;

You’ll find complete coverage of wait monitoring in Chapter 17

X$KSMLRU

The X$KSMLRU table can be used to monitor the latest large object (LOB) allocations

in the shared pool In earlier versions of Oracle8i, the contents of this table were erasedafter a SELECT statement was issued against it This is not the case with later versions—

however, the table may change quickly, particularly in a dynamic environment

USING THE ORACLE DATA DICTIONARY

P A R T

I

X$KSMLRU returns the 10 latest allocations, so for use in ongoing analysis, it’s a good idea to create a second table and dump the contents of X$KSMLRU into it from time

to time

Let’s say you want to figure out which large PL/SQL objects you should pin in the shared pool (“Pinning” an object means forcing Oracle to keep it Pinning objects in the shared pool is discussed in later chapters.) You can use a query like that shown in Listing 4.3 This query returns the six largest users of the shared pool You will proba-bly want to change the number of rows returned as needed In this example, we can see that a stored procedure gets loaded quite a bit, as well as some large SQL state-ments We might well want to find those SQL statements and create them as PL/SQL statements instead

Listing 4.3: Using X$KSMLRU to Determine Objects to Pin in the Shared Pool

SELECT * FROM (SELECT ksmlrhon, ksmlrsiz FROM x$ksmlru

ORDER BY ksmlrsiz) WHERE rownum < 6;

KSMLRHON KSMLRSIZ

-

-SP_1438_SEL_S_INVOICE 1060

SEG$ 2232

PKG_3541_CALL_STATISTICS 4120

BEGIN pkg_4488_sel_m_eqp_src 4132

SELECT * FROM “CSTTDD” 4292

select a.* from csttdd a, cs 4324

X$KSPPI and X$KSPPCV

There is a class of parameters that is not available to you in V$PARAMETER or any V$

view: the hidden or undocumented parameters But you can see them in the X$KSPPI and X$KSPPCV tables, which contain all the various parameters and their current and

default settings in Oracle These tables are made for the pirate in all of us!

Oracle has more hidden and undocumented parameters than it has documented

ones Many of these parameters are dangerous and should never be tinkered with unless

you have guidance from Oracle Support, and not until they’ve been tested in a non-production environment first Nevertheless, some of the hidden parameters can be very useful from time to time Often when we install a new Oracle version, we produce

Listing 4.4: Querying for Hidden Parameters

SELECT a.ksppinm “Name”, b.ksppstvl “Current Value”, b.ksppstdf “Original Default?”

FROM x$ksppi a, x$ksppcv bWHERE a.indx=b.indxAND substr(ksppinm,1,1)=‘_’

ORDER BY 1;

and a partial resultName Current Value Origional Default?

- - _trace_flushing FALSE TRUE

-_trace_multi_block_reads FALSE TRUE_trace_write_batch_size 32 TRUE_tts_allow_nchar_mismatch FALSE TRUE_unnest_subquery FALSE TRUE_use_ism TRUE TRUE_use_nosegment_indexes FALSE TRUE_use_vector_post TRUE TRUE_wait_for_sync TRUE TRUE_walk_insert_threshold 0 TRUE_write_clones 3 TRUE_yield_check_interval 100 TRUE

Using the DBA_, ALL_, and USER_ Views

The DBA_, ALL_, and USER_ views are used primarily for database administration poses This is in contrast to the dynamic performance (V$) views that contribute pri-marily to database tuning (although they are handy for backup and recovery, as well)

pur-As stated earlier in this chapter, a user’s privileges determines which views he orshe can query In the ALL_ view, the grants to specific objects determine what objects

USING THE ORACLE DATA DICTIONARY

P A R T

I

the user can see All users who have the ability to log in to the database can query theUSER_ and ALL_ views, giving users a way to tell what objects they own and haveaccess to.

Note that there are some DBA views that do not exist as ALL_ or USER_ views This

is generally for security purposes Also, you will find that columns don’t appear in all

of these views This is sometimes for security purposes, and sometimes because thosecolumns are simply not needed for a particular view For example, with the USER_views, there is really no need for the username column NOW

The DBA_ Views

These views are used by the DBA to get an overall look at the entire database Forexample:

• Documenting the database This involves locating all objects in the database, alldatafiles, rollback segments and so on We will cover this in more detail shortly

• Performing security audits of the database

• Finding out where and when certain problems, such as space problems, arelikely to occur

• Determining how much free space remains in the database

• Determining what users are set up on the system, and what default and rary tablespaces are assigned to those users

avail-able to all DBAs—that’s exactly why you need to be careful about giving DBA privileges.Access to DBA_ views is granted through use of the DBA role (see later in this section for

instructions on granting users access to specific DBA_ views, if that is required) Never

grant the DBA role just to accommodate temporary access to a DBA_ view Substantial risk

is associated with the DBA role, as discussed in Chapter 21

Following is an example of using the DBA_USERS dictionary view to produce areport of all users We want to make sure that no one is using the SYSTEM tablespacefor the TEMPORARY tablespace (as is the default setting in Oracle)

SQL> SELECT username, temporary_tablespace FROM dba_users;

USERNAME TEMPORARY_TABLESPACE

-

-SYS -SYSTEM SYSTEM SYSTEM OUTLN SYSTEM DBSNMP SYSTEM SID SYSTEM TEST TEMP SCOTT2 TEMP SCOTT TEMP As you can see from the report above, we probably need to modify temporary tablespace settings for several users, in order to avoid the problems with sort segments in the SYSTEM tablespace (this problem is discussed in Chapter 6) The DBA_ reports offer all sorts of information like this In the later section “Documenting the Data-base,” you’ll see many examples of queries and the resulting output that will help you document your database configuration NOTE A new role is available in 8i that allows you to give users access to the data dic-tionary views but not DBA privileges (as with the DBA role) The SELECT_CATALOG_ROLE role allows the user assigned to this role to select from all the data dictionary views The USER_ Views Here is the output from a query to the USER_TABLES view for the SCOTT schema: SQL> SELECT table_name, tablespace_name, pct_free, pct_used, pct_increase FROM user_tables; TABLE_NAME TABLESPACE_NAME PCT_FREE PCT_USED PCT_INCREASE - - -

-BONUS USERS 10 40 50

CHILD USERS 10 40 50

DEPT USERS 10 40 50

DUMMY USERS 10 40 50

EMPLOYEE USERS 10 40 50

USING THE ORACLE DATA DICTIONARY

P A R T

I

HOLD_EVENTS USERS 10 40 50

NEWTABLE USERS 10 40 50

PARENT USERS 10 40 50

PAY_TABLE USERS 10 40 50

SALGRADE USERS 10 40 50

TEMP_EMP USERS 10 40 50

TEMP_EMPLOYEE USERS 10 40 50

TESTME USERS 10 40 50

TEST_ME USERS 10 40 50

TEST_RGF USERS 10 40 50

In this query, we are looking for the list of tables owned by the user SCOTT, and SCOTT only He may have access to other tables, but they will not be listed in this view Because these objects are only objects that belong to the SCOTT schema, there is no need for an OWNER column You will find that there is no OWNER column in most of the USER_ views Following is a second example of querying a USER_ view: SQL> SELECT username, account_status, expiry_date, default_tablespace FROM user_users; USERNAME ACCOUNT_STATUS EXPIRY_DA DEFAULT_TABLESPACE - - - -SCOTT OPEN 31-MAR-01 USERS

Here we find only our own account information We can see that our account pass-word expires on March 31 We can also see in the ACCOUNT_STATUS column whether our password has expired and whether the system is allowing us to use grace logins

You’ll see many other examples of USER_ views throughout this book

The ALL_ Views

Since users can access any Oracle object, provided the correct grants are given, you need a way to query the data dictionary metadata on those objects Enter the ALL_ views, which provide a complete picture of objects you have access to, and other important database-level information Because of security concerns, use of the ALL_ views is more restricted For example, the ALL_USERS view only contains three columns, as opposed to ten columns for USER_USERS and twelve columns for DBA_USERS

The next example is a query against the ALL_TABLES view Contrast this against the earlier query on USER_TABLES Note the inclusion of the OWNER column; this view can now report on multiple schemas if you have access to objects in multiple schemas You can see some tables in the SCOTT2 schema in our example, which implies that we have some form of access to these tables Of course, there are other views that will tell us what accesses we have, but we’ll save that for Chapter 21

SQL> SELECT owner, table_name, tablespace_name, pct_free, pct_used, pct_increase from all_tables WHERE OWNER NOT IN (‘SYS’,’SYSTEM’,’OUTLN’);

OWNER TABLE_NAME TABLESPACE_NAME PCT_FREE PCT_USED PCT_INCREASE

- - - - -

-SCOTT DEPT USERS 10 40 50

SCOTT BONUS USERS 10 40 50

SCOTT SALGRADE USERS 10 40 50

SCOTT DUMMY USERS 10 40 50

SCOTT EMPLOYEE USERS 10 40 50

SCOTT TEST_RGF USERS 10 40 50

SCOTT TESTME USERS 10 40 50

SCOTT NEWTABLE USERS 10 40 50

SCOTT TEST_ME USERS 10 40 50

SCOTT PAY_TABLE USERS 10 40 50

SCOTT2 EMP LOCAL_UNIFORM 10 40 0

SCOTT2 DEPT LOCAL_UNIFORM 10 40 0

SCOTT2 BONUS LOCAL_UNIFORM 10 40 0

SCOTT2 SALGRADE LOCAL_UNIFORM 10 40 0

SCOTT2 DUMMY LOCAL_UNIFORM 10 40 0

SCOTT TEMP_EMPLOYEE USERS 10 40 50

SCOTT TEMP_EMP USERS 10 40 50

SCOTT PARENT USERS 10 40 50

SCOTT CHILD USERS 10 40 50

SCOTT HOLD_EVENTS USERS 10 40 50

Using the V$ Dynamic Performance Views

The V$ dynamic performance views are used primarily for the following purposes:

• For database performance monitoring and tuning, as discussed in Chapters 15 through 17

• To facilitate recovery solutions for the database, as discussed in Chapters 10 through 13

USING THE ORACLE DATA DICTIONARY

P A R T

I

• For database documentation In particular, the V$ views provide information onthe redo logs and the control files The rest of this chapter demonstrates this use

in documenting particular database structures

NOTE Despite their name, the dynamic performance views are not truly “dynamic,” in thesense that they are updated on a real-time basis They should not be expected to providereal-time information

Documenting the Database

This section presents a series of queries on data dictionary views that you can run tohelp you document your Oracle database These reports will come in handy whenyou need to recover parts of your database, and when you run into odd problemswith things such as user accesses In addition, studying and understanding the reportswill help you see how to better use the data dictionary

We have included SQL*Plus formatting commands in the headers of these reports,

so they should look as good on your screen as they do ours! Many of them utilize character lines, so if you’re going to print the output, you will want to do so in land-scape mode Also, notice that we’ve excluded the SYS and SYSTEM users in many ofthese reports When you want to reinstate this data, simply remove the query linesthat cause these users to be excluded

132-All sorts of SQL code is used in these examples—outer joins, unions, and more Wehope the examples will get you started creating your own set of useful scripts forquerying your data dictionary The idea here is to get your feet wet, so that as youcome across more detailed queries in other chapters of this book and in your everydayOracle environment, you will develop a feeling of comfort with the data dictionary.When you can navigate it with ease, you will be a better DBA

Database Tablespaces and Associated Datafiles

The query in Listing 4.5 will report on your database’s tablespaces and the datafilesassociated with those tablespaces The output also includes the size of each datafile,and if you run this query in SQL*Plus, it will break on each tablespace, giving you thetotal size of each In this listing we use several columns of the DBA_DATA_FILES datadictionary view, including TABLESPACE_NAME and FILE_NAME (to give us the name

of the datafile associated with the tablespace, because each tablespace can have more

than one datafile) Also, we include the BYTES column The listing also shows theSQL*Plus report with sample output

Listing 4.5: Report on Tablespaces and Datafiles

TTITLE CENTER “Database Tablespace and Datafile Report”

COLUMN no_prt NOPRINT

BREAK ON no_prt SKIP 2

COMPUTE SUM OF bytes ON no_prt

COMPUTE SUM OF bytes ON report

COLUMN bytes FORMAT 9,999,999,999

SELECT tablespace_name no_prt, tablespace_name, file_name, bytes

-RBS D:\ORACLE\ORADATA\ORA816\ORA816_ -RBS_01.DBF 20,971,520

20,971,520

-SYSTEM D:\ORACLE\ORADATA\ORA816\ -SYSTEM01.DBF 57,671,680

57,671,680

-TEMP D:\ORACLE\ORADATA\ORA816\ORA816_ -TEMP_01.DBF 10,485,760

10,485,760

-USERS D:\ORACLE\ORADATA\ORA816\ORA816_ -USERS_01.DBF 31,457,280

USERS D:\ORACLE\ORADATA\ORA816\USERS02.DBF 5,242,880

36,700,160What can you deduce from this report? First of all, there is a problem with consis-tency in the naming convention for datafiles This is always a serious managementissue (If you don’t agree, you might want to reconsider your choice of career…or, at

-DOCUMENTING THE DATABASE

P A R T

I

least, reread “Naming Conventions” in Chapter 3.) Whether you’re naming file tems or datafiles or the objects within your database, be consistent!

sys-Online Redo Logs

You can use the V$LOG and V$LOGFILE parameters to document the location andsizes of the online redo logs Listing 4.6 shows a report that uses the data dictionary

to document the location, number, and size of these logs on a Unix system It issorted by each redo log group, and then by the group member Incidentally, this list-ing is a good example of spreading redo log group members among disks The firstmembers of the groups are sitting on disk /ora010, and the second member of eachredo log group is sitting on disk /ora110

Listing 4.6: Documenting Your Redo Logs

COLUMN member FORMAT a60SET LINES 132

TTITLE CENTER “Redo Log Report”

BREAK ON REPORTCOMPUTE SUM OF bytes ON reportCOLUMN bytes FORMAT 9,999,999,999

SELECT a.group#, b.member, a.bytes FROM v$log a, v$logfile b

-Control Files

You can use the V$PARAMETER and V$CONTROLFILE_RECORD_SECTION views toget the location and size of the control files For example, should you need to re-create the init.ora parameter file, it helps to know where the control files used to be

Also, such a report helps you analyze the distribution of these files to ensure they areprotected against accidental loss Listing 4.7 is a nice little script that reports the loca-tion and size of each control file

Listing 4.7: Documenting the Control Files

COLUMN NAME FORMAT a60SET LINES 132

TTITLE CENTER “Control File Report”

BREAK ON REPORTCOMPUTE SUM OF bytes ON REPORTCOLUMN bytes FORMAT 9,999,999,999

SELECT c.name, b.db_block_value * (1 + 2 * sum(ceil(record_size * records_total / b.db_block_value))) bytes

FROM sys.v_$controlfile_record_section a,(SELECT value db_block_value FROM v$parameter WHERE name=‘db_block_size’) b,v$controlfile c

GROUP by c.name, b.db_block_value;

DOCUMENTING THE DATABASE

P A R T

I

Control File ReportNAME BYTES - -/ora101/oracle/DBDB/crtl/control01.ctl 9,814,016/ora201/oracle/DBDB/crtl/control02.ctl 9,814,016/ora301/oracle/DBDB/crtl/control03.ctl 9,814,016

sum 29,442,048

-NOTE The number of bytes reported in this output is a close approximation This scriptworks fine on Solaris 2.6 with Oracle 8.1.6.3, but was about 8 blocks short on an NT sys-tem running 8.1.6 On other NT systems, however, it worked just fine (go figure!)

Current Parameters in Use

There are many times when the DBA needs to know the current setting of a databaseparameter You’ll also have frequent questions about the names and values of hiddenparameters In Chapter 3 we discussed the possibility of changing parameters dynami-cally This report will provide the information you need in order to know if a parame-ter can be changed on-the-fly

For session parameters, only two possibilities are reported: The parameter caneither change (YES) or it cannot (NO) For system-level parameters, there are threepossibilities: The parameter can change as soon as you issue the command (IMMEDI-ATE), or it will change as soon as your session exits (DEFERRED), or it cannot bechanged at all (NO) The report also tells you whether the parameter is currently mod-ified or is taking its default setting

The report shown in Listing 4.8 has parameters sorted by name, with hidden meters at the top There’s also a description of the parameter, which we have set up todisplay on a second line for each parameter in the report

para-NOTE If you dig a little, you’ll find that this report has many elements in common withthe code for the V$PARAMETER view This is one example of how you can study Oracle’shandling of the data dictionary views and modify them to provide the data you really want.You might even consider turning this report into a view, named perhaps MYV$_ALL_PARAMETERS

Listing 4.8: Report of Current Database Parameters

SET LINES 132SET PAGES 66TTITLE CENTER “Parameter Setting Report”

COLUMN “Parameter Name” FORMAT a25 WRAPCOLUMN “Value” FORMAT a20 WRAP

COLUMN “Default?” FORMAT a5COLUMN “Session Modifiable” FORMAT a4COLUMN “System Modifiable” FORMAT a12COLUMN “Currently Modified” FORMAT a4COLUMN “Oracle adjusted” FORMAT a4COLUMN “Parameter Description” FORMAT a80SELECT

ksppinm “Parameter Name”,ksppstvl “Value”,

ksppstdf “Default?”, DECODE(BITAND(ksppiflg/256,1),1,’YES’,’NO’) “Session Modifiable”, DECODE(BITAND(ksppiflg/65536,3),1,’IMMEDIATE’,2,’DEFERRED’,

3,’IMMEDIATE’,’NO’)

“System Modifiable “, DECODE(BITAND(ksppstvf,7),1,’YES’,4,’SYSTEM_MOD’,’NO’)

“Currently Modified”,DECODE(BITAND(ksppstvf,2),2,’YES’,’NO’) “Oracle Adjusted”, SUBSTR(ksppdesc,1,80) “Parameter Description”

FROM x$ksppi x, x$ksppcv y WHERE (x.indx = y.indx)ORDER BY ksppinm;

Parameter Setting ReportParameter Name Value Defau Sess System Mo Curr Orac - - - - Parameter Description

_use_vector_post TRUE TRUE NO NO NO NOuse vector post

-_wait_for_sync TRUE TRUE NO NO NO NOwait for sync on commit MUST BE ALWAYS TRUE

_walk_insert_threshold 0 TRUE NO NO NO NOmaximum number of unusable blocks to walk across freelist

DOCUMENTING THE DATABASE

P A R T

I

_write_clones 3 TRUE NO IMMEDIATE NO NOwrite clones flag

_yield_check_interval 100 TRUE YES IMMEDIATE NO NOinterval to check whether actses should yield

active_instance_count TRUE NO NO NO NOnumber of active instances in the parallel server

always_anti_join NESTED_LOOPS TRUE NO NO NO NOalways use this anti-join when possible

always_semi_join standard TRUE NO NO NO NOalways use this semi-join when possible

aq_tm_processes 0 TRUE NO IMMEDIATE NO NOnumber of AQ Time Managers to start

audit_trail NONE TRUE NO NO NO NOenable system auditing

background_dump_dest D:\Oracle\admin\ora8 FALSE NO IMMEDIATE NO NO

16\bdumpDetached process dump directorybackup_tape_io_slaves FALSE TRUE NO DEFERRED NO NOBACKUP Tape I/O slaves

bitmap_merge_area_size 1048576 TRUE NO NO NO NOmaximum memory allow for BITMAP MERGE

blank_trimming FALSE TRUE NO NO NO NOblank trimming semantics parameter

buffer_pool_keep TRUE NO NO NO NONumber of database blocks/latches in keep buffer pool

buffer_pool_recycle TRUE NO NO NO NONumber of database blocks/latches in recycle buffer pool

commit_point_strength 1 TRUE NO NO NO NOBias this node has toward not preparing in a two-phase commit

compatible 8.1.6 FALSE NO NO NO NODatabase will be completely compatible with this software versio

control_file_record_keep_ 7 TRUE NO IMMEDIATE NO NOtime

control file record keep time in days

PL/SQL Objects in the Database

The report in Listing 4.9 documents the names and types of PL/SQL objects in thedatabase, sorted by schema and object name It can serve as a good cover page for the

report described in the next section, which extracts the syntax of the PL/SQL code inthe database.

Listing 4.9: PL/SQL Code in the Database

COLUMN object_name FORMAT a50SET LINES 132

SET PAGES 66TTITLE CENTER “Stored PL/SQL Object Listing”

SELECT owner, object_name, object_typeFROM dba_objects

WHERE object_type IN (‘FUNCTI/ON’,’PROCEDURE’,’PACKAGE’,

‘PACKAGE BODY’,’TRIGGER’)ORDER BY owner, object_type, object_name;

Stored PL/SQL Object ListingOWNER OBJECT_NAME OBJECT_TYPE - - -SCOTT GET_ALL_BYTES PROCEDURESCOTT MY_PROCEDURE PROCEDURESCOTT EMPLOYEE_TRIGGER TRIGGER

PL/SQL Object Text

In the RevealNet Knowledge Base for Oracle Administration, you’ll find a report onthe text of all PL/SQL objects within the database, titled PL/SQL Source Report Withjust a tiny bit of modification to the code, you could have it extract just a specificpiece of PL/SQL, or just the PL/SQL for a specific user

Users’ Setups in the Database

The report produced by the code in Listing 4.10 documents the users in the database,sorted by username (The output has been slightly modified to fit on this page.)

NOTE Don’t forget about the importance of keeping your SYSTEM tablespace mented and unfilled Controlling the default tablespace settings for users is particularlyimportant in preventing this The report shown in Listing 4.10 can be used to alert youabout users with incorrect temporary tablespace or default tablespace settings

Listing 4.10: Database User Report

SET LINES 132 SET PAGES 66 SELECT a.username, a.default_tablespace, a.temporary_tablespace, NVL(b.num_objects,0) “Number of Objects”

FROM dba_users a, (SELECT owner, COUNT(*) num_objects FROM dba_objects GROUP BY owner) b WHERE b.owner (+) = a.username

ORDER BY 1;

USERNAME DEFAULT TEMPORARY Number of Objects

- - -

-DBSNMP SYSTEM SYSTEM 4

OUTLN SYSTEM SYSTEM 5

PERFSTAT PERFSTAT TEMP 59

REPO REPOSITORY TEMP 99

REPOSITORY REPOSITORY TEMP 0

SCOTT USERS TEMPTEMP 15

SYS SYSTEM TEMP 2160

SYSTEM TOOLS TEMP 59

List of Current Roles

Listing 4.11 shows the SQL to produce a report that lists the current roles in your database, and the grants that those roles have This report is specific to roles and excludes other types of grantees

Listing 4.11: Role Grants Report

SET PAGES 66 SET LINES 80 BREAK ON role SKIP 1 TTITLE CENTER “Role Grants Report”

SELECT a.role, b.privilege FROM dba_roles a, dba_tab_privs b WHERE a.role=b.grantee

UNION SELECT a.role, b.privilege FROM dba_roles a, dba_sys_privs b WHERE a.role=b.grantee

ORDER BY 1, 2;

List of Current Grants

The report produced from Listing 4.12 is a listing of all the grants that all users have,sorted by grantee, object, and type; it also includes direct grants to objects and systemgrants In addition, you can see whether the users have the ability to grant the rolethey own to other users This report uses a join and unions between several data dic-tionary tables, including DBA_ROLE_PRIVS, DBA_TAB_PRIVS, and DBA_SYS_PRIVS

Listing 4.12: Current Grants to Users

SET PAGES 66SET LINES 132BREAK ON grantee SKIP 1SELECT a.grantee, ‘Object Grant’ AS grant_type, b.privilege,b.grantable AS “Grant Option”

FROM dba_role_privs a, dba_tab_privs bWHERE a.grantee=b.grantee

UNIONSELECT a.grantee, ‘System Grant’ AS grant_type, b.privilege,b.admin_option AS “Grant Option”

FROM dba_role_privs a, dba_sys_privs bWHERE a.grantee=b.grantee

UNIONSELECT a.grantee, ‘Role’ AS grant_type, a.granted_role,a.admin_option AS “Grant Option”

FROM dba_role_privs aORDER BY 1, 2

Current Index Key Structures

Often, the DBA will want to produce a list of indexes and the columns they are built

on This is very handy when tuning SQL statements Listing 4.13 is a SQL statementthat will produce a report on indexes and their key structures It presents the user-name, the table on which the index is built, the index type, and the key order of thecolumns This report uses the DBA_IND_COLUMNS data dictionary view

Listing 4.13: Index Key Report

SET LINES 132COLUMN table_owner FORMAT a20COLUMN index_name FORMAT a25COLUMN column_name FORMAT a25

DOCUMENTING THE DATABASE

P A R T

I