Как перенести oracle на другой сервер

Обновлено: 05.07.2024

Из этого руководства вы узнаете, как перенести базы данных Oracle в SQL Server с использованием Помощника по миграции SQL Server для Oracle (SSMA для Oracle).

Предварительные требования

Прежде чем приступить к переносу базы данных Oracle в SQL Server, сделайте следующее:

Убедитесь, что ваша исходная среда поддерживается.
Скачайте и установите SQL Server.
Скачайте и установите SSMA для Oracle.
Получите необходимые разрешения для SSMA для Oracle и поставщик.
Получите возможность подключения и требуемые разрешения для доступа к исходному и целевому объектам.

Подготовка к миграции

При подготовке к миграции в облако убедитесь в том, что исходная среда поддерживается и все остальные предварительные требования выполнены. Так вам будет проще успешно и эффективно выполнить миграцию.

Этот этап процесса включает в себя инвентаризацию баз данных для переноса, проверку этих баз данных на отсутствие проблем или препятствий для миграции и устранение возможных проблем.

Обнаружить

Чтобы лучше понять процесс миграции и подготовиться к нему, используйте набор средств Microsoft Assessment and Planning Toolkit (MAP), который поможет выявить существующие источники данных и получить сведения о функциях, используемых вашей организацией. Этот процесс включает в себя сканирование сети для обнаружения всех экземпляров, версий и компонентов Oracle в организации.

Для проведения инвентаризации с помощью набора средств MAP сделайте следующее:

На панели Overview (Обзор) выберите Create/Select database (Создание или выбор базы данных).

В разделе Create or select a database (Создание или выбор базы данных) щелкните Create an inventory database (Создать базу данных инвентаризации), введите имя и краткое описание для новой базы данных инвентаризации, а затем нажмите кнопку ОК.

Щелкните Collect inventory data (Сбор данных инвентаризации), чтобы открыть мастер инвентаризации и оценки.

В этом мастере выберите Oracle, а затем щелкните Next (Далее).

Выберите оптимальный вариант для поиска компьютеров с учетом среды и потребностей вашей организации, а затем щелкните Next (Далее).

Введите существующие учетные данные или создайте их для нужных систем, а затем щелкните Next (Далее).

Укажите очередность учетных данных и нажмите кнопку Next.

Укажите учетные данные для каждого компьютера, который требуется обнаружить. Вы можете указать уникальные учетные данные для каждого компьютера или выбрать их из списка Computers (Компьютеры).

Проверьте выбранные настройки и нажмите кнопку Finish (Готово).

После завершения сканирования просмотрите сводный отчет Data Collection (Сбор данных). Это сканирование может занять несколько минут в зависимости от количества баз данных. По завершении нажмите кнопку Close (Закрыть).

Выберите Options (Параметры), чтобы создать отчет об оценке баз данных Oracle. Для создания отчета поочередно выберите оба параметра.

Оценка

Завершив выбор источников данных, с помощью SSMA для Oracle оцените тот экземпляр Oracle, который вы переносите на виртуальную машину SQL Server, чтобы увидеть различия между ними. Используя помощник по миграции, можно изучить объекты баз данных и данные в них, оценить возможности переноса баз данных, перенести объекты баз данных в SQL Server, а затем перенести данные в SQL Server.

Чтобы создать оценку, сделайте следующее:

Выберите File (Файл) и New Project (Создать проект).

Укажите имя и расположение проекта, а затем в раскрывающемся списке выберите целевой объект для миграции в SQL Server. Щелкните ОК.

Щелкните Connect to Oracle (Подключиться к Oracle), введите сведения о подключении к Oracle и нажмите кнопку Connect (Подключиться).

На панели Filter objects (Фильтрация объектов) выберите схемы Oracle, которые вы намерены перенести, и щелкните OK (ОК).

На панели Oracle Metadata Explorer (Обозреватель метаданных Oracle) выберите нужную схему Oracle и щелкните Create Report (Создать отчет), чтобы создать отчет в формате HTML со статистикой преобразований и списком ошибок и предупреждений (при их наличии). Можно также выбрать вкладку Create Report (Создать отчет) в правом верхнем углу.

