Oracle перенос базы на другой сервер: Администрирование БД Oracle

Содержание

Руководство по миграции из Oracle в SQL Server — SQL Server

Статья

03/27/2023

Применимо к:SQL Server

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

Другие рекомендации по миграции см. в руководствах по переносу баз данных в Azure.

Важно!

Испробуйте новое расширение «Оценка переноса базы данных для Oracle» в Azure Data Studio для предварительной оценки Oracle для SQL и классификации рабочей нагрузки. Если вы находитесь на раннем этапе миграции Oracle в SQL и вам нужно выполнить высокоуровневую оценку рабочей нагрузки, определить размер целевого объекта Azure SQL для рабочей нагрузки Oracle или определить четность миграции возможностей, воспользуйтесь новым расширением. Чтобы получить подробные сведения об оценке и преобразовании кода, перейдите к SSMA для Oracle.

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

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

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

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

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

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

Обнаружить

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

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

Откройте набор средств 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.

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

Откройте SSMA для Oracle.
Выберите File (Файл) и New Project (Создать проект).
Укажите имя и расположение проекта, а затем в раскрывающемся списке выберите целевой объект для миграции в SQL Server. Щелкните ОК.
Щелкните Connect to Oracle (Подключиться к Oracle), введите сведения о подключении к Oracle и нажмите кнопку Connect (Подключиться).
На панели Filter objects (Фильтрация объектов) выберите схемы Oracle, которые вы намерены перенести, и щелкните OK (ОК).
На панели Oracle Metadata Explorer (Обозреватель метаданных Oracle) выберите нужную схему Oracle и щелкните Create Report (Создать отчет), чтобы создать отчет в формате HTML со статистикой преобразований и списком ошибок и предупреждений (при их наличии). Как вариант, можно также выбрать вкладку Создать отчет в правом верхнем углу.
Ознакомьтесь с отчетом в формате HTML, чтобы получить сведения о статистике преобразований, а также об ошибках или предупреждениях. Также можно открыть отчет в Excel, чтобы получить список объектов Oracle и действий, необходимых для выполнения преобразований схемы. По умолчанию этот отчет находится в папке report в каталоге SSMAProjects. Пример:
drive:\<username>\Documents\SSMAProjects\MyOracleMigration\report\report_2016_11_12T02_47_55\

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

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

Щелкните 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). Дополнительные сведения см. на следующих ресурсах:

статья Начало работы со службами SQL Server Integration Services;
технический документ SQL Server Integration Services: службы SSIS для Azure и гибридного перемещения данных.

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

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

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

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

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

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

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

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

Оптимизация

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

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

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

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

Заголовок	Описание
Модель и средство оценки рабочей нагрузки данных	Предоставляет предлагаемые «наиболее подходящие» целевые платформы, уровень готовности облака и уровни исправления приложений или баз данных для указанных рабочих нагрузок. Обеспечивает простое и быстрое вычисление и создание отчетов, ускоряя оценку больших объемов ресурсов, предоставляя автоматизированный и унифицированный процесс принятия решений относительно целевой платформы.
Артефакты скрипта инвентаризации Oracle	Включает в себя запрос PL/SQL, который обращается к системным таблицам Oracle и возвращает количество объектов по типам схем, типам объектов и состоянию. Он также дает приблизительную оценку объема «необработанных данных» и размера таблиц в каждой схеме. Результаты сохраняются в формате CSV.
Автоматизация сбора и объединения данных для оценки баз данных Oracle в SSMA	Это набор ресурсов, который использует CSV-файл (sources.csv в папках проектов) в качестве основы для создания XML-файлов, необходимых для проведения оценки SSMA в режиме консоли. Файл source.csv предоставляется клиентом на основе инвентаризации существующих экземпляров Oracle. Выходные файлы: AssessmentReportGeneration_source_1.xml, ServersConnectionFile.xml и VariableValueFile.xml.
Проблемы в SSMA и возможные решения при миграции баз данных Oracle	Обсуждение возможностей, которые Oracle предоставляет для назначение нескалярного условия в предложении WHERE. В SQL Server, однако, такой тип условия не поддерживается. В результате SSMA для Oracle не преобразует запросы с нескалярным условием в предложении WHERE, а создает ошибку O2SS0001. В этом техническом документе содержатся дополнительные сведения о данной проблеме и способах ее устранения.
Руководство по переносу баз данных Oracle в SQL Server	Описывает задачи, связанные с переносом схемы Oracle в SQL Server последней версии. Если миграция требует внесения изменений в компоненты и функции, то следует тщательно учесть возможное влияние каждого изменения на приложения, использующие базу данных.
Из Oracle в SQL Server — средство сравнения баз данных	SSMA for Oracle Tester — это рекомендуемое средство для автоматической проверки преобразования объектов базы данных и переноса данных, которое является надмножеством функций средства сравнения баз данных. Если вы ищете альтернативный вариант проверки данных, можно использовать средство сравнения баз данных для сравнения данных на уровне строк или столбцов во всех или выбранных таблицах, строках и столбцах.

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

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

