Trong bài học trước thì chúng ta đã  cùng tìm hiểu và cơ chế bảo mật, kiểm soát quyền hạn người dùng bằng Audit trong Oracle database. Trong bài học này, chúng ta sẽ có 1 serial nói về quá trình sao lưu và phục hồi dữ liệu trong Oracle Database. Ở phần này, sẽ tập trung vào các khái niệm quan trọng trong Oracle Database mà bạn cần phải nắm chắc nó.

Sau khi hoàn thành bài học này, bạn sẽ có khả năng:

• Nhận biết các loại lỗi có thể xảy ra trong cơ sở dữ liệu Oracle.
• Mô tả quá trình phục hồi phiên bản (instance recovery).
• Mô tả quá trình phục hồi hoàn chỉnh và không hoàn chỉnh (complete và incomplete recovery).

Trách nhiệm của người DBA trong việc quản trị sao lưu và phục hồi dữ liệu trong Oracle Database

Vai trò của người quản trị cơ sở dữ liệu (DBA) thường là đảm bảo cơ sở dữ liệu luôn sẵn sàng và hoạt động khi người dùng cần. Để đạt được mục tiêu đó, DBA làm việc cùng với quản trị hệ thống để:

• Dự đoán và tránh các nguyên nhân thường gây ra sự cố.
• Nâng cao thời gian trung bình giữa các sự cố để tăng tính khả dụng của cơ sở dữ liệu.
• Đảm bảo phần cứng hoạt động đáng tin cậy nhất có thể, bảo vệ các thành phần quan trọng bằng cách lập bản sao và bảo trì hệ điều hành đúng thời điểm. Oracle Database cung cấp các tùy chọn cấu hình tiên tiến như Real Application Clusters và Oracle Data Guard để tăng tính ổn định.
• Giảm thời gian để khôi phục sau sự cố bằng cách thực hành các quy trình phục hồi trước và cấu hình sao lưu sẵn sàng khi cần thiết.
• Giảm thiểu mất mát dữ liệu. DBA tuân thủ các quy tắc tốt nhất để cấu hình cơ sở dữ liệu sao cho không bao giờ mất đi bất kỳ transaction nào đã được xác nhận. Điều này có thể được đảm bảo thông qua việc sử dụng file log, công nghệ Flashback, cũng như sử dụng cơ sở dữ liệu dự phòng và Oracle Data Guard.

Sao lưu và phục hồi: Các loại Failure trong Oracle Database

• Lỗi câu lệnh: Một thao tác cơ sở dữ liệu đơn lẻ (select, insert, update hoặc delete) thất bại.
• Lỗi quá trình người dùng: Một phiên làm việc cơ sở dữ liệu đơn lẻ bị lỗi.
• Lỗi mạng: Mất kết nối tới cơ sở dữ liệu.
• Lỗi người dùng: Người dùng hoàn thành một thao tác mà thực tế là không chính xác (xóa bảng hoặc nhập dữ liệu sai).
• Lỗi phiên bản: Phiên bản cơ sở dữ liệu đột ngột tắt.
• Lỗi phương tiện: Mất mát một hoặc nhiều tập tin cần thiết cho hoạt động cơ sở dữ liệu (tức là các tập tin đã bị xóa hoặc ổ đĩa gặp sự cố).

Statement Failure

Khi một thao tác cơ sở dữ liệu đơn lẻ thất bại, có thể cần sự can thiệp của DBA để sửa lỗi liên quan đến quyền hạn của người dùng hoặc phân bổ không gian cơ sở dữ liệu. DBA cũng có thể cần hỗ trợ trong việc khắc phục sự cố, ngay cả đối với các vấn đề không trực tiếp thuộc khu vực công việc của họ.

Điều này có thể khác nhau rất nhiều giữa các tổ chức khác nhau. Ví dụ, trong các tổ chức sử dụng ứng dụng sẵn có (tức là tổ chức không có nhà phát triển phần mềm riêng), DBA là điểm liên lạc duy nhất và phải kiểm tra lỗi logic trong các ứng dụng.

