# von myISAM auf MEMORY! ERROR 1114: Table full



## xip (2. Feb 2010)

Hallo, ich habe folgene MyISAM Tabelle:

Tabelle feld:
feld varchar(500)
domain varchar(50)
time timestamp

jetzt wollte ich sie mit:

ALTER TABLE feld engine = memory;

in den Speicher packen. Da kommt allerdings folgende Fehlermeldung:

ERROR 1114 (HY000): The table '#sql-1018_1' is full

habt ihr da eine Idee woran das liegen kann?


----------



## ice-breaker (2. Feb 2010)

der Speicher von MySQL der für die Memory-Engine bereitgestellt wird, reicht nicht aus um alle Daten in der MyISAM-Tabelle in den Ram zu packen.
Warum willst du das eigentlich tun? Bedenke das die Daten in der Memory-Engine flüchtig sind, MySQL neustarten oder ein Rechnerabsturz bedeuten den unwiderruflichen Verlust aller Daten.


----------



## xip (2. Feb 2010)

mir gehts hauptsächlich nur um die Performance. Habe derbe Probleme mit dieser.


Wie kann ich den genügend Speicher frei geben?


----------



## ice-breaker (2. Feb 2010)

mach lieber in dem anderen Thread weiter, da finden wir eine sinnvollere Lösung


----------



## xip (2. Feb 2010)

ja, da haste wohl recht, aber so oder so. 
Richtig performant wird das ganze wohl eh nur als ENGINE MEMORY. 

Da haste denn ja wohl richtig druck. Desshalb interessiert mich schon wie ich das Teil zum laufen bringe. Wenn das Problem mit den Indezies erstmal gelöst werde ich sowas probieren.

lg


----------



## Gelöschtes Mitglied 5909 (2. Feb 2010)

MySQL ist schrott imho...


----------



## ice-breaker (2. Feb 2010)

xip hat gesagt.:


> Richtig performant wird das ganze wohl eh nur als ENGINE MEMORY.


Schmarn, ich habe teilweise richtig große DBs und die sind bestimmt nicht in einer Memory-Engine und absolut performant.



xip hat gesagt.:


> Da haste denn ja wohl richtig druck. Desshalb interessiert mich schon wie ich das Teil zum laufen bringe. Wenn das Problem mit den Indezies erstmal gelöst werde ich sowas probieren


deine Größe der Tabelle ist zu groß für den Ram den du MySQL zugeteilt hast, du musst MySQL mehr Ram geben, oder du musst der Memory Engine mit den Optionen MAX_ROWS und AVG_ROW_LENGTH eine bessere Kalkulation des Rams geben, die du brauchst.


----------



## xip (3. Feb 2010)

So, also das mit den MEMORY Tabellen habe ich jetzt so hinbekommen:


```
set max_heap_table_size=1024M
```
dann kann ich einfach einen Table in den RAM Laden in dem ich:

```
ALTER TABLE tabelle ENGINE = MEMORY;
```
wenn die Software fertig ist mache ich es einfach wieder rückgängig und fahre mit dem Dumper einen Backup:

```
ALTER TABLE tabelle ENGINE = MYISAM;
```
aber wie kann ich jetzt eigentlich den RAM Zugriff erhöhen??
in der my.ini/cnf 
die key_buffer erhöhen?? Was das schon?


----------



## ice-breaker (3. Feb 2010)

und wenn mitten in der Bearbeitung der Server abschmiert, sind alle Datenweg :applaus:
komplett "fehloptimiert" :noe:


----------



## xip (3. Feb 2010)

das bin ich bereit zu riskieren wenn ich dadurch eine Performancesteigerung hinbekomme.

Und du weist doch, no risk no fun!!


----------



## maki (3. Feb 2010)

xip hat gesagt.:


> das bin ich bereit zu riskieren wenn ich dadurch eine Performancesteigerung hinbekomme.
> 
> Und du weist doch, no risk no fun!!


Naja, wenn Datenkonsistenz bzw. richtige Ergebnisse nicht wichtig sind, gibt es keine Grenzen für Optimierungen...


```
public static void main(String[] args) {
		System.exit(0);
	}
```


----------



## xip (3. Feb 2010)

ach komm!!!!!!!

....

davon mal ganz ab, ich betreibe nicht nur irgendwelche PHP Anwendungen die sich auf Datenbanken stützen. Sondern auch rechenlastige JAVA Programme die ich jetzt auf eine Datenbank ausweite.

Der Grund für meine Datenbank ist eine ArrayList. Ab einer gewissen größe spackt das ab. Ich glaube kaum das ich mal locker 20000000 Einträge in sowas speicher kann.

Und wenn da mal was abstürzt für was ich ca 5-6 Stunden Berechnung gebraucht habe, was aber langfristig gesehen, über Zeiträume von vielen Monaten, deutliche Performance steigerung gibt, bin ich gerne bereit dazu das zu opfern.

Darüber hinaus gibs ja noch nen Dumper!!! Der macht Backups!!!


----------



## ice-breaker (3. Feb 2010)

Würdest du nur dein DB-Design ordentlich machen, wäre auch eine persistente Datenbank überhaupt kein Problem.


----------



## xip (3. Feb 2010)

wäre diese schneller als eine Temporäre?


----------

