資料庫崩潰了
重裝SQL
Server
然後附加原來的資料庫，或者使用備份還原資料庫。
把MDF
文件放在C:\Program
Files\Microsoft
SQL
Server\MSSQL\data
文件夾下
然後在打開SQL資料庫，右擊資料庫所有任務\附加資料庫把MDF文件加上就行了。
⑵ MySQL資料庫崩潰怎麼辦
MySQL 隨著版本不停迭代，崩潰的現象越來越少，也越來越隱蔽。
一旦遇到生產環境上的 MySQL 崩潰，就需要保留現場信息，供分析用。雖然 MySQL 的 error log 中會列印部分信息，但對於比較隱蔽的崩潰，往往顯得力不從心。
通過開啟操作系統級別、放開用戶限制、啟用 MySQL 參數三個步驟，我們啟用了 MySQL 的 coremp 功能，使得 MySQL 崩潰時留下了足夠的線索。
對於復雜崩潰的分析，還是需要將 coremp 交給專業的研發工程師手裡，或者提交給 MySQL 開發團隊。
不過不管是什麼場景，能提供一份 coremp，所有技術人員都會感謝你的。
⑶ 資料庫崩潰是怎麼回事
郁悶
哪個網站開幾個月就關閉啊
沒有的
資料庫崩潰應該不可能,如果你說5000注冊就崩潰的話,我認為不可能
不過我認為還是sql資料庫好!個人意見!
⑷ 程序在執行SQL語句時，若出現系統異常中斷或資料庫突發崩潰，如何保證
備份可用數據後，卸載重裝恢復資料庫。
程序在執行SQL語句時，若出現系統異常中斷或資料庫突發崩潰，先備份可用的數據，包含所有系統資料庫和用戶資料庫的數據文件和日誌文件。
卸載原來的安裝。
系統表查找和刪除所有的MSSQLServer項。
磁碟上刪除安裝SQLSErver產生的所有文件。
重新安裝SQLServer，所需安裝的補丁的版本要求保持與備份系統資料庫時安裝的補丁版本一致。
單用戶模式下恢復master資料庫。
恢復其他系統資料庫。
恢復用戶資料庫。
⑸ 如何恢復MAX資料庫崩潰
主要軟體版本: 4.4
主要軟體修正版本: 4.4
次要軟體: N/A
解答:MAX資料庫崩潰非常罕見，但是當突然斷電或者死機而導致系統非正常關機、重啟時可能會導致這一問題。資料庫崩潰可能出現的一個現象就是當點擊MAX中任一文件夾旁邊的擴展按鈕「＋」時，文件夾不但不展開，「＋」還消失了。如果這一現象是在安裝了新版本的MAX之後才產生的，您需要確認一下安裝之後是否重啟了PC。
MAX會備份資料庫文件，這可以被用於恢復資料庫崩潰。具體步驟如下：以管理員身份或者有管理員許可權的用戶賬號登錄（如果安裝了F-Secure之類的固件，請確保其在下面的過程中保持關閉！）：退出所有的NI應用程序。
打開命令窗： 從Windows的「開始」菜單，選擇Run...。 輸入"cmd"，點擊OK。 輸入"net stop mxssvr"，回車，停止MAX資料庫服務。如果有提示讓你停止其他的服務，也按照要求停止。 輸入"exit" ，回車，關閉命令窗。
找到最後一個文件夾：
Windows XP和Windows 2000:
找到C:\Documents and Settings\All Users\Application Data\National Instruments\MAX\Data Dictionaries\Last文件夾Application Data是一個隱藏文件夾。通過選擇Tools �0�3Folder Options...,，點擊View，然後選擇Show hidden files and folders，可以顯示出隱藏文件夾。Windows Vista: 找到C:\ProgramData\National Instruments\MAX\Data Dictionaries\Last文件夾 如果找不到該文件夾，就到C盤下，然後在菜單欄中選擇Organize �0�3Folder and Search Options，點擊View。 選擇Show hidden files and folders選項。 勾除Hide protected Operating System files選項。
備份Last文件夾，將其保存到另外的地方。
找到Data文件夾:
Windows XP和Windows 2000:
找到C:\Documents and Settings\All Users\Application Data\National Instruments\MAX\Data\文件夾Application Data是一個隱藏文件夾。通過選擇Tools �0�3Folder Options...,，點擊View，然後選擇Show hidden files and folders，可以顯示出隱藏文件夾. Windows Vista: 找到C:\ProgramData\National Instruments\MAX\Data文件夾如果找不到該文件夾，就到C盤下，然後在菜單欄中選擇Organize �0�3Folder and Search Options，點擊View. 選擇Show hidden files and folders選項.勾除Hide protected Operating System files選項.
備份Data文件夾，將其保存到另外的地方。
打開原始的Data文件夾，找到config3.mxs.bak。右鍵點擊該文件，選擇「屬性」，檢查該文件的創建和修改時間。General頁面上可以找到創建時間和最後一次修改時間。
如果時間中有這樣的信息，繼續如下步驟；如果文件太老，而且文件創建時間不確定，又或者config3.mxs.bak文件大小和config3.mxs文件大小一致，只需要刪除整個Data文件夾，然後跳到第10步。
注意: 刪除Data文件夾會刪除所有的配置信息，MAX下次重啟時，您必須再次配置所有的硬體。
刪除MAX\Data文件夾中的config3.mxs，或者將其保存成其他的名字，如果Data文件夾中還有config3.mxc, config3.mxd, config3.mx5,和storage.mxc，做同樣的處理。將config3.mxs.bak重命名為config3.mxs。重啟計算機。
打開MAX。
⑹ 資料庫崩潰應如何將其恢復使資料庫損失最小
主要軟體版本: 4.4
主要軟體修正版本: 4.4
次要軟體: N/A
解答:MAX資料庫崩潰非常罕見，但是當突然斷電或者死機而導致系統非正常關機、重啟時可能會導致這一問題。資料庫崩潰可能出現的一個現象就是當點擊MAX中任一文件夾旁邊的擴展按鈕「＋」時，文件夾不但不展開，「＋」還消失了。如果這一現象是在安裝了新版本的MAX之後才產生的，您需要確認一下安裝之後是否重啟了PC。
MAX會備份資料庫文件，這可以被用於恢復資料庫崩潰。具體步驟如下：以管理員身份或者有管理員許可權的用戶賬號登錄（如果安裝了F-Secure之類的固件，請確保其在下面的過程中保持關閉！）：退出所有的NI應用程序。
⑺ 當SQL Server資料庫崩潰時如何恢復
SQL Server資料庫恢復必須之前有備份，包括資料庫備份和日誌備份（實際處理操作），
當SQL Server資料庫一旦出現崩潰或故障時就可以及時方便地進行恢復，菜單操作（選擇「資料庫」單擊右鍵選下拉菜單中的「恢復」即可）或命令語句操作都可以
⑻ mysql資料庫崩潰的原因
MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數據字典的准確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關，表總數越大，崩潰恢復時間越長。另外磁碟 IOPS 也會影響崩潰恢復時間，像這里開發庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發現，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那麼 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後，感覺共享表空間在很多業務環境下，反而更有優勢。
臨時冒出另外一種解決想法，即用 GDB 調試崩潰恢復，通過臨時修改 validate 變數值讓 MySQL 跳過表空間驗證過程，然後讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發現，如果以 debug 模式運行，確實可以臨時修改 validate 變數，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變數，想法破滅。