После переноса ознакомьтесь с руководством по проверке и оптимизации после миграции.

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

Другие рекомендации по миграции см. в руководствах по переносу баз данных в Azure.

Видео по миграции см. в разделе Обзор процесса миграции.

Межплатформенная миграция Oracle Database / Хабр

В последние годы межплатформенная миграция 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 часов. Поэтому банк при продуктивной миграции предпочел использовать более долгую, но более простую и надежную процедуру. Вместе с заказчиком она и была реализована.

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

404: Страница не найдена

ПоискOracle

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

Что я могу сделать сейчас?

Если вы впервые посещаете TechTarget, добро пожаловать! Извините за обстоятельства, при которых мы встречаемся. Вот куда вы можете пойти отсюда:

Поиск

Узнайте последние новости.
Наша домашняя страница содержит самую свежую информацию о базе данных/приложениях Oracle.
Наша страница «О нас» содержит дополнительную информацию о сайте, на котором вы находитесь, SearchOracle.
Если вам нужно, пожалуйста, свяжитесь с нами, мы будем рады услышать от вас.

Просмотр по категории

Управление данными

Новое финансирование Fivetran для защиты от экономической неопределенности
Поставщик интеграции данных выделил 125 миллионов долларов на финансирование не только исследований и разработок, но и обеспечения бесперебойной работы, если…
Снежное приобретение Neeva для добавления генеративного ИИ
Ожидаемая покупка позволит поставщику облака данных внедрить генеративный ИИ в свой пакет управления данными и потенциально . ..
Преимущества стека данных развиваются по мере модернизации
Модернизация операций с данными меняет способ использования организациями стеков данных. Эксперты отрасли делятся определениями новой формы…

Бизнес-аналитика

Alteryx представляет генеративный движок искусственного интеллекта, обновление Analytics Cloud
Давний поставщик управления данными разработал новый механизм ИИ, который включает в себя генеративный ИИ. Он также представил новые возможности …
Microsoft представляет AI Boost для Power BI, новую Fabric для данных
Технический гигант представил инструмент, который дополнит его основную аналитическую платформу генеративным искусственным интеллектом, а также новый пакет SaaS …
ThoughtSpot представляет новый инструмент, который интегрирует LLM OpenAI
Поставщик аналитических услуг представил ряд новых возможностей, в том числе Sage, которая объединяет технологию генеративного искусственного интеллекта OpenAI . ..

ПоискSAP

Обзор ERP: партнеры SAP представляют новые продукты на выставке Sapphire
На SAP Sapphire 2023 партнеры SAP и независимые поставщики программного обеспечения представили продукты и услуги, направленные на автоматизацию процессов, повышение безопасности и…
Новый реестр устойчивого развития SAP отслеживает выбросы углерода
Если компании хотят улучшить усилия по обеспечению устойчивого развития, они должны будут относиться к экологической отчетности так же, как к финансовой отчетности. …
Новости SAP Sapphire 2023, тенденции и анализ
Конференция подтверждает мнение клиентов SAP о том, что будущее за облачными технологиями, путем демонстрации облачных продуктов, услуг и …

