㈠ 伺服器出現宕機的原因有哪些
①
運行環境：一般來說，此原因是排名第一的伺服器宕機類別，運行環境可以看作是支持資料庫伺服器運行的系統和資源集合，包括操作系統、硬體以及網路等，在運行環境的問題中，最普遍的問題是磁碟空間耗盡。
② 伺服器性能：最常見的伺服器宕機原因是運行sql，但還有其他的可能，比如也有些問題是由於伺服器Bug或錯誤的行為導致的。
③ 復制問題：復制問題通常由於主備數據不一致導致。
④數據丟失、損壞：數據丟失問題通常由於錯誤操作導致，並總是伴隨著缺少可用備份的問題，數據丟失一般情況下是由於drop
table的錯誤操作導致，並總是伴隨著缺少可用備份的問題。
| 要及時地發現伺服器宕機的問題!!!
有一句話說得很好，時間就是金錢，要最快時間發現宕機的問題，例如是否是應用程序導致內存溢出或泄露，是否是進程過多或不斷創建、耗盡資源等，是否應用程序異常導致，是否是遭受黑客入侵攻擊導致，是否是誤操作導致等等，伺服器宕機時，為了避免造成不必要的損失，要盡早通知服務商解決相關問題。
| 多准備空間
最好准備2個網站空間，它們存放的內容相同，但IP不同，且機房的地理位置不同，這樣宕機的可能性就大大降低了，第一時間發現宕機問題後，可以迅速地通過修改域名記錄，指向目前正常的網站空間。
㈡ 伺服器突然宕機是什麼原因
伺服器突然宕機原因：
1、由操作員意向操作的重啟——用於維護或更新伺服器、部署機房或特殊情況等等。
2、非操作員本身意願造成的重啟——如供電(欠壓，過載，波動)、震動、硬體質量(熱穩定性(熱敏度)和抗干擾能力)、資源沖突、DirectX文件的損壞、系統不完善或瓶頸問題、病毒、灰塵、散熱不良……等等原因而造成重啟。
3、由於用戶訪問量過大，造成資源耗盡，或者你網站的數據超出你的空間限制范圍大小也會出現宕機。
㈢ SQL2000 經常宕機報錯
耐心看下面這幾篇KBA，都是涉及這個錯誤的。
造成這個錯誤的原因好像有點復雜，但多半和你的磁碟系統有關。
http://support.microsoft.com/kb/810885
http://support.microsoft.com/kb/815056
http://support.microsoft.com/kb/909380
http://msdn2.microsoft.com/en-us/library/aa175396(sql.80).aspx
㈣ 伺服器宕機是什麼意思怎處理解決
伺服器宕機是指伺服器因為某些原因而導致伺服器無法運轉，造成網路無法正常使用。 對於網站來說，伺服器宕機所造成影響很大，它不但造成訪客無妨對網站進行訪問，甚至還可能影響到網站在搜索引擎上的收錄和排名， 因而在租用伺服器時，建議站長選擇想美國伺服器這種出現宕機概率比較低的伺服器。在伺服器使用的過程中，伺服器宕機可能都出現， 首先我們要找到伺服器可能出現宕機的原因嗎，才能找到對應的解決辦法。下面壹基比小喻來給大家介紹下。
要即時發現伺服器宕機的問題。時間就是金錢，這是不變的真理。我們要第一時間， 發現宕機的問題。如果他伺服器宕機時，為了避免造成不必要的損失，要盡早通知服務商解決相關問題。
最好准備2個網站空間，他們存放的內容相同，而ip不同，並且機房的地理位置不同。這樣2個主機， 同時宕機的可能性就大大降低了。第一時間發現宕機問題後，可以迅速的通過修改dnspod.com中的域名記錄，指向目前正常的網站空間。Dnspod解析生效的時間是實時的， 而一般的dns伺服器，刷新時間較長，對外聲稱24小時內生效，按照實際經驗看來，差不多30分鍾內生效，否則就要檢查域名綁定是否正確了。
㈤ 伺服器宕機原因及其解決方案
對於廣大站長來說，伺服器宕機對網站的收錄跟排名都是有非常大的影響的，最重要的是宕機會影響網站業務的進行，所以無論不管說是用戶還是服務商都不希望伺服器出現宕機問題，那假如出現了，我們該如何解決它呢？
伺服器宕機是每個服務商都會遇到的問題，一般有以下幾種原因：
1.伺服器性能
伺服器的性能問題有很多，但最多見的應該就是SQL，但我們也不能一概而論，還有別的可能性，例如有些問題就是伺服器Bug或錯誤行為導致的。另外，較差的Schema和索引設計也是較多的出錯原因之一。
2.運行環境
如果是這個問題，那麼最常見的就是磁碟空間消耗完了。
3.數據丟了或損壞
數據丟失也有很多原因，可能不是用戶錯誤操作，也可能是人為攻擊造成的，但一般來說是由drop table錯誤操作導致，通常出現這個問題都會伴隨著缺少可用備份的問題。
4.復制
復制問題一般是由主備數據不一致導致的。
我們了解了這幾項宕機原因，那麼如何判斷或查看伺服器宕機原因呢？
（1）查看是否是誤操作導致的
（2）查看是否是應用程序導致的
（3）查看是否是應用程序導致內存溢出或者泄露，out of memory導致
（4）查看是否是流量負載過大導致的
（5）查看是否是遭受黑客入侵攻擊導致的
那我們查明是如原因後，我們又該如何去解決問題呢？
1.發現伺服器宕機後，及時聯系服務商解決相關問題，就算短暫的宕機也可能會造成較大的損失，請大家及時聯系自己的服務商。
2.做好提前防範的准備。可以同時運行兩個網站空間，備份內容，當一個出現問題，立刻啟動另一個。
3.使用一款功能好的宕機監控第一時間智能處理，故障發生時可設置自動切換至備用IP，恢復後將切換回原IP，能夠有效提高網站可用性和頁面性能。有效規避風險降低成本。
㈥ 伺服器宕機是什麼意思怎處理解決
宕機伺服器排查故障方法
1、在運行環境的問題中，最普遍的問題時磁碟空間耗盡。
2、在性能問題中，最普通的伺服器宕機原因確實是運行很糟糕的SQL，但也不一定都是這個原因，比如也有很多問題時由於伺服器Bug或錯誤的行為導致的。
3、糟糕的Schema和索引設計是第二大影響性能的問題。
4、復制問題通常由於主備數據不一致導致。
5、數據丟失問題通常由於操作的錯誤操作導致，並總是便隨著缺少可用備份的問題。
6.由於系統原因，導致的伺服器宕機，一般重啟下伺服器就可以。
明白了伺服器宕機的原因，我們就可以採取相應的措施來排查。宕機伺服器如何排查故障
㈦ SQL Server 2008 R2 持續佔用內存直到伺服器死機，怎麼解決
和sql server 的機制有關，sql server能訪問伺服器多少內存就會佔用多少，並不會自動釋放，可以限制資料庫伺服器的內存使用量，具體方法：右鍵點擊資料庫實例，點開屬性對話框，在內存標簽內設置 」最大伺服器內存大小「 為你想限制的大小，重啟資料庫服務就可以了。不過還是建議你先檢查下資料庫性能，做下優化！
㈧ 100ms的SQL把伺服器搞崩潰了
一個項目上線了兩個月，除了一些反饋的優化和小Bug之外，項目一切順利；前期是屬於推廣階段，可能使用人員沒那麼多，當然對於項目部署肯定提前想到並發量了，所以早就把集群安排上，而且還在測試環境搞了一下壓測，絕對是沒得問題的；但是，就在兩個月後的一天，系統突然跑的比烏龜還慢，投訴開始就陸續反饋過來了。
經過排查，原來是頻繁執行一條耗時100ms的SQL導致，100ms感覺不長，但就是把系統搞崩了，具體細節如下。
項目採用ABP進行開發，集成統一的認證中心(IDS4)，部分數據對接第三方系統，拆分後的這個項目架構相對簡單。
考慮並發量不高，就算是高峰期也不會超過1000，於是就搞了個單台的資料庫伺服器(MySQL)，測試環境中經過壓測，完全能抗住。
上線時，由於線上資源的關系，DB伺服器的配置沒有按測試環境的標准來分配，相關人員想著後續看情況進行補配。上線推的比較緊，簡單評估了配置風險，初步判斷沒啥大問題，於是就推上線了。
相關技術棧：ABP、IdentityServer4、Autofac、AutoMapper、Quartz.NET、EF Core、Redis、MySQL等，這都不重要，重要的是100ms的SQL把系統搞崩了。
由於系統相對不大，並沒有把分布式日誌、調度監控，性能監控集成上去。
上線期間，前期處於使用推廣階段，一切正常。兩個月後的一天，系統處於使用高峰時段，突然陸續收到反饋：系統有點卡！！！於是趕緊進行排查。
由於系統已經是集群部署的，慢這個問題首先懷疑是資料庫伺服器，於是讓DBA的同事排查了一下，沒有鎖，只是有大量事務等待提交(waiting for handler commit)，通過如下命令可查的：
看到都是插入審計日誌記錄導致，一看日誌記錄頻率，差不多一秒500條記錄。DBA同事說可能是記錄插入頻繁導致，此時CPU已經爆到100%了，為了快速解決問題，於是就趕緊關掉了一些不必要的日誌記錄。
這么一改，稍微降了一點，沒有事務提交的記錄，系統勉強可以撐著用，但是CPU還是在85%~97%波動；
看到這種情況，當然還是不放心，繼續排查。 中間有對伺服器的配置產生過懷疑，但非常肯定的是這不是主要原因，於是和DBA的同事繼續排查。
系統雖然可以正常使用，但時不時的也看看監控屏，CPU一直處於高水位狀態，還是有點慌的，因為一有問題，信息和電話都要爆。
突然DBA同事發現有一個單表查詢的SQL執行比較頻繁，於是單獨拿出來試了一下，查詢時間150ms左右，這個表的數據量不大，8萬左右，但沒有加任何索引，因為想著數據量不大，查詢時長還可接受，所以當時就沒有加相關索引。
定位到這條SQL後，想到的第一步就是增加索引，在測試環境上試了一把，執行效率直接飛速提高到1ms；效果如下：
所以和DBA同事達成一致意見，在生成環境上增加復合索引( 創建索引一定要注意欄位順序 )，在中午時候，系統使用頻率不太高，於是就在生成上快速加了索引，我去，CPU一下降到了20%以內，意不意外；就算在使用高峰期，也沒超過20%，通過zabbix工具監控看到CPU的效果：
問題算是解決了，總算鬆了一口氣。
這里有個問題： CPU都爆了為什麼沒有報警提醒，這塊DBA同事正在排查相關配置。這里發現CPU爆了，還是無意的遠程到伺服器，發現很卡，一看CPU才知道爆了。
系統雖小，問題不大，但其實暴露的問題還是挺多。
這次線上小事故暫時分享到這，因為項目不大，所以沒有做那麼多監控，但以下建議，小夥伴可以參考一下：
文章來自https://www.cnblogs.com/zoe-zyq/p/16207287.html
㈨ ORACLE伺服器可能由於SQL語句導致宕機嗎
會
宕機
SQL語句
太復雜可能會過多的消耗CPU資源，也可能由於語句中的
子查詢
多，並且數據量又非常大，查詢邏輯不合理，導致內存消耗過大
這些都可以引起
資料庫伺服器
宕機
資料庫2個表，各20W資料庫左右，每秒
聯合查詢
3-10次
伺服器：
小型機
，4G內存，12個CPU
由於查詢語句復雜不合理，系統運行3天就宕機
結果伺服器上的6個數據服務都優化SQL語句，現在小型機運行正常