Trần Văn Bình - Chuyên gia Oracle

101_24/02/2026

🐘 [THỰC CHIẾN] Khi PostgreSQL chậm dần – Và hóa ra "thủ phạm" không phải query, mà là connections!

Chắc hẳn bạn đã từng gặp tình huống này:
- Lúc đầu, mọi thứ chạy rất ngon lành.
- Sau vài tháng, latency bắt đầu tăng, CPU database cao dù không có query nào quá nặng.
- Thỉnh thoảng, bạn nhận được lỗi too many connections.
- Phản xạ thường thấy của team là: tối ưu query, thêm index, scale database.
- Nhưng có một khả năng rất hay bị bỏ qua:
👉 Bạn đang mở quá nhiều connection tới PostgreSQL. Và lúc đó, một công cụ tên PgBouncer trở nên thực sự có ý nghĩa.

1️⃣ Vấn đề gốc: PostgreSQL không được thiết kế cho hàng nghìn connection
Khác với nhiều hệ thống khác, PostgreSQL:
- Mỗi connection = một process riêng.
- Mỗi process tiêu tốn RAM đáng kể.
- Nhiều connection → context switching tăng mạnh.

Hệ quả: Query nhẹ vẫn chậm, vì bottleneck không nằm ở query, mà ở số lượng connection.

📌 Ví dụ thực tế:
- 5 service, mỗi service mở 100 connection → 500 connection tới DB.
- Scale lên 10 service → 1000 connection.
👉 PostgreSQL bắt đầu “đuối”.

2️⃣ PgBouncer là gì?
- PgBouncer là một connection pooler đứng giữa ứng dụng và PostgreSQL.
- Thay vì:
App → PostgreSQL
- Bạn sẽ có:
App → PgBouncer → PostgreSQL

🔧 Điều PgBouncer thực sự làm
- Nhận hàng trăm/hàng nghìn connection từ ứng dụng.
- Nhưng chỉ giữ một số lượng nhỏ connection thật tới database.
- Phân phối lại connection này cho các request.

📊 Minh họa đơn giản:
- 1000 client connections → PgBouncer → 50 connections thực tới PostgreSQL

3️⃣ Tại sao điều này lại quan trọng?
✅ Giảm chi phí tạo connection – TCP handshake, authentication, tạo process backend… đều được tái sử dụng.

✅ Ổn định hệ thống khi traffic tăng – Khi có spike, không tạo thêm hàng trăm connection, chỉ reuse pool sẵn có, tránh "shock" cho DB.

✅ Tăng throughput thực tế – Ít connection = ít context switching + ít memory usage + scheduler hiệu quả hơn.

4️⃣ Các mode pooling – Bạn cần hiểu rõ
PgBouncer có 3 mode:
- Session pooling – 1 client giữ 1 connection suốt session. Gần như không khác gì không dùng PgBouncer.

- Transaction pooling (phổ biến nhất) – 1 transaction = 1 connection. Sau commit, connection được trả lại pool. Hiệu quả cao nhất trong đa số hệ thống backend.

- Statement pooling – 1 query = 1 connection. Cực nhanh nhưng không dùng được transaction phức tạp.

5️⃣ Flow thực tế trong production
- Không dùng PgBouncer: App → PostgreSQL (1000 connections)

- Dùng PgBouncer: App → PgBouncer → PostgreSQL (50–100 connections)

6️⃣ Cấu hình cơ bản (pgbouncer.ini)

