[20170215]再次理解flush redo.txt

[20170215]再次理解flush redo.txt

--链接:
http://blog.itpub.net/267265/viewspace-1992583/
http://blog.itpub.net/267265/viewspace-1992840/

在Oracle 11g里,Data Guard 切换多了一个新的功能:flush redo。

flush redo就是出现问题时,Flush可以把没有发送的redo从主库传送到standby数据库。而只要主库能启动到mount状态,那么Flush 就可
以把没有发送的归档和current online redo 发送到备库。

Flush语法:

SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;

这里的target_db_name 是我们在主库的db_unique_name 名称。 Flush 会将未发送的redo 从主库
传到备库,并且等待redo 在standby 库上apply 之后返回成功。 所以只要Flush成功,那么Failover 就没有主句丢失。

--//我前面的测试target_db_name必须加引号,只所以回头看文档主要春节前在解决一套容灾系统时,发现许多我不习惯的做法,
--//没有fal等参数,而且db_unique_name两边是一样的,感觉很不规范.我一直认为在dg中每个都应该分配一个不同的db_unique_name.

--//再仔细看这篇文件,使用的是db_unique_name.
--//顺便提一下oracle的name缺省很容易混淆,特别是概念不清晰的情况下.而且许多情况下都是一样的.

--//以后学习还是给认真看oracle 官方文档为准.
http://docs.oracle.com/cd/E11882_01/server.112/e41134/sql_stmts.htm#SBYDB5117
ALTER SYSTEM FLUSH REDO TO target_db_name [[NO] CONFIRM APPLY]
   
This statement flushes redo data from a primary database to a standby database and optionally waits for the flushed redo
data to be applied to a physical or logical standby database.

This statement must be issued on a mounted, but not open, primary database.

--//这里并没有指出target_db_name是什么?

http://docs.oracle.com/cd/E11882_01/server.112/e17766/e12700.htm
8.2.2 Performing a Failover to a Physical Standby Database

This section describes how to perform a failover to a physical standby database.

Step 1   Flush any unsent redo from the primary database to the target standby database.

If the primary database can be mounted, it may be possible to flush any unsent archived and current redo from the
primary database to the standby database. If this operation is successful, a zero data loss failover is possible even if
the primary database is not in a zero data loss data protection mode.

Ensure that Redo Apply is active at the target standby database.

Mount, but do not open the primary database. If the primary database cannot be mounted, go to Step 2.

Issue the following SQL statement at the primary database:

SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;

For target_db_name, specify the DB_UNIQUE_NAME of the standby database that is to receive the redo flushed from the
primary database.

This statement flushes any unsent redo from the primary database to the standby database, and waits for that redo to be
applied to the standby database.

If this statement completes without any errors, go to Step 5. If the statement completes with any error, or if it must
be stopped because you cannot wait any longer for the statement to complete, continue with Step 2.

--//这里明确的指出是DB_UNIQUE_NAME,好了现在重复测试.
1.环境:
SYS@book> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

--//停止备库.
--//在主库执行:
alter system archive log current ;
alter system archive log current ;
alter system archive log current ;
alter system archive log current ;
alter system archive log current ;
alter system archive log current ;

SYS@book> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /u01/app/oracle/archivelog/book
Oldest online log sequence     613
Next log sequence to archive   615
Current log sequence           615

--//当前seq=615.关闭主库.

2.测试flush redo前准备,主要配置不同的db_unique_name,验证target_db_name参数.
--//备库:
SYS@bookdg> startup nomount
ORACLE instance started.
Total System Global Area    634732544 bytes
Fixed Size                    2255792 bytes
Variable Size               197133392 bytes
Database Buffers            427819008 bytes
Redo Buffers                  7524352 bytes

SYS@bookdg> show parameter db_unique_name
NAME           TYPE   VALUE
-------------- ------ -------
db_unique_name string bookdg

--//修改db_unique_name为XXXX
SYS@bookdg> alter system set db_unique_name='XXXX' scope=spfile;
System altered.

SYS@bookdg> alter system set log_archive_config='DG_CONFIG=(book,bookdg,xxxx)';
System altered.

SYS@bookdg> alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/archivelog/book MANDATORY VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=xxxx' scope=spfile;
System altered.

--//重启备库到mount:
SYS@bookdg> shutdown immediate;
ORA-01507: database not mounted
ORACLE instance shut down.

SYS@bookdg> startup mount
ORACLE instance started.
Total System Global Area  634732544 bytes
Fixed Size                  2255792 bytes
Variable Size             197133392 bytes
Database Buffers          427819008 bytes
Redo Buffers                7524352 bytes
Database mounted.

SYS@bookdg> show parameter db_unique_name
NAME           TYPE    VALUE
-------------- ------- -----
db_unique_name string  XXXX

--//主库有一些参数也要修改,因为备库的db_unique_name已经修改
--//主库:
SYS@book> startup nomount
ORACLE instance started.
Total System Global Area  634732544 bytes
Fixed Size                  2255792 bytes
Variable Size             197133392 bytes
Database Buffers          427819008 bytes
Redo Buffers                7524352 bytes

SYS@book> alter system set log_archive_config='DG_CONFIG=(book,bookdg,xxxx)';
System altered.

SYS@book> show parameter log_archive_dest_2
NAME               TYPE   VALUE
------------------ ------ ----------------------------------------------------------------------------------------------------
log_archive_dest_2 string SERVICE=bookdg LGWR ASYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bookdg
--//这里也要修改为:
SYS@book> alter system set log_archive_dest_2='SERVICE=bookdg LGWR ASYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=xxxx' scope=spfile;
System altered.

--//关闭启动到mount状态.
SYS@book> shutdown immediate ;
ORA-01507: database not mounted
ORACLE instance shut down.

SYS@book> startup mount
ORACLE instance started.
Total System Global Area  634732544 bytes
Fixed Size                  2255792 bytes
Variable Size             197133392 bytes
Database Buffers          427819008 bytes
Redo Buffers                7524352 bytes
Database mounted.

3.测试flush redo功能:
SYS@book> ALTER SYSTEM FLUSH REDO TO bookdg;
ALTER SYSTEM FLUSH REDO TO bookdg
                           *
ERROR at line 1:
ORA-00922: missing or invalid option

SYS@book> ALTER SYSTEM FLUSH REDO TO XXXX;
ALTER SYSTEM FLUSH REDO TO XXXX
                           *
ERROR at line 1:
ORA-00922: missing or invalid option
--//oracle 官方并没有提到这里要使用引号.^_^.我估计这里如果dg存在多个,应该这样写:ALTER SYSTEM FLUSH REDO TO 'dg1,dg2';

SYS@book> ALTER SYSTEM FLUSH REDO TO 'bookdg';
ALTER SYSTEM FLUSH REDO TO 'bookdg'
*
ERROR at line 1:
ORA-16053: DB_UNIQUE_NAME  is not in the Data Guard Configuration
=========================================
$ oerr ora 16053
16053, 00000, "DB_UNIQUE_NAME %s is not in the Data Guard Configuration"
// *Cause:  The specified DB_UNIQUE_NAME is not in the Data Guard
//          Configuration.
// *Action: If the DG_CONFIG attribute of the LOG_ARCHIVE_CONFIG parameter
//          is enabled, you must specify a valid DB_UNIQUE_NAME.  The list
//          of valid DB_UNIQUE_NAMEs can be seen with the V$DATAGUARD_CONFIG
//          view.  This problem can also occur when specifying a non-standby
//          destination with an DB_UNIQUE_NAME attribute that does not match
//          the DB_UNIQUE_NAME initialization parameter for the current
//          instance.
=========================================
--//因为找到合适的log_archive_dest_N,执行失败.

SYS@book> ALTER SYSTEM FLUSH REDO TO 'xxxx';
ALTER SYSTEM FLUSH REDO TO 'xxxx'
*
ERROR at line 1:
ORA-16447: Redo apply was not active at the target standby database

$ oerr ora 16447
16447, 00000, "Redo apply was not active at the target standby database"
// *Cause:  ALTER SYSTEM FLUSH REDO TO STANDBY failed because redo apply
//          is not active at the target database.
// *Action: Start redo apply at the standby database and reissue the
//          ALTER SYSTEM FLUSH REDO TO STANDBY statement, or reissue the
//          ALTER SYSTEM FLUSH REDO TO STANDBY statement with the
//          NO CONFIRM APPLY clause.

--//检查主库alert日志:
Wed Feb 15 15:33:34 2017
ALTER SYSTEM FLUSH REDO TO 'xxxx' CONFIRM APPLY
ALTER SYSTEM FLUSH REDO TO xxxx CONFIRM APPLY [Process Id: 28538] (book)
Flush redo: No wait for non-current ORLs to be archived
Waiting for all FAL entries to be archived...
All FAL entries have been archived.
Waiting for dest_id 2 to become synchronized...
Wed Feb 15 15:33:37 2017
ARC0: Standby redo logfile selected for thread 1 sequence 607 for destination LOG_ARCHIVE_DEST_2
Active, synchronized flush redo target has been identified
Recovery is not running at physical standby 'LOG_ARCHIVE_DEST_2'.
If this standby is the target, please startmanaged standby recovery at the target and re-issueFLUSH REDO command

--//检查备库日志
Wed Feb 15 15:33:37 2017
RFS[1]: Assigned to RFS process 19369
RFS[1]: Selected log 4 for thread 1 sequence 607 dbid 1337401710 branch 896605872
RFS[1]: Opened log for thread 1 sequence 608 dbid 1337401710 branch 896605872
Wed Feb 15 15:33:38 2017
Archived Log entry 445 added for thread 1 sequence 607 ID 0x4fb7d86e dest 1:
Archived Log entry 446 added for thread 1 sequence 608 rlc 896605872 ID 0x4fb7d86e dest 2:
RFS[1]: Opened log for thread 1 sequence 609 dbid 1337401710 branch 896605872
Archived Log entry 447 added for thread 1 sequence 609 rlc 896605872 ID 0x4fb7d86e dest 2:
RFS[1]: Opened log for thread 1 sequence 610 dbid 1337401710 branch 896605872
Archived Log entry 448 added for thread 1 sequence 610 rlc 896605872 ID 0x4fb7d86e dest 2:
RFS[1]: Opened log for thread 1 sequence 611 dbid 1337401710 branch 896605872
Archived Log entry 449 added for thread 1 sequence 611 rlc 896605872 ID 0x4fb7d86e dest 2:
RFS[1]: Opened log for thread 1 sequence 612 dbid 1337401710 branch 896605872
Archived Log entry 450 added for thread 1 sequence 612 rlc 896605872 ID 0x4fb7d86e dest 2:
RFS[1]: Opened log for thread 1 sequence 613 dbid 1337401710 branch 896605872
Archived Log entry 451 added for thread 1 sequence 613 rlc 896605872 ID 0x4fb7d86e dest 2:
RFS[1]: Opened log for thread 1 sequence 614 dbid 1337401710 branch 896605872
Archived Log entry 452 added for thread 1 sequence 614 rlc 896605872 ID 0x4fb7d86e dest 2:

--//说明:最后seq=614,归档的日志已经传输到备库.而online redo没有传输,从主库的alert提示看,没有打开传输设置.
--//备注:我以前的测试成功是因为使用dgmgrl管理dg.

--//在备库执行,打开传输与应用日志模式:
SYS@bookdg> alter database recover managed standby database using current logfile disconnect ;
Database altered.

--//检查备库日志
Wed Feb 15 15:37:45 2017
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (bookdg)
Wed Feb 15 15:37:46 2017
MRP0 started with pid=24, OS id=19373
MRP0: Background Managed Standby Recovery process started (bookdg)
started logmerger process
Wed Feb 15 15:37:52 2017
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Completed: alter database recover managed standby database using current logfile disconnect
Media Recovery Log /u01/app/oracle/archivelog/book/1_607_896605872.dbf
Media Recovery Log /u01/app/oracle/archivelog/book/1_608_896605872.dbf
Media Recovery Log /u01/app/oracle/archivelog/book/1_609_896605872.dbf
Media Recovery Log /u01/app/oracle/archivelog/book/1_610_896605872.dbf
Media Recovery Log /u01/app/oracle/archivelog/book/1_611_896605872.dbf
Media Recovery Log /u01/app/oracle/archivelog/book/1_612_896605872.dbf
Media Recovery Log /u01/app/oracle/archivelog/book/1_613_896605872.dbf
Media Recovery Log /u01/app/oracle/archivelog/book/1_614_896605872.dbf
Media Recovery Waiting for thread 1 sequence 615
--//等待主库传输seq=615.

--//在主库执行:
SYS@book> ALTER SYSTEM FLUSH REDO TO 'XXxX';
System altered.

--//注意:引号里面大小写混用,也是ok的,说明db_unique_name可以大小写混用的,虽然不提倡.

--//检查备库日志
Wed Feb 15 15:40:16 2017
RFS[2]: Assigned to RFS process 19393
RFS[2]: Selected log 4 for thread 1 sequence 615 dbid 1337401710 branch 896605872
Wed Feb 15 15:40:16 2017
Archived Log entry 453 added for thread 1 sequence 615 ID 0x4fb7d86e dest 1:
Wed Feb 15 15:40:17 2017
Media Recovery Log /u01/app/oracle/archivelog/book/1_615_896605872.dbf
Wed Feb 15 15:40:17 2017
Standby switchover readiness check: Checking whether recoveryapplied all redo..
Identified End-Of-Redo (move redo) for thread 1 sequence 615 at SCN 0x3.1756ba81
Database not available for switchover
  End-Of-REDO archived log file has not been recovered
  Incomplete recovery SCN:3:391538419 archive SCN:3:391559809
Physical Standby did not apply all the redo from the primary.
Resetting standby activation ID 1337448558 (0x4fb7d86e)
Media Recovery Waiting for thread 1 sequence 616
Wed Feb 15 15:40:19 2017
Standby switchover readiness check: Checking whether recoveryapplied all redo..
Physical Standby applied all the redo from the primary.

SYS@bookdg> @ &r/dg/dg
PROCESS       PID STATUS       CLIENT_P GROUP# THREAD#  SEQUENCE#     BLOCK#     BLOCKS DELAY_MINS
--------- ------- ------------ -------- ------ ------- ---------- ---------- ---------- ----------
RFS         19391 IDLE         ARCH     N/A          0          0          0          0          0
ARCH        19325 CLOSING      ARCH     4            1        615          1       1498          0
MRP0        19373 WAIT_FOR_LOG N/A      N/A          1        616          0          0          0

4.验证是否传输正确:
--//主库上执行:
SYS@book> set numw 12
SYS@book> @ &r/logfile ;
GROUP# STATUS     TYPE       MEMBER                           IS_ GROUP# THREAD# SEQUENCE#       BYTES BLOCKSIZE MEMBERS ARC STATUS     FIRST_CHANGE# FIRST_TIME          NEXT_CHANGE# NEXT_TIME
------ ---------- ---------- -------------------------------- --- ------ ------- --------- ----------- --------- ------- --- ---------- ------------- ------------------- ------------ -------------------
     1            ONLINE     /mnt/ramdisk/book/redo01.log     NO       1       1       614    52428800       512       1 YES INACTIVE     13276440300 2017-02-15 15:06:03  13276440307 2017-02-15 15:06:06
     2            ONLINE     /mnt/ramdisk/book/redo02.log     NO       2       1       615    52428800       512       1 YES CURRENT      13276440307 2017-02-15 15:06:06  13276461697 2017-02-15 15:40:15
     3            ONLINE     /mnt/ramdisk/book/redo03.log     NO       3       1       613    52428800       512       1 YES INACTIVE     13276440283 2017-02-15 15:05:50  13276440300 2017-02-15 15:06:03
     4            STANDBY    /mnt/ramdisk/book/redostb01.log  NO
     5            STANDBY    /mnt/ramdisk/book/redostb02.log  NO
     6            STANDBY    /mnt/ramdisk/book/redostb03.log  NO
     7            STANDBY    /mnt/ramdisk/book/redostb04.log  NO
7 rows selected.

SYS@book> alter system dump logfile '/mnt/ramdisk/book/redo02.log' validate;
System altered.

--//转储内容:
DUMP OF REDO FROM FILE '/mnt/ramdisk/book/redo02.log'
Opcodes *.*
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
VALIDATE ONLY
FILE HEADER:
    Compatibility Vsn = 186647552=0xb200400
    Db ID=1337401710=0x4fb7216e, Db Name='BOOK'
    Activation ID=1337448558=0x4fb7d86e
    Control Seq=33442=0x82a2, File size=102400=0x19000
    File Number=2, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000000615, SCN 0x0003175666f3-0xffffffffffff"
thread: 1 nab: 0x5db seq: 0x00000267 hws: 0x4 eot: 3 dis: 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
resetlogs count: 0x35711eb0 scn: 0x0000.000e2006 (925702)
prev resetlogs count: 0x3121c97a scn: 0x0000.00000001 (1)
Low  scn: 0x0003.175666f3 (13276440307) 02/15/2017 15:06:06
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
Enabled scn: 0x0000.000e2006 (925702) 11/24/2015 09:11:12
Thread closed scn: 0x0003.17566c5e (13276441694) 02/15/2017 15:23:11
Disk cksum: 0x184 Calc cksum: 0x184
Terminal recovery stop scn: 0x0000.00000000
Terminal recovery  01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 17 blocks
End-of-redo stream : Yes
Unprotected mode
Miscellaneous flags: 0x4800008
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
Zero blocks: 8
Format ID is 2
redo log key is a7f8a15237d6b5e7fe61cb4acdc6227b
redo log key flag is 5
Enabled redo threads: 1
END OF REDO DUMP
----- Redo read statistics for thread 1 -----
Read rate (SYNC): 748Kb in 0.01s => 73.10 Mb/sec
Total redo bytes: 748Kb Longest record: 2Kb, moves: 0/617 moved: 0Mb (0%)
Longest LWN: 8Kb, reads: 1192
Last redo scn: 0x0003.17566c5b (13276441691)
Change vector header moves = 103/1210 (8%)
----------------------------------------------

--//备库上执行:
SYS@bookdg> alter system dump logfile '/u01/app/oracle/archivelog/book/1_615_896605872.dbf' validate;
System altered.

--//转储内容:
DUMP OF REDO FROM FILE '/u01/app/oracle/archivelog/book/1_615_896605872.dbf'
Opcodes *.*
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
VALIDATE ONLY
FILE HEADER:
    Compatibility Vsn = 186647552=0xb200400
    Db ID=1337401710=0x4fb7216e, Db Name='BOOK'
    Activation ID=1337448558=0x4fb7d86e
    Control Seq=44808=0xaf08, File size=102400=0x19000
    File Number=4, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000000615, SCN 0x0003175666f3-0x00031756ba81"
thread: 1 nab: 0x5db seq: 0x00000267 hws: 0x5 eot: 0 dis: 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
resetlogs count: 0x35711eb0 scn: 0x0000.000e2006 (925702)
prev resetlogs count: 0x3121c97a scn: 0x0000.00000001 (1)
Low  scn: 0x0003.175666f3 (13276440307) 02/15/2017 15:06:06
Next scn: 0x0003.1756ba81 (13276461697) 02/15/2017 15:40:15
Enabled scn: 0x0000.000e2006 (925702) 11/24/2015 09:11:12
Thread closed scn: 0x0003.17566c5e (13276441694) 02/15/2017 15:23:11
Disk cksum: 0x1f22 Calc cksum: 0x1f22
Terminal recovery stop scn: 0x0000.00000000
Terminal recovery  01/01/1988 00:00:00
Most recent redo scn: 0x0003.1756ba80 (13276461696)
Largest LWN: 17 blocks
End-of-redo stream : Yes
Unprotected mode
Miscellaneous flags: 0x48000b9
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
Zero blocks: 8
Format ID is 2
redo log key is a7f8a15237d6b5e7fe61cb4acdc6227b
redo log key flag is 5
Enabled redo threads: 1
END OF REDO DUMP
----- Redo read statistics for thread 1 -----
Read rate (SYNC): 748Kb in 0.01s => 73.10 Mb/sec
Total redo bytes: 748Kb Longest record: 2Kb, moves: 0/617 moved: 0Mb (0%)
Longest LWN: 8Kb, reads: 1192
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last redo scn: 0x0003.17566c5b (13276441691)
Change vector header moves = 103/1210 (8%)
----------------------------------------------

--//因为主库还没有归档,从~内容看,应该没有问题.

5.总结:
1.写的有点长^_^.
2.ALTER SYSTEM FLUSH REDO TO target_db_name;中参数target_db_name里面是db_unique_name.并且要使用引号,另外我估计多个要写成类似
  ALTER SYSTEM FLUSH REDO TO 'xxxdg1,xxxdg2' 格式.
3.备库要设置在传输模式:
  alter database recover managed standby database using current logfile nt logfile disconnect ;
  或者
  alter database recover managed standby database disconnect from session ;
4.要好好看官方文档,比如fal*参数对应的是Oracle Net service name,开始不看文档我以为也是db_unique_name.
  http://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams088.htm
  而参数LOG_ARCHIVE_CONFIG里面的DG_CONFIG实际上DB_UNIQUE_NAME
  Specifies a list of up to 30 unique database names (defined with the DB_UNIQUE_NAME initialization parameter) for all
  of the databases in the Data Guard configuration.
  http://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams123.htm#REFRN10237
5.我感觉oracle不如把这个命令改写为:
  ALTER SYSTEM FLUSH REDO TO log_archive_dest_N;
  这样好理解.不容易错误.^_^.
6.实际上测试中总是磕磕绊绊,还遇到一个问题就是备库参数log_archive_dest_1中.如果最后的DB_UNIQUE_NAME=bookdg(与配置不一致)
  在启动备库时alert提示:
Wed Feb 15 11:37:49 2017
Using STANDBY_ARCHIVE_DEST parameter default value as ?/dbs/arch

--//这样传输的归档实际上在dbs目录
$ ls -l /u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/arch*
-rw-r-----  1 oracle oinstall 4608 2017-02-15 11:43:18 /u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/arch1_593_896605872.dbf
-rw-r-----  1 oracle oinstall 3584 2017-02-15 11:43:18 /u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/arch1_594_896605872.dbf
-rw-r-----  1 oracle oinstall 1024 2017-02-15 11:43:18 /u01/app/oracle/product/11.2.0.4/dbhome_1/dbs/arch1_595_896605872.dbf
--//配置本地归档可以不使用最后的DB_UNIQUE_NAME=XXXX.

7.最后我的观点,在配置dg中每个数据库配置不同的DB_UNIQUE_NAME有必要的.无论是备份还是管理都很有必要.
  而且规范的命令风格也很重要,像我们的灾备系统主库net 服务名xxxx,备库net 服务名yyyy,非常容易乱.
  而如果主库net服务名xxxx,备库net 服务名xxxxdg,不是很清晰明了.
  我一般建议配置数据库的ORACLE_SID不要超过6个字符,这样备库存在多个,我习惯的备库命令ORACLE_SID命名风格是xxxxxxd1,xxxxxxd2.
8.还原相关设置:

--//备库:
SYS@bookdg> alter system set log_archive_config='DG_CONFIG=(book,bookdg)';
System altered.

SYS@bookdg> alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/archivelog/book MANDATORY VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=bookdg' scope=spfile;
System altered.

SYS@bookdg> alter system set db_unique_name='bookdg' scope=spfile;
System altered.

--//主库:
SYS@book> alter system set log_archive_config='DG_CONFIG=(book,bookdg)';
System altered.

SYS@book> alter system set log_archive_dest_2='SERVICE=bookdg LGWR ASYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bookdg' ;
System altered.

时间: 2024-07-30 13:28:46

[20170215]再次理解flush redo.txt的相关文章

[20170209]理解pre_page_sga参数.txt

[20170209]理解pre_page_sga参数.txt --昨天测试pre_page_sga=true的情况: http://blog.itpub.net/267265/viewspace-2133198/ --//再次看看官方的定义: http://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams201.htm#REFRN10174 PRE_PAGE_SGA determines whether Oracle reads

[20150309]热备份与redo.txt

[20150309]热备份与redo.txt -- 最近一段时间看关于备份的书籍,提到热备份期间,如果对某块做dml操作,redo 日志里面是包含整个数据库,防止出现块分裂. -- http://blog.itpub.net/267265/viewspace-1441552/ --实际上仅仅第1次会做,后续的dml就不会做这样的操作,做一个测试例子: 1.测试环境: SCOTT@test> @ver1 PORT_STRING                    VERSION        B

[20161003]触发器与redo.txt

[20161003]触发器与redo.txt --对于触发器,我个人认为对于dba是最讨厌的东西,它使得维护变得困难,不小心就陷入陷阱里面. --我曾经跟开发讲过建立一个触发器相当于给表建立一个索引.除非万不得以不要建立触发器. --昨天看了一个例子,重复作者的测试来说明问题: http://orasql.org/2016/09/22/how-even-empty-trigger-increases-redo-generation/ 1.环境: SCOTT@test01p> @ ver1 POR

java中的对象引用问题的再次理解

对象|问题 测试程序:public class Test { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } public Test() { } public void call(Test t1,Test t2) { System.out.println("t1地址1="+t1); Test t3 =

再次理解C语言的变参

实在是令我很郁闷的事啊. 去年用了两天的时间恶补了一下变参,今天看到变参.发现头脑一篇空白,啥都不知道了.   古人有云:温故而知新.今日我就在看一遍,做个笔记了.   在 C 语言中,函数参数的 传递方式有值传和址传 . 值传是把实参的一个专用的.临时的复制值给被调函数中相应的形参 被调用函数使用.修改这个传来的复制值,不会影响实参的值 . 址传则 是把变量 ( 实参 ) 的地址传给被调函数 . 被调函数通过这个地址找到该变量的存放位置,直接对该地址中存放 的变量的内容进行存取操作 . 无论是

值类型、引用类型 再次理解

 重新理解一下C#中的值类型和引用类型,在以前读<C#高级编程(第三版)>时,也是粗略看了一下,没有在意,直到今天,重新认识了这个东西. 一.值类型:存储在堆栈中:引用类型:存储在托管对上: 二.值类型进行"="操作时,会创建值类型的复制版本: 值类型: int i = 20; int j= i; Console.WriteLine(string.Format("i={0}/tj={1}", i.ToString(), j.ToString())); /

[20120417]select生产redo.txt

select生成redo主要有几个原因,常见的主要是修改表记录太多,在commit后,由于记录已经不在数据缓存,在下次select时,再修改相关信息,称为快速提交. 做一个测试: 1.快速提交产生的: SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise

再次理解js中的call函数

a.call(b); 网上说明的版本比较多.有的说,是指针替换.有说,将a对象的方法加在b对象执行.官方说:什么对象替换什么对象.反正看了几个版本,尽管有具体的实例,看了我三次都没看懂它的具体含义.看过还是云里雾里的.后来发现,结合实验去理解非常好.   其实,换成自己能够接受的方式理解为好.a对象的方法应用到b对象上(函数apply的意思正好说明符合这样理解:a对象应用到b对象上去) a对象既然添加到b对象上了.那么b对象自然就拥有了a对象所有的内容.所有,b对象就继承了a对象了.结合自己编写

javascript中闭包概念与用法深入理解_javascript技巧

本文实例分析了javascript中闭包概念与用法.分享给大家供大家参考,具体如下: 1.问题的引出,什么时候会遇到闭包? 首先因为JS是没有块状作用域的,但是有函数作用域即函数作为了局部变量之间的界限,不同函数内的局部变量具有独立性, 因为JS没有块状作用域,笔者初学JS时,在事件的监听时,因为不理解JS中局部变量的作用域,犯过不少错误! (1)JS中的变量作用域 for(var i=0;i<9;i++) { } alert(i) //输出9 我们发现,虽然变量i是块状区域for()内的一个局