Как стать автором
Обновить
10
0

Разработчик приложений баз данных, DBA

Отправить сообщение
попробовал, результат такой же, как и в первом случае 2 минуты 49 секунд на 1000 строк.
insert into RemotePG...RemoteTable (RecordID, RecordName)
select top 1000 RecordID, RecordName
from LocalTable with(nolock)
у меня сложилось некоторое предубеждение против SSIS, уж больно он капризный. но вы меня убедили, возьму себя в руки и попробую на какой-нибудь большой таблице. отпишусь по результатам.
это не если, а вполне работает, выше ответил. удалённые сервера, это тупенькие машинки, 2Гб оперативки, на целеронах, используются как POS терминалы в розничной сети.
в реальной жизни данные вставляются блоками по 500 записей. в таком случае, в случае обрыва, можно продолжить с того места, где закончил. а не пытаться запихнуть 1млн. записей разом.
есть несколько блоков данных, условно медленные и быстрые, быстрые — раз в час, медленные два раза в сутки. проблема в том, что хостов, на которых эти данные нужны, больше сотни. таблиц, которые таким образом синхронизируются примерно два десятка.
а чем SSIS пакет будет принципиально отличаться? когда-то давно пробовал SSIS с единственным mysql, скорость была похожа, как если бы я просто исполнял запросы из консоли.
главное не в INSERT с большим количеством строк за раз, а, всё-таки, удалённое исполнение этого запроса.
начну с конца. про главного врага и да и нет. я специально писал про удалённый сервер, но в реальности ситуация с локальным точно такая же. мне кажется, главный враг — это ожидание подтверждения транзакции со стороны mssq. про количество соединений, если честно не догадался проверить, вы утверждаете, что в одной транзакции mssql каждый раз открывает новое соединение?
блоки, которые сейчас используются в бою, это примерно 30Мб раз в час, на сотню узлов PostgeSQL, и примерно 150Мб два раза в сутки, на ту же сотню хостов.
способ с архивацией — передачей — распаковкой хорош, но хотелось обойтись без ещё одной детальки, которая может сломаться.
с одной стороны, да, ничего особенного, с другой, когда стоит задача передать много данных, и вроде бы механизм для этого есть, а пользоваться им невозможно, захотелось рассказать как это решено.
наверное тут дело и в ровном рельефе. у меня стандартный маршрут 43км. за примерно 1:50, 23км/ч, но с набором высоты около 200м. вот на горках я и потею. опять же, это на мтб со злой резиной, поставить слик/полуслик, и либо потливость убавится, либо средняя выростет.
это вы, непонятно с чего, решили что меня плохо учили и начали читать лекции и объяснять на пальцах.
не понял какая связь. и почему надо ждать пока будут нанесены десятки тысяч ударов. С-300 американцы не горят желанием испытывать в реальных условиях.
да, забыл кавычки у «невидимки». за лекцию для физика, где военная кафедра была на комплексе С-300, с его настройкой и программированием, спасибо.
интересный диалог:
— против каких именно ПВО?
— Вьетнам, Ливия, Ирак, Югославия…
угу, позор, с помощью ПВО разработанно в 50-х годах сбили невидимку. в зоне действия С-300 сша не летает.
было бы здорово увидеть, против каких именно ПВО американские лётчики так успешно воевали. на тему «воевать уменьем» вспоминается эпизод со сбитым с помощью С-125 стелсом f-117 во времена югославской войны.
написано смертность среди пешеходов (pedestrians) стукнутых транспортным средством, которое в основном, всё-таки, автомобили. и на малых скоростях (20-30 км/ч) сильно зависит от водителя, его реакции, можно на 20км/ч ехать и переехать полностью, а можно чуть стукнуть и остановиться.
может быть скажу глупость, моторы в разные стороны, возможно потому, что они стоят на платформе сориентированные в противоположные стороны.

offtopic: буквально сегодня шарил по китайским магазинам собирая похожий набора, и именно с такой же целью – чтобы ребёнок что-то потрогал руками. просто программирование на питоне в каком-то виде учит давно, пора освоить си-подобный язык, и заодно воплотить связку кода с железом.
да, теперь понятно, я почему-то ваш первый комментарий истолковал, как миграцию с одного вендора в девелоперской версии в, например, другого вендора в тестовой версии.
именно, миграция с одной СУБД на другую.
гуглил, и что уж там, пытался мигрировать с ms sql, на, как раз postgres. если в БД хранимые процедуры измеряются тысячами, это малореальная задача. и мне кажется, что в более-менее больших проектах, лучше использовать особенности каждого вендора по максимуму, чтобы не было ситуации «работает везде, но не очень».

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность