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

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

28.03.2024 14:36


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 Кб, 132 просмотров)
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
 
Тут палка о двух концах. Определить, что идет расчет ТД можно только по тому, что он начался. Если при этом он упадет из-за убитого индекса, то получим, что опт будет вечно ждать окончания расчета, а расчет - починки индекса. Поэтому в МТ, когда оптимизатор должен быть один, такие учеты не ведутся.
Часовой пояс GMT +3, время: 14:36.

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