如何查看数据库是否处于归档模式

第一种方法

selectname,log_modefromv$database;

-----------------------------------------------------------

第二种方法

archiveloglist

2,oracle启动归档模式？

startupmount

alterdatabasearchivelog;

alterdatabaseopen;

altersystemsetlog_archive_start=truescope=spfile;

修改数据库参数文件c:oracleadminoradbpfileinitora，取消以下语句的#注释

log_archive_start=true

log_archive_dest_1="location=C:Oracleoradataoradbarchive"

log_archive_format=%%ORACLE_SID%%T%TS%SARC

关闭数据库，重新启动

查看C:Oracleoradataoradbarchive目录下，可以看到类似ARC的文件，说明归档成功

解释initora参数文件中关于归档重做日志参数项的含义

归档模式是自动还是手工，true为自动，false为手工

log_archive_start=true

归档日志文件所保存的路径

log_archive_dest_1="location=C:Oracleoradataoradbarchive"

归档日志文件的命名方法

log_archive_format=%%ORACLE_SID%%T%TS%SARC

2、禁止归档

a关闭数据库shutdownimmediate

bstartupmount

calterdatabase

dalterdatabaseopen

一 更改日志 *** 作模式三步走

默认情况下 Oracle数据库采用的是非归档模式 但是 非归档模式不能够防止因物理损坏而导致丢失数据问题 为此数据库管理员可能需要把日志 *** 作模式从非归档模式转换为归档模式 其实 要进行这个转换的话 只需要通过简单的三个步骤即可 不过在进行 *** 作之前 要需要注意 以下的 *** 作都必须要求用户具有数据库管理员的权限 即只有SYSDBA或者SYSOPER身份才能够执行如下的 *** 作

要更改日志 *** 作模式 具体 *** 作步骤如下

第一步 先确定当前的日志 *** 作模式 当数据库管理员更改当前 *** 作日志模式之前 需要先确定一下当前日志 *** 作模式 此时数据库管理员可以查询动态性能视图 来确认当前日志 *** 作模式 如可以利用如下语句来查询我们所需要的信息 动态性能视图中存储著很多数据库运行信息 从中我们数据库管理员可以获取很多有用的信息 如现在要了解当前数据库的日志 *** 作模式 就可以从数据库动态性能视图中获知

第二步 关闭数据库 如果确认数据库当前的日志 *** 作模式为非归档模式 需要把它改为归档 *** 作模式 需要先关闭当前运行的数据库 然后重新装载数据库 需要注意的是 更改日志 *** 作模式只能够在MOUNT状态下进行 因此必须首先关闭数据库 然后重新装载数据库 另外 如果需要更改日志 *** 作模式 那么在关闭数据库时不能够使用SHUTDOWN ABORT命令 SHUTDOWN ABORT命令的作用其实跟KILL进程具有同样的效果 若利用这个命令的话 可能会给数据库带来一些不利的因素 如可能导致文件状态不一致 在数据库正常关闭的时候 数据库会同步校验各个文件 使得重新启动的时候文件时间点一致并且不用进行崩溃修复 而使用这个命令不会进行这个检验 所以 采用SHUTDOWN ABORT命令关闭数据库的时候 可能会导致数据库启动出错 导致已经递交的数据丢失 甚至出现数据库崩溃的噩梦 所以 无论是在更换数据库日志 *** 作模式 又或者其他原因需要关闭数据库的 最好不要采用这个命令 只有在采用其他关闭数据库命令不能够奏效的情况下 才能够使用这个命令 笔者建议通过SHUTDOWN IMMEDIATE命令来关闭数据库

数据库关闭之后 再利用Startup命令 把数据库启动到MOUNT状态 再次提醒一次 只有在Mount状态下才能够更改日志 *** 作模式

第三步 更改日志 *** 作模式 以上准备工作做好之后 就可以利用相关命令来更改日志 *** 作模式 我们可以利用如下命令来进行更改

然后重新打开数据库之后 设置就生效了

二 手工对重做日志文件进行归档

有时候出于某些原因 数据库管理员可能需要手工对重做日志进行归档 在 G以后的版本中 默认情况下 当将日志 *** 作模式从非归档模式转换为归档 *** 作模式的时候 Oracle数据库会在后台自动启动一个ARCH进程 这个进程就是负责重做日志的备份任务 通常情况下 归档模式下 数据库会自动备份重做日志

若需要手工备份重做日志的话 即手工归档 则必须在改变 *** 作日志模式中明确说明 即在上面的命令中 加入MANUAL参数 如果加入这个参数后 则数据库管理员就必须手工执行归档命令 如果数据库管理员没有手工执行归档命令的话 则日志组中的内容就无法被进行覆盖 所以通常情况下 除了一些特殊的需要 如数据库测试 才使用手工归档方式 否则的话 就还是采用自动归档方式更加的合理 值得一提的是 根据笔者了解 这个参数只是一个过渡参数 主要为了跟以前的Oracle数据库版本兼容 估计在不久之后 这个手工归档的参数会取消掉

