Ngân hàng đề — Microsoft Administering Azure SQL

Đáp án

B — Azure Monitor Alerts.

Vì sao đúng

⚠ Logic Apps tích hợp với Azure Monitor:

⚠ Logic App chạy
        ↓
⚠ Ghi số liệu và log vào Azure Monitor
   ⚠ RunsFailed, RunsSucceeded,
     RunLatency
        ↓
⚠ Đặt alert rule trên số liệu đó
        ↓
⚠ Action group thông báo
   ⚠ email, SMS, Teams, webhook

Vì sao các phương án khác sai

• C (Logic App run history) — ⚠ bẫy gần nhất: ⚠ lịch sử chạy là ⚠ rất hữu ích để ĐIỀU TRA, ⚠ nhưng ⚠ phải TỰ VÀO XEM; ⚠ nó không THÔNG BÁO cho ai cả.

• D (Azure SQL audits) — ⚠ ghi hoạt động trong CSDL: ⚠ không biết gì về Logic App.

• A ("ARM notifications") — ⚠ không phải tính năng có thật.

Ghi nhớ

⚠ Azure Monitor — kiến trúc cảnh báo phải thuộc: | Thành phần | Vai trò | |---|---| | ⚠ Metric / Log | ⚠ dữ liệu thu thập | | ⚠ Alert rule | ⚠ điều kiện kích hoạt | | ⚠ Action group | ⚠ làm gì khi kích hoạt: email, SMS, webhook, Logic App, Function | | ⚠ Alert processing rule | ⚠ chặn cảnh báo trong cửa sổ bảo trì |

Từ khoá nhận diện:

"được THÔNG BÁO về sự cố" → ⚠ Azure Monitor Alerts "xem lại chuyện gì đã xảy ra" → ⚠ run history, log "ai truy cập dữ liệu" → ⚠ SQL Auditing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cảnh báo khi quy trình KHÔNG chạy không | ⚠ quan trọng nhất | | Action group gửi tới đâu | | | Retry policy đã cấu hình hợp lý chưa | |

Và loại sự cố mà mọi hệ thống cảnh báo dựa trên lỗi đều bỏ sót: quy trình ngừng chạy hẳn. Không có lỗi nào để báo, không có gì bất thường trong log — chỉ là im lặng, và không ai để ý cho tới khi thiếu dữ liệu.

Đáp án

A — Elastic Jobs.

Ghi nhớ về chất lượng câu hỏi

⚠ Phương án C và D GIỐNG HỆT NHAU — ⚠ cả hai đều ghi "Azure Logic Apps".

⚠ Đây là ⚠ lỗi soạn đề: ⚠ thực chất câu này chỉ còn ba lựa chọn phân biệt được.

⚠ Không ảnh hưởng đáp án — ⚠ Elastic Jobs vẫn là câu trả lời đúng.

Vì sao đúng

⚠ Elastic Jobs chạy T-SQL trên NHIỀU CSDL Azure SQL, quản tập trung:

⚠ Job agent (một CSDL riêng)
        ↓ ⚠ định nghĩa job và target group
⚠ Target group có thể là:
   ⚠ danh sách CSDL cụ thể
   ⚠ MỌI CSDL trong một server
   ⚠ MỌI CSDL trong một elastic pool
        ↓
⚠ Chạy CÙNG một script T-SQL
   trên tất cả
        ↓
⚠ Kết quả gom về một nơi

Vì sao các phương án khác sai

• C và D (Azure Logic Apps) — ⚠ làm được nhưng không phải công cụ chuyên dụng: ⚠ phải tự nối tới từng CSDL, ⚠ tự quản danh sách, ⚠ tự gom kết quả.

• B (ARM template) — ⚠ triển khai hạ tầng, ⚠ không chạy công việc định kỳ.

Ghi nhớ

⚠ Chạy job trên Azure SQL — bảng phải thuộc: | Môi trường | Công cụ | |---|---| | ⚠ SQL Server trên VM | ⚠ SQL Server Agent | | ⚠ Azure SQL Managed Instance | ⚠ SQL Server Agent (CÓ) | | ⚠ Azure SQL Database | ⚠ Elastic Jobs — KHÔNG có Agent | | ⚠ Quy trình nhiều hệ thống | ⚠ Logic Apps | | ⚠ Đường ống dữ liệu | ⚠ Data Factory |

Từ khoá nhận diện:

"chạy T-SQL trên nhiều Azure SQL Database" → ⚠ Elastic Jobs "Azure SQL Database không có SQL Agent" → ⚠ điểm khác biệt hay bị hỏi "quy trình nối nhiều dịch vụ" → ⚠ Logic Apps

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng mô hình nào | ⚠ quyết định công cụ chạy job | | Target group có tự bao gồm CSDL mới không | | | Job database có được theo dõi không | ⚠ nó cũng là một điểm hỏng |

Và khác biệt hay khiến các cuộc di trú lên Azure SQL Database bị bất ngờ: không có SQL Server Agent. Rất nhiều hệ thống dựa vào hàng chục job đã chạy im lặng nhiều năm, và không ai nhớ ra chúng cho tới ngày cutover.

Đáp án

A — Active geo-replication.

Vì sao đúng

⚠ Đề cần CẢ HAI chỉ số đều THẤP: | Chỉ số | Yêu cầu | Active geo-replication | |---|---|---| | ⚠ RPO thấp | ⚠ mất rất ít dữ liệu | ⚠ nhân bản liên tục, trễ vài giây | | ⚠ RTO thấp | ⚠ khôi phục rất nhanh | ⚠ secondary ĐÃ CHẠY SẴN, chỉ cần nâng cấp |

⚠ Primary đang chạy
        ↓ ⚠ nhân bản liên tục
⚠ Secondary ĐANG CHẠY, ĐỌC ĐƯỢC
        ↓ ⚠ sự cố
⚠ Nâng secondary lên primary
        ↓
⚠ Hoạt động lại trong PHÚT

⚠ Điểm mấu chốt: ⚠ secondary đã tồn tại và đã đồng bộ — ⚠ không phải dựng lại từ đầu.

Vì sao các phương án khác sai

• B (sao lưu và khôi phục tiêu chuẩn) — ⚠ RTO RẤT CAO: ⚠ phải chờ khôi phục toàn bộ CSDL, ⚠ có thể hàng giờ.

• C (log shipping mỗi 24 giờ) — ⚠ RPO RẤT CAO: ⚠ có thể mất tới 24 giờ dữ liệu.

• D (database snapshot) — ⚠ ảnh chụp tại một thời điểm, nằm CÙNG máy chủ: ⚠ không bảo vệ khỏi sự cố máy chủ hay vùng; ⚠ và ⚠ Azure SQL Database không hỗ trợ theo cách này.

Ghi nhớ

⚠ RPO/RTO theo giải pháp — bảng phải thuộc: | Giải pháp | RPO | RTO | |---|---|---| | ⚠ HA tích hợp trong vùng | ⚠ ≈ 0 | ⚠ giây | | ⚠ Zone-redundant | ⚠ ≈ 0 | ⚠ giây | | ⚠ Active geo-replication | ⚠ giây | ⚠ phút | | ⚠ Auto-failover group | ⚠ giây | ⚠ phút, TỰ ĐỘNG | | ⚠ Geo-restore từ sao lưu | ⚠ tới 1 giờ | ⚠ GIỜ | | ⚠ Log shipping 24 giờ | ⚠ tới 24 GIỜ | ⚠ giờ |

Từ khoá nhận diện:

"RPO và RTO đều thấp" → ⚠ geo-replication hoặc failover group "chi phí thấp, chấp nhận chậm" → ⚠ sao lưu và khôi phục "tự động chuyển đổi" → ⚠ auto-failover group "HA trong cùng vùng" → ⚠ zone-redundant

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã diễn tập chuyển đổi thật chưa | ⚠ RTO trên giấy khác RTO thật | | Ứng dụng có tự kết nối lại sau failover không | | | Secondary có được dùng cho báo cáo không | ⚠ tận dụng khoản đã trả |

Và phần tốn thời gian nhất trong một lần chuyển đổi dự phòng thật thường không phải là cơ sở dữ liệu: đó là ứng dụng, DNS, bộ nhớ đệm kết nối và những người phải quyết định có chuyển hay không. Chỉ diễn tập mới cho biết con số RTO thật.

