Runbook xử lý PostgreSQL chậm trong production

Dưới đây là runbook xử lý PostgreSQL chậm trong production theo hướng DBA vận hành thực chiến: ưu tiên an toàn dữ liệu, giảm tác động dịch vụ, khoanh vùng theo bằng chứng, rồi mới can thiệp. Tôi bám theo checklist vận hành nội bộ về kiểm tra disk/log/replication, các truy vấn giám sát active query và blocking, cùng case thực tế nội bộ nơi long running transaction làm autovacuum kém hiệu quả, dead tuple tăng, table phình to và query chậm.

1) Mục tiêu

Xử lý tình trạng PostgreSQL chậm mà vẫn giữ an toàn production:

• Không vội restart khi chưa rõ nguyên nhân

• Không VACUUM FULL / REINDEX thường trực giữa giờ cao điểm

• Không reset statistics bừa bãi

• Luôn kiểm tra replication/backup trước các thao tác rủi ro

Tài liệu nội bộ cũng đang yêu cầu theo dõi đầu/cuối ngày các hạng mục tối thiểu: disk usage, alert log, trạng thái service, replication. Khi có trạng thái bất thường phải đọc log, phân tích nguyên nhân rồi kiểm tra lại sau xử lý.

---

RUNBOOK

2) Triệu chứng kích hoạt runbook

Kích hoạt runbook khi có một hoặc nhiều dấu hiệu:

• Ứng dụng timeout, API response tăng cao

• Active session tăng bất thường

• Nhiều query chạy lâu

• CPU/IO tăng đột ngột

• Replication lag tăng

• Disk usage tăng nhanh

• Log xuất hiện nhiều slow query / lock wait / checkpoint / temp file

Trong tài liệu vận hành nội bộ, checklist tháng cũng theo dõi CPU, RAM, disk, active session, DB size, parameter, blocking session; ngoài ra có hướng dẫn lấy report các câu lệnh chiếm tải bằng pg_profile và top query qua pg_stat_statements.

---

3) Giả định

• Có quyền đăng nhập OS user postgres

• Có quyền xem pg_stat_activity, pg_locks, pg_stat_replication

• Tốt nhất có pg_read_all_stats hoặc superuser

• Nếu có HA primary/standby thì mọi thao tác write/maintenance phải cân nhắc replication lag

• Phiên bản có thể từ 11 đến 16/17/18; tôi sẽ chỉ rõ điểm khác khi cần

---

4) Bước 0 – Giữ an toàn trước khi xử lý

4.1. Xác nhận phạm vi sự cố

• Chậm toàn hệ thống hay 1 database/schema?

• Chậm read, write, hay cả hai?

• Chỉ primary chậm hay standby cũng lag?

• Có thay đổi gần đây: deploy app, batch, vacuum thủ công, reindex, DDL, patch?

4.2. Không làm ngay

• Không restart DB chỉ vì “đang chậm”

• Không chạy VACUUM FULL

• Không REINDEX thường giữa giờ cao điểm

• Không pg_stat_reset() để “làm sạch số liệu”

Lý do: pg_stat_reset() làm reset cả các counter mà autovacuum dùng để quyết định vacuum/analyze; tài liệu PostgreSQL cảnh báo việc này có thể làm autovacuum bỏ lỡ công việc cần thiết, gây bloat hoặc statistics lỗi thời.

4.3. Nếu có HA

Kiểm tra ngay replication trước khi làm gì mạnh tay:

-- Primary
select * from pg_stat_replication;

-- Nếu có replication slot
select * from pg_replication_slots;

-- Standby
select * from pg_stat_wal_receiver;

Tài liệu nội bộ cũng dùng đúng các truy vấn này để kiểm tra đồng bộ, cộng thêm truy vấn đo lag bằng LSN.

---

5) Bước 1 – Chụp nhanh hiện trạng trong 5 phút đầu

5.1. Kiểm tra OS

date
hostname
uptime
df -h
free -g
vmstat 1 5
iostat -xz 1 5
top -H -b -n 1 | head -50

Tài liệu vận hành nội bộ quy định check disk định kỳ; ngưỡng cảnh báo thường là 85% warning, 95% critical. Nếu disk đầy nhanh phải coi đó là ưu tiên cao vì có thể kéo theo WAL, temp file, archive backlog và checkpoint pressure.

5.2. Kiểm tra log PostgreSQL

su - postgres
cd $PGLOG
ls -ltr
tail -n 200 $PGLOG/postgresql_*.log
tail -n 200 $PGLOG/logfile_start

