Ngân hàng đề — Microsoft Azure Database Administrator

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi mô tả tình huống trong Azure SQL Database:

• Plan cache (bộ nhớ đệm kế hoạch thực thi truy vấn) đang bị đầy bởi các compiled plans chỉ được sử dụng một lần (single-use hoặc ad-hoc plans). Điều này gây áp lực bộ nhớ (memory pressure), làm giảm hiệu suất và tiêu tốn tài nguyên không cần thiết.
• Người dùng đã chạy lệnh T-SQL: SELECT * FROM sys.database_scoped_configurations và nhận kết quả từ bảng (hình ảnh đính kèm).
• Mục tiêu: Cấu hình một tùy chọn để giảm áp lực bộ nhớ bằng cách tối ưu hóa plan cache cho các truy vấn ad-hoc.

📊 Phân tích nội dung hình ảnh (bảng sys.database_scoped_configurations):
Bảng hiển thị các cấu hình database-scoped với cột: configuration_id, name, value, is_value_default:

• ID 1: LEGACY_CARDINALITY_ESTIMATION = 0 (không phải mặc định, mặc định=1 → sử dụng estimator mới).
• ID 2: QUERY_OPTIMIZER_HOTFIXES = 0 (không phải mặc định, mặc định=1 → không áp dụng hotfixes).
• ID 3: OPTIMIZE_FOR_AD_HOC_WORKLOADS = 0 (không phải mặc định, mặc định=1 → đang TẮT).
• ID 4: ACCELERATED_PLAN_FORCING = 1 (là mặc định → đang BẬT).

Vấn đề chính là ad-hoc workloads (truy vấn chỉ dùng 1 lần) đang lấp đầy cache với full execution plans, thay vì chỉ lưu stub (phiên bản rút gọn). Giải pháp cần kích hoạt tùy chọn phù hợp để lưu trữ plan stubs thay vì full plans, giải phóng bộ nhớ.

🛠️ Kiến thức cập nhật (Azure SQL đến 2026): Theo tài liệu Microsoft (phiên bản mới nhất SQL Server 2022 và Azure SQL Hyperscale), OPTIMIZE_FOR_AD_HOC_WORKLOADS chính là tùy chọn lý tưởng cho tình huống này, giúp giảm kích thước cache lên đến 65% cho ad-hoc queries (xem Microsoft Docs: sys.database_scoped_configurations và Optimize for ad hoc workloads).

✅ Đáp án đúng: OPTIMIZE_FOR_AD_HOC_WORKLOADS

Lý do lựa chọn:

• Tùy chọn này được thiết kế chính xác để giải quyết vấn đề plan cache đầy single-use plans từ ad-hoc workloads. Khi bật (set value=1), SQL Server chỉ lưu plan stub (thông tin cơ bản) cho lần thực thi đầu tiên, và chỉ lưu full plan từ lần thứ hai trở đi.
• Trong bảng, nó đang OFF (value=0), nên cần cấu hình bật lên để giảm ngay memory pressure.
• Đây là giải pháp tiêu chuẩn, hiệu quả cao mà không ảnh hưởng đến truy vấn lặp lại (repeated queries).

📋 Giải thích tất cả các phương án

• LEGACY_CARDINALITY_ESTIMATION ❌ (SAI)
  Tùy chọn này chọn cardinality estimator cũ (SQL Server 2012) thay vì mới (từ 2014+). Nó ảnh hưởng đến ước lượng số hàng (row estimates) trong query optimization, giúp cải thiện một số truy vấn cũ, nhưng KHÔNG liên quan đến việc giảm kích thước plan cache hay single-use plans. Trong bảng, value=0 (sử dụng estimator mới), bật nó không giải quyết memory pressure từ ad-hoc.

• QUERY_OPTIMIZER_HOTFIXES ❌ (SAI)
  Tùy chọn này áp dụng các hotfix mới nhất cho query optimizer mà không cần restart. Nó sửa lỗi optimizer, cải thiện chất lượng plan, nhưng KHÔNG giảm số lượng plans trong cache hay xử lý ad-hoc workloads. Trong bảng, value=0 (không áp dụng hotfixes), bật nó chỉ fix bugs chứ không relieve memory.

• OPTIMIZE_FOR_AD_HOC_WORKLOADS ✅ (ĐÚNG)
  Như đã giải thích ở trên: Bật để lưu plan stubs cho ad-hoc queries, giảm memory usage đáng kể cho single-use plans. Hoàn hảo khớp với vấn đề, và đang OFF trong bảng → cần cấu hình ngay.

• ACCELERATED_PLAN_FORCING ❌ (SAI)
  Tùy chọn này tăng tốc độ plan forcing (Intelligent Query Processing feature) bằng cách sử dụng ML để force plans nhanh hơn. Nó giúp queries parameterized nhanh, nhưng KHÔNG giảm plan cache size và đã BẬT (value=1) trong bảng, nên cấu hình thêm vô ích.

Tài liệu tham khảo chính:

• 📘 Microsoft Docs: sys.database_scoped_configurations (cập nhật 2024).
• 📘 Optimize for ad hoc workloads (hiệu quả đến Azure SQL 2026).
• 🔍 Để áp dụng: ALTER DATABASE SCOPED CONFIGURATION SET OPTIMIZE_FOR_AD_HOC_WORKLOADS = ON;.

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi này thuộc chủ đề Azure Data Factory (ADF) – một dịch vụ ETL (Extract, Transform, Load) trên Microsoft Azure dùng để quản lý và thực thi các pipeline dữ liệu.
Tình huống cụ thể: Bạn có 10 pipelines trong một Azure Data Factory. Nhiệm vụ là gán nhãn (label) cho từng pipeline theo mục đích chính: ingest (hấp thụ dữ liệu), transform (chuyển đổi dữ liệu), hoặc load (tải dữ liệu). Các nhãn này phải hỗ trợ grouping (nhóm) và filtering (lọc) khi sử dụng monitoring experience (giao diện giám sát) trong Data Factory.
Mục tiêu: Tìm cách thêm metadata (siêu dữ liệu) vào từng pipeline để dễ dàng quản lý và theo dõi hoạt động trong phần Monitoring Hub của ADF.
📘 Lưu ý kiến thức cập nhật: Theo tài liệu Microsoft Azure Data Factory phiên bản mới nhất (tính đến 2026, bao gồm ADF v2 và các tính năng monitoring nâng cao), annotations là cơ chế chính để labeling pipelines cho mục đích này. (Nguồn: Microsoft Docs - Pipeline annotations và ADF Monitoring Hub).

✅ Đáp án đúng: "an annotation"

Lý do lựa chọn:
🛠️ Annotations là tính năng chuyên dụng trong Azure Data Factory cho phép thêm các cặp key-value (nhãn tùy chỉnh) trực tiếp vào pipeline JSON definition. Chúng được thiết kế đặc biệt để group và filter các pipeline runs trong Monitoring Hub (giao diện giám sát). Ví dụ, bạn có thể thêm annotation như {"purpose": "ingest"} cho pipeline ingest, sau đó lọc/group theo key "purpose" trong monitoring view.
✅ Điều này khớp hoàn hảo với yêu cầu: labels có sẵn cho grouping/filtering. Không có tính năng nào khác hỗ trợ trực tiếp như vậy trong ADF monitoring (cập nhật 2026).

📋 Giải thích tất cả các phương án (đúng và sai)

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Phần giải thích sử dụng tiếng Việt hoàn toàn:

• an annotation
  ✅ Đúng. Annotations được thêm vào phần annotations trong JSON của pipeline (qua Author & Monitor hoặc ARM template). Chúng hiển thị trong Monitoring Hub dưới dạng filter/group options, cho phép phân loại pipelines theo "ingest/transform/load" một cách trực quan và linh hoạt. Hoàn hảo cho yêu cầu! (Nguồn: ADF Annotations Docs).

• a resource tag
  ❌ Sai. Resource tags là metadata cấp Azure Resource (như Data Factory instance), không áp dụng trực tiếp cho từng pipeline riêng lẻ. Tags không hỗ trợ grouping/filtering trong ADF Monitoring Hub; chúng chỉ dùng cho cost management hoặc RBAC ở mức resource group/subscription. Không phù hợp cho labeling pipelines.

• a run group ID
  ❌ Sai. "Run group ID" không phải là tính năng chuẩn trong ADF. Pipeline runs có Run ID tự động, nhưng không dùng để labeling/groping theo purpose. Không hỗ trợ filter theo custom groups trong monitoring.

• a user property
  ❌ Sai. "User property" (hoặc custom properties) có thể thêm vào datasets/linked services, nhưng không áp dụng cho pipelines và không tích hợp với Monitoring Hub cho grouping/filtering. Annotations mới là cách chính thức cho pipelines.

• a correlation ID
  ❌ Sai. Correlation ID dùng để trace và correlate logs giữa các services (như Application Insights), không phải để labeling pipelines hay grouping trong ADF monitoring. Nó chỉ hỗ trợ debugging runs, không phù hợp với yêu cầu.

🏆 Kết luận và khuyến nghị

✅ Sử dụng annotations là cách tối ưu và chính thức từ Microsoft để đạt yêu cầu. Để triển khai: Vào ADF Studio > Pipeline > Properties > Annotations > Thêm key-value. Sau đó, refresh Monitoring Hub để filter/group ngay!
📘 Tài liệu tham khảo chính:

• Monitor pipelines with annotations
• ADF Pipeline JSON Schema (cập nhật 2026).
  Nếu cần script ARM hoặc ví dụ code, hãy cho tôi biết nhé! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi:
Câu hỏi xoay quanh một truy vấn Transact-SQL (T-SQL) được thực thi trên SQL Server (hoặc Azure SQL Database/Managed Instance), sử dụng hệ thống view sys.database_files để lấy thông tin về các file dữ liệu và log của cơ sở dữ liệu hiện tại. Truy vấn này tính toán và hiển thị các cột như kích thước file, không gian đã sử dụng, và các thông tin liên quan khác.

Cụ thể:

• Truy vấn lấy dữ liệu từ sys.database_files, bao gồm các cột như file_id, type, physical_name, name, size, max_size, is_percent_growth, growth.
• Nó tính toán kích thước theo đơn vị MB bằng cách chia số trang (pages, mỗi page 8KB) cho 128 (vì 128 pages = 1MB).
• Sử dụng hàm FILEPROPERTY([name], 'SpaceUsed') để lấy không gian đã sử dụng thực tế của file (cũng theo pages).
• Câu hỏi chính: Cột nào trong kết quả truy vấn đại diện cho không gian trống (free space) trong mỗi file?

Truy vấn này rất hữu ích cho DBA để giám sát dung lượng file database, đặc biệt trong Azure SQL Database hoặc on-premises SQL Server. ✅