Đáp án

A và C — Automated backups và lệnh T-SQL RESTORE.

Ghi nhớ về chất lượng câu hỏi

⚠ Phương án C không chính xác với Azure SQL Database.

⚠ KHÔNG sửa khoá — ⚠ nhưng nhớ rằng ⚠ RESTORE T-SQL không dùng được trên Azure SQL Database.

⚠ Phần chắc chắn đúng: ⚠ automated backups là nền tảng của point-in-time restore.

Vì sao đúng (phần A)

⚠ Azure SQL Database sao lưu TỰ ĐỘNG:

⚠ Full backup: hằng tuần
⚠ Differential: 12-24 giờ
⚠ Transaction log: mỗi 5-10 phút
        ↓
⚠ Ghép ba loại
        ↓
⚠ Khôi phục về BẤT KỲ thời điểm nào
   trong thời hạn lưu (1-35 ngày)

⚠ Không phải cấu hình gì — ⚠ bật sẵn từ lúc tạo CSDL.

Vì sao các phương án khác sai

• B (ảnh chụp Azure Blob Storage) — ⚠ không phải cơ chế của Azure SQL Database: ⚠ sao lưu do dịch vụ tự quản, ⚠ khách không thao tác trực tiếp trên blob.

• D (Always On availability group) — ⚠ là giải pháp HA: ⚠ giữ bản sao đồng bộ, ⚠ không cho khôi phục về thời điểm trong quá khứ.

Ghi nhớ

⚠ Các loại khôi phục của Azure SQL — bảng phải thuộc: | Loại | Dùng khi | |---|---| | ⚠ Point-in-time restore | ⚠ lỗi con người, hỏng dữ liệu — trong thời hạn lưu | | ⚠ Restore deleted database | ⚠ CSDL bị xoá nhầm | | ⚠ Geo-restore | ⚠ cả vùng sập — dùng bản sao lưu địa lý | | ⚠ Long-term retention restore | ⚠ khôi phục từ bản lưu nhiều năm |

Từ khoá nhận diện:

"khôi phục về thời điểm bất kỳ" → ⚠ point-in-time restore, dựa trên automated backups "CSDL bị xoá" → ⚠ restore deleted database "cả vùng sập" → ⚠ geo-restore hoặc failover group "giữ sao lưu nhiều năm" → ⚠ long-term retention

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Thời hạn lưu đặt bao nhiêu ngày | | | Đã thử khôi phục thật chưa và mất bao lâu | | | Có cần long-term retention không | |

Và điều chỉ một cuộc diễn tập mới nói cho bạn biết: khôi phục cơ sở dữ liệu của bạn mất bao lâu. Con số đó là RTO thật, và nó thường lớn hơn nhiều so với ước lượng của mọi người trong phòng.

Đáp án

A — Azure VM với SQL Server.

Vì sao đúng

⚠ Đề cần MỞ RỘNG giải pháp HA/DR có sẵn tại chỗ sang Azure: | Yêu cầu | Vì sao cần SQL trên VM | |---|---| | ⚠ Mở rộng HA/DR TẠI CHỖ | ⚠ cần CÙNG công nghệ hai bên | | ⚠ Always On AG xuyên tại chỗ - Azure | ⚠ replica ở Azure phải là SQL Server đầy đủ | | ⚠ Cùng phiên bản, cùng cấu hình | ⚠ chỉ IaaS cho phép |

⚠ Tại chỗ: SQL Server + Always On AG
        ↓ ⚠ mở rộng AG
⚠ Azure VM: SQL Server (cùng phiên bản)
   ⚠ làm replica bổ sung
        ↓
⚠ Vùng Azure trở thành site DR

⚠ Đây là mẫu triển khai lai chuẩn của Microsoft.

Vì sao các phương án khác sai

• B (Azure SQL Managed Instance) — ⚠ PaaS, KHÔNG tham gia được Always On AG với SQL Server tại chỗ: ⚠ có Managed Instance link (nhân bản từ SQL Server sang MI), ⚠ nhưng ⚠ đó là cơ chế khác, không phải mở rộng AG hiện có.