三 设置归档文件的存储位置

在 *** 作系统管理中 系统管理员往往会重新设置我的文档 IE收藏夹等存储位置 以防止系统奔溃时这些数据的丢失 其实 在Oracle归档日志文件管理中也是如此 当数据库管理员把日志 *** 作模式从非归档模式转换为归档模式时 需要根据实际情况 重新设置归档文件的存储位置

当数据库处于归档模式时 如果进行日志切换 后台进程将自动生成归档日志文件 归档日志文件的默认存储位置为Oracle数据库安装目录下的RDBMS下 而在实际工作中 数据库管理员往往会改变其存储位置 如出于空间的考虑或者安全方面的考虑 会把归档日志存放在数据文件不同的硬盘中 等等

如果需要更改归档日志的 *** 作文件 则需要变更相应的初始化参数 参数Log Archive Dest就是用来控制归档日志的存储路径的 通常情况下 若是没有备用数据库的话 则只需要把归档日志存放到服务器上的独立的硬盘中即可 而不需要进行异地备份 如果需要配置本地归档日志的存储路径 则可以通过以上的初始化参数以及Log Archive Duples_Dest参数 其中前面一个参数用来指定第一个归档日志的位置 第二个参数用来指定第二个归档日志的位置 当分别对以上两个参数进行配置后 数据库系统在进行日志切换时 后台进程就会生成两份完全相同的归档日志 分别存储在上面两个不同的路径中 这里需要强调的一点是 存放在两个不同路径中的归档日志文件是完全相同的 这主要是出于数据安全的需要 一般情况下 只需要一个归档日志即可 若不放心的话 则可以设置多个归档日志存放位置 不过这些归档日志最好能够存放到不同的磁盘上 否则的话 就没有多少的实际意义

除了以上这个配置参数之外 平时工作中 我们还经常会使用Log Archive Dest_N这个参数 这个参数主要用于指定多个归档位置 通常情况下 可以多大十个归档位置 这个参数跟先前提到的两个参数有比较大的不同 数据库管理员要对此有清晰的认识 只有如此 才能够根据自己的需要 选择合适的初始化参数 他们的差异主要有以下几点

一是不带N的初始化参数(即前面的两个参数)只能够用来配置本地归档位置 而后面谈到的这个参数这可以用来配置本地归档位置与远程归档位置 也就是说 如果数据库管理员要把归档日志文件保存在网络上的其它主机中时 就必须利用后面的参数进行配置 这个区别是几个参数之间最大的差异 不过由于网络传输等方面的限制 笔者并不建议把归档日志保存在其它主机上 而是建议在数据库服务器中增加一块独立的硬盘用来保存归档日志文件即可 因为硬盘之间数据的复制要比网络传输要快的多 这可以避免重做日志归档时对网络资源过多的占用 从而降低网络的性能

二是前面两个参数只能够配置两个不同的归档日志位置;而后面一个参数则可以配置多大十个归档日志文件位置 这是两者数量上的差异 不过没什么作用 对于大部分企业来说 可能两个归档日志文件存放位置已经可以满足他们的需求了 另外一个小的差异就是 后面这个参数不能够跟前面两个参数共存 为此 当使用后者这个参数时 就需要先把前面两个参数禁用掉 因为数据库默认情况下 是启动第一个初始化参数的

三是具体的配置也有所不同 利用后者参数指定归档日志存储位置时 如果配置本地归档位之 则需要指定Location选项;如果是配置远程归档日志位置时 则就需要制定Service选项 这个选项主要用来指定远程数据库的网络服务名 通常情况下 数据库管理员可以同时配置本地归档位置与远程归档位置

lishixinzhi/Article/program/Oracle/201311/18259

1、常用命令

SQL> show parameter log_archive_dest;

SQL> archive log list;

SQL> select from V$FLASH_RECOVERY_AREA_USAGE;

ARCHIVELOG 9662 0 141

SQL> select sum(percent_space_used)3/100 from v$flash_recovery_area_usage;

29904

SQL> show parameter recover;

db_recovery_file_dest string /u01/oracle/flash_recovery_area

db_recovery_file_dest_size big integer 2G

2、删除日志

cd $ORACLE_BASE/flash_recovery_area/orcl/archivelog

转移或清除对应的归档日志, 删除一些不用的日期目录的文件，注意保留最后几个文件在删除归档日志后，必须用RMAN维护控制文件，否则空间显示仍然不释放。

3、rman target sys/password

RMAN> crosscheck archivelog all;

RMAN> delete expired archivelog all;

或者

RMAN> delete archivelog until time “sysdate-1″;

4、再查

SQL> select from V$FLASH_RECOVERY_AREA_USAGE;

5、修改大小

SQL> alter system set db_recovery_file_dest_size=4G scope=both;

su - oracle //进入oracle账户

sqlplus / as sysdba //以 *** 作系统权限认证的oracle sys管理员登陆

archive log list //查看数据库的归档模式

