Quá trình Database Writer (DBWn) trong Oracle Database sẽ ghi nội dung các bộ đệm(Buffer) vào files dữ liệu. DBWn chịu trách nhiệm ghi các bộ đệm đã được sửa đổi (dirty) trong bộ đệm cơ sở dữ liệu vào đĩa. 

Mặc dù một tiến trình Database Writer (DBW0) là đủ cho hầu hết các hệ thống, nhưng bạn có thể cấu hình các tiến trình bổ sung để cải thiện hiệu suất ghi nếu hệ thống của bạn sửa đổi dữ liệu nhiều. Các tiến trình bổ sung này có tên là DBW1 đến DBW9, DBWa đến DBWz và BW36-BW99.

Các tiến trình DBWn bổ sung này không hữu ích trên các hệ thống đơn nhân(uniprocessor systems). Khi một bộ đệm trong bộ đệm cơ sở dữ liệu(Database buffer) được sửa đổi, nó được đánh dấu là bẩn (dirty) và được thêm vào đầu hàng đợi kiểm tra định kỳ được lưu trữ theo thứ tự số thay đổi hệ thống (SCN).

Thứ tự này phù hợp với thứ tự của redo được ghi vào các nhật ký redo cho các bộ đệm đã thay đổi. Khi số lượng bộ đệm khả dụng trong bộ đệm cơ sở dữ liệu giảm xuống dưới ngưỡng nội bộ (đến mức các tiến trình máy chủ thấy khó để lấy được bộ đệm khả dụng), DBWn sẽ ghi các bộ đệm(Buffer) không sử dụng thường xuyên vào các tệp dữ liệu (Data files) từ đuôi của danh sách LRU để các tiến trình có thể thay thế bộ đệm khi cần.

DBWn cũng sẽ ghi từ đuôi của hàng đợi kiểm tra tiếp tục để giữ cho quá trình kiểm tra tiến lên.

Cấu trúc bộ nhớ SGA chứa địa chỉ byte của redo (RBA) tại vị trí trong luồng redo nơi phục hồi nên bắt đầu trong trường hợp có một sự cố với instance. Cấu trúc này hoạt động như một con trỏ vào redo và được ghi vào tệp điều khiển(Control file) bởi quá trình CKPT mỗi ba giây một lần.

Bởi vì DBWn viết các bộ đệm dirty theo thứ tự SCN và bởi vì redo cũng theo thứ tự SCN, mỗi khi DBWn ghi các bộ đệm dirty từ danh sách LRU, nó cũng đẩy con trỏ được giữ trong cấu trúc bộ nhớ SGA để phục hồi instance (nếu cần thiết) bắt đầu đọc redo từ khoảng vị trí chính xác và tránh I/O không cần thiết. Điều này được gọi là checkpoint tăng tiến.

Lưu ý: Có các trường hợp khác khi DBWn có thể ghi (ví dụ: khi tablespace được đưa vào chế độ chỉ đọc hoặc không kết nối). Trong các trường hợp như vậy, không có checkpoint tăng tiến nào xảy ra vì các buffer dirty chỉ thuộc về các tệp dữ liệu tương ứng được ghi vào cơ sở dữ liệu không liên quan đến thứ tự SCN.

Thuật toán LRU giữ các block được truy cập thường xuyên hơn trong bộ đệm để giảm thiểu đọc từ đĩa. Tùy chọn CACHE có thể được đặt trên các bảng để giúp giữ các block lâu hơn trong bộ nhớ.

Tham số khởi tạo DB_WRITER_PROCESSES xác định số lượng tiến trình DBWn. Số lượng tối đa của các tiến trình Database Writer là 100. Nếu không được chỉ định trong quá trình khởi động, Oracle Database sẽ quyết định cách thiết lập DB_WRITER_PROCESSES dựa trên số lượng CPU và nhóm bộ xử lý. Tiến trình DBWn sẽ ghi các buffer dirty vào đĩa trong các điều kiện sau:

• Khi một tiến trình máy chủ không thể tìm thấy một buffer sạch có thể tái sử dụng sau khi quét một số lượng buffer ngưỡng, nó sẽ gửi tín hiệu cho DBWn để thực hiện ghi. DBWn ghi các buffer dirty vào đĩa bất đồng bộ trong khi thực hiện các xử lý khác.
• DBWn ghi các buffer để đẩy checkpoint (điểm kiểm tra), đó là vị trí trong chuỗi redo (log) mà khởi động lại thực thể bắt đầu. Vị trí này được xác định bằng buffer dirty cũ nhất trong bộ đệm buffer.

Trong tất cả các trường hợp, DBWn thực hiện ghi đa khối (multiblock) để tăng hiệu suất. Số lượng khối được ghi trong một lần ghi đa khối thay đổi theo hệ điều hành.

Quá trình LGWR (Log Writer process) có trách nhiệm quản lý bộ đệm redo log bằng cách ghi các mục nhập của bộ đệm redo log vào file redo log trên đĩa. LGWR ghi toàn bộ redo đã được sao chép trong bộ đệm kể từ lần ghi cuối cùng.

LGWR khởi động và phối hợp các quy trình hỗ trợ đồng thời để thực hiện một số công việc. LGWR xử lý các hoạt động nhanh hoặc cần được phối hợp, và ủy thác các hoạt động đến các tiến trình LGnn có thể được hưởng lợi từ các hoạt động đồng thời, chủ yếu là ghi redo từ bộ đệm log vào file redo log và đăng tải việc ghi hoàn tất đến tiến trình foreground đang chờ đợi.

Bởi vì các tiến trình LGnn hoạt động đồng thời và một số hoạt động phải được thực hiện theo thứ tự, LGWR buộc thứ tự để đảm bảo rằng ngay cả khi các hoạt động ghi được hoàn thành không theo thứ tự, việc thông báo đến các tiến trình foreground sẽ đúng thứ tự.

Bộ đệm redo log là một bộ đệm vòng tròn. Khi LGWR ghi toàn bộ redo từ bộ đệm redo log vào file redo log trên đĩa, các tiến trình máy chủ sau đó có thể sao chép các mục nhập(Entries) mới qua các mục nhập trong bộ đệm redo log đã được ghi vào đĩa.

LGWR thường ghi đủ nhanh để đảm bảo rằng luôn có không gian khả dụng trong bộ đệm cho các mục nhập mới(Entries), ngay cả khi truy cập vào redo log là nặng. LGWR ghi một phần liên tục của bộ đệm vào đĩa.

LGWR sẽ thực hiện ghi vào khi:

• Khi một tiến trình người dùng commit một transaction
• Khi một online redo log switch xảy ra
• Khi redo log buffer chỉ còn 1/3 dung lượng hoặc chứa 1 MB dữ liệu đệm
• Trước khi một tiến trình DBWn ghi các buffer đã được sửa đổi xuống đĩa (nếu cần)
• Khi ba giây đã trôi qua kể từ lần ghi cuối cùng vào các tập tin log.

Trước khi DBWn có thể ghi một buffer đã được sửa đổi, tất cả các bản ghi redo liên quan đến thay đổi trên buffer đó phải được ghi xuống đĩa trước (theo giao thức ghi trước).

Nếu DBWn phát hiện rằng một số bản ghi redo chưa được ghi, nó sẽ gửi tín hiệu cho LGWR để ghi các bản ghi redo xuống đĩa và đợi cho LGWR hoàn tất việc ghi redo log buffer trước khi DBWn có thể ghi các buffer dữ liệu. LGWR ghi vào nhóm log hiện tại.

