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 này thuộc về Azure Data Factory (ADF) – một dịch vụ ETL (Extract, Transform, Load) của Microsoft Azure dùng để quản lý và điều phối các pipeline dữ liệu.

📋 Tình huống cụ thể:

• Có 4 pipelines:
  • Ingest Data from System1 (hút dữ liệu từ Hệ thống 1).
  • Ingest Data from System2 (hút dữ liệu từ Hệ thống 2) – hai pipeline này không có phụ thuộc lẫn nhau (chạy độc lập).
  • Populate Dimensions (điền dữ liệu vào bảng Dimensions) – phải chạy SAU khi cả hai pipeline Ingest hoàn thành.
  • Populate Facts (điền dữ liệu vào bảng Facts) – phải chạy SAU khi Populate Dimensions hoàn thành.
• Yêu cầu chung: Tất cả pipelines phải chạy định kỳ mỗi 8 giờ (every eight hours).

🛠️ Vấn đề cần giải quyết: Làm thế nào để lập lịch thực thi (schedule) các pipelines này sao cho tuân thủ thứ tự phụ thuộc (dependencies) và chạy lặp lại đúng chu kỳ thời gian. Trong ADF, để xử lý dependencies giữa pipelines, ta thường dùng parent-child pipeline (pipeline cha chứa các activity "Execute Pipeline" để gọi pipeline con theo thứ tự). Triggers dùng để kích hoạt: Schedule trigger (lập lịch định kỳ) hoặc Event trigger (kích hoạt bởi sự kiện).

🎯 Mục tiêu: Chọn cách triển khai đúng để đảm bảo thứ tự thực thi và lịch chạy định kỳ.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create a parent pipeline that contains the four pipelines and use a schedule trigger.

Lý do (dựa trên tài liệu Azure Data Factory phiên bản mới nhất 2024-2026):

• 🛠️ Tạo parent pipeline chứa các activity Execute Pipeline để gọi lần lượt: Ingest1 và Ingest2 song song (dùng ForEach hoặc parallel execution), sau đó Populate Dimensions, rồi Populate Facts → đảm bảo thứ tự dependencies.
• 📅 Sử dụng schedule trigger (hoặc tumbling window trigger nâng cao) gắn vào parent pipeline để chạy định kỳ mỗi 8 giờ (ví dụ: recurrence mỗi 8h).
• ✅ Cách này hiệu quả, scalable, và phù hợp với best practices ADF cho orchestration phức tạp.

Nguồn tham khảo:

• 📘 Azure Data Factory Triggers (cập nhật 2024).
• 📘 Pipeline Orchestration & Dependencies (ví dụ parent-child).
• 📘 Schedule Trigger Docs (hỗ trợ every X hours).

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

• E ❌ Phương án SAI: Add a schedule trigger to all four pipelines.
  Lý do sai: Mặc dù schedule trigger có thể làm các pipeline chạy mỗi 8 giờ, nhưng không đảm bảo thứ tự dependencies. Ingest1 và Ingest2 có thể chạy muộn, dẫn đến Populate Dimensions chạy trước khi dữ liệu sẵn sàng → vi phạm yêu cầu "Populate Dimensions must execute after...". Không có cơ chế orchestration giữa các pipeline độc lập.

• E ❌ Phương án SAI: Add an event trigger to all four pipelines.
  Lý do sai: Event trigger kích hoạt dựa trên sự kiện (như file mới trong Blob Storage), không phù hợp cho lịch định kỳ mỗi 8 giờ. Hơn nữa, vẫn không xử lý dependencies giữa pipelines → có thể chạy lệch thứ tự hoặc không chạy đúng chu kỳ thời gian.

• E ❌ Phương án SAI: Create a parent pipeline that contains the four pipelines and use an event trigger.
  Lý do sai: Parent pipeline đúng để enforce dependencies (qua Execute Pipeline activities), nhưng event trigger không hỗ trợ lịch định kỳ mỗi 8 giờ → chỉ chạy khi có sự kiện cụ thể (ví dụ: file arrival). Không đáp ứng "all pipelines must execute every eight hours".

• A ✅ Phương án ĐÚNG: Create a parent pipeline that contains the four pipelines and use a schedule trigger.
  (Giải thích chi tiết như phần trên: Kết hợp orchestration + scheduling định kỳ → hoàn hảo cho scenario này).

🧩 Kết luận: Cách tiếp cận parent pipeline với schedule trigger là best practice trong ADF để xử lý ETL workflows có dependencies và recurring jobs (cập nhật đến 2026 vẫn giữ nguyên). Nếu triển khai thực tế, dùng Azure Portal/Studio để thiết kế! 🚀

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

Câu hỏi này xoay quanh việc triển khai chiến lược sao lưu (backup strategy) cho 10 máy ảo Azure (Azure Virtual Machines - VMs) đã cài đặt SQL Server. Yêu cầu cụ thể bao gồm:

• Có thể khôi phục (restore) các cơ sở dữ liệu cụ thể (specific databases) đến các instance SQL Server khác (không nhất thiết trên cùng VM gốc).
• Đảm bảo quản lý tập trung (centralized management) cho các bản sao lưu từ nhiều VM.

🛠️ Bối cảnh chính: Đây là tình huống thực tế trong môi trường Azure, nơi cần sao lưu dữ liệu SQL Server trên VMs để hỗ trợ khôi phục linh hoạt (point-in-time restore cho từng database riêng lẻ) và quản lý từ một nơi duy nhất, thay vì sao lưu thủ công hoặc phân tán. Kiến thức dựa trên phiên bản Azure Backup mới nhất (cập nhật đến 2026), hỗ trợ SQL Server trên Azure VMs qua Recovery Services vault với tính năng Application-consistent backups cho SQL.

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

