開發人員向我反映由於誤操作刪除了表裡的一些資料，要求我恢復。
諮詢了誤操作的時間點後，我用閃回查詢試了一下，被誤刪的資料還在回滾段，可以挽救回來。
我先備份了現在表裡的資料。
create table a as select * from 業務表。
然後我做了一件愚蠢的事
truncate table 業務表
insert into 業務表 select * from 業務表 as of timestamp to_timestamp('2014-06-18 13:30:01','yyyy-mm-dd hh24:mi:ss');
error at line 1:
ora-01466: unable to read data - table definition has changed
結果提示了錯誤，說表的定義已經改變。因為oracle的閃回要求你的表結構從你誤操作的時間點起到執行閃回查詢的時間點，表定義是不能改變的。
剛剛閃回查詢還可以，怎麼短短一分鐘不到，誰就把表結構給改了呢？
奧，我明白了，是我自己犯了錯誤，truncate操作也被閃回查詢認為是改變表結構定義的操作。是我自己做的孽。
怎麼辦？
還好，truncate之前，我是備份了 開發誤操作後的資料的，這部分資料我可以找回。
那麼開發誤操作的資料如何找回呢？閃回是不行了
logminer要登場了。慶幸的是，所有的資料庫我都開啟了輔助日誌。
最終通過logminier，
**用品店
www.xfqiao.com解析了那段時間的誤操作日誌，通過sql_undo欄位的內容，成功恢復出了資料，有驚無險。
這個事件給我提了個大醒。dba要了解oracle特性的細節，基礎知識要紮實，盡量避免使用truncate操作。刪除資料前要做備份。
誤操作，導致git的ssh授權校驗被覆蓋
下午在做從跳板機到git伺服器的配置時，在git伺服器上操作授權校驗檔案時，cat檔案做追加操作，結果敲的 然後回車就悲劇了，哎！瞬時石化了，悲劇了，備份也被我mv了.幸虧在另外一屏還有一些screen時的一些記錄，無奈在screen中無法滾屏，趕緊拷貝，分析規律，幸虧還能找到每個人的pub key...
記一次ubuntu誤操作導致無法用sudo
原因 掛載自己做的rootfs，進入目錄，執行sudo chmod 777 etc 多了乙個斜槓。本意是更改自己的rootfs的etc目錄的屬性的，沒想到變成系統的 etc了。解決 重啟系統進入recovery模式 修改許可權為0440。使用虛擬機器的話，要在啟動時按住shift鍵不放 我在這一步花...
Linux系統誤操作導致終端不能夠識別最基本的命令
1.問題描述 在我修改完配置檔案之後,系統不能夠識別最基本的命令列,比如ls等 2.問題分析 命令不能用了主要是你的 path變數錯誤的關係。如果你只是在shell下 export 命令改的名字的話 直接restart就行了。如果你是更改配置檔案改的，可以 bin vi 你的配置檔案,進行修改正常就...