In the previous blog, we used the duplicate method to create a physical standbyblog. csdn. netaaron8219articledetails38434579. Today we are talking about some problems encountered when using the non-duplicate method to create a slave database in 11g. In 10 Gb, the following methods can be used to create the backup Database Control File RMANbackup
In the previous blog, I used the duplicate method to create the physical standby http://blog.csdn.net/aaron8219/article/details/38434579. Today I will talk about some problems encountered in the 11g using the non-duplicate method to create the standby database, and make a summary. In 10 Gb, the following methods can be used to create the backup Database Control File RMAN backup
In the previous blog, duplicate is used to create a physical standbyHttp://blog.csdn.net/aaron8219/article/details/38434579Today, we will discuss some problems encountered when using the non-duplicate method to create a slave database in 11g, and make a summary.
In 10 Gb, the following methods can be used to create slave Database Control Files:
RMAN> backup current controlfile for standby format 'C: \ ctl _ % U ';
RMAN> backup full database format 'C: \ backup \ full _ % U' include current controlfile for standby;
RMAN> copy current controlfile for standby to 'C: \ backup \ control01.ctl ';
SQL> alter database create standby controlfile as 'C: \ backup \ control01.ctl ';
The first two types generate backup sets for the slave Database Control file. In the nomount state, run the RMAN command restore, for example:
SQL> startup nomount
RMAN> restore controlfile from 'C: \ backup \ xxxx ';
The other two methods are to directly create the slave Database Control File. One is through the RMAN command, and the other is through the SQL command, the Standby Database Control file is created, it can be directly copied to the target path of the slave database to start the slave database to the mount state, for example:
Copy to C: \ app \ oracle \ oradata \ tc and perform redundancy (CONTROL01.CTL, CONTROL02.CTL) in the slave database.
SQL> startup mount -- directly starts to the mount State and does not need to be restored by RMAN.
However, during the 11g period, RMAN backup does not support "backup current controlfile for standby" or "include current controlfile for standby" to create a backup database control file. Although the command can still be executed successfully, however, when you restore the control file in the slave database and start it to the mount state, you will find that the control file is still the control file of the master database, for example:
RMAN> restore controfile from 'C: \ backup \ xxxx ';
RMAN> alter database mount;
SQL> select database_role from v $ database;
DATABASE_ROLE
----------------
PRIMARY -- note that the database role is determined by the control file. Here is primary, which indicates that it is started with the master database control file.
If you do not notice this, an error will be reported when you recover the database file and enable redo apply, prompting that the database is not a backup database.
Therefore, if you do not use duplicate to create a backup database, you must use the File Creation Method to directly generate the backup database control file instead of generating the RMAN backup set.
The last time we used the duplicate method of RMAN to configure the physical standby database of DG, we will use the duplicate method for this time. In fact, the steps are basically the same as 10 Gb, refer to my previous blog building 10g DG. The only difference is that backup sets are no longer used to restore backup database control files.
Specific steps (Omitted): directly jump to after the database data file is restored
-- View the log file of the slave Database
SQL> set lin 120 pages 120
SQL> col member for a60
SQL> select group #, member from v $ logfile;
GROUP # MEMBER
----------------------------------------------------------------------
2 C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_2.262.855057605
2 + FRA/tc/onlinelog/group_2.258.855057607
1 C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_1.261.855057597
1 + FRA/tc/onlinelog/group_1.257.855057601
3 C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_3.266.855058587
3 + FRA/tc/onlinelog/group_3.259.855058591
4 C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_4.267.855058593
4 + FRA/tc/onlinelog/group_4.260.855058595
5 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO05.LOG
6 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO06.LOG
7 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO07.LOG
8 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO08.LOG
9 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO09.LOG
-- Compare the log files of the master database
SQL> set lin 120 pages 120
SQL> col member for a60
SQL> select group #, member from v $ logfile;
GROUP # MEMBER
----------------------------------------------------
2 + DATA/tc/onlinelog/group_2.262.855057605
2 + FRA/tc/onlinelog/group_2.258.855057607
1 + DATA/tc/onlinelog/group_1.261.855057597
1 + FRA/tc/onlinelog/group_1.257.855057601
3 + DATA/tc/onlinelog/group_3.266.855058587
3 + FRA/tc/onlinelog/group_3.259.855058591
4 + DATA/tc/onlinelog/group_4.267.855058593
4 + FRA/tc/onlinelog/group_4.260.855058595
Because no log files are created for the standby database in the master database, there are currently only online log files in four groups and two threads are allocated. Each THREAD uses two groups and each group has two MEMBER instances, put one on + DATA, and the other on + FRA
It is observed that the two log group locations recorded in the slave Database Control file are converted from '+ DATA/TC/ONLINELOG' specified by the LOG_FILE_NAME_CONVERT parameter to 'C: \ APP \ ORACLE \ ORADATA \ TC \ ', but' + FRA/TC/ONLINELOGFILE 'is not specified, so the current status is displayed, + FRA is still the structure of the master database, but the slave database uses a single-instance local disk structure and does not use the ASM disk group. In this case, the two groups of logs are as follows, how should I use the slave database?
In fact, 'Group _ 1.261.855057597 'is not generated in the data file directory 'C: \ APP \ ORACLE \ ORADATA \ TC \' of the standby database ', 'Group _ 2.262.855057605 ', 'Group _ 3.266.855058587', 'Group _ 4.267.855058593 ', let alone the four online log files corresponding to + FRA, when we restore database data files, we only restore data files and temporary files. How should we create these files?
At first, I thought of deleting the content of the online log files that are totally impossible + FRA from the backup database control file.
SQL> alter database drop logfile '+ FRA/tc/onlinelog/group_1.257.855057601 ';
Alter database drop logfile '+ FRA/tc/onlinelog/group_1.257.855057601'
*
Row 3 has an error:
Error in ORA-01514: log Description: no such log
ORA-01517: log Member: '+ FRA/tc/onlinelog/group_1.257.855057601'
It is normal because there is no such path. Even if there is, the online redo log will not be restored in the "RMAN> restore database;" command.
-- Try to recreate the control file
SQL> oradebug setmypid
Processed statements
SQL> alter database backup controlfile to trace;
The database has been changed.
SQL> oradebug tracefile_name
C: \ APP \ ORACLE \ diag \ rdbms \ tcdg \ tc \ trace \ tc_ora_1792.trc
With oradebug, you can easily track specific trace files without executing complex SQL query statements.
Open the tc_ora_1792.trc file in the target path. You can find the statement for creating the control file. Select NORESETLOGS as follows:
STARTUP NOMOUNT
Create controlfile reuse database "TC" NORESETLOGS FORCE LOGGING ARCHIVELOG
# MAXLOGFILES 192
MAXLOGMEMBERS 3
MAXDATAFILES 1024
MAXINSTANCES 32
# MAXLOGHISTORY 292
* ** 09:30:03. 000
LOGFILE
* ** 09:30:04. 265
GROUP 1 (
'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_1.261.855057597 ',
'+ FRA/tc/onlinelog/group_1.257.855057601'
) SIZE 50 m blocksize 512,
GROUP 2 (
'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_2.262.855057605 ',
'+ FRA/tc/onlinelog/group_2.258.855057607'
) SIZE 50 m blocksize 512,
GROUP 3 (
'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_3.266.855058587 ',
'+ FRA/tc/onlinelog/group_3.259.855058591'
) SIZE 50 m blocksize 512,
GROUP 4 (
'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_4.267.855058593 ',
'+ FRA/tc/onlinelog/group_4.260.855058595'
) SIZE 50 m blocksize 512
-- STANDBY LOGFILE
-- GROUP 5 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO05.LOG 'SIZE 50 m blocksize 512,
-- GROUP 6 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO06.LOG 'SIZE 50 m blocksize 512,
-- GROUP 7 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO07.LOG 'SIZE 50 m blocksize 512,
-- GROUP 8 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO08.LOG 'SIZE 50 m blocksize 512,
-- GROUP 9 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO09.LOG 'SIZE 50 m blocksize 512
DATAFILE
* ** 09:30:04. 765
'C: \ APP \ ORACLE \ ORADATA \ TC \ SYSTEM.256.855057451 ',
'C: \ APP \ ORACLE \ ORADATA \ TC \ SYSAUX.257.855057453 ',
'C: \ APP \ ORACLE \ ORADATA \ TC \ UNDOTBS1.258.855057453 ',
'C: \ APP \ ORACLE \ ORADATA \ TC \ USERS.259.855057453 ',
'C: \ APP \ ORACLE \ ORADATA \ TC \ EXAMPLE.264.855057687 ',
'C: \ APP \ ORACLE \ ORADATA \ TC \ UNDOTBS2.265.855058289'
Character set ZHS16GBK
;
-- After removing the content of the + FRA online log file, execute the create statement.
SQL> STARTUP NOMOUNT
SQL> CREATE CONTROLFILE REUSE DATABASE "TC" NORESETLOGS FORCE LOGGING ARCHIVELOG
2 MAXLOGFILES 192
3 MAXLOGMEMBERS 3
4 MAXDATAFILES 1024
5 MAXINSTANCES 32
6 MAXLOGHISTORY 292
7. LOGFILE
8 GROUP 1 (
9 'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_1.261.855057597'
10) SIZE 50 mb blocksize 512,
11 GROUP 2 (
12 'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_2.262.855057605'
13) SIZE 50 mb blocksize 512,
14 GROUP 3 (
15 'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_3.266.855058587'
16) SIZE 50 mb blocksize 512,
17 GROUP 4 (
18 'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_4.267.855058593'
19) SIZE 50 m blocksize 512
20 -- STANDBY LOGFILE
21 -- GROUP 5 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO05.LOG 'SIZE 50 M BLOCKSIZE
512,
22 -- GROUP 6 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO06.LOG 'SIZE 50 M BLOCKSIZE
512,
23 -- GROUP 7 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO07.LOG 'SIZE 50 M BLOCKSIZE
512,
24 -- GROUP 8 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO08.LOG 'SIZE 50 M BLOCKSIZE
512,
25 -- GROUP 9 'C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO09.LOG 'SIZE 50 M BLOCKSIZE
512
26. DATAFILE
27 'C: \ APP \ ORACLE \ ORADATA \ TC \ SYSTEM.256.855057451 ',
28 'C: \ APP \ ORACLE \ ORADATA \ TC \ SYSAUX.257.855057453 ',
29 'C: \ APP \ ORACLE \ ORADATA \ TC \ UNDOTBS1.258.855057453 ',
30 'C: \ APP \ ORACLE \ ORADATA \ TC \ USERS.259.855057453 ',
31 'C: \ APP \ ORACLE \ ORADATA \ TC \ EXAMPLE.264.855057687 ',
32 'C: \ APP \ ORACLE \ ORADATA \ TC \ UNDOTBS2.265.855058289'
33 character set ZHS16GBK
34;
Create controlfile reuse database "TC" NORESETLOGS FORCE LOGGING ARCHIVELOG
*
Row 3 has an error:
ORA-01503: create controlfile failed
Error in ORA-01565: identification file 'C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_1.261.855057597'
ORA-27041: Unable to open file
OSD-04002: Unable to open file
O/S-Error: (OS 2) the system cannot find the specified file.
The online log corresponding to the local path does not exist. As described earlier, do you want to remove the entire LOGFILE segment from the control file?
I did not perform the test and thought it should not be so complicated. After the remote archiving path of the master database does not have an ERROR, enable REDO APPLY directly in the slave database.
SQL> recover managed standby database disconnect from session
Media recovery is completed.
Check the log file status. The slave database performs the CLEARING operation on the online log files, from group 1st to group 4th, one by one until the log files are cleared, an online log file is created in the data file directory.
SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 3 CURRENT
2 3 CLEARING
3 2 INACTIVE
4 2 INACTIVE
SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 3 CURRENT
2 3 UNUSED
3 3 CLEARING
4 2 INACTIVE
SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 3 CURRENT
2 3 UNUSED
3 3 UNUSED
4 3 CLEARING
SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 3 CURRENT
2 3 UNUSED
3 3 UNUSED
4 3 UNUSED
As you can see, the CLEARING operation updates the path of the online log file that is incorrect in the control file of the original slave database, and adds a group of online log groups based on the original one, the status of UNUSED log groups is changed to UNUSED. Currently, each online log group has three members, one under the Instance name tc, the other under DB_UNIQUE_NAME (TCDG), and the other under FLASH_RECOVERY_AREA. You can check the v $ logfile view for confirmation.
SQL> col member for a70
SQL> select group #, member from v $ logfile;
GROUP # MEMBER
--------------------------------------------------------------------------------
2 C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_2.262.855057605
2 C: \ APP \ ORACLE \ ORADATA \ TCDG \ ONLINELOG \ O1_MF_2_9YOKR04W_.LOG
1 C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_1.261.855057597
1 C: \ APP \ ORACLE \ ORADATA \ TCDG \ ONLINELOG \ o1_mf_00009yokq7g5_.log
3 C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_3.266.855058587
3 C: \ APP \ ORACLE \ ORADATA \ TCDG \ ONLINELOG \ o1_mf_3_9yokr1_3_.log
4 C: \ APP \ ORACLE \ ORADATA \ TC \ GROUP_4.267.855058593
4 C: \ APP \ ORACLE \ ORADATA \ TCDG \ ONLINELOG \ O1_MF_4_9YOKSH5V_.LOG
5 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO05.LOG
6 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO06.LOG
7 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO07.LOG
8 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO08.LOG
9 C: \ APP \ ORACLE \ ORADATA \ TC \ STB_REDO09.LOG
1 C: \ APP \ ORACLE \ FLASH_RECOVERY_AREA \ TCDG \ ONLINELOG \ o1_mf_00009yokqc7t_.log
2 C: \ APP \ ORACLE \ FLASH_RECOVERY_AREA \ TCDG \ ONLINELOG \ O1_MF_2_9YOKRBMK_.LOG
3 C: \ APP \ ORACLE \ FLASH_RECOVERY_AREA \ TCDG \ ONLINELOG \ O1_MF_3_9YOKRY8S_.LOG
4 C: \ APP \ ORACLE \ FLASH_RECOVERY_AREA \ TCDG \ ONLINELOG \ O1_MF_4_9YOKSK5C_.LOG
-- View data files
SQL> select file #, ts #, name from v $ datafile;
FILE # TS # NAME
--------------------------------------------------------------------------------
1 0 C: \ APP \ ORACLE \ ORADATA \ TC \ SYSTEM.256.855057451
2 1 C: \ APP \ ORACLE \ ORADATA \ TC \ SYSAUX.257.855057453
3 2 C: \ APP \ ORACLE \ ORADATA \ TC \ UNDOTBS1.258.855057453
4 4 C: \ APP \ ORACLE \ ORADATA \ TC \ USERS.259.855057453
5 6 C: \ APP \ ORACLE \ ORADATA \ TC \ EXAMPLE.264.855057687
6 5 C: \ APP \ ORACLE \ ORADATA \ TC \ UNDOTBS2.265.855058289
-- View temporary files
SQL> select file #, ts #, name from v $ tempfile;
FILE # TS # NAME
--------------------------------------------------------------------------------
1 3 C: \ APP \ ORACLE \ ORADATA \ TCDG \ DATAFILE \ O1_MF_TEMP_9YOKLBG5_.TMP
Note that the default temporary file storage location is under TCDG, rather than tc, you can not process it. However, if you find it awkward, you can add a temporary tablespace, specify that the temporary files are stored in the tc directory, and then delete the existing temporary tablespace. Note that you must specify including contents and datafiles during deletion, to delete the tablespace together with the data file.
Finally, perform another DG synchronization test (note the TIME when each command is executed)
-- Master database:
SQL> set time on; -- in order to make the operations on both sides of the master and slave databases more descriptive, set the operation time
10:47:59 SQL> archive log list
Database Log mode archiving Mode
Enable automatic archiving
Archiving end point USE_DB_RECOVERY_FILE_DEST
The earliest online log sequence 53
Next archive log sequence 54
Current Log sequence 54
10:48:05 SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 2 ACTIVE
2 2 CURRENT -- the CURRENT is in group2. Pay attention to the STATUS after switching logs.
3 2 INACTIVE
4 2 INACTIVE
10:48:31 SQL> select sequence #, thread #, applied, archived fromv $ archived_log where sequence #> 49 order by 1;
SEQUENCE # THREAD # APPLIED ARC
--------------------------------
50 1 YES
50 1 NO YES
51 1 YES
51 1 NO YES
52 1 YES
52 1 NO YES
53 1 NO YES
53 1 YES
10:49:35 SQL> create user zlm identified by mongoon8219; -- pay attention to the time when the user is created, whether the standby database can be used immediately
The user has been created.
10:50:45 SQL> conn zlm/python8219
ERROR:
ORA-01045: User ZLM has no create session permission; login is denied
Warning: you are no longer connected to ORACLE.
10:51:06 SQL> grant create session, resource to zlm;
SP2-0640: not connected
10:51:37 SQL> conn/as sysdba
Connected.
10:51:43 SQL> grant create session, resource to zlm;
Authorization successful.
10:51:52 SQL> conn zlm/python8219
Connected.
10:51:59 SQL> create table test1 (int number, name varchar2 (10 ));
The table has been created.
10:52:27 SQL> insert into test1 values (1, 'on8219 ');
One row has been created.
10:52:48 SQL> commit;
Submitted.
10:53:13 SQL> alter system archive log current;
Alter system archive log current
*
Row 3 has an error:
ORA-01031: insufficient Permissions
10:53:29 SQL> conn/as sysdba
Connected.
10:53:41 SQL> alter system archive log current; -- with this operation, the slave database will receive the master database change before logging on to the zlm user
The system has been changed.
10:54:16 SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 2 CURRENT -- note that because operations are performed on node 1, only the two log groups group1 and group2 are used.
2 2 ACTIVE
3 2 INACTIVE
4 2 INACTIVE
10:55:32 SQL> drop user zlm;
Drop user zlm
*
Row 3 has an error:
ORA-01922: CASCADE must be specified to delete 'zlm'
10:57:05 SQL> drop user zlm cascade;
The user has been deleted.
10:57:16 SQL> conn zlm/python8219
ERROR:
ORA-01017: invalid username/password; login denied
Warning: you are no longer connected to ORACLE.
10:58:32 SQL> alter system archive log current;
SP2-0640: not connected
10:58:43 SQL> conn/as sysdba
Connected.
10:58:51 SQL> alter system archive log current; -- the slave database cannot be connected to the zlm user since it has been deleted
The system has been changed.
10:59:23 SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 2 ACTIVE
2 2 CURRENT -- after switching the log again, CURRENT returns to group2
3 2 INACTIVE
4 2 INACTIVE
10:59:29 SQL>
-- Slave database:
SQL> set time on;
10:48:46 SQL> archive log list
Database Log mode archiving Mode
Enable automatic archiving
Archiving end point USE_DB_RECOVERY_FILE_DEST
The earliest online log sequence 53
Next archived log sequence 0
Current Log sequence 54
10:48:48 SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 3 CLEARING
2 3 CURRENT -- corresponds to the STATUS at the beginning of the master database. Each time the master database is switched, the slave database also switches once.
3 3 UNUSED
4 3 UNUSED
10:49:07 SQL> select sequence #, thread #, applied, archived from v $ archived_log wher
E sequence #> 49 order by 1;
SEQUENCE # THREAD # APPLIED ARC
--------------------------------
50 1 YES
51 1 YES
52 1 YES
53 1 YES
Eight rows have been selected.
10:50:00 SQL> conn zlm/mongoon8219 -- the master database switches logs at 10:53:41. No zlm user
ERROR:
ORA-01017: invalid username/password; login denied
Warning: you are no longer connected to ORACLE.
10:53:59 SQL> conn zlm/mongoon8219 -- only after the archive log of the master database switch is applied to the slave database can the data of the master database be synchronized to the slave database.
Connected.
10:54:41 SQL> select * from test1;
INT NAME
----------------------------------------------------------------------
1 aaron8219
10:54:50 SQL> conn/as sysdba
Connected.
10:55:58 SQL> conn zlm/python8219
Connected.
10:56:21 SQL> select group #, members, status from v $ log;
Select group #, members, status from v $ log
*
Row 3 has an error:
ORA-00942: Table or view does not exist
10:56:33 SQL> conn/as sysdba
Connected.
10:56:44 SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 3 CURRENT -- at this time, the master database has been switched once, so CURRENT is from group2 to group1
2 3 CLEARING
3 3 UNUSED
4 3 UNUSED
10:56:47 SQL> conn zlm/python8219
Connected.
10:57:56 SQL> select * from test1; -- the master database performed drop user at 10:57:05, but zlm users can still query
INT NAME
----------------------------------------------------------------------
1 aaron8219
10:59:06 SQL> select * from test1; -- log switching is performed on the master database at 10:58:51. The slave database applies this archive, and zlm cannot query
Select * from test1
*
Row 3 has an error:
ORA-00942: Table or view does not exist
10:59:46 SQL> conn zlm/mongoon8219 -- The zlm user cannot be connected, because the operation to delete the user has taken effect in the slave database.
ERROR:
ORA-01017: invalid username/password; login denied
Warning: you are no longer connected to ORACLE.
10:59:50 SQL> conn/as sysdba
Connected.
11:00:02 SQL> select group #, members, status from v $ log;
GROUP # MEMBERS STATUS
------------------------------------
1 3 CLEARING
2 3 CURRENT -- after the master database switches logs for 2nd times, the online logs of the slave database are returned from group1 to group2.
3 3 UNUSED
4 3 UNUSED
11:00:05 SQL>
Summary:
1. In 11g, the traditional method to create a slave database can be the same as 10g, but note that you should generate a slave Database Control File by directly creating a file instead of using a backup set.
2. after redo apply is enabled, the old information in the control file is automatically cleared (the storage path here), and online redo logfile is generated one by one, A group of online logs will be added based on the original logs.
3. the results are consistent with those of the standby database created in duplicate mode. Each group also generates three online log members. The only difference is that set newname for tempfile 1 TO 'C: \ xxxx 'to specify a path and a file name. Otherwise, a conflict is reported and duplicate cannot be completed.
4. you need to copy the password file of the master database to the corresponding location of the slave database, while duplicate is automatically created in the slave database. duplicate can also be specified using the spfile parameter and generate spfile directly in the slave database, in normal mode, you need to manually create a spfile.