✅ Đáp án đúng: ColumnC
Lý do lựa chọn:
ColumnC được tính bằng công thức: (CAST([size] AS DECIMAL(38,0))/128.0) - (CAST(FILEPROPERTY([name], 'SpaceUsed') AS DECIMAL(38,0))/128.0).

• Đây chính là kích thước tổng (total size) trừ đi kích thước đã sử dụng (used space), nên đại diện cho không gian trống (free space) trong mỗi file, tính bằng MB.
• Công thức này chuẩn xác và được sử dụng phổ biến trong SQL Server để kiểm tra dung lượng khả dụng. 🛠️

📋 Giải thích tất cả các phương án (đúng/sai)

• ColumnA ❌ SAI
  ColumnA = CAST([size] as DECIMAL(38,0))/128.0. Đây là tổng kích thước file (total size) tính bằng MB, lấy từ cột size của sys.database_files (số pages đã cấp phát). Không phải free space, mà là toàn bộ dung lượng đã được allocate.

• ColumnB ❌ SAI
  ColumnB = CAST(FILEPROPERTY([name], 'SpaceUsed') AS DECIMAL(38,0))/128.0. Đây là không gian đã sử dụng thực tế (used space) trong file, tính bằng MB. Hàm FILEPROPERTY trả về số pages đang chứa dữ liệu thực, nên đây là phần đã chiếm dụng, không phải phần trống.

• ColumnC ✅ ĐÚNG
  ColumnC = (CAST([size] AS DECIMAL(38,0))/128.0) - (CAST(FILEPROPERTY([name], 'SpaceUsed') AS DECIMAL(38,0))/128.0). Như đã giải thích, đây là free space = total size - used space. Phương pháp này chính xác cho cả data files và log files trong SQL Server.

• ColumnD ❌ SAI
  ColumnD = [max_size]. Đây là kích thước tối đa (maximum size) mà file có thể phát triển đến (theo pages, hoặc -1 nếu không giới hạn). Nó không liên quan đến free space hiện tại, mà chỉ là giới hạn tăng trưởng.

📘 Tài liệu tham khảo (cập nhật đến 2026)

• sys.database_files: Microsoft Docs - sys.database_files (SQL Server) (áp dụng cho SQL Server 2022 và Azure SQL Database mới nhất).
• FILEPROPERTY: Microsoft Docs - FILEPROPERTY (Transact-SQL) (hỗ trợ 'SpaceUsed' cho không gian đã dùng).
• Kiến thức không thay đổi lớn từ SQL Server 2019-2022, vẫn chuẩn đến Azure SQL updates 2026. 🧰

Hy vọng phân tích này giúp bạn nắm vững cách giám sát database files! Nếu cần script mở rộng, hãy hỏi thêm nhé. 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi:
Câu hỏi mô tả tình huống bạn đang có một instance Microsoft SQL Server 2019 chạy on-premises (tại trung tâm dữ liệu nội bộ) với cơ sở dữ liệu DB1 có dung lượng lớn 4 TB. Bạn dự định di chuyển (migrate) DB1 sang Azure SQL Database Managed Instance – một dịch vụ quản lý toàn diện trên Azure, tương tự SQL Server on-prem nhưng được Azure quản lý tự động (bao gồm patching, backup, v.v.).
Mục tiêu chính là giảm thiểu thời gian downtime (thời gian hệ thống ngừng hoạt động) và mất mát dữ liệu (data loss) trong quá trình migration. Đây là kịch bản migration lớn (4 TB), đòi hỏi công cụ hỗ trợ online migration (di chuyển liên tục, đồng bộ hóa dữ liệu thời gian thực) để tránh gián đoạn kinh doanh.
🛠️ Bối cảnh kỹ thuật: Azure SQL Managed Instance hỗ trợ các phương pháp migration từ SQL Server on-prem như backup/restore (offline, downtime cao), log shipping, hoặc công cụ chuyên dụng cho online migration để đảm bảo tính liên tục.

✅ Đáp án đúng: Azure Database Migration Service
Lý do lựa chọn: Azure Database Migration Service (DMS) là công cụ chính thức của Microsoft được thiết kế dành riêng cho migration database từ on-premises SQL Server sang Azure SQL Managed Instance. Nó hỗ trợ online migration với chế độ continuous sync (đồng bộ liên tục qua transaction log replication), giúp giảm downtime xuống mức tối thiểu (chỉ cần cutover ngắn khi sẵn sàng) và gần như zero data loss cho database lớn như 4 TB. DMS tự động xử lý schema conversion, data movement, và ongoing replication. Đây là phương pháp được khuyến nghị mới nhất (cập nhật đến 2026) cho Azure SQL MI migrations.
📘 Tài liệu tham khảo: Microsoft Docs - Migrate SQL Server to Azure SQL Managed Instance using DMS (phiên bản mới nhất hỗ trợ DMS Premium tier cho large-scale migrations).

🔍 Giải thích tất cả các phương án (sử dụng kiến thức Azure cập nhật 2026)

• distributed availability groups ❌
  Phân tích sai: Đây là tính năng mở rộng của Always On Availability Groups (AG) trong SQL Server, cho phép thiết lập AG giữa các Windows Server Failover Cluster (WSFC) khác nhau (cross-domain hoặc cross-cluster). Nó dùng cho high availability (HA) giữa các site on-premises hoặc hybrid, không phải công cụ migration trực tiếp sang Azure SQL Managed Instance. Không hỗ trợ continuous sync tự động cho downtime thấp, và không tương thích đầy đủ với managed instance (Azure SQL MI không hỗ trợ WSFC truyền thống). Sử dụng sẽ phức tạp, không giảm thiểu downtime hiệu quả cho 4 TB DB.