Nếu một trong các tập tin trong nhóm bị hỏng hoặc không có sẵn, LGWR tiếp tục ghi vào các tập tin khác trong nhóm và ghi lỗi vào tệp theo dõi LGWR và trong thông báo cảnh báo hệ thống. Nếu tất cả các tập tin trong một nhóm bị hỏng, hoặc nếu nhóm không có sẵn vì chúng chưa được lưu trữ, LGWR sẽ không thể tiếp tục hoạt động.

Khi một người dùng thực hiện lệnh COMMIT, LGWR đặt một bản ghi commit vào bộ đệm redo log và ghi nó xuống đĩa ngay lập tức, cùng với các mục redo của giao dịch. Những thay đổi tương ứng trên các khối dữ liệu được trì hoãn cho đến khi việc ghi chúng trở nên hiệu quả hơn.

Điều này được gọi là cơ chế commit nhanh. Việc ghi đồng thời các mục redo chứa bản ghi commit của giao dịch là sự kiện duy nhất xác định liệu giao dịch đã được commit hay chưa. Oracle Database trả về mã thành công cho giao dịch đang commit, mặc dù các bộ đệm dữ liệu chưa được ghi xuống đĩa.

Nếu cần thêm không gian đệm, LGWR đôi khi sẽ ghi các mục redo trước khi một giao dịch được commit. Những mục này chỉ trở thành vĩnh viễn nếu giao dịch được commit sau đó. Khi một người dùng commit một giao dịch, Oracle Database gán cho giao dịch một SCN (System Change Number), được ghi lại cùng với các mục redo của giao dịch trong redo log.

SCN được ghi lại trong redo log để các hoạt động phục hồi có thể được đồng bộ hóa trong các Real Application Clusters và cơ sở dữ liệu phân tán.

Trong thời điểm hoạt động cao điểm, LGWR có thể ghi vào tập tin redo log bằng cách sử dụng commit nhóm.

Ví dụ, giả sử một người dùng commit một giao dịch. LGWR phải ghi các mục redo của giao dịch xuống đĩa. Trong khi điều này xảy ra, các người dùng khác thực hiện các lệnh COMMIT. Tuy nhiên, LGWR không thể ghi vào tập tin redo log để commit những giao dịch này cho đến khi nó hoàn thành thao tác ghi trước đó.

Sau khi các mục của giao dịch đầu tiên được ghi vào tập tin redo log, toàn bộ danh sách các mục redo của các giao dịch đang chờ (chưa được commit) có thể được ghi xuống đĩa trong một thao tác duy nhất, yêu cầu ít I/O hơn so với việc xử lý các mục redo của từng giao dịch một cách riêng lẻ.

Do đó, Oracle Database giảm thiểu I/O đĩa và tối đa hóa hiệu suất của LGWR. Nếu yêu cầu để commit tiếp tục ở mức cao, mỗi lần ghi (bởi LGWR) từ bộ đệm redo log có thể chứa nhiều bản ghi commit.

Checkpoint là một cấu trúc dữ liệu xác định một số thứ tự thay đổi hệ thống (SCN) trong luồng redo của cơ sở dữ liệu. Checkpoint được ghi lại trong control file và trong tiêu đề của data file. Chúng là một yếu tố quan trọng của phục hồi.

Khi một checkpoint xảy ra, Oracle Database phải cập nhật tiêu đề của tất cả các data file để ghi lại các chi tiết của checkpoint. Điều này được thực hiện bởi quá trình CKPT. Quá trình CKPT không ghi các khối vào đĩa; DBWn luôn thực hiện công việc đó. SCN được ghi lại trong tiêu đề data file đảm bảo rằng tất cả các thay đổi được thực hiện trên các khối cơ sở dữ liệu trước SCN đó đã được ghi vào đĩa.

Quá trình khôi phục dữ liệu khi bắt đầu một phiên làm việc được thực hiện bởi tiến trình System Monitor (SMON) nếu cần. SMON cũng chịu trách nhiệm làm sạch các đoạn tạm thời không còn sử dụng.

