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

Tìm thấy 100 câu.

Câu 81 Chọn nhiều đáp án Plan and configure a high availability and disaster recovery
You are tasked with configuring a hybrid HA/DR solution for your on-premises SQL Server. Which of the following can be used to achieve this?
  1. A

    Azure Blob backup.
  2. B Azure Site Recovery.
  3. C Azure SQL Database Managed Instance.
  4. D Stretch Database.
Xem giải thích

Đáp án

A và B — Azure Blob backup và Azure Site Recovery.

Vì sao đúng

⚠ Hai cách dùng Azure làm site DR cho SQL Server tại chỗ: | Cách | Nội dung | |---|---| | ⚠ Azure Blob backup | ⚠ BACKUP TO URL — ghi thẳng bản sao lưu lên Azure Storage | | ⚠ Azure Site Recovery | ⚠ nhân bản CẢ MÁY ẢO tại chỗ sang Azure |

⚠ Blob backup
   ⚠ SQL Server tại chỗ
   ⚠ BACKUP DATABASE ... TO URL = 'https://...'
        ↓
   ⚠ bản sao lưu nằm ở Azure
   ⚠ vùng tại chỗ sập vẫn còn

⚠ Site Recovery
   ⚠ nhân bản cả máy ảo
        ↓
   ⚠ sự cố → ⚠ bật máy ảo ở Azure

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

  • C (Azure SQL Managed Instance) — ⚠ là ĐÍCH ĐẾN, không phải cơ chế HA/DR lai: ⚠ có MI link để nhân bản từ SQL Server sang MI, ⚠ nhưng bản thân MI không phải "cách để đạt HA/DR lai".

  • D (Stretch Database) — ⚠ chuyển dữ liệu LẠNH lên Azure để tiết kiệm: ⚠ không phải giải pháp DR; ⚠ ⚠ và đã bị khai tử.

Ghi nhớ

⚠ Các cách dùng Azure cho DR của SQL Server tại chỗ: | Cách | Đặc điểm | |---|---| | ⚠ Backup to URL (Blob) | ⚠ đơn giản nhất, RTO cao | | ⚠ Azure Site Recovery | ⚠ nhân bản cả máy, RTO trung bình | | ⚠ Always On AG với replica trên Azure VM | ⚠ RTO thấp nhất, phức tạp nhất | | ⚠ Managed Instance link | ⚠ nhân bản sang PaaS, hiện đại | | ⚠ Log shipping sang Azure VM | ⚠ cách cũ, vẫn dùng được |

Từ khoá nhận diện:

"sao lưu lên đám mây" → ⚠ BACKUP TO URL "nhân bản cả máy ảo" → ⚠ Site Recovery "RTO thấp cho SQL" → ⚠ Always On AG với replica Azure "Stretch Database" → ⚠ đã khai tử, luôn là phương án sai

⚠ BACKUP TO URL — chi tiết Chi tiết
⚠ Ghi thẳng lên Azure Blob Storage
⚠ Dùng SAS token hoặc Managed Identity để xác thực
⚠ Không cần đĩa cục bộ lớn
⚠ Kết hợp lifecycle để chuyển sang lớp lạnh
⚠ Hạn chế ⚠ phụ thuộc băng thông mạng; CSDL rất lớn thì chậm
⚠ Azure Site Recovery cho SQL — cân nhắc Cân nhắc
⚠ Nhân bản ở mức MÁY, không hiểu giao dịch SQL
⚠ Microsoft khuyến nghị dùng cơ chế của SQL ⚠ AG, log shipping — nhất quán hơn
⚠ ASR hợp cho các máy chủ ứng dụng đi kèm
⚠ Kết hợp thực tế ⚠ AG cho CSDL, ASR cho máy chủ ứng dụng
⚠ Stretch Database — vì sao hay xuất hiện làm phương án sai Lý do
⚠ Nghe như liên quan tới lai (hybrid)
⚠ Thực chất chỉ chuyển DỮ LIỆU LẠNH lên Azure để tiết kiệm chỗ
⚠ Truy vấn vẫn liền mạch nhưng chậm hơn
⚠ Trạng thái ⚠ ĐÃ KHAI TỬ, không dùng cho thiết kế mới

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản sao lưu có nằm ngoài site chính không | | | RTO của từng cách là bao nhiêu | | | Đã thử khôi phục từ Azure Blob chưa | |

Và cách đơn giản nhất để bắt đầu một chiến lược DR lai, thường bị đánh giá thấp: BACKUP TO URL. Chỉ một câu lệnh, và bản sao lưu của bạn đã nằm ở một vị trí địa lý khác — điều mà nguyên tắc 3-2-1 đòi hỏi.

Câu 82 Plan and configure a high availability and disaster recovery

A company wants to implement a high availability and disaster recovery (HA/DR) solution in Azure. They require a maximum of 5 minutes of data loss and a recovery time of 30 minutes. Based on these requirements, which HA/DR solution should they implement?

  1. A Azure Backup with weekly retention.
  2. B Active Geo-Replication.
  3. C Azure Site Recovery.
  4. D Always On availability groups with asynchronous replication.
Xem giải thích

Đáp án

B — Active Geo-Replication.

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

⚠ Câu này GẦN TRÙNG với #17466 trong CÙNG LÔ, chỉ khác con số RTO.

Câu RPO RTO Khoá
⚠ #17466 ⚠ 5 phút ⚠ 15 phút ⚠ active geo-replication
⚠ #17478 (câu này) ⚠ 5 phút ⚠ 30 phút ⚠ active geo-replication
⚠ Cùng kết luận ⚠ RPO phút + RTO phút ⇒ cần secondary chạy sẵn

Vì sao đúng

⚠ Đối chiếu yêu cầu: | Yêu cầu | Active geo-replication | |---|---| | ⚠ Mất tối đa 5 phút dữ liệu | ⚠ nhân bản liên tục, trễ vài GIÂY | | ⚠ Khôi phục trong 30 phút | ⚠ secondary chạy sẵn, chuyển trong PHÚT | | ⚠ Giải pháp Azure | ⚠ đúng |

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

  • D (Always On AG với nhân bản BẤT ĐỒNG BỘ) — ⚠ bẫy hợp lý nhất: ⚠ về mặt kỹ thuật ⚠ cũng đạt được RPO và RTO này; ⚠ nhưng ⚠ đó là giải pháp cho SQL Server trên VM (IaaS) với gánh nặng vận hành lớn hơn nhiều; ⚠ với Azure SQL thì geo-replication là lựa chọn tự nhiên.

  • A (Azure Backup với lưu trữ hằng tuần) — ⚠ RPO tới MỘT TUẦN: ⚠ vượt xa yêu cầu 5 phút.

  • C (Azure Site Recovery) — ⚠ nhân bản MÁY ẢO: ⚠ Microsoft không khuyến nghị cho CSDL SQL vì tính nhất quán giao dịch.

Ghi nhớ

⚠ Quy trình chọn giải pháp HA/DR — bốn bước: | Bước | Câu hỏi | |---|---| | ⚠ 1. RPO là bao nhiêu | ⚠ quyết định TẦN SUẤT sao chép dữ liệu | | ⚠ 2. RTO là bao nhiêu | ⚠ quyết định có cần secondary CHẠY SẴN không | | ⚠ 3. Đang dùng PaaS hay IaaS | ⚠ quyết định bộ công cụ khả dụng | | ⚠ 4. Cần đa vùng không | ⚠ quyết định phạm vi bảo vệ |

Từ khoá nhận diện:

"RPO phút, RTO phút, Azure SQL" → ⚠ geo-replication hoặc failover group "RPO phút, RTO phút, SQL trên VM" → ⚠ Always On AG "RPO giờ trở lên" → ⚠ sao lưu và khôi phục "Site Recovery cho CSDL" → ⚠ thường là phương án sai

⚠ Vì sao Site Recovery không hợp cho CSDL Lý do
⚠ Nhân bản ở mức ĐĨA, không hiểu giao dịch
⚠ Có thể nhân bản một trạng thái không nhất quán
⚠ Microsoft khuyến nghị dùng cơ chế của chính CSDL
⚠ ASR hợp cho ⚠ máy chủ ứng dụng, máy chủ file — không phải CSDL giao dịch
⚠ Bảng RPO/RTO tổng hợp — nên thuộc lòng Bảng
⚠ Sao lưu hằng tuần ⚠ RPO 7 ngày
⚠ Sao lưu hằng ngày ⚠ RPO 24 giờ
⚠ Log backup mỗi 5-10 phút (PITR) ⚠ RPO ~10 phút, RTO GIỜ
⚠ Geo-replication bất đồng bộ ⚠ RPO giây, RTO phút
⚠ Nhân bản đồng bộ (cùng vùng) ⚠ RPO 0, RTO giây
⚠ Đừng quên chi phí Chi phí
⚠ RPO và RTO càng thấp, chi phí càng cao ⚠ thường theo cấp số
⚠ Secondary chạy sẵn = trả tiền gấp đôi
⚠ Hỏi nghiệp vụ: ngừng một giờ mất bao nhiêu tiền
⚠ So sánh ⚠ chi phí giải pháp với thiệt hại ước tính

Ba việc kiểm chứng: | Việc | Cách | |---|---| | RPO và RTO đã được nghiệp vụ xác nhận chưa | | | Chi phí giải pháp có tương xứng không | | | Đã đo RTO thật bằng diễn tập chưa | |

Và cách nhanh nhất để có một yêu cầu RPO/RTO thực tế: đưa kèm bảng giá của từng mức. Yêu cầu "không được mất dữ liệu, phải chạy lại ngay" thường được điều chỉnh rất nhanh khi nhìn thấy con số.

Câu 83 Configure and manage automation of tasks (15-20%)
Your database maintenance tasks have been automated using Azure Elastic Jobs. You want to ensure that the operations team receives timely alerts in the event of a failure. What should you do?
  1. A Configure the Azure Monitor to watch over the tasks.
  2. B Modify the ARM templates to include notification logic.
  3. C Implement custom logging and notifications using PowerShell.
  4. D Configure Job history retention and alert settings in the Elastic Job agent.
Xem giải thích

Đáp án

D — Cấu hình lưu giữ lịch sử job và thiết lập cảnh báo trong chính Elastic Job agent.

Vì sao đúng

⚠ Elastic Jobs có cơ chế theo dõi riêng: | Thành phần | Nội dung | |---|---| | ⚠ Job database | ⚠ CSDL riêng lưu định nghĩa job và LỊCH SỬ chạy | | ⚠ jobs.job_executions | ⚠ bảng chứa trạng thái từng lần chạy | | ⚠ Retention | ⚠ giữ lịch sử bao lâu | | ⚠ Cảnh báo | ⚠ dựa trên trạng thái trong job database |

⚠ Job chạy trên nhiều CSDL
        ↓
⚠ Kết quả ghi vào job database
   ⚠ thành công / thất bại / đang chạy
        ↓
⚠ Cấu hình alert đọc trạng thái đó
        ↓
⚠ Đội vận hành được báo

⚠ Dùng cơ chế CÓ SẴN của dịch vụ thay vì tự dựng bên ngoài.

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

  • A (dùng Azure Monitor theo dõi các tác vụ) — ⚠ gần đúng và trong thực tế thường kết hợp: ⚠ nhưng ⚠ Azure Monitor cần được cấp dữ liệu; ⚠ nguồn dữ liệu chính vẫn là job database.

  • C (tự viết logging và thông báo bằng PowerShell) — ⚠ tự dựng lại thứ đã có: ⚠ thêm chỗ hỏng, thêm việc bảo trì.

  • B (sửa ARM template để thêm logic thông báo) — ⚠ ARM template TRIỂN KHAI hạ tầng: ⚠ không chứa logic chạy lúc vận hành.

Ghi nhớ

