Технология FTEX для этой задачи не подойдет, поскольку при ее использовании переносится вся БД целиком с всеми схемами. Я бы разделил Вашу задачу на два этапа:
Миграция всей БД с RISC на Linux 86
Разделение базы на несколько с помощью, например, технологии Oracle Datapump Export/Import.
Статья была написана 4 года назад. За это время технология межплатформенной миграции СУБД Oracle шагнула далеко вперед. Я имею в виду Full Transportable Export Import с скриптами M5.
Об этом речь пойдет в второй части статьи. - В ней подробно будет описана эта технология.
Статья была написана 4 года назад. За это время технология межплатформенной миграции СУБД Oracle шагнула далеко вперед. Я имею в виду Full Transportable Export Import с скриптами M5.
Об этом речь пойдет в второй части статьи. - В ней подробно будет описана эта технология.
По моему опыту, в абсолютном большинстве случаев, для миграции с RISC на x86, применяется именно транспортируемые табличные пространства. - Если важно уменьшить время простоя.
Если время простоя позволяет, то используется Datapump Export/Import.
Да, GoldenGate применяется, но гораздо реже - с ним много заморочек и много ограничений.
Также требуется наличие отдельной лицензии (если заказчик сейчас за этим следит).
Одно неоспоримое преимущество GG - он позволяет обеспечить практически нулевое время простоя при такой миграции.
В статье речь идет о RISC-платформах в контексте миграции БД Oracle на x86. Самые распространенные для Oracle на RISC - это SPARC и IBM Power. Эти платформы имеют формат Big Endian.
Спасибо за замечание!
Я поправил текст: "На большинстве RISC-платформ, прежде всего на самых распространенных, таких как SPARC и IBM Power, байты упорядочены от старшего к младшему (Big Endian), а на Linux x86 — наоборот, от младшего к старшему (Little Endian)."
On-Lgin триггер точно также будет срабатывать, когда соединение впервые открывается в пуле соединений. И в таком триггере Вы можете определить проверки, которые должны быть выполнены в момент создания пула соединений. Поэтому, On-Login триггер вполне востребован и для серверов приложений.
С нетерпением ждем следующую статью про конвертацию кода.
Ума не приложу, что делать с очередями Advanced Queuing, обьектными типами PL/SQL, глобальными контекстами и цепочками джобов (scheduler chains), а также динамическим SQL 4-ого типа (dbms_sql). - Как эти 600 тыс. строк переписать на pg/sql ...
"Многоуровневое локальное секционирование" - Вы имеете в виду Subpartitioning?
Но он поддерживается PG.
Отсутствие поддержки глобальных индексов - это уже другой недостаток PostgreSQL.
Аналог DataGuard есть в PG: это обычный физический стенбай, доступный на чтение.
Вы, видимо, имеете в виду DataGuard Observer и Global Data Services - автоматическую активацию стенбай-БД и переключение на него приложений.
Кстати, последнее можно сделать без GDS - на стороне клиента с помощью Transparent Application Failover (в дескрипторе соединения на клиенте описываются подключения к примари и ее репликам).
Скажите, пожалуйста: а как приостановить работу джоба?
Спасибо.
Поправил!
Я использовал скрипты M5 версии 4.9.
Они рабочие - менять их не пришлось.
Технология FTEX для этой задачи не подойдет, поскольку при ее использовании переносится вся БД целиком с всеми схемами. Я бы разделил Вашу задачу на два этапа:
Миграция всей БД с RISC на Linux 86
Разделение базы на несколько с помощью, например, технологии Oracle Datapump Export/Import.
Да. Я читал эту хорошую статью Алексея Струченко.
Статья была написана 4 года назад. За это время технология межплатформенной миграции СУБД Oracle шагнула далеко вперед. Я имею в виду Full Transportable Export Import с скриптами M5.
Об этом речь пойдет в второй части статьи. - В ней подробно будет описана эта технология.
Да. Я читал эту хорошую статью Алексея Струченко.
Статья была написана 4 года назад. За это время технология межплатформенной миграции СУБД Oracle шагнула далеко вперед. Я имею в виду Full Transportable Export Import с скриптами M5.
Об этом речь пойдет в второй части статьи. - В ней подробно будет описана эта технология.
По моему опыту, в абсолютном большинстве случаев, для миграции с RISC на x86, применяется именно транспортируемые табличные пространства. - Если важно уменьшить время простоя.
Если время простоя позволяет, то используется Datapump Export/Import.
Да, GoldenGate применяется, но гораздо реже - с ним много заморочек и много ограничений.
Также требуется наличие отдельной лицензии (если заказчик сейчас за этим следит).
Одно неоспоримое преимущество GG - он позволяет обеспечить практически нулевое время простоя при такой миграции.
В статье речь идет о RISC-платформах в контексте миграции БД Oracle на x86. Самые распространенные для Oracle на RISC - это SPARC и IBM Power. Эти платформы имеют формат Big Endian.
Спасибо за замечание!
Я поправил текст: "На большинстве RISC-платформ, прежде всего на самых распространенных, таких как SPARC и IBM Power, байты упорядочены от старшего к младшему (Big Endian), а на Linux x86 — наоборот, от младшего к старшему (Little Endian)."
On-Lgin триггер точно также будет срабатывать, когда соединение впервые открывается в пуле соединений. И в таком триггере Вы можете определить проверки, которые должны быть выполнены в момент создания пула соединений. Поэтому, On-Login триггер вполне востребован и для серверов приложений.
Видимо, Вы имеете в виду включение этой функциональности в Open Source дистрибутив PostgreSQL. Таких планов, пока нет.
Спасибо!
Но pg_varibales НЕ позволяет создать константу существующую для нескольких сессий.
Глобальные константы существуют в оракле в SGA - видимы сразу для всех сессий.
Как это реализовать в PG?
Большое спасибо за статью.
Но Вы ничего не сказали, что делать с Oracle Advanced Queuing и Advanced Compression.
Что же делать с объектными типами PL/SQL, если они содержат еще и методы, а не только атрибуты?
Что делать с глобальными контекстами?
И куда засунуть в PG Oracle Flashback Archive?
Спасибо!
С нетерпением ждем следующую статью про конвертацию кода.
Ума не приложу, что делать с очередями Advanced Queuing, обьектными типами PL/SQL, глобальными контекстами и цепочками джобов (scheduler chains), а также динамическим SQL 4-ого типа (dbms_sql). - Как эти 600 тыс. строк переписать на pg/sql ...
Расскажите, пожалуйста! ?
"Многоуровневое локальное секционирование" - Вы имеете в виду Subpartitioning?
Но он поддерживается PG.
Отсутствие поддержки глобальных индексов - это уже другой недостаток PostgreSQL.
Аналог DataGuard есть в PG: это обычный физический стенбай, доступный на чтение.
Вы, видимо, имеете в виду DataGuard Observer и Global Data Services - автоматическую активацию стенбай-БД и переключение на него приложений.
Кстати, последнее можно сделать без GDS - на стороне клиента с помощью Transparent Application Failover (в дескрипторе соединения на клиенте описываются подключения к примари и ее репликам).