oracle日志管理

oracle 日志管理

一： Active (Current) and Inactive Redo Log File(目前活動和非活動的日志檔案）

active（current）：Redo log files that are required for instance recovery are called active redo log files

執行個體恢複需要該日志就叫活動的，或者叫目前的重做日志檔案

inactive：Redo log files that are no longer required for instance recovery are called inactive redo log files

執行個體恢複時不需要的日志就叫inactive日志

二：Log Sequence Numbers

當發生日志切換并且lgwr背景程序開始寫該日志檔案，oracle資料庫便給該日志檔案配置設定一個新的日志序列号。

當資料庫歸檔了該日志檔案，則歸檔日志将會保有該日志序列号。

線上日志，或者歸檔日志被日志序列号唯一辨別，當執行個體crash或者需要媒體恢複時，資料庫使用日志序列号以升序方式應用重做日志檔案和必須的歸檔日志檔案。

三：Creating Redo Log Groups

采用預設組号

ALTER DATABASE

ADD LOGFILE ('/oracle/CRM2/CRM/redo4a.log', '/oracle/CRM2/CRM/redo4b.log') SIZE 200M;

采用指定組号 (注意為了好管理不要跳躍性的指定你的組号）

ALTER DATABASE 

ADD LOGFILE GROUP 10 ('/oracle/CRM2/CRM/redo10a.log', '/oracle/CRM2/CRM/redo10b.log')

SIZE 200M;

四：Creating Redo Log Members

添加一個日志成員到日志組号2 注意事項：

必須指定日志檔案名。

檔案大小不需要指定，檔案大小取決于已存在日志組指定的大小。

新日志成員的狀态會從新添加時候的invalid到第一次使用時變為active

語句：

ALTER DATABASE ADD LOGFILE MEMBER '/oracle/CRM2/CRM/redo2b.log' TO GROUP 2;

五：Relocating and Renaming Redo Log Members（遷移和重命名日志成員）

重命名日志成員步驟：

步驟1： Shutdown the database.

shutdown immediate

步驟2： Copy the redo log files to the new location.

The following example uses operating system commands (UNIX) to move the 

redo log members to a new location:

mv /source/log1a.rdo /ddestination/log1c.rdo

mv /source/log2a.rdo /destination/log2c.rdo

步驟3： Startup the database。

startup mount

步驟4： Rename the redo log members.

alter database

rename file  '/source/log1a.rdo', '/source/log2a.rdo' 

           to '/destination/log1c.rdo', '/destination/log2c.rdo';

步驟5：Open the database for normal operation.

The redo log alterations take effect when the database is opened.

alter database open

六：Dropping Redo Log Groups and Members

drop log group（restrictions）：删除重做日志組的限制條件

限制一：instance 要求至少兩個組，而不管組内成員個數

限制二：你可以丢棄一個狀态為inactive狀态的重做日志組，如果要丢棄目前的日志組，必須手動切換日志組

限制三：如果是歸檔模式，确定丢棄重做日志組之前，成員已經被歸檔，通過視圖v$log 進行檢查

select group#,archived,status from v$log;

    GROUP# ARC STATUS

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

         1 YES INACTIVE

         2 NO  CURRENT

         3 YES INACTIVE

         4 YES UNUSED

        10 YES UNUSED

語句：ALTER DATABASE DROP LOGFILE GROUP xx; 注意，該指令實際上不删除日志檔案，需要用作業系統指令删除。

Dropping Redo Log Members

限制一：drop的日志成員不能是目前組或者活動組的成員

限制二：drop之前確定日志成員已經歸檔，如果資料庫是歸檔模式的話

限制三：drop的成員屬于活動日志組，則必須 force a log switch

語句：ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';

七：Forcing Log Switches

語句：alter system switch logfile;

八： Clearing a Redo Log File

當資料庫一直open時，可能會出現日志損壞，最終挂起資料庫，alter database clear logfile 語句能夠用于重新初始化這個日志檔案。

ALTER DATABASE CLEAR LOGFILE GROUP 3;

如果該日志檔案沒有歸檔，則

ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;

九：oracle是如何切換日志的？

目前日志狀态如下（注意紅色部分，目前日志序列号最大是42，而日志組6中序列号最小為37）

SQL> select group#,sequence#,archived,status from v$log;

    GROUP#  SEQUENCE# ARC STATUS

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

         1         38 YES INACTIVE

         2         40 YES INACTIVE

         3         41 YES INACTIVE

         4         42 NO  CURRENT

         5         39 YES INACTIVE

         6         37 YES INACTIVE

切換日志組：

SQL> alter system switch logfile;

System altered.

再查詢日志組狀态：

         4         42 YES ACTIVE

         6         43 NO  CURRENT

總結：oracle總是找日志組中sequence#字段值為最小的日志組，做為下一個目前日志組。

十：重做日志恢複（見如下例1、例2、例3）

例1：資料庫處于open狀态，意外丢失inactive日志組所有成員

運作如下指令，不過該指令執行後，日志檔案狀态處于unuse狀态，需要重新開機資料庫 日志組才能真正生效。

或者重建日志檔案

SQL> alter database drop logfile group 3;

Database altered.

SQL> alter database add logfile group 3 '/oracle/CRM2/CRM/redo03.log' size 200m  reuse;

SQL> select group#,archived,status from v$log;

         3 YES UNUSED

例2：如果資料庫關閉，再open時出現日志組所有成員丢失的情況有如下兩種情景：

情景一：非活動日志組所有成員全部損毀

關閉前日志狀态如下

         2 YES INACTIVE

         3 NO  CURRENT

當資料庫關閉後，打開資料庫提示

SQL> startup

ORACLE instance started.

Total System Global Area  322961408 bytes

Fixed Size                  2020480 bytes

Variable Size              92277632 bytes

Database Buffers          222298112 bytes

Redo Buffers                6365184 bytes

Database mounted.

ORA-00313: open failed for members of log group 1 of thread 1

ORA-00312: online log 1 thread 1: '/oracle/CRM2/CRM/redo01.log'

目前資料庫狀态

SQL> select open_mode from v$database;

OPEN_MODE

----------

MOUNTED

目前日志狀态如下所示：

查詢redo01.log所在的日志組如下所示：

SQL> select group#,member from v$logfile;

    GROUP# MEMBER

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

         3 /oracle/CRM2/CRM/redo03.log

         2 /oracle/CRM2/CRM/redo02.log

         1 /oracle/CRM2/CRM/redo01.log

         2 /oracle/CRM2/CRM/redo2b.log

運作alter database clear logfile group 1 重新初始化建立日志組1如下所示：

SQL> alter database clear logfile group 1;

重新打開資料庫如下：

SQL> alter database open;

READ WRITE

情景二：資料庫open時目前聯機日志檔案丢失

查詢目前資料庫日志狀态發現目前日志組1所有成員丢失如下所示：

         1 NO  CURRENT

         1 /oracle/CRM2/CRM/redo01.log

此時資料庫啟動狀态如下：   

此時若執行 clear unarchived logfile會報如下錯誤：

SQL> alter database clear unarchived logfile group 1;

alter database clear unarchived logfile group 1

*

ERROR at line 1:

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

由于關閉資料庫之前資料檔案處于一緻性狀态是以執行基于取消的不完全恢複。

SQL> recover database until cancel;

Media recovery complete.

用resetlogs打開資料庫時自動建立丢失的日志檔案

SQL> alter database open resetlogs;

例3：資料庫處于open狀态意外丢失目前聯機日志

目前資料庫日志狀态如下：

删除目前日志如下

[root@oracle CRM]# rm -rf redo01.log

切換目前日志組，觸發報錯，錯誤資訊位于alert檔案中如下：

ORA-16038: log 1 sequence# 20 cannot be archived

Wed Oct 17 01:50:35 2012

SQL> alter database clear unarchived logfile group 1;   （注意這裡，如果是非目前日志組丢失則删除日志組後直接重建即可，不需要運作此指令處理）

SQL> select group#,archived,status from v$Log;

         1 YES UNUSED

此時需要注意：

1  如果直接drop目前日志組直接重建會報如下錯誤

SQL> alter database drop logfile group 1;

alter database drop logfile group 1

ORA-00350: log 1 of instance CRM (thread 1) needs to be archived

2  clear unarchived logfile group 1 後，日志組1資料庫還不能使用，需要重新啟動資料庫或者重建日志組1

重建步驟如下：

SQL> alter database  add logfile group 1 '/oracle/CRM2/CRM/redo01.log' size 200m reuse;

本文轉自 zhangxuwl 51CTO部落格，原文連結：http://blog.51cto.com/jiujian/1031329，如需轉載請自行聯系原作者