Sửa chữa an toàn dữ liệu cơ sở dữ liệu sản xuất

Lỗi xảy ra và đôi khi dữ liệu phải được sửa trong sản xuất. Cách an toàn nhất để đi về điều này từ quan điểm của công ty lớn là gì? Có công cụ nào có thể giúp đỡ? Dưới đây là một số cân nhắc thúc đẩy yêu cầu này ...

1. Chúng ta cần đăng nhập ai đã chạy truy vấn và những gì họ đã chạy
2. Lý tưởng nhất là chúng ta cần cấp cho người đó quyền truy cập chỉ để chạy các truy vấn đối với các bảng quan tâm và chỉ trong một thời gian ngắn
3. Bất cứ điều gì đang chạy, các truy vấn cần phải có một số thông minh về nó để không cho phép chạy lâu và khóa SQL để chạy mà không có sự cho phép rõ ràng
4. Quá trình này cần phải là thuyết bất khả tri DB hoặc ít nhất là hiểu về máy chủ DB2, Oracle và SQL.

Chúng tôi đang cố gắng giảm rủi ro của các truy vấn sửa lỗi pro-hoc từ việc thực hiện "điều sai" và đồng thời thêm một số bảo mật / kiểm toán vào quy trình. Suy nghĩ hay ý tưởng?

Không bao giờ cập nhật cơ sở dữ liệu sản xuất bằng tay.

Viết kịch bản.

Kiểm tra ba lần và có nhiều người làm điều đó, không chỉ một người làm ba lần.

Bao gồm các truy vấn xác nhận sau thay đổi trong các tập lệnh.

Bất cứ khi nào tình huống cho phép, hãy kiểm tra toàn bộ thay đổi trong một giao dịch được hoàn trả vào cuối, sau khi xác thực sau thay đổi đã chạy. Khi tự tin với kết quả, thay đổi rollback thành một cam kết.

Kiểm tra các kịch bản quảng cáo nauseam dựa trên cơ sở dữ liệu thử nghiệm.

Tạo một bản sao lưu trước khi chạy tập lệnh đối với cơ sở dữ liệu sản xuất.

Chạy các kịch bản.

Kiểm tra, xác nhận và kiểm tra ba lần dữ liệu đã thay đổi bằng cách sử dụng tập lệnh xác thực sau thay đổi.

Làm một kiểm tra trực quan nào.

Nếu bất cứ điều gì có vẻ tắt, trở lại và khôi phục lại bản sao lưu.

Không tiến hành dữ liệu thay đổi dưới dạng dữ liệu sản xuất cho đến khi bạn hoàn toàn chắc chắn rằng mọi thứ đều ổn và bạn đã đăng xuất khỏi các nhà quản lý (doanh nghiệp) có liên quan.

Câu trả lời của Marjan Venema là hợp lệ về mặt kỹ thuật và nên được theo dõi khi có thể. Than ôi, Marjan trả lời từ quan điểm của một nhà lý thuyết , hoặc một quản trị viên cơ sở dữ liệu thuần túy , người thích làm cho mọi thứ sạch sẽ. Trong thực tế, đôi khi các ràng buộc kinh doanh làm cho không thể làm mọi thứ một cách sạch sẽ.

Hãy tưởng tượng trường hợp sau:

1. Có một lỗi trong sản phẩm phần mềm khiến nó ngừng hoạt động khi phát hiện ra thứ mà nó cho là không nhất quán dữ liệu trong cơ sở dữ liệu,

2. Tất cả các nhà phát triển có khả năng sửa lỗi trong ứng dụng đều không thể truy cập được,

3. Công ty hiện đang mất hàng ngàn đô la mỗi giờ (giả sử là 6.000 đô la, có nghĩa là 100 đô la mỗi phút),

4. Lỗi này ảnh hưởng đến một số bảng, một trong số đó là rất lớn và chỉ liên quan đến chính dữ liệu, không phải lược đồ,

5. Để khắc phục lỗi, bạn nên thử nghiệm một chút với dữ liệu, bao gồm cả loại bỏ và thay đổi nó,

6. Cơ sở dữ liệu lớn và sẽ mất ba giờ để lấy hoặc khôi phục bản sao lưu,

7. Bản sao lưu đầy đủ cuối cùng được thực hiện ba tuần trước; cũng có các bản sao lưu gia tăng hàng ngày và bản sao lưu gia tăng hàng ngày cuối cùng đã được thực hiện 14 giờ trước,

8. Sao lưu cơ sở dữ liệu được giả định đáng tin cậy; họ đã được kiểm tra nghiêm ngặt, kể cả gần đây,

9. Mất 14 giờ dữ liệu là không thể chấp nhận được, nhưng mất từ ​​một đến hai giờ dữ liệu là,

10. Môi trường dàn dựng được sử dụng lần cuối sáu tháng trước; có vẻ như nó không được cập nhật và có thể mất hàng giờ để thiết lập nó,

11. Cơ sở dữ liệu là Microsoft SQL Server 2008 Enterprise.

Cách làm sạch sẽ là:

1. Khôi phục bản sao lưu trong môi trường dàn dựng,

2. Thử nghiệm ở đó,

3. Kiểm tra kịch bản cuối cùng hai lần,

4. Chạy script trên máy chủ sản xuất.

Chỉ cần bước đầu tiên sẽ có giá $ 18 000 cho công ty của bạn. Rủi ro là khá thấp nếu bạn thực hiện bước thứ ba một cách hoàn hảo, nhưng vì bạn làm việc dưới áp lực cực lớn, rủi ro sẽ cao hơn nhiều. Bạn có thể kết thúc với một kịch bản hoạt động hoàn hảo trong việc dàn dựng, sau đó bắt vít cơ sở dữ liệu sản xuất.

Thay vào đó, bạn có thể đã làm như thế này:

1. Tạo ảnh chụp nhanh (Microsoft SQL Server hỗ trợ điều đó và phải mất vài giây để hoàn nguyên (và không có gì để tạo) ảnh chụp nhanh của cơ sở dữ liệu phải mất một giờ để sao lưu; Tôi tưởng tượng rằng các sản phẩm cơ sở dữ liệu khác cũng hỗ trợ ảnh chụp nhanh),

2. Thử nghiệm trực tiếp trên cơ sở dữ liệu sản xuất, trở lại ảnh chụp nhanh nếu có sự cố.

Mặc dù một người theo chủ nghĩa thuần túy sẽ sửa chữa cơ sở dữ liệu một cách sạch sẽ và vẫn có nguy cơ làm hỏng mọi thứ do áp lực thời gian trong khi lãng phí hơn 20 000 đô la của công ty mình, một quản trị viên cơ sở dữ liệu trong các ràng buộc kinh doanh tài khoản sẽ sửa chữa cơ sở dữ liệu theo cách sẽ giảm thiểu rủi ro (nhờ ảnh chụp nhanh) trong khi thực hiện nhanh chóng.

Phần kết luận

Bản thân tôi là một người theo chủ nghĩa thuần túy và tôi ghét làm mọi thứ theo cách không trong sạch. Là một nhà phát triển, tôi cấu trúc lại mã mà tôi sửa đổi, tôi nhận xét các phần khó không thể được cấu trúc lại, tôi kiểm tra đơn vị mã cơ sở và tôi thực hiện đánh giá mã. Nhưng tôi cũng xem xét các trường hợp bạn làm mọi thứ sạch sẽ và ngày hôm sau bạn bị sa thải, hoặc bạn giảm thiểu cả rủi ro và tác động tài chính bằng cách thực hiện một cuộc tấn công nhanh có hiệu quả.

Nếu một số anh chàng IT muốn làm mọi thứ sạch sẽ chỉ vì sự sạch sẽ trong khi nó gây ra tổn thất hàng ngàn đô la cho công ty, thì anh chàng IT này có một sự hiểu lầm sâu sắc về công việc của mình.

Sửa chữa an toàn dữ liệu cơ sở dữ liệu sản xuất. Cách an toàn nhất để đi về điều này từ quan điểm của công ty lớn là gì? Có công cụ nào có thể giúp đỡ?