TheServerSide.com

5 примеров лидера слуг Scrum
Термин «лидер-слуга» был удален из Руководства по Scrum 2020, но это не значит, что он не важен. Вот пять примеров…
Как решить проблемы с производительностью Python
Python — отличный язык для решения математических и научных задач непрограммистами, даже если такая оптимизация влияет на …
Скрам против водопада: в чем разница?
Большинство организаций выбирают между методологиями Waterfall и Agile, что часто означает сравнение Scrum и Waterfall. Вот…

Центр обработки данных

Различия между Green Globes и LEED для центров обработки данных
Учитывайте сертификаты Green Globes и LEED при строительстве экологичных центров обработки данных. Узнайте о различиях в том, как оцениваются …
6 лучших практик миграции центров обработки данных
Миграция центра обработки данных может быть сложным процессом. Используйте лучшие практики при переносе центра обработки данных, чтобы обеспечить максимальное время безотказной работы, избегайте . ..
Навигация по стандарту и сертификации центров обработки данных Energy Star
Организации могут использовать центры обработки данных стандарта Energy Star и сертифицированные активы для повышения энергоэффективности. Обратите внимание на Energy Star…

Управление контентом

8 программных инструментов для обмена знаниями и совместной работы
Обмен знаниями и совместная работа являются основными элементами современного рабочего места благодаря удаленной и гибридной работе. Эти восемь инструментов могут …
Каковы преимущества базы знаний?
Поскольку база знаний позволяет клиентам и сотрудникам быстро находить ответы, она может повысить оценку удовлетворенности клиентов организации…
Как создать базу знаний WordPress
База знаний позволяет клиентам быстро находить ответы на свои вопросы, что приносит пользу CX. Организации могут использовать WordPress…

HRSoftware

UKG интегрирует генеративный ИИ в HR-технологии с помощью Google Vertex
UKG использует платформу Google Vertex AI для тестирования и изучения генеративного ИИ и видит, что он обеспечивает диалоговые возможности …
Федеральные регуляторы призывают HR проводить аудит предвзятости ИИ
Последнее предупреждение EEOC о предвзятости ИИ при приеме на работу может побудить работодателей проводить проверки ИИ, проводимые либо внутри компании, либо с …
Иммиграционный закон Флориды создает проблемы для HR и экономики
Новый иммиграционный закон Флориды требует, чтобы компании со штатом более 25 сотрудников использовали E-Verify для проверки статуса разрешения на работу. …

Как перенести работающую базу данных Oracle на другую систему

Сожалеем. Мы не смогли найти совпадение по вашему запросу.

Мы предлагаем вам попробовать следующее, чтобы найти то, что вы ищете:

Проверьте правильность написания вашего ключевого слова.
Используйте синонимы для введенного вами ключевого слова, например, попробуйте «приложение» вместо «программное обеспечение».
Начать новый поиск.

Связаться с отделом продаж

Меню
Меню

Использование Oracle VM Server для SPARC 2.1

Оргад Кимчи и Роман Иванов, февраль 2012 г.

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

Введение

В этой статье описывается, как воспользоваться преимуществами функции Live Migration в Oracle VM Server for SPARC 2.1 (ранее называвшейся Sun Logical Domains) для миграции работающего одного экземпляра Oracle Database 11 g Release 2 на другой систему без перерыва.

Примечание : Oracle Database 11 g Версия 2 с Oracle VM Server для SPARC сертифицирована, начиная с Oracle Solaris 10 10/08. В этой статье использовался Oracle Solaris 10 9/10, чтобы оценить функцию динамической миграции Oracle VM Server для SPARC 2.1.

Основы

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

Запланированные и незапланированные простои

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

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

Запланированные простои должны быть запланированы так, чтобы свести к минимуму влияние на доступность системы, поскольку даже незначительное изменение подсистем может привести к нарушению доступности и повлиять на бизнес-потребности.

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

Незапланированный простой происходит в результате сбоев оборудования и событий окружающей среды. Обычно такие простои необходимо устранять немедленно. Этот документ не рассматривает этот тип простоя.

Введение в Oracle VM Server для SPARC

Oracle VM Server для SPARC 2.1 поддерживается на платформах Oracle UltraSPARC T2 и UltraSPARC T2 Plus, а также на платформах Oracle SPARC T3 и SPARC T4.

Oracle VM Server for SPARC позволяет создавать несколько виртуальных систем на одной физической системе. Каждая виртуальная система называется логическим доменом и запускает собственный экземпляр Oracle Solaris 10 или Oracle Solaris 11.

Oracle VM Server for SPARC позволяет точно распределять ресурсы ЦП и памяти для рабочей нагрузки. В этом документе описывается, как выполнить миграцию активного домена с помощью функции динамической миграции. Динамическая миграция между двумя машинами сводит к минимуму перерывы в работе приложений и предоставляет мощную платформу для управления производственными средами.

Введение в базу данных Oracle

База данных Oracle — это ведущее приложение для работы с базами данных, поэтому оно часто используется на серверах. Благодаря виртуализации и консолидации Oracle Database теперь может работать в выбранных сертифицированных виртуальных средах, таких как Oracle VM Server for SPARC.

Обзор динамической миграции

В выпуске Oracle VM Server for SPARC 2.1 представлена функция динамической миграции, которая позволяет перенести активный домен в другую систему, пока домен продолжает работать.

Live Migration использует SSL для шифрования структур памяти логических доменов, поскольку они безопасно передаются по сети.

Хост, на котором инициирована миграция, называется исходной машиной , а хост, на который переносится домен, называется целевая машина .

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

Live Migration имеет набор требований и ограничений для ЦП, памяти и ввода-вывода, которые должны быть выполнены на исходной и целевой машинах. См. «Требования к динамической миграции домена» в примечаниях к выпуску Oracle VM Server для SPARC 2.1.

Преимущества динамической миграции

Использование динамической миграции дает следующие преимущества:

Обслуживание — как администратор вы можете минимизировать время простоя с помощью функции динамической миграции Oracle VM Server для домена SPARC. Если вам необходимо отключить какое-либо оборудование, используйте эту функцию, чтобы сохранить работающие приложения, переместив их на какой-либо другой сервер.
Ресурс оборудования. Если вы видите лучший способ развертывания приложения на разных серверах, используйте динамическую миграцию домена, чтобы переместить активный домен на машину с большей физической памятью, большей мощностью ЦП или лучшей подсистемой ввода-вывода. Это изменение повышает производительность приложения, сохраняя структуры памяти в тепле, поскольку любое приложение, интенсивно использующее память, будет сохранять все структуры памяти на месте. Например, после динамической миграции Oracle Database будет иметь системную глобальную область (SGA) и другие структуры памяти, расположенные так же, как и до миграции.
Длительные вычисления — вы можете максимально увеличить доступность приложения во время миграции, поскольку нет необходимости останавливать приложение во время миграции. Например, при переносе приложений, которые выполняют длительные вычисления, такие как анализ финансовых данных или научные вычисления, вам не нужно перезапускать с самого начала или выполнять какие-либо промежуточные процедуры сохранения и восстановления данных.

Требования к оборудованию и программному обеспечению

Прежде чем начать, убедитесь, что ваше программное и аппаратное обеспечение соответствует этим требованиям.

Требования к базе данных Oracle

Для запуска конфигурации с одним экземпляром базы данных Oracle на сервере Oracle VM Server for SPARC необходимо использовать базу данных Oracle 11 g Release 2 (база данных Oracle 11.2.0.1). Более поздние версии также могут поддерживаться. См. документацию по базе данных Oracle, чтобы убедиться, что конкретная версия поддерживается, и проверить наличие дополнительных требований. Также см. веб-сайт My Oracle Support (требуется регистрация).

Аппаратная конфигурация

Любой сервер, поддерживающий Oracle VM Server для SPARC, может использоваться с базой данных Oracle. В зависимости от выбранной конфигурации и варианта развертывания может потребоваться дополнительное оборудование, такое как внешние массивы хранения или сетевые коммутаторы.