Ознакомьтесь с отчетом в формате HTML, чтобы получить сведения о статистике преобразований, а также об ошибках или предупреждениях. Также можно открыть отчет в Excel, чтобы получить список объектов Oracle и действий, необходимых для выполнения преобразований схемы. По умолчанию этот отчет находится в папке report в каталоге SSMAProjects. Пример:

Обновление типов данных

Проверьте сопоставления типов данных по умолчанию и измените их в зависимости от требований, если это необходимо. Для этого сделайте следующее:

Щелкните Tools (Средства) и выберите Project Settings (Параметры проекта).

Перейдите на вкладку Type mapping (Сопоставление типов).

Сопоставление типов для каждой таблицы можно изменить, выбрав имя нужной таблицы в области Oracle Metadata explorer (Обозреватель метаданных Oracle).

Преобразовать схему

Чтобы преобразовать схему, сделайте следующее:

(Необязательно.) Чтобы преобразовать динамические или специализированные запросы, щелкните нужный узел правой кнопкой мыши и выберите пункт Add statement (Добавить инструкцию).

Перейдите на вкладку Connect to SQL Server (Подключение к SQL Server), а затем введите сведения о подключении к экземпляру SQL Server.

а. В раскрывающемся списке Database (База данных) выберите целевую базу данных или введите неиспользуемое имя, чтобы создать базу данных на целевом сервере.
b. Предоставьте сведения о проверке подлинности.
c. Выберите Подключиться.

На панели Oracle Metadata Explorer (Обозреватель метаданных Oracle) щелкните правой кнопкой мыши схему, с которой вы работаете, и выберите действие Convert Schema (Преобразовать схему). Также можно выбрать вкладку Convert Schema (Преобразовать схему) в правом верхнем углу.

Когда преобразование завершится, сравните преобразованные объекты с исходными, чтобы выявить возможные проблемы, и устраните их в соответствии с рекомендациями.

Сравните преобразованный текст Transact-SQL с исходным кодом и просмотрите рекомендации.

На панели выходных данных щелкните значок Review results (Проверка результатов), а затем просмотрите ошибки в области Error list (Список ошибок).

В качестве упражнения по исправлению схемы в автономном режиме сохраните проект на локальном устройстве, выбрав File > Save Project (Файл > Сохранить проект). Это позволит вам оценить исходную и целевую схемы в автономном режиме и устранить проблемы перед публикацией схемы в экземпляре SQL Server.

Перенос базы данных

Когда будут выполнены все предварительные условия и завершены задачи, связанные с подготовкой к миграции, вы можете переходить к переносу схемы и базы данных. Перенос состоит из двух этапов: публикация схемы и перенос базы данных.

Чтобы опубликовать схему и перенести базу данных, сделайте следующее:

Опубликуйте схему. В области SQL Server Metadata Explorer (Обозреватель метаданных SQL Server) щелкните базу данных правой кнопкой мыши и выберите Synchronize with Database (Синхронизировать с базой данных). Схема Oracle будет опубликована в экземпляре SQL Server.

Проверьте результаты сопоставления исходного и целевого проектов, как показано ниже:

Перенесите данные. В области Oracle Metadata Explorer (Обозреватель метаданных Oracle) щелкните правой кнопкой мыши схему или объект, которые вы хотите перенести, и выберите Migrate Data (Перенос данных). Также можно выбрать вкладку Migrate Data (Миграция данных) в правом верхнем углу.

Чтобы перенести данные всей базы данных, установите флажок рядом с ее именем. Чтобы перенести данные из отдельных таблиц, разверните базу данных, разверните Таблицы и установите флажок рядом с нужной таблицей. Чтобы не переносить данные из определенной таблицы, снимите флажок.

На панели Migrate Data (Перенос данных) введите сведения о подключении к Oracle и SQL Server.

После завершения миграции изучите отчет о переносе данных.

Подключитесь к экземпляру SQL Server с помощью SQL Server Management Studio и проверьте результаты миграции, просмотрев данные и схему.

Помимо SSMA, для переноса данных можно использовать службы SQL Server Integration Services (SSIS). Дополнительные сведения см. на следующих ресурсах:

После миграции

