資料庫落盤慢

Ⅰ oracle 資料庫很慢，應該如何優化

1、是這樣的。
2、這個說不好，我沒這么做過。你手邊應該有oralce的全套電子文檔吧。關鍵是你要找對系統表或者視圖。我記得索引的系統視圖不是這個。
3、這些與你要做的有關系嗎？別像沒頭蒼蠅一樣瞎撞了。
4、不用刪表，如果你連基本的語句命令都不懂，那隻能看書了。
5、慢的原因有好多，逐步排除吧，等找到真正原因再說。急沒用的。
6、默認情況下，是會建到用戶的默認表空間的。
7、這個看你的維護需要。最起碼先弄明白你的庫是怎麼回事再說吧。就從這些問題看，你根本就是門外漢，連庫是怎麼回事都沒弄明白。

Ⅱ Mysql資料庫伺服器逐漸變慢 該怎麼分析與解決

我們先來看第一個階段，MySQL慢的診斷思路，一般我們會從三個方向來做：

• 第一個方向是MySQL內部的觀測

• 第二個方向是外部資源的觀測

• 第三個方向是外部需求的改造

1.1 MySQL 內部觀測

我們來看MySQL內部的觀測，常用的觀測手段是這樣的，從上往下看，第一部分是Processlist，看一下哪個SQL壓力不太正常，第二步是explain，解釋一下它的執行計劃，第三步我們要做Profilling，如果這個SQL能再執行一次的話, 就做一個Profilling，然後高級的DBA會直接動用performance_schema ，MySQL 5.7 以後直接動用sys_schema，sys_schema是一個視圖，裡面有便捷的各類信息，幫助大家來診斷性能。再高級一點，我們會動用innodb_metrics進行一個對引擎的診斷。

除了這些手段以外，大家還提出了一些亂七八糟的手段，我就不列在這了，這些是常規的一個MySQL的內部的狀態觀測的思路。除了這些以外，MySQL還陸陸續續提供了一些暴露自己狀態的方案，但是這些方案並沒有在實踐中形成套路，原因是學習成本比較高。

1.2 外部資源觀測


外部資源觀測這部分，我引用了一篇文章，這篇文章的二維碼我貼在上面了。這篇文章是國外的一個神寫的，標題是：60秒的快速巡檢，我們來看一下它在60秒之內對伺服器到底做了一個什麼樣的巡檢。一共十條命令，這是前五條，我們一條一條來看。

1.uptime，uptime告訴我們這個機器活了多久，以及它的平均的負載是多少。


2.dmesg -T | tail，告訴我們系統日誌里邊有沒有什麼報錯。

3.vmstat 1，告訴我們虛擬內存的狀態，頁的換進換出有沒有問題，swap有沒有使用。

4. mpstat -P ALL，告訴我們CPU壓力在各個核上是不是均勻的。

5.pidstat 1，告訴我們各個進程的對資源的佔用大概是什麼樣子。


我們來看一下後五條：

首先是iostat-xz 1，查看IO的問題，然後是free-m內存使用率，之後兩個sar，按設備網卡設備的維度，看一下網路的消耗狀態，以及總體看TCP的使用率和錯誤率是多少。最後一條命令top，看一下大概的進程和線程的問題。

這個就是對於外部資源的診斷，這十條命令揭示了應該去診斷哪些外部資源。

1.3 外部需求改造

第三個診斷思路是外部的需求改造，我在這里引用了一篇文檔，這篇文檔是MySQL的官方文檔中的一章，這一章叫Examples of Common Queries，文檔中介紹了常規的SQL怎麼寫, 給出了一些例子。文章的鏈接二維碼在slide上。

我們來看一下它其中提到的一個例子。

它做的事情是從一個表裡邊去選取，這張表有三列，article、dealer、price，選取每個作者的最貴的商品列在結果集中，這是它的最原始的SQL，非常符合業務的寫法，但是它是個關聯子查詢。

關聯子查詢成本是很貴的，所以上面的文檔會教你快速地把它轉成一個非關聯子查詢，大家可以看到中間的子查詢和外邊的查詢之間是沒有關聯性的。

第三步，會教大家直接把子查詢拿掉，然後轉成這樣一個SQL，這個就叫業務改造，前後三個SQL的成本都不一樣，把關聯子查詢拆掉的成本，拆掉以後SQL會跑得非常好，但這個SQL已經不能良好表義了，只有在診斷到SQL成本比較高的情況下才建議大家使用這種方式。

為什麼它能夠把一個關聯子查詢拆掉呢？

這背後的原理是關系代數，所有的SQL都可以被表達成等價的關系代數式，關系代數式之間有等價關系，這個等價關系通過變換可以把關聯子查詢拆掉。

