Foreign Key-Zombie!?

Hallo Leutz,

habe einen Foreign Key von ON DELETE/ UPDATE RESTRICT nach CASCADE
ändern wollen. Da diese Änderungen auf direktem Weg mit dem MySQL
Administrator eh' nicht funktionieren, habe ich zunächst den
existierenden Foreign Key gelöscht und wollte ihn danach mit den
geänderten Parametern neu anlegen, wie es auch schon zig mal in anderen
Tabellen geklappt hat.

Diesmal verweigert mir MySQL jedoch den Key unter gleichem Namen wieder
anzulegen.
SHOW ENGINE INNODB STATUS sagt mir, daß es schon einen Key mit diesem
Namen in der Tabelle "datenbankname/#sql-954_1" gibt. Irgendwas denke
ich, ist da intern schief gelaufen, evtl. weil zum Zeitpunkt des
Löschens noch Daten in der Tabelle waren, und nun geistert der alte FK
als Zombie irgendwo rum. :)

Habe die Datenbank daraufhin über die Backupfunktion von MySQL
Administrator gesichert, gelöscht und anschließend wiederhergestellt -
keine Änderung. Stelle ich sie unter anderem Namen wieder her, kann ich
meinen FK ohne Probleme anlegen. Aus dem Dump-File geht im übrigen auch
nicht hervor, daß er irgendwo in einem Tabellenschema enthalten ist.
Ein Neustart des Servers hat ebensowenig was gebracht wie die Reparatur-
oder Optimierungsfunktion für Tabellen.

Hat jemand eine Idee, woran es liegen könnte und wie ich meinen FK
wieder in meiner originalen DB erstellen kann? Möchte ungern den Namen
der DB ändern und noch weniger den Namen des FK, da der alte ja
anscheinend noch irgendwo herumgeistern muß.

Schönen Gruß
Thorsten

P.S.: Benutze MySQL 5.0.22 CE

Re: Foreign Key-Zombie!?

Thorsten Kleibaum wrote:

> SHOW ENGINE INNODB STATUS sagt mir, daß es schon einen Key mit diesem
> Namen in der Tabelle "datenbankname/#sql-954_1" gibt. Irgendwas denke
> ich, ist da intern schief gelaufen, evtl. weil zum Zeitpunkt des
> Löschens noch Daten in der Tabelle waren, und nun geistert der alte FK
> als Zombie irgendwo rum. :)

Weil eine Tabelle mit diesem Namen offenbar noch in der Datenbank rumfliegt.
Zu erkennen an einem passenden .frm-File.

Ob man das bei InnoDB einfach löschen darf, weiß ich allerdings nicht -
ebensowenig, ob das überhaupt was bringt.


Thomas
--
Ich kenne keinen Adrenalin-Schock, der so zuschlägt, wie der, wenn man
Sachen löscht, die man eigentlich nicht löschen wollte ... Zuckungen
durch den ganzen Körper, erst verkrampft sich der Magen, dann wird es
flau, Hitze- und Kältewallungen ... [Bettina Fink in dasr]

Re: Foreign Key-Zombie!?

Hallo Thomas,

Thomas Rachel wrote:

>> SHOW ENGINE INNODB STATUS sagt mir, daß es schon einen Key mit diesem
>> Namen in der Tabelle "datenbankname/#sql-954_1" gibt. Irgendwas denke
>> ich, ist da intern schief gelaufen, evtl. weil zum Zeitpunkt des
>> Löschens noch Daten in der Tabelle waren, und nun geistert der alte
>> FK als Zombie irgendwo rum. :)
>
> Weil eine Tabelle mit diesem Namen offenbar noch in der Datenbank
> rumfliegt. Zu erkennen an einem passenden .frm-File.

Also, eine Datei mit obigem Namen existiert nach dem Löschen der
Datenbank ebensowenig wie eine Datei mit dem Namen der Tabelle. Daran
kann es also nicht liegen.
Habe auch versucht, das Dump-File mal um eine entsprechende FK-Klausel
zu erweitern. Bekomme aber auch da eine eine Fehlermeldung.

Re: Foreign Key-Zombie!?

"Thorsten Kleibaum" wrote:
>
> habe einen Foreign Key von ON DELETE/ UPDATE RESTRICT nach CASCADE
> ändern wollen. Da diese Änderungen auf direktem Weg mit dem MySQL
> Administrator eh' nicht funktionieren, habe ich zunächst den
> existierenden Foreign Key gelöscht und wollte ihn danach mit den
> geänderten Parametern neu anlegen, wie es auch schon zig mal in anderen
> Tabellen geklappt hat.
>
> Diesmal verweigert mir MySQL jedoch den Key unter gleichem Namen wieder
> anzulegen.
> SHOW ENGINE INNODB STATUS sagt mir, daß es schon einen Key mit diesem
> Namen in der Tabelle "datenbankname/#sql-954_1" gibt.