После успешного завершения этапа миграции необходимо выполнить ряд дополнительных задач, чтобы обеспечить бесперебойную и эффективную работу всех компонентов.

Исправление приложений

После переноса данных в целевую среду все приложения, которые раньше использовали источник, должны переключиться на использование целевого объекта миграции. Для этого в некоторых случаях потребуется внести изменения в приложения.

Data Access Migration Toolkit — это расширение для Visual Studio Code, с помощью которого можно анализировать исходный код Java и отслеживать вызовы и запросы к API доступа к данным. Этот набор средств содержит представление с одной областью для задач, которые нужно решить для поддержки новой серверной части базы данных. Дополнительные сведения см. в записи блога Перенос приложения Java из Oracle.

Выполнение тестов

Тестирование переноса базы данных проводится следующим образом.

Разработка проверочных тестов. Чтобы протестировать перенос базы данных, необходимо использовать SQL-запросы. Следует создать проверочные запросы, которые будут выполняться в исходной и в целевой базах данных. Проверочные запросы должны охватывать всю определенную ранее область.

Настройка тестовой среды. Тестовая среда должна содержать копию исходной и целевой баз данных. Не забудьте изолировать тестовую среду.

Выполнение проверочных тестов. Выполните проверочные тесты в исходной и целевой базах данных, а затем проанализируйте результаты.

Выполнение тестов производительности. Запустите тесты производительности для исходной и целевой баз данных, а затем проанализируйте и сравните результаты.

Оптимизация

Проверка после миграции — очень важный шаг, позволяющий добиться точности и полноты данных и устранить проблемы с производительностью рабочей нагрузки.

Дополнительную информацию об этих проблемах и мерах по их устранению см. в руководстве по проверке и оптимизации после миграции.

Ресурсы, посвященные миграции

Дополнительную помощь по этому сценарию миграции можно получить в приведенных ниже ресурсах. Они разработаны как вспомогательные материалы по реализации реальных проектов миграции.

Эти ресурсы разработали специалисты по разработке данных SQL. Основная задача этой команды — включить и ускорить комплексную модернизацию проектов миграции платформы данных на платформу данных Microsoft Azure.

Дальнейшие действия

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

В этой статье расскажем как клонировать базу данных Oracle используя холодную резервную копию исходной базы данных.
Если у вас есть холодная копия, то можно переходить к шагу 2, в противном случае пойдем по порядку.

Шаг 1

Определяем файлы базы данных и копируем их в нужное место. Для идентификации необходимых файлов базы данных выполните запрос:

SET LINES 100 PAGES 999

COL NAME FORMAT A50

SELECT NAME, BYTES

