首頁 資料庫 mysql教程 11g使用非duplicate方式创建物理standby要注意的问题总结

11g使用非duplicate方式创建物理standby要注意的问题总结

Jun 07, 2016 pm 03:59 PM
使用 創建 方式 物理

在上篇博文中,使用了duplicate方式来创建物理standby http://blog.csdn.net/aaron8219/article/details/38434579 今天来说说在11g中采用非duplicate方式创建备库碰到的一些问题,并做个总结。 在10g中,通常可以使以下几种方法创建备库控制文件 RMAN backup

在上篇博文中,使用了duplicate方式来创建物理standby http://blog.csdn.net/aaron8219/article/details/38434579今天来说说在11g中采用非duplicate方式创建备库碰到的一些问题,并做个总结。

在10g中,通常可以使以下几种方法创建备库控制文件

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';

前两种生成的是备库控制文件的备份集,需要在nomount状态下,用RMAN命令restore,如:
SQL> startup nomount
RMAN> restore controlfile from 'c:\backup\xxxx';

而后两种是直接创建备库控制文件。一种是通过RMAN命令的方式,另一种是通过SQL命令的方式,创建出来的备库控制文件,可以直接复制到备库目标路径后用来启动备库到mount状态,如:
复制到C:\app\oracle\oradata\tc并冗余(CONTROL01.CTL,CONTROL02.CTL)后,可以直接在备库执行
SQL> startup mount --直接启动到mount状态,不需要RMAN恢复

但是在11g中,RMAN备份不再支持以“backup current controlfile for standby”或“include current controlfile for standby”来创建备库控制文件,虽然命令仍然可以执行成功,但是当你在备库恢复完控制文件并启动到mount状态下,你会发现这个控制文件依旧是主库的控制文件,如:
RMAN> restore controfile from 'c:\backup\xxxx';
RMAN> alter database mount;
SQL> select database_role from v$database;

DATABASE_ROLE
----------------
PRIMARY --注意,数据库角色是由控制文件决定的,这里是primary,说明是用主库控制文件启动的

如果没有注意到这点,那么当你恢复完数据库文件,并启用REDO APPLY的时候,就会报错,提示不是备用数据库。
所以,如果不是用duplicate方式来创建备库的话,要注意使用创建文件的方式直接生成备库控制文件,而不是生成RMAN备份集

上次使用了RMAN的duplicate方式来配置DG物理备库,那么这次就用非duplicate方式来做一次,其实步骤大致和10g是一致的,可以参考我以前搭建10g DG的博客,惟一不同的是,不再使用备份集来恢复备库控制文件

具体步骤(略),直接跳到完成数据库数据文件恢复后

--查看备库的日志文件

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

--对比一下主库的日志文件

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

由于主库没有创建备库日志文件,所以目前只有在线日志文件,共4组,分配给2个THREAD,每个THREAD使用2组,并且每组有2个MEMBER,一个放在+DATA,另一个放在+FRA

通过观察发现,此时在备库控制文件中记录的2个日志组位置,一个是通过LOG_FILE_NAME_CONVERT参数指定的从'+DATA/TC/ONLINELOG'转换到了'C:\APP\ORACLE\ORADATA\TC\',但是并没有指定过'+FRA/TC/ONLINELOGFILE',所以也就是现在看到的状态,+FRA那部分依然是主库的结构,但是备库是采用单实例本地磁盘的结构,并没有使用ASM磁盘组,那么这样2组日志,在备库应该怎么使用呢?

可以发现,其实此时在备库数据文件目录‘C:\APP\ORACLE\ORADATA\TC\’中,并没有生成‘GROUP_1.261.855057597’,‘GROUP_2.262.855057605’,‘GROUP_3.266.855058587’,‘GROUP_4.267.855058593’这4个在线日志文件,更别说是+FRA对应的4个文件了,即,在我们恢复数据库数据文件的时候,只会恢复数据文件和临时文件,那么应该如何创建这几个文件呢?

开始,我想到的是先把完全不可能存在的+FRA那组在线日志文件的内容,从备库控制文件中删除

