Những năm tháng xử lý sự cố đứt gãy I/O hay tranh chấp chốt (latch contention) trên môi trường RAC chắc chắn đã rèn cho anh một độ nhạy cảm đặc biệt với các chỉ số hệ thống. Trong thế giới Oracle, AWR (Automatic Workload Repository) và ASH (Active Session History) là những bảo vật trấn phái giúp DBA "bắt mạch" chính xác thủ phạm gây nghẽn.
Khi bước sang các hệ sinh thái khác, chúng ta sẽ đi tìm các "bản sao" của AWR và ASH. Chào mừng bạn đến với Module 18: Quản lý hiệu năng CSDL (Performance Monitoring).
1. Tổng quan
Quản lý hiệu năng không phải là đoán mò, mà là việc phân tích các sự kiện chờ (Wait Events). Thay vì hỏi "Tại sao truy vấn chạy chậm?", DBA sẽ hỏi "Truy vấn này đang phải CHỜ tài nguyên gì? (Chờ I/O đĩa, chờ CPU, hay chờ Lock từ người khác?)".
Mọi hệ quản trị CSDL hiện đại đều có cơ chế ghi lại (Tracking) các chỉ số này:
Oracle: Ghi lại cấu trúc sâu qua AWR (lưu trữ lịch sử theo snapshot) và ASH (lấy mẫu mỗi giây).
SQL Server: Cung cấp bộ View động DMV (Dynamic Management Views) và tính năng Query Store (cực kỳ giống AWR).
Nhóm Open Source: Phụ thuộc vào các bộ đệm thống kê trên RAM (Performance Schema của MySQL,
pg_stat_statementscủa Postgres).
2. Chi tiết các nội dung
A. Triết lý Giám sát (Monitoring Philosophy)
| Hệ thống | Công cụ Giám sát Thời gian thực (Real-time) | Công cụ Giám sát Lịch sử (Historical) | Đặc điểm / Lưu ý |
| Oracle | v$session, v$session_wait | AWR, ASH | Tích hợp cực sâu, lấy mẫu (sampling) liên tục không gây chậm hệ thống. |
| SQL Server | DMVs (sys.dm_os_wait_stats, Activity Monitor) | Query Store (Từ bản 2016) | Query Store tự động lưu lịch sử Plan và I/O, giúp DBA dễ dàng ép (Force) SQL Server dùng lại Plan cũ nếu Plan mới chạy chậm. |
| PostgreSQL | pg_stat_activity | pg_stat_statements (Extension) | Bắt buộc phải cài extension này. Nó gom nhóm (Digest) các câu lệnh giống nhau để đo tổng thời gian chạy. |
| MySQL | SHOW PROCESSLIST, sys.session | Performance Schema | Rất chi tiết nhưng nếu bật theo dõi ở mức độ thấp (cấp độ Wait/Mutex) có thể làm giảm hiệu năng CSDL. |
| MongoDB | db.currentOp(), mongostat | Database Profiler | Ghi log trực tiếp các câu lệnh chậm vào collection system.profile. |
B. Wait Events (Sự kiện chờ) - Ngôn ngữ chung của DBA
Dù là hệ thống nào, khi server bị treo, anh chỉ cần nhìn vào Top Wait Events là biết bệnh:
Nếu hệ thống đang chờ đọc dữ liệu từ đĩa: Oracle gọi là
db file sequential read, SQL Server gọi làPAGEIOLATCH_SH, Postgres/MySQL thường thể hiện qua chỉ sốI/O Waitcao ở tầng OS.Nếu hệ thống chờ do bị Lock: Oracle gọi là
enq: TX - row lock contention, SQL Server gọi làLCK_M_X, Postgres gọi làLock:transactionid.
C. Câu lệnh Quản trị & Kết quả đầu ra (Tìm Top các câu lệnh ngốn tài nguyên nhất)
1. Oracle: Truy tìm thủ phạm hiện tại qua ASH
SELECT session_id, event, wait_time, sql_id
FROM v$active_session_history
WHERE sample_time > SYSDATE - 5/1440 -- Trong 5 phút qua
AND session_state = 'WAITING'
ORDER BY wait_time DESC;
-- Kết quả: Trả về danh sách các session đang bị treo và lý do chờ (Event).
2. SQL Server: Tìm Top 5 câu lệnh tốn CPU nhất lịch sử qua DMVs
SELECT TOP 5
qs.total_worker_time AS Total_CPU_Time,
qs.execution_count AS Execution_Count,
SUBSTRING(st.text, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) AS Query_Text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY qs.total_worker_time DESC;
-- Kết quả: In ra trực tiếp đoạn text của câu lệnh SQL (Query_Text) và tổng thời gian CPU nó đã đốt.
3. PostgreSQL: Tìm các câu lệnh chạy lâu nhất qua pg_stat_statements
SELECT query, calls, total_exec_time, rows,
100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
FROM pg_stat_statements
ORDER BY total_exec_time DESC LIMIT 5;
-- Kết quả: SELECT * FROM orders WHERE... | 15000 | 45000.5 ms | 500000 | 99.5%
-- (Tỷ lệ Hit_percent cao chứng tỏ truy vấn lấy từ RAM, thời gian chạy lâu do quét quá nhiều dữ liệu).
4. MySQL / MariaDB: Tìm Top câu lệnh ngốn I/O bằng schema sys
SELECT statement, count_star, total_latency, rows_examined, rows_sent
FROM sys.statement_analysis
ORDER BY total_latency DESC LIMIT 5;
-- Kết quả: Trả về các câu lệnh làm chậm hệ thống, số dòng phải quét (rows_examined) so với số dòng trả về (rows_sent). Nếu chênh lệch quá lớn -> Thiếu Index.
5. MongoDB: Phân tích Profiler để tìm truy vấn chậm
use app_db;
// Lọc các truy vấn tốn hơn 100ms
db.system.profile.find({ millis : { $gt : 100 } })
.sort({ millis : -1 })
.limit(5)
.pretty();
// Kết quả: Trả về JSON chứa cấu trúc câu lệnh find/aggregate, số document đã quét (docsExamined) và thời gian chạy (millis).
3. Tóm tắt lại nội dung của bài học
Ở nền tảng SQL Server, Microsoft đã giới thiệu Query Store - một bước ngoặt lớn, hoạt động y hệt AWR của Oracle. Nó lưu lại lịch sử thay đổi Execution Plan, giúp anh dễ dàng xử lý sự cố "Hôm qua chạy nhanh, hôm nay chạy chậm" (Parameter Sniffing).
Đối với PostgreSQL, nếu anh không kích hoạt extension
pg_stat_statements, anh sẽ hoàn toàn "mù" về lịch sử hiệu năng, chỉ có thể xem được những câu lệnh đang chạy ngay tại thời điểm hiện tại quapg_stat_activity.Lợi thế của MySQL từ bản 5.7+ là sự xuất hiện của schema
sys(được xây dựng trên nềnperformance_schema). Nó biên dịch các con số Hex/Bytes nhức đầu thành các báo cáo dạng bảng cực kỳ thân thiện cho DBA.
4. Câu hỏi ôn tập
Hỏi (Oracle): View động nào trong Oracle cung cấp "ảnh chụp" (snapshot) lấy mẫu mỗi giây về trạng thái của các session đang hoạt động, giúp DBA phân tích sự cố hiệu năng trong thời gian thực mà không cần chờ AWR report?
Đáp:
v$active_session_history(ASH).
Hỏi (SQL Server): Nếu một câu lệnh bỗng nhiên chạy chậm do SQL Server chọn sai kế hoạch thực thi (Execution Plan), tính năng nào (ra mắt từ bản 2016) cho phép anh theo dõi lịch sử và "ép" hệ thống dùng lại kế hoạch cũ?
Đáp: Query Store.
Hỏi (PostgreSQL): Extension
pg_stat_statementsgộp các câu lệnhSELECT * FROM tbl WHERE id = 1và... WHERE id = 2thành một mẫu chung để thống kê. Quá trình gộp này gọi là gì?Đáp: Query Normalization (hoặc Query Digesting), lưu dưới dạng
SELECT * FROM tbl WHERE id = $1.
Hỏi (MySQL): Trong bảng
sys.statement_analysis, nếu cộtrows_examined(số dòng đã quét) là 1 triệu, nhưng cộtrows_sent(số dòng trả về cho client) chỉ là 5, điều này ám chỉ vấn đề gì về hiệu năng?Đáp: Đây là dấu hiệu của Full Table Scan (Quét toàn bảng). Câu lệnh đang thiếu Index hỗ trợ cho điều kiện
WHERE, dẫn đến việc quét thừa một lượng dữ liệu khổng lồ.
Hỏi (MongoDB): Mức độ cấu hình (Profiling Level) nào sẽ ra lệnh cho MongoDB ghi lại toàn bộ TẤT CẢ các thao tác (kể cả nhanh lẫn chậm) vào collection
system.profile?Đáp: Profiling Level 2 (Level 0 là tắt, Level 1 là chỉ ghi các lệnh chậm hơn ngưỡng
slowms).
5. Bài tập thực hành (Cấu hình Giám sát Truy vấn Chậm)
Đề bài tình huống: Hệ thống dạo này thỉnh thoảng xuất hiện hiện tượng "nghẽn cổ chai" vài giây rồi tự hết. Giám đốc yêu cầu anh phải cấu hình hệ thống tự động ghi lại các câu lệnh chạy chậm hơn 1 giây (1000ms) để ngày mai có dữ liệu phân tích.
Hãy viết lệnh/cấu hình kích hoạt tính năng "Slow Query Log" hoặc Profiler cho 5 hệ thống.
Đáp án:
1. Oracle: (Cấu hình tự động theo dõi các session chạy quá lâu qua Resource Manager hoặc theo dõi cấp độ Session)
-- Kích hoạt SQL Trace cho các câu lệnh lâu (Yêu cầu thiết lập ngưỡng)
ALTER SYSTEM SET statistics_level = ALL SCOPE=BOTH;
-- Oracle tự động thu thập vào AWR, anh có thể dùng ADDM để báo cáo các truy vấn tốn I/O ngày hôm sau.
2. SQL Server: (Cấu hình Extended Events để bắt truy vấn chậm)
CREATE EVENT SESSION [Capture_Slow_Queries] ON SERVER
ADD EVENT sqlserver.sql_statement_completed(
ACTION(sqlserver.client_hostname,sqlserver.database_name,sqlserver.sql_text)
WHERE ([duration]>(1000000))) -- Đơn vị tính là micro-giây (1 triệu = 1 giây)
ADD TARGET package0.event_file(SET filename=N'C:\SQL_Logs\SlowQueries.xel');
ALTER EVENT SESSION [Capture_Slow_Queries] ON SERVER STATE = START;
3. PostgreSQL: (Cấu hình ghi log câu lệnh chậm thẳng ra file log OS)
ALTER SYSTEM SET log_min_duration_statement = 1000; -- Tính bằng mili-giây
SELECT pg_reload_conf();
4. MySQL / MariaDB: (Bật Slow Query Log)
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1; -- Tính bằng giây
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow-query.log';
5. MongoDB: (Bật Profiler cấp độ 1, ngưỡng 1000ms cho Database hiện tại)
use app_db;
db.setProfilingLevel(1, { slowms: 1000 });
// Kiểm tra lại cấu hình: db.getProfilingStatus()
Phát hiện được truy vấn chậm mới chỉ là bước chẩn đoán bệnh. Chữa bệnh dứt điểm đòi hỏi kỹ thuật mổ xẻ "Execution Plan" (Kế hoạch thực thi).
Ở bài tiếp theo, Module 19: Quản lý hiệu năng CSDL: Tuning SQL, chúng ta sẽ so sánh cách đọc Plan của Oracle (EXPLAIN PLAN) với các hệ thống khác để xem bộ não của chúng quyết định chọn đường đi (Index Seek, Hash Join, Nested Loop...) như thế nào
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