⚠ Elastic Jobs — thành phần phải thuộc: | Thành phần | Vai trò | |---|---| | ⚠ Job agent | ⚠ dịch vụ điều phối, gắn với một job database | | ⚠ Job database | ⚠ lưu định nghĩa, lịch chạy, LỊCH SỬ | | ⚠ Target group | ⚠ tập CSDL đích | | ⚠ Job step | ⚠ script T-SQL | | ⚠ Output target | ⚠ nơi ghi KẾT QUẢ truy vấn (tuỳ chọn) |

Từ khoá nhận diện:

"cảnh báo cho Elastic Jobs" → ⚠ cấu hình trong job agent, dựa trên job database "job SQL Server Agent hỏng" → ⚠ job alert + operator "quy trình Logic Apps hỏng" → ⚠ Azure Monitor alert "chẩn đoán Logic App" → ⚠ Run History

⚠ Truy vấn lịch sử Elastic Job Truy vấn
⚠ jobs.job_executions ⚠ mọi lần chạy, trạng thái, thông báo lỗi
⚠ Lọc lifecycle = 'Failed' ⚠ tìm lần chạy hỏng
⚠ Xem theo từng CSDL đích ⚠ hỏng ở CSDL nào
⚠ Đặc thù ⚠ một job chạy trên 50 CSDL có thể hỏng ở 3 cái
⚠ Kiến trúc cảnh báo đầy đủ Kiến trúc
⚠ Job database ghi trạng thái
⚠ Truy vấn định kỳ tìm lần chạy hỏng
⚠ Đẩy sang Log Analytics
⚠ Azure Monitor alert + action group
⚠ Trong thực tế ⚠ thường kết hợp cơ chế của dịch vụ với Azure Monitor
⚠ Đừng quên cảnh báo "vắng mặt" Đừng quên
⚠ Job KHÔNG chạy khi đáng lẽ phải chạy
⚠ Không có lỗi nào để báo
⚠ Cần cảnh báo dựa trên "không có lần chạy nào trong N giờ"
⚠ Đây là ⚠ loại sự cố im lặng nhất và nguy hiểm nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Job database giữ lịch sử bao lâu | | | Có cảnh báo khi job KHÔNG chạy không | | | Job hỏng ở một CSDL trong nhóm có được báo không | |

Và đặc thù cần lưu ý khi giám sát job chạy trên nhiều cơ sở dữ liệu: job có thể "thành công" tổng thể trong khi hỏng ở vài đích. Cảnh báo chỉ nhìn trạng thái tổng sẽ bỏ sót đúng những trường hợp cần chú ý nhất.

Câu 84 Configure and manage automation of tasks (15-20%)
You've just automated a database workflow using Azure Logic Apps and it seems to be failing intermittently. What is the most suitable method to diagnose these failures?
  1. A Check the Windows Event Viewer logs.
  2. B Review the SQL Server Error Logs.
  3. C Examine the Activity Log in the Azure portal.
  4. D Review the Run History in Azure Logic Apps.
Xem giải thích

Đáp án

D — Xem lại Run History trong Azure Logic Apps.

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

⚠ Câu này và #17437 ở lô trước có khoá KHÁC NHAU cho cùng một sản phẩm — vì hỏi hai việc khác nhau.

Câu Hỏi gì Khoá
⚠ #17437 (lô 159) ⚠ làm sao ĐƯỢC BÁO khi có sự cố ⚠ Azure Monitor Alerts
⚠ #17480 (câu này) ⚠ làm sao CHẨN ĐOÁN nguyên nhân hỏng ⚠ Run History
⚠ Không mâu thuẫn ⚠ cảnh báo để BIẾT, lịch sử để HIỂU

Vì sao đúng

⚠ Run History lưu chi tiết TỪNG lần chạy: | Xem được | Nội dung | |---|---| | ⚠ Trạng thái từng HÀNH ĐỘNG | ⚠ thành công, thất bại, bỏ qua | | ⚠ Đầu vào và đầu ra của mỗi bước | ⚠ giá trị thật | | ⚠ Thông báo lỗi chi tiết | | | ⚠ Thời gian chạy từng bước | | | ⚠ Chạy lại (resubmit) được | |

⚠ Mở Run History
        ↓
⚠ Lọc các lần chạy FAILED
        ↓
⚠ Mở một lần cụ thể
        ↓
⚠ Xem bước nào có dấu X đỏ
        ↓
⚠ Đọc input, output, thông báo lỗi

⚠ Với lỗi NGẮT QUÃNG: ⚠ so sánh lần chạy hỏng với lần chạy thành công là cách nhanh nhất.

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

  • C (Activity Log trên cổng Azure) — ⚠ ghi thao tác trên MẶT PHẲNG QUẢN LÝ: ⚠ ai tạo, sửa, xoá Logic App; ⚠ không có gì về nội dung lần chạy.

  • B (SQL Server Error Log) — ⚠ chỉ có lỗi phía CSDL: ⚠ có thể hữu ích nếu bước gọi SQL hỏng, ⚠ nhưng không cho bức tranh toàn quy trình.

  • A (Windows Event Viewer) — ⚠ log của máy chủ Windows: ⚠ Logic Apps là dịch vụ PaaS, không chạy trên máy của bạn.

Ghi nhớ

⚠ Chẩn đoán so với cảnh báo — bảng phải thuộc: | Mục đích | Công cụ | |---|---| | ⚠ ĐƯỢC BÁO khi có sự cố | ⚠ Azure Monitor alert | | ⚠ HIỂU vì sao hỏng | ⚠ Run History | | ⚠ Phân tích XU HƯỚNG | ⚠ Log Analytics với KQL | | ⚠ Ai đã sửa cấu hình | ⚠ Activity Log |

Từ khoá nhận diện:

"chẩn đoán, tìm nguyên nhân" → ⚠ Run History "được thông báo" → ⚠ Azure Monitor alert "ai sửa tài nguyên" → ⚠ Activity Log "phân tích nhiều lần chạy" → ⚠ đẩy sang Log Analytics

