The principle of 1 and Dataguard is dataguard by establishing a primary and standby group to establish its reference 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 primary database for the implementation of the brief process: Force LOGGING, ENABLE archiving, a local archive destination. Create number of StandbyLibrary: 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 creation 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, which can be specified by specifying the Delay=minutes attribute in the parameter log_archive_dest_n specified on standby. The log on the standby should be the same size as the log on the main library, and the log group on the standby shouldMore than the main library, because the archive operation only has time to 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 view the log application by querying the view V$managed_standby. 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 standbyAutomatically create data files. 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 proceed, but it takes a little extra time, and if the switching operation contains the logical standby, then both the master and standby instances must be open, and the standby to be converted to the main library becomes the archive 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, if the value is to standby you can switch, otherwise you need to check whether the current Dataguard configuration is functioning properly), and then switch the main library to standby (execute ALTER DATABASE COMMIT to Switchover to physical STANDBY, so that the original control file is backed up and a new STANDBY control file is generated, and then just restart the library for STANDBY mode, and when the above operation is complete, on the original STANDBY database, You need to query whether the switchover information for the primary repository is received by the target standby (SELECT switchover_status from v$database; If the result is switchover Pending that standby switch to PRIMARY is possible, otherwise you need to check whether the configuration of Dataguard is working properly), and 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); Ensure that the main library is connected to all standby, that only one instance is active for the RAC Environment, and if the standby that you want to perform the failover operation is currently running in Maximum protection mode, you should convert it to maximum performance mode (Alter DATABASE SET by command STANDBY DATABASE to maximize performance;) failover steps: FirstDiscover and resolve the issue of 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 switchover 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 DISCONNECT From Session; i. To let the standby of the read-only mode perform a sort operation should be aware of the problem: the sort operation cannot use a non-temporal tablespace, the temporary tablespace must be managed locally, and onlyInclude temporary files if the main library does not have a temporary tablespace when creating standby, you need to create a temporary tablespace on the main library and execute alter SYSTEM SWITCH LOGFILE; 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 perform operations such as nologging|unrecoverable on the main library, you should copy the tablespace containing these changes to standby. If you change the main library's parameter file, then you should also change sThe Tandby 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;