• Azure Backup for SQL Server in Azure VMs (Microsoft Docs, cập nhật 2025).
• Centralized backup management with Azure Backup (hỗ trợ multi-VM và granular restore).

✅ Đáp án đúng: Azure Backup

Lý do lựa chọn:
Azure Backup là giải pháp lý tưởng vì nó cung cấp sao lưu nhất quán ứng dụng (application-consistent backups) cho SQL Server trên Azure VMs, cho phép khôi phục granular (specific databases) đến bất kỳ SQL Server instance nào khác (item-level restore). Đồng thời, nó hỗ trợ quản lý tập trung qua Recovery Services vault, nơi bạn có thể theo dõi, lập lịch và khôi phục từ một console duy nhất cho tất cả 10 VMs. Tính năng này đã được nâng cấp đến năm 2026 với hỗ trợ long-term retention và cross-subscription management. ✅

🛠️ 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/sai dựa trên yêu cầu câu hỏi:

• ❌ Automated Backup in the SQL virtual machine settings
  Phương án này SAI vì chỉ là tính năng tự động sao lưu toàn bộ instance SQL hoặc VM qua extension SQL VM (Azure SQL VM Agent), không hỗ trợ khôi phục specific databases một cách linh hoạt đến instance khác. Quản lý cũng không tập trung (phải cấu hình riêng từng VM), và không có vault trung tâm như Azure Backup. Phù hợp cho backup cơ bản nhưng thiếu granular restore.

• ✅ Azure Backup
  Phương án này ĐÚNG như đã giải thích ở trên. Nó đáp ứng đầy đủ: sao lưu application-consistent cho SQL, restore specific databases (qua portal hoặc PowerShell), và centralized management cho nhiều VMs qua một vault. Hỗ trợ chính xác yêu cầu "restore to other SQL Server instances".

• ❌ Azure Site Recovery
  Phương án này SAI vì Azure Site Recovery (ASR) dành cho disaster recovery và replication VMs (khôi phục toàn bộ VM/site), không phải sao lưu databases cụ thể. Nó không hỗ trợ granular database restore hay centralized backup management cho SQL data. ASR tập trung vào failover VMs, không phải backup strategy.

• ❌ SQL Server Agent jobs
  Phương án này SAI vì SQL Server Agent chỉ cho phép tạo jobs sao lưu thủ công/tự động cục bộ trên từng instance (như BACKUP DATABASE T-SQL), thiếu centralized management cho 10 VMs và không dễ dàng restore specific DBs đến instance khác mà không cần script phức tạp. Không tích hợp native với Azure cho multi-VM.

🧩 Kết luận: Azure Backup là lựa chọn tối ưu, giúp DBA quản lý hiệu quả môi trường SQL trên Azure VMs với tính linh hoạt cao và chi phí hợp lý! Nếu cần triển khai thực tế, hãy sử dụng Azure Portal để tạo Policy cho SQL workloads. 🚀

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

Câu hỏi này thuộc chủ đề AWS RDS (Relational Database Service), cụ thể là tình huống failover trong cấu hình Multi-AZ Deployment cho một cơ sở dữ liệu SQL Server tên là SalesSQLDb1.

• Bối cảnh: SalesSQLDb1 là một RDS instance (hoặc DB cluster) được triển khai Multi-AZ để đảm bảo tính sẵn sàng cao. Khi xảy ra sự cố (như primary instance lỗi), AWS tự động thực hiện failover sang standby instance (trở thành primary mới).
• Vấn đề cần giải quyết: Sau failover, ứng dụng SalesSQLDb1App1 (một ứng dụng kết nối đến database này) có thể gặp vấn đề truy cập. Câu hỏi yêu cầu hành động cần thiết nhất để đảm bảo database vẫn accessible (có thể truy cập được) từ ứng dụng.
• Mục tiêu: Xác định bước tiếp theo để ứng dụng tiếp tục kết nối mà không gián đoạn lâu dài, dựa trên cơ chế DNS failover của AWS RDS (endpoint DNS sẽ tự động resolve đến primary instance mới sau khoảng 60-120 giây).
  ✅ Phiên bản AWS cập nhật đến 2026: RDS Multi-AZ (bao gồm SQL Server) vẫn sử dụng cơ chế failover tự động với endpoint ổn định, nhưng ứng dụng cần refresh connection strings để tránh cache IP cũ (theo tài liệu AWS RDS 2024-2026).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Update the connection strings of SalesSQLDb1App1.
🛠️ Lý do chi tiết:
Sau failover, RDS endpoint (ví dụ: salessqldb1.abcdef123.us-east-1.rds.amazonaws.com) vẫn giữ nguyên, nhưng DNS record sẽ cập nhật để trỏ đến primary instance mới. Tuy nhiên, ứng dụng SalesSQLDb1App1 có thể đang sử dụng IP cũ được cache trong connection pool hoặc connection string cứng. Việc cập nhật connection strings (thay đổi timeout, retry logic, hoặc refresh DNS) đảm bảo ứng dụng kết nối ngay lập tức đến endpoint mới, tránh downtime. Đây là best practice của AWS để xử lý post-failover connectivity.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết:

• Configure SalesSQLDb1 as writable.
  ❌ Sai: Sau failover tự động của RDS Multi-AZ, standby instance đã tự động trở thành writable primary ngay lập tức (không cần cấu hình thủ công). Việc này được AWS xử lý tự động, không phải hành động cần thiết để đảm bảo accessibility từ app.