Checklist nội bộ cũng yêu cầu khi có bất thường thì đọc ngay log PostgreSQL để phân tích nguyên nhân trước khi xử lý tiếp.

5.3. Kiểm tra service

pg_ctl -D $PGDATA status

---

6) Bước 2 – Xác định chậm do đâu: lock, query xấu, autovacuum/bloat, IO, connection pressure hay replication

6.1. Active session / long running query

SELECT
    now(),
    pid,
    usename,
    datname,
    application_name,
    client_addr,
    state,
    wait_event_type,
    wait_event,
    backend_start,
    xact_start,
    query_start,
    age(now(), xact_start)  AS xact_age,
    age(now(), query_start) AS query_age,
    backend_xid,
    backend_xmin,
    left(query, 1000) AS query
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
ORDER BY query_start NULLS LAST;

Để nhìn nhanh active query lặp lại trong checklist tháng, tài liệu nội bộ dùng:

SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;

và đặt KPI active session cho từng DB.

Nhận định

• wait_event_type='Lock': nghi lock chain

• state='active' + query_age rất lớn: query chạy lâu thực sự

• state='idle in transaction': cực nguy hiểm, dễ giữ snapshot, cản autovacuum

• backend_xmin/backend_xid già: nghi long running transaction

Tài liệu nội bộ có case thực tế xác nhận 1 transaction ứng dụng không kết thúc → long running transaction → autovacuum kém hiệu quả → table size tăng → response chậm.

---

6.2. Tìm blocking / blocked session

WITH RECURSIVE locktree AS (
    SELECT
        a.pid,
        a.usename,
        a.datname,
        a.application_name,
        a.client_addr,
        a.state,
        a.wait_event_type,
        a.wait_event,
        a.xact_start,
        a.query_start,
        pg_blocking_pids(a.pid) AS blockers,
        left(a.query, 500) AS query
    FROM pg_stat_activity a
    WHERE a.pid <> pg_backend_pid()
),
t AS (
    SELECT *, 1 AS lvl
    FROM locktree
    WHERE array_length(blockers, 1) > 0
    UNION ALL
    SELECT l.*, t.lvl + 1
    FROM locktree l
    JOIN t ON l.pid = ANY(t.blockers)
)
SELECT * FROM t
ORDER BY lvl, query_start;

Nếu cần xem blocker gốc:

SELECT
    a.pid AS blocked_pid,
    a.usename AS blocked_user,
    ka.pid AS blocking_pid,
    ka.usename AS blocking_user,
    age(now(), a.query_start) AS blocked_for,
    age(now(), ka.query_start) AS blocking_for,
    left(a.query, 300) AS blocked_query,
    left(ka.query, 300) AS blocking_query
FROM pg_stat_activity a
JOIN pg_stat_activity ka
  ON ka.pid = ANY(pg_blocking_pids(a.pid))
ORDER BY blocked_for DESC;

Hành động nhanh

• Làm việc với team app trước nếu blocker là batch/job hợp lệ

• Ưu tiên pg_cancel_backend(pid) cho query đang chạy

• Chỉ dùng pg_terminate_backend(pid) khi xác định rõ transaction gây nghẽn và chấp nhận rollback của session đó

Tài liệu nội bộ cũng hướng dẫn kiểm tra long running transaction rồi có thể terminate theo PID sau khi phối hợp team ứng dụng.

---

6.3. Tìm long running transaction đang chặn autovacuum

SELECT
    pid,
    datname,
    usename,
    application_name,
    client_addr,
    state,
    xact_start,
    age(now(), xact_start) AS xact_age,
    backend_xmin,
    backend_xid,
    left(query, 500) AS query
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL
   OR backend_xid   IS NOT NULL
ORDER BY greatest(age(backend_xmin), age(backend_xid)) DESC NULLS LAST;

Tài liệu vận hành nội bộ dùng gần như đúng truy vấn này để phát hiện long running transaction khi dead tuple tăng vượt KPI; sau đó mới cân nhắc terminate và vacuum tay ở giờ thấp điểm.

Quyết định

• Nếu query business hợp lệ nhưng chạy quá lâu: đánh giá giảm tải app trước

• Nếu là idle in transaction: ưu tiên xử lý

• Nếu có nhiều table bloat/dead tuple cao: đây thường là root cause hơn là triệu chứng

---

6.4. Kiểm tra dead tuple / autovacuum / bloat

SELECT
    schemaname,
    relname,
    n_live_tup,
    n_dead_tup,
    round(100.0 * n_dead_tup / nullif(n_live_tup,0), 2) AS dead_pct,
    last_vacuum,
    last_autovacuum,
    last_analyze,
    last_autoanalyze,
    vacuum_count,
    autovacuum_count,
    analyze_count,
    autoanalyze_count
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 50;

