[ТЕМА ЗАКРЫТА]
24.10.2011 13:20
AlexeyF
 
центральный фаревол без ограничения сталкивался с нереальным количеством соединений - напрягает
уже за много лет это ограничение устоялось
25.10.2011 11:19
AlexeyF
 
странно...
устанавливаю IamNoob = no, пару раз запускаю оптимайзер -с=о и получаю IamNoob = yes
Совсем не удобно
25.10.2011 11:33
OlegON
 
увы, для незарегистрированных так. поправлю потом - будет только в Maintenance это делать
26.10.2011 12:45
AlexeyF
 
Цитата:
+ Параметр DisableOldStats (yes) - отключение агрессивного сбора статистики.
ставится по умолчанию (yes), но по идее это те у кого проблемы с валидацией должны сами ставить, а кого устраивает как работали, так и работали бы дальше. Сейчас получится что надо обязательно параметр поменять, или сразу, или по рекомендации, через полгода.

Исхожу из того что старый режим агрессивной валидации лучше, чем DisableOldStats=yes, как сечас - так это или не так, лучше или нет?
26.10.2011 13:06
Dim
 
а может оптимайзер сам будет стопить почтовый и кассовый сервера?
26.10.2011 13:08
AlexeyF
 
Цитата:
Dim а может оптимайзер сам будет стопить почтовый и кассовый сервера?
вот только не надо это делать по умолчанию
26.10.2011 13:11
OlegON
 
Цитата:
AlexeyF Исхожу из того что старый режим агрессивной валидации лучше, чем DisableOldStats=yes, как сечас - так это или не так, лучше или нет?
Проблема в том, что сталкиваются с неприятностями при использовании этого параметра новички. У меня, например, вообще ни разу не проявлялась эта засада. В чем она состоит - при сильной фрагментации таблички и древней статистике по ней валидация идет очень долго и выходит за рамки MaintenanceTime, мешая работать пользователям. Естественно, что первое желание админа при таком подвохе - оптимизатор выключить. Как было раньше - 20 табличек обрабатывалось оптимизатором за проход на валидацию/дефрагментацию, 20 - просто валидация и сбор статистики (быстрее). Теперь по умолчанию валидируется и дефрагментируется 30 табличек (по ним и статистика собирается), валидация и сбор статистики отдельно не производится. Это исключило случаи, когда из-за древнезапущенной БД валидируется фрагментированная табличка. Старый режим лучше тем, что быстрее проходит круг табличек, собирая статистику.
26.10.2011 13:13
OlegON
 
Цитата:
Dim а может оптимайзер сам будет стопить почтовый и кассовый сервера?
Нет, сейчас он себе попробует на время работы очищать пространство, блокируя supermag. А в целом идея маложивуча. Часто эти сервисы стоят отдельно.
26.10.2011 13:21
OlegON
 
Простейший расчет (версия 1028.2):
Цитата:
SQL> select count(*) from dba_tables where owner='SUPERMAG';

COUNT(*)
----------
893
Исходим из оптимистичного предположения, что оптимизируется 30 табличек в час. Итого, по умолчанию - три часа МТ, за ночь он переворачивает 90 табличек.
893/90=9.6, т.е. со всеми форсмажорами и переносами ТД, он при трехчасовом МТ будет проходить таблички по кругу за две недели. Я считаю - это нормально.
27.10.2011 02:35
whitewizard
 
а чего это после оптимизатора у меня на всех базах залочился пользователь supermag?
27.10.2011 05:41
Propil
 
whitewizard
похоже, опт не доработал до конца - что-то его прервало
Блокировка введена вчера для "ночного" режима работы
27.10.2011 06:44
whitewizard
 
на 8 базах? окошечки черные везде закрытые были
27.10.2011 07:05
Propil
 
посмотри логи оптимайзера
27.10.2011 07:21
AlexeyF
 
Те же грабли, в смысле на десятке баз супермаг по отключался.
Как то можно отключаемым сделать фишку с заблокировать supermag ?
27.10.2011 07:34
Propil
 
В этой версии оптимайзера, думаю не отключается.
Олег планировал сделать опцию
Сейчас - только запустить опта еще раз уже не в maintenance режиме, чтобы разлочить
27.10.2011 07:44
whitewizard
 
нифига. разлочил я ручками.
27.10.2011 07:48
Propil
 
в смысле - оптимайзером не получилось?
27.10.2011 07:49
whitewizard
 
оптимайзер и так запускается каждые 35 минут.
а в итоге с утра беда такая.
27.10.2011 07:50
Propil
 
я к тому, что если прервать работу опта в maintenance режиме - могут остаться битые индексы
И по-любому надо его еще раз запускать для проверки
Или да - ручками править
27.10.2011 07:51
whitewizard
 
никто не прерывал
27.10.2011 07:51
Propil
 
сам сегодня остался на двух базах без рассчитанного ТД
27.10.2011 07:53
whitewizard
 
так, а цель лочить?
27.10.2011 07:54
Propil
 
https://olegon.ru/showthread.php?t=7196&page=43
Цитата:
% На время своей работы в MaintenanceTime оптимизатор будет стараться заблокировать supermag. Многие не отнеслись с пониманием к тому, что это время единоличного использования БД оптимизатором и, например, не останавливают почтовик, что вредит обоим. Жду комментариев.
27.10.2011 07:59
whitewizard
 
не совсем это хорошо.
27.10.2011 08:09
OlegON
 
На скольких БД я остался... Приношу свои извинения. Фича вырвана с позором, разбираюсь... Пока не понял, что произошло, но базы завелись сами.
27.10.2011 08:15
Dim
 
у меня такого не произошло как ни странно
27.10.2011 08:15
konst
 
на 9-ке эта фича не сработала
27.10.2011 08:21
OlegON
 
Там нет разницы в версиях, судя по всему, речь идет о длине интервала обработки. На мелких БД нормально переподключался СМ, а на больших - нет, что и помешало мне поймать баг на старте. Пока не могу объяснить явление. На многих отвалился Сервер Лицензий и передумал подключаться обратно, собака. Но разлочилось везде. Фича убрана, пока программеры С+ руки растить из правильного места не начнут.
27.10.2011 08:22
Dim
 
у плохого танцора прогеры С+ виноваты? )))
27.10.2011 08:26
OlegON
 
Еще раз, я сначала заподозрил, что я такой кривой, не разлочил supermag и суетливо тут пытался найти залоченного, чтобы разобрать руками. Но он разлочен везде. Зато не везде подключился Сервер Лицензий, из-за чего и проблема.


Опции темы


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

 

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