❶ 硬碟出現IO錯誤，該怎麼辦
1、先下載並解壓軟體打開後，直接雙擊需要恢復的分區，然後右擊軟體圖標選擇《以管理員身份運行》
(1)硬碟io弱擴展閱讀
1、保持良好的環境
硬碟對環境的要求比較高，有時候嚴重集塵或是空氣濕度過大，都會造成電子元件短路或是介面氧化，從而引起硬碟性能的不穩定甚至損壞。
2、防止受震動
硬碟是十分精密的存儲設備，進行讀寫操作時，磁頭在碟片表面的浮動高度只有幾微米；即使在不工作的時候，磁頭與碟片也是接觸的。硬碟在工作時，一旦發生較大的震動，就容易造成磁頭與資料區相撞擊，導致碟片資料區損壞或刮傷磁碟，丟失硬碟內所儲存的文件數據。
❷ 電腦硬碟出現IO設備錯誤無法運行此項請求怎麼解決
1、首先先對硬碟作檢測，去嘗試將移動另一台電腦查看是否會出現這個情況，而過能正常讀取的話，那說明設備是好的。如果不能讀取的話說明是設備的問題了。那麼建議去專業維修部門去維修吧。記得把重要數據拷貝好。
2、移動設備正常，那麼說可能是i/o地址沖突的原因造成硬碟無法讀取的原因。
解決方法：開機通過安全模式進入系統，XP系統的話開機按住F8不動即可進入安全模式了。然後打開「開始-控制面板-系統」，找到系統圖標後點擊打開它，在窗口上選擇「通用串列匯流排控制器」下查看標有黃色的「!」的設備;選中該設備，右鍵單擊窗口下的「屬性」，從「資源」列表查看Windows給出的提示，單擊「輸入/輸出范圍」對其進行更改，直到提示Windows顯示「無沖突設備」時再確定退出即可。但是不要去修改i/o地址，一般系統也將自動設置了固定的i/o地址的
3、有可能是硬碟存在壞道了、未格式化、文件目錄損壞等原因造成的。
解決方法：將數據恢復備份好。設備有數據的話，一定不要重分區，格式化之類的操作。那樣的話恢復的數據不完整。保持現狀。正確的分析處理很大程度上是可以完整的恢復出原來的數據的。而不需要數據恢復軟體掃描恢復。單純使用數據恢復軟體掃描恢復的話，耗時，效果也很難說。可能恢復不完整數據。
❸ 硬碟io性能
一，硬碟IO的延時
對於sql Server資料庫系統，限制查詢響應的主要因素是硬碟的延時，根據硬碟的物理構造（磁軌和扇區），延時可以分為尋道延時和旋轉延時：
尋道延時：硬碟的物理刺頭移動並定位到所需數據的時間，
旋轉延時：硬碟旋轉到所需數據的時間，通常用MB/S，或IO吞吐量來衡量
在OLTP系統中，數據更新操作較多，每次讀取的數據量少，目標數據的位置相對隨機（隨機讀寫），因此，對於尋道延時要求更高，硬碟需要花費更多的尋道時間。
在DSS/DW系統中，事務的運行時間更長，數據相對靜態，不常更新，讀操作比寫操作的要求更高，順序讀操作佔比很高，因此，IO吞吐量更重要，可以通過硬碟的盤面來增加順序訪問的IO吞吐量。
二，根據WaitType偵測IO性能
SQL Server引擎把IO作為一個資源來看待，在多任務的現代資料庫系統中，同一時刻會接收到很多查詢請求，每一個查詢請求都需要申請系統資源（CPU、內存和IO），才能繼續執行下去，然而系統的資源是有限的，當查詢爭用資源時，有些查詢請求資源得到滿足，順利執行下去，有些查詢請求的資源得不到滿足，該查詢就被阻塞，處於等待資源分配的狀態。當出現IO性能問題時，查詢語句會被硬碟IO阻塞，這使得執行計劃被迫掛起（或阻塞）來等待資源，SQL Server通過DMV來顯示系統運行的狀態，用等待類型來表示不同的阻塞信息。
1，數據文件的IO
如果SQL Server 出現 IO 性能問題，那麼在SQL Server 內部通過DMV sys.dm_exec_requests的wait_type，來反饋 IO 問題。如果查詢請求的wait_type長時間處於PageIOLatch_XX，那麼說明系統不能很快把數據讀取到內存中。
PAGEIOLATCH_xx ：用於描述數據頁的IO爭用，說明系統正在從硬碟載入數據到內存的Buffer Pool中
當SQL Server 要去讀或寫一個Page的時候，首先會在Buffer Pool里尋找，如果在Buffer Pool中找到了，那麼讀寫操作會繼續進行，沒有任何等待。如果沒有找到，那麼SQL Server 就會設置Wait_Type為PageIOLatch_EX（寫）或PageIOLatch_SH（讀），然後發起一個非同步IO操作，將頁面讀入Buffer Pool中，在IO沒有完成之前，Request將會保持在PageIOLatch_EX（寫）或PageIOLatch_SH（讀）的等待狀態。IO消耗的時間越長，等待的時間越長。
2，日誌文件的寫入
日誌文件以寫為主，工作量由修改命令激發的事務數量決定。當SQL Server要寫事務到日誌文件時，如果Disk 不能及時完成IO請求，那麼事務就無法提交，SQL Server 不得不進入WriteLog 等待狀態，直到事務被成功記錄到日誌文件中，才會提交當前的事務。
如果request經常出現WriteLog的Wait type，說明事務日誌的寫請求不能被Disk及時完成，這種情況，對SQL Server 整體性能影響較大。
WRITELOG：在數據被修改時，在Log Cache和Buffer Cache中都會有記錄，如果在Log Cache中的數據在checkpoint時寫入硬碟，就會發生這種等待。
LOGBUFFER等待：很少出現，當一個任務正在等待存儲日誌到Log Buffer中時，就會出現LOGBUFFER等待，出現這種等待，說明日誌所在的硬碟無法響應請求。如果把日誌文件放在一個非常慢的硬碟上，而數據文件放在一個非常快的硬碟上，就會出現這種等待。
3，AYSNC_IO_COMPLIETION和IO_COMPLIETION也是IO瓶頸的潛在指標
AYSNC_IO_COMPLIETION：標識任務正在等待IO請求來完成操作，當一個應用程序連接SQL Server，在處理數據時變得非常慢，很可能就會出現這種類型的等待。
IO_COMPLIETION：發生在一個任務正在等待用於非數據頁IO的IO操作上，非數據頁，一般是指日誌文件，通常發生在修改大量修改，或者內存中存在大量的臟數據時。
三，影響讀寫性能的因素
資料庫系統對IO的性能依賴較高，那麼影響資料庫系統讀寫性能的因素有哪些呢？
1，物理硬碟的IO能力
機械硬碟的IO速度沒有固態硬碟快，可以考慮把資料庫系統的機械硬碟更新為固態硬碟。
2，內存對硬碟IO的影響
在SQL Server Engine 訪問數據時，如果相應的data不存在於Buffer Pool，那麼Buffer Manager 從Disk中的Data File（mdf 或 ndf）中將相應的data page讀取到內存中。SQL Server 將data page緩存起來。理想情況下，只要SQL Server能夠使用的內存充足，SQL Server 會將所有讀取到內存的中Data Page緩存到Buffer Pool中。對於讀取操作，只要相應的數據都緩存在內存中，Select 就不會有任何硬碟IO。
當Buffer Pool空間不足時，SQL Server 激活 LazyWriter，主動將內存中一些很久沒有使用的Data Cache和 Plan Cache 清除，mark為Free buffer，供其它Data Page使用。如果這些Page上的修改還沒有被CheckPoint寫回Disk，那麼LazyWrite會將其寫回。
3，碎片和壓縮
如果數據頁面或index 頁面的碎片很多，每個頁面存儲的數據行較少，那麼SQL Server 需要讀寫更多的Page。如果數據在頁面里存儲的非常緊湊，存儲相同數據所消耗的Page越少，並且可以充分利用SQL Server 預讀的優勢，減少IO。
壓縮技術不僅使數據佔用的Disk 空間減少，而且能夠減少IO。由於數據在寫入Disk之間經過壓縮處理，存儲相同數據所消耗的Page減少，讀取的Data Page會減少。壓縮技術在一定程度上能夠降低IO，但需要付出一定的代價：額外消耗少量的CPU和內存來解壓縮。
4，利用多個物理硬碟實現Data File的並發讀寫
在DB中的FileGroup 創建多個File，將這些File存放到不同的Physical Disk上。File 分布到不同的Physical Disk上，IO也會分布到不同的Physical Disk上，這樣能夠實現數據的並發讀取，提高讀取性能。
對於日誌文件，SQL Server會頻繁的寫事務日誌。只要資料庫發生修改，就會不斷地寫入日誌文件。如果不能及時完成日誌文件的IO，會導致事務的延遲提交，對性能的影響較大，所以，盡量將日誌文件放到寫入速度快的Disk上。SQL Server 順序寫事務日誌，在一個時間點，SQL Server 只會寫一個日誌文件。在不同的Physical Disk上創建多個log file對性能基本沒有幫助。
5，工作負載
日誌文件以寫為主，工作量由修改命令申請的事務數量決定，日誌文件是順序寫的，寫入速度快於隨機寫。如果日誌記錄不能及時寫入，那麼Request會處於WriteLog等待狀態，對系統整體性能影響較大。
數據文件寫入的數據量由修改量決定，SQL Server除了設置bulk logged 恢復模式之外，沒有太大的調整選項。
數據文件讀取的數據量，由訪問的數據量和Buffer Pool中緩存的數據量共同決定。如果訪問的數據量減少或者內存緩存區增加，都可以降低SQL Server 從Physical Disk讀取的Data Page數量。在內存不變的情況下，可以通過優化查詢語句，減少數據訪問量，來提高SQL Server 數據文件的讀取性能。
❹ 移動硬碟io錯誤，系統超級緩慢，超級懸賞！！！
有幾個可能。
1.你的硬碟介面有問題了。如排線有松動，移動U的板有松動。
2.硬碟自身的壞道
了。要是這個問題要盡快處理了。說不好那天。0道壞了硬碟就找不到了。
3.你的硬碟內有大量的瑣碎文件碎片。在啟動時硬碟在做自動修復。自然要佔用大量CPU.這種的解決方法最好是你把硬碟分開直接連接系統不用套。來把數據導出格式化。
如是套的問題。你可以再找一個套試試就知道了。
希望是套的問題吧。
硬碟的問題也不能排除。只是你先把數據救 出來再想別的了。
❺ 如何提升磁碟io
1. 文件越多讀取越慢：如果可以的話，將多個小文件合並成一個文件。
2. 讀寫次數越多讀取越慢：一次多讀一些數據到內存。
3. 將讀寫操作分配到不同的硬碟上。
4. 磁碟RAID0比RAID5讀寫速度快很多。
❻ 9217-4i4e 磁碟io不足
解答如下:
磁碟io性能不足 千次閱讀 2018-05-22 15:38:49
密集讀寫磁碟io成為短板，程序運行過慢。
主硬碟是掛載新硬碟性能4倍。
主硬碟比較小，掛載硬碟大。
在主硬碟上進行讀寫操作，基礎數據定時移動到掛載硬碟上。
主要用到的命令
磁碟io性能觀測：iostat -d -k 1 10
❼ 硬碟IO錯誤有辦法解決嗎
系統提示硬碟I/O錯誤時，可能硬碟的識別及操作存在故障，可以按下述步驟進行排查解決：
1、確認該硬碟是否顯示在磁碟管理器中，若有顯示，繼續下述步驟；若無顯示，證明系統未識別到硬碟，可能的原因是SATA數據線，硬碟電源線，硬碟損壞導致的，需進一步排查。
2、若磁碟管理器中有顯示硬碟，先確認其狀態，是否未分區或格式化，若沒有，先嘗試給移動硬碟分區及格式化。
3、若硬碟有分區格式化，但無分配相應的盤符，此時可以右擊此分區，選擇「變更盤符及路徑」選項，重新選擇分配一個盤符給硬碟的分區即可。
❽ 如何解決磁碟io造成的系統卡頓問題
具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？
相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？
dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？
當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？
如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦？
回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。
由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。