PDF (US Ltr)
- 26.8Mb
PDF (A4)
- 26.9Mb
HTML Download (TGZ)
- 7.1Mb
HTML Download (Zip)
- 7.2Mb
次に示すのは、発生する可能性のある InnoDB 固有の一般的なエラーのリスト (ただし、すべてが含まれているわけではありません)、および各エラーが発生する理由と問題の解決方法に関する情報です。
-
1005 (ER_CANT_CREATE_TABLE)テーブルを作成できません。エラーメッセージがエラー 150 を示している場合は、外部キー制約が正しく形成されていなかったためにテーブルの作成が失敗しました。エラーメッセージがエラー -1 を示している場合は、テーブルに内部の
InnoDBテーブルの名前に一致したカラム名が含まれているためにテーブルの作成が失敗した可能性があります。 -
1016 (ER_CANT_OPEN_FILE)InnoDBテーブルの.frmファイルが存在するにもかかわらず、このテーブルがInnoDBデータファイルに見つかりません。セクション14.19.3「InnoDB データディクショナリの操作のトラブルシューティング」を参照してください。 -
1114 (ER_RECORD_FILE_FULL)InnoDBでテーブルスペース内の空き領域が不足しています。新しいデータファイルを追加するために、テーブルスペースを再構成してください。 -
1205 (ER_LOCK_WAIT_TIMEOUT)ロック待機のタイムアウトの期限が切れました。トランザクション全体ではなく、待機時間の長すぎたステートメントがロールバックされました。
innodb_lock_wait_timeout構成オプションの値は、SQL ステートメントがほかのトランザクションの完了をより長い時間待機するようにする場合は増やし、また長時間実行されるトランザクションが多すぎるためにロックの問題が発生し、さらにビジー状態のシステム上の並列性が低下している場合は減らすことができます。 -
1206 (ER_LOCK_TABLE_FULL)ロックの総数が、
InnoDBでロックの管理専用に使用されているメモリーの量を超えています。このエラーを回避するには、innodb_buffer_pool_sizeの値を増やします。個々のアプリケーション内では、大きな操作をより小さな操作に分割することが回避方法になる場合があります。たとえば、このエラーが大きなINSERTで発生する場合は、複数のより小さなINSERT操作を実行します。 -
1213 (ER_LOCK_DEADLOCK)トランザクションでデッドロックが発生し、アプリケーションで修正措置をとることができるように自動的にロールバックされました。このエラーからリカバリするには、このトランザクション内のすべての操作を再度実行します。デッドロックは、ロックに対する要求がトランザクション間で整合性のない順序で到着した場合に発生します。ロールバックされたトランザクションがそのすべてのロックを解放したため、ほかのトランザクションは要求したすべてのロックを取得できるようになりました。そのため、ロールバックされたトランザクションを再実行すると、そのトランザクションがほかのトランザクションの完了を待機しなければならないことがありますが、通常デッドロックは再発しません。デッドロックが頻繁に発生する場合は、ロック操作のシーケンス (
LOCK TABLES、SELECT ... FOR UPDATEなど) を、問題が発生する異なるトランザクションまたはアプリケーション間で整合性があるようにしてください。詳細は、セクション14.2.11「デッドロックの対処方法」を参照してください。 -
1216 (ER_NO_REFERENCED_ROW)行を追加しようとしていますが、親の行がないため、外部キー制約に違反します。最初に親の行を追加してください。
-
1217 (ER_ROW_IS_REFERENCED)子を持つ親の行を削除しようとしているため、外部キー制約に違反します。最初に子を削除してください。
-
ERROR 1553 (HY000): インデックス 'fooIdx' をドロップできません。外部キー制約で必要とされていますこのエラーメッセージは、特定の参照制約を適用できる最後のインデックスを削除しようとしたときにレポートされます。
DML ステートメントの最適なパフォーマンスを得るために、
InnoDBでは、親テーブルでのUPDATEおよびDELETE操作で、対応する行が子テーブル内に存在するかどうかを容易にチェックできるように、インデックスは外部キーカラムに存在する必要があります。CREATE TABLE、CREATE INDEX、およびALTER TABLEステートメントの副作用として、MySQL は、このようなインデックスを必要に応じて自動的に作成または削除します。インデックスを削除すると、
InnoDBは、そのインデックスが外部キー制約のチェックに使用されていないかどうかをチェックします。同じ制約を適用するために使用できる別のインデックスが存在する場合は、引き続きインデックスを削除できます。InnoDBは、特定の参照制約を適用できる最後のインデックスを削除できないようにしています。
mysql> ALTER TABLE mytable DROP PRIMARY KEY;
ERROR 1025 (HY000): Error on rename of '.\database\#sql-454_3' to '.\database\mytable' (errno: 150).
I solved it using:
mysql> ALTER TABLE mytable DROP PRIMARY KEY, ADD PRIMARY KEY (column1,column2,column3);
I hope help you.
I'd gotten used to creating auto-incrementing indices using the SERIAL keyword.
CREATE TABLE parent (
id SERIAL PRIMARY KEY NOT NULL
) ENGINE=InnoDB;
In PostgreSQL id will be created as type integer so I was trying this:
CREATE TABLE child (
id SERIAL PRIMARY KEY NOT NULL,
parent_id integer,
FOREIGN KEY (parent_id) REFERENCES parent(id)
) ENGINE=InnoDB;
This failed as parent.id was in fact created as type bigint(20) unsigned.
CREATE TABLE child (
id SERIAL PRIMARY KEY NOT NULL,
parent_id bigint(20) UNSIGNED,
FOREIGN KEY (parent_id) REFERENCES parent(id)
) ENGINE=InnoDB;
ERROR 1005 (HY000) at line 156: Can't create table 'db1.testtable' (errno: 121)
Of course as my SQL had been created from the mysqldump utility, I was confused how an error had appeared in the SQL code!
It turned out it was the presence of existing "ibdata1", "ib_logfile0" and "ib_logfile1" in /var/lib/mysql/ that was causing the problem.
The solution for me was to stop mysql, delete EVERYTHING in the /var/lib/mysql/ folder, then start mysql (this recreates fresh versions of the above files in addition to a fresh "mysql" database), and then re-run my import of the dump.sql file:
shell> mysql < dump.sql
(No username or password needed as the fresh "mysql" database has no root password.)
This worked perfectly and recreated all databases (including re-populating the "mysql" database with my previous data - including my old root password).
ERROR 1005 (HY000): Can't create table ... (errno: 150)
The problem was that the table names are case sensitive in the statement, but for some reason the generated file from phyMyAdmin made them all lower case.
Changing:
ALTER TABLE `jobPostingJobCategories`
ADD CONSTRAINT `jobpostingjobcategories_ibfk_1` FOREIGN KEY (`jobID`) REFERENCES `jobpostings` (`jobID`) ON DELETE CASCADE,
ADD CONSTRAINT `jobpostingjobcategories_ibfk_2` FOREIGN KEY (`categoryID`) REFERENCES `jobcategories` (`categoryID`) ON DELETE CASCADE;
to:
ALTER TABLE `jobPostingJobCategories`
ADD CONSTRAINT `jobpostingjobcategories_ibfk_1` FOREIGN KEY (`jobID`) REFERENCES `jobPostings` (`jobID`) ON DELETE CASCADE,
ADD CONSTRAINT `jobpostingjobcategories_ibfk_2` FOREIGN KEY (`categoryID`) REFERENCES `jobCategories` (`categoryID`) ON DELETE CASCADE;
fixed the problem
mysql\data\ibdata1
I then restarted which bebuilt the data directory file and I was able to add the table with no problems.
http://eliacom.com/wpErrNo150.php
I restored the original DB and content and then used DROP SCHEMA to remove the DB. I re-created the DB and the the tables in the db without further problems.
CREATE TABLE IF NOT EXISTS `cursos_crs` (
`crs_id` INT NOT NULL AUTO_INCREMENT ,
`crs_nome` VARCHAR(45) NULL ,
`crs_instituicao` VARCHAR(45) NULL ,
`crs_carga_horaria` VARCHAR(45) NULL ,
`crs_data_inicio` DATE NULL ,
`crs_data_fim` DATE NULL ,
`pro_id` INT NOT NULL ,
`stc_id` INT NOT NULL ,
PRIMARY KEY (`crs_id`) ,
CONSTRAINT `fk_cursos_crs_profissional_pro1`
FOREIGN KEY (`pro_id` )
REFERENCES `profissional_pro` (`pro_id` )
ON DELETE CASCADE
ON UPDATE NO ACTION,
CONSTRAINT `fk_cursos_crs_situacao_std1`
FOREIGN KEY (`stc_id` )
REFERENCES `situacao_stc` (`stc_id` )
ON DELETE SET NULL
ON UPDATE NO ACTION)
ENGINE = InnoDB;
A FK on delete set null no atributo stc_id, porém este atributo estava not null.
Fiz esta correção na tabela `stc_id` INT NULL e o problema foi solucionado.