• D (Azure SQL Database) — ⚠ PaaS, càng không tham gia AG được.

• C (Azure Kubernetes Service) — ⚠ điều phối container: ⚠ không liên quan HA/DR của SQL Server truyền thống.

Ghi nhớ

⚠ Chọn mô hình theo yêu cầu tương thích — bảng phải thuộc: | Yêu cầu | Mô hình | |---|---| | ⚠ Mở rộng AG/FCI có sẵn, cùng công nghệ | ⚠ SQL Server trên Azure VM (IaaS) | | ⚠ Cần gần đủ tính năng, ít vận hành hơn | ⚠ Managed Instance | | ⚠ Ứng dụng mới, CSDL đơn lẻ | ⚠ Azure SQL Database | | ⚠ Nguyên tắc | ⚠ càng cần tương thích với hệ thống cũ, càng phải xuống IaaS |

Từ khoá nhận diện:

"mở rộng HA/DR tại chỗ sang Azure" → ⚠ SQL Server trên Azure VM "nhân bản từ SQL Server sang PaaS" → ⚠ Managed Instance link "ứng dụng mới hoàn toàn" → ⚠ Azure SQL Database

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Băng thông có đủ cho nhân bản không | | | Quorum có chịu được mất một site không | | | Đã diễn tập chuyển sang replica Azure chưa | |

Và điểm dễ tính sai nhất khi mở rộng một cụm HA sang đám mây: quorum. Nếu đường nối giữa hai site đứt, cụm phải quyết định bên nào tiếp tục hoạt động — và tính sai số phiếu nghĩa là cả hai bên cùng dừng.

Đáp án

A — Azure Monitor.

Vì sao đúng

⚠ Azure Monitor là nền tảng giám sát tổng hợp của Azure: | Giám sát gì cho HA/DR | Nội dung | |---|---| | ⚠ Độ trễ nhân bản | ⚠ secondary trễ bao nhiêu — chính là RPO thực tế | | ⚠ Trạng thái sức khoẻ của replica | | | ⚠ Sự kiện failover | | | ⚠ Tình trạng sao lưu | | | ⚠ Cảnh báo khi vượt ngưỡng | |

⚠ Metric + Log từ tài nguyên
        ↓ ⚠ Azure Monitor
⚠ Alert rule
        ↓ ⚠ Action group
⚠ Email, SMS, Teams, PagerDuty, webhook

Vì sao các phương án khác sai

• B (Azure Policy) — ⚠ CƯỠNG CHẾ chuẩn cấu hình: ⚠ ví dụ bắt mọi CSDL phải bật geo-replication; ⚠ nhưng ⚠ không giám sát hoạt động.

• C (Azure Blueprint) — ⚠ đóng gói mẫu môi trường để triển khai lặp lại: ⚠ hạ tầng, không phải giám sát; ⚠ (nay đã được thay bằng Template Specs và Deployment Stacks).

• D (Azure Bicep) — ⚠ ngôn ngữ định nghĩa hạ tầng: ⚠ triển khai chứ không giám sát.

Ghi nhớ

⚠ Bốn công cụ dễ lẫn — bảng phải thuộc: | Công cụ | Việc | |---|---| | ⚠ Azure Monitor | ⚠ GIÁM SÁT: metric, log, alert | | ⚠ Azure Policy | ⚠ CƯỠNG CHẾ chuẩn cấu hình | | ⚠ Azure Blueprint / Template Specs | ⚠ ĐÓNG GÓI mẫu môi trường | | ⚠ Bicep / ARM | ⚠ ĐỊNH NGHĨA hạ tầng |

Từ khoá nhận diện:

"giám sát, cảnh báo" → ⚠ Azure Monitor "bắt buộc tuân thủ chuẩn" → ⚠ Azure Policy "triển khai hạ tầng" → ⚠ Bicep / ARM "đối chiếu Google Cloud" → ⚠ Monitor ↔ Cloud Monitoring; Policy ↔ Organization Policy

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có cảnh báo khi độ trễ nhân bản tăng không | | | Có ai được báo khi failover tự động xảy ra không | | | Secondary có đủ cấu hình để gánh tải thật không | |