Theo tài liệu nội bộ, cần giám sát live_tuple và dead_tuple; khi vượt KPI phải kiểm tra long running transaction. Có hướng dẫn KPI dead/live tùy bảng và chỉ cân nhắc vacuum tay khi thực sự cần, tốt nhất vào giờ thấp điểm.

Hành động

• Nếu dead tuple tăng nhưng không có long transaction: xem autovacuum có đủ tài nguyên không

• Nếu dead tuple tăng mạnh + long transaction tồn tại: xử lý transaction trước, không vacuum trước

• Nếu bảng phình bất thường: cân nhắc vacuum, reindex, hoặc xử lý dữ liệu theo partition/window

Tài liệu case nội bộ đã ghi rõ nhiều sự cố do autovacuum không hiệu quả trên bảng lớn, đặc biệt sau thay đổi ứng dụng.

---

6.5. Tìm câu lệnh chiếm tải bằng pg_stat_statements

Điều kiện

• PostgreSQL 11+: cần shared_preload_libraries='pg_stat_statements' và CREATE EXTENSION pg_stat_statements

• Chỉ superuser hoặc role có pg_read_all_stats mới thấy đầy đủ query và queryid

Điều này được nêu rõ trong tài liệu PostgreSQL 11/12/13/16/17.

Top query theo tổng thời gian

PG11/12:

SELECT
    query,
    calls,
    total_time,
    total_time / calls AS time_per,
    stddev_time,
    rows,
    rows / calls AS rows_per,
    100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent,
    blk_read_time,
    blk_write_time,
    temp_blks_read,
    temp_blks_written
FROM pg_stat_statements
WHERE query NOT SIMILAR TO '%pg_%'
ORDER BY total_time DESC
LIMIT 20;

PG13+ đổi cột total_time thành total_exec_time:

SELECT
    query,
    calls,
    total_exec_time,
    total_exec_time / calls AS time_per,
    stddev_exec_time,
    rows,
    rows / calls AS rows_per,
    100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent,
    blk_read_time,
    blk_write_time,
    temp_blks_read,
    temp_blks_written,
    wal_bytes
FROM pg_stat_statements
WHERE query NOT SIMILAR TO '%pg_%'
ORDER BY total_exec_time DESC
LIMIT 20;

Tài liệu nội bộ cũng dùng truy vấn tương tự để lọc top query theo calls, time_per, rows_per, và theo dõi hit_percent; còn tài liệu PostgreSQL 13+ cho thấy thêm các cột như total_exec_time, wal_bytes.

Cách đọc

• hit_percent thấp: nghi đọc đĩa nhiều

• temp_blks_written cao: sort/hash spill do work_mem hoặc query xấu

• blk_read_time cao: IO chậm

• wal_bytes cao: query write nặng, nhiều WAL

• calls cao + time_per thấp nhưng tổng lớn: hot path cần tối ưu app

• time_per cao: ít query nhưng rất chậm, ưu tiên EXPLAIN (ANALYZE, BUFFERS)

---

6.6. Kiểm tra replication lag và tác động HA

SELECT
  pid,
  application_name,
  pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn)   AS sending_lag,
  pg_wal_lsn_diff(sent_lsn, flush_lsn)              AS receiving_lag,
  pg_wal_lsn_diff(flush_lsn, replay_lsn)            AS replaying_lag,
  pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS total_lag
FROM pg_stat_replication;

Tài liệu nội bộ khuyến nghị đúng truy vấn này.

Vì sao phải check?

• Nếu đang chậm do write storm/checkpoint/WAL, standby sẽ lag

• Nếu định terminate nhiều session hoặc chạy vacuum/reindex, cần biết RPO/RTO và lag hiện tại

• Với hot standby, nhiều lệnh maintenance như VACUUM, REINDEX, ANALYZE, CREATE INDEX không chạy trên standby recovery; phải thực hiện ở primary.

---

7) Bước 3 – Khắc phục nhanh theo từng nhánh nguyên nhân

Nhánh A – Lock / blocking chain

Dấu hiệu

• wait_event_type='Lock'

• Nhiều session blocked bởi 1 blocker

Xử lý

1. Xác định blocker gốc

2. Xác minh đó là session app hay maintenance

3. pg_cancel_backend(blocker_pid) trước nếu phù hợp

4. Không được thì pg_terminate_backend(blocker_pid) sau khi chấp nhận rollback

Rủi ro

• Rollback transaction lớn có thể còn tốn thời gian