[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0

pool_mode = transaction

max_client_conn = 1000
default_pool_size = 50

📌 Sau đó, app chỉ cần đổi port kết nối sang PgBouncer (6432). Xong!

7️⃣ Những thứ cần lưu ý (rất quan trọng)
⚠️ Transaction pooling không giữ state – Ví dụ SET search_path ... sẽ không được bảo toàn giữa các transaction.

⚠️ Prepared statement – Một số driver (như Go) dùng prepared statement mặc định, có thể không tương thích tốt → cần config lại nếu gặp lỗi.

⚠️ Long transaction – Giữ connection lâu sẽ làm giảm hiệu quả của pool.

8️⃣ Khi nào nên dùng PgBouncer?
✅ Nên dùng khi:
- Hệ thống có nhiều service.
- Concurrency cao.
- Bắt đầu thấy DB bị nghẽn connection.
- CPU DB cao nhưng query không nặng.

❌ Không cần thiết khi:
- Hệ thống nhỏ.
- Traffic thấp.
- Số connection ít.

9️⃣ Tổng kết
- PgBouncer không phải là tool để “tăng tốc query”.
- Nó giải quyết một vấn đề khác: quá nhiều connection → làm nghẽn database.

🔑 Takeaway:
- Khi hệ thống bắt đầu chậm, đừng chỉ nhìn vào query.
Hãy nhìn vào số lượng connection.

- Rất nhiều hệ thống không cần scale database ngay lập tức –
chỉ cần quản lý connection tốt hơn là đủ.

KHAI GIẢNG KHÓA HỌC OAZ29, NGÀY 22/04/2026

Chào mừng tất cả anh/em đến với khoá học Oracle DBA A-Z Enterprise K29 (OAZ29), với 100% học viên hài lòng về kết quả sau hóa học, CHẮC CHẮN anh/em sẽ có những TRẢI NGHIỆM tuyệt vời từ khoá học này, sẽ rút ngắn thời gian 3-5 năm, cũng như tiết kiệm được rất nhiều $$$. Khóa học OAZ dùng nền tảng Zoom đã đào tạo được nhiều học viên nước ngoài (từ Mỹ, Nhật, Hàn Quốc, Đức, Campuchia, Lào…), với mong muốn những tri thức, kinh nghiệm DBA sẽ lan tỏa rộng hơn, giúp ích cho nhiều anh/em DBA trên toàn cầu vì "Việt Nam Hùng Cường".

Các mục tiêu anh/em sẽ đạt được từ khóa học:

1. Quản trị được MỌI cơ sở dữ liệu Oracle lớn, nhỏ theo đúng quy trình chuẩn đảm bảo an toàn tuyệt đối, hiệu năng cao, hoạt động 24/7. Từ đó có tư duy/quy trình vận hành các cơ sở dữ liệu khác: MS Server, MySQL, PosgreSQL,...

2. Tự động hóa quá trình quản trị cơ sở dữ liệu giúp giảm công sức, nguồn lực cho các doanh nghiệp.

3. Thiết kế, cài đặt các cơ sở dữ liệu chuẩn, tối ưu, bảo mật.

4. Chuyển đổi (migration) dữ liệu giữa các nền tảng (điều mà bên B sẽ không muốn cho bạn biết, những anh em nào làm bên B thông cảm giúp).

5. Cài đặt, Quản trị được Oracle RAC, DataGuard, GoldenGate

6. Backup đảm bảo an toàn tuyệt đối, 100% Recovery thành công

7. Kiến thúc SQL, PL/SQL giúp viết job tự động hóa vận hành

8. Kiến thức Unix, Linux,....

9. Sẵn sàng thi đỗ chứng chỉ OCP 2019

10. Khỏe mạnh, kỷ luật bản thân và có tư duy tích cực để tự đứng vững trong cuộc sống cũng như giải quyết được các vấn đề khó trong cuộc sống.

Voucher OraAZ01102025 giảm giá 10% khóa học nếu anh em chia sẻ bài viết này tại 3 group IT và inbox vào zalo 090/29/12/888

Những anh/em nào chưa kịp đăng ký có thể đăng ký trong tuần này, chậm nhất 26/04/2026 hoặc khoá sau OAZ30 vào 01/07/2026
Chi tiết khoá học: https://www.tranvanbinh.vn/2020/06/khai-giang-khoa-hoc-oracle-dba-z.html

TẠM BIỆT OAZ28: 01/12/2025 - 17/04/2026

Hơn 3 tháng không phải là dài nhưng ĐỦ để chúng ta cùng nhau đi hết chặng đường với khối lượng kiến thức đồ sộ của nghề DBA, rất nhiều, rất nhiều kiến thức, quy trình, bí kíp được truyền cho mọi người, có thể làm mọi người "HOẢNG", thầy gửi lại 1 số keyword cho mọi người dễ nhớ:

- Tài nguyên: Gửi trong nhóm kín, tất cả những bí kíp, thủ tục, quy trình cần để quản trị MỌI Database Oracle, SQL Server, MySQL/MariaDB, PostgreSQL, đồng bộ DataGuard, GoldenGate, SQL, PL/SQL, Linux/Unix

- Tài nguyên trên trang tranvanbinh.vn, search google bằng tranvanbinh.vn, các bí kíp sẽ bị khóa dần cho đến hết năm 2023, do đó cần down về sớm.

- Hiểu rõ để Quy hoạch tablespace CHUẨN để có thể lưu trữ DB "khủng" 100TB-1000TB

- Shutdown immediate nhé, nếu DB "khủng" sẽ 1-2 tiếng mới close được thì cần kết hợp shutdown abort

- Partition, index bảng --> nếu tạo nhầm thì chuyển non-partition hoặc chuyển ngược lại, bí kíp của các DB 1.000TB

- Resumable để ứng dụng không bị dừng ngay lập tức khi tablespace đầy

- Compress giúp giảm dung lượng 3-10 lần, thường nén cho DWH, bảng lớn

- Undo Retention 12h - 24h để lấy lại dữ liệu đã commit nhầm của nghiệp vụ hoặc các thủ tục, package nhỡ tay cập nhật mà không backup

- Redo log group >=3, mỗi group >=2, switch log 3-6 lần/giờ

- Control file >=2

- Quản lý giao dịch đồng thời: Lock, deadlock

- User, tối thiểu hóa quyền, thu hồi quyền tự động trong 12c/19c

- Audit: Audit DB, FGA, Trigger, Firewall, DDL Audit (chuyên dụng với Imperva, Oracle Database Firewall & Audit Vault)

- Các nguy cơ lỗi DB tiềm ẩn rất nhiều (do câu lệnh SQL, do người dùng, do kết nối, do instance, do storage,...)

- BACKUP & RECOVERY rất quan trọng, luôn tư duy mất DB hiện tại thì khôi phục như thế nào nhanh nhất

- Flashback lại dữ liệu đã commit, lấy lại bảng drop, hay lấy lại toàn bộ DB

- SQL Tunning, "nhắm mắt" tunning với tool SQL Tunning Advisor

- SQL Access Advisor hỗ trợ khi viết lại câu SQL

- SQL Performance Analyer: Dễ dàng giả lập tải trên DB Test

- Resource Manager: Để giới hạn parallel, active session, CPU, undo, temp,...

- Tự động hóa với Job/Scheduler job (add datafile, add partition, drop partition, cảnh báo, báo cáo... Tự động) và dọn dẹp tự động mức OS với crontab, với hơn 50 job tự động thông dụng nhất của DBA

- SQL

- PL/SQL

- Instance Tunning

- Oracle RAC, ASM

- DataGuard

- GoldenGate

- Bí kíp ôn thi và pass OCP 2019

- Các Tool chuyên dụng: SQL*Plus, TOAD, SQL Navagator, SQL Developer, PL/SQL Developer, Putty, MobaXterm, Xshell, SecureCRT,...

- Các thủ tục, script trong mỗi nội dung trên đã được cấp đầy đủ

- Các quy trình vận hành step by step, quy trình bảo trì step by step của các DB Oracle, SQL Server, MySQL, PosgreSQL, DataGuard, GoldenGate

- Quản trị Linux, Solaris, AIX dễ dàng

- Các bài học cuộc sống, rèn luyện THÂN - TÂM - TUỆ, liên tục tiến lên mỗi ngày góp công sức vào KỶ NGUYÊN VƯƠN MÌNH CỦA VIỆT NAM.
....

Một lời khuyên duy nhất của thầy là HỌC NHIỀU, LÀM NHIỀU, CẢI TIẾN LIÊN TỤC MỖI NGÀY, giữ ĐẠO ĐỨC với nghề DBA, khi có bất kỳ vấn đề gì khó khăn thầy sẽ hỗ trợ nhé.

Chúc các anh/em nhiều sức khỏe, hạnh phúc và thành công.

Chi tiết khóa học : https://www.tranvanbinh.vn/2020/06/khai-giang-khoa-hoc-oracle-dba-z.html

🚀🚀🚀 KHÓA HỌC ONLINE COACHING "ORACLE DBA A-Z ENTERPRISE" (DBA_AZ), HOTLINE 090.29.12.888 🚀🚀🚀 DBA, Oracle DBA A-Z, Online Coaching DBA

🛡️ CÁC BƯỚC XÁC THỰC THUÊ BAO TRÊN MYMOBIFONE 🛡️

✨Từ ngày 15/4/2026, việc xác thực thông tin thuê bao sẽ được tăng cường nhằm bảo vệ quyền lợi người dùng và chuẩn hóa dữ liệu thuê bao trên toàn hệ thống.

✨MobiFone đã tích hợp tính năng xác thực thuê bao trực tiếp trên ứng dụng MyMobiFone, giúp khách hàng xác thực nhanh chóng và thuận tiện mà không cần đến điểm giao dịch.

✨Tải ứng dụng MyMobiFone tại mbf.vn/appdl và thực hiện các bước dưới đây để xác thực thông tin kịp thời và sử dụng dịch vụ ổn định cùng MobiFone.

🏗️ MONOLITHIC vs MICROSERVICES vs SERVERLESS – KIẾN TRÚC NÀO "CHẤT" CHO DỰ ÁN CỦA BẠN?

Bạn đang phân vân không biết nên xây dựng hệ thống theo kiểu nguyên khối (Monolithic), chia nhỏ (Microservices), hay không cần quản lý server (Serverless)? Nhìn sơ đồ này là thấy ngay điểm khác biệt cốt lõi! 👇

1️⃣ MONOLITHIC – "MỘT KHỐI" DUY NHẤT.
Client → SINGLE APPLICATION (Product + Cart + Order) → Shared Database

📌 Đặc điểm chính:
- Một codebase duy nhất, deploy và scale như một khối.
- Các module (Product, Cart, Order) dùng chung database.
- Thay đổi nhỏ cũng phải redeploy toàn bộ.

✅ Ưu: Đơn giản, dễ triển khai lúc đầu, phù hợp MVP.
❌ Nhược: Khó mở rộng, lỗi một module có thể ảnh hưởng toàn hệ thống.

Ví dụ: Một ứng dụng web nhỏ thời đầu của Shopee.

2️⃣ MICROSERVICES – "CHIA NHỎ" ĐỂ TRỊ
Client → API Gateway → Product Service (MongoDB)
→ Cart Service (PostgreSQL)
→ Order Service (PostgreSQL)

📌 Đặc điểm chính:
- Mỗi service độc lập, có database riêng.
- API Gateway điều phối request.
- Mỗi service có thể được viết bằng ngôn ngữ khác nhau, deploy riêng lẻ.

✅ Ưu: Scale linh hoạt, thay đổi một service không ảnh hưởng service khác.
❌ Nhược: Phức tạp hơn (distributed transaction, observability, network latency).

Ví dụ: Netflix, Uber, Spotify – mỗi tính năng là một service riêng.

3️⃣ SERVERLESS – "HÀM" CHẠY KHI CÓ SỰ KIỆN
Client → API Gateway → Product Function (tạm thời)
→ Cart Function
→ Order Function
→ Data Stores (SQL/NoSQL, Object Storage)

📌 Đặc điểm chính:
- Code được viết dưới dạng function, chạy khi có event (HTTP request, queue...).
- Không cần quản lý server, tự động scale.
- Stateless – dữ liệu phải lưu ở ngoài (database, object storage).

✅ Ưu: Không lo infrastructure, trả tiền theo thời gian chạy, phù hợp tác vụ ngắn.
❌ Nhược: Cold start có thể gây độ trễ, khó debug, không phù hợp cho ứng dụng có trạng thái phức tạp.

Ví dụ: AWS Lambda dùng cho xử lý ảnh, gửi email, xác thực người dùng.

🎯 CHỌN KIẾN TRÚC NÀO?
1. Độ phức tạp: Monolithic thấp – Microservices cao – Serverless trung bình
2. Tốc độ dev ban đầu: Monolithic nhanh – Microservices chậm – Serverless trung bình
3. Khả năng scale: Monolithic giới hạn (scale dọc) – Microservices vô hạn (scale ngang) – Serverless tự động
4. Quản lý server: Monolithic có – Microservices có – Serverless không
5. Chi phí khi ít tải: Monolithic thấp (một máy) – Microservices cao (nhiều máy) – Serverless rất thấp (trả theo dùng)
6. Chi phí khi tải cao: Monolithic cao (phải nâng cấp máy) – Microservices cao (nhiều instance) – Serverless có thể cao nếu dùng nhiều

👉 Lời khuyên:
- Monolithic – Startup, MVP, hệ thống nhỏ, đội ngũ ít.
- Microservices – Hệ thống lớn, nhiều team, cần scale độc lập.
- Serverless – Tác vụ ngắn, thưa thớt, không muốn quản lý server.

⚙️📊
Xây dựng hệ thống cơ sở dữ liệu lớn về tổ chức bộ máy và cán bộ

Tôi có buidl 1 tài liệu Linux, bao quát toàn bộ Exam LPI 101, 102, 202, 202, anh em nào cần rq tôi share cho mà dùng. Link: https://drive.google.com/file/d/1SVjxh4xI6vWT_G5xvjEethfCpPbAKv8U/view?usp=sharing

Thông báo tuyển chọn công dân có trình độ đại học ngành công nghệ thông tin vào CATP Hà Nội