Để hiểu lỗi logic trong các ứng dụng, bạn nên làm việc cùng các nhà phát triển để hiểu phạm vi của vấn đề. Các công cụ của Oracle Database có thể hỗ trợ bằng cách giúp xem xét lịch sử ghi log hoặc các trans trước đó.

Lưu ý: Trong nhiều trường hợp, lỗi câu lệnh được thiết kế và mong muốn. Ví dụ, các chính sách bảo mật và quy tắc hạn mức thường được quyết định trước. Nếu người dùng gặp lỗi khi cố gắng vượt quá giới hạn của mình, có thể mong muốn để thao tác thất bại và không cần giải quyết.

User process failure

Các quy trình người dùng(User process) mà ngắt kết nối không bình thường khỏi instance có thể có các công việc chưa commit, nó cần phải được quay trở lại. Quá trình giám sát quy trình (PMON) là quá trình nền liên tục kiểm tra các server process để đảm bảo rằng session của chúng vẫn còn kết nối.

Nếu PMON phát hiện một server process mà user không còn kết nối nữa, PMON sẽ khôi phục từ bất kỳ trans nào đang diễn ra; nó cũng sẽ quay trở lại các thay đổi như lúc chưa commit và giải phóng bất kỳ lock nào đang được giữ bởi session làm việc bị lỗi.

Không cần sự can thiệp của DBA để khôi phục từ lỗi user process, nhưng người quản trị hệ thống phải theo dõi xu hướng. Một hoặc hai người dùng ngắt kết nối không bình thường không đáng lo ngại.

Một số lỗi user process nhỏ có thể xảy ra từ thời gian này đến thời gian khác. Tuy nhiên, sự cố liên tục và hệ thống cho thấy các vấn đề khác.

Một tỷ lệ lớn sự ngắt kết nối không bình thường có thể cho thấy cần thiết đào tạo lại người dùng (bao gồm cách chỉ dạy cho người dùng đăng xuất thay vì chỉ chấm dứt chương trình của họ).Ngoài ra, điều này cũng có thể là dấu hiệu của các vấn đề mạng hoặc ứng dụng lỗi.

Lỗi trong kết nối mạng - Network Failure

Giải pháp tốt nhất cho lỗi mạng là cung cấp các đường dẫn dự phòng cho kết nối mạng. Các bộ lắng nghe (listeners) sao lưu, kết nối mạng và các card mạng xịn để giảm khả năng mất kết nối mạng ảnh hưởng đến tính khả dụng của hệ thống.

Lỗi người dùng - User Error

Người dùng có thể vô tình xóa hoặc sửa đổi dữ liệu. Nếu họ chưa commit hoặc thoát khỏi chương trình của mình, họ có thể đơn giản là quay trở lại trạng thái trước đó.

Bạn có thể sử dụng Oracle LogMiner để truy vấn các bản ghi redo logs online và các redo logs đã được lưu trữ thông qua giao diện Enterprise Manager hoặc SQL.

Dữ liệu transaction có thể tồn tại trong redo logs trực tuyến lâu hơn so với các đoạn undo; nếu bạn đã cấu hình sao lưu thông tin redo, redo sẽ tồn tại cho đến khi bạn xóa các file đã được lưu trữ.

Người dùng muốn khôi phục lại một bảng đã bị xóa có thể lấy lại từ recycle bin bằng cách sử dụng flashback để khôi phục bảng trước khi bị xóa. Nếu recycle bin đã bị xóa hoặc người dùng đã xóa bảng với tùy chọn PURGE, bảng bị xóa vẫn có thể khôi phục bằng cách sử dụng khôi phục điểm thời gian (PITR) nếu cơ sở dữ liệu đã được cấu hình đúng.

Trong Oracle Database 12c, RMAN cho phép bạn khôi phục một hoặc nhiều bảng hoặc các phân vùng bảng đến ở một thời điểm với thời gian cụ thể mà không ảnh hưởng đến các đối tượng cơ sở dữ liệu còn lại.

Sao lưu và phục hồi từ lỗi người dùng với các Giải pháp Flashback Oracle