• database mirroring ❌
  Phân tích sai: Database Mirroring là tính năng HA cũ (deprecated từ SQL Server 2012, hoàn toàn loại bỏ ở SQL Server 2022+), chỉ hỗ trợ asynchronous replication giữa principal và mirror database on-premises. Nó không hỗ trợ migration sang Azure SQL Managed Instance vì MI không chấp nhận mirroring endpoint trực tiếp, và quá trình failover sẽ gây downtime lớn (không continuous sync). Không phù hợp cho DB 4 TB do hiệu suất kém và đã lỗi thời.

• Always On Availability Group ❌
  Phân tích sai: Always On AG là giải pháp HA/read-scale cho SQL Server on-premises, hỗ trợ synchronous/asynchronous replication giữa các replica. Tuy có thể dùng hybrid AG để connect on-prem với Azure SQL MI (qua listener), nhưng không phải migration tool tối ưu. Nó yêu cầu cấu hình phức tạp (WSFC, endpoint), không tự động handle schema/data sync đầy đủ, và downtime vẫn cao khi cutover (không continuous như DMS). Microsoft khuyến nghị DMS thay thế cho migration, không dùng AG chính cho mục tiêu này.

• Azure Database Migration Service ✅
  Phân tích đúng: Như đã giải thích ở trên, DMS là lựa chọn lý tưởng với minimal downtime (online mode qua CDC - Change Data Capture replication) và zero data loss (transactional consistency). Hỗ trợ full schema/data migration, validation, và cutover tự động. Phù hợp hoàn hảo cho SQL Server 2019 → Azure SQL MI (2026 updates bao gồm hỗ trợ Gen2 hardware cho throughput cao hơn).
  🛠️ Lợi ích nổi bật: Tích hợp Azure Data Studio, hỗ trợ parallel data movement cho 4 TB DB, và monitoring qua Azure portal.

💡 Kết luận: Sử dụng Azure DMS đảm bảo migration mượt mà, an toàn cho môi trường production lớn. Nếu cần thực hiện, hãy kích hoạt DMS instance Premium để xử lý workload cao! 🚀

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📘 Nội dung câu hỏi:
Câu hỏi mô tả tình huống bạn đang quản lý nhiều cơ sở dữ liệu Azure SQL (Azure SQL databases) nằm trên cùng một máy chủ Azure SQL Database server, thuộc resource group có tên ResourceGroup1. Yêu cầu là phải thiết lập cảnh báo (alert) khi mức sử dụng CPU vượt quá 80% đối với bất kỳ database nào. Giải pháp phải áp dụng được cho các database mới được tạo thêm trên máy chủ Azure SQL đó. Câu hỏi hỏi về resource type (loại tài nguyên) cần sử dụng để tạo alert này.

🔍 Phân tích sâu: Đây là vấn đề liên quan đến Azure Monitor và metric alerts cho Azure SQL Database. Metric CPU percentage (%) là metric cấp độ database (per database), không phải cấp độ server tổng hợp. Để cảnh báo per database (kể cả tương lai), bạn cần tạo alert rule trên resource type phù hợp với metric này. Tuy nhiên, metric alerts thường yêu cầu chỉ định resource cụ thể; với các database mới, cần tạo alert thủ công hoặc sử dụng Azure Policy/Automation để tự động hóa (nhưng câu hỏi tập trung vào resource type cơ bản). Kiến thức dựa trên Azure SQL Database metrics cập nhật đến năm 2026 (Azure Monitor hỗ trợ metric CPU% vCores/DTU per db, không thay đổi cơ bản).

✅ Đáp án đúng: SQL Databases
Lý do chọn: Resource type SQL Databases (Microsoft.Sql/servers/databases) là nơi metric CPU percentage được hỗ trợ trực tiếp. Bạn có thể tạo alert rule trên từng database cụ thể để theo dõi CPU > 80%. Với các database mới trên cùng server, bạn có thể áp dụng template hoặc script (như Azure CLI/PowerShell) để mở rộng, phù hợp nhất với yêu cầu "apply to any additional databases". Không resource type nào khác hỗ trợ metric này một cách chính xác cho per-database alerting.

🛠️ Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm giải thích rõ ràng:

• Resource Groups ❌
  Giải thích sai: Resource Groups (nhóm tài nguyên) cho phép scope alert trên nhiều resource con, nhưng không hỗ trợ metric CPU% per database ở cấp độ group. CPU% chỉ tồn tại per database riêng lẻ, không aggregate ở RG. Không đáp ứng yêu cầu alert per db và cho db mới (phải tạo rule riêng).

• SQL Servers ❌
  Giải thích sai: SQL Servers (máy chủ logic Azure SQL, Microsoft.Sql/servers) có metrics như connections, deadlocks, nhưng không có metric CPU% per database. CPU trên server là tổng hợp (nếu elastic pool) hoặc không trực tiếp per db đơn lẻ. Không thể alert chính xác "for any database" vượt 80%, và không tự động apply cho db mới.

• SQL Databases ✅
  Giải thích đúng: Đây là resource type chính xác (Microsoft.Sql/servers/databases). Metric CPU percentage được thu thập per database, cho phép set threshold 80%. Bạn tạo alert rule trên resource cụ thể của từng db, và có thể scale cho db mới bằng automation (Azure Policy hoặc Logic Apps). Hoàn hảo khớp yêu cầu!