• Update the connection strings of SalesSQLDb1App1.
  ✅ Đúng: Như đã giải thích ở trên, đây là bước cần thiết nhất để ứng dụng refresh kết nối, xử lý DNS propagation và tránh lỗi "host unreachable" do cache IP cũ. AWS khuyến nghị implement retry logic trong connection strings post-failover.

• Update the firewall rules of SalesSQLDb1.
  ❌ Sai: Firewall rules (Security Groups hoặc VPC rules) được gắn với DB instance hoặc DB subnet group, và chúng được replicate tự động trong Multi-AZ. Failover không thay đổi rules, nên không cần update để đảm bảo app truy cập.

• Update the users in SalesSQLDb1.
  ❌ Sai: Trong RDS Multi-AZ cho SQL Server, users và permissions được sync asynchronously giữa primary và standby qua replication. Sau failover, users vẫn hợp lệ trên primary mới, không yêu cầu update thủ công trừ khi có thay đổi đặc biệt (không liên quan đến accessibility cơ bản).

📘 Tài liệu tham khảo

• AWS RDS Documentation: Failover for Amazon RDS SQL Server Multi-AZ (cập nhật 2025).
• AWS Best Practices: Connection Management After Failover – Nhấn mạnh update app connection strings.
• AWS re:Post & Blogs 2024-2026: Các case study về RDS failover khuyến nghị retry và DNS refresh trong app code.

🛠️ Lời khuyên từ Azure DBA: Dù là AWS, tương tự Azure SQL Managed Instance Always On, luôn test failover và dùng connection resiliency libraries (như Microsoft.Data.SqlClient với resiliency patterns)!

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

Câu hỏi này thuộc ngữ cảnh quản trị cơ sở dữ liệu trên Microsoft Azure SQL Database, tập trung vào việc đánh giá mục tiêu kinh doanh (business goals). Cụ thể, bạn đang cần một tính năng để cung cấp mức độ truy cập phù hợp cho khách hàng dựa trên thỏa thuận dịch vụ (service agreement) của họ.
📌 Ý nghĩa cốt lõi: Thỏa thuận dịch vụ thường quy định quyền xem dữ liệu cụ thể (ví dụ: khách hàng A chỉ xem dữ liệu của mình, khách hàng B xem dữ liệu mở rộng hơn). Tính năng cần chọn phải kiểm soát truy cập tại mức hàng dữ liệu (row-level), đảm bảo bảo mật và tuân thủ mà không ảnh hưởng đến hiệu suất tổng thể. Đây là kịch bản phổ biến trong môi trường đa tenant (nhiều khách hàng chia sẻ database).

✅ Đáp án đúng: row-level security (RLS)

Lý do lựa chọn:
Row-level security (RLS) là tính năng mạnh mẽ nhất trong Azure SQL Database để kiểm soát truy cập dữ liệu theo từng hàng dựa trên thông tin người dùng (như user ID, role, hoặc điều kiện tùy chỉnh liên kết với service agreement). Nó sử dụng security predicates (hàm lọc và block) để tự động ẩn các hàng không được phép, đảm bảo khách hàng chỉ thấy dữ liệu phù hợp mà không cần thay đổi ứng dụng.
🛠️ Ưu điểm cập nhật (tính đến 2026): Hỗ trợ tích hợp với Azure AD authentication, hiệu suất cao với indexed views, và dễ quản lý qua T-SQL. Phù hợp hoàn hảo cho business goals đa khách hàng.
📘 Nguồn tham khảo:

• Microsoft Docs: Row-level security (Azure SQL Database) (cập nhật 2024, vẫn chuẩn đến 2026).
• Azure SQL Security Best Practices.

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

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á dựa trên chức năng thực tế trong Azure SQL Database và Azure ecosystem (phiên bản mới nhất 2026):

• ❌ dynamic data masking
  Phương án này sai vì dynamic data masking chỉ che giấu (mask) dữ liệu nhạy cảm bằng cách thay thế giá trị thực (ví dụ: email thành xxx@xxx.com) cho người dùng không đủ quyền, nhưng không kiểm soát truy cập theo hàng dữ liệu. Khách hàng vẫn thấy tất cả các hàng, chỉ là dữ liệu bị mờ đi. Không phù hợp với service agreement yêu cầu "level of access" cụ thể (vẫn cho phép liệt kê hàng).
  🛠️ Ứng dụng thực tế: Dùng cho bảo vệ PII (Personally Identifiable Information), không phải phân quyền theo hợp đồng.

• ❌ Conditional Access in Azure
  Phương án này sai vì Conditional Access thuộc Azure AD (Entra ID), dùng để kiểm soát truy cập vào tài nguyên Azure dựa trên điều kiện như vị trí, thiết bị, hoặc risk level (ví dụ: yêu cầu MFA từ IP lạ). Nó không hoạt động ở mức dữ liệu database (row-level), mà chỉ ở authentication/authorization cấp cao. Không giải quyết được việc phân quyền dữ liệu theo service agreement trong SQL Database.
  🛠️ Ứng dụng thực tế: Bảo mật truy cập ứng dụng Azure, không phải nội dung dữ liệu.