На рис. 1 показана типичная конфигурация оборудования и кабели, совместимые с динамической миграцией домена. В этом примере используется следующее оборудование:

Два сервера SPARC T4-1 от Oracle, каждый с 64 ГБ памяти и одним процессором SPARC T4.
Восемь ядер ЦП на процессор и 8 потоков ЦП на ядро. Таким образом, каждая система имеет 64 потока процессора (8×8). Один внутренний диск используется на каждом сервере в качестве системного диска управляющего домена.
Один массив хранения Sun Storage 2540-M2 от Oracle с шестнадцатью дисками SAS емкостью 300 ГБ. Массив хранения подключен к обоим серверам, и каждый сервер подключен к одному и тому же контроллеру массива (A или B), на который сопоставлены LUN. Массив хранения предоставляет один LUN (LUN 0), который используется в качестве системного диска гостевого домена, и второй LUN для хранения данных базы данных Oracle (LUN 1).
Два адаптера главной шины FC-AL емкостью 4 ГБ (HBA), по одному на каждый сервер. Эти HBA используются для подключения массива хранения к обоим серверам.
Четыре встроенных сетевых интерфейса 1-GbE на каждом сервере, которые используются для сетевой связи.

Рис. 1. Конфигурация оборудования и кабели

Запуск Oracle Database на Oracle VM Server для SPARC Память.

Каждый управляющий домен, предоставляющий виртуальные устройства (виртуальный диск и виртуальную сеть) гостевому домену Oracle Database с одним экземпляром, должен иметь не менее 8 ЦП (1 ядро ЦП) и 4 ГБ памяти.

Сведения о конфигурации

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

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

Служба одного виртуального диска ( primary-vds0 ) экспортирует физические диски как виртуальные диски в гостевой домен.
Одна служба концентратора виртуальной консоли ( primary-vcc0 ) обеспечивает доступ к виртуальной консоли гостевого домена. Эта служба использует диапазон портов 5000–5100 для доступа к виртуальным консолям.
Служба одного виртуального коммутатора ( primary-vsw0 ) связан с основным сетевым интерфейсом ( nxge0 ).

Установка и настройка программного обеспечения

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

Установка ОС Oracle Solaris

Oracle Solaris предустанавливается на новые серверы SPARC. Для этих систем убедитесь, что установлена соответствующая версия Oracle Solaris, и проверьте наличие необходимых исправлений.

Чтобы переустановить Oracle Solaris в системе SPARC, см. документацию по Oracle Solaris 10 или Oracle Solaris 11. В примере из этой статьи операционная система установлена на первый внутренний диск сервера.

После установки Oracle Solaris систему можно настроить и включить для использования программного обеспечения Oracle VM Server for SPARC 2.1.

Установка программного обеспечения Oracle VM Server for SPARC

Программное обеспечение Oracle VM Server for SPARC также предварительно устанавливается на новые серверы SPARC. Для этих систем убедитесь, что установлена соответствующая версия Oracle VM Server for SPARC, и проверьте наличие всех необходимых исправлений.

Если Oracle Solaris был переустановлен на сервере, возможно, вам придется переустановить программное обеспечение Oracle VM Server for SPARC. См. страницу загрузки виртуальной машины Oracle.

В следующем примере показаны действия, выполняемые на каждом физическом сервере. На каждом сервере уже установлен Oracle Solaris и необходимые исправления.

Убедитесь, что микропрограмма системы соответствует выпуску Oracle VM Server for SPARC, который вы планируете установить. См. «Необходимое программное обеспечение и исправления» в Oracle VM Server для SPARC 2.1 Примечания к выпуску и «Обновление микропрограммы системы» в Oracle VM Server для SPARC 2.1 Руководство по администрированию документации.
Загрузите программное обеспечение Oracle VM Server for SPARC 2.1 со страницы загрузки Oracle VM.
Распаковать архив.
Установите пакет SUNWldm.v . См. «Установка программного обеспечения Oracle VM Server для SPARC в новой системе» в Oracle VM Server для SPARC 2.1: Руководство по администрированию 9.0174 .
основной # pkgadd -d OVM_Server_SPARC-2_1/Product SUNWldm.v

