Oracle Data Guard AFR v1.1

Oracle Data Guard Ángel Freire R. Oracle Consultant 11-09-2014

High Availability

avanttic

Consultoría tecnológica

High Availability Features

avanttic

1.

Confidence

2.

Recoverability

3.

Detecting errors in real time

4.

Continuity of Operations

Consultoría tecnológica

Analysis of High Availability

avanttic

1.

Business Impact Analysis

2.

The cost of Downtime

3.

Recovery Time Objective (RTO)

4.

Recovery Point Objective (RPO)

5.

Total Cost of Ownership (TCO)

6.

Return on Investment (ROI)

Consultoría tecnológica

High Availability Systems

avanttic

1.

Layer 1 (Billing, Sales)

2.

Layer 2 (Purchasing, Inventory)

3.

Layer 3 (BI)

Consultoría tecnológica

Cost and High Availability

avanttic

1.

Maximum tolerated stop.

2.

Maximum frequency of stops tolerated.

3.

Easily quantifiable costs (sales, inactive employees, contractual penalties)

4.

Difficult to quantify costs (Legal Proceedings)

5.

Unquantifiable costs (negative publicity, angry customers)

Consultoría tecnológica

Implementing High Availability

avanttic

Consultoría tecnológica

Oracle High Availability Solutions • • • • • • • • • • • • • • • • • • • avanttic

Fast-Start Fault Recovery Oracle Restart Oracle Real Application Clusters and Oracle Clusterware Oracle RAC One Node Oracle Data Guard Oracle GoldenGate and Oracle Streams Oracle Flashback Technology Oracle Automatic Storage Management Fast Recovery Area Recovery Manager Data Recovery Advisor Oracle Secure Backup Oracle Security Features LogMiner Oracle Exadata Storage Server Software (Exadata Cell) Oracle Exadata Database Machine Oracle Database File System (DBFS) Client Failover Automatic Block Repair Corruption Prevention, Detection, and Repair

Consultoría tecnológica

Planned outages • • • • • • • • • • • • • • • • •

avanttic

Operating system and hardware upgrades -> Oracle RAC Oracle Database patches -> Oracle RAC Oracle Grid Infrastructure upgrades and patches -> Oracle RAC Storage Migration -> Oracle ASM Migrating to Exadata Storage -> Oracle MAA best practices Upgrading Exadata Storage -> Exadata Patch Manager Migrating a single-instance database to Oracle RAC -> Oracle Grid Infrastructure Migrating to Oracle ASM -> Oracle Data Guard Migrating a single-instance database to Oracle RAC -> Oracle Data Guard Patch set and database upgrades -> Oracle Data Guard using SQL Apply Oracle interim patches, Oracle clusterware upgrades and patches, Oracle ASM upgrades Operating System and Hardware Upgrades -> Oracle Data Guard Standby-First Patch Apply Migration across Windows and Linux -> Oracle Data Guard Platform migration across the same endian format platforms -> Transportable database Platform migration across different endian format platforms -> Transportable tablespace Patch set and database upgrades, platform migration, rolling upgrades, and when different character sets are required -> Oracle GoldenGate and Oracle Streams Application upgrades -> Online Application Maintenance and Upgrades

Consultoría tecnológica

No Planned outages

avanttic

•

Site Failures -> Oracle Data Guard

•

Site Failures -> Oracle GoldenGate and Oracle

•

Streams Site Failures -> Recovery Manager

• • • •

Computer Failures -> Oracle Real Application Clusters and Oracle Clusterware

•

Computer Failures -> Oracle GoldenGate and Oracle

•

Streams Storage Failures -> Oracle Automatic Storage

•

Management Storage Failures -> Oracle Data Guard

•

Storage Failures -> RMAN with Fast Recovery Area and Oracle Secure Backup

•

Storage Failures -> Oracle GoldenGate and Oracle Streams

•

Data Corruption -> Oracle Exadata Storage Server Software (Exadata Cell) and Oracle ASM Data

•

Corruption -> Corruption Prevention, Detection, and Repair

•

Data Corruption -> Data Recovery Advisor and RMAN with Fast Recovery Area

•

Data Corruption -> Oracle Data Guard

Computer Failures -> Oracle RAC One Node Computer Failures -> Fast-Start Fault Recovery Computer Failures -> Oracle Data Guard

Consultoría tecnológica

No Planned outages

avanttic

•

Data Corruption -> Oracle GoldenGate and Oracle Streams

•

Human Errors -> Oracle Security

•

Features Human Errors -> Oracle

• • • •

Flashback Technology Human Errors ->

•

Hangs or slow down - Oracle Database and Oracle Enterprise Manager

LogMiner Lost writes -> Oracle Data Guard, RMAN, DB_LOST_WRITE_PROTECT Lost writes -> Oracle Data Guard Oracle Exadata Storage Server Software (Exadata Cell)

Consultoría tecnológica

Oracle Data Guard: Evolución

avanttic

Consultoría tecnológica

New Features Data Guard 10.1 •

Data Guard Broker Support for RAC Automatic

•

LogMiner Configuration Log Miner Support for Index-Organized Tables LogMiner Support for More Types: LONG, Multibyte CLOB and NCLOB

• • • •

Fine-Grained Supplemental Logging Secured Redo Transmission

•

Uniquely Named Databases with DB_UNIQUE_NAME

•

Simplified Zero Data Loss for Data Guard SQL Apply

•

Zero Downtime Instantiation for SQL Apply Real Time Apply Automating Recovery Through Open Resetlogs in Standby Databases

• •

avanttic

Consultoría tecnológica

New Features Data Guard 10.2 • Fast-Start Failover • Automatic Conversion of the Primary Database to a Standby Database Upon Failover • Optimized Asynchronous Redo Transmission • Faster Redo Apply Failover • • • •

Faster SQL Apply Failover Additional Data Type Support in LogMiner and SQL Apply Automatic Deletion of Applied Archive Logs Data Guard: Improved Manageability for Redo Transport, Log Apply, and Broker

• Easy Conversion of a Physical Standby Database to a Reporting Database • Flashback Across Data Guard Switchovers • Fine-Grained, Automated Tracking of SQL Apply Runtime Performance • Optimized Creation of Logical Standby Database

avanttic

Consultoría tecnológica

New Features Data Guard 11.1  Fast-Start Failover for Maximum Performance Mode  Compression of Redo Traffic (Only for Gap Resolution)  Real-Time Query Capability of Physical Standby Database  Fast Role Transitions in a Data Guard Configuration  User Configurable Conditions to Initiate Fast-Start Failover  Dynamic Setting of Oracle Data Guard SQL Apply Parameters  Enhanced Data Guard Broker Based Management Framework    

Enhanced Data Guard Management Interface (Using SQL*Plus) Histogram for Redo Transport Response Time Snapshot Standby Strong Authentication for Data Guard Redo Transport

 Enhanced DDL Handling in Oracle Data Guard SQL Apply  Enhanced Oracle RAC Switchover Support for Logical Standby Databases  Oracle Scheduler Support in Data Guard SQL Apply  Fine-Grained Auditing (FGA) Support in Data Guard SQL Apply Support  Transparent Data Encryption (TDE) with Data Guard SQL Apply  Support XMLType Data Type (Only CLOB) in Data Guard SQL Apply  Virtual Private Database (VPD) Support in Data Guard SQL Apply  SMP Scalable Redo Apply  Archive Log Management Improvements avanttic

Consultoría tecnológica

New Features Data Guard 11.2

avanttic



Automatic Block Repair



Compressed Table Support in Logical Standby Databases and Oracle LogMiner



Configurable Real-Time Query Apply Lag Limit



Integrated Support for Application Failover in a Data Guard Configuration



Support Up to 30 Standby Databases



Universal Connection Pool (UCP) Integration with Oracle Data Guard



Enable Sampling for Active Data Guard



SQL Apply Support for Object Relational Model



SQL Apply Support for Binary XML

Consultoría tecnológica

Oracle Data Guard Concepts

avanttic

Consultoría tecnológica

Configurations    

avanttic

Primary database Physical standby database Logical standby database Snapshot Standby Database

Consultoría tecnológica

Services  Redo Transport Services  Apply Services  Role Transitions

avanttic

Consultoría tecnológica

Role Transitions  Switchover  Switchback  Failover  Reinstate  Convert

avanttic

Consultoría tecnológica

Interfaces  Enterprise Manager / Grid Control  DGMGRL  SQL*Plus  Initialization Parameters

avanttic

Consultoría tecnológica

Complementary Technologies  Oracle RAC  Flashback Database  RMAN

avanttic

Consultoría tecnológica

Why Data Guard? Advantage  Disaster protection.  Complete protection of data.  Efficient use of resources.  Flexibility between availability and performance.  Flexibility between configurations.  Automatic detection and resolution erros.  Simple and centralized management.  Full integration with Oracle Database.  Automatic role transitions.

Disadvantage  Increased complexity of the environment.  Higher cost of Licensing.  Higher cost of Hardware.  Higher cost of knowledge.

avanttic

Consultoría tecnológica

Physical Standby

avanttic

Consultoría tecnológica

Why Physical Standby?    

Advantage Protection against disasters. Data protection. Load Reduction of production (RMAN, SQL Read Only). Low impact on production. Disadvantages

 Database available only for reading.  Standby must be an exact copy of Production

avanttic

Consultoría tecnológica

Parameters  COMPATIBLE (Todos)  CONTROL_FILE_RECORD_KEEP_TIME (Todos)  CONTROL_FILES (Todos)  DB_FILE_NAME_CONVERT (Physical Standby, Snapshot Standby)  DB_UNIQUE_NAME (Todos)  FAL_CLIENT (Physical Standby, Snapshot Standby) Obsolete  FAL_SERVER (Physical Standby, Snapshot Standby)  INSTANCE_NAME (Todos)  LOG_ARCHIVE_CONFIG (Todos)  LOG_ARCHIVE_DEST_n (Todos)  LOG_ARCHIVE_DEST_STATE_n (Todos) ENABLE, DEFER or ALTERNATE.  LOG_ARCHIVE_FORMAT (Todos)  LOG_ARCHIVE_LOCAL_FIRST (Primary, Snapshot Standby) Obsolete  LOG_ARCHIVE_MAX_PROCESSES (Todos)  LOG_ARCHIVE_MIN_SUCCEED_DEST (Todos)  LOG_ARCHIVE_TRACE (Todos)  LOG_FILE_NAME_CONVERT (Physical Standby, Logical tandby, Snapshot Standby)  REMOTE_LOGIN_PASSWORDFILE (Todos)  SHARED_POOL_SIZE (Todos)  STANDBY_ARCHIVE_DEST (Physical Standby, Logical Standby, Snapshot Standby) Obsolete avanttic

 STANDBY_FILE_MANAGEMENT (Primary, Physical Standby, Snapshot Standby)

Consultoría tecnológica

LOG_ARCHIVE_DEST_n               

avanttic

AFFIRM / NOAFFIRM ALTERNATE COMPRESSION DB_UNIQUE_NAME DELAY LOCATION and SERVICE MANDATORY MAX_CONNECTIONS MAX_FAILURE NET_TIMEOUT NOREGISTER REOPEN SYNC / ASYNC TEMPLATE VALID_FOR

Consultoría tecnológica

Protection Mode

avanttic

Consultoría tecnológica

Protection Mode Maximum Performance (NOAFFIRM, ASYNC) ■ Maximum Availability (AFFIRM, SYNC) ■ Maximum Protection (AFFIRM, SYNC) ■

avanttic

Consultoría tecnológica

Maximum Performance • Maximum performance mode is the default level of data protection. • This mode provides the highest possible level of data protection without affecting the performance of the primary database. • Transactions can commit as soon as the redo data is written to the local online redo log. • Redo data is shipped to the standby database asynchronously with respect to the commitment of the transactions that create the redo data. • Configuration requirements: • Standby redo log on at least one standby database • At least one standby database that is configured with the ASYNC and NOAFFIRM redo transport attributes Maximum Performance Mode Maximum performance is the default protection mode and provides the highest possible level of data protection 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 is also written to at least one standby database, but that redo data is written asynchronously with respect to the commitment of 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. Maximum performance mode requirement: Set the ASYNC and NOAFFIRM redo transport attributes of the LOG_ARCHIVE_DEST_ n parameter on at least one standby database.

avanttic

Consultoría tecnológica

