Привет. Возникла проблема: резко просела производительность экстракторов.

Значит, смотрю лог. Там так:



То есть, кто может объяснить, что происходит на этапе между "Запрос данных получен" и "Выбор данных запланирован"? Какие операции, куда смотреть на более подробные логи?

Если смотреть по логам экстрактора раньше, то эта операция занимала 3 (прописью: "три") секунды. Сейчас сервер тупит 2 часа 26 минут, причём непонятно по какой причине.

Добрый день.
Для всех без исключения экстракторов или для отдельных? Full or Delta? Размер пакета? Кол-во полей не увеличивали? Экстрактор стандартный или самописный?

Отреплицировать источник данных, переинициализировать дельту (если дельта-обновление) - не помогает?
Можно еще посмотреть, что твориться в SM50 в это время.
Если тихо, то пойти в RSA3 в исходной системе и протестировать нужный экстрактор.

Быть может в исходной системе фоновых процессов не хватает.

Ммм, для многих. В данном случае я привёл лог 0FI_AR_4, дельта, и его вроде не расширяли.

У нас есть один экстрактор, самописный, который качает из самой системы в неё же (физически из таблички в систему) - вот у него всё нормально, такой разницы между этими событиями не появилось.

Посмотреть, что творится в SM50 в четыре часа ночи идея неплохая, но если честно - очень хочется ночами спать, вот.

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

Они по цепочке запускаются? Какие условия запуска?
Может действительно, куча экстракторов начинает работать и в исходной системе тупо не хватает фоновых процессов для них всех, поэтому кто-то сидит и курит в это время.

(зачем 4 утра? нельзя разве днем прогнать? предупредить юзеров и стартануть)

Запускаются по цепочки, ну, там разные условия запуска В основном - просто один за другим работать должны. Они и отрабатывают. Просто существенно медленнее.

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

Короче, если говорить о вопросах. Нужны логи (а так гадать кто что сделал в это время можно очень долго). Ести ли возможность получить более подробные логи об экстракторах со стороны R3 и со стороны BW?

Вот он написал "Запрос данных получен" и ждёт кучу времени. Где посмотреть, чего он ждёт?

[s]SM37?[/s]

SM21? )

Увы, там ничего по этой теме нет...

Тэк-с, окей.

RFC-соединение какого пользователя использует для подключения?
Он диалоговый или системный? (su01 смотрим).

Если диалоговый/системный, то смотрим сколько в R/3 диалоговых и фоновых процессов в SM50.

не понимаю, что мешает посмотреть sm37 за ночь и понять что могло работать оновременно, благо время выполнения там есть. зачем ночью сидеть?

коллеги правильно говорят - смотрите нагрузку на систему ночью

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

и еще - потрясите админов - вдруг они запланировали бэкап на это время или какие нибудь процеудры обсдлуживания СУБД - тоже сажает серваки на ура...

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

Проблемы могут быть как на стороне Source System and BW.
Но, из всех симптомов, у Вас как и указали выше проблемы скорее всего на стороне Source System и вот почему =
На стороне Source System и на стороне BW могут выполнятся задачи. О которых сказал BW-ник.
Так как у вас проблемы при экстракции, то проблема по большей части на стороне Source System (Исходной системы).
Source System => InfoPackage => PSA
Source System, какие здесь могут быть проблемы = это те о которых описал BW-ник.
Source System и BW используют технологии ALE/tRFC позволяющих передавать данные.
Передача данных выполняется параллельно, значит нужно определять/настраивать уровень параллелизации.

Эти шаги выполняются на стороне Source system экстрактором. У вас стандартные экстракторы значит от SAP, здесь уже ничего не изменишь. И падение производительности носит системный характер.
Поэтому правильно заметили, что при экстракции необходимо определить проблемы с наличием свободных ресурсов Процессов. Транзакции sm50, sm51.
Далее проверяют обычно экстракцию в RSA3. Но у вас все OK.
Можно проанализировать в SE30 выбрав рабочие процессы с заданиями экстракции.
Фоновые задачи по экстракции на стороне ECC выполняет ALEREMOTE можем проанализировать SQL выражения (но это чаще всего для самописных экстракторов, но все таки просмотреть не помешает)его в ST05.
Обратите внимание на таблицу ROIDOCPRMS она очень важна для параллелизации. Число параллельных обработок = Число Фоновых процессов - 2.
Важен Размер Инфопакета влияющий на частоту выполнения например операции COMMIT в БД.
Все коды транзакции уже были описаны выше коллегами. А точный ответ вам вряд-ли кто даст, поскольку каждая система особенна по своему. Ваша проблема должна решаться с базисом.

549184 FAQ: What is important for extraction
417307 Extractor package size: Collective note for applications
157652 Main memory requirement for extraction from R/3

Мда... проблема проявляла себя три дня, и на четвертый как я сел её караулить ночью в SM50 - перестала.

У кого-то на небесах отличное чувство юмора

Привет,
Считаю, это может быть и проблема в BW и вот почему:
после того, как происходит "Запрос данных получен" экстрактор создает фоновое задание в системе, из которой экстракция будет делаться и посылает в BW "Выбор данных запланирован". При любых проблемах с этой системой фоновое задание будет создано быстро и поставлено в очередь на выполнение. Если в назначенное время старта у системы не окажется свободных ресурсов, старт выполнения будет задержан. Задачу и лог ее выполнения можно увидеть в SM37 - ее имя заканчивается на ID реквеста из BW. ID реквеста можно взять из монитора загрузки в BW. Утром, прийдя на работу, посмотрите, какая была задержка старта задачи, связанной с реквестом, а также лог ее выполнения. Там написано, когда началась выборка данных, когда их послали в BW. Сопоставив время, можно что-нибудь дальше разнюхивать.

Задержка может произойти при передаче сообщения "Выбор данных запланирован" из-за проблем в BW. Надо в системе- источнике открыть тр SM58 - очередь запросов TRFC для системы BW. В ней не должно быть много запросов. Если в ней все-таки их много, то надо разбираться, почему и в каком они статусе. Эти запросы по очереди должна обрабатывать BW. Если их много, то она их обрабатывает медленно, либо какой-то глючный экстрактор нагенерил их зря, а BW спокойно и планомерно их выполняет, либо просто сразу много экстракторов гонят свои данные в BW.

Надо проверить еще входящие IDOCи в BW (тр BD87). Если есть желтые и старые - смотреть, почему не происходит их обработка - либо настройки партнера, либо отказ системы из-за ресурсов.

Макс.