FROM (SELECT NAME, BYTES FROM V$DATAFILE

SELECT NAME, BYTES FROM V$TEMPFILE

FROM V$LOGFILE LF, V$LOG L

(SELECT SUM (BYTES) AS POO FROM DBA_FREE_SPACE) FREE

Он покажет все файлы данных, временные файлы и журналы повторного выполнения. Кроме того, будет показан размер файлов, чтобы можно было оценить необходимый объем пространства на целевой файловой системе для хранения.

Остановите исходную базу данных, выполнив:

Скопируйте все необходимые файлы на целевую файловую систему. Убедитесь, что все скопированные файлы и директории имеют корректного владельца и набор прав доступа.

Запустите исходную базу данных:

Шаг 2

Создание spfile для новой базы данных. Этот шаг предполагает, что вы используете spfile, если нет, то скопируйте существующий.
Для создания, выполните в sqlplus:

Этой командой вы создадите новый pfile в директории $ORACLE_HOME/dbs.

Только что созданный pfile необходимо отредактировать. Если клонированная база данных имеет новое имя, то его требуется сменить, так же как и некоторые пути. Просмотрите созданный файл и внесите необходимые изменения. Обратите внимание на параметры памяти, например, если вы клонируете промышленную базу на сервер разработки, уступающий по параметрам, то необходимо уменьшит соответствующие параметры, например, объем используемой оперативной памяти.

Шаг 3

На этом шаге создаются управляющие файлы для клонированной базы данных. Для этого подключаемся к исходной базе данных и делаем снимок с текущих управляющих файлов, выполнив в sqlplus:

Теперь, используя текстовый редактор внесите в полученный файл следующие изменения:

Ниже приведен пример, как примерно должен выглядеть полученный файл, база данных не в режиме ARCHIVELOG и называется TEST:

Шаг 4

Добавляем новое вхождение в /etc/oratab (или /opt/oracle/oratab) для новой базы данных. Источник новых переменных окружения . oraenv и проверяем, что все работает, выполнив:

если вывод не показал новое имя базы данных, то ищем причину.

Шаг 5

Создаем новый файл паролей и управляющие файлы. Для создания файла паролей выполните команду:

Для создания управляющих файлов выполните:

@/home/oracle/cr_ новый _SID

На этом этапе легко можно столкнуться с ошибками. Приведу наиболее частые и пути их решения:

ORA-01113: file 1 needs media recovery

Вероятнее всего перед копированием файлов исходная база не была остановлена, или не остановилась полностью к моменту копирования. Вернитесь к шагу 1 и повторите копирование.

Проверьте pfile созданный на втором шаге. Убедитесь, что значение параметра control_files указывает на корректное расположение файлов. Если с control_files все в порядке, то убедитесь, что управляющие файлы не были скопированы вместе с другими файлами базы данных. Если это так, то удалите их или переименуйте.

Шаг 6

Выполним ряд проверок.

Выполните проверку, открыт ло экземпляр базы данных. Для этого выполните:

SELECT STATUS FROM V$INSTANCE;

Статус базы данных должен быть OPEN

Проверяем файлы данных, статусы у всех должны быть ONLINE и SYSTEM:

SELECT DISTINCT STATUS FROM V$DATAFILE;

Просмотрите alert.log на наличие ошибок.

Шаг 7

Устанавливаем глобальное имя базы данных. Поскольку клонированная база данных продолжает содержать имя исходной, выполним:

ALTER DATABASE RENAME GLOBAL_NAME TO новый _SID

Шаг 8

Создадим spfile, выполнив в sqlplus:

CREATE SPFILE FROM PFILE;

Шаг 9

На этом шаге предстоит изменить ID базы данных, который необходим, например, при использовании RMAN. Если же RMAN использовать не планируется, то все равно лучше сменить, это будет наиболее правильно, да и лишний опыт не повредит.
Из sqlplus выполняете:

Из командной строки UNIX выполните:

NID спросит, действительно ли вы хотите изменить ID, ответить – Y (да). После того, как отработает, снова запустите базу, выполнив из sqlplus:

В этом посте моего блога я покажу Вам как можно восстановить базу данных Oracle на другом хосте. В этом случае DBID базы данных будет таким же, как и исходная база данных. Вся сложность заключается в том, что когда вы хотите создать новую копию базы данных, используйте RMAN DUPLICATE . Это изменит DBID новой базы данных.

В этом примере имя моей тестовой базы данных dbase1 и она запущены на машине neptune. Целевая задача состоит в том, чтобы сделать резервную копию на машине neptune и залить эту копию на резервную машину saturn, и далее выполнить процесс восстановление экземпляра базы на машине saturn.

Шаг 1. На машине neptun делаем бэкап базы, выполняя команды в утилите RMAN:

Шаг 2. Передаем созданные две части бэкапа на целевую машину (с сервера neptune на saturn), используем команды оболочки bash на unix-сервере:

Шаг 3.Определяем DBID базы на исходной машине Neptune, обращаясь к представлению v$database :

Шаг 4.Теперь выполняем команды на целевой машине Saturn. Прежде всего установим ORACLE_SID

Шаг 5. Установим DBID и восстановим spfile из файла pfile:

Подсказка! Откройте pfile в редакторе, если хотите поменять расположение файлов базы данных

Шаг 6. Запускаем экземпляр с использованием pfile:

Шаг 7. Восстанавливаем управляющие файлы (controlfile) и монтируем базу:

Шаг 8. С помощью SQL*Plus указываем файлы данных (data file) и имена журналов redo log:

Шаг 9. Каталогизируем бекапы:

Шаг 10. Если вы хотите использовать имена файлов, отличные от исходных, то создаем специальный скрипт с использованием SET NEWNAME :

Шаг 11.Открываем базу данных (переводим в состояние Open) с использование опции resetlogs :

Этапы импорта и экспорта данных базы данных Oracle (начало работы)

Описание:
1. Существует много способов импорта и экспорта данных базы данных, вы можете импортировать и экспортировать с помощью команды exp / imp, или вы можете использовать сторонний инструмент для экспорта, такой как: PLSQL
2. Если вы знакомы с командами, рекомендуется использовать команду exp / imp для импорта и экспорта, чтобы избежать проблем, вызванных различиями версий сторонних инструментов, и в то же время это более эффективно, но обратите особое внимание: обратите внимание на детали пользователя и его разрешения при использовании команды. к
3. Когда целевая база данных импортируется, необходимо создать то же имя пользователя, что и при экспорте (стараться быть согласованным), и предоставить не более низкие права, чем пользователь во время экспорта, и в то же время создать то же имя табличного пространства, что и исходная база данных, если локальная база данных уже существует. Одно и то же табличное пространство может быть только расширено.

1. Подготовка перед импортом (работа в целевой базе данных)

Дополнение знаний:
Табличное пространство
База данных Oracle хранит физические таблицы в табличных пространствах. Экземпляр базы данных может иметь N табличных пространств, а табличное пространство может иметь N таблиц. к
Табличное пространство является логическим разделением баз данных, и каждая база данных имеет по крайней мере одно табличное пространство (так называемое табличное пространство SYSTEM). Чтобы упростить управление и повысить эффективность работы, некоторые дополнительные табличные пространства могут использоваться для разделения пользователей и приложений. Например: табличное пространство USER предназначено для обычных пользователей, а табличное пространство RBS - для сегмента отката. Табличное пространство может принадлежать только одной базе данных.

1. Войдите на сервер

Вы можете использовать инструменты Xshell или secureCRT

2. Проверьте, достаточно ли места на диске

Выполните команду df -h или df -H для запроса. Если свободного места недостаточно, замените целевую среду новой целевой средой и продолжите другие операции.

3. Запрос информации о табличном пространстве

UsingВойдите в систему с помощью терминала и выполните команды в последовательности:
[oracle @ orac

] $ su-oracle (переключиться на пользователя oracle (имя пользователя для linux))

Создайте новую папку в каталоге / home / oracle / app / oradata, которая позже будет использоваться для создания табличного пространства. Путь не является уникальным и зависит от расположения целевой базы данных, где хранятся файлы данных.

OgВойдите в базу данных

Вы можете получить табличное пространство текущей базы данных, как показано ниже:

Вы также можете войти в базу данных с помощью стороннего инструмента для выполнения вышеуказанного оператора SQL (также возможны следующие шаги)
*Заметка: Если имя табличного пространства импортируемой базы данных совпадает с именем текущего существующего табличного пространства, нет необходимости создавать новое табличное пространство (не может быть перестроено), но вы должны убедиться, что размер существующего табличного пространства достаточен, или он был настроен для автоматического увеличения и автоматического увеличения максимума. Если значение достаточно велико, расширять табличное пространство не нужно, просто используйте уровень табличного пространства напрямую, пропустите четвертый шаг. к
Напротив, если нет табличного пространства с именем или табличное пространство недостаточно велико для хранения импортируемых данных, табличное пространство необходимо расширить и выполнить четвертый шаг.

4. Расширение табличного пространства

Есть много способов расширить табличное пространство, кратко представив некоторые из распространенных методов:
① напрямую увеличить размер табличного пространства:
Сначала проверьте расположение файла данных в табличном пространстве

После определения местоположения файла данных выполните команду:
Измените размер файла базы данных «путь к файлу данных», чтобы изменить размер
например:

нота : Этот метод сообщит об ошибке при увеличении табличного пространства с табличными данными, указывая, что увеличение не удалось. Рекомендуется следующий метод
② увеличить количество файлов данных
Изменить имя табличного пространства табличного пространства Добавить файл данных «Путь к добавленному файлу данных» Размер файла данных
например:

③ Установите табличное пространство для автоматического расширения
Изменение файла данных базы данных - табличного пространства, подлежащего расширению, - автоматическое расширение до следующего размера блока расширения. Максимальный максимальный размер расширения.
например:

замечания Методы могут использоваться в комбинации, особенно если вы не уверены в окончательном размере импортируемого файла, например:

После расширения табличного пространства вы можете выполнить sql, чтобы проверить размер табличного пространства на шаге 3., чтобы убедиться, что расширение табличного пространства прошло успешно.

5. Создайте временное табличное пространство и табличное пространство данных

Перед созданием пользователя необходимо сначала создать два табличных пространства: временное табличное пространство и табличное пространство базы данных, в противном случае системное табличное пространство по умолчанию вызовет другие проблемы. к
TemporaryСоздать временное табличное пространство
Создайте временное имя табличного пространства временного табличного пространства временный файл - расположение временного табличного пространства - размер размера временного табличного пространства автоматически расширяется на следующие 100 м maxsize 10240 м локальное управление экстентом;
например:

TableСоздать табличное пространство данных
Параметры примерно такие же, как при создании временного табличного пространства
например:

нота : Если вы выполняете шаг 4., то есть табличное пространство расширяется вместо нового, вам не нужно создавать табличное пространство данных (но также необходимо создать временное табличное пространство - личное мнение)

6. Создайте пользователя базы данных и укажите табличное пространство

Этот пользователь используется для управления данными, которые будут импортированы. При импорте он также переключится на этого пользователя для операции импорта (если вы используете команду imp для импорта, лучше всего, если это имя пользователя совпадает с именем пользователя, используемым при экспорте. Если оно отличается, это может быть Нужно сделать картографию), формат такой:
Создать имя пользователя пользователя, идентифицированное паролем пользователя. Табличное пространство по умолчанию. Указанное имя табличного пространства. Временное табличное пространство. Временное имя табличного пространства.
например:

7. Предоставьте права пользователя

Поскольку пользователь будет использоваться для операций импорта, разрешения, которые должны быть предоставлены пользователю, включают как минимум разрешения dba, IMP_FULL_DATABASE, и некоторые люди предполагают, что они должны соответствовать разрешениям пользователя при экспорте данных базы данных. к
SQL авторизации: (в зависимости от конкретной ситуации)

Во-вторых, используйте команду exp / imp

Расширение знаний:
Роль экспорта и импорта данных (EXPDP и IMPDP)
1. Реализовать логическое резервное копирование и логическое восстановление. к
2, перемещать объекты между пользователями базы данных. к
3. Перемещение объектов между базами данных
4, реализовать движение табличного пространства. к
Разница между экспортом и импортом данных и традиционным экспортом и импортом:
До 10g традиционный экспорт и импорт используют инструмент EXP и IMP соответственно. Начиная с 10g, сохраняются не только оригинальные инструменты EXP и IMP, но и инструменты экспорта и импорта данных EXPDP и IMPDP. При использовании EXPDP и IMPDP вам следует Вопросы, требующие внимания:
EXP и IMP являются инструментальными программами на стороне клиента, их можно использовать как на стороне клиента, так и на стороне сервера. к
EXPDP и IMPDP являются инструментами на стороне сервера и могут использоваться только на стороне сервера ORACLE, а не на стороне клиента.
IMP применяется только к файлам экспорта EXP, но не к файлам экспорта EXPDP; IMPDP применяется только к файлам экспорта EXPDP, но не к файлам экспорта EXP.

1. Экспортная команда

Существует три способа экспорта и импорта:
ExportПолный режим экспорта (импорта):
Экспортируйте все содержимое базы данных, но для работы требуются специальные разрешения,
Exp username / password buffer = 32000 file = экспортированный каталог заполнен = y
например:

ExportПользовательский режим экспорта (импорта)
Экспортировать все объекты указанного пользователя, например:

Table Экспорт (импорт) табличный режим
Экспортируйте все данные таблицы пользователя, например:

замечания : Вы можете выполнить exp help = y, imp help = y, чтобы просмотреть справочные команды, и выполнить exp или imp, чтобы просмотреть соответствующий номер версии.

Шаги экспорта:
Сначала переключитесь на пользователя оракула (администратор базы данных)

Экспорт в соответствии с требуемым режимом экспорта

Параметр COMPRESS объединит фрагменты при экспорте, попытайтесь сжать данные в начальный экстент, по умолчанию N, как правило, рекомендуется. Параметр DIRECT сообщит EXP, что нужно читать данные напрямую, вместо использования SELECT для чтения данных в таблице, как в традиционном EXP, что уменьшает обработку операторов SQL. Как правило, рекомендуется. Однако в некоторых случаях параметр DIRECT не может быть использован. к
Другие параметры могут ссылаться на справочные команды или другие материалы для обучения. Я не буду повторять их здесь.

2. Импортировать команду

Войдите на сервер и переключитесь на пользователя оракула.

Выполнить команду импорта:
При импорте необходимо использовать нового пользователя, созданного в подготовительной работе, например: имя пользователя abc, пароль ABC
Imp username / password file = путь к файлу dmp log = полный путь к выходному журналу = y ignore = y;
например:

подсказки : Процесс импорта данных часто сталкивается с проблемами, поэтому рекомендуется обратиться к дополнительной информации, всегда есть способ ее решить. Я считаю, что всему есть необходимость в его существовании, проблема только временная, а успех неизбежен!

3. Используйте сторонние инструменты (возьмите PLSQL в качестве примера)

1. Введение в формат экспорта

① Формат Dmp: .dmp - это двоичный файл, который может быть кроссплатформенным и содержать разрешения, что является эффективным.
② Формат Sql: файлы в формате .sql можно просматривать с помощью текстового редактора. Он обладает большей гибкостью и не так эффективен, как первый. Он подходит для импорта и экспорта небольших данных. Особенно обратите внимание, что в таблице не может быть больших полей (blob, clob, long), если они есть, будет сообщено об ошибке.
③ Формат pde: файлы в формате .pde. .Pde - это собственный формат файлов PL / SQL Developer, который можно импортировать и экспортировать только с помощью инструмента PL / SQL Developer, и который нельзя просмотреть в текстовом редакторе. к
Примечания: Хотя формат dmp является наиболее предпочтительным, его нелегко реализовать по двум причинам: во-первых, этот формат требует установки полной версии oracle, поскольку при экспорте необходимо выбрать соответствующий exp.exe и imp.exe, а экспорт - это установленная версия для экспорта. Версия базы данных данных такая же, и то же самое применяется при импорте, иначе будут несовместимые версии (введенные в справочный материал, лично не подтвержденные), во-вторых, экспорт этого формата часто сталкивается с процессом экспорта в одно мгновение, но Причина неудачного экспорта неизвестна (вы можете сослаться на конфигурацию переменной среды. Конфигурация ORACLE_HOME верна, я пробовал много раз, но все еще есть проблемы, и, наконец, у меня нет выбора, кроме как экспортировать в формат pde).

2. Метод экспорта

Войдите в инструмент plsql. Используемый пользователь - это пользователь, имеющий разрешения на экспорт (exp_full_database, dba и т. Д.) Для исходной базы данных. к
Port Экспортировать оператор построения таблицы (включая структуру хранения)
Инструменты шага экспорта -> экспорт объекта пользователя, выберите объект для экспорта и экспортируйте файл .sql, как показано ниже:

Дождитесь завершения экспорта

Data Экспорт данных
Инструменты шага экспорта -> таблицы экспорта, выберите таблицу для экспорта и формат экспорта для экспорта. к
Экспорт в формат DMP, как показано ниже:

Экспорт в формат sql, как показано ниже:

Экспорт в формат pde, как показано ниже:

замечания : Если вы используете сторонний инструмент для экспорта и импорта всей базы данных, это займет много времени, и у вас должно быть достаточно времени для работы (это займет несколько часов, если объем данных большой)

3. Способ импорта

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, а в случае репликации — исполнитель.

Миграция с помощью TTS создавалась, чтобы быстро переносить оракловые файлы в рамках одной платформы. Уже потом она была расширена функционалом конвертации из одного Endian-формата в другой (технология RMAN Convert). Такая миграция состоит из трех этапов:

выгрузка метаданных из словаря старой базы;
перенос файлов данных с конвертацией RMAN;
загрузка метаданных в словарь новой базы.

Это важно по следующей причине. Начиная с 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 завершена!

Автор: Алексей Струченко, руководитель направления СУБД «Инфосистемы Джет»

Читайте также: