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

Đáp án

A và C — SQL Insights và Query Store.

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

⚠ Câu này GẦN TRÙNG với #17430 ở lô trước — cùng khoá.

Vì sao đúng

⚠ Hai công cụ bổ sung nhau đúng theo hai chiều đề hỏi: | Công cụ | Chiều | |---|---| | ⚠ SQL Insights | ⚠ gần THỜI GIAN THỰC — thu từ DMV liên tục | | ⚠ Query Store | ⚠ LỊCH SỬ — lưu kế hoạch và số liệu qua thời gian |

⚠ SQL Insights
   ⚠ "hiện tại hệ thống thế nào?"
   ⚠ chờ đợi, kết nối, tài nguyên

⚠ Query Store
   ⚠ "truy vấn này tuần trước chạy sao?"
   ⚠ so sánh kế hoạch cũ và mới
        ↓
⚠ Ghép lại = bức tranh đầy đủ

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

• B (Extended Events) — ⚠ bắt sự kiện theo yêu cầu: ⚠ mạnh cho điều tra cụ thể, ⚠ nhưng ⚠ phải cấu hình trước và ⚠ không cho cái nhìn lịch sử sẵn có.

• D (Resource Governor) — ⚠ GIỚI HẠN tài nguyên: ⚠ là công cụ kiểm soát, ⚠ không phải giám sát.

Ghi nhớ

⚠ Thời gian thực so với lịch sử — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | ⚠ Ngay bây giờ đang xảy ra gì | ⚠ DMV, SQL Insights | | ⚠ Trước đây chạy thế nào | ⚠ Query Store | | ⚠ Bắt một sự kiện cụ thể | ⚠ Extended Events | | ⚠ Chỉ số hạ tầng theo thời gian | ⚠ Azure Monitor | | ⚠ Giới hạn tài nguyên | ⚠ Resource Governor — không phải giám sát |

Từ khoá nhận diện:

"cả thời gian thực và lịch sử" → ⚠ SQL Insights + Query Store "truy vấn chậm đi so với trước" → ⚠ Query Store, báo cáo Regressed Queries "giới hạn CPU cho một nhóm người dùng" → ⚠ Resource Governor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Query Store có đang ở chế độ READ_WRITE không | | | Có công cụ nào cho cái nhìn thời gian thực không | | | Dữ liệu lịch sử giữ được bao lâu | |

Và giới hạn thường lộ ra vào lúc bất tiện nhất khi chỉ có một công cụ: bạn biết hệ thống đang chậm nhưng không biết nó bắt đầu chậm từ bao giờ. Con số "từ bao giờ" thường dẫn thẳng tới thay đổi đã gây ra sự cố.

Đáp án

C — Thêm một index phù hợp cho bảng.

Vì sao đúng

⚠ Table scan nghĩa là SQL Server phải ĐỌC TOÀN BỘ bảng:

⚠ SELECT * FROM DonHang WHERE KhachHangID = 500
        ↓ ⚠ không có index trên KhachHangID
⚠ ĐỌC HẾT 10 triệu dòng
⚠ Lọc ra 3 dòng
        ↓ ⚠ có index
⚠ Index seek → ⚠ đọc đúng 3 dòng

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

• A (bật database automatic tuning) — ⚠ gần đúng và về lâu dài rất tốt: ⚠ nó ⚠ cũng đề xuất và tạo index; ⚠ nhưng ⚠ đề hỏi ⚠ bạn nên làm gì khi ĐÃ nhìn thấy vấn đề cụ thể — ⚠ hành động trực tiếp là thêm index.

• B (kiểm tra tính toàn vẹn CSDL) — ⚠ DBCC CHECKDB phát hiện hỏng dữ liệu: ⚠ không liên quan tới hiệu năng truy vấn.

• D (điều chỉnh thiết lập máy chủ) — ⚠ quá mơ hồ và không nhắm đúng vấn đề: ⚠ table scan là vấn đề của một truy vấn cụ thể.

Ghi nhớ

⚠ Đọc execution plan — hành động tương ứng: | Thấy gì | Làm gì | |---|---| | ⚠ Table Scan / Clustered Index Scan | ⚠ thêm index phù hợp | | ⚠ Key Lookup nhiều | ⚠ thêm cột vào INCLUDE của index | | ⚠ Sort tốn kém | ⚠ index theo đúng thứ tự cần | | ⚠ Ước tính lệch thực tế | ⚠ UPDATE STATISTICS | | ⚠ Cảnh báo ép kiểu ngầm | ⚠ sửa kiểu dữ liệu tham số | | ⚠ Spill to tempdb | ⚠ cập nhật thống kê, lọc sớm hơn |

