Khác gì so với SQL Server tự cài

Page 8 KB, extent, write-ahead logging, chỉ mục, columnstore, partition và T-SQL của BanHang vẫn là SQL Server. Phần đổi là ai giữ đĩa, ai chạy backup, và trần hiệu năng được bán theo tầng dịch vụ.

Có ba cách chạy. Cùng một câu SELECT không có nghĩa là cùng một việc vận hành.

Chương này tập trung vào hai dịch vụ PaaS. Máy ảo nằm ở mục cuối.

1. Những gì chương trước không mang sang Azure SQL Database #

Trên Azure SQL Database, script tạo BanHang với D:\, E:\, L:\ và filegroup FG_DATA / FG_ARCHIVE không chạy. Database chỉ có filegroup PRIMARY. Nền tảng đặt file. Tách ổ SSD và HDD bằng filegroup không còn là công cụ của bạn.

Partition, nén trang, columnstore, temporal table, row-level security và Query Store vẫn dùng được. Trên Azure SQL Database, mọi partition nằm trên PRIMARY. Sơ đồ FG_DATA / FG_ARCHIVE của chương lưu trữ không tạo được. Tách nóng và lạnh trên dịch vụ này là việc của tầng compute và của bảng riêng, không phải của ổ đĩa.

2. Backup tự động #

Với tầng không phải Hyperscale, nền tảng giữ chuỗi giống chương lưu trữ, nhưng lịch không do bạn đặt:

• Full mỗi tuần.
• Differential mỗi 12 giờ trên mô hình vCore. Mô hình DTU mặc định 24 giờ. Có thể chỉnh 12 hoặc 24 giờ.
• Log khoảng mỗi 10 phút. Tần suất lệch theo kích thước compute và mức ghi.

Point-in-time restore (PITR) đưa database về một thời điểm trong cửa sổ lưu. Mặc định 7 ngày. Chỉnh được từ 1 đến 35 ngày. Tầng Basic chỉ đến 7 ngày. Bạn không tắt lịch này.

Lưu lâu hơn 35 ngày thì bật long-term retention (LTR): bản full được chép sang kho riêng, giữ tối đa 10 năm, theo tuần, tháng hoặc năm. LTR không bật sẵn.

Ba đường lấy lại dữ liệu:

Backup mới mặc định nằm trên kho geo-redundant, trừ khi lúc tạo chọn môi trường dev và kho locally redundant. Đổi kiểu dư thừa kho backup làm lần restore sau có thể lâu hơn vì phải sao chép theo kích thước dữ liệu.

Dung lượng backup tính tiền phần vượt quá dung lượng data tối đa đã mua. Database ghi nhiều, hoặc REBUILD chỉ mục ngay sau full, làm differential và log backup lớn hơn đến full tuần sau. Một lần rebuild lớn có thể bị nền tảng chụp thành full mới nếu differential sắp quá to.

Xóa nhầm lúc 12:07 #

Cùng sự cố chương lưu trữ: DELETE đơn trước năm 2026 lúc 12:07 giờ Việt Nam, phát hiện lúc 12:10. Không có file .trn để STOPAT. API nhận giờ UTC. 12:06 giờ Việt Nam là 2026-10-02T05:06:00Z.

az sql db restore \
  --resource-group rg-banhang \
  --server banhang-sql \
  --name BanHang \
  --dest-name BanHang_1206 \
  --time 2026-10-02T05:06:00Z

BanHang đang chạy vẫn là bản đã mất dữ liệu. BanHang_1206 là database mới, cùng server, tại thời điểm trước lệnh xóa. Ứng dụng chuyển chuỗi kết nối sang database mới, hoặc đổi tên sau khi đã đối chiếu số đơn. Restore không ghi đè BanHang.

Geo-restore và PITR không thay failover group. PITR là sửa lỗi người dùng. Failover group là khi cả region không dùng được.

Hyperscale #

Hyperscale không đi theo chuỗi full, differential và log. Dữ liệu được chụp snapshot ở tầng lưu trữ, log được giữ riêng trong cửa sổ retention. Backup gần như không chiếm compute của replica đang phục vụ. Trong cùng region và cùng loại storage, restore database nhiều terabyte thường xong trong khoảng phút đến khoảng một giờ, không tỷ lệ thuận với kích thước như restore file .bak.

RPO của PITR trên Hyperscale trong cửa sổ lưu là 0 phút: về được thời điểm đã chọn, không phải “mốc log backup 10 phút trước”. Restore sang tầng General Purpose hoặc Business Critical từ Hyperscale không được hỗ trợ. Chiều ngược lại cũng vậy.