上面的這篇文檔是一個大學的教材，它從頭教了關於代數和SQL之間的關系。然後一步步推導怎麼去簡化這句SQL。

第一，MySQL本身提供了很多命令來觀察MySQL自身的各類狀態，大家從上往下檢一般能檢到SQL的問題或者伺服器的問題。

第二，從伺服器的角度，我們從巡檢的腳本角度入手，伺服器的資源就這幾種，觀測手法也就那麼幾種，我們把伺服器的資源全部都觀察一圈就可以了。

第三，如果實在搞不定，需求方一定要按照資料庫容易接受的方式去寫SQL，這個成本會下降的非常快，這個是常規的MySQL慢的診斷思路。

Ⅲ 伺服器資料庫文件拷貝到移動硬碟慢

你是要問伺服器資料庫文件拷貝到移動硬碟慢的原因這個問題吧，具體原因如下：
可能是由於儲存問題、客戶端問題或者是伺服器問題導致的。
具體的解決方法為：在託管共享文件夾的文件伺服器上，將文件復制到其本地硬碟。如果文件復制速度異常低（比平均速度），請嘗試更新存儲的驅動程序。
如果問題仍然存在，請與驅動程序製造商聯系以進行進一步的故障排除。

Ⅳ 當資料庫變慢時的解決方法有哪些

我們使用電腦和手機時候最不能忍受就是設備又卡又慢了,嚴重影響我們工作或者游戲體驗。當資料庫變慢時，我們應如何入手，下面的解決方法。

方法步驟

第一章 檢查系統的狀態

1.1 使用sar來檢查操作系統是否存在IO問題

1.2 關注內存vmstat

1.3 找到使用資源特別大的Oracle的session及其執行的語句

1.4 查找前十條性能差的sql語句

當資料庫變慢時，我們應如何入手

當應用管理員通告現在應用很慢、資料庫很慢時，當Oracle DBA在資料庫上做幾個示例的Select也發現同樣的問題時，有些時侯就會無從下手，因為DBA認為資料庫的各種命種率都是滿足Oracle文檔的建議。實際上如今的優化己經向優化等待(waits)轉型了，實際中性能優化最根本的出現點也都集中在I/O，這是影響性能最主要的方面，由系統中的等待去發現Oracle庫中的不足、操作系統某些資源利用的不合理是一個比較好的辦法。下面把一些實踐經驗與大家分享，本文測重於Unix環境。

第一章 檢查系統的狀態

通過操作系統的一些工具檢查系統的狀態，比如CPU、內存、交換、磁碟的利用率，根據經驗或與系統正常時的狀態相比對，有時系統表面上看起來看空閑，這也可能不是一個正常的狀態，因為cpu可能正等待IO的完成。除此之外，還應觀注那些佔用系統資源(cpu、內存)的進程。

1.1 使用sar來檢查操作系統是否存在IO問題

#sar -u 2 10 -- 即每隔2秒檢察一次，共執行20次。

結果示例：

註：在redhat下，%system就是所謂的%wio。

Linux 2.4.21-20.ELsmp (YY075) 05/19/2005

10:36:07 AM CPU %user %nice %system %idle

10:36:09 AM all 0.00 0.00 0.13 99.87

10:36:11 AM all 0.00 0.00 0.00 100.00

10:36:13 AM all 0.25 0.00 0.25 99.49

10:36:15 AM all 0.13 0.00 0.13 99.75

10:36:17 AM all 0.00 0.00 0.00 100.00

其中：

Ø %usr指的是用戶進程使用的cpu資源的百分比;

Ø %sys指的是系統資源使用cpu資源的百分比;

Ø %wio指的是等待io完成的百分比，這是值得觀注的一項;

Ø %idle即空閑的百分比。

如果wio列的值很大，如在35%以上，說明系統的IO存在瓶頸，CPU花費了很大的時間去等待I/O的完成。Idle很小說明系統CPU很忙。像以上的示例，可以看到wio平均值為11，說明I/O沒什麼特別的問題，而idle值為零，說明cpu已經滿負荷運行了。

當系統存在IO問題時，可以從以下幾個方面解決：

Ø 聯系相應的操作系統的技術支持對這方面進行優化，比如hp-ux在劃定卷組時的條帶化等方面。

Ø 查找Oracle中不合理的sql語句，對其進行優化;

Ø 對Oracle中訪問量頻繁的表除合理建索引外，再就是把這些表分表空間存放以免訪問上產生熱點，再有就是對表合理分區。

1.2 關注內存

