Тормоза в СМ2000.

Тормоза в СМ2000.

(СМ2000 вер. 1.24.3. на 8 -м ORACLе)
Столкнулся со следующей ситуацией: ранее процессы ORACLE на серваке откушивали
не более 25% ресурса. Вчера ORACLE начал постепенно загребать до 100% ресурсов,
сооветсвенно начались тормоза. Попробывали переиндексацию БД (через админовский модуль)
такое ощущение, что процедура некорректно отработала СМ2000 стартует, но через час работы, все теже 100% ресурса, кассовые документы и весы грузятся с дикими тормозами.

Вопрос есть ли какой нибудь механизм контроля целостности индексов, и быстрая процедура
их востановления (из админовского модуля более 2-х часов).

Есть механизм поиска по форуму. :( Сделай оптимайзером /optimize и лог на обменник выложи.

Оптимайзер, я думаю.
Да, похоже на инвалидный индекс.

Оптимайзер под 1.24.3 ?
Созрел перейти на 1.24.6 и 9-й Oracle. Вопрос стоит ли прогнать ли оптимайзер перед импортом экспортом.

после поиска по темам нарвался на такой запрос

select t.table_name, t.last_analyzed, t.num_rows
from all_tables t
where t.table_name in ('FFMAPREP', 'SMSPEC');

Вот результат по моей базе

SMSPEC
FFMAPREP 21.03.07 7:08:32 3665958

Вопрос, почему нет анализа по спеку

yurakor, да запусти ты оптимайзер, как Олег рекомендует...

сейчас..запускать буду оптимайзер, но если кто знает подскажите откуда появляется last_analyzad, после какого действия?? Что это last_analyzad?

А в базе, в адм. модуле есть задание на расчет статистики?

нет...этой ночью был запущен полный перерасчет индексов через адм. модуль...вот и все задания

Статистика по аналититическим таблицам рассчитывается при расчете товародвижения автоматически.
По всем остальным - по расписанию, по заданию в административном модуле.

Оптимайзер конечно посчитает статистику. Но задание лучше сделать все-таки. Хоть раз в месяц...

так это поле - это полный сбор статистики? (я про запрос см. выше)

Этот запрос показывает дату, время сбора статистики и количество записей на момент ее сбора.

Восстановили базу
Сделали полную перестройку индексов через админ. модуль
Прогнали оптимайзер с ключем \optimize

Полный рассчет аналитики

Кассовые документы перестали выгружаться с УКМ4 сервера ругань
Запись 1. Код=80004005h (0) [SMUKMD~1]:
Ошибка при попытке импорта записи из таблицы CASHSAIL. Ключ записи "ShopIndex=2,CashNumber=1,ZNumber=208,CheckNumber=1,ID=1".

Запись 2. Код=80004005h (1502) [Microsoft OLE DB Provider for Oracle]:
ORA-01502: индекс 'SUPERMAG.SMCCASHCHECKITEMS_PK' или часть такого индекса находится в неиспользуемом состоянии

OlegON: За заливку временных файлов на форум буду наказывать

Еще раз оптимайзер. Иногда приходится 3-4 раза подряд прогонять.
или

И еще, а место у тебя в базе есть?

Оптимайзер не только прогонять нужно, но и читать лог, что он туда пишет. Поправь, у тебя там warning'ов море, включая нехватку места в базе.

Сорри за файл (не знал куда залить)...место как раз теперь все время не хватает после оптимизатора...каждый день приходится добавлять новые файлы users. На форуме прочитал, что это нормальный процесс после оптимизации и со временем и старые users будут нормально работать.
Если не сложно, можно ли подсказать таблицу где хранится флаг автоматического обновления ассортимента. Что-то пока никак не найду

Таблицу не знаю. Убирали галочку вручную во всех ассортиметах...

я так понимаю, надо посмотреть на SACardAssort.flags (только не спрашивай про структуру этого флага; включи обновление да посмотри как он поменялся и поменялся ли)
если окажется, что не оно - значит тебе в SMCardAssortRules. там сами правила обновления живут. наличие правила - чем не флаг? *05

спасибо полезу поищу....главная сейчас проблема что файлы users пожирает по 2Гб как-будто до этого база пустая была

Для работы большинства функций, выполняемых оптимайзером нужно, чтобы в базе было столько же свободного места, сколько занято данными.
Так что не жадничай, добавляй.
Думаю, выделить место на диске не так уж сложно.

UPDATE supermag.sacardassort SET flags = '2' WHERE flags = '10';
COMMIT ;

спасибо за помощь...места хватает я добавляю )