List:Commits« Previous MessageNext Message »
From:paul Date:January 10 2006 4:11am
Subject:svn commit - mysqldoc@docsrva: r748 - in trunk: . refman-4.1 refman-5.0 refman-5.1
View as plain text  
Author: paul
Date: 2006-01-10 05:11:12 +0100 (Tue, 10 Jan 2006)
New Revision: 748

Log:
 r6017@frost:  paul | 2006-01-09 21:11:26 -0600
 General revisions.


Modified:
   trunk/
   trunk/refman-4.1/innodb.xml
   trunk/refman-5.0/innodb.xml
   trunk/refman-5.1/innodb.xml


Property changes on: trunk
___________________________________________________________________
Name: svk:merge
   - b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6010
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994
   + b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:6017
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:1994

Modified: trunk/refman-4.1/innodb.xml
===================================================================
--- trunk/refman-4.1/innodb.xml	2006-01-10 01:11:11 UTC (rev 747)
+++ trunk/refman-4.1/innodb.xml	2006-01-10 04:11:12 UTC (rev 748)
@@ -1435,11 +1435,11 @@
           log files must be less than 4GB on 32-bit computers. The
           default is 5MB. Sensible values range from 1MB to
           1/<replaceable>N</replaceable>-th of the size of the buffer
-          pool, below, where <replaceable>N</replaceable> is the number
-          of log files in the group. The larger the value, the less
-          checkpoint flush activity is needed in the buffer pool, saving
-          disk I/O. But larger log files also mean that recovery is
-          slower in case of a crash.
+          pool, where <replaceable>N</replaceable> is the number of log
+          files in the group. The larger the value, the less checkpoint
+          flush activity is needed in the buffer pool, saving disk I/O.
+          But larger log files also mean that recovery is slower in case
+          of a crash.
         </para>
       </listitem>
 
@@ -1998,8 +1998,17 @@
         If you have <literal>UNIQUE</literal> constraints on secondary
         keys, starting from MySQL 3.23.52, you can speed up a table
         import by turning off the uniqueness checks temporarily during
-        the import session: <literal>SET UNIQUE_CHECKS=0;</literal> For
-        big tables, this saves a lot of disk I/O because
+        the import session:
+      </para>
+
+<programlisting>
+SET UNIQUE_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET UNIQUE_CHECKS=1;
+</programlisting>
+
+      <para>
+        For big tables, this saves a lot of disk I/O because
         <literal>InnoDB</literal> can then use its insert buffer to
         write secondary index records in a batch.
       </para>
@@ -2864,7 +2873,7 @@
 </programlisting>
 
     <para>
-      Suppose that this data file, over time, has grown to 988MB. Below
+      Suppose that this data file, over time, has grown to 988MB. Here
       is the configuration line after adding another auto-extending data
       file.
     </para>
@@ -3030,8 +3039,8 @@
 
     <para>
       To be able to recover your <literal>InnoDB</literal> database to
-      the present from the binary backup described above, you have to
-      run your MySQL server with binary logging turned on. Then you can
+      the present from the binary backup just described, you have to run
+      your MySQL server with binary logging turned on. Then you can
       apply the binary log to the backup database to achieve
       point-in-time recovery:
     </para>
@@ -3844,13 +3853,14 @@
 
           <para>
             In consistent reads, there is an important difference from
-            the previous isolation level: In this level, all consistent
-            reads within the same transaction read the same snapshot
-            established by the first read. This convention means that if
-            you issue several plain <literal>SELECT</literal> statements
-            within the same transaction, these <literal>SELECT</literal>
-            statements are consistent also with respect to each other.
-            See <xref linkend="innodb-consistent-read"/>.
+            the <literal>READ COMMITTED</literal> isolation level: All
+            consistent reads within the same transaction read the same
+            snapshot established by the first read. This convention
+            means that if you issue several plain
+            <literal>SELECT</literal> statements within the same
+            transaction, these <literal>SELECT</literal> statements are
+            consistent also with respect to each other. See
+            <xref linkend="innodb-consistent-read"/>.
           </para>
         </listitem>
 
@@ -3861,9 +3871,9 @@
 
           <para>
             This level is like <literal>REPEATABLE READ</literal>, but
-            all plain <literal>SELECT</literal> statements are
-            implicitly converted to <literal>SELECT ... LOCK IN SHARE
-            MODE</literal>.
+            <literal>InnoDB</literal> implicitly commits all plain
+            <literal>SELECT</literal> statements to <literal>SELECT ...
+            LOCK IN SHARE MODE</literal>.
           </para>
         </listitem>
 
@@ -3876,21 +3886,21 @@
       <title>&title-innodb-consistent-read;</title>
 
       <para>
-        A consistent read means that <literal>InnoDB</literal> uses its
+        A consistent read means that <literal>InnoDB</literal> uses
         multi-versioning to present to a query a snapshot of the
         database at a point in time. The query see the changes made by
-        exactly those transactions that committed before that point of
-        time, and no changes made by later or uncommitted transactions.
-        The exception to this rule is that the query sees the changes
-        made by the transaction itself that issues the query.
+        those transactions that committed before that point of time, and
+        no changes made by later or uncommitted transactions. The
+        exception to this rule is that the query sees the changes made
+        by earlier statements within the same transaction.
       </para>
 
       <para>
         If you are running with the default <literal>REPEATABLE
-        READ</literal> isolation level, then all consistent reads within
-        the same transaction read the snapshot established by the first
-        such read in that transaction. You can get a fresher snapshot
-        for your queries by committing the current transaction and after
+        READ</literal> isolation level, all consistent reads within the
+        same transaction read the snapshot established by the first such
+        read in that transaction. You can get a fresher snapshot for
+        your queries by committing the current transaction and after
         that issuing new queries.
       </para>
 
@@ -3909,14 +3919,14 @@
         Note that consistent read does not work over <literal>DROP
         TABLE</literal> and over <literal>ALTER TABLE</literal>.
         Consistent read does not work over <literal>DROP TABLE</literal>
-        because MySQL can't use table that has been dropped and
+        because MySQL can't use a table that has been dropped and
         <literal>InnoDB</literal> destroys the table. Consistent read
         does not work over <literal>ALTER TABLE</literal> because it is
-        executed inside of the transaction which creates a new table and
-        inserts rows from the old table to the new table. Now, when you
+        executed inside of the transaction that creates a new table and
+        inserts rows from the old table to the new table. When you
         reissue the consistent read, it will not see any rows in the new
         table, because they were inserted in a transaction that is not
-        visible in the snapshot that the consistent read reads.
+        visible in the snapshot read by the consistent read.
       </para>
 
     </section>
@@ -3940,7 +3950,7 @@
         in the table. Can you safely add the child row to table
         <literal>child</literal>? No, because it may happen that
         meanwhile some other user deletes the parent row from the table
-        <literal>parent</literal>, without you being aware of it.
+        <literal>parent</literal> without you being aware of it.
       </para>
 
       <para>
@@ -4005,7 +4015,7 @@
       </para>
 
       <para>
-        Please note that the above is merely an example of how
+        The preceding description is merely an example of how
         <literal>SELECT ... FOR UPDATE</literal> works. In MySQL, the
         specific task of generating a unique identifier actually can be
         accomplished using only a single access to the table:
@@ -4022,6 +4032,12 @@
         does not access any table.
       </para>
 
+      <para>
+        Locks set by <literal>IN SHARE MODE</literal> and <literal>FOR
+        UPDATE</literal> reads are released when the transaction is
+        committed or rolled back.
+      </para>
+
     </section>
 
     <section id="innodb-next-key-locking">
@@ -4063,10 +4079,10 @@
         in the gaps, a new row might meanwhile be inserted to the table.
         If you execute the same <literal>SELECT</literal> within the
         same transaction, you would see a new row in the result set
-        returned by the query. This is contrary the isolation principle
-        of transactions: A transaction should be able to run so that the
-        data it has read does not change during the transaction. If we
-        regard a set of rows as a data item, the new
+        returned by the query. This is contrary to the isolation
+        principle of transactions: A transaction should be able to run
+        so that the data it has read does not change during the
+        transaction. If we regard a set of rows as a data item, the new
         <quote>phantom</quote> child would violate this isolation
         principle.
       </para>
@@ -4823,8 +4839,8 @@
 </programlisting>
 
         <para>
-          This tip is valid for inserts into any storage engine, not
-          just <literal>InnoDB</literal>.
+          This tip is valid for inserts into any table, not just
+          <literal>InnoDB</literal> tables.
         </para>
       </listitem>
 
@@ -4838,6 +4854,8 @@
 
 <programlisting>
 SET UNIQUE_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET UNIQUE_CHECKS=1;
 </programlisting>
 
         <para>
@@ -4857,6 +4875,8 @@
 
 <programlisting>
 SET FOREIGN_KEY_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET FOREIGN_KEY_CHECKS=1;
 </programlisting>
 
         <para>
@@ -4866,7 +4886,7 @@
 
       <listitem>
         <para>
-          If you often have recurring queries to tables that are not
+          If you often have recurring queries for tables that are not
           updated frequently, use the query cache available as of MySQL
           4.0:
         </para>
@@ -4912,8 +4932,8 @@
 
       <para>
         Another way to use <literal>InnoDB</literal> Monitors is to let
-        them continuously write data to the standard output of the
-        server <command>mysqld</command>. In this case, no output is
+        them periodically write data to the standard output of the
+        <command>mysqld</command> server. In this case, no output is
         sent to clients. When switched on, <literal>InnoDB</literal>
         Monitors print data about every 15 seconds. Server output
         usually is directed to the <filename>.err</filename> log in the
@@ -4925,7 +4945,7 @@
       </para>
 
       <para>
-        Monitor output includes information of the following types:
+        Monitor output includes the following types of information:
       </para>
 
       <itemizedlist>
@@ -4976,7 +4996,7 @@
       </para>
 
 <programlisting>
-CREATE TABLE innodb_monitor(a INT) TYPE=InnoDB;
+CREATE TABLE innodb_monitor (a INT) TYPE=InnoDB;
 </programlisting>
 
       <para>
@@ -4993,12 +5013,12 @@
         MySQL's SQL parser: The only things that matter are the table
         name <literal>innodb_monitor</literal> and that it be an
         <literal>InnoDB</literal> table. The structure of the table is
-        not relevant at all for the <command><literal>InnoDB</literal>
-        Monitor</command>. If you shut down the server when the monitor
-        is running, and you want to start the monitor again, you must
-        drop the table before you can issue a new <literal>CREATE
-        TABLE</literal> statement to start the monitor. This syntax may
-        change in a future release.
+        not relevant at all for the <literal>InnoDB</literal> Monitor.
+        (This syntax may If you shut down the server, the monitor does
+        not restart automatically when you restart the server. You must
+        drop the monitor table and issue a new <literal>CREATE
+        TABLE</literal> statement to start the monitor. change in a
+        future release.)
       </para>
 
       <para>
@@ -5015,8 +5035,7 @@
       </para>
 
       <para>
-        A sample of <command><literal>InnoDB</literal> Monitor</command>
-        output:
+        A sample of <literal>InnoDB</literal> Monitor output:
       </para>
 
 <programlisting>
@@ -5031,69 +5050,73 @@
 SEMAPHORES
 ----------
 OS WAIT ARRAY INFO: reservation count 413452, signal count 378357
---Thread 32782 has waited at btr0sea.c line 1477 for 0.00 seconds the semaphore:
-X-lock on RW-latch at 41a28668 created in file btr0sea.c line 135
+--Thread 32782 has waited at btr0sea.c line 1477 for 0.00 seconds the
+semaphore: X-lock on RW-latch at 41a28668 created in file btr0sea.c line 135
 a writer (thread id 32782) has reserved it in mode wait exclusive
 number of readers 1, waiters flag 1
 Last time read locked in file btr0sea.c line 731
 Last time write locked in file btr0sea.c line 1347
 Mutex spin waits 0, rounds 0, OS waits 0
-RW-shared spins 108462, OS waits 37964; RW-excl spins 681824, OS waits 375485
+RW-shared spins 108462, OS waits 37964; RW-excl spins 681824, OS waits
+375485
 ------------------------
 LATEST FOREIGN KEY ERROR
 ------------------------
 030709 13:00:59 Transaction:
-TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831 inser
-ting
+TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831
+inserting
 15 lock struct(s), heap size 2496, undo log entries 9
 MySQL thread id 25, query id 4668733 localhost heikki update
 insert into ibtest11a (D, B, C) values (5, 'khDk' ,'khDk')
 Foreign key constraint fails for table test/ibtest11a:
 ,
-  CONSTRAINT `0_219242` FOREIGN KEY (`A`, `D`) REFERENCES `ibtest11b` (`A`, `D`)
- ON DELETE CASCADE ON UPDATE CASCADE
+  CONSTRAINT `0_219242` FOREIGN KEY (`A`, `D`) REFERENCES `ibtest11b` (`A`,
+  `D`) ON DELETE CASCADE ON UPDATE CASCADE
 Trying to add in child table, in index PRIMARY tuple:
- 0: len 4; hex 80000101; asc ....;; 1: len 4; hex 80000005; asc ....;; 2: len 4;
- hex 6b68446b; asc khDk;; 3: len 6; hex 0000114e0edc; asc ...N..;; 4: len 7; hex
- 00000000c3e0a7; asc .......;; 5: len 4; hex 6b68446b; asc khDk;;
+ 0: len 4; hex 80000101; asc ....;; 1: len 4; hex 80000005; asc ....;; 2:
+ len 4; hex 6b68446b; asc khDk;; 3: len 6; hex 0000114e0edc; asc ...N..;; 4:
+ len 7; hex 00000000c3e0a7; asc .......;; 5: len 4; hex 6b68446b; asc khDk;;
 But in parent table test/ibtest11b, in index PRIMARY,
 the closest match we can find is record:
-RECORD: info bits 0 0: len 4; hex 8000015b; asc ...[;; 1: len 4; hex 80000005; a
-sc ....;; 2: len 3; hex 6b6864; asc khd;; 3: len 6; hex 0000111ef3eb; asc ......
-;; 4: len 7; hex 800001001e0084; asc .......;; 5: len 3; hex 6b6864; asc khd;;
+RECORD: info bits 0 0: len 4; hex 8000015b; asc ...[;; 1: len 4; hex
+80000005; asc ....;; 2: len 3; hex 6b6864; asc khd;; 3: len 6; hex
+0000111ef3eb; asc ......;; 4: len 7; hex 800001001e0084; asc .......;; 5:
+len 3; hex 6b6864; asc khd;;
 ------------------------
 LATEST DETECTED DEADLOCK
 ------------------------
 030709 12:59:58
 *** (1) TRANSACTION:
-TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185, OS thread id 30733 inser
-ting
+TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185, OS thread id 30733
+inserting
 LOCK WAIT 3 lock struct(s), heap size 320, undo log entries 146
 MySQL thread id 21, query id 4553379 localhost heikki update
-INSERT INTO alex1 VALUES(86, 86, 794,'aA35818','bb','c79166','d4766t','e187358f'
-,'g84586','h794',date_format('2001-04-03 12:54:22','%Y-%m-%d %H:%i'),7
+INSERT INTO alex1 VALUES(86, 86, 794,'aA35818','bb','c79166','d4766t',
+'e187358f','g84586','h794',date_format('2001-04-03 12:54:22','%Y-%m-%d
+%H:%i'),7
 *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290252780 lock mode S waiting
-Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138; asc a
-a35818;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290252780 lock mode S waiting
+Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;
+asc aa35818;; 1:
 *** (2) TRANSACTION:
-TRANSACTION 0 290251546, ACTIVE 2 sec, process no 3190, OS thread id 32782 inser
-ting
+TRANSACTION 0 290251546, ACTIVE 2 sec, process no 3190, OS thread id 32782
+inserting
 130 lock struct(s), heap size 11584, undo log entries 437
 MySQL thread id 23, query id 4554396 localhost heikki update
-REPLACE INTO alex1 VALUES(NULL, 32, NULL,'aa3572','','c3572','d6012t','', NULL,'
-h396', NULL, NULL, 7.31,7.31,7.31,200)
+REPLACE INTO alex1 VALUES(NULL, 32, NULL,'aa3572','','c3572','d6012t','',
+NULL,'h396', NULL, NULL, 7.31,7.31,7.31,200)
 *** (2) HOLDS THE LOCK(S):
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290251546 lock_mode X locks rec but not gap
-Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138; asc a
-a35818;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290251546 lock_mode X locks rec but not gap
+Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;
+asc aa35818;; 1:
 *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290251546 lock_mode X locks gap before rec insert intention waiting
-Record lock, heap no 82 RECORD: info bits 0 0: len 7; hex 61613335373230; asc aa
-35720;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290251546 lock_mode X locks gap before rec insert intention
+waiting
+Record lock, heap no 82 RECORD: info bits 0 0: len 7; hex 61613335373230;
+asc aa35720;; 1:
 *** WE ROLL BACK TRANSACTION (1)
 ------------
 TRANSACTIONS
@@ -5105,45 +5128,48 @@
 ---TRANSACTION 0 0, not started, process no 3491, OS thread id 42002
 MySQL thread id 32, query id 4668737 localhost heikki
 show innodb status
----TRANSACTION 0 290328384, ACTIVE 0 sec, process no 3205, OS thread id 38929 in
-serting
+---TRANSACTION 0 290328384, ACTIVE 0 sec, process no 3205, OS thread id
+38929 inserting
 1 lock struct(s), heap size 320
 MySQL thread id 29, query id 4668736 localhost heikki update
-insert into speedc values (1519229,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjgjlhh
-gghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjfh
----TRANSACTION 0 290328383, ACTIVE 0 sec, process no 3180, OS thread id 28684 co
-mmitting
+insert into speedc values (1519229,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjg
+jlhhgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjfh
+---TRANSACTION 0 290328383, ACTIVE 0 sec, process no 3180, OS thread id
+28684 committing
 1 lock struct(s), heap size 320, undo log entries 1
 MySQL thread id 19, query id 4668734 localhost heikki update
-insert into speedcm values (1603393,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjgjlh
-hgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjf
----TRANSACTION 0 290328327, ACTIVE 0 sec, process no 3200, OS thread id 36880 st
-arting index read
+insert into speedcm values (1603393,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgj
+gjlhhgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjf
+---TRANSACTION 0 290328327, ACTIVE 0 sec, process no 3200, OS thread id
+36880 starting index read
 LOCK WAIT 2 lock struct(s), heap size 320
-MySQL thread id 27, query id 4668644 localhost heikki Searching rows for update
+MySQL thread id 27, query id 4668644 localhost heikki Searching rows for
+update
 update ibtest11a set B = 'kHdkkkk' where A = 89572
 ------- TRX HAS BEEN WAITING 0 SEC FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 65556 n bits 232 table test/ibtest11a index PRIM
-ARY trx id 0 290328327 lock_mode X waiting
-Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00; asc
- supremum.;;
+RECORD LOCKS space id 0 page no 65556 n bits 232 table test/ibtest11a index
+PRIMARY trx id 0 290328327 lock_mode X waiting
+Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00;
+asc supremum.;;
 ------------------
----TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831 ro
-llback of SQL statement
+---TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id
+34831 rollback of SQL statement
 ROLLING BACK 14 lock struct(s), heap size 2496, undo log entries 9
 MySQL thread id 25, query id 4668733 localhost heikki update
 insert into ibtest11a (D, B, C) values (5, 'khDk' ,'khDk')
----TRANSACTION 0 290327208, ACTIVE 1 sec, process no 3190, OS thread id 32782
+---TRANSACTION 0 290327208, ACTIVE 1 sec, process no 3190, OS thread id
+32782
 58 lock struct(s), heap size 5504, undo log entries 159
 MySQL thread id 23, query id 4668732 localhost heikki update
-REPLACE INTO alex1 VALUES(86, 46, 538,'aa95666','bb','c95666','d9486t','e200498f
-','g86814','h538',date_format('2001-04-03 12:54:22','%Y-%m-%d %H:%i'),
----TRANSACTION 0 290323325, ACTIVE 3 sec, process no 3185, OS thread id 30733 in
-serting
+REPLACE INTO alex1 VALUES(86, 46, 538,'aa95666','bb','c95666','d9486t',
+'e200498f','g86814','h538',date_format('2001-04-03 12:54:22','%Y-%m-%d
+%H:%i'),
+---TRANSACTION 0 290323325, ACTIVE 3 sec, process no 3185, OS thread id
+30733 inserting
 4 lock struct(s), heap size 1024, undo log entries 165
 MySQL thread id 21, query id 4668735 localhost heikki update
-INSERT INTO alex1 VALUES(NULL, 49, NULL,'aa42837','','c56319','d1719t','', NULL,
-'h321', NULL, NULL, 7.31,7.31,7.31,200)
+INSERT INTO alex1 VALUES(NULL, 49, NULL,'aa42837','','c56319','d1719t','',
+NULL,'h321', NULL, NULL, 7.31,7.31,7.31,200)
 --------
 FILE I/O
 --------
@@ -5194,7 +5220,6 @@
 ----------------------------
 END OF INNODB MONITOR OUTPUT
 ============================
-1 row in set (0.05 sec)
 </programlisting>
 
       <para>
@@ -5206,8 +5231,8 @@
         <listitem>
           <para>
             If the <literal>TRANSACTIONS</literal> section reports lock
-            waits, your application may have lock contention. The output
-            can also help to trace the reasons for transaction
+            waits, your applications may have lock contention. The
+            output can also help to trace the reasons for transaction
             deadlocks.
           </para>
         </listitem>
@@ -5220,7 +5245,7 @@
             semaphore. A large number of threads waiting for semaphores
             may be a result of disk I/O, or contention problems inside
             <literal>InnoDB</literal>. Contention can be due to heavy
-            parallelism of queries, or problems in operating system
+            parallelism of queries or problems in operating system
             thread scheduling. Setting
             <literal>innodb_thread_concurrency</literal> smaller than
             the default value can help in such situations.
@@ -5250,16 +5275,15 @@
         diagnostic output to stderr or files instead of stdout or
         fixed-size memory buffers, to avoid potential buffer overflow
         errors. As a side effect, the output of <literal>SHOW INNODB
-        STATUS</literal> is written to a status file every fifteen
-        seconds. The name of the file is
+        STATUS</literal> is written to a status file in the MySQL data
+        directory every fifteen seconds. The name of the file is
         <filename>innodb_status.<replaceable>pid</replaceable></filename>,
         where <replaceable>pid</replaceable> is the server process ID.
-        This file is created in the MySQL data directory.
         <literal>InnoDB</literal> removes the file for a normal
         shutdown. If abnormal shutdowns have occurred, instances of
         these status files may be present and must be removed manually.
         Before removing them, you might want to examine them to see if
-        they contain useful information to the cause of abnormal
+        they contain useful information about the cause of abnormal
         shutdowns. Beginning with MySQL 4.0.21, the
         <filename>innodb_status.<replaceable>pid</replaceable></filename>
         file is created only if the configuration option
@@ -5275,8 +5299,8 @@
     <title>&title-innodb-multi-versioning;</title>
 
     <para>
-      Because <literal>InnoDB</literal> is a multi-versioned database,
-      it must keep information about old versions of rows in the
+      Because <literal>InnoDB</literal> is a multi-versioned storage
+      engine, it must keep information about old versions of rows in the
       tablespace. This information is stored in a data structure called
       a <firstterm>rollback segment</firstterm> (after an analogous data
       structure in Oracle).
@@ -5305,7 +5329,7 @@
       Undo logs in the rollback segment are divided into insert and
       update undo logs. Insert undo logs are needed only in transaction
       rollback and can be discarded as soon as the transaction commits.
-      Update undo logs are used also in consistent reads, and they can
+      Update undo logs are used also in consistent reads, but they can
       be discarded only after there is no transaction present for which
       <literal>InnoDB</literal> has assigned a snapshot that in a
       consistent read could need the information in the update undo log
@@ -5314,7 +5338,7 @@
 
     <para>
       You must remember to commit your transactions regularly, including
-      those transactions that only issue consistent reads. Otherwise,
+      those transactions that issue only consistent reads. Otherwise,
       <literal>InnoDB</literal> cannot discard data from the update undo
       logs, and the rollback segment may grow too big, filling up your
       tablespace.
@@ -5347,10 +5371,10 @@
       the table would carry just 10 MB of useful data, it may grow to
       occupy 10 GB with all the dead rows. In such a case, it would be
       good to throttle new row operations, and allocate more resources
-      for the purge thread. Starting with MySQL 4.0.22 and 4.1.6, there
-      is a startup option and settable global variable
-      <literal>innodb_max_purge_lag</literal> for exactly this purpose.
-      See <xref linkend="innodb-parameters"/>, for more information.
+      for the purge thread. Starting with MySQL 4.0.22 and 4.1.6, the
+      <literal>innodb_max_purge_lag</literal> system variable exists for
+      exactly this purpose. See <xref linkend="innodb-parameters"/>, for
+      more information.
     </para>
 
   </section>
@@ -5363,8 +5387,8 @@
       MySQL stores its data dictionary information for tables in
       <filename>.frm</filename> files in database directories. This is
       true for all MySQL storage engines. But every
-      <literal>InnoDB</literal> table also has its own entry in
-      <literal>InnoDB</literal> internal data dictionaries inside the
+      <literal>InnoDB</literal> table also has its own entry in the
+      <literal>InnoDB</literal> internal data dictionary inside the
       tablespace. When MySQL drops a table or a database, it has to
       delete both an <filename>.frm</filename> file or files, and the
       corresponding entries inside the <literal>InnoDB</literal> data
@@ -5392,7 +5416,7 @@
       by the row ID that <literal>InnoDB</literal> assigns to the rows
       in such a table. The row ID is a 6-byte field that increases
       monotonically as new rows are inserted. Thus, the rows ordered by
-      the row ID are physically in the insertion order.
+      the row ID are physically in insertion order.
     </para>
 
     <para>
@@ -5400,8 +5424,8 @@
       row data is on the same page where the index search leads. If a
       table is large, the clustered index architecture often saves a
       disk I/O when compared to the traditional solution. (In many
-      databases, the data is traditionally stored on a different page
-      from the index record.)
+      database systems, data storage uses a different page from the
+      index record.)
     </para>
 
     <para>
@@ -5424,7 +5448,7 @@
       <title>&title-innodb-physical-structure;</title>
 
       <para>
-        All indexes in <literal>InnoDB</literal> are B-trees where the
+        All <literal>InnoDB</literal> indexes are B-trees where the
         index records are stored in the leaf pages of the tree. The
         default size of an index page is 16KB. When new records are
         inserted, <literal>InnoDB</literal> tries to leave 1/16 of the
@@ -5448,7 +5472,7 @@
       <title>&title-innodb-insert-buffering;</title>
 
       <para>
-        It is a common situation in a database application that the
+        It is a common situation in database applications that the
         primary key is a unique identifier and new rows are inserted in
         the ascending order of the primary key. Thus, the insertions to
         the clustered index do not require random reads from a disk.
@@ -7257,9 +7281,9 @@
         contains the character &lsquo;<literal>#</literal>&rsquo; if you
         enclose the name within backticks. Thus, you can drop such an
         orphaned table like any other orphaned table using the method
-        described above. Note that to copy or rename a file in the Unix
-        shell, you need to put the file name in double quotes if the
-        file name contains &lsquo;<literal>#</literal>&rsquo;.
+        described earlier. Note that to copy or rename a file in the
+        Unix shell, you need to put the file name in double quotes if
+        the file name contains &lsquo;<literal>#</literal>&rsquo;.
       </para>
 
       <para>

Modified: trunk/refman-5.0/innodb.xml
===================================================================
--- trunk/refman-5.0/innodb.xml	2006-01-10 01:11:11 UTC (rev 747)
+++ trunk/refman-5.0/innodb.xml	2006-01-10 04:11:12 UTC (rev 748)
@@ -1435,11 +1435,11 @@
           log files must be less than 4GB on 32-bit computers. The
           default is 5MB. Sensible values range from 1MB to
           1/<replaceable>N</replaceable>-th of the size of the buffer
-          pool, below, where <replaceable>N</replaceable> is the number
-          of log files in the group. The larger the value, the less
-          checkpoint flush activity is needed in the buffer pool, saving
-          disk I/O. But larger log files also mean that recovery is
-          slower in case of a crash.
+          pool, where <replaceable>N</replaceable> is the number of log
+          files in the group. The larger the value, the less checkpoint
+          flush activity is needed in the buffer pool, saving disk I/O.
+          But larger log files also mean that recovery is slower in case
+          of a crash.
         </para>
       </listitem>
 
@@ -2005,13 +2005,21 @@
         If you have <literal>UNIQUE</literal> constraints on secondary
         keys, you can speed up a table import by turning off the
         uniqueness checks temporarily during the import session:
-        <literal>SET UNIQUE_CHECKS=0;</literal>. For big tables, this
-        saves a lot of disk I/O because <literal>InnoDB</literal> can
-        then use its insert buffer to write secondary index records as a
-        batch.
       </para>
 
+<programlisting>
+SET UNIQUE_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET UNIQUE_CHECKS=1;
+</programlisting>
+
       <para>
+        For big tables, this saves a lot of disk I/O because
+        <literal>InnoDB</literal> can then use its insert buffer to
+        write secondary index records as a batch.
+      </para>
+
+      <para>
         To get better control over the insertion process, it might be
         good to insert big tables in pieces:
       </para>
@@ -2827,7 +2835,7 @@
 </programlisting>
 
     <para>
-      Suppose that this data file, over time, has grown to 988MB. Below
+      Suppose that this data file, over time, has grown to 988MB. Here
       is the configuration line after adding another auto-extending data
       file.
     </para>
@@ -2993,8 +3001,8 @@
 
     <para>
       To be able to recover your <literal>InnoDB</literal> database to
-      the present from the binary backup described above, you have to
-      run your MySQL server with binary logging turned on. Then you can
+      the present from the binary backup just described, you have to run
+      your MySQL server with binary logging turned on. Then you can
       apply the binary log to the backup database to achieve
       point-in-time recovery:
     </para>
@@ -3788,13 +3796,14 @@
 
           <para>
             In consistent reads, there is an important difference from
-            the previous isolation level: In this level, all consistent
-            reads within the same transaction read the same snapshot
-            established by the first read. This convention means that if
-            you issue several plain <literal>SELECT</literal> statements
-            within the same transaction, these <literal>SELECT</literal>
-            statements are consistent also with respect to each other.
-            See <xref linkend="innodb-consistent-read"/>.
+            the <literal>READ COMMITTED</literal> isolation level: All
+            consistent reads within the same transaction read the same
+            snapshot established by the first read. This convention
+            means that if you issue several plain
+            <literal>SELECT</literal> statements within the same
+            transaction, these <literal>SELECT</literal> statements are
+            consistent also with respect to each other. See
+            <xref linkend="innodb-consistent-read"/>.
           </para>
         </listitem>
 
@@ -3805,9 +3814,9 @@
 
           <para>
             This level is like <literal>REPEATABLE READ</literal>, but
-            all plain <literal>SELECT</literal> statements are
-            implicitly converted to <literal>SELECT ... LOCK IN SHARE
-            MODE</literal>.
+            <literal>InnoDB</literal> implicitly commits all plain
+            <literal>SELECT</literal> statements to <literal>SELECT ...
+            LOCK IN SHARE MODE</literal>.
           </para>
         </listitem>
 
@@ -3820,21 +3829,21 @@
       <title>&title-innodb-consistent-read;</title>
 
       <para>
-        A consistent read means that <literal>InnoDB</literal> uses its
+        A consistent read means that <literal>InnoDB</literal> uses
         multi-versioning to present to a query a snapshot of the
         database at a point in time. The query see the changes made by
-        exactly those transactions that committed before that point of
-        time, and no changes made by later or uncommitted transactions.
-        The exception to this rule is that the query sees the changes
-        made by the transaction itself that issues the query.
+        those transactions that committed before that point of time, and
+        no changes made by later or uncommitted transactions. The
+        exception to this rule is that the query sees the changes made
+        by earlier statements within the same transaction.
       </para>
 
       <para>
         If you are running with the default <literal>REPEATABLE
-        READ</literal> isolation level, then all consistent reads within
-        the same transaction read the snapshot established by the first
-        such read in that transaction. You can get a fresher snapshot
-        for your queries by committing the current transaction and after
+        READ</literal> isolation level, all consistent reads within the
+        same transaction read the snapshot established by the first such
+        read in that transaction. You can get a fresher snapshot for
+        your queries by committing the current transaction and after
         that issuing new queries.
       </para>
 
@@ -3853,14 +3862,14 @@
         Note that consistent read does not work over <literal>DROP
         TABLE</literal> and over <literal>ALTER TABLE</literal>.
         Consistent read does not work over <literal>DROP TABLE</literal>
-        because MySQL can't use table that has been dropped and
+        because MySQL can't use a table that has been dropped and
         <literal>InnoDB</literal> destroys the table. Consistent read
         does not work over <literal>ALTER TABLE</literal> because it is
-        executed inside of the transaction which creates a new table and
-        inserts rows from the old table to the new table. Now, when you
+        executed inside of the transaction that creates a new table and
+        inserts rows from the old table to the new table. When you
         reissue the consistent read, it will not see any rows in the new
         table, because they were inserted in a transaction that is not
-        visible in the snapshot that the consistent read reads.
+        visible in the snapshot read by the consistent read.
       </para>
 
     </section>
@@ -3884,7 +3893,7 @@
         in the table. Can you safely add the child row to table
         <literal>child</literal>? No, because it may happen that
         meanwhile some other user deletes the parent row from the table
-        <literal>parent</literal>, without you being aware of it.
+        <literal>parent</literal> without you being aware of it.
       </para>
 
       <para>
@@ -3949,7 +3958,7 @@
       </para>
 
       <para>
-        Please note that the above is merely an example of how
+        The preceding description is merely an example of how
         <literal>SELECT ... FOR UPDATE</literal> works. In MySQL, the
         specific task of generating a unique identifier actually can be
         accomplished using only a single access to the table:
@@ -3966,6 +3975,12 @@
         does not access any table.
       </para>
 
+      <para>
+        Locks set by <literal>IN SHARE MODE</literal> and <literal>FOR
+        UPDATE</literal> reads are released when the transaction is
+        committed or rolled back.
+      </para>
+
     </section>
 
     <section id="innodb-next-key-locking">
@@ -4007,10 +4022,10 @@
         in the gaps, a new row might meanwhile be inserted to the table.
         If you execute the same <literal>SELECT</literal> within the
         same transaction, you would see a new row in the result set
-        returned by the query. This is contrary the isolation principle
-        of transactions: A transaction should be able to run so that the
-        data it has read does not change during the transaction. If we
-        regard a set of rows as a data item, the new
+        returned by the query. This is contrary to the isolation
+        principle of transactions: A transaction should be able to run
+        so that the data it has read does not change during the
+        transaction. If we regard a set of rows as a data item, the new
         <quote>phantom</quote> child would violate this isolation
         principle.
       </para>
@@ -4758,8 +4773,8 @@
 </programlisting>
 
         <para>
-          This tip is valid for inserts into any storage engine, not
-          just <literal>InnoDB</literal>.
+          This tip is valid for inserts into any table, not just
+          <literal>InnoDB</literal> tables.
         </para>
       </listitem>
 
@@ -4772,6 +4787,8 @@
 
 <programlisting>
 SET UNIQUE_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET UNIQUE_CHECKS=1;
 </programlisting>
 
         <para>
@@ -4790,6 +4807,8 @@
 
 <programlisting>
 SET FOREIGN_KEY_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET FOREIGN_KEY_CHECKS=1;
 </programlisting>
 
         <para>
@@ -4799,7 +4818,7 @@
 
       <listitem>
         <para>
-          If you often have recurring queries to tables that are not
+          If you often have recurring queries for tables that are not
           updated frequently, use the query cache:
         </para>
 
@@ -4837,8 +4856,8 @@
 
       <para>
         Another way to use <literal>InnoDB</literal> Monitors is to let
-        them continuously write data to the standard output of the
-        server <command>mysqld</command>. In this case, no output is
+        them periodically write data to the standard output of the
+        <command>mysqld</command> server. In this case, no output is
         sent to clients. When switched on, <literal>InnoDB</literal>
         Monitors print data about every 15 seconds. Server output
         usually is directed to the <filename>.err</filename> log in the
@@ -4850,7 +4869,7 @@
       </para>
 
       <para>
-        Monitor output includes information of the following types:
+        Monitor output includes the following types of information:
       </para>
 
       <itemizedlist>
@@ -4901,7 +4920,7 @@
       </para>
 
 <programlisting>
-CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB;
+CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;
 </programlisting>
 
       <para>
@@ -4918,12 +4937,12 @@
         MySQL's SQL parser: The only things that matter are the table
         name <literal>innodb_monitor</literal> and that it be an
         <literal>InnoDB</literal> table. The structure of the table is
-        not relevant at all for the <command><literal>InnoDB</literal>
-        Monitor</command>. If you shut down the server when the monitor
-        is running, and you want to start the monitor again, you must
-        drop the table before you can issue a new <literal>CREATE
-        TABLE</literal> statement to start the monitor. This syntax may
-        change in a future release.
+        not relevant at all for the <literal>InnoDB</literal> Monitor.
+        (This syntax may If you shut down the server, the monitor does
+        not restart automatically when you restart the server. You must
+        drop the monitor table and issue a new <literal>CREATE
+        TABLE</literal> statement to start the monitor. change in a
+        future release.)
       </para>
 
       <para>
@@ -4939,8 +4958,7 @@
       </para>
 
       <para>
-        A sample of <command><literal>InnoDB</literal> Monitor</command>
-        output:
+        A sample of <literal>InnoDB</literal> Monitor output:
       </para>
 
 <programlisting>
@@ -4955,69 +4973,73 @@
 SEMAPHORES
 ----------
 OS WAIT ARRAY INFO: reservation count 413452, signal count 378357
---Thread 32782 has waited at btr0sea.c line 1477 for 0.00 seconds the semaphore:
-X-lock on RW-latch at 41a28668 created in file btr0sea.c line 135
+--Thread 32782 has waited at btr0sea.c line 1477 for 0.00 seconds the
+semaphore: X-lock on RW-latch at 41a28668 created in file btr0sea.c line 135
 a writer (thread id 32782) has reserved it in mode wait exclusive
 number of readers 1, waiters flag 1
 Last time read locked in file btr0sea.c line 731
 Last time write locked in file btr0sea.c line 1347
 Mutex spin waits 0, rounds 0, OS waits 0
-RW-shared spins 108462, OS waits 37964; RW-excl spins 681824, OS waits 375485
+RW-shared spins 108462, OS waits 37964; RW-excl spins 681824, OS waits
+375485
 ------------------------
 LATEST FOREIGN KEY ERROR
 ------------------------
 030709 13:00:59 Transaction:
-TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831 inser
-ting
+TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831
+inserting
 15 lock struct(s), heap size 2496, undo log entries 9
 MySQL thread id 25, query id 4668733 localhost heikki update
 insert into ibtest11a (D, B, C) values (5, 'khDk' ,'khDk')
 Foreign key constraint fails for table test/ibtest11a:
 ,
-  CONSTRAINT `0_219242` FOREIGN KEY (`A`, `D`) REFERENCES `ibtest11b` (`A`, `D`)
- ON DELETE CASCADE ON UPDATE CASCADE
+  CONSTRAINT `0_219242` FOREIGN KEY (`A`, `D`) REFERENCES `ibtest11b` (`A`,
+  `D`) ON DELETE CASCADE ON UPDATE CASCADE
 Trying to add in child table, in index PRIMARY tuple:
- 0: len 4; hex 80000101; asc ....;; 1: len 4; hex 80000005; asc ....;; 2: len 4;
- hex 6b68446b; asc khDk;; 3: len 6; hex 0000114e0edc; asc ...N..;; 4: len 7; hex
- 00000000c3e0a7; asc .......;; 5: len 4; hex 6b68446b; asc khDk;;
+ 0: len 4; hex 80000101; asc ....;; 1: len 4; hex 80000005; asc ....;; 2:
+ len 4; hex 6b68446b; asc khDk;; 3: len 6; hex 0000114e0edc; asc ...N..;; 4:
+ len 7; hex 00000000c3e0a7; asc .......;; 5: len 4; hex 6b68446b; asc khDk;;
 But in parent table test/ibtest11b, in index PRIMARY,
 the closest match we can find is record:
-RECORD: info bits 0 0: len 4; hex 8000015b; asc ...[;; 1: len 4; hex 80000005; a
-sc ....;; 2: len 3; hex 6b6864; asc khd;; 3: len 6; hex 0000111ef3eb; asc ......
-;; 4: len 7; hex 800001001e0084; asc .......;; 5: len 3; hex 6b6864; asc khd;;
+RECORD: info bits 0 0: len 4; hex 8000015b; asc ...[;; 1: len 4; hex
+80000005; asc ....;; 2: len 3; hex 6b6864; asc khd;; 3: len 6; hex
+0000111ef3eb; asc ......;; 4: len 7; hex 800001001e0084; asc .......;; 5:
+len 3; hex 6b6864; asc khd;;
 ------------------------
 LATEST DETECTED DEADLOCK
 ------------------------
 030709 12:59:58
 *** (1) TRANSACTION:
-TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185, OS thread id 30733 inser
-ting
+TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185, OS thread id 30733
+inserting
 LOCK WAIT 3 lock struct(s), heap size 320, undo log entries 146
 MySQL thread id 21, query id 4553379 localhost heikki update
-INSERT INTO alex1 VALUES(86, 86, 794,'aA35818','bb','c79166','d4766t','e187358f'
-,'g84586','h794',date_format('2001-04-03 12:54:22','%Y-%m-%d %H:%i'),7
+INSERT INTO alex1 VALUES(86, 86, 794,'aA35818','bb','c79166','d4766t',
+'e187358f','g84586','h794',date_format('2001-04-03 12:54:22','%Y-%m-%d
+%H:%i'),7
 *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290252780 lock mode S waiting
-Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138; asc a
-a35818;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290252780 lock mode S waiting
+Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;
+asc aa35818;; 1:
 *** (2) TRANSACTION:
-TRANSACTION 0 290251546, ACTIVE 2 sec, process no 3190, OS thread id 32782 inser
-ting
+TRANSACTION 0 290251546, ACTIVE 2 sec, process no 3190, OS thread id 32782
+inserting
 130 lock struct(s), heap size 11584, undo log entries 437
 MySQL thread id 23, query id 4554396 localhost heikki update
-REPLACE INTO alex1 VALUES(NULL, 32, NULL,'aa3572','','c3572','d6012t','', NULL,'
-h396', NULL, NULL, 7.31,7.31,7.31,200)
+REPLACE INTO alex1 VALUES(NULL, 32, NULL,'aa3572','','c3572','d6012t','',
+NULL,'h396', NULL, NULL, 7.31,7.31,7.31,200)
 *** (2) HOLDS THE LOCK(S):
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290251546 lock_mode X locks rec but not gap
-Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138; asc a
-a35818;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290251546 lock_mode X locks rec but not gap
+Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;
+asc aa35818;; 1:
 *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290251546 lock_mode X locks gap before rec insert intention waiting
-Record lock, heap no 82 RECORD: info bits 0 0: len 7; hex 61613335373230; asc aa
-35720;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290251546 lock_mode X locks gap before rec insert intention
+waiting
+Record lock, heap no 82 RECORD: info bits 0 0: len 7; hex 61613335373230;
+asc aa35720;; 1:
 *** WE ROLL BACK TRANSACTION (1)
 ------------
 TRANSACTIONS
@@ -5029,45 +5051,48 @@
 ---TRANSACTION 0 0, not started, process no 3491, OS thread id 42002
 MySQL thread id 32, query id 4668737 localhost heikki
 show innodb status
----TRANSACTION 0 290328384, ACTIVE 0 sec, process no 3205, OS thread id 38929 in
-serting
+---TRANSACTION 0 290328384, ACTIVE 0 sec, process no 3205, OS thread id
+38929 inserting
 1 lock struct(s), heap size 320
 MySQL thread id 29, query id 4668736 localhost heikki update
-insert into speedc values (1519229,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjgjlhh
-gghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjfh
----TRANSACTION 0 290328383, ACTIVE 0 sec, process no 3180, OS thread id 28684 co
-mmitting
+insert into speedc values (1519229,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjg
+jlhhgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjfh
+---TRANSACTION 0 290328383, ACTIVE 0 sec, process no 3180, OS thread id
+28684 committing
 1 lock struct(s), heap size 320, undo log entries 1
 MySQL thread id 19, query id 4668734 localhost heikki update
-insert into speedcm values (1603393,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjgjlh
-hgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjf
----TRANSACTION 0 290328327, ACTIVE 0 sec, process no 3200, OS thread id 36880 st
-arting index read
+insert into speedcm values (1603393,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgj
+gjlhhgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjf
+---TRANSACTION 0 290328327, ACTIVE 0 sec, process no 3200, OS thread id
+36880 starting index read
 LOCK WAIT 2 lock struct(s), heap size 320
-MySQL thread id 27, query id 4668644 localhost heikki Searching rows for update
+MySQL thread id 27, query id 4668644 localhost heikki Searching rows for
+update
 update ibtest11a set B = 'kHdkkkk' where A = 89572
 ------- TRX HAS BEEN WAITING 0 SEC FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 65556 n bits 232 table test/ibtest11a index PRIM
-ARY trx id 0 290328327 lock_mode X waiting
-Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00; asc
- supremum.;;
+RECORD LOCKS space id 0 page no 65556 n bits 232 table test/ibtest11a index
+PRIMARY trx id 0 290328327 lock_mode X waiting
+Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00;
+asc supremum.;;
 ------------------
----TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831 ro
-llback of SQL statement
+---TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id
+34831 rollback of SQL statement
 ROLLING BACK 14 lock struct(s), heap size 2496, undo log entries 9
 MySQL thread id 25, query id 4668733 localhost heikki update
 insert into ibtest11a (D, B, C) values (5, 'khDk' ,'khDk')
----TRANSACTION 0 290327208, ACTIVE 1 sec, process no 3190, OS thread id 32782
+---TRANSACTION 0 290327208, ACTIVE 1 sec, process no 3190, OS thread id
+32782
 58 lock struct(s), heap size 5504, undo log entries 159
 MySQL thread id 23, query id 4668732 localhost heikki update
-REPLACE INTO alex1 VALUES(86, 46, 538,'aa95666','bb','c95666','d9486t','e200498f
-','g86814','h538',date_format('2001-04-03 12:54:22','%Y-%m-%d %H:%i'),
----TRANSACTION 0 290323325, ACTIVE 3 sec, process no 3185, OS thread id 30733 in
-serting
+REPLACE INTO alex1 VALUES(86, 46, 538,'aa95666','bb','c95666','d9486t',
+'e200498f','g86814','h538',date_format('2001-04-03 12:54:22','%Y-%m-%d
+%H:%i'),
+---TRANSACTION 0 290323325, ACTIVE 3 sec, process no 3185, OS thread id
+30733 inserting
 4 lock struct(s), heap size 1024, undo log entries 165
 MySQL thread id 21, query id 4668735 localhost heikki update
-INSERT INTO alex1 VALUES(NULL, 49, NULL,'aa42837','','c56319','d1719t','', NULL,
-'h321', NULL, NULL, 7.31,7.31,7.31,200)
+INSERT INTO alex1 VALUES(NULL, 49, NULL,'aa42837','','c56319','d1719t','',
+NULL,'h321', NULL, NULL, 7.31,7.31,7.31,200)
 --------
 FILE I/O
 --------
@@ -5118,7 +5143,6 @@
 ----------------------------
 END OF INNODB MONITOR OUTPUT
 ============================
-1 row in set (0.05 sec)
 </programlisting>
 
       <para>
@@ -5130,8 +5154,8 @@
         <listitem>
           <para>
             If the <literal>TRANSACTIONS</literal> section reports lock
-            waits, your application may have lock contention. The output
-            can also help to trace the reasons for transaction
+            waits, your applications may have lock contention. The
+            output can also help to trace the reasons for transaction
             deadlocks.
           </para>
         </listitem>
@@ -5144,7 +5168,7 @@
             semaphore. A large number of threads waiting for semaphores
             may be a result of disk I/O, or contention problems inside
             <literal>InnoDB</literal>. Contention can be due to heavy
-            parallelism of queries, or problems in operating system
+            parallelism of queries or problems in operating system
             thread scheduling. Setting
             <literal>innodb_thread_concurrency</literal> smaller than
             the default value can help in such situations.
@@ -5175,16 +5199,15 @@
         <literal>stdout</literal> or fixed-size memory buffers, in order
         to avoid potential buffer overflows. As a side effect, the
         output of <literal>SHOW ENGINE INNODB STATUS</literal> is
-        written to a status file every fifteen seconds. The name of the
-        file is
+        written to a status file in the MySQL data directory every
+        fifteen seconds. The name of the file is
         <filename>innodb_status.<replaceable>pid</replaceable></filename>,
         where <replaceable>pid</replaceable> is the server process ID.
-        This file is created in the MySQL data directory.
         <literal>InnoDB</literal> removes the file for a normal
         shutdown. If abnormal shutdowns have occurred, instances of
         these status files may be present and must be removed manually.
         Before removing them, you might want to examine them to see if
-        they contain useful information to the cause of abnormal
+        they contain useful information about the cause of abnormal
         shutdowns. The
         <filename>innodb_status.<replaceable>pid</replaceable></filename>
         file is created only if the configuration option
@@ -5200,8 +5223,8 @@
     <title>&title-innodb-multi-versioning;</title>
 
     <para>
-      Because <literal>InnoDB</literal> is a multi-versioned database,
-      it must keep information about old versions of rows in the
+      Because <literal>InnoDB</literal> is a multi-versioned storage
+      engine, it must keep information about old versions of rows in the
       tablespace. This information is stored in a data structure called
       a <firstterm>rollback segment</firstterm> (after an analogous data
       structure in Oracle).
@@ -5230,7 +5253,7 @@
       Undo logs in the rollback segment are divided into insert and
       update undo logs. Insert undo logs are needed only in transaction
       rollback and can be discarded as soon as the transaction commits.
-      Update undo logs are used also in consistent reads, and they can
+      Update undo logs are used also in consistent reads, but they can
       be discarded only after there is no transaction present for which
       <literal>InnoDB</literal> has assigned a snapshot that in a
       consistent read could need the information in the update undo log
@@ -5239,7 +5262,7 @@
 
     <para>
       You must remember to commit your transactions regularly, including
-      those transactions that only issue consistent reads. Otherwise,
+      those transactions that issue only consistent reads. Otherwise,
       <literal>InnoDB</literal> cannot discard data from the update undo
       logs, and the rollback segment may grow too big, filling up your
       tablespace.
@@ -5272,8 +5295,8 @@
       the table carries just 10 MB of useful data, it may grow to occupy
       10 GB with all the <quote>dead</quote> rows. In such a case, it
       would be good to throttle new row operations, and allocate more
-      resources to the purge thread. The startup option and settable
-      global variable <literal>innodb_max_purge_lag</literal> exists for
+      resources to the purge thread. The
+      <literal>innodb_max_purge_lag</literal> system variable exists for
       exactly this purpose. See <xref linkend="innodb-parameters"/>, for
       more information.
     </para>
@@ -5288,8 +5311,8 @@
       MySQL stores its data dictionary information for tables in
       <filename>.frm</filename> files in database directories. This is
       true for all MySQL storage engines. But every
-      <literal>InnoDB</literal> table also has its own entry in
-      <literal>InnoDB</literal> internal data dictionaries inside the
+      <literal>InnoDB</literal> table also has its own entry in the
+      <literal>InnoDB</literal> internal data dictionary inside the
       tablespace. When MySQL drops a table or a database, it has to
       delete both an <filename>.frm</filename> file or files, and the
       corresponding entries inside the <literal>InnoDB</literal> data
@@ -5315,7 +5338,7 @@
       by the row ID that <literal>InnoDB</literal> assigns to the rows
       in such a table. The row ID is a 6-byte field that increases
       monotonically as new rows are inserted. Thus, the rows ordered by
-      the row ID are physically in the insertion order.
+      the row ID are physically in insertion order.
     </para>
 
     <para>
@@ -5323,8 +5346,8 @@
       row data is on the same page where the index search leads. If a
       table is large, the clustered index architecture often saves a
       disk I/O when compared to the traditional solution. (In many
-      databases, the data is traditionally stored on a different page
-      from the index record.)
+      database systems, data storage uses a different page from the
+      index record.)
     </para>
 
     <para>
@@ -5347,7 +5370,7 @@
       <title>&title-innodb-physical-structure;</title>
 
       <para>
-        All indexes in <literal>InnoDB</literal> are B-trees where the
+        All <literal>InnoDB</literal> indexes are B-trees where the
         index records are stored in the leaf pages of the tree. The
         default size of an index page is 16KB. When new records are
         inserted, <literal>InnoDB</literal> tries to leave 1/16 of the
@@ -5371,7 +5394,7 @@
       <title>&title-innodb-insert-buffering;</title>
 
       <para>
-        It is a common situation in a database application that the
+        It is a common situation in database applications that the
         primary key is a unique identifier and new rows are inserted in
         the ascending order of the primary key. Thus, the insertions to
         the clustered index do not require random reads from a disk.
@@ -7167,10 +7190,10 @@
         perform SQL statements on tables whose name contains the
         character &lsquo;<literal>#</literal>&rsquo; if you enclose the
         name within backticks. Thus, you can drop such an orphaned table
-        like any other orphaned table using the method described above.
-        Note that to copy or rename a file in the Unix shell, you need
-        to put the file name in double quotes if the file name contains
-        &lsquo;<literal>#</literal>&rsquo;.
+        like any other orphaned table using the method described
+        earlier. Note that to copy or rename a file in the Unix shell,
+        you need to put the file name in double quotes if the file name
+        contains &lsquo;<literal>#</literal>&rsquo;.
       </para>
 
     </section>

Modified: trunk/refman-5.1/innodb.xml
===================================================================
--- trunk/refman-5.1/innodb.xml	2006-01-10 01:11:11 UTC (rev 747)
+++ trunk/refman-5.1/innodb.xml	2006-01-10 04:11:12 UTC (rev 748)
@@ -1428,11 +1428,11 @@
           log files must be less than 4GB on 32-bit computers. The
           default is 5MB. Sensible values range from 1MB to
           1/<replaceable>N</replaceable>-th of the size of the buffer
-          pool, below, where <replaceable>N</replaceable> is the number
-          of log files in the group. The larger the value, the less
-          checkpoint flush activity is needed in the buffer pool, saving
-          disk I/O. But larger log files also mean that recovery is
-          slower in case of a crash.
+          pool, where <replaceable>N</replaceable> is the number of log
+          files in the group. The larger the value, the less checkpoint
+          flush activity is needed in the buffer pool, saving disk I/O.
+          But larger log files also mean that recovery is slower in case
+          of a crash.
         </para>
       </listitem>
 
@@ -1982,13 +1982,21 @@
         If you have <literal>UNIQUE</literal> constraints on secondary
         keys, you can speed up a table import by turning off the
         uniqueness checks temporarily during the import session:
-        <literal>SET UNIQUE_CHECKS=0;</literal>. For big tables, this
-        saves a lot of disk I/O because <literal>InnoDB</literal> can
-        then use its insert buffer to write secondary index records as a
-        batch.
       </para>
 
+<programlisting>
+SET UNIQUE_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET UNIQUE_CHECKS=1;
+</programlisting>
+
       <para>
+        For big tables, this saves a lot of disk I/O because
+        <literal>InnoDB</literal> can then use its insert buffer to
+        write secondary index records as a batch.
+      </para>
+
+      <para>
         To get better control over the insertion process, it might be
         good to insert big tables in pieces:
       </para>
@@ -2803,7 +2811,7 @@
 </programlisting>
 
     <para>
-      Suppose that this data file, over time, has grown to 988MB. Below
+      Suppose that this data file, over time, has grown to 988MB. Here
       is the configuration line after adding another auto-extending data
       file.
     </para>
@@ -2969,8 +2977,8 @@
 
     <para>
       To be able to recover your <literal>InnoDB</literal> database to
-      the present from the binary backup described above, you have to
-      run your MySQL server with binary logging turned on. Then you can
+      the present from the binary backup just described, you have to run
+      your MySQL server with binary logging turned on. Then you can
       apply the binary log to the backup database to achieve
       point-in-time recovery:
     </para>
@@ -3764,13 +3772,14 @@
 
           <para>
             In consistent reads, there is an important difference from
-            the previous isolation level: In this level, all consistent
-            reads within the same transaction read the same snapshot
-            established by the first read. This convention means that if
-            you issue several plain <literal>SELECT</literal> statements
-            within the same transaction, these <literal>SELECT</literal>
-            statements are consistent also with respect to each other.
-            See <xref linkend="innodb-consistent-read"/>.
+            the <literal>READ COMMITTED</literal> isolation level: All
+            consistent reads within the same transaction read the same
+            snapshot established by the first read. This convention
+            means that if you issue several plain
+            <literal>SELECT</literal> statements within the same
+            transaction, these <literal>SELECT</literal> statements are
+            consistent also with respect to each other. See
+            <xref linkend="innodb-consistent-read"/>.
           </para>
         </listitem>
 
@@ -3781,9 +3790,9 @@
 
           <para>
             This level is like <literal>REPEATABLE READ</literal>, but
-            all plain <literal>SELECT</literal> statements are
-            implicitly converted to <literal>SELECT ... LOCK IN SHARE
-            MODE</literal>.
+            <literal>InnoDB</literal> implicitly commits all plain
+            <literal>SELECT</literal> statements to <literal>SELECT ...
+            LOCK IN SHARE MODE</literal>.
           </para>
         </listitem>
 
@@ -3796,21 +3805,21 @@
       <title>&title-innodb-consistent-read;</title>
 
       <para>
-        A consistent read means that <literal>InnoDB</literal> uses its
+        A consistent read means that <literal>InnoDB</literal> uses
         multi-versioning to present to a query a snapshot of the
         database at a point in time. The query see the changes made by
-        exactly those transactions that committed before that point of
-        time, and no changes made by later or uncommitted transactions.
-        The exception to this rule is that the query sees the changes
-        made by the transaction itself that issues the query.
+        those transactions that committed before that point of time, and
+        no changes made by later or uncommitted transactions. The
+        exception to this rule is that the query sees the changes made
+        by earlier statements within the same transaction.
       </para>
 
       <para>
         If you are running with the default <literal>REPEATABLE
-        READ</literal> isolation level, then all consistent reads within
-        the same transaction read the snapshot established by the first
-        such read in that transaction. You can get a fresher snapshot
-        for your queries by committing the current transaction and after
+        READ</literal> isolation level, all consistent reads within the
+        same transaction read the snapshot established by the first such
+        read in that transaction. You can get a fresher snapshot for
+        your queries by committing the current transaction and after
         that issuing new queries.
       </para>
 
@@ -3829,14 +3838,14 @@
         Note that consistent read does not work over <literal>DROP
         TABLE</literal> and over <literal>ALTER TABLE</literal>.
         Consistent read does not work over <literal>DROP TABLE</literal>
-        because MySQL can't use table that has been dropped and
+        because MySQL can't use a table that has been dropped and
         <literal>InnoDB</literal> destroys the table. Consistent read
         does not work over <literal>ALTER TABLE</literal> because it is
-        executed inside of the transaction which creates a new table and
-        inserts rows from the old table to the new table. Now, when you
+        executed inside of the transaction that creates a new table and
+        inserts rows from the old table to the new table. When you
         reissue the consistent read, it will not see any rows in the new
         table, because they were inserted in a transaction that is not
-        visible in the snapshot that the consistent read reads.
+        visible in the snapshot read by the consistent read.
       </para>
 
     </section>
@@ -3860,7 +3869,7 @@
         in the table. Can you safely add the child row to table
         <literal>child</literal>? No, because it may happen that
         meanwhile some other user deletes the parent row from the table
-        <literal>parent</literal>, without you being aware of it.
+        <literal>parent</literal> without you being aware of it.
       </para>
 
       <para>
@@ -3925,7 +3934,7 @@
       </para>
 
       <para>
-        Please note that the above is merely an example of how
+        The preceding description is merely an example of how
         <literal>SELECT ... FOR UPDATE</literal> works. In MySQL, the
         specific task of generating a unique identifier actually can be
         accomplished using only a single access to the table:
@@ -3942,6 +3951,12 @@
         does not access any table.
       </para>
 
+      <para>
+        Locks set by <literal>IN SHARE MODE</literal> and <literal>FOR
+        UPDATE</literal> reads are released when the transaction is
+        committed or rolled back.
+      </para>
+
     </section>
 
     <section id="innodb-next-key-locking">
@@ -3983,10 +3998,10 @@
         in the gaps, a new row might meanwhile be inserted to the table.
         If you execute the same <literal>SELECT</literal> within the
         same transaction, you would see a new row in the result set
-        returned by the query. This is contrary the isolation principle
-        of transactions: A transaction should be able to run so that the
-        data it has read does not change during the transaction. If we
-        regard a set of rows as a data item, the new
+        returned by the query. This is contrary to the isolation
+        principle of transactions: A transaction should be able to run
+        so that the data it has read does not change during the
+        transaction. If we regard a set of rows as a data item, the new
         <quote>phantom</quote> child would violate this isolation
         principle.
       </para>
@@ -4719,8 +4734,8 @@
 </programlisting>
 
         <para>
-          This tip is valid for inserts into any storage engine, not
-          just <literal>InnoDB</literal>.
+          This tip is valid for inserts into any table, not just
+          <literal>InnoDB</literal> tables.
         </para>
       </listitem>
 
@@ -4733,6 +4748,8 @@
 
 <programlisting>
 SET UNIQUE_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET UNIQUE_CHECKS=1;
 </programlisting>
 
         <para>
@@ -4751,6 +4768,8 @@
 
 <programlisting>
 SET FOREIGN_KEY_CHECKS=0;
+<replaceable>... import operation ...</replaceable>
+SET FOREIGN_KEY_CHECKS=1;
 </programlisting>
 
         <para>
@@ -4760,7 +4779,7 @@
 
       <listitem>
         <para>
-          If you often have recurring queries to tables that are not
+          If you often have recurring queries for tables that are not
           updated frequently, use the query cache:
         </para>
 
@@ -4798,8 +4817,8 @@
 
       <para>
         Another way to use <literal>InnoDB</literal> Monitors is to let
-        them continuously write data to the standard output of the
-        server <command>mysqld</command>. In this case, no output is
+        them periodically write data to the standard output of the
+        <command>mysqld</command> server. In this case, no output is
         sent to clients. When switched on, <literal>InnoDB</literal>
         Monitors print data about every 15 seconds. Server output
         usually is directed to the <filename>.err</filename> log in the
@@ -4811,7 +4830,7 @@
       </para>
 
       <para>
-        Monitor output includes information of the following types:
+        Monitor output includes the following types of information:
       </para>
 
       <itemizedlist>
@@ -4862,7 +4881,7 @@
       </para>
 
 <programlisting>
-CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB;
+CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;
 </programlisting>
 
       <para>
@@ -4879,12 +4898,12 @@
         MySQL's SQL parser: The only things that matter are the table
         name <literal>innodb_monitor</literal> and that it be an
         <literal>InnoDB</literal> table. The structure of the table is
-        not relevant at all for the <command><literal>InnoDB</literal>
-        Monitor</command>. If you shut down the server when the monitor
-        is running, and you want to start the monitor again, you must
-        drop the table before you can issue a new <literal>CREATE
-        TABLE</literal> statement to start the monitor. This syntax may
-        change in a future release.
+        not relevant at all for the <literal>InnoDB</literal> Monitor.
+        (This syntax may If you shut down the server, the monitor does
+        not restart automatically when you restart the server. You must
+        drop the monitor table and issue a new <literal>CREATE
+        TABLE</literal> statement to start the monitor. change in a
+        future release.)
       </para>
 
       <para>
@@ -4900,8 +4919,7 @@
       </para>
 
       <para>
-        A sample of <command><literal>InnoDB</literal> Monitor</command>
-        output:
+        A sample of <literal>InnoDB</literal> Monitor output:
       </para>
 
 <programlisting>
@@ -4916,69 +4934,73 @@
 SEMAPHORES
 ----------
 OS WAIT ARRAY INFO: reservation count 413452, signal count 378357
---Thread 32782 has waited at btr0sea.c line 1477 for 0.00 seconds the semaphore:
-X-lock on RW-latch at 41a28668 created in file btr0sea.c line 135
+--Thread 32782 has waited at btr0sea.c line 1477 for 0.00 seconds the
+semaphore: X-lock on RW-latch at 41a28668 created in file btr0sea.c line 135
 a writer (thread id 32782) has reserved it in mode wait exclusive
 number of readers 1, waiters flag 1
 Last time read locked in file btr0sea.c line 731
 Last time write locked in file btr0sea.c line 1347
 Mutex spin waits 0, rounds 0, OS waits 0
-RW-shared spins 108462, OS waits 37964; RW-excl spins 681824, OS waits 375485
+RW-shared spins 108462, OS waits 37964; RW-excl spins 681824, OS waits
+375485
 ------------------------
 LATEST FOREIGN KEY ERROR
 ------------------------
 030709 13:00:59 Transaction:
-TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831 inser
-ting
+TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831
+inserting
 15 lock struct(s), heap size 2496, undo log entries 9
 MySQL thread id 25, query id 4668733 localhost heikki update
 insert into ibtest11a (D, B, C) values (5, 'khDk' ,'khDk')
 Foreign key constraint fails for table test/ibtest11a:
 ,
-  CONSTRAINT `0_219242` FOREIGN KEY (`A`, `D`) REFERENCES `ibtest11b` (`A`, `D`)
- ON DELETE CASCADE ON UPDATE CASCADE
+  CONSTRAINT `0_219242` FOREIGN KEY (`A`, `D`) REFERENCES `ibtest11b` (`A`,
+  `D`) ON DELETE CASCADE ON UPDATE CASCADE
 Trying to add in child table, in index PRIMARY tuple:
- 0: len 4; hex 80000101; asc ....;; 1: len 4; hex 80000005; asc ....;; 2: len 4;
- hex 6b68446b; asc khDk;; 3: len 6; hex 0000114e0edc; asc ...N..;; 4: len 7; hex
- 00000000c3e0a7; asc .......;; 5: len 4; hex 6b68446b; asc khDk;;
+ 0: len 4; hex 80000101; asc ....;; 1: len 4; hex 80000005; asc ....;; 2:
+ len 4; hex 6b68446b; asc khDk;; 3: len 6; hex 0000114e0edc; asc ...N..;; 4:
+ len 7; hex 00000000c3e0a7; asc .......;; 5: len 4; hex 6b68446b; asc khDk;;
 But in parent table test/ibtest11b, in index PRIMARY,
 the closest match we can find is record:
-RECORD: info bits 0 0: len 4; hex 8000015b; asc ...[;; 1: len 4; hex 80000005; a
-sc ....;; 2: len 3; hex 6b6864; asc khd;; 3: len 6; hex 0000111ef3eb; asc ......
-;; 4: len 7; hex 800001001e0084; asc .......;; 5: len 3; hex 6b6864; asc khd;;
+RECORD: info bits 0 0: len 4; hex 8000015b; asc ...[;; 1: len 4; hex
+80000005; asc ....;; 2: len 3; hex 6b6864; asc khd;; 3: len 6; hex
+0000111ef3eb; asc ......;; 4: len 7; hex 800001001e0084; asc .......;; 5:
+len 3; hex 6b6864; asc khd;;
 ------------------------
 LATEST DETECTED DEADLOCK
 ------------------------
 030709 12:59:58
 *** (1) TRANSACTION:
-TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185, OS thread id 30733 inser
-ting
+TRANSACTION 0 290252780, ACTIVE 1 sec, process no 3185, OS thread id 30733
+inserting
 LOCK WAIT 3 lock struct(s), heap size 320, undo log entries 146
 MySQL thread id 21, query id 4553379 localhost heikki update
-INSERT INTO alex1 VALUES(86, 86, 794,'aA35818','bb','c79166','d4766t','e187358f'
-,'g84586','h794',date_format('2001-04-03 12:54:22','%Y-%m-%d %H:%i'),7
+INSERT INTO alex1 VALUES(86, 86, 794,'aA35818','bb','c79166','d4766t',
+'e187358f','g84586','h794',date_format('2001-04-03 12:54:22','%Y-%m-%d
+%H:%i'),7
 *** (1) WAITING FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290252780 lock mode S waiting
-Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138; asc a
-a35818;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290252780 lock mode S waiting
+Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;
+asc aa35818;; 1:
 *** (2) TRANSACTION:
-TRANSACTION 0 290251546, ACTIVE 2 sec, process no 3190, OS thread id 32782 inser
-ting
+TRANSACTION 0 290251546, ACTIVE 2 sec, process no 3190, OS thread id 32782
+inserting
 130 lock struct(s), heap size 11584, undo log entries 437
 MySQL thread id 23, query id 4554396 localhost heikki update
-REPLACE INTO alex1 VALUES(NULL, 32, NULL,'aa3572','','c3572','d6012t','', NULL,'
-h396', NULL, NULL, 7.31,7.31,7.31,200)
+REPLACE INTO alex1 VALUES(NULL, 32, NULL,'aa3572','','c3572','d6012t','',
+NULL,'h396', NULL, NULL, 7.31,7.31,7.31,200)
 *** (2) HOLDS THE LOCK(S):
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290251546 lock_mode X locks rec but not gap
-Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138; asc a
-a35818;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290251546 lock_mode X locks rec but not gap
+Record lock, heap no 324 RECORD: info bits 0 0: len 7; hex 61613335383138;
+asc aa35818;; 1:
 *** (2) WAITING FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index symbole
-trx id 0 290251546 lock_mode X locks gap before rec insert intention waiting
-Record lock, heap no 82 RECORD: info bits 0 0: len 7; hex 61613335373230; asc aa
-35720;; 1:
+RECORD LOCKS space id 0 page no 48310 n bits 568 table test/alex1 index
+symbole trx id 0 290251546 lock_mode X locks gap before rec insert intention
+waiting
+Record lock, heap no 82 RECORD: info bits 0 0: len 7; hex 61613335373230;
+asc aa35720;; 1:
 *** WE ROLL BACK TRANSACTION (1)
 ------------
 TRANSACTIONS
@@ -4990,45 +5012,48 @@
 ---TRANSACTION 0 0, not started, process no 3491, OS thread id 42002
 MySQL thread id 32, query id 4668737 localhost heikki
 show innodb status
----TRANSACTION 0 290328384, ACTIVE 0 sec, process no 3205, OS thread id 38929 in
-serting
+---TRANSACTION 0 290328384, ACTIVE 0 sec, process no 3205, OS thread id
+38929 inserting
 1 lock struct(s), heap size 320
 MySQL thread id 29, query id 4668736 localhost heikki update
-insert into speedc values (1519229,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjgjlhh
-gghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjfh
----TRANSACTION 0 290328383, ACTIVE 0 sec, process no 3180, OS thread id 28684 co
-mmitting
+insert into speedc values (1519229,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjg
+jlhhgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjfh
+---TRANSACTION 0 290328383, ACTIVE 0 sec, process no 3180, OS thread id
+28684 committing
 1 lock struct(s), heap size 320, undo log entries 1
 MySQL thread id 19, query id 4668734 localhost heikki update
-insert into speedcm values (1603393,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgjgjlh
-hgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjf
----TRANSACTION 0 290328327, ACTIVE 0 sec, process no 3200, OS thread id 36880 st
-arting index read
+insert into speedcm values (1603393,1, 'hgjhjgghggjgjgjgjgjggjgjgjgjgjgggjgj
+gjlhhgghggggghhjhghgggggghjhghghghghghhhhghghghjhhjghjghjkghjghjghjghjfhjf
+---TRANSACTION 0 290328327, ACTIVE 0 sec, process no 3200, OS thread id
+36880 starting index read
 LOCK WAIT 2 lock struct(s), heap size 320
-MySQL thread id 27, query id 4668644 localhost heikki Searching rows for update
+MySQL thread id 27, query id 4668644 localhost heikki Searching rows for
+update
 update ibtest11a set B = 'kHdkkkk' where A = 89572
 ------- TRX HAS BEEN WAITING 0 SEC FOR THIS LOCK TO BE GRANTED:
-RECORD LOCKS space id 0 page no 65556 n bits 232 table test/ibtest11a index PRIM
-ARY trx id 0 290328327 lock_mode X waiting
-Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00; asc
- supremum.;;
+RECORD LOCKS space id 0 page no 65556 n bits 232 table test/ibtest11a index
+PRIMARY trx id 0 290328327 lock_mode X waiting
+Record lock, heap no 1 RECORD: info bits 0 0: len 9; hex 73757072656d756d00;
+asc supremum.;;
 ------------------
----TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id 34831 ro
-llback of SQL statement
+---TRANSACTION 0 290328284, ACTIVE 0 sec, process no 3195, OS thread id
+34831 rollback of SQL statement
 ROLLING BACK 14 lock struct(s), heap size 2496, undo log entries 9
 MySQL thread id 25, query id 4668733 localhost heikki update
 insert into ibtest11a (D, B, C) values (5, 'khDk' ,'khDk')
----TRANSACTION 0 290327208, ACTIVE 1 sec, process no 3190, OS thread id 32782
+---TRANSACTION 0 290327208, ACTIVE 1 sec, process no 3190, OS thread id
+32782
 58 lock struct(s), heap size 5504, undo log entries 159
 MySQL thread id 23, query id 4668732 localhost heikki update
-REPLACE INTO alex1 VALUES(86, 46, 538,'aa95666','bb','c95666','d9486t','e200498f
-','g86814','h538',date_format('2001-04-03 12:54:22','%Y-%m-%d %H:%i'),
----TRANSACTION 0 290323325, ACTIVE 3 sec, process no 3185, OS thread id 30733 in
-serting
+REPLACE INTO alex1 VALUES(86, 46, 538,'aa95666','bb','c95666','d9486t',
+'e200498f','g86814','h538',date_format('2001-04-03 12:54:22','%Y-%m-%d
+%H:%i'),
+---TRANSACTION 0 290323325, ACTIVE 3 sec, process no 3185, OS thread id
+30733 inserting
 4 lock struct(s), heap size 1024, undo log entries 165
 MySQL thread id 21, query id 4668735 localhost heikki update
-INSERT INTO alex1 VALUES(NULL, 49, NULL,'aa42837','','c56319','d1719t','', NULL,
-'h321', NULL, NULL, 7.31,7.31,7.31,200)
+INSERT INTO alex1 VALUES(NULL, 49, NULL,'aa42837','','c56319','d1719t','',
+NULL,'h321', NULL, NULL, 7.31,7.31,7.31,200)
 --------
 FILE I/O
 --------
@@ -5079,7 +5104,6 @@
 ----------------------------
 END OF INNODB MONITOR OUTPUT
 ============================
-1 row in set (0.05 sec)
 </programlisting>
 
       <para>
@@ -5091,8 +5115,8 @@
         <listitem>
           <para>
             If the <literal>TRANSACTIONS</literal> section reports lock
-            waits, your application may have lock contention. The output
-            can also help to trace the reasons for transaction
+            waits, your applications may have lock contention. The
+            output can also help to trace the reasons for transaction
             deadlocks.
           </para>
         </listitem>
@@ -5105,7 +5129,7 @@
             semaphore. A large number of threads waiting for semaphores
             may be a result of disk I/O, or contention problems inside
             <literal>InnoDB</literal>. Contention can be due to heavy
-            parallelism of queries, or problems in operating system
+            parallelism of queries or problems in operating system
             thread scheduling. Setting
             <literal>innodb_thread_concurrency</literal> smaller than
             the default value can help in such situations.
@@ -5136,16 +5160,15 @@
         <literal>stdout</literal> or fixed-size memory buffers, in order
         to avoid potential buffer overflows. As a side effect, the
         output of <literal>SHOW ENGINE INNODB STATUS</literal> is
-        written to a status file every fifteen seconds. The name of the
-        file is
+        written to a status file in the MySQL data directory every
+        fifteen seconds. The name of the file is
         <filename>innodb_status.<replaceable>pid</replaceable></filename>,
         where <replaceable>pid</replaceable> is the server process ID.
-        This file is created in the MySQL data directory.
         <literal>InnoDB</literal> removes the file for a normal
         shutdown. If abnormal shutdowns have occurred, instances of
         these status files may be present and must be removed manually.
         Before removing them, you might want to examine them to see if
-        they contain useful information to the cause of abnormal
+        they contain useful information about the cause of abnormal
         shutdowns. The
         <filename>innodb_status.<replaceable>pid</replaceable></filename>
         file is created only if the configuration option
@@ -5161,8 +5184,8 @@
     <title>&title-innodb-multi-versioning;</title>
 
     <para>
-      Because <literal>InnoDB</literal> is a multi-versioned database,
-      it must keep information about old versions of rows in the
+      Because <literal>InnoDB</literal> is a multi-versioned storage
+      engine, it must keep information about old versions of rows in the
       tablespace. This information is stored in a data structure called
       a <firstterm>rollback segment</firstterm> (after an analogous data
       structure in Oracle).
@@ -5191,7 +5214,7 @@
       Undo logs in the rollback segment are divided into insert and
       update undo logs. Insert undo logs are needed only in transaction
       rollback and can be discarded as soon as the transaction commits.
-      Update undo logs are used also in consistent reads, and they can
+      Update undo logs are used also in consistent reads, but they can
       be discarded only after there is no transaction present for which
       <literal>InnoDB</literal> has assigned a snapshot that in a
       consistent read could need the information in the update undo log
@@ -5200,7 +5223,7 @@
 
     <para>
       You must remember to commit your transactions regularly, including
-      those transactions that only issue consistent reads. Otherwise,
+      those transactions that issue only consistent reads. Otherwise,
       <literal>InnoDB</literal> cannot discard data from the update undo
       logs, and the rollback segment may grow too big, filling up your
       tablespace.
@@ -5233,8 +5256,8 @@
       the table carries just 10 MB of useful data, it may grow to occupy
       10 GB with all the <quote>dead</quote> rows. In such a case, it
       would be good to throttle new row operations, and allocate more
-      resources to the purge thread. The startup option and settable
-      global variable <literal>innodb_max_purge_lag</literal> exists for
+      resources to the purge thread. The
+      <literal>innodb_max_purge_lag</literal> system variable exists for
       exactly this purpose. See <xref linkend="innodb-parameters"/>, for
       more information.
     </para>
@@ -5249,8 +5272,8 @@
       MySQL stores its data dictionary information for tables in
       <filename>.frm</filename> files in database directories. This is
       true for all MySQL storage engines. But every
-      <literal>InnoDB</literal> table also has its own entry in
-      <literal>InnoDB</literal> internal data dictionaries inside the
+      <literal>InnoDB</literal> table also has its own entry in the
+      <literal>InnoDB</literal> internal data dictionary inside the
       tablespace. When MySQL drops a table or a database, it has to
       delete both an <filename>.frm</filename> file or files, and the
       corresponding entries inside the <literal>InnoDB</literal> data
@@ -5276,7 +5299,7 @@
       by the row ID that <literal>InnoDB</literal> assigns to the rows
       in such a table. The row ID is a 6-byte field that increases
       monotonically as new rows are inserted. Thus, the rows ordered by
-      the row ID are physically in the insertion order.
+      the row ID are physically in insertion order.
     </para>
 
     <para>
@@ -5284,8 +5307,8 @@
       row data is on the same page where the index search leads. If a
       table is large, the clustered index architecture often saves a
       disk I/O when compared to the traditional solution. (In many
-      databases, the data is traditionally stored on a different page
-      from the index record.)
+      database systems, data storage uses a different page from the
+      index record.)
     </para>
 
     <para>
@@ -5308,7 +5331,7 @@
       <title>&title-innodb-physical-structure;</title>
 
       <para>
-        All indexes in <literal>InnoDB</literal> are B-trees where the
+        All <literal>InnoDB</literal> indexes are B-trees where the
         index records are stored in the leaf pages of the tree. The
         default size of an index page is 16KB. When new records are
         inserted, <literal>InnoDB</literal> tries to leave 1/16 of the
@@ -5332,7 +5355,7 @@
       <title>&title-innodb-insert-buffering;</title>
 
       <para>
-        It is a common situation in a database application that the
+        It is a common situation in database applications that the
         primary key is a unique identifier and new rows are inserted in
         the ascending order of the primary key. Thus, the insertions to
         the clustered index do not require random reads from a disk.
@@ -7102,10 +7125,10 @@
         perform SQL statements on tables whose name contains the
         character &lsquo;<literal>#</literal>&rsquo; if you enclose the
         name within backticks. Thus, you can drop such an orphaned table
-        like any other orphaned table using the method described above.
-        Note that to copy or rename a file in the Unix shell, you need
-        to put the file name in double quotes if the file name contains
-        &lsquo;<literal>#</literal>&rsquo;.
+        like any other orphaned table using the method described
+        earlier. Note that to copy or rename a file in the Unix shell,
+        you need to put the file name in double quotes if the file name
+        contains &lsquo;<literal>#</literal>&rsquo;.
       </para>
 
     </section>

Thread
svn commit - mysqldoc@docsrva: r748 - in trunk: . refman-4.1 refman-5.0 refman-5.1paul10 Jan