• SQL Virtual Machines ❌
  Giải thích sai: SQL Virtual Machines (Azure VM cài SQL Server, Microsoft.Compute/virtualMachines với extension SQL) dùng cho SQL Server on VM, không phải Azure SQL Database (PaaS). Metrics CPU là của VM tổng thể, không per Azure SQL db. Hoàn toàn không liên quan đến server Azure SQL PaaS.

📚 Tài liệu tham khảo

• Azure Docs chính thức (cập nhật 2024-2026): Metrics for Azure SQL Database – Xác nhận CPU% là metric per database.
• Azure Monitor Alerts: Create metric alerts for Azure SQL – Hướng dẫn tạo trên resource type SQL Databases.
• Server vs Database metrics: Azure SQL resource health and metrics – Phân biệt rõ per-db vs server-level.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần script tạo alert tự động, hãy hỏi thêm nhé!

🧩 Phân tích chi tiết câu hỏi

📘 Nội dung câu hỏi:
Câu hỏi xoay quanh tình huống bạn đang quản lý một cơ sở dữ liệu SQL Server (chạy trên Azure Virtual Machine) có tên DB1. Bạn xem Plan Summary (tóm tắt kế hoạch thực thi) cho query 1178902 qua hình ảnh biểu đồ. Biểu đồ hiển thị thời lượng thực thi (duration) tính bằng mili giây (ms) của từng lần chạy query theo thời gian (từ 12:00 AM đến 6:00 PM qua nhiều ngày).

🔍 Phân tích hình ảnh biểu đồ một cách kỹ lưỡng:

• Trục Y (dọc): Thời lượng thực thi từ 0 đến 25.000 ms.
• Trục X (ngang): Thời gian theo giờ qua các ngày (12:00 AM → 6:00 AM → 12:00 PM → 6:00 PM → lặp lại).
• Các điểm dữ liệu:
  • Điểm xanh lá (Plan 1221065): Luôn ở mức thấp nhất (gần 0 ms ở đầu và cuối biểu đồ, khoảng dưới 5.000 ms), cho thấy query chạy nhanh nhất.
  • Điểm đỏ đậm (Plan 1220907): Không được đề cập trực tiếp trong lựa chọn, nhưng có duration cao (khoảng 20.000-25.000 ms ở một số điểm).
  • Điểm đỏ nhạt (Plan 1220917): Duration trung bình-cao (khoảng 10.000-20.000 ms), chậm hơn plan xanh.
    Mục tiêu: Chọn hành động để đảm bảo query sử dụng execution plan chạy trong thời gian ngắn nhất (least amount of time), tức là plan có duration thấp nhất từ biểu đồ → Plan 1221065.

Câu hỏi kiểm tra kiến thức về Query Store trong SQL Server (tính năng theo dõi và quản lý execution plans), áp dụng trên Azure VM (tương tự on-premises, cập nhật đến SQL Server 2022/ Azure SQL 2026 không thay đổi cơ bản).

✅ Đáp án đúng: Force the query execution plan for plan 1221065.

Lý do lựa chọn (chi tiết):
🛠️ Plan 1221065 (màu xanh lá trên biểu đồ) có duration thấp nhất (gần 0-5.000 ms), chứng tỏ đây là plan tối ưu nhất cho query 1178902. Sử dụng lệnh sp_query_store_force_plan để force (ép buộc) SQL Server luôn dùng plan này, tránh query tự chọn plan kém (do parameter sniffing hoặc thống kê thay đổi).
✅ Kết quả: Query sẽ chạy nhanh hơn đáng kể, ổn định hiệu suất. Đây là best practice từ Microsoft cho Query Store (hỗ trợ từ SQL Server 2016+).

🧪 Giải thích tất cả các phương án (đúng/sai):

• ✅ [ĐÚNG] Force the query execution plan for plan 1221065.
  Như phân tích trên: Plan này có thời lượng thực thi ngắn nhất trên biểu đồ (xanh lá, <5.000 ms). Force plan qua Query Store đảm bảo query luôn dùng nó, giải quyết vấn đề biến động performance. Không ảnh hưởng cache khác, an toàn và chính xác.

• ❌ [SAI] Run the DBCC FREEPROCCACHE command.
  Lệnh này xóa toàn bộ plan cache trong SQL Server, buộc recompile tất cả query. Tuy có thể tạo plan mới nhanh hơn ngẫu nhiên, nhưng không đảm bảo chọn đúng Plan 1221065 (có thể lại chọn plan chậm như 1220917). Gây overhead lớn (downtime hiệu suất tạm thời), không phải giải pháp target cho vấn đề cụ thể này.

• ❌ [SAI] Force the query execution plan for plan 1220917.
  Plan 1220917 (đỏ nhạt trên biểu đồ) có duration cao (10.000-20.000 ms), chậm hơn plan xanh. Force plan này sẽ làm query chạy chậm hơn, trái ngược mục tiêu "least amount of time".

• ❌ [SAI] Disable parameter sniffing.
  Parameter sniffing là hiện tượng optimizer dùng giá trị tham số đầu tiên để tạo plan, gây plan kém cho giá trị khác. Disable (qua OPTION (OPTIMIZE FOR UNKNOWN)) có thể ổn định nhưng không chọn được plan cụ thể nhanh nhất như 1221065. Biểu đồ cho thấy vấn đề là plan selection, không chỉ sniffing; giải pháp này không target đúng và có thể làm chậm thêm.

