怎么重新wwWee141CoM在找回来？是否能再次ee141恢复正常？_hospitalndnd_新浪博客
怎么重新wwWee141CoM在找回来？是否能再次ee141恢复正常？
有一段时间，我狂热喜欢上了古代地理学。我发现，由于古地名的专用名是单字，加上音调问题，直接译成英文以后，重名多得一塌糊涂。比如，河北有一个冀州，英文可直接译为“Jizhou”。但距它不远就还有一个蓟州（现在叫蓟县），东边邻省山东还有一个济州（现在叫济宁），南边邻省河南还有一个汲州（现在叫汲县），南方的江西还有一个吉州（现在叫吉安），译成英文完全一样！如果再找找发音基本相似的地方，那就更多了，比如辽宁锦州和金州、河北晋州和景州、湖北荆州、湖南靖州……真让外国汉学家晕死。
　　上面这个例子，生动说明了英文与中文的差别。有的网友总想把两者比较一下。中文有三四千个常用汉字。如果把汉字与26个字母比，汉字就太多了，如果把汉字与几十万（一说几百万）英文单词比，汉字又太少了。实际上，由于这两个文字体系完全不同，这两种比法都不是太有可比性。一定要比，就把汉语词汇与英文词汇比，还算基本对等。考虑到一个汉字就是一个汉语单音节，所以如果非得要在英文中找一个和汉字对等的东西，大概就是英文的单音节。比如英文单词“black”就是由b、la、ck三个单音节构成的。与之相对应的中文词汇“黑色”是由黑、色两个单音节构成的。我是外行，不知道构成英文单词的单音节总量是多少，有研究的兄弟赐教一下哈。
　　前几年，网上已经有一个热贴指出过，表达相同含义时，一般情况下中文使用的音节比英文使用的音节要少。也就是说，中文更简洁。
　　我仔细对照了一下，这个现象倒是客观存在。主要原因，可能是因为英文没有四个声调的问题。你用四个声调去跟人家喊“hello”，都是那个意思，最多是别人批评你发音不标准，怀疑是从伦敦郊区来的。可是汉语不一样，“包子”发平声，声调一改成了“豹子”，意思就全变了，就不是你吃它而是它吃你的问题了。声调再转转，还可以变成“刨子”、“孢子”、“雹子”等等。由于中文有四个声调，英语一个声音在汉语里当四个用，所以汉语相对简短，英语则必需增加几个音节以表达同样的意思。这就好比200这个数目，用二进制写出来是一长串，要比用十进制写出来长得多。
　　例如，汉语中的牛肉、羊肉、猪肉，是在牛、羊、猪加个肉字就行了。英文单词叫Beef、mutton、pork，但这些单词与英文中的牛、羊、猪（cattle、sheep、pig）没有字面上的直观联系，增加了学习和背记的难度。其实，英国人和人一样，也知道怎么造词方便。比如麻雀肉，英文也叫Sparrow
Meat，和中文一样。英文在牛肉、羊肉、猪肉上那样去另造新词，主要目的是为了追求简短。因为这三个词比麻雀肉可要常用的多，如果整天说cattlemeat、sheepmeat、pigmeat，实在是太冗长。所以，在这个方面，中文由于拥有四个声调和几千个常用汉字，组词时会比较沾光；而英文似乎在“好记”和“好读”两个目标上不易兼顾。在信息量和知识量爆炸的今天，词汇量也在爆炸式增长，这个困难可能会越发明显。
　　上面，我简单把以前见过的网上观点叙述了一下。我认为这些观点有一定道理。但是，我感觉，仅凭这些还远远不足以证明汉字会比英文优越。其实汉字也同样存在一些劣势。比如四个发音的存在，对语言使用者的发音要求会更高，出现误会的可能性会增加。
　　最后，我对汉字的评价和展望是：汉字与世界其他主要文字相比，并没有根本上的优劣之分，它是人类文字大家族中既与众不同、又与众不异的平等一员。在古代，汉字对和民族凝聚形成发挥了极其重要的作用。在今天，汉字已经彻底解决了与信息化时代兼容的问题。在未来，汉字的世界地位取决于的世界地位。如果说以前汉字成就了，未来则有待于去成就汉字。
hospitalndnd
博客等级：
博客积分：0
博客访问：30
关注人气：0
荣誉徽章：博客访问： 15178
博文数量： 14
注册时间：
认证徽章：
让学习成为一种习惯，加油！
分类： Oracle 16:39:45
一、知识回顾
1、正常情况我们在生产中配置ADG会使用最大可用模式配合参数lgwr和sync。
SQL& show parameter log_archive_dest_2
NAME&&&&&&&& TYPE& VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_2&&&&&& string&&& SERVICE=stdtest lgwr sync affi
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& rm VALID_FOR=(ONLINE_LOGFILES,
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& PRIMARY_ROLE) DB_UNIQUE_NAME=s
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& tdtest
这种配置在保证备库同步情况不影响主库的情况下最大限度的保证了主备的实时性。
SQL& select name,dbid,database_role,protection_mode from v$
NAME&&DBID DATABASE_ROLE&&& PROTECTION_MODE
--------- ---------- ---------------- --------------------
PRIMARY&&&&&& MAXIMUM AVAILABILITY
2、监控进程
SQL& SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
PROCESS&& CLIENT_P& SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH&& ARCH&&& 145 CLOSING
ARCH&& ARCH&&& 135 CLOSING
ARCH&& ARCH&&& 141 CLOSING
ARCH&& ARCH&&& 146 CLOSING
LGWR&& LGWR&&& 147 WRITING
SQL& SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
PROCESS&& CLIENT_P& SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH&& ARCH&&& 145 CLOSING
ARCH&& ARCH&&& 146 CLOSING
ARCH&& ARCH&&&&& 0 CONNECTED
ARCH&& ARCH&&& 144 CLOSING
RFS&& ARCH&&&&& 0 IDLE
RFS&& UNKNOWN&&&& 0 IDLE
RFS&& LGWR&&& 147 IDLE
RFS&& UNKNOWN&&&& 0 IDLE
MRP0&& N/A&&& 147 APPLYING_LOG
3、监控恢复操作的进程
SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# FROM V$ARCHIVE_DEST_STATUS;
ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#
---------------- ------------- --------------- ------------
&&&&&&& 1&&& 146&&&&&& 0&&& 0
&&&&&&& .......
&&&&&&& 1&&& 146&&&&&& 1&&146
32 rows selected.
4、回顾三种同步模式
4.1 最大保护模式（Maximum Protection）
1）这种模式提供了最高级别的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主库会自动关闭，防止未受保护的数据出现；
4）优点：该模式可以保证备库没有数据丢失；
5）缺点：主库的自动关闭会影响到主库的可用性，同时需要备库恢复后才能提交，对网络等客观条件要求非常的高，
&&&&&&&& 主库的性能会因此受到非常大的冲击。
4.2 最大可用性模式（Maximum Availability）
1）该模式提供了仅次于“最大保护模式”的数据保护能力；
2）要求至少一个物理备库收到重做日志后，主库的事务才能够提交；
3）主库找不到合适的备库写入时，主数据库不会关闭，在没有达到net_timeout之前主库会hang住，但是并不是shutdown。而后主数据库以
&& 最大性能模式运行直到故障消除，并且解决所有重做日志文件的中断。当所有中断解决之后，主数据库自动继续以最大可用性模式运行；
4）优点：该模式可以在没有问题出现的情况下，保证备库没有数据丢失，是一种折中的方法；
5）缺点：在正常运行的过程中缺点是主库的性能受到诸多因素的影响。
4.3 最大性能模式（Maximum Performance）
1）该模式是默认模式，可以保证主数据库的最高可用性；
2）保证主库运行过程中不受备库的影响，主库事务正常提交，不因备库的任何问题影响到主库的运行；
3）优点：避免了备库对主数据库的性能和可用性影响；
4）缺点：如果与主库提交的事务相关的恢复数据没有发送到备库，这些事务数据将被丢失，不能保证数据无损失。
二、主备库同步中断后，如何恢复同步
在很多场合下主从同步中断，如恢复同步可能会遇到很多不同情况，现根据几个场景做以下实验。
主备中断后，当主库归档日志完整，备库启动后会自动恢复
1、查看主备库日志情况
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
模拟备库故障，直接关机
SQL& shutdown abort
ORACLE instance shut down
SQL& alter s
System altered.
SQL& create table a (id integer);
Table created.
SQL& alter s
System altered.
SQL& insert into a values (11);
1 row created.
Commit complete.
SQL& alter s
System altered.
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
模拟排除故障，重新同步备库。
SQL& startup nomount
ORACLE instance started.
Total System Global Area
Fixed Size&&&&& 2252664 bytes
Variable Size&&&
Database Buffers&&
Redo Buffers&&&&& 9195520 bytes
SQL& alter database mo
Database altered.
SQL& alter database recover managed standby database using current logfile dis
Database altered.
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
由于主库归档日志都在，在备库故障期间的log file gap，会被归档的日志文件由arch进程负责传输到从数据库。
同时通过LNSn把归档日志传到备库，备库RFS接受，MRP进程应用到standby redo log。
查看日志应用情况。
SQL& select sequence#, applied from v$archived_
&SEQUENCE# APPLIED
---------- ---------
&68 IN-MEMORY
由于归档丢失或备库控制文件损坏等，需主库全量备份恢复
1、备库模拟宕机，直接关闭数据库
SQL& shutdown abort
ORACLE instance shut down.
2、在备库宕机期间主库做一些操作
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
SQL& create table b (name char(1));
Table created.
SQL& insert into b values ('a');
1 row created.
Commit complete.
SQL& alter s
System altered.
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
[oracle@pritest archivelog]$ pwd
/u01/app/oracle/archivelog
[oracle@pritest archivelog]$ ls -trl
-rw-r----- 1 oracle oinstall&& 444416 Nov 10 11:00 arch_1_69_.arc
-rw-r----- 1 oracle oinstall& 1224704 Nov 10 11:00 arch_1_70_.arc
-rw-r----- 1 oracle oinstall& 1097216 Nov 10 11:32 arch_1_71_.arc
-rw-r----- 1 oracle oinstall& 4003840 Nov 10 13:53 arch_1_72_.arc
3、主库删掉备库宕机期间产生的归档日志
[oracle@pritest archivelog]$ rm arch_1_7*
4、启动备库
由于归档日志丢失，备库不能直接恢复
SQL& startup nomount
ORACLE instance started.
Total System Global Area
Fixed Size&&&&& 2252664 bytes
Variable Size&&&
Database Buffers&&
Redo Buffers&&&&& 9195520 bytes
SQL& alter database mo
Database altered.
alter database open
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/u01/app/oracle/oradata/pritest/system01.dbf'
5、备份主库控制文件和做全备，并同步主库
SQL& alter database create standby controlfile as '/tmp/controldg01.ctl';
Database altered.
[oracle@pritest pritest]$ scp -r /tmp/controldg01.ctl
controldg01.ctl&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 100% 9808KB&& 9.6MB/s&& 00:00&&&
[oracle@pritest pritest]$ scp -r /tmp/controldg01.ctl
controldg01.ctl&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 100% 9808KB&& 9.6MB/s&& 00:00&
[oracle@pritest archivelog]$ rman target /
RMAN& backup database format '/u01/app/oracle/backup/full_%d_%T_%s_%U' plus archivelog FORMAT '/u01/app/oracle/backup/arc_%d_%s_%p.bak';
Starting backup at
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=38 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of backup plus archivelog command at 11/10/:13
RMAN-06059: expected archived log not found, loss of archived log compromises recoverability
ORA-19625: error identifying file /u01/app/oracle/archivelog/arch_1_7_.arc
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
RMAN& cross
。。。。。。
RMAN& delete ex
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=38 device type=DISK
List of Archived Log Copies for database with db_unique_name PRITEST
=====================================================================
Key&&&& Thrd Seq&&&& S Low Time&&&&&&&&&&
------- ---- ------- - -------------------
2&&&&&& 1&&& 7&&&&&& X
&&&&&&& Name: /u01/app/oracle/archivelog/arch_1_7_.arc
123&&&& 1&&& 70&&&&& X
&&&&&&& Name: /u01/app/oracle/archivelog/arch_1_70_.arc
124&&&& 1&&& 71&&&&& X
&&&&&&& Name: /u01/app/oracle/archivelog/arch_1_71_.arc
125&&&& 1&&& 72&&&&& X
&&&&&&& Name: /u01/app/oracle/archivelog/arch_1_72_.arc
Do you really want to delete the above objects (enter YES or NO)? yes
deleted archived log
archived log file name=/u01/app/oracle/archivelog/arch_1_7_.arc RECID=2 STAMP=
deleted archived log
archived log file name=/u01/app/oracle/archivelog/arch_1_70_.arc RECID=123 STAMP=
deleted archived log
archived log file name=/u01/app/oracle/archivelog/arch_1_71_.arc RECID=124 STAMP=
deleted archived log
archived log file name=/u01/app/oracle/archivelog/arch_1_72_.arc RECID=125 STAMP=
Deleted 4 EXPIRED objects
RMAN& backup database format '/u01/app/oracle/backup/full_%d_%T_%s_%U' plus archivelog FORMAT '/u01/app/oracle/backup/arc_%d_%s_%p.bak';
Starting backup at
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=81 RECID=141 STAMP=
channel ORA_DISK_1: starting piece 1 at
channel ORA_DISK_1: finished piece 1 at
piece handle=/u01/app/oracle/backup/arc_PRITEST_20_1.bak tag=TAG310 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at
RMAN& exit
[oracle@pritest backup]$ ll
total 1152500
-rw-r----- 1 oracle oinstall&&
Nov 10 15:42 arc_PRITEST_16_1.bak
-rw-r----- 1 oracle oinstall&&
Nov 10 15:42 arc_PRITEST_17_1.bak
-rw-r----- 1 oracle oinstall&&&&& 22528 Nov 10 15:43 arc_PRITEST_20_1.bak
-rw-r----- 1 oracle oinstall
Nov 10 15:43 full_PRITEST__0isj7ob8_1_1
-rw-r----- 1 oracle oinstall&&
Nov 10 15:43 full_PRITEST__0jsj7ocb_1_1
[oracle@pritest backup]$ pwd
/u01/app/oracle/backup
[oracle@pritest backup]$ scp -r ./*
arc_PRITEST_11_1.bak&&&&&&&&&&&&&&&&&&&&&&&&& 100%&& 69MB& 69.4MB/s&& 00:01&&&
arc_PRITEST_12_1.bak&&&&&&&&&&&&&&&&&&&&&&&&& 100%&& 23MB& 23.0MB/s&& 00:00&&&
arc_PRITEST_15_1.bak&&&&&&&&&&&&&&&&&&&&&&&&& 100%&& 40KB& 39.5KB/s&& 00:00&&&
full_PRITEST__0dsj7m2i_1_1&&&&&&&& 100% 1023MB& 39.3MB/s&& 00:26&&&
full_PRITEST__0esj7m4b_1_1&&&&&&&& 100% 9888KB&& 9.7MB/s&& 00:00&&
6、用备份恢复备库
SQL& shutdown abort
ORACLE instance shut down.
SQL& startup mount
ORACLE instance started.
[oracle@stdtest backup]$ rman target /
RMAN& catalog start with '/u01/app/oracle/backup';
Starting implicit crosscheck backup at
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=32 device type=DISK
Finished implicit crosscheck backup at
Starting implicit crosscheck copy at
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at
searching for all files in the recovery area
cataloging files...
no files cataloged
searching for all files that match the pattern /u01/app/oracle/backup
List of Files Unknown to the Database
=====================================
File Name: /u01/app/oracle/backup/arc_PRITEST_11_1.bak
File Name: /u01/app/oracle/backup/arc_PRITEST_12_1.bak
File Name: /u01/app/oracle/backup/arc_PRITEST_17_1.bak
File Name: /u01/app/oracle/backup/arc_PRITEST_15_1.bak
File Name: /u01/app/oracle/backup/arc_PRITEST_16_1.bak
File Name: /u01/app/oracle/backup/full_PRITEST__0isj7ob8_1_1
File Name: /u01/app/oracle/backup/full_PRITEST__0jsj7ocb_1_1
File Name: /u01/app/oracle/backup/full_PRITEST__0esj7m4b_1_1
File Name: /u01/app/oracle/backup/full_PRITEST__0dsj7m2i_1_1
File Name: /u01/app/oracle/backup/arc_PRITEST_20_1.bak
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /u01/app/oracle/backup/arc_PRITEST_11_1.bak
File Name: /u01/app/oracle/backup/arc_PRITEST_12_1.bak
File Name: /u01/app/oracle/backup/arc_PRITEST_17_1.bak
File Name: /u01/app/oracle/backup/arc_PRITEST_15_1.bak
File Name: /u01/app/oracle/backup/arc_PRITEST_16_1.bak
File Name: /u01/app/oracle/backup/full_PRITEST__0isj7ob8_1_1
File Name: /u01/app/oracle/backup/full_PRITEST__0jsj7ocb_1_1
File Name: /u01/app/oracle/backup/full_PRITEST__0esj7m4b_1_1
File Name: /u01/app/oracle/backup/full_PRITEST__0dsj7m2i_1_1
File Name: /u01/app/oracle/backup/arc_PRITEST_20_1.bak
Starting restore at
Starting implicit crosscheck backup at
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK
Crosschecked 3 objects
Finished implicit crosscheck backup at
Starting implicit crosscheck copy at
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at
searching for all files in the recovery area
cataloging files...
no files cataloged
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/pritest/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/pritest/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/pritest/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/pritest/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/backup/full_PRITEST__0dsj7m2i_1_1
channel ORA_DISK_1: piece handle=/u01/app/oracle/backup/full_PRITEST__0dsj7m2i_1_1 tag=TAG346
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at
Starting recover at
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 80 is already on disk as file /u01/app/oracle/archivelog/arch_1_80_.arc
archived log for thread 1 with sequence 81 is already on disk as file /u01/app/oracle/archivelog/arch_1_81_.arc
archived log for thread 1 with sequence 82 is already on disk as file /u01/app/oracle/archivelog/arch_1_82_.arc
archived log for thread 1 with sequence 83 is already on disk as file /u01/app/oracle/archivelog/arch_1_83_.arc
archived log file name=/u01/app/oracle/archivelog/arch_1_80_.arc thread=1 sequence=80
archived log file name=/u01/app/oracle/archivelog/arch_1_81_.arc thread=1 sequence=81
archived log file name=/u01/app/oracle/archivelog/arch_1_82_.arc thread=1 sequence=82
archived log file name=/u01/app/oracle/archivelog/arch_1_83_.arc thread=1 sequence=83
unable to find archived log
archived log thread=1 sequence=84
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/10/:40
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 84 and starting SCN of 1089419
这报错可以忽略，主机84号归档日志还未归档。
SQL& alter dat
Database altered.
SQL& alter database recover managed standby database using current logfile dis
Database altered.
7、验证主备库日志同步
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
1、场景介绍
当主备同步中断了，备库想快一点恢复，偏偏这个时候归档太多恢复不过来或者说需要的归档直接丢了，可以选择
重新搭建备库。如果库小的话还是可以的，但是如果主库比较大可能耗费的时间会很久，而且容易出一些问题。单单是全库
备份恢复这个时间就不会短，更何况中间还会涉及到很多东西。其实利用基于scn的备份去恢复我们的备库，从而绕开中间
过多或者丢失的归档。
我们都知道我们传统的dg都是属于物理dg，下面是物理dg的简单解释：
物理备用数据库：以基于块对块的主数据库同样的磁盘数据库结构，物理备用数据库物理等同于主数据库。
1.数据库的每一个块的内容包括块的逻辑位置都和主库完全一致
2.DG通过执行重做应用，维护物理备用数据库
3.物理STANDBY 打开flashbackdatabase后可以完全读写打开
4.物理备用数据库使用通过oracle恢复机制，从归档重做日志文件或直接从备系统上的备重做日志文件用用重做数据来恢复。
5.物理备用数据库可用于执行备份
6.物理备用数据库使用重做应用技术使用低级别的恢复机制应用更改，绕过了所有SQL基本代码层，因此应用海量重做数据最有效，
& 性能大于逻辑备份。
我们找到备库端数据文件中最低的scn，然后在主库去基于这个scn进行备份，这个时候rman回去扫描整个主库的块，如果块内的scn小于
备库端数据文件中最低的scn，则证明这个块从备库应用到的时间点到现在是没有改变的，就忽略掉这个块。如果块内的scn大于备库端数据
文件中最低的scn证明在这个阶段这个快进行了修改，就记录下这个块的内容。等拿到备库端去恢复的时候就替换这个块的内容。
官方文档mos的id(Doc ID )，大家可自行去查看。
Steps to perform for Rolling Forward aPhysical Standby Database using RMAN Incremental Backup.
2、开始模拟实验
2.1 直接关闭备库数据库
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
SQL& shutdown abort
ORACLE instance shut down.
2.2 在备库宕机期间主库数据变化
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
SQL& alter database enable block change tracking using file '/u01/app/oracle/oradata/pritest/rman_change_track.bct'
Database altered.
SQL& col filename for a55
SQL& select * from v$block_change_
STATUS&&& FILENAME&&&&&&&BYTES
---------- ------------------------------------------------------- ----------
ENABLED&&& /u01/app/oracle/oradata/pritest/rman_change_track.bct&&&&
SQL& update a set id=18;
1 row updated.
Commit complete.
SQL& alter s
System altered.
SQL& create table ee (id integer);
Table created.
SQL& alter s
System altered.
SQL& alter table ee move tablespace USERS;
Table altered.
SQL& alter s
System altered.
2.3 模拟主库丢失归档日志
[oracle@pritest archivelog]$ ls -trl
-rw-r----- 1 oracle oinstall&& 989184 Nov 16 16:20 arch_1_124_.arc
-rw-r----- 1 oracle oinstall&&& 24576 Nov 16 16:21 arch_1_125_.arc
-rw-r----- 1 oracle oinstall&&& 31232 Nov 16 16:21 arch_1_126_.arc
-rw-r----- 1 oracle oinstall&&& 17920 Nov 16 16:22 arch_1_127_.arc
[oracle@pritest archivelog]$ rm arch_1_125_.arc arch_1_126_.arc
2.4 查找备库数据文件最低的scn
[oracle@stdtest ~]$ sqlplus / as sysdba
SQL& startup mount
SQL& select CHECKPOINT_CHANGE#& from v$datafile_header order by 1;
CHECKPOINT_CHANGE#
------------------
&&& 1160832
&&& 1160832
&&& 1160832
&&& 1160832
SQL& select CHECKPOINT_CHANGE#& from v$database& order by 1;
CHECKPOINT_CHANGE#
------------------
&&& 1159823
SQL& shutdown abort
ORACLE instance shut down.
2.5 备份主库控制文件,更新备库控制文件
SQL& alter database create standby controlfile as '/tmp/controldg01.ctl';
Database altered.
[oracle@pritest ~]$ scp -r /tmp/controldg01.ctl
controldg01.ctl&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 100% 9872KB&& 9.6MB/s&& 00:00&&&
[oracle@pritest ~]$ scp -r /tmp/controldg01.ctl
controldg01.ctl&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& 100% 9872KB&& 9.6MB/s&& 00:00&&
2.6 执行基于SCN的增量备份
[oracle@pritest backup]$ rman target /
RMAN& run {
sql 'alter system switch logfile';
backup incremental from scn 1159823 database format '/u01/app/oracle/backup/incre_%d_%T_%s_%U' tag 'FORSTANDBY';
using target database control file instead of recovery catalog
sql statement: alter system switch logfile
Starting backup at
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=53 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/pritest/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/pritest/sysaux01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/pritest/undotbs01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/pritest/users01.dbf
channel ORA_DISK_1: starting piece 1 at
channel ORA_DISK_1: finished piece 1 at
piece handle=/u01/app/oracle/backup/incre_PRITEST__10sjhpmm_1_1 tag=FORSTANDBY comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
channel ORA_DISK_1: starting piece 1 at
channel ORA_DISK_1: finished piece 1 at
piece handle=/u01/app/oracle/backup/incre_PRITEST__11sjhpmn_1_1 tag=FORSTANDBY comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at
RMAN& (我有点不解？)
using target database control file instead of recovery catalog
specification does not match any backup in the repository
[oracle@pritest backup]$ ls -trl
total 13808
-rw-r----- 1 oracle oinstall& 3981312 Nov 16 16:28 incre_PRITEST__17sjnl9v_1_1
-rw-r----- 1 oracle oinstall
Nov 16 16:28 incre_PRITEST__18sjnla3_1_1
[oracle@pritest backup]$ scp -r ./incre_PRITEST_*
incre_PRITEST__10sjhpmm_1_1&&&&&&& 100%&& 16MB& 15.6MB/s&& 00:00&&&
incre_PRITEST__11sjhpmn_1_1&&&&&&& 100% 9920KB&& 9.7MB/s&& 00:00&
2.7 备库恢复控制文件
[oracle@stdtest backup]$ rman target/
RMAN& startup mount
Oracle instance started
database mounted
Total System Global Area&&&
Fixed Size&&&&&&&&&&&&&&&&&&&& 2252664 bytes
Variable Size&&&&&&&&&&&&&&&
Database Buffers&&&&&&&&&&&&
Redo Buffers&&&&&&&&&&&&&&&&&& 9195520 bytes
RMAN& catalog start with '/u01/app/oracle/backup';
Starting implicit crosscheck backup at
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=30 device type=DISK
Finished implicit crosscheck backup at
Starting implicit crosscheck copy at
using channel ORA_DISK_1
Crosschecked 4 objects
Finished implicit crosscheck copy at
searching for all files in the recovery area
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /u01/app/oracle/fast_recovery_area/STDTEST/autobackup//o1_mf_s__f0l4lkk8_.bkp
File Name: /u01/app/oracle/fast_recovery_area/STDTEST/autobackup//o1_mf_s__f0kyqno7_.bkp
searching for all files that match the pattern /u01/app/oracle/backup
List of Files Unknown to the Database
=====================================
File Name: /u01/app/oracle/backup/incre_PRITEST__18sjnla3_1_1
File Name: /u01/app/oracle/backup/incre_PRITEST__17sjnl9v_1_1
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /u01/app/oracle/backup/incre_PRITEST__18sjnla3_1_1
File Name: /u01/app/oracle/backup/incre_PRITEST__17sjnl9v_1_1
2.8 恢复数据库
restore 是还原，文件级的恢复。就是物理文件还原。
recover 是恢复，数据级的恢复。逻辑上恢复，比如应用归档日志、重做日志，全部同步，保持一致。
这里数据文件是基于原来的，所以不需要 restore database。
Starting recover at
using channel ORA_DISK_1
channel ORA_DISK_1: starting incremental datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: /u01/app/oracle/oradata/pritest/system01.dbf
destination for restore of datafile 00002: /u01/app/oracle/oradata/pritest/sysaux01.dbf
destination for restore of datafile 00003: /u01/app/oracle/oradata/pritest/undotbs01.dbf
destination for restore of datafile 00004: /u01/app/oracle/oradata/pritest/users01.dbf
channel ORA_DISK_1: reading from backup piece /u01/app/oracle/backup/incre_PRITEST__17sjnl9v_1_1
channel ORA_DISK_1: piece handle=/u01/app/oracle/backup/incre_PRITEST__17sjnl9v_1_1 tag=FORSTANDBY
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
starting media recovery
archived log for thread 1 with sequence 131 is already on disk as file /u01/app/oracle/archivelog/arch_1_131_.arc
archived log for thread 1 with sequence 132 is already on disk as file /u01/app/oracle/archivelog/arch_1_132_.arc
archived log for thread 1 with sequence 133 is already on disk as file /u01/app/oracle/archivelog/arch_1_133_.arc
archived log file name=/u01/app/oracle/archivelog/arch_1_131_.arc thread=1 sequence=131
archived log file name=/u01/app/oracle/archivelog/arch_1_132_.arc thread=1 sequence=132
archived log file name=/u01/app/oracle/archivelog/arch_1_133_.arc thread=1 sequence=133
unable to find archived log
archived log thread=1 sequence=134
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/16/:16
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 134 and starting SCN of 1162339
这报错可以忽略，主机134号归档日志还未归档。
2.9 启动数据库应用MRP并且验证主备同步
[oracle@stdtest ~]$ sqlplus / as sysdba
SQL& alter dat
Database altered.
SQL& alter database recover managed standby database using current logfile dis
Database altered.
SQL& select max(sequence#) from v$archived_
MAX(SEQUENCE#)
--------------
SQL& select *
no rows selected
3、知识补充
我们在进行基于scn增量备份的时候他需要去扫描全库，再做两个scn点的差集，去判断这个块会不会需不需要进行备份，
那么如果主库很大，那么做增量备份的也不会很快。当然会比全部备份快很多，他只需要扫描所有的块，需要记录的不一定会很多。
由于一些测试必须使用生产环境，可以拿备库给做测试，测试完后再恢复。
主要流程是备库开启数据库闪回，把备库从PHYSICAL STANDBY模式切换到SNAPSHOT STANDBY模式，该模式可读写，等测试完切回
PHYSICAL STANDBY模式，利用闪回恢复到测试之前的状态，再应用归档日志恢复原状。
2、先查看备库是否开启闪回
SQL& select flashback_on from v$
FLASHBACK_ON
------------------
SQL& alter database recover managed sta
Database altered.
SQL& alter d
Database altered.
SQL& select flashback_on from v$
FLASHBACK_ON
------------------
SQL& show parameter DB_RECOVERY_FILE_DEST
NAME&&&&&&&& TYPE& VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest&&&&&& string& /u01/app/oracle/fast_recovery_area
db_recovery_file_dest_size&&&&& big integer 4182M
查看闪回数据文件
SQL& !ls -trl /u01/app/oracle/fast_recovery_area/STDTEST/flashback
total 102416
-rw-r----- 1 oracle oinstall
Nov 17 09:51 o1_mf_f0wj4n6t_.flb
-rw-r----- 1 oracle oinstall
Nov 17 10:42 o1_mf_f0wj4jkw_.flb
3、查看备库当前状态
SQL& select database_role,db_unique_name,open_mode from v$
DATABASE_ROLE& DB_UNIQUE_NAME &&OPEN_MODE
---------------- ------------------------------ --------------------
PHYSICAL STANDBY stdtest&&&READ ONLY WITH APPLY
4、切换到 snapshot standby
SQL& alter database convert
Database altered.
5、查看日志
[oracle@stdtest trace]$tail -f /u01/app/oracle/diag/rdbms/stdtest/pritest/trace/alert_pritest.log
Fri Nov 17 10:19:35 2017
alter database convert to snapshot standby
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_11/17/:35
Killing 4 processes with pids 98,2900 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 2850
All dispatchers and shared servers shutdown
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
Fri Nov 17 10:19:38 2017
SMON: disabling cache recovery
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after incomplete recovery UNTIL CHANGE 1170706
Resetting resetlogs activation ID
(0x8612acb6)
Online log /u01/app/oracle/oradata/pritest/redo01.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/oracle/oradata/pritest/redo02.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/oracle/oradata/pritest/redo03.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 1170704
Fri Nov 17 10:19:38 2017
Setting recovery target incarnation to 3
AUDIT_TRAIL initialization parameter is changed back to its original value as specified in the parameter file.
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: alter database convert to snapshot standby
6、开打备库
SQL& select database_role,open_mode from v$
DATABASE_ROLE& OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY MOUNTED
Database altered.
7、对备库做一些操作
SQL& select *
no rows selected
Table dropped.
SQL& create user test identified by test123;
User created.
Grant succeeded.
SQL& conn test/test123
Connected.
SQL& create table abc as select * from dba_
Table created.
8、在SNAPSHOT STANDBY模式下，日志正常传输但不应用，下面语句进行确认
SQL& col CTIME for a18
SQL& col NAME for a15
SQL& col VALUE for a13
SQL& col DATUM_TIME for a20
SQL& select to_char(SYSDATE,'yyyymmdd hh24:mi:ss') CTIME,NAME,VALUE,DATUM_TIME
SQL& from V$DATAGUARD_STATS WHERE NAME LIKE '%lag';
CTIME&&&& NAME &&& VALUE& DATUM_TIME
------------------ --------------- ------------- --------------------
:03:21& transport lag&& +00 00:00:00& 11/17/:20
:03:21& apply lag&&& +00 00:44:20& 11/17/:20
看日志我们是 10:19 切换成，大致是44分钟。
9、切回 PHYSICAL STADNBY
SQL& alter database convert
alter database convert to physical standby
ERROR at line 1:
ORA-01126: database must be mounted in this instance and not open in any instance
SQL& shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL& startup mount
Database mounted.
SQL& alter database convert
Database altered.
10、切换完成后，发现闪回日志恢复完成，同时自动删除闪回日志，日志如下：
Fri Nov 17 11:12:58 2017
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (pritest)
Killing 3 processes with pids 93 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 3487
Flashback Restore Start
Flashback Restore Complete
Drop guaranteed restore point
Guaranteed restore point& dropped
Clearing standby activation ID
(0x864f2ff6)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE ;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE ;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE ;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE ;
Shutting down archive processes
Archiving is disabled
Fri Nov 17 11:12:59 2017
ARCH shutting down
ARC3: Archival stopped
Fri Nov 17 11:12:59 2017
ARCH shutting down
ARC2: Archival stopped
Fri Nov 17 11:12:59 2017
ARCH shutting down
ARC1: Archival stopped
Fri Nov 17 11:12:59 2017
ARCH shutting down
ARC0: Archival stopped
Completed: alter database convert to physical standby
11、开启同步主库
SQL& startup mount force
ORACLE instance started.
Total System Global Area
Fixed Size&&&&& 2252664 bytes
Variable Size&&&
Database Buffers&&
Redo Buffers&&&&& 9195520 bytes
Database mounted.
SQL& select database_role,db_unique_name,open_mode from v$
DATABASE_ROLE& DB_UNIQUE_NAME &&OPEN_MODE
---------------- ------------------------------ --------------------
PHYSICAL STANDBY stdtest&&&MOUNTED
SQL& alter dat
Database altered.
SQL&& alter database recover managed standby database using current logfile dis
Database altered.
12、验证是否恢复到最初切换前
SQL& select database_role,db_unique_name,open_mode from v$
DATABASE_ROLE& DB_UNIQUE_NAME &&OPEN_MODE
---------------- ------------------------------ --------------------
PHYSICAL STANDBY stdtest&&&READ ONLY WITH APPLY
SQL& select *
no rows selected
SQL& conn test/test123
ORA-01017: invalid username/ logon denied
Warning: You are no longer connected to ORACLE.
阅读(110) | 评论(0) | 转发(0) |
下一篇：没有了
相关热门文章
给主人留下些什么吧！~~
请登录后评论。