Recover khi mất REDO log files

Oracle Redo Log File đóng vai trò quan trọng trong việc đảm bảo tính toàn vẹn và khả năng phục hồi dữ liệu trong cơ sở dữ liệu Oracle. Nó là một tập tin nhật ký liên tục được ghi để theo dõi tất cả các thay đổi được thực hiện trong cơ sở dữ liệu.

Chức năng:

• Ghi lại mọi thay đổi dữ liệu trong cơ sở dữ liệu, bao gồm chèn, cập nhật và xóa.
• Duy trì thông tin này theo thứ tự thời gian, tạo thành lịch sử hoạt động của cơ sở dữ liệu.

Mục đích:

• Phục hồi: Trong trường hợp hệ thống gặp sự cố hoặc sập, redo log cho phép cơ sở dữ liệu thực hiện lại các thay đổi được ghi lại trong quá trình phục hồi, đảm bảo tính nhất quán của dữ liệu.

Cấu trúc:

• Bao gồm nhiều tệp nhật ký redo được nhóm lại với nhau để dự phòng.
• Mỗi tệp được chia thành các bản ghi redo, chứa chi tiết về các sửa đổi dữ liệu cụ thể.

Quản lý:

• Quản lý tự động: Oracle tự động xử lý việc tạo, chuyển đổi và lưu trữ các tệp nhật ký redo.
• Tùy chọn cấu hình: Người dùng có thể tùy chỉnh các khía cạnh khác nhau của quản lý nhật ký redo, chẳng hạn như kích thước và chiến lược lưu trữ.

Tầm quan trọng:

• Cực kỳ quan trọng đối với tính toàn vẹn của dữ liệu: Redo log là yếu tố cần thiết để đảm bảo tính nhất quán của dữ liệu và ngăn mất dữ liệu trong trường hợp xảy ra sự cố bất ngờ.
• Cân nhắc về hiệu suất: Mặc dù đóng vai trò quan trọng, nhưng hoạt động của redo log có thể ảnh hưởng đến hiệu suất của cơ sở dữ liệu. Việc cân bằng giữa bảo vệ dữ liệu và hiệu suất là rất quan trọng.

Redo log đang sử dụng  hay còn gọi là redo log online, sau khi thực hiện switchlog thì sẽ được lưu trữ ra file còn gọi là Archivelog

Các trạng thái của online redo log như sau:

Log status:

UNUSED – Online redo log là trạng thái chưa được sử dụng, ở database mới hoặc hình thành sau khi thực hện lênh resetlog.
CURRENT – Current redo log. là online redo log đang được sử dụng hiện tại.
ACTIVE – Sau khi curent thì sẽ chuyển sang active. Dùng để cho các trường hợp crash recovery.
CLEARING – hình thành sau khi thực hiện ALTER DATABASE CLEAR LOGFILE sau đó nó chuyển sang trạng thái unused.
INACTIVE – là trạng thái không hoạt động, dùng cho media recovery.

Theo khuyến cáo của Oracle thì mỗi database nên cần ít nhất tối thiểu như sau: 3 groups redo log, mỗi group ít nhất 2 members.

Lưu ý: Trước khi thực hiện theo hướng dẫn này, bạn phải thực hiện backup database, nếu không có backup =>> sẽ không recovery được:

rman target /

--Xóa các bản ghi archivelog không tồn tại khỏi catalog của RMAN nếu có:
-- có thể là các archivelog được xoá thủ công hoặc di chuyển đi
CROSSCHECK ARCHIVELOG ALL;
DELETE EXPIRED ARCHIVELOG ALL;
backup database plus archivelog;

Recover khi mất redo log phụ thuộc vào trạng thái của file redo log đang bị mất, chúng ta sẽ làm chi tiết từng trường hợp có thể xảy ra dưới đây:

CASE 1: Mất 1 member của 1 group.

