Linux + ASM+OCFS环境下增加ORACLE RAC联机重做日志文件

Linux+ASM+OCFS环境下增加ORACLE RAC联机重做日志文件

本文PDF版下载 http://xunzhaoxz.itpub.net/resource/40016/29745

作者：xunzhao【转载时请以超链接形式标明文章出处和作者信息】

链接：http://xunzhaoxz.itpub.net/post/40016/487726

关键字：Oracle RAC ASM OCFS Create Redo Log Groups

环境说明：

操作系统版本：Linux AU4.5

内核版本：2.6.9.55

Oracle clusterware 版本：10.2.0.4

Oracle database 版本：10.2.0.4

存储介质：ASM+OCFS

节点数：2个节点

1) 实验思路：

[1] 查看当前联机重做日志文件信息

[2] 实验前进行必要的文件备份

[3] 增加两组联机重做日志文件，每个文件大小为100MB

[4] 查看oracle运行状态，执行手工切换归档日志，使用新的联机日志文件

[5] 再次增加一组日志文件，每个实例（线程）各一个，这样每个实例一共各有5个日志文件

[6] 删除原来的两组500MB的日志文件

[7] 增加两组100MB的日志文件

[@more@]

2) 首先查看当前联机日志文件状态：

从数据库的逻辑层面查看：

[oracle@gisdb1 ~]$ export ORACLE_SID=gisdb1

[oracle@gisdb1 ~]$ sqlplus /nolog

SQL> conn sys as sysdba;

SQL> set linesize 120;

SQL> select * from v$log;

从数据库存储的物理层面查看：

3) 实验前进行必要的文件备份：

参数文件的备份：

SQL> create pfile='/oracle/pfile_0907081758_before_add_redolog.ora' from spfile;

控制文件的备份：

SQL> alter database backup controlfile to /oracle/controlfile_0907081759_before_add_redolog.ora';

4) 增加联机日志文件（存储在ASM磁盘上）：

SQL> alter database add logfile thread 1 group 5 ('+DATA1/GISDB/ONLINELOG/group5') size 100M;

SQL> alter database add logfile thread 2 group 6 ('+DATA1/GISDB/ONLINELOG/group6') size 100M;

SQL> alter database add logfile thread 1 group 7 ('+DATA1/GISDB/ONLINELOG/group7') size 100M;

SQL> alter database add logfile thread 2 group 8 ('+DATA1/GISDB/ONLINELOG/group8') size 100M;

增加联机日志完成后，执行SQL> select * from v$logfile;查看当前物理文件信息

SQL> set linesize 120;

SQL> select * from v$log;

在节点二上查看当前联机日志文件信息：

5) 在节点一上再次增加两个日志文件：

SQL> alter database add logfile thread 1 group 9 ('+DATA1/GISDB/ONLINELOG/group9') size 100M;

SQL> alter database add logfile thread 2 group 10 ('+DATA1/GISDB/ONLINELOG/group10') size 100M;

SQL> select * from v$log;

通过asmcmd查看存储在ASM磁盘上的物理文件信息：

[oracle@gisdb1 ~]$ export ORACLE_SID=+ASM1

[oracle@gisdb1 ~]$ asmcmd

ASMCMD> cd +DATA1/gisdb/onlinelog

ASMCMD> ls -l

6) 删除旧的500M的联机日志文件：

注意：删除日志文件注意事项：

[1] 该文件已归档

[2] 当前未被使用，即状态为INACTIVE

[3] 必须保证删除该日志文件后，每个实例（线程THREAD）至少有两个日志文件

Oracle官方原文说明如下：

http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/onlineredo005.htm

Dropping Redo Log Groups and Members

In some cases, you may want to drop an entire group of redo log members. For example, you want to reduce the number of groups in an instance redo log. In a different case, you may want to drop one or more specific redo log members. For example, if a disk failure occurs, you may need to drop all the redo log files on the failed disk so that the database does not try to write to the inaccessible files. In other situations, particular redo log files become unnecessary. For example, a file might be stored in an inappropriate location.

Dropping Log Groups

To drop a redo log group, you must have the ALTER DATABASE system privilege. Before dropping a redo log group, consider the following restrictions and precautions:

· An instance requires at least two groups of redo log files, regardless of the number of members in the groups. (A group comprises one or more members.)

· You can drop a redo log group only if it is inactive. If you need to drop the current group, first force a log switch to occur.

· Make sure a redo log group is archived (if archiving is enabled) before dropping it. To see whether this has happened, use the V$LOG view.

· SELECT GROUP#, ARCHIVED, STATUS FROM V$LOG;

·

· GROUP# ARC STATUS

· --------- --- ----------------

· 1 YES ACTIVE

· 2 NO CURRENT

· 3 YES INACTIVE

· 4 YES INACTIVE

·

Drop a redo log group with the SQL statement ALTER DATABASE with the DROP LOGFILE clause.

The following statement drops redo log group number 3:

ALTER DATABASE DROP LOGFILE GROUP 3;

When a redo log group is dropped from the database, and you are not using the Oracle-managed files feature, the operating system files are not deleted from disk. Rather, the control files of the associated database are updated to drop the members of the group from the database structure. After dropping a redo log group, make sure that the drop completed successfully, and then use the appropriate operating system command to delete the dropped redo log files.

When using Oracle-managed files, the cleanup of operating systems files is done automatically for you.

下面进行删除操作：删除上图中的GROUP1日志文件，然后查看结果：

SQL> alter database drop logfile group 1;

数据库已更改。

SQL> select * from v$log;

删除日志的注意事项和操作步骤如上，下面依次删除GROUP3，GROUP2，GROUP4：

SQL> alter database drop logfile group 3;

SQL> select * from v$log;

SQL> alter database drop logfile group 2;

SQL> select * from v$log;

SQL> alter database drop logfile group 4;

SQL> select * from v$log;

7) 删除完成后，当前一共剩下3组日志文件，每个实例（线程THREAD）各3个日志文件，下面进行添加操作：

SQL> alter database add logfile thread 1 group 1 ('+DATA1/GISDB/ONLINELOG/group1') size 100M;

SQL> alter database add logfile thread 2 group 2 ('+DATA1/GISDB/ONLINELOG/group2') size 100M;

SQL> alter database add logfile thread 1 group 3 ('+DATA1/GISDB/ONLINELOG/group3') size 100M;

SQL> alter database add logfile thread 2 group 4 ('+DATA1/GISDB/ONLINELOG/group4') size 100M;

SQL> select * from v$log;

通过asmcmd查看存储在ASM磁盘上的物理文件信息，此时应该有5组共10个日志文件：

ASM磁盘组上确实存在10个联机重做日志文件。

为保险起见，依次在两个节点上执行以下操作，手工切换当前redo log，使新增的日志文件生效：

SQL> alter system switch logfile;

SQL> alter system switch logfile;

SQL> select * from v$log;

8) 所有操作执行完毕，检查系统当前状态并查看日志：

[1] 查看RAC当前状态

[oracle@gisdb2 ~]$ crs_stat -t

[2] 分别在两个节点上查看ALTER日志，观察是否存在异常记录：

节点一：

[oracle@gisdb1 ~]$ vi /oracle/admin/gisdb/bdump/alert_gisdb1.log

节点二：

[oracle@gisdb2~]$ vi /oracle/admin/gisdb/bdump/alert_gisdb2.log

查看两个节点上的alter日志文件，没有任何警报记录，至此本次实验结束。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22085031/viewspace-1024269/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22085031/viewspace-1024269/