⚠ Lỗi ngắt quãng của Logic App — nguyên nhân thường gặp Nguyên nhân
⚠ Dịch vụ bên ngoài giới hạn tần suất (throttling)
⚠ Timeout khi hệ thống đích chậm
⚠ Token hết hạn
⚠ Dữ liệu đầu vào bất thường ⚠ giá trị null, định dạng lạ
⚠ Chạy đồng thời quá nhiều
⚠ Cách tìm ⚠ so sánh input của lần hỏng với lần thành công
⚠ Làm Logic App bền hơn Cách
⚠ Cấu hình retry policy cho từng hành động ⚠ exponential backoff
⚠ Dùng scope + "run after" để bắt lỗi ⚠ như try/catch
⚠ Giới hạn số lần chạy đồng thời
⚠ Thêm bước kiểm tra dữ liệu đầu vào
⚠ Với lỗi thoáng qua ⚠ retry giải quyết phần lớn mà không cần ai can thiệp
⚠ Giữ lịch sử chạy được bao lâu Thời hạn
⚠ Mặc định 90 ngày
⚠ Muốn giữ lâu hơn: đẩy sang Log Analytics
⚠ Log Analytics cho phép truy vấn KQL trên nhiều Logic App
⚠ Với hệ thống quan trọng ⚠ nên bật ngay từ đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bước nào hỏng và với input nào | | | Retry policy đã cấu hình chưa | | | Có so sánh với lần chạy thành công chưa | |

Và kỹ thuật hiệu quả nhất khi gỡ lỗi một quy trình hỏng ngắt quãng: đặt cạnh nhau một lần chạy hỏng và một lần chạy thành công. Điểm khác biệt giữa hai đầu vào đó thường chính là câu trả lời.

Câu 85 Configure and manage automation of tasks (15-20%)
You are automating deployments for your Azure environment. Which of the following tools or scripts can be used to define resources for deployment in Azure in a declarative manner, without specifying the sequence of programming commands?
  1. A Azure CLI scripts
  2. B ARM templates
  3. C PowerShell scripts
  4. D SQL Server Management Studio (SSMS)
Xem giải thích

Đáp án

B — ARM template.

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

⚠ Câu này GẦN TRÙNG với #17462 trong cùng lô.

Câu Phương án đưa ra Khoá
⚠ #17462 ⚠ CLI, PowerShell, ARM, Bicep ⚠ ARM + Bicep
⚠ #17481 (câu này) ⚠ CLI, ARM, PowerShell, SSMS ⚠ ARM
⚠ Khác biệt ⚠ Bicep KHÔNG có trong danh sách câu này
⚠ Bài học ⚠ đáp án phụ thuộc vào danh sách phương án

Vì sao đúng

⚠ Đề nói rõ "declarative manner, without specifying the sequence of programming commands":

⚠ Khai báo
   ⚠ "tôi MUỐN hệ thống trông thế này"
   ⚠ Azure tự tính các bước
        ↓
⚠ ARM template (và Bicep)

⚠ Mệnh lệnh
   ⚠ "chạy lệnh 1, rồi lệnh 2, rồi lệnh 3"
        ↓
⚠ Azure CLI, PowerShell

⚠ Cụm "không phải khai trình tự lệnh" loại bỏ hẳn CLI và PowerShell.

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

  • A (Azure CLI script) và C (PowerShell script) — ⚠ đều là MỆNH LỆNH: ⚠ phải khai từng bước theo thứ tự.

  • D (SQL Server Management Studio) — ⚠ công cụ quản trị CSDL: ⚠ không triển khai tài nguyên Azure.

Ghi nhớ

⚠ Đặc trưng của cú pháp khai báo — bảng phải thuộc: | Đặc trưng | Nội dung | |---|---| | ⚠ Mô tả TRẠNG THÁI, không mô tả BƯỚC | | | ⚠ Idempotent | ⚠ chạy lại vẫn ra cùng kết quả | | ⚠ Engine tự tính thứ tự phụ thuộc | | | ⚠ Xem trước bằng what-if | | | ⚠ Là "hạ tầng dạng mã" đúng nghĩa | |

Từ khoá nhận diện:

"declarative, không khai trình tự lệnh" → ⚠ ARM / Bicep "script từng bước" → ⚠ CLI / PowerShell "đa đám mây" → ⚠ Terraform "quản trị CSDL" → ⚠ SSMS — không bao giờ là công cụ triển khai Azure

⚠ Ba câu về chủ đề này trong hai lô — tổng kết Tổng kết
⚠ Hỏi "công cụ nào tự động hoá được" ⚠ CLI, PowerShell, ARM, Bicep đều đúng — xem danh sách
⚠ Hỏi "cú pháp KHAI BÁO" ⚠ CHỈ ARM và Bicep
⚠ Hỏi "triển khai nhiều tài nguyên như một đơn vị" ⚠ ARM / Bicep
⚠ Mẹo làm bài ⚠ tìm từ khoá phân biệt: "declarative", "as a unit", "tools"
⚠ Bicep — nên biết dù câu này không có Đặc điểm
⚠ Cú pháp gọn hơn ARM JSON rất nhiều
⚠ Biên dịch ra ARM — cùng engine
⚠ Tự suy phụ thuộc từ tham chiếu
⚠ Có module để tái sử dụng
⚠ Microsoft khuyến nghị ⚠ Bicep cho dự án mới
⚠ Quy trình triển khai chuẩn Quy trình
⚠ Mã hạ tầng trong Git
⚠ Pull request → chạy what-if
⚠ Merge → pipeline triển khai
⚠ Cùng template cho dev/test/prod, khác tham số
⚠ Kết quả ⚠ ba môi trường thật sự giống nhau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạ tầng có mô tả bằng mã khai báo không | | | Đã dùng Bicep thay JSON chưa | | | Có chạy what-if trước khi triển khai không | |