📚 Tài liệu tham khảo (cập nhật đến 2026):

• Microsoft Docs - Query Store Force Plan: sp_query_store_force_plan (SQL Server 2022/Azure SQL Managed Instance 2026).
• Azure VM SQL Performance Tuning: Monitor performance with Query Store.
• Plan Summary Visualization: Tích hợp trong SQL Server Management Studio (SSMS) v19+ hoặc Azure Data Studio.

🛡️ Lời khuyên từ Azure DBA: Kích hoạt Query Store trước (ALTER DATABASE DB1 SET QUERY_STORE = ON), kiểm tra plan regression qua sys.query_store_plan trước khi force!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi tập trung vào việc thiết kế giải pháp backup cho cơ sở dữ liệu SQL Server được host trên Azure Virtual Machine (VM). Yêu cầu chính là:

• Trong trường hợp Azure regional outage (sự cố toàn bộ một vùng Azure, ví dụ region East US bị down hoàn toàn), phải có khả năng restore database từ backup.
• Giải pháp phải minimize costs (giảm thiểu chi phí tối đa).

🛠️ Bối cảnh kỹ thuật: Backup thường được lưu trữ trên Azure Storage Account. Azure cung cấp các tùy chọn redundancy (dư thừa dữ liệu) khác nhau để bảo vệ dữ liệu trước các loại sự cố: data center failure, availability zone outage, hoặc regional outage. Để chống regional outage, dữ liệu phải được replicate cross-region (sang vùng khác). Tuy nhiên, cần chọn loại rẻ nhất đáp ứng yêu cầu này (dựa trên phiên bản Azure Storage mới nhất đến 2026, không có thay đổi lớn về redundancy options cơ bản).

📘 Dẫn nguồn tham khảo:

• Azure Storage redundancy options (Microsoft Docs, cập nhật 2024-2026).
• Azure SQL VM backup best practices (khuyến nghị GRS cho cross-region recovery với chi phí thấp).

✅ Đáp án đúng: geo-redundant storage (GRS)

Lý do lựa chọn:
GRS replicate dữ liệu 6 lần (3 bản chính trong primary region + 3 bản trong secondary region cách xa ít nhất 300km). Trong regional outage, bạn có thể fail-over sang secondary region để restore backup mà không mất dữ liệu (RPO gần 0, RTO phụ thuộc failover). Chi phí thấp nhất so với RA-GRS vì không hỗ trợ read access từ secondary (chỉ cần cho backup restore, không cần read thường xuyên). Đây là lựa chọn tối ưu theo best practices Azure cho disaster recovery (DR) với ngân sách hạn chế. ✅

🔍 Phân tích tất cả các phương án (đúng/sai)

Dưới đây là giải thích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên khả năng chống regional outage và chi phí (thấp → cao: LRS < ZRS < GRS < RA-GRS).

• ❌ locally-redundant storage (LRS):
  Chỉ replicate 3 bản trong một data center duy nhất (không cross-AZ hay cross-region). Nếu regional outage xảy ra (toàn vùng down), backup sẽ mất hoàn toàn, không thể restore. Rẻ nhất nhưng không đáp ứng yêu cầu DR. ❌

• ❌ read-access geo-redundant storage (RA-GRS):
  Tương tự GRS nhưng thêm read access từ secondary region (cho phép đọc dữ liệu từ vùng phụ). Đáp ứng regional outage nhưng chi phí cao hơn GRS ~30-50% (do bandwidth và read fees). Không cần thiết cho backup (chỉ restore, không read thường xuyên), vi phạm yêu cầu minimize costs. ❌

• ❌ zone-redundant storage (ZRS):
  Replicate 3 bản across 3 availability zones trong cùng region. Chống AZ outage tốt nhưng không cross-region, nên regional outage sẽ làm mất toàn bộ backup, không restore được. Chi phí cao hơn LRS nhưng vẫn không đủ cho yêu cầu. ❌

• ✅ geo-redundant storage (GRS):
  (Như đã giải thích ở trên) Hoàn hảo cho regional outage với replication cross-region, chi phí tối ưu nhất trong các lựa chọn geo-redundant. ✅

🛡️ Lưu ý bổ sung: Sử dụng GRS kết hợp Azure Backup hoặc SQL Server native backup to URL. Để minimize costs hơn nữa, enable cool/archive tier cho backup lâu dài (theo Azure Storage lifecycle management, cập nhật 2026). Nếu cần tự động failover, kết hợp Azure Site Recovery.

🧩 Giải thích nội dung câu hỏi

Câu hỏi tập trung vào việc tối ưu hóa tempdb trong SQL Server 2019 chạy trên Azure Virtual Machine (VM) với hệ điều hành Windows Server 2019. Ban đầu, VM có cấu hình 4 vCPUs và 28 GB bộ nhớ. Sau đó, bạn scale up (mở rộng theo chiều dọc) VM lên 8 vCPUs và 64 GB bộ nhớ. Mục tiêu là đạt độ trễ thấp nhất (lowest latency) cho tempdb – một hệ thống database tạm thời quan trọng trong SQL Server, thường gặp vấn đề nghẽn (contention) trên các file dữ liệu mặc định.

