Как правильно сделать бэкап из (PL/)SQL по сети?

Question

[Олег Чирухин]

Задача: Нужно делать бэкап данных БД (без схемы). Базку-источник изменять нельзя, т.е. это ридонли-бэкап.



Контекст: бэкап данных Оракла в произвольную БД по сети. Сейчас пишу интеграцию Оракла с Постгресом.



Ресурсы: только connection string, и возможность подключиться к базке с максимальными правами. Т.е. ssh до сервера нет, с жесткого файл с бэкапом по ssh не прочитаешь, и вообще на сервере может внезапно стоять венда.



Вопрос: Есть ли на таких условиях какой-нибудь быстрый проверенный способ стянуть данные? Может у кого завалялось готовое опенсорцное решение? %)



Слово «быстрый» тут присутствует потому, что просто селектать кусочками по N строк (через rownum или row_number()) и переправлять на целевую базку — излишне медленно.



Если у кого-то появится желание подискутировать на более глобальную тему — копирование из базки в базку по сети с оптимизацией по времени выполнения, вэллкам.



Спасибо

Comments

[Alexander Lebedev]

Вы писали>Нужно делать бэкап данных БД (без схемы)
Что это значит, какие данные имеются в ввиду, и что значит без схемы(схема=юзер у которого есть данные).
Что имеется ввиду под бекапом? Если репликация в другую БД то почему бы не воспользоваться GoldenGate.

[Олег Чирухин]

+cawaleb,

подрузмевалось схема = «чертеж» для создания БД, описанный формальным языком. Схема таблицы/отношения — это заголовок таблицы/отношения (набор аттрибутов, для каждого из них имя, тип/домен, порядок для SQL). В SQL-based RDBMS схема, кроме набора схем таблиц, включает еще и вьюхи, индексы, пакеты, процедуры, функции, итп

под «без схемы» подразумевается, что не нужно решать задачу анализа и формальной записи (анализировать структуру БД, как-то ее описывать, дампить в файл, отображать на другой тип БД например Oracle->Postgres, итп), предположим что она решена. Нужно скопировать только строки таблиц, сохраняя присущие строкам параметры (соответствие названию таблицы, порядку аттрибутов в заголовке таблицы, сохранение порядка строк).

под «бекапом» подразумевается резервное копирование данных (в нашем случае — строк таблиц) на какой-то внешний по отношению к базе данных сервер. Как написано в пункте «ресурсы», единственным средством коммуникации между сервером-БД и сервером-бэкапером является обычное подключение до БД (я использую Java, соответственно жавовский драйвер оракла и стандартный Connection, но расстаться с Жавой ничто не мешает), инициируемое со стороны сервера-бэкапера.

GoldenGate посмотрю — спасибо!
Вопросы по GG:
1) оно free+opensource? Не нашел исходников на сайте Оракла.
2) оно точно не требует никакой настройки со стороны сервера-источника данных? (подразумевается, что на сервере базы данных есть оракл, установленный с настройками по умолчанию, и это всё что у нас есть. Большинство утилит требуют всяких специальных настроек).

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

Answer 1

[bdmalex]

impdp,expdp — религия не позволяет использовать ???

Comments

[sparhawk]

Для них нужна папка на сервере. Судя по написанному, может не быть такой возможности.
Тогда просто imp/exp

Answer 2

[Alexander Lebedev]

В таком случае, для бекапа exp.
А для переноса в postgre сулукты через odbc/jdbc. Тут мало что придумаешь.

Comments

[Alexander Lebedev]

сулукты = селекты, конечно. Интересная опечатка получилась.

Answer 3

[shane54]

Как уже упоминалось, ваш выбор — Data Pump. Причем, в вашем случае есть два разных способа его использования. Можно настроить DB Link между базами и использовать Data Pump в режиме Network Export/Import (с некоторыми ограничениями на типы колонок). А можно на базе получателе запускать expdp(.exe) и соединяться с исходной базой путем указания TNS-Alias'а. Также обратите внимание, для выборочного бекапа Data Pump поддерживает гибкие возможности настройки – можно экспортировать только определенные объекты (таблицы в вашем случае), а можно и определенные наборы строк таблиц (хотя, справедливости ради, и старый exp(.exe) поддерживал условие Where). Ну и самое сладкое — т.к. искомый вопрос звучал «Как правильно сделать бэкап из (PL/)SQL по сети?» – Data Pump может выполнять все свои функции (а также кучу всего другого, чего невозможно выполнить через утилиты expdp/impdp) посредством API. Все есть в документации (официальной и «выжимке»). Отмечу лишь, на Data Pump’е можно реализовать реальную бизнес-логику, он в этом смысле очень далеко ушел от рядового средства экспорта базы данных. Из минусов, правда – безумное количество багов, заставить его работать так как нужно, может потребоваться достаточно продолжительное время. К тому же, если нет доступа к Металинку, найти специфические патчи именно для него будет большая проблема.

Comments

[Олег Чирухин]

Спасибо) Но нужно сделать одно маленькое замечание для людей, которые в будущем нагуглят этот вопрос. Я не нашел ни одного способа, как можно выполнить желаемое с помощью датапампа и других утилит, т.к. они все требуют доступа к файлам, а по условию задачи доступа к файлам нет, есть только sql connection через драйвер базы данных. Так же все советы про db link тоже не имеют смысла, т.к. требуют покупки и установки Оракла на компьютер, который будет делать бэкап (это невозможно хотя бы по двум причинам: лицензия на Оракл стоит намного больше нашей бесплатной софтинки для бэкапа, помочь в реализации которой и должны были ответы на этот вопрос, плюс установка Оракла на неподдерживаемую операционную систему (никто же не будет покупать RHEL ради бэкапа, ведь правда?) — это такой гемор, который не каждому под силу, в ближайшее время буду писать подробный гид по установке Оракла на ArchLInux x86_64)/ Короче. Способа осуществить желаемое в топике средствами Оракла я не нашел. Что могу посоветовать гуглящим: использование стандартного JDBC с ограничением на FetchSize будет использовать довольно быструю реализацию работы с курсорами, которая на три порядка быстрее стандартного виндовинга через rownum от Тома Кайта (при размере таблицы в пятнадцать миллионов записей, чем дальше — тем медленней), а инсерты пачками (более одного row в списке insert values) — на пару порядков быстрее индивидуальных инсертов (на том же размере базы и коммуникации через виртуальную сетевую карту — дело происходило внутри VMWare).