Và loại cảnh báo hay bị quên nhất trong mọi thiết kế HA/DR: cảnh báo khi chính cơ chế bảo vệ ngừng hoạt động. Một liên kết nhân bản đứt từ ba tuần trước chỉ lộ ra vào đúng lúc bạn cần nó nhất.

Đáp án

D — Xoá các file sao lưu để "kiểm tra khả năng khôi phục".

Vì sao đúng

⚠ Đây là câu hỏi PHỦ ĐỊNH — ⚠ tìm cách KHÔNG hợp lệ.

⚠ Vì sao xoá file sao lưu là cách sai: | Vấn đề | Nội dung | |---|---| | ⚠ HUỶ chính thứ đang muốn kiểm tra | ⚠ kiểm tra sao lưu bằng cách xoá sao lưu | | ⚠ Không đảo ngược được | ⚠ nếu khôi phục thất bại thì mất hẳn | | ⚠ Không chứng minh được điều gì | ⚠ muốn biết bản sao lưu dùng được thì KHÔI PHỤC THỬ nó | | ⚠ Có thể vi phạm quy định lưu trữ | |

⚠ Cách ĐÚNG để kiểm tra sao lưu
        ↓
⚠ Khôi phục vào một CSDL MỚI
        ↓
⚠ Kiểm tra tính toàn vẹn dữ liệu
        ↓
⚠ Đo THỜI GIAN khôi phục
        ↓
⚠ Xoá CSDL thử nghiệm
        ↓
⚠ Bản sao lưu gốc VẪN CÒN NGUYÊN

Vì sao các phương án khác đều hợp lệ

• A (kiểm thử failover và failback) — ⚠ thực hành BẮT BUỘC: ⚠ chỉ có cách này mới biết RTO thật và phát hiện bước bị quên.

• C (mô phỏng sự cố toàn vùng) — ⚠ bài diễn tập DR chuẩn: ⚠ nhiều tổ chức làm định kỳ, có kế hoạch.

• B (kiểm thử tải trên replica chính) — ⚠ hợp lệ: ⚠ cần biết hệ thống chịu được tải đỉnh, ⚠ và ⚠ secondary có gánh nổi không sau failover.

Ghi nhớ

⚠ Kiểm thử HA/DR — thực hành phải thuộc: | Thực hành | Nội dung | |---|---| | ⚠ Khôi phục thử định kỳ | ⚠ bản sao lưu chưa thử = chưa phải bản sao lưu | | ⚠ Diễn tập failover có kế hoạch | ⚠ đo RTO thật | | ⚠ Kiểm thử failback | ⚠ hay bị quên — quay về thế nào | | ⚠ Mô phỏng sự cố vùng | | | ⚠ Ghi lại kết quả và cải thiện | | | ⚠ KHÔNG BAO GIỜ | ⚠ phá huỷ cơ chế bảo vệ để "kiểm tra" |

Từ khoá nhận diện:

"cách nào KHÔNG hợp lệ" → ⚠ đọc kỹ, đây là câu phủ định "kiểm tra sao lưu" → ⚠ KHÔI PHỤC THỬ, không phải xoá "đo RTO thật" → ⚠ diễn tập failover

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần khôi phục thử gần nhất là bao giờ | | | Đã kiểm thử FAILBACK chưa | ⚠ không chỉ failover | | Ứng dụng có tự kết nối lại sau failover không | |

Và câu nói đáng nhớ nhất về sao lưu: một bản sao lưu chưa bao giờ được khôi phục thử thì không phải là bản sao lưu, mà chỉ là một hy vọng. Cách kiểm tra nó là khôi phục ra một nơi khác — không bao giờ là xoá nó đi.

Đáp án

B — Data Classification.

Vì sao đúng

⚠ Data Discovery & Classification gắn NHÃN cho cột: | Loại nhãn | Ví dụ | |---|---| | ⚠ Sensitivity label | ⚠ Public, General, Confidential, Highly Confidential | | ⚠ Information type | ⚠ Financial, Health, Credentials, Contact Info, Name |

⚠ Azure QUÉT lược đồ tự động
        ↓
