List:Commits« Previous MessageNext Message »
From:john.russell Date:April 6 2011 5:59am
Subject:svn commit - mysqldoc@oter02: r25753 - trunk/refman-5.6
View as plain text  
Author: jdrussel
Date: 2011-04-06 07:59:30 +0200 (Wed, 06 Apr 2011)
New Revision: 25753

Log:
Mainly removed a few references to obsolete have_innodb variable.
Not sure what change the innodb-* files are picking up.


Modified:
   trunk/refman-5.6/errors-problems.xml
   trunk/refman-5.6/innodb-compression.xml
   trunk/refman-5.6/innodb-information-schema.xml
   trunk/refman-5.6/se-innodb-core.xml


Modified: trunk/refman-5.6/errors-problems.xml
===================================================================
--- trunk/refman-5.6/errors-problems.xml	2011-04-06 05:10:52 UTC (rev 25752)
+++ trunk/refman-5.6/errors-problems.xml	2011-04-06 05:59:30 UTC (rev 25753)
Changed blocks: 2, Lines Added: 3, Lines Deleted: 22; 1428 bytes

@@ -4635,9 +4635,8 @@
         </para>
 
         <para>
-          You can check which storage engines your
-          <command>mysqld</command> server supports by using this
-          statement:
+          To check which storage engines your <command>mysqld</command>
+          server supports, use this statement:
         </para>
 
 <programlisting>

@@ -4645,27 +4644,9 @@
 </programlisting>
 
         <para>
-          You can also use the following statement, and check the value
-          of the variable that is associated with the storage engine in
-          which you are interested:
+          See <xref linkend="show-engines"/> for full details.
         </para>
 
-<programlisting>
-SHOW VARIABLES LIKE 'have_%';
-</programlisting>
-
-        <para>
-          For example, to determine whether the
-          <literal>InnoDB</literal> storage engine is available, check
-          the value of the <literal role="sysvar">have_innodb</literal>
-          variable.
-        </para>
-
-        <para>
-          See <xref linkend="show-engines"/>, and
-          <xref linkend="show-variables"/>.
-        </para>
-
       </section>
 
       <section id="deleting-from-related-tables">


Modified: trunk/refman-5.6/innodb-compression.xml
===================================================================
--- trunk/refman-5.6/innodb-compression.xml	2011-04-06 05:10:52 UTC (rev 25752)
+++ trunk/refman-5.6/innodb-compression.xml	2011-04-06 05:59:30 UTC (rev 25753)
Changed blocks: 4, Lines Added: 21, Lines Deleted: 19; 3809 bytes

@@ -296,8 +296,8 @@
       <para>
         When you import the dump file into a new database, if you want
         to have the tables re-created as they exist in the original
-        database, ensure the server has
-        the proper settings for the configuration parameters
+        database, ensure the server has the proper settings for the
+        configuration parameters
         <literal role="sysvar">innodb_file_format</literal> and
         <literal role="sysvar">innodb_file_per_table</literal>,
       </para>

@@ -523,12 +523,12 @@
 
       <para>
         When InnoDB strict mode is ON
-        (<literal>innodb_strict_mode=1</literal>), InnoDB
-        rejects invalid <literal>ROW_FORMAT</literal> or
+        (<literal>innodb_strict_mode=1</literal>), InnoDB rejects
+        invalid <literal>ROW_FORMAT</literal> or
         <literal>KEY_BLOCK_SIZE</literal> parameters. For compatibility
-        with earlier versions of InnoDB, strict mode is not
-        enabled by default; instead, InnoDB issues warnings (not errors)
-        for ignored invalid parameters.
+        with earlier versions of InnoDB, strict mode is not enabled by
+        default; instead, InnoDB issues warnings (not errors) for
+        ignored invalid parameters.
       </para>
 
       <para>

@@ -782,13 +782,12 @@
       environment with fast, multi-core CPUs. When a page of a
       compressed table is in memory, InnoDB often uses an additional 16K
       in the buffer pool for an uncompressed copy of the page. The
-      adaptive LRU algorithm attempts to balance
-      the use of memory between compressed and uncompressed pages to
-      take into account whether the workload is running in an I/O-bound
-      or CPU-bound manner. Still, a configuration with more memory
-      dedicated to the InnoDB buffer pool tends to run better when using
-      compressed tables than a configuration where memory is highly
-      constrained.
+      adaptive LRU algorithm attempts to balance the use of memory
+      between compressed and uncompressed pages to take into account
+      whether the workload is running in an I/O-bound or CPU-bound
+      manner. Still, a configuration with more memory dedicated to the
+      InnoDB buffer pool tends to run better when using compressed
+      tables than a configuration where memory is highly constrained.
     </para>
 
     <bridgehead id="innodb-compression-tuning-when-size">