Trong trường hợp như vậy, nếu một member redo log của một nhóm bị mất, cơ sở dữ liệu sẽ tiếp tục chạy vì nó có thể ghi vào member khác của nhóm này nhưng sẽ gây ra lỗi trong Alert log và TRẠNG THÁI của thành viên bị mất sẽ chuyển thành INVALID. Để phục hồi từ trường hợp này, sau đây là các bước cần thiết.

STEP 1: kiểm tra Status redo Log

select member, a.group#, a.status, b.status from v$log a, v$logfile b where  a.group# = b.group#  order by a.group#, member;

Trường hợp này về cơ bản là không ảnh hưởng gì đến redo log, chúng ta chỉ drop member đó đi và create lại là xong, nhưng nếu member đó là Curent redo log => chúng ta không thể drop được vì oracle không cho drop member khi group đang là CURRENT (ORA-01609) => giải pháp là chúng ta phải chuyển trạng thái của Group từ CURRENT thành ACTIVE hoặc là INACTIVE

STEP 2: Thực hiện switch logfile.

Alter system switch logfile;

STEP 3: Thực hiện drop member

Alter database drop logfile member ‘<LOG File name where b.status in above query was INVALID>’;

STEP 4: Tạo lại member logfile

Alter database add logfile member ‘<Same LOG FILE NAME that was dropped>’ to group <a.group# from above query>;

CASE 2: Mất hết các member trong group

Khi tất cả các member của nhóm REDO logfile bị mất, cơ sở dữ liệu sẽ bị sập, trên thực tế, SMON sẽ tự chết gây ra tình trạng Shutdown database vì không có chỗ để ghi REDO logfile, điều này có nghĩa là không thể khôi phục giao dịch, do đó Oracle sẽ tự tắt để đảm bảo không còn giao dịch nào được thực hiện khi nó không thể ghi logs.

STEP 1: Thực hiện startup database bình thường sẽ không được và báo lỗi SMON và check redo log

STARTUP;

STEP 2: thực hiện startup database ở chế độ MOUNT

STARTUP MOUNT;

STEP 3: kiểm tra status

select member, a.group#, a.status, b.status, a.archived  from v$log a, v$logfile b where  a.group# = b.group# order by a.group#, member;

Tuỳ thuộc vào group bị hỏng chúng ta có các phương án khác nhau tương ứng với mỗi trường hợp này

A. Nếu group hỏng/mất là INACTIVE

– nếu đã có ARCHIVED logfile thực hiện lệnh bên dưới và sau đó OPEN database:

alter database clear logfile group <a.group# of the lost group from the above query>

– nếu chưa có ARCHIVED logfile thực hiện lệnh bên dưới và sau đó OPEN database:

alter database clear UNARCHIVED logfile group <a.group# of the lost group from the above query>

B. Nếu group hỏng/mất là STATUS = ACTIVE

Trong trường hợp này chúng ta sẽ cố gắng chuyển group này về trạng thái INACTIVE, sử dụng ALTER SYSTEM CHECKPOINT, nếu thành công => chúng ta thực hiện theo bước A) ở bên trên, nếu không thành công thì phải làm tuần tự như sau:

STARTUP MOUNT

select group#, status, archived, thread#, sequence#, first_change# from v$log; (SCN cuối cùng {first_change#} STATUS = CURRENT)

rman target /

restore database until scn <SCN {first_change#}from v$log >;

recover database until scn <SCN {first_change#}from v$log >;

alter database open resetlogs;

C. Nếu group hỏng/mất là STATUS = CURRENT => thực hiện tương tự như trường hợp B) bên trên

Tổng kết lại:

Việc mất mát hỏng hóc REDO logfile là trường hợp vô cùng tệ hại và nguy hiểm cho Database và đôi khi làm DBA toát mồ hôi để xử lý khôi phục trong các trường hợp này !!! Cho nên chúng ta phải hết sức thận trọng trong việc quản lý DB…

Chúc các bạn thành công !