Настройка массива хранения

Массив хранения Sun Storage 2540-M2 подключен к управляющему домену, который экспортирует два LUN (LUN 0 и LUN 1) как виртуальные диски в гостевой домен.

Гостевой домен использует первый LUN (LUN 0) в качестве системного диска для операционной системы, а второй LUN (LUN 1) — в качестве диска для хранения файлов данных базы данных Oracle. На рис. 2 показана схема хранения исходной и целевой машин.

Рис. 2. Конфигурация хранилища

Настройка домена управления

После установки программного обеспечения Oracle VM Server for SPARC перенастройте текущую систему, чтобы она стала доменом управления. Выполните следующие действия на каждом физическом сервере:

1. Создайте службу концентратора виртуальной консоли ( vcc ) для использования демоном сервера терминалов виртуальной сети ( vntsd ) и в качестве концентратора для всех консолей логического домена.
основной # ldm add-vcc диапазон портов = 5000-5100 основной-vcc0 основной

2. Создайте сервер виртуальных дисков ( vds ).
первичный# ldm add-vds первичный-vds0 первичный

3. Создайте службу виртуального коммутатора ( vsw ), чтобы обеспечить сетевое взаимодействие между устройствами виртуальной сети ( vnet ) в логических доменах.
первичный# ldm add-vsw net-dev=igb0 первичный-vsw0 первичный

4. Убедитесь, что службы были созданы с помощью 9Команда 0299 ldm list-services , как показано в листинге 1.
Листинг 1. Проверка служб
первичный# ldm list-services первичный VDS НАЗВАНИЕ ГРОМКОСТЬ ВАРИАНТЫ УСТРОЙСТВО первичный-vds0 ВКК НАЗВАНИЕ ДИАПАЗОН ПОРТОВ первичный-vcc0 5000-5100 ВМЗ НАЗВАНИЕ MAC NET-DEV РЕЖИМ УСТРОЙСТВА первичный-vsw0 02:04:4f:fb:9f:0d nxge0 switch@0 prog,promisc ВКК НАЗВАНИЕ LDOM ПОРТЫ-ДИАПАЗОН первичный-vcc0 первичный 5000-5100 ВМЗ ИМЯ LDOM MAC NET-DEV ID DEVICE LINKPROP DEFAULT-VLAN-ID PVID VID ... первичный-vsw0 первичный 00:14:4f:f8:28:c2 igb0 0 switch@0 1 1 1500 вкл. VDS НАЗВАНИЕ LDOM ТОМ ВАРИАНТЫ MPGROUP УСТРОЙСТВО первичный-vds0 первичный

Oracle VM Server для SPARC использует SSL для шифрования миграционного трафика, чтобы защитить конфиденциальные данные от неправомерного использования и устранить потребность в дополнительном оборудовании и выделенных сетях.

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

Примечание : ЦП SPARC T4 имеют встроенные криптографические инструкции, поэтому вам не нужно назначать их ЦП.

1. Определите, есть ли у вас криптографические устройства в домене управления.
первичный # список ldm -o крипто первичный
2. Назначьте криптографические ресурсы домену управления.
первичный# ldm set-crypto 1 первичный
3. Назначьте ЦП и память управляющему домену.
Вы можете сократить общее время миграции, добавив больше ЦП в основной домен на исходном компьютере. Лучше всего иметь не менее восьми процессоров, назначенных каждому основному домену. Например, следующие команды назначают управляющему домену восемь ЦП и 4 ГБ памяти.
первичный # ldm start-reconf первичный первичный # ldm set-vcpu 8 первичный первичный # ldm set-memory 4G первичный
4. Перезагрузите систему.
primary# init 6
После перезагрузки системы Oracle VM Server for SPARC включается, и в системе настраивается один домен: управляющий домен, primary . Из управляющего домена можно создавать и настраивать дополнительные домены.
5. Убедитесь, что диспетчер логических доменов ( ldmd ) и службы Virtual Network Terminal Server ( vntsd ) включены.
основной # svcadm enable ldmdprimary # svcadm enable vntsd
6. Добавьте конфигурацию машины логического домена в служебный процессор (SP). Например, следующая команда добавляет конфигурацию с именем initial .
primary# ldm add-config initial