@@ -1267,11 +1266,14 @@
     </para>
 
     <para>
-      Note that compressed tables use a different file format for the redo log and the per-table tablespaces than in
-      MySQL 5.1 and earlier. The
-      <link linkend="glos_mysql_enterprise_backup">MySQL Enterprise Backup</link> product supports this latest <link linkend="glos_barracuda">Barracuda</link> file format for
-      compressed InnoDB tables. The older InnoDB Hot Backup product can only
-      back up tables using the file format <link linkend="glos_antelope">Antelope</link>, and thus does not
+      Note that compressed tables use a different file format for the
+      redo log and the per-table tablespaces than in MySQL 5.1 and
+      earlier. The <link linkend="glos_mysql_enterprise_backup">MySQL
+      Enterprise Backup</link> product supports this latest
+      <link linkend="glos_barracuda">Barracuda</link> file format for
+      compressed InnoDB tables. The older InnoDB Hot Backup product can
+      only back up tables using the file format
+      <link linkend="glos_antelope">Antelope</link>, and thus does not
       support InnoDB tables that use compression.
     </para>
 


Modified: trunk/refman-5.6/innodb-information-schema.xml
===================================================================
--- trunk/refman-5.6/innodb-information-schema.xml	2011-04-06 05:10:52 UTC (rev 25752)
+++ trunk/refman-5.6/innodb-information-schema.xml	2011-04-06 05:59:30 UTC (rev 25753)
Changed blocks: 2, Lines Added: 14, Lines Deleted: 14; 2505 bytes

@@ -68,13 +68,12 @@
     </indexterm>
 
     <para>
-      Two new pairs of Information Schema tables
-      can give you some insight into how well
-      compression is working overall. One pair of tables contains
-      information about the number of compression operations and the
-      amount of time spent performing compression. Another pair of
-      tables contains information on the way memory is allocated for
-      compression.
+      Two new pairs of Information Schema tables can give you some
+      insight into how well compression is working overall. One pair of
+      tables contains information about the number of compression
+      operations and the amount of time spent performing compression.
+      Another pair of tables contains information on the way memory is
+      allocated for compression.
     </para>
 
     <section id="innodb-information-schema-innodb_cmp">

@@ -163,13 +162,14 @@
       </bridgehead>
 
       <para>