3. Ba tầng compute #

Next-gen General Purpose tính IOPS theo dung lượng storage đã mua: khoảng 3 IOPS mỗi GB, có sàn tối thiểu, và có thể mua thêm IOPS đến trần của số vCore. Đây là tầng khác với General Purpose cũ.

Trên Managed Instance General Purpose cũ, mỗi file có IOPS và throughput theo kích thước file:

Một file 100 GB chỉ được 500 IOPS dù instance còn trần. Nhiều file lớn hơn làm tăng tổng IOPS, đến khi chạm trần instance. Mỗi file data trên tầng General Purpose cũ tối đa 8 TB. Database lớn hơn 8 TB cần ít nhất hai file data. Business Critical của Managed Instance tính IOPS theo vCore, khoảng 4.000 IOPS mỗi vCore, không theo mẹo tách nhiều file. Azure SQL Database Business Critical có bảng IOPS riêng theo mục tiêu compute, không lấy số 4.000 này.

Số này là mức Microsoft công bố cho Managed Instance và có thể đổi theo thế hệ phần cứng. Khi chọn tầng, đọc lại trang resource limits của đúng thế hệ đang tạo.

4. Trần ghi log #

Trên bản cài sẵn, nút cổ chai của log là đĩa L:. Trên Azure SQL, nền tảng giới hạn tốc độ ghi log theo tầng và số vCore. Vượt trần, phiên chờ LOG_RATE_GOVERNOR. Giao dịch không lỗi ngay. Chúng chậm lại.

Với Managed Instance General Purpose, mức công bố là khoảng 4,5 MiB/s mỗi vCore, trần instance khoảng 120 MiB/s, và từng database còn trần theo kích thước file log (khoảng 22 đến 65 MiB/s). Business Critical premium-series cao hơn, khoảng 12 MiB/s mỗi vCore. REBUILD chỉ mục lớn hoặc nạp dữ liệu hàng loạt có thể đụng trần này dù CPU còn trống.

CDC và các tính năng đọc log làm ADR ngừng cắt log sớm. Log giữ lâu hơn. Trên Azure SQL Database có thể phải tăng tầng. Trên Managed Instance có thể phải tăng trần storage của instance.

5. Những thứ đã bật sẵn #

RCSI mặc định có nghĩa là chương kỹ thuật không cần ALTER DATABASE ... SET READ_COMMITTED_SNAPSHOT ON cho database mới trên Azure SQL Database. Ứng dụng chuyển từ bản cài sẵn, nơi đọc đang lấy khóa chung, sẽ thấy ít bị chặn ghi hơn và nhiều sử dụng version store hơn. Version store của ADR nằm trong database, tính vào dung lượng bạn mua.

TDE do nền tảng giữ khóa (service-managed) không xuất được certificate. Trên Managed Instance, BACKUP ... WITH COPY_ONLY của database mã hóa kiểu này không restore được sang nơi khác, vì khóa nội bộ không mang theo. Muốn một file .bak restore được về SQL Server tự cài thì dùng customer-managed key trong Key Vault, hoặc tắt TDE trước khi backup. PITR của nền tảng không cần bước này.

Khóa customer-managed phải còn trong Key Vault. Xóa khóa hoặc gỡ quyền của nền tảng thì database không mở được.

6. Managed Instance vẫn gần chương cũ #

Managed Instance chạy SQL Agent, nhiều database trên một instance, và cho tạo file cùng filegroup. Đường dẫn file do nền tảng gán. Bỏ FILENAME trong ALTER DATABASE ADD FILE.

CREATE DATABASE không khai báo file và filegroup trong cùng câu lệnh. Tạo database trước, rồi ALTER DATABASE để thêm file hoặc đổi tùy chọn.

Ràng buộc đáng nhớ:

• Một file log. File .bak có nhiều file log không restore được.
• General Purpose cũ: tối đa 280 file cho cả instance, tính cả data và log.
• Business Critical: tới 32.767 file mỗi database, vẫn trong trần storage của instance.
• BACKUP và RESTORE chỉ qua Azure Blob (TO URL / FROM URL). Không ghi ra đĩa, không băng.
• Backup do người dùng phải COPY_ONLY. Không có differential hay log backup tay. Không có NORECOVERY trên log backup.
• FILESTREAM không có. Bacpac hoặc .bak chứa FILESTREAM restore thất bại.
• Tầng General Purpose không có In-Memory OLTP. Nền tảng vẫn thêm filegroup XTP. Không sửa filegroup đó.

