MINI

C:/Quest Software/Toad for Oracle 11.5/ClientFiles/User Files/
files >> C:/Quest Software/Toad for Oracle 11.5/ClientFiles/User Files/HCExplanations.XML
 <HealthCheckItems>
	<Item InternalID="151">AUDIT_TRAIL = os | db | db_extended | xml | xml_extended  results in Oracle collecting instance wide audit trail information, which adds a slight overhead to all database transactions  that might be inadvisable for a production database.  AUDIT_TRAIL = none | false disables all such audit data collection and its overhead.  Prior to Oracle 11g, AUDIT_TRAIL = none was the default.  It is now AUDIT_TRAIL = db, which means to both enable auditing and to store that information within the database.</Item>
	<Item InternalID="152">AUDIT_SYS_OPERATIONS = true enables auditing of operations issued by user SYS and users connecting with SYSDBA or SYSOPER privileges.  Generally speaking most compliance checks are at a minimum for just the database application users.  It may not be necessary to collect audit data for privileged accounts performing database maintenance as opposed to apps working directly with company data.  The default is AUDIT_SYS_OPERATIONS = false.</Item>
	<Item InternalID="153">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="177">Let Oracle set the current CPU_COUNT based upon currently available OS resources since under a virtual machine it's rather easy to add or subtract CPUs.  In fact in some cases CPUs can even be dynamically allocated based upon virtual machine load.  Therefore hard coding the CPU_COUNT is not recommended since the logical number of CPUs can vary.</Item>
	<Item InternalID="102">Let Oracle identify the current CPU_COUNT the OS sees - since CPU multi-core upgrades have become quite common and inexpensive.  Plus database host relocation is also not totally uncommon anymore.  Therefore hard coding the CPU_COUNT is not recommended since the physical number of CPUs can vary.</Item>
	<Item InternalID="103">Many OLTP and data warehousing databases repetitively execute the same commands.  For example a hard-coded screen or report run by one user that is also run by another user will often only vary the bind variable values.  Setting CURSOR_SHARING=similar permits Oracle to share cursors across sessions for such scenarios.  This can radically reduce the amount of hard parsing.  Furthermore it can help to reduce SGA and/or PGA memory usage in some cases.</Item>
	<Item InternalID="104">Setting CURSOR_SPACE_FOR_TIME=true instructs Oracle to favor space for cursors in order to save time.  The database will then tend to "pin" SQL inside the library cache shared pool area, thus making all SQL ineligible for the aging-out process until the cursor for the SQL statement is closed.  Oracle recommends setting CURSOR_SPACE_FOR_TIME=true in any database where SHARED_POOL_SIZE is large enough to simultaneously contain all open cursors.</Item>
	<Item InternalID="105">It used to be that DB_CACHE_SIZE X DB_BLOCK_SIZE determined the total size of the SGA's buffer cache (data).  Oracle now supports having multiple block sizes within a database and for separate dynamic DB_CACHE_SIZE buffer areas within the SGA.  So for best control use only the newer parameters.</Item>
	<Item InternalID="106">Memory is cheap and abundant these days - even on notebooks and desktop PCs.  And although cache hit ratios are no longer stressed as in days past with the emphasis instead more on wait states, memory is still faster than disk IO.  Therefore don't skimp on memory allocations for Oracle.  In some cases this value will have been derived from another setting, so you need to change another parameter to affect this one.  Also note that with the much newer automatic and dynamic memory allocation settings available, this rule may not apply.</Item>
	<Item InternalID="107">Memory is cheap and abundant these days - even on notebooks and desktop PCs.  And although cache hit ratios are no longer stressed as in days past with the emphasis instead more on wait states, memory is still faster than disk IO.  Therefore don't skimp on memory allocations for Oracle.  In some cases this value will have been derived from another setting, so you need to change another parameter to affect this one.  Also note that with the much newer automatic and dynamic memory allocation settings available, this rule may not apply.</Item>
	<Item InternalID="100">Memory is cheap and abundant these days - even on notebooks and desktop PCs.  And although cache hit ratios are no longer stressed as in days past with the emphasis instead more on wait states, memory is still faster than disk IO.  Therefore don't skimp on memory allocations for Oracle.  In some cases this value will have been derived from another setting, so you need to change another parameter to affect this one.  Also note that with the much newer automatic and dynamic memory allocation settings available, this rule may not apply.</Item>
	<Item InternalID="127">Memory is cheap and abundant these days - even on notebooks and desktop PCs.  And although cache hit ratios are no longer stressed as in days past with the emphasis instead more on wait states, memory is still faster than disk IO.  Therefore don't skimp on memory allocations for Oracle.  In some cases this value will have been derived from another setting, so you need to change another parameter to affect this one.  Also note that with the much newer automatic and dynamic memory allocation settings available, this rule may not apply.</Item>
	<Item InternalID="109">Memory is cheap and abundant these days - even on notebooks and desktop PCs.  And although cache hit ratios are no longer stressed as in days past with the emphasis instead more on wait states, memory is still faster than disk IO.  Therefore don't skimp on memory allocations for Oracle.  In some cases this value will have been derived from another setting, so you need to change another parameter to affect this one.  Also note that with the much newer automatic and dynamic memory allocation settings available, this rule may not apply.</Item>
	<Item InternalID="110">Memory is cheap and abundant these days - even on notebooks and desktop PCs.  And although cache hit ratios are no longer stressed as in days past with the emphasis instead more on wait states, memory is still faster than disk IO.  Therefore don't skimp on memory allocations for Oracle.  In some cases this value will have been derived from another setting, so you need to change another parameter to affect this one.  Also note that with the much newer automatic and dynamic memory allocation settings available, this rule may not apply.</Item>
	<Item InternalID="111">Memory is cheap and abundant these days - even on notebooks and desktop PCs.  And although cache hit ratios are no longer stressed as in days past with the emphasis instead more on wait states, memory is still faster than disk IO.  Therefore don't skimp on memory allocations for Oracle.  In some cases this value will have been derived from another setting, so you need to change another parameter to affect this one.  Also note that with the much newer automatic and dynamic memory allocation settings available, this rule may not apply.</Item>
	<Item InternalID="178">Let Oracle set the current DB_WRITER_PROCESSES based upon currently available OS resources since under a virtual machine it's rather easy to add or subtract CPUs.  In fact in some cases CPUs can even be dynamically allocated based upon virtual machine load.  Therefore hard coding the DB_WRITER_PROCESSES is not recommended since the logical number of CPUs can vary.</Item>
	<Item InternalID="186">Oracle Enterprise Manager (OEM) offers several optional, extra cost add-ons that you must be properly licensed for in order to use directly or indirectly (i.e. via TOAD).  Note that these optional add-ons are often automatically installed and enabled in a databases created by Oracle's Database Creation Assistant (DBCA).  That includes the database generated by the Oracle installer - which simply calls DBCA after installing the software.</Item>
	<Item InternalID="187">Oracle Enterprise Manager (OEM) offers several optional, extra cost add-ons that you must be properly licensed for in order to use directly or indirectly (i.e. via TOAD).  Note that these optional add-ons are often automatically installed and enabled in a databases created by Oracle's Database Creation Assistant (DBCA).  That includes the database generated by the Oracle installer - which simply calls DBCA after installing the software.</Item>
	<Item InternalID="188">Oracle Enterprise Manager (OEM) offers several optional, extra cost add-ons that you must be properly licensed for in order to use directly or indirectly (i.e. via TOAD).  Note that these optional add-ons are often automatically installed and enabled in a databases created by Oracle's Database Creation Assistant (DBCA).  That includes the database generated by the Oracle installer - which simply calls DBCA after installing the software.</Item>
	<Item InternalID="93">Often knowing which initialization parameters remain set to their defaults is useful.  You might be interested in knowing which parameters don't match "golden rules" or "best practices" and which parameters' values have changed from one version to another.  For example the parameter DB_FILE_MULTIBLOCK_READ_COUNT default value increased from 16 to 128.  That might be worth knowing.</Item>
	<Item InternalID="94">Often knowing which initialization parameters have been deprecated is important.  When you attempt to start your database with deprecated parameters set, one of two scenarios can happen.  Either the database will start and log a warning in the alert.log file, or the database simply won't open and log an error in the alert.log file.  Both scenarios are best avoided.</Item>
	<Item InternalID="95">The initialization parameter COMPATIBLE defaults to that of the current software installed.  However there are times where you might change this.  For example when initially deploying a new version, you might set COMPATBLE to the earlier version so as to guarantee backward compatibility of your application with that earlier release.  Knowing that this parameter has been set to anything less than the current release is worth knowing as it might prevent you from realizing the benefits offered by newer releases if you forget to unset it.</Item>
	<Item InternalID="96">The initialization parameter OPTIMIZER_FEATURES_ENABLE defaults to that of the current software installed.  However there are times where you might change this.  For example when initially deploying a new version, you might set OPTIMIZER_FEATURES_ENABLE to the earlier version so as to guarantee backward compatibility of your application with that earlier release.  Knowing that this parameter has been set to anything less than the current release is worth knowing as it might prevent you from realizing the benefits offered by newer releases if you forget to unset it.</Item>
	<Item InternalID="97">The OPTIMIZER_INDEX_CACHING parameter defaults to 0.  It can range from 0 to 100, which indicates the percentage of the index blocks the optimizer should assume are in the cache.  Many people feel that with properly defined indexes that this default is too conservative.  With a good index design informing Oracle that a larger percentage are likely to be in the cache will generally result in the optimizer making a better decision about whether to perform an index scan of a full-table.  More specifically setting this parameter to a higher value makes nested loops joins and IN-list iterators look less expensive to the optimizer.</Item>
	<Item InternalID="98">The OPTIMIZER_INDEX_COST_ADJ parameter defaults to 100.  It can range from 0 to 100, which informs the optimizer to evaluate index access paths at the "regular" or same cost as any other access path (e.g. full table scan).  Many people feel that with properly defined indexes that this default is too liberal.  With a good index design informing Oracle that an index scan might be cheaper will generally result in the optimizer more prone to selecting an index access path over a full table scan - and better performance.</Item>
	<Item InternalID="101">For safety (i.e. better fault tolerance) it is advisable to have at least three control files all on separate disks.</Item>
	<Item InternalID="108">If DB_KEEP_CACHE_SIZE &gt; 0 and the database has no objects specified as KEEP, then you may have wasted or underutilized SGA memory allocations.</Item>
	<Item InternalID="112">If any database buffer caches are set as DB_nK_CACHE_SIZE &gt; 0 and the database has no objects specified as using that block size, then you may have wasted or underutilized SGA memory allocations.</Item>
	<Item InternalID="154">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="157">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="8">Relational database tables should generally have a primary key so that you can distinguish one row from another.</Item>
	<Item InternalID="179">Let Oracle set the current PARALLEL_THREADS_PER_CPU based upon currently available OS resources since under a virtual machine it's rather easy to add or subtract CPUs.  In fact in some cases CPUs can even be dynamically allocated based upon virtual machine load.  Therefore hard coding the PARALLEL_THREADS_PER_CPU is not recommended since the logical number of CPUs can vary.</Item>
	<Item InternalID="180">Let Oracle set the current RESOURCE_MANAGER_CPU_ALLOCATION based upon currently available OS resources since under a virtual machine it's rather easy to add or subtract CPUs.  In fact in some cases CPUs can even be dynamically allocated based upon virtual machine load.  Therefore hard coding the RESOURCE_MANAGER_CPU_ALLOCATION is not recommended since the logical number of CPUs can vary.</Item>
	<Item InternalID="181">Not all virtual machine vendors manage VM memory allocations and management the same way.  In fact, the memory management features and capabilities can vary for a single vendor providing multiple solutions (e.g. Oracle has OVM, Virtual Box, etc.).  Furthermore under a virtual machine it's rather easy to add or subtract memory.  In fact in some cases memory can even be dynamically allocated based upon virtual machine load.  Thus forcing the entire SGA to lock within the VM OS could reduce the number of concurrent VMs that a host can run.  Although some vendors (such as VMware) offer something known as a "balloon driver" that seeks to alleviate memory over allocation issues, many believe that it's simply better not to push memory over-allocation.</Item>
	<Item InternalID="182">Not all virtual machine vendors manage VM memory allocations and management the same way.  In fact, the memory management features and capabilities can vary for a single vendor providing multiple solutions (e.g. Oracle has OVM, Virtual Box, etc.).  Furthermore under a virtual machine it's rather easy to add or subtract memory.  In fact in some cases memory can even be dynamically allocated based upon virtual machine load.  Thus forcing the entire SGA to pre-load within the VM OS could reduce the number of concurrent VMs that a host can run.  Although some vendors (such as VMware) offer something known as a "balloon driver" that seeks to alleviate memory over allocation issues, many believe that it's simply better not to push memory over-allocation.</Item>
	<Item InternalID="99">Newer versions of Oracle offer much more automated memory management initialization parameter settings.  Under Oracle 10g these parameters include SGA_MAX_SIZE,  SGA_TARGET and PGA_AGGREGATE_TARGET.  Under Oracle 11g these parameters include MEMORY_TARGET and MEMORY_MAX_TARGET.  If you use the 11g parameters you should not set the 10g ones.  If you use the 10g parameters you should not set individual memory management parameters such as DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, STREAMS_POOL_SIZE, WORKAREA_SIZE_POLICY and all the *_AREA_SIZE parameters.</Item>
	<Item InternalID="113">If any tablespaces have their default block size set to nK and there are no database buffer caches set with DB_nK_CACHE_SIZE &gt; 0 then your general database buffer cache may have to handle multiple block sizes which can lead to inefficient memory utilization - and gaps.</Item>
	<Item InternalID="39">The SYSTEM tablespace should be reserved for catalog use only or at least primarily.  When you permit users to create and drop temporary objects with the SYSTEM tablespace this only helps to both fragment that space and/or create gaps within the space.  Both of which can slow true data dictionary operations and hence your entire database.  Simply do not do this.</Item>
	<Item InternalID="40">The SYSTEM tablespace should be reserved for catalog use only or at least primarily.  When you permit users to create and drop persistent objects with the SYSTEM tablespace this only helps to both fragment that space and/or create gaps within the space.  Both of which can slow true data dictionary operations and hence your entire database.  Simply do not do this.</Item>
	<Item InternalID="55">When you create a user and specify their default temporary tablespace, Oracle verifies that tablespace exists.  But if that tablespace is later dropped, then the user definition ends up referencing a non-existent tablespace.</Item>
	<Item InternalID="56">When you create a user and specify their default persistent tablespace, Oracle verifies that tablespace exists.  But if that tablespace is later dropped, then the user definition ends up referencing a non-existent tablespace.</Item>
	<Item InternalID="32">Dictionary managed tablespaces (i.e. those with rows in DBA_DMT_FREE_SPACE) with a high degree of fragmentation can often result in performance degradation.  Locally managed tablespaces are much less prone to this type of problem.</Item>
	<Item InternalID="33">If your tablespace is approaching full and you do not have auto-extend specified for its datafiles then you will get the nasty "cannot allocate extent" error.  Note too that even with auto-extend specified some operating systems have file systems with file size limits that limit the auto-extend capability.  Thus is but one test needed to make sure users never encounter the "cannot allocate extent" error.</Item>
	<Item InternalID="20">If your tablespace is approaching full and you do not have auto-extend specified for its datafiles then you will get the nasty "cannot allocate extent" error.  Note too that even with auto-extend specified some operating systems have file systems with file size limits that limit the auto-extend capability.  Thus is but one test needed to make sure users never encounter the "cannot allocate extent" error.</Item>
	<Item InternalID="84">Locally managed tablespaces are now the default and recommended to be used by Oracle for all your tablespaces.  As you migrate from versions &lt;= 8.0 to &gt;= 8i, you should make sure to convert to using locally managed tablespaces.</Item>
	<Item InternalID="114">The days of smaller block sizes being more efficient are long since over.  In most situations a block size of 8K is not unreasonable.  The only exception is RAC environments - where there are still scenarios where a smaller block size (e.g. 4K) is still preferable.</Item>
	<Item InternalID="115">Oracle increased the default for MULTI_BLOCK_READ_COUNT from 16 to 128.  That setting is good for many productions environments, but for smaller deployments (e.g. dev &amp; test) the lesser hardware may benefit from a smaller size.  In addition, certain disk storage systems with cache might benefit from less aggressive read ahead.</Item>
	<Item InternalID="116">In almost all cases database performance will benefit from DISK_ASYNCH_IO = true.  While this is the default for some platforms, this parameter is so important that it's not worth leaving up to chance.</Item>
	<Item InternalID="117">These three parameters provide duplicate methods for attaining similar performance results.  Basically there are two universally recommended scenarios.  First, if you set DISK_ASYNCH_IO to false, then you should also set DBWR_IO_SLAVES to a value other than its default of zero in order to simulate asynchronous I/O.  Second, if you set DISK_ASYNCH_IO to true, then you should also set DBWR_IO_SLAVES to zero (only need one way to affect asynchronous I/O).  Also note that DBWR_IO_SLAVES is relevant only on systems with only one database writer process.</Item>
	<Item InternalID="118">This parameter is calculated based upon other parameter settings, often in a very complex manner with good reasons by Oracle.  You should treat the Oracle calculation as a minimum setting and not choose something that is less than that floor.</Item>
	<Item InternalID="183">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="184">In a production environment you generally should consider some method of controlling resource allocation and usage.  This can often especially be true when you are in a virtual environment where resources are typically much closer to tolerance levels (i.e. less slack since less over capacity).</Item>
	<Item InternalID="185">In a production environment you generally should consider some method of controlling resource allocation and usage.  This can often especially be true when you are in a virtual environment where resources are typically much closer to tolerance levels (i.e. less slack since less over capacity).</Item>
	<Item InternalID="159">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="119">This setting controls whether to use direct I/O and/or asynchronous I/O against file system based database files.  SETALL simply instructs Oracle to attempt to use both mechanisms.</Item>
	<Item InternalID="167">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="121">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="128">In many cases, even for non-data warehouses, allowing the Oracle optimizer consider performing a cost-based star query transformation can lead to a better explain plan.</Item>
	<Item InternalID="123">In many cases, even for non-data warehouses, allowing the Oracle optimizer consider performing a cost-based query rewrite from a base table to its summarized materialized views can lead to a better explain plan.</Item>
	<Item InternalID="129">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="130">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="131">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="132">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="163">For a production system where performance is generally more important than debugging  (except when a problem occurs), then setting this initialization parameter at the database level will result in less general overhead.  You can always alter a session to enable this for specific needs.</Item>
	<Item InternalID="124">Disable this parameter unless you specifically want to take advantage of the recycle bin, otherwise objects that are dropped will still consume space unless the PURGE option is specified on DROP commands.</Item>
	<Item InternalID="150">The Oracle Enterprise Manager (OEM) management packs (e.g diagnostics and tuning) are optional and must be specifically licensed.  However the Database Configuration Assistant (DBCA) creates databases with AWR, ADDM and the PL/SQL packages required to use the optional management packs enabled.  Prior to Oracle 11gR2 the DBA had to disable these optional features manually, there were several ways to accomplish this.  This parameter simplifies that process.</Item>
	<Item InternalID="51">When using the database to store audit data the DBA should move all the audit tables from the SYSTEM tablespace.</Item>
	<Item InternalID="86">In the past this audit table sequence had a cache setting too small to support a high rate of concurrent logins.  The common recommendation was to increase the value to &gt;= 1000.</Item>
	<Item InternalID="45">Knowing which database links are inactive or inaccessible can be very informative when attempting to avoid and/or debug numerous problems.</Item>
	<Item InternalID="43">Oracle recommends at least three redo log groups and two members per group for redundancy (and thus availability).</Item>
	<Item InternalID="85">AWR snapshots consume resources, thus do not schedule them too frequently.  Also the default retention period is far too short for meaningful use, so it should be increased.</Item>
	<Item InternalID="126">Many applications call the same SQL statements during a typical session, thus having at least a 20 cursors cached can reduce parse calls and cursor opens.</Item>
	<Item InternalID="122">It is important to set the value of OPEN_CURSORS high enough to prevent your application from running out of open cursors.  The number will vary from one application to another.  Assuming that a session does not open the number of cursors specified by OPEN_CURSORS, there is no added overhead to setting this value higher than actually needed.</Item>
	<Item InternalID="125">REMOTE_LOGIN_PASSWORDFILE specifies whether Oracle checks for a password file.  When it's set to NONE then Oracle ignores any password file, therefore privileged users must be authenticated by the operating system.  EXCLUSIVE is supported for backward compatibility.  It now has the same behavior as the value SHARED.</Item>
	<Item InternalID="120">When not specifically setting the redo log checkpoint timeout it's recommended to use the advisory utility that allows you to specify your optimal mean time to recovery (MTTR) recovery interval so that it can suggest the optimal redo log size.</Item>
	<Item InternalID="155">PLSQL_OPTIMIZE_LEVEL specifies the optimization level that will be used to compile PL/SQL library units.  The higher the setting of this parameter, the more effort the compiler makes to optimize PL/SQL library units.</Item>
	<Item InternalID="156">PLSQL_CODE_TYPE specifies the compilation mode for PL/SQL library units.  NATIVE means that PL/SQL library units (with the possible exception of top-level anonymous PL/SQL blocks) will be compiled to native (machine) code.  Such modules will be executed natively without incurring any interpreter overhead.</Item>
	<Item InternalID="158">PLSQL_COMPILER_FLAGS specifies a list of flags for the PL/SQL compiler as a comma-separated list of strings.  NATIVE means that PL/SQL library units (with the possible exception of top-level anonymous PL/SQL blocks) will be compiled to native (machine) code.  Such modules will be executed natively without incurring any interpreter overhead.  NON_DEBUG means that PL/SQL library units will be compiled for normal execution.</Item>
	<Item InternalID="57">Relational database tables should generally have at least one unique key and/or index so that you can distinguish one row from another.</Item>
	<Item InternalID="9">Indexes add overhead to all INSERT, UPDATE and DELETE commands.  Thus you should minimize the number of indexes for any given tables to those actually needed for data accuracy and/or query performance.</Item>
	<Item InternalID="46">The error ORA-0600 is a generic catch-all error for those errors so new as not yet to have their own assigned number.  In most cases an ORA-0600 error requires a call to Oracle tech support as this is usually a problem or even a bug with the database.  In most cases the application causing the error is merely exposing an Oracle problem.</Item>
	<Item InternalID="59">Relational database tables should generally narrow and tall.  That means tables should have few columns but many rows.  The idea is to use normalization techniques to keep all the tables well designed.  The exception being data warehouses - where dimension tables often become quite wide (i.e. have many columns).</Item>
	<Item InternalID="60">Indexes add overhead to all INSERT, UPDATE and DELETE commands.  Thus you should minimize the size of indexes (i.e. number of columns) for any given tables to only those columns actually needed for data accuracy and/or query performance.</Item>
	<Item InternalID="61">The LOG and RAW data types have been replaced by CLOB and BLOB data types.  Oracle recommends no longer using the old data types.</Item>
	<Item InternalID="62">It may be beneficial to know when you have global indexes (i.e. those whose partitioning strategy does not match the table's).  There are times where global indexes are preferable.  But in geenral local indexes (i.e. those whose partitioning strategy matches the table's) are the norm.</Item>
	<Item InternalID="63">When a table's row size is larger than the database or tablespace's block size then each row requires two IOs.  You may need to either increase the database block size (a reorganization exercise) or moving the table to a tablespace with a larger block size (a relocation).</Item>
	<Item InternalID="54">Given the INSERT, UPDATE and DELETE overhead costs of indexes one needs to design all indexes without overlapping indexes or duplication of effect.  Since the optimizer can use only one index for a given condition, design indexes such that they can handle the widest range of scenarios.</Item>
	<Item InternalID="58">Even though newer versions of Oracle can maintain primary and unique key constraints using non unique indexes, the DBA may want to be aware of these.</Item>
	<Item InternalID="31">When you join a parent table (using PK) and a child table (using FK) the performance will suffer when the data types and/or lengths are not identical.  Although it's essentially a relational design mistake to allow PKs and FKs not to match - it will work.  But the optimizer will need to add steps to the explain plan to perform implicit data type conversions - which means indexes may not be used.</Item>
	<Item InternalID="53">When the child table does not have an index on a FK, then certain DML operations on that child table will require a lock at some level on the parent table which can radically decrease perfmance.  See the Oracle concepts manual for a complete explanation: Data Integrity chapter, section regarding Concurrency Control, Indexes, and Foreign Keys.</Item>
	<Item InternalID="64">Contrary to popular belief, there is no such thing as a partial FK.  By definition the FK of a child table has to point to a row that exists in the parent or be null.  That means the entire key - and not just portions.  When you create a FK that has both mandatory and optional columns, then the database will not enforce that constraint when some columns are there and others are null.  See the Oracle concepts manual for a complete explanation: Data Integrity chapter, section regarding Nulls and Foreign Keys.</Item>
	<Item InternalID="65">By definition a unique key should have been a candidate primary key that was not chosen as the main or primary key.  As primary keys don't permit optional columns - then neither do the candidate unique keys not chosen as the primary.  See the Oracle concepts manual for a complete explanation: Data Integrity chapter, section regarding Combine UNIQUE Key and NOT NULL Integrity Constraints.</Item>
	<Item InternalID="38">When you define tables and/or columns using mixed case and/or spaces, then all references to these items in application must quote those references.  This is such a pain that it's generally to be avoided.  The only exceptions are third party applications that were built this way and/or databases moved from another platform such as MS SQL Server where mixed case names are more common.  In those cases you may be stuck with mixed case.</Item>
	<Item InternalID="160">CLIENT_RESULT_CACHE_LAG specifies the maximum time (in milliseconds) since the last round trip to the server, before which the OCI client query execute makes a round trip to get any database changes related to the queries cached on the client.  Setting this value too high can result in using stale data.</Item>
	<Item InternalID="161">CLIENT_RESULT_CACHE_SIZE specifies the maximum size of the client per-process result set cache (in bytes).  All OCI client processes inherit this maximum size.  Setting a nonzero value enables the client query cache feature.  This can be overridden by the client configuration parameter OCI_RESULT_CACHE_MAX_SIZE.  Since memory is cheap and plentiful on most client machines these days set the cache to at least 4 MB.</Item>
	<Item InternalID="162">DB_ULTRA_SAFE sets the default values for other parameters that control protection levels.  Better safe than sorry - so do not set to OFF.</Item>
	<Item InternalID="164">JAVA_JIT_ENABLED enables or disables the Just-in-Time (JIT) compiler for the Oracle Java Virtual Machine (OracleJVM) environment.  Since most application developers prefer to use the JVM outside the database, there's often no need to use Oracle's.</Item>
	<Item InternalID="165">JAVA_POOL_SIZE specifies (in bytes) the size of the Java pool, from which the Java memory manager allocates most Java state during runtime execution.  Since most application developers prefer to use the JVM outside the database, there's often no need to use Oracle's.</Item>
	<Item InternalID="166">Java session space is the memory that holds Java state from one database call to another.  Since most application developers prefer to use the JVM outside the database, there's often no need to use Oracle's.</Item>
	<Item InternalID="168">OPTIMIZER_USE_INVISIBLE_INDEXES enables or disables the use of invisible indexes.  FALSE means that invisible indexes will not be considered by the optimizer, but will still be maintained by DML operations.  If the indexes are truly invisible then the optimizer should generally not consider them.</Item>
	<Item InternalID="169">Disable this parameter unless you specifically want to take advantage of the recycle bin, otherwise objects that are dropped will still consume space unless the PURGE option is specified on DROP commands.</Item>
	<Item InternalID="170">RESULT_CACHE_MAX_RESULT specifies the percentage of RESULT_CACHE_MAX_SIZE that any single result can use.  If using this feature advisable not to set it below the default value.</Item>
	<Item InternalID="171">RESULT_CACHE_MODE specifies when a ResultCache operator is spliced into a query's execution plan.  FORCE means that the ResultCache operator is added to the root of all SELECT statements (provided that it is valid to do so).  This may be too wide a setting, it might be better to use use hints for those cases where it makes sense.</Item>
	<Item InternalID="172">RESULT_CACHE_REMOTE_EXPIRATION specifies the number of minutes that a result using a remote object is allowed to remain valid.  Setting this parameter to 0 implies that results using remote objects should not be cached.  Setting this parameter to a nonzero value can produce stale answers (for example, if the remote table used by a result is modified at the remote database).</Item>
	<Item InternalID="143">Oracle recommends at least three redo log groups and two members per group for redundancy (and thus availability).</Item>
	<Item InternalID="88"></Item><Item InternalID="49"></Item><Item InternalID="48"></Item><Item InternalID="47"></Item><Item InternalID="5"></Item></HealthCheckItems>