[ТЕМА ЗАКРЫТА]
17.09.2011 16:20
OlegON
 
Можно, только вот зачем? Они по большому счету должны быть всегда перепосланы.
18.09.2011 02:02
whitewizard
 
Дык не всегда.
18.09.2011 09:06
OlegON
 
Исходим из того, что автоматизировать есть часто повторяющуюся процедуру, что явно не относится к "дык не всегда", а чтобы рулить почтовиком полностью, надо будет его половину переписать. Смысла не вижу. Прежде чем убивать, надо разобрать что там, анализировать и пр... Или я что-то не заметил?
18.09.2011 13:57
whitewizard
 
Ну вот, например сеть у меня организована с помощью Энфорты и файлового обмена. Иногда сеть падает и пакетам некуда складываться.
18.09.2011 19:09
OlegON
 
Поставь Argus и не парься. Если сеть уродская, то пользоваться штатными передавалками вообще нереально. Нужна докачка и прочие прелести. Оптимайзер тут никаким костылем не будет... Все равно надо пакеты слать, иначе еще тот рассинхрон получится.
Argus и прочие проблемы передачи пакетов предлагаю обсудить в более другой теме.
26.09.2011 14:25
ckadi
 
СМ2к 1.026сп3, 10.2.0.4 оракл. Оптимайзер запускается 2 раза в час кроном.
лог оптимайзера за последний запуск
26.09.11 17:00:57 -- *********************** Obsolete parameters ***********************
26.09.11 17:00:58 -- Set database parameters
26.09.11 17:01:05 -- Checking system statistic values...
26.09.11 17:01:07 -- Check supermag grants
26.09.11 17:01:18 -- Old statistics check :
26.09.11 17:01:28 -- Gather stats... Table : "SUPERMAG"."SMSPEC"
26.09.11 17:01:29 -- Validating...

На этом виснет оптимайзер, грузит сервер, супермаг еле шевелится у народа, жалуются на тормоза. Всегда на этом месте, пару недель уже это.
Что делать?
26.09.2011 14:50
Mr_Vito
 
26.09.11 15:25:46 -- Gather stats... Table : "SUPERMAG"."SMFOREIGNUNITS"
26.09.11 15:25:46 -- Validating...
26.09.11 15:25:46 -- Gather...
26.09.11 15:25:47 -- OLEGON-ERROR! : Query:serversm2:db2000:java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-01008: not all variables bound
ORA-06512: at line 23

Оптимизатор начал ругаться таким образом на десятка 2 табличек, как лечить?
26.09.2011 14:54
Mr_Vito
 
забыл :(
оракл 10.2.0.4 супермаг 26.3
начал ругаться с 22 числа с часу ночи (база ilishco)
26.09.2011 15:18
OlegON
 
Цитата:
ckadi На этом виснет оптимайзер, грузит сервер, супермаг еле шевелится у народа, жалуются на тормоза. Всегда на этом месте, пару недель уже это. Что делать?
Ночью не останавливайте оптимизатор, он будет успевать делать это в MaintenanceTime и не будет докучать днем. Просто статистика на smspec настолько древняя, что необходимо срочно ее посчитать. А сейчас оптимизатор просто остановите до вечера, а вечером пусть начнет, когда никого нет. Сделает - отстанет. Я сейчас повышу порог "срочности" для статистики.
26.09.2011 15:25
OlegON
 
Цитата:
Mr_Vito Оптимизатор начал ругаться таким образом на десятка 2 табличек, как лечить?
Не знаю и журналов у меня теперь нет :( Блок расчета статистики не трогал уже очень давно, хотя не так давно поправил глюк с неподхватом некоторых табличек. Какая-то бага в базе, попробуй расчитать вручную.
26.09.2011 15:30
OlegON
 
Цитата:
ckadi На этом виснет оптимайзер, грузит сервер, супермаг еле шевелится у народа, жалуются на тормоза.
Попробуйте сейчас? Суть проблемы я описал выше, но теперь "древняя" это 200 дней, а не 30, как было.
28.09.2011 10:15
MirProd
 
Перестал приходить ежедневный отчет оптимизатора. Последний 25.09.11, последняя запись в логе о процедуре отправки отчета - тоже 25.09.11. ???
28.09.2011 12:36
OlegON
 
почта подтверждена? По моему у меня похожая БД в топе рассылки была, могло сбросить код за флуд.
30.09.2011 07:47
OlegON
 
Есть мысль ввести параметр ForceNoob с yes по умолчанию, который будет отключать половину выводимой в лог информации. Уже жалобы есть на то, что его листать надоедает, а мне тут надо значительно увеличить объем информации. Соответственно, вопрос, что оставить в логе? На что вы по любому будете смотреть?
30.09.2011 10:22
konst
 
Может быть сделать по другому:
параметр - LogLevel
значения например от 0... до 5
0 - лог вообще не пишется
1 - только что то важное
2 - еще что то
5 - полный
или по маске - по разделам
00000000 - ничего
00000001 - о системе
00000010 - состояние БД и т.д.
тогда значение:
00000011 - разрешит писать в лог о системе и состояние БД

сам на логи посмотрел... они у меня ежедневно перекладываются в каталог log и переименовываются по дате
теоретически можно сделать это и после каждого запуска дополнительно добавить время...
каких то проблем с просмотром не вижу
30.09.2011 10:54
OlegON
 
Суть в том, что ставить по умолчанию "ничего не пишется" - зло, когда оно екнется, будет уже не понятно, что было. Поэтому хотел полениться и ввести две позиции, ежедневный или дебагово-полный. В любом случае хотелось бы знать, что нужно только в полном, поскольку мне нужно все и себе я ограничивать лог не буду. Если же большинству лог вообще не интересен, я включу его только на ошибки по умолчанию и тогда можно будет его включить и у меня параллельно, чтобы винт не клался.
30.09.2011 16:42
akonev
 
когда все уже замечательски работает, то лог нужен только для разборок постфактум и для анализа ошибок, которые оптер нарыл. для этого ему лучше быть большим и полным.

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

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

но тут-то уже все есть. все собирается и в файлик складывается :)
только много всего. при полусотне юзеров утомляет сессии и запросы проматывать.

поэтому лично меня бы сильно порадовал вариант с флажками: это писать, это не писать.
05.10.2011 08:51
AlexeyF
 
В своей центральной базе решил я посмотреть параметры оптимайзера.
Есть параметр WebStatusCode=0 Не могу найти на форуме что он означает.

подскажите, что это за параметр ?
05.10.2011 09:08
akonev
 
Цитата:
AlexeyF ...Есть параметр WebStatusCode=0 Не могу найти на форуме что он означает.
подскажите, что это за параметр ?
Это новая фишка, пока в разработке: web-монитор состояния базы. Обсуждалась позавчера-вчера в чате форума, можно найти в журналах.

Если оставить 0 - монитор не будет работать для этой базы вовсе. Если указать какие-нибудь цифирки (до 11 штук) - это будет "пароль" для просмотра своего монитора.

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

Олег в чате принимает пожелания на тему, чего еще показать полезного. :)
20.10.2011 08:15
OlegON
 
