昨天，遇到一件讓自己膽戰(zhàn)心驚的事情，就是數(shù)據(jù)庫(kù)導(dǎo)出的DMP文件由原來(lái)的800多M變?yōu)榱爽F(xiàn)在的300多M，整整少了500M！ 仔細(xì)回想，自己平時(shí)操作數(shù)據(jù)庫(kù)還是很小心的，就算有失誤，也不可能造成那么大的損失啊！ 在這里記錄一下解決過(guò)程： 1，首先當(dāng)然想到了Oracle的重做日志功能，也學(xué)習(xí)了Oracle自帶的日志分析工具LogMiner的使用方法，等會(huì)在另外一篇文章里記錄一下這個(gè)工具的使用方法。 2，在使用LogMiner之前，突然想到，能不能把800M的數(shù)據(jù)庫(kù)和300M的數(shù)據(jù)庫(kù)的每張表都單獨(dú)導(dǎo)出為DMP文件，進(jìn)行一下大小的對(duì)比 3，在用exp導(dǎo)出時(shí)，有一個(gè)log選項(xiàng)設(shè)定導(dǎo)出日志的文件路徑，此文件記錄了所有導(dǎo)出的數(shù)據(jù)庫(kù)表名和記錄數(shù)，用UltraEdit32的正則表達(dá)式功能去除了除開表名的其他不相關(guān)數(shù)據(jù)。 4，用Java編寫了一個(gè)小程序，讀入所有表名，對(duì)每個(gè)表名單獨(dú)進(jìn)行exp操作。 5，果然不出所料，其中有一個(gè)表被某個(gè)管理員清理過(guò)，那個(gè)表本來(lái)就很大，占到了500多M！ 至此，問(wèn)題解決，總結(jié)一下，不管碰到什么意外的問(wèn)題，不要慌張，冷靜分析才是王道！ PS:被刪除數(shù)據(jù)的那張表竟然占到了500多M，而整個(gè)數(shù)據(jù)庫(kù)才800M，很不解，然后看了一下這張表的模式，發(fā)現(xiàn)設(shè)計(jì)的很有問(wèn)題，這張表里面表達(dá)了多對(duì)多的關(guān)系，所以數(shù)據(jù)冗余太大，而且這些冗余根本就不是必須的，反而影響了性能！找常理來(lái)說(shuō)，針對(duì)多對(duì)多的關(guān)系應(yīng)該轉(zhuǎn)化為兩個(gè)多對(duì)一的關(guān)系。
文章來(lái)源:http://localhost/wp2/?p=48