[ТЕМА ЗАКРЫТА]
09.11.2011 09:22
OlegON
 
https://olegon.ru/showpost.php?p=101417&postcount=9
Если мешает - можешь пропатчить свою Java, но на самом деле это только на отображение времени в логе. Maintenance сверяется с моим, а у меня Java уже патченная.
11.11.2011 08:56
Stels
 
почему-то сегодня ниодного отчёта ни по одной базе на почту не пришло..
как будто первое число месяца :)
(по логам оптимизатор отрабатывает)
11.11.2011 09:20
OlegON
 
А ты первого числа код подтверждал? Сегодня закончился срок действия бесплатной регистрации на месяц, которую я раздавал. Уфф... Некоторые абсолютно наплевательски относились к тому, что им писал оптимизатор, сервер просто завален был... Но уж раз пообещал тогда...
11.11.2011 10:37
Stels
 
нет. вроде как отчёты приходили - думал не надо.
ясно - подтвердим
15.11.2011 17:25
AlexeyF
 
! первая платная регистрация

Тут, плз, поточнее ?
появился юрик с банковским счётом, с которым можно заключить договор на оптимайзер и перечислять за услуги безналом ?
15.11.2011 18:06
OlegON
 
кстати, да... пока все в процессе обсуждения, но "юрик", скорее всего, будет.
15.11.2011 18:17
AlexeyF
 
Поскорее, плз, надо определиться с условиями и расценками деятельности этого юрика. Это что бы успеть безболезненно заложить в бюджет на 2012г.
05.12.2011 05:08
AlexeyF
 
Уже пару часов оптимайзер говорит Sorry, too much unregistered sessions. При этом запуск идёт не в ровное время, типа 09:00. хх:09, хх:02, хх:39, хх:34 Печально.
05.12.2011 07:32
bob
 
Цитата:
AlexeyF Уже пару часов оптимайзер говорит Sorry, too much unregistered sessions. При этом запуск идёт не в ровное время, типа 09:00. хх:09, хх:02, хх:39, хх:34 Печально.
Олег в какой-то теме писал на прошлой неделе вроде, что уменьшает кол-во сессий для незарегистрированных пользователей. При превышении кол-во дает отлуп всем остальным.
05.12.2011 07:37
OlegON
 
https://olegon.ru/showpost.php?p=103373&postcount=229
Внимательно проследил, работает корректно. Просто по ночам вообще полный аут. Бекапы идут, отчеты и пр. долгие операции. Количество процессов оптимизатора в сутки скачет от 6 до 50+. При моих 4х ядрах...В хх:02, уверен, запускать особо нет смысла, поскольку большинство нечитающих будут ставить ровно в 00:00 и до 00:02 он еще не отработает.
AlexeyF получает бесплатную регистрацию на квартал для своих двух БД за активную обратную связь по фичам оптимизатора.
05.12.2011 13:17
AlexeyF
 
Тогда вот какие ещё есть вопросы...

У меня DontUseFFMAPREP=NO
В начале нового месяца оптимайзер у индексов FFMAPREP_, которые разделами, делает все подразделы "unused" и начинает их перестраивать Rebuilding of SUPERMAG.FFMAPREP_DOC rebuild subpartition FF_2006_PO и т.д.

Я прервал этот процесс и сделал ручками
ALTER INDEX SUPERMAG.FFMAPREP_SUPPLIER REBUILD SUBPARTITION
для всех подразделов, у которых статус "неиспользуемые". Так быстрее, чем это бы делал сам оптимайзер.
Но при следующем проходе оптимайзер опять все подразделы FFMAPREP_xxxxxx индексов делает unused и опять начинает их заново перестраивать.
Думаю - интересно, не стал дожидаться, ещё раз прервал процесс, перезапустил оптимайзер и стало ещё интересней. :)
Вначале оптимайзер перестроил подразделы индексов, которые остались "недоступные" при обычной проверке "Gathering list of invalid index subpartitions".
Потом - Tablespace : FFTAB, начинается обработка FFTAB и опять все подразделы в статус "неиспользуемый" и опять перестроение всех подразделов уже второй раз за ОДИН запуск оптимайзера. (а процесс перестроения подразделов оптимайзером не быстрый)

В связи с вышеизложенныим два вопроса.
1. перестроение подразделов FFMAPREP_xxxxx в режиме Tablespace : FFTAB чем то отличается от ручного ALTER INDEX SUPERMAG.FFMAPREP_SUPPLIER REBUILD SUBPARTITION всех подразделов ? При условии что подразделы для новых месяцев уже созданы?

2. Может лучше сначала FFTAB обрабатывать, а уже потом проверять остальные инвалидные индексы, разделы и подразделы, разделы индексов и т.д.? Тогда не будет дублирования, в случае какихто нештатных ситуаций.
05.12.2011 15:40
OlegON
 
1. отличается. при перестройке индексов еще и проверяется там что-то с чем-то, сейчас уже не помню точно, но дополнительные операции какие-то есть.
2. спорный момент... вообще-то наличие инвалидов - нештатная ситуация и первое, что должен сделать оптимизатор - попробовать повоевать с ними, а не проводить какие-то оптимизации. поэтому, как я понял, у тебя и пошла двойная перестройка. т.е. можно усложнять логику, только это чревато каким-то сбоем при отсутствии обработки каких-то комбинаций и вариантов. можно усугубить ситуацию, пытаясь провести оптимизацию без уведомления администратора о том, что инвалидные индексы есть и не удается их перестроить... поэтому, извини, пока оставлю в таком виде. тупо, зато надежно.
11.12.2011 16:29
dest_
 
Доброго времени суток уважаемым форумчанам.
Появился небольшой вопрос по оптимайзеру, которым воспользовался сегодня впервые. Итак, исходные данные: операционка Windows 2008 Server R2 64bit, Oracle 11g, СМ 1.028 SP2. Оптимайзер трудился 2,5 часа и выдал лог на 1,4Мб, который полностью состоит из ошибок (лог прикрепил в архиве). Т.к. с Ораклом я совсем еще "на Вы", прошу подсказать опытных и компетентных форумчан о чем свидетельствуют данные ошибки и как с ними поступать в данном случае. Заранее благодарен всем откликнувшимся.
Вложения
Тип файла: 7z optimizer.7z (39.1 Кб, 100 просмотров)
11.12.2011 18:34
OlegON
 
Цитата:
dest_ Доброго времени суток уважаемым форумчанам.
Появился небольшой вопрос по оптимайзеру, которым воспользовался сегодня впервые.
"Кому нечего делать, прошу посмотреть мои проблемы и сделать все за меня"...
Во-первых, скачивать, разархивировать и копаться в логе некогда.
Во-вторых, проблемы с БД, а не с оптимизатором, т.е. милости прошу заводить на каждую ошибку тему в оракловом разделе.
В-третьих, лог оптимизатора с частными проблемами интереса не представляет, прошу подобные вещи выкладывать во временный раздел хранилища.
На первый раз за нарушение тематики выдавать не буду, но прошу тут не продолжать.
11.12.2011 23:02
dest_
 
Цитата:
OlegON На первый раз за нарушение тематики выдавать не буду, но прошу тут не продолжать.
Спасибо, Олег, ошибку осознал. Получается к оптимизатору относится только время его работы (удивило 2,5 ч.), это его только первый запуск или это частный случай (например количество тех же ошибок)? просто за сервером иногда работают пользователи в Супермаге, поэтому хотелось бы уточнить, стоит ли дальше запускать оптимизатор до устранения всех ошибок и вообще стоит ли запускать на Oracle 11g, т.к. в логе написало, что эта версия не тестировалась?
12.12.2011 07:22
OlegON
 