⚠ Đề xuất nhãn cho từng cột
   ⚠ dựa trên tên cột và kiểu dữ liệu
        ↓
⚠ Bạn duyệt hoặc sửa
        ↓
⚠ Nhãn lưu như SIÊU DỮ LIỆU
        ↓
⚠ Audit log ghi lại ai đọc cột có nhãn

Vì sao các phương án khác sai

• D (Dynamic Data Masking) — ⚠ CHE giá trị khi hiển thị: ⚠ là hành động, ⚠ không phải phân loại.

• C (TDE) — ⚠ mã hoá tệp dữ liệu: ⚠ không phân loại gì.

• A (SQL Data Sync) — ⚠ đồng bộ dữ liệu, hoàn toàn khác.

Ghi nhớ

⚠ Vòng đời quản trị dữ liệu nhạy cảm — bảng phải thuộc: | Bước | Công cụ | |---|---| | ⚠ 1. PHÁT HIỆN và PHÂN LOẠI | ⚠ Data Classification | | ⚠ 2. BẢO VỆ | ⚠ DDM, quyền cấp cột, Always Encrypted | | ⚠ 3. GIÁM SÁT | ⚠ Auditing kèm nhãn phân loại | | ⚠ 4. BÁO CÁO tuân thủ | ⚠ báo cáo phân loại | | ⚠ Bước 1 là nền | ⚠ không biết dữ liệu nhạy cảm ở đâu thì không bảo vệ được |

Từ khoá nhận diện:

"gắn nhãn Sensitive, Confidential" → ⚠ Data Classification "che giá trị hiển thị" → ⚠ Dynamic Data Masking "mã hoá" → ⚠ TDE hoặc Always Encrypted "ghi lại ai truy cập" → ⚠ Auditing

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã chạy phát hiện phân loại chưa | | | Có cột nào tên khó hiểu nhưng chứa dữ liệu nhạy cảm không | | | Audit có ghi kèm nhãn phân loại không | |

Và bước đầu tiên của mọi chương trình bảo vệ dữ liệu, thường bị bỏ qua vì nó không tạo ra thứ gì nhìn thấy được: biết dữ liệu nhạy cảm đang nằm ở đâu. Không có bản đồ đó thì mọi biện pháp bảo vệ đều là đoán.

Đáp án

A — Azure SQL Managed Instance với Auto-failover group.

Vì sao đúng

⚠ Đối chiếu ba yêu cầu với phương án: | Yêu cầu | Auto-failover group của MI | |---|---| | ⚠ Tự động chuyển đổi, KHÔNG can thiệp tay | ⚠ auto-failover group làm TỰ ĐỘNG | | ⚠ Primary đọc-ghi, secondary CHỈ ĐỌC | ⚠ secondary có listener chỉ đọc | | ⚠ Hai replica ở HAI VÙNG khác nhau | ⚠ failover group là giải pháp ĐA VÙNG |

⚠ Auto-failover group
   ⚠ hai endpoint cố định:
     ⚠ <ten>.database.windows.net (đọc-ghi)
     ⚠ <ten>.secondary...  (chỉ đọc)
        ↓
⚠ Sự cố vùng → ⚠ TỰ chuyển
        ↓
⚠ Ứng dụng KHÔNG đổi chuỗi kết nối

Vì sao các phương án khác sai

• B (Azure SQL Database với Active geo-replication) — ⚠ thiếu đúng một yêu cầu: ⚠ geo-replication ⚠ chuyển đổi THỦ CÔNG; ⚠ đề đòi tự động.

• C (Azure SQL Database zone-redundant premium) — ⚠ chỉ trong MỘT vùng: ⚠ chịu được sập một zone, ⚠ không đáp ứng yêu cầu hai VÙNG khác nhau.

• D (SQL Server trên Azure VM với Always On AG CÙNG VÙNG) — ⚠ sai vì "cùng vùng": ⚠ đề đòi hai vùng khác nhau.

Ghi nhớ

