Comments 16
Отлично!
Вопросы:
1) Сколько места занимает промежуточная база CDC? Она очищается по мере перезаливки данных в Оракл?
2) Схема в Oracle доступна всем только на чтение?
3) Какая средняя/максимальная между коммитом транзакции в Бисквите, и появлением изменений в Оракле?
4) Планируете научиться делать перезаливку напрямую в Оракл без промеждуточной таблицы?
5) Oracle partitioning использовать не планируете? Индексы по огромным таблицам signs, code в Оракле работают быстро?
Вопросы:
1) Сколько места занимает промежуточная база CDC? Она очищается по мере перезаливки данных в Оракл?
2) Схема в Oracle доступна всем только на чтение?
3) Какая средняя/максимальная между коммитом транзакции в Бисквите, и появлением изменений в Оракле?
4) Планируете научиться делать перезаливку напрямую в Оракл без промеждуточной таблицы?
5) Oracle partitioning использовать не планируете? Индексы по огромным таблицам signs, code в Оракле работают быстро?
Ответы:
1) В среднем объем промежуточной бд CDC порядка 5Gb. Да, данные в ней чистятся, как только они попадут в Оракловую базу.
Но как известно, физически объем экстентов меньше не станет.
2) Нет, есть пользователи с правами на запись.
3) Не замеряли. Интервал сна в процессах репликации можно регулировать от 1 секунды и более.
4) Первичная заливка делается напрямую, без промежуточной бд CDC.
5) В данном решении не используется, данных не так много.
1) В среднем объем промежуточной бд CDC порядка 5Gb. Да, данные в ней чистятся, как только они попадут в Оракловую базу.
Но как известно, физически объем экстентов меньше не станет.
2) Нет, есть пользователи с правами на запись.
3) Не замеряли. Интервал сна в процессах репликации можно регулировать от 1 секунды и более.
4) Первичная заливка делается напрямую, без промежуточной бд CDC.
5) В данном решении не используется, данных не так много.
Делаете ли бекап базы Oracle?
Сложно ли будет после восстановления из бекапа «докатить» изменения?
Сложно ли будет после восстановления из бекапа «докатить» изменения?
Админил сервера бд для одной ИС на прогресс 10, тоже в банке, показалось страшным legacy из 90-х, плюс инструменты администрирования — сплошные костыли из скриптов на баше в 3 слоя. В остальном мире никто про такую базу и не слышал. Удивлен что кто-то ей пользуется добровольно, не планируя переезд.
Добровольно пользуются некоторые, т.к. переезд на другую современную АБС стоит приличных денег, и в поддержании будет дороже…
В остальном мире никто про такую базу и не слышал.
Ну неправда же. База конечно далеко не самая распространенная, но заграницей вполне себе известная.
В России в основном представлена в банковском секторе (БИСКВИТ), есть ряд торговых решений, мне известно о продукте медицинской направленности, ряд ERP-систем, используется вроде бы PepsiCo, концерном PSA (хотя это информация достаточно давняя, давно не слышал упоминаний). Хэдлайнер конечно думаю ВТБ )))
Не могу сказать что администрирование OE доставляет какую-то невероятную, несравнимую с другими БД боль. Мне кажется это дело привычки больше. К чему привык то и кажется более удобным. Хотя если нужен исключительно GUI для администрирования, то OE пока что по крайней точно не ваш выбор. Однако и в этом направлении делаются определенные шаги, с каждой версией OE Managment позволяет с помощью веб-интерфейса делать все больше и больше.
Я не столько имел ввиду Россию или зарубеж, сколько наслышанность о существовании этой СУБД в IT тусовке — никто еще ни разу из знакомых и коллег не говорил что слышал о ней, пользовался и знает что это такое. Каждый такой разговор я начинал с «звучит похоже на postgres, только progress». И ссылку обязательно на сайт как прув, иначе не верят.
Администрю как раз и v10 — никаких костылей на баше не заметил.
Повезло. Мне ИС досталась реализованная таким образом, что буквально всё, от авторизации и меню подключения пользователей к системе в режиме мульти-юзер до меню администрирования (с пунктами переключения after-image файлов, сохранения дампа, установки миграции) — было реализовано набором из нескольких десятков баш скриптов и файлов переменных. Одни скрипты рисовали cli меню, другие подключались при выборе пунктов, третьи реализовывали отдельные функции. Чтобы получить из этого мессива настоящее значение какого-либо параметра — приходилось собирать промежуточные значения через 3-5 слоев. А в конце это всё собиралось в команды для бинарников progress с установленными флагами и путями.
что происходит с репликацией когда схема на источнике меняется?
Хороший вопрос. Думаю, что нужно сначала остановить процессы репликации, внести необходимые изменения в схеме источника, затем в оракл, обновить репликационную схему, запустить репликационные процессы.
Но, возможно не под все случаи этот вариант подойдет.
Но, возможно не под все случаи этот вариант подойдет.
В зависимости от того, что меняется. Если в реплицируемую таблицу будет добавлено новое поле, то репликация будет продолжаться без проблем, но и без нового поля пока не будет обновлена репликационная карта.
Добавление новых полей и таблиц не заставляет переделывать схему Оралка и Schema Holder. а вот удаление полей или таблиц — надо переделывать так как репликация останавливается когда не находит нужного поля или нужной
таблицы. У меня стоит pro2sql, но это то же самое что и pro2ora
У меня вопрос к автору: сколько данных перекачиваетсся из Прогресса в Оракл с помошю этого метода? Ведь вы тут пишите о колоссальный раметах. Сотни Террабайтах в год. Это здорово. Но хотелось бы понять реально сколько переходит через CDC в Оракл?
таблицы. У меня стоит pro2sql, но это то же самое что и pro2ora
У меня вопрос к автору: сколько данных перекачиваетсся из Прогресса в Оракл с помошю этого метода? Ведь вы тут пишите о колоссальный раметах. Сотни Террабайтах в год. Это здорово. Но хотелось бы понять реально сколько переходит через CDC в Оракл?
Sign up to leave a comment.
Как подружить Progress OpenEdge и СУБД Oracle