А структуры баз одинаковые ? Нужны ли проверки целостности, валидность данных или нет ? Если структуры одинаковые и проверки не нужны, то наверное все таки самый быстрый способ через текстовые файлы (Bulk Load). Если структуры не одинаковые или проверки нужны, то задача усложняется. Я бы лично такую задачу реализовал через ETL инструменты, но для этого надо немного знать сам один из ETL продуктов, ну и иметь его инсталляцию естественно.

P.S. Прокси не пойдут. Как Вы себе представляете формирование запроса получения данных на Oracle на таблицу с большим кол-вом данных и запихивание ее в одной транзакции в ASE ? А если даже бить на порции запросами, то производительность тоже не на высоте будет. Ну и плюс если не так что то пойдет, текстовые файлы можно перегрузить с того момента, где был затык, а вот запросами это опять время на получение самих данных с базы источника.

White OwlИ RS и DI это две полноценные ETL системы. Решающие одинаковые задачи и впрямую конкурирующие на рынке.
Те кто использовал обе системы могут их сравнивать и высказывать свои личные мнения. Высказывание этого мнения подразумевает что человек имеет опыт работы с обеими системами. Иначе у него не было бы этого мнения.
Мое личное мнение: RS намного удобнее и надежнее DI. У DI намного ниже порог вхождения, но RS намного быстрее работает и в итоге он намного удобнее, особенно для людей привыкших к скриптам.
Replication Server вообще ничего близкого к ETL не имеет. Где там поддержка различных механизмов трансформации данных, где маппирование, где поддержка SCD измерений, поддержка lookup, поддержка CDC промышленных БД и т.д. и т.п. ? ETL это намного больше, чем копировалка данных с поддержкой скриптов, а RS вообще из другой оперы и то, что из него можно сделать копировалку данных не означает, что он стал ETL. Ну с натягом можно назвать ELT, но никак не ETL :)

Всех с Наступающим Новым Годом!

White OwlОн решает ETL задачи?
Вот как раз ключевый момент, чтобы не спорить - термин "ETL задачи". Судя по всему я и ты вкладываем разный смысл в этот термин.

White OwlASCRUSпропущено...

Вот как раз ключевый момент, чтобы не спорить - термин "ETL задачи". Судя по всему я и ты вкладываем разный смысл в этот термин.Я вкладываю дословный - Extract-Transform-Load, а ты какой?
Extract - основная задача с любого источника достать информацию любого формата. Под любым источником можно понимать действительно любой, не обязательно РСУБД или файл. Это может быть FTP, поток, веб сервис, LDAP, ERP система, OLAP сервер, MUPS ... что угодно. Так же любым форматом данных не обязательно должен быть формат двумерных данных. Это может быть собственный формат, многомерный куб, XML, формат обмена данными существующих систем и т.д. Так же в задачи Extract входит управление данными источника, это копирование, перемещение, удаление данных, архивирование. Так же важной задачей в данном процессе является поддержка захвата изменений данных (CDC) с источников, что позволяет снизить нагрузки на источник данных при получении данных с него. Так же дополнительной задачей является проверка форматов и наполнения загружаемых данных, с обработкой обнаруженных ошибок.

Transformation - задача преобразовать данные в нужную форму. Это может быть слияние или разделение данных, вычитание, агрегация, сортировка, фильтрация и т.д. Важной отличительной особенностью средств ETL является то, что полностью вся трансформация данных выполняется самим продуктом ETL, без привлечения источников или приемников данных. Это гарантирует высокую скорость трансформации данных и позволяет не нагружать источники и приемники дополнительной работой. К слову сказать, если полученные данные прогружаются на какой то сервер (так называемая стэйджинговая область) и их обработка происходит там путем посыла запросов на сервер, это уже называется ELT (Extract Loading Transforming). Такой подход так же применяется, но ETL назвать его нельзя.

Loading - задача в любой приемник записать информацию нужного формата. Здесь полная аналогия с источником, приемник и формат могут быть разнообразными и не обязательно это РСУБД. Здесь важным моментом является поддержка высокоскоростных интерфейсов приемников по загрузке данных одним блоком, поддержка загрузки записей пакетами, обработка ошибок загрузки записей в приемник. Так же, когда используется в качестве приемника ХД, дополнительно на процесс накладываются требования обеспечить ведение во времени изменений измерений (SCD), ведение синтетических ключей для измерений и фактов, установка синтетических ключей измерений в факты по натуральным (lookup).

Соответственно, если взять к примеру задачу , где нужно по фтп получать события в виде файлов, вытаскивать их и попутно вести архив обработанных файлов, одновременно с РСУБД тащить справочники, с Excel и веб сервисов подгружать дополнительные сведения, все это денормализовывать в звезду и записывать в DWH - это чисто ETL задача, причем достаточно примитивная и любой нормальный продукт ETL должен ее позволить сделать с полпинка без написания каких либо скриптов, не используя в работе процессов никаких РСУБД или сторонних продуктов - собрал данные с источников, обработал на своем инстансе, результат в ХД залил через bulk load. Если все это RS делает ... ну что же, снимаю шляпу и дальше не спорю.

:) Ладно, бог с ним с этими терминами. На самом деле ELT часто хватает выше крыши ;)