Пользователь
Логин:
Пароль:
Регистрация
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

 

Опрос


Погода

Медленная загрузка заявок с помощью data exchange

Форумы
Обновления
Поиск
Пользователи 
Правила
Помощь
Войти
Регистрация

Страницы: 1 2 След.
RSS
Медленная загрузка заявок с помощью data exchange, data exchange
Коллеги, последнее время значительно увеличилось время импорта заявок из Excel файла с помощью загрузчика СД. (data exchange). При этом ЭК или персонал загружаются достаточно быстро. С чем это может быть связано?
Как вариант нехватка индекса на таблице. Что именно передается? Создается объект или какая логика загрузки…?
Сколько в базе объектов на этой таблице?
Связи при загрузки используются? Пользователь, Услуга, (справочники)?
Передаются Пользователь, Сервис, Эк , Описание, Подробная информация, Группа назначения,
Связи используются, сервисы например передаются в виде Id
Предлагаю провести эксперимент, на тестовом стенде выполнить все тоже-же самое, но с отключение по одному полю, в загрузки. Данные нужно грузить одни и те же, каждый раз замеряя скорость загрузки, далее удаляя загруженные данные убирать по одному из полей в загрузки.
Если оценивать по полям, то «Подробная информация», «Связи используются», что такое «Эк»? В общем если разделить текстовую загрузку от связей, то можно будет понять причину, если загрузка ускорится при отключении связей, то дело в связанных таблицах, если в текстовых полях, то нужно смотреть на таблицу в которую производится загрузка.
Провел, убрал все поля, кроме двух.
время загрузки 2 заявок 8 минут.
Одно поле ID1 -id заявки как уникальное, но на него всегда warning и система ставит правильный id системный и время создания.
Может неправильный импорт, хотя раньше когда данных было мало процесс шел намного быстрее.
В БД только 500 000 заявок.
База на SQL?
Oracle 9, пока еще. переводим на 10 ку.
Цитата
Dima Kirsanov пишет:
Одно поле ID1 -id заявки как уникальное, но на него всегда warning и система ставит правильный id системный и время создания.


Немного вот этот пункт не понял…

Как вариант можно включить DEBUG и посмотреть что будет в логах. Если UP Time на сервере большой, то лучше выполнить плановую перезагрузку системы (для профилактики), чтобы точно дело бы не в утечке памяти. То-есть процесс импорта порождает создания некого объекта, скажем обращения, с какими-то связями так? Или это CMDB со связями? (или это Change с которыми работают специалисты…) – чтобы понять проблему, нужно понять процесс…
Суть в следующем, весь процесс загрузки обращений - заявок противоречит внутреннему процессу, но служба поддержки пошла на уступки специалистов технологов. которые выполняют работы. Координатор службы технологов присылает экселевский файл,который содержит порядка 700 плановых заявок на месяц. их надо завести все в сервис деске. Соответственно, чтобы технологи не производили это вручную, я загружаю эти используя data_ exchange.
Все заявки (то есть столбцы в файле) имеют - Пользователя (инициатора), Сервис (Услугу), Описание, Подробное описание , Группу назначения, Ответственного исполнителя, Статус (как правило Назначена). Соответственно некоторые поля, как инициатор например это связь с другой таблицей.
По отладке ничего не понятно, она отображает то же что и пишется в окне когда происходит создание объекта.
В результате этой заливки в СД создаются заявки в том статусе, который указан в файле. Потом исполнители заполняют решение, когда надо и закрывают заявку.
Теперь проблема ясна, база данных и сервер приклада это физически разнесенные машины или все на одной крутиться?
В обычном режиме работы замедления в системе наблюдаются? Система шустро работает или местами подтормаживает?
Страницы: 1 2 След.
Читают тему (гостей: 1, пользователей: 0, из них скрытых: 0)

Сегодня были (гостей: 34, пользователей: 3, из них скрытых: 2) Феликс Умнягин