home *** CD-ROM | disk | FTP | other *** search
/ Liren Large Software Subsidy 5 / 05.iso / a / a524 / 28.ddi / doc / idxstat.doc < prev    next >
Encoding:
Text File  |  1991-03-04  |  2.3 KB  |  63 lines
  1. ...
  2. ... $Header: idxstat.doc,v 6002708.1 89/11/07 22:19:33 cyang Exp $ /rcs/6.0/vms_src_log/60027_patches/idxstat.doc Copyr (c) 1989 Oracle
  3. ...
  4.  
  5. File     : UTL$:IDXSTAT.DOC
  6. Modification history:
  7.         Porter  09/21/89        Changed to 8 character filenames
  8.         Porter  03/29/89        Created
  9.  
  10. OVERVIEW:
  11.  
  12.   Very often, when an application is running slowly, the reason will be the
  13.   presence of an unneeded index or the absence of a needed one.  These scripts
  14.   help in pinpointing those situations.
  15.  
  16. SCRIPTS:
  17.  
  18.   Three scripts allow analysis of a user's indexes, or indexed columns:
  19.  
  20.   IDXSTAT.SQL           - The main script
  21.   ONEIDXS.SQL           - Run for ONE index
  22.   DISPIDXS.SQL          - Display statistics
  23.   
  24.   IDXSTAT.SQL - This script runs ONEIDXS.SQL on multiple tables and 
  25.   columns.  It takes two parameters, the table name and the column name to 
  26.   run it on.  It will not accept a column that is not part of a non-unique
  27.   index.
  28.  
  29.   ONEIDXS.SQL - This script takes two parameters, the table name and 
  30.   the column name to do the analysis on.  It will accept any column of
  31.   any table. It should be used to analyze possible new candidates for 
  32.   indexes.
  33.   
  34.   DISPIDXS.SQL - This script reports the index statistics generated
  35.   by the previous two scripts.  It takes the same two parameters, either
  36.   of which may be wildcarded in standard SQL fashion (%, for example).
  37.  
  38. USE: 
  39.  
  40.   Normally, the user should run IDXSTAT.SQL on their current application,
  41.   then run DISPIDXS.SQL, looking for tables with a large amount
  42.   of BADNESS or very non-distinct keys.
  43.  
  44.   Then, if the user wishes to check on new index columns, use
  45.   ONEIDXS.SQL on those columns.
  46.  
  47.   Since the scripts create two tables (see below), the user should
  48.   remember to drop them when the analysis is finished.
  49.   
  50. NOTES:
  51.   
  52.   Two tables are created by the scripts - INDEX$INDEX_STATS, which
  53.   holds global statistics for each table, and INDEX$BADNESS_STATS, which
  54.   holds the badness tables for each table. 
  55.  
  56.   All scripts must be run from within SQLPLUS, version 3.0.3.1 or later. 
  57.   This is to obtain the code the treats the NEW_VALUE clause correctly.
  58.   
  59.   The code currently does not understand concatenated indexes.  
  60.   
  61.   The code should go and see how many rows per block are being used in the
  62.   table, and this would allow better statistics about db_block_gets to be made.
  63.