Trong bài này, chúng ta sẽ tìm hiểu Kiến trúc Oracle DataGuard và các Background processes với sự trợ giúp của các sơ đồ.
- Tiến trình LNS của cơ sở dữ liệu chính (gọi là Primary database) sẽ trích xuất (capture) dữ liệu redo entry từ redo log buffer.
- Sau đó dữ liệu redo entry được gửi đến tiến trình RFS của cơ sở dữ liệu dự phòng (standby database) thông qua Oracle Net (chúng ta hay cấu hình log_archive_dest_2 ở trên Primary)
- Sau đó, tiến trình RFS ghi dữ liệu redo entry tới standby redo log file
- Nếu tiến trình LNS không đủ nhanh capture các dữ liệu redo entry trước khi chuyển đến online redo log hoặc nếu redo entry đang ghi xuống redo log rất nhanh thì tiến trình LNS sẽ đọc từ Online redo log file và gửi dữ liệu redo đó tới tiến trình RFS thông qua Oracle net .
- Nếu gặp một số sự cố mạng xảy ra và online redo log được chuyển thành archived redo log, trước khi nó được ghi vào stadnby redo log file thì tiến trình RFS sẽ giao tiếp trực tiếp với tiến trình ARCn để giải quyết vấn đề thiếu archived log (gọi là archive log gap).
- Một khi với bất kỳ cách nào dữ liệu redo được ghi vào standy redo log file, thì tiến trình MRP [trong trường hợp physical standby] sẽ apply dữ liệu redo hay hoặc LSP [trong trường hợp logical standby] sẽ apply câu lệnh sql đó trên cơ sở dữ liệu standby.
- Fetch archive log (FAL) client là tiến trình MRP. fetch archive log (FAL) server là một tiến trình foreground chạy trên cơ sở dữ liệu Primary và phục vụ các yêu cầu cần archive log FAL client. Một máy chủ FAL riêng biệt được tạo cho mỗi máy khách FAL đến. FAL_SERVER xác định được rằng FAL server cho standby database. Giá trị là tên Oracle Net service name, được giả định là được cấu hình đúng cách trên hệ thống cơ sở dữ liệu stadnby để trỏ đến FAL server mong muốn.
Các tham số FAL_CLIENT và FAL_SERVER rất hữu ích vì managed-recovery proces (MRP) trong physical standby sẽ tự động kiểm tra và giải quyết các gap (đỗ trễ, lag) tại thời điểm redo được apply. Điều này tức là bạn không cần phải tự mình chuyển những gaps redo log từ Primary sang Standby.
FAL_CLIENT và FAL_SERVER chỉ cần được xác định trong file tham số khởi tạo (pfile, spfile) cho (các) cơ sở dữ liệu dự phòng. Điều đó là có thể; tuy nhiên, để xác định hai tham số này trong tham số khởi tạo cho máy chủ cơ sở dữ liệu primary để giảm bớt khối lượng công việc sẽ cần được thực hiện nếu cơ sở dữ liệu primary được yêu cầu chuyển đổi vai trò của nó.
1. LGWR : LGWR thu thập dữ liệu redo entry và cập nhật các online redo log file.
2 . Cách gửi dữ liệu redo entry
Dữ liệu REDO được gửi thông qua tiến trình ARCn hoặc tiến trình LGWR.
Sử dụng tiến trình ARCn
Đây là mặc định và hỗ trợ hiệu suất tối đa (maximum performance). Tham số init log_archive_max_processes chỉ định số lượng tối đa của tiến trình ARC được gọi khi db primary được bắt đầu. Giá trị mặc định là 4 và nó là tham số động có thể được điều chỉnh bằng lệnh ALTER SYSTEM
Trên cơ sở dữ liệu primary, sau khi ARC0 thực hiện chuyển thành công online redo logfile thành archived redo log trên local, tiến trình ARC1 truyền redo từ cục bộ đến standby (qua cấu hình log_archive_dest_2 trong file tham số của Primary). Trên cơ sở dữ liệu dự phòng, tiến trình RFS sẽ ghi dữ liệu reod vào archived redo logfile.
Sử dụng tiến trình LNS [Log writer network server] : Tiến trình LNS hoạt động theo hai cách:
Cách 1 - Chế độ SYNC : Khi bạn cấu hình môi trường dataguard ở chế độ Sync Redo transport Service, tiến trình LGWR chuyển redo tới tiến trình LNS, quá trình này truyền dữ liệu trực tiếp đến tiến trình RFS trên cơ sở dữ liệu dự phòng. LGWR chờ xác nhận từ tiến trình LNS và tiến trình LNS chờ xác nhận từ tiến trình RFS rằng dữ liệu redo được apply cho cơ sở dữ liệu dự phòng trước khi xác nhận commit.
Cách 2 - Chế độ ASYNC : Khi bạn cấu hình môi trường ASYNC redo transport service, nó độc lập với quy trình LNS, cho dù tiến trình LNS đã đọc từ redo log buffer hayt từ online redo log file. Dataguard chỉ bắt đầu tiến trình asynchronous LNS, ngoài việc LGWR không có tương tác với đích asynchonous standby nào. Nói một cách dễ hiểu, data guard sẽ không đợi bất kỳ thông báo nào từ cơ sở dữ liệu dự phòng rằng redo có được apply hay không và tiếp tục thực hiện công việc của nó. Vì vậy, nó là cách nhanh hơn so với chế độ SYNC.
- Tiến trình ARCn : Như chúng ta đã biết tiến trình ARCn tạo ra một bản sao của các online redo log file. ARCn cũng chịu trách nhiệm vận chuyển dữ liệu redo tới một tiến trình RFS tại cơ sở dữ liệu dự phòng và chủ động phát hiện và giải quyết các redo log thiếu (redo gap) trên tất cả cơ sở dữ liệu dự phòng.
CÁC TIẾN TRÌNH TRÊN CƠ SỞ DỮ LIỆU STANBY
- RFS [Remote File Server] : Như chúng ta đã thấy ở trên, tiến trình RFS có thể lấy dữ liệu redo từ tiến trình LNS hoặc từ tiến trình ARCn trên Primary và tiến trình RFS có thể ghi thông tin redo tới standby redo log file. Mỗi tiến trình LNS và ARCn giao tiếp với cơ sở dữ liệu dự phòng có tiến trình RFS riêng.
- ARCn [Archiver]: Tiến trình ARCn lưu trữ standby redo log cũ
- MRP [Managed Recovery Process] : Trong trường hợp tiến trình MRP của physical dataguard bắt đầu hoạt động. Tiến trình MRP sẽ apply thông tin archived redo log tới physical standby database. Bạn có thể bật đồng bộ bằng lệnh “ALTER DATABASE RECOVER MANAGED STANDBY DATABASE” nó sẽ khởi tạo tiến trình foreground để thực hiện khôi phục. Và nếu bạn muốn thực hiện phục hồi ở background thì thêm tùy chọn DISCONNECT FROM SESSION khi đó tiến trình backgroun MRP sẽ được bật.
- LSP [Logical Standby]: Nó chỉ có tác dụng đối với logical dataguard. Nó kiểm soát việc apply archived redo log vào logical standby database. Tiến trình LSP sẽ chuyển đổi dữ liệu redo thành các câu lệnh sql và sau đó các câu lệnh sql này sẽ được applytới logical standby database.
