Резервный оракул, что это такое
Обновлено: 04.07.2024
В этом руководстве представлен обзор подхода к управлению Oracle dSource в среде Delphix, где настроен Oracle Data Guard и выполняются операции переключения.
Предполагается, что физическая резервная среда Oracle Data Guard установлена и работает нормально, повторная отправка выполняется успешно, а управляемое восстановление применяет повтор на резервной площадке.
Oracle Data Guard позволяет выполнять контролируемые операции переключения и аварийного переключения. Переключение позволяет поменять местами роли основного и резервного сайтов. Переключение следует отличать от аварийного переключения, поскольку, с другой стороны, аварийное переключение обычно выполняется в сценариях, связанных с потерей основного сайта, а резервный сайт преобразуется в основной. Как правило, после операции аварийного переключения основной сайт необходимо перестроить и установить в качестве резервного после того, как он будет восстановлен после любого сбоя, приведшего к отключению сайта.
Общая информация
Окружающая среда
- Обнаружены две целевые хост-среды, связанные с Delphix Engine: oelvbc1n1 и oelvbc1n2.
- На одном хосте работает основной сайт, указанный через db_unique_name из db112
- На одном хосте работает резервный сайт, указанный через db_unique_name из db112_stb, этот сайт через физическую резервную базу данных связан с Delphix в качестве dSource.
Сценарий
- Контролируемое переключение между сайтами выполняется на уровне Oracle с помощью командной строки Data Guard Broker
- В результате существующая первичная база данных (db112) становится физической резервной базой данных.
- Существующий резервный сайт (db112_stb) становится основным сайтом в результате изменения роли
- DSource в Delphix должен следовать за резервной базой данных с одного целевого хоста на другой в результате операции переключения
- Перемещение источника dSource с одного сайта на другой означает отсоединение источника dSource от Engine и присоединение его к новому целевому хосту после операции переключения в Oracle.
Обратите внимание, что в этом документе не рассматривается операция аварийного переключения.
Текущее состояние среды
Резервный сайт DB112_STB:
Резервный сайт — это физический резервный сайт, который в данный момент смонтирован, но не открыт, а управляемое восстановление активно.
Основной сайт:
Основная база данных открыта для чтения и записи и отправляет архивные журналы на резервный сайт посредством доставки журналов через LOG_ARCHIVE_DEST_2.
Конфигурация Data Guard Broker:
Конфигурация брокера настроена и выглядит исправно.
Резервная база данных Oracle принята ядром для использования в качестве dSource.
Для подключения резервной базы данных, которая смонтирована (не открыта) с управляемым восстановлением, необходимо связать ее с Delphix с помощью пользователя SYS. При наличии Active Data Guard в процессе связывания можно было бы использовать обычного пользователя базы данных Delphix. Резервная база данных работает в среде, определенной в Delphix как OELVBC1N1.
На приведенном ниже снимке экрана показана физическая резервная база данных DB112_STB, связанная с Delphix.
Выполните переключение Data Guard.
Смена роли в этом случае выполняется с помощью утилиты командной строки Data Guard Broker dgmgrl. Это предполагает, что конфигурация Data Guard Broker уже создана и работает нормально. Процесс переключения следующий
Убедитесь, что среда Data Guard готова к переключению.
Проверьте основной сайт.
- На основном сайте должно быть указано, что он готов к переходу на физический резерв, "TO STANDBY".
- Между сайтами не должно быть обнаружено пробелов в архивных журналах, "NO GAP".
Проверьте резервный сайт.
- Резервный сайт должен показывать, что он готов внести изменения в основной. Не должно быть задержек ни в переносе, ни в применении.
Выполните переключение, чтобы поменять местами роли на каждом из сайтов.
- Выполните переключение с основного сервера с помощью утилиты командной строки Data Guard Broker.
- Теперь должно быть видно, что роли поменялись местами.
SQLPlus можно использовать для подтверждения изменения роли.
- Новая первичная база данных теперь будет отображаться на хосте резервного сайта (oelvbc1n2).
- Новая физическая резервная база данных теперь появится на хосте основного сайта (oelvbc1n1).
Изменения роли базы данных Data Guard и Delphix.
Изменение роли в физической резервной среде Data Guard может быть прозрачным для Delphix. Если вы не хотите изменять сайт, который Delphix использует в качестве своего dSource, и согласны с тем, чтобы dSource был подключен к базе данных, которая была резервной базой данных, а теперь является основной базой данных, то на уровне Delphix больше ничего не нужно делать для размещения. изменение.
Delphix с радостью позволит вам выполнить дальнейшую моментальную синхронизацию dSource, даже если его роль изменилась на уровне Oracle.
Выравнивание dSource в Delphix с новым резервным сайтом.
Использование резервного сайта в качестве dSource было очень обдуманным решением, и после изменения роли в Oracle вы, как правило, захотите, чтобы Delphix отражал новое расположение резервного сайта и использовал его в качестве dSource.
Учитывая это, после того как переключение на Oracle было выполнено, Delphix необходимо указать на то, что теперь является новым резервным сайтом. Механизм для выполнения этого заключается в выполнении переключения и отсоединении dSource от исходного резервного сайта и присоединении новой резервной базы данных к исходному первичному сайту, но теперь на котором работает текущая резервная база данных.
После изменения роли командная строка Data Guard Broker показывает, что новый резервный сайт теперь находится на том же месте, что и исходный первичный сайт.
- Посредник показывает, что Physical Standby теперь работает с базой данных Data Guard db112 (db_unique_name=db112).
- Oracle показывает, что резервный сайт теперь работает на узле oelvbc1n1 и базе данных db112 (db_unique_name=db112).
- С другой стороны, Delphix по-прежнему указывает на исходный сайт OELVBC1N2, который теперь работает как основная база данных.
Выравнивание расположения Delphix dSource с новым резервным сайтом.
Процесс согласования Delphix с новым основным сайтом и средой заключается в отсоединении текущей среды dSource (oelvbc1n2) и базы данных (db_unique_name db112_stb) от Delphix и повторном подключении dSource в Engine к новой среде основного сайта (oelvbc1n1). ) и базу данных (db_unique_name db112).
Это выполняется через интерфейс командной строки Delphix (CLI) от имени пользователя delphix_admin, используя шаги, описанные в следующей документации.
Обратите внимание, что интерфейс командной строки изменяется в разных выпусках, а набор команд и параметров может отличаться от тех, что указаны в документации и подробно описаны ниже.
- В интерфейсе командной строки я выполнил следующие действия, чтобы отсоединить базу данных, установленную в настоящее время в качестве источника (старая резервная база данных, которая теперь является основным сайтом).
- Чтобы присоединить старую среду основного сайта/новый резервный сайт, целевая среда хоста должна быть уже обнаружена ядром Delphix и отображаться как среда и неприсоединенная база данных в пользовательском интерфейсе Delphix.
- В пользовательском интерфейсе Delphix задание подключения источника будет отображаться как действие.
- После завершения операций присоединения источник dSource должен отображаться как активный.
- Операции SnapSync теперь можно выполнять с перемещенным dSource, как обычно.
Из пользовательского интерфейса видно, что dSource теперь подключен к базе данных db112 (db_unique_name db112), работающей на целевом хосте OELVBC1N1.
Конфигурация Data Guard содержит основную базу данных и до тридцати связанных баз данных st andby. В этой главе описываются следующие рекомендации по началу работы с Data Guard:
2.1 Типы резервных баз данных
Резервная база данных — это согласованная с точки зрения транзакций копия рабочей базы данных Oracle, которая изначально создается из резервной копии основной базы данных. После создания и настройки резервной базы данных Data Guard автоматически обслуживает резервную базу данных, передавая данные повторного выполнения основной базы данных в резервную систему, где данные повторного выполнения применяются к резервной базе данных.
Резервная база данных может быть одного из следующих типов: физическая резервная база данных, логическая резервная база данных или резервная база данных моментального снимка.При необходимости физическая или логическая резервная база данных может взять на себя роль первичной базы данных и взять на себя производственную обработку. Конфигурация Data Guard может включать любую комбинацию этих типов резервных баз данных.
2.1.1 Физические резервные базы данных
Физическая резервная база данных — это точная поблочная копия первичной базы данных. Физическая резервная база данных поддерживается как точная копия с помощью процесса Redo Apply, в котором данные повторного выполнения, полученные из первичной базы данных, постоянно применяются к физической резервной базе данных с использованием механизмов восстановления базы данных.
Преимущества физической резервной базы данных
Физическая резервная база данных имеет следующие преимущества:
Аварийное восстановление и высокая доступность
Физическая резервная база данных — это надежное и эффективное решение для аварийного восстановления и обеспечения высокой доступности. Простые в управлении возможности переключения и аварийного переключения позволяют легко менять роли между основной и физической резервной базами данных, сводя к минимуму время простоя основной базы данных из-за запланированных и незапланированных простоев.
Физическая резервная база данных может предотвратить потерю данных даже в случае непредвиденных аварий. Физическая резервная база данных поддерживает все типы данных и все операции DDL и DML, которые может поддерживать первичная база данных. Он также обеспечивает защиту от повреждения данных и ошибок пользователя. Физические повреждения на уровне хранилища в первичной базе данных не будут распространяться на резервную базу данных. Точно так же можно легко устранить логические повреждения или ошибки пользователя, которые в противном случае могли бы привести к потере данных.
Уменьшение нагрузки на основную базу данных
Oracle Recovery Manager (RMAN) может использовать физическую резервную базу данных для разгрузки резервных копий из основной базы данных, экономя ценные циклы ЦП и ввода-вывода.
К физической резервной базе данных также можно обращаться, когда активно действие Redo Apply, что позволяет переносить запросы с основной на физическую резервную базу данных, что еще больше снижает основную рабочую нагрузку.
Технология Redo Apply, используемая физической резервной базой данных, является наиболее эффективным механизмом обновления резервной базы данных с учетом изменений, вносимых в первичную базу данных, поскольку она применяет изменения с использованием низкоуровневых механизмов восстановления, которые обходят все уровни кода уровня SQL.
2.1.2 Логические резервные базы данных
Логическая резервная база данных изначально создается как идентичная копия первичной базы данных, но позже ее можно изменить, чтобы она имела другую структуру. Логическая резервная база данных обновляется выполнением операторов SQL. Это позволяет пользователям получать доступ к резервной базе данных для запросов и отчетов в любое время. Таким образом, логическая резервная база данных может использоваться одновременно для защиты данных и создания отчетов.
Data Guard автоматически применяет информацию из архивного файла журнала повторов или резервного файла журнала повторов к логической резервной базе данных, преобразуя данные в файлах журнала в операторы SQL и затем выполняя операторы SQL в логической резервной базе данных. Поскольку логическая резервная база данных обновляется с помощью операторов SQL, она должна оставаться открытой. Хотя логическая резервная база данных открыта в режиме чтения/записи, ее целевые таблицы для регенерированного SQL доступны только для операций только для чтения. Пока эти таблицы обновляются, их можно одновременно использовать для других задач, таких как отчеты, суммирование и запросы. Более того, эти задачи можно оптимизировать, создав дополнительные индексы и материализованные представления для обслуживаемых таблиц.
У логической резервной базы данных есть некоторые ограничения на типы данных, типы таблиц и типы операций DDL и DML. Информацию о типах данных и поддержке DDL в логических резервных базах данных см. в Приложении C.
Преимущества логической резервной базы данных
Логическая резервная база данных идеально подходит для обеспечения высокой доступности (HA), но при этом предлагает преимущества восстановления данных (DR). По сравнению с физической резервной базой данных логическая резервная база данных обеспечивает значительные дополнительные преимущества высокой доступности:
Защита от дополнительных видов сбоев
Поскольку логическая резервная копия анализирует повтор и восстанавливает логические изменения в базе данных, она может обнаруживать и защищать от определенных видов аппаратных сбоев на основной базе данных, которые потенциально могут быть воспроизведены посредством изменений на уровне блоков. Oracle поддерживает наличие как физических, так и логических резервных серверов для одного и того же основного сервера.
Эффективное использование ресурсов
Логическая резервная база данных открыта для чтения и записи, в то время как изменения в основной базе данных реплицируются. Следовательно, логическая резервная база данных может одновременно использоваться для удовлетворения многих других бизнес-требований, например, она может выполнять рабочие нагрузки по созданию отчетов, которые были бы проблематичными для пропускной способности основной базы данных. Его можно использовать для тестирования новых выпусков программного обеспечения и некоторых видов приложений на полной и точной копии исходных данных.Он может размещать другие приложения и дополнительные схемы, одновременно защищая данные, реплицированные с основного сервера, от локальных изменений. Его можно использовать для оценки влияния определенных видов физической реструктуризации (например, изменений в схемах разделения). Поскольку логический резерв идентифицирует транзакции пользователей и реплицирует только эти изменения, отфильтровывая фоновые системные изменения, он может эффективно реплицировать только интересующие транзакции.
Логический резерв — это простое готовое решение для создания актуальных, непротиворечивых реплик первичной базы данных, которые можно использовать для распределения рабочей нагрузки. По мере увеличения рабочей нагрузки на отчеты можно создавать дополнительные логические резервные серверы с прозрачным распределением нагрузки, не влияя на транзакционную пропускную способность основного сервера.
Оптимизировано для требований отчетности и поддержки принятия решений
Ключевым преимуществом логического резерва является то, что можно создавать важные вспомогательные структуры для оптимизации рабочей нагрузки отчетов; структуры, которые могут оказать недопустимое влияние на время отклика транзакций первичного сервера. В логической резервной системе данные могут быть физически реорганизованы в хранилище другого типа с другим разделением, иметь много разных индексов, создавать и поддерживать материализованные представления с обновлением по требованию, а также ее можно использовать для управления созданием кубов данных и других данных OLAP. просмотров.
Сведение к минимуму времени простоя при обновлении программного обеспечения
Логический режим ожидания можно использовать для значительного сокращения времени простоя, связанного с применением наборов исправлений и новых выпусков программного обеспечения. Логический резерв можно обновить до новой версии, а затем переключить, чтобы он стал активным основным. Это обеспечивает полную доступность, пока старый основной сервер преобразуется в логический резервный и применяется набор исправлений.
2.1.3 Резервные базы данных моментальных снимков
Снимок резервной базы данных — это тип обновляемой резервной базы данных, которая обеспечивает полную защиту данных для первичной базы данных. Резервная база данных моментального снимка получает и архивирует, но не применяет повторные данные из своей первичной базы данных. Данные повторного выполнения, полученные из базы данных-источника, применяются, когда резервная база данных моментального снимка преобразуется обратно в физическую резервную базу данных после отмены всех локальных обновлений резервной базы данных моментального снимка.
Снимок резервной базы данных обычно со временем отличается от основной базы данных, поскольку данные повторного выполнения из первичной базы данных не применяются по мере их получения. Локальные обновления резервной базы данных моментальных снимков вызовут дополнительные расхождения. Однако данные в базе данных-источнике полностью защищены, поскольку резервный моментальный снимок может быть преобразован обратно в физическую резервную базу данных в любое время, после чего будут применены данные повторного выполнения, полученные от основного.
Преимущества резервной базы данных моментальных снимков
Резервная база данных с моментальным снимком — это полностью обновляемая резервная база данных, обеспечивающая аварийное восстановление и защиту данных, аналогичные преимуществам физической резервной базы данных. Резервные базы данных с моментальными снимками лучше всего использовать в сценариях, когда преимущество временного обновляемого моментального снимка первичной базы данных оправдывает увеличение времени восстановления после сбоев основной базы данных.
Преимущества использования резервной базы данных моментальных снимков заключаются в следующем:
Он предоставляет точную копию рабочей базы данных для целей разработки и тестирования, обеспечивая постоянную защиту данных.
Его можно легко обновить, чтобы он содержал текущие производственные данные, путем преобразования в физический резерв и повторной синхронизации.
Возможность создать резервный моментальный снимок, протестировать его, повторно синхронизировать с рабочей средой, а затем снова создать резервный и тестовый моментальный снимок — это цикл, который можно повторять сколь угодно часто. Тот же процесс можно использовать для простого создания и регулярного обновления резервного снимка для отчетов, где требуется доступ для чтения/записи к данным.
2.2 Пользовательские интерфейсы для администрирования конфигураций Data Guard
Вы можете использовать следующие интерфейсы для настройки, реализации и управления конфигурацией Data Guard:
Управление предприятием Oracle
Enterprise Manager предоставляет графический интерфейс для брокера Data Guard, который автоматизирует многие задачи, связанные с созданием, настройкой и мониторингом среды Data Guard. См. Oracle Data Guard Broker и интерактивную справку Oracle Enterprise Manager для получения информации о графическом интерфейсе пользователя и его мастерах.
Интерфейс командной строки SQL*Plus
Некоторые операторы SQL*Plus используют ключевое слово STANDBY для указания операций с резервной базой данных. Другие операторы SQL не включают синтаксис, специфичный для резервной базы данных, но они полезны для выполнения операций с резервной базой данных. См. в главе 16 список соответствующих утверждений.
Для определения среды Data Guard используется несколько параметров инициализации. См. главу 14 для получения списка соответствующих параметров инициализации.
Интерфейс командной строки брокера Data Guard (DGMGRL)
Интерфейс командной строки DGMGRL является альтернативой использованию Oracle Enterprise Manager. Интерфейс командной строки DGMGRL удобен, если вы хотите использовать посредник для управления конфигурацией Data Guard из пакетных программ или сценариев. Полную информацию см. в разделе Oracle Data Guard Broker.
2.3 Требования к работе Data Guard
В следующих разделах описываются эксплуатационные требования для использования Data Guard:
2.3.1 Требования к оборудованию и операционной системе
Начиная с Oracle Database 11 g, Data Guard обеспечивает повышенную гибкость для конфигураций Data Guard, в которых основная и резервная системы могут иметь разные архитектуры ЦП, операционные системы (например, Windows и Linux), двоичные файлы операционных систем (32-разрядные /64-разрядная версия) или двоичные файлы базы данных Oracle (32-разрядная/64-разрядная версия).
В примечании 413484.1 обсуждается поддержка смешанных платформ и ограничения для физических резервных серверов.
В примечании 1085687.1 обсуждается поддержка смешанных платформ и ограничения для логических резервных серверов.
Один и тот же выпуск Oracle Database Enterprise Edition должен быть установлен в первичной базе данных и во всех резервных базах данных, за исключением случаев последовательного обновления базы данных с использованием логических резервных баз данных.
2.3.2 Требования к программному обеспечению Oracle
В следующем списке описаны требования к программному обеспечению Oracle для использования Data Guard:
Oracle Data Guard доступен только как функция Oracle Database Enterprise Edition. Он недоступен в Oracle Database Standard Edition.
Возможно смоделировать резервную среду базы данных с базами данных, работающими под управлением Oracle Database Standard Edition. Это можно сделать, вручную переместив архивные файлы журналов повторного выполнения с помощью утилиты копирования операционной системы или с помощью пользовательских сценариев, которые периодически отправляют архивные файлы журналов повторного выполнения из одной базы данных в другую. Следствием этого является то, что эта конфигурация не обеспечивает простоту использования, управляемость, производительность и возможности аварийного восстановления, доступные в Data Guard
С помощью Data Guard SQL Apply вы сможете выполнить последовательное обновление программного обеспечения базы данных Oracle с выпуска набора исправлений n (как минимум, это должен быть выпуск 10.1.0.3) до любого набора исправлений с более высокой версией или основной версии. Во время непрерывного обновления вы можете запускать различные выпуски базы данных Oracle в первичной и логической резервной базах данных, одновременно обновляя их. Для получения полной информации см. главу 12 "Использование SQL Apply для обновления базы данных Oracle" и файл ReadMe для соответствующего выпуска набора исправлений Oracle Database 10 g.
Параметр инициализации базы данных COMPATIBLE должен иметь одинаковое значение во всех базах данных в конфигурации Data Guard, за исключением случаев использования логической резервной базы данных, которая может иметь более высокий параметр COMPATIBLE, чем основная база данных.
Если вы в настоящее время используете Oracle Data Guard в программном обеспечении базы данных Oracle8 i, полную информацию об обновлении до Oracle Data Guard 11 g см. в Руководстве по обновлению базы данных Oracle.
Первичная база данных должна работать в режиме ARCHIVELOG. Дополнительную информацию см. в Руководстве администратора базы данных Oracle.
Основной базой данных может быть база данных с одним экземпляром или база данных Oracle Real Application Clusters (Oracle RAC). Резервные базы данных могут быть базами данных с одним экземпляром или базами данных Oracle RAC, и эти резервные базы данных могут представлять собой смесь физических, логических и моментальных снимков. Дополнительную информацию о настройке и использовании Oracle Data Guard с Oracle RAC см. в разделе Обзор Oracle Database High Availability.
Каждая основная база данных и резервная база данных должны иметь свой собственный управляющий файл.
Если резервная база данных расположена в той же системе, что и первичная база данных, архивные каталоги для резервной базы данных должны использовать другую структуру каталогов, чем первичная база данных. В противном случае резервная база данных может перезаписать файлы первичной базы данных.
Для защиты от незарегистрированных операций прямой записи в первичной базе данных, которые не могут быть распространены на резервную базу данных, включите FORCE LOGGING в первичной базе данных перед выполнением резервного копирования файлов данных для создания резервной базы данных. Держите базу данных в режиме FORCE LOGGING до тех пор, пока требуется резервная база данных.
Учетные записи пользователей, которые вы используете для управления первичным и резервным экземплярами баз данных, должны иметь системные привилегии SYSDBA.
Для простоты эксплуатации Oracle рекомендует при настройке Oracle Automatic Storage Management (Oracle ASM) и Oracle Managed Files (OMF) в конфигурации Data Guard симметрично устанавливать их в основной и резервной базе данных. То есть, если какая-либо база данных в конфигурации Data Guard использует Oracle ASM, OMF или оба, то каждая база данных в конфигурации должна использовать Oracle ASM, OMF или оба соответственно. Для получения дополнительной информации см. сценарий в Разделе 13.5.
Поскольку некоторые приложения, выполняющие обновления с использованием данных на основе времени, не могут обрабатывать данные, введенные из нескольких часовых поясов, рассмотрите возможность установки одного и того же часового пояса для основной и удаленной резервной систем, чтобы обеспечить сохранение хронологического порядка записей после обновления. переход роли.
2.4 Рекомендации по структуре каталога резервной базы данных
Структура каталогов различных резервных баз данных важна, поскольку она определяет пути к резервным файлам данных, архивным файлам журнала повторного выполнения и резервным файлам журнала повторного выполнения. Если возможно, файлы данных, файлы журналов и управляющие файлы в основной и резервной системах должны иметь одинаковые имена и пути и использовать соглашения об именовании оптимальной гибкой архитектуры (OFA). Архивные каталоги в резервной базе данных также должны быть одинаковыми на разных сайтах, включая размер и структуру. Эта стратегия позволяет другим операциям, таким как резервное копирование, переключение и отработка отказа, выполнять тот же набор шагов, что снижает сложность обслуживания.
Дополнительную информацию об оптимальной гибкой архитектуре (OFA) можно найти в документации Oracle по вашей операционной системе.
В противном случае необходимо задать параметры преобразования имени файла (как показано в таблице 2-1) или переименовать файл данных. Тем не менее, если вам нужно использовать систему с другой структурой каталогов или разместить резервную и первичную базы данных в одной системе, вы можете сделать это с минимальным дополнительным администрированием.
Три основных параметра конфигурации показаны на рис. 2-1. К ним относятся:
Резервная база данных в той же системе, что и основная база данных, которая использует структуру каталогов, отличную от основной системы. Это показано на рис. 2-1 как Standby1 .
Если у вас есть резервная база данных в той же системе, что и основная база данных, вы должны использовать другую структуру каталогов. В противном случае резервная база данных попытается перезаписать файлы первичной базы данных.
Резервная база данных в отдельной системе, которая использует ту же структуру каталогов, что и основная система. Это показано на рисунке 2-1 как Standby2. Это рекомендуемый метод.
Резервная база данных в отдельной системе, которая использует структуру каталогов, отличную от основной системы. Это показано на рис. 2-1 как Standby3 .
Если какая-либо база данных в конфигурации Data Guard использует Oracle ASM, OMF или оба, то каждая база данных в конфигурации должна использовать Oracle ASM, OMF или оба соответственно. В главе 13 описан сценарий, описывающий настройку OMF в конфигурации Data Guard.
Рис. 2-1 Возможные резервные конфигурации
Таблица 2-1 описывает возможные конфигурации первичной и резервной баз данных и последствия каждой из них.
Таблица 2-1 Расположение резервной базы данных и параметры каталога
То же, что и в основной системе
Отличается от основной системы (обязательно)
Вы можете либо вручную переименовать файлы, либо настроить параметры инициализации DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT в резервной базе данных, чтобы автоматически обновлять пути к файлам данных первичной базы данных и архивным файлам журнала повторного выполнения, а также резервным файлам журнала повторного выполнения в управляющем файле резервной базы данных. (См. Раздел 3.1.4.)
Резервная база данных не защищает от сбоев, которые разрушают систему, в которой находятся основная и резервная базы данных, но предоставляет возможность переключения для планового обслуживания.
То же, что и в основной системе
Вам не нужно переименовывать файлы первичной базы данных, архивные файлы журналов повторного выполнения и резервные файлы журналов повторного выполнения в управляющем файле резервной базы данных, хотя вы все равно можете сделать это, если хотите использовать новую схему именования (например, чтобы распространить файлы между разными дисками).
Размещая резервную базу данных на отдельном физическом носителе, вы защищаете данные в первичной базе данных от сбоев, которые разрушают основную систему.
Отличается от основной системы
Вы можете либо вручную переименовать файлы, либо настроить параметры инициализации DB_FILE_NAME_CONVERT и LOG_FILE_NAME_CONVERT в резервной базе данных для автоматического переименования файлов данных (см. Раздел 3.1.4).
Размещая резервную базу данных на отдельном физическом носителе, вы защищаете данные в первичной базе данных от сбоев, которые разрушают основную систему.
С дублированием 11gR2 rman очень легко создать резервную базу данных.
2.ПРАКТИКА
Информация SID первичной базы данных: PRIM Домен/IP-адрес основной базы данных: SID резервной базы данных ABSO: PRIM_SBY Домен/IP-адрес резервной базы данных: CROO
Поделиться:
Установка, настройка, мониторинг и деактивация Data Guard Broker
1.ЦЕЛЬ И ОБЛАСТЬ ПРИМЕНЕНИЯ
Установка программного обеспечения брокера Oracle Data Guard с программным обеспечением базы данных Oracle и файлом bin программы можно найти в папке $ORACLE_HOME/bin/dgmgrl.Преимущество dgmgrl заключается в том, что большинство действий с основной/резервной базой данных можно легко выполнить с помощью этого инструмента, особенно переключение и управление основной/резервной базой данных.
<р>2. ВАЖНОПри использовании брокера для обслуживания конфигурации Data Guard вы должны использовать либо интерфейс командной строки брокера «DGMGRL», либо Grid Control для внесения любых изменений в конфигурацию Data Guard. Если вы хотите использовать SQL*Plus, вам следует удалить конфигурацию Data Guard Broker с помощью команды REMOVE CONFIGURATION PRESERVE DESTINATIONS в DGMGRL. Затем вы должны установить для параметра DG_BROKER_START значение «FALSE» для всех баз данных в конфигурации.
Поделиться:
Установка логического резерва
1.ЦЕЛЬ И ОБЛАСТЬ ПРИМЕНЕНИЯ
В другой своей статье я объяснил установку физической резервной базы данных, и в этой статье мы собираемся преобразовать физическую резервную базу данных в логическую резервную базу данных.
2.ПРАКТИКА
<р>2.1. В первичной базе данных нам нужно выполнить запрос, чтобы увидеть, какие таблицы не поддерживаются логическим резервомПоделиться:
Дублировать komutuyla первичная база данных asm’inden non-asm резервная база данных kurulumu
1.AMAÇ VE KAPSAM
ASM kurulu bir veritabanına дублирует komutuyla non-ASM standby yaratmak.
2.УЙГУЛАМА
База данных Özellikleri
Имя базы данных: - bugra
Первичное_уникальное_имя_базы: bugra // ASM
Резервное_уникальное_имя: stdby // не-ASM
Первичное имя хоста: - bugra.localdomain / / 192.168.2.101
Имя резервного хоста: - stdby.localdomain // 192.168.2.102
2.1 Oluşturacağımız dosyalar için primaryde ve standbyda lokasyonları yaratıyoruz.
[Подробнее…]
Здесь будет построена физическая резервная установка. Наше предположение состоит в том, что первичная база данных уже запущена и работает нормально, а ORACLE_HOME также установлен на резервном сервере.
Пошаговое создание резервной базы данных Oracle database 12c вручную.
Ваша первичная база данных называется orcl, а имя резервной базы данных — stdby .
Здесь мы используем два терминала, терминал -1 используется для основной базы данных, а терминал-2 используется для резервной базы данных
<р>1. Подключиться как sysdba и включить режим FORCE LOGGING для базы данных.$ sqlplus / as sysdba
SQL> изменить принудительное ведение журнала базы данных;
Проверьте принудительное ведение журнала с помощью следующей команды
SQL> SELECT force_logging FROM v$database ;
<р>2. Настройте резервные журналы повторного выполнения в базе данных-источнике, проверьте, не включен ли OMF, и сначала включите его.SQL> изменить системный набор db_create_file_dest = '/disk1/ oradata / orcl ';
Чтобы проверить OMF
SQL> показать параметр db_create_file_dest
ИМЯ ТИП ЗНАЧЕНИЕ
db_create_file_dest строка /disk1/oradata/orcl
Настройте FRA, если он не установлен
SQL> изменить системный набор db_recovery_file_dest_size =5g;
SQL> изменить системный набор db_recovery_file_dest = '/disk3/ oradata / orcl / fra ';
Проверьте db_recovery_file_dest, используя следующий запрос
SQL> показать параметр db_recovery_file_dest
ИМЯ ТИП ЗНАЧЕНИЕ
db_recovery_file_dest строка /disk3/oradata/orcl/fra
SQL> изменить базу данных, добавить резервный файл журнала;
SQL> изменить базу данных, добавить резервный файл журнала;
Проверьте информацию в файле журнала
<р>3. Задайте параметры инициализации LOG_ARCHIVE_DEST_1 и LOG_ARCHIVE_DEST_2 для основной базы данных.SQL> изменить системный набор log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST';
SQL> изменить системный набор log_archive_dest_2='SERVICE= tns_stdby ASYNC VALID_FOR =( ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME= stdby ';
SQL> изменить системный набор log_archive_config =' dg_config =( prod,stdby )';
Проверьте приведенные выше параметры, используя следующий запрос
SQL> ПОКАЗАТЬ ПАРАМЕТР LOG_ARCHIVE_DEST
SQL> ПОКАЗАТЬ ПАРАМЕТР LOG_ARCHIVE_CONFIG
<р>4. Настройте режим ARCHIVELOG, если он не включен, выполните следующие шаги, чтобы включить его.SQL> список архивных журналов
Режим журнала базы данных Нет режима архива
Автоматическое архивирование отключено
Целевое расположение архива USE_DB_RECOVERY_FILE_DEST
Самая старая последовательность онлайн-журнала 563
Текущая последовательность журнала 564
SQL> НЕМЕДЛЕННОЕ ВЫКЛЮЧЕНИЕ
SQL> МОНТАЖ ПРИ ЗАПУСКЕ
SQL> ALTER ARCHIVELOG БАЗЫ ДАННЫХ;
SQL> ИЗМЕНИТЬ БАЗУ ДАННЫХ ОТКРЫТЬ;
<р>5. Запустите RMAN и сделайте полную резервную копию базы данных.RMAN> резервная копия базы данных плюс архивный журнал;
<р>6. Настройте LISTENER в резервной базе данных, войдя на резервный сервер.$ export ORACLE_SID= в режиме ожидания
(АДРЕС = (ПРОТОКОЛ = TCP)(ХОСТ = 192.168.11.48)(ПОРТ = 1531))
<р>7. Проверьте конфигурацию прослушивателя и запустите службу прослушивателя.$ lsnrctl start lis_stdby
<р>8. В основной системе баз данных создайте псевдоним tns для физической резервной базы данных.Добавьте приведенные ниже новые записи, в которых упоминаются сведения о хосте и порте резервной базы данных.
(АДРЕС = (ПРОТОКОЛ = TCP)( ХОСТ = 192.168.11.48)(ПОРТ = 1531))
<р>9. Проверьте правильность настройки записей tns .Теперь с основного сервера используйте команду tnsping и проверьте доступность прослушивателя.
<р>10. Скопируйте файл паролей основной базы данных в резервную систему базы данных.$ cd $ORACLE_HOME/dbs
$ cp orapworkcl orapwstdby
<р>11. На хосте первичной базы данных создайте PFILE и скопируйте его на резервный сервер как initstdby.ora в папку $ORACLE_HOME/dbs.$ sqlplus / as sysdba
SQL> создать pfile ='$HOME/initprod.ora' из spfile;
Скопируйте p-файл в папку Oracle по умолчанию $ORACLE_HOME/dbs
$ cp $HOME/initorcl.ora $ORACLE_HOME/dbs/initstdby.ora
<р>12. Отредактируйте файл initstdby.ora на резервном сервере.$ cd $ORACLE_HOME/dbs
-> удалить все записи параметров *.__
-> везде, где " orcl ", замените его на " stdby " для control_files , db_create_file_dest , db_recovery_file_dest , Diagnostic_dest
-> измените " stdby " на " orcl " для параметра log_archive_dest_2.
-> добавьте новые параметры снизу и сохраните файл.
’/disk2/oradata/orcl’,’/disk2/oradata/stdby’
’/disk2/oradata/orcl’,’/disk2/oradata/stdby’
<р>13. На резервном хосте создайте необходимые каталоги в /disk1, /disk2 и /disk3$ mkdir /disk1/oradata/stdby
$ mkdir /disk2/oradata/stdby
$ mkdir /disk3/oradata/stdby/fra
<р>14. Запустите экземпляр с только что обновленным файлом параметров.$ sqlplus / as sysdba
SQL> запуск nomount pfile ='$ORACLE_HOME/dbs/initstdby.ora ';
<р>15. На хосте первичной базы данных вызовите RMAN и подключитесь как SYSDBA к целевой базе данных и вспомогательной базе данных.$ rman target sys/вспомогательная система оракула/ [электронная почта защищена]_stdby
Выполнить скрипт для создания резервной базы данных
дублировать целевую базу данных для резервной из активной базы данных
spfile parameter_value_convert 'orcl','stdby' set db_unique_name ='stdby';
Проверка правильности работы физической резервной базы данных
<р>16. В резервной базе данных определите существующие архивные файлы журналов повторного выполнения. <р>17. Выполните переключение журнала в базе данных-источнике.$ sqlplus / as sysdba
SQL> изменить файл журнала переключения системы ;
SQL> изменить файл журнала переключения системы ;
<р>18. В физической резервной базе данных запустите Redo Apply.SQL> изменить базу данных, восстановить управляемую резервную базу данных, используя текущий файл журнала, отключиться;
Читайте также: