Расхождения между словарём и базой для таблицы адаптацией не устраняются . Данные важны . Расхождения по добавленному полю и наличию первичного индекса . Как можно выравнить ?

мммм не совсем вопрос ясен. Если только индекс - то удалить и создать по новой.

Индекс не создаётся , поскольку говорит , что такое имя уже используется для существующего объекта . На самом деле индекс уже из базы то же удалили !

так не бывает... все тильды и цифирки учли?

Бывает !
При попытке его создания из словаря :
ORA-00955: name is already used by an existing object

значит объект с таким именем в базе существует - а Вы говорите, что удалили.
Я и говорю, что так не бывает. Уточните полное наименование первичного индекса - возможно вы какую-то тильду или номер не учли?

Так цепляйтесь к Ораклу напрямую и смотрите внимательно: есть такой объект или нет. Оракл едва-ли глючит с "name is already used"

Коллеги, доброго времени суток, хочу продолжить данную тему: ситуация была как описано выше, первичный индекс пришлось создавать из оракла, т.к. средствами сапа ничего не получалось (хотя, может у меня просто мало опыта), вопрос в том, почему так происходит, и как это лечится? Пришлось восстанавливать данные в адаптированной табличке из временной копии (qcmXXX), но это же косяк! Система 4.6С, оракл 8.1.7.2, базис и абап 54 уровня. Поделитесь опытом пожалуйста.

dropается этот индекс на уровне oracle. И создается через se11. Иначе не увидите этот индекс через sap

он дропается на уровне оракла, его просто уже нет см. ситуацию описанную выше, а вот по поводу SE11 можно поподробнее?

Элементарно...

А можете вот так:
select * from dba_indexes where owner = 'SAPR3' and index_name like '%bla_bla_bla%'; -- есть такой или нет?

SE16/SE14 - выбираем табличку и смотрим индексы. Так же, в DB02 можно сделать проверочку и посмотреть недостающие индексы. В базе может индекса и не быть, а вот в словаре САПа он еще есть и статус у него может быть активный. Так же, возможно переактивировать данный индекс и он будет создан в БД.

Спасибо за ответы, но назрел еще вопрос, ситуация следующая: при изменении домена в табличке с большим объемом данных, процесс адаптации вылетал на шаге переноса данных из временной копии таблицы в новую таблицу, с ошибкой о невозможности расширить индекс (т.е. о достижении максимального числа экстентов). Пробовал исправить ситуацию так: находил индекс в базе и ставил количество экстентов unlimited, запускал процесс заново, однако он вылетал на том же месте и с той же ошибкой. Как выяснилось, SAP генерит SQLный код в котором пересоздает индексы и вот в этом коде он и указывает количество экстентов, а потом, в процессе адаптации лочит индекс и не дает исправить кол-во экстентов. Вопрос в следующем, где физически хранится SQLный код в SAP для процесса адаптации таблички. Хочу залезть в него и указать нужное мне количество экстентов.

storage parameters таблиц генерятся сапом из класса таблиц (se11 - technical settings), у индексов - или из таблицы берётся, или у индекса что-то подобное есть, посмотреть сейчас не где. В любом случае сразу после создания индекса ты можешь увеличить next extend и max extends например из se14.

Да это то понятно, что и где хранится и на основе чего генерится, суть вопроса в другом: процесс адаптации таблицы был прерван и SAP уже где-то сгенерил SQL-код и хранит его (как я подозреваю), т.е. я запускаю процесс адаптации не с нуля а с 5-го шага, на котором заново создается таблица и индексы, поэтому мне нужно именно в SQL-коде SAPа поменять количество экстентов у индекса.

нигде никакой сиквел не хранится. он генерится тогда когда нужен. Следовательно - вы меняете нужные параметры и они вступают в действие.