SQL> alter database drop logfile '+FRA/tc/onlinelog/group_1.257.855057601';
alter database drop logfile '+FRA/tc/onlinelog/group_1.257.855057601'
*
第 1 行出现错误:
ORA-01514: 日志说明中出现错误: 没有此类日志
ORA-01517: 日志成员: '+FRA/tc/onlinelog/group_1.257.855057601'

很正常,因为并没有这个路径,就算有,ONLINE REDO LOG也不会在“RMAN> restore database;”命令中恢复

--尝试重建控制文件

SQL> oradebug setmypid
已处理的语句
SQL> alter database backup controlfile to trace;

数据库已更改。

SQL> oradebug tracefile_name
C:\APP\ORACLE\diag\rdbms\tcdg\tc\trace\tc_ora_1792.trc

用oradebug可以轻松地跟踪到具体的trace文件,而不需要执行复杂的sql查询语句

去目标路径打开这个tc_ora_1792.trc文件,可以发现创建控制文件的语句,这里选择NORESETLOGS,内容如下:

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "TC" NORESETLOGS FORCE LOGGING ARCHIVELOG
MAXLOGFILES 192
MAXLOGMEMBERS 3
MAXDATAFILES 1024
MAXINSTANCES 32
MAXLOGHISTORY 292


*** 2014-08-13 09:30:03.000
LOGFILE


*** 2014-08-13 09:30:04.265
GROUP 1 (
'C:\APP\ORACLE\ORADATA\TC\GROUP_1.261.855057597',
'+FRA/tc/onlinelog/group_1.257.855057601'
) SIZE 50M BLOCKSIZE 512,
GROUP 2 (
'C:\APP\ORACLE\ORADATA\TC\GROUP_2.262.855057605',
'+FRA/tc/onlinelog/group_2.258.855057607'
) SIZE 50M BLOCKSIZE 512,
GROUP 3 (
'C:\APP\ORACLE\ORADATA\TC\GROUP_3.266.855058587',
'+FRA/tc/onlinelog/group_3.259.855058591'
) SIZE 50M BLOCKSIZE 512,
GROUP 4 (
'C:\APP\ORACLE\ORADATA\TC\GROUP_4.267.855058593',
'+FRA/tc/onlinelog/group_4.260.855058595'
) SIZE 50M BLOCKSIZE 512
-- STANDBY LOGFILE
-- GROUP 5 'C:\APP\ORACLE\ORADATA\TC\STB_REDO05.LOG' SIZE 50M BLOCKSIZE 512,
-- GROUP 6 'C:\APP\ORACLE\ORADATA\TC\STB_REDO06.LOG' SIZE 50M BLOCKSIZE 512,
-- GROUP 7 'C:\APP\ORACLE\ORADATA\TC\STB_REDO07.LOG' SIZE 50M BLOCKSIZE 512,
-- GROUP 8 'C:\APP\ORACLE\ORADATA\TC\STB_REDO08.LOG' SIZE 50M BLOCKSIZE 512,
-- GROUP 9 'C:\APP\ORACLE\ORADATA\TC\STB_REDO09.LOG' SIZE 50M BLOCKSIZE 512
DATAFILE


*** 2014-08-13 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
;

--去掉+FRA在线日志文件内容后,执行创建语句

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 50M BLOCKSIZE 512,
11 GROUP 2 (
12 'C:\APP\ORACLE\ORADATA\TC\GROUP_2.262.855057605'
13 ) SIZE 50M BLOCKSIZE 512,
14 GROUP 3 (
15 'C:\APP\ORACLE\ORADATA\TC\GROUP_3.266.855058587'
16 ) SIZE 50M BLOCKSIZE 512,
17 GROUP 4 (
18 'C:\APP\ORACLE\ORADATA\TC\GROUP_4.267.855058593'
19 ) SIZE 50M BLOCKSIZE 512
20 -- STANDBY LOGFILE
21 -- GROUP 5 'C:\APP\ORACLE\ORADATA\TC\STB_REDO05.LOG' SIZE 50M BLOCKSIZE
512,
22 -- GROUP 6 'C:\APP\ORACLE\ORADATA\TC\STB_REDO06.LOG' SIZE 50M BLOCKSIZE
512,
23 -- GROUP 7 'C:\APP\ORACLE\ORADATA\TC\STB_REDO07.LOG' SIZE 50M BLOCKSIZE
512,
24 -- GROUP 8 'C:\APP\ORACLE\ORADATA\TC\STB_REDO08.LOG' SIZE 50M BLOCKSIZE
512,
25 -- GROUP 9 'C:\APP\ORACLE\ORADATA\TC\STB_REDO09.LOG' SIZE 50M 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
*
第 1 行出现错误:
ORA-01503: CREATE CONTROLFILE 失败
ORA-01565: 标识文件 'C:\APP\ORACLE\ORADATA\TC\GROUP_1.261.855057597' 时出错
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。

