oracle data guard что это
Active Data Guard
Ensure high availability, data protection, and disaster recovery for enterprise data with Oracle Active Data Guard. Survive disasters and data corruption while creating, maintaining, and managing one or more synchronized standby databases.
Fully integrated into the Oracle Database, Data Guard and Active Data Guard’s architectural advantages provide superior data protection and availability for the Oracle Database compared to the increased risks of storage replication techniques.
Implement Oracle Data Guard best practices to achieve minimal downtime and zero data loss for unplanned outages.
Autonomous Data Guard provides a fully managed high-availability and disaster- recovery configuration across availability domains (ADs) with the simple click of a button or REST API call to enable it.
Active Data Guard Features
Key capabilities
Disaster recovery to multiple standby databases
Oracle Data Guard’s automation manages one or more synchronized copies of a live database—providing zero data loss in the case of an unexpected outage of the primary database.
In-memory database replication
In-memory redo replication ensures isolation from underlying corruption such as disk corruption and includes automatic comprehensive validation of replicated data blocks.
Flexible protection modes
Data Guard provides three different protection modes that allow data replication flexibility to balance data loss protection and performance.
Real-Time Query and DML Offload on Oracle Active Data Guard
Real-time query and data manipulation language uses the standby database for queries, reports, and occasional updates without impacting the primary database
Data protection
Fast-start failover (FSFO)
Fast-start failover allows the Oracle Data Guard broker to automatically failover to a standby database without the need for human intervention.
Automatic Block Repair
Provides automatic and user-transparent recovery of a corrupted database from the standby database.
Far Sync
Achieve zero data loss across any distance in the event of site failure—with no network latency.
Advanced features
Application Continuity
Masks outages from end-users and applications by recovering in-flight database transactions following recoverable outages.
Rolling database upgrades
Reduces downtime for database version upgrades without the complexity of adding extra software to the system.
Global Data Services (GDS)
Oracle Sharding
Oracle Sharding maximizes the ability to horizontally partition and distribute data geographically, providing greatly enhanced scalability and fault isolation.
Data Guard customer successes
Oracle Data Guard offers data protection and availability across data centers or the cloud.
Epsilon improves availability and security with Oracle
Data Guard use cases
Complete data protection and disaster recovery
Automates the management of synchronized copies of a live database and is included with Oracle Database Enterprise Edition.
Automatic role transitions to maintain business continuity
Failover automation ensures a seamless transition from the primary database to a synchronized standby database in cases of failure, while ensuring database availability by replaying uncommitted in-flight transactions.
Minimize downtime for upgrades
Full upgrade automation with minimal downtime via rolling database version upgrades without the complexity of adding extra software to the system.
Zero data loss at any distance
Zero data loss is achieved when utilizing Far Sync even over configurations where the primary and standby databases are distributed over long geographical distances without risking application performance.
Русские Блоги
Принцип Oracle Dataguard, данные Oracle в режиме реального времени
Принципы Oracle Dataguard
DataGuard может обеспечить избыточность, защиту данных, восстановление после сбоев и т. Д. Базы данных Oracle для быстрого переключения баз данных и аварийного восстановления. При обеспечении «транзакционной согласованности» рабочей базы данных используйте физическую полную резервную копию рабочей библиотеки для создания резервной базы данных. Резервная база данных будет автоматически поддерживать резервную базу данных посредством архивных журналов или записей повторов, переданных из рабочей базы данных.
Технология синхронизации данных DataGuard имеет следующие преимущества:
1) Встроенные функции базы данных Oracle полностью совместимы с новыми функциями каждой новой версии Oracle, и нет необходимости доплачивать.
2) Управление конфигурацией является относительно простым и не требует знакомства с другими сторонними программными продуктами.
3) Физическая резервная база данных поддерживает любые типы объектов данных и типов данных;
4) База данных логического резерва открыта, и вы можете выполнять запросы и другие операции, поддерживая синхронизацию данных.
5) В режиме максимальной защиты он может обеспечить нулевую потерю данных.
Oracle DataGuard состоит из первичной базы данных (производственной базы данных) и одной или нескольких резервных баз данных (до 9). Базы данных, составляющие Data Guard, связаны через Oracle Net и могут быть распределены в разных регионах. Пока библиотеки могут общаться друг с другом, их физическое местоположение не ограничено и не ограничено операционной системой.
1. Основная база данных
DataGuard содержит первичную базу данных, которая является производственной базой данных, к которой имеет доступ большинство приложений. База данных может быть либо базой данных одного экземпляра, либо RAC.
2. Резервная база данных
2. Резервный тип базы данных
Резервная база данных обычно делится на две категории: логический резерв и физический резерв. Логический режим ожидания
Логическим резервом является получение журнала повторов первичной базы данных и преобразование его в оператор SQL, а затем выполнение оператора SQL в резервной базе данных для достижения синхронизации. Физический режим ожидания
Физический режим ожидания синхронизируется с помощью восстановления носителя путем получения и применения журнала повторов основной базы данных.Только не только физическая структура файла одинакова, но и место хранения блока на диске точно такое же.
Повторить транспортные услуги
Управляйте передачей данных повтора одному или нескольким местам архивирования. Службы регистрации приложений
Примените данные повтора к резервной базе данных, чтобы обеспечить соответствие транзакции основной базе данных. Данные повтора могут быть прочитаны из файла архива резервной базы данных, или они могут быть прочитаны непосредственно с помощью файла журнала ожидания. Ролевые переходы
В DataGuard есть две роли: основная и резервная. Переключение ролей позволяет базе данных переключаться между этими двумя ролями. Существует два типа переключения: переключение и отработка отказа.
1) Переключение: преобразование основной базы данных и резервной базы данных. Переключение может гарантировать, что никакие данные не будут потеряны.
2) аварийное переключение: при сбое первичной базы данных, который не может быть восстановлен вовремя, будет вызвано аварийное переключение для преобразования резервной базы данных в новую первичную базу данных. В режиме максимальной защиты или режиме максимальной доступности аварийное переключение может гарантировать, что данные не будут потеряны.
1. Максимальная защита
Этот режим является режимом защиты данных по умолчанию, предоставляя максимально возможное число без ущерба для производительности исходной базы данных.
2. Максимальная доступность
Эта модель в основном похожа на «максимальную защиту». В нормальных условиях основная и резервная базы данных синхронизируются.
Если есть проблема с сетью или резервной базой данных, это не повлияет на сбой основной библиотеки. Основная библиотека автоматически переключит библиотеку в режим «максимальной производительности». Когда резервная база данных будет доступна, архив будет перенесен в резервную базу данных для восстановления.
3. Максимальная производительность
Этот режим обеспечивает максимальную производительность основной библиотеки, а данные передаются асинхронно между основной и резервной библиотеками. То есть активные и резервные журналы архивируются в
Будет переведен в резервную библиотеку
1. DATAGUARD принцип
DATAGUARD устанавливает свои эталонные отношения путем создания группы PRIMARY and STANDBY.
После создания STANDBY DATAGUARD передает REDO основной базы данных (PRIMARY) в базу данных STANDBY, а затем применяет REDO в STANDBY для достижения синхронизации базы данных.
Существует два типа STANDBY: физическое STANDBY и логическое STANDBY
Физическая STANDBY предоставляет точно такую же копию (блок-блок), что и основная база данных, а база данных SCHEMA, включая индексы, одинакова. Непосредственно применяется REDO для достижения синхронизации.
Это не относится к логическому STANDBY. В логическом STANDBY логическая информация одна и та же, но физическая организация и структура данных могут отличаться. Метод для синхронизации с основной библиотекой заключается в преобразовании полученного REDO в оператор SQL и последующем выполнении SQL в STANDBY. Утверждение. Помимо аварийного восстановления, логика STANDBY может использоваться и в других целях, например, для запросов и отчетов пользователей.
DATAGUARD содержит три службы (передача журнала, приложение журнала, преобразование роли)
Служба обработки журналов автоматически применяет журналы с одной стороны, а с другой стороны автоматически обнаруживает REDO, которого отсутствует STANDBY, и автоматически запрашивает отсутствующее REDO из основной базы данных или другого STANDBY.
Несколько режимов защиты DATAGUARD: максимальная защита, максимальная доступность, максимальная производительность
Максимальная защита означает, что если REDO не доступен хотя бы в одном STANDBY, транзакция не может быть зафиксирована. Если он недоступен в STANDBY, работа основной базы данных останавливается. Обычно есть больше ограничений, и это не очень часто используется в производственных средах (не хорошие показатели эффективности затрат).
Максимальная доступность означает, что если STANDBY недоступен, основная база данных по-прежнему может обрабатывать транзакции, но после устранения проблемы STANDBY и основная база данных повторно синхронизируются. Такая проблема заключается в том, что когда перед ресинхронизацией возникает FAILOVER, некоторые данные могут быть потеряны.
Максимальная производительность означает, что операция фиксации основной базы данных не ожидает STANDBY. PRIMARY и STANDBY слабо связаны, а уровень защиты данных низкий.
Возможные режимы физического РЕЖИМА ОЖИДАНИЯ: режим только для чтения (ОТКРЫТО ЧИТАТЬ) и режим восстановления (ИЗМЕНЕННОЕ ВОССТАНОВЛЕНИЕ)
2. Физическая реализация DATAGUARD краткий процесс
Подготовка основной базы данных: FORCE LOGGING, ENABLE ARCHIVING, локальный архив назначения.
Создать базу данных STANDBY:
А. Закройте основную библиотеку, выполните холодное резервное копирование файлов данных основной библиотеки, файлов журналов и файлов паролей, а затем запустите основную библиотеку, создайте управляющий файл STANDBY в главной библиотеке: измените базу данных, создайте резервный файл управления как «имя файла»
б) Подготовьте файл параметров, скопируйте файл параметров, резервный файл основной библиотеки и управляющий файл STANDBY в систему STANDBY.
c) Если это система WINDOWS, вам необходимо создать службу WINDOWS.
г. Настроить tnsnames.ora на обеих машинах, оба могут tnsping
д. Настроить мониторинг в главной библиотеке и библиотеке STANDBY
е. Использовать обнаружение обрыва соединения в системе STANDBY: установите sqlnet.expire_time = 2 в sqlnet.ora
г. Создайте SPFILE в STANDBY
alter database mount standby database
I. Инициализировать журнал приложения службы
alter database recover managed standby database disconnect from session;
3. DATAGUARD обслуживание
Служба доставки журналов
В некоторых случаях может потребоваться интервал времени между архивным журналом и журналом приложения.В этом случае вы можете указать атрибут delay = minutes в параметре log_archive_dest_n в STANDBY.
Способы увеличения файлов журнала STANDBY:
Добавьте метод STANDBY для группы журналов:
alter database add standby группа 10 файлов журнала («имя файла 1», «имя файла 2») размер 100M Для нескольких мест назначения общего файла журнала STANDBY с общим архивом в некоторых случаях необходимо указать атрибут зависимости параметра log_archive_dest_n, роль этого атрибута заключается в объяснении Место назначения зависит от успешного архивирования родительского места назначения.
Параметр log_archive_dest_n также может указывать атрибуты reopen, max_failures, sync, async. Указав атрибут LGWR или ARCH для этого параметра, выберите, использовать ли процесс LGWR или ARCH для передачи журналов.
Несколько процессов, используемых для приема журнала: LGWR, ARCH, RFS, FAL. Процесс FAL используется для устранения пробелов в журнале.
Инструкция для установки режима защиты данных: изменить базу данных установить резервную базу данных на максимальную (защита | доступность | производительность)
б) Журнал приложений
Для физического STANDBY служба приложения журнала включает в себя следующие процессы: RFS, ARC, MRP. MRP должен управлять процессом восстановления.
Несколько команд для запуска операции восстановления STANDBY: изменение базы данных для восстановления управляемой резервной базы данных (запуск сеанса переднего плана), изменение восстановления базы данных для управляемой резервной базы данных, отключение от сеанса (запуск фонового сеанса, что означает, что сеанс может продолжать выполнять другие действия), изменение базы данных восстановить управляемую резервную базу данных, отменить (остановить журнал приложений).
c) управление файлами данных
Когда основная библиотека заново создает файл данных, вы можете определить параметр standby_file_management как auto, чтобы резервный также автоматически создавал файл данных. Если структура каталогов основной библиотеки и файлов резервных данных отличается, вы можете установить db_file_name_convert для преобразования имени файла в основной библиотеке в имя файла в резервном файле. Если для standby_file_management установлено значение auto, вы не можете переименовывать или создавать файлы данных и файлы журналов в режиме ожидания.
Каждую минуту основная библиотека будет спрашивать, есть ли разрыв в режиме ожидания. Это называется сердцебиением.
Вы можете установить параметр log_archive_trace для отслеживания архивов на разных уровнях.
ORACLE поддерживает две формы переключения и переключения ролей и отработки отказа
Переключение содержит два этапа: сначала основная библиотека преобразуется в STANDBY, затем STANDBY преобразуется в основную библиотеку.
Подготовка к аварийному переключению: параметры, которые необходимо изменить для завершения перехода роли (необходимо изменить log_archive_dest_n и log_archive_dest_state_n для всех STANDBY), убедитесь, что основная библиотека и все STANDBY подключены, для среды RAC убедитесь, что активен только один экземпляр, если должны выполняться операции аварийного переключения STANDBY в данный момент работает в режиме максимальной защиты, его следует преобразовать в режим максимальной производительности (команда ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;)
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
Отмените операцию восстановления: ОТМЕНА БАЗЫ ДАННЫХ УПРАВЛЕНИЯ ЗАПИСЬЮ БАЗЫ ДАННЫХ ALTER DATABASE;
г. Пусть режим ожидания работает в режиме только для чтения
Запустите STANDBY в режиме только для чтения:
ALTER DATABASE MOUNT STANDBY DATABASE;
ALTER DATABASE OPEN READ ONLY;
Переведите STANDBY в режим восстановления в режим только для чтения:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE OPEN READ ONLY;
ч. Переведите STANDBY из режима READ ONLY в режим восстановления.
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
I. Проблемы, на которые следует обратить внимание при выполнении операции сортировки для STANDBY в режиме только для чтения:
Операции сортировки не могут использовать невременные табличные пространства. Временные табличные пространства должны управляться локально и содержать только временные файлы
Если основная библиотека не имеет временного табличного пространства при создании STANDBY, необходимо создать временное табличное пространство в главной библиотеке и выполнить команду ALTER SYSTEM SWITCH LOGFILE; передать команду redo в STANDBY. Если вы хотите добавить временный файл во временное табличное пространство STANDBY, вам необходимо сначала преобразовать STANDBY в режим READ ONLY и выполнить команду ALTER TABLESPACE temp1 ADD TEMPFILE ‘/ disk1 / oracle / dbs / s_temp1.dbf’ SIZE 10M REUSE; увеличить временный файл.
к. Вы можете создать резервную копию базы данных, сделав резервную копию STANDBY.
к. Операции с основной библиотекой и ответ STANDBY:
Если вы выполняете команду ALTER DATABASE CLEAR UNARCHIVED LOGFILE или используете RESETLOGS при открытии базы данных, вы должны заново создать STANDBY.
Если вы выполняете команду ALTER DATABASE ENABLE | DISABLE в основной библиотеке, если вы изменяете состояние табличного пространства, если для параметра STANDBY_FILE_MANAGEMENT установлено значение AUTO и создается табличное пространство или увеличивается файл данных, вам не нужно использовать STANDBY.
Если вы удалите табличное пространство или файл данных в основной библиотеке, вам необходимо удалить соответствующий файл данных в операционной системе после приложения журнала STANDBY.
Если вы переименуете файл данных в основной библиотеке, вам также придется переименовать его в STANDBY (поскольку это изменение контрольного файла, поэтому журнал не передается, поэтому обе стороны должны выполнить одну и ту же операцию)
Если вы измените контрольный файл в основной библиотеке, вам придется заново создать контрольный файл STANDBY или перестроить базу данных STANDBY.
Если вы добавляете или удаляете файлы журналов в основной библиотеке, вам также необходимо внести изменения в STANDBY.
Конкретный метод: сначала отмените восстановление, если STANDBY_FILE_MANAGEMENT имеет значение AUTO, затем измените на MANUAL, затем используйте команду ALTER DATABASE ADD STANDBY LOGFILE’prmy3.log ‘SIZE 100K; увеличьте файл журнала или используйте команду ALTER DATABASE DROP STANDBY LOGFILE’prmy3.log’ Удалите файл журнала и, наконец, восстановите значение параметра STANDBY_FILE_MANAGEMENT.
Если вы выполнили такие операции, как nologging | невосстановимые в основной библиотеке, вам следует скопировать табличное пространство, содержащее эти изменения, в STANDBY.
Если вы измените файл параметров основной библиотеки, то вам также следует изменить файл параметров STANDBY.
л. процесс мониторинга
SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
м. Контролировать ход операции восстановления
SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# FROM V$ARCHIVE_DEST_STATUS;
1 Introduction to Oracle Data Guard
Oracle D ata Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions. Data Guard maintains these standby databases as transactionally consistent copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.
With Data Guard, administrators can optionally improve production database performance by offloading resource-intensive backup and reporting operations to standby systems.
This chapter includes the following topics that describe the highlights of Oracle Data Guard:
1.1 Data Guard Configurations
A D ata Guard configuration consists of one production database and one or more standby databases. The databases in a Data Guard configuration are connected by Oracle Net and may be dispersed geographically. There are no restrictions on where the databases are located, provided they can communicate with each other. For example, you can have a standby database on the same system as the production database, along with two standby databases on other systems at remote locations.
You can manage primary and standby databases using the SQL command-line interfaces or the Data Guard broker interfaces, including a command-line interface (DGMGRL) and a graphical user interface that is integrated in Oracle Enterprise Manager.
1.1.1 P rimary Database
A Data Guard configuration contains one production database, also referred to as the primary database, that functions in the primary role. This is the database that is accessed by most of your applications.
The primary database can be either a single-instance Oracle database or an Oracle R eal Application Clusters database.
1.1.2 S tandby Databases
A s tandby database is a transactionally consistent copy of the primary database. Using a b ackup copy of the primary database, you can create up to nine standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database.
Similar to a primary database, a standby database can be either a single-instance Oracle database or an Oracle Real Application Clusters database.
A standby database can be either a physical standby database or a logical standby database:
Physical standby database
Provides a physically identical copy of the primary database, with on disk database structures that are identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. A physical standby database is kept synchronized with the primary database, though Redo Apply, which recovers the redo data received from the primary database and applies the redo to the physical standby database.
A physical standby database can be used for business purposes other than disaster recovery on a limited basis.
Logical standby database
Contains the same logical information as the production database, although the physical organization and structure of the data can be different. The logical standby database is kept synchronized with the primary database though SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executing the SQL statements on the standby database.
A logical standby database can be used for other business purposes in addition to disaster recovery requirements. This allows users to access a logical standby database for queries and reporting purposes at any time. Also, using a logical standby database, you can upgrade Oracle Database software and patch sets with almost no downtime. Thus, a logical standby database can be used concurrently for data protection, reporting, and database upgrades.
1.1.3 Configuration Example
Figure 1-1 shows a typical Data Guard configuration that contains a primary database that transmits redo data to a standby database. The standby database is remotely located from the primary database for disaster recovery and backup operations. You can configure the standby database at the same location as the primary database. However, for disaster recovery purposes, Oracle recommends you configure standby databases at remote locations.
Figure 1-1 shows a t ypical Data Guard configuration in which redo is being applied out of standby redo log files to a standby database.
Figure 1-1 Typical Data Guard Configuration
Description of «Figure 1-1 Typical Data Guard Configuration»
1.2 Data Guard Services
The following sections explain how Data Guard manages the transmission of redo data, the application of redo data, and changes to the database roles:
Control the automated transfer of redo data from the production database to one or more archival destinations.
Apply redo data on the standby database to maintain transactional synchronization with the primary database. Redo data can be applied either from archived redo log files, or, if real-time apply is enabled, directly from the standby redo log files as they are being filled, without requiring the redo data to be archived first at the standby database.
Change the role of a database from a standby database to a primary database, or from a primary database to a standby database using either a switchover or a failover operation.
1.2.1 Redo Transport Services
Redo transport services control the automated transfer of redo data from the production database to one or more archival destinations.
Redo transport services perform the following tasks:
Transmit redo data from the primary system to the standby systems in the configuration
Manage the process of resolving any gaps in the archived redo log files due to a network failure
Enforce the database protection modes (described in Section 1.4)
A utomatically detect missing or corrupted archived redo log files on a standby system and automatically retrieve replacement archived redo log files from the primary database or another standby database
1.2.2 Log Apply Services
The redo data transmitted from the primary database is written on the standby system into standby redo log files, if configured, and then archived into archived redo log files. Log apply services automatically apply the redo data on the standby database to maintain consistency with the primary database. It also allows read-only access to the data.
The main difference between physical and logical standby databases is the manner in which log apply services apply the archived redo data:
F or physical standby databases, Data Guard uses Redo Apply technology, which applies redo data on the standby database using standard recovery techniques of an Oracle database, as shown in Figure 1-2.
Figure 1-2 Automatic Updating of a Physical Standby Database
Description of «Figure 1-2 Automatic Updating of a Physical Standby Database »
F or logical standby databases, Data Guard uses SQL Apply technology, which first transforms the received redo data into SQL statements and then executes the generated SQL statements on the logical standby database, as shown in Figure 1-3.
Figure 1-3 Automatic Updating of a Logical Standby Database
Description of «Figure 1-3 Automatic Updating of a Logical Standby Database»
1.2.3 Role Transitions
An Oracle database operates in one of two roles: primary or standby. Using Data Guard, you can change the role of a database using either a switchover or a failover operation.
A switchover is a role reversal between the primary database and one of its standby databases. A switchover ensures no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role. The transition occurs without having to re-create either database.
A failover is when the primary database is unavailable. Failover is performed only in the event of a catastrophic failure of the primary database, and the failover results in a transition of a standby database to the primary role. The database administrator can configure Data Guard to e nsure no data loss.
The role transitions described in this documentation are invoked m anually using SQL statements. You can also use the Oracle Data Guard broker to simplify role transitions and automate failovers using Oracle Enterprise Manager or the DGMGRL command-line interface, as described in Section 1.3.
1.3 Data Guard Broker
The Data Guard broker is a distributed management framework that automates the creation, maintenance, and monitoring of Data Guard configurations. You can use either the Oracle Enterprise Manager graphical user interface (GUI) or the Data Guard command-line interface (DGMGRL) to:
Create and enable Data Guard configurations, including setting up redo transport services and log apply services
Manage an entire Data Guard configuration from any system in the configuration
Manage and monitor Data Guard configurations that contain Real Application Clusters primary or standby databases
Simplify switchovers and failovers by allowing you to invoke them using either a single key click in Oracle Enterprise Manager or a single command in the DGMGRL command-line interface.
Enable fast-start failover to fail over automatically when the primary database becomes unavailable. When fast-start failover is enabled, the Data Guard broker determines if a failover is necessary and initiates the failover to the specified target standby database automatically, with no need for DBA intervention and with no loss of data.
In addition, Oracle Enterprise Manager automates and simplifies:
Creating a physical or logical standby database from a backup copy of the primary database
Adding new or existing standby databases to an existing Data Guard configuration
Monitoring log apply rates, capturing diagnostic information, and detecting problems quickly with centralized monitoring, testing, and performance tools
1.3.1 Using Oracle Enterprise Manager
Oracle Enterprise Manager, also referred to as Enterprise Manager, provides a web-based interface for viewing, monitoring, and administering primary and standby databases in a Data Guard configuration. Enterprise Manager’s easy-to-use interfaces combined with the broker’s centralized management and monitoring of the Data Guard configuration enhance the Data Guard solution for high availability, site protection, and data protection of an enterprise.
From the Enterprise Manager Central Console, all management operations can be performed locally or remotely. You can view home pages for Oracle databases, including primary and standby databases and instances, create or add existing standby databases, start and stop instances, monitor instance performance, view events, schedule jobs, and perform backup and recovery operations. See Oracle Data Guard Broker and the Oracle Enterprise Manager online help system.
Figure 1-4 shows the Data Guard management overview page in Enterprise Manager.
Figure 1-4 Data Guard Overview Page in Oracle Enterprise Manager
Description of «Figure 1-4 Data Guard Overview Page in Oracle Enterprise Manager»
1.3.2 Using the Data Guard Command-Line Interface
The Data Guard command-line interface (DGMGRL) enables you to control and monitor a Data Guard configuration from the DGMGRL prompt or within scripts. You can perform most of the activities required to manage and monitor the databases in the configuration using DGMGRL. See Oracle Data Guard Broker for complete DGMGRL reference information and examples.
1.4 D ata Guard Protection Modes
In some situations, a business cannot afford to lose data. In other situations, the availability of the database may be more important than the loss of data. Some applications require maximum database performance and can tolerate some small amount of data loss. The following descriptions summarize the three distinct modes of data protection.
Maximum protection This protection mode ensures that no data loss will occur if the primary database fails. To provide this level of protection, the redo data needed to recover each transaction must be written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits. To ensure data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to the standby redo log of at least one transactionally consistent standby database.
Maximum availability This protection mode provides the highest level of data protection that is possible without compromising the availability of the primary database. Like maximum protection mode, a transaction will not commit until the redo needed to recover that transaction is written to the local online redo log and to the standby redo log of at least one transactionally consistent standby database. Unlike maximum protection mode, the primary database does not shut down if a fault prevents it from writing its redo stream to a remote standby redo log. Instead, the primary database operates in maximum performance mode until the fault is corrected, and all gaps in redo log files are resolved. When all gaps are resolved, the primary database automatically resumes operating in maximum availability mode.
This mode ensures that no data loss will occur if the primary database fails, but only if a second fault does not prevent a complete set of redo data from being sent from the primary database to at least one standby database.
Maximum performance This protection mode (the default) provides the highest level of data protection that is possible without affecting the performance of the primary database. This is accomplished by allowing a transaction to commit as soon as the redo data needed to recover that transaction is written to the local online redo log. The primary database’s redo data stream is also written to at least one standby database, but that redo stream is written asynchronously with respect to the transactions that create the redo data.
When network links with sufficient bandwidth are used, this mode provides a level of data protection that approaches that of maximum availability mode with minimal impact on primary database performance.
The maximum protection and maximum availability modes require that standby redo log files are configured on at least one standby database in the configuration. All three protection modes require that specific log transport attributes be specified on the LOG_ARCHIVE_DEST_ n initialization parameter to send redo data to at least one standby database. See Section 5.6 for complete information about the data protection modes.
1.5 Data Guard and Complementary Technologies
Oracle Database provides several unique technologies that complement Data Guard to help keep business critical systems running with greater levels of availability and data protection than when using any one solution by itself. The following list summarizes some Oracle high-availability technologies:
Oracle Real Application Clusters (RAC)
RAC enables multiple independent servers that are linked by an interconnect to share access to an Oracle database, providing high availability, scalability, and redundancy during failures. RAC and Data Guard together provide the benefits of both system-level, site-level, and data-level protection, resulting in high levels of availability and disaster recovery without loss of data:
RAC addresses system failures by providing rapid and automatic recovery from failures, such as node failures and instance crashes. It also provides increased scalability for applications.
Data Guard addresses site failures and data protection through transactionally consistent primary and standby databases that do not share disks, enabling recovery from site disasters and data corruption.
Many different architectures using RAC and Data Guard are possible depending on the use of local and remote sites and the use of nodes and a combination of logical and physical standby databases. See Appendix D, «Data Guard and Real Application Clusters» and Oracle Database High Availability Overview for RAC and Data Guard integration.
The Flashback Database feature provides fast recovery from logical data corruption and user errors. By allowing you to flash back in time, previous versions of business information that might have been erroneously changed or deleted can be accessed once again. This feature:
Eliminates the need to restore a backup and roll forward changes up to the time of the error or corruption. Instead, Flashback Database can roll back an Oracle database to a previous point-in-time, without restoring datafiles.
Provides an alternative to delaying the application of redo to protect against user errors or logical corruptions. Therefore, standby databases can be more closely synchronized with the primary database, thus reducing failover and switchover times.
Avoids the need to completely re-create the original primary database after a failover. The failed primary database can be flashed back to a point in time before the failover and converted to be a standby database for the new primary database.
See Oracle Database Backup and Recovery Advanced User’s Guide for information about Flashback Database, and Section 6.2.2 for information delaying the application of redo data.
Recovery Manager (RMAN)
RMAN is an Oracle utility that simplifies backing up, restoring, and recovering database files. Like Data Guard, RMAN is a feature of the Oracle database and does not require separate installation. Data Guard is well integrated with RMAN, allowing you to:
Use the Recovery Manager DUPLICATE command to create a standby database from backups of your primary database.
Take backups on a physical standby database instead of the production database, relieving the load on the production database and enabling efficient use of system resources on the standby site. Moreover, backups can be taken while the physical standby database is applying redo.
Help manage archived redo log files by automatically deleting the archived redo log files used for input after performing a backup.
1.6 Summary of Data Guard Benefits
Data Guard offers these benefits:
Disaster recovery, data protection, and high availability
Data Guard provides an efficient and comprehensive disaster recovery and high availability solution. Easy-to-manage switchover and failover capabilities allow role reversals between primary and standby databases, minimizing the downtime of the primary database for planned and unplanned outages.
Complete data protection
Data Guard can ensure no data loss, even in the face of unforeseen disasters. A standby database provides a safeguard against data corruption and user errors. Storage level physical corruptions on the primary database do not propagate to the standby database. Similarly, logical corruptions or user errors that cause the primary database to be permanently damaged can be resolved. Finally, the redo data is validated when it is applied to the standby database.
Efficient use of system resources
The standby database tables that are updated with redo data received from the primary database can be used for other tasks such as backups, reporting, summations, and queries, thereby reducing the primary database workload necessary to perform these tasks, saving valuable CPU and I/O cycles. With a logical standby database, users can perform normal data manipulation on tables in schemas that are not updated from the primary database. A logical standby database can remain open while the tables are updated from the primary database, and the tables are simultaneously available for read-only access. Finally, additional indexes and materialized views can be created on the maintained tables for better query performance and to suit specific business requirements.
Flexibility in data protection to balance availability against performance requirements
Oracle Data Guard offers maximum protection, maximum availability, and maximum performance modes to help enterprises balance data availability against system performance requirements.
A utomatic gap detection and resolution
If connectivity is lost between the primary and one or more standby databases (for example, due to network problems), redo data being generated on the primary database cannot be sent to those standby databases. Once a connection is reestablished, the missing archived redo log files (referred to as a gap) are automatically detected by Data Guard, which then automatically transmits the missing archived redo log files to the standby databases. The standby databases are synchronized with the primary database, without manual intervention by the DBA.
Centralized and simple management
The Data Guard broker provides a graphical user interface and a command-line interface to automate management and operational tasks across multiple databases in a Data Guard configuration. The broker also monitors all of the systems within a single Data Guard configuration.
Integration with Oracle Database
Data Guard is a feature of Oracle Database Enterprise Edition and does not require separate installation.
Automatic role transitions
When fast-start failover is enabled, the Data Guard broker automatically fails over to a synchronized standby site in the event of a disaster at the primary site, requiring no intervention by the DBA. In addition, applications are automatically notified of the role transition.