После загрузки данных в куб они не видны в BEX. При вызове интерфейса администрирования куба появляется надпись
"Загруженные записи еще нельзя посмотреть в системе отчетов"

Детальная информация выводит следующее:
------------------------------------------------------

There is an inconsistency between the load status of the data and the option of reporting on this data.

There is data in the InfoCube/ODS object that is OK from a quality point of view, but is not yet displayed in reporting.

The problem, for example, is to do with request 0000008799, number REQU_3YKVRLZGNCTC67AH1MNQRVI9V.

Procedure
Choose 'Refresh' to remove the inconsistency.
------------------------------------------------------

Напротив запроса в поле "запрос существует для системы запросов"
отсутствует значок.

После refresh-а данные становятся доступными. Данные становятся доступными и после сжатия куба, но мне оно не нужно.

Как это решается?

А В ИНФО-ПАКЕТЕ КАКАЯ ОПЦИЯ ВЫБРАНА ДЛЯ ОБРАБОТКИ ДАННЫХ?

PSA и затем в цели данных по пакетам.
Полная цепочка процессов выглядит так
Старт -> Инфо-пакет -> ODS активация -> ODS обновление цели.

В качестве цели выступает куб. Данные в него попадают, но признака
доступности в BEX нет.

проверь установки автоматической обработки запросов в кубе.

вообще то подобные темы уже поднимались - поиском пройдись по форуму....

Установка качества на OK отмечена.

Искал, но не нашел.

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

В мониторе цепочка вся исполнена. Все зеленое. Проходит минут 10,
а результат тот же. К тому же при начатии на refresh все сразу становится доступно. А записей загружаю всего около 20. Так что на
незавершение процесса не похоже.

После подтверждения обновления появляется диалоговое окно

---------------------------------------------------------------------------
Технический №запр-ИдОснД изменено: с 0 на 8818
№запр-ИдОснД качества изменено: с 0 на 8818
Метка времени качества изменена: с 0 на 20050727131000
Выполнить обновление в управляющей таблице статуса для куба STAR5?
----------------------------------------------------------------------------

Нажимаю ok и тогда данные доступны для запросов.
Что все-таки не так.

проверьте в настройках ODS установленные параметры: стоит ли галочка на пункте "Автоматическое обновление целей данных из ODS". Может в этом дело?

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

В ручном режиме (при запуске инфо-пакета) все нормально отрабатывает, а в цепочках нет.

Почитал на SAPFans. У многих схожие проблемы.

Однако

1. У меня нет агрегатов и, следовательно, сворачивать в них
нечего.

2. Перестроение индексов в процессе загрузки не совсем правильное
дело (особенно, если в перспективе загруженных данных будет
много, а новых мало).

3. Еще какой-то совет был о том, что надо запрос в Bex создавать до
первой загрузки (бред какой-то, может не так понял).

4. Статусы у меня зеленые где только можно.

5. У меня обычный базовый куб.

Еще добавлю, при сжатии или перестроении индекса, все проходит успешно и в цепочке (но мне ни то, ни другое не требуется)

Сам себе похоже вопросы задаю. Прелесть. Тогда еще спрошу.
В документации сказано, что F-таблица автоматом разбивается на партиции, а E-таблица - только вручную. То есть каждый запрос
при загрузке попадает в собственную партицию. Таким образом при
загрузке 100 запросов без их сжатия мы получим 100 партиций на E-
таблице. Для каждой партиции создаются локальные индексы.
Следовательно - удаление индекса, загрузка в куб и создание
индекса для одного запроса будут задействовать только одну партицию. Это означает, что потерь в производительности при удалении и создании индекса быть не должно (при условии, что при этих операциях не задействуются глобальные индексы?!). Короче, нет ничего плохого в удалении и создании индекса при каждой загрузке.
Или я ошибаюсь?

если создаем цепочку, то drop index и create index перед выполнением пакета вставляются по умолчанию ( если сие не отключено в настройках ) . по хорошему так должно и быть. при запуске отдельного пакета так и происходит - дропается индех, загружается информация, потом создается индекс. В общем случае загрузка в таком режиме эффективнее и быстрее проходит, нежели если индекс будет престраиваться находу при записи каждой записи. При этом вновь создаваемый индекс - особенно для b-tree индекса по опредлению будет сбалансированным и "хорошим", что не может не сказаться на общей производительности.

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

Я так понимаю 2 млн применительно к F-таблице.
Термин логическое партицирование мне не совсем понятен. Это
общий размер в записях всех запросов (в F-таблице), которые еще
не были сжаты?!