Từ khoá nhận diện:

"table scan tốn phần lớn chi phí" → ⚠ thêm index "index scan trên bảng nhỏ" → ⚠ có thể bình thường, đừng vội thêm "tự động tối ưu lâu dài" → ⚠ Automatic Tuning

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Truy vấn này chạy bao nhiêu lần mỗi ngày | ⚠ quyết định index có đáng không | | Đã có index nào gần đúng chưa | ⚠ sửa index cũ tốt hơn thêm cái mới | | Bảng có bao nhiêu index rồi | ⚠ quá nhiều làm chậm việc ghi |

Và câu hỏi nên đặt trước khi thêm bất kỳ index nào: truy vấn này quan trọng tới mức nào?. Mỗi index là một khoản thuế thu trên mọi lần ghi vào bảng đó, mãi mãi.

Đáp án

D — Resource Governor.

Vì sao đúng

⚠ Resource Governor giới hạn tài nguyên theo NHÓM workload:

⚠ Phiên kết nối tới
        ↓ ⚠ Classifier function
⚠ Phân vào WORKLOAD GROUP
   ⚠ "bao-cao", "ung-dung", "adhoc"
        ↓
⚠ Mỗi group gắn với RESOURCE POOL
   ⚠ giới hạn CPU %, bộ nhớ %, IOPS
        ↓
⚠ Truy vấn báo cáo nặng KHÔNG
   làm chết ứng dụng chính

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

• B (DMV) — ⚠ chỉ QUAN SÁT trạng thái: ⚠ không giới hạn gì.

• A (SQL Insights) — ⚠ giám sát: ⚠ cũng không giới hạn.

• C (Intelligent Query Processing) — ⚠ nhóm tính năng TỐI ƯU truy vấn tự động: ⚠ adaptive join, memory grant feedback; ⚠ giúp chạy nhanh hơn, ⚠ không phân bổ tài nguyên theo người dùng.

Ghi nhớ

⚠ Resource Governor — ba thành phần phải thuộc: | Thành phần | Vai trò | |---|---| | ⚠ Classifier function | ⚠ quyết định phiên nào vào group nào | | ⚠ Workload group | ⚠ nhóm logic, đặt giới hạn số request | | ⚠ Resource pool | ⚠ giới hạn CPU, bộ nhớ, IOPS thật sự | | ⚠ Có sẵn | ⚠ default và internal pool |

Từ khoá nhận diện:

"giới hạn tài nguyên cho một nhóm người dùng" → ⚠ Resource Governor "quan sát tài nguyên" → ⚠ DMV, SQL Insights "tối ưu truy vấn tự động" → ⚠ Intelligent Query Processing "giới hạn ở mức Azure" → ⚠ bậc dịch vụ / vCore, không phải Resource Governor

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đang dùng bản Enterprise hay Standard | ⚠ quyết định có Resource Governor không | | Có workload nào đang lấn át workload khác không | | | Đã cân nhắc tách instance thay vì Resource Governor chưa | |

Và cân nhắc thực dụng trước khi dựng Resource Governor: tách hẳn thành hai instance hoặc hai CSDL thường đơn giản hơn. Resource Governor mạnh, nhưng classifier function chạy với mọi kết nối và là một điểm phức tạp phải bảo trì mãi.

Đáp án

D — sys.dm_os_waiting_tasks.

Vì sao đúng

⚠ DMV này cho biết CHÍNH XÁC ai đang chờ ai: | Cột quan trọng | Nội dung | |---|---| | ⚠ session_id | ⚠ phiên đang CHỜ (bị chặn) | | ⚠ blocking_session_id | ⚠ phiên đang CHẶN — head blocker | | ⚠ wait_type | ⚠ loại chờ, ví dụ LCK_M_X | | ⚠ wait_duration_ms | ⚠ chờ bao lâu rồi | | ⚠ resource_description | ⚠ tài nguyên nào bị khoá |

⚠ Session 55 chờ session 42
⚠ Session 61 chờ session 42
⚠ Session 42 KHÔNG chờ ai
        ↓
⚠ 42 là HEAD BLOCKER
        ↓
⚠ Xử lý 42 là giải phóng cả chuỗi

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

• C (sys.dm_exec_requests) — ⚠ bẫy gần nhất và cũng có cột blocking_session_id: ⚠ nhưng ⚠ chỉ hiện các request ĐANG CHẠY; ⚠ ⚠ dm_os_waiting_tasks chuyên về TÁC VỤ ĐANG CHỜ và cho bức tranh chuỗi chặn đầy đủ hơn.

• B (sys.dm_exec_sessions) — ⚠ thông tin về phiên: ⚠ ai đăng nhập, từ máy nào; ⚠ không có thông tin chặn.

• A (sys.dm_exec_query_optimizer_info) — ⚠ thống kê hoạt động của bộ tối ưu: ⚠ hoàn toàn không liên quan.

Ghi nhớ

⚠ Chẩn đoán blocking — bộ DMV phải thuộc: | DMV | Vai trò | |---|---| | ⚠ sys.dm_os_waiting_tasks | ⚠ ai chờ ai — TÌM HEAD BLOCKER | | ⚠ sys.dm_exec_requests | ⚠ request đang chạy, cũng có blocking_session_id | | ⚠ sys.dm_tran_locks | ⚠ khoá nào đang giữ trên tài nguyên nào | | ⚠ sys.dm_exec_sql_text | ⚠ lấy câu lệnh từ sql_handle | | ⚠ sys.dm_exec_sessions | ⚠ ai đăng nhập, ứng dụng nào |

Từ khoá nhận diện:

"head blocker, danh sách phiên bị chặn" → ⚠ sys.dm_os_waiting_tasks "khoá đang giữ" → ⚠ sys.dm_tran_locks "deadlock đã xảy ra" → ⚠ Extended Events, session system_health "hệ thống chờ ở đâu nói chung" → ⚠ sys.dm_os_wait_stats

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có giao dịch nào mở quá lâu không | ⚠ sys.dm_tran_active_transactions | | READ COMMITTED SNAPSHOT đã bật chưa | | | Ứng dụng có chờ người dùng TRONG giao dịch không | ⚠ thiết kế rất tệ |

Và nguyên nhân blocking tệ nhất và khó chữa nhất: giao dịch mở ra rồi chờ người dùng bấm nút trên màn hình. Không có index hay cấu hình nào cứu được một thiết kế như vậy.

Đáp án

B — Query Store.

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

⚠ Câu này GẦN TRÙNG với #17431 ở lô trước.

Vì sao đúng

⚠ Đề mô tả đúng định nghĩa của Query Store: | Đề nói | Query Store | |---|---| | ⚠ "thu thập và lưu dữ liệu" | ⚠ ghi liên tục vào chính CSDL | | ⚠ "kế hoạch thực thi truy vấn" | ⚠ lưu MỌI kế hoạch của mỗi truy vấn | | ⚠ "thống kê thời gian chạy" | ⚠ thời gian, CPU, I/O, bộ nhớ |

⚠ Ví như "hộp đen máy bay" của CSDL
        ↓
⚠ Ghi mọi truy vấn và cách nó chạy
        ↓
⚠ Khi có sự cố → ⚠ mở ra xem lại

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

• A (Extended Events) — ⚠ bắt sự kiện theo cấu hình: ⚠ mạnh và linh hoạt, ⚠ nhưng ⚠ không tự lưu kế hoạch thực thi có cấu trúc để so sánh theo thời gian.

• C (Resource Governor) — ⚠ giới hạn tài nguyên, không thu thập gì.

• D (SQL Insights) — ⚠ giám sát tổng thể workload: ⚠ thu từ DMV; ⚠ không lưu kế hoạch thực thi chi tiết như Query Store.

Ghi nhớ

⚠ Query Store lưu bốn nhóm dữ liệu — bảng phải thuộc: | Nhóm | Nội dung | |---|---| | ⚠ Query text | ⚠ văn bản truy vấn đã chuẩn hoá | | ⚠ Query plan | ⚠ MỌI kế hoạch từng dùng cho truy vấn đó | | ⚠ Runtime statistics | ⚠ thời gian, CPU, đọc, ghi, bộ nhớ theo khoảng thời gian | | ⚠ Wait statistics | ⚠ truy vấn đó chờ ở đâu — từ SQL Server 2017 |

