Здравствуйте!

Несколько фирм разрабатывает АСУ предприятия, каждая свой кусок. Будет несколько разных баз данных под управлением одного сервера Oracle (скорее всего 9.х). Необходимо организовать передачу данных между базами, причем планируется делать это по расписанию, т.е. раз в день, раз в час.

Опыта работы с Oracle почти никакого, поэтому вопрос: можно ли такую связь организовать средствами только сервера Oracle или придеться писать промежуточное ПО?

Заранее спасибо.

Здравствуйте, syn, Вы писали:

syn>Здравствуйте!

syn>Несколько фирм разрабатывает АСУ предприятия, каждая свой кусок. Будет несколько разных баз данных под управлением одного сервера Oracle (скорее всего 9.х). Необходимо организовать передачу данных между базами, причем планируется делать это по расписанию, т.е. раз в день, раз в час.

syn>Опыта работы с Oracle почти никакого, поэтому вопрос: можно ли такую связь организовать средствами только сервера Oracle или придеться писать промежуточное ПО?


Можно. Смотри в сторону репликации

Здравствуйте, Stepkh, Вы писали:

syn>>Здравствуйте!

syn>>Несколько фирм разрабатывает АСУ предприятия, каждая свой кусок. Будет несколько разных баз данных под управлением одного сервера Oracle (скорее всего 9.х). Необходимо организовать передачу данных между базами, причем планируется делать это по расписанию, т.е. раз в день, раз в час.

syn>>Опыта работы с Oracle почти никакого, поэтому вопрос: можно ли такую связь организовать средствами только сервера Oracle или придеться писать промежуточное ПО?


S>Можно. Смотри в сторону репликации

Все, что я прочитал про репликацию, касалось организации передачи данных между несколькими серверами Oracle, которые при этом должны были иметь одинаковые схемы данных.
Меня интересует, можно ли в SQL-запросе обращаться к другой базе (схеме). Или, например, написать процедуру, которая бы перекачивала данные из одной базы в другую и запускалась по определенному расписанию.

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

Здравствуйте, syn, Вы писали:

syn>Здравствуйте!

syn>Несколько фирм разрабатывает АСУ предприятия, каждая свой кусок. Будет несколько разных баз данных под управлением одного сервера Oracle (скорее всего 9.х). Необходимо организовать передачу данных между базами, причем планируется делать это по расписанию, т.е. раз в день, раз в час.
Несколько непонятно , что Вы имеете ввиду во фразе "под управлением одного сервера Oracle".
Это может быть один экземплер (Instance) Oracle, на котором в разных схемах живут разные "базы данных"
(логической единицы "база данных" в Oracle нет). Тогда, вообще говоря, связь между "базами" может осуществляться напрямую или почти напрямую через специально созданные VIEW и никакого расписания не надо, данные всегда свежие и "прямые".
Если все же по каким то причинам Вам требуется все таки "перекачка" данных (ну, например, нужны не все данные или какая то их резщультируюшая агрегация) можно воспользоваться материализованными представлениями и задать расписание обновления.

Если же вы имеете ввиду несколько экземпляров (Instance) Oracle на одном физическом сервере, то надо смотреть как Вам написали выше в сторону репликации.

Мне ближе первый вариант потому как проще, минусом его может являться то, что при остановке экземпляра для каких либо работ мы останавливаем все "базы", а также возможная "несовместимость" схем между собой в результате кривых
ручек "Нескольких фирм".

syn>Меня интересует, можно ли в SQL-запросе обращаться к другой базе (схеме).
Можно, <имя схемы>.<имя объекта>, или создать синоним на объект и обращаться по имени синонима.
syn>Или, например, написать процедуру, которая бы перекачивала данные из одной базы в другую и запускалась по определенному расписанию.
Процедуру написать можно (см. PL/SQL Procedures and Packages), запускать по расписанию тоже (см. пакет DBMS_JOB).

Еще можно покопать в сторону "хранимых" представлений (Materialized views).

Здравствуйте, syn, Вы писали:

syn>Меня интересует, можно ли в SQL-запросе обращаться к другой базе (схеме)
Можно, для этого есть линки между базами Oracle

Здравствуйте, KisA, Вы писали:

KA>Мне ближе первый вариант потому как проще, минусом его может являться то, что при остановке экземпляра для каких либо работ мы останавливаем все "базы", а также возможная "несовместимость" схем между собой в результате кривых
KA>ручек "Нескольких фирм".

+

Рискну предположить, что, если несколько фирм пишут одну АСУ, то база все-таки должна быть тоже одна, в смысле, совместно спроектированная. Наверняка, будут и общие куски (схемы).
А на кривые руки нужны регламенты внесения изменений, создания объектов и пр. И злой админ для стучания по почкам Я учавствовал в подобном проекте. Были и общие, и "необщие" схемы — никаких особенных проблем не помню.

Здравствуйте, MarkDev, Вы писали:

MD>Рискну предположить, что, если несколько фирм пишут одну АСУ, то база все-таки должна быть тоже одна, в смысле, совместно спроектированная. Наверняка, будут и общие куски (схемы).
MD>А на кривые руки нужны регламенты внесения изменений, создания объектов и пр. И злой админ для стучания по почкам Я учавствовал в подобном проекте. Были и общие, и "необщие" схемы — никаких особенных проблем не помню.

Как раз сейчас идет согласование ТЗ на нормативную базу предприятия. Просто у каждой фирмы есть свои наработки в соответствующей области и свои схемы данных. Планируется, что в дальнейшем каждая фирма будет самостоятельно дорабатывать/развивать свой кусок.
Но одна из фирм предложила обмен данными через локальные файлы. Я сильно засомневался, что у Oracle нет готовых решений для таких задач. Здесь предложили несколько решений, мне больше понравилось сделать VIEW на импортируемые данные. (При этом есть возможность корректировать свою схему данных, главное, чтобы структура VIEW оставалась неизменной). Если online работа не подойдет, то в другой схеме написать процедуру для перекачки данных и запускать ее по расписанию.

Всем спасибо за предоставленную информацию.

Здравствуйте, syn, Вы писали:

syn>Как раз сейчас идет согласование ТЗ на нормативную базу предприятия. Просто у каждой фирмы есть свои наработки в соответствующей области и свои схемы данных. Планируется, что в дальнейшем каждая фирма будет самостоятельно дорабатывать/развивать свой кусок.
Над всем этим зоопарком должен обязательно стоять дядька с плеткой. А вообще — дело 100% безнадежное.

syn>Но одна из фирм предложила обмен данными через локальные файлы.
Сумашедшие.
syn>Я сильно засомневался, что у Oracle нет готовых решений для таких задач. Здесь предложили несколько решений, мне больше понравилось сделать VIEW на импортируемые данные.
Нет такого понятия — VIEW на импортируемые данные. Или работает один экзепляр — и каждая контора работает в своей схеме — никакого реплицирования, перекачивания не нужно. Из одной схемы можно напрямую обращаться к объектам другой схемы при наличиии соответствующих прав. Либо 2-ой вариант — каждая контора работает со своим экземпляром Oracle. Тогда нужно наладить линки (database links) между экземплярами — и опять, обращаться в запросах как к обычным таблицам. Никакого реплицирования и перекачивания. Но этот вариан заведомо гибельный — если таких контор много — то железа точно не напасетесь.
syn>(При этом есть возможность корректировать свою схему данных, главное, чтобы структура VIEW оставалась неизменной). Если online работа не подойдет, то в другой схеме написать процедуру для перекачки данных и запускать ее по расписанию.
Раз все работают с Oracle базы не территориально распределенные — нафига какое-то реплицирование и перекачивание — объясните?

syn>Всем спасибо за предоставленную информацию.

Спасибо за внимание.

Здравствуйте, syn, Вы писали:

syn>Здравствуйте!

syn>Несколько фирм разрабатывает АСУ предприятия, каждая свой кусок. Будет несколько разных баз данных под управлением одного сервера Oracle (скорее всего 9.х). Необходимо организовать передачу данных между базами, причем планируется делать это по расписанию, т.е. раз в день, раз в час.
syn>Опыта работы с Oracle почти никакого, поэтому вопрос: можно ли такую связь организовать средствами только сервера Oracle или придеться писать промежуточное ПО?
syn>Заранее спасибо.
можно посмотреть Oracle Streams