[ТЕМА ЗАКРЫТА]
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
 
Чувствую, что не в тему ляпну, но все-же:
Может быть, запустить задания на пересоздание индексов в Адм. модуле?
У нас как-то были тормоза дикие, решилось запуском заданий...

з.ы. если ступил, не ругайте строго:)
17.11.2008 16:25
dmware
 
Цитата:
Mihon Чувствую, что не в тему ляпну, но все-же:
Может быть, запустить задания на пересоздание индексов в Адм. модуле?
У нас как-то были тормоза дикие, решилось запуском заданий...

з.ы. если ступил, не ругайте строго:)
уже пересоздавал..., увы, это не поможет...
прихожу к выводу, что оракл по собственной инициативе решает, что обращение не по индексу будет перспективней в плане скорости...
набрел тут на раздел, где обсуждалась похожая проблема:

решение на пятой странице. мне оно никак вроде бы и не подходит, или же я просто не углядел пока
18.11.2008 07:44
dmware
 
повозился с параметрами оптимайзера... в результате несколько уменьшилось время выборки документов. но по-прежнему очень долгие апдейты.. например, клиентский модуль практически умирает на некоторое время при смене статуса документа.
расчет себестоимости вылетел с той же ошибкой...
что делать?
18.11.2008 10:25
deucel
 
Цитата:
dmware прихожу к выводу, что оракл по собственной инициативе решает, что обращение не по индексу будет перспективней в плане скорости...
попробуй в параметрах БД

optimizer_index_caching = 90
optimizer_index_cost_adj = 10

последний параметр можно при необходимости опускать еще, но лучше не стоит - будет вылазить в других местах.
18.11.2008 10:29
deucel
 
Цитата:
dmware повозился с параметрами оптимайзера... в результате несколько уменьшилось время выборки документов. но по-прежнему очень долгие апдейты.. например, клиентский модуль практически умирает на некоторое время при смене статуса документа.
расчет себестоимости вылетел с той же ошибкой...
что делать?
Если сервера хватает - то похоже проблемы в параметрах БД (initDBname.ora)
если не сложно - покажи, мож чего посоветуем.
18.11.2008 13:18
dmware
 
Цитата:
deucel попробуй в параметрах БД

optimizer_index_caching = 90
optimizer_index_cost_adj = 10

последний параметр можно при необходимости опускать еще, но лучше не стоит - будет вылазить в других местах.
вчера пришел именно к этому... причем увеличение производительности было отмечено. но только на выборке документов и очень незначительное.

первоначальные установки:
optimizer_index_caching = 0
optimizer_index_cost_adj = 70

правда до этого (до операции экспорта/импорта) все было именно так и работало неплохо.
еще параметр db_file_multiblock_read_count с 24 до 16
18.11.2008 13:34
dmware
 
Цитата:
deucel Если сервера хватает - то похоже проблемы в параметрах БД (initDBname.ora)
если не сложно - покажи, мож чего посоветуем.
*.compatible='9.2.0.0.0'
*.control_files='R:\ORACLE\ORADATA\DBCOSTR\CONTROL01.CTL','T:\ORACLE\ORADATA\DBCOSTR\CONTROL02.CTL'
*.core_dump_dest='c:\oracle\admin\dbcostr\cdump'
*.cursor_sharing='SIMILAR'
*.db_block_checksum=FALSE
*.db_block_size=8192
*.db_cache_advice='OFF'
*.db_cache_size=1543503872
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_keep_cache_size=268435456
*.db_name='DBCOSTR'
*.db_writer_processes=4
*.dispatchers='(PROTOCOL=TCP) (SERVICE=dbcostrXDB)'
*.fast_start_mttr_target=300
*.hash_join_enabled=TRUE
*.instance_name='DBCOSTR'
*.java_pool_size=33554432
*.job_queue_processes=10
*.large_pool_size=8388608
*.log_buffer=524288
*.O7_DICTIONARY_ACCESSIBILITY=TRUE
*.open_cursors=200
*.optimizer_index_caching=90
*.optimizer_index_cost_adj=10
*.optimizer_mode='CHOOSE'
*.parallel_automatic_tuning=TRUE
*.pga_aggregate_target=301989888
*.processes=300
*.query_rewrite_enabled='FALSE'
*.remote_login_passwordfile='EXCLUSIVE'
*.session_cached_cursors=100
*.sga_max_size=2207330416
*.shared_pool_size=201326592
*.sort_area_size=65536
*.star_transformation_enabled='FALSE'
*.timed_statistics=TRUE
*.undo_management='AUTO'
*.undo_retention=10800
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='c:\oracle\admin\dbcostr\udump'
18.11.2008 13:50
deucel
 
не считая остального - твоя проблема в

Цитата:
dmware *.cursor_sharing='SIMILAR'
он отрабатывает также как и 'FORCE'

поставь стандартный 'EXACT'
18.11.2008 13:56
deucel
 
ну или к примеру на магазинах у меня для CPU c HT и 1Гб памяти

Код:
*.background_dump_dest='D:\oracle\oradata\DBname\bdump'
*.compatible='9.2.0.8.0'
*.control_files='D:\oracle\oradata\DBname\control01.ctl','D:\oracle\oradata\SEMIL01\control02.ctl','D:\oracle\oradata\DBname\control03.ctl'
*.core_dump_dest='D:\oracle\oradata\DBname\cdump'
*.cpu_count=1
*.db_block_checksum=FALSE
*.db_block_size=8192
*.db_cache_size=268435456
*.db_domain=''
*.db_file_multiblock_read_count=64
*.db_name='DBname'
*.db_writer_processes=1
*.dbwr_io_slaves=2
*.fast_start_mttr_target=300
*.filesystemio_options='SETALL'
*.instance_name='DBname'
*.job_queue_processes=5
*.log_buffer=10485760
*.max_dump_file_size='1024'
*.O7_DICTIONARY_ACCESSIBILITY=TRUE
*.optimizer_index_caching=90
*.optimizer_index_cost_adj=10
*.parallel_automatic_tuning=TRUE
*.pga_aggregate_target=134217728
*.pre_page_sga=TRUE
*.processes=100
*.remote_login_passwordfile='EXCLUSIVE'
*.shared_pool_size=134217728
*.timed_statistics=TRUE
*.transactions_per_rollback_segment=1
*.undo_management='AUTO'
*.undo_retention=10800
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='D:\oracle\oradata\DBname\udump'
*.workarea_size_policy='AUTO'
18.11.2008 14:19
dmware
 
Цитата:
deucel не считая остального - твоя проблема в



он отрабатывает также как и 'FORCE'

