[Oracle, IT-инфраструктура, Администрирование баз данных] Межплатформенная миграция Oracle Database
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В последние годы межплатформенная миграция Oracle Database перестала быть уникальной задачей. Компании, как правило, переезжают с рисковых платформ на x86, хотя бывает и наоборот. В этом посте поделимся нашим опытом межплатформенных миграций и подробнее остановимся на описании относительно нового способа физической миграции — расширении TTS.
Первый вопрос — Endian-формат
При межплатформенной миграции базы данных Oracle «переезжают» с одной платформы на другую. Платформы имеют разный порядок байт в файлах, который называется Endian-формат. У рисковых платформ этот формат — Big, у x86 — Little. Здесь приведены данные по различным платформам согласно Metalink-ноте 733205.1 (см. support.oracle.com).
PLATFORM_NAME
ENDIAN_FORMAT
Oracle Solaris on SPARC (32-bit & 64-bit)
Big
AIX-Based Systems (64-bit)
Big
HP-UX (64-bit)
Big
HP-UX IA (64-bit)
Big
IBM zSeries Based Linux
Big
Apple Mac OS
Big
IBM Power Based Linux
Big
HP Tru64 UNIX
Little
Linux IA (32-bit & 64-bit)
Little
HP Open VMS
Little
Microsoft Windows IA (32-bit & 64-bit)
Little
Oracle Solaris on x86 & x86-64
Little
Linux 64-bit for AMD
Little
Microsoft Windows 64-bit for AMD
Little
В последних версиях Oracle Database задача миграции между платформами с одинаковым Endian-форматом стала заметно проще. Как правило, работа Oracle Data Guard (Physical Standby) между такими платформами сертифицирована. Миграция через Standby хорошо документирована, требует минимального простоя базы данных и имеет прозрачную процедуру отката (обратный Switchover), если что-то пошло не так. Обычно такую миграцию компании выполняют самостоятельно.
Второй вопрос — сайзинг
Миграция Oracle Database между платформами с разным Endian-форматом значительно сложнее и связана со многими дополнительными аспектами. Например, в сообществе широко обсуждаются вопросы сайзинга. Несколько лет назад мы провели масштабное исследование производительности Oracle Database на самых распространенных рисковых платформах Power/AIX и Sparc/Solaris в сравнении с платформой x86.
Для тестирования мы выбрали нагружающие скрипты Silly Little Oracle Benchmark (SLOB), разработанные Кевином Клоссоном. В отличие от большинства генераторов синтетической нагрузки с «вшитыми» запросами, эти скрипты в несколько потоков запускают собственные запросы к базе данных. Запросы мы разработали так, чтобы избежать влияния дисковой подсистемы (все данные были в прогретом кеше) и конкуренции за внутренние ресурсы экземпляра Oracle (у каждого потока свои данные). Мы измеряли число логических чтений в секунду при растущем объеме параллельных неконкурирующих потоков SLOB. В исследовании участвовали 16-ядерные домены рисковых серверов с актуальными на момент исследования процессорами Power8 и Sparc M7 в сравнении с 16-ядерным x86 сервером Intel. На рисунке показан характерный результат, полученный при сравнении платформ (ось X — потоки SLOB, ось Y — логические чтения в секунду).
На невысоких нагрузках лучшую производительность показывает x86 сервер, в том числе за счет аппаратных возможностей процессора Intel. При росте количества сессий SLOB (после 32) происходит перелом и рисковые серверы выходят вперед — начинает работать многопоточность (в ядре процессора Intel два треда, в ядре процессоров Power8 и Sparc M7 до восьми тредов). Следует заметить, что запросы к Oracle были разработаны таким образом, чтобы утилизировать все треды — в реальных системах это бывает далеко не всегда. Именно многопоточность объясняет окончательную «победу» сервера Sparc. В процессоре Power8 режим SMT=8 (восемь тредов на ядро) работал настолько своеобразно, что даже сам вендор рекомендовал использовать режим SMT=4 (четыре треда на ядро).
Результаты сравнительного исследования оказались неоднозначными. Для себя мы сделали вывод, что получить точный сайзинг можно, только тестируя работу конкретной базы данных на новой платформе. Но для этого базу нужно мигрировать. Поэтому часто требуется предварительный сайзинг, для которого мы используем принцип «ядро в ядро», несмотря на разнообразие сравнительных синтетических тестов типа SpecInt. Этот принцип серьезно усложняет обоснование, почему нужно мигрировать на Power/AIX. Нередко приходится искать дополнительные аргументы со стороны заказчика, а то и с помощью вендора. Дело в том, что оракловый коэффициент многоядерности (Core Factor) для процессоров IBM вдвое выше. И при одинаковом количестве ядер лицензирование Oracle получается вдвое дороже:
Vendor and Processor
Core Factor
Intel Xeon Platinum 92XX, Intel Xeon Platinum 82XX, Intel Xeon Platinum 81XX, Intel Xeon Gold 62XX, Intel Xeon Gold 61XX, Intel Xeon Gold 52XX, Intel Xeon Gold 51XX, Intel Xeon Silver 42XX, Intel Xeon Silver 41XX, Intel Xeon Bronze 32XX, Intel Xeon Bronze 31XX, Intel Xeon Series 56XX, Series 65XX, Series 75XX, Series E7-28XX, E7-28XX v2, Series E7-48XX, E7-48XX v2, E7-48XX v3, E7-48XX v4, Series E7-88XX, E7-88XX v2, E7-88XX v3, E7-88XX v4, Series E5-24XX, E5-24XX v2, E5-24XX v3, Series E5-26XX, E5-26XX v2, E5-26XX v3, E5–26XX v4, Series E5-46XX, E5-46XX v2, E5-46XX v3, E5-46XX v4, E3-15XX v5, E3-15XX v6, Series E3-12XX, E3-12XX v2, E3-12XX v3, E3-12XX v4, E3–12XX v5, E3-12XX v6, E5-14XX v3, E5-14XX v2, E5-16XX v4, E5-16XX v3, E5-16XX v2, and E5-16XX or earlier Multicore chips
0.5
SPARC M5, SPARC M6, SPARC M7, SPARC M8
0.5
IBM POWER6, IBM POWER7, IBM POWER7+
1.0
IBM POWER8, POWER9
1.0
Третий вопрос — окно простоя
Вернемся к теме миграции. Есть три принципиально разных подхода к переносу Oracle Database между платформами:
- Логическая миграция. Классический Export/Import, Data Pump, SQL-команды через Database Link. При этом способе между платформами переносятся не файлы данных, а сами данные. Этот вариант проверен временем и относительно несложный. Он имеет всего одно ограничение: время простоя базы данных получается очень большим.
- Физическая миграция — Transportable Tablespace или TTS. При физической миграции между платформами переносятся файлы с данными, что значительно быстрее. Созданные на одной платформе файлы подключаются к базе данных на другой, поэтому необходимо тщательное тестирование, в том числе на предмет внутренних ошибок Oracle. TTS имеет сравнительно небольшое количество ограничений, а способы их обхода хорошо документированы.
- Репликация. Как правило, используется Oracle Golden Gate, хотя это не единственное решение. В основе любой репликации лежит разбор транзакционных журналов на базе-источнике с последующим применением (возможно с трансформацией) на базе-приемнике. Несмотря на развитые средства верификации данных (Oracle вместе с Golden Gate предлагает специальное ПО Veridata), остается серьезный риск потерять данные и не заметить это. Получается, что за целостность перенесенных данных в случаях логической и физической миграции отвечает Oracle, а в случае репликации — исполнитель.
Прошли времена, когда базы данных размером 1 Тб считались большими. Современные БД намного внушительнее, а ограничения на технологические окна со стороны бизнеса стали жестче. Логическая миграция при всей своей надежности оказывается слишком медленной. Миграцию через репликацию приходится долго и скрупулезно тестировать, чтобы в итоге не получить несогласованные данные. Таким образом, физическая миграция (TTS) чаще оказывается оптимальным способом переноса Oracle Database между платформами.
Миграция с помощью TTS создавалась, чтобы быстро переносить оракловые файлы в рамках одной платформы. Уже потом она была расширена функционалом конвертации из одного Endian-формата в другой (технология RMAN Convert). Такая миграция состоит из трех этапов:
- выгрузка метаданных из словаря старой базы;
- перенос файлов данных с конвертацией RMAN;
- загрузка метаданных в словарь новой базы.
Для большинства баз данных этап конвертации является самым долгим и лимитирует общее время миграции — время выгрузки и загрузки метаданных обычно не превышает получаса, а средняя скорость конвертации составляет примерно 1 Тб в час. Однако мы неоднократно сталкивались с исключениями из этого правила. Например, когда в базе данных из-за большого числа объектов словаря (например, в случае комплексного секционирования) выгрузка метаданных по длительности оказалась сопоставима с конвертацией.
Это важно по следующей причине. Начиная с 12 версии RMAN (сама БД при этом быть версии 11) появилась возможность переносить и конвертировать не файлы с данными (что требует недоступности базы на все время переноса), а файлы бекапа (Backup Set). Это позволяет сделать полный бекап и восстановить его на новой платформе без остановки базы данных, а в технологическое окно перенести инкрементальный бэкап — «сконвертировать дельту». Такой способ намного быстрее переноса целой базы. Более того, можно повторить перенос инкрементального бэкапа несколько раз, пока «конвертация дельты» не начнет умещаться в заданное бизнесом технологическое окно.
Такой относительно новый функционал RMAN получил несколько названий, самое точное из которых, на наш взгляд — Cross-Platform Backup/Restore. С его помощью можно сократить время простоя, необходимое для конвертации: особенно если конвертируемые файлы Backup Set расположить на специальной файловой системе Veritas, допускающей переключение между платформами. При этом время выгрузки и загрузки метаданных данный способ не уменьшает!
Новая старая миграция
Новый способ миграции по сути является расширением TTS и на сегодня недостаточно документирован. Чтобы изучить его, необходимо читать синтаксис конкретных команд RMAN. Поэтому поделимся общей процедурой Cross-Platform Backup-Restore, реализованной нами в нескольких конкретных проектах миграции с рисковых платформ на x86.
Ниже приведены основные шаги этой процедуры. При создании скриптов миграции конкретных баз мы активно использовали генерацию текстов команд из SQL *Plus во всех случаях, когда необходимо перечисление файлов данных либо табличных пространств.
- Проверки перед миграцией. Проверки для классического TTS изложены в Metalink-ноте 371556.1 и для Cross-Platform Backup/Restore они в целом такие же. Особое внимание следует обратить на пользовательские объекты в табличном пространстве SYSTEM, которое при TTS не переносится и на режим Block Change Tracking.
- Создание базы данных на целевой платформе с правильной кодировкой и Timezone.
- Выполнение на исходной базе полного бекапа (level0) с помощью RMAN-команд Backup Incremental Level 0 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
- Перенос пользователей с исходной базы в целевую базу: временное создание табличных пространств, перенос пользователей утилитами expdp/impdp, удаление табличных пространств (таким образом удается перенести пользователей до того, как табличные пространства будут перенесены TTS).
- Генерация на исходной базе скрипта по раздаче привилегий пользователей.
- Восстановление целевой базы из перенесенного полного бекапа (level0) с помощью RMAN-команд Restore From Platform ‘название_исходной_платформы’ All Foreign Datafiles Format ‘формат_backup_set’ From Backupset ‘имя_backup_set’. Название исходной платформы следует писать строго как в таблице Endian-форматов (см. начало статьи) — например, для Power/AIX это AIX-Based Systems (64-bit).
- Выполнение на исходной базе инкрементального бекапа (level1) с помощью RMAN-команд Backup Incremental Level 1 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
- Применение на целевой базе перенесенного инкрементального бекапа level1 c помощью RMAN-команд Recover From Platform ‘название_исходной_платформы’ Foreign Datafilecopy ‘формат_backup_set’ From Backupset ‘имя_backup_set’. Шаги 1-8 можно делать вне технологического окна. Далее перечислены шаги процедуры миграции, требующие простоя.
- Перевод табличных пространств исходной базы данных в режим READ ONLY с помощью SQL-команд Alter Tablespace имя Read Only.
- Выполнение на исходной базе инкрементального бекапа (level1) с помощью RMAN-команд Backup Incremental Level 1 Datafile ‘номер_файла’ Format ‘формат_backup_set’.
- Параллельно п. 10 выгрузка из исходной базы метаданных пользователей утилитой expdp. Мы используем параметры «content=metadata_only exclude=user,role,role_grant,profile»).
- Параллельно п. 10 выгрузка из исходной базы метаданных табличных пространств утилитой expdp. Мы обычно используем параметры «exclude=table_statistics,index_statistics transport_full_check=no transport_tablespaces=список_табличных_пространств» т. к. выгрузка статистики оптимизатора часто оказывается долгой, особенно в базах данных 12 версии. В этом случае статистику нужно либо перенести пакетом DBMS_STATISTICS, либо частично собрать на целевой базе.
- Применение на целевой базе перенесенного инкрементального бекапа level1 (это второй инкрементальный бекап, выполненный в окно простоя) c помощью RMAN-команд Recover From Platform ‘название_исходной_платформы’ Foreign Datafilecopy ‘формат_backup_set’ From Backupset ‘имя_backup_set’.
- Загрузка в целевую базу метаданных табличных пространств, метаданных пользователей утилитой (оба действия — утилита impdp) и раздача пользователям привилегий (созданный в п. 5 скрипт).
- Перевод табличных пространств целевой базы данных в режим READ WRITE с помощью SQL-команд Alter Tablespace имя Read Write.
- Проверка INVALID объектов целевой базы данных и при необходимости их компиляция. Это последний шаг описанной процедуры. На этом межплатформенная физическая миграция с помощью Cross-Platform Backup/Restore завершена!
За последние полгода мы несколько раз прибегали к описанной выше процедуре миграции. Переносили базу данных системы лояльности (версия 12, размер порядка 5 Тб) с платформы Power/AIX на платформу x86/Linux в крупном банке. В ходе нескольких тестовых миграций мы зафиксировали следующие тайминги — 1,5 часа при «ручном» переносе статистики оптимизатора и 3,5 часа при ее переносе в рамках TTS (см. п. 12 процедуры миграции). Бизнес согласовал технологическое окно длительностью 6 часов. Поэтому банк при продуктивной миграции предпочел использовать более долгую, но более простую и надежную процедуру. Вместе с заказчиком она и была реализована.
Автор: Алексей Струченко, руководитель направления СУБД «Инфосистемы Джет»
===========
Источник:
habr.com
===========
Похожие новости:
- [SQL, Microsoft SQL Server, Администрирование баз данных] Шифрование в MySQL: использование Master Key
- [Системное администрирование, IT-инфраструктура, SAN] Мониторинг СХД IBM Storwize при помощи Zabbix
- [IT-инфраструктура, Сетевые технологии, Беспроводные технологии, IT-компании] Private PSK (Pre-Shared Key) – особенности и возможности платформы ExtremeCloud IQ
- [IT-инфраструктура, Законодательство в IT, IT-компании, Удалённая работа] Ассоциация участников отрасли ЦОД предупреждает о проблемах и сбоях при переводе на удаленную работу 30% инженеров
- [IT-инфраструктура, Виртуализация, Конференции, IT-компании] VMworld 2020: щеночки, «кубики» и Рене Зеллвегер
- [IT-инфраструктура, Бизнес-модели, Финансы в IT] Яндекс не будет покупать «Тинькофф банк». Переговоры остановили
- [Информационная безопасность] Заменит ли автоматизация пентестеров?
- [Администрирование баз данных, SQL, PostgreSQL, MySQL] Восемь интересных возможностей PostgreSQL, о которых вы, возможно, не знали (перевод)
- [Алгоритмы, Машинное обучение] Компьютерное зрение. Свой алгоритм или решение из «коробки»?
- [IT-инфраструктура, Сетевые технологии, Asterisk, Сетевое оборудование] Микро DECT гарнитура Snom A150 — обзор
Теги для поиска: #_oracle, #_itinfrastruktura (IT-инфраструктура), #_administrirovanie_baz_dannyh (Администрирование баз данных), #_oracle, #_blog_kompanii_infosistemy_dzhet (
Блог компании Инфосистемы Джет
), #_oracle, #_itinfrastruktura (
IT-инфраструктура
), #_administrirovanie_baz_dannyh (
Администрирование баз данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:50
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 В последние годы межплатформенная миграция Oracle Database перестала быть уникальной задачей. Компании, как правило, переезжают с рисковых платформ на x86, хотя бывает и наоборот. В этом посте поделимся нашим опытом межплатформенных миграций и подробнее остановимся на описании относительно нового способа физической миграции — расширении TTS. Первый вопрос — Endian-формат При межплатформенной миграции базы данных Oracle «переезжают» с одной платформы на другую. Платформы имеют разный порядок байт в файлах, который называется Endian-формат. У рисковых платформ этот формат — Big, у x86 — Little. Здесь приведены данные по различным платформам согласно Metalink-ноте 733205.1 (см. support.oracle.com). PLATFORM_NAME ENDIAN_FORMAT Oracle Solaris on SPARC (32-bit & 64-bit) Big AIX-Based Systems (64-bit) Big HP-UX (64-bit) Big HP-UX IA (64-bit) Big IBM zSeries Based Linux Big Apple Mac OS Big IBM Power Based Linux Big HP Tru64 UNIX Little Linux IA (32-bit & 64-bit) Little HP Open VMS Little Microsoft Windows IA (32-bit & 64-bit) Little Oracle Solaris on x86 & x86-64 Little Linux 64-bit for AMD Little Microsoft Windows 64-bit for AMD Little В последних версиях Oracle Database задача миграции между платформами с одинаковым Endian-форматом стала заметно проще. Как правило, работа Oracle Data Guard (Physical Standby) между такими платформами сертифицирована. Миграция через Standby хорошо документирована, требует минимального простоя базы данных и имеет прозрачную процедуру отката (обратный Switchover), если что-то пошло не так. Обычно такую миграцию компании выполняют самостоятельно. Второй вопрос — сайзинг Миграция Oracle Database между платформами с разным Endian-форматом значительно сложнее и связана со многими дополнительными аспектами. Например, в сообществе широко обсуждаются вопросы сайзинга. Несколько лет назад мы провели масштабное исследование производительности Oracle Database на самых распространенных рисковых платформах Power/AIX и Sparc/Solaris в сравнении с платформой x86. Для тестирования мы выбрали нагружающие скрипты Silly Little Oracle Benchmark (SLOB), разработанные Кевином Клоссоном. В отличие от большинства генераторов синтетической нагрузки с «вшитыми» запросами, эти скрипты в несколько потоков запускают собственные запросы к базе данных. Запросы мы разработали так, чтобы избежать влияния дисковой подсистемы (все данные были в прогретом кеше) и конкуренции за внутренние ресурсы экземпляра Oracle (у каждого потока свои данные). Мы измеряли число логических чтений в секунду при растущем объеме параллельных неконкурирующих потоков SLOB. В исследовании участвовали 16-ядерные домены рисковых серверов с актуальными на момент исследования процессорами Power8 и Sparc M7 в сравнении с 16-ядерным x86 сервером Intel. На рисунке показан характерный результат, полученный при сравнении платформ (ось X — потоки SLOB, ось Y — логические чтения в секунду).  На невысоких нагрузках лучшую производительность показывает x86 сервер, в том числе за счет аппаратных возможностей процессора Intel. При росте количества сессий SLOB (после 32) происходит перелом и рисковые серверы выходят вперед — начинает работать многопоточность (в ядре процессора Intel два треда, в ядре процессоров Power8 и Sparc M7 до восьми тредов). Следует заметить, что запросы к Oracle были разработаны таким образом, чтобы утилизировать все треды — в реальных системах это бывает далеко не всегда. Именно многопоточность объясняет окончательную «победу» сервера Sparc. В процессоре Power8 режим SMT=8 (восемь тредов на ядро) работал настолько своеобразно, что даже сам вендор рекомендовал использовать режим SMT=4 (четыре треда на ядро). Результаты сравнительного исследования оказались неоднозначными. Для себя мы сделали вывод, что получить точный сайзинг можно, только тестируя работу конкретной базы данных на новой платформе. Но для этого базу нужно мигрировать. Поэтому часто требуется предварительный сайзинг, для которого мы используем принцип «ядро в ядро», несмотря на разнообразие сравнительных синтетических тестов типа SpecInt. Этот принцип серьезно усложняет обоснование, почему нужно мигрировать на Power/AIX. Нередко приходится искать дополнительные аргументы со стороны заказчика, а то и с помощью вендора. Дело в том, что оракловый коэффициент многоядерности (Core Factor) для процессоров IBM вдвое выше. И при одинаковом количестве ядер лицензирование Oracle получается вдвое дороже: Vendor and Processor Core Factor Intel Xeon Platinum 92XX, Intel Xeon Platinum 82XX, Intel Xeon Platinum 81XX, Intel Xeon Gold 62XX, Intel Xeon Gold 61XX, Intel Xeon Gold 52XX, Intel Xeon Gold 51XX, Intel Xeon Silver 42XX, Intel Xeon Silver 41XX, Intel Xeon Bronze 32XX, Intel Xeon Bronze 31XX, Intel Xeon Series 56XX, Series 65XX, Series 75XX, Series E7-28XX, E7-28XX v2, Series E7-48XX, E7-48XX v2, E7-48XX v3, E7-48XX v4, Series E7-88XX, E7-88XX v2, E7-88XX v3, E7-88XX v4, Series E5-24XX, E5-24XX v2, E5-24XX v3, Series E5-26XX, E5-26XX v2, E5-26XX v3, E5–26XX v4, Series E5-46XX, E5-46XX v2, E5-46XX v3, E5-46XX v4, E3-15XX v5, E3-15XX v6, Series E3-12XX, E3-12XX v2, E3-12XX v3, E3-12XX v4, E3–12XX v5, E3-12XX v6, E5-14XX v3, E5-14XX v2, E5-16XX v4, E5-16XX v3, E5-16XX v2, and E5-16XX or earlier Multicore chips 0.5 SPARC M5, SPARC M6, SPARC M7, SPARC M8 0.5 IBM POWER6, IBM POWER7, IBM POWER7+ 1.0 IBM POWER8, POWER9 1.0 Третий вопрос — окно простоя Вернемся к теме миграции. Есть три принципиально разных подхода к переносу Oracle Database между платформами:
Прошли времена, когда базы данных размером 1 Тб считались большими. Современные БД намного внушительнее, а ограничения на технологические окна со стороны бизнеса стали жестче. Логическая миграция при всей своей надежности оказывается слишком медленной. Миграцию через репликацию приходится долго и скрупулезно тестировать, чтобы в итоге не получить несогласованные данные. Таким образом, физическая миграция (TTS) чаще оказывается оптимальным способом переноса Oracle Database между платформами. Миграция с помощью TTS создавалась, чтобы быстро переносить оракловые файлы в рамках одной платформы. Уже потом она была расширена функционалом конвертации из одного Endian-формата в другой (технология RMAN Convert). Такая миграция состоит из трех этапов:
Для большинства баз данных этап конвертации является самым долгим и лимитирует общее время миграции — время выгрузки и загрузки метаданных обычно не превышает получаса, а средняя скорость конвертации составляет примерно 1 Тб в час. Однако мы неоднократно сталкивались с исключениями из этого правила. Например, когда в базе данных из-за большого числа объектов словаря (например, в случае комплексного секционирования) выгрузка метаданных по длительности оказалась сопоставима с конвертацией. Это важно по следующей причине. Начиная с 12 версии RMAN (сама БД при этом быть версии 11) появилась возможность переносить и конвертировать не файлы с данными (что требует недоступности базы на все время переноса), а файлы бекапа (Backup Set). Это позволяет сделать полный бекап и восстановить его на новой платформе без остановки базы данных, а в технологическое окно перенести инкрементальный бэкап — «сконвертировать дельту». Такой способ намного быстрее переноса целой базы. Более того, можно повторить перенос инкрементального бэкапа несколько раз, пока «конвертация дельты» не начнет умещаться в заданное бизнесом технологическое окно. Такой относительно новый функционал RMAN получил несколько названий, самое точное из которых, на наш взгляд — Cross-Platform Backup/Restore. С его помощью можно сократить время простоя, необходимое для конвертации: особенно если конвертируемые файлы Backup Set расположить на специальной файловой системе Veritas, допускающей переключение между платформами. При этом время выгрузки и загрузки метаданных данный способ не уменьшает! Новая старая миграция Новый способ миграции по сути является расширением TTS и на сегодня недостаточно документирован. Чтобы изучить его, необходимо читать синтаксис конкретных команд RMAN. Поэтому поделимся общей процедурой Cross-Platform Backup-Restore, реализованной нами в нескольких конкретных проектах миграции с рисковых платформ на x86. Ниже приведены основные шаги этой процедуры. При создании скриптов миграции конкретных баз мы активно использовали генерацию текстов команд из SQL *Plus во всех случаях, когда необходимо перечисление файлов данных либо табличных пространств.
За последние полгода мы несколько раз прибегали к описанной выше процедуре миграции. Переносили базу данных системы лояльности (версия 12, размер порядка 5 Тб) с платформы Power/AIX на платформу x86/Linux в крупном банке. В ходе нескольких тестовых миграций мы зафиксировали следующие тайминги — 1,5 часа при «ручном» переносе статистики оптимизатора и 3,5 часа при ее переносе в рамках TTS (см. п. 12 процедуры миграции). Бизнес согласовал технологическое окно длительностью 6 часов. Поэтому банк при продуктивной миграции предпочел использовать более долгую, но более простую и надежную процедуру. Вместе с заказчиком она и была реализована. Автор: Алексей Струченко, руководитель направления СУБД «Инфосистемы Джет» =========== Источник: habr.com =========== Похожие новости:
Блог компании Инфосистемы Джет ), #_oracle, #_itinfrastruktura ( IT-инфраструктура ), #_administrirovanie_baz_dannyh ( Администрирование баз данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 18:50
Часовой пояс: UTC + 5