Nếu bất kỳ giao dịch nào đã kết thúc bị bỏ qua trong quá trình khôi phục phiên bản vì lỗi đọc tập tin hoặc lỗi ngoại tuyến, SMON sẽ khôi phục chúng khi tablespace hoặc tập tin được đưa trở lại trực tuyến(Online).

SMON thường xuyên kiểm tra để xem liệu quá trình này có cần thiết không. Các tiến trình khác có thể gọi SMON nếu chúng phát hiện có nhu cầu cho nó.

Process Monitor process (PMON) thực hiện phục hồi quá trình khi một quá trình người dùng bị lỗi. PMON chịu trách nhiệm dọn dẹp bộ đệm cache cơ sở dữ liệu và giải phóng tài nguyên mà quá trình người dùng đang sử dụng.

Ví dụ, nó đặt lại trạng thái của bảng giao dịch hoạt động, giải phóng khóa và loại bỏ ID quá trình khỏi danh sách các quá trình hoạt động.

PMON định kỳ kiểm tra trạng thái của quá trình trình diễn và máy chủ và khởi động lại bất kỳ quá trình nào đã dừng chạy (nhưng không phải bất kỳ quá trình nào mà Oracle Database đã chấm dứt một cách cố ý).

Giống như SMON, PMON kiểm tra định kỳ để xem liệu nó cần thiết hay không; nó có thể được gọi nếu một quá trình khác phát hiện nhu cầu sử dụng nó.

Quá trình phục hồi (RECO) là một quá trình nền được sử dụng trong cấu hình cơ sở dữ liệu phân tán để giải quyết tự động các sự cố liên quan đến giao dịch phân tán. Quá trình RECO của một phiên bản tự động kết nối với các cơ sở dữ liệu khác liên quan đến một giao dịch phân tán đang bị đình chỉ.

Khi quá trình RECO thiết lập lại kết nối giữa các máy chủ cơ sở dữ liệu liên quan, nó tự động giải quyết tất cả các giao dịch đang bị đình chỉ, loại bỏ bất kỳ hàng đợi giao dịch nào tương ứng với các giao dịch đình chỉ đã được giải quyết từ bảng giao dịch chờ của mỗi cơ sở dữ liệu.

Nếu quá trình RECO không kết nối được với máy chủ từ xa, RECO tự động thử kết nối lại sau một khoảng thời gian định kỳ. Tuy nhiên, RECO sẽ chờ một khoảng thời gian ngày càng tăng (tăng mũ) trước khi thử kết nối lại.

Quá trình đăng ký của Listener Registration process (LREG) sẽ đăng ký thông tin về database instance và dispatcher processes với Oracle Net Listener. LREG cung cấp cho listener các thông tin sau:

Khi instance bắt đầu, LREG cố gắng kết nối với listener. Nếu listener đang chạy, LREG sẽ truyền thông tin cho nó. Nếu listener không chạy, LREG sẽ định kỳ thử kết nối với listener. Sau khi listener đã bắt đầu, có thể mất tối đa 60 giây để LREG đăng ký database instance với listener.

Bạn có thể sử dụng lệnh ALTER SYSTEM REGISTER để khởi tạo ngay quá trình đăng ký dịch vụ sau khi khởi động listener.

Quá trình Archiving (ARCn) sao chép các tập tin redo log vào một thiết bị lưu trữ chỉ định sau khi một log switch đã xảy ra. Các quá trình ARCn chỉ xuất hiện khi cơ sở dữ liệu ở chế độ ARCHIVELOG và chế độ lưu trữ tự động được kích hoạt.

Nếu bạn dự định có một khối lượng công việc lớn cho việc lưu trữ (như trong quá trình tải dữ liệu theo lô), bạn có thể tăng số lượng tối đa của các quá trình Archiver.

Cũng có thể có nhiều đích đến nhật ký lưu trữ. Đề nghị có ít nhất một quá trình Archiver cho mỗi đích đến. Giá trị mặc định là có bốn quá trình Archiver.