⚠ So sánh các giải pháp HA/DR — bảng phải thuộc: | Giải pháp | Tự động | Đa vùng | Secondary đọc được | |---|---|---|---| | ⚠ Zone-redundant | ⚠ CÓ | ⚠ KHÔNG | ⚠ không lộ ra | | ⚠ Active geo-replication | ⚠ KHÔNG | ⚠ CÓ | ⚠ CÓ | | ⚠ Auto-failover group | ⚠ CÓ | ⚠ CÓ | ⚠ CÓ | | ⚠ Always On AG trên VM | ⚠ CÓ | ⚠ CÓ nếu cấu hình đa vùng | ⚠ CÓ |

Từ khoá nhận diện:

"tự động + đa vùng + secondary đọc được" → ⚠ auto-failover group "đa vùng nhưng chuyển tay" → ⚠ active geo-replication "trong một vùng, chịu sập zone" → ⚠ zone-redundant "Managed Instance đa vùng" → ⚠ CHỈ có failover group

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ứng dụng có dùng endpoint của failover group không | ⚠ hay vẫn trỏ thẳng vào server | | Thời gian ân hạn đặt bao nhiêu | | | Đã diễn tập chuyển đổi có kế hoạch chưa | |

Và điều quyết định giá trị thật của một auto-failover group: ứng dụng có kết nối qua endpoint của nhóm hay không. Rất nhiều hệ thống cấu hình đúng ở tầng cơ sở dữ liệu rồi vẫn sập, vì chuỗi kết nối trỏ thẳng vào tên máy chủ cũ.

Đáp án

A — Có (Yes).

Vì sao đúng

⚠ Khuyến nghị của Microsoft về số data file cho tempdb: | Số lõi | Số data file | |---|---| | ⚠ 8 lõi trở xuống | ⚠ BẰNG số lõi | | ⚠ Trên 8 lõi | ⚠ BẮT ĐẦU từ 8, tăng thêm 4 mỗi lần nếu vẫn còn tranh chấp |

⚠ VM có 16 vCPU
        ↓ ⚠ theo khuyến nghị
⚠ Bắt đầu với 8 data file
        ↓
⚠ Theo dõi tranh chấp `PAGELATCH`
        ↓
⚠ Còn tranh chấp → ⚠ thêm 4 file nữa

⚠ Tám file cho 16 vCPU là ĐIỂM XUẤT PHÁT ĐÚNG — ⚠ vì vậy đáp án là "Có".

Vì sao "Không" là sai

• ⚠ Có người nghĩ ⚠ phải bằng 16 file cho 16 vCPU — ⚠ nhưng ⚠ khuyến nghị dừng ở 8 rồi mới tăng dần theo quan sát; ⚠ quá nhiều file cũng gây chi phí quản lý.

Ghi nhớ

⚠ Cấu hình tempdb — bảng phải thuộc: | Cấu hình | Khuyến nghị | |---|---| | ⚠ Số data file | ⚠ = số lõi (tối đa 8), rồi tăng dần thêm 4 | | ⚠ Kích thước file | ⚠ TẤT CẢ BẰNG NHAU | | ⚠ Autogrowth | ⚠ cùng một mức cho mọi file | | ⚠ Đặt sẵn kích thước lớn | ⚠ tránh phải tự lớn lên lúc chạy | | ⚠ Vị trí | ⚠ đĩa NHANH NHẤT, tách khỏi data và log | | ⚠ Trên Azure VM | ⚠ đặt tempdb trên ĐĨA TẠM cục bộ (ổ D:) — nhanh nhất |

Từ khoá nhận diện:

"tranh chấp tempdb" → ⚠ chia nhiều data file bằng nhau "PAGELATCH_UP trên trang 2:1:1" → ⚠ tranh chấp trang cấp phát tempdb "tempdb trên Azure VM" → ⚠ đĩa tạm cục bộ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các file tempdb có bằng nhau không | | | max server memory đã điều chỉnh theo RAM mới chưa | | | Còn tranh chấp PAGELATCH trên tempdb không | ⚠ nếu còn thì thêm 4 file |

Và việc hay bị quên nhất sau khi nâng cấu hình một máy chủ SQL: max server memory vẫn giữ giá trị cũ. Bạn trả tiền cho 64 GB RAM trong khi SQL Server vẫn chỉ dùng đúng phần được cấu hình từ hồi máy còn 28 GB.