常用的工具便是vmstat，對於hp-unix來說，可以用glance。Aix來說可以用topas。當發現vmstat中pi列非零，memory中的free列的值很小，glance、topas中內存的利用率多於80%時，這時說明內存方面應該調節一下。方法大體有以下幾項：

Ø 劃給Oracle使用的內存不要超過系統內存的1/2，一般保在系統內存的40%為益。

Ø 為系統增加內存;

Ø 如果你的連接特別多，可以使用MTS的方式;

Ø 打全補丁，防止內存漏洞。

1.3 找到使用資源特別大的Oracle的session及其執行的語句

Hp-unix可以用glance或top。IBM AIX可以用topas。此外可以使用ps的命令。

通過這些程序可以找到點用系統資源特別大的這些進程的進程號，就可以通過以下的sql語句發現這個pid正在執行哪個sql，這個sql最好在pl/sql developer、toad等軟體中執行：

SELECT a.username, a.machine, a.program, a.sid, a.serial#, a.status,

c.piece, c.sql_text

FROM v$session a, v$process b, v$sqltext c

WHERE b.spid = 'ORCL'

AND b.addr = a.paddr

AND a.sql_address = c.address(+)

ORDER BY c.piece;

可以把得到的這個sql分析一下，看一下它的執行計劃是否走索引。對其優化避免全表掃描，以減少IO等待，從而加快語句的執行速度。

提示：在做優化sql時，經常碰到使用in的語句，這時一定要用exists把它給換掉，因為Oracle在處理In時是按Or的方式做的，即使使用了索引也會很慢。比如：

SELECT col1, col2, col3 FROM table1 a

WHERE a.col1 NOT IN (SELECT col1 FROM table2)

可以換成：

SELECT col1, col2, col3 FROM table1 a

WHERE NOT EXISTS

(SELECT 'x' FROM table2 b WHERE a.col1=b.col1)

1.4 查找前十條性能差的sql語句

SELECT * FROM (SELECT parsing_user_id, executions, sorts, command_type,

disk_reads, sql_text FROM v$sqlarea

ORDER BY disk_reads DESC)

WHERE ROWNUM<10;

第二章 檢查會話狀態

要快速發現Oracle Server的性能問題的原因，可以求助於v$session_wait視圖，看系統的這些session在等什麼，使用了多少的IO。以下是參考腳本：

-- 腳本說明：查看佔I/O較大的正在運行的session：

SELECT se.sid, se.serial#, pr.spid, se.username, se.status, se.terminal,

se.program, se.mole, se.sql_address, st.event, st.p1text,

si.physical_reads, si.block_changes

FROM v$session se, v$session_wait st, v$sess_io si, v$process pr

WHERE st.sid=se.sid AND st.sid=si.sid

AND se.PADDR=pr.ADDR

AND se.sid>6

AND st.wait_time=0

AND st.event NOT LIKE '%SQL%'

ORDER BY physical_reads DESC;

對檢索出的結果的幾點說明：

1. 以上是按每個正在等待的session已經發生的物理讀排的序，因為它與實際的I/O相關。

2. 可以看一下這些等待的進程都在忙什麼，語句是否合理?

SELECT sql_address FROM v$session WHERE sid=;

SELECT * FROM v$sqltext WHERE address=;

執行以上兩個語句便可以得到這個session的語句。

也以用alter system kill session 'sid, serial#';把這個session殺掉。

3. 應觀注一下event列，這是調優的關鍵一列，下面對常出現的event做以簡要的說明：

1) buffer busy waits，free buffer waits這兩個參數所標識是dbwr是否夠用的問題，與IO很大相關的，當v$session_wait中的free buffer wait的條目很小或沒有時，說明系統的dbwr進程決對夠用，不用調整;free buffer wait的條目很多，系統感覺起來一定很慢，這時說明dbwr已經不夠用了，它產生的wio已經成為資料庫性能的瓶頸，這時的解決辦法如下：

Ø 增加寫進程，同時要調整db_block_lru_latches參數：

示例：修改或添加如下兩個參數

db_writer_processes=4

db_block_lru_latches=8

Ø 開非同步IO。IBM這方面簡單得多，hp則麻煩一些，可以與Hp工程師聯系。

2) db file sequential read，指的是順序讀，即全表掃描，這也是應盡量減少的部分，解決方法就是使用索引、sql調優，同時可以增大db_file_multiblock_read_count這個參數。

3) db file scattered read參數指的是通過索引來讀取，同樣可以通過增加db_file_multiblock_read_count這個參數來提高性能。

4) latch free與栓相關，需要專門調節。

5) 其他參數可以不特別觀注

補充：解決系統變慢的常用技巧方法