Và phép thử đơn giản để biết hạ tầng của bạn có thật sự là "hạ tầng dạng mã": xoá sạch một resource group thử nghiệm rồi dựng lại từ kho mã. Nếu làm được trong vài phút thì đúng; nếu phải hỏi lại vài người thì chưa.

Câu 86 Chọn nhiều đáp án Configure and manage automation of tasks (15-20%)
You have just configured a regular maintenance job using SQL Server Agent. To ensure smooth operations, you want to be notified if the job fails. Which of the following steps should you take?
  1. A Create an Operator with the desired contact details.
  2. B Use Azure Logic Apps to monitor the job status.
  3. C Configure Notifications on the job to alert the Operator upon failure.
  4. D Configure the SQL Server Audit feature for notifications.
Xem giải thích

Đáp án

A và C — Tạo Operator với thông tin liên hệ, và cấu hình Notification trên job để báo cho Operator khi thất bại.

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

⚠ Đây là câu THỨ TƯ về cảnh báo job SQL Agent trong hai lô liên tiếp.

Câu Góc hỏi
⚠ #17405, #17436, #17463 ⚠ TÍNH NĂNG nào báo khi job hỏng → job alert
⚠ #17482 (câu này) ⚠ hai BƯỚC cấu hình cụ thể
⚠ Bổ sung cho nhau ⚠ câu này chỉ rõ QUY TRÌNH thiết lập

Vì sao đúng

⚠ Hai bước bắt buộc, thiếu một là không có email:

⚠ Bước 1: Tạo OPERATOR
   ⚠ tên + địa chỉ email
   ⚠ (không có operator thì không biết gửi cho ai)
        ↓
⚠ Bước 2: Cấu hình NOTIFICATION trên job
   ⚠ chọn operator
   ⚠ chọn "When the job fails"
        ↓
⚠ Job hỏng → ⚠ email tới operator

⚠ Thiếu bước 1: ⚠ không có người nhận. ⚠ Thiếu bước 2: ⚠ job không biết phải báo.

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

  • B (dùng Logic Apps theo dõi trạng thái job) — ⚠ làm được nhưng THỪA: ⚠ dựng cả một quy trình bên ngoài trong khi cơ chế nội tại đã đủ.

  • D (cấu hình SQL Server Audit để thông báo) — ⚠ Audit GHI LẠI hoạt động, không GỬI thông báo: ⚠ nhầm chức năng.

Ghi nhớ

⚠ Chuỗi cấu hình đầy đủ — bảng phải thuộc: | Bước | Cấu hình | Hay quên | |---|---|---| | ⚠ 1 | ⚠ Database Mail: profile và tài khoản SMTP | | | ⚠ 2 | ⚠ Bật Mail Profile trong thuộc tính SQL Agent | ⚠ QUÊN NHIỀU NHẤT | | ⚠ 3 | ⚠ Tạo Operator | | | ⚠ 4 | ⚠ Gán Notification cho từng job | | | ⚠ 5 | ⚠ THỬ bằng cách cho một job hỏng | ⚠ hay bỏ qua |

Từ khoá nhận diện:

"thông báo khi job hỏng" → ⚠ Operator + Notification "ghi lại hoạt động" → ⚠ Audit — không gửi thông báo "Azure SQL Database" → ⚠ không có SQL Agent, dùng Elastic Jobs

⚠ Ba tuỳ chọn thông báo trên job Tuỳ chọn
⚠ When the job fails ⚠ phổ biến nhất
⚠ When the job succeeds ⚠ dùng cho job quan trọng cần xác nhận
⚠ When the job completes ⚠ cả hai — dễ gây nhiễu
⚠ Với job chạy thường xuyên ⚠ chỉ báo khi HỎNG
⚠ Operator nên là gì Nên
⚠ Địa chỉ NHÓM, không phải cá nhân ⚠ người nghỉ việc là mất cảnh báo
⚠ Hộp thư có người thật sự đọc
⚠ Cân nhắc gửi vào hệ thống ticket
⚠ Rà soát định kỳ ⚠ địa chỉ còn hoạt động không
⚠ Ngoài email — các đường khác Đường
⚠ Ghi vào Windows Event Log ⚠ hệ thống giám sát ngoài đọc được
⚠ Job step cuối gọi webhook ⚠ Teams, Slack
⚠ Đẩy log SQL Agent vào Log Analytics
⚠ Môi trường lớn ⚠ gom mọi cảnh báo về một nơi tốt hơn email rời rạc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đã thử cho một job hỏng chưa | ⚠ cách duy nhất chắc chắn | | Operator có phải nhóm không | | | Mail Profile của Agent đã bật chưa | |

Và bước cuối cùng mà hầu như ai cũng bỏ qua khi thiết lập cảnh báo: thử nó. Cấu hình đúng trên màn hình và email thật sự tới hộp thư là hai chuyện hoàn toàn khác nhau.

Câu 87 Monitor, configure, and optimize database resources (20-25%)
You notice that certain queries are consuming excessive resources. To control the amount of CPU and memory that a workload uses on a SQL Server, you would utilize:
  1. A Database Engine Tuning Advisor
  2. B SQL Server Configuration Manager
  3. C Resource Governor
  4. D SQL Insights
Xem giải thích

Đáp án

C — Resource Governor.

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

⚠ Câu này GẦN TRÙNG với #17459 trong cùng lô.

Câu Hỏi gì
⚠ #17459 ⚠ thành phần nào giới hạn CPU, bộ nhớ, I/O cho một nhóm người dùng
⚠ #17483 (câu này) ⚠ dùng gì để kiểm soát CPU và bộ nhớ mà một workload tiêu thụ
⚠ Cùng khoá ⚠ Resource Governor

Vì sao đúng

⚠ Resource Governor là công cụ DUY NHẤT của SQL Server để phân bổ tài nguyên:

⚠ Truy vấn báo cáo ngốn hết CPU
        ↓ ⚠ Resource Governor
⚠ Phân loại phiên vào workload group "bao-cao"
        ↓
⚠ Group gắn với pool giới hạn 30% CPU
        ↓