Vấn đề cốt lõi: Tempdb sử dụng data files để phân tán workload (như sorting, hashing, temp tables), giúp giảm I/O contention và latency. Số lượng data files cần được điều chỉnh dựa trên số lượng logical processors (vCPUs) của VM để đạt hiệu suất tối ưu. Với việc scale up lên 8 vCPUs, cần xác định tổng số data files lý tưởng cho tempdb.

🛠️ Lưu ý kỹ thuật: Theo best practices mới nhất của Microsoft (cập nhật đến 2026), tempdb nên có 1 data file cho mỗi logical processor (vCPU) lên đến 8 files. Điều này giúp cân bằng workload đều trên các cores, giảm SGAM/PFS page contention, từ đó đạt lowest latency.

✅ Đáp án đúng: 8

Lý do lựa chọn: Với VM Azure đã scale up lên 8 vCPUs, khuyến nghị chính thức là tạo 8 data files cho tempdb (mỗi file tương ứng 1 vCPU). Số lượng này tối ưu hóa phân tán I/O, giảm latency đáng kể so với cấu hình mặc định (1 file). Nếu vượt quá 8 vCPUs, thêm files theo nhóm 4 (12, 16,...), nhưng ở đây chính xác 8 là lý tưởng. Điều này được áp dụng sau khi scale up, vì tempdb sẽ tự động tái cấu hình khi restart SQL Server hoặc VM.

📋 Phân tích tất cả các phương án

• 2
  ❌ Sai: Số lượng 2 files chỉ phù hợp với VM có 2 vCPUs hoặc ít hơn (giai đoạn ban đầu của câu hỏi). Với 8 vCPUs, 2 files sẽ gây contention cao (nhiều threads tranh chấp cùng file), dẫn đến latency tăng vọt do bottleneck I/O. Không đạt lowest latency.

• 4
  ❌ Sai: 4 files phù hợp với cấu hình ban đầu 4 vCPUs, nhưng sau scale up lên 8 vCPUs, số này không đủ để phân tán workload đều. Kết quả là một nửa vCPUs bị idle, gây imbalanced PAGELATCH waits và latency cao hơn so với 8 files.

• 8
  ✅ Đúng: Như đã giải thích ở trên, 8 data files khớp chính xác với 8 vCPUs, đảm bảo mỗi vCPU có 1 file riêng, giảm contention xuống mức thấp nhất. Best practice từ Microsoft cho Azure SQL Server VMs.

• 64
  ❌ Sai: 64 files quá nhiều (bằng dung lượng RAM), gây overhead quản lý cao (metadata overhead, file growth coordination). Không khuyến nghị, dẫn đến performance kém hơn do fragmentation và I/O waste, hoàn toàn không đạt lowest latency.

📘 Tài liệu tham khảo

• Microsoft Docs chính thức (cập nhật 2024-2026): Performance best practices for SQL Server on Azure VMs – Khuyến nghị rõ ràng về tempdb files dựa trên vCPUs.
• SQL Server Tempdb Best Practices: Tempdb database – Xác nhận quy tắc 1 file/vCPU lên đến 8.
• Azure VM Scaling Guide: Scale Azure VMs – Scale up yêu cầu tái cấu hình SQL Server để tận dụng resources mới.

🛠️ Khuyến nghị thực tế: Sau scale up, restart SQL Server, tạo files kích thước bằng nhau (equal size), enable Trace Flag 1117/1118 để tránh auto-growth issues, và monitor qua DMVs như sys.dm_db_file_space_usage. Nếu workload nặng, test với SQL Server 2022 cho cải tiến tempdb hash partitioning!

🧩 Phân tích chi tiết nội dung câu hỏi

Câu hỏi thuộc dạng series questions trong kỳ thi chứng chỉ (như AZ-305 hoặc DP-203), nơi mỗi câu đưa ra một kịch bản giống nhau nhưng giải pháp khác nhau. Người dùng KHÔNG thể quay lại câu hỏi sau khi trả lời, nên cần chọn cẩn thận.

Kịch bản chính (Goal):

• Bạn có tài khoản Azure Data Lake Storage chứa staging zone (vùng tạm lưu dữ liệu).
• Cần thiết kế quy trình hàng ngày để:
  1. Ingest incremental data (hấp thụ dữ liệu tăng dần, chỉ phần mới từ staging zone).
  2. Transform data bằng cách thực thi R script (chuyển đổi dữ liệu thông qua script ngôn ngữ R).
  3. Insert transformed data vào data warehouse trong Azure Synapse Analytics.

Giải pháp đề xuất (Solution):
Sử dụng Azure Data Factory (ADF) schedule trigger để kích hoạt pipeline hàng ngày, pipeline này thực thi mapping data flow để chuyển đổi dữ liệu, sau đó chèn vào data warehouse.

Câu hỏi: Giải pháp này có đạt mục tiêu (meet the goal) không?

📘 Tài liệu tham khảo:

• Azure Data Factory Mapping Data Flows (cập nhật 2024-2026: Không hỗ trợ R scripts trực tiếp).
• Azure Synapse Analytics R Support (chỉ hỗ trợ R qua SQL Pool sp_execute_external_script hoặc Spark với custom).
• ADF Triggers & Pipelines (phiên bản mới nhất 2026: Schedule trigger hỗ trợ daily, nhưng transformation giới hạn).

✅ Đáp án đúng: No

