情況描述：
朋友的測試環境，程式呼叫的時候提示ora-00376:file 6 cannot be read at this time;
我先用shutdown abort停庫，然後startup時候提示ora-01157: cannot identify/lock data file 6 - see dbwr trace file
發現有個資料檔案沒了！
嘗試把這個datafile offline
sql>alter database datafile 6 offline;
報錯ora-01145: offline immediate disallowed unless media recovery enabled
看網上說資料庫是非歸檔模式的，嘗試開啟歸檔
sql>alter database archivelog;
報錯ora-00265: instance recovery required, cannot set archivelog mode
原來是因為我shutdown abort停的庫(如果shutdown immediate停的話當時應該就會直接報錯的，被我完美跳過了。。)
於是使用offline drop(網上查的)
sql>alter database datafile 6 offline drop;
然後sql>alter database open; 資料庫順利開啟
總結處理這個問題時出現錯誤的地方：
1.不應該盲目停庫
2.不細心 之前一直沒有發現是資料檔案丟了，在資料資料夾下面看到個dbf我就以為是有問題的那個dbf，其實我看到的那個是臨時表空間的dbf..只是因為命名太接近了，就把我迷住了。
3.停庫之前查v$datafile時發現了datafile 6的checkpoint_change#的和其他的不一致，但是這個線索沒有追蹤下去
網上查了一下 offline drop和offline沒什麼本質的區別，都是只改寫了control檔案，不會更新file$和ts$，但是對資料檔案的offline只能在資料庫是歸檔模式下才能執行；
對乙個datafile執行offline和offline drop的區別
1、對乙個datafile執行offline或offline drop本質上是一回事；但對乙個datafile執行offline只能在歸檔模式下，而對乙個datafile執行offline drop則既可以在歸檔模式也可 以在非歸檔模式下；
2、對乙個datafile無論是執行offline還是offline drop，都是只改寫了control檔案，不會更新file$和ts$，這就是為什麼可以在mount狀態下對某個datafile執行offline/offline drop的本質原因；
3、只有當對datafile所在的表空間執行offline normal的時候，才會既改寫control檔案，又更新ts$和seg$，oracle這裡會把ts$的online$欄位的值由1改為2，但依然不會去更新file$；
4、只有當對datafile所在的表空間執行drop操作的時候，oracle才會去更新ts$和file$，oracle這裡會把ts$的online$欄位的值由1改為3，會把file$的status$欄位由2改為1；
注 意，無論是file$的file#還是ts$的ts#，它們都是連續的！並且oracle會重用file$的file#，但是不會重用ts$裡的ts#， 這本質上是因為ts$裡會記錄tablespace的名字，而file$裡並沒有記錄datafile的名字，所以file$裡的記錄可以重用而ts$則 不能。
5、只要你對乙個datafile執行了offline或者offline drop操作，則oracle在open的時候就不會去儲存上（無論是檔案系統、裸裝置還是asm）校驗這個檔案了，所以即使這個檔案已經在儲存上被刪掉了，此時庫依然可以open。
6、 無論你是在歸檔模式還是在非歸檔模式，且無論你對某個datafile是執行了offline還是offline drop操作，只要歸檔日誌還在（對應於歸檔模式）或者相關的online redo log沒有被logfile switch覆蓋（對應於非歸檔模式），則這個datafile始終是可以online的，裡面的資料都還在。當然，即使歸檔日誌不在了，online redo log被logfile switch覆蓋了，這個datafile也是可以online的，只是裡面的資料可能會不一致。(從這搬運過來)
通過Google挖掘細分市場的乙個案例
我是亦仁，前阿里運營，現持續創業者。本文篇幅較長，無閱讀門檻，比較適合想兼職賺點零花錢的程式設計師 想找場景學習程式設計的小夥伴以及沒有創業點子的朋友。全文4000字，完整讀完大約需要10分鐘。受益於google這麼多年，不得不感慨google是我最好的老師，總能在我需要的時候為我指明方向，並一步步...
乙個案例引發的思考
今天下午，團隊開了乙個簡短的版本總結會。會上測試經理分析了乙個案例 某子程式在轉測試後發現不能被平台排程，原因是子程式的排程入口跟不符合平台規範。很明顯開發在轉測試前沒有充分自驗證，測試經理提出，後續對跟平台對接的子程式轉測試必須要有將子程式接入平台跑通後的驗證報告和相關checklist，否則不予...
乙個案例的簡單總結
翻看去年處理的乙個案例，發現處理時間挺長的，而且這個案例也有點意思，就再看多兩眼，做個簡單總結。1.首先是應用伺服器效能不穩定，排查之後，伺服器是vm，要求加資源，並且所有資源都reserved.2.接著就是應用伺服器連線資料庫時很不穩定，資料庫經常報 recovery mode 好像是資料庫莫名被...