7. Убедитесь, что конфигурация готова к использованию.
первичный # ldm list-configfactory-default первоначальный [текущий]

Настройка гостевого домена

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

Гостевой домен ldg1 изначально создается со следующими ресурсами:

Восемь ГБ памяти.
Двадцать четыре процессора.
Один виртуальный сетевой интерфейс ( vnet0 ), подключенный к виртуальному коммутатору primary-vsw0 .
Один виртуальный диск, который отображается как c0d0 в гостевом домене и является LUN из массива хранения. Домен ldg1 использует LUN 0 массива хранения ( c2t6d0 ).
Второй виртуальный диск, который отображается как c0d1 в гостевом домене и является LUN из массива хранения. Домен ldg1 использует LUN 1 массива хранения ( c2t6d1 ). Этот виртуальный диск используется для хранения файлов базы данных Oracle.

Выполните следующие шаги для создания каждого гостевого домена:

1. Создайте гостевой домен ldg1 из управляющего домена на исходной машине.
Примечание : Выполните только команду ldm set-crypto , если ваш сервер не является системой на основе SPARC T4.
основной # ldm создать ldg1 первичный # ldm set-vcpu 24 ldg1 основная # ldm set-memory 8G ldg1 первичный # ldm set-crypto 3 ldg1 первичный # ldm add-vnet vnet0 первичный-vsw0 ldg1 основной # ldm add-vdsdev /dev/dsk/c2t6d0s2 vol1@primary-vds0 первичный # ldm add-vdisk vol1 vol1@primary-vds0 ldg1 основной # ldm add-vdsdev /dev/dsk/c2t6d1s2 oradata@primary-vds0 первичный # ldm add-vdisk oradata oradata@primary-vds0 ldg1

2. После создания домена привяжите и запустите гостевой домен из управляющего домена на исходном компьютере с помощью следующих команд.
первичный# ldm bind ldg1primary# ldm start ldg1

3. Определите консольный порт для домена.
primary# ldm ls ldg1NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldg1 активен -n---- 5000 24 8G 0. 0% 1h 1m

4. Доступ к консоли ldg1 с помощью команды telnet .
primary# telnet localhost 5000

После запуска гостевого домена убедитесь, что в гостевом домене установлены соответствующие ОС Oracle Solaris и исправления. Установку можно выполнить по сети, с DVD-диска или с помощью ISO-образа DVD-диска. См. Руководство по администрированию Oracle VM Server для SPARC 2.1 .

Примечание : LUN часто отображаются с разными именами на разных серверах. Имена LUN в управляющих доменах не обязательно должны быть идентичными. Но управляющие домены в обеих системах должны виртуализировать одни и те же LUN (LUN 0 и LUN 1) с одинаковыми именами томов ( vol1 и или орадата ).

Пример в листинге 2 показывает, как домен с именем ldg1 сконфигурирован с восемью ЦП, 24 ГБ памяти и двумя LUN из массива хранения Sun Storage 2540-M2.

Листинг 2. Пример конфигурации домена

 primary# ldm ls -l ldg1
НАЗВАНИЕ СОСТОЯНИЕ ФЛАГИ ПРОТИВ ПАМЯТИ VCPU UTIL UPTIME
ldg1 активен -n---- 5000 24 8G 0.0% 1h 1m
МЯГКОЕ СОСТОЯНИЕ
Солярис работает
МАК
    00:14:4ф:фб:96:89
HOSTID
    0x84fb9689
КОНТРОЛЬ
    политика отказа = игнорировать
ЗАВИСИМОСТЬ
    мастер=