Она по прежнему в статусе "не тестировалась", сочувствую, поскольку, скорее всего, Сервис Плюс вам поставил древнюю и кривую 11 версию (более менее нормальная вышла около месяца назад). Я на самом деле стараюсь выправлять ошибки работы оптимизатора на 11й версии, насколько мне это доступно, поскольку у меня по прежнему нет ни одного клиента на 11g. По идее работать будет, ошибки править тоже, но, как и на 9й версии многое может не делать. По этой же идее ошибки надо поправить как можно быстрее, оптимизатор останавливать не надо.
13.12.2011 05:39
AlexeyF
 
Несколько постов назад обсуждали ситуацию с пересозданием подразделов индексов SUPERMAG.FFMAPREP

Сейчас наблюдаю ситуацию:
Ночью считается себестоимость но и в оптимайзере наступило время обслуживания - в логе
13.12.11 04:42:18 -- ******************************************************
13.12.11 04:42:18 -- Gathering list of invalid indexes
13.12.11 04:42:28 -- Index SUPERMAG.FFMAPREP_ARTICLE locked, skipping...
13.12.11 04:42:28 -- **************************************************************
13.12.11 04:42:28 -- Partitions and subpartitions state check
13.12.11 04:42:30 -- **************************************************************
13.12.11 04:42:31 -- Gathering list of invalid index partitions
13.12.11 04:42:32 -- **************************************************************
13.12.11 04:42:33 -- Gathering list of invalid index subpartitions
13.12.11 04:43:06 -- Rebuilding of SUPERMAG.FFMAPREP_DOC rebuild subpartition FF4_2008_PO
13.12.11 04:43:21 -- Rebuilding of SUPERMAG.FFMAPREP_DOC rebuild subpartition FF4_2008_PN


Т.е. пошло опять пересоздание разделов индексов FFMAPREP, долго это будет и т.д.
Я понял что оптимайзер перестраивать начал потому что Index SUPERMAG.FFMAPREP_ARTICLE locked, skipping...
но идёт расчёт товародвижения и это нормально. Прав я или нет ?

Я перестроение индексов FFMAPREP лишний раз не люблю - большие они и перестраиваются долго.
13.12.2011 07:20
OlegON
 
вообще-то время обслуживания подразумевает, что он в базе один... в обычное время учитывается, что идет расчет и перестройка индексов пропускается... рекомендую разнести эти две операции. если оптимизатор разберет какую-то нужную табличку во время расчета ТД или ТД задумается и оптимизатор начнет собирать незалоченные индексы... ТД может резко затупить или упасть.
14.12.2011 05:47
AlexeyF
 
