[ОТВЕТИТЬ]
11.12.2007 09:48
creosote
 
Несколько дней назад среднесуточная реализация не расчиталась в положенное время, начался бэкап и в логе получилась запись:
ORA-12012: ошибка при автоисполнении задания 81
ORA-20021: Сервер Супермага не запущен
ORA-06512: на "SUPERMAG.SCHEDULE", line 293
ORA-06512: на line 1
Запустил задание в обед, оно провисело до вечера, результата - ноль.
Пересоздал задание, запустил в 22:00 на свободной базе, провисело до 6-ти утра, результат отсутствует.

На сей момент имею отсутствие расчёта среднесуточной реализации за неделю, подскажите с чем может быть связано такое поведение задания?

Может есть внешняя функция с помощью которой можно расчитать среднесуточную реализацию, пока буду разбираться с проблемой?
11.12.2007 09:59
Mtirt
 
Job_queue_processes чему равно?
Увеличь этот параметр хотя бы на 1.
11.12.2007 10:07
creosote
 
Job_queue_processes = 5
Задание запускается под пользователем SUPERMAG это нормально?
11.12.2007 10:13
Mtirt
 
Задание запускается под тем пользователем, под которым оно создано.
Права у supermag на это есть.

В SSEventlog что по этому поводу написано?
11.12.2007 10:14
kadr
 
что значит провисело? в адм. модуле высветилось время начала 22-00 и просто не закончилось или задание даже не запустилось? Если запустилось и не закончилось, то что что делает в это время сессия на уровне базы? Сколько ещё заданий автоматически запускается? что написано в таблице sseventlog?
11.12.2007 10:31
creosote
 
Запустил руками(13-ое):

10.12.2007 12:47:52 Запуск задачи № 13
10.12.2007 17:13:05 FixRemains.Calc[M]:All = 23184295 Select = 0 Part = 0%
10.12.2007 17:13:05 FixRemains.Calc[E]:ORA-03113: принят сигнал конца файла по коммуникационному каналу
10.12.2007 21:44:57 Controller exit: 10.12.2007 21:44:57
10.12.2007 21:45:18 Remains.CalcFromGoods[M]:INSERT INTO TTRemains ( StoreLoc, Article, Quantity )( select Location, Art
10.12.2007 21:45:18 icle, - SUM(Quantity) Quantity from ( SELECT 2 Location, S.Article, SUM( S.Quantity * DECODE(2,D.L
10.12.2007 21:45:18 ocationTo,1,D.LocationFrom,-1,0)) Quantity FROM SmDocuments D , SmSpec S WHERE D.DocType = S.DocTyp
10.12.2007 21:45:18 e and D.ID = S.DocID and 2 in (D.LocationTo,D.LocationFrom) and D.DocState >= 2 and D.CreatedAt >
10.12.2007 21:45:18 :i_Date and S.Article in (select FData from TTFilterStr where FType=1) GROUP BY 2, S.Article HAVING
10.12.2007 21:45:18 SUM( S.Quantity * DECODE(2,D.LocationTo,1,D.LocationFrom,-1,0)) <> 0 UNION ALL SELECT StoreLoc, Art
10.12.2007 21:45:18 icle, - Quantity FROM SMGoods WHERE Quantity <> 0 and StoreLoc =2 and Article in (select FData from
10.12.2007 21:45:18 TTFilterStr where FType=1) ) group by Location, Article having SUM(Quantity) <> 0 )

Перестартовал базу:

10.12.2007 21:45:18 Remains.CalcFromGoods[E]:ORA-01089: никакие действия не разрешены, т.к. идет срочный останов
10.12.2007 21:45:18 Remains.Calc[E]:ORA-01089: никакие действия не разрешены, т.к. идет срочный останов
10.12.2007 21:45:18 ORA-01089: никакие действия не разрешены, т.к. идет срочный останов
10.12.2007 21:45:18 Сбой задачи №13, см. ошибки в предыдущем сообщении и доп. информацию в последующих
10.12.2007 21:45:18 Функция управления "Расчет среднесуточной реализации" (Управление складом)
10.12.2007 21:45:18 begin SmWHControlTask(13); end;
10.12.2007 21:45:43 Controller startup: 10.12.2007 21:45:43

Пересоздал задание(13-ое), запустилось по расписанию:

10.12.2007 22:00:05 Запуск задачи № 13
11.12.2007 0:15:05 Запуск задачи № 12
11.12.2007 0:16:31 Успешное завершение задачи № 12 (00ч 01м 26с)
11.12.2007 0:16:36 Запуск задачи № 12
11.12.2007 0:16:37 Успешное завершение задачи № 12 (00ч 00м 01с)
11.12.2007 0:17:02 Запуск задачи № 12
11.12.2007 0:17:02 Успешное завершение задачи № 12 (менее секунды)
11.12.2007 0:18:02 Запуск задачи № 12
11.12.2007 0:18:02 Успешное завершение задачи № 12 (менее секунды)
11.12.2007 0:19:02 Запуск задачи № 12
11.12.2007 0:19:02 Успешное завершение задачи № 12 (менее секунды)
11.12.2007 0:20:02 Запуск задачи № 12
11.12.2007 0:20:02 Успешное завершение задачи № 12 (менее секунды)
11.12.2007 0:21:02 Запуск задачи № 12
11.12.2007 0:21:02 Успешное завершение задачи № 12 (менее секунды)
11.12.2007 0:22:02 Запуск задачи № 12
11.12.2007 0:22:07 Успешное завершение задачи № 12 (00ч 00м 05с)
11.12.2007 0:23:02 Запуск задачи № 12
11.12.2007 0:23:02 Успешное завершение задачи № 12 (менее секунды)
11.12.2007 0:24:02 Запуск задачи № 12
11.12.2007 0:24:02 Успешное завершение задачи № 12 (менее секунды)
11.12.2007 0:25:02 Запуск задачи № 12
11.12.2007 0:25:02 Успешное завершение задачи № 12 (менее секунды)
11.12.2007 6:08:00 Controller exit: 11.12.2007 06:08:00
11.12.2007 6:08:10 Controller startup: 11.12.2007 06:08:10
11.12.2007 6:52:04 Controller exit: 11.12.2007 06:52:04
11.12.2007 6:53:03 Controller startup: 11.12.2007 06:53:03
11.12.2007 6:53:19 Controller exit: 11.12.2007 06:53:19
11.12.2007 6:53:30 Controller startup: 11.12.2007 06:53:30

По сей момент тишина.
11.12.2007 10:36
creosote
 
"что значит провисело? в адм. модуле высветилось время начала 22-00 и просто не закончилось или задание даже не запустилось?"

Высветилось начало в 22-00 и так и осталось в таком состоянии до утра.

" Если запустилось и не закончилось, то что что делает в это время сессия на уровне базы? "

На уровне базы сессия читает с диска(смотрю Spotlight-ом, количество чтений с диска увеличивается, загрузка ЦП этой сессией всегда 0)

"Сколько ещё заданий автоматически запускается?"

Запускается всго 2 задания:
Регистрация актов переоценки(12-ое)
Расчёт среднесуточной реализации(13-ое)
11.12.2007 10:40
kadr
 
alert.log смотрел? есть там ошибки в период с 10.12.2007 22:00:00 по 11.12.2007 6:08:00?

Такое ощущение что задание не запустилось, либо запустилось и умерло не дав об этом знать, а может просто не смогло получить какую либо блокировку, т.к. у тебя в 6 часов несколько раз перезапускался сервер СуперМага, а задание не дало о себе знать диким воплем что сервер СуперМага не запущен

так же неплохо посмотреть что во вьюхе svjobs в столбце isbroken
11.12.2007 10:44
kadr
 
Цитата:
creosote
На уровне базы сессия читает с диска(смотрю Spotlight-ом, количество чтений с диска увеличивается, загрузка ЦП этой сессией всегда 0)
Раз через Spotlight, смотришь, то что в строке "Waiting for"? все ли индикаторы у тебя зелёные?
Точно пересоздал с теми же параметрами? может указал интервал для расчёта большой?
11.12.2007 10:48
creosote
 
в alert.log за этот период ошибок нет.
В стольбце isbroken стоят нули на оба задания.

Какие блокировки требуются для этого задания?
Запускал его после рестарта базы, поздно вечером наличие пользователей исключено.
11.12.2007 11:02
creosote
 