Maximum Availability • Maximum availability mode ensures zero data loss without compromising the availability of the primary database. • Redo data must be written to both the local online redo log and the standby redo log on at least one synchronized standby database. • The primary database does not shut down if it cannot write to at least one synchronized standby database. • If no synchronized standby databases are available, the primary database operates in an unsynchronized mode until at least one standby database is synchronized. • Configuration requirements: At least one standby database must have a standby redo log, and that standby database destination must be configured with the SYNC and AFFIRM redo transport attributes.

avanttic

Consultoría tecnológica

Maximum Availability Maximum Availability Mode This protection mode provides the highest possible level of data protection without compromising the availability of the primary database. A transaction does not commit until the redo that is needed to recover that transaction is written to the local online redo log and to at least one remote standby redo log. 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 an unsynchronized mode until the fault is corrected and all gaps in redo log files are resolved. When all gaps are resolved and the standby database is synchronized, the primary database automatically resumes operating in maximum availability mode. This mode guarantees that no data loss occurs 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 availability mode requirements: • Configure standby redo log files on at least one standby database. • Set the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter for at least one standby database.

avanttic

Consultoría tecnológica

Maximum Protection • Maximum protection mode ensures zero data loss in the event of a failure of the primary database, the network, or all standby databases. • The primary database shuts down if a fault prevents it from writing its redo stream to at least one synchronized standby database. • Redo data must be written to both the local online redo log and the standby redo log on at least one synchronized standby database. • Configuration requirements: At least one standby database must have a standby redo log, and that standby database destination must be configured with the SYNC and AFFIRM redo transport attributes. Maximum Protection Mode This protection mode ensures that no data loss occurs if the primary database fails. To provide this level of protection, the redo data that is needed to recover each transaction must be written to both the local online redo log and the standby redo log on at least one standby database before the transaction commits. To ensure that data loss cannot occur, the primary database shuts down if a fault prevents it from writing its redo stream to at least one remote standby redo log. For multiple-instance RAC databases, Data Guard shuts down the primary database if it is unable to write the redo records to at least one properly configured database instance. Maximum protection mode requirements: • Configure standby redo log files on at least one standby database. • Set the SYNC and AFFIRM attributes of the LOG_ARCHIVE_DEST_n parameter for at least one standby database destination. Note: Oracle recommends a minimum of two standby databases for maximum protection mode.

avanttic

Consultoría tecnológica

Role Transitions

avanttic

Consultoría tecnológica

Role Transitions: Switchover and Failover • Switchover – Planned role transition – Used for operating-system or hardware maintenance – Manually invoked on primary database • Failover – Unplanned role transition – Used in an emergency – Minimal or no data loss (depending on the data-protection mode) – Fast-start failover can be enabled for automatic failover – Initiated at standby database

avanttic

Consultoría tecnológica

Switchover • Transitions the roles of the primary and standby databases • Requires no resetting of the online redo logs of the new primary database • Incurs no data loss A switchover operation transitions the primary database to the standby role and transitions the standby database to the primary role, without resetting the online redo logs of the new primary database. The primary database at the start of a switchover operation will need to be shutdown and restarted. The physical standby database is not shutdown and restarted during a switchover. If the physical standby database is in the Active Data Guard mode, it is closed for the transition then opened again after the switchover completes, but it is never totally shutdown to require a restart. If the switchover operation involves a logical standby database, there is no need to shut down and restart either the primary database or any of the standby databases. Logical standby databases do not need to be shut down and restarted. Note: When necessary, the broker automatically starts and stops all but one instance in a Real Application Clusters (RAC) environment for the primary database. If the broker is not used, this must be done manually. Starting with Oracle Database 11g Release 2 (11.2), the secondary RAC instances of a physical standby database no longer need to be shutdown during the switchover. They can stay in the mounted or Active Data Guard state. The primary still requires only one instance be running during a switchover.

avanttic

Consultoría tecnológica

Switchover

avanttic

Consultoría tecnológica

Switchover

avanttic

Consultoría tecnológica

Failover

avanttic

Consultoría tecnológica