Это понятно, что желательно разделить.
Но где то в логе наблюдал сообщение оптимайзера, что мол идёт расчёт ТД и подумал что раз этот момент определяется - значит должны вносятся коррективы соответствующие в работу (оптимайзера) Жаль что не так :(
14.12.2011 06:47
OlegON
 
Тут палка о двух концах. Определить, что идет расчет ТД можно только по тому, что он начался. Если при этом он упадет из-за убитого индекса, то получим, что опт будет вечно ждать окончания расчета, а расчет - починки индекса. Поэтому в МТ, когда оптимизатор должен быть один, такие учеты не ведутся.
14.12.2011 08:02
OlegON
 
собственно, если есть какие-то другие предложения по алгоритму - с удовольствием обсужу.
14.12.2011 09:12
AlexeyF
 
Тогда поговорим ...
"Если при этом он упадет из-за убитого индекса, то получим, что опт будет вечно ждать окончания расчета, а расчет - починки индекса."
Почему "вечно ждать" ?
Идёт сессия оптимайзера, он заметил, что идёт расчёт ТД и не трогает таблицы-индексы, которые в этом расчёте используются, с остальными делает все операции как положено. Если наступило МТ, то пускай работает не касаясь FF таблиц и индексов.

Если таблица или индекс поломались, ну и что. ТД вывалится с ошибкой и при следующем запуске оптимайзера он увидит, что нет расчёта ТД и будет работать в обычном режиме. В том числе полечит сбойные индексы FF, из-за которых ТД отвалился.

Утром админ смотрит что расчёт упал с такой то ошибкой, смотрит в логе что оптимайзер при след запуске полечил этот индекс и спокойно запускает расчёт ещё раз.

Т.е. предложение, не зависимо от МТ, если определёно, что запущен расчёт ТД - не трогать FF таблицы и индексы, считать что DontUseFFMAPREP=yes
14.12.2011 09:42
OlegON
 
1. "Не трогает таблицы, участвующие в расчете" - не катит, я просто физически вспарюсь отслеживать кучу версий, включая новые. Сейчас он просто игнорит все.
2. "увидит, что нет расчета ТД" - в том и проблема, что не увидит. Гениальность решения С+ в том, что никаких признаков расчета ТД нет (я о них не знаю). Есть запись в журнале о том, что ТД начало считаться, и если оно падает, эта запись никуда не пропадает. Расчитывать на время тут нельзя, у многих оно считается сутками. Поэтому расчет простой, в МТ оптимизатор работает один и в это время расчета ТД нет. Суть МТ в том, что оптимизатор в это время работает один.
14.12.2011 09:51
Mtirt
 
А если перевернуть логику?
Проверять не начало расчета ТД, а его окончание?
Т.е. если есть запись об окончании расчета ТД - можно запускать оптимайзер в МТ.
Нет записи - в МТ не запускаем, выдаем сообщение админу "Не смогли запустить, потому как похоже считается ТД". Если это действительно так - админ поймет, не так - должен разобраться, почему не посчитался ТД.
14.12.2011 09:56
OlegON
 
так она такая и есть, эта логика, проверка окончания... а при твоем предложении, если админ - лентяй или ТД его мало интересует, то получим интересную багу в виде того, что при изуродованном ТД оптимизатор не будет работать, пока админ не зачешется. сейчас оптимизатор и на нерасчитанное ТД ругается, только свои координаты для ругани в БД прописали менее 10%. Но я не очень понимаю цели, если так не хочется, можно МТ сузить до минуты в тот интервал, когда опт не запускается..
14.12.2011 10:05
Mtirt
 
Нормальному админу хочется и ТД посчитать и оптимайзер в МТ запустить.
При этом, он не знает, когда закончится расчет ТД и можно запускать оптимайзер в МТ. И действует по наитию, насколько я понимаю.

Кстати, а что будет, если сначала оптимайзер в МТ, а потом расчет ТД? Может же это и оптимайзер делать? И именно в таком порядке?
14.12.2011 10:55
OlegON
 
у меня везде сначала как раз работает МТ, а потом считается ТД. Поскольку второе гораздо с меньшей вероятностью закончится вовремя. Оптимизатор не считает ТД, он только переносит. В МТ. Поэтому я совсем ненормальный, но сначала (с 23 по умолчанию) гоняю оптимизатора, останавливая кассовик с почтовиком, а под утро, когда уже и окончательно уверен, что все кассы слились, запускаю расчет ТД.
14.12.2011 10:57
Mtirt
 
А у МТ есть жесткие рамки? Он позже закончится не может?
Просто после перехода на 28.2 проблем с запуском ТД по расписанию тоже нет - запустить можно через минуту после окончания времени МТ.
14.12.2011 11:14
OlegON
 
У МТ рамки жесткие, перед тем, как запустить оптимизацию очередной таблички, опт проверяет, в МТ он или нет. Однако, если попадется ооочень большая табличка, он может и припоздниться самим процессом. Тут я ничего не могу поделать. Считать размеры таблички разве что...
14.12.2011 11:39
AlexeyF
 
Расклад простой МТ - каждую ночь с остановкой кассового, на неделе 3 раза вечером запуск ТД. Придётся переделать расписание что бы в такие ночи оптимайзер не запускался совсем. МТ, до ТД не вариант, т.к. у меня расчёт идёт 12 часов. мне его надо запускать как можно раньше.
Другого варианта не предвидится из переписки выше :)


Опции темы


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

 

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