熬了幾個月，終於，系統上線的日子就要到來，雖然知道bug很多，雖然，這幾天，程序還在修改，還在發佈。
週六的時候，重感冒，人暈暈的，剛好有個人過來和我說話，邊聊邊登錄用pl/sql dev 登錄到測試數據庫，查詢，奇怪，怎麼我清空的表，又有數據，馬上輸入：
truncate table xxxxrole drop storage;
truncate table yyyymenu drop storage;
習慣性的看下pl/sql dev 的標題，突然，直冒冷汗，我登錄錯了，現在是連接到了SIT環境，而不是我的測試環境，而現在， 樓下正在用SIT環境給用戶演示，培訓，估計有30-50個人正在看演示或操作。如果這個過程出錯，那將會給用戶帶來很多負面的感覺，對上線很不利，嚴重的話，已經算是小事故了。
我馬上試了下用 Flashback Query, 沒結果。嘗試用 Logminer, 無法運行，沒有設置UTL_FILE_DIR=, 似乎可以在運行時重新設置，但我當時不知道。檢查，系統運行在未歸檔模式，而且，恢復也需要關服務重啓，而這個時候，重啓似乎也不可接受。
一時六神無主。找了另外一個比較熟悉這些數據庫表關係的開發人員，讓他幫忙恢復。最後，從UAT環境，導出相關表的數據，再修改恢復到SIT環境，半個小時後搞定。
得了幾個經驗教訓：
1， truncate table， rm -f 之類的操作，一定要慎重，再慎重；
2， 不同數據庫，特別是測試和實際環境，應該不同用戶名密碼，這樣，登錄錯了，也會有警覺；
3， 業務環境的連接，默認，還是不要保存到tnsnames.ora，出錯，會死人的；
4， 系統還是運行在歸檔模式爲佳；
5，精神不佳時，還是不要操作數據庫;
6，不要給數據庫USER分配不必要的權限，特別是如dba之類;
...