-        InnoDB uses a <link linkend="glos_buddy_allocator">buddy allocator</link> system to manage
-				memory allocated to <link linkend="glos_page_size">pages of various sizes</link>, from 1KB to 16KB. Each row of the two tables
-        described here corresponds to a single page size, except for
-        rows with <literal>PAGE_SIZE&lt;1024</literal>, which are
-        implementation artifacts. The smallest blocks
-        (<literal>PAGE_SIZE=64</literal> or
-        <literal>PAGE_SIZE=128</literal>, depending on the server
+        InnoDB uses a <link linkend="glos_buddy_allocator">buddy
+        allocator</link> system to manage memory allocated to
+        <link linkend="glos_page_size">pages of various sizes</link>,
+        from 1KB to 16KB. Each row of the two tables described here
+        corresponds to a single page size, except for rows with
+        <literal>PAGE_SIZE&lt;1024</literal>, which are implementation
+        artifacts. The smallest blocks (<literal>PAGE_SIZE=64</literal>
+        or <literal>PAGE_SIZE=128</literal>, depending on the server
         platform) are used for keeping track of compressed pages for
         which no uncompressed page has been allocated in the buffer
         pool. Other blocks of <literal>PAGE_SIZE&lt;1024</literal>


Modified: trunk/refman-5.6/se-innodb-core.xml
===================================================================
--- trunk/refman-5.6/se-innodb-core.xml	2011-04-06 05:10:52 UTC (rev 25752)
+++ trunk/refman-5.6/se-innodb-core.xml	2011-04-06 05:59:30 UTC (rev 25753)
Changed blocks: 10, Lines Added: 92, Lines Deleted: 69; 13112 bytes

@@ -310,9 +310,10 @@
       </bridgehead>
 
       <para>
-        If you use MyISAM tables but aren't tied to them for technical
-        reasons, you'll find many things more convenient when you use
-        InnoDB tables in MySQL 5.5:
+        If you use <literal>MyISAM</literal> tables but aren't tied to
+        them for technical reasons, you'll find many things more
+        convenient when you use <literal>InnoDB</literal> tables in
+        MySQL 5.5:
       </para>
 
       <itemizedlist>

@@ -322,32 +323,39 @@
             If your server crashes because of a hardware or software
             issue, regardless of what was happening in the database at
             the time, you don't need to do anything special after
-            restarting the database. InnoDB automatically finalizes any
-            changes that were committed before the time of the crash,
-            and undoes any changes that were in process but not
-            committed. Just restart and continue where you left off.
+            restarting the database. InnoDB
+            <link linkend="glos_crash_recovery">crash recovery</link>
+            automatically finalizes any changes that were committed
+            before the time of the crash, and undoes any changes that
+            were in process but not committed. Just restart and continue
+            where you left off. This process is now much faster than in
+            MySQL 5.1 and earlier.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            The InnoDB buffer pool caches table and index data as the
-            data is accessed. Frequently used data is processed directly
-            from memory. This cache applies to so many types of
-            information, and speeds up processing so much, that
-            dedicated database servers assign up to 80% of their
-            physical memory to the InnoDB buffer pool.
+            The InnoDB <link linkend="glos_buffer_pool">buffer
+            pool</link> caches table and index data as the data is
+            accessed. Frequently used data is processed directly from
+            memory. This cache applies to so many types of information,
+            and speeds up processing so much, that dedicated database
+            servers assign up to 80% of their physical memory to the
+            InnoDB buffer pool.
           </para>
         </listitem>
 
         <listitem>
           <para>
             If you split up related data into different tables, you can
-            set up foreign keys that enforce referential integrity.
-            Update or delete data, and the related data in other tables
-            is updated or deleted automatically. Try to insert data into
-            a secondary table without corresponding data in the primary
-            table, and it gets kicked out automatically.
+            set up <link linkend="glos_foreign_key">foreign keys</link>
+            that enforce
+            <link linkend="glos_referential_integrity">referential
+            integrity</link>. Update or delete data, and the related
+            data in other tables is updated or deleted automatically.
+            Try to insert data into a secondary table without
+            corresponding data in the primary table, and the bad data
+            gets kicked out automatically.
           </para>
         </listitem>
 

@@ -360,21 +368,25 @@
 
         <listitem>
           <para>
-            When you design your database with appropriate primary key
-            columns for each table, operations involving those columns
-            are automatically optimized. It is very fast to reference
-            the primary key columns in <literal>WHERE</literal> clauses,
+            When you design your database with appropriate
+            <link linkend="glos_primary_key">primary key</link> columns
+            for each table, operations involving those columns are
+            automatically optimized. It is very fast to reference the
+            primary key columns in <literal>WHERE</literal> clauses,
             <literal>ORDER BY</literal> clauses, <literal>GROUP
-            BY</literal> clauses, and join operations.
+            BY</literal> clauses, and
+            <link linkend="glos_join">join</link> operations.
           </para>
         </listitem>
 
         <listitem>
           <para>
             Inserts, updates, deletes are optimized by an automatic
-            mechanism called change buffering. InnoDB not only allows
-            concurrent read and write access to the same table, it
-            caches changed data to streamline disk I/O.
+            mechanism called
+            <link linkend="glos_change_buffering">change
+            buffering</link>. InnoDB not only allows concurrent read and
+            write access to the same table, it caches changed data to
+            streamline disk I/O.
           </para>
         </listitem>
 

@@ -382,9 +394,10 @@
           <para>
             Performance benefits are not limited to giant tables with
             long-running queries. When the same rows are accessed over
-            and over from a table, a feature called the Adaptive Hash
-            Index takes over to make these lookups even faster, as if
-            they came out of a hash table.
+            and over from a table, a feature called the
+            <link linkend="glos_adaptive_hash_index">Adaptive Hash
+            Index</link> takes over to make these lookups even faster,
+            as if they came out of a hash table.
           </para>
         </listitem>
 

@@ -404,18 +417,21 @@
 
         <listitem>
           <para>
-            Specify a primary key for every table using the most
-            frequently queried column or columns, or an auto-increment
+            Specify a <link linkend="glos_primary_key">primary
+            key</link> for every table using the most frequently queried
+            column or columns, or
+            an<link linkend="glos_auto_increment">auto-increment</link>
             value if there isn't an obvious primary key.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Embrace the idea of joins, where data is pulled from
-            multiple tables based on identical ID values from those
-            tables. For fast join performance, define foreign keys on
-            the join columns, and declare those columns with the same
+            Embrace the idea of <link linkend="glos_join">joins</link>,
+            where data is pulled from multiple tables based on identical
+            ID values from those tables. For fast join performance,
+            define <link linkend="glos_foreign_keys">foreign keys</link>
+            on the join columns, and declare those columns with the same
             datatype in each table. The foreign keys also propagate
             deletes or updates to all affected tables, and prevent
             insertion of data in a child table if the corresponding IDs

@@ -425,18 +441,21 @@
 
         <listitem>
           <para>
-            Turn off autocommit. Committing hundreds of times a second
-            puts a cap on performance (limited by the write speed of
-            your storage device).
+            Turn off <link linkend="glos_autocommit">autocommit</link>.
+            Committing hundreds of times a second puts a cap on
+            performance (limited by the write speed of your storage
+            device).
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Bracket sets of related changes, logical units of work, with
-            <literal>START TRANSACTION</literal> and
-            <literal>COMMIT</literal> statements. While you don't want
-            to commit too often, you also don't want to issue huge
+            Group sets of related <link linkend="glos_dml">DML</link>
+            operations into
+            <link linkend="glos_transactions">transactions</link>, by
+            bracketing them with <literal>START TRANSACTION</literal>
+            and <literal>COMMIT</literal> statements. While you don't
+            want to commit too often, you also don't want to issue huge
             batches of <literal>INSERT</literal>,
             <literal>UPDATE</literal>, or <literal>DELETE</literal>
             statements that run for hours without committing.

@@ -458,17 +477,20 @@
           <para>
             Enable the <literal>innodb_file_per_table</literal> option
             to put the data and indexes for individual tables into
-            separate files, instead of in a single giant system
-            tablespace. (This setting is required to use some of the
-            other features, such as table compression and fast
-            truncation.)
+            separate files, instead of in a single giant
+            <link linkend="glos_system_tablespace">system
+            tablespace</link>. (This setting is required to use some of
+            the other features, such as table
+            <link linkend="glos_compression">compression</link> and fast
+            <link linkend="glos_truncate">truncation</link>.)
           </para>
         </listitem>
 
         <listitem>
           <para>
             Evaluate whether your data and access patterns benefit from
-            the new InnoDB table compression feature
+            the new InnoDB table
+            <link linkend="glos_compression">compression</link> feature
             (<literal>ROW_FORMAT=COMPRESSED</literal> on the
             <literal>CREATE TABLE</literal> statement. You can compress
             InnoDB tables without sacrificing read/write capability.

@@ -646,25 +668,28 @@
 
         <listitem>
           <para>
-            Issue the command <literal>SHOW VARIABLES LIKE
-            'have_innodb';</literal> to confirm that InnoDB is available
-            at all. If the result is <literal>NO</literal>, you have a
-            mysqld binary that was compiled without InnoDB support and
-            you need to get a different one. If the result is
-            <literal>DISABLED</literal>, go back through your startup
-            options and configuration file and get rid of any
-            <literal>skip-innodb</literal> option.
+            Issue the command <literal>SHOW ENGINES;</literal> to see
+            all the different MySQL storage engines. Look for
+            <literal>DEFAULT</literal> in the InnoDB line.
           </para>
         </listitem>
 
         <listitem>
           <para>
-            Issue the command <literal>SHOW ENGINES;</literal> to see
-            all the different MySQL storage engines. Look for
-            <literal>DEFAULT</literal> in the InnoDB line.
+            If InnoDB is not present at all, you have a
+            <literal>mysqld</literal> binary that was compiled without
+            InnoDB support and you need to get a different one.
           </para>
         </listitem>
 
+        <listitem>
+          <para>
+            If InnoDB is present but disabled, go back through your
+            startup options and configuration file and get rid of any
+            <literal>skip-innodb</literal> option.
+          </para>
+        </listitem>
+
       </itemizedlist>
 
     </section>

@@ -11690,8 +11715,8 @@
             changed buffer pool blocks to disk. The default value is 20,
             and the range is 1-5000. This option is intended for tuning
             performance in combination with the setting
-            <literal>innodb_purge_threads=1</literal>, and typical users
-            do not need to modify it.
+            <literal>innodb_purge_threads=<replaceable>n</replaceable></literal>,
+            and typical users do not need to modify it.
           </para>
         </listitem>
 

@@ -11713,15 +11738,13 @@
 
           <para>
             The number of background threads devoted to the InnoDB purge
-            operation. Currently, can only be 0 (the default) or 1. The
-            default value of 0 signifies that the purge operation is
-            performed as part of the master thread. Running the purge
-            operation in its own thread can reduce internal contention
-            within InnoDB, improving scalability. Currently, the
-            performance gain might be minimal because the background
-            thread might encounter different kinds of contention than
-            before. This feature primarily lays the groundwork for
-            future performance work.
+            operation. The default value of 0 signifies that the purge
+            operation is performed as part of the master thread. A value
+            of 1 runs the purge operation in its own thread, which can
+            reduce internal contention within InnoDB, improving
+            scalability. Increasing the value to greater than 1 creates
+            that many separate purge threads, which can improve
+            efficiency on systems with extra CPU capacity.
           </para>
         </listitem>
 


Thread
svn commit - mysqldoc@oter02: r25753 - trunk/refman-5.6john.russell6 Apr