Программа конвертации данных писана на VFoxPro.
Качает более 8000 документов, большая часть из которых с длинной историей.
Проблема в том, что документы без истории конвертятся в 4 (!) раза медленнее, чем с историей.

Загрузка сервера не превышает трети всех ресурсов. Клиент (где собственно и происходит конвертация данных для последующего занесения в БД) загружен наполовину или более.

Грешили на распределение памяти конвертера, кушает много, освобождает редко и приходится периодически чистить, но толку очень мало.
Сейчас грешим на железо, поскольку обе станции работают уже пятые сутки. Сервер справляется, клиент сильно тормозит.
И такая ситуация складывается на третьи сутки.
Какие еще есть идеи, предположения?
У нас фантазия иссякла.

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

PaulWistРассказал бы ещё чего-нибудь?

- как организованы транзакции при перекачке
- как происходит определение необходимых данных для закачки
- через какой механизм происходит закачка (через ODBC соединения или через xp_cmdshell, или через OPENROWSET)


Транзакции организованы по умолчанию,одна команда - одна транзакция.
Закачка идет через ODBC - соединение.
Конвертация необходимых данных (насколько я поняла разработчика), идет по схеме: любой тип dBase переводится в символьный, а при занесении с таблицу sql сервер сам конвертирует из символьного в тип заполняемого поля.

Вообще не знала, что так можно делать.

PaulWist1. Посмотреть на установку трайсера для ODBC (Control Panel - ODBC - закладка Tracing, галка д.б. снята)

2. CAST and CONVERT в BOL явное и неявное преобразование типов.

3. Есть ли наличие индексов в DBF/SQL?


Галку проверю.
С преобразованием типов фигня полная. По словам программиста, все пущено на самотек. Попробую завтра добраться до исходников.
Индексы есть, много.

Igor Korolyov
Hi trinity!

Не видя кода сказать ничего разумного нельзя.

Posted via ActualForum NNTP Server 1.3

Я понимаю.
Завтра будут исходники, может что прояснится.
Но факт остается фактом, эффективность одного и того же кода на третьи сутки работы падает в четыре раза на меньших нагрузках.

PaulWist1. Посмотреть на установку трайсера для ODBC (Control Panel - ODBC - закладка Tracing, галка д.б. снята)

2. CAST and CONVERT в BOL явное и неявное преобразование типов.

3. Есть ли наличие индексов в DBF/SQL?

Трассировка отключена.
Все индексы перед закачкой удаляются.
Индексация происходит после закачки всех данных.

Не поняла, что такое BOL?

Еще такой момент, программа сьедает почти всю оперативку, но загрузка проца не превышает 6% и на сервере и на кленте.

PaulWistЕщё вопросы

- этот конвертер выполняет одноразовую работу или запускается по расписанию
- есть ли в командах или ХП сервера конструкции типа IF EXISTS SELECT ....
- каков размер БД на сервере и как стоит приращение БД в % или Mb.
- есть ли индексы для DBF


BOL - Book On Line - хелп для MSSQL.

1. одноразовая
2. нет
3. Не совсем понятно, какая база интересует. Итоговая получается 4 гига, а исходная 700 метров
4. Индексы есть

приращение в процентах (10)

Проблема решена. Как и предполагалось, косяк был в индексации при занесении в одну из таблиц.
Не буду углубляться, у всех бывают ошибки.
На медлительность MS SQL при конвертации форматов
можно грешить очень незначительно, хотя все наверное зависит от задачи. Но быстрее будет перегнать неродной формат закачиваемых таблиц в sql, а потом уже заниматься его обработкой. Это если кому пригодится.