Мне скоро понадобится обновить протокол. Это значит, что оптимизатор, клиентская часть, обновится так же. Если у кого-то замечания/предложения по этому поводу - высказывайтесь. Проблемы могут быть у кого-то с дерьмовой связью.
24.10.2011 08:16
ckadi
 
SM 1.026sp3, Oracle 9i. Оптимайзер-4 запускал с ключами vo: последнего запуска лог

**************************************************************
24.10.11 10:54:29 -- Gathering list of invalid indexes
24.10.11 10:54:30 -- Rebuilding of SUPERMAG.SMSTAFF_PK :2 : 0Mb
24.10.11 10:54:31 -- OLEGON-ERROR! : Query:sm-lazo:dbmag2:java.sql.SQLException: ORA-00604: error occurred at recursive SQL level 1
ORA-06550: line 6, column 27:
PL/SQL: ORA-00600: internal error code, arguments: [12830], [SUPERMAG], [SMSTAFF], [], [], [], [], []
ORA-06550: line 6, column 3:
PL/SQL: SQL Statement ignored
На данной базе Оптимайзер 2 раза в час позавчера(24.10.11) начал выполнять кроном. Сервер по питанию сотрудники магза ребутали на выходных без моего ведома, полагаю в это время работал оптимайзер с базой.

Не запускалась база в Сервер Супермага:
ORA-01502: индекс 'SUPERMAG.SMSTAFF_...<не записал точное название>' или часть такого индекса
находится в неиспользуемом состоянии
Выполнял alter index ... unusable; , затем alter index ... rebuild; , ошибку устранил, база в "Сервер Супермага" запустилась. При логине клиентом см2к выдается:
ORA-01502: index 'SUPERMAG.SMSTAFF_PK' or partition of such index is in unusable state
unusable\rebuild с индексом SUPERMAG.SMSTAFF_PK выполнял - не помогло.
Что делать?
24.10.2011 08:23
OlegON
 
триггер надо удалить, что-то про password, уже писалось в одной из тем оптимизаторской.
24.10.2011 08:23
ckadi
 
Повторил alter index SUPERMAG.SMSTAFF_PK rebuild; - ошибка ORA-01502 исчезла.
24.10.2011 08:24
OlegON
 
могут начаться другие, если триггер оставить.
24.10.2011 09:06
ckadi
 
Действительно, при создании пользователя ругалось на индекс еще 1 (...surname), ребилд его сделал.
Произвел поиск в разделе "Мои программы", по "password", выдалось 4 сообщения, про триггер не было упоминания. Мож я косо ищу?
https://olegon.ru/showthread.php?p=1...ord#post100804
https://olegon.ru/showthread.php?p=7...word#post74233
https://olegon.ru/showthread.php?p=7...word#post73773
https://olegon.ru/showthread.php?p=5...word#post58576
24.10.2011 09:53
OlegON
 
Цитата:
Andrew_Konev DBPasswordChange ?
Он самый... Вот, удаление триггера dbpasswordchange
24.10.2011 09:54
vdm
 
По SMSTAFF ищи.
Например это
https://olegon.ru/showthread.php?t=2701

Хотя для твоей версии был заявлен фикс https://olegon.ru/showthread.php?t=3546, но это для статистики, м.б. не твой случай.
24.10.2011 10:12
OlegON
 
Нет-нет, статистика там тоже падала, я про нее и говорил, когда упомянул про дальнейшие ошибки.
24.10.2011 13:09
OlegON
 
Цитата:
AlexeyF Ограничение на простой коннекта 260 сек. понимаю так, что этого не хватает ?
когда операция выполняется оптимайзером у него обмена нет никакого ?
Не помню, кажется, сервер пингует клиента раз в 5 или даже 10 минут. А зачем тебе такое суровое ограничение?


Опции темы


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

 

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