本地路径对应的在线日志不存在,刚才也已经说明了,那么是不是要把控制文件中的LOGFILE整段都去掉呢?
这个我没有做测试,觉得应该不用这么复杂,确保主库远程归档路径没有ERROR后,直接在备库启用REDO APPLY

SQL> recover managed standby database disconnect from session
完成介质恢复。

此时查看日志文件的状态,会发现,备库会对在线日志文件做CLEARING操作,从第1组到第4组,逐个进行,直到清除完毕,在清除的同时,会在数据文件目录中创建在线日志文件。

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

可以看到,CLEARING操作更新了原来备库控制文件中错误的在线日志文件路径,并且在原来的基础上,又加了1组在线日组,并且会把还未使用到的日志组状态变成UNUSED。目前每个在线日志组有3个成员,一个在实例名tc下面,一个在DB_UNIQUE_NAME(TCDG)下面,另一个在FLASH_RECOVERY_AREA下面,这个可以通过查看v$logfile视图得到确认

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_1_9YOKQ7G5_.LOG
3 C:\APP\ORACLE\ORADATA\TC\GROUP_3.266.855058587
3 C:\APP\ORACLE\ORADATA\TCDG\ONLINELOG\O1_MF_3_9YOKRRJ3_.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_1_9YOKQC7T_.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

--查看数据文件

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

--查看临时文件

SQL> select file#,ts#,name from v$tempfile;

FILE# TS# NAME
---------- ---------- ------------------------------------------------------------
1 3 C:\APP\ORACLE\ORADATA\TCDG\DATAFILE\O1_MF_TEMP_9YOKLBG5_.TMP

注意默认是的临时文件存放位置是在TCDG下面,而不是tc,可以不做处理。但如果觉得别扭,可以先增加一个临时表空间,指定临时文件存放到tc目录下,然后再删除现有的临时表空间,注意删除的时候要指定including contents and datafiles,才会在删除表空间的时候连数据文件一起删除

最后,再做一个DG同步测试(注意执行各命令时的TIME)

--主库:

SQL> set time on; --为了使主备库两边的操作更加能说明问题,设置操作时间
10:47:59 SQL> archive log list
数据库日志模式 存档模式
自动存档 启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 53
下一个存档日志序列 54
当前日志序列 54
10:48:05 SQL> select group#,members,status from v$log;

GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 2 ACTIVE
2 2 CURRENT --当前CURRENT在group2,注意后面切换日志后的STATUS
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 YES
50 1 NO YES
51 1 YES YES
51 1 NO YES
52 1 YES YES
52 1 NO YES
53 1 NO YES
53 1 YES YES

10:49:35 SQL> create user zlm identified by aaron8219; --注意创建用户的时间,在备库是否能立即使用

用户已创建。

10:50:45 SQL> conn zlm/aaron8219
ERROR:
ORA-01045: 用户 ZLM 没有 CREATE SESSION 权限; 登录被拒绝

警告: 您不再连接到 ORACLE。
10:51:06 SQL> grant create session,resource to zlm;
SP2-0640: 未连接
10:51:37 SQL> conn /as sysdba
已连接。
10:51:43 SQL> grant create session,resource to zlm;

授权成功。

10:51:52 SQL> conn zlm/aaron8219
已连接。
10:51:59 SQL> create table test1(int number,name varchar2(10));

表已创建。

10:52:27 SQL> insert into test1 values(1,'aaron8219');

已创建 1 行。

10:52:48 SQL> commit;

提交完成。

10:53:13 SQL> alter system archive log current;
alter system archive log current
*
第 1 行出现错误:
ORA-01031: 权限不足

10:53:29 SQL> conn /as sysdba
已连接。
10:53:41 SQL> alter system archive log current; --有了这个操作,备库才会接受到主库变更,才能登陆zlm用户

系统已更改。

10:54:16 SQL> select group#,members,status from v$log;

GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 2 CURRENT --注意,由于是在节点1上做的操作,始终只会用到group1和group2这2个日志组
2 2 ACTIVE
3 2 INACTIVE
4 2 INACTIVE

10:55:32 SQL> drop user zlm;
drop user zlm
*
第 1 行出现错误:
ORA-01922: 必须指定 CASCADE 以删除 'ZLM'

10:57:05 SQL> drop user zlm cascade; --注意drop用户的时间,对照备库此时对该用户的操作情况

用户已删除。

10:57:16 SQL> conn zlm/aaron8219
ERROR:
ORA-01017: 用户名/口令无效; 登录被拒绝

警告: 您不再连接到 ORACLE。
10:58:32 SQL> alter system archive log current;
SP2-0640: 未连接
10:58:43 SQL> conn /as sysdba
已连接。
10:58:51 SQL> alter system archive log current; --备库从这个时间点开始,无法再连接到zlm用户,因为已删除

系统已更改。

10:59:23 SQL> select group#,members,status from v$log;

GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 2 ACTIVE
2 2 CURRENT --再次切换日志后,CURRENT又回到group2
3 2 INACTIVE
4 2 INACTIVE

10:59:29 SQL>

--备库:

SQL> set time on;
10:48:46 SQL> archive log list
数据库日志模式 存档模式
自动存档 启用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 53
下一个存档日志序列 0
当前日志序列 54
10:48:48 SQL> select group#,members,status from v$log;

GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 3 CLEARING
2 3 CURRENT --与主库一开始的STATUS对应,主库每切换一次,备库也切换一次
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 YES
51 1 YES YES
52 1 YES YES
53 1 YES YES

已选择8行。

10:50:00 SQL> conn zlm/aaron8219 --主库是在10:53:41时刻才切换日志的,早于该时间点,并没有zlm用户
ERROR:
ORA-01017: 用户名/口令无效; 登录被拒绝

警告: 您不再连接到 ORACLE。
10:53:59 SQL> conn zlm/aaron8219 --只有备库应用了主库切换的归档日志后,备库才能同步主库数据
已连接。
10:54:41 SQL> select * from test1;

INT NAME
---------- ------------------------------------------------------------
1 aaron8219

10:54:50 SQL> conn /as sysdba
已连接。
10:55:58 SQL> conn zlm/aaron8219
已连接。
10:56:21 SQL> select group#,members,status from v$log;
select group#,members,status from v$log
*
第 1 行出现错误:
ORA-00942: 表或视图不存在

10:56:33 SQL> conn /as sysdba
已连接。
10:56:44 SQL> select group#,members,status from v$log;

GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 3 CURRENT --此时主库已经发生过一次切换,所以CURRENT从group2到group1上
2 3 CLEARING
3 3 UNUSED
4 3 UNUSED

10:56:47 SQL> conn zlm/aaron8219
已连接。
10:57:56 SQL> select * from test1; --主库在10:57:05时刻进行了drop user,但zlm用户依然可以查询

INT NAME
---------- ------------------------------------------------------------
1 aaron8219

10:59:06 SQL> select * from test1; --主库在10:58:51时刻进行了日志切换,备库应用了这个归档,zlm无法查询
select * from test1
*
第 1 行出现错误:
ORA-00942: 表或视图不存在

10:59:46 SQL> conn zlm/aaron8219 --之后也无法继续连接zlm用户,因为删除用户的操作已经在备库生效
ERROR:
ORA-01017: 用户名/口令无效; 登录被拒绝

警告: 您不再连接到 ORACLE。
10:59:50 SQL> conn /as sysdba
已连接。
11:00:02 SQL> select group#,members,status from v$log;

GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 3 CLEARING
2 3 CURRENT --主库经过第2次切换日志后,备库在线日志又从group1回到了group2
3 3 UNUSED
4 3 UNUSED

11:00:05 SQL>

非duplicate方式搭建物理standby总结:

1.在11g中,用传统方法来创建备库可以和10g一样,但是要注意用直接创建文件的方式来生成备库控制文件,而不是用备份集。
2.开启REDO APPLY以后,会自动清除控制文件中旧的信息(这里指存放路径),并立即逐个生成ONLINE REDO LOGFILE,会在原来的基础上再多加一组在线日志。

3.和采用duplicate方式创建的备库结果一致,每组也是生成3个在线日志成员,惟一的区别就是在duplicate中必须用SET NEWNAME FOR TEMPFILE 1 TO 'C:\xxxx',来指定一个路径和文件名,否则会报冲突,无法完成duplicate。

4.需要拷贝主库密码文件到备库相应位置,而duplicate是自动在备库创建的,duplicate还能用spfile参数指定并在备库直接生成spfile,而普通方式在完成后需要手动创建一个spfile。

本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

<🎜>:泡泡膠模擬器無窮大 - 如何獲取和使用皇家鑰匙
3 週前 By 尊渡假赌尊渡假赌尊渡假赌
北端:融合系統,解釋
3 週前 By 尊渡假赌尊渡假赌尊渡假赌
Mandragora:巫婆樹的耳語 - 如何解鎖抓鉤
3 週前 By 尊渡假赌尊渡假赌尊渡假赌

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)

熱門話題

Java教學
1664
14
CakePHP 教程
1423
52
Laravel 教程
1321
25
PHP教程
1269
29
C# 教程
1249
24
crystaldiskmark是什麼軟體? -crystaldiskmark如何使用? crystaldiskmark是什麼軟體? -crystaldiskmark如何使用? Mar 18, 2024 pm 02:58 PM

CrystalDiskMark是一款適用於硬碟的小型HDD基準測試工具,可快速測量順序和隨機讀取/寫入速度。接下來就讓小編為大家介紹一下CrystalDiskMark,以及crystaldiskmark如何使用吧~一、CrystalDiskMark介紹CrystalDiskMark是一款廣泛使用的磁碟效能測試工具,用於評估機械硬碟和固態硬碟(SSD)的讀取和寫入速度和隨機I/O性能。它是一款免費的Windows應用程序,並提供用戶友好的介面和各種測試模式來評估硬碟效能的不同方面,並被廣泛用於硬體評

foob​​ar2000怎麼下載? -foobar2000怎麼使用 foob​​ar2000怎麼下載? -foobar2000怎麼使用 Mar 18, 2024 am 10:58 AM

foob​​ar2000是一款能隨時收聽音樂資源的軟體,各種音樂無損音質帶給你,增強版本的音樂播放器,讓你得到更全更舒適的音樂體驗,它的設計理念是將電腦端的高級音頻播放器移植到手機上,提供更便捷高效的音樂播放體驗,介面設計簡潔明了易於使用它採用了極簡的設計風格,沒有過多的裝飾和繁瑣的操作能夠快速上手,同時還支持多種皮膚和主題,根據自己的喜好進行個性化設置,打造專屬的音樂播放器支援多種音訊格式的播放,它還支援音訊增益功能根據自己的聽力情況調整音量大小,避免過大的音量對聽力造成損害。接下來就讓小編為大

BTCC教學:如何在BTCC交易所綁定使用MetaMask錢包? BTCC教學:如何在BTCC交易所綁定使用MetaMask錢包? Apr 26, 2024 am 09:40 AM

MetaMask(中文也叫小狐狸錢包)是一款免費的、廣受好評的加密錢包軟體。目前,BTCC已支援綁定MetaMask錢包,綁定後可使用MetaMask錢包進行快速登錄,儲值、買幣等,且首次綁定還可獲得20USDT體驗金。在BTCCMetaMask錢包教學中,我們將詳細介紹如何註冊和使用MetaMask,以及如何在BTCC綁定並使用小狐狸錢包。 MetaMask錢包是什麼? MetaMask小狐狸錢包擁有超過3,000萬用戶,是當今最受歡迎的加密貨幣錢包之一。它可免費使用,可作為擴充功能安裝在網絡

網易信箱大師怎麼用 網易信箱大師怎麼用 Mar 27, 2024 pm 05:32 PM

網易郵箱,作為中國網友廣泛使用的一種電子郵箱,一直以來以其穩定、高效的服務贏得了用戶的信賴。而網易信箱大師,則是專為手機使用者打造的信箱軟體,它大大簡化了郵件的收發流程,讓我們的郵件處理變得更加便利。那麼網易信箱大師該如何使用,具體又有哪些功能呢,下文中本站小編將為大家帶來詳細的內容介紹,希望能幫助到大家!首先,您可以在手機應用程式商店搜尋並下載網易信箱大師應用程式。在應用寶或百度手機助手中搜尋“網易郵箱大師”,然後按照提示進行安裝即可。下載安裝完成後,我們打開網易郵箱帳號並進行登錄,登入介面如下圖所示

百度網盤app怎麼用 百度網盤app怎麼用 Mar 27, 2024 pm 06:46 PM

在如今雲端儲存已成為我們日常生活和工作中不可或缺的一部分。百度網盤作為國內領先的雲端儲存服務之一,憑藉其強大的儲存功能、高效的傳輸速度以及便捷的操作體驗,贏得了廣大用戶的青睞。而且無論你是想要備份重要文件、分享資料,還是在線上觀看影片、聽取音樂,百度網盤都能滿足你的需求。但很多用戶可能對百度網盤app的具體使用方法還不了解,那麼這篇教學就將為大家詳細介紹百度網盤app如何使用,還有疑惑的用戶們就快來跟著本文詳細了解一下吧!百度雲網盤怎麼用:一、安裝首先,下載並安裝百度雲軟體時,請選擇自訂安裝選

如何在真我手機上建立資料夾? 如何在真我手機上建立資料夾? Mar 23, 2024 pm 02:30 PM

標題:真我手機新手指南:如何在真我手機上建立資料夾?在現今社會,手機已成為人們生活中不可或缺的工具。而真我手機作為一款備受歡迎的智慧型手機品牌,其簡潔、實用的作業系統備受用戶喜愛。在使用真實我手機的過程中,很多人可能會遇到需要整理手機中的檔案和應用程式的情況,而建立資料夾就是一種有效的方式。本文將介紹如何在真我手機上建立資料夾,幫助使用者更好地管理自己的手機內容。第

如何使用迅雷下載磁力鏈接 如何使用迅雷下載磁力鏈接 Feb 25, 2024 pm 12:51 PM

隨著網路科技的快速發展,我們的生活也得到了極大的便利,其中之一就是能夠透過網路下載和分享各種資源。而在下載資源的過程中,磁力連結成為了一種非常常見且方便的下載方式。那麼,迅雷磁力連結又是如何使用的呢?下面,我將給大家詳細介紹一下。迅雷是一款非常受歡迎的下載工具,它支援多種下載方式,其中包括磁力連結。磁力連結可以理解為一種下載位址,透過它我們可以取得資源的相關

格力+如何創造家庭 格力+如何創造家庭 Mar 01, 2024 pm 12:40 PM

很多朋友表示想知道在格力+軟體裡該怎麼去創建家庭,下面為大家帶來了操作方法,想要了解的朋友和我一起來看看吧。首先,開啟手機上的格力+軟體,並登入。接著,在頁面底部的選項列中,點選最右邊的「我的」選項,即可進入個人帳戶頁面。 2.來到我的頁面後,在“家庭”下方的選項裡有一個“創建家庭”,找到後在它的上面點擊進入。 3.接下來跳到建立家庭的頁面裡,根據提示在輸入框裡輸入要設定的家庭名稱,輸入好後在右上角點選「儲存」按鈕。 4.最後在頁面下方會彈出一個「儲存成功」的提示,代表家庭已經成功創建好了。

See all articles