• ❌ service principals
  Phương án này sai vì service principals là đối tượng identity trong Azure AD dùng cho ứng dụng/dịch vụ xác thực không tương tác (non-interactive), cấp quyền qua RBAC (Role-Based Access Control). Nó không cung cấp kiểm soát chi tiết theo hàng dữ liệu hoặc tùy chỉnh theo service agreement của khách hàng. Chỉ là cơ chế xác thực, không phải feature bảo mật dữ liệu.
  🛠️ Ứng dụng thực tế: Dùng cho automation như Azure Functions truy cập SQL, không phù hợp business goals đa khách hàng.

• ✅ row-level security (RLS)
  Như đã giải thích ở trên, đây là đúng vì trực tiếp đáp ứng yêu cầu: phân quyền truy cập theo hàng dựa trên predicate functions, dễ dàng map với service agreement (ví dụ: WHERE CustomerID = SESSION_CONTEXT(N'CustomerID')). Hiệu suất tối ưu, tích hợp native với Azure SQL (hỗ trợ Always Encrypted và Ledger đến 2026).
  📘 Nguồn: Như phần đáp án đúng.

🧩 Kết luận: RLS là lựa chọn tối ưu cho Azure DBA trong kịch bản này, giúp cân bằng bảo mật và kinh doanh. Nếu cần triển khai thực tế, hãy dùng T-SQL để tạo policy! 🚀

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

📘 Nội dung câu hỏi:
Câu hỏi xoay quanh một cơ sở dữ liệu Azure SQL chứa bảng factSales với 6 tỷ rows (rows), được tải dữ liệu hàng đêm qua quy trình batch (batch process). Bảng này có các cột như hình ảnh mô tả:

• SalesID: kiểu dữ liệu Int (số nguyên 4 bytes).
• Product: kiểu dữ liệu Int (số nguyên 4 bytes).
• Total Number: kiểu dữ liệu Numeric(8,4) (số thập phân chính xác, độ chính xác 8 chữ số, 4 sau dấu phẩy).
• Tax Number: kiểu dữ liệu Numeric(8,4) (tương tự Total Number).
• SalesRep: kiểu dữ liệu Varchar(30) (chuỗi ký tự biến đổi, tối đa 30 ký tự).

🛠️ Yêu cầu chính: Cung cấp loại compression (nén dữ liệu) mang lại giảm không gian lưu trữ lớn nhất (greatest reduction in space) đồng thời tối ưu hiệu suất (maximize performance). Đây là tình huống điển hình của data warehouse (kho dữ liệu) với bảng fact lớn, ít thay đổi (chỉ load nightly), phù hợp với phân tích dữ liệu lớn (analytics). Hình ảnh minh họa rõ ràng cấu trúc bảng là fact table với dữ liệu số học và chuỗi ngắn, không có cột LOB lớn, nên compression columnar sẽ hiệu quả cao.

✅ Đáp án đúng: columnstore archival compression
Lý do lựa chọn (dựa trên kiến thức Azure SQL cập nhật đến 2026):
Loại nén này kết hợp columnstore index (lưu trữ theo cột, nén dữ liệu lặp lại hiệu quả với tỷ lệ lên đến 10x so với rowstore) và archival compression (mức nén mạnh nhất, sử dụng thuật toán nén bổ sung như MS-XPRESS hoặc tương đương, lý tưởng cho dữ liệu ít truy cập như archival). Với 6 tỷ rows, dữ liệu số (Int, Numeric) lặp lại cao và chuỗi ngắn (Varchar(30)), archival compression giảm space tối đa (có thể >75% so với row/page), đồng thời tăng performance query analytics lên 10-100x nhờ vectorized processing. Phù hợp nightly load (batch insert vào columnstore). Đây là khuyến nghị chính thức từ Microsoft cho large fact tables trong Azure SQL Database và Synapse Analytics (phiên bản mới nhất SQL Server 2022/Azure SQL 2026).

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

• ❌ page compression
  Phương án này áp dụng nén page-level (nén prefix + dictionary trên mỗi page 8KB), hiệu quả hơn row compression (giảm ~40-60% space với dữ liệu lặp). Tuy nhiên, với 6 tỷ rows fact table kiểu analytics, nó kém hơn columnstore vì vẫn lưu row-oriented (hàng ngang), không tận dụng lặp dữ liệu theo cột, dẫn đến space reduction thấp hơn và performance query chậm hơn trên large scans.

• ❌ row compression
  Phương án cơ bản nhất, nén row-level (sử dụng variable-length storage, bỏ padding cho fixed-length types như Int/Numeric). Giảm space ~20-40% với bảng có Int/Varchar, nhưng không có prefix/dictionary hay columnar storage, nên không phải greatest reduction – đặc biệt kém với 6 tỷ rows dữ liệu lặp (như Product/SalesID), và performance query không cải thiện nhiều cho analytics.

• ❌ columnstore compression
  Nén theo columnstore index (lưu columnar segments, nén dictionary + RLE/BitMap, giảm space ~5-10x cho fact tables). Rất tốt cho performance (query nhanh hơn rowstore), nhưng không phải mức cao nhất vì thiếu archival layer – archival thêm nén mạnh cho cold data, giảm space thêm 2-5x nữa (tùy dữ liệu).

• ✅ columnstore archival compression
  Đúng tuyệt đối như đã giải thích: Kết hợp columnstore + archival (ALTER TABLE ... REBUILD WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE)). Giảm space lớn nhất (lên đến 15x+ với dữ liệu số lặp như bảng này), performance tối ưu cho read-heavy workload nightly load. Hình ảnh xác nhận dữ liệu phù hợp (Int/Numeric lặp cao, Varchar ngắn).

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

