刪除數(shù)據(jù)庫的sql語句如何寫？drop database 數(shù)據(jù)庫名 --刪除數(shù)據(jù)庫的drop table 表名--刪除表的delete from 表名 where 條件 --刪除數(shù)據(jù)的truncatO

刪除數(shù)據(jù)庫的sql語句如何寫？

drop database 數(shù)據(jù)庫名 --刪除數(shù)據(jù)庫的drop table 表名--刪除表的delete from 表名 where 條件 --刪除數(shù)據(jù)的truncat

Oracle數(shù)據(jù)庫運行越來越慢，應(yīng)該怎么優(yōu)化一下？

隨著業(yè)務(wù)數(shù)據(jù)的增長，以及新業(yè)務(wù)的推出，很多企業(yè)都面臨著系統(tǒng)性能的問題，并且日益凸顯。似乎用盡了所有招數(shù)，但性能就是不見改善，問題到底出在哪里？

遇到如此問題，我們一般怎么做呢？是不是都有過下面的體會？

不差錢人的做法：

升級cpu、擴內(nèi)存、換固態(tài)盤存儲，只能說一開始很管用，慢慢地老問題又出現(xiàn)了。

老實人做法：

新上線了業(yè)務(wù)系統(tǒng)性能不佳，怎么辦呢？我們來玩打游擊。把一些不重要的業(yè)務(wù)放在晚上運行，調(diào)整新業(yè)務(wù)的功能模塊，或者暫時不做數(shù)據(jù)同步等

扯皮做法：

看看網(wǎng)絡(luò)有沒有問題呢，有的話就改；是不是存儲的問題呢，有問題就換；運維人員有沒有問題呢，服務(wù)商也隨意招；但要誰來承擔(dān)責(zé)任呢，每次遇到嚴重的故障，是不是時間用來扯皮較多？

現(xiàn)實中，很多運維人員都很拼命地在保障系統(tǒng)高效運行，但根據(jù)相關(guān)統(tǒng)計，80%的系統(tǒng)性能問題來自SQL方面的問題。所以，在基本保證網(wǎng)絡(luò)(跟平時比，跟同時段其他業(yè)務(wù)比)、服務(wù)器(CPU、內(nèi)存使用率)、存儲（IO等待）等資源都問題不大的情況下，可以通過查看Oracle對應(yīng)時段的AWR、ASH、ADDM來尋找同時段運行較慢的SQL。有針對性的去優(yōu)化。

而SQL優(yōu)化中最基本的做法就是建立索引（這個需要根據(jù)SQL執(zhí)行計劃去建立合適的索引）、SQL改寫、HINT提示等等

性能優(yōu)化是一個比較復(fù)雜的系統(tǒng)工程，以上僅是提示點思路吧，具體還需要根據(jù)系統(tǒng)的實際情況多做練習(xí)，然后再觀察。優(yōu)化是一個循序漸進的過程，就像我們?nèi)松∫粯?，先吃藥治病，然后再去醫(yī)院復(fù)查，看看是否已經(jīng)治愈一個道理。

希望以上對題主有所幫助，也歡迎其他大牛提出更好的思路，幫助題主。