"Раз через Spotlight, смотришь, то что в строке "Waiting for"? все ли индикаторы у тебя зелёные? "
В строке Waiting for - db file parallel read, и далее путь к файлу базы Users.dbf, ожидаемые файлы меняются и чтение вроде идёт, т.к.
Wait state/time: In waiting(0s) всё время, Physical redas и Consistent gets увеличиваются, следил целый день.
Индикаторы в основном зелёные, временами буфер уходит в рыжий.

"Точно пересоздал с теми же параметрами? может указал интервал для расчёта большой?"

Пересоздал с параметрами по умолчанию. На всех группах товаров стоит Диапазон расчёта: последние 14 дней.
11.12.2007 12:41
creosote
 
Смущает продолжительность попытки расчёта, ведь последний удачный расчёт длился чуть больше часа, а теперь не хватает 8-ми часов для его завершения.
11.12.2007 13:12
kadr
 
а попутно никакие параметры базы не менялись?
11.12.2007 14:41
creosote
 
Последние изменения.

Параметр job_queue_processes был равен 1 при этом работало, теперь:
job_queue_processes=5
session_cached_cursors=50
max_rollback_segments=200
optimizer_index_cost_adj=2
pga_aggregate_target=419430400
sort_area_size=0
db_file_multiblock_read_count=8

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

Посмотрел по v$session сессию этого задания(оно сейчас запущенно) возник вопрос - нормально ли что поле PROCESS пустое?
11.12.2007 16:06
kadr
 
Цитата:
creosote Последние изменения.

Параметр job_queue_processes был равен 1 при этом работало, теперь:
job_queue_processes=5
session_cached_cursors=50
max_rollback_segments=200
optimizer_index_cost_adj=2
pga_aggregate_target=419430400
sort_area_size=0
db_file_multiblock_read_count=8

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

Посмотрел по v$session сессию этого задания(оно сейчас запущенно) возник вопрос - нормально ли что поле PROCESS пустое?
я бы вернул все параметры на те которые были раньше и проверил на них за сколько отрабатывает задание. Так как очень похоже что съехали планы выполнения и теперь требуется намного больше времени на его отработку
11.12.2007 16:14
creosote
 
После смены параметров выполнял сбор статистики, следует ли мне пробовать возвращать все параметры в предыдущее состояние(это несколько проблематично)?
11.12.2007 16:26
kadr
 
max_rollback_segments=200
job_queue_processes=5

можно оставить,
всё остальное вернуть обратно, пересчитать статистику и сравнить. А уж потом оценивать есть эффект или нет
11.12.2007 17:05
creosote
 
Спасибо, сегодня вечером попробую.

Сейчас у меня план вот такой:
(прикрепил)
Вложения
Тип файла: txt plan.txt (4.7 Кб, 140 просмотров)
12.12.2007 09:47
creosote
 
Вернул параметры в следующее состояние:

db_file_multiblock_read_count=32
optimizer_index_cost_adj=30
pga_aggregate_target=209715200
session_cached_cursors=0
sort_area_size=8192000

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

Всем, кто проявил внимание, большое спасибо, Вы мне очень помогли!
12.12.2007 10:38
OlegON
 
Цитата:
creosote sort_area_size=0
Это зачем? Если хочешь, чтобы оно было неустановлено, то снимай его, а не в ноль устанавливай.
12.12.2007 11:14
creosote
 
Хочу, чтобы sort_area_size было неустановлено, поставив его в ноль думал, что именно снимаю его. Как правильно снять этот параметр, чтобы он не учитывался?
12.12.2007 11:39
OlegON
 
Делаешь pfile из spfile, вырезаешь этот параметр, делаешь spfile из pfile... А так - вообще не знаю, что это будет...
12.12.2007 13:18
kadr
 
Цитата:
creosote Хочу, чтобы sort_area_size было неустановлено, поставив его в ноль думал, что именно снимаю его. Как правильно снять этот параметр, чтобы он не учитывался?
Очччень странное желание, ведь это размер памяти выделяемой процессу для операций сортировки, и если этот параметр недостаточный, то Оракель начинает производить сортировки во временном ТС, т.е. на диске, а это в свою очередь в большинстве случаев катастрофически снижает скорость.
Я видел у тебя установлен pga_aggregate_target, значит делаем допущение что Оракель у тебя 9-ый, а в 9-ке есть параметр workarea_size_policy, если его установить в auto то Оракель будет игнорировать установленные значения sort_area_size.
Ещё вижу
max_rollback_segments=200, я бы рекомендовал автоматическое управление сегментами отката.
session_cached_cursors=0, мысли правильные у тебя, нужно увеличивать
12.12.2007 15:03
creosote
 