• App có thể reconnect và tái diễn nếu chưa chặn nguồn

Rollback

• Không có rollback thật sự; đây là hành động cắt session

• Phải song song làm với app team để chặn job/query gây lock

---

Nhánh B – Long running transaction / idle in transaction

Dấu hiệu

• xact_age lớn

• backend_xmin già

• n_dead_tup tăng, autovacuum không theo kịp

Xử lý

1. Xác định session nguồn: app, batch, report

2. Chặn nguồn phát sinh ở app/job scheduler nếu cần

3. pg_terminate_backend(pid) với session treo

4. Sau khi dọn blocker, chạy:

VACUUM (VERBOSE, ANALYZE) schema.table_name;

chỉ với bảng bị ảnh hưởng nặng, ở giờ thấp điểm

Tài liệu nội bộ ghi nhận root cause điển hình là long running transaction làm autovacuum không hiệu quả, và khuyến nghị giám sát table size/dead tuple thường xuyên.

Rủi ro

• Terminate làm rollback giao dịch

• Vacuum tay trên bảng lớn tạo thêm IO

Rollback

• Không có rollback cho terminate; phải dựa trên app retry/cơ chế nghiệp vụ

---

Nhánh C – Query xấu / full scan / spill temp

Dấu hiệu

• Top query trong pg_stat_statements

• temp_blks_written cao

• blk_read_time cao

• Explain có Seq Scan/HashAgg/Sort lớn

Xử lý ưu tiên

1. Lấy SQL top offender

2. Chạy EXPLAIN (ANALYZE, BUFFERS, VERBOSE) trên môi trường an toàn hoặc giờ thấp điểm

3. Tối ưu theo thứ tự:

   • sửa predicate/join

   • thêm/sửa index

   • cập nhật statistics

   • xem lại partition pruning

   • cuối cùng mới chỉnh parameter

Tài liệu nội bộ cũng ghi rõ: nếu còn full scan thì tiếp tục làm việc với team ứng dụng để tối ưu SQL query.

---

Nhánh D – Bloat / index fragmentation

Dấu hiệu

• Table/index size tăng bất thường

• Dead tuple cao kéo dài

• Query kế hoạch xấu dần

Xử lý

1. Xử lý long transaction trước

2. VACUUM (ANALYZE) theo bảng

3. Nếu index nghi hỏng hiệu quả: cân nhắc REINDEX CONCURRENTLY

REINDEX INDEX CONCURRENTLY schema.index_name;
-- hoặc
REINDEX TABLE CONCURRENTLY schema.table_name;

Tài liệu PostgreSQL 12 nêu rõ REINDEX CONCURRENTLY phù hợp production hơn vì giảm chặn writes, nhưng tốn thời gian và tài nguyên hơn; reindex thường sẽ block writes lên bảng trong lúc build.

Rủi ro

• REINDEX CONCURRENTLY lâu, tạo thêm IO/CPU

• Không chạy được kiểu “concurrently” cho mọi trường hợp partition như reindex từng partition là an toàn hơn

Khuyến nghị production

• Reindex từng index/partition

• Làm theo maintenance window

• Theo dõi replication lag trong suốt quá trình

---

Nhánh E – Connection pressure / app storm

Dấu hiệu

• Active session tăng vọt

• Nhiều query giống nhau, thời gian ngắn nhưng tổng tải lớn

• CPU tăng nhưng không có 1 query đơn lẻ quá nặng

Xử lý

1. Xác minh pool app có lỗi hay không

2. Tạm thời giảm traffic/job nếu có thể

3. Ưu tiên triage theo query hot path trong pg_stat_statements

4. Chỉ cân nhắc tăng max_connections nếu đã xác minh app/pool thực sự cần; không tăng để “chữa cháy” mù quáng

---

Nhánh F – Disk / WAL / archive / checkpoint pressure

Dấu hiệu

• df -h cao

• WAL/archive tăng nhanh

• Replication slot giữ WAL

• Log có checkpoint too frequent, temp file lớn

Xử lý

1. Kiểm tra disk usage

2. Kiểm tra replication slot / standby lag

3. Không xóa WAL thủ công khi chưa hiểu luồng archive/replication

Tài liệu nội bộ cũng cảnh báo rõ: dọn WAL sai bằng pg_archivecleanup có thể làm hỏng cluster hoặc GoldenGate; phải monitor disk usage hằng ngày và cảnh báo tăng đột ngột.

---

8) Khi nào được restart PostgreSQL?

Chỉ cân nhắc restart khi:

• Đã xác định rõ nguyên nhân liên quan memory/session leak/backend treo

