17.11.2008 07:17
dmware
 
Нужна помощь!
Расчет себестоимости вывалился с ошибкой...

ORA-01410: ROWID неверен
ORA-06512: ia "SUPERMAG.FIFOTRANSFER", line 216
ORA-06512: ia "SUPERMAG.FIFOTRANSFER", line 359
ORA-06512: ia "SUPERMAG.FIFOTRANSFER", line 816
ORA-06512: ia "SUPERMAG.FIFOTRANSFER", line 843
ORA-06512: ia "SUPERMAG.SMRUNTRANSFER", line 6
ORA-06512: ia line 1

{ call Supermag.SMRunTransfer(?, ?) }
Params:
{0} (null)[0](0,0): vt=7 value=16.11.2008
{1} (null)[0](0,0): vt=7 value=16.11.2008

Что можно сделать? Где смотреть?
Возможно это как-то связано с очень медленной обработкой некоторых запросов? Например, выборка накладных за 15 последних дней выполняется на протяжении 15(!) минут... Отображение текущих остатков или выполнение рукописных отчетов по реализации (использую SMDOCUMENTS, SMSPEC...) по времени в пределах нормы...
17.11.2008 09:07
Mtirt
 
Надо смотреть в глубь Alert.log
Но похоже, что экспорт/импорт не помог.

Что касается медленной работы: статистика по таблицам после импорта собиралась? По temp-овым таблицам может имеет смысл удалить статитсику?
17.11.2008 09:27
dmware
 
Цитата:
Mtirt Надо смотреть в глубь Alert.log
Но похоже, что экспорт/импорт не помог.

Что касается медленной работы: статистика по таблицам после импорта собиралась? По temp-овым таблицам может имеет смысл удалить статитсику?
в том то и дело, что в alert.log ничего страшного нет... лишь последовательные вставки в redo, типа:

Thread 1 advanced to log sequence 934
Current log# 1 seq# 934 mem# 0: R:\ORACLE\ORADATA\DBCOSTR\REDO01.LOG

Статистика собиралась неоднократно административными заданиями.
17.11.2008 10:59
Kryukov
 
Цитата:
dmware в том то и дело, что в alert.log ничего страшного нет... лишь последовательные вставки в redo, типа:

Thread 1 advanced to log sequence 934
Current log# 1 seq# 934 mem# 0: R:\ORACLE\ORADATA\DBCOSTR\REDO01.LOG

Статистика собиралась неоднократно административными заданиями.
а не через административные задания статистику собирал ?
17.11.2008 11:43
dmware
 
Цитата:
Kryukov а не через административные задания статистику собирал ?
нет, не собирал...
при помощи - dbms_stats?
17.11.2008 11:53
kadr
 
Цитата:
dmware нет, не собирал...
при помощи - dbms_stats?
или analyze table...
17.11.2008 14:53
dmware
 
Цитата:
kadr или analyze table...
Посмотрел план выполнения запроса (select * from supermag.smspec where docid in('КЗ01200282')) - SELECT STATEMENT, GOAL = CHOOSE 1307 1786 105374
TABLE ACCESS FULL SUPERMAG SMSPEC 1307 1786 105374
- как я понимаю, индексы не используются. Вот и причина?...
Выполнил сбор статистики вручную следующим образом (правильно?):

begin
dbms_stats.gather_schema_stats (
ownname => 'SUPERMAG',
cascade => TRUE,
estimate_percent => dbms_stats.auto_sample_size,
method_opt=>'for all columns size skewonly'
);
end;

Перезапустил базу. План запроса не изменился... как, собственно, и скорость работы с документами...
17.11.2008 15:40
kadr
 
Цитата:
dmware Посмотрел план выполнения запроса (select * from supermag.smspec where docid in('КЗ01200282')) - SELECT STATEMENT, GOAL = CHOOSE 1307 1786 105374
TABLE ACCESS FULL SUPERMAG SMSPEC 1307 1786 105374
- как я понимаю, индексы не используются. Вот и причина?...
Выполнил сбор статистики вручную следующим образом (правильно?):

begin
dbms_stats.gather_schema_stats (
ownname => 'SUPERMAG',
cascade => TRUE,
estimate_percent => dbms_stats.auto_sample_size,
method_opt=>'for all columns size skewonly'
);
end;

Перезапустил базу. План запроса не изменился... как, собственно, и скорость работы с документами...
Этот запрос выдаёт СМ или это от ваших приложекний?
А если переписать запрос так
Код:
select * from supermag.smspec where docid ='КЗ01200282' and docpyte='тип документа'
Просто сама конструкция in медленная, так ещё и индекс уникальный по двум полям построен, поэто Оракель и не может понять что именно от него хотят.
17.11.2008 15:56
dmware
 
Цитата:
kadr Этот запрос выдаёт СМ или это от ваших приложекний?
А если переписать запрос так
Код:
select * from supermag.smspec where docid ='КЗ01200282' and docpyte='тип документа'
Просто сама конструкция in медленная, так ещё и индекс уникальный по двум полям построен, поэто Оракель и не может понять что именно от него хотят.
Так... План запроса получил через PL/SQL Developer. По второму запросу:
SELECT STATEMENT, GOAL = CHOOSE 4 5 265
TABLE ACCESS BY INDEX ROWID SUPERMAG SMSPEC 4 5 265
INDEX RANGE SCAN SUPERMAG SMCSPEC_DISPLAYPOS 5 5

Все-таки, выходит, индексы используются...
Первый запрос - 0,266с
Второй запрос - 0,047с
Работа с документами по-прежнему очень медленная.. что же еще можно предпринять?
17.11.2008 16:16
Mihon
 
Чувствую, что не в тему ляпну, но все-же:
Может быть, запустить задания на пересоздание индексов в Адм. модуле?
У нас как-то были тормоза дикие, решилось запуском заданий...

з.ы. если ступил, не ругайте строго:)
Часовой пояс GMT +3, время: 00:17.

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.