Từ khoá nhận diện:

"lưu kế hoạch thực thi và số liệu chạy" → ⚠ Query Store "bắt sự kiện tuỳ chỉnh" → ⚠ Extended Events "giới hạn tài nguyên" → ⚠ Resource Governor "giám sát nhiều CSDL" → ⚠ SQL Insights

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Query Store có đang READ_WRITE không | | | Chế độ thu thập là AUTO hay ALL | | | Dung lượng đã dùng bao nhiêu phần trăm | |

Và lý do Query Store thay đổi hẳn cách gỡ lỗi hiệu năng cơ sở dữ liệu: trước nó, câu hỏi "hôm qua truy vấn này chạy thế nào" gần như không có câu trả lời. Giờ thì chỉ cần mở báo cáo ra xem.

Đáp án

C và D — ARM template và Bicep.

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

⚠ Câu này làm rõ sự khác biệt mà ba câu ở lô trước gây bối rối.

Vì sao đúng

⚠ Khai báo (declarative) so với mệnh lệnh (imperative): | Kiểu | Mô tả gì | Công cụ | |---|---|---| | ⚠ KHAI BÁO | ⚠ TRẠNG THÁI mong muốn | ⚠ ARM, Bicep, Terraform | | ⚠ MỆNH LỆNH | ⚠ CÁC BƯỚC phải làm | ⚠ Azure CLI, PowerShell |

⚠ Khai báo (Bicep)
   resource sqlDb 'Microsoft.Sql/servers/databases@...' = {
     name: 'mydb'
     sku: { name: 'S1' }
   }
   ⚠ "tôi MUỐN có CSDL này"

⚠ Mệnh lệnh (CLI)
   az sql db create --name mydb --service-objective S1
   ⚠ "hãy TẠO CSDL này"
        ↓
⚠ Chạy lại: khai báo thì OK
   ⚠ mệnh lệnh có thể báo "đã tồn tại"

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

• A (Azure CLI) và B (PowerShell) — ⚠ tự động hoá được nhưng là MỆNH LỆNH: ⚠ mô tả hành động, không mô tả kết quả.

Ghi nhớ

⚠ Đặc tính của cú pháp khai báo — bảng phải thuộc: | Đặc tính | Nội dung | |---|---| | ⚠ Idempotent | ⚠ chạy nhiều lần vẫn ra một trạng thái | | ⚠ Tự tính thứ tự phụ thuộc | | | ⚠ Xem trước được | ⚠ what-if | | ⚠ Phát hiện trôi cấu hình | | | ⚠ Rà soát bằng pull request | |

Từ khoá nhận diện:

"declarative, khai báo" → ⚠ ARM, Bicep, Terraform "imperative, script từng bước" → ⚠ CLI, PowerShell "đa đám mây" → ⚠ Terraform "cú pháp dễ đọc hơn ARM" → ⚠ Bicep

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

Và khác biệt thực dụng nhất giữa hai kiểu cú pháp: script mệnh lệnh cho biết bạn đã làm gì, mã khai báo cho biết hệ thống PHẢI trông như thế nào. Chỉ cái thứ hai còn đúng sau khi ai đó sửa tay trên Portal.

Đáp án

D — Job alerts trong SQL Server Agent.

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

⚠ Đây là câu THỨ BA về job alert trong hai lô liên tiếp.

Vì sao đúng

⚠ Cơ chế sẵn có, không phải dựng gì thêm:

⚠ Job kết thúc với trạng thái FAILED
        ↓
⚠ Notification của job kích hoạt
        ↓
⚠ Database Mail gửi tới Operator
        ↓
⚠ Người trực nhận email NGAY

⚠ Cấu hình được cả ba tình huống: ⚠ khi thất bại, khi thành công, hoặc khi hoàn tất (cả hai).

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

• A (Azure Logic Apps) — ⚠ làm được nhưng THỪA: ⚠ dựng cả một quy trình để theo dõi job, ⚠ trong khi SQL Agent đã có sẵn cơ chế.

• B (Elastic Jobs) — ⚠ để CHẠY T-SQL trên nhiều CSDL Azure SQL: ⚠ không phải cơ chế thông báo.

• C (ARM templates) — ⚠ triển khai hạ tầng, hoàn toàn không liên quan.

Ghi nhớ

