Форум OlegON > Ресурсы OlegON > Вопросы сервера > Программы OlegON

Оптимайзер-4 (вопросы и обсуждения) : Программы OlegON

26.04.2024 22:42


16.07.2013 12:04
omnomnom
 
немного непонятно откуда программа берет время. в логе сейчас 16.07.13 03:29:41, а системное 11.04.
16.07.2013 12:07
OlegON
 
предлагаю разобраться с установленной Java и часовым поясом в системе.
16.07.2013 12:43
omnomnom
 
обновил яву. взлетело
26.07.2013 18:27
omnomnom
 
еще пару вопросов накопилось.
оптимайзер пару лет назад запускали на этой базе и в таблице настроек был записан email администратора.
С недавнего времени мы начали использовать оптимайзер снова. предварительно я затер все поля в которых был старый email. и вписал свой. но программа упорно продолжает слать уведомления о отсутствии связи на старый email. где что я пропустил?

Второй вопрос касается проверки документов в подчиненных базах при помощи таблицы olegon_sync
Сейчас таблица заполнена вот так:
base1 13 qqq
base2 10 qqq
base3 15 qqq
Но магии не происходит. все 3 базы доступны. в tns names адреса прописаны.

Третий вопрос касается проверки больших таблиц типа SMSPEC или SMPRICEHISTORY
Судя по логам оптимайзер ночью в MT периоде пытается их оптимизировать
25.07.13 05:10:48 -- Gather stats... Table : "SUPERMAG"."SMSPEC"
25.07.13 05:10:48 -- Gather...
потом много таких сообщений сообщений
25.07.13 08:10:01 -- Second connection of optimizer disabled...
и потом где то в 8 стартует уже не МТ видимо прерываясь по тайм ауту.
Можно ли надеяться что он эти таблицы когда нибудь пройдет? можно ли собственноручно собрать статистику по тяжелым таблицам? учтет ли это оптимайзер? MT период порядка 3 часов. Хотя я пробовал и на всю ночь поставить. Gather stats... может и часов 6 висеть.
26.07.2013 18:36
OlegON
 
емейлы обновляются в самом конце, т.е. опт должен отработать полностью. поля лучше не затирать, а обновлять. рекомендую убедиться, что поле одно и написано правильно.
Код:
select * from olegon_params where lower(name)='adminemail';
должен вернуть одну запись.

второй вопрос не описан. "магии не происходит" - не описание проблемы.

с большими таблицами не понятно, почему "second connection" возникает? скорее всего просто нестабильная связь и во время долгих операций оптимизатора просто прерывает, о чем он не знает. smspec анализируется каждый день, это правильно. потом идет работа с другими таблицами по кругу.
26.07.2013 19:07
omnomnom
 
C емейлом понятно. видимо опт еще не разу не отработал полностью

по поводу. второго вопроса.
В описании функционала написано что программа будет формировать текстовик с расхождениями между базами. но это не происходит. может быть по каким либо логам можно понять почему?
26.07.2013 19:10
Dim
 
я думаю, если опт до конца не отрабатывает, то до сверки баз он тоже не дошел
31.07.2013 16:39
omnomnom
 
Еще вопрос небольшой. у нас FFtables и FFINDX вынесены в отдельные табличные пространства.
в оптимайзере соотвественно в таблице указано.

FFTables FFTABLES
FFIndexes FFINDX

недавно я проглядывал партиции в FFTABLES и обнаружил следующую аномалию
Нажмите на изображение для увеличения
Название: 2xeqw5a.png
Просмотров: 451
Размер:	26.6 Кб
ID:	2176
и так же в свежесозданной партиции FF09_2013.

Может я что то не так в настройках указал?
31.07.2013 17:07
OlegON
 
что вы делаете с картинками? :( можете скриптом показать расположение таблицы и индексов на ней? я как-то всем этим графическим поделиям не очень доверяю... допускаю, что какой-то алгоритмический просчет по партициям мог быть...
31.07.2013 17:25
omnomnom
 
Запросом получается вот так
select TABLE_NAME, PARTITION_NAME, TABLESPACE_NAME
from DBA_TAB_PARTITIONS;

FFMAPREP FF4_2011 FFTABLES
FFMAPREP FF5_2011 FFINDX
FFMAPREP FF6_2011 FFTABLES
FFMAPREP FF_2006 FFTABLES
Часовой пояс GMT +3, время: 22:42.

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