Wie man am Namen leicht erkennt, ist das eine temporäre Tabelle. MySQL
implementiert ALTER TABLE als "neue Tabelle anlegen, Daten kopieren,
Tabellen umbenennen, Original wegwerfen". Anscheinend ist bei dir die
Original-Tabelle erhalten geblieben. Womöglich benutzt ja ein Client
die Original Tabelle noch?

> Habe die Datenbank daraufhin über die Backupfunktion von MySQL
> Administrator gesichert, gelöscht und anschließend wiederhergestellt -
> keine Änderung. Stelle ich sie unter anderem Namen wieder her, kann ich
> meinen FK ohne Probleme anlegen.

Klar, weil InnoDB den Datenbanknamen in den (internen) Indexnamen
reincodiert. Was genau meinst du mit "gelöscht"? DROP DATABASE? Wenn
nein, dann versuch das mal. Das sollte eigentlich alle InnoDB-internen
Tabellen (also u.a. auch die Tabelle mit den FKs) aufräumen.

> Aus dem Dump-File geht im übrigen auch
> nicht hervor, daß er irgendwo in einem Tabellenschema enthalten ist.

Ich habe noch nie ein Backup mit dem MySQL-Administrator gemacht. Aber
wenn das ein Dump ist, sollte das eigentlich funktionieren. Eventuell
ist ja dein InnoDB-Tablespace beschädigt. Leider kann man InnoDB's
interne Datenstrukturen nicht anfassen. Wenn du deine Daten gesichert
hast, kannst du den MySQL-Daemon stoppen, die ibdata* und iblog* Files
löschen und danach dein Backup wieder einspielen.


XL

Re: Foreign Key-Zombie!?

Axel Schwenke wrote:

>> habe einen Foreign Key von ON DELETE/ UPDATE RESTRICT nach CASCADE
>> ändern wollen. Da diese Änderungen auf direktem Weg mit dem MySQL
>> Administrator eh' nicht funktionieren, habe ich zunächst den
>> existierenden Foreign Key gelöscht und wollte ihn danach mit den
>> geänderten Parametern neu anlegen, wie es auch schon zig mal in
>> anderen Tabellen geklappt hat.
>>
>> Diesmal verweigert mir MySQL jedoch den Key unter gleichem Namen
>> wieder anzulegen.
>> SHOW ENGINE INNODB STATUS sagt mir, daß es schon einen Key mit diesem
>> Namen in der Tabelle "datenbankname/#sql-954_1" gibt.
>
> Wie man am Namen leicht erkennt, ist das eine temporäre Tabelle. MySQL
> implementiert ALTER TABLE als "neue Tabelle anlegen, Daten kopieren,
> Tabellen umbenennen, Original wegwerfen". Anscheinend ist bei dir die
> Original-Tabelle erhalten geblieben. Womöglich benutzt ja ein Client
> die Original Tabelle noch?

Wäre eine schlüssige Erklärung. Allerdings wüßte ich nicht, welcher
Client das sein sollte, zumal ich MySQL neu gestartet habe und somit ja
alle offenen Verbindungen geschlossen sein sollte. Ein Handle auf eine
Datei oder das Verzeichnis war auch nicht offen.


>> Habe die Datenbank daraufhin über die Backupfunktion von MySQL
>> Administrator gesichert, gelöscht und anschließend wiederhergestellt
>> - keine Änderung. Stelle ich sie unter anderem Namen wieder her,
>> kann ich meinen FK ohne Probleme anlegen.
>
> Klar, weil InnoDB den Datenbanknamen in den (internen) Indexnamen
> reincodiert. Was genau meinst du mit "gelöscht"? DROP DATABASE? Wenn
> nein, dann versuch das mal. Das sollte eigentlich alle InnoDB-internen
> Tabellen (also u.a. auch die Tabelle mit den FKs) aufräumen.

Hab auch das über den Administrator gemacht. Da dieser den Menüpunkt
"Drop Schema" anbietet, nehme ich an, daß er über DROP SCHEMA arbeitet.
Laut Dokumentation sind beide Ausdrücke aber synonym zu verwenden.


>> Aus dem Dump-File geht im übrigen auch
>> nicht hervor, daß er irgendwo in einem Tabellenschema enthalten ist.
>
> Ich habe noch nie ein Backup mit dem MySQL-Administrator gemacht. Aber
> wenn das ein Dump ist, sollte das eigentlich funktionieren. Eventuell
> ist ja dein InnoDB-Tablespace beschädigt. Leider kann man InnoDB's
> interne Datenstrukturen nicht anfassen. Wenn du deine Daten gesichert
> hast, kannst du den MySQL-Daemon stoppen, die ibdata* und iblog* Files
> löschen und danach dein Backup wieder einspielen.

Wie in meinem ersten Posting schon vermutet, nehme ich an, daß es ein
interner Fehler war. Bin jedenfalls mit keinem Ansatz vorran gekommen
und habe es jetzt auf die oben beschriebene harte Tour gelöst. Ging dann
auch ohne Probleme.

Schönen Dank
Thorsten