Bạn có thể tạm thời tắt thay đổi cơ sở dữ liệu trong Microsoft SQL Server không?

Trong bản cập nhật sắp tới, tôi sẽ cần chuyển đổi nhiều bảng trong máy chủ của chúng tôi từ UTF-16 sang UTF-8. Tôi hy vọng điều này sẽ mất nhiều giờ.

Có cách nào hay để tắt CHÈN và CẬP NHẬT nhưng vẫn cho phép CHỌN trong cơ sở dữ liệu không?

Hay tôi cần chặn các thay đổi ở cấp độ doanh nghiệp/tắt cơ sở dữ liệu trong khi quá trình cập nhật đang diễn ra?

bạn có thể có một Vấn đề XY. Có nhiều cách để thực hiện những gì bạn đang cố gắng mà không yêu cầu các bảng đang được vận hành không có sẵn để thay đổi trong suốt thời gian hoạt động. Đây là cách tôi xoay nó (cấp độ cao):

1. Thêm một cột mới với định nghĩa mong muốn (kiểu dữ liệu, đối chiếu, v.v.).
2. Sử dụng trình kích hoạt 'sau khi chèn' để đảm bảo rằng các thay đổi dữ liệu đến từ ứng dụng của bạn cũng làm thay đổi cột mới.
3. Chèn lấp dữ liệu hiện có trong bảng.
4. Bỏ cột cũ, đổi tên cột mới để có tên cột cũ.

Nếu không có thêm kiến ​​thức về lược đồ cơ sở dữ liệu, quyền, v.v. và một số ý tưởng về chiến lược của bạn đối với ứng dụng của bạn, thì cực kỳ khó để đưa ra quy định. Ở mức tối thiểu, ứng dụng thậm chí có cho phép bạn hoạt động ở chế độ chỉ đọc với các bản cập nhật bảng bị chặn không?

Ở cấp độ rất cơ bản, "Có" bạn có thể làm điều đó... TỪ CHỐI CHÈN, CẬP NHẬT, XÓA BẬT <bảng> ĐẾN <người dùng> tuy nhiên không thể nói ứng dụng của bạn sẽ phản ứng như thế nào. Theo kinh nghiệm của tôi, hầu hết các ứng dụng sẽ phát ra lỗi ở khắp mọi nơi và giết người đẫm máu nếu bạn làm điều này, thậm chí có thể làm hỏng dữ liệu (lỗi không được kiểm tra, giao dịch sử dụng kém, v.v.). Hiếm khi (có thể là không bao giờ) tôi thấy một ứng dụng chuyển sang chế độ chỉ đọc một cách duyên dáng khi quyền truy cập cơ sở dữ liệu không như thiết kế/mong đợi.

Vì vậy, hãy KIỂM TRA! Thử nghiệm, thử nghiệm, thử nghiệm, trong môi trường phi sản xuất được kiểm soát cho đến khi bạn có một quy trình được lập thành văn bản hỗ trợ thay đổi của mình.

Nếu các yêu cầu của bạn không cho phép cắt điện kéo dài (hoặc hoàn toàn không cắt điện), thì có nhiều cách phức tạp hơn để xử lý việc này. Một ý tưởng sẽ là thêm trình kích hoạt sau khi chèn/sau khi cập nhật để tự động chuyển đổi các bản ghi mới/đã cập nhật trong một trường mới trong khi bạn chạy bảo trì trên các đợt nhỏ hơn. Sau khi tất cả dữ liệu được chuyển đổi, hãy chuyển ứng dụng sang trường mới và bỏ trường cũ.

UTF-8 và UTF-16 sang một bên, tôi nghĩ câu hỏi lớn hơn mà bạn đang đặt ra là làm thế nào để triển khai các thay đổi đối với hệ thống sản xuất với thời gian ngừng hoạt động tối thiểu. Tôi chắc rằng có một vài cách khác nhau, nhưng đây là cách tôi sẽ tiếp cận nó.

1. Tạo một bản sao của cơ sở dữ liệu của bạn.
2. Chạy các bản cập nhật lược đồ của bạn trên bản sao.
3. Sử dụng một sản phẩm như So sánh SQL Redgate hoặc viết tập lệnh của riêng bạn để đồng bộ hóa dữ liệu của bạn. Đưa họ đến gần nhất có thể
4. Tắt ứng dụng, đồng bộ lại lần cuối.
5. Thay đổi kết nối cơ sở dữ liệu thành cơ sở dữ liệu mới (Hoặc đổi tên cơ sở dữ liệu).
6. Khởi động lại ứng dụng.

Tôi biết điều này nghe có vẻ đơn giản và có thể không thực hiện được vì nhiều lý do, nhưng nó đáng để nghiên cứu.

Tôi muốn làm điều này vì một vài lý do. Mất điện tối thiểu và tác động đến người dùng. Tùy chọn quay lại an toàn. Một cơ hội để kiểm tra tác động của các thay đổi lược đồ/dữ liệu.

Tôi đánh giá cao điều này sẽ trở nên phức tạp hơn nếu có các ứng dụng hoặc kết nối tích hợp khác với cơ sở dữ liệu của bạn, nhưng việc khôi phục lại một bản nâng cấp không thành công cũng không thú vị lắm.