Tài liệu ORACLE8i- P5 doc

CHAPTER 4 • THE DATA DICTIONARY 150 -- 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/tiger Connected. SQL> alter procedure get_all_bytes compile; Procedure altered. SQL> set serveroutput on SQL> exec get_all_bytes Total bytes: 141557760 PL/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_bytes AUTHID DEFINER AS total_bytes NUMBER; BEGIN SELECT 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/tiger Connected. SQL> set serveroutput on SQL> exec sys.get_all_bytes Total bytes: 249561088 Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 151 Using the Oracle Data Dictionary Now that you know what the data dictionary is and how it came to be, we urge you not to stop here! Don’t fall into the trap of being a DBA who doesn’t know how to use your data dictionary to effectively manage your database. Unfortunately, many DBAs are not comfortable with the data dictionary’s tables and views and don’t use them regularly. 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 to these 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 perfor- mance views. NOTE Beyond its maintenance as a result of Oracle’s DDL operations, the data dictio- 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 is valid. Among the items checked are the presence of the object in the SQL statement (for example, do the tables being inserted into really exist?), and whether the columns in that object in fact exist. Often, when you see ORA-type errors, it’s because something in the recursive table lookups didn’t work out. You may have entered an invalid column or object name, 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 chapter with some typical uses for data dictionary information; you can tailor these for use in your 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 differ slightly 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 data dictionary 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 see them used in other chapters of this book, as well. USING THE ORACLE DATA DICTIONARY Oracle Essentials PART I Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 4 • THE DATA DICTIONARY 152 • 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 LRU algorithm), we can tell how often a particular block has been “touched,” or used, by the database. Thus, we now have a mechanism to determine which blocks in the database are truly 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 the IRBA_SEQ column (if IRBA_SEQ=0, it is available; otherwise it is being used) 3 - In use IRBA_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 the name 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 the datafile or the tablespace name associated with the datafile. Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 153 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) the block is. Listing 4.2 is the code for a report that tells us which database blocks are the hot blocks. It provides the name of the segment and the datafile in which it belongs. Be aware that this query can take some time to complete, depending on the size of your database buffer cache and the number of overall segments, as well as the number of datafiles in your database. Listing 4.2: Listing the Hot Blocks in the Database Buffer Cache COLUMN segment_name FORMAT a30 COLUMN file_name FORMAT a60 SET LINES 132 SELECT * FROM (SELECT a.tch, a.file#, a.dbablk, b.segment_name, c.file_name FROM x$bh a, dba_extents b, dba_data_files c WHERE a.file#=b.file_id AND a.dbablk >= b.block_id AND a.dbablk < b.block_id+b.blocks AND 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 num- ber of buffer busy waits. Using the following query, you can determine which datafiles are experiencing the worst wait problems: SELECT count, file#, name FROM x$kcbfwait, v$datafile WHERE 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 erased after 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 Oracle Essentials PART I Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 4 • THE DATA DICTIONARY 154 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 Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 155 a list of hidden parameters just to see what’s out there. The SQL in Listing 4.4 gives you this list for Oracle8i. Note that the SQL in this listing may change somewhat with new Oracle software versions (because Oracle never guarantees that database views won’t change). Because the X$ tables might change in 9i, this code may well not work. As a result, you may have to do a little experimentation to see what might have changed (or you can buy the 9i version of this book when it comes out!). 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 b WHERE a.indx=b.indx AND substr(ksppinm,1,1)=‘_’ ORDER BY 1; -- and a partial result Name 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 pur- 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). As stated earlier in this chapter, a user’s privileges determines which views he or she can query. In the ALL_ view, the grants to specific objects determine what objects USING THE ORACLE DATA DICTIONARY Oracle Essentials PART I Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 4 • THE DATA DICTIONARY 156 the user can see. All users who have the ability to log in to the database can query the USER_ and ALL_ views, giving users a way to tell what objects they own and have access 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 those columns 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. For example: • Documenting the database. This involves locating all objects in the database, all datafiles, 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, are likely to occur. • Determining how much free space remains in the database. • Determining what users are set up on the system, and what default and tempo- rary tablespaces are assigned to those users. WARNING There are no restrictions on the DBA_ views; their information is 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 a report of all users. We want to make sure that no one is using the SYSTEM tablespace for the TEMPORARY tablespace (as is the default setting in Oracle). Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 157 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 Oracle Essentials PART I Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 4 • THE DATA DICTIONARY 158 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. Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 159 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 Oracle Essentials PART I Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... database documentation In particular, the V$ views provide information on the 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 the sense that they are updated on a real-time basis They should not be expected to provide real-time information Documenting... file systems or datafiles or the objects within your database, be consistent! Online Redo Logs You can use the V$LOG and V$LOGFILE parameters to document the location and sizes 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 is sorted by each redo log group, and then by the group member Incidentally,... in days PL/SQL Objects in the Database The report in Listing 4.9 documents the names and types of PL/SQL objects in the database, sorted by schema and object name It can serve as a good cover page for the Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark www.sybex.com Copyright ©2002 SYBEX, Inc., Alameda, CA DOCUMENTING THE DATABASE report described in the next section, which... a real-time basis They should not be expected to provide real-time information Documenting the Database This section presents a series of queries on data dictionary views that you can run to help you document your Oracle database These reports will come in handy when you need to recover parts of your database, and when you run into odd problems with things such as user accesses In addition, studying... example of spreading redo log group members among disks The first members of the groups are sitting on disk /ora010, and the second member of each redo log group is sitting on disk /ora110 Listing 4.6: Documenting Your Redo Logs COLUMN member FORMAT a60 SET LINES 132 TTITLE CENTER “Redo Log Report” BREAK ON REPORT COMPUTE SUM OF bytes ON report COLUMN bytes FORMAT 9,999,999,999 SELECT a.group#, b.member,... /ora101/oracle/DBDB/redo/dbdb_redo06a.log 104,857,600 6 /ora201/oracle/DBDB/redo/dbdb_redo06b.log 104,857,600 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark www.sybex.com Copyright ©2002 SYBEX, Inc., Alameda, CA DOCUMENTING THE DATABASE 163 /ora101/oracle/DBDB/redo/dbdb_redo07a.log 104,857,600 PA R T 7 /ora201/oracle/DBDB/redo/dbdb_redo07b.log 104,857,600 8 /or1a01/oracle/DBDB/redo/dbdb_redo08a.log 104,857,600... you analyze the distribution of these files to ensure they are protected against accidental loss Listing 4.7 is a nice little script that reports the location and size of each control file Listing 4.7: Documenting the Control Files COLUMN NAME FORMAT a60 SET LINES 132 TTITLE CENTER “Control File Report” BREAK ON REPORT COMPUTE SUM OF bytes ON REPORT COLUMN bytes FORMAT 9,999,999,999 SELECT c.name, b.db_block_value... consider turning this report into a view, named perhaps MYV$_ALL_ PARAMETERS Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark www.sybex.com Copyright ©2002 SYBEX, Inc., Alameda, CA DOCUMENTING THE DATABASE Listing 4.8: Report of Current Database Parameters 165 PA R T I SET LINES 132 SET PAGES 66 TTITLE CENTER “Parameter Setting Report” Oracle Essentials COLUMN “Parameter Name” FORMAT... associated with the tablespace, because each tablespace can have more Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark www.sybex.com Copyright ©2002 SYBEX, Inc., Alameda, CA DOCUMENTING THE DATABASE than one datafile) Also, we include the BYTES column The listing also shows the SQL*Plus report with sample output 161 PA R T I Listing 4.5: Report on Tablespaces and Datafiles... modification to the code, you could have it extract just a specific piece 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 unfragmented . 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. 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