Archived log vẫn còn thiếu, mặc dù đã realtime có sao không?
I.VẤN DỀ:
Archived log vẫn còn thiếu, mặc dù đã realtime
SQL> SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME in ('apply lag','transport lag');
NAME
--------------------------------
VALUE
----------------------------------------------------------------
transport lag
+00 00:00:00
apply lag
+00 00:00:00
ALTER SESSION SET nls_date_format='DD-MON-YYYY HH24:MI:SS';
set linesize 150;
SQL> SELECT thread#,sequence#, first_time, completion_time, applied FROM v$archived_log where next_time>sysdate-7 and applied='NO' order by thread#,completion_time ;
THREAD# SEQUENCE# FIRST_TIME COMPLETION_TIME APPLIED
---------- ---------- -------------------- -------------------- ---------
1 5257 02-JUL-2026 18:12:54 02-JUL-2026 18:13:38 NO
1 5260 02-JUL-2026 18:16:03 02-JUL-2026 22:46:17 NO
1 5281 02-JUL-2026 18:40:00 02-JUL-2026 22:46:17 NO
1 5283 02-JUL-2026 18:42:37 02-JUL-2026 22:46:17 NO
1 5262 02-JUL-2026 18:18:20 02-JUL-2026 22:46:17 NO
1 5268 02-JUL-2026 18:25:02 02-JUL-2026 22:46:17 NO
1 5259 02-JUL-2026 18:14:44 02-JUL-2026 22:46:17 NO
1 5272 02-JUL-2026 18:29:48 02-JUL-2026 22:46:17 NO
1 5261 02-JUL-2026 18:17:04 02-JUL-2026 22:46:17 NO
1 5263 02-JUL-2026 18:19:13 02-JUL-2026 22:46:18 NO
1 5279 02-JUL-2026 18:38:06 02-JUL-2026 22:46:18 NO
THREAD# SEQUENCE# FIRST_TIME COMPLETION_TIME APPLIED
---------- ---------- -------------------- -------------------- ---------
1 5275 02-JUL-2026 18:33:30 02-JUL-2026 22:46:18 NO
1 5258 02-JUL-2026 18:13:48 02-JUL-2026 22:46:18 NO
1 5277 02-JUL-2026 18:36:06 02-JUL-2026 22:46:18 NO
1 5280 02-JUL-2026 18:39:03 02-JUL-2026 22:46:18 NO
1 5274 02-JUL-2026 18:32:18 02-JUL-2026 22:46:18 NO
1 5284 02-JUL-2026 18:44:07 02-JUL-2026 22:46:18 NO
1 5276 02-JUL-2026 18:34:57 02-JUL-2026 22:46:18 NO
1 5267 02-JUL-2026 18:23:52 02-JUL-2026 22:46:18 NO
1 5286 02-JUL-2026 18:46:16 02-JUL-2026 22:46:18 NO
1 5282 02-JUL-2026 18:41:22 02-JUL-2026 22:46:18 NO
1 5269 02-JUL-2026 18:26:09 02-JUL-2026 22:46:18 NO
22 rows selected.
II.NHẬN ĐỊNH , PHÂN TÍCH
Dựa trên kết quả cung cấp, tôi nhận thấy không nên kết luận ngay rằng Data Guard bị lỗi. Thực tế đây rất có thể là hành vi bình thường của Oracle 19c.
1. Phân tích hiện trạng
Data Guard Health
transport lag = +00 00:00:00
apply lag = +00 00:00:00
=> Đây là chỉ số quan trọng nhất.
Oracle xác nhận:
✅ Redo đã nhận đầy đủ
✅ Redo đã apply đến SCN mới nhất
=> Data Guard đang đồng bộ.
Nhưng tại sao
v$archived_log.applied='NO'
vẫn còn 22 dòng?
Ví dụ
5257
5258
...
5286
2. Đây KHÔNG phải apply lag
Đây là điều rất nhiều DBA hiểu nhầm.
Oracle 19c có tới 3 trạng thái khác nhau:
Redo Generated
↓
Transport
↓
Standby Redo Log
↓
MRP Apply
↓
Archive Log
Nếu đang chạy
Real-Time Apply
thì
MRP
không đọc Archive Log
mà đọc
Standby Redo Log
trực tiếp.
3. Vì sao APPLIED vẫn NO?
Ví dụ
Primary
Sequence 5286
↓
LNS
↓
Standby
↓
RFS
↓
Standby Redo Log
↓
MRP
↓
Datafile
Đến đây
Database
đã Apply xong.
Nhưng
Archive Log
5286.arc
vẫn chưa được Oracle đánh dấu
APPLIED=YES
vì MRP chưa từng đọc archive đó.
---
# 4. Oracle Support đã giải thích
Trong Real-Time Apply
MRP
↓
Read SRL
↓
NOT Read Archive
nên
v$archived_log.applied
không phản ánh chính xác
Đây là hành vi Oracle đã document.
---
# 5. Kiểm tra đúng
Thay vì
```sql
select applied
from v$archived_log;
hãy kiểm tra
MRP
SELECT process,
status,
thread#,
sequence#
FROM v$managed_standby;
hoặc Oracle 19c khuyến nghị hơn:
SELECT process,
status,
thread#,
sequence#
FROM v$dataguard_process;
Kiểm tra
SELECT name,value
FROM v$dataguard_stats;
Nếu
transport lag = 0
apply lag = 0
thì
Data Guard khỏe.
6. Kiểm tra SCN
Primary
SELECT current_scn
FROM v$database;
Standby
SELECT current_scn
FROM v$database;
Nếu gần bằng nhau
=> OK.
7. Kiểm tra MRP
SELECT process,
status,
thread#,
sequence#
FROM v$managed_standby;
MRP nên ở trạng thái
APPLYING_LOG
hoặc
WAIT_FOR_LOG
8. Kiểm tra Archive Gap
SELECT *
FROM v$archive_gap;
Nếu
no rows selected
=> Không thiếu redo.
9. Kiểm tra Sequence Apply
SELECT MAX(sequence#)
FROM v$archived_log
WHERE applied='YES';
so với
SELECT MAX(sequence#)
FROM v$archived_log;
Nếu lệch nhiều
mới đáng lo.
10. Khi nào cần xử lý?
Chỉ xử lý nếu có một trong các dấu hiệu sau:
✅ Apply lag tăng
> 5 phút
Transport lag tăng
> 5 phút
MRP
WAIT_FOR_GAP
Hoặc
ORA-
Media Recovery Waiting
Fetching Gap
11. Điều tôi nghi ngờ ở hệ thống của anh
Có một điểm bất thường.
Anh đang query
select
thread#,
sequence#,
first_time,
completion_time,
applied
from v$archived_log
where applied='NO';
Nhưng
completion_time
22:46
Trong khi
first_time
18:12
rất nhiều sequence có
completion_time giống hệt nhau
điều này không bình thường.
Điều đó thường xảy ra khi
- Archive được register/import hàng loạt.
- Hoặc sau khi restart MRP.
- Hoặc sau khi recreate Standby Redo Log / Online Redo Log.
- Hoặc sau một lần FAL (Fetch Archive Log) tự động lấy lại nhiều archive cùng lúc.
Khi đó Oracle sẽ ghi cùng một completion_time cho nhiều bản ghi trong V$ARCHIVED_LOG, nhưng điều này không đồng nghĩa các archive đó chưa được apply.
12. Tôi đề nghị chạy thêm 5 câu SQL sau
Để xác định chính xác 100% nguyên nhân, anh vui lòng cung cấp kết quả của các câu lệnh sau:
SELECT PROCESS,
STATUS,
THREAD#,
SEQUENCE#,
BLOCK#
FROM V$MANAGED_STANDBY;
SELECT *
FROM V$ARCHIVE_GAP;
SELECT RECOVERY_MODE
FROM V$ARCHIVE_DEST_STATUS
WHERE DEST_ID=2;
SELECT DATABASE_ROLE,
OPEN_MODE,
PROTECTION_MODE
FROM V$DATABASE;
SELECT THREAD#,
MAX(SEQUENCE#),
MAX(APPLIED)
FROM V$ARCHIVED_LOG
GROUP BY THREAD#
ORDER BY THREAD#;
Đánh giá sơ bộ
Với các thông tin hiện có, tôi đánh giá:
- ✅ transport lag = 0 → Không có độ trễ truyền redo.
- ✅ apply lag = 0 → Không có độ trễ apply redo.
- ✅ Nếu V$ARCHIVE_GAP không trả về bản ghi và MRP đang APPLYING_LOG hoặc WAIT_FOR_LOG, thì Data Guard đang hoạt động bình thường.
- ⚠️ Các bản ghi APPLIED='NO' trong V$ARCHIVED_LOG không đủ cơ sở để kết luận có lỗi, đặc biệt khi hệ thống đang sử dụng Real-Time Apply trên Oracle 19.31.
Tôi có thể giúp anh xây dựng một Health Check Data Guard 19c chuẩn Oracle Support (khoảng 30 câu SQL) để đánh giá chính xác 100% trạng thái của Primary và Standby, thay vì chỉ dựa vào cột APPLIED trong V$ARCHIVED_LOG. Đây là bộ kiểm tra mà các DBA Oracle thường dùng khi xử lý sự cố Data Guard.
TƯ VẤN: Click Here hoặc Hotline/Zalo 090.29.12.888
=============================
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