⚠ Ứng dụng chính vẫn còn 70%
Giới hạn được Tham số
⚠ CPU ⚠ MAX_CPU_PERCENT
⚠ Bộ nhớ ⚠ MAX_MEMORY_PERCENT
⚠ I/O ⚠ MAX_IOPS_PER_VOLUME
⚠ Số request đồng thời ⚠ GROUP_MAX_REQUESTS

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

  • A (Database Engine Tuning Advisor) — ⚠ đề xuất INDEX và cấu trúc: ⚠ giúp truy vấn chạy nhanh hơn, ⚠ không giới hạn tài nguyên.

  • D (SQL Insights) — ⚠ GIÁM SÁT: ⚠ cho biết ai tiêu nhiều, ⚠ không chặn được.

  • B (SQL Server Configuration Manager) — ⚠ quản dịch vụ, giao thức mạng, tài khoản chạy dịch vụ: ⚠ không phân bổ tài nguyên truy vấn.

Ghi nhớ

⚠ Ba nhóm công cụ dễ lẫn — bảng phải thuộc: | Nhóm | Công cụ | Việc | |---|---|---| | ⚠ GIÁM SÁT | ⚠ DMV, SQL Insights, Query Store | ⚠ biết chuyện gì đang xảy ra | | ⚠ TỐI ƯU | ⚠ Tuning Advisor, Automatic Tuning | ⚠ chạy nhanh hơn | | ⚠ KIỂM SOÁT | ⚠ Resource Governor | ⚠ giới hạn tài nguyên |

Từ khoá nhận diện:

"giới hạn CPU/bộ nhớ cho workload" → ⚠ Resource Governor "đề xuất index" → ⚠ Database Engine Tuning Advisor "giám sát" → ⚠ DMV, SQL Insights "quản dịch vụ và giao thức" → ⚠ Configuration Manager

⚠ GIỚI HẠN của Resource Governor phải nhớ Giới hạn
⚠ Chỉ có ở bản ENTERPRISE
⚠ CÓ ở Azure SQL Managed Instance
⚠ KHÔNG có ở Azure SQL Database
⚠ Giới hạn CPU ⚠ chỉ áp dụng khi CÓ tranh chấp; rảnh thì vẫn dùng hết
⚠ Muốn giới hạn cứng ⚠ dùng CAP_CPU_PERCENT
⚠ Classifier function — điểm cần cẩn thận Cẩn thận
⚠ Chạy với MỌI kết nối mới
⚠ Viết chậm là làm chậm toàn bộ việc đăng nhập
⚠ Viết sai có thể khoá bạn ra khỏi máy chủ
⚠ Cách cứu ⚠ khởi động SQL Server ở chế độ -f để bỏ qua Resource Governor
⚠ Lựa chọn thay thế đơn giản hơn Lựa chọn
⚠ Tách thành instance riêng
⚠ Tách CSDL báo cáo sang replica đọc
⚠ Với Azure SQL: dùng elastic pool hoặc CSDL riêng
⚠ Cân nhắc ⚠ Resource Governor mạnh nhưng thêm một lớp phức tạp phải bảo trì mãi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bản SQL Server có phải Enterprise không | | | Có workload nào đang lấn át workload khác không | | | Tách instance có đơn giản hơn không | |

Và rủi ro ít được nhắc tới của Resource Governor: classifier function chạy với mọi kết nối mới. Một hàm viết cẩu thả ở đó không chỉ làm chậm hệ thống — nó có thể khiến chính bạn không đăng nhập được nữa.

Câu 88 Monitor, configure, and optimize database resources (20-25%)
When attempting to optimize the performance of a query, which feature in SQL Server allows for the monitoring and management of execution plans used by the query optimizer to improve the performance of your queries over time?
  1. A SQL Profiler
  2. B Resource Governor
  3. C Dynamic Data Masking
  4. D Query Store
Xem giải thích

Đáp án

D — Query Store.

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

⚠ Câu này GẦN TRÙNG với #17461 trong cùng lô — câu THỨ BA về Query Store trong hai lô.

Câu Góc hỏi
⚠ #17431 (lô 159) ⚠ tìm truy vấn tốn kém gần đây
⚠ #17461 ⚠ thu thập và lưu kế hoạch cùng số liệu chạy
⚠ #17484 (câu này) ⚠ theo dõi và QUẢN LÝ kế hoạch thực thi để cải thiện theo thời gian
⚠ Cùng khoá ⚠ Query Store

Vì sao đúng

⚠ Chữ "QUẢN LÝ" (management) trong đề là điểm phân biệt: | Năng lực | Nội dung | |---|---| | ⚠ Theo dõi | ⚠ lưu mọi kế hoạch từng dùng | | ⚠ So sánh | ⚠ kế hoạch nào nhanh, kế hoạch nào chậm | | ⚠ QUẢN LÝ | ⚠ ÉP dùng một kế hoạch cụ thể | | ⚠ Cải thiện theo thời gian | ⚠ FORCE_LAST_GOOD_PLAN tự động |

⚠ Truy vấn có 3 kế hoạch trong lịch sử
   ⚠ Plan 1: 50 ms
   ⚠ Plan 2: 45 ms
   ⚠ Plan 3: 8.000 ms  ← ⚠ đang dùng
        ↓
⚠ sp_query_store_force_plan
   ⚠ ép quay lại Plan 2
        ↓
⚠ Hiệu năng phục hồi ngay

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

  • A (SQL Profiler) — ⚠ theo dõi sự kiện, ĐÃ KHAI TỬ: ⚠ không lưu kế hoạch có cấu trúc, ⚠ không ép được kế hoạch.

  • B (Resource Governor) — ⚠ giới hạn tài nguyên, không liên quan kế hoạch.

  • C (Dynamic Data Masking) — ⚠ che dữ liệu hiển thị, không liên quan hiệu năng.

Ghi nhớ

