如果有个库10T大小，我用哪种手段备份？数据量比较大，有一种备份方式rman
用rman要考虑备份速度，人家问你10T要多少时间，就是看你的一个磁盘写的速度。
生产中 200m/s，它肯定是个盘阵，起码是个raid。
10t=10000000m/200m=50000s/3600s=大约13小时
在公司备份10T数据用rman大约13小时，是不是时间太长了。这13小时内，磁盘的IO都被备份操作占用了，如果你的库在这13小时中有其它任务呢？
其它操作的速度应该特别慢。所以10T以上的数据就不要用rman了，不是说不支持rman了。
像10T及10T以上的的数据量，一般应该就是DW了，如果你做常规备份的话，备份时很耗资源，还原时也一样耗资源。
所以有了一种新手段，容灾。它是一种特殊的备份，从本质意义上说它是负责灾难恢复的。
容灾(灾难恢复)
一些大型公司，比如银行、证券等，必须有自己的容灾中心。比如你在北京有个机房，地震了发生火灾了，即使有备份那没有用。我整个机房、整个大厦都没了，那你的备份跟着也消失了。
为了避免上面的情况，可以搭建一套容灾中心，容灾中心和你的生产库肯定不在一个地方。
1、异地(比如生产库在：北京 容灾中心在：广州)
2、容灾可以看成特殊的备份(一个库的数据如果有10T以上数据，不能做常规备份，我们就可以用容灾)
比如公司的主库在北京，容灾库在上海，容灾肯定涉及到数据的同步，你主库把变化的数据同步给容灾库。
这篇文章介绍的容灾手段叫dataguard简称dg，只要安装了oracle数据库，就可以使用dg。
dg原理：它实现的原理是主库开启binlog日志，然后传输日志。它为什么不传输数据呢？因为产生的日志量肯定数据量小。
dg也一样它同步的是日志，把日志从生产库同步到容灾库。
首先主库开启lns进程，它负责把日志发送给备库。
备库开启rfs进程，用来接收主库传输过来的日志。会产生一个日志的队列，因为主库要周期的给备库发送日志。
备库开启mrp进程，用来解析接收到的日志，在本地恢复。(备库要处于mount状态，如果处于open状态mrp进程就不能恢复)
DataGuard环境中必须保证3个进程正常工作，否则此DataGuard环境将不能满足灾备需要。
所以主库与备库的数据是永远同步的，当主库出现问题，备库可以对外提供服务，不影响生产。
【DG可以解决的问题】
1、在主库停机维护时，需要停止主库，可以把备份库顶上，让程序访问备份库，对于外部客户来说，他感觉不到业务中断过。
(1)主库安装OS补丁或Oracle补丁
2、一个新的数据迁移项目，将数据迁移同型号更高端IBM服务器与存储中，主库数据2T，并且此迁移操作必须停机时间控制在30分钟以内(此次时间远远适于迁移数据库文件所需时间),怎么办？
(1)把备份库顶上去 (2)然后迁移数据
3、由于主库(仓库)数据量非常巨大(50T),所以没有常规备份，但此系统存在DataGuard灾备系统，如果主库某数据文件由于某种原因导致介质故障，你将如何对其进行恢复。
【DataGuard高可用性】
DataGuard确保企业数据的高可用性，数据保护以及灾难恢复。在主数据库故障无法修复时启动DataGuard的备份库，可以像主库一样继续对外提供服务而不影响业务的持续运行。
Data Guard三种保护模式
Oracle Data Guard为我们提供了非常人性化的三种保护模式，其目的应用于不同的保护级别和场合，存在的目的就是让我们的数据库，健健康康活着，创造出自己的价值
1）保护最大化：主库与备库实时同步数据，如果主库挂了，备库也不能前进，等主库好了，
备库才能前进（在写入主库的redo日志时同时写入备库redo日志，并且保证至少有一个备库redo日志可用【当你有多个备库时】），
最大限度的保证数据的完整性，不允许丢数据。
【实际生产很少用，对数据保护最好，但是太占资源
1、事务级数据库，每秒请求数比较多，每秒几千几万次请求，实时的只要主库日志发生变化，你就传一份给备库，只要日志发生变化，你就传一份，太频繁
2、oracle是先写日志后写数据，现在主库本地redo写完不行，要等待备库也接收到日志后，备库回复主库收到后，主库才认为操作才能完成。会产生大量的延迟
】
2）可用最大化：默认按第1种方式进行数据同步。当网络出现问题或备库出现问题时，不影响主库的工作而是转换为“性能最大化”模式，
等备库恢复正常后，再转换为可用保护最大化模式。
【实际生产很少用】
3）性能最大化：主库与备库是异步传输数据(定期传日志)，保证主库的性能最好，如果主库挂了，尽最大努力恢复备库。
【实际生产很多用
1、LNS进程将主库的日志发送给备份，不会考虑备库是否接收了
2、周期性传递日志，当主库日志切换时，把日志同步到备库，主库的压力较小
】
总结：性能最大化有可能丢数据，只能尽最大努力去恢复备库
假设
9点30分，主库切换日志，将日志传递到备份一份。
9点45分，主库出问题了，备份库能恢复到主库9点30分的状态，丢了15分钟数据。
搭建之前和对应负责人说明问题，可能会丢失数据，他们能接受丢失多少时间的数据？
30分钟 40分钟 50分钟 60分钟
如果人家可以接受的是30分钟，那么你就要保证30分钟强制切换一次日志。(写个存储过程+计划任务 保证30分钟切换一次日志)
这种丢失能满足90%的行业，你想想比如地震了，楼都塌了，你才丢失了30分钟数据。
还有10%的行业，恰恰这10%行业是做容灾最多的行业，比如银行，你去和银行谈需求，地震了银行能允许丢失多少数据？
如果银行允许丢失30分钟，那完蛋了，这银行不用开了，倒闭了。
可以使用"保护最大化"模式，使用这种模式，对服务器要求较高，你肯定要升级你的硬件、网络带宽。
我们需要用两个虚拟机来模拟实现
保证两边时间一致
date -s "20161212" 【root用户操作】
【两边数据库中 sys用户对应的密码要一致，否则也报错】
保证路径、实例名等都一致
主库：8.8 备库：8.66
1、主库和备库：开启归档模式
archive log list;-----------查看归档启动否
shutdown immediate;---------开启归档前要正常关库
startup mount;-------------启动Mount状态
alter database archivelog;-------开启归档模式
alter database open;--------开启数据库
2、确认主库强制写日志【备库也做，因为我们有可能会切换角色】
select force_logging from v$database;
(所有sql语句nologging操作时 也会强制写日志)
SQL> alter database force logging;
3、主库和备库
都配置“监听”、“传输文件”，并开启监听
4、主库和备库
都创建“归档日志”目录：
mkdir -p /home/oracle/archive
5、修改主备数据库的参数文件
【主DB8】
SQL>create pfile from spfile;
cd $ORACLE_HOME/dbs/
vi initecom.ora
DB_UNIQUE_NAME=ecom 【show parameter DB_UNIQUE_NAME 确认 主库唯一名称】
LOG_ARCHIVE_CONFIG='DG_CONFIG=(DB8,DB66)' 【主库的网络连接串，请以你的tnsname.ora为准】
LOG_ARCHIVE_DEST_1='LOCATION=/home/oracle/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ecom' 【主库的归档日志路径，所有日志及角色保存在本地】
LOG_ARCHIVE_DEST_2='SERVICE=DB66 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ecom' 【同步在线日志和主角色到备库去】
FAL_SERVER=DB8 【声明服务器端】
FAL_CLIENT=DB66 【声明客户端】
STANDBY_FILE_MANAGEMENT=AUTO 【如果产生新的表空间，默认只传递数据，此参数作用主库把新创建的数据文件也传到备库】
##########################
DB_UNIQUE_NAME=ecom
LOG_ARCHIVE_CONFIG='DG_CONFIG=(DB8,DB66)'
LOG_ARCHIVE_DEST_1='LOCATION=/home/oracle/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ecom'
LOG_ARCHIVE_DEST_2='SERVICE=DB66 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ecom'
FAL_SERVER=DB8
FAL_CLIENT=DB66
STANDBY_FILE_MANAGEMENT=AUTO
##########################
rm -rf spfileecom.ora
【备DB66 】
SQL>create pfile from spfile;
cd $ORACLE_HOME/dbs
vi initecom.ora
DB_UNIQUE_NAME=ecom
LOG_ARCHIVE_CONFIG='DG_CONFIG=(DB8,DB66)'
LOG_ARCHIVE_DEST_1='LOCATION=/home/oracle/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ecom' 【主库的归档日志路径 】
LOG_ARCHIVE_DEST_2='SERVICE=DB8 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ecom'
FAL_SERVER=DB66
FAL_CLIENT=DB8
STANDBY_FILE_MANAGEMENT=AUTO
##########################
DB_UNIQUE_NAME=ecom
LOG_ARCHIVE_CONFIG='DG_CONFIG=(DB8,DB66)'
LOG_ARCHIVE_DEST_1='LOCATION=/home/oracle/archive VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ecom'
LOG_ARCHIVE_DEST_2='SERVICE=DB8 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ecom'
FAL_SERVER=DB66
FAL_CLIENT=DB8
STANDBY_FILE_MANAGEMENT=AUTO
##########################
rm -rf spfileecom.ora
6、主库
sqlplus / as sysdba
SQL> startup force;
7、备库
SQL> sqlplus / as sysdba
SQL> shutdown immediate
SQL> startup nomount; 【一会我们会做一个rman恢复】
8、主库
SQL> show parameter ARCHIVE(查看到刚才配置的值生效了)
SQL> create table s1 as select * from scott.dept;
【主库比备库多1张s1表，两边数据不一致了，如果此时主库向备库推送日志操作s1表的，就出问题了】
10、主库
mkdir /home/oracle/db_bak/
rman target /
RMAN> backup full database format='/home/oracle/db_bak/%U' include current controlfile for standby; 【备库恢复时加载的是主库的控制文件】
(别退出RMAN，第12步用)
11、备库
mkdir /home/oracle/db_bak/
12、主库(把全库备份的文件拷贝到备库)
cd /home/oracle/db_bak/
scp 备份文件 oracle@192.168.8.66:/home/oracle/db_bak/
scp * oracle@192.168.8.66:/home/oracle/db_bak/
RMAN>connect auxiliary sys/lipengfei@DB66
RMAN> duplicate target database for standby nofilenamecheck;【异机(备库)恢复，保证主备库的数据和状态一样】
RMAN> exit
13、备库
cd /oracle/app/oradata/ecom
ls -------->查看有没有文件
sqlplus / as sysdba
SQL>select open_mode from v$database;----------mount状态
14、查看进程
【主库】
SQL> select process from v$managed_standby;
（没有灾备的进程）
SQL> insert into s1 select * from s1;
SQL> insert into s1 select * from s1;
SQL> insert into s1 select * from s1;
SQL> commit;
SQL> alter system switch logfile;
SQL> select process from v$managed_standby;【虚拟环境比较慢，需要1-5分钟产生进程。】
PROCESS
---------
ARCH
ARCH
LNS
【从库】
SQL> select process from v$managed_standby;
PROCESS
---------
ARCH
ARCH
RFS
RFS
（已经有了进程，rfs接收进程）
【备库具有恢复日志进程，需要手动激活此进程】
SQL> alter database recover managed standby database disconnect from session;
SQL> select process from v$managed_standby;
PROCESS
---------
ARCH
ARCH
RFS
RFS
MRP0
【主库】
SQL> select error from v$archive_dest;【如果过了好久都没有产生LNS进程，可能有问题，查看归档错误信息】
SQL> select count(*) from s1;
【从库】
SQL> alter database open; 【报错不明显，因为MRP进程开启着呢，要想恢复必须库处于mount状态】
SQL> alter database recover managed standby database cancel;【备库上，只有把恢复日志进程取消，才可以打开数据库】
SQL> alter database open;
SQL> select count(*) from s1;（已经有了）
SQL> create table s3 as select * from scott.dept; 【报错，因为DG是单向的，如果当前还是备库角色，即使是open状态，他也不能创建表，因为它是只读的】
DG只要安装Oarcle10g以上的企业版，它自带的功能，不用额外花钱。
10g主库是open状态，备库是mount。
11g主库和备库全可以是open。
###############################虚拟机慢，可以不做#################################
【主库】
SQL>startup force;
SQL> select process from v$managed_standby; 【LNS进程还在】
PROCESS
---------
ARCH
ARCH
LNS
【从库】
SQL> shutdown immediate
SQL> startup mount;
SQL> select process from v$managed_standby;
PROCESS
---------
ARCH
ARCH
【主库】
SQL> alter system switch logfile;
【从库】
SQL> shutdown immediate
SQL> startup mount;
SQL> select process from v$managed_standby; 【RFS进程还在，少了一个MRP进程】
PROCESS
---------
ARCH
ARCH
RFS
RFS
SQL> alter database recover managed standby database disconnect from session;
SQL> select process from v$managed_standby;
PROCESS
---------
ARCH
ARCH
RFS
RFS
MRP0
################################################################
------------角色切换-------------
就是主变备、备变主
当主库升级时，把主库离线，备库顶上了，备库变成主库。为什么不直接切把请求到备库呢，非要把备库变成主库？
1、备库是只读的，只有变成主库，才能读写
2、防止数据丢失
(1)a主库，由于升级等原因要离线3小时(9:00--12:00)
(2)b备库，变成新的主库，这3小时内b新主库上对外提供服务(9:00--12:00，所有的操作都记录到b库)
(3)a主库3小时过后，操作完毕，变成新的备库(12:00恢复正常)
(4)b主库再往a备库同步数据(从9:00--12:00的操作，因为这个时间段内，a在停库升级)
(5)a再变回主库
(6)b再变回从库，这3小时内，一点数据没有丢失
切换方式：
1、无损切换(不会丢失任何数据)：主备都是可用状态，主库停机前，把日志切换一下，把前端应用中断一会(备变主的切换过程)，备变主之后，继续接收前端请求
2、有损切换：主库突然失效了(比如主库所在机房地震了)，备库没有同步当前日志组，损失的是主库当前日志组操作。
==============================无损切换=================================
【从库】
SQL> shutdown immediate
SQL> startup mount;
SQL> select process from v$managed_standby; 【没有RFS进程】
PROCESS
---------
ARCH
ARCH
【主库】
SQL> alter system switch logfile;
【从库 需要等等大约5-8分钟，比较慢，能看到错误ORA-03113】
SQL> select process from v$managed_standby; 【RFS进程还在，少了一个MRP进程】
PROCESS
---------
ARCH
ARCH
RFS
RFS
SQL> alter database recover managed standby database disconnect from session;
SQL> select process from v$managed_standby;
PROCESS
---------
ARCH
ARCH
RFS
RFS
MRP0
【主】
create table s3 as select * from dba_objects;
insert into s3 select * from s3;
commit;
SQL> select database_role from v$database;【查看角色状态】
DATABASE_ROLE
----------------
PRIMARY
【从】
SQL> select database_role from v$database;【查看角色状态】
DATABASE_ROLE
----------------
PHYSICAL STANDBY
【主】
检查主库是否具有切换的状态
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
------------------
TO STANDBY
SQL> alter system switch logfile;
############################################
主库 开一个新窗口
sqlplus / as sysdba
delete from s3 where rownum<1000;
检查主库是否具有切换的状态
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
SESSIONS ACTIVE (不能切换，还有其他活动会话正在操作，没有commit)
############################################
【主库】
SQL> ALTER DATABASE commit TO switchover TO physical standby WITH SESSION shutdown;【切换变成备库 并关闭所有活动会话，上面那个delete会自动回滚】
SQL> startup mount force;
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PHYSICAL STANDBY
(备库)
【从库】
SQL> select database_role from v$database; 【备库还是备库，不会自动变成主库】
DATABASE_ROLE
----------------
PHYSICAL STANDBY
(备库)
咱们的容灾，与双机热备不同，它的角色永远不会自动切换。
热备：
同地(通过维护VIP)，一个节点挂了，另一个节点接管VIP，前端应用不用改变。
角色切换比较快
容灾：
异地，没有VIP切换，前端应用要变
角色切换比较慢(异地通过网络连接，肯定会慢)
咱们的灾备切换一点也不频繁，也许一年也切换不上一次，甚至有些公司从来不切换。
容灾投入资本非常大，银行每年的投入都会过亿元，可能每年只做一次容灾演练，模拟如果出现意外能不能容灾。
电信容灾做得就不太好，当年汶川地震，电信公司当时是这么说的，支援灾区，只要拿震区身份证，免费办理一张电话卡，免费赠送100元。
其实是它库里的部分电话号没了 或 电话号有里面的计费没了。
做为手机就无所谓了，拿身份证重新申请一个，或你说你以前用的是什么号，电信一查说没有人用，再把这号给你就可以了。
如果是银行呢？银行如果把数据弄没了，就麻烦了。震区把银行震没了，除了救援部门外，第一个去灾区的就是网络部门，第二个就是银行部门。
网络部门去做线缆的维护，比如地下光缆抢修，把网络修复。
地震发生了，老百姓的家没了，老百姓还关心的就是银行的钱还有没有。
银行直接带PC机过去，连接到网络，连接到省级库，可以查出老百姓的帐户情况。
【备库】
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO PRIMARY 【可以切换到主库，备库没有外部请求，直接可以切换】
SQL> alter database commit to switchover to primary; 【切换成主库】
SQL> startup mount force;
SQL> alter database open;
SQL> select database_role from v$database;
DATABASE_ROLE
----------------
PRIMARY 【变为主库】
验证
【新主】
SQL> select process from v$managed_standby;【有lns】
SQL> select count(*) from s3; 【最后建的表，看看丢没丢数据】
【新从】
SQL> select process from v$managed_standby;【有RFS 没有MRP0】
SQL> alter database recover managed standby database disconnect from session;
==============================有损切换=================================
【新主】
create table s4 as select * from s3;
select count(*) from s4;
把新主的虚拟机电源关闭
【新从】
SQL> select database_role from v$database; 【还是备库】
DATABASE_ROLE
----------------
PHYSICAL STANDBY
SQL> alter database recover managed standby database cancel; 【关闭MRP】
SQL> select process from v$managed_standby;【有RFS】
PROCESS
---------
ARCH
ARCH
RFS
RFS
SQL> alter database recover managed standby database finish force;【force停止当前rfs进程,进行恢复】
SQL> select process from v$managed_standby;【无RFS】
PROCESS
---------
ARCH
ARCH
SQL> alter database commit to switchover to primary;【切换成主库状态】
SQL> startup force;
SQL> select database_role from v$database; 【主库】
DATABASE_ROLE
----------------
PRIMARY
SQL> select count(*) from s4; 【丢失了】
SQL> select count(*) from s3 ; 【正常还存在】
---------------------------附加赠送----------------------------
dg的日常管理【dg环境比较稳定，周期性的巡检】
【在新主库】
(1)查看进程的活动状态
SQL> select process,client_process,sequence#,status from v$managed_standby;
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH ARCH 763 CLOSING
ARCH ARCH 762 CLOSING
MRP0 N/A 764 WAIT_FOR_LOG
RFS LGWR 764 IDLE
RFS N/A 0 IDLE
PROCESS：显示进程信息
CLIENT_PROCESS：显示对应的主数据库中的进程
SEQUENCE#：显示归档redo 的序列号
STATUS：显示的进程状态
通过上述查询可以得知primary 开了两个归档进程，使用lgwr 同步传输方式与standby 通信，已经接收完763 的日志，正等待764。
（1）PROCESS：进程名称，如ARCH、RFS、MRP0等。
（2）CLIENT_P：对应的Primary数据库中的进程，如ARCH、LGWR等。
（3）SEQUENCE#：归档序号。
（4）STATUS：进程的当前状态，值较多，常见的有：
1）ALLOCATED：正准备连接Primary数据库。
2）ATTACHED：正在连接Primary数据库。
3）CONNECTED：已连接至Primary数据库。
4）IDLE：空闲中。
5）RECEIVING：归档文件接收中。
6）OPENING：归档文件处理中。
7）CLOSING：归档文件处理完，收尾中。
8）WRITING：REDO数据库写向归档文件中。 【SEQUENCE# 与select * from v$log中 SEQUENCE#一致】
9）WAIT_FOR_LOG：等待新的REDO数据中。
10）WAIT_FOR_GAP：归档有中断，正等待中断的那部分REDO数据。
11）APPLYING_LOG：应用REDO数据中。
(2)确认redo 应用进度---v$archive_dest_status
该视图显示归档文件路径配置信息及redo 的应用情况等，例如：
SQL> select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name
2 from v$archive_dest_status where status='VALID';
DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD#APPLIED_SEQ# DB_UNIQUE_
-------------------- ---------------- ------------- --------------- ------------ ----------
LOG_ARCHIVE_DEST_1 1 765 0 0 jsspdg
LOG_ARCHIVE_DEST_2 0 0 0 0 jssweb
STANDBY_ARCHIVE_DEST 1 764 1 764 NONE
(3)检查归档文件路径及创建信息---v$archived_log
该视图查询standby 数据库归档文件的一些附加信息，比如文件创建时间啦，创建进程啦，归档序号啦，是否被应用啦之类，例如：
SQL> select name,creator,sequence#,applied,completion_time from v$archived_log;
NAME CREATOR SEQUENCE# APP COMPLETION_TIM
-------------------------------------------------- ------- ---------- --- --------------
E:\ORA10G\ORADATA\JSSPDG\LOG1_750_641301252.ARC ARCH 750 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_749_641301252.ARC ARCH 749 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_751_641301252.ARC ARCH 751 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_752_641301252.ARC ARCH 752 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_753_641301252.ARC ARCH 753 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_754_641301252.ARC ARCH 754 YES 18-1 月-08
(4)查询归档历史---v$log_history
该视图查询standby 库中所有已被应用的归档文件信息(不论该归档文件是否还存在)，例如：
SQL> select first_time,first_change#,next_change#,sequence# from v$log_history;
FIRST_TIME FIRST_CHANGE# NEXT_CHANGE# SEQUENCE#
------------------- ------------- ------------ ----------
2008-01-03 12:00:51 499709 528572 18
2008-01-08 09:54:42 528572 539402 19
2008-01-08 22:00:06 539402 547161 20
2008-01-09 01:05:57 547161 560393 21
2008-01-09 10:13:53 560393 561070 22
【注意】
（1）备用数据库在日志恢复过程中（MRP进程存在期间）数据库处于MOUNTED状态，此时备用数据库无法打开供读取使用
（2）打开备用数据库
停止备用库的日志恢复进程MRP
alter database recover managed standby database cancel;
open备用数据库,备用数据库默认打开为只读方式
alter database open;
（3）重新启动备用数据库的MRP进程，数据库自动从OPEN状态转换到MOUNT 状态
alter database recover managed standby database disconnect from session;
（4）mrp进程停止期间，只要RFS进程存在，那么不影响日志的接收
在配制静态连接的listener.ora的时候：
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME=STREET.LOVEUNIX.CN)
(ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1)
(SID_NAME=street)//这里的SID_NAME应该和环境变量的:ORACLE_SID=street
完全一样，大小写必须一致；
)
)
数据库能闪回之前的任意时间点，闪回数据库类似之前的时间点还原。
redo+archive
10号(SCN:5000) -------------------------------> 19号(SCN:9000) 20号(SCN:10000)
全库备份 恢复时间点 当前时间点
| | |
-------------------------------------------------------------------------------------------------
SCN只能从小变大，不能从大变小，如果从大变小数据库认为你后面还有操作动作，它不让你变，所以我们需要先全库还原.
闪回的过程是从当前时间点往回退的过程，它可以做到SCN从大到小
因为它多维护了一份日志，闪回日志。
它把redo日志时间节点的状态放在闪回日志中，不会像redo记录那么细，它只保存某个时间点做的是什么工作，
但具体工作的动作还在redo和archive中，恢复的过程是先找闪回日志，再找redo和archive，
再把redo和archive一步一步退掉就行了。
1、
闪回恢复时，不用做全库恢复，节省了I/O 【生产库全库恢复比较耗时】
2、
一般做时间点恢复，离当前时间都比较近，闪回恢复查日志比较少一些，做闪回恢复比时间点恢复快好多。
咱们维护日志会有额外消耗，你做一步操作它记录一下日志。你再多维护一份闪回日志，它就多一份消耗资源。
闪回它是一个小功能，oracle没有花大力气开发。它不像redo可以循环使用和归档日志，它是逐渐扩大的。
所以为了减轻日志的负担，它只保留1天的，这个值可以扩大，你保留的时间越多，不仅占空间，oracle的负担也会增加。
【查看 闪回功能 开启状态】
SQL> select FLASHBACK_ON from v$database;
(系统默认没有开闪回功能)
设置闪回
SQL> shutdown immediate
SQL> startup mount;
SQL> alter database archivelog; (闪回必须运行在归档模式)
SQL> alter database FLASHBACK on; (闪回启动)
SQL> alter database open;
SQL> select FLASHBACK_ON from v$database;
查看闪回路径
SQL> show parameter recover;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /oracle/app/flash_recovery_area 【闪回空间所在路径】
db_recovery_file_dest_size big integer 2G 【闪回空间大小】
recovery_parallelism integer 0
闪回保留时间(默认1天)
SQL> show parameter flashback
==================================================
闪回数据库(恢复到时间点,指定时间点后的数据丢失)
窗口1
sqlplus scott/lipengfei
exit
窗口2
sqlplus / as sysdba
select count(*) from all_users where username='SCOTT';
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;【2015-09-04 21:23:46 查看时间点,用户还在】
drop user scott cascade;(删除scott用户)
select count(*) from all_users where username='SCOTT';
create table haha as select * from all_objects;
shutdown abort
startup mount
恢复到删除用户前的时间点
SQL> flashback database to timestamp to_timestamp('2015-09-04 21:23:46','yyyy-mm-dd hh24:mi:ss');
SQL> alter database open resetlogs;
SQL> select count(*) from haha; 【我们做了闪回数据库，回到之前了，那时候还没有haha表】
SQL> sqlplus scott/lipengfei
SQL> exit
总结：闪回数据库是针对整个数据库来做的，通过维护闪回日志，以回退的方式能够快速恢复数据库。
局限性：
1、闪回日志保留时间：只能恢复闪回日志保留时间内的 【全库备份，只要日志是全部连续有效的，恢复到哪都可以】
查看最早可以恢复到的时间点
SQL> select to_char(OLDEST_FLASHBACK_TIME,'yyyy-mm-dd hh24:mi:ss') from v$flashback_database_log;
2、额外资源占用太大(库随时都在维护闪回日志，但是使用的频率很少，可能你好几年也不恢复一次)
==================================================
闪回回收站【类似windows的 回收站】
每个表空间下，都有一个默认回收站(system表空间除外)，没有额外的维护。当你drop对象时，它会自动放入回收站中。
SQL> sqlplus scott/lipengfei
SQL> create table ss1 as select * from dept;
SQL> insert into ss1 select * from ss1;
SQL> commit;
SQL> select * from ss1;
SQL> drop table ss1;
SQL> select * from ss1;
SQL> show parameter recyclebin;【dba来操作，默认回收站是开启的，如果没有，可以用sys开启 alter system set recyclebin=on scope=spfile;】
SQL> show recyclebin;(有内容了)
SQL> create table haha as select * from dept;
SQL> flashback table ss1 to before drop;
SQL> select * from ss1;【只是从回收站取回删除的数据】
SQL> select * from haha;
【局限性：空间容量大小】
SQL> sqlplus / as sysdba
create tablespace tbs01 datafile '/oracle/app/oradata/ecom/tbs01.dbf' size 10M;
SQL> sqlplus scott/lipengfei
create table ss2 tablespace tbs01 as select * from all_objects;
select bytes/1024/1024 from user_segments where segment_name='SS2'; 【大约5M】
insert into ss2 select * from ss2 where rownum<10000;
commit;
select bytes/1024/1024 from user_segments where segment_name='SS2';【大约6M】
drop table ss2;
show recyclebin;(有内容了)
create table ss3 tablespace tbs01 as select * from all_objects;【大约5M】
select count(*) from ss3;
show recyclebin;(没有内容了) 【回收站的优先级最低，当空间足够时，回收站内容会被保留。如果没有空间了，回收站的内容会被覆盖】
drop table ss3;
show recyclebin;(有内容了)
purge recyclebin; 【清空回收站】
show recyclebin;(没有内容)
==================================================
闪回undo查询
SQL>sqlplus scott/lipengfei
create table ss4 tablespace tbs01 as select * from all_objects;
select count(*) from ss4;
drop table ss4;
show recyclebin; (有内容了)
create table ss5 tablespace tbs01 as select * from scott.dept;
select * from ss5;
delete from ss5;
select * from ss5;
commit;【不能Rollabck】
show recyclebin;(表空间回收站中没有ss5，delete删除的内容没有保存在表空间回收站，存放在了undo中)
SQL>sqlplus / as sysdba
show parameter undo
NAME TYPE VALUE
------------------------ ----------- ------------
undo_management string AUTO
undo_retention integer 900 【保留900秒，给闪回用】
undo_tablespace string UNDOTBS1
SQL>sqlplus scott/lipengfei
create table s6 as select * from scott.dept;
select * from s6;
insert into s6 values(66,'fuck','you');
commit;
select * from s6;
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual; 【2015-09-04 21:54:14 显示当前时间】
delete from s6; 【删除的数据放在undo中了，数据前映像】
commit;
rollback; 【commit后，rollback失效】
select * from s6;
select * from s6 as of timestamp to_timestamp('2015-09-04 21:54:14','yyyy-mm-dd hh24:mi:ss');
insert into s6 select * from s6 as of timestamp to_timestamp('2015-09-04 21:54:14','yyyy-mm-dd hh24:mi:ss');
commit;
【局限性，undo的空间大小及undo保留时间】
SQL>sqlplus / as sysdba
create undo tablespace uuu datafile'/oracle/app/oradata/ecom/uuu.dbf' size 100m;
show parameter undo 【同一时间只能有一个UNDO表空间被使用】
alter system set undo_tablespace=uuu scope=both;
startup force;
drop tablespace UNDOTBS1;
SQL>sqlplus scott/lipengfei
select * from s6 as of timestamp to_timestamp('2015-09-04 21:54:14','yyyy-mm-dd hh24:mi:ss');【报错ORA-01555】
闪回有很多局限性，还原是个投机取巧的手段，能用闪回是最好了，恢复效率很高。但不会说数据库有闪回，咱们就不做常规备份了，常规备份是日常必做的。
306
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