• Microsoft Docs - Data Compression: Data compression in Azure SQL – So sánh row/page/columnstore/archival.
• Columnstore Indexes Overview: Columnstore indexes – Archival cho greatest space savings (SQL Server 2022+/Azure SQL).
• Azure SQL Best Practices: Compression for analytics – Khuyến nghị archival cho large fact tables >1B rows.

🛠️ Lời khuyên DBA: Để áp dụng, dùng ALTER TABLE factSales REBUILD WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE); và monitor qua DMVs như sys.dm_db_index_physical_stats. Test trên dev trước vì rebuild tốn thời gian với 6B rows!

🧩 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 triển khai một cơ sở dữ liệu trên Azure SQL Database Managed Instance (một dịch vụ quản lý toàn diện của Azure, tương tự SQL Server on-premises nhưng được Azure quản lý).
Vấn đề cần giải quyết: Ngăn chặn các truy vấn đọc (read queries) chặn các truy vấn ghi (write queries) vào cơ sở dữ liệu.

• Trong SQL Server/Azure SQL, hiện tượng blocking xảy ra khi các giao dịch đọc (SELECT) sử dụng isolation level READ COMMITTED mặc định giữ shared locks trên dữ liệu đang đọc, dẫn đến chặn các giao dịch ghi (INSERT/UPDATE/DELETE) phải chờ lock được giải phóng.
• Mục tiêu là kích hoạt cơ chế row versioning (phiên bản hóa hàng) để reads và writes có thể song song mà không block lẫn nhau.
  ✅ Câu hỏi yêu cầu thiết lập một tùy chọn cơ sở dữ liệu (database option) cụ thể để khắc phục vấn đề này, dựa trên tính năng của Azure SQL Managed Instance (cập nhật đến 2026, hỗ trợ đầy đủ snapshot isolation).

✅ Đáp án đúng: READ_COMMITTED_SNAPSHOT to ON

• Lý do chọn: Tùy chọn này kích hoạt snapshot isolation cho isolation level READ COMMITTED, sử dụng row versioning trong tempdb để reads lấy dữ liệu từ phiên bản nhất quán tại thời điểm bắt đầu giao dịch, thay vì giữ shared locks. Kết quả:
  • Reads không block writes (và writes không block reads).
  • Giảm blocking đáng kể mà không cần thay đổi isolation level của ứng dụng.
  • Áp dụng ngay lập tức sau khi ALTER DATABASE SET READ_COMMITTED_SNAPSHOT ON;.
    🛠️ Lưu ý: Chỉ áp dụng cho toàn bộ database, yêu cầu không có active connections lúc set. Đây là giải pháp chuẩn của Microsoft cho vấn đề blocking read-write (phiên bản mới nhất Azure SQL Managed Instance 2026 vẫn giữ nguyên).

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

• ❌ PARAMETERIZATION to FORCED
  Sai vì tùy chọn này buộc parameterize tất cả truy vấn để tái sử dụng execution plan và tránh SQL injection. Nó không ảnh hưởng đến locking mechanism hay blocking giữa read/write, chỉ liên quan đến query optimization.

• ❌ PARAMETERIZATION to SIMPLE
  Sai vì thiết lập này cho phép ad-hoc queries (không parameterize), dẫn đến plan cache lớn hơn và ít reuse. Không liên quan gì đến việc ngăn blocking read-write, chỉ ảnh hưởng đến performance của query parsing.

• ❌ Delayed Durability to Forced
  Sai vì tùy chọn này buộc delayed durability (ghi log vào disk sau commit, không chờ flush), nhằm tăng throughput commit transaction. Nó cải thiện performance write nhưng không giải quyết blocking giữa read và write, thậm chí có thể tăng rủi ro dữ liệu nếu crash.

• ✅ READ_COMMITTED_SNAPSHOT to ON
  Đúng như đã giải thích ở trên: Kích hoạt row versioning, loại bỏ shared locks cho reads, ngăn blocking hiệu quả.

📘 Tài liệu tham khảo

• Microsoft Docs: READ_COMMITTED_SNAPSHOT (Azure SQL Managed Instance) (cập nhật 2024-2026).
• Troubleshoot Blocking: Snapshot Isolation.
  🛠️ Khuyến nghị: Kiểm tra tempdb space trước khi bật (row versioning dùng tempdb lưu versions). Test trên dev trước khi apply production!

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

Câu hỏi tập trung vào Azure Data Factory (ADF), một dịch vụ ETL (Extract, Transform, Load) của Microsoft Azure dùng để quản lý pipeline dữ liệu. Cụ thể:

• Bạn có một pipeline thực hiện incremental load (tải dữ liệu tăng dần) từ nguồn dữ liệu vào Azure Data Lake Storage Gen2.
• Dữ liệu cần tải được xác định bởi cột LastUpdatedDate trong bảng nguồn (tức là chỉ tải những bản ghi được cập nhật sau lần tải trước).
• Pipeline được lập kế hoạch chạy mỗi 4 giờ (tức là theo lịch trình định kỳ).
• Yêu cầu chính:
  • Tự động retry (thử lại) khi pipeline thất bại do concurrency (đồng thời) hoặc throttling limits (giới hạn tốc độ) – đây là các lỗi tạm thời phổ biến trong ADF.
  • Hỗ trợ backfilling (tải lại dữ liệu lịch sử đã tồn tại trong bảng, ví dụ để điền dữ liệu bị thiếu từ quá khứ).

Câu hỏi yêu cầu chọn loại trigger (kích hoạt) phù hợp nhất để đáp ứng cả hai yêu cầu trên. Trigger là cơ chế tự động chạy pipeline mà không cần kích hoạt thủ công. 🛠️

