dgdogПусть на каждой из "200 БД" запускается служба подготовки к выгрузке.

(базы разные от 1С, Firebird, ... и до простых текстовых файлов экспорта из клиентбанков)

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

грубо говоря, берешь своего клиента, вырезаешь из него все источники, кроме одного нужного на конкретном месте, и делешь программу выгрузки данных для Ивановой Марьи Владимировны.

Остальные базы лежат где-как и в локальной сети и на удаленках... я из них только данные тяну на клиента, а уже потом фигачу в БД

БД сдохла, забудь. Эту работу можно теперь делать только на других машинах.

Либо на самих источниках данных по мега-файлу запроса к репликации - НЕ ТРОГАЯ ОСНОВНОЙ СЕРВЕР вообще

Либо создавать второй сервер, на него выгружать полную копию основной БД - см. nbackup - и там молотить твои 40 минут опять таки НЕ ТРОГАЯ ОСНОВНОЙ СЕРВЕР, сохраняе изменения в файл-пакет, и уже готовую выжимку не требующую больше проверок - отсялать на основной.

Во втором случае, однако, потенциально будут две проблемы:

1) пока твои 40 минут шли бухи что-то сделали с основной БД и пакет подготовленный по слепку 40-минутной давности уже не подходит 1 в 1, нужно его обрабатывтаь напильником. Может такое быть или нет? Не знаю, только ты знаешь с какими данными кто работает в твоей системе.
2) сегодня у тебя 200 баз, а завтра 20 000 - и второй сервер так же захлебнётся.

То есть второй вариант - это быстро заткнуть дырку и отдышаться. А в конечном итоге тебе все равно придется работу распараллеливать.

Симонов Дениси какая связь между количеством БД 1С'овских и архитектурой?

прямой нету

но примерно в такой же пропорции увеличивались и остальные рабочие места - в том числе работающие с его ФБ-самопиской.

Надеюсь, запросы не текстом каждый раз наново формируются, а используют параметры и prepare ?


группируй свои запросы, хотя бы по дате

http://bobby-tables.com/ru_RU/delphi.html

ну и до кучи

линейный поиск на клиенте (типа FieldByName и ParamByName в Delphi) тоже использовать в цикле НЕЛЬЗЯ

если подобное у тебя есть - убирай его наружу циклов

dgdogПрактически так оно и есть. Запускается десять разных клиентов которые тащат конкретные данные из конкретных источников. Но мне каждую строчку надо сверить с моей базой

НЕ НАДО

делай клиенты, которые не будут трогать основной сервер вообще.

сервер должен подготовить ОДИН общий zip-файл с требованием к репликации и всей сопутствующей инфой, которого будет достаточно ЛЮБОМУ клиенту для проверки всех его записей НЕ ТРОГАЯ сам сервер

dgdogЗапускается десять разных клиентов которые тащат

ЦП кстати гавно I5

ну так запускай свои 10 клиентов на 10 разных процессоров

если даже один i5 для тебя мелочь несущественная, то 10 штук i5 побыстрее будут

Dimitry SibiryakovВо-вторых, у него на подготовку файла уйдёт больше ресурсов, чем сейчас.


судя по вышесказанному файл по сути будет линейной срезкой нескольких таблиц за три последних месяца

так что ресурсы если какие и будут нужны - то disk i/o и больше ничего

у него затык в процессоре => поставить отдельный винчестер исключительно под формирование пакета и прием ответных пакетов означает разгрузить его бутылочное горлышко, что ему и требуется

dgdogНагрузка то на сервер не уменьшается. Сейчас параметрами шьет.

Prepare делаешь ? как минимум Prepare добавляет нагрузку серверу на каждый отдельный запрос

либо решай радикально - избавляй сервер от этой работы вообще

либо грызись за каждый каждый процент, в том числе и по возможности убирай каждый лишний случай парсинга SQL-запросов на сервере

dgdog,

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

потому что как-то это все странно звучит, если вместе

и i5 - дерьмо (вы русские есть очень много кушать!)
и одного нового процессора не получишь, хотя фирма растёт на дрожжах и заела себе сотни новых компьютеров с базами данных на них

странно это звучит вместе взятое