• Oracle data guard broker framework
• Oracle data guard process
• Automatic Gap Detection and Resolution
• Data protection modes

Oracle data guard broker framework

• Oracle data guard broker là một framework quản lý phân tán tự động và tập trung để tạo, duy trì và giám sát các cấu hình của Oracle data guard.
• Sau khi tạo cấu hình Oracle data guard, Broker sẽ giám sát hoạt động, tình trạng sức khỏe và tính sẵn sàng của tất cả các hệ thống trong cấu hình.
• Có thể sử dụng Oracle enterprise manager grid control hoặc giao diện command-line ( DGMGRL) để thuận tiện trong việc quản lý với Broker.

Oracle data guard process

• Oracle data guard sử dụng một vài process để cần thiến cho việc thực hiện tự động phục hồi thảm họa và tăng tính sẵn sàng cao. Một số process tồn tại trước sự xuất hiện của Data guard, những process đặc trưng khác được tạo ra để phục vụ cho Data guard.

Processes trên primary database

• LGWRn: 
  • Thu thập thông tin redo transaction và cập nhật vào Online redo logs trên primary database.
  • For each synchronous (SYNC) standby database: LGWR sẽ truyền redo vào một tiến trình LNS (Log Network Server),  và chuyển trực tiếp đến tiến trình RFS (Remote File Server) trên standby database. LGWR đợi xác nhận từ tiến trình LNS trước khi xác nhận commit.
  • For asynchronous (ASYNC) standby databases: Tiến trình LNS đọc độc lập redo từ redo log buffer trên memory hoặc trong online redo log file, và gửi các redo đến standby database.
• ARCn:
  • Tạo ra một bản copy của online redo log file vào archive redo log sử dụng cho việc recovery primary database.
  • Chịu trách nhiệm chuyển redo data đến tiến trình RFS trên standby database và chủ động phát hiện xử lý GAP trên tất cả các standby database.

Processes trên standby database

• Trên Standby database, data guard sử dụng 4 processes là Remote file server (RFS), Archiver (ARCn), Managed recovery (MRP), Logical standby (LSP):
  • RFS: Nhận thông tin redo từ primary database và có thể ghi redo vào Standby redo logs hoặc Archived redo logs. Mỗi tiến trình LNSn và ARCn từ primary database sẽ có tiến trình RFS của riêng nó.
  • ARCn: Lưu trữ Standby redo logs.
  • MRP: Chỉ có trên Physical standby database, nó sẽ apply thông tin redo log vào physical standby database.
  • LSP: Chỉ có trên Logical standby database, nó kiểm soát các thông tin apply archive redo logs vào standby database.

Automatic Gap Detection and Resolution

• Nếu kết nối giữa primary database và một hoặc nhiều standby database gặp sự cố, thì các redo data được tạo ra trên primary database sẽ không thể gửi đến các standby database.
• Khi một kết nối được thiết lập lại, oraccle data guard sẽ tự động tìm kiếm các Archived redo log files bị thiếu (gọi là GAP). Và sẽ tự động chuyển các Archived redo log files bị thiếu vào các standby database bằng cách sử dụng tiến trình ARCn (Arhiver process). Lúc này các standby database sẽ đồng bộ với primary mà không cần sự can thiệp của DBA.

Data protection modes

• Có 3 chế độ bảo vệ dữ liệu trong data guard: Maximum protection, maximum availability và maximum performance.

Maximum protection

• Hệ thống sẽ đảm bảo không bị mất dữ liệu nếu primary database gặp lỗi.
• Các dữ liệu redo data cần thiết để recovery mỗi transaction phải được ghi vào cả hai Online redo log và Standby redo logtrên ít nhất một standby database trước khi transaction commit.
• Để đảm bảo dữ liệu không bị mất khi hệ thống gặp lỗi thì primary database sẽ shutdown. Đây là chế độ an toàn cao nhất trong Data guard, nên tùy từng bài toán cụ thể chúng ta sẽ triển khai các chế độ protection trong data guard cho phù hợp.

Maximum avaibality

• Chế độ Maximum avaibality giống với chế độ Maximum protection. Chỉ khác ở chỗ, nếu như hệ thống gặp lỗi thì primary database sẽ không shutdown mà chuyển sang chế dộ Maximum performance.
• Khi tất các các GAP đã được xử lý và primary database đã đồng bộ với standby database thì primary database sẽ tự động điều chỉnh về chế độ hoạt động Maximum avaibality.

Maximum performance

• Đây là chế độ bảo vệ mặc định khi cài Data guard, nó cung cấp mức độ cao nhất có thể bảo vệ dữ liệu mà không ảnh hưởng tới hiệu suất của primary database.
• Điều này được thể hiện bằng cách cho phép một transaction commit trên primary database ngay sau khi redo data cần thiết để khôi phục transaction được ghi vào Online redo log.