Copy-only backup hữu ích khi chuyển instance hoặc giữ một bản ngoài chuỗi PITR. Nó không thay PITR cho sự cố xóa nhầm lúc 12:07: bản copy-only chỉ đúng thời điểm bạn chạy lệnh.

7. Sẵn sàng cao do nền tảng giữ #

Bản cài sẵn dùng log shipping hoặc Availability Group do bạn dựng. PaaS đã có bản sao trong region.

Business Critical giữ vài replica trên SSD cục bộ. Một replica đọc được trong region. Hyperscale thêm replica đọc và named replica khi cần báo cáo tách khỏi primary.

Failover group là endpoint cho cả một nhóm database, trỏ sang region cặp khi region chính không dùng được. Cổng chờ trước khi tự chuyển mặc định một giờ, để một sự cố ngắn không đổi region. Geo-restore là đường cuối khi failover group không còn. Geo-restore về bản đã sao chép xong, nên mất nhiều dữ liệu hơn failover group.

Zone redundancy trải replica qua availability zone trong một region. Bật lúc tạo nếu region hỗ trợ. Đây là lựa chọn cho hỏng một zone, không phải cho hỏng cả region.

8. Việc vẫn thuộc về bạn #

Nền tảng không biết đơn nào được phép xóa.

1. Cửa sổ PITR 7 ngày là mặc định. BanHang cần về được một thời điểm cách đây vài tuần thì tăng retention. Cần giữ theo năm thì bật LTR và restore thử một bản LTR.
2. Trần max size đầy thì ghi thất bại. Đặt cảnh báo dung lượng data, và cảnh báo wait LOG_RATE_GOVERNOR, trước khi đầy.
3. Elastic Jobs hoặc Automation thay SQL Agent trên Azure SQL Database. Managed Instance dùng SQL Agent, nhưng job không ra được file share Windows như máy nội bộ.
4. Private endpoint hoặc quy tắc firewall. Logical server có firewall riêng với firewall database.
5. Đăng nhập Microsoft Entra cho người quản trị. Tài khoản SQL chỉ cho ứng dụng nếu còn cần.
6. Cửa sổ bảo trì cho vá lỗi nền tảng. Bạn không chọn từng bản vá như máy tự cài.
7. Serverless tự tạm dừng khi không có kết nối thì lần gọi đầu sau khi ngủ phải chờ compute khởi động. BanHang đang phục vụ đơn thì dùng compute provisioned.
8. DBCC CHECKDB vẫn chạy được khi cần nghi ngờ hỏng trang. Nền tảng đã có kiểm tra riêng. Không có lịch shrink.

BACPAC là gói lược đồ và dữ liệu để chuyển database nhỏ hoặc đưa vào công cụ phát triển. Nó không phải chuỗi PITR và không thay log backup 10 phút.

9. SQL Server trên máy ảo Azure #

Chọn máy ảo khi cần đúng chương lưu trữ: filegroup trên từng đĩa, nhiều file log, FILESTREAM, tail-log, Availability Group do bạn cấu hình.

Đĩa vẫn có quy tắc riêng của Azure:

• Đĩa log: host caching = None.
• Đĩa data Premium SSD: host caching = ReadOnly.
• Không dùng caching ReadWrite cho file dữ liệu hoặc log của SQL Server.
• tempdb đặt trên đĩa tạm cục bộ của máy ảo. Đĩa này mất khi deallocate. SQL tạo lại tempdb lúc khởi động. Không đặt file data của BanHang lên đĩa tạm.
• Tách data và log sang các đĩa khác nhau, giống vai trò của E: và L: trong chương lưu trữ.
• Availability Group trải availability zone nếu cần chịu một zone hỏng. Đĩa dùng chung của failover cluster không tự nhân bản dữ liệu. Hỏng đĩa đó vẫn phải restore.

Azure Backup cho SQL Server trên máy ảo có thể chạy full, differential và log giúp bạn. Chuỗi restore và STOPAT vẫn là cơ chế chương lưu trữ, chỉ khác chỗ chứa bản backup.

10. Chọn chỗ đặt BanHang #

Trên Azure SQL Database, thứ tự việc của chương kỹ thuật đổi thành: PITR và LTR đã có thì kiểm tra cửa sổ lưu, Query Store và RCSI đã bật thì bắt đầu từ chỉ mục và trần log, TDE đã bật thì quyết định có cần khóa tự giữ hay không.

Nguồn #

• Automated backups
• Hyperscale backups
• Recover using backups
• Feature comparison
• T-SQL differences for Managed Instance
• Managed Instance resource limits
• Accelerated database recovery