Oracle Database bao gồm công nghệ Oracle Flashback: một nhóm tính năng hỗ trợ xem trạng thái trước đây của dữ liệu - và quay dữ liệu lên và xuống theo thời gian - mà không yêu cầu phục hồi cơ sở dữ liệu từ bản sao lưu.

Với công nghệ này, bạn có thể giúp người dùng phân tích và khôi phục từ các lỗi. Đối với người dùng đã commit những thay đổi lỗi, có thể sử dụng các phương pháp sau để phân tích lỗi:

• Flashback Query: Xem dữ liệu đã commit như nó tồn tại tại một thời điểm trong quá khứ. Lệnh SELECT với mệnh đề AS OF tham chiếu đến một thời điểm trong quá khứ thông qua một mốc thời gian hoặc số thay đổi hệ thống (SCN).
• Flashback Version Query: Xem dữ liệu lịch sử đã commit trong một khoảng thời gian cụ thể. Sử dụng mệnh đề VERSIONS BETWEEN của lệnh SELECT (vì lý do hiệu suất với các chỉ mục hiện có).
• Flashback Transaction Query: Xem tất cả các thay đổi cơ sở dữ liệu được thực hiện ở mức transaction.

Các giải pháp khả thi để khôi phục từ lỗi người dùng:

• Flashback Transaction Backout: Quay trở lại một transaction cụ thể và các transaction phụ thuộc liên quan.
• Flashback Table: Quay trở lại một hoặc nhiều bảng với nội dung của chúng tại một thời điểm trước đó mà không ảnh hưởng đến các đối tượng cơ sở dữ liệu khác.
• Flashback Drop: Hoàn tác các tác động của việc xóa một bảng bằng cách khôi phục bảng bị xóa từ recycle bin vào cơ sở dữ liệu cùng với các đối tượng phụ thuộc như chỉ mục và trigger.
• Flashback Database: Trả về cơ sở dữ liệu về một thời điểm hoặc SCN trong quá khứ.

Sự cố Instance: Xử lý vấn đề khi Phiên bản Cơ sở dữ liệu bị tắt trước khi đồng bộ hóa file

Sự cố của instance xảy ra khi instance cơ sở dữ liệu bị tắt trước khi đồng bộ hóa tất cả các file cơ sở dữ liệu. Một sự cố instance có thể xảy ra do lỗi phần cứng hoặc phần mềm hoặc thông qua việc sử dụng các lệnh tắt emergency SHUTDOWN ABORT và STARTUP FORCE.

Thường thì không cần sự can thiệp của quản trị viên để khôi phục từ sự cố instance nếu Oracle Restart được kích hoạt và đang giám sát cơ sở dữ liệu của bạn.

Oracle Restart cố gắng khởi động lại phiên bản cơ sở dữ liệu ngay sau khi nó gặp sự cố. Nếu cần can thiệp thủ công, có thể có một vấn đề nghiêm trọng hơn ngăn chặn việc khởi động lại phiên bản, chẳng hạn như một lỗi về bộ nhớ hoặc CPU.

Understanding instance recovery: Checkpoint(CKPT) Process

Để hiểu về quá trình phục hồi theo thời điểm kiểm tra (checkpoint recovery) cụ thể, cần hiểu cách hoạt động của một số quy trình nền (background processes).

Mỗi ba giây (hoặc thường xuyên hơn), quá trình CKPT sẽ lưu trữ dữ liệu trong file control để ghi nhận các block data đã được DBWn ghi từ bộ nhớ chung (SGA) xuống đĩa. Điều này được gọi là "checkpoint tăng tiến" (incremental checkpoint).

Mục đích của checkpoint là xác định vị trí trong file ghi redo trực tuyến mà quá trình phục hồi instance sẽ bắt đầu (được gọi là "vị trí checkpoint"). Khi có sự chuyển đổi log, quá trình CKPT cũng ghi thông tin checkpoint này vào Header của các file data.

Quá trình checkpoint tồn tại với một số mục đích:

• Đảm bảo rằng các block dữ liệu đã được sửa đổi trong bộ nhớ chung được ghi xuống đĩa đều đặn, nhằm tránh mất dữ liệu trong trường hợp hệ thống hoặc cơ sở dữ liệu gặp sự cố.
• Giảm thời gian cần thiết cho quá trình phục hồi instance (chỉ cần xử lý các mục nhập trong file ghi redo trực tuyến từ vị trí checkpoint cuối cùng để phục hồi).
• Đảm bảo rằng tất cả các dữ liệu đã được commit đã được ghi vào các file data trong quá trình tắt cơ sở dữ liệu.

Understanding instance recovery: Redo log files and log writer

Các file redo log ghi lại các thay đổi trong cơ sở dữ liệu do các transaction và hoạt động bên trong Oracle thực hiện. (Một transaction là một đơn vị logic của công việc bao gồm một hoặc nhiều câu lệnh SQL được thực thi bởi người dùng.)

Các file redo log bảo vệ cơ sở dữ liệu khỏi mất tính toàn vẹn do sự cố hệ thống như mất điện, hỏng đĩa và những vấn đề tương tự. Các file redo log nên được sao lưu đa kênh (multiplexed) để đảm bảo thông tin được lưu trữ trong chúng không bị mất trong trường hợp có sự cố đĩa.

File redo log bao gồm các nhóm file redo log. Mỗi nhóm bao gồm một file redo log và các bản sao sao lưu đa kênh của nó.

Mỗi bản sao giống nhau được gọi là một thành viên của nhóm đó, và mỗi nhóm được xác định bằng một số. Quá trình Log Writer (LGWR) ghi các bản ghi redo từ bộ đệm redo log vào tất cả các thành viên trong một nhóm redo log cho đến khi các file đầy hoặc yêu cầu chuyển đổi log.

Sau đó, nó chuyển đổi và ghi vào các file trong nhóm tiếp theo. Các nhóm redo log được sử dụng theo cách vòng tròn.

Mẹo thực hành tốt: Nếu có thể, các file redo log sao lưu đa kênh nên được đặt trên các đĩa khác nhau.

Thông tin checkpoint được ghi bởi quá trình CKPT bao gồm vị trí checkpoint, số thay đổi hệ thống (SCN), vị trí trong file ghi redo trực tuyến để bắt đầu quá trình phục hồi, thông tin về các log, và nhiều hơn nữa.

Lưu ý: Quá trình CKPT không ghi các khối dữ liệu xuống đĩa hoặc các khối redo vào file ghi redo trực tuyến.

Hiểu về cơ chế phục hồi dữ liệu trong oracle database - Understanding instance recovery

Khi xảy ra sự cố với instance trong cơ sở dữ liệu Oracle, quá trình phục hồi tự động sẽ được kích hoạt. Điều quan trọng là khởi động lại instance theo cách thông thường. Nếu chức năng Oracle Restart được bật và cấu hình để giám sát cơ sở dữ liệu, thì quá trình này sẽ diễn ra tự động.

Quá trình phục hồi bắt đầu bằng việc gắn kết các file controlr và cố gắng mở các file data. Nếu phát hiện rằng các file data chưa được đồng bộ trong quá trình tắt máy, instance sử dụng thông tin trong nhóm redo log để điều chỉnh các file data đến thời điểm tắt máy. Sau đó, cơ sở dữ liệu được mở và các transaction chưa được hoàn tất sẽ được rollback lại.

Các giai đoạn trong quá trình phụ hồi dữ liệu trong Oracle Datbase - Pharse of instance recovery

Để mở một file data, instance phải kiểm tra số thứ tự thay đổi hệ thống (SCN) có trong phần đầu của file data có khớp với SCN hiện tại được lưu trong file control của cơ sở dữ liệu.

Nếu các số không khớp, instance sẽ áp dụng data redo từ các log redo trực tuyến, "redo" tuần tự các transaction cho đến khi file data được cập nhật. Sau khi tất cả các file data đã được đồng bộ với file control, cơ sở dữ liệu được mở và người dùng có thể đăng nhập.

Khi các nhật ký redo được áp dụng, tất cả các transaction sẽ được áp dụng để đưa cơ sở dữ liệu trở về trạng thái như lúc xảy ra sự cố. Điều này thường bao gồm các transaction đang tiến hành nhưng chưa được commit.