поставь стандартный 'EXACT'
а как же (цитата - с установленным параметром CURSOR_SHARING=EXACT (устанавливается по умолчанию) для каждого уникального SQL-оператора, который я выполняю, в представлении V$SQL создается новая запись – выполняется полный разбор оператора и для него создается новый план выполнения. В разделяемом пуле могут находиться сотни и тысячи очень похожих запросов, которые отличаются только литералами, используемыми в SQL-операторах. Это означает, что в приложении не используются переменные связывания, и это также означает, что сервер базы данных вынужден выполнять полный разбор практически каждого запроса, который, в свою очередь, не только потребляет много процессорного времени...

и вот тоже ( Здесь видно, что для EXACT сколько запросов (отличающихся только литералом) мы будем выполнять, столько и будет полных разборов, построений планов. Таких запросов в системе может быть на столько много, что сервер не сможет справиться с их разбором.
При прочих значениях параметра сursor_sharing, можно наглядно видеть, что только один запрос находиться в shared pool. И все сессии могут использовать план этого запроса. То есть полный разбор, построение плана производится один раз, а выполняется – много раз. Следствием этого является уменьшение количества полных разборов (они превращаются в частичный). А это значит, что потребляется меньше ресурсов (процессорное время, конкуренция в библиотечном кеше, размер разделяемого пула,…), производительность растет...

разве с параметром EXACT наоборот не упадет производительность? конечно же я поэкспериментирую - мне больше ничего не остается. но все таки?
хотя, с другой стороны - для запросов не подменяются планы...
18.11.2008 14:43
baggio
 
я бы прибавил *.sort_area_size=65536
до метра хотябы...
и
*.log_buffer=10485760 ...
18.11.2008 15:04
deucel
 
Цитата:
baggio я бы прибавил *.sort_area_size=65536
до метра хотябы...
Тогда уж
WORKAREA_SIZE_POLICY = AUTO

18.11.2008 20:00
dmware
 
так.. провел серию тестов после рабочего дня..
переиндексация... затем увиличил оба параметра:

Цитата:
baggio я бы прибавил *.sort_area_size=65536
до метра хотябы...
и
*.log_buffer=10485760 ...
получил... понижение производительности... неожиданно...
оцениваю следующим образом - собственно чрезвычайно долгая выборка документов (приходные накладные выбираю)...
у меня получилось вместо полутора минут за выбранный мною период (5 дней по одному из магазинов) до смены параметров, две с копейками...
вернул все обратно... далее...
расчет статистики, полный, в административном модуле... та же выборка - не дождался результата (> 5-7 минут)...
удалил статистику по схеме... просто, чтобы посмотреть, что получится...
begin
dbms_stats.delete_schema_stats(
ownname => 'supermag'
);
end;
вдруг выясняется, что теперь документы выбираются за полторы минуты... медленно, но это не предыдущий вариант...
собираю статистику тем же заданием - больше 5 минут. просто уже не дождался...
все это время системным монитором наблюдаю постоянное обращение к диску, где у меня размещены файлы userXX.dbf. при этом обращения к индексам почти нет...
да, пробовал устанавливать cursor_sharing как в EXACT, так и возвращал обратно. никакой разницы не заметил. параметр динамический, для чистоты эксперимента перезапускал экземпляр...
собственно ни к чему не пришел:)
18.11.2008 20:28
OlegON
 
Цитата:
*.db_writer_processes=4
этого не надо вообще
Цитата:
*.log_buffer=524288
это бы увеличить до 10М
Цитата:
*.query_rewrite_enabled='FALSE'
?
Цитата:
*.sga_max_size=2207330416
а база часом не свопается?
Цитата:
*.sort_area_size=65536
это не надо
cursor_sharing лучше не трогать, оно неадекватно влияет... Почтовик летает, отчеты проседают до жути.
Индексы надо отребилдить вручную, статистику собрать через analyze. Встроенным заданиям верить не надо, кроме проведения актов и сбора мусора они ничего толком не умеют.
Прочитал ветку и не понял, что проседает-то? Проц? Винты? Планы бы посмотреть. То, что ты выбрал в начале - неудачный пример.
19.11.2008 10:01
dmware
 
Цитата:
OlegON ...
Индексы надо отребилдить вручную, статистику собрать через analyze. Встроенным заданиям верить не надо, кроме проведения актов и сбора мусора они ничего толком не умеют.
Прочитал ветку и не понял, что проседает-то? Проц? Винты? Планы бы посмотреть. То, что ты выбрал в начале - неудачный пример.
При выборке, например, приходных накладных за некоторый период, процесс oracle.exe - 87-100%, обращение к винту, на котором лежат userx.dbf, к индексам обращения практически нет (2-10%) и очень долго формируется результат: против обычных секунд - долгие минуты.
В настоящий момент занялся перестройкой индексов по таблицам с документами...
Перестроил вручную на smspec - больше не успел - запустил пользователей - вечером продолжу...
после перестройки (а еще пересоздал первичный ключ, внешние ключи...) собрал статистику вручную (все так же):
begin
dbms_stats.gather_schema_stats (
ownname => 'SUPERMAG',
cascade => TRUE,
estimate_percent => dbms_stats.auto_sample_size,
method_opt=>'for all columns size auto'
);
end;
пока все по-прежнему...
сейчас наблюдаю обращение к юзерс - 100%, индексы тоже задействованы... такое ощущение, что действительно по какой-то из таблиц, в которой информация с документами, проблема с индексами... остальные то разделы замечательно работают...
19.11.2008 10:07
dmware
 
во время выполнения выборки из своей сессии посмотрел самый массивный запрос:
Код:
SELECT --+ FIRST_ROWS
 DH.ID as ID, DH.CreatedAt, CL.Name as ClientName, DH.LocationTo, DH.OpCode as Operation, DH.UserOp, DH.TotalSum, DH.Debt as Payment, DH.BaseDocTypeAndID, DH.DocState, (select (select nvl(Sum(SPECV.TotalPrice), :"SYS_B_00") from Supermag.SVSpecWI SPECV where SPECV.DocType = DH.DocType and SPECV.DocID = DH.ID) - (select nvl(Sum(SVAT.TaxSum), :"SYS_B_01") from Supermag.SVSpecVatWI SVAT where SVAT.DocType = DH.DocType and SVAT.DocID = DH.ID and SVAT.TaxRate > :"SYS_B_02") from Dual) as TotalSumNoVat, (select nvl(Sum(SVAT10.TaxSum),....
отсюда обращение к представлениям, за которыми стоят указанные таблицы...
SVSpecWI(SLSPECQMISMATCH, SMCARD, SMCOMMONBASES, SMSPECCOMPINF, SMSPECIO)
SVSpecVatWI(SMSPECTAX, SMTAXIDENTITY)
SVInsertedDocsWI (SMDOCBLOBFILES)
SVDocumentsWI (SMDOCTAX, SMDOCUMENTS, SMPARTNERUSERLOC, SMTAXIDENTITY, SMWAYBILLSIN)

наверное следует для них вручную пересоздать индексы и посмотреть, что из этого получится?
еще хотел отметить достаточно быструю выборку документов, ассоциированных с артикулом в карточке товара (раздел документы). а ведь там документы разных типов... возможно выборка в этих разделах ведется из разных таблиц
19.11.2008 10:36
dmware
 
Цитата:
OlegON статистику собрать через analyze
только сейчас заметил - пропустил.. попробую сделать так
19.11.2008 10:42
Mtirt
 
Тогда еще заодно и
ANALYZE TABLE problem_table VALIDATE STRUCTURE CASCADE OFFLINE
20.11.2008 13:09
baggio
 
а ктонить такое видел..
1.26.1. SP4

SQL*Loader: Release 9.2.0.8.0 - Production on Чтв Ноя 20 12:54:53 2008

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Управляющий файл: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.CTL
Файл данных: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.DAT
Строка опций обработки файла: "fix 123"
Файл плохих записей: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\PathFinder_FFMapOutIn0.bad
Файл удаленных записей: ничего не задано

(Разрешить удалять все записи)

Количество записей для загрузки: ALL
Количество записей для пропуска: 0
Допускается ошибок: 0
Продолжение: ничего не задано
Использован маршрут: Прямой
Бесшумные режимы: FEEDBACK, ERRORS и DISCARDS

Таблица SUPERMAG.FFMAPOUTIN, загружен из каждой логической записи.
Режим вставки действует для этой таблицы: INSERT

Имя столбца Позиция Дл. Огр. Вкл Тип данных
------------------------------ ---------- ----- ---- ---- ---------------------
INCOMEDOC FIRST 4 INTEGER
INCOMEITEM NEXT 4 INTEGER
SALEDOC NEXT 4 INTEGER
SALEITEM NEXT 4 INTEGER
QUANTITY NEXT 8 DOUBLE
ARTICLE NEXT 50 CHARACTER
SALEOP NEXT 2 SMALL INTEGER
INCOMEOP NEXT 2 SMALL INTEGER
SALEDATE NEXT 8 DATE YYYYMMDD
INCOMEDATE NEXT 8 DATE YYYYMMDD
FORCEDMAPPING NEXT 1 CHARACTER
INCOMEQ NEXT 8 DOUBLE
INCOMETOTALSUM NEXT 10 PACKED DECIMAL (19, 4)
INCOMETOTALNOVAT NEXT 10 PACKED DECIMAL (19, 4)

SQL*Loader-929: Ошибка при синтаксическом анализе команды вставки для таблицы SUPERMAG.FFMAPOUTIN.
ORA-01031: привилегий недостаточно
20.11.2008 13:19
kadr
 
такое видели ещё 2 года назад вот тут
20.11.2008 13:31
dmware
 
Цитата:
Mtirt Тогда еще заодно и
ANALYZE TABLE problem_table VALIDATE STRUCTURE CASCADE OFFLINE
после этой проверки, которая продолжалась много часов, а также пересоздания индексов для таблиц, которые участвуют при выборке документов (выше) ничего разительно не изменилось.
статистка была собрана, также пробовал ее удалять.
взял два запроса:
1-й участвует при выборке накладных,
2-й - тот, что используется в карточке товара (из сессии)
таблицы те же самые. только второй отрабатывает за секунды даже при большом интервале.
в первом участвуют представления.
по дискам видно, что во втором задействуются индексы.
на настоящий момент идей нет никаких, кроме как удалить представления, создать их заново (просто еще не успел)
сейчас идет расчет себестоимости, который продолжается уже почти 11 часов (операция переноса остатков)


Опции темы


Часовой пояс GMT +3, время: 16:58.

 

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