Oracle Dataguard principle

The  oracle Dataguard is the Oracle's own data synchronization feature that transfers log files from the original database to the target database and then applies the log files on the target database, keeping the target database synchronized with the source database. is a database-level high availability scenario.   dataguard can provide Oracle database redundancy, data protection, failure recovery, and so on to achieve rapid database switching and catastrophic recovery. When transactional consistency is guaranteed in the production database, a standby is created using a physical full backup of the production library, which automatically maintains an alternate database through an archive log or redo entry that is transmitted over the production library.   dataguard Data synchronization technology has the following advantages:  1) The capabilities built into the Oracle database itself are fully compatible with the new features of each Oracle new version and do not require an additional fee.  2) configuration management is simpler and does not require familiarity with other third-party software products. 3) The physical standby database supports any type of data object and data type;  4) logical standby database is open to perform operations such as querying while keeping data synchronized. 5) in Maximum protection mode, 0 loss of data is ensured.    I. Architecture  oracle Dataguard consists of a primary database (production database) and one or more standby databases (up to 9). The database that makes up data guard is connected through Oracle NET and can be distributed across different geographies. As long as the libraries can communicate with each other, their physical location is not limited by the operating system. The  1.primary database  dataguard contains a Primary database, which is a production database accessed by most applications, which can be either a single-instance database or a RAC. The  2.standby database  standby database is a copy of the primary database (transactionally consistent). You can create up to 9 standby databases in the same data guard. Once created, Data guard automatically maintains each standby database by applying the redo of the primary database. The standby database can also be a single-instance database or a RAC structure.    standby Database type standby database is usually divided into two categories: logical standby and physical standby.   Logic standby   logic standby is aReceives the redo log of the primary database and translates it into an SQL statement, and then executes the SQL statement on the standby database for synchronization. Physical standby   Physical standby are synchronized by receiving and applying the redo log of the primary database in the form of media recovery, not only the physical structure of the file, but also the storage location of the block on the disk is identical.    Services   Redo Transfer Service (Redo Transport Services)   Control the transfer of Redo data to one or more archived destinations.   Log Application services   apply redo data to the standby database to maintain consistency with the transactions of the primary database. The redo data can be read from an archive file in the standby database or directly by applying an alternate log file. There are two roles in the   Role transformation Service (roles transitions)  dataguard: Primary and Standby. Role conversion is to have the database switch between the two roles, switching between the two: switchover and failover    1) switchover: Convert primary database to standby database. Switchover can ensure that data is not lost.    2) Failover: When the primary database fails and cannot be restored in a timely manner, failover is called to convert a standby database into a new primary database. In maximum protected mode or highest availability mode, the failover guarantees that no data loss is possible.    protection mode   1. Maximum protection     This mode is the default data protection mode, providing the highest possible level of data protection without affecting the performance of the source database. In this mode, once the log data is written to the online log file of the source database, the transaction can be committed without waiting for the log to be written to the target database, and if the network bandwidth is sufficient, the mode provides a level of data protection similar to the maximum available mode. 2. Maximum availability     This mode is basically the same as "maximum protection". Under normal circumstances, the master repository is synchronized. When there is a problem with the network or the standby, it will not affect the main library's machine, the main library will automatically convert the library "maximum performance" mode, wait for the repository to be available, transfer the archive to the standby for recovery. 3. Maximum Performance     This mode ensures maximum performance of the main library, and the data between the main repositories is transmitted asynchronously. That is, the primary and standby logs will not be transferred to the standby repository  [above   source]  1, Dataguard principle Dataguard is to establish a primary and standby group to establish its referential relationship. Once  standby is created, Dataguard passes the redo of the primary database (PRIMARY) to the standby database and then applies standby in redo to synchronize the database.   has two types of standby: physical standby and logical standby physical standby provide exactly the same copy as the primary database (blocks to blocks), and the database schema, including the index, is the same. It is directly applied redo to achieve synchronization. Logical standby is not the case, in logical standby, the logical information is the same, but the physical organization and data structure can be different, it is synchronized with the main library by converting the received redo into SQL statements, and then executing the SQL statement on the standby. Logic standby has other uses in addition to disaster recovery, such as for user queries and reports. The  dataguard contains three services (log transfer, log application, role translation) log Transport service to control the transmission of Redo data (transfer log, implement database protection mode)--------------standby receive redo data by using the RFS process. The log application service automatically applies the log on one hand, and automatically detects the missing redo from the primary database or other standby, and standby the missing redo. Several protection modes of  dataguard: Maximum protection, maximum available, maximum performance maximum protection means that a transaction cannot be committed unless the redo is available in at least one standby. If it is not available in a standby, the operation of the primary database is stopped. Usually more restrictive, not very commonly used in production environments (price/performance is not good). Maximum availability means that if standby is not available, the primary database can still handle transactions, but after the problem is corrected, the standby and the primary database are resynchronized. One such problem is that some data may be lost when there is failover before resynchronization. Maximum performance means that the commit operation of the primary database does not wait for standby. Primary and standby loosely coupled, with low data protection levels.   Physical Standby possible modes: read-only mode (OPEN READONLY) and Recovery mode (mananged RECOVERY)   2. Physical Dataguard the preparation of the master database for the brief process: Force logging,enable archiving, a local archive destination. Create a standby database: A. Close the main library, cool back up the main library data files, log files, and password files, and then start the main library and create the standby control file on the main library: ALTER DATABASE create standby controlfile as ' filename ' B. Prepare the parameter file, copy the parameter file, the backup main library file and the standby control file to the standby system. The parameters that need to be changed are: standby_archive_dest-----received archive log store Db_file_name_convert and log_file_name_ Convert-----Use log_archive_dest_1 to-----Local archive destination log_archive_dest_2= ' service=standby '-----when the main and standby libraries are under the same system Archive to the destination of standby Standby_file_management=autoremote_archive_enable=truefal_serverfal_clientinstance_ Name-----This parameter distinguishes the main library lock_name_space when the main and standby libraries are under the same system-----when the primary and standby libraries are under the same system, specify the standby instance name and Instance_ Name is the same as C. If you are a Windows system, you need to create a Windows service. D. Configure the Tnsnames.ora of the two machines, both sides can tnsping E. Configure monitoring on the main and standby libraries F. Dead connection detection on standby system: Sqlnet.ora set Sqlnet.expire_time= 2g. Create Spfileh on standby. Start Standby:startup nomountalter database Mount standby databasei. Initializing the Log app service alter DATABASE recover Managed standby database disconnect from session; 3, Dataguard maintenance   A. Log shipping service In some cases, you may need to have a time interval between the archive log and the application log, at which point you can refer to the standbySpecify the Delay=minutes property in the Log_archive_dest_n parameter. The log on the standby should be the same size as the log on the main library, and the log group on the standby should be more than the main library because the archive operation is time-complete. That is, the RFS (log receive) process does not have to wait for the log to be archived before using the standby log. The simplest way to tell if a log group is sufficient is to look at the warning log and RFS trace file. Add standby log file: ALTER DATABASE statement using the Add standby logfile clause. Related views v$standby_log,v$logfile add standby log Group: ALTER DATABASE add standby logfile Group 10 (' filename 1 ', ' File name 2 ') size 100M for multiple Standby share the archive log file destination, in some cases you need to specify the dependency property of the Log_archive_dest_n parameter, which is used to indicate that the destination relies on a successful archive of the parent destination. Parameter log_archive_dest_n can also specify reopen, Max_failures, Sync, async properties. Select whether to transfer the log with LGWR or arch process by specifying the LGWR or Arch property for this parameter. Several processes used for log reception are: Lgwr,arch,rfs,fal. The FAL process is used to resolve log seams. The statement that sets the data protection mode is: ALTER DATABASE set standby database to Maximun (protection|availability|performance)   B. Log app service for physical standby, the Log app service involves several processes: RFS,ARC,MRP. MRP is the management recovery process. Several commands to start the standby recovery operation: ALTER DATABASE recover managed standby database (start foreground session); ALTER DATABASE recover managed Standby Database disconnect from session (initiates a background session, which means the session can continue to do something else); ALTER DATABASE recover managed standby database Cancel (stop log app) . You can v$managed_sta by querying the viewNdby View the log application.  c. data file management when the main library creates a new data file, you can define the parameter standby_file_management to auto, and let standby also automatically create the data file. If the directory structure of the master and standby data files is different, you can set Db_file_name_convert to convert the file names on the main library to the filenames on standby. If Standby_file_management is set to auto, you cannot rename or create a data file, log file on standby. Every minute the main library asks standby if there is a gap, which is called heartbeat. You can query the view v$archived_gap, and if you find gaps, you can copy the log files from the main library to standby, and then register the relevant files with the standby. The specific method is: ALTER DATABASE register logfile ' file name '. Of course, you can also set the parameter fal_server,fal_client, let the log application service automatically handle gap problem. For standby Log app service, the following views help monitor: V$managed_standby,v$archived_dest_status,v$archived_log,v$log_status,v$dataguard_ Status. You can set the parameter Log_archive_trace to track the archive at different levels.   D. Role conversion Oracle supports two forms of role conversion----switchover and failoverswitchover contain two steps, first the main library is converted to standby, and then standby is converted to the main library switchover preparation: Complete the role conversion needs to change Parameters (must change Log_archive_dest_n and Log_archive_dest_state_n on all standby), ensure that the main library is connected to all standby, and that no user is connected to the database; For a RAC environment, ensure that only one instance is active, before the role conversion, the primary library instance should be open, and the standby instance is the Mount state, because the standby database can also apply the archive log during the conversion process. If the standby is readonly, the switching operation can still be done, but it takes a little extra time, and if the switch operation contains a logical standby, then both the master and standby instances must be open, and the standby that will be converted to the main library becomesArchive mode; Cancels the log delay on the standby library. Switchover steps: On the current main library, first confirm that you can perform the switchover operation (select Switchover_status from V$database, and if the value is to standby you can switch, Otherwise you need to check that the current Dataguard configuration is working properly, and then switch the main library to STANDBY (execute ALTER DATABASE COMMIT to switchover to physical STANDBY; So the original control file is backed up and generated a new standby control file, and then just restart the library for the standby mode can be, after the completion of the above operation, on the original standby database, you need to query the Master library's switchover information is received by the target standby (SELECT Switchover_status from V$database; If the result is switchover pending the standby switch to primary is possible, you need to check if the Dataguard configuration is working properly), Then execute ALTER DATABASE COMMIT to switchover to PRIMARY; convert standby to PRIMARY and restart the library. It is important to note that if the library online redo log does not exist, the toggle statement will automatically create them, however, it will take a long time. Oracle therefore recommends adding online redo logs manually. There are two ways to manually add online redo logs: The first is to copy the logs from the original repository to the standby, and define the parameter Log_file_name_convert to associate standby with the new log. The second method is to drop the log that exists on all target STANDBY and create a new log with the command alter DATABASE ADD STANDBY logfile. The final step in switchover is to convert the newly generated standby into recovery mode and archive the new primary once.  failover Preparation: The parameters that need to be changed to complete the role conversion (must change the log_archive_dest_n and Log_archive_dest_state_n on all standby); Make sure that the main library is connected to all standby, that only one instance is active for the RAC environment, and that if the standby that you want to failover is currently running in Maximum protection mode, you should convert it to maximum performance mode (by commandALTER database SET STANDBY database to maximize performance;)  failover steps: First to find and solve the problem of Log gap, Then copy the log number above the library from other libraries and apply these logs, if you do not manually register the new log, then you can execute the following statement ALTER DATABASE RECOVER MANAGED STANDBY database FINISH; Otherwise the statement to be executed is ALTER DATABASE RECOVER MANAGED STANDBY database FINISH SKIP STANDBY LOGFILE; next execute ALTER DATABASE COMMIT to SWITCH Over-to PRIMARY; Complete the switchover and restart the new main library, and if possible, make a backup of the main library.  e. Start Standbystartup nomount; ALTER database MOUNT STANDBY DATABASE; ALTER database RECOVER MANAGED STANDBY database DISCONNECT from Session; f. Close STANDBY first to verify that it is in a recovery state: SELECT PROCESS, STATUS from V$managed_standby; undo restore operation: ALTER database RECOVER MANAGED STANDBY database cancel; SHUTDOWN immediate; g. Let standby run in read-only access mode start standby for read-only mode: Startup Nomount; ALTER database MOUNT STANDBY DATABASE; ALTER DATABASE OPEN read only; Convert the recovery mode STANDBY to read only mode: ALTER DATABASE RECOVER MANAGED STANDBY database CANCEL; ALTER DATABASE OPEN READ only; h. Convert STANDBY from READ only to recovery mode ALTER DATABASE RECOVER MANAGED STANDBY database DISCONNECTFrom session;  I. Let the standby of a read-only mode perform a sort operation: the sort operation cannot use a non-temporal tablespace, the temporary tablespace must be managed locally, and only temporary files are included if the primary library does not have a temporary tablespace when the standby is created, you need to create a temporary tablespace on the main library and execute the ALTER SYSTEM SWITCH LOGFILE; pass redo to standby. If you want to add temporary file to standby temporary table space, you need to convert standby to read only mode and execute the command alter tablespace TEMP1 ADD tempfile '/disk1/oracle/dbs/s_ TEMP1.DBF ' SIZE 10M reuse; add temporary files.  j. You can make a backup of the database by backing up the standby.  k. Actions on the main library and standby response: If you execute ALTER DATABASE CLEAR unarchived logfile or use resetlogs when you open the database, you must recreate standby. If you execute ALTER DATABASE enable| on the main library DISABLE, if you change the state of the tablespace, if you set the parameter standby_file_management to auto and create a table space or add a data file, you do not need to operate on standby. If you delete a tablespace or data file on the main library, you need to delete the relevant data file on the operating system after the standby log application. If you rename the data file on the main library, you also need to rename it on the standby (because it is a change to the control file, so there is no log pass, so the same action is done on both sides) if you change the control file on the main library, You will re-create the standby control file or rebuild the standby database. If you add or delete log files on the main library, you also need to synchronize changes on the standby. The method is: Cancel the recovery first, if Standby_file_management is auto, then change to manual, then use the command alter DATABASE ADD STANDBY LOGFILE ' prmy3.log ' SIZE 100K; Add log files or alter DATABASE drop STANDBY LOGFILE ' prmy3.log ' drop log file with the command, and finally restore the value of the parameter standby_file_management. If you are inNologging|unrecoverable on the main library, you should copy the tablespace containing these changes to standby. If you change the main library's parameter file, you should also change the standby parameter file.  l. Monitoring process Select process, client_process, sequence#, STATUS from v$managed_standby; m. Process for monitoring recovery operations Select archived _thread#, archived_seq#, applied_thread#, applied_seq# from v$archive_dest_status; [  source] 

Oracle Dataguard Principles