Lý do chọn đáp án đúng:
Giải pháp KHÔNG đạt mục tiêu vì mapping data flow trong ADF chỉ hỗ trợ transformation qua giao diện trực quan (expressions, transformations như aggregate, join), KHÔNG thể thực thi R script để transform dữ liệu. Yêu cầu bắt buộc dùng R script, nhưng mapping data flow chỉ hỗ trợ Python (qua Custom transformation từ 2023) hoặc Scala/Spark SQL, không có R. Quy trình ingest incremental và insert vào Synapse là OK (qua sink activity), nhưng phần transform sai hoàn toàn. 🛠️ Để đúng, cần dùng Synapse Pipeline với Spark job (custom R via external script) hoặc SQL Pool stored procedure gọi sp_execute_external_script.

📋 Giải thích tất cả các phương án

• Yes ❌ SAI: Phương án này cho rằng giải pháp đạt mục tiêu, nhưng mapping data flow không hỗ trợ execute R script. Nó chỉ dùng visual data transformations (không code-based như R). Dù schedule trigger chạy daily và ingest/insert OK, phần transform thiếu R → KHÔNG meet the goal.
• No ✅ ĐÚNG: Giải pháp KHÔNG đáp ứng vì thiếu khả năng thực thi R script trong mapping data flow. Cần giải pháp khác như: ADF gọi Synapse Notebook (R support via ML runtime) hoặc Stored Procedure trong Synapse SQL Pool. Điều này phù hợp kiến thức Azure 2026, nơi ADF tập trung visual ETL còn R thuộc Synapse/ML services.

🧩 Gợi ý giải pháp đúng (không phải câu hỏi): Sử dụng ADF pipeline với Execute Pipeline activity gọi Synapse Spark Notebook chạy R script, kết hợp Copy activity cho incremental ingest (qua watermark/delta).

🧩 Phân tích chi tiết câu hỏi trắc nghiệm

📖 Nội dung câu hỏi:
Câu hỏi mô tả tình huống bạn đang quản lý SQL Server chạy trên Azure Virtual Machines (VMs), với một Always On Availability Group (AG) đã được thiết lập. Có một cơ sở dữ liệu tên DB1 KHÔNG thuộc AG này. Bạn đã tạo bản sao lưu đầy đủ (full database backup) của DB1. Bây giờ, nhiệm vụ là thêm DB1 vào AG, và câu hỏi tập trung vào tùy chọn restore nào phải sử dụng trên secondary replica (bản sao phụ) để thực hiện điều này một cách chính xác.

🛠️ Quy trình thêm database vào AG trên Azure SQL Server VMs:

• Trên primary replica: Backup full + transaction log của DB1.
• Trên secondary replica: Restore các backup đó với trạng thái phù hợp để database ở chế độ restoring (sẵn sàng nhận log và sync dữ liệu từ primary).
• Sau đó, sử dụng lệnh ALTER AVAILABILITY GROUP để join DB1 vào AG.
  Đây là quy trình chuẩn của Always On Availability Groups trong SQL Server (áp dụng cho Azure VMs, không thay đổi đến SQL Server 2022/2026).

✅ Đáp án đúng: Restore with Norecovery
Lý do chọn đáp án này:
Khi thêm database vào AG, secondary replica phải restore backup full (và sau đó là log backups) với NORECOVERY để database ở trạng thái RESTORING. Trạng thái này cho phép secondary nhận và áp dụng transaction log từ primary, đảm bảo sync dữ liệu liên tục. Nếu dùng RECOVERY hoặc STANDBY, database sẽ không ở trạng thái phù hợp để join AG. Quy trình này được Microsoft khuyến nghị chính thức cho Azure SQL IaaS (VMs).

🔍 Giải thích chi tiết từng phương án trả lời

• Restore with Recovery ❌ (Sai)
  Phương án này đưa database về trạng thái ONLINE (có thể truy cập đọc/ghi ngay lập tức). Tuy nhiên, trong AG, secondary replica KHÔNG THỂ ở trạng thái online vì nó chỉ dùng để sync dữ liệu từ primary. Nếu restore với RECOVERY, bạn không thể join database vào AG (sẽ báo lỗi). Phù hợp cho restore độc lập, không phải AG.

• Restore with Norecovery ✅ (Đúng)
  Phương án này giữ database ở trạng thái RESTORING (không online, chờ log tiếp theo). Đây chính là yêu cầu bắt buộc trên secondary replica để:

  • Nhận transaction log backup từ primary.
  • Thực hiện JOIN database vào AG qua T-SQL (ví dụ: ALTER DATABASE [DB1] SET HADR AVAILABILITY GROUP = [AGName];).
    Hoàn hảo cho Always On AG trên Azure VMs!

• Restore with Standby ❌ (Sai)
  Phương án này restore database ở trạng thái STANDBY (read-only, nhưng rollback khi áp dụng log mới). Nó dùng chủ yếu cho Log Shipping (không phải AG), vì AG yêu cầu trạng thái RESTORING thuần túy để sync real-time. Sử dụng STANDBY sẽ gây lỗi khi join AG trên secondary.

📘 Tài liệu tham khảo (cập nhật mới nhất đến 2026)

• Microsoft Docs chính thức: Add a database to an Always On availability group (SQL Server) – Xác nhận rõ ràng "RESTORE DATABASE ... WITH NORECOVERY".
• Azure SQL VM AG Guide: Always On availability groups on SQL Server on Azure VMs – Quy trình không thay đổi ở SQL Server 2022.
• SQL Server 2022 Docs: Không có cập nhật lớn về restore options cho AG đến 2026.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần demo T-SQL cụ thể, hãy hỏi thêm nhé! 😊