注意：输入archive log list会显示出USE_DB_RECOVERY_FILE_DEST

select from V$RECOVERY_FILE_DEST; //查询归档日志空间大小及路径

show parameter recover; //显示归档文件路径

退出到oracle账户根目录然后进入rman输入以下命令进入rman

rman target sys/password

RMAN> crosscheck archivelog all; //验证的DB的归档日志

RMAN> delete expired archivelog all; //删除所有归档日志

RMAN>DELETE ARCHIVELOG ALL COMPLETED BEFORE ‘SYSDATE-7’; //保留7天的归档日志

再查

SQL> select from V$RECOVERY_FILE_DEST;

修改大小

SQL> alter system set db_recovery_file_dest_size=5G scope=both;

关闭归档

SQL> alter system set log_archive_start=false scope=spfile; #禁用自归档

SQL> shutdown immediate; //强制关闭数据库

SQL> startup mount; //重启数据库到mount模式

SQL> alter database noarchivelog; //修改为非归档模式

SQL> alter database open; //打数据文件

SQL> archive log list; //再次查看前归档模式

环境：

AIX61

Oracle 11g RAC

故障：

数据库频繁出现归档日志空间不够，导致数据库无法登陆的故障。一查发现原因是归档日志切换频繁， *** 作系统空间不够。

确定原因：

[aix01@oracle]/oracle>df -g

Filesystem GB blocks Free %Used Iused %Iused Mounted on

/dev/hd4 050 028 44% 13674 17% /

/dev/hd2 300 067 78% 49208 23% /usr

/dev/hd9var 100 037 63% 9285 10% /var

/dev/hd3 200 103 49% 2407 1% /tmp

/dev/fwdump 100 099 2% 30 1% /var/adm/ras/platform

/dev/hd1 025 018 28% 465 2% /home

/dev/hd11admin 025 025 1% 5 1% /admin

/proc - - - - - /proc

/dev/hd10opt 050 028 44% 10241 14% /opt

/dev/livedump 025 025 1% 12 1% /var/adm/ras/livedump

/dev/oraclelv 3000 1129 63% 161681 6% /oracle

/dev/installlv 1500 338 78% 6478 1% /install

/dev/crslv 1000 335 67% 7807 1% /crs

/dev/wmsapplv 3000 1749 42% 15537 1% /wmprod

/dev/archivelv 2925 2925 1% 4 1% /arch1

/dev/backuplv 40000 10713 74% 306 1% /sysbackup

aix02:arch2 3025 064 99% 3 1% /arch2

可以看到，/arch2里文件系统空间已经达到99%，/arch2是用来存放归档日志的文件系统，进而导致数据库出错。

提出问题：

这下问题来了，/arch2的空间是30G，每天备份脚本都会自动rman备份归档日志，并自动清除归档日志文件，按照正常情况下，数据库不可能一天产生这么大的归档日志量。

如何查询归档日志都是由什么应用产生的，这就是logminer的用途。

使用方法：

-- 1指定要分析的日志文件

exec sysdbms_logmnradd_logfile(logfilename => '/arch2/2_825_733092736dbf',options => dbms_logmnrnew);

-- 2使用本地的在线数据字典分析归档日志

exec sysdbms_logmnrstart_logmnr(options => sysdbms_logmnrdict_from_online_catalog);

-- 3查询分析出来的归档日志内容，例如统计最大修改量的Schema

select seg_owner,count() from v$logmnr_contents group by seg_owner;

-- 4增加别的日志文件

exec sysdbms_logmnradd_logfile(logfilename=>'/arch2/2_825_733092736dbf');

-- 5结束分析归档日志

exec sysdbms_logmnrend_logmnr;

下面是具体的过程：

SQL> exec sysdbms_logmnradd_logfile(logfilename => '/arch2/2_825_733092736dbf',options => dbms_logmnrnew);

PL/SQL procedure successfully completed

SQL> exec sysdbms_logmnrstart_logmnr(options => sysdbms_logmnrdict_from_online_catalog);

PL/SQL procedure successfully completed

SQL> select seg_owner,count() from v$logmnr_contents group by seg_owner;

SEG_OWNER COUNT()

-------------------------------- ----------

2237

SYS 688

TMS 60

SPHSY 70

SINOSYNEW 30

SINOSY 381

WAS 4551934

7 rows selected

SQL> execute dbms_logmnrend_logmnr ;

PL/SQL procedure successfully completed

结论：

从上面查询结果可以看出 *** 作量最大的用户是WAS用户，再具体看下v$logmnr_contents可以发现基本修改的内容是一致的。

与开发人员沟通后，最终确认是一个执行update过程存在问题，where条件未正确定位到记录，每执行一次都会导致大规模的修改数据。

以上就是关于如何查看数据库是否处于归档模式全部的内容，包括:如何查看数据库是否处于归档模式、配置归档日志，让数据库管理更加顺畅、如何解决Oracle数据库归档日志占满磁盘空间等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！