• Đã cô lập nguồn gây lỗi

• Có HA hoặc maintenance window phù hợp

• Đã kiểm tra replication/backups/rollback plan

Tài liệu nội bộ có SOP khởi động lại/tắt service bằng pg_ctl, nhưng đó là thao tác vận hành có kiểm soát, không phải default action cho mọi case chậm.

Lệnh

pg_ctl -D $PGDATA stop -mf
pg_ctl -D $PGDATA start
pg_ctl -D $PGDATA status

Rủi ro

• Downtime

• Session rollback

• Recovery/replay tăng nếu hệ thống write lớn

• Có thể che mất nguyên nhân gốc

---

9) Truy vấn “gói cứu hỏa” nên có sẵn

9.1 Active/blocked

SELECT pid, usename, datname, state, wait_event_type, wait_event,
       age(now(), xact_start) AS xact_age,
       age(now(), query_start) AS query_age,
       left(query, 300) AS query
FROM pg_stat_activity
WHERE pid <> pg_backend_pid()
ORDER BY query_start NULLS LAST;

9.2 Long transaction

SELECT pid, datname, usename, state, backend_xmin, backend_xid,
       age(now(), xact_start) AS xact_age,
       left(query, 300) AS query
FROM pg_stat_activity
WHERE backend_xmin IS NOT NULL OR backend_xid IS NOT NULL
ORDER BY greatest(age(backend_xmin), age(backend_xid)) DESC;

9.3 Dead tuple cao

SELECT schemaname, relname, n_live_tup, n_dead_tup,
       round(100.0*n_dead_tup/nullif(n_live_tup,0),2) AS dead_pct,
       last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 30;

9.4 Top query chiếm tải

-- PG13+
SELECT query, calls, total_exec_time,
       round(total_exec_time/calls,2) AS avg_ms,
       rows,
       temp_blks_written,
       blk_read_time,
       blk_write_time,
       wal_bytes
FROM pg_stat_statements
WHERE query NOT SIMILAR TO '%pg_%'
ORDER BY total_exec_time DESC
LIMIT 20;

9.5 Replication lag

SELECT pid, application_name,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS total_lag
FROM pg_stat_replication;

---

10) Hậu kiểm sau xử lý

Phải xác minh lại bằng số liệu, không kết luận theo cảm giác.

Kiểm tra bắt buộc

• Active session giảm chưa

• Query top offender giảm total_exec_time/time_per chưa

• Blocking chain hết chưa

• Dead tuple có ngừng tăng chưa

• Replication lag về bình thường chưa

• Disk/WAL về ngưỡng an toàn chưa

• Ứng dụng hết timeout chưa

Ghi nhận

• Thời điểm bắt đầu/kết thúc

• Root cause

• SQL/PID bị xử lý

• Có terminate session nào không

• Có vacuum/reindex không

• Tác động tới RPO/RTO

• Kế hoạch phòng ngừa

Checklist nội bộ cũng yêu cầu ghi nhận nếu phát hiện bất thường/sự cố để phục vụ vận hành tiếp theo.

---

11) Khuyến nghị production lâu dài

1. Bật và dùng pg_stat_statements chuẩn chỉnh
   PostgreSQL 11+ yêu cầu shared_preload_libraries và extension theo DB; quyền xem đủ SQL text/queryid cần superuser hoặc pg_read_all_stats.

2. Giám sát dead tuple, long transaction, active session, replication lag theo ngưỡng
   Đây là bài học rút ra trực tiếp từ case nội bộ.

3. Không dùng pg_stat_reset() bừa bãi
   Vì có thể ảnh hưởng logic kích hoạt autovacuum.

4. Bảo trì định kỳ index/bảng lớn có churn cao
   Nhưng dùng REINDEX CONCURRENTLY hoặc theo partition/window; tránh giờ cao điểm.

5. Có report định kỳ top SQL
   Tài liệu nội bộ còn dùng pg_profile để lấy sample/report khi cao tải.

---

12) Mẫu quyết định nhanh theo thực chiến

• Nếu lock chain → tìm blocker gốc → cancel/terminate có kiểm soát

• Nếu long transaction + dead tuple cao → xử lý transaction trước → vacuum/analyze bảng bị ảnh hưởng

• Nếu top query chiếm tải → lấy từ pg_stat_statements → explain → sửa SQL/index

• Nếu disk/WAL tăng nhanh → check replication slot/lag/archive → không xóa WAL mù quáng

• Nếu chưa rõ nguyên nhân → giữ nguyên DB, tiếp tục chụp số liệu, không restart vội

=============================
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