Решено. database.mysql.inc on line 172

Главные вкладки

Аватар пользователя FunnyPainters FunnyPainters 24 ноября 2009 в 5:30

Ошибка на всех сранцах:

user warning: Table 'ВАШ_ПРЕФИКС_cache_page' is marked as crashed and should be repaired query: DELETE FROM ВАШ_ПРЕФИКС_cache_page in ПУТЬ/includes/database.mysql.inc on line 172.

Решение:

идем в phpmyadmin->SQL->Выполняем запрос: TRUNCATE `ВАШ_ПРЕФИКС_cache_page`;

Это я делаю TRUNCATE а правильнее как подсказали — REPAIR TABLE

REPAIR TABLE `ВАШ_ПРЕФИКС_cache_block`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_filter`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_form`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_menu`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_page`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_update`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache`;
REPAIR TABLE `ВАШ_ПРЕФИКС_search_index`;
REPAIR TABLE `ВАШ_ПРЕФИКС_sessions`;
REPAIR TABLE `main_watchdog`;

TRUNCATE — Удаляет все строки в таблице, не записывая в журнал удаление отдельных строк. Инструкция TRUNCATE TABLE похожа на инструкцию DELETE без предложения WHERE, однако TRUNCATE TABLE выполняется быстрее и требует меньших ресурсов системы и журналов транзакций.

РЕККОМЕНДУЮТ ЕЩЕ ЧИСТИТЬ:

TRUNCATE `ВАШ_ПРЕФИКС_accesslog`;
TRUNCATE `ВАШ_ПРЕФИКС_cache`;
TRUNCATE `ВАШ_ПРЕФИКС_search_index`;
TRUNCATE `ВАШ_ПРЕФИКС_sessions`;
TRUNCATE `main_watchdog`;

а тут http://www.drupal.ru/node/28946 еще больше. весь кеш

TRUNCATE `ВАШ_ПРЕФИКС_cache`;
TRUNCATE `ВАШ_ПРЕФИКС_cache_block`;
TRUNCATE `ВАШ_ПРЕФИКС_cache_filter`;
TRUNCATE `ВАШ_ПРЕФИКС_cache_form`;
TRUNCATE `ВАШ_ПРЕФИКС_cache_menu`;
TRUNCATE `ВАШ_ПРЕФИКС_cache_page`;
TRUNCATE `ВАШ_ПРЕФИКС_cache_update`;

Комментарии

Аватар пользователя vgoodvin vgoodvin 24 ноября 2009 в 9:30

Ага. А если тоже самое, но с таблицей system? Тоже TRUNCATE? Это неверное решение. Верное - REPAIR TABLE `table_name`. Исправьте пока кто-нибудь не забил всю БД. TRUNCATE отличается от DELETE тем, что сначала удаляет, а потом пересоздает таблицу, поэтому и работает быстрее.

PS. в phpmyadmin еще проще. для REPAIR TABLE выбираете нужные таблицы и делаете "repair table".

Аватар пользователя FunnyPainters FunnyPainters 24 декабря 2009 в 1:16

REPAIR TABLE `ВАШ_ПРЕФИКС_cache`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_block`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_filter`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_form`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_menu`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_page`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache_update`;
REPAIR TABLE `ВАШ_ПРЕФИКС_cache`;
REPAIR TABLE `ВАШ_ПРЕФИКС_search_index`;
REPAIR TABLE `ВАШ_ПРЕФИКС_sessions`;
REPAIR TABLE `main_watchdog`;

Аватар пользователя FunnyPainters FunnyPainters 2 января 2010 в 3:06

Узнал истоки ошибки. Все заключается в стандартном поиске.. Для него надо возможность хостера создать для сирха ВРЕМЕННЫЕ база данных.
Ребята в решение создали модуль fast_search а стандартный банится...

Аватар пользователя vgoodvin vgoodvin 2 января 2010 в 20:26

"FunnyPainers" wrote:
ВРЕМЕННЫЕ база данных

Поподробнее можно? Недопонял что за временные БД.

Я всегда думал что ошибка типа "...is marked as crashed and should be repaired..." возникает в случае сбоя, перенагрузки и других побочных эффектов нестабильной работы сервера. Может я не прав, тогда поправьте.

Аватар пользователя Виктор Степаньков ака RxB Виктор Степаньк... 2 января 2010 в 20:39

Имелись ввиду скорее всего временные таблицы, но модуль search явно не создаёт таблиц этого типа, если я не ошибаюсь, значит всё-таки косяк кроется в хостерском мускуле

Аватар пользователя FunnyPainters FunnyPainters 11 января 2010 в 21:03

RxB wrote:
Имелись ввиду скорее всего временные таблицы, но модуль search явно не создаёт таблиц этого типа, если я не ошибаюсь, значит всё-таки косяк кроется в хостерском мускуле

Да, именно временные таблицы имелись ввиду. А для сирха, для пятого друпала - желательно использовать временные таблицы.
Можете покопатся здесь — временные таблицы в drupal search