1樓：石痕
今天，2023年正月十五，下午4點多，我也是update忘了加where，導致1400多條資料受影響，還好整個庫資料不多。先把昨天資料恢復到新建資料庫，在新建資料庫匯出受影響的表列資料，再把匯出資料恢復到資料庫。影響只有一天，20多條，手動改。
當時也快嚇死了，哈哈。不過小單位，真的搞不定最多影響一天，問題不大
2樓：Agnes
我那些天也犯了乙個一模一樣的錯誤，好在是watchdog裡面，沒有影響正常的資料流通。我當時做的是ROLLBACK,結果那個table裡面若干個record沒有update回來， 引起了乙個false alert。
其實這種錯誤說起來是系統設計的問題，本來資料庫操作就是非常容易出錯，乙個script寫錯了，引起大的問題，不應該僅僅歸結於程式設計師，就像亞麻很久以前的那個AWS的問題一樣。
3樓：Kevin
生產上直接執行指令碼？還是剛睡醒？不是很緊急的問題，一般還是寫方案後找人評審再處理吧，要是放到我們公司，那不僅僅是開除那麼簡單了。希望這個同行的哥們引以為戒呀！
4樓：南瓜
正常配置的資料庫基本都是可以恢復的不要慌 ， 以前經常誤操作delete，update 什麼的， 現在恢復資料起來得心應手
5樓：
我曾經把生產環境的redis flush了立刻找開發和運維過來看，20分鐘從stg環境拉資料修復了現場。
最後被一頓臭罵，但是除了專案經理公司其他人都不知道。
當季度績效也沒影響。
6樓：Sophia
和我一起入職的小夥伴，在工作第一年將erp系統中直接執行了一條不帶where的sql語句，將全廠幾百萬條記錄的發貨數全部改成了2這個神奇的數字。然後我們夥同也是一起來的dba，用快照將資料恢復出來，本以為結束了，結果尼瑪由於剛去業務不熟居然發現這個發貨表下有表級的變更發貨數的觸發器，然後又把相關的表又恢復了一次，花了一上午時間，市場部主任坐我們旁邊一上午無語的看著我們，不過還好最後沒出事情。結論如下:
1、觸發器很重要，以後每次更新較大資料量的時候都會看觸發器。
2、發現資料批量處理問題要及時處理，快照時間有限。
3、與業務部門不斷協調溝通，在資料沒有恢復之前，盡量不要執行相關可能更改資料的業務操作。保證不會一邊恢復，資料一邊又在變更。資料恢復之後，讓業務部門抽查核對，確保資料不存在大範圍的二次問題。
這點是最重要的。
ps:我們用的oracle,自己開發的erp系統。
7樓：
資料庫出問題，妥妥的s1級別的故障，你還自己想辦法？直接上報dba，大家一起坐下來趕緊緊急處理啊，這是7x24的活。你這心也是大拖了幾天...
你這叫是修好了也就得過且過了，要是沒弄好影響了production，開除都算是輕的。報上去責任在大也不會開除你。
8樓：
我也犯睏的時候更新過生產資料庫
但基本每次都會 START TRANSACTION
然後當你看更新影響了全表的時候，你會瞬間清醒過來 ...
9樓：buger
一般情況下，我執行影響較大的語句都會用以下的方式BEGIN TRAN
執行的SQL語句
ROLLBACK TRAN
執行完成後，檢視受影響的行數，確認無誤後，再執行一次SQL。
10樓：飛一站
後續建議關閉sql server client的自動事務，每次update之後必須手動commit才資料落地。
或者換其他支援手動commit的資料庫管理器。
11樓：聰明的愚人
有過類似的經歷，當時還是剛入新公司第二天，和乙個老同事先在測試庫里update乙個字段，表象沒問題，更新上了想要的資料，還在test環境驗證了多條更新資料，報告上司：這樣更新沒問題。然後將sql語句use改一下，然後F5。
一眨眼，我倆傻眼。影響行數3萬多=整表記錄行數。立馬乙個轉身，報告領導：
某工，那個語句有問題，將所有資料都更新了。然後領導過來，看一下情況，然後就開始忙活著了，恢復後已是凌晨了。現在的我乖多了，update前先備份。
12樓：
我仍然記得06年前公司的一位程式設計師也是幹了這個沒where的事，生產環境停三天補資料，損失40萬美金。後來我做任何架構設計都要求一熱備一冷備，發布之前再備份。
13樓：天使喜歡
產品環境應該設定為非預設提交。從選項中取消選擇SET IMPLICIT_TRANSACTIONS check-box。
具體操作為：導航到選項工具》選項》查詢執行》 SQL Server> ANSI在Microsoft SQL Server Management Studio中。
14樓：Minghao Hu
跟SQL語言的設計有很大的關係，一般通用程式語言都是先做條件判斷，再執行具體操作，而使用SQL時都是先寫執行的操作，再限定這一操作的執行物件的所滿足的條件，二者邏輯相反。通用程式語言的邏輯更符合我的生活常識，而SQL在查詢上下文複雜時很可能遺忘需要限定的條件。C#的Linq為什麼是先寫條件再寫操作，可能與通用程式語言使用者與SQL使用者熟悉的邏輯不同有關。
15樓：jusalun
馬上聯絡dba，你再操作的話會繼續汙染資料擴大損失
到時候就不是能根據UPDATE_LOG回滾的事情了
你要是藏著掖著的話，造成更大的損失，那你就可以周一刷簡歷了
16樓：Eason
我的第乙份工作，運維乙個生產系統，沒有測試環境，直接用生產環境編譯生效儲存過程的那種，資料庫是SQL Server。
有次星期六早上，加班處理資料，沒加where條件，一張產品資訊表乙個字段幾十萬條被我update了。
我滴個小心肝呦，接手系統的時間和我接觸資料庫的時間一樣，三個月。
緊急聯絡了開發（沒有dba），開發是個小妹妹，跑來公司，經驗也不足，處理不了，然後聯絡了另外乙個系統的開發，他也打車來公司幫忙，中午請他們吃了飯。
開發安慰我說他們都犯過這樣的錯，還好週六，沒什麼生產。
處理過程大概是這樣：找到備份，恢復上乙個時間段的，在恢復之前，把這段時間產生的資料再備份下。備份恢復了，我再把缺的資料補上。
後來我每次處理資料都提醒自己加where，並且是先Select出來，或者count下看有多少條。
現在換了家公司，主要用的Oracle，各種環境齊全，媽媽再也不用擔心了。
17樓：羊頭怪
估計是職場新人，oracle是可以閃回的SQLserver估計也是可以的。不過前提是不要拖太久。拖時間長了，資料庫自身帶的備份空間滿了就被覆蓋了。到時候就真的GG了
18樓：「已登出」
聽過很多次身邊的朋友有這種操作的，刪了幾十條到幾萬條的都有。及時告訴領導，sqlserver可以通過日誌恢復，找會處理的人弄。
另外，生產庫這麼重要，是不能隨便操作的。這麼隨意的操作，說明根本不重視。這樣的專案中，公司基本上沒像樣甚至沒有DBA。
所以最重要的是發現問題-->查詢原因-->了解影響範圍-->及時上報領導。
ps:昨天我也發現同事經過某某某操作刪了8個月的檔案，還好能補救。
19樓：MAZE
等那麼久，日誌都被覆蓋了，萬一備份也覆蓋了，DBA也無力回天啊，就算有定時備份，生產環境這麼長時間又產生了新資料，還不能簡單的回滾資料還得手動合併新資料，這鍋DBA背的很苦澀。
20樓：明省
我也幹過類似的事，不同之處在於生產庫的整表資料量有1200多萬條，當時感覺心臟都不不工作了。
兩個多小時後，我得救了，因為我有乙個習慣，就是把update和delete永遠先放
begin tran
rollback tran
裡跑一遍，看看受影響的行數，然後再commit
21樓：spring
請第一時間通知領導和相關業務人員，商量處理辦法。我第一天上班，老闆的第一條要求就是有問題不能隱瞞不報，出了問題要第一時間報告出來。那個公司歷史上只開過乙個人，就是安裝裝置時出錯，隱瞞不報導致裝置大量損壞，最後耗費了大量的人力物力才搞好，給公司的聲譽帶來極大負面影響。
22樓：大火
我也幹過這種蠢事，將資料庫4萬多條時間記錄update成當前時間了。當時就傻了，還好影響不大，領導沒有太多責怪我。
以後注意update後面加個top(1)就好了，也不用擔心沒選中後面的where了。(當然，不管怎樣，做增刪改操作一定要仔細仔細再仔細啊！避免再次出現這種錯誤了！)
23樓：Ivony
問題已經發生責任就無可推卸了，最好的補救方式就是盡快通知專業人士處理。像你這樣自以為是的補救只會讓問題越來越糟糕。
更何況，你有隨便UPDATE整個表的許可權，本來就有人要為這種事情擔責任的。你承擔你能承擔的那部分就好。
職場和人生的乙個很重要的區別在於，職場是有限責任制的，每個人只按照自己的職位和薪資承擔有限的責任，這個責任通常來說以你的薪資為限。也就是說在非故意且不違法的情況下造成的一切損失公司只會扣除你的薪資而不會讓你承擔賠償責任的。
所以，怕什麼……
最後，公司沒有告訴出現你這種事情你應該做什麼，這也是有人要擔責任的。
資料庫操作優化如何入手？
ccxxiii 資料庫效能優化 系統CPU，記憶體，磁碟儲存，系統引數，以oracle為例，資料庫SGA，PGA，Process，cursor，session等引數設定優化。對於資料庫SQL優化，首先要規範sql寫法，索引建立，資料生命週期管理等。何以解憂，唯有讀書和實踐。總結幾點 1.善用expl...
資料庫最核心操作是什麼？
假定是一般的關係型資料庫，最重要的當然是 DCL，DDL，DQL，DML呀 DCL 許可權管理 DDL 庫表結構管理 DQL 查詢 DML 資料修改。 lemon wonder 簡單的一條insert插入操作，就涉及到方方面面，是否有insert許可權，要滿足ACID原則，插入的資料是否涉及到隱式型...
php 資料庫操作類 快取 日誌？
有關PHP的快取部分的內容，可以直接使用thinkphp中的預設模組就可以，方便。此外，有關快取是這樣的 普遍快取技術 大多也和資料庫結合在一起 舉個常用的方法，多表關聯的時候，把附表中的內容生成陣列儲存到主表的乙個欄位中，需要的時候陣列分解一下，這樣的好處是唯讀乙個表，壞處就是兩個資料同步會多不少...