Цитата:
kadr Очччень странное желание, ведь это размер памяти выделяемой процессу для операций сортировки, и если этот параметр недостаточный, то Оракель начинает производить сортировки во временном ТС, т.е. на диске, а это в свою очередь в большинстве случаев катастрофически снижает скорость.
Я видел у тебя установлен pga_aggregate_target, значит делаем допущение что Оракель у тебя 9-ый, а в 9-ке есть параметр workarea_size_policy, если его установить в auto то Оракель будет игнорировать установленные значения sort_area_size.
Ещё вижу
max_rollback_segments=200, я бы рекомендовал автоматическое управление сегментами отката.
session_cached_cursors=0, мысли правильные у тебя, нужно увеличивать
Оракл у меня действительно 9-ый, желание сбросить sort_area_size было обусловлено незнанием действия параметра workarea_size_policy. workarea_size_policy=auto, значит, если я правильно понял, sort_area_size можно отсавить в покое.

Подскажи пожалуйста, как поставить автоматическое управление сегментами отката?

Ещё меня очень интересует вопрос - как правильно определить значение параметра optimizer_index_cost_adj?
12.12.2007 16:13
creosote
 
Ага, у меня undo_management=auto.

По поводу optimizer_index_cost_adj:
Этот запрос

select substr(event, 1, 20), average_wait, time_waited/total_waits
from v$system_event
where event like 'db file s%'

Выдаёт:

db file sequential read
average_wait=2
time_waited/total_waits=1,8070314483574691304823820715711600323
db file scattered read
average_wait=0
time_waited/total_waits=,15874361878311545663048983842787304152

Подскажите пожалуйста, как из этих цифр получить optimizer_index_cost_adj?
12.12.2007 22:27
OlegON
 
Забей на этот запрос и поставь пока optimizer_index_cost_adj = 2, у меня, например, выше просто не живет автозаказ, независимо от multiblock_read_count. База большая? А то, может, рано это все крутить... До 30Гб гоняй оптимайзер и не парься :)
12.12.2007 23:15
kadr
 
to creosote послушай OlegON`a, без явных тормозов на каких-то из моментов не дело крутить параметры базы, яркий пример ты нам сам и продемонстрировал
13.12.2007 09:44
creosote
 
Цитата:
OlegON Забей на этот запрос и поставь пока optimizer_index_cost_adj = 2, у меня, например, выше просто не живет автозаказ, независимо от multiblock_read_count. База большая? А то, может, рано это все крутить... До 30Гб гоняй оптимайзер и не парься :)
База большая, да, уже больше 100 Гб, просто есть подозрение, что именно из-за optimizer_index_cost_adj = 2 не делается расчёт среднесуточной.

Проблема как-раз в том, что явные тормоза имеются, когда становлюсь на карточку и открываю закладку Заказ, пирходится ждать от 20-ти, до 40-ка секунд. Начал крутить параметры - отвалился расчёт среднесуточной. Пользователи недовольны ессесьно. Полная оптимизация базы была где-то месяц назад, каждый третий день делаю сбор статистики, попробую сделать в эти выходные оптимизацию, может отживеет.
13.12.2007 10:02
kadr
 
Цитата:
creosote Проблема как-раз в том, что явные тормоза имеются, когда становлюсь на карточку и открываю закладку Заказ, пирходится ждать от 20-ти, до 40-ка секунд. ...
а если убрать галочку "Поставщики" на сколько меняется вермя ожидания?

ПыСы. Да и наверно нужно уже другую тему начинать, с текущим вопросом то уже закончили
13.12.2007 10:32
creosote
 
Цитата:
kadr а если убрать галочку "Поставщики" на сколько меняется вермя ожидания?

ПыСы. Да и наверно нужно уже другую тему начинать, с текущим вопросом то уже закончили
Хех, без Поставщиков время ожидания резко меняется в лучшую сторону. Спасибо, очень помогли.

Пожалуй, действительно пора начинать новую тему, но уже с совершенно новым вопросом.


Опции темы


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

 

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