Yh1:oracle Data Guard Knowledge Base

DataGuard : are you familiar with Oracle?

everyone: that's pretty familiar.

Small: OK, then we do not talk about the basics today, straight into the topic! The child who does not have a class goes back to mend.

Today's topics include:

Performance and diagnosis of ADG in 12.2

Deploying Columnstore on ADG

DG Cross-Platform migration

DG Data Recovery

DG's archive Management

Performance and diagnosis of ADG in 12.2

In Oracle 12.2, ADG has a number of amazing improvements that improve DBA efficiency by ADG Standby database performance data collection and diagnostics, snapshot standby database applications, and real-time database operation monitoring, to align with user needs This provides better quality of service for business applications.

Remote AWR

The awr snapshot of the ADG standby database is called a remote snapshot. A database node called a target is responsible for storing snapshots collected from a remote ADG standby database node, known as a source. The target can be either a ADG primary database or a non-ADG database. If the target is the ADG primary database, it is also the source database, and its snapshot is a local snapshot.

You can use the AWR report, Oracle database import and export capabilities, and user-defined queries to access snapshot or awr data stored on the target. Automated Database Diagnostic Monitor (ADDM) applications can use AWR data to analyze any database performance-related issues.

Support for SQL Tuning Advisor

Allows DBAs to offload tuning of the primary database workload to the ADG standby database and adjust ADG SQL workloads on the ADG itself. When SQL tuning of the primary database workload is unloaded to the ADG standby database, the SQL tuning process starts from the primary database, but the tuning process is performed remotely on the ADG standby database, and the results are written back to the primary database database. When you adjust the ADG workload, the entire SQL tuning process is performed locally on the ADG standby database while maintaining the read-only state of the database. This is achieved by collecting the required information from the Dblink of the primary database and writing any database state changes, such as SQL configuration file implementations, back to the primary database. The SQL configuration file implemented on the primary database is recommended to be applied to the ADG standby database using the Redo application mechanism.

For more new features, please click :

Oracle 12.2 New features handheld handbook-Performance and Diagnostics for volume sixth ADG

Deploying Columnstore on ADG

We are doomed to lose the people we love, otherwise how do we know how important they are in our lives? From "Rejuvenation"

Deploy Columnstore on the active Data guard, optionally in the main library, the standby library, or both. When you deploy Columnstore on the main repository, you can manipulate the same or different sets of objects on two libraries, and if you manipulate different sets of objects, it is equivalent to increasing the storage size of the in-memory.

There are three ways to configure:

1. Deploy the same in-memory on the master repository

2. Deploy Columnstore only on the standby library

3. Main Library in-memory and standby in-memory store different objects

A third advantage is that you can run different workloads in each database. For example, the HR application runs the report in the primary database, and the sales history application runs the report in the standby database. As a result, none of the two databases bear the full load of the analysis report.

in the above three typical configurations, three services will be created: Standby only, primary, primary, and standby three services. For example, if you need the sales Fact table data for the last one months in the master instance, the sales data for the first one months is stored in the standby instance. You need to populate the dimension table in two instances. For each sales partition, you can use the inmemory ... The Distribute for service specifies an alternate or primary service. For each dimension table, specify the services that include the primary DB instance and the standby DB instance.

For more details, click:

"12.2 new features" Deploy Columnstore on Oracle Active Data Guard

Cross-platform migration

In Oracle databases, cross-platform migration has been a complex task. Oracle's Dataguard technology continues to evolve, not only as a disaster-tolerant, but also as an important mission in data migration.

since 10g, Oracle's DG has started to have a limited support for cross-platform dataguard environments, simplifying the process of data migration, and now the successful implementation process has been released from Aix to the Solaris SPARC platform.

To implement the process, please click:

Dataguard support for cross-platform data migrations

DG Recovery

DG in the main library of the archive log successfully transferred to the repository, the local backup failed, and a rman-06004,rman-20003 error occurred, how to respond please review the DG Recovery encounter rman-06004,rman-20003

DG Archive Management

In 11g, with the maturation of ASM, RAC, data guard (including active data Guard), the use of Rac+asm+data Guard is increasingly becoming a reliable, easy-to-maintain, stable, high-availability and disaster-tolerant solution. This article discusses how to manage archive logs in an Oracle 11g Data guard environment.

Archived logs are important, and backup recovery requires it, and data guard needs it. In earlier versions of the data Guard environment, there was often an archive log management problem, but 11g made a lot of improvements that made our use and maintenance more convenient.

In the data Guard environment, the archive log management needs to meet the following requirements or requirements:

1. The main library uses the fast recovery zone (Fast recovery area), where in the RAC there is no doubt that the fast recovery zone is best placed on ASM.

2. Specify the appropriate space for the quick recovery area. First we need to estimate a reasonable retention time for the archive. For example, due to backup system problems or data guard repository issues, maintenance, etc., the length of time to archive retention is required. Let's say 24 hours, and then assess how much of the archive will be in the 24-hour maximum amount of filings. In general, the volume of data processing at the time of the largest archive, assuming that within 24 hours to archive the maximum of 200G. Note that for RAC, the sum of all nodes in this 24-hour archive amount. Finally, specify the amount of space needed for the quick recovery area, which specifies the size of the fast recovery area, compared with the parameter db_recovery_file_dest_size. It is also assumed that the quick Recovery Zone stores archive logs.

3. Specify the quick recovery area on the standby and specify the appropriate size for the quick recovery area, mainly because of the archive log capacity after switching to the main library, and if the archive capacity of the main library is under pressure, the repository can store more archived logs so that the archive logs are backed up by a standby repository.

4. Use Rman to configure archive deletion policy for main library and backup: CONFIGURE ARCHIVELOG deletion policy to applied on all STANDBY;

Yh1:oracle Data Guard Knowledge Base