Khôi phục dữ liệu Oracle Database – một trong những hệ quản trị cơ sở dữ liệu quan trọng nhất trên thế giới. Trong bài viết này, chúng ta sẽ khám phá quá trình phục hồi dữ liệu, một quy trình quan trọng và phức tạp, nhằm đảm bảo tính toàn vẹn và khả năng khôi phục của hệ thống.
Bằng cách sử dụng các công cụ và phương pháp phục hồi phù hợp, chúng ta có thể hiệu quả giải quyết các tình huống mất dữ liệu khác nhau.
Sau khi hoàn thành bài học này, bạn sẽ có khả năng:
- Xác định nhu cầu phục hồi hiệu suất: Hiểu rõ các chỉ số và tình huống cần đến phục hồi dữ liệu.
- Miêu tả và sử dụng các tùy chọn có sẵn: Khám phá các tính năng và khả năng của các công cụ chính như Recovery Manager (RMAN) và Data Recovery Advisor, giúp bạn lựa chọn thông minh trong quá trình phục hồi.
- Thực hiện các thao tác phục hồi cho các thành phần sau:
- Control file: Học cách khôi phục và phục hồi control file, một thành phần quan trọng giữ metadata và cấu trúc của cơ sở dữ liệu.
- Redo log file: Hiểu rõ về việc phục hồi redo log file, chứa bản ghi về tất cả các thay đổi được thực hiện trong cơ sở dữ liệu và đóng vai trò quan trọng trong việc đảm bảo tính nhất quán và bền vững của dữ liệu.
- Data file: Nắm vững các kỹ thuật phục hồi data file, nơi lưu trữ dữ liệu thực tế của các đối tượng cơ sở dữ liệu, và khôi phục chúng về trạng thái nhất quán.
Dù bạn là quản trị cơ sở dữ liệu(DBA), Dev hay một người đam mê Oracle, hướng dẫn này sẽ giúp bạn phục hồi dữ liệu một cách hiệu quả trong cơ sở dữ liệu Oracle, đảm bảo tính tin cậy và tính sẵn sàng của thông tin quý giá. Hãy cùng bắt đầu hành trình này và khám phá bí mật về phục hồi dữ liệu trong Oracle.
Các trạng thái khi Open Oracle Database
Để 1 cơ sở dữ liệu Oracle bắt đầu hoạt động, nó cần các yếu tố sau:
- Tất cả các Control file phải tồn tại và được đồng bộ.
- Tất cả các Data file phải tồn tại và được đồng bộ.
- Ít nhất một thành viên của mỗi nhóm redo log phải có sẵn.
Khi một cơ sở dữ liệu di chuyển từ trạng thái Shutdown đến trạng thái hoạt động Open, nó thực hiện kiểm tra tính nhất quán nội bộ với các giai đoạn sau:
- NOMOUNT: Để đạt trạng thái NOMOUNT (còn được gọi là STARTED), Instance phải đọc Parameter File khởi tạo. Khi vào trạng thái NOMOUNT, thì sẽ không kiểm tra các file cơ sở dữ liệu.
- MOUNT: Khi Instance chuyển sang trạng thái MOUNT, nó kiểm tra xem tất cả các Control file được liệt kê trong Parameter File khởi tạo có tồn tại và được đồng bộ hóa hay không. Nếu thiếu hoặc hỏng ít nhất một Control file, Instance sẽ trả về một lỗi (ghi chú Control file thiếu) cho quản trị viên và vẫn ở trạng thái NOMOUNT.
- OPEN: Khi Instance chuyển từ trạng thái MOUNT sang trạng thái OPEN, nó thực hiện các bước sau:
- Kiểm tra xem tất cả các nhóm redo log được biết đến trong Control file có ít nhất một thành viên có mặt. Bất kỳ thành viên nào bị thiếu sẽ được ghi chú trong log cảnh báo.
- Xác minh rằng tất cả các Data file được biết đến trong Control file có mặt trừ khi chúng đã được chuyển sang trạng thái ngoại tuyến(offline). Các tệp ngoại tuyến sẽ không được kiểm tra cho đến khi quản trị viên cố gắng đưa chúng trực tuyến.
Quản trị viên có thể chuyển Data file sang trạng thái ngoại tuyến và mở Instance nếu Data file không thuộc các tablespace SYSTEM hoặc UNDO. Nếu có bất kỳ tệp nào bị thiếu, một lỗi ghi chú tệp thiếu đầu tiên sẽ được trả về cho quản trị viên và Instance vẫn ở trạng thái MOUNT. Khi Instance tìm thấy các tệp bị thiếu, chỉ tệp đầu tiên gây ra vấn đề sẽ xuất hiện trong thông báo lỗi.
Để tìm tất cả các tệp cần phục hồi, quản trị viên có thể kiểm tra View hiệu suất động v$recover_file để có danh sách đầy đủ các tệp cần chú ý.
SQL> startup ORACLE instance started. Total System Global Area 171966464 bytes Fixed Size 775608 bytes Variable Size 145762888 bytes Database Buffers 25165824 bytes Redo Buffers 262144 bytes Database mounted. ORA-01157: cannot identify/lock data file 4 - see DB WR trace file ORA-01110: data file 4: '/oracle/oradata/orcl/users 01.dbf' SQL> SELECT name, error 2 FROM v$datafile 3 JOIN v$recover_file 4 USING (file#); NAME ERROR ----------------------------------- ---------------- -- /oracle/oradata/orcl/users01.dbf FILE NOT FOUND /oracle/oradata/orcl/example01.dbf FILE NOT FOUND
Confirm rằng tất cả các Data file không ở trạng thái ngoại tuyến hoặc chỉ đọc đều được đồng bộ với Control file. Nếu cần thiết, phục hồi Instance sẽ được thực hiện tự động.
Tuy nhiên, nếu một tệp không đồng bộ đến mức không thể khôi phục bằng cách sử dụng nhóm redo log trực tuyến, thì quản trị viên phải thực hiện phục hồi phương tiện. Nếu có bất kỳ tệp nào cần phục hồi phương tiện, một thông báo lỗi ghi chú tệp đầu tiên cần phục hồi sẽ được trả về cho quản trị viên và Instance vẫn ở trạng thái MOUNT.
ORA-01113: file 4 needs media recovery ORA-01110: data file 4: '/oracle/oradata/orcl/users 01.dbf
Một lần nữa, View v$recover_file cung cấp một danh sách đầy đủ các tệp cần chú ý. Các tệp hiện có và yêu cầu phục hồi phương tiện sẽ được liệt kê, nhưng không có thông báo lỗi được hiển thị.
Khôi phục dữ liệu trong khi Database đang được Open
- Mất bất kỳ Control file nào.
- Một Data file thuộc các tablespace SYSTEM hoặc UNDO.
- Một nhóm redo log hoàn chỉnh (Miễn là ít nhất một thành viên của nhóm vẫn tồn tại, Instance vẫn được duy trì mở).
Sau khi một cơ sở dữ liệu được mở, sự cố của Instance có thể do sự cố phương tiện xảy ra, ví dụ như mất Control file, mất toàn bộ nhóm redo log, hoặc mất Data file thuộc các tablespace SYSTEM hoặc UNDO.
Ngay cả khi một nhóm redo log không hoạt động bị mất, cơ sở dữ liệu cuối cùng cũng sẽ gặp sự cố do chuyển đổi log. Trong nhiều trường hợp, Instance gặp sự cố không tắt hoàn toàn nhưng không thể tiếp tục thực hiện công việc.
Phục hồi từ các loại sự cố phương tiện này phải được thực hiện khi cơ sở dữ liệu tắt. Do đó, quản trị viên phải sử dụng lệnh SHUTDOWN ABORT trước khi bắt đầu công tác phục hồi.
Việc mất Data file thuộc các tablespace khác không gây ra sự cố Instance và cơ sở dữ liệu có thể được khôi phục trong khi vẫn mở, với công việc tiếp tục trong các tablespace khác. Các lỗi này có thể được phát hiện bằng cách kiểm tra Redo Log cảnh báo hoặc sử dụng Data Recovery Advisor.
Data Recovery Advisor tự động thu thập thông tin về sự cố dữ liệu khi gặp lỗi. Ngoài ra, nó còn có thể kiểm tra các sự cố một cách chủ động.
Trong chế độ này, nó có thể phát hiện và phân tích các sự cố dữ liệu trước khi quá trình cơ sở dữ liệu phát hiện lỗi và thông báo. (Lưu ý rằng việc sửa chữa luôn dưới sự kiểm soát của con người.) Sự cố dữ liệu có thể rất nghiêm trọng.
Ví dụ, nếu các Redo Log hiện tại bị mất, bạn sẽ không thể mở cơ sở dữ liệu của mình. Một số sự cố dữ liệu (như hỏng block trong các Data file) không phải là thảm họa vì chúng không làm cơ sở dữ liệu tắt hoặc ngăn bạn khởi động cơ sở dữ liệu Oracle. Data Recovery Advisor xử lý cả hai trường hợp:
khi bạn không thể khởi động cơ sở dữ liệu (do các tệp cơ sở dữ liệu yêu cầu bị mất, không đồng nhất hoặc hỏng) và khi phát hiện lỗi tệp trong quá trình chạy.
Cách ưu tiên để xử lý các sự cố dữ liệu nghiêm trọng như sau:
- Chuyển sang cơ sở dữ liệu standby nếu bạn đang ở trong cấu hình Data Guard. Điều này cho phép người dùng trở lại làm việc càng sớm càng tốt.
- Sửa chữa nguyên nhân chính gây ra sự cố dữ liệu.
Khi xảy ra sự cố, có một số cách để truy cập vào Data Recovery Advisor. Bạn cũng có thể sử dụng Data Recovery Advisor thông qua dòng lệnh RMAN:
rman target / rman> list failure all;
Trong Instance hiện tại, Data Recovery Advisor hỗ trợ cơ sở dữ liệu đơn. Các cơ sở dữ liệu Oracle Real Application Clusters không được hỗ trợ.
Data Recovery Advisor không thể sử dụng các block hoặc file được chuyển từ cơ sở dữ liệu standby để sửa chữa sự cố trên cơ sở dữ liệu chính.
Hơn nữa, bạn không thể sử dụng Data Recovery Advisor để chẩn đoán và sửa chữa sự cố trên cơ sở dữ liệu standby. Tuy nhiên, Data Recovery Advisor hỗ trợ việc chuyển đổi sang cơ sở dữ liệu standby như một tùy chọn sửa chữa (như đã đề cập trước đó).
Khôi phục dữ liệu Oracle Database khi mất 1 Control File
Các tùy chọn phục hồi từ việc mất Control file phụ thuộc vào cấu hình lưu trữ của Control file và xem liệu có ít nhất một Control file còn lại hay đã mất hết. Nếu sử dụng lưu trữ ASM và có ít nhất một bản sao Control file còn lại, bạn có thể thực hiện phục hồi theo hướng dẫn bằng cách sử dụng Enterprise Manager hoặc thực hiện phục hồi thủ công bằng RMAN như sau:
- Đặt cơ sở dữ liệu ở chế độ NOMOUNT.
- Kết nối với RMAN và thực hiện lệnh RESTORE CONTROLFILE để khôi phục Control file từ một Control file hiện có, ví dụ:
restore controlfile from '+DATA/orcl/controlfile/current.260.695209463'; --Sau khi Control file được khôi phục thành công, hãy mở cơ sở dữ liệu.
Nếu Control file của bạn được lưu trữ dưới dạng file hệ thống file thông thường và có ít nhất một bản sao Control file còn lại, khi cơ sở dữ liệu đang tắt, bạn chỉ cần sao chép một trong số các Control file còn lại vào vị trí của file đã bị mất.
Nếu sự cố thiết bị là do mất ổ đĩa hoặc bộ điều khiển, hãy sao chép một trong số các Control file còn lại vào một vị trí khác và cập nhật Parameter File của Instance để trỏ đến vị trí mới.
Hoặc, bạn có thể xóa tham chiếu đến Control file bị mất trong Parameter File khởi tạo. Hãy nhớ rằng Oracle khuyến nghị luôn có ít nhất hai Control file trong suốt thời gian.
Khôi phục dữ liệu Oracle Database khi mất 1 Redo Log File
Phục hồi từ việc mất một thành viên của nhóm redo log đơn lẻ không ảnh hưởng đến Instance đang chạy. Chúng ta có thể thực hiện phục hồi nó bằng các lệnh SQL:
1. Xác định xem có Redo Log bị thiếu bằng cách kiểm tra nhật ký cảnh báo.
/* Để kiểm tra nhật ký cảnh báo trong Oracle, bạn có thể làm theo các bước sau: 1) Mở phiên SQL*Plus hoặc SQL Developer. 2) Đăng nhập vào cơ sở dữ liệu Oracle bằng tài khoản có đặc quyền SYSDBA hoặc SYSOPER. 3) Chạy câu lệnh sau để xem nội dung nhật ký cảnh báo: */ SELECT * FROM alert_log;
Lệnh này truy vấn và hiển thị nội dung của nhật ký cảnh báo, bao gồm các thông báo về lỗi, cảnh báo và thông tin quan trọng khác về cơ sở dữ liệu.
Bạn cũng có thể sử dụng các công cụ quản lý Oracle như Oracle Enterprise Manager (EM) hoặc Oracle Database Control để truy cập và kiểm tra nhật ký cảnh báo một cách dễ dàng và trực quan hơn.
Lưu ý rằng thông tin trong nhật ký cảnh báo sẽ cung cấp thông tin về các sự kiện, lỗi và cảnh báo quan trọng xảy ra trong cơ sở dữ liệu Oracle. Đảm bảo kiểm tra nhật ký cảnh báo thường xuyên để phát hiện và giải quyết các vấn đề liên quan đến cơ sở dữ liệu của bạn.
2. Khôi phục tệp bị thiếu bằng cách trước tiên xóa thành viên redo log bị mất:
ALTER DATABASE DROP LOGFILE MEMBER '<filename>' --Sau đó, thêm một thành viên mới để thay thế thành viên redo log bị mất: ALTER DATABASE ADD LOGFILE MEMBER '<filename>' TO GROUP <integer>
Lưu ý: Nếu bạn đang sử dụng Oracle Managed Files (OMF) cho các tệp redo log của mình và sử dụng cú pháp trên để thêm một thành viên redo log mới vào một nhóm hiện có, tệp thành viên redo log mới này sẽ không phải là một tệp OMF. Nếu bạn muốn đảm bảo rằng thành viên redo log mới là một tệp OMF, thì tùy chọn phục hồi dễ dàng nhất là tạo một nhóm redo log mới và sau đó xóa nhóm redo log có thành viên redo log bị thiếu.
3. Nếu sự cố thiết bị là do mất ổ đĩa hoặc bộ điều khiển, hãy đổi tên file bị thiếu.
4. Nếu nhóm đã được lưu trữ hoặc nếu bạn đang ở chế độ NOARCHIVELOG, bạn có thể giải quyết vấn đề bằng cách xóa nhóm nhật ký để tạo lại tệp hoặc các tệp bị thiếu. Bạn có thể xóa nhóm bị ảnh hưởng thủ công bằng lệnh sau:
ALTER DATABASE CLEAR LOGFILE GROUP <integer>
Lưu ý: Enterprise Manager không cho phép bạn xóa một nhóm nhật ký chưa được lưu trữ. Làm như vậy sẽ làm đứt mạch thông tin redo. Nếu bạn phải xóa một nhóm nhật ký chưa được lưu trữ, bạn nên ngay lập tức backup đầy đủ toàn bộ cơ sở dữ liệu. Nếu không làm như vậy, có thể dẫn đến mất dữ liệu nếu xảy ra sự cố khác. Để xóa một nhóm nhật ký chưa được lưu trữ, sử dụng lệnh sau:
ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP <integer>
Phục hồi Oracle Database khi mất 1 Data File trong chế độ NOARCHIVELOG
Để khôi phục dữ liệu khi mất một Data file trong cơ sở dữ liệu ở chế độ NOARCHIVELOG bằng cách sử dụng RMAN, làm theo các bước sau:
1. Đảm bảo rằng Instance cơ sở dữ liệu đã được tắt.
2. Mở Instance RMAN bằng cách chạy lệnh sau trên command line:
rman target /
3. Xác định Data file bị mất bằng cách kiểm tra thông tin trong log cảnh báo (alert log).
4. Thực hiện khôi phục tệp bị mất bằng cách sử dụng lệnh sau:
RESTORE DATAFILE '<đường_dẫn_đến_tệp_bị_mất>';
Lưu ý: Đường dẫn đến tệp bị mất phải được cung cấp chính xác.
5. Sau khi Data file bị mất đã được khôi phục thành công, mở lại cơ sở dữ liệu bằng cách chạy lệnh sau:
ALTER DATABASE OPEN;
6. Nhập lại tất cả các thay đổi đã được thực hiện kể từ lần sao lưu cuối cùng.
Lưu ý: Khi cơ sở dữ liệu ở chế độ NOARCHIVELOG, phục hồi chỉ có thể thực hiện đến thời điểm sao lưu cuối cùng. Vì vậy, việc mất Data file có thể dẫn đến mất dữ liệu không thể khôi phục được. Do đó, rất quan trọng để thường xuyên sao lưu dữ liệu và chuyển sang chế độ ARCHIVELOG để có khả năng phục hồi đầy đủ khi xảy ra sự cố.
Phục hồi Oracle Database khi mất 1 Data File trong chế độ ARCHIVELOG
Để khôi phục và phục hồi Data file bị mất trong chế độ ARCHIVELOG bằng cách sử dụng RMAN, làm theo các bước sau:
1. Mở phiên RMAN bằng cách chạy lệnh sau trên dòng lệnh:
rman target /
2. Xác định Data file bị mất bằng cách chạy lệnh sau trong phiên RMAN:
RESTORE DATAFILE '<đường_dẫn_tệp_bị_mất>'; --Lưu ý: Thay thế `<đường_dẫn_tệp_bị_mất>` bằng đường dẫn Data file thực tế bị mất.
3. Khôi phục Data file bị mất bằng cách chạy lệnh sau trong phiên RMAN:
RECOVER DATAFILE '<đường_dẫn_tệp_bị_mất>'; --Lưu ý: Thay thế `<đường_dẫn_tệp_bị_mất>` bằng đường dẫn Data file thực tế bị mất.
4. Sau khi khôi phục và phục hồi Data file bị mất thành công, thoát khỏi phiên RMAN bằng cách chạy lệnh sau:
EXIT;
Quá trình khôi phục và phục hồi Data file bị mất sẽ được RMAN thực hiện dựa trên các bản sao lưu và các tập tin nhật ký bắt buộc. Nếu tất cả các bước được thực hiện chính xác, bạn sẽ khôi phục được Data file bị mất và cơ sở dữ liệu sẽ sẵn sàng để người dùng tiếp tục làm việc.