✅ Đáp án đúng: tumbling window

Lý do lựa chọn:

• Tumbling window trigger là loại trigger duy nhất hỗ trợ tự động retry cho các lỗi tạm thời như concurrency/throttling (qua thuộc tính retry và retryInterval), đồng thời cho phép backfill dễ dàng bằng cách chỉ định khoảng thời gian lịch sử (sử dụng tham số @trigger().startTime và @trigger().windowEnd).
• Nó chạy theo cửa sổ thời gian cố định (fixed intervals, ví dụ mỗi 4 giờ), phù hợp với lịch chạy định kỳ.
• Hoàn hảo cho incremental load dựa trên timestamp như LastUpdatedDate, vì có thể truyền window start/end vào pipeline để lọc dữ liệu (ví dụ: LastUpdatedDate > @trigger().startTime và < @trigger().windowEnd).
• Theo tài liệu ADF mới nhất (cập nhật 2024-2026), tumbling window vẫn là lựa chọn chuẩn cho các pipeline cần độ tin cậy cao và backfill. 📘

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên khả năng đáp ứng hai yêu cầu chính (retry tự động + backfill):

• ✅ tumbling window
  Đúng vì: Hỗ trợ đầy đủ retry tự động (cấu hình retry: 3, retryInterval: "00:05:00") cho lỗi throttling/concurrency, và backfill qua lệnh Trigger.Backfill với tùy chọn window cụ thể. Chạy định kỳ theo interval (như 4 giờ), lý tưởng cho incremental load. Không có hạn chế nào với yêu cầu bài toán. 🏆

• ❌ on-demand
  Sai vì: Đây là chế độ chạy thủ công (không tự động), không có cơ chế retry tự động hay lịch trình định kỳ (chạy theo yêu cầu). Không hỗ trợ backfill tự động, chỉ phù hợp cho test/debug. Không đáp ứng chạy mỗi 4 giờ hay xử lý lỗi tạm thời. 🚫

• ❌ event
  Sai vì: Trigger dựa trên sự kiện (event-based, như blob upload hoặc HTTP request), không chạy theo lịch cố định (mỗi 4 giờ). Không hỗ trợ backfill lịch sử dữ liệu, và retry chỉ cơ bản (không mạnh cho throttling như tumbling). Phù hợp cho reactive scenarios, không phải scheduled incremental load. ⏰

• ❌ schedule
  Sai vì: Chạy theo lịch CRON (có thể set mỗi 4 giờ), nhưng KHÔNG hỗ trợ retry tự động cho concurrency/throttling (chỉ retry cơ bản, không như tumbling) và KHÔNG hỗ trợ backfill (không có window parameters để tải dữ liệu lịch sử). Đã bị deprecated dần so với tumbling window trong ADF hiện đại. 📅

📚 Tài liệu tham khảo

• Tumbling window trigger chính thức: Azure Docs - Create a tumbling window trigger (cập nhật 2024, áp dụng đến 2026).
• So sánh triggers: Azure Docs - Pipeline execution and triggers – Xác nhận tumbling window là optimal cho retry + backfill.
• Backfill & Retry config: Azure Docs - Backfill manually với ví dụ incremental load.

Hy vọng phân tích này giúp bạn nắm vững ADF triggers! Nếu cần demo pipeline, hãy cho biết thêm chi tiết. 🚀

🧩 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 yêu cầu đề xuất một chiến lược tính sẵn sàng (availability strategy) cho cơ sở dữ liệu Azure SQL Database, phải đáp ứng ba yêu cầu chính:

• Hỗ trợ failover (chuyển đổi dự phòng) mà không yêu cầu ứng dụng client thay đổi chuỗi kết nối (connection strings). Điều này nghĩa là ứng dụng có thể tiếp tục kết nối mà không cần chỉnh sửa code hoặc cấu hình.
• Replicate (sao chép) cơ sở dữ liệu đến một vùng Azure thứ cấp (secondary Azure region), tức là sao chép dữ liệu qua các vùng địa lý khác nhau để đảm bảo tính sẵn sàng cao.
• Hỗ trợ failover đến vùng thứ cấp, nghĩa là có thể chuyển đổi tự động hoặc thủ công sang vùng dự phòng khi vùng chính gặp sự cố.

Câu hỏi tập trung vào các tính năng high availability và disaster recovery (HA/DR) của Azure SQL Database, đặc biệt là khả năng geo-redundancy (dự phòng đa vùng) với transparent failover (failover trong suốt, không ảnh hưởng connection string). Đây là kiến thức cốt lõi cho Azure DBA, dựa trên tài liệu Microsoft cập nhật đến năm 2026 (Azure SQL hỗ trợ Failover Groups với tích hợp Azure Front Door và Private Link cho bảo mật cao hơn).

✅ Đáp án đúng: failover groups
Lý do lựa chọn:
Failover Groups là tính năng chuyên biệt của Azure SQL Database (bao gồm cả single database và elastic pools), được thiết kế chính xác để đáp ứng tất cả ba yêu cầu:

• Tạo read-write listener (địa chỉ DNS cố định) cho phép ứng dụng kết nối mà không cần thay đổi connection string ngay cả sau failover.
• Tự động replicate dữ liệu asynchronously đến secondary region (hỗ trợ lên đến 4 secondary replicas).
• Hỗ trợ automatic hoặc manual failover đến secondary region với RPO thấp (thường <5 giây) và RTO nhanh (phút).
  🛠️ Đây là giải pháp geo-redundant HA/DR tiêu chuẩn, được khuyến nghị trong Azure Well-Architected Framework cho workload quan trọng.

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