⚠ Query Store — bốn báo cáo phải biết: | Báo cáo | Trả lời | |---|---| | ⚠ Top Resource Consuming Queries | ⚠ câu nào tốn nhất | | ⚠ Regressed Queries | ⚠ câu nào CHẬM ĐI so với trước | | ⚠ Queries With Forced Plans | ⚠ câu nào đang bị ép kế hoạch | | ⚠ Queries With High Variation | ⚠ câu nào hiệu năng dao động mạnh |

Từ khoá nhận diện:

"quản lý kế hoạch thực thi" → ⚠ Query Store "truy vấn tự nhiên chậm đi" → ⚠ plan regression → Query Store "tự động sửa" → ⚠ Automatic Tuning với FORCE_LAST_GOOD_PLAN "bắt sự kiện tuỳ chỉnh" → ⚠ Extended Events

⚠ Vì sao kế hoạch thực thi tự nhiên xấu đi Nguyên nhân
⚠ Thống kê cập nhật với dữ liệu mới ⚠ bộ tối ưu ước tính khác
⚠ Parameter sniffing ⚠ kế hoạch tối ưu cho tham số ĐẦU TIÊN, tệ cho tham số khác
⚠ Nâng compatibility level ⚠ bộ tối ưu mới hoạt động khác
⚠ Dữ liệu tăng làm đổi ngưỡng lựa chọn
⚠ Điểm chung ⚠ không ai đổi mã, mà truy vấn vẫn chậm đi
⚠ Parameter sniffing — vấn đề kinh điển Vấn đề
⚠ Thủ tục biên dịch với tham số đầu tiên nó thấy
⚠ Tham số đó trả về 5 dòng → kế hoạch dùng index seek
⚠ Lần sau tham số trả về 5 triệu dòng → seek 5 triệu lần
⚠ Cách chữa ⚠ OPTION (RECOMPILE), OPTIMIZE FOR, hoặc ép kế hoạch bằng Query Store
⚠ Ép kế hoạch — dùng cẩn thận Cẩn thận
⚠ Là giải pháp TẠM để dập lửa
⚠ Kế hoạch bị ép có thể không còn tối ưu khi dữ liệu đổi
⚠ Nên rà soát các kế hoạch đang bị ép định kỳ
⚠ Giải pháp gốc ⚠ sửa truy vấn, sửa index, cập nhật thống kê

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo Regressed Queries có gì | | | Có kế hoạch nào đang bị ép mà quên gỡ không | | | Automatic Tuning FORCE_LAST_GOOD_PLAN đã bật chưa | |

Và loại sự cố mà Query Store sinh ra để giải quyết: truy vấn tự nhiên chậm đi mà không ai đổi gì cả. Trước khi có nó, câu trả lời cho tình huống đó thường chỉ là những phỏng đoán.

Câu 89 Chọn nhiều đáp án Plan and implement data platform resources (20-25%)
When deploying a hybrid SQL Server solution, what are the two main considerations to ensure data consistency between your on-premises and Azure environments?
  1. A Setting up a VPN gateway.
  2. B Implementing Azure SQL Data Sync.
  3. C Enabling Entra ID authentication.
  4. D Configuring transactional replication.
Xem giải thích

Đáp án

A và B — Thiết lập VPN gateway, và triển khai Azure SQL Data Sync.

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

⚠ Phương án D (transactional replication) cũng là cách hợp lệ để giữ dữ liệu nhất quán giữa tại chỗ và Azure.

Phương án Đánh giá
⚠ A — VPN gateway ⚠ hạ tầng KẾT NỐI, điều kiện cần
⚠ B — SQL Data Sync ⚠ cơ chế ĐỒNG BỘ, khoá của đề
⚠ D — Transactional replication ⚠ cũng đồng bộ được, nhưng MỘT CHIỀU

⚠ KHÔNG sửa khoá — ⚠ đề hỏi hai cân nhắc CHÍNH, ⚠ và cặp "kết nối + đồng bộ" bao phủ đầy đủ hơn.

Vì sao đúng

⚠ Hai lớp cần thiết cho giải pháp lai:

⚠ Lớp 1: KẾT NỐI
   ⚠ VPN gateway (hoặc ExpressRoute)
   ⚠ tại chỗ ↔ Azure nói chuyện được
        ↓
⚠ Lớp 2: ĐỒNG BỘ DỮ LIỆU
   ⚠ SQL Data Sync
   ⚠ dữ liệu hai bên khớp nhau

⚠ Thiếu lớp 1: ⚠ không có đường đi. ⚠ Thiếu lớp 2: ⚠ có đường nhưng dữ liệu không đồng bộ.

Vì sao phương án C sai

  • C (bật xác thực Entra ID) — ⚠ là chuyện DANH TÍNH: ⚠ quan trọng cho bảo mật, ⚠ nhưng ⚠ không liên quan tới tính nhất quán dữ liệu.

Ghi nhớ

⚠ Kiến trúc lai — các lớp phải có: | Lớp | Thành phần | |---|---| | ⚠ Kết nối | ⚠ VPN gateway hoặc ExpressRoute | | ⚠ Danh tính | ⚠ Entra ID, Entra Connect | | ⚠ Dữ liệu | ⚠ Data Sync, replication, hoặc AG | | ⚠ Giám sát | ⚠ Azure Arc, Azure Monitor | | ⚠ Bảo mật | ⚠ Private Endpoint, firewall |

Từ khoá nhận diện:

"nhất quán dữ liệu giữa tại chỗ và Azure" → ⚠ Data Sync hoặc replication "kết nối mạng lai" → ⚠ VPN gateway hoặc ExpressRoute "đăng nhập bằng tài khoản công ty" → ⚠ Entra ID "quản máy chủ ngoài Azure" → ⚠ Azure Arc

