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

Тогда вот какие ещё есть вопросы...

У меня 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 обрабатывать, а уже потом проверять остальные инвалидные индексы, разделы и подразделы, разделы индексов и т.д.? Тогда не будет дублирования, в случае какихто нештатных ситуаций.

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

Доброго времени суток уважаемым форумчанам.
Появился небольшой вопрос по оптимайзеру, которым воспользовался сегодня впервые. Итак, исходные данные: операционка Windows 2008 Server R2 64bit, Oracle 11g, СМ 1.028 SP2. Оптимайзер трудился 2,5 часа и выдал лог на 1,4Мб, который полностью состоит из ошибок (лог прикрепил в архиве). Т.к. с Ораклом я совсем еще "на Вы", прошу подсказать опытных и компетентных форумчан о чем свидетельствуют данные ошибки и как с ними поступать в данном случае. Заранее благодарен всем откликнувшимся.

Вложения

optimizer.7z (39.1 Кб, 135 просмотров)

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

Спасибо, Олег, ошибку осознал. Получается к оптимизатору относится только время его работы (удивило 2,5 ч.), это его только первый запуск или это частный случай (например количество тех же ошибок)? просто за сервером иногда работают пользователи в Супермаге, поэтому хотелось бы уточнить, стоит ли дальше запускать оптимизатор до устранения всех ошибок и вообще стоит ли запускать на Oracle 11g, т.к. в логе написало, что эта версия не тестировалась?

Она по прежнему в статусе "не тестировалась", сочувствую, поскольку, скорее всего, Сервис Плюс вам поставил древнюю и кривую 11 версию (более менее нормальная вышла около месяца назад). Я на самом деле стараюсь выправлять ошибки работы оптимизатора на 11й версии, насколько мне это доступно, поскольку у меня по прежнему нет ни одного клиента на 11g. По идее работать будет, ошибки править тоже, но, как и на 9й версии многое может не делать. По этой же идее ошибки надо поправить как можно быстрее, оптимизатор останавливать не надо.

Несколько постов назад обсуждали ситуацию с пересозданием подразделов индексов 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 лишний раз не люблю - большие они и перестраиваются долго.

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

Это понятно, что желательно разделить.
Но где то в логе наблюдал сообщение оптимайзера, что мол идёт расчёт ТД и подумал что раз этот момент определяется - значит должны вносятся коррективы соответствующие в работу (оптимайзера) Жаль что не так :(

Тут палка о двух концах. Определить, что идет расчет ТД можно только по тому, что он начался. Если при этом он упадет из-за убитого индекса, то получим, что опт будет вечно ждать окончания расчета, а расчет - починки индекса. Поэтому в МТ, когда оптимизатор должен быть один, такие учеты не ведутся.