• ✅ failover groups
  Phương án đúng hoàn toàn. Như đã giải thích ở trên, Failover Groups bao bọc active geo-replication và cung cấp listener DNS toàn cục, đảm bảo failover transparent cross-region mà không gián đoạn connection string. Hỗ trợ cả SQL Managed Instance từ năm 2023.
  (Nguồn: Microsoft Docs - Azure SQL Database auto-failover groups, cập nhật 2026 với hỗ trợ zone-redundant HA tích hợp).

• ❌ transactional replication
  Phương án sai. Transactional Replication là tính năng on-premises của SQL Server để sao chép dữ liệu giữa các database (có thể cross-region), nhưng không hỗ trợ automatic failover và yêu cầu thay đổi connection string thủ công sau failover. Không được thiết kế cho Azure SQL Database HA/DR (Azure SQL không hỗ trợ publisher đầy đủ như on-prem). Phù hợp hơn cho data warehousing, không phải geo-DR.
  (Nguồn: Microsoft Docs - Transactional Replication, lưu ý hạn chế trên Azure SQL).

• ❌ Availability Zones
  Phương án sai. Availability Zones chỉ cung cấp high availability trong cùng một region (zone-redundant), không replicate cross-region và không hỗ trợ failover đến secondary region. Failover chỉ xảy ra intra-region, vẫn cần connection string cố định nhưng không đáp ứng yêu cầu geo-replication.
  (Nguồn: Microsoft Docs - Azure SQL zone-redundant HA, không thay thế geo-DR).

• ❌ geo-replication
  Phương án sai nhưng gần đúng. Active Geo-Replication replicate dữ liệu đến secondary region (lên đến 4 replicas) và hỗ trợ failover, nhưng yêu cầu thay đổi connection string thủ công (hoặc dùng DNS alias tự quản lý). Không có listener tự động như Failover Groups. Failover Groups thực chất xây dựng trên geo-replication để khắc phục hạn chế này.
  (Nguồn: Microsoft Docs - Active geo-replication, so sánh với Failover Groups trong phần "Limitations").

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

• Azure SQL Database Availability Strategies – Hướng dẫn chính thức từ Microsoft (cập nhật 2026).
• Auto-failover Groups Deep Dive.

Hy vọng phân tích này giúp bạn nắm vững kiến thức Azure SQL HA/DR! 🚀 Nếu cần ví dụ triển khai PowerShell/ARM, hãy hỏi thêm nhé!

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

Câu hỏi này xoay quanh việc migrate (di chuyển) một cơ sở dữ liệu Microsoft SQL Server 2019 tên là DB1 sang Azure SQL Database. DB1 đang sử dụng các tính năng sau ở mức database-level và instance-level:

• Clustered columnstore indexes: Chỉ mục cột clustered, giúp tối ưu hóa lưu trữ và truy vấn dữ liệu lớn.
• Automatic tuning: Tự động tối ưu hóa hiệu suất, như tạo chỉ mục tự động.
• Change tracking: Theo dõi thay đổi dữ liệu mà không cần kích hoạt CDC (Change Data Capture).
• PolyBase: Tính năng cho phép truy vấn dữ liệu từ nguồn bên ngoài (như Hadoop, Azure Blob Storage) trực tiếp từ SQL Server.

Mục tiêu: Xác định tính năng nào phải bị loại bỏ (removed) hoặc thay thế (replaced) trước khi migrate, vì Azure SQL Database không hỗ trợ đầy đủ tất cả các tính năng của SQL Server on-premises. Azure SQL Database là dịch vụ PaaS (Platform as a Service), nên một số tính năng instance-level hoặc yêu cầu quyền cao không được hỗ trợ. 🛠️ Lưu ý quan trọng: Dựa trên tài liệu Microsoft cập nhật đến năm 2026 (Azure SQL Database phiên bản mới nhất), migrate yêu cầu kiểm tra tính tương thích qua Data Migration Assistant (DMA) hoặc Azure SQL Migration extension for Azure Data Studio.

✅ Đáp án đúng: PolyBase

Lý do lựa chọn:

• PolyBase không được hỗ trợ trong Azure SQL Database (bao gồm single database và elastic pools). Đây là tính năng chỉ có trên SQL Server on-premises, Azure SQL Managed Instance, hoặc Azure Synapse Analytics.
• Trước khi migrate, bạn phải remove PolyBase (xóa các external tables, data sources liên quan) hoặc thay thế bằng các tính năng khác như:
  • Elastic Queries (truy vấn external SQL databases).
  • Azure Synapse Link hoặc Serverless SQL pools cho dữ liệu lớn.
• Nếu giữ PolyBase, migrate sẽ thất bại với lỗi tương thích.
• 📘 Nguồn tham khảo:
  • Azure SQL Database features comparison (cập nhật 2026: PolyBase ❌ Not supported).
  • PolyBase documentation (xác nhận không hỗ trợ Azure SQL DB).

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

• Clustered columnstore indexes ❌ Sai (không cần remove/thay thế):
  Tính năng này được hỗ trợ đầy đủ trong Azure SQL Database từ phiên bản SQL Server 2014 trở lên. Nó giúp nén dữ liệu và tối ưu OLAP workloads. Migrate sẽ giữ nguyên mà không vấn đề.
  📘 Nguồn: Columnstore indexes in Azure SQL.

• PolyBase ✅ Đúng (phải remove/thay thế):
  Như đã giải thích ở trên, không hỗ trợ trong Azure SQL Database. Phải xóa các PolyBase objects trước migrate để tránh lỗi.
  📘 Nguồn: Như phần đáp án đúng.

• Change tracking ❌ Sai (không cần remove/thay thế):
  Tính năng này được hỗ trợ đầy đủ ở mức database-level trong Azure SQL Database. Nó nhẹ hơn CDC và hoạt động tốt sau migrate.
  📘 Nguồn: Change tracking in Azure SQL.

• Automatic tuning ❌ Sai (không cần remove/thay thế):
  Azure SQL Database có tính năng tương đương và nâng cao hơn gọi là Automatic tuning (FORCE_LAST_GOOD_PLAN, CREATE_INDEX, DROP_INDEX). Tính năng on-premises sẽ được migrate và tự động kích hoạt.
  📘 Nguồn: Automatic tuning in Azure SQL.

🛠️ Khuyến nghị thực tế: Sử dụng Azure Database Migration Service (DMS) hoặc DMA để đánh giá và migrate tự động, tự detect các vấn đề như PolyBase. Test trên môi trường staging trước khi production! 🚀

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

Câu hỏi này xoay quanh việc giám sát và thông báo thay đổi cấu hình trên 50 cơ sở dữ liệu Azure SQL. Cụ thể, bạn cần thông báo cho chủ sở hữu cơ sở dữ liệu khi các thiết lập như kích thước cơ sở dữ liệu (database size) hoặc cấp độ giá (pricing tier) bị thay đổi trong Azure.

🔍 Yêu cầu chính:

• Đây là các thay đổi hành chính (administrative changes), không phải dữ liệu vận hành thời gian thực như CPU hay lưu lượng truy cập.
• Azure sử dụng Activity Log (Nhật ký Hoạt động) để ghi lại các hành động quản trị như thay đổi cấu hình, tạo/tắt tài nguyên, v.v.
• Mục tiêu là tạo thông báo (alert) ngay lập tức khi sự kiện này xảy ra, không chỉ thu thập log.

🛠️ Bối cảnh Azure (cập nhật đến 2026): Với Azure Monitor (phiên bản mới nhất), bạn có thể sử dụng Alert Rules dựa trên Activity Log signals để phát hiện thay đổi cấu hình Azure SQL Database một cách chính xác và nhanh chóng. Không liên quan đến metrics (chỉ số hiệu suất) vì đây không phải thay đổi đo lường.

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

• Azure Monitor Activity Log Alerts (Microsoft Docs, cập nhật 2025).
• Azure SQL Database Auditing & Monitoring (hướng dẫn giám sát thay đổi).

✅ Đáp án đúng: Create an alert rule that uses an Activity Log signal type

Lý do chọn đáp án này:

• Thay đổi database size hoặc pricing tier (như chuyển từ Basic sang Premium) là sự kiện quản trị được ghi nhận trong Activity Log (Administrative category).
• Alert Rule với Activity Log signal cho phép tạo quy tắc cảnh báo dựa trên các sự kiện cụ thể trong log này, gửi thông báo qua email/SMS/Teams ngay khi phát hiện thay đổi.
• Phù hợp cho 50 databases: Áp dụng scope ở mức subscription/resource group để bao quát tất cả.
• ✅ Hiệu quả cao: Thời gian gần thực tế (real-time), không cần diagnostic settings phức tạp.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết:

• ❌ [SAI] Create a diagnostic setting for the activity log that has the Security log enabled.
  Phương án này sai vì Diagnostic Setting chỉ thu thập và lưu trữ log (gửi đến Log Analytics/Storage/Event Hubs), không tự động tạo thông báo/alert. Hơn nữa, Security log chỉ ghi các sự kiện bảo mật (như đăng nhập thất bại), không bao gồm thay đổi cấu hình như size/pricing tier (thuộc Administrative log). Không đáp ứng yêu cầu "notify" ngay lập tức.

• ❌ [SAI] For the database, create a diagnostic setting that has the InstanceAndAppAdvanced metric enabled.
  Phương án này sai vì Diagnostic Setting với metrics (như InstanceAndAppAdvanced) chỉ thu thập chỉ số hiệu suất (CPU, DTU, storage usage), không ghi thay đổi cấu hình hành chính. Metrics không phát hiện hành động "modify settings" mà chỉ đo lường trạng thái hiện tại. Không có chức năng alert tự động cho thay đổi cấu hình.

• ❌ [SAI] Create an alert rule that uses a Metric signal type.
  Phương án này sai vì Metric alerts chỉ theo dõi chỉ số số học (như storage % > 80%), không phát hiện sự kiện rời rạc như thay đổi size/tier. Metrics thay đổi sau khi hành động xảy ra, nhưng alert rule cần signal từ Activity Log để bắt chính xác sự kiện "modified".

• ✅ [ĐÚNG] Create an alert rule that uses an Activity Log signal type.
  Như đã giải thích ở trên: Đây là cách chính xác và được khuyến nghị trong Azure để alert trên các thay đổi hành chính. Bạn có thể lọc sự kiện theo "Microsoft.Sql/servers/databases/write" hoặc category "Administrative". Hoàn hảo cho quy mô 50 DB!

🛡️ Lời khuyên từ Azure DBA: Để triển khai, vào Azure Portal > Monitor > Alerts > Create alert rule > Chọn Activity Log signal > Filter theo Resource URI của SQL DB và Operation Name liên quan đến "update database". Kết hợp Action Group để notify owner.