Sau khi cơ sở dữ liệu đã được mở, những transaction chưa được commit đó sẽ bị rollback lại. Khi quá trình phục hồi instance hoàn tất giai đoạn lùi lại (rollback), các file data chỉ chứa dữ liệu đã được commit.

Tuning instance recovery - Tinh chỉnh khôi phục instance

Thông tin transaction được ghi lại trong các nhóm redo log trước khi instance trả về "commit complete" cho một transaction.

Thông tin trong các nhóm redo log đảm bảo rằng transaction có thể được khôi phục trong trường hợp xảy ra sự cố. Thông tin transaction cũng phải được ghi vào file dữ liệu.

Quá trình ghi file dữ liệu thường xảy ra sau khi thông tin được ghi lại trong các nhóm redo log, vì quá trình ghi file dữ liệu chậm hơn rất nhiều so với quá trình ghi redo log. (Việc ghi ngẫu nhiên cho file dữ liệu chậm hơn so với việc ghi tuần tự cho các file redo log.)

Mỗi ba giây, quá trình checkpoint ghi lại thông tin trong file control về vị trí checkpoint trong redo log. Do đó, máy chủ Oracle Database biết rằng tất cả các mục redo log được ghi lại trước điểm này không cần thiết cho việc khôi phục cơ sở dữ liệu. Trong hình minh họa ở trên, các khối sọc chưa được ghi vào đĩa.

Thời gian cần thiết cho quá trình phục hồi instance là thời gian cần để đưa file data từ điểm checkpoint cuối cùng đến SCN mới nhất được ghi lại trong file control.

Người quản trị điều khiển thời gian đó bằng cách đặt mục tiêu MTTR (trong giây) và thông qua việc xác định kích thước của các nhóm redo log. Ví dụ, đối với hai nhóm redo, khoảng cách giữa vị trí checkpoint và cuối nhóm redo log không được vượt quá 90% kích thước nhóm redo log nhỏ nhất.

So sánh phục hồi dữ liệu toàn bộ và theo thời gian xác định trong oracle database

Khi thực hiện phục hồi toàn bộ, bạn đưa cơ sở dữ liệu lên trạng thái được cập nhật đầy đủ, bao gồm tất cả các thay đổi dữ liệu đã được commit cho đến thời điểm hiện tại.

Tuy nhiên, phục hồi không hoàn chỉnh đưa cơ sở dữ liệu hoặc tablespace về một điểm trong quá khứ. Điều này có nghĩa là có một số transaction bị thiếu; tất cả các sửa đổi dữ liệu được thực hiện từ thời điểm phục hồi đến hiện tại đều bị mất.

Trong nhiều trường hợp, điều này là mục tiêu mong muốn vì có thể có những thay đổi cần được hoàn tác trong cơ sở dữ liệu. Phục hồi đến một điểm trong quá khứ là cách để loại bỏ các sửa đổi không mong muốn.

Quá trình phục hồi hoàn chỉnh: Các bước cần thiết để đảm bảo dữ liệu được khôi phục đầy đủ

Các bước sau mô tả quá trình phục hồi hoàn chỉnh:

1. Các file bị hỏng hoặc mất được khôi phục từ bản sao lưu.
2. Các thay đổi từ các bản sao lưu tăng tiến, các file redo log đã lưu trữ và các file redo log trực tuyến được áp dụng khi cần thiết. Các thay đổi redo log được áp dụng vào các file data cho đến khi đạt đến bản ghi nhật ký trực tuyến hiện tại và các transaction mới nhất đã được nhập lại. Các khối undo được tạo ra trong suốt quá trình này. Điều này được gọi là rolling forward hoặc cache recovery.

3. Các file data đã khôi phục có thể chứa các thay đổi đã commit và chưa commit.

4. Các khối undo được sử dụng để hoàn tác bất kỳ thay đổi chưa commit nào. Điều này đôi khi được gọi là phục hồi transaction.

5. Các file data hiện đang ở trạng thái đã phục hồi và khớp với các file dữ liệu khác trong cơ sở dữ liệu.

Phục hồi không hoàn chỉnh: Khôi phục cơ sở dữ liệu đến một thời điểm xác định