ВЦПУ
    VID PID UTIL STRAND
    0 16 0,2% 100%
    1 17 0,0% 100%
    2 18 0,5% 100%
    3 19 0,0% 100%
    4 20 0,0% 100%
    5 21 0,0% 100%
    6 22 0,1% 100%
    7 23 0,0% 100%
    8 24 0,1% 100%
    9 25 0,0% 100%
    10 26 0,0% 100%
    11 27 0,0% 100%
    12 28 0,0% 100%
    13 290,0% 100%
    14 30 0,0% 100%
    15 31 0,0% 100%
    16 32 0,0% 100%
    17 33 0,0% 100%
    18 34 0,0% 100%
    19 35 0,0% 100%
    20 36 0,0% 100%
    21 37 0,0% 100%
    22 38 0,0% 100%
    23 39 0,1% 100%
ОБЪЕМ ПАМЯТИ
    РА ПА РАЗМЕР
    0x8000000 0x408000000 8G
ПЕРЕМЕННЫЕ
    загрузочное устройство = vdisk1
    раскладка клавиатуры = американский английский
СЕТЬ
    НАЗВАНИЕ ID УСЛУГИ УСТРОЙСТВО MAC РЕЖИМ PVID VID MTU LINKPROP
    vnet1 основной-vsw0@основной 0 сеть@0 00:14:4f:f9:c0:62 1 1500
ДИСК
    НАЗВАНИЕ VOLUME TOUT ID DEVICE SERVER MPGROUP
    vdisk1 vol1@primary-vds0 0 disk@0 первичный
    oradata oradata@primary-vds0 1 диск@1 первичный
VCONS
    НАЗВАНИЕ СЛУЖЕБНЫЙ ПОРТ
    ldg1 первичный-vcc0 @ первичный 5000

В примере в листинге 3 показана конфигурация управляющего домена. Используйте команду ldm list-services , чтобы убедиться, что службы созданы.

Листинг 3. Пример конфигурации домена управления

 primary# ldm ls-services primary
ВКК
    НАЗВАНИЕ LDOM ПОРТЫ-ДИАПАЗОН
    первичный-vcc0 первичный 5000-5100
ВМЗ
    ИМЯ LDOM MAC NET-DEV ID DEVICE LINKPROP DEFAULT-VLAN-ID ...
    первичный-vsw0 первичный 00:14:4f:f9:32:b0 nxgeg0 0 switch@0 1 1 ...
VDS
    НАЗВАНИЕ LDOM ТОМ ВАРИАНТЫ MPGROUP УСТРОЙСТВО
    первичный-vds0 первичный том 1 /dev/dsk/c2t6d0s2
                           орадата /dev/dsk/c2t6d1s2

Установка Oracle Solaris в гостевом домене

Убедитесь, что в гостевом домене установлена соответствующая версия Oracle Solaris, и проверьте наличие необходимых исправлений.

После установки Oracle Solaris в гостевом домене систему можно настроить и включить для использования базы данных Oracle.

Установка базы данных Oracle

Установка программного обеспечения базы данных Oracle аналогична стандартной установке базы данных Oracle. Начните с установки Oracle Database, а затем примените последний набор исправлений. Используйте второй LUN для создания файловой системы UFS или ZFS для хранения файлов данных базы данных Oracle.

Дополнительные сведения об использовании ZFS для базы данных Oracle см. в разделе Настройка ZFS в Oracle Solaris для базы данных Oracle.

Подготовка целевого сервера

Подготовьте целевой сервер следующим образом.

Выполните шаги, описанные в следующих разделах, чтобы подготовить целевую машину:
Установка сервера Oracle VM для программного обеспечения SPARC
Настройка домена управления
Убедитесь, что все службы виртуального ввода-вывода, которые используются переносимым доменом, доступны на целевом сервере.
Убедитесь, что целевой сервер имеет доступ как к LUN 0, так и к LUN 1 из одного и того же хранилища.
Чтобы добавить первый LUN (LUN 0) и второй LUN (LUN 1) на целевой компьютер, выполните следующие команды из домена управления целевого сервера:
# ldm add-vdsdev /dev/dsk/c2t6d0s2 vol1@ первичный-vds0 # ldm add-vdsdev /dev/dsk/c2t6d1s2 oradata@primary-vds0
Примечание : LUN часто отображаются с разными именами на разных серверах.