Innodb Error Handling - Oracle 5.0 Reference Manual

To see information about the tablespace, use the Tablespace Monitor. See
ENGINE INNODB STATUS
The maximum row length, except for variable-length columns (VARBINARY, VARCHAR,
TEXT), is slightly less than half of a database page. That is, the maximum row length is about 8000
bytes.
LONGBLOB
and
BLOB TEXT
If a row is less than half a page long, all of it is stored locally within the page. If it exceeds half a page,
variable-length columns are chosen for external off-page storage until the row fits within half a page.
For a column chosen for off-page storage,
rest externally into overflow pages. Each such column has its own list of overflow pages. The 768-byte
prefix is accompanied by a 20-byte value that stores the true length of the column and points into the
overflow list where the rest of the value is stored.
14.2.10.3. Defragmenting a Table
If there are random insertions into or deletions from the indexes of a table, the indexes may become
fragmented. Fragmentation means that the physical ordering of the index pages on the disk is not close
to the index ordering of the records on the pages, or that there are many unused pages in the 64-page
blocks that were allocated to the index.
One symptom of fragmentation is that a table takes more space than it "should" take. How much that is
exactly, is difficult to determine. All
may vary from 50% to 100%. Another symptom of fragmentation is that a table scan such as this takes
more time than it "should" take:
SELECT COUNT(*) FROM t WHERE a_non_indexed_column <> 12345;
(In the preceding query, we are "fooling" the SQL optimizer into scanning the clustered index rather
than a secondary index.) Most disks can read 10MB/s to 50MB/s, which can be used to estimate how
fast a table scan should be.
It can speed up index scans if you periodically perform a "null"
MySQL to rebuild the table:
ALTER TABLE
Another way to perform a defragmentation operation is to use
file, drop the table, and reload it from the dump file.
If the insertions into an index are always ascending and records are deleted only from the end, the
filespace management algorithm guarantees that fragmentation in the index does not occur.
InnoDB
14.2.11.
InnoDB
Error handling in
the standard, any error during an SQL statement should cause rollback of that statement.
sometimes rolls back only part of the statement, or the whole transaction. The following items describe
how
InnoDB
• If you run out of file space in the tablespace, a MySQL
rolls back the SQL statement.
• A transaction deadlock causes
the whole transaction when this happens.
A lock wait timeout causes
lock and encountered the timeout. (Until MySQL 5.0.13
if a lock wait timeout happened. You can restore this behavior by starting the server with the
innodb_rollback_on_timeout
normally retry the statement if using the current behavior or the entire transaction if using the old
behavior.
InnoDB
and the
and columns must be less than 4GB, and the total row length, including
LONGTEXT
columns, must be less than 4GB.
InnoDB
tbl_name ENGINE=INNODB
Error Handling
is not always the same as specified in the SQL standard. According to
InnoDB
performs error handling:
InnoDB
InnoDB
Error Handling
Monitors".
InnoDB
stores the first 768 bytes locally in the row, and the
InnoDB
data and indexes are stored in B-trees, and their fill factor
Table is full
to roll back the entire transaction. You should normally retry
to roll back only the single statement that was waiting for the
InnoDB
[1249] option, available as of MySQL 5.0.32.) You should
1280
Section 14.2.12.2,
operation, which causes
ALTER TABLE
to dump the table to a text
mysqldump
error occurs and
rolled back the entire transaction
"SHOW
and
BLOB
InnoDB
InnoDB
--