Types of Failovers • Manual failover: Invoked by the DBA – Complete: Attempts to minimize data loss by applying all available redo on the standby database – Immediate: No additional data is applied on the Standby database • Fast-start failover: Invoked automatically by the Data Guard broker Types of Failovers A manual failover is invoked through DGMGRL or Enterprise Manager. There are two types of manual failover: • Complete: The maximum amount of redo data for the protection mode is recovered. In this type of failover, the broker avoids disabling any standby databases that are not the failover target. Complete failover is the default and recommended type of failover. • Immediate: No additional redo data is applied to the standby database after the failover is invoked. This is the fastest type of failover. After an immediate failover, you must recreate or reinstate the original primary database and all standby databases that were not a target of the failover. Note: You should always try to perform a complete failover. Perform an immediate failover only when a complete failover is unsuccessful. Depending on the destination attributes of redo transport services, a complete failover can take place without incurring any data loss, while an immediate failover usually results in the loss of data. You can configure fast-start failover so that the broker automatically fails over to a chosen standby database in the event of the loss of the primary database. For details, see the lesson titled “Enabling Fast-Start Failover.”

avanttic

Consultoría tecnológica

Failover Considerations • The old primary database is disabled from the Data Guard configuration. • Data loss is possible. • Failover should be used only in an emergency. • When choosing a standby database to fail over to, you should: – Choose a physical standby database when possible – Choose the standby database that is most current

avanttic

Consultoría tecnológica

Logical Standby

avanttic

Consultoría tecnológica

Logical Standby

avanttic

Consultoría tecnológica

Por que Logical Standby? Advantage     

Additional types of protection against failures. Efficient use of resources. Load distribution. Optimization for reporting and decision support requirements. Minimize downtime during upgrades. Disadvantages

 Several limitations of data types.  Several SQL commands limitations.  SQL command application, not the REDO LOG.

avanttic

Consultoría tecnológica

Data types not supported      

avanttic

BFILE Collections (VARRAYS, Nested Tables) Multimedia Data types (Spatial, Image, Oracle Text) ROWID, UROWID User-defined types XMLType (Object Relational) Binary XML

Consultoría tecnológica

SQL commands ignored  ALTER DATABASE  ALTER MATERIALIZED VIEW ALTER  MATERIALIZED VIEW LOG  ALTER SESSION  ALTER SYSTEM  CREATE CONTROL FILE  CREATE DATABASE  CREATE DATABASE LINK  CREATE PFILE FROM SPFILE  CREATE MATERIALIZED VIEW  CREATE MATERIALIZED VIEW LOG  CREATE SCHEMA AUTHORIZATION    

CREATE SPFILE FROM PFILE DROP DATABASE LINK DROP MATERIALIZED VIEW DROP MATERIALIZED VIEW LOG

 EXPLAIN  LOCK TABLE  SET CONSTRAINTS

avanttic

 SET ROLE  SET TRANSACTION

Consultoría tecnológica

Oracle Dataguard Views             

avanttic

DBA_LOGSTDBY_EVENTS DBA_LOGSTDBY_HISTORY DBA_LOGSTDBY_LOG DBA_LOGSTDBY_NOT_UNIQUE DBA_LOGSTDBY_PARAMETERS DBA_LOGSTDBY_SKIP DBA_LOGSTDBY_SKIP_TRANSACTION DBA_LOGSTDBY_UNSUPPORTED V$LOGSTDBY_PROCESS V$LOGSTDBY_PROGRESS V$LOGSTDBY_STATE V$LOGSTDBY_STATS V$LOGSTDBY_TRANSACTION

Consultoría tecnológica

Active Data Guard

avanttic

Consultoría tecnológica

Oracle Active Data Guard • Is an option for Oracle Database 11 g Enterprise Edition • Enhances quality of service by offloading resource intensive activities from a production database to a standby database • Includes the following features: – Real-time query – RMAN block change tracking on a physical Standby database Oracle Active Data Guard is a separately licensed database option for Oracle Database 11 g Enterprise Edition. It includes the Real-time Query feature, which enables a physical standby database to be open read-only while Redo Apply is active. With this feature, users who are connected to a physical standby database can query and report against data that is up-todate with the primary database. Oracle Active Data Guard also enables you to configure RMAN block change tracking for a physical standby database. With RMAN block change tracking, you can offload fast incremental backups from the production database to the physical standby database.

avanttic

Consultoría tecnológica

Using Real-Time Query