⚠ Chọn cơ chế đồng bộ dữ liệu lai Chọn
⚠ Cần HAI CHIỀU ⚠ SQL Data Sync
⚠ Một chiều, gần thời gian thực ⚠ transactional replication
⚠ Một chiều, cho DR ⚠ Managed Instance link, hoặc AG
⚠ Có biến đổi dữ liệu ⚠ Data Factory
⚠ Đơn giản nhất ⚠ một chiều — tránh được mọi bài toán xung đột
⚠ VPN Gateway so với ExpressRoute So sánh
⚠ VPN: qua Internet, mã hoá IPsec, dựng nhanh
⚠ ExpressRoute: đường riêng, băng thông cao, SLA
⚠ VPN: chi phí thấp
⚠ ExpressRoute: dựng mất vài tuần
⚠ Lưu ý ⚠ SQL Data Sync Agent chỉ cần kết nối RA Internet, không bắt buộc VPN
⚠ Bài toán nhất quán trong kiến trúc lai Bài toán
⚠ Độ trễ đồng bộ ⚠ hai bên không bao giờ giống nhau 100% tại mọi thời điểm
⚠ Xung đột khi hai bên cùng sửa
⚠ Xử lý khi mất kết nối
⚠ Thiết kế tốt ⚠ xác định rõ bên nào là NGUỒN SỰ THẬT cho từng loại dữ liệu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên nào là nguồn sự thật cho dữ liệu nào | ⚠ câu hỏi quan trọng nhất | | Độ trễ đồng bộ chấp nhận được là bao nhiêu | | | Mất kết nối thì chuyện gì xảy ra | |

Và câu hỏi phải trả lời trước khi dựng bất kỳ kiến trúc lai nào: khi hai bên khác nhau, bên nào đúng?. Không trả lời được câu đó thì mọi cơ chế đồng bộ đều chỉ đang trì hoãn một cuộc tranh cãi.

Câu 90 Monitor, configure, and optimize database resources (20-25%)
Which of the following is NOT a primary purpose of using SQL Insights for monitoring?
  1. A Investigating transient errors
  2. B Determining most frequent query execution plans
  3. C Monitoring tempdb usage
  4. D Reviewing long-running queries
Xem giải thích

Đáp án

B — Xác định các kế hoạch thực thi truy vấn hay dùng nhất.

Vì sao đúng

⚠ Đây là câu PHỦ ĐỊNH — ⚠ tìm việc KHÔNG phải mục đích chính của SQL Insights.

⚠ Phân vai rõ ràng: | Việc | Công cụ đúng | |---|---| | ⚠ Kế hoạch thực thi hay dùng nhất | ⚠ QUERY STORE — không phải SQL Insights | | ⚠ Điều tra lỗi thoáng qua | ⚠ SQL Insights | | ⚠ Theo dõi tempdb | ⚠ SQL Insights | | ⚠ Xem truy vấn chạy lâu | ⚠ SQL Insights |

⚠ SQL Insights thu thập từ DMV
   ⚠ chờ đợi, kết nối, tài nguyên,
     tempdb, truy vấn đang chạy
        ↓
⚠ KHÔNG lưu kế hoạch thực thi
        ↓
⚠ Kế hoạch thực thi là địa hạt
   của QUERY STORE

Vì sao các phương án khác đều là mục đích hợp lệ

  • A (điều tra lỗi thoáng qua) — ⚠ SQL Insights thu liên tục: ⚠ nên bắt được lỗi chỉ xuất hiện chốc lát.

  • C (theo dõi tempdb) — ⚠ có sẵn chỉ số về tempdb: ⚠ dung lượng, tranh chấp.

  • D (xem truy vấn chạy lâu) — ⚠ thu từ dm_exec_requests: ⚠ thấy truy vấn đang chạy và thời gian.

Ghi nhớ

⚠ Phân vai công cụ giám sát — bảng phải thuộc: | Công cụ | Chuyên về | |---|---| | ⚠ SQL Insights | ⚠ workload tổng thể, chờ đợi, tài nguyên, tempdb | | ⚠ Query Store | ⚠ KẾ HOẠCH THỰC THI và số liệu theo truy vấn | | ⚠ Extended Events | ⚠ sự kiện chi tiết theo yêu cầu | | ⚠ Azure Monitor | ⚠ chỉ số hạ tầng | | ⚠ Auditing | ⚠ ai làm gì |

Từ khoá nhận diện:

"kế hoạch thực thi" → ⚠ Query Store "chờ đợi, tempdb, kết nối" → ⚠ SQL Insights hoặc DMV "bắt deadlock" → ⚠ Extended Events "CPU của VM" → ⚠ Azure Monitor

⚠ SQL Insights thu thập gì Thu thập
⚠ Chỉ số hiệu năng từ DMV
⚠ Thống kê chờ đợi
⚠ Sử dụng tempdb
⚠ Kết nối và phiên
⚠ Truy vấn đang chạy lâu
⚠ KHÔNG thu ⚠ kế hoạch thực thi chi tiết
⚠ Vì sao cần nhiều công cụ Lý do
⚠ Không công cụ nào làm được tất cả
⚠ Mỗi cái nhìn hệ thống từ một tầng
⚠ Điều tra sự cố thường phải dùng 2-3 cái
⚠ Quy trình chuẩn ⚠ Monitor → Insights → Query Store → execution plan
⚠ Từ rộng tới hẹp ⚠ đừng bắt đầu từ chi tiết nhất
⚠ Mẹo làm câu PHỦ ĐỊNH Mẹo
⚠ Đọc kỹ chữ "NOT", "EXCEPT", "KHÔNG"
⚠ Xét từng phương án: có phải mục đích chính không
⚠ Ba cái đúng, một cái sai — tìm cái lệch
⚠ Sai lầm thường gặp ⚠ đọc lướt rồi chọn phương án đúng đầu tiên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dùng đúng công cụ cho đúng câu hỏi không | | | Query Store đã bật chưa | ⚠ cho phần kế hoạch thực thi | | SQL Insights có được dựng không | ⚠ cần VM thu thập |

Và cách tiếp cận hiệu quả khi chẩn đoán hiệu năng: đi từ rộng tới hẹp. Bắt đầu bằng execution plan của một truy vấn khi chưa biết hệ thống đang nghẽn ở đâu là cách nhanh nhất để mất cả buổi chiều.