Đó là một thực tiễn xấu và một cổng mời cho nhiều vấn đề và vấn đề dữ liệu hơn. Thậm chí còn có một cụm từ mô tả phương pháp này là " Nhanh và bẩn ".

Tiếp tục sửa chữa / cập nhật trực tiếp trên một máy chủ sản xuất là rất nguy hiểm , vì nó sẽ khiến bạn / công ty của bạn phải trả giá (một bộ luật, dữ liệu xấu / bẩn, doanh nghiệp bị mất, v.v. )

Tuy nhiên, lỗi sẽ ở đó và cần phải được sửa chữa. Các de-facto tiêu chuẩn công nghiệp là để áp dụng các bản vá lỗi / (kịch bản triển khai) trên một Staging (môi trường trước khi sản xuất với bản sao mới nhất của cơ sở dữ liệu sản) và để cho dữ liệu phân tích / QA để xác minh việc sửa chữa. Kịch bản tương tự phải được kiểm soát phiên bản và áp dụng cho môi trường Prod để tránh các vấn đề.

Có một số thực tiễn tốt được đề cập trong bài đăng liên quan này - Cơ sở dữ liệu thực hành tốt

Bộ tài liệu tham khảo tốt để tìm là:

• Làm thế nào nhanh chóng bạn có thể nhận được một lỗi cố định vào sản xuất?
• Kim tự tháp chi phí phát triển phần mềm
• Cần bao nhiêu thời gian để kiểm tra và sửa lỗi

Trong hầu hết các tổ chức, tôi đã làm việc cập nhật dữ liệu trong môi trường trực tiếp luôn được thực hiện bởi một nhóm nhỏ người có quyền truy cập để làm việc đó, điển hình là với một chức danh công việc như DBA. Vì các cập nhật chỉ có thể được thực hiện bởi một số ít người, ít nhất có khả năng họ làm quen với dữ liệu và do đó giảm (nhưng không loại trừ) nguy cơ gặp sự cố.

Người viết kịch bản cập nhật sẽ làm như vậy trong bài kiểm tra (theo các câu trả lời khác) và nhận được dấu hiệu nghiêm trọng từ những người không chuyên về công nghệ (những người biết hệ thống, cộng với người có thẩm quyền cao cấp) rằng các tính năng dường như 'lại đúng' Ngoài thử nghiệm hoang tưởng của riêng họ. Các tập lệnh và dữ liệu sẽ được xác minh độc lập bởi một kỹ thuật viên khác (thường là vai trò DBA mà tôi đã đề cập) trong bài kiểm tra trước khi được đưa vào sản xuất. Các kết quả sẽ được kiểm tra theo các giá trị dự đoán (duy nhất cho mọi kịch bản, nhưng thường là những thứ như số đếm, v.v.)

Trong một công ty tôi làm việc, lấy bản sao lưu không phải là một lựa chọn thực tế, nhưng tất cả các hàng được cập nhật đã được ghi vào một tệp văn bản để tham khảo TRƯỚC KHI cập nhật, và sau đó một lần nữa SAU bản cập nhật nên bất cứ ai cũng cần tham khảo. Các tập lệnh và dữ liệu này được giữ trong Nhật ký thay đổi dữ liệu được tổ chức hợp lý.

Mỗi doanh nghiệp là duy nhất và rủi ro khi cập nhật một số dữ liệu rõ ràng là lớn hơn so với các doanh nghiệp khác.

Bằng cách có một quy trình khiến mọi người phải nhảy qua các vòng để thực hiện các cập nhật này, hy vọng bạn quảng bá một nền văn hóa khiến mọi người muốn coi đây là biện pháp cuối cùng và tạo ra thái độ "kiểm tra hai lần, kiểm tra ba lần" lành mạnh xung quanh công cụ này.

Đôi khi bạn phải sửa dữ liệu trên Prod không tồn tại trên các máy chủ khác. Đây không chỉ là do lỗi mà có thể là từ việc nhập dữ liệu từ tệp mà khách hàng đã gửi không chính xác hoặc do sự cố do ai đó xâm nhập vào hệ thống của bạn. Hoặc từ một vấn đề gây ra bởi nhập dữ liệu xấu. Nếu cơ sở dữ liệu của bạn lớn hoặc có thời gian quan trọng, bạn có thể không có thời gian để khôi phục bản sao lưu mới nhất và sửa lỗi trên dev.