1、在我的電腦窗口，右擊要清理的盤符―“屬性”―“清理磁碟”--勾選要刪除的文件--確定--是。

2、右鍵瀏覽器e――屬性――點2個刪除1個清除(都要逐一確定)――確定 。

3、把C:WINDOWSPrefetch(預讀文件)把裡面的文件全部刪除

4、用優化大師或超級兔子清理注冊表和垃圾文件。

5、“開始”――運行中輸入msconfig――確定――啟動――除了輸入法ctfmon以外的勾全去掉。

6、右鍵我的電腦”――屬性――點高級――點啟動和故障恢復中的設置――去掉所有的勾――寫入調試信息選擇“無”――確定――點高級下面錯誤報告――點禁用――2次確定。

7、“開始”..打開控制面板中的文件夾選項..點查看..點去末項自動搜索文件夾前面的勾..確定。

8、右鍵我的電腦――屬性――硬體――設備管理器――雙擊IDE控制器――次要通道――高級設置――傳送模式都選DMA――設備類型選無――確定――主要通道也同樣設置――確定。

9、右鍵C盤進行磁碟清理和其它選項中的系統還原清理。

Ⅳ 資料庫寫入數據很卡，查詢也很慢，懂的高手請來，賞分解決可以追加分

看這種現象，估計是SQL語句寫的不夠好，SQL要用綁定變數的方式，影響查詢性能主要就是執行SQL過多，而且SQL寫的不好，無效索引過多，第一步必須優化SQL，之後就是清理歷史數據，清理無用索引，大表數據可以用分區表，還有就是tomcat的性能也需要注意，如果太卡，重啟一下tomcat試試，是否有效果

Ⅵ 資料庫和應用分開部署訪問變慢

資料庫慢一般有三種情況第一種情況 逐漸變慢 要建立一個長期的監控機制 比如 寫個shell腳本每天的忙時(通常 ~ etc )定時收集os neork db的信息 每個星期出report對收集到的信息進行分析 這些數據的積累 可以決定後期的優化決策 並且可以是DBA說服manager採用自己決策的重要數據 DBA的價值 就在每個星期的report中體現
第二種情況 突然變慢 也是最容易解決的 先從業務的角度看是DB的使用跟以前有何不同 然後做進一步判斷 硬體/網路故障通常也會引起DB性能的突然下降
第一步: 察看DB/OS/NEORK的系統log 排除硬體/網路問題
第二步 察看資料庫的等待事件 根據等待事件來判斷可能出問題的環節 如果 沒有等待事件 可以排除資料庫的問題 如果有等待時間 根據不同的等待事件 來找引起這些事件的根源
比如latch free等跟SQL parse有關系的等待事件 OS的表現是CPU 的佔用率高
db file scattered read等跟SQL disk read有關系的等待時間 OS的表現是iostat可以看到磁碟讀寫量增加
第三步: 察看os的信息 CPU/IO/MEMORY等
a Cpu 的佔用率
CPU佔用率與資料庫性能不成反比 CPU佔用率高 不能說明資料庫性能慢 通常情況 一個優化很好 而且業務量確實很大的資料庫 CPU的佔用率都會高 而且會平均分布在每個進程上 反過來 CPU的佔用率都會高也不代表資料庫性能就好 要結合資料庫的等待事件來判斷CPU佔用率高是否合理
如果某個進程的cpu佔用高 肯定是這個進程有問題 如果 不是oracle的進程 可以讓application察看是否程序有死循環等漏洞 如果 是oracle的進程 可以根據pid查找oracle數據字典看看這個進程的發起程序 正在執行的sql語句 以及等待事件 然後 不同情況使用不同的方法來解決
b IO
排除硬體的IO問題 資料庫突然變慢 一般來說 都是一個或幾個SQL語句引起的
如果IO很頻繁 可以通過優化disk reads高的TOP SQL來解決 當然這也是解決IO問題的最笨也是最有效的辦法
OS以及存儲的配置也是影響IO的一個重要的原因
比如 最常見的HP unix下非同步IO的問題 如果DBA GROUP沒有MLOCK的許可權 ORACLE是不使用AIO的 偏偏OS與DB的兩方的admin如果配合不夠好地話 這個配置就很容易給漏掉了
c Memory
第二種情況與memory的關系比較小 只要SGA區配置合理沒有變化 一般來說 只要不是Application Memory leak 不會引起突然變慢的現象
第三種情況 不定時變慢 是最難解決的 現場出現的問題原因也是五花八門千奇百怪 最重要的是 出現慢的現象時 以最快的速度抓取到最多的信息以供分析 先寫好抓取數據的shell 腳本 並在現象發生時及時按下回車鍵