是否选择增量备份：
1.增量备份选项
指定一个参数incremental level=n,在执行backup命令时加上，增量备份可以创建两个级别，用整数0...n表示(n最大不超4),从0级开始，所有增量备份都必须先创建0级备份。0级相当于数据库的完整备份.
.建立增量级别0的全库备份
RMAN>backup incremental level=0 database;
2.增量备份类型
Differental(差异)和Cumulative(累积).默认情况下RMAN创建的增量备份集是differental方式，如果要建立cummulative方式的增量备份，需要在执行backup命令时显示指定.
如:RMAN>backup incremental level=1 cumulative database;
3.RMAN保留策略
两种保留策略：基于时间和基于冗余数量的备份保留策略
.基于时间的备份保留策略
RMAN>configure retention policy to recover window of n days;
control_file_record_keep_time用来指定记录在控制文件中的最少保存时间，以天为单位。建议这个参数初始化不小于你在RMAN中设置的备份保留时间。
.基于冗余数量的备份保留策略
RMAN>configure retention policy to redundancy n;
n为大于0的正整数
设置不采用任何备份保留策略
RMAN>configure retention policy to none;
如果不设置保留备份策略，使用report obsolete和delete obsolete命令也不会有任何匹配记录.
4.启用通道
5.启用复合备份
.在生成备份集的同时，向指定位置生成指定份数(最大不超过4)的备份集复制文件
三种方式复合备份：
a.执行backup命令指定复合备份
RMAN>backup copies 3 database 在执行全库备份同时，自动生成当前备份集2份备份到默认备份目录
b.利用set bakcup copies 命令指定复合备份.在run{}命令块中利用set backup copies命令为该命令块中所有的bakcup命令设置Duplexed方式
RMAN>run{
set backup copies 2;
bakcup device type disk format 'D:akcup1\%U','D:akcup2\%U'
tablespace user,sales;
}
c.利用configure命令指定复合备份
configure ... backup copies命令可以为指定的设备类型设置默认的备份复制数量
RMAN>configure default device type to disk;
RMAN>configure datafile bakcup copies for device type disk to 2;
RMAN>configure archivelog bakcup copies for device type disk to 2;
6.RMAN catalog
1.创建一个独立的表空间
2.创建一个独立的schema
>grant connect,resource,recovery_catalog_owner to rmanct identified by rmanct;
3.通过rman连接到新创建的恢复目录中
f:oracle>RMAN catalog rmanct/rmanct
4.在RMAN中创建catalog
RMAN>create catalog tablespace RMANTBS;
需要在恢复目录中注册该数据库
F:oracle>RMAN target / catalog rmanct/rmanct@bakdb
注册数据库：
RMAN>register database;
7.启用备份优化
满足以下条件，才能启用备份优化
.configure backup optimization 参数为on
.执行bakcup database或backup archivelog命令中带有all或like参数
8.启用备份压缩
10g新增一个as compressed backupset的选项
RMAN配置回归默认值：
RMAN>configure retention policy clear; ---configure clear;
a.基于时间的保留策略
RMAN>configure retention policy to recovery window of n days;
b.基于冗余数量的保留策略
RMAN>configure retention policy to redundancy n;
常在RUN块中运行的命令
.给数据文件指定新的路径和名称
RMAN>run{
allocate channel C1 device type disk;
set newname for datafile 4 to 'F:oracleoradata
ewdbuser01.dbf';
......
}
.设置恢复到的时间点或SCN
RMAN>run{
allocate channcel C1 type disk;
set until time "to_date('2009-4-18 14:23:54','yyyy-mm-dd hh24:mi:ss')";
......
}
.定义备份片段的冗余数
RMAN>run{
allocate channel c1 device type disk;
set backup copies 3;
.......
}
v$session视图对应"会话"信息
v$process视图对应"连接"信息
>select s.sid,s.serial#,p.spid,s.client_info
from v$process p,v$session s
where p.addr=s.paddr and client_inof like '%id=rman%';
v$session_longops 记录oracle数据库中执行时间超过6秒的操作
ch 9 RMAN恢复
RMAN中的恢复对应的两个操作：数据库修复(Restore)和数据库恢复(Recover)
.数据库修复:利用备份集的数据文件来替换已经损坏的数据文件或将其恢复到一个新的位置。对应restore命令
.数据库恢复：指应用所有重做日志，将数据库恢复到崩溃前的状态，或者应用部分REDO，将数据库恢复到指定的时间点。对应使用recover命令
9.1 RMAN恢复扫盲
恢复步骤
.将数据库置于正确的状态:mount/open,一般整哭恢复需要在mount状态操作，表空间或者数据文件级的恢复也可以在open状态
.执行完全或不完全恢复
.打开数据库.如果执行不完全恢复，打开时必须指定restlogs.
9.2.1 对数据库进行完全介质恢复
如果当前数据库只剩下控制文件和spfile，其它数据文件因为某些原因导致全部丢失，不过幸运的是之前创建过整库的备份，并且执行备份操作之后，所有的归档文件和重做日志文件都还在，这种情况下可以将数据库恢复崩溃前那一刻状态，这种恢复方式叫完全介质恢复.
恢复步骤：
1.启动数据库到加载状态
RMAN>starup mount;
2.执行恢复操作
RMAN>restore database;
RMAN>recover database delete archivelogs skip tablespace temp;
3.打开数据库
RMAN>alter database open;
上述操作在归档模式下进行，如果是非归档模式，在执行restore命令前，首先需要恢复之前备份的控制文件，并且在执行restore和recover命令后，必须以open restlogs方式打开数据库
注意：RMAN备份不备份临时表空间的数据文件，恢复时自动创建临时表空间的数据文件
2.从备份集中恢复
10g开始，restore命令直接提供了from backup子句，这样就可以直接从指定的备份片段中恢复控制文件，在启动数据库之前，必须首先通过
set命令设置dbid：
RMAN>set dbid=....;
启动数据库到nomount状态：
RMAN>starup nomount;
执行restore命令时指定控制文件所在备份片段的详细路径:
RMAN>restore controlfile from '';
提示：
使用备份的控制文件进行恢复之后，必须recover database,并且以open restlogs方式打开数据库.
3.归档模式无备份，丢失数据文件的恢复
执行修复：
SQL> alter database create datafile 'F:ORACLEPRODUCT10.2.0ORADATATESTBOOKS01.DBF' as 'F:ORACLEPRODUCT10.2.0ORADATATESTBOOKS01.DBF';
SQL> recover datafile 7;
完成介质恢复。
SQL> alter database open;
恢复的关键:丢失的数据文件，从其创建时刻起所有的重做日志文件都还在，通过重建该数据文件后，通过recover命令应用所有重做日志文件的方式，重建该数据文件中的内容。
TEST (DBID=2110641229)
host del F:oracleproduct10.2.0oradata estcontrol*
4.丢失控制文件的恢复
.删除控制文件
host del F:oracleproduct10.2.0oradata estcontrol*
.启动数据库到noumout状态
SQL>startup nomount;
.开启rman窗口
>set oracle_sid=test;
>rman target /
.必须先指定DBID
RMAN>set dbid=2110641229
由于备份是在nocatalog模式下，因此备份信息、备份设置都是存储在目标数据库的控制文件中，现在控制文件丢失，相当于前面的一些配置也丢失了，用show all命令查看，所有配置都恢复成了默认值.
RMAN>show all;
此时要恢复控制文件，不能直接使用restore controlfile from autobackup命令，因为自动备份的设置也丢失了，并且此时也是在nocatalog模式下，无法配置controlfile autobackup的相关属性，因此选择显示指定控制文件备份集的方式恢复控制文件.执行命令如下：
RMAN> restore controlfile from 'F:oracleoraclescript
manbakC-2110641229-20131212-00';
.有了控制文件，可以将数据库设为mount状态
RMAN>alter database mount;
.由于只是控制文件丢失，数据文件仍在，因此并不需要对整个数据库进行修复，只需要执行recover命令，重新应用备份的控制文件生成的那些重做日志即可：
RMAN>recover database;
.打开数据库
RMAN>alter database open resetlogs;
5.丢失联机重做日志文件的恢复
5.1 丢失非当前的联机重做日志文件
.模拟文件丢失
SQL>shutdown immediate
SQL>host del F:oracleproduct10.2.0oradata est
edo01.log
.动态性能视图V$log中记录联机重做日志组的信息,从中可以查询当前的联机重做日志:
SQL>select group#,thread#,sequence#,members,archived,status from v$log;
SQL>select * from v$logfile;---查询联机日志文件
其中，status：
.unused:表示重未用过.一般刚刚创建或open resetlogs打开后，联机重做日志组为这一状态
.current：表示当前的
.Active：表示活动的.虽然不是当前状态，但也可能正被使用或要被使用
.clearing:日志正在清空，当执行alter database clear logfile语言时该日志组会变成这种状态，语句执行后，操作日志组状态变为unused
.clearing_current:日志正在清空,但是由于清空时出错如I/O设备无法访问，导致清空工作不能顺序完成，则该日志组就会被置于这种状态
.Inactive:不活动状态，表示该组日志中的内容已经被归档或顺利写入数据文件，该组日志可被继续重用.
5.2 修复丢失的联机重做日志文件
通过alter database clear logfile命令重建该组重做日志文件即可:
SQL>alter database clear logfile group 3;
然后就可以正常打开数据库：
SQL>alter database open;
5.3 丢失当前的联机重做日志文件
如果没有备份，就只能强制恢复了，需要修改一个隐藏的初始化参数：
SQL>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
这是一个隐藏参数，设置为true后，oracle在open时会跳过一些一致性的检查.
Chap 10 DataGuard
。逻辑standby 接收Primary数据库生成的REDO，将其转换成SQL语句，然后在standby数据库上执行SQL语句实现同步，叫SQL Apply
。物理standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现同步，叫Redo Apply
10.1 Data Guard服务
.Redo传输服务
oracle通过RTS服务控制REDO数据，从primary数据库发送到其它一个或者多个归档目标.归档目标既可以指向本地路径，也可以指向一个远端的Service Name.
.Log应用服务(Log Apply Services)
LAS服务主要用来应用REDO数据到Standby数据库，以保持Standby数据库与Primay数据库的事务一致
REDO数据既可以从Standby数据库端的归档文件中读取，也可直接应用Standby
.角色转换
一套DG环境中只有两种角色:Primary和Standby，所谓角色转换就是让数据库在这两个角色中切换，切换也分两种：switchover和failover
.switchove:Primary数据库和Standby数据库之间的角色切换，switchover可以确保数据不丢失
.failover:当primary数据库出现故障并且不能及时被恢复时，通过failover将DG配置的其中一个Standby数据库转换为新的Primary数据库.在最大保护模式或最高可用性模式下，failover也可以保证数据不会丢失
10.1.1.3 保护模式
.最大保护(Max Protection)：确保数据绝无丢失，要求所有的事务在提交前其REDO不仅被写入到本地的online redologs，还要同时写入到Standby数据库的Standby Redologs，并确认REDO数据至少在一个Standby数据库中可用。如果出现什么故障导致Standby数据库不可用(如网络中断),Primary数据库会被Shutdown
.最高性能(Max performance):不影响primary数据库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前primary数据库的REDO数据至少需要写入一个Standby数据库，不过这种写入方式可以不同步
.最高可用性(Max availability)
与最大保护模式类似，也要求本地事务在提交前必须写入一台Standby数据库的StandbyRedologs中，不过与最大保护模式不同的是，如果出现故障导致standby数据库无法访问，primary数据库并不会被shutdown，而是自动转为最高性能模式，等standby数据库恢复正常之后，primary数据库又会自动转换成最高可用性模式。
10.1.2.1 Standby数据库类型
1.物理Standby
在物理Standby没有执行REDO应用操作的时候，可以将物理Standby数据库以Read Only模式打开
。REDO应用 物理Standby通过REDO应用来保持与Primary数据库的一致性，所谓REDO应用，实质是通过Oracle的恢复机制，应用归档文件(或Standby Redologs文件)中的REDO数据.恢复操作属于块对块的应用.REDO应用是物理Standby数据库的核心.
。READ ONLY模式打开
以READ ONLY模式打开后，可以在Standby数据库执行查询或备份操作，此时Standby数据库仍然能够继续接收Primary数据库发送的REDO数据，不过并不会应用，直到Standby数据库重新恢复REDO应用.也就是说在READ Only模式下不能执行REDO应用，REDO应用时数据库肯定处于未打开状态。如果需要的话，可以在这两种状态之间转换，如先应用REDO，然后将数据库置为READ ONLY状态，需要与primary同步时再次执行redo应用命令，切换回REDO应用状态。
。READ WRITE模式打开
以Read Write模式打开，Standby数据库将暂停从Primary数据库接收REDO数据，并且暂时失去灾难包含的功能。可以暂时置为此状态，操作完之后将数据库闪回到操作前的状态(闪回后,dataguard会自动同步，不需要重建物理standby,不过如果没有启动闪回，那就回不到READ WRITE前的状态了)
10.2.1 物理standby创建前的准备工作
.启用Force Logging
SQL>alter database force logging;
SQL>alter database no force logging;
10.2.1.2 创建密钥文件
F:orapwd file=f:oracleproduct10.2.0db_1databasePWDtest.ora password=xxxx entries=30
注意：windows平台和Linux平台密钥命名规则不同：
.Windows:PWD[sid].ora
.Linux:orapw[sid]
10.2.1.3 配置standby redologs
对于最大保护和最高可用性模式，建议为standby数据库配置standby redologs，并使用LGWR SYNC模式传输REDO数据.
1.关于Standby Redologs
创建适当数目的日志组，一般比primary数据库的online redologs日志组至少多一个
2.管理standby redologs
standby redologs的操作方式与online redologs几乎一样，只不过在创建或删除时需要多指定一个standby关键字
SQL>alter database add standby logfile group 4('F:oracleoradata eststandbyrd01.log') size 200m;
SQL>alter database drop standby logfile group 4;
standby redologs专用视图v$standby_log查看当前数据库中创建的standby redologs
10.2.1.4 设置初始化参数
10.2.2.2 创建standby数据库控制文件
SQL>alter database create standby controlfile as 'd:ackupjsspdg01.ctl';
10.2.2.3 配置standby数据库的初始化参数文件
(1)创建pfile客户端初始化参数文件
SQL>create pfile='d:akcupinitjsspdg.ora' from SPFILE;
(2)修改初始化参数文件中的参数
10.2.2.4 复制文件到standby服务器
复制文件：备份的数据文件、创建的standby数据库控制文件和修改过的初始化参数文件
10.2.2.5 配置standby数据库
.创建新的oracleservice(windows环境需要)
.创建密钥文件，注意与primary密码一致
.配置监听并启动
.修改tnsnames.ora
.创建服务器端的初始化文件
10.2.2.6 启动物理standby数据库REDO应用
物理standby启动startup后，数据库为READ ONLY模式
通常情况下，物理standby数据库加载到mount状态即可：
SQL>startup mount;
进入mount状态后，standby数据库就开始接收primary数据库发送的归档redo数据，然后可以通过一些命令应用这些redo数据.
启动redo应用:
SQL>alter database recover managed standby database disconnect from session;
或者附件using current logfile子句启动实时应用：
SQL>alter database recover managed standby database using current logfile disconnect from session;
注:要启动实时应用，Primary数据库在发送redo数据时必须使用LGWR进程发送.如果使用ARCH方式发送redo数据,standby数据库无法启动实时应用，强行启动报错.
TIPS:
disconnect from session子句并非必须，该子句的作用，指定启动完应用后自动退出到命令操作符前.如果不指定该子句，当前session就会一直停留处理redo应用.如果想做其他操作，只能新建一个连接.
10.2.2.7 停止standby数据库
正常情况下，首先停止Primary，如果直接停止standby数据库，轻则Primary数据库的alert文件中记录一堆归档发送失败的错误信息，重则Primary直接shutdown。如果必须要这么做，需要修改Primary数据库的log_archive_dest_state_n参数，暂时取消向standby数据库发送日志，例如:
SQL>alter system set log_archive_dest_state_2=defer;
这样standby端不可访问时，Primary数据库的alert日志文件中也不会再报错
然后standby端就可以停止redo应用：
SQL>alter database recover managed standby database cancel;
最后是关闭standby数据库:
SQL>shutdown immediate;
接收归档，打开远端归档：
SQL>alter system set log_archive_dest_state_2=enable;
查看归档的文件:
SQL>select * from v$archived_log
Primary修改的数据是否能够在Standby数据库中看到，受一下因素印象：
.同步模式：默认情况Primary端发送归档日志通过arch方式，只有当Primary切换日志时，产生的归档文件才会被发送到standby端；
.是否应用了应用：将redo数据发送到standby端，并不代表standby数据库中拥有了这些数据，必须手动执行应用命令，将Primary数据库修改过的修改应用到standby数据库后，才能从standby端看到.
.是否实时应用：当你在standby端配置了standby redologs文件，并且Primary在传输REDo数据时也采用了LGWR同步传输的方式
SQL>set SQLPROMPT "JSSPDG>"
(7)启动热动应用
SQL>alter database recover managed standby database disconnect from session;
在打开数据库之前，必须首先暂停redo应用:
SQL>alter database recover managed standby database cancel;
10.2.4 物理standby的角色转换
.检查是否支持switchover操作
SQL>select switchover_status from v$database;
--to standby 则表示Primary数据库支持转换为standby角色，如果为sessions active，说明当前有人扔在连接Primary数据库
.启动switchover
首先将Primary数据库转换为standby角色
SQL>alter database commit to switchover to physical standby; 该语句还提供了一个with session shutdown子句，专门用来处理前步骤中仍有用户在连接的情况。
.重新启动到mount状态(原Primary数据库操作).首先shutdown原Primary数据库，然后启动到mount状态:
SQL>shutdown immediate
SQL>starup mount
此时原Primary数据库就是以Standby身份在运行
.检查是否能否执行switchover操作(待转换Standby数据库操作)
待原Primary切换为Standby角色之后，检查待转换的Standby数据库switchover_status列，看是否支持角色转换.
SQL>select switchover_status from v$database;
--To Primary
此时待转换的Standby数据库，状态若为sessions active.另外还有可能显示为switchover pending,这说明当前Standby数据库没有启动REDO应用，重新执行Alter database recover managed standby database disconnect from session命令即可.
.转换角色到Primary(待转换Standby数据库操作).通过下面语句转换为Standby数据库为Primary角色:
SQL>alter database commit to switchover to primary; 同样支持with session shutdown
注意：待转换的物理Standby可以处于mount模式或open read only模式，但是不能处于open read write模式
.完成转换，打开新的Primary数据库
SQL>alter database open;
10.2.4.3 物理Standby的failover
如果待转换角色的Standby处于max protection模式，需要切换为max performance模式
SQL>alter database set standby database to maximize performance;
如果待转换的Standby处于Maximum Protection或Maximum Availability模式的话归档日志应该是连续存在的，这种情况可以直接从第三步执行，否则按照第一步开始执行
1.检查归档文件是否连续
查询待转换Standby数据库的V$archive_gap视图，确认归档文件是否连接
>select * from v$archive_gap
如果有返回记录，按照列出的记录号复制对应的归档文件到待转换的Standby服务器
文件复制过来后，通过下列命令将其加入数据字典:
SQL>alter database register physical logfile 'filespec1';
2.检查归档文件是否完整
分别在Primary和Standby数据库执行下列语句：
SQL>select distinct thread#,max(sequence#) over(partion by thread#) a from v$archived_log;
取得当前数据库各线程已归档文件最大序号，如果Primary和Standby最大序号不相同，必须将多出的序号对应的归档文件复制到待转换的Standby服务器。
3.启动failover
SQL>alter database recover managed standby database finsh force;
force 关键字会停止当前活动的RFS进程，以便立即执行failover
4.切换物理Standby角色为Primary
SQL>alter database commit to switchover to primary;
5.启动新的Primary数据库
如果当前DB已经mount，直接open即可，如果处于read only模式，首先shutdown immediate，然后再startup
SQL>alter database open;
10.2.5 用Read Only模式打开物理standby
1.物理Standby数据库从shutdown状态启动到read only状态，直接startup即可
SQL>starup
2.物理Standby数据库从REDO应用状态启动到READ ONLY状态
首先需要取消REDO应用
SQL>alter database recover managed standby database cancel;
虽然当前是在mount状态，但并不能直接alter database open
SQL>alter database open;
open的时候不需要附件read only子句，oracle会根据控制文件判断是否是物理standby，从而自动启动到READ ONLY模式
3.物理Standby数据库从READ ONLY状态切换回REDO应用状态
要从OPEN状态切换回REDO应用状态，并不需要shutdown数据库再启动，直接执行应用REDO语句即可
SQL>alter database recover managed standby database disconnect from session;
10.2.6.1 创建表空间或数据文件
初始化参数standby_file_management用来控制是否自动将Primary数据库增加表空旷或数据文件的改动，传播到物理Standby数据库.该参数有两个值:
.AUTO:Primary数据库执行表空间创建操作也会被物理Standby数据库执行
.MANUAL:
删除表空间：
>drop tablespacexx including contents and datafiles;
10.2.7.2 监控恢复进度
1.查看进程的活动状态
v$managed_standby视图专门用于显示物理Standby数据库相关进程的当前状态，关注PROCESS CLIENT_PROCESS SEQUENCE#和STATUS
SQL>select process,client_process,sequence#,status from v$managed_standby;
1.process:进程名称，如ARCH,RFS,MRP0
2.client_p:对应Primary数据库中的进程，如ARCH，LGWR
3.sequence#：归档序号
4.status：进程的当前状态，
.allocated:正在准备连接Primary数据库
.attached:正在连接Primary数据库
.connected:已连接至Primary数据库
.idle:空闲中
.receiving:归档文件接收中
.opening：归档文件处理中
.closing:归档文件处理完，收尾中
.writing:redo数据库写向归档文件中
.wait_for_log:等待新的redo数据中
.wait_for_gap:归档有中断，正等待中断的那部分REDO数据
.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 from v$archive_dest_status where status='VALID';
3.检查归档文件路径和创建信息
物理Standby数据库端可以通过查询v$archived_log视图，获取归档文件的一些附加信息，如文件创建时间，归档进程，归档序号，是否被应用等
SQL>select name,creator,sequence#,applied,completion_time from v$archived_log;
4.查询归档历史
物理standby数据库端通过v$log_history视图，可以查询所有已被应用的归档文件信息
SQL>select first_time,first_change#,next_change#,sequence# from v$log_history;
5.查看物理standby数据库未接收的日志文件
从Primary端获取。日志文件的发送通过log_archive_dest_n参数来控制，因此只需要比对本地生成的归档和远端生成归档差异
>select local.thread#,local.sequence# from(select thread#,sequence# from v$archived_log where dest_id=1) local
where local.sequence# not in(select sequence# from v$archived_log where dest_id=2 and thread#=local.thread#);
tips:dest_id=n,n其实就是log_archive_dest_n参数中的N
10.2.7.3 监控日志应用服务
1.查询当前数据的基本信息
数据库角色、包含模式、保护级别
SQL>select database_role,db_unique_name,open_mode,protection_mode,protection_level,switchover_status from v$database;
2.查看当前redo应用和redo传输服务的活动状态
查看物理standby数据库当前redo应用和redo传输服务的状态，v$managed_standby视图
>select process,status,thread#,sequence#,block# from v$managed_standby;
3.检查应用模式(是否启用了实时应用)
物理standby数据库查询v$archive_dest_status视图，如果打开实时应用，则recovery_mode列显示为managed real time apply
SQL>select recovery_mode from v$archive_dest_status where dest_id=2;
4.data guard事件(v$dataguard_status)
该视图显示那些被自动触发写入alter.log或服务器trace文件的事件.
SQL>select message from v$dataguard_status;
10.2.8 调整物理standby端redo数据应用频率
调整应用频率，说白就是调整I/O读取能力
.设置recover并行度
在介质恢复或redo应用期间，都需要读取重做日志文件，默认都是串行恢复
SQL>recover standby database parallel 2;
建议parallel的值为#CPUs*2;
.加快redo应用频繁
设置db_block_checking=false能提高2倍左右的应用效率
.设置parallel_execution_message_size参数值
.优化磁盘I/O
disk_asynch_io=true;
10.3 逻辑standby
10.3.2.6 打开逻辑standby及应用redo数据
SQL>alter database open resetlogs;
在逻辑standby端启动SQL应用
SQL>alter database start logical standby apply;
注意:应用redo数据时必须是在open read write模式下
启动redo应用:
SQL>alter database start logical standby apply immediate;
停止：
SQL>atler database stop logical standby apply immediate;
10.3.3.3 转换物理standby为逻辑standby
SQL>show parameter db_name
SQL>alter database recover to logical standby JSSLDG;
执行完该语句之后，关闭数据库并重新启动到mount状态
重启是因为涉及逻辑standby数据库更名，包括DBID,INCARNATION
10.3.4 玩转逻辑standby的角色转换
1.准备工作
.检查初始化参数fal_server、fal_client、log_archive_config
.检查log_archive_dest_n参数值设置是否正确
SQL>show parameter fal;
SQL>show parameter log_archive_dest;
DBLINK:
>create database link getjssweb connect to jss identified by jss using 'jsspre_192.168.100.100';
>alter session enable guard;
10.4 DataGuard服务
10.4.1 REDO传输服务(redo transport services)
1.认识log_archive_dest_n参数
2.使用ARCn进程发送REDO数据
redo传输服务使用ARCn进程发送REDO数据.
Chap 11 FlashBack
11.1.1 应用flashback query查询过去的数据
11.1.1.1 基于时间的查询(as of timestamp)
SQL>select * from flash_tbl as of timestamp sysdate-5/1440;
通过以上记录恢复:
SQL>insert into flash_tbl
select * from flash_tbl as of timestamp sysdate-5/1440 where id<10;
11.1.1.2 基于SCN的查询(AS OF SCN)
获取SCN的方法：
a.select current_scn from v$database;
b.select dbms_flashback.get_system_change_number from dual;
b的前提是要有操作对象的访问权限:
>grant execute on dbms_flashback to user;
获取SCN，然后删除操作并提交:
>select dbms_flashback.get_system_change_number from dual;
>delete flash_tbl where id>10;
执行select语句并附加as of scn,同时指定删除前的SCN,可以查询到指定SCN时对象中的记录:
>select * from flash_tbl as of scn .....;
执行insert，将删除的数据重新恢复回表:
SQL>insert into flash_tbl select * from flash_tbl as of scn .... where id>10;
SQL>commit;
使用scn查询比timestamp更精确
不过在实际执行flashback query时，时间转换后具体对应哪个SCN，通过sys用户下smon_scn_time来记录
SQL>desc sys.smon_scn_time;
在10g中，系统评价每3秒产生一次系统时间与SCN的匹配并存入sys.smon_scn_time表：
>select scn,to_char(time_dp,'YYYY-MM-DD HH24:MI:SS') as time from sys.smon_scn_time order by time;
在oracle数据库也可手动进行时间和SCN的转换，oracle提供了两个函数SCN_TO_TIMESTAMP和TIMESTAMP_TO_SCN
SQL> SELECT TIMESTAMP_TO_SCN(SYSDATE) FROM DUAL;
SQL> SELECT TO_CHAR(SCN_TO_TIMESTAMP(4942206),'YYYY-MM-DD HH24:MI:SS') FROM DUAL;
11.1.3 使用dbms_flashback包实现flashback query
11.1.2 应用flashback Query查询操作的事务
11.1.2.1 使用flashback version query查询记录修改版本
查询过去某个时间点对象中保存的记录信息，在当前时间与指定的过去某个时间点之间，对象可能做过多次修改。
flashback version query也是以select查询后面附加versions between timestamp[/SCN] start and end子句即可。通过version between能够查看指定时间段内undo表空间记录的不同版本.
11.1.2.2 使用flashback transaction query查询事务信息
flashback transaction query功能在实际应用时对应的是个视图：flashback_transaction_query
注意：查询flashback_transaction_query视图，用户需要是DBA角色，或被授予了select any transaction权限
>grant select any transaction to xxx;
11.1.3 应用flashback query注意事项
11.1.3.1 自动撤销管理表空间
要使用flashback的相关特性，必须启用自动撤销管理表空间，不单单对于flashback query，也包括flashback table和flashback database，对于后两项还有其它附件条件，如flashback table需要启用recycle bin(回收站),flashback database 要求启用flashback area(闪回区)
9i后取消回滚段说法，完全以UNDO段代替，正好与REDO概念相对应.
UNDO端不再由DBA手工介入，完全由oracle在运行时自动分配.
是否启用自动撤销管理表空间由两个初始化参数决定：
.undo_management:值为auto表示使用自动撤销表空间管理，manual则表示手动
.undo_tablespace:oracle数据库中个可以创建多个undo表空间，不过同时只能使用一个，当undo_management初始化参数为auto时，undo_tablespace参数用来指定当前使用的undo表空间名称
undo表空间大小，直接影响到flashback query的查询能力。
11.1.3.2 初始化参数undo_retention
用来指定undo段中数据保存的最短时间，以秒为单位，是一个动态参数，可以在实例运行随时修改，默认900秒，15min
11.2 Flashback Table闪回表
oracle10g引入一个recycle bin的功能(主要针对被删除的表及其关联的对象,如触发器、索引、约束)，被删除的表并非真正删除，而是先通过修改数据字典的方式，将其改名并放入recycle bin中，如果要恢复recycle bin中的对象，借助flashback table是最简便的方式
11.2.1.1 删除恢复实验
SQL>drop table temp1;
SQL>select object_name,original_name from recyclebin;
如果commit恢复没有用
SQL>flashback table temp1 to before drop;
11.2.2 从UNDO表空间恢复
基于UNDO的表恢复，被恢复的表必须启用ROW MOVEMENT.表的ROW MOVEMENT属性用来控制是否运行修改列值所造成的记录移动.
查询表是否启用或禁用ROW MOVEMENT
SQL> select row_movement from user_tables where table_name='FLASH_TBL';
触发recycle bin主动清除原因:没有足够的空间.导致出现这个结果的原因：
.表空间无足够的空闲，并且没有新的空间扩展操作
.该表空间内又要创建新的对象，需要分配空间
3.清除Recycle Bin中的现有对象
>show parameter RECYCLEBIN;
清空当前的Recyclebin
>purge recyclebin
用PURGE指定表
>purge table tmp;
11.3 Flashback Database闪回数据库
11.3.1.2 操作原理
oracle为了实现Flashback Database特性，另外引入了一组新的日志文件:Flashback Logs 这些信息被写入一个专用的存储区叫Flash Recovery Area,简称FRA.当需要Flashback Database时，通过Flashback Log中保存的数据，就可以快速将oracle数据库恢复到指定时间点块的状态,然后再通过应用重做日志，将数据库恢复到一致性状态.
Flashback Log的创建、删除、修改都是由Oracle自动进行，完全无须DBA手工干预，唯一需要DBA介入的，就是给FlashRecoveryArea分配适当的空间
。数据库必须处于归档模式
。数据库必须指定了Flash Recovery Area
两个参数控制:
.DB_RECOVERY_FILE_DEST:指定FRA的存储路径
.DB_RECOVERY_FILE_DEST_SIZE：指定FRA最大可用空间
。数据必须启动Flashback Database
Flashback Database作为一项特性存在,在应用该功能前，必须启用该特性
>select flashback_on from v$database;
启动Flashback database特性:
>alter database flashback on; 该命令必须在MOUNT模式执行，并且数据已经打开了归档模式.
。再来一个初始化参数:DB_FLASHBACK_RETENTION_TARGET
该参数用来控制Flashback Logs保留的时间
SQL> show parameter db_flashback_retention_target
。启用Force Logging
>select force_logging from v$database;
>alter database force logging;
11.3.2 Flashback Database操作示例
1.检查是否启动flash recovery area:
>show parameter db_recover
2.检查归档
>archive log list
3.检查是否启用Flashback database和Force Logging
>select flashback_on,force_logging from v$database;
4.查询当前的SCN
>select dbms_flashback.get_system_change_number from dual;
5.模拟误删除
>drop table table1 purge
>drop table table2 purge;
6.重新启动到mount
>shutdown immediate
>startup mount
>flashback database to scn xxxxxx;
>alter database open resetlogs;
执行以上命令之后，两种方式修复数据库:
1)直接alter database open resetlogs打开数据库，当然指定SCN之后产生的数据丢失
2)另外一种方式先执行alter database open read only命令以read only模式打开数据库，然后立刻通过逻辑导出的方式将误操作涉及表的数据导出，再执行recover database命令以重新应用数据库产生的redo，将数据库修复到flashback database操作前的状态，然后再通过逻辑导入的方式，将之前误操作的表重新导入.
Chap 12 Import/Export导入和导出数据
一般情况，Import/Export工具可以完成任务
.获取数据库中对象的创建脚本
.备份数据
.跨平台、跨版本的迁移数据
.在多个oracle数据库之间通过传输表空间特性快速复制数据
eg>exp scott/tigger@jsspre file=scott_tables.dmp log=scott_tables.log
eg>imp
12.2.1 创建相关视图和角色
如果使用DBCA界面方式创建的数据库，DBCA会自动创建执行imp/exp所需的视图和角色。如果数据库是手动通过CREATE DATABASE语法创建,那么在执行IMP/EXP之前，必须首先执行cataxp.sql或catalog.sql
cataxp.sql脚本文件中语句主要执行下列任务:
.创建执行Import、export所需的数据字典及相关视图
.创建EXP_FULL_DATABASE角色并授予相应的权限，拥有该角色的用户能够执行整库的导出
.创建IMP_FULL_DATABASE角色并授予相应的权限，拥有该角色的用户能够执行整库的导入
.将EXP_FULL_DATABASE/IMP_FULL_DATABASE两个角色授予DBA
12.2.2 授予权限
执行IMP/EXP的用户至少要有CREATE SESSION权限，即连接oracle数据库的权限
默认情况，用户只能导出自己的表，要导出其它SCHEMA拥有的表，执行导出的用户还必须拥有EXP_FULL_DATABASE角色
>grant create session to xxx;
如果要授予SCOTT用户导出其它用户中的对象
>grant exp_full_database to xxx;
查看帮助>exp help=y
12.2.3.4 处理模式
Import/Export工具提供4种操作模式
.整库模式：导出或导入整个数据库，只有拥有EXP_FULL_DATABASE和IMP_FULL_DATABASE角色的用户或特权用户才能执行
.表空间模式:导出或导入指定表空间中的对象数据,对应IMP/EXP命令中tablespace参数
.用户模式:导出或导入用户自有对象，即owner为当前连接用户的所有对象，如果是DBA角色用户，则可以同时导出多个用户，对应IMP/EXP命令中的owner参数
.表模式:导出或导入指定的表或表的分区,对应IMP/EXP命令中的tables参数
参数owner，该参数用来指定要导出的schema列表，如果同时指定多个schema的话，每个schema名称间以逗号分隔即可.
eg：导出用户scott和jss拥有的对象
>exp system/manager@jsspre_192 owner=(scott,jss) file=schema_scott.dmp log=schema_scott.log
12.3.4 全库导出
全库模式导出与表模式或用户模式导出的唯一区别就是相关参数FULL=Y，当然必须拥有DBA角色，或者拥有EXP_FULL_DATABASE角色的用户才能够执行全库模式的导出。
>exp system/manager@jsspre_192 full=y file=fulldb.dmp log=fulldb.log
查询当前用户所属对象占用空间;
>select sum(bytes)/1024/1024 M from user_segments;
>select owner,sum(bytes)/1024/1024 m from dba_segments group by owner
直接路径导出、直接路径导出、压缩空间
12.4 imp导入
chap 13 Data Pump导入和导出数据
Data Pump导入/导出工具是一个服务器端的工具，它是通过调用服务器端Data Pump API的方式实现数据加载或卸载，一般在目标服务器上执行.
13.1.2 Data Pump 如何处理数据
Data Pump以下方式导入或导出数据:
.直接路径方式
.外部表方式
.复制数据文件方式
13.2 调用IMPDP/EXPDP
1.命令行方式调用
>exp scott/tigger@jsspre_192 tables=(emp,bonus) file=F:xx.dmp log=F:xx.log
2.参数文件方式调用
expdp username/password@tnsname parfile=paramter.dat
13.3 过滤对象或数据
13.4 Data Pump执行导出
创建DBLink
>create database link ZJLPD_FROM_DB09 connect to ZJ_LPD identified by zj_lpd using '192.168.100.66/DB09';
Chap 14 使用传输表空间迁移数据
14.1 传输表空间
实现复制数据的方式介于物理和逻辑方式之间，原理:首先通过Export逻辑导出工具或Data Pump Export数据泵导出工具，导出操作的表空间中对象的元数据，然后复制表空间对应的数据文件和刚刚导出生成的Dump文件到目标服务器的适当路径下，最后再导入前面逻辑导出工具生成的Dump文件
Chap 15 Duplicate复制数据库
15.1.1 认识DUPLICATE命令
>duplicate target database to newdbname;
Chap 16 体系机构之数据库结构
对所有未归档的重做日志进行归档：
>alter system archive log all;
不管是创建表空间还是创建表或索引，都支持指定PCTFREE和PCTUSED这两个存储参数，如果创建表等存储对象时未指定，那么该表将自动继承所在表空间的存储参数，设置这两个参数后可以随时通过alter语句进行修改.
1.pctfree参数
pctfree参数用来设置数据块中保留的最小空闲空间的比例，之所以要在数据块中预留出部分空闲空间，主要是考虑数据块中保存的记录有可能发生修改操作.
pctfree参数在指定时是以百分比的形式体现.
2.pctused参数
pctused参数也是指定一个百分比，功能是用来指定当已用空间降低至指定的百分比时，这个数据块才会被放入可用块列表.
16.2.3 区
区是oracle数据库中的最小分配单位，由一组连续的块组成。创建存储对象时至少会为其分配一个区，第一个被分配的区叫初始区.
Autoallocate:自动确定初始区及扩展区大小
>create tablespace mantbs datafile 'F:xxxmantbs01.dbf' size 200M extent management local autoallcate;
通过数据字典查询区的分配情况,要查询指定对象拥有的区,可以通过USER_EXTENTS视图实现:
>select segment_name,tablespace_name,bytes,blocks
from user_extents where segment_name='OBJECTS';
UNIFROM：手动指定初始区和扩展区的大小
>create tablespace mantbs datafile 'F:xxxmantbs01.dbf' size 200M extent management local UNIFROM size 512K;
段：
段由一系列的区组成，一个段只属一个特定的存储对象(如表、索引、LOB列等),实际上当Oracle创建存储对象时，首先分配的就是段.每个段至少包含一个区.
oracle 10g常见段:
(1)数据段：存储表数据
.普通表数据段
.表的分区或子分区
.每个LOB类型都至少拥有两个独立段
.簇表和嵌套表
(2)索引段:存储索引结构
(3)回滚段
(4)临时段
16.2.5 表空间
16.2.5.1 特殊表空间类型
1.SYSTEM表空间
SYSTEM表空间主要用来保存数据库的数据字典,如DBA_*,ALL_*,USER_*均保存在system表空间中
2.SYSAUX表空间
3.UNDO表空间
专门用来保存UNDO数据，而且该表空间中只能用来创建UNDO段
4.临时表空间
该表空间中的对象是临时存在
Chap 17 体系结构之实例结构
17.1 内存结构
.SGA:存放操作的数据、库缓存、数据字典等控制信息的内存区域，这块区域中大多数内容共享存在,几乎所有Oracle进程都会访问这块内存区中的数据
.PGA:服务进程专用的内存区域,非共享
17.1.1 SGA组成结构
操作系统分配给Oracle数据库的内存资源，至少有一半以上会由SGA占用，组成主要分几个不同的池：
.共享池(Shared Pool)
.Java池(Java Pool)
.大池(Large Pool)
.流池(Stream Pool)
.数据缓冲区(Database Buffer Cache)
.重做日志缓存区(RedoLog Buffer)
.shared_pool_size 控制共享池大小
.java_pool_size 控制Java池大小
.large_pool_size 控制大池大小
.streams_pool_size 控制流池大小
.DB_*_cache_size: 共8个相关cache_size参数,分别用来控制各个数据缓冲区的大小
.log_buffer:控制重做日志缓冲区的大小
此外还有两个重要参数，作用于整个SGA内存区:
.SGA_TARGET：用于控制SGA自动内存管理
.SGA_MAX_SIZE:控制实例运行时SGA最大能使用的内存空间
17.1.1.1 设置与SGA相关的初始化参数
10g，直接支持修改当前内存中参数值的SGA参数，包括：shared_pool_size,large_pool_size,java_pool_size,streams_pool_size以及db_cache_size,sga_target
SQL>alter system set db_cache_size=xxxx;
查看当前实例的粒度单位：
>SQL> select component,granule_size from v$sga_dynamic_components;
17.1.1.2 查看SGA内存分配
查看整个SGA的大小
SQL>show sga;
Total System Global Area 612368384 bytes
Fixed Size 1250428 bytes
Variable Size 213912452 bytes
Database Buffers 390070272 bytes
Redo Buffers 7135232 bytes
或者查询v$sga视图
SQL>select * from v$sga;
.Fixed Size:系统固定占用的部分，用来存储数据库和实例的状态等信息
.Variable Size：包括share pool、large pool、java pool、stream pool几个部分
.database buffers:数据缓冲区大小
.redo buffers:重做日志缓冲区大小
如果希望查看SGA中各部分的内存分配情况，可以通过查询V$SGAINFO视图实现
>select name,bytes from v$sgainfo
17.1.2 自动SGA内存管理
oracle 10g之后SGA内存自动管理，sga_target参数管理
启用或禁用SGA内存的自动管理与两个初始化参数有关：
.sga_target:该参数值大于0时，则SGA内存将会自动分配，等于0时则由DBA手动设置相关初始化参数控制SGA的内存分配
.statistics_level:设置为typical或all，以便收集到足够的统计信息
17.1.3 数据缓冲区管理
数据缓冲区中的数据都是共享存在，数据被一次性读取到数据缓冲区之后，只要不被替换出缓冲区，下次再有访问该数据的请求时，都可以直接从内存中获取。
1.数据在缓冲区中的管理方式
oracle通过维护两个列表来管理数据缓冲区的缓存块:
。写入列表(write list):写入列表中维护的是脏缓存块，指那些发生了修改，但尚未保存到数据文件的数据.
。最近最少使用列表(LRU):包括空闲缓存、命中缓存，以及那些还没来得及写入列表的脏缓存块.
查询数据缓冲区的命中率:
SQL> select 1-(sum(decode(name,'physical reads',value,0))/(sum(decode(name,'db block gets',value,0))+(sum(decode(name,'consistent gets',value,0))))) "buffer hit ratio" from v$sysstat;
buffer hit ratio
----------------
.963498866
该查询的返回结果如果非常接近100%,则表名数据缓冲区当前设置的空间足够使用，如果返回的数据低于95%，那么就要考虑加大缓冲区或调整SQL
2.数据缓冲区的大小设置
整个SGA内存区，数据缓冲区的内存分配最复杂.
.默认池:默认情况下从数据文件中读取到的数据库都是存储在这个区域，对应初始化参数db_cache_size
.保持池:为满足那些虽然频繁访问但不是最热的数据块
.回收池:与keep池的功能相反,为了将那些不希望长期保存在数据缓冲区中的数据能够被快速的换出缓存区，对应初始化参数buffer_pool_recycle
17.1.4 共享池管理
共享池(shared pool)是SGA区中最重要的组成部分，由库缓存(library cache)、数据字典缓存(dictionary cache)、用于并发执行消息缓存及控制结构(control structures)几个部分组成.
共享池对应参数:shared_pool_size
共享池主要由库缓存和数据字典缓存组成，
17.1.5 其它缓冲区管理
1.重做日志缓冲区
重做日志缓冲区就是用来临时保存这些重做记录的区域，对应初始化参数log_buffer.
重做记录在重做日志缓冲区中保存的时间并不长，因为重做日志缓冲区的空间并补打，重要记录的目的地是重做日志文件.
触发LGWR进程的条件之一，就是重做日志缓冲区被写满了1/3，或者包含了超过1M的重做记录.
2.大池
主要用于分配大块的内存
为大池分配内存空间对应初始化参数large_pool_size,需要配置大池:
.执行并行查询：用来分配和协调并行查询任务
.RMAN备份：用于RMAN备份的磁盘I/O缓冲区
.UGA:当使用共享服务器方式连接，UGA占用的空间也是在大池中分配
3.Java池
SGA的一个可选内存池，主要用来处理JavaProcedure.
4.Stream池
对应参数:streams_pool_size
17.1.6 SGA共享池和数据缓存池的分配
与SGA有关的是V$DB_CACHE_ADVICE视图和V$SHARED_POOL_ADVICE
1.V$DB_CACHE_ADVICE
该视图用来生成不同数据缓冲池大小时的资源开销
数据缓冲区建议受初始化参数DB_cache_advice的参数值影响，该参数有三个可用值：
.off:关闭建议并且也不为建议分配内存
.ready：关闭建议，不过仍为建议分配内存
.on:启用建议，会占用一定的内存和CPU资源
2.V$SHARED_POOL_ADVICE视图
该视图用来估计不同共享池大小时，各项资源的开销情况
SQL>desc v$shared_pool_advice;
17.1.7 PGA组成结构
PGA是一块保存服务进程的数据和控制信息的内存结构，可以理解为服务于Oracle进程的专用内存区域，非共享存在，每个连接到Oracle的进程都拥有自己独立的PGA区.
PGA主要由两部分组成:私有SQL区和会话内存区
。私有SQL区
当用户连接到oracle数据时，都会在实例中创建一个会话，第一个会话都对应一个连接进程.
每条执行的SQL语句都有一个私有SQl区，即使是多个用户同时执行一条相同的SQL语句,每个执行该语句的会话都有自己的私有SQL区，这些会话使用相同的共享SQL区来保存共享信息，能够共享的信息包括语句的语法分析，执行计划等.
每个私有SQL区又可以分成两个部分：
.持久区：如绑定变量这类会话在执行过程中需要使用的信息都保存在持久区
.运行区:运行区的内容随着会话操作的SQL不同而变化
17.1.7.2 会话内存区
会话内存区用来保存用户会话相关的信息，对于共享服务器连接，会话内存区是共享存在，而不是某个会话私有.
17.1.8 PGA内存管理
对于复杂的查询，返回结果可能需要进行复杂的运算，PGA中专有的缓存区，叫SQL工作区，用来执行下列的操作：
.基于排序的查询，如order by,group by,rollup
.Hash-join
.Bitmap Merge
.Bitmap Create
9i后,Oracle新引入一个初始化参数:PGA_AGGREGATE_TARGET,现在DBA只需要为该参数指定一个可供PGA使用的最大值.
是否启用PGA自动内存管理由初始化参数workarea_size_policy控制，设置为manual，则表示手动管理PGA内存.
PGA_AGGREGATE_TARGET参数设置的是PGA可分配内存的最大值，而不是单个进程能够使用的最大内存，实际上每个SQL工作区能够使用的最大内存仍有限制：
.对于串行操作：每个进程可用的最大内存为min(pga_aggregate_target*0.05,_pga_max_size/2),其中_pga_max_size是一个隐含的初始化参数，默认值为200M
.对于并行操作：每个进程可用的最大内存为pga_aggregate_target*0.3/并行度
Oracle提供了一个视图V$pga_target_advice，可以用来显示不同pga_aggregate_target参数值时PGA的性能统计，当然只是一个预估值：
SQL>desc v$pga_target_advice;
17.2 进程结构
实例的一半是内存，实例的另一半就是进程.与内存不同，进程是实实在在存在.通过相关进程，Oracle实现数据库与实例的联通，通过相关进程，oracle实现数据库与实例的互动;通过相关进程，oracle实现用户对oracle数据库的应用.
Oracle系统涉及的进程分为两类:用户进程和Oracle进程
.用户进程：指用户连接到Oracle数据库的应用的进程,如sqlplus...,这类进程一般存在于用户端
.Oracle进程:Oracle进程就是经纪人角色
17.2.1 Oracle进程
Oracle进程分两类:服务进程和后台进程
17.2.1.1 服务进程
Oracle的服务进程由Oracle实例自动创建，用来处理连接到实例的用户进程发出的请求，用户必须通过连接到Oracle的服务进程来获取数据库中的信息.对于专用服务器模式，用户进程和Oracle进程是一一对应，而在共享服务器模式下，一个Oracle服务进程可能同事服务多个用户进程.
服务进程主要用来执行下列的任务
.解析、执行用户提交的SQL语句
.从磁盘数据文件中读取必须的数据块到SGA的数据缓冲区
.以适当形式返回SQL语句执行结果
17.2.1.2 后台进程
后台进程让内存区与物理文件打交道.
17.2.8 Jnnn 任务队列进程
在Oracle数据库中，用户可以通过创建JOB的方式，在指定时间执行指定的任务.而Jnnn进程就是用来执行用户创建的JOB进程的，该进程以一个队列的形式管理用户创建的JOB.
17.3 实例相关的文件
17.3.1 参数文件(parameter files)
SPFILE位于%ORACLE_HOME%database目录下(Linux/UNIX环境为$ORACLE_HOME/dbs目录下)，并且文件名格式为spfile_[sid].ora
如果要修改spfile初始化参数，两种方式:
>alter system set parameter 对于单个或数个参数的修改,引入spfile后,某些初始化参数支持在实际运行过程中进行修改.对于那些仍然不允许在实例中修改的初始化参数，可以在修改时指定scope=spfile，即只保存在SPFILE中,等下次数据库重新启动时生效
>alter system set sga_max_size=1024m scope=spfile;
17.3.2 警告文件(Alert File)
每个数据库默认都有一个警告文件,该文件默认保持在$ORACLE_BASE/admin[sid]/bdump下,文件名格式为alert_[sid].log,该文件是一个文本格式文件,包括下列内容：
.数据启动和关闭信息,其中包括启动数据库的详细初始化参数
.Oracle数据库在运行过程中出现的严重内部错误
.数据库管理操作
.共享服务进程及高度进程运行时产生的消息和错误
.JOB执行产生的消息和错误
17.3.3 跟踪文件(Trace Files)
每个服务进程和后台进程都能创建自己的跟踪文件,进程跟踪文件有两种触发方式:
1.DBA手动触发
最常见的手动触发进程生成跟踪文件的方式是启动SQL_TRACE
>alter session set sql_trace=true;
此时后台进程已经自动生成了Trace信息并记录到跟踪文件，用户主动触发的跟踪文件，默认将会保存在$ORACLE_BASE/admin/[sid]/udump/[sid]_ora_[process id].trc
UDUMP/CDUMP/BDUMP目录中的trace文件：
这三个目录内分别记录了不同类型进程输出的跟踪文件，其中：
.UDUMP中的U代表User,用来存放用户连接的进程输出的跟踪文件
.CDUMP中的C代表Core,用来存放Oracle内核输出的跟踪文件
.BDUMP中的B代表Background,用来存放Oracle后台进程输出的跟踪文件
这几个目录中的.trc文件均可删除，不会影响到Oracle数据库的运行
Data Guard环境归档中断(GAP)或丢失的处理
FAL(Fetch Archive Log)
FAL机制能够自动处理多种归档中断问题
1.自动处理接收归档
默认情况下Oracle会自动处理归档的中断
.查询Primary数据库端设置，归档目标设置:
>show parameter log_archive;
.FAL相关参数
>show parameter FAL
1.正常情况下接收归档
>select max(sequence#) from v$archived_log;
>select max(sequence#) from v$archived_log;