⚠ Ba thứ phải cấu hình đủ — bảng phải thuộc: | Thứ tự | Cấu hình | |---|---| | ⚠ 1. Database Mail | ⚠ profile và tài khoản SMTP | | ⚠ 2. Bật Mail Profile trong thuộc tính SQL Agent | ⚠ BƯỚC HAY BỊ QUÊN NHẤT | | ⚠ 3. Tạo Operator | ⚠ tên và địa chỉ email | | ⚠ 4. Gán notification cho job | | | ⚠ Thiếu bước 2 | ⚠ mọi thứ trông đúng nhưng KHÔNG email nào được gửi |

Từ khoá nhận diện:

"job SQL Agent hỏng, báo ngay" → ⚠ job alert + operator "chạy T-SQL trên nhiều Azure SQL DB" → ⚠ Elastic Jobs "quy trình nhiều dịch vụ" → ⚠ Logic Apps "Azure SQL Database" → ⚠ không có SQL Agent

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mail Profile của SQL Agent đã bật chưa | ⚠ bước bị quên nhiều nhất | | Operator có phải một NHÓM email không | | | Job có bật retry cho lỗi thoáng qua không | |

Và bước cấu hình bị quên nhiều nhất khi dựng cảnh báo cho SQL Server Agent: bật mail profile trong chính thuộc tính của Agent. Database Mail hoạt động, operator có địa chỉ, job có notification — và vẫn không email nào được gửi.

Đáp án

A — Azure Resource Manager template (ARM template)

Vì sao đúng

ARM template là cách khai báo hạ tầng dạng mã của Azure: bạn mô tả trạng thái mong muốn của cả nhóm tài nguyên — máy ảo, cơ sở dữ liệu, thành phần mạng — trong một tệp, kể cả thứ tự phụ thuộc giữa chúng. Triển khai mang tính idempotent, nghĩa là chạy lại nhiều lần vẫn ra cùng kết quả, nên dựng lại y hệt ở môi trường khác là chuyện đơn giản.

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

• B. Elastic Jobs — chạy script T-SQL trên nhiều cơ sở dữ liệu, không triển khai hạ tầng.
• C. SQL Server Agent jobs — bộ lập lịch công việc bên trong CSDL.
• D. Azure Logic Apps — nền tảng tự động hoá quy trình nghiệp vụ và tích hợp ứng dụng, không phải công cụ quản lý hạ tầng.

Đáp án

C — ARM template.

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

⚠ Công cụ chuyên dụng cho việc này KHÔNG có trong danh sách phương án.

⚠ KHÔNG sửa khoá — ⚠ trong bốn phương án, ⚠ ARM template là cách duy nhất quản nhiều CSDL như một khối thay vì thao tác từng cái.

⚠ Cách nhớ an toàn: ⚠ thao tác DỮ LIỆU trên nhiều CSDL → Elastic Jobs; ⚠ quản CẤU HÌNH nhiều CSDL → ARM/Bicep.

Vì sao đúng (theo bối cảnh đề)

⚠ ARM template mô tả nhiều CSDL trong một file:

⚠ Một template mô tả:
   ⚠ CSDL A, B, C với cùng cấu hình
   ⚠ firewall rule, bậc dịch vụ,
     chính sách sao lưu
        ↓
⚠ Triển khai MỘT lần
        ↓
⚠ Đổi cấu hình: sửa template,
   triển khai lại — áp cho TẤT CẢ

⚠ Đúng ý "không phải quản từng CSDL riêng lẻ" như đề nêu.

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

• A (Azure CLI script) và B (PowerShell cmdlet) — ⚠ phải viết vòng lặp qua từng CSDL: ⚠ vẫn là thao tác từng cái, chỉ tự động hoá phần gõ lệnh.

• D (SQL Server Agent job) — ⚠ Azure SQL Database KHÔNG CÓ SQL Server Agent: ⚠ phương án sai về mặt kỹ thuật.

Ghi nhớ

⚠ Quản nhiều Azure SQL Database — bảng phải thuộc: | Nhu cầu | Công cụ | |---|---| | ⚠ Chạy T-SQL trên nhiều CSDL | ⚠ Elastic Jobs | | ⚠ Quản cấu hình nhiều CSDL | ⚠ ARM template / Bicep | | ⚠ Chia sẻ tài nguyên giữa nhiều CSDL | ⚠ Elastic Pool | | ⚠ Truy vấn xuyên CSDL | ⚠ Elastic Query | | ⚠ Cưỡng chế chuẩn cấu hình | ⚠ Azure Policy |

