Ví dụ: Cập nhật tất cả các hàng của bảng khách hàng vì bạn quên thêm mệnh đề where.Tai nạn cơ sở dữ liệu tồi tệ nhất xảy ra với bạn trong sản xuất là gì?
Tôi đã xóa cơ sở dữ liệu trực tiếp và xóa cơ sở dữ liệu đó.
Bài học kinh nghiệm: đảm bảo bạn biết SQL của bạn - và đảm bảo rằng bạn sao lưu trước khi bạn chạm vào nội dung.
Một DBA junior có nghĩa là để làm:
delete from [table] where [condition]
Thay vào đó họ gõ:
delete [table] where [condition]
Đó là giá trị T-Sql nhưng về cơ bản bỏ qua nơi [điều kiện] cắn hoàn toàn (ít nhất là nó đã làm trở lại sau đó trên MSSQL 2000/97 - Tôi quên cái nào) và lau toàn bộ bảng.
Đó là niềm vui: -/
Chắc chắn không phải trên SQL Server 2000. Không có SQL Server 97 - phiên bản trước là SQL Server 7. – splattne
tôi phát hiện ra tôi không hiểu Oracle làm lại các file log (? Ngữ đó là một thời gian dài trước đây) và mất dữ liệu thương mại của một tuần, trong đó có đến được tay tái được lấy từ vé giấy.
Có là lớp lót bạc - vào cuối tuần tôi đã nhập vào, tôi đã học được rất nhiều về khả năng sử dụng của màn hình nhập thương mại, được cải thiện đáng kể sau đó.
Tôi nghĩ sai lầm tồi tệ nhất của tôi là
truncate table Customers
truncate table Transactions
tôi didnt xem những gì MSSQL Server Tôi đã đăng nhập vào, tôi muốn để xóa bản sao cục bộ của tôi ra ... Các quen thuộc "OH s ** t" khi nó đã mất nhiều thời gian hơn khoảng nửa giây để xóa, ông chủ của tôi nhận thấy tôi đã đi màu trắng visibily, và hỏi những gì tôi vừa làm. Khoảng nửa mintue sau, giám sát trang web của chúng tôi đã phát điên và bắt đầu gửi email cho chúng tôi nói rằng trang web đã ngừng hoạt động.
Bài học kinh nghiệm? Không bao giờ giữ một kết nối mở để sống DB lâu hơn hoàn toàn cần thiết.
Chỉ đến 4 giờ sáng, cũng khôi phục dữ liệu từ bản sao lưu! Ông chủ của tôi cảm thấy tiếc cho tôi, và đã mua cho tôi bữa tối ...
Trường hợp xấu nhất cho hầu hết mọi người là mất dữ liệu sản xuất, nhưng nếu họ không chạy sao lưu hàng đêm hoặc sao chép dữ liệu vào trang web DR thì họ xứng đáng họ nhận được!
@Keith trong T-SQL, không phải là từ khóa FROM tùy chọn cho DELETE? Cả hai tuyên bố đó đều giống hệt nhau ...
Tôi làm việc cho một công ty thương mại điện tử nhỏ, có 2 nhà phát triển và một DBA, tôi là một trong những nhà phát triển. Tôi thường không có thói quen cập nhật dữ liệu sản xuất một cách nhanh chóng, nếu chúng tôi đã lưu trữ các quy trình, chúng tôi đã thay đổi chúng tôi đặt chúng thông qua kiểm soát nguồn và có cài đặt thường xuyên triển khai chính thức.
Dù sao thì người dùng đã đến với tôi cần cập nhật cho cơ sở dữ liệu liên hệ của chúng tôi, cập nhật hàng loạt một loạt các cơ sở.Vì vậy, tôi đã viết truy vấn trong môi trường thử nghiệm của chúng tôi, ví dụ như
update facilities set address1 = '123 Fake Street'
where facilityid in (1, 2, 3)
Điều gì đó tương tự. Chạy nó trong thử nghiệm, 3 hàng cập nhật. Sao chép nó vào clipboard, dán nó vào dịch vụ đầu cuối trên hộp sql sản xuất của chúng tôi, chạy nó, xem trong kinh dị vì phải mất 5 giây để thực hiện và cập nhật 100000 hàng. Bằng cách nào đó chúng tôi đã copy dòng đầu tiên và không phải là thứ hai, và đã không được chú ý như tôi CTRL +V, CTRL +E 'd.
DBA của tôi, một quý ông lớn tuổi của Hy Lạp, có lẽ là người gắt gỏng nhất mà tôi gặp đã không hồi hộp. May mắn thay, chúng tôi đã có một bản sao lưu, và nó đã không phá vỡ bất kỳ trang nào, may mắn là trường chỉ thực sự cho mục đích hiển thị (và thanh toán/giao hàng).
Bài học kinh nghiệm đã chú ý đến những gì bạn đang sao chép và dán, có thể là một số cách khác.
Điều tồi tệ nhất xảy ra với tôi là máy chủ sản xuất tiêu thụ tất cả không gian trong HD. Tôi đã sử dụng SQL Server vì vậy tôi thấy các tập tin cơ sở dữ liệu và thấy rằng các bản ghi là khoảng 10 Gb vì vậy tôi quyết định làm những gì tôi luôn luôn làm khi tôi muốn trunc một tập tin đăng nhập. Tôi đã làm một Detach xóa các tập tin đăng nhập và sau đó đính kèm một lần nữa. Tôi cũng nhận ra rằng nếu tập tin nhật ký không được đóng đúng thì thủ tục này không hoạt động. vì vậy tôi kết thúc với một tệp mdf và không có tệp nhật ký. Rất may tôi đã đi đến trang web của Microsoft tôi nhận được một cách để khôi phục lại cơ sở dữ liệu như phục hồi và di chuyển đến cơ sở dữ liệu khác.
update Customers set ModifyUser = 'Terrapin'
Tôi quên mệnh đề where - khá ngây thơ, nhưng trên một bảng với 5000 khách hàng, tên của tôi sẽ được trên tất cả các kỷ lục cho một thời gian ...
Bài học kinh nghiệm: giao dịch sử dụng cam kết và rollback !
Tôi đã từng viết một con trỏ cập nhật chưa bao giờ thoát. Trên bảng hàng 2M +. Các ổ khóa chỉ leo thang và leo thang cho đến khi hộp 16 lõi, 8GB RAM (vào năm 2002!) Thực sự bị dừng lại (trong loạt màn hình xanh).
Khoảng 7 năm trước, tôi đã tạo ra một kịch bản thay đổi cho DB của khách hàng sau khi làm việc muộn. Tôi đã chỉ thay đổi thủ tục lưu trữ nhưng khi tôi tạo ra SQL tôi đã có "đối tượng phụ thuộc kịch bản" kiểm tra. Tôi chạy nó trên máy địa phương của tôi và tất cả dường như hoạt động tốt. Tôi chạy nó trên máy chủ của khách hàng và kịch bản đã thành công.
Sau đó, tôi đã tải trang web và trang web trống. Để kinh dị của tôi, cài đặt "đối tượng phụ thuộc tập lệnh" đã thực hiện một DROP TABLE cho mỗi bảng mà các thủ tục được lưu trữ của tôi được chạm vào.
Tôi ngay lập tức được gọi là người dẫn đầu và ông chủ cho họ biết điều gì đã xảy ra và hỏi nơi có bản sao lưu mới nhất của DB. 2 nhà phát triển khác đã được tham gia và kết luận mà chúng tôi đã đưa ra là không có hệ thống dự phòng nào được đưa ra và không có dữ liệu nào có thể được khôi phục. Khách hàng đã mất toàn bộ nội dung của trang web và tôi là nguyên nhân gốc rễ. Kết quả là một khoản tín dụng $ 5000 được cung cấp cho khách hàng của chúng tôi.
Đối với tôi đó là một bài học tuyệt vời, và bây giờ tôi rất thận trọng về việc chạy bất kỳ kịch bản thay đổi nào và sao lưu DB trước. Tôi vẫn còn với cùng một công ty ngày hôm nay, và bất cứ khi nào các câu chuyện cười đi lên về sao lưu hoặc kịch bản cơ sở dữ liệu ai đó luôn luôn mang đến sự kiện "DROP TABLE" nổi tiếng.
Tôi nghĩ rằng tôi đang làm việc trong DB thử nghiệm (trường hợp này không rõ ràng), vì vậy khi tôi hoàn thành 'thử nghiệm' tôi chạy một tập lệnh để đặt lại tất cả dữ liệu trở lại dữ liệu thử nghiệm chuẩn mà chúng tôi sử dụng. ouch!
May mắn thay điều này xảy ra trên cơ sở dữ liệu đã có bản sao lưu tại chỗ, vì vậy sau khi tìm ra tôi đã làm điều gì đó sai, chúng tôi có thể dễ dàng mang lại cơ sở dữ liệu gốc.
Tuy nhiên sự việc này đã dạy cho công ty tôi đã làm việc cho thực sự riêng biệt môi trường sản xuất và thử nghiệm.
Chúng tôi đang cố sửa một nút bị hỏng trên một cụm Oracle.
Mô-đun quản lý lưu trữ gặp sự cố, vì vậy, chúng tôi đã nhấp vào nút chưa cài đặt với ý định cài đặt lại và sao chép cấu hình từ nút khác.
Hmm, nó chỉ ra nút chưa cài đặt được áp dụng cho toàn bộ cụm, do đó, vui lòng xóa mô-đun quản lý bộ nhớ khỏi tất cả các nút trong hệ thống.
Gây mọi nút trong cụm sản xuất bị lỗi. Và vì không có nút nào có trình quản lý lưu trữ, chúng sẽ không xuất hiện!
Đây là một thực tế thú vị về các bản sao lưu ... các bản sao lưu lâu đời nhất được xoay vòng ngoài trang web và bạn biết tệp cũ nhất của mình trên cơ sở dữ liệu là gì? Các tệp cấu hình đã được thiết lập khi hệ thống được cài đặt.
Vì vậy, chúng tôi phải yêu cầu người ngoại vi gửi chuyển phát nhanh bằng băng đó và một vài giờ sau, chúng tôi đã cài đặt và chạy lại mọi thứ. Bây giờ chúng tôi giữ bản sao cục bộ của các tập tin cài đặt và cấu hình!
Cập nhật tất cả các hàng của bảng khách hàng vì bạn quên thêm mệnh đề where.
Đó chính xác là tôi đã làm: | . Tôi đã cập nhật cột mật khẩu cho tất cả người dùng thành chuỗi mẫu mà tôi đã nhập vào bảng điều khiển. Phần tồi tệ nhất của nó là tôi đã truy cập vào máy chủ sản xuất và tôi đã kiểm tra một số truy vấn khi tôi đã làm điều này. Người cao niên của tôi sau đó đã phải hoàn nguyên một bản sao lưu cũ và phải thực hiện một số cuộc gọi từ một số khách hàng thực sự bất mãn. Ofcourse còn thời gian khác khi tôi đã sử dụng câu lệnh delete, mà tôi thậm chí không muốn nói về ;-)
bảng Truncate T_DAT_STORE
T_DAT_STORE là bảng thực tế của bộ phận tôi làm việc. Tôi nghĩ rằng tôi đã được kết nối với cơ sở dữ liệu phát triển. May mắn thay, chúng tôi có một bản sao lưu hàng ngày, mà không được sử dụng cho đến ngày hôm đó, và dữ liệu đã được khôi phục trong sáu giờ.
Kể từ đó tôi rà soát lại tất cả mọi thứ trước khi một truncate, và định kỳ tôi yêu cầu một sự phục hồi sao lưu các bảng nhỏ chỉ để kiểm tra sao lưu được thực hiện tốt (Backup không được thực hiện bởi bộ phận của tôi)
tôi không hãy nhớ tất cả các câu lệnh sql đã hết kiểm soát nhưng tôi có một bài học kinh nghiệm - làm điều đó trong một giao dịch nếu bạn có thể (hãy cẩn thận với các tệp nhật ký lớn!).
Trong sản xuất, nếu bạn có thể, tiến hành theo cách cũ thời:
Khá uncool, nhưng nói chung làm việc và thậm chí có thể cung cấp cho thủ tục này để ai đó khác để chạy nó trong ca đêm của họ trong khi bạn đang nhận được giấc ngủ xứng đáng của bạn :-)
Điều này đã không xảy ra với tôi, chỉ là một khách hàng của chúng tôi whos mess tôi đã phải dọn dẹp.
Họ có một máy chủ SQL chạy trên một mảng đĩa RAID5 - ổ đĩa hotswap tốt đẹp hoàn chỉnh với các chỉ báo trạng thái đĩa sáng. Xanh = Tốt, Đỏ = Xấu.
Một trong các ổ đĩa của chúng được chuyển từ xanh sang đỏ và thiên tài được yêu cầu kéo và thay thế ổ đĩa xấu (Màu đỏ) sẽ thay thế một màu xanh lá cây (Xanh lá cây). Vâng, điều này không hoàn toàn xoay xở để hạ gục bộ đột kích - lựa chọn phần mềm có thể đọc được (Đỏ) và không thể thay đổi (Xanh) trong vài phút .. sau khi nhận ra sai lầm và hoán đổi ổ đĩa trở lại bất kỳ khối dữ liệu nào đã được viết trong thời gian này thời gian trở thành jyberish khi đồng bộ hóa đĩa bị mất) ... 24 giờ liên tục sau đó viết các chương trình meta để phục hồi dữ liệu có thể đọc được và tái tạo lại một lược đồ có kích thước trung bình mà chúng đã sao lưu và chạy.
Đạo đức của câu chuyện này bao gồm ... Không bao giờ sử dụng RAID5, luôn duy trì bản sao lưu, cẩn thận những người bạn thuê.
Tôi đã mắc lỗi lớn trên hệ thống sản xuất của khách hàng một lần - may mắn khi tự hỏi tại sao lệnh đã mất quá nhiều thời gian để thực hiện những gì tôi đã thực hiện và hủy nó trước khi thế giới kết thúc.
Đạo đức của câu chuyện này bao gồm ... luôn bắt đầu một giao dịch mới trước khi thay đổi bất cứ điều gì, kiểm tra kết quả là những gì bạn mong đợi và sau đó và chỉ sau đó cam kết giao dịch.
Là một quan sát chung nhiều loại rm -rf lỗi/loại có thể được ngăn ngừa bằng cách xác định đúng ràng buộc khoá ngoại trên giản đồ của bạn và ở xa từ bất kỳ lệnh có nhãn 'CASCADE'
tôi đã làm chính xác những gì bạn đề nghị . Tôi đã cập nhật tất cả các hàng trong bảng chứa tài liệu khách hàng vì tôi đã quên thêm "ID = 5" ở cuối. Đó là một sai lầm.
Nhưng tôi thông minh và hoang tưởng. Tôi biết tôi sẽ vít lên một ngày. Tôi đã phát hành "giao dịch bắt đầu". Tôi đã phát hành một khoản hoàn tiền và sau đó kiểm tra bảng là OK.
Nó không phải.
Bài học kinh nghiệm trong sản xuất: mặc dù thực tế chúng tôi muốn sử dụng các bảng InnoDB trong MySQL vì nhiều lý do MANY ... SURE bạn chưa quản lý để tìm một trong số ít bảng MyISAM không tôn trọng giao dịch và bạn không thể quay trở lại. Đừng tin tưởng MySQL trong bất kỳ trường hợp nào, và thói quen ban hành một "giao dịch bắt đầu" là một điều tốt. Ngay cả trong trường hợp xấu nhất (những gì đã xảy ra ở đây) nó đã không làm tổn thương bất cứ điều gì và nó sẽ bảo vệ tôi trên các bảng InnoDB.
Tôi phải khôi phục bảng từ bản sao lưu. May mắn là chúng tôi có các bản sao lưu hàng đêm, dữ liệu gần như không bao giờ thay đổi và bảng chỉ có vài chục hàng nên gần như tức thì. Để tham khảo, không ai biết rằng chúng tôi vẫn có các bảng không phải là InnoDB, chúng tôi nghĩ chúng tôi đã chuyển đổi chúng từ lâu. Không ai nói với tôi để tìm ra cho gotcha này, không ai biết nó đã có. Ông chủ của tôi sẽ làm điều tương tự (nếu anh ta đã gõ quá sớm trước khi gõ mệnh đề where).
cái gì đó để tác động của:
update email set processedTime=null,sentTime=null
trên một cơ sở dữ liệu bản tin sản xuất, gửi lại tất cả các email trong cơ sở dữ liệu.
bỏ và xóa cùng một lúc .. nhưng tại sao bạn phản ứng quá khó với cơ sở dữ liệu sản xuất kém ;-) – Chris