Phòng thủ đầu tiên của bạn (và thứ mà không có cơ sở dữ liệu Doanh nghiệp nào có thể có được mà không có!) Là các bảng kiểm toán. Bạn có thể sử dụng chúng để sao lưu các thay đổi dữ liệu xấu. Hơn nữa, bạn có thể viết các tập lệnh để trả dữ liệu về trạng thái trước đó và kiểm tra chúng trên các máy chủ khác từ lâu trước khi bạn cần hoàn nguyên dữ liệu đã kiểm toán. Sau đó, rủi ro duy nhất là bạn xác định các hồ sơ chính xác để hoàn nguyên.

Tiếp theo tất cả các tập lệnh để thay đổi dữ liệu về sản xuất nên bao gồm:

Họ nên ở trong các giao dịch rõ ràng và có khối TRY Catch.

Họ nên có một chế độ thử nghiệm mà bạn có thể sử dụng để khôi phục các thay đổi sau khi bạn thấy những gì họ sẽ có. Bạn nên có một thống kê được chọn từ trước khi thay đổi được thực hiện và một lần chạy sau thay đổi để đảm bảo thay đổi là chính xác. Kịch bản phải đảm bảo số lượng hàng được xử lý được hiển thị. Chúng tôi có một số điều này được thiết lập sẵn trong một mẫu để đảm bảo các phần được hoàn thành. Mẫu để thay đổi, giúp tiết kiệm thời gian bằng văn bản sửa chữa quá.

Nếu có một lượng lớn dữ liệu để thay đổi hoặc cập nhật, thì hãy xem xét việc viết tập lệnh để chạy theo lô với các cam kết cho mỗi lô. Bạn không muốn khóa toàn bộ hệ thống trong khi bạn sửa một triệu bản ghi. Nếu bạn có số lượng dữ liệu lớn cần khắc phục, hãy đảm bảo rằng một dba hoặc ai đó được sử dụng để điều chỉnh hiệu suất sẽ xem xét tập lệnh trước khi chạy và chạy trong giờ nghỉ nếu có thể.

Tiếp theo tất cả các tập lệnh để thay đổi bất cứ điều gì trong sản xuất là mã được xem xét và đưa vào kiểm soát nguồn. Tất cả trong số họ - không có ngoại lệ.

Cuối cùng các nhà phát triển không nên chạy các tập lệnh này. Chúng nên được chạy bởi dbas hoặc một nhóm quản lý cấu hình. Nếu bạn không có ai trong số họ, thì chỉ những người dẫn đầu về công nghệ hoặc cao hơn mới có quyền điều hành mọi thứ trên prod. Càng ít người chạy mọi thứ trên prod, càng dễ dàng theo dõi một vấn đề. Các kịch bản nên được viết sao cho chúng chỉ đơn giản là chạy, không có phần tô sáng và chạy từng bước một. Đó là những thứ nổi bật thường khiến mọi người gặp rắc rối khi họ quên làm nổi bật mệnh đề where.

Tôi đã cập nhật dữ liệu nhiều lần trong việc chạy cơ sở dữ liệu sản xuất. Tôi đồng ý với câu trả lời ở trên, rằng đây sẽ không bao giờ là quy trình vận hành tiêu chuẩn.

Nó cũng sẽ tốn kém (chúng tôi sẽ nhìn qua vai của mỗi bà mẹ và thảo luận về 2 hoặc 3 có thể)

Và nguyên tắc vàng: luôn tạo một câu lệnh chọn để hiển thị những gì sẽ được thực hiện trước khi thực hiện một câu lệnh cập nhật / xóa / chèn

Quy tắc vàng đang được thực thi bởi hai người khác trong đội!

lại: câu trả lời của MainMa ...

Có một lỗi trong sản phẩm phần mềm khiến nó ngừng hoạt động khi phát hiện ra thứ mà nó cho là không nhất quán dữ liệu trong cơ sở dữ liệu,

