Проблемы с структурами 2LIS*

Однажды как то пришлось исполнять эту ноту, геморой ещё тот, ибо проблемы были с 03 экстрактором, а склады прерывали свою работу только раз в году и то на 2 дня , на новый год.
Температура за окном +30 подсказывала что новый год не скоро, а проблема с очередью в SMQ1 и разностью структур экстратора уже есть.

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

Note 835466 - Using the repair mode of the hash solution


Symptom
With the function for checking the LBWQ for structure changes (the hash solution), a termination is forced when the update report RMBWV3xx is run (xx = application number) if the structure of the data in the LBWQ does not correspond to the current ABAP Dictionary version.

This occurs when changes are made to extract structures of the LO Customizing Cockpit, even though data of the 'old' structure was contained in the extraction queue (LBWQ).



The update can only run successfully if the LBWQ contains only the data of the currently valid ABAP Dictionary version.

You can use repair mode to update the data with the 'old' structure.

This note describes how to carry out the data correction.

Note:
During the check, the entire interface of the extraction module is checked. Note also that changing an inactive DataSource means changing the interface. Extract structures can only be changed if there is no data in the LBWQ (see also Note 762951).


Reason and Prerequisites
Note 834897 and the relevant application-specific notes for the hash solution are prerequisites.

Solution
The subsequent actions must take place in a posting-free period. It is absolutely essential that new data does not arrive in LBWQ during repair mode.

Step 1:
Lock your users and ensure that no IDocs are imported and that no batch tasks are running, and so on.

Step 2:
Ensure that there is no longer any data in transaction RSA7.

Step 3:
Then set the user parameter MCEX_REPAIR_MODE with the application-specific value. You will find this value in the relevant note of the application for the hash solution.

Step 4:
Undo the change to the extract structure/DataSource and replicate the DataSource to BW. Activate the transfer rules of the DataSource.

Step 5:
Then start the report RMBWV3xx (xx = application number) manually in transaction SE38.
This report MUST be executed by the same user for which the user parameter was set.
All data that was generated with the 'old' structure is then updated and set in transaction RSA7.
The program termination occurs again when the first data record is posted with the 'new' structure.

Step 6:
Then load the data in transaction RSA7 into BW.

Step 7:
Then restore the structure changes. Replicate the DataSource into BW again and activate the transfer rules.

Step 8:
Start the update report again. You should now be able to update all data.

Step 9:
Finally, delete the user parameter MCEX_REPAIR_MODE.

Step 10:
Document processing can now be reactivated.


For example:
Initial situation in LBWQ:

Data record 1 - structure 1
Data record 2 - structure 1
Data record 3 - structure 1

Data record 4 - structure 2
Data record 5 - structure 2


1.) Steps 4 - 6: Structure 1 is restored and the relevant data is updated.


New situation in LBWQ:
Data record 4 - structure 2
Data record 5 - structure 2
*клево. только обычно операция на живой системе происходит и у Вас уже есть Data record 6 - structure 1 :(


2.) Steps 7 - 8: Structure 2 is restored and the data is updated.
There is no longer any data in LBWQ.

If several structure changes occurred one after the other, and there are more than two structure versions in LBWQ, you must proceed step by step in the same sequence in which the versions were generated. Steps 4 to 8 must be executed repeatedly until the update report runs successfully again.

Признак с большим кол-вом записей

Сценарий проблемы:

Имеется признак с большим кол-вом записей и большим кол-вом навигационных атрибутов (приблизительно более 45). В признак добавляется новый навигационный атрибут или дисплей атрибут переводится в навигационный. При переносе в продуктив очищается X-таблица (Сиды атрибутов) и выполняется Insert во временную таблицу (что бы потом ее содержимое записать в X-таблицу). Это команда выполняется часами. Отчеты не работают.

Решение от SAP в письме ниже.
Мы применили ноты 536223 и 1466536.
После применения ноты 536223 система стала загружать сиды частями, по 10 атрибутов за раз. Общее время переноса сократилось до нескольких минут.

Dear Customer,

In first place,
According to the note 536223 (the instructions provided in 'Solution'
part), you should try to set the value of parameter SPLIT_SX_TABL_THRES
to 10, and try to run the transport again.
Also, please implement:
   1466536 Long runtimes when transporting InfoObjects
   1556266 RSD1:Err. converting display attribute to navigation attrib.
   1618989 Error when using SID for conversion to navigation attribute
If you havent already implemented.
This will improve performance.

Спасибо, Митя!