Bei mir war die Tabelle cache_pages defekt. Der normale User bekam nur eine Fehlremeldung, meldete man sich als admin an, bekam man in einem anderen Tab die Seite angezeigt. Meldete man sich wieder ab, kam wieder die Fehlermeldung. Ich hab dann die Tabelle gelöscht und neu hinzugefügt, dann ging es wieder.
Jetzt die Fragen:
1. Cached typo3 die Seiten nicht, wenn ein admin aktiv ist ?
2. Wie kann eine Tabelle "einfach so" kaputt gehen ?
MfG
nein ein admin sieht immer eine generierte seite, nicht die im cache.
mysql 3 ist nicht transaktions-sicher. wenn php mal 'abstürzt" dann kann es passieren das eine tabelle unsauber geschrieben wurde.
im mysqlcc gibt es aber eine optimize und/oder repair funktion die solche defekte tabellen repariert. (für den fall das es mal eine andere tabelle erwischt)
sollte aber pro jahr so grob 2 mal passieren. mehr wäre beunruhigend #paralyzed#
mysql4 hat das problem weniger, hängt aber am typ der tabellen (ob myisap oder berkley oder was da alles ist)
Danke für die Antwort. Das Repair(en) oder ein Optimize geht dann allerdings nicht mehr... Mir hat's gerade die zweite Tabelle zerrissen. Diesmal die cache_pagesection... Er meckert dann das er die Datei gar nicht öffnen kann. Solange mir die Caches abrauchen kann ich damit klar kommen, was aber wenn die tt_content in Jagdgründe reitet ? (Datensicherung ist schließlich was für Feiglinge 😉 )
Aber dann bin ich damit ja auch durch für dieses Jahr, oder ? 😃
😢 Heute wars dann wieder soweit:
------------------------>8----------------------------
Can't open file: 'cache_pages.MYI'. (errno: 145)
Fehler
SQL-Befehl :
SHOW KEYS FROM `cache_pages`
MySQL meldet:
Can't open file: 'cache_pages.MYI'. (errno: 145)
----------------------8<------------------------------
Was passiert da ?
(3.6.0RC1 quickstart auf Win2k Advanced Server)
Schon wieder...:
----------->8-----------------------------
Daten 259.640 Bytes
Index 4.096 Bytes
Überhang 16.384 PB
Effektiv -18.446.744.073.709.290.000 Bytes
Insgesamt 263.736 Bytes
----------------8<-------optimizen...--------------
t3_quickstart.cache_pages optimize info Key 1 - Found wrong stored record at 0
t3_quickstart.cache_pages optimize info Wrong bytesec: 34-32-97 at 259640; Skipped
t3_quickstart.cache_pages optimize info Wrong bytesec: 49-48-48 at 427660; Skipped
t3_quickstart.cache_pages optimize warning Number of rows changed from 86 to 95
t3_quickstart.cache_pages optimize status OK
----------->8-----------------------------
Wie kommt das ?
optimize ist nicht das gleiche wie repair würd ich mal meinen. wenn die tabelle dahin ist ist ein optimize auch kaum drin.
mysql -uusername -p dbname
Enter password: DasPasswort
...
mysql> REPAIR TABLE tablename;
...
mysql> exit
was sind das denn so für seiten? tut zB imagemagick zu lange rum und wird wegen dem php-exec-limit dann abgewürgt? (zu grosse / zu viele bilder)
oder knallt der server öfter mal hin?
ist das ein iis oder apache?
das sollt selten vorkommen. fehlerhafte tabellen sind meistens wenn mysql die einzelnen dateien nicht auf die festplatte bringt...
Erstmal danke für die Antwort.
Nach einem Optimize ist die Tabelle wieder "benutzbar".
Ab und zu sagt er aber auch "kann Datei cache_pages.MYI nicht öffnen". Dann geht das optimizen natürlich auch nicht mehr, ist klar... Dann lösche ich die Tabelle und generiere sie neu. Ist beim Cache ja auch nicht schlimm...
Habe gerade mal in die .err Datei geschaut, da steht:
040330 14:47:05 read_const: Got error 134 when reading table ./t3_quickstart/cache_pages
error 127 = Daten-Datei ist beschädigt (kam auch vor)
error 134 = Datensatz wurde bereits gelöscht (oder Daten-Datei beschädigt)
Mysql 4.0.15, Apache auf einem Win2K Adv.Serv.
wie gehts denn der festplatte wo die daten geschrieben werden?
eventuell mal den ./data ordner vom mysql verschieben und in der my.ini (my.cnf) den neuen ort eintragen?
oder läuft ein oberagressiver virenscanner der jede dateioperation analysiert und das schreiben vom mysql verzögert?
oder arbeitet die festplatte ohnehin schwer?
oder läuft ein oberagressiver virenscanner der jede dateioperation analysiert und das schreiben vom mysql verzögert?
Das klingt viel versprechend. Der Server ist nämlich auch der Antivirenserver... (NAV 8.1 CE) mit "eigenem" (lokalen) Client... Ich nehm die Ordner mal aus der Überwachung raus, mal sehen wie's dann läuft.
Vielen Dank für den Tip(p ?) !!! 😃
Das scheint's gewesen zu sein, seit fast 3 Wochen ist Ruhe.
Besten Dank ossipetz !
windows 2003
iis
typo 3.5.1
immer wenn man an den templates arbeitet.
zerschossen werden:
cache_pages
cache_pagesection
es bleibt einem nichts anderes übrig als mysql zu killen im taskmanager.
runterfahren geht auch nicht mehr.