• Làm thế nào để bạn biết đó là một "lỗi"? Dữ liệu không nhất quán theo các quy tắc mà nhà phát triển sản phẩm phần mềm đặt ra.

Tất cả các nhà phát triển có khả năng sửa lỗi trong ứng dụng đều không thể truy cập được,

Công ty hiện đang mất hàng ngàn đô la mỗi giờ (giả sử là 6.000 đô la, có nghĩa là 100 đô la mỗi phút),

• Rõ ràng việc mất 100 đô la / phút là không đủ quan trọng đối với ban quản lý công ty để họ xác định vị trí và đảm bảo rằng các nhà phát triển có thẩm quyền quay lại để sửa lỗi của họ và giúp bạn khôi phục cơ sở dữ liệu.

Lỗi này ảnh hưởng đến một số bảng, một trong số đó là rất lớn và chỉ liên quan đến chính dữ liệu, không phải lược đồ,

• Tất cả các vấn đề cơ sở dữ liệu "quan tâm" lược đồ. Làm thế nào lược đồ được thiết kế là những gì sẽ xác định cách bạn giải quyết vấn đề này.

Để khắc phục lỗi, bạn nên thử nghiệm một chút với dữ liệu, bao gồm cả loại bỏ và thay đổi nó,

• Đó là những gì cơ sở dữ liệu dàn của bạn là dành cho. Bạn có thể cần phải sao lưu dữ liệu đó với dữ liệu "bị hỏng" từ cơ sở dữ liệu sản xuất ngay sau khi bạn sao lưu toàn bộ sản phẩm trực tuyến.

Cơ sở dữ liệu lớn và sẽ mất ba giờ để lấy hoặc khôi phục bản sao lưu,

• Sau đó, tốt hơn hết là bạn nên bắt đầu ngay để nó có thể chạy trong khi bạn phân tích vấn đề, phát triển các kịch bản sửa lỗi, kiểm tra và tinh chỉnh chúng cùng với các nhà phát triển và các DBA khác giúp bạn.

Bản sao lưu đầy đủ cuối cùng được thực hiện ba tuần trước; cũng có các bản sao lưu gia tăng hàng ngày và bản sao lưu gia tăng hàng ngày cuối cùng đã được thực hiện 14 giờ trước,

• Bạn không có ít nhất các bản sao lưu trực tuyến đầy đủ hàng ngày? Bạn đang say sưa. Nhưng có lẽ bạn đã quen với điều đó. Điều tốt là sao lưu đầy đủ bạn bắt đầu ở trên đang chạy. Hãy chắc chắn quản lý theo từng phút của các chi phí có thể tránh được với các bản sao lưu trực tuyến hàng ngày.

Sao lưu cơ sở dữ liệu được giả định đáng tin cậy; họ đã được kiểm tra nghiêm ngặt, kể cả gần đây,

• Xuất sắc! Sau đó, bạn có thể không phải khôi phục cơ sở dữ liệu nhiều lần.

Mất 14 giờ dữ liệu là không thể chấp nhận được, nhưng mất từ ​​một đến hai giờ dữ liệu là,

• Theo kịch bản bạn đã mô tả, tất cả các cược đã tắt. Đây là một tình huống "quản lý thảm họa thông tin". Một điều tốt cho quản lý được thực hiện trong suốt thời gian này là ghi lại các chi phí có thể tránh được trong tương lai với các bản sao lưu dự phòng và các thủ tục và tài nguyên phục hồi.

Môi trường dàn dựng được sử dụng lần cuối sáu tháng trước; có vẻ như nó không được cập nhật và có thể mất hàng giờ để thiết lập nó,

• Nếu hệ thống sao lưu của bạn hỗ trợ sao lưu trực tuyến (tức là cơ sở dữ liệu hoạt động đầy đủ trong quá trình sao lưu), thì bạn có thể thực hiện trích xuất để sao lưu cơ sở dữ liệu dàn dựng cùng một lúc nếu bạn có đủ tài nguyên phần cứng để tránh làm chậm quá trình sao lưu.

Cơ sở dữ liệu là Microsoft SQL Server 2008 Enterprise.

• Khó hơn để làm tất cả điều này nhưng không phải là không thể. Chúc may mắn!