Phục hồi không hoàn chỉnh, hay phục hồi tại 1 thời điểm cụ thể trong thời gian của cơ sở dữ liệu (DBPITR), sử dụng bản sao lưu để tạo ra phiên bản không cập nhật nhất của cơ sở dữ liệu.

Điều này có nghĩa là bạn không áp dụng tất cả các bản ghi redo được tạo ra sau bản sao lưu gần nhất. Thực hiện loại phục hồi này chỉ khi thực sự cần thiết. Để thực hiện phục hồi điểm trong thời gian, bạn cần:

• Một bản sao lưu ngoại tuyến hoặc trực tuyến hợp lệ của tất cả các file dữ liệu được tạo trước điểm phục hồi.
• Tất cả các nhật ký đã lưu trữ từ thời điểm của bản sao lưu đến thời điểm phục hồi chỉ định.

Các bước để thực hiện phục hồi điểm trong thời gian như sau:

1. Khôi phục các file dữ liệu từ bản sao lưu: Bản sao lưu được sử dụng phải là từ trước điểm phục hồi mục tiêu. Điều này liên quan đến sao chép các file sử dụng lệnh hệ điều hành hoặc sử dụng lệnh RESTORE của RMAN.
2. Sử dụng lệnh RECOVER: Áp dụng redo từ các file nhật ký redo đã lưu trữ, bao gồm càng nhiều nhật ký cần thiết để đạt đến điểm phục hồi đích.
3. Trạng thái phục hồi: Bây giờ các file dữ liệu chứa một số transaction đã commit và chưa commit vì redo có thể chứa dữ liệu chưa commit.
4. Sử dụng lệnh ALTER DATABASE OPEN: Cơ sở dữ liệu được mở trước khi áp dụng undo. Điều này nhằm cung cấp khả năng sẵn có cao hơn.
5. Áp dụng dữ liệu undo: Trong khi redo được áp dụng, redo hỗ trợ các file dữ liệu undo cũng được áp dụng. Do đó, undo sẵn sàng để áp dụng cho các file dữ liệu để hoàn tác bất kỳ transaction chưa commit nào. Điều này được thực hiện tiếp theo.
6. Quá trình hoàn tất: Các file dữ liệu hiện đã được khôi phục đến điểm trong thời gian mà bạn đã chọn.

Oracle Flashback Database là phương pháp hiệu quả nhất để thực hiện DBPITR. Khác với các tính năng flashback khác, nó hoạt động ở mức vật lý và trả lại các file data hiện tại về nội dung của chúng tại một thời điểm trong quá khứ.

Kết quả tương tự như kết quả của DBPITR, bao gồm cả OPEN RESETLOGS, nhưng Flashback Database thường nhanh hơn vì nó không yêu cầu bạn phục hồi file dữ liệu và chỉ yêu cầu áp dụng redo hạn chế so với phục hồi phương tiện.

Giải pháp bảo vệ dữ liệu và phục hồi của Oracle

Oracle cung cấp một giải pháp bảo vệ dữ liệu phù hợp tùy thuộc vào mục tiêu sao lưu và phục hồi của bạn và RTO (Thời gian phục hồi mong muốn):

• Oracle Recovery Manager (RMAN) là thành phần chính của phần mềm Oracle Database quản lý quá trình sao lưu, khôi phục và phục hồi cơ sở dữ liệu.
• Oracle Secure Backup (OSB) là giải pháp quản lý sao lưu trên băng ghi cấp doanh nghiệp của Oracle cho cả cơ sở dữ liệu và hệ thống file.
• Công nghệ Oracle Database Flashback là một tập hợp các giải pháp khôi phục dữ liệu cho phép hoàn tác lỗi do con người bằng cách hoàn tác chọn lọc và hiệu quả hiệu ứng của một sai sót.
• Data Recovery Advisor cung cấp khả năng xác định vấn đề và khôi phục cơ sở dữ liệu thông minh.
• Data Guard và Active Data Guard cho phép các cơ sở dữ liệu dự phòng vật lý mở để truy cập đọc trong khi vẫn đồng bộ với cơ sở dữ liệu sản xuất thông qua phục hồi phương tiện.