Từ khoá nhận diện:

"chạy script T-SQL trên nhiều CSDL" → ⚠ Elastic Jobs "triển khai/cấu hình nhiều tài nguyên như một đơn vị" → ⚠ ARM / Bicep "nhiều CSDL dùng chung tài nguyên tính toán" → ⚠ Elastic Pool "SQL Server Agent trên Azure SQL Database" → ⚠ KHÔNG TỒN TẠI

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc cần làm là thao tác DỮ LIỆU hay CẤU HÌNH | ⚠ quyết định công cụ | | Có CSDL nào lệch chuẩn không | ⚠ Azure Policy phát hiện | | Elastic Pool có tiết kiệm được không | |

Và cách phân biệt hai nhóm công cụ hay bị lẫn: ARM và Policy làm việc với vỏ ngoài của cơ sở dữ liệu, Elastic Jobs làm việc với ruột bên trong. Cấu hình bậc dịch vụ là việc của ARM; rebuild index là việc của Elastic Jobs.

Đáp án

A — Azure SQL Database với active geo-replication.

Vì sao đúng

⚠ Đối chiếu yêu cầu với năng lực: | Yêu cầu | Active geo-replication | |---|---| | ⚠ RPO tối đa 5 phút | ⚠ nhân bản liên tục, độ trễ vài GIÂY | | ⚠ RTO tối đa 15 phút | ⚠ secondary chạy sẵn, chuyển trong PHÚT | | ⚠ Giải pháp riêng của Azure | ⚠ đúng |

⚠ RPO 5 phút và RTO 15 phút
   ⚠ không quá khắt khe
   ⚠ nhưng cũng KHÔNG cho phép
     khôi phục từ sao lưu
        ↓
⚠ Cần secondary ĐANG CHẠY
        ↓
⚠ Active geo-replication (hoặc failover group)

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

• C (Azure VM với sao lưu hằng ngày) — ⚠ RPO tới 24 GIỜ: ⚠ vượt xa yêu cầu 5 phút; ⚠ và ⚠ RTO khôi phục cũng hàng giờ.

• B (Azure Blob Storage với RA-GRS) — ⚠ là nhân bản cho KHO ĐỐI TƯỢNG: ⚠ không phải giải pháp cho CSDL SQL.

• D (Azure Table Storage với LRS) — ⚠ sai cả dịch vụ lẫn mức nhân bản: ⚠ LRS chỉ nhân bản trong MỘT trung tâm dữ liệu.

Ghi nhớ

⚠ RPO/RTO đạt được theo giải pháp — bảng phải thuộc: | Giải pháp | RPO | RTO | |---|---|---| | ⚠ HA tích hợp (cùng vùng) | ⚠ ≈0 | ⚠ giây | | ⚠ Zone-redundant | ⚠ ≈0 | ⚠ giây | | ⚠ Active geo-replication | ⚠ giây | ⚠ phút — đáp ứng đề | | ⚠ Auto-failover group | ⚠ giây | ⚠ phút, tự động | | ⚠ Geo-restore | ⚠ tới 1 giờ | ⚠ giờ | | ⚠ Sao lưu hằng ngày | ⚠ tới 24 giờ | ⚠ giờ |

Từ khoá nhận diện:

"RPO phút, RTO phút" → ⚠ geo-replication hoặc failover group "RPO giờ, RTO giờ" → ⚠ sao lưu và khôi phục "RPO ≈ 0" → ⚠ nhân bản đồng bộ, chỉ trong cùng vùng "LRS, ZRS, GRS, RA-GRS" → ⚠ thuật ngữ của STORAGE, không phải SQL

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Độ trễ nhân bản thực tế là bao nhiêu | ⚠ đó là RPO thật | | Đã diễn tập và đo RTO thật chưa | | | Ứng dụng có tự kết nối lại không | |

Và điều làm nhiều tổ chức trượt cam kết RTO dù cơ sở dữ liệu chuyển đổi hoàn hảo: họ chỉ tính thời gian của cơ sở dữ liệu. Thời gian phát hiện sự cố, thời gian ra quyết định và thời gian ứng dụng ổn định lại đều nằm trong cùng một đồng hồ.