avanttic

Consultoría tecnológica

Using Real-Time Query With Oracle Active Data Guard, you can use a physical standby database for queries while redo is applied to the physical standby database. This feature enables you to use a physical standby database for disaster recovery and to offload work from the primary database during normal operation. Note: If you need to create additional structures (such as indexes and materialized views), you can create a logical standby database as described in the lesson titled “Creating a Logical Standby Database.” In addition, this feature provides a loosely coupled read/write clustering mechanism for OLTP workloads when configured as follows: • Primary database: Recipient of all update traffic • Several readable standby databases: Used to distribute the query workload The physical standby database can be opened in read-only mode only if all files were recovered up to the same system change number (SCN). Otherwise, the open fails.

avanttic

Consultoría tecnológica

Snapshot Standby

avanttic

Consultoría tecnológica

Snapshot Standby • A snapshot standby database is a fully updatable Standby database created by converting a physical Standby database. • Snapshot standby databases receive and archive—but do not apply—redo data from a primary database. • When the physical standby database is converted, an implicit guaranteed restore point is created and Flashback Database is enabled. A snapshot standby database is a fully updatable standby database that is created by converting a physical standby database to a snapshot standby database. A snapshot standby database receives and archives—but does not apply—redo data from a primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back to a physical standby database, after discarding all local updates to the snapshot standby database. You can create a snapshot standby database by using DGMGRL commands or SQL commands. When the standby database is converted to a snapshot standby database, an implicit guaranteed restore point is created and Flashback Database is enabled. After performing operations on the snapshot standby database, you can convert it back to a physical standby database. Data Guard implicitly flashes the database back to the guaranteed restore point and automatically applies the primary database redo that was archived by the snapshot standby database since it was created. The guaranteed restore point is dropped after this process is completed.

avanttic

Consultoría tecnológica

Data Guard Broker

avanttic

Consultoría tecnológica

Data Guard Broker

avanttic

Consultoría tecnológica

Data Guard Broker

avanttic

Consultoría tecnológica

Data Guard Broker Components

• Client-side: – Oracle Enterprise Manager Grid Control – DGMGRL (command-line interface) • Server-side: Data Guard monitor – DMON process – Configuration files

avanttic

Consultoría tecnológica

Data Guard Broker Components Data Guard Broker: Components The Oracle Data Guard broker consists of both client-side and server-side components. On the client, you can use the following Data Guard components to define and manage a configuration: • Oracle Enterprise Manager • DGMGRL, which is the Data Guard command-line interface (CLI) On the server, the Data Guard monitor is a broker component that is integrated with the Oracle database. The Data Guard monitor comprises the Data Guard monitor (DMON) process and broker configuration files, with which you can control the databases of that configuration, modify their behavior at run time, monitor the overall health of the configuration, and provide notification of other operational characteristics. The configuration file contains profiles that describe the current state and properties of each database in the configuration. Associated with each database are various properties that the DMON process uses to control the database’s behavior. The properties are recorded in the configuration file as a part of the database’s object profile that is stored there. Many database properties are used to control database initialization parameters related to the Data Guard environment.

avanttic

Consultoría tecnológica

Oracle Data Guard Broker: Features • The Oracle Data Guard broker is a distributed management framework. • The broker automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations. • With the broker, you can perform all management operations locally or remotely with easy-to-use interfaces: – Oracle Enterprise Manager Grid Control – DGMGRL (a command-line interface) The following are some of the operations that the broker automates and simplifies: • Automated creation of Data Guard configurations incorporating a primary database, a new or existing standby database, redo transport services, and log apply services Note: Any of the databases in the configuration can be a Real Application Clusters (RAC) database. • Adding new or existing standby databases to each existing Data Guard configuration, for a total of one primary database and from one to 30 standby databases in the same configuration • Managing an entire Data Guard configuration (including all databases, redo transport services, and log apply services) through a client connection to any database in the configuration • Invoking switchover or failover with a single command to initiate and control complex role changes across all databases in the configuration • Monitoring the status of the entire configuration, capturing diagnostic information, reporting statistics (such as the log apply rate and the redo generation rate), and detecting problems quickly with centralized monitoring, testing, and performance tools

avanttic

Consultoría tecnológica