1,存档模式之后,rman备份将联机日志存档
alter system archive log all;--归档所有已填满的联机日志
alter system archive log current;--归档当前日志文件,强迫一个日志切换(虽然可能日志没满)
alter system switch logfile;--切换日志之后前一个联机日志也会写入存档
2,更改归档路径参数文件到非系统盘
show parameter db_recover--和下面的show db_recovery_file_dest 一样
alter system set db_recovery_file_dest='d:\xs\archivedlogb' scope=spfile;
![](//images0.cnblogs.com/blog/412950/201301/13211209-0746ec6562fd45bfa53e188db987d5a1.jpg)
问:这个big integer具体用途?
答:将归档日志放到其他不受限制的路径下来解决这个问题
3,更改联机日志文件存放目录到非系统盘
步骤
a 关闭数据库
b 使用操作系统的命令拷贝、移动或重命名重做日志文件到目标路径
c mount启动
alter database rename file 'E:\app\xs\oradata\jsce\REDO01.LOG' to 'E:\app\rmanb\redolog\REDO01.LOG';
4,修改rman备份参数--见http://www.cnblogs.com/sumsen/archive/2013/01/12/2857589.html
疑问:rman备份的时候包括了spfile和controlfile,如果之后两者有改变,用之前的rman备份文件还原会恢复为变化之后的吗?
如果是的话,难道spfile和controlfile也归档了吗?如果不是,怎么办?
5自动存档要使用吗,这个存档终点什么意思?存档时间间隔设置?
更新:这里的 USE_DB_RECOVERY_FILE_DEST就是执行修改的步骤2中修改的archivelog归档路径
更改归档区大小:alter system set db_recovery_file_dest_size=6G;
![](//images0.cnblogs.com/blog/412950/201301/16142958-944f716bebee45e19b2519567b049e7d.png)
![](//images0.cnblogs.com/blog/412950/201301/16142950-fff84960ac834f02af44939d18d0c2a5.png)
答:alter system set log_archive_dest_1='location=e:\app\rmanb';可以修改存档终点,并且不需要scope=spfile
但是改之后,归档路径还是上面的db_recovery_file_dest控制,不变,并且不是日期文件夹那种
alter system switch logfile;之后在e:\app\rmanb产生了文件,为什么不是(alter system set db_recovery_file_dest='d:\xs\archivedlogb' scope=spfile;)?
更新:1.19 参考:http://yesican.blog.51cto.com/52065/247338
在10g中,如果指定了db_recovery_file_dest 参数,那么归档日志将存放到这个参数指向的目录下,如果同时指定了log_archive_dest,则将同时往这两个参数指定的目录中归档。
小结:log_archive_dest_n与DB_RECOVERY_FILE_DEST参数都可以用来存放归档日志,但二者的关系是:不设置log_archive_dest_n时,使用DB_RECOVERY_FILE_DEST来存文件;当设置了log_archive_dest_n时,则使用log_archive_dest_n来存放归档日志(系统不再使用DB_RECOVERY_FILE_DEST)。
使用DB_RECOVERY_FILE_DEST存储归档日志是OMF方式,oracle会自动将每天的归档日志生成一个日期文件夹,并且归档的格式是.ARC,如果使用了log_archive_dest_n,可以设置归档日志格式,但是不能每天一个归档文件夹。
如果在更改归档路径之后,oracle没有找到指定的路径,就会hang住
更改了归档路径之后,不用将之前路径的归档复制到新目录,oracle会记录在控制文件中完整的归档日志路径的,修改归档路径后,你不用担心,数据库还是可以找到的,只要你不删除这些归档和这些归档在控制文件中的记录没有被覆盖掉
log_archive_dest_n 的n是1-10,如果都设置了目录,可以同时向十个文件夹写入同样日志,通过冗余保证归档安全。
SQL>alter system set log_archive_dest_1='location=/logs/log_1' ;
去掉
SQL> alter system set log_archive_dest_1='' scope=spfile;
LOG_ARCHIVE_DEST 和 LOG_ARCHIVE_DEST_n 只能取其一。当LOG_ARCHIVE_DEST设置为非空的时候,那LOG_ARCHIVE_DEST_n就不起作用。反之,如果LOG_ARCHIVE_DEST没有设置,则LOG_ARCHIVE_DEST_n的设置才能生效。如果两类参数均未设定,则系统在启动之后启用缺省值
![](http://images0.cnblogs.com/blog/412950/201301/19235718-ff1df0189d334d91bc3ac10529da34c0.jpg)
1.22 号更新:
SYS@ncbeta>alter system set log_archive_dest_1='location=D:\xs\JSCEarlog'; --目录,不用加scope,改了之后立即生效
修改之后归档日志就产生在上述log_archive_dest_1='location=D:\xs\JSCEarlog,db_recovery_file_dest 就不再产生。
SYS@ncbeta>alter system set log_archive_format='JSCE_%s_%t_%r.ARC' scope=spfile; --格式,10g里面需要增加scope=spfile
%s: 日志序列号,%S: 日志序列号(带有前导0),%t: 重做线程编号,%T: 重做线程编号(带有前导0),%a: 活动ID号,%d: 数据库ID号,%r RESETLOGS的ID值.
从10g开始,配置归档日志文件格式时,必须带有%s,%t和%r匹配符,配置了归档文件格式后,必须重启数据库
下图是闪回区修改之后产生的归档db_recovery_file_dest = d:\xs\archivedlogb,最新的日期1.22时间更新停留在9:25
使用log_archive_dest_1='location=D:\xs\JSCEarlog' ,alter system archive log current 归档之后,归档日志产生在这里,上面的闪回区不再用(并且新归档格式)
1.14补充controlfile:
在rman的show all参数有一个CONFIGURE CONTROLFILE AUTOBACKUP ON;
on状态下,所有影响rman恢复的操作就会自动备份controlfile(spfile也有)到指定目录,如下图
查看controlfile --select status,name from v$controlfile;
或者:SYS@ncbeta>show parameter control_files;
修改系统的参数文件--注意:这里是讲前面的01 02控制文件去掉,变成03
>alter system set control_files='C:\app\dell\flash_recovery_area\ncbeta\CONTROL03.CTL' scope=spfile
之后shutdown immediate,手工复制路径下的02改名字为CONTROL03.CTL,重启之后
之后,发现我是要复制三个控制文件的,不是变成只有一个03,于是
SYS@ncbeta>alter system set control_files='C:\app\dell\oradata\ncbeta\CONTROL01.CTL','C:\app\dell\fl
ash_recovery_area\ncbeta\CONTROL02.CTL','C:\app\dell\flash_recovery_area\ncbeta\CONTROL03.CTL' SCOPE
=SPFILE;
启动oracle,崩溃,说“文件比控制文件更新 - 旧的控制文件”。--原因是我直接改名了在上面文件夹下之前copy的老的控制文件
使用之前的rman恢复到出问题之前的时间点,之后发现只有一个控制文件
不过oracle没有问题,于是重做上面的步骤。
SYS@ncbeta>alter system set control_files='C:\app\dell\oradata\ncbeta\CONTROL01.CTL','C:\app\dell\fl
ash_recovery_area\ncbeta\CONTROL02.CTL','C:\app\dell\flash_recovery_area\ncbeta\CONTROL03.CTL' SCOPE
=SPFILE;
重启之后,出现了三个控制文件
2013-01-27 23:03:05 更新
如果数据库在启动或者关闭之后发现一个控制文件损坏(比如oracle之前有两个控制文件,关闭状态下强制手工删除一个控制文件),可以
SYS@jsce>startup mount
ORACLE 例程已经启动。
SYS@jsce>alter system set control_files='E:\app\xs\flash_recovery_area\jsce\CONTROL02.CTL' scope=spfile;--这里更改系统保留一个正确的
系统已更改。
SYS@jsce>shutdown immediate
ORA-01507: ??????
ORACLE 例程已经关闭。
SYS@jsce>startup
ORACLE 例程已经启动。
查看就一个了
SYS@jsce>show parameter control_file;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time integer 7
control_files string E:\APP\XS\FLASH_RECOVERY_AREA\
JSCE\CONTROL02.CTL
2013-01-28 08:52:23 更新:
昨天晚上突然想通了我在itpub发帖对asm中控制文件restore的疑惑,下面是实验步骤:
Copyright (c) 1982, 2010, Oracle. All rights reserved.
已连接到空闲例程。
SYS@ncbeta>startup mount
ORACLE 例程已经启动。
Total System Global Area 1071333376 bytes
Fixed Size 1379384 bytes
Variable Size 570426312 bytes
Database Buffers 494927872 bytes
Redo Buffers 4599808 bytes
数据库装载完毕。
SYS@ncbeta>show parameter control_files;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string C:\APP\DELL\ORADATA\NCBETA\CON
TROL01.CTL, C:\APP\DELL\FLASH_
RECOVERY_AREA\NCBETA\CONTROL02
.CTL, C:\APP\DELL\FLASH_RECOVE
RY_AREA\NCBETA\CONTROL03.CTL
SYS@ncbeta>alter system set control_files=c:/cfncbeta.ctl scope=spfile;
alter system set control_files=c:/cfncbeta.ctl scope=spfile
*
第 1 行出现错误:
ORA-02095: 无法修改指定的初始化参数
SYS@ncbeta>alter system set control_files='c:/cfncbeta.ctl' scope=spfile; --这里更改控制文件路径到'c:/cfncbeta.ctl',目前此路径并没有控制文件
系统已更改。
SYS@ncbeta>
到rman
C:\Documents and Settings\dell>rman target/
恢复管理器: Release 11.2.0.1.0 - Production on 星期一 1月 28 08:58:20 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
已连接到目标数据库: NCBETA (DBID=3184901590, 未打开)
RMAN> restore controlfile from 'C:\APP\DELL\ORADATA\NCBETA\CONTROL01.CTL';
启动 restore 于 28-1月 -13
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=135 设备类型=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: restore 命令 (在 01/28/2013 08:59:59 上) 失败
RMAN-06496: 当数据库已装载或打开时, 必须使用 TO 子句
RMAN> shutdown immediate
数据库已卸装
Oracle 实例已关闭
RMAN> startup nomount;---上面的错误说明控制文件的还原需要到nomount下执行
已连接到目标数据库 (未启动)
Oracle 实例已启动
系统全局区域总计 1071333376 字节
Fixed Size 1379384 字节
Variable Size 570426312 字节
Database Buffers 494927872 字节
Redo Buffers 4599808 字节
RMAN> restore controlfile from 'C:\APP\DELL\ORADATA\NCBETA\CONTROL01.CTL';
启动 restore 于 28-1月 -13
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=134 设备类型=DISK
通道 ORA_DISK_1: 已复制控制文件副本
输出文件名=C:\CFNCBETA.CTL
完成 restore 于 28-1月 -13
RMAN> startup
数据库已经启动
数据库已装载
释放的通道: ORA_DISK_1
数据库已打开
RMAN>
RMAN>
有图有真相一下
1.17号更新
今天终于改成了归档,不过NC真的感觉卡了。
海哥让我看看警告日志,
show parameter background_dump_dest --在oracle home @?/admin/sid/bdump
海哥让我修改下面的几个参数
show parameter sga --两个sga改成4G,修改之后重启
show parameter pga_agg --改成2G,修改之后不重启
修改前后windows资源管理器
前
后
2013-01-22 13:52:45 更新内存占用
2013-08-28 16:54:32 更新
刚刚感觉NC有些慢,然后看了oracle的服务器,不明白为什么硬件没有动的情况下,总内存怎么从11840降到了9794,怪不得慢
一、概念
SGA指系统全局区域(System Global Area),是用于存储数据库信息的内存区,该信息为数据库进程所共享。
PGA
指进程全局区域(Process Global Area),包含单个服务器进程或单个后台进程的数据和控制信息,与几个进程共享的SGA
正相反,PGA 是只被一个进程使用的区域,PGA 在创建进程时分配,在终止进程时回收。 Oracle
10g提供了PGA内存的自动管理。参数pga_aggregate_target可以指定PGA内存的最大值。当参数
pga_aggregate_target大于0时,Oracle将自动管理pga内存,并且各进程的所占PGA之和,不大于
pga_aggregate_target所指定的值。
二、配置
oracle推荐OLTP(on-line Transaction Processing)系统oracle占系统总内存的80%,然后再分配80%给SGA,20%给PGA。也就是
SGA=system_total_memory*80%*80%
PGA=system_total_memory*80%*20%
三、操作
用SYS用户以SYSDBA身份登录系统
alter system set sga_max_size=2000m scope=spfile;
alter system set sga_target=2000m scope=spfile;
alter system set pga_aggregate_target=500m scope=spfile;
然后重新启动数据库
最后查看一下是否生效
show parameter sga_max_size;
show parameter sga_target;
show parameter pga_aggregate_target;
)
2013-01-18 17:23:16 更新
增加了sga和pga,调大和增加了联机日志之后,现在感觉软件流畅多了,比归档模式之前更加的流程,最大的安慰,感谢海哥和上海-Digoss
现在打开科目余额表和银行对账单,秒开
今天一天一共有292M 归档,从下午两点到了晚上十一点才产生了切换,很给力
2013-01-23 11:03:39 更新:
经过昨天 log_archive_dest_1 和db_recovery_file_dest的调研测试之后,刚刚更改了财务正式环境oracle的归档目录到log_archive_dest_1=F:\JSCEarlog,更改了归档的format,切换了一下当前的联机日志,一切正常
我没有敢删除之前归档日志所在闪回区的文件(1.3G),也没有rman重新备份。
现在的环境应该不用去担心归档的大小了(190G足够),也不用担心闪回区大小了(show parameter db_recover,因为我们不用闪回归档)
下面是和digoss的聊天
Sumsen♂ 9:34:46 比如更改归档目录之前的rman全备为r1,更改之后的全备为r2,之后删除了在闪回区的老归档日志,以后需要还原了,oracle肯定用最新的全备还原,也就是r2,可是这时候需要r1时候的归档,那么oracle还能识别吗 上海-Digoss 9:36:02 能 v$archived_log Sumsen♂ 9:37:13 但是如果我把r1删除了呢 上海-Digoss 9:39:45 之前的归档没有删除 可以识别的 Sumsen♂ 9:40:21 也就是说rman的全备份和之前的归档至少要保留一个 上海-Digoss 9:41:07 不保留就是恢复不到那个时候,如果业务没有要求也可以删了 有goldengate 要看是否都同步了 Sumsen♂ 9:41:49 额,那没有问题,因为我们是财务软件,从不需要回到过去,如果要恢复,肯定是恢复到现在
上文也提到:
更改了归档路径之后,不用将之前路径的归档复制到新目录,oracle会记录在控制文件中完整的归档日志路径的,修改归档路径后,你不用担心,数据库还是可以找到的,只要你不删除这些归档和这些归档在控制文件中的记录没有被覆盖掉
2014-01-11 18:28:55
回想起昨天dmp导入归档模式归档被占满的情况,我想到了正式库的归档,如果大量输入写入是不是也会存在卡住呢?
这里存档终点和db_file_recover_desk不是同一个地方
⊙﹏⊙b汗,我之前就问过这个问题了
http://www.itpub.net/thread-1758425-1-1.html
看来我jsce的归档不受限制了,到时候删除一些归档就行了
jsce
RMAN> show all; 使用目标数据库控制文件替代恢复目录 RMAN 配置参数为: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'E:\RMAN ncbacku p\Controlfilebackup\%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT 'E:\RMAN ncbackup\%d_%u_%t'; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default CONFIGURE SNAPSHOT CONTROLFILE NAME TO 'D:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\S NCFJSCE.ORA'; # default RMAN>