All about Data Guard

All about Data Guard 1. Data Guard Configurations (Data Guard Configurations) Data Guard is a collection composed of one primary database (production database) and one or more standby databases (up to nine). Databases that make up Data Guard are connected through Oracle Net and may be distributed in different regions. As long as databases can communicate with each other, there is no limit on their physical locations. As for the operating system, it does not matter (in some cases), as long as oracle is supported. You can manage the primary database or standby database through the command line, or through the dedicated command line interface (DGMGRL) provided by Data Guard broker, or through the OEM graphical interface. 1. Primary database as mentioned earlier, Data Guard contains a production database that is accessed by most applications. This database can be a single-instance database or RAC. 2. the Standby database is the replication of the primary database (transaction consistency ). You can create up to nine standby databases in the same Data Guard. Once the creation is complete, Data Guard automatically maintains each standby database through the redo application of the primary database. Standby databases can also be single-instance databases or RAC structures. Standby databases are generally divided into two categories: Logical standby and physical standby. How to differentiate them? What are the characteristics of the two categories and how to build them, here is a simple example: Logical standby is like asking someone to sketch a portrait for you. The basic organs are there. You can rest assured that, however, the color of each organ may not be the same as that of your own. Physical standby is like taking a photo with a camera. What kind of photo do you look like? Your eyes are definitely on your nose. Or, like looking in the mirror, you are inside and outside. Specifically, the database not only has the same physical structure of the file, but even the storage locations of the connected block on the disk are the same (by default ). Why? We have to start with the synchronization mechanism. The logical standby receives the redo log of the primary database and converts it to an SQL statement. Then, it executes the SQL statement (SQL Apply) on the standby database for synchronization, physical standby synchronizes data by receiving and applying the redo log of the primary database in the media recovery mode (Redo Apply. In addition, I don't know if you have noticed the details of adjectives: for camera photos, there is a powerful and easy-to-use dummies camera, and for sketch, even the simplest painting method, it also requires a lot of exercises to be mastered. Does this detail show that logical standby requires more operation skills than physical standby? 2. Data Guard Services REDO Transport Services controls the transmission of Redo Data to one or more archiving destinations. Log application Services applies redo data to the standby database to maintain transaction consistency with the primary database. Redo data can be read from the archive file of the standby database, or the standby redo log file can be directly applied (if the real-time application opens ). Role Transitions (Dg) has only two roles: primary and standby. Role conversion is to allow the database to switch between the two roles. There are also two types of switching: switchover and failover. Switchover: converts the primary database to the standby database. Switchover ensures that data is not lost. Failover: when the primary database fails and cannot be recovered in time, failover is called to convert a standby database to a new primary database. In the maximum protection mode or the highest availability mode, failover can ensure that no data is lost. Note: You can briefly understand the concepts mentioned above. It is too simple to chew on the text. Otherwise, you will get confused more and more details about related services in the following sections, not only is there a straightforward description, but there will also be examples, plus simple images, even if you do not understand it, you will certainly understand it again :) 3. Data Guard Protection mode (Data Guard Protection Modes) for Data Guard, its survival logic is very simple, so it can live well, do meaningful things, and do more meaningful things. :) because it provides three Data protection modes, we call it another kind: There are three models: Maximum protection: This mode ensures that no data is lost. There is a price to implement this step. It requires that all transactions be written into the local online redo log before committing, it also submits the standby redo log to the standby database at the same time, and confirms that the redo data is available in at least one standby database (if there are more than one) before it is submitted on the primary database. If any fault occurs that causes the standby database to be unavailable, the primary database will be shut down. Maximum performance: This mode provides the highest level of data protection policies without affecting the performance of the primary database. Transactions can be committed at any time. The redo data of the current primary database also needs to be written to at least one standby database, but such writing can be non-synchronous. If the network conditions are ideal, this mode can provide data protection similar to the highest availability, but only has a slight performance impact on the primary database. Maximum availability: This mode provides the highest level of data protection policies without affecting the availability of the primary database. The implementation method is similar to the maximum protection mode. It also requires that all transactions ensure that redo data is available in at least one standby database before committing. However, if a fault occurs during the import, the standby database redo log cannot be written at the same time, the primary database will not shut down, but will be automatically converted to the highest-performance mode. After the standby database returns to normal, it is then automatically converted to the highest availability mode. Maximum protection and maximum availability require at least one standby database redo data to be written synchronously. You must specify the LOG_ARCHIVE_DEST_n initialization parameter for all three modes. LOG_ARCHIVE_DEST_n is very important. Are you familiar with it? I promise you will be familiar with it if you finish learning dataguard. Iv. Advantages of Data Guard summary disaster recovery and high availability comprehensive Data protection effective use of system resources more flexible balance between high availability and high performance mechanism automatic fault check and centralized and easy-to-use solution Management mode-Based Automated role conversion the same Data Guard configuration contains a Primary database and a maximum of nine Standby databases. The creation of Primary is not mentioned. The Standby database can be initially created through the backup of the primary database. Once it is created and configured as standby, the dg is responsible for transmitting the redo data of the primary database to the standby database. The redo data received by the standby database through the application is consistent with the transactions of the primary database. I. In the first chapter of Standby database types, we briefly introduce Standby databases and know that they are generally divided into two categories: Physical standby and logical standby. At the same time, we briefly describe their respective features, next, let's take a deeper look at the relevant aspects: 1. physical standby we know that physical standby is exactly the same as the primary database (it can also be different by default, but it is not absolutely true). Dg maintains the physical standby database through the redo application. Generally, you can enable the function in read-only mode without restoring the application. If the flashback area is specified in the database, the function can be set to read-write temporarily. Redo application physical standby applies redo files through the Application archive file or directly from the standby system through the oracle recovery mechanism. The Restoration Operation belongs to the block-to-block application (do not understand? So we can understand block replication and copy the changed block in redo to standby ). If redo is being applied, the database cannot be open. The Redo application is the core of physical standby. It is necessary to understand its concept and principles. A special chapter will be provided later. After the Read-only mode is enabled in read-only mode, you can perform queries or backup operations in the standby database (reducing the pressure on the primary database in disguise ). At this time, the standby database can continue to receive redo data, but the operation will not be triggered until the database recovers the redo application. That is to say, the redo application cannot be executed in read-only mode. When a redo application is used, the database is definitely not enabled. If necessary, you can switch between the two states, such as applying redo first, then read-only, and then switching the database status and then applying redo, the same is true for databases. If the Read-write mode is enabled in read-write mode, the standby database suspends receiving redo data from the primary database and temporarily loses the disaster protection function. Of course, opening in read-write mode is not useless. For example, you may need to debug some data temporarily, but it is not convenient to operate in the official database, then you can temporarily set the standby database to read-write mode. After the operation, the database will flash back to the status before the operation (after the flash, Data Guard will automatically synchronize, standby ). Physical standby features Ø disaster recovery and high availability physical standby provides a sound and extremely efficient disaster recovery and high availability solution. Easier to manage switchover/failover role conversion and shorter planned or unplanned downtime. Data protection applications physical standby databases, and Dg can ensure that data is not lost even in the face of unpredictable disasters. As mentioned above, physical standby is based on block-to-block replication, so objects and statements are irrelevant. What is on the primary database and what is physical standby. By transferring backup tasks and query-only requests to physical standby, You can effectively save the cpu and I/o resources of the primary database. The redo application technology used to improve the performance of physical standby uses the underlying recovery mechanism, which can bypass the SQL-level code layer and thus achieve the highest efficiency. 2. Logical standby logical standby is logically the same as the primary database and may have different structures. Logical standby is consistent with the primary database through SQL applications. Because of this, logical standby can be opened in read-write mode, and you can access the logical standby database at any time. There are also advantages and disadvantages. Logical standby imposes operational restrictions on some data types and ddl. Features of logical standby: In addition to similar disaster recovery, high availability, and data protection mentioned in physical standby, it also has the following features: effective use of standby hardware resources in addition to disaster recovery, the logical standby database can also be used for other business needs. For example, you can create additional indexes and materialized views in the standby database to improve query performance and meet specific business needs. For example, create a new schema (the primary database does not exist) and execute ddl or dml operations in these schemas. The standby database can remain open when updating tables. In this case, these tables can be used for read-only access at the same time. This allows the logical standby database to be used for data protection and report operations at the same time, freeing the primary database from those report and query tasks, saving valuable CPU and I/O resources. Ø smooth upgrades, such as cross-version upgrades and small patching, should be said that the application space is very large, but the risk is very small (if you have enough technical strength. In addition, although physical standby can also implement some upgrade operations, I am afraid it will not be able to cope with cross-platform operations, so this item will not be listed as a feature of physical standby ), I personally think this is a recommended online smooth and rolling upgrade method. II. The Data Guard operation interface (mode) is an important feature in the oracle environment. oracle provides multiple methods to set up, operate, manage, and maintain Data Guard configurations, such: oracle Enterprise Manager (Oracle Enterprise Manager) Orcale EM provides a window-based management method. Basically, you only need a few clicks to complete operations such as Configuration Management and Maintenance of dg, the essence is to call a manager specifically provided by oracle for dg: Data Guard Broker to implement management operations. Sqlplus command line management, mainly used in this series of articles. Don't be intimidated when you hear the command line. There are not many data guard management commands. You just need to move a little bit out of your head to remember it. DGMGRL (Data Guard broker command line) is Data Guard Broker, but it is a command line operation. I don't feel like using parameterized parameters as an operation method to initialize the parameter file. It should be said that here, through parameter initialization, more flexible Data Guard configuration is provided. Iii. Data Guard software and hardware requirements 1. Hardware and operating system requirements all oracle databases in the same Data Gurid configuration must run on the same platform. For example, the 32-bit linux System in the inter architecture can form a set of Data Guard with the 32-bit linux System in the inter architecture. In addition, a 64-bit HP-UX can also form a set of Data Guard with a 32-bit HP-UX if the server is running on 32-bit. The hardware configurations of different servers can be different, such as cpu, memory, and storage devices. However, ensure that the standby database server has enough disk space to receive and apply redo data. The operating system of the primary database and the standby database must be the same, but the operating system version may be slightly different. For example (linux as4 & linux as5), the directory paths of the primary database and the standby database can also be different. 2. software requirements Data Guard is a feature of Oracle Enterprise Edition. You can see that the Standard Edition is not supported. The SQL application of Data Guard allows you to roll up the server database version (the database version before the upgrade is not earlier than 10.1.0.3 ). All Database initialization parameters in the same Data Guard configuration: COMPATIBLE values must be the same. The Primary database must run in archive mode, and be sure to enable force logging on the primary database to prevent the user from using nologging and other methods to avoid writing redo and the corresponding operations cannot be transmitted to the standby database. Both the Primary and standby databases can be applied to a single instance or RAC architecture, and the same data guard configuration can be used in combination with logical standby and physical standby. The Primary and standby databases can be on the same server, but you need to pay attention to their respective data file storage directories to avoid rewriting or overwriting. Use a user with sysdba system permissions to manage the primary and standby databases. We recommend that the database adopt the same storage architecture. For example, if ASM/OMF is used for storage, ASM/OMF is also required for both primarty and standby. In addition, it is very important to note that the time settings of each server should not cause synchronization problems due to the inconsistent Time Zone/time settings. 4. distinguish between the redo logs (Online Redo Logs, Archived Redo Logs, and Standby Redo Logs) and the black and black redo LOGS. You must have been dizzy and spoke many times. Well, to be honest, it's also painful for me to describe it. This is an invitation between Chinese and English. I can't talk too much about it. Otherwise, you may not know what people are talking about after reading this article and reading the related concepts of other documents. You may not be able to do this kind of wrong things, but I certainly don't want to be subjective). What's more, I 've also been mistaken for xxxxxxxxxxxxxxxxxxx times (X = 9, we are determined not to suffer as much hardship as we do. The hard-to-solve DDMM were once again read one hundred times and one hundred times for reading the document. However, when the key time is reached, the redo will not be clearly mixed here, and the latter will have to be mixed by the redo, so here I want to use all my saliva + all my understandings of the system so far, and give everyone a simple vernacular. REDO ). What to redo? Why do we need to redo it? Redo is oracle's processing mechanism for operations. Our operation data (add volume change) is not directly reflected in data files, but first recorded (online redo log Hello ), when the appropriate time is reached, the corresponding process operations are submitted to the data file (details can be seen: the trigger conditions and logic in the data write process ). Do you want to say that if you save all online redo logs, isn't it equivalent to having all the operations performed by the database? En, I can tell you very responsibly that you are right. oracle has come along with you and implemented it. This is archived redo logs, or archive log for short. Let's look back at Data Guard. Because the Data in the standby database usually comes from the primary database, how can we get the redo of the primary database through the RFS process and save it locally, standby redo logs Hello (if the arch mode is used, do not write standby redo and directly Save the archive). Then, the related processes of the standby database read the received redo data and write it into the standby database. How is the data generated after being saved? Two ways are physical standby through redo applications and logical standby through SQL applications. What is the application of physical standby? Is the content in the redo log (archived redo logs is applied by default, if real-time applications are enabled, they are directly read from standby redo logs, that is the redo application and SQL application mechanism (maybe we will talk about this topic in depth later, which is complicated and interesting ). We will try to sum up the above content to see if we can draw some conclusions: for the primary database and the logical standby database, the online redo log file is definitely necessary, is redo log required for physical standby? After all, physical standby usually does not have write operations, so physical standby should not generate redo data. To ensure the consistency of database transactions, archive is required, that is to say, both primary and standby must run in the archive mode. Standby redo logs is a standby database-specific file (IF configured). Its features, such as file storage and configuration features, are similar to those of online redo logs, however, it stores the redo data received from the primary database, while the online redo logs records the Operation Records on the local machine. Part 2 Physical standby (1) creation step 1. Preparations regardless of physical standby or logical standby, the initial creation depends on the primary database, because the most important part of the preparation work, is the configuration of the primary database. 1. Enable the Forced Logging mode to set the primary database to the force logging mode. Run the following statement: SQL> alter database force logging. Note: FORCE LOGGING must be known that some DDL statements can avoid writing redo logs by specifying the NOLOGGING clause (the purpose is to increase the speed, if the specified database is in force logging mode, the database records all operations except the temporary tablespace or temporary rollback segment and ignores specified parameters such as NOLOGGING. If a statement such as nologging is executed while executing force logging, force logging waits until all such statements are executed. Force logging is saved as a fixed parameter in the control file, so it is not affected by restart and other operations (only once). If you want to cancel, you can use the alter database no force logging statement to disable forced logging. 2. Create a password file (if it does not exist). Note that all databases in the same Data Guard configuration must have independent password files, in addition, the SYS users of all database servers in the same Data Guard configuration must have the same password to ensure smooth transmission of redo Data, because the redo transmission service transmits redo Data through authenticated network sessions, the session uses the SYS User Password contained in the password file for authentication. 3. Configure Standby Redo Log for the maximum protection and maximum availability mode, Standby database must be configured with standby redo log, and oracle recommends that all databases use the lgwr async mode for transmission, of course, you may not know what lgwr async is. It doesn't matter. You will soon know. Oracle recommends that you consider the standby redo log configuration when creating standby. Standby redo logs is very similar to online redo logs. It should be said that the two are just different service objects, and the command formats of other parameter attributes and even operations are almost the same, you can use the idea of creating online redo logs when designing standby redo logs, such as multiple file groups and multiple file redundancy in each group. In addition, oracle provides some standard suggestions: * Ensure that the file size of standby redo log is the same as that of the online redo log file of the primary database. * To create an appropriate log group, the number of standby redo log files is at least one more than the number of online redo log files in the primary database. The recommended number of standby redo log groups is based on the number of threads in the primary database (the number of threads here can be understood as the number of rac nodes in the rac structure ). There is a recommended formula for reference: (the number of log groups per Thread + 1) * The maximum number of threads. For example, the primary database has two threads, and each thread allocates two groups of logs, the number of standby log groups is recommended to be six. Using this formula can reduce the possibility of LGWR process lock on the primary database instance. Tip: the logical standby database may need to add more standby redo log files (or archive processes) depending on the workload, because the logical standby needs to write online redo log files at the same time. The Standby redo log operation method is almost the same as the online redo log operation method, except that a standby keyword needs to be specified during Creation or Deletion, for example, adding: ========================================================== ========================================================== ==================================== SQL> alter database add standby logfile group 4 ('e: \ ora10g \ oradata \ jsspdg \ STANDBYRD01.LOG ') size 20 M; SQL> alter database drop standby logfile group 4; ========================================================== ====================================== ========================================================== = In addition, in terms of reliability, it is recommended that standby redologs be created in the primary database. Once a switchover occurs, the normal operation of primary as standby is not affected. Verify that the standby redo log file group is successfully created. For example: ========================================================== ================================== SQL> SELECT GROUP #, THREAD #, SEQUENCE #, ARCHIVED, status from v $ STANDBY_LOG; ========================================================== ===================================4. Set the initialization parameters for the primary database, you need to define initialization parameters for several primary roles to control the redo transmission service, there are also several additional standby role parameters that need to be added to control the acceptance of redo databases and applications (switchover/failover after primary/standby roles may be exchanged, so we recommend that you All initial parameters are configured ). The following parameters are initialization parameters related to the primary role: DB_NAME must be the same for all databases in the same Data Guard. For example, DB_NAME = jsswebDB_UNIQUE_NAME specifies a unique name for each database. Once specified, this parameter will not change unless you modify it. For example: DB_UNIQUE_NAME = jsswebLOG_ARCHIVE_CONFIG this parameter uses the DG_CONFIG attribute to list all DB_UNIQUE_NAME (including primary db and standby db) in the same Data Guard, separated by commas. For example: LOG_ARCHIVE_CONFIG = \d G _ CONFIG = (jssweb, jsspdg) â CONTROL _ FILES: the path of the CONTROL file. The path for generating the LOG_ARCHIVE_DEST_n archive file. This parameter is very important, and there are a lot of attributes and sub-parameters (not listed here. I will explain it separately later. If you are curious, we recommend that you directly query the official oracle documentation. Chapter 14th of the Data guard White Paper specifically introduces the attributes of this parameter and the functions and settings of sub-parameters ). For example, LOG_ARCHIVE_DEST_1 = 'location = E: \ ora10g \ oradata \ jssweb VALID_FOR = (ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME = jssweb 'Log _ logs, the specified parameter value is ENABLE, the redo transmission service is allowed to transmit redo data to the specified path. This parameter has a total of four attribute values, with different functions. REMOTE_LOGIN_PASSWORDFILE we recommend that you set the parameter value to EXCLUSIVE or SHARED. Ensure that all db servers in the same Data Guard configuration have the same sys password. LOG_ARCHIVE_FORMAT specifies the format of the archive file. LOG_ARCHIVE_MAX_PRODUCESSES specifies the number of archiving processes (1-30). The default value is usually 4. The following parameters are related to the standby role. We recommend that you set them in the initialization parameters of the Primary database. In this way, after role transition (Primary is converted to Standby), the system can run normally: FAL_SERVER specifies a TNSNAMES, generally, the database corresponding to tnsnames is the primary role. For example, FAL_SERVER = jsswebFAL_CLIENT specifies a TNSNAMES. Generally, the database corresponding to this tnsnames is a standby role. For example: FAL_CLIENT = jsspdg: FAL is the abbreviation of Fetch Archived Log DB_FILE_NAME_CONVERT. This type of parameter is described many times during duplicate replication and table space transfer. This parameter and the parameter with the same name in the preceding content are used, the format is identical. LOG_FILE_NAME_CONVERT is the same as STANDBY_FILE_MANAGEMENT. If the data file of the primary database is modified (such as the new database, or the new database), modify the data file in standby according to the settings of this parameter. AUTO indicates automatic management. If it is set to MANUAL, MANUAL management is required. For example: STANDBY_FILE_MANAGEMENT = AUTO Note: The parameters listed above are only parameters that may be related to the primary/standby roles, and some basic parameters such as * _ dest, * _ size and other database-related parameters also need to be modified according to the actual situation during specific configuration. 5. Make sure that the DATABASE is in archive mode: SQL> archive log list; SQL> startup mount; SQL> alter database archivelog; SQL> ALTER DATABASE OPEN; 2. manually create physical standby1 and backup (manually copy data files or use RMAN) --- primary database operation 2. create a control file-use the following statement to create a control file for the standby database: SQL> alter database create standby controlfile as 'd: \ backup \ jsspdg01.ctl '; note: The control file usually requires multiple copies. You can either manually copy the above files or create several more files by using the command. In addition, make sure that the primary database does not have any structural changes (such as adding tablespaces) during the period when the standby database is created after the control file is created ), otherwise, problems may occur during synchronization between primary and standby. 3. create an initialization parameter file create a client initialization parameter file such as SQL> create pfile = 'd: \ backup \ initjsspdg. ora 'from spfile; modify the parameters in the initialization parameter file according to the actual situation. Pay attention to the attribute configuration of the primary and standby roles, and pay attention to the file path. 4. copy the file to the standby server in at least three parts: data file, control file, and modified initialization parameter file. Note the path. 5. Configure the standby database 1). Create a New OracleService (required in windows ). 2) create a password file. Ensure that the password is consistent with that of the primary database. 3). Configure the listener and start 4). Modify tnsnames. ora of primary and standby and add the corresponding Net Service names respectively. 5 ). create the initialization file on the server. 6. Start standby. As we mentioned earlier, physical standby can be opened in read-write mode in rare cases, in some cases, it can be enabled in read-only mode. Therefore, by default, it can be loaded to the mount status. SQL> startup mount; Start redo application SQL> alter database recover managed standby database disconnect from session; Start real-time application SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; prompt: the disconnect from session clause is not required. It is used to specify that the session automatically exits before the command operator after the application is started. If this clause is not specified, the current session will remain in the redo application, if you want to perform other operations, you can create only one connection. 7. If standby is stopped, the redo application should be stopped first. You can run the following statement: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CALCEL; then stop the standby Database SQL> SHUTDOWN IMMEDIATE. Of course, you have to directly shut down the database. dg is originally used for Disaster Tolerance. Don't say that you have stopped standby, that is, you are not afraid to directly unplug the power. Part 2 Physical standby (2) Creation example in order to minimize hardware requirements, the data guard created here is on the same machine, but its creation process is no different from that of multiple machines. The example for demonstration is sufficient. We configure the primary database and standby database in two phases, as shown below: 1. Configure the Primary database and related operations 1. confirm that the master database is in the archive mode SQL> archive log list; 2. Set the primary database to the FORCE LOGGING mode. Use the following statements: SQL> alter database force logging; 3. create the standby database Control File SQL> alter database create standby controlfile as 'd: \ backup \ jsspdg01.ctl '; 4. Create a primary database client initialization parameter file. Note: There are many modifications here. For convenience, we first create and modify pfile, and then re-create spfile through pfile, you can also use the alter system set command to directly modify the spfile content. SQL> create pfile from spfile; copy the initialization parameter file as the client initialization parameter file of the standby Database SQL> host copy e: \ ora10g \ product \ 10.2.0 \ db_1 \ database \ initjssweb. ora d: \ backup \ initjsspdg. ora modifies the client initialization parameter file and adds DB_UNIQUE_NAME = jssweb LOG_ARCHIVE_CONFIG = 'dg _ CONFIG = (jssweb, jsspdg) 'log_archive_dest_1 = 'location = E: \ ora10g \ oradata \ jssweb \ VALID_FOR = (ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME = jssweb 'log_archive_dest_2 = 'service = jsspdg Lgwr async VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = jsspdg 'Role = ENABLE role = EXCLUSIVE # -------- configure the parameters of the standby role for role conversion FAL_SERVER = jsspdg FAL_CLIENT = jssweb role = 'oradata \ jsspdg ', 'oradata \ jssweb' LOG_FILE_NAME_CONVERT = 'oradata \ jsspdg ', 'oradata \ jssweb' STANDBY_FILE_MANAGEMENT = auto SQL> shutdown imm Ediate SQL> create spfile from pfile = 'initjssweb. ora '; 5. copy the data file to the standby server (in a variety of ways, not detailed). Note that you need to copy all the data files, backup control file and client initialization parameter file 6. configuration of listener and net service names (Diverse methods, not detailed ). Restart listener after completion: 2. Standby Database Configuration and related operations 1. Create a New OracleService through ORADIM 2. Create a password file. Ensure that the sys password is consistent with the primary database. E: \ ora10g> orapwd file = e: \ ora10g \ product \ 10.2.0 \ db_1 \ database \ PWDjsspdg. ora password = verysafe entries = 30 3. Create the directory E: \ ora10g \ product \ 10.2.0 \ admin \ jsspdg> mkdir adump 4. copy the file, do not describe too much. 5. Add the following parameters to the initialization parameter file: db_unique_name = jsspdgLOG_ARCHIVE_CONFIG = 'dg _ CONFIG = (jssweb, jsspdg) 'db _ FILE_NAME_CONVERT = 'oradata \ JSS ', 'oradata \ jsspdg 'LOG _ FILE_NAME_CONVERT = 'oradata \ jssweb', 'oradata \ jsspdg' LOG _ ARCHIVE_FORMAT = log % t _ % s _ % R. arcLOG_ARCHIVE_DEST_1 = 'location = E: \ ora10g \ oradata \ jsspdg \ VALID_FOR = (ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME = jsspdg 'Log _ Role = ENABLE # --- the following parameters are used for role switching LOG_ARCHIVE_DEST_2 = 'service = jssweb lgwr async VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = jssweb 'Log _ ARCHIVE_DEST_STATE_2 = ENABLEREMOTE_LOGIN_PASSWORDFILE = EXCLUSIVEFAL_SERVER = jsswebFAL_CLIENT = jsspdgSTANDBY_FILE_MANAGEMENT = AUTO Note: At the same time, modify the * _ dest path and use this pfile to create spfile SQL> create spfile from pfile = 'd: \ backup \ initjsspdg. ora '; 6. Start standby to mount SQL> startup mount; 7. Start the redo application SQL> alter database recover managed standby database disconnect from session; 8. To view synchronization information, first connect to the primary database SQL> show parameter instance_name; NAME TYPE VALUE ---------------------------------- instance_name string j Ssweb SQL> alter system switch logfile; the system has been changed. SQL> select max (sequence #) from v $ archived_log; MAX (SEQUENCE #) ------------ 51 connect to standby Database SQL> show parameter instance_name; name type value suspend ----------- pause instance_name string jsspdg SQL> select max (sequence #) from v $ archived_log; MAX (SEQUENCE #) -------------- 51 9. Pause the redo application through the following statement. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; note: this is only a temporary redo application. Instead of stopping the Standby DATABASE, standby will still keep receiving but will not apply the received archive, until you start the redo application again.