⑴ sqlserver 2012日誌滿了導致資料庫掛起恢復，如何解決
1、分離資料庫
2、將日誌改名，使資料庫找不到日誌文件。
3、附加，不帶日誌文件。附加的窗口中取消日誌文件的選定。
這樣，就會生成一個新的日誌文件。
⑵ SQLServer資料庫收縮相關知識
SQL Server 資料庫採取預先分配空間的方法來建立資料庫的數據文件或者日誌文件，比如數據文件的空間分配了300MB，而實際上只佔用了20MB空間，這樣就會造成磁碟存儲空間的浪費。可以通過資料庫收縮技術對資料庫中的每個文件進行收縮，刪除已經分配但沒有使用的頁。從而節省伺服器的存儲的成本。
官方解釋：收縮數據文件通過將數據頁從文件末尾移動到更靠近文件開頭的未佔用的空間來恢復空間。在文件末尾創建足夠的可用空間後，可以取消對文件末尾的數據頁的分配並將它們返回給文件系統。
收縮後的資料庫不能小於資料庫最初創建時指定的大小。 或是上一次使用文件大小更改操作（如 DBCC SHRINKFILE）設置的顯式大小。
比如：如果資料庫最初創建時的大小為 10 MB，後來增長到 100 MB，則該資料庫最小隻能收縮到 10 MB，即使已經刪除資料庫的所有數據也是如此。
不能在備份資料庫時收縮資料庫。 反之，也不能在資料庫執行收縮操作時備份資料庫。
介紹：收縮指定資料庫中的數據文件大小。
語法格式：
參數說明：
介紹：收縮當前資料庫的指定數據或日誌文件的大小，或通過將數據從指定的文件移動到相同文件組中的其他文件來清空文件，以允許從資料庫中刪除該文件。文件大小可以收縮到比創建該文件時所指定的大小更小。這樣會將最小文件大小重置為新值。
語法格式：
參數說明：
例如，如果創建一個10MB 的文件，然後在文件仍然為空的時候將文件收縮為2 MB，默認文件大小將設置為2 MB。這只適用於永遠不會包含數據的空文件。
另附SqlServer常見問題解答
1）管理器不會主動刷新，需要手工刷新一下才能看到最新狀態（性能方面的考慮）
2）很少情況下，恢復進程被掛起了。這個時候假設你要恢復並且回到可訪問狀態，要執行：
RESTORE database dbname with recovery
這使得恢復過程能完全結束。
3）如果你要不斷恢復後面的日誌文件，的確需要使資料庫處於「正在還原狀態」，
這通常是執行下面命令：
RESTORE database dbname with norecovery
原來SQL Server對伺服器內存的使用策略是用多少內存就佔用多少內存，只用在伺服器內存不足時，才會釋放一點佔用的內存，所以SQL Server 伺服器內存往往會佔用很高。我們可以通過DBCC MemoryStatus來查看內存狀態。
SQL SERVER運行時會執行兩種緩存:
1. 數據緩存：執行個查詢語句，SQL SERVER會將相關的數據頁（SQL SERVER操作的數據都是以頁為單位的）載入到內存中來， 下一次如果再次請求此頁的數據的時候，就無需讀取磁碟了，大大提高了速度。
2.執行命令緩存：在執行存儲過程，自定函數時，SQL SERVER需要先二進制編譯再運行，編譯後的結果也會緩存起來， 再次調用時就無需再次編譯。
可以調用以下幾個DBCC管理命令來清理這些緩存：
但是，這幾個命令雖然會清除掉現有緩存，為新的緩存騰地方，但是Sql server並不會因此釋放掉已經佔用的內存。SQL SERVER並沒有提供任何命令允許我們釋放不用到的內存。因此我們只能通過動態調整SQL SERVER可用的物理內存設置來強迫它釋放內存。
解決SQLSERVER內存佔用過高的方法：
1、清除所有緩存DBCC DROPLEANBUFFERS
2、調整SQLSERVER可使用的最大伺服器內存。
在SQL管理器，右擊實例名稱
在屬性實例屬性裡面找到內存選項
把最大內存改成合適的內存，確定後內存就會被強制釋放，然後重啟實例。再看看任務管理器，內存使用率就降下來啦。
1、查看連接對象
USE master
GO
--如果要指定資料庫就把注釋去掉
SELECT * FROM sys.[sysprocesses] WHERE [spid]>50 --AND DB_NAME([dbid])='gposdb'
當前連接對象有67個其中『WINAME』的主機名，『jTDS』的進程名不屬於已知常用軟體，找到這台主機並解決連接問題。在360流量防火牆中查看有哪個軟體連接了伺服器IP，除之。
2、然後使用下面語句看一下各項指標是否正常，是否有阻塞，正常情況下搜索結果應該為空。
SELECT TOP 10
[session_id],
[request_id],
[start_time] AS '開始時間',
[status] AS '狀態',
[command] AS '命令',
dest.[text] AS 'sql語句',
DB_NAME([database_id]) AS '資料庫名',
[blocking_session_id] AS '正在阻塞其他會話的會話ID',
[wait_type] AS '等待資源類型',
[wait_time] AS '等待時間',
[wait_resource] AS '等待的資源',
[reads] AS '物理讀次數',
[writes] AS '寫次數',
[logical_reads] AS '邏輯讀次數',
[row_count] AS '返回結果行數'
FROM sys.[dm_exec_requests] AS der
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50 AND DB_NAME(der.[database_id])='gposdb'
ORDER BY [cpu_time] DESC
查看是哪些SQL語句佔用較大可以使用下面代碼
--在SSMS里選擇以文本格式顯示結果
SELECT TOP 10
dest.[text] AS 'sql語句'
FROM sys.[dm_exec_requests] AS der
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50
ORDER BY [cpu_time] DESC
3、如果SQLSERVER存在要等待的資源，那麼執行下面語句就會顯示出會話中有多少個worker在等待
SELECT TOP 10
[session_id],
[request_id],
[start_time] AS '開始時間',
[status] AS '狀態',
[command] AS '命令',
dest.[text] AS 'sql語句',
DB_NAME([database_id]) AS '資料庫名',
[blocking_session_id] AS '正在阻塞其他會話的會話ID',
der.[wait_type] AS '等待資源類型',
[wait_time] AS '等待時間',
[wait_resource] AS '等待的資源',
[dows].[waiting_tasks_count] AS '當前正在進行等待的任務數',
[reads] AS '物理讀次數',
[writes] AS '寫次數',
[logical_reads] AS '邏輯讀次數',
[row_count] AS '返回結果行數'
FROM sys.[dm_exec_requests] AS der
INNER JOIN [sys].[dm_os_wait_stats] AS dows
ON der.[wait_type]=[dows].[wait_type]
CROSS APPLY
sys.[dm_exec_sql_text](der.[sql_handle]) AS dest
WHERE [session_id]>50
ORDER BY [cpu_time] DESC;
4、查詢CPU佔用最高的SQL語句
SELECT TOP 10
total_worker_time/execution_count AS avg_cpu_cost, plan_handle,
execution_count,
(SELECT SUBSTRING(text, statement_start_offset/2 + 1,
(CASE WHEN statement_end_offset = -1
THEN LEN(CONVERT(nvarchar(max), text)) * 2
ELSE statement_end_offset
END - statement_start_offset)/2)
FROM sys.dm_exec_sql_text(sql_handle)) AS query_text
FROM sys.dm_exec_query_stats
ORDER BY [avg_cpu_cost] DESC;
5、索引缺失查詢
SELECT
DatabaseName = DB_NAME(database_id)
,[Number Indexes Missing] = count(*)
FROM sys.dm_db_missing_index_details
GROUP BY DB_NAME(database_id)
ORDER BY 2 DESC;
SELECT TOP 10
[Total Cost] = ROUND(avg_total_user_cost * avg_user_impact * (user_seeks + user_scans),0)
, avg_user_impact
, TableName = statement
, [EqualityUsage] = equality_columns
, [InequalityUsage] = inequality_columns
, [Include Cloumns] = included_columns
FROM sys.dm_db_missing_index_groups g
INNER JOIN sys.dm_db_missing_index_group_stats s
ON s.group_handle = g.index_group_handle
INNER JOIN sys.dm_db_missing_index_details d
ON d.index_handle = g.index_handle
ORDER BY [Total Cost] DESC;
找到索引缺失的表，根據查詢結果中的關鍵次逐一建立索引。
⑶ sqlserver 2012日誌滿了導致資料庫掛起恢復，怎麼解決
1、分離資料庫
2、將日誌改名，使資料庫找不到日誌文件。
3、附加，不帶日誌文件。附加的窗口中取消日誌文件的選定。 這樣，就會生成一個新的日誌文件。
⑷ SQL資料庫出現恢復掛起狀態怎麼辦
SQL資料庫出現恢復掛起狀態怎麼辦
將SQL Server的啟動帳號改為資料庫文件中具有完全控制許可權的本地管理員用戶帳號，然後停止SQL服務並重新啟動，就OK。
⑸ 伺服器崩潰了進不去了怎麼辦
伺服器數據恢復工程師對客戶的伺服器進行了初步檢查，檢查結果與客戶描述及故障推測一致，伺服器數據丟失的原因確實與異常斷電有關，由於突然斷電導致了啟動信息丟失，另外客戶伺服器上的資料庫也受到了破壞。想要恢復數據除了修復linux操作系統外還需要整理資料庫碎片，修復資料庫。
【伺服器數據恢復過程】
伺服器數據恢復工程師將客戶伺服器內的所有數據都按扇區備份到專用伺服器上，將客戶原始伺服器狀態復原，開始在專用伺服器上進行數據分析和恢復。
linux系統修復後嘗試啟動伺服器，伺服器成功啟動，但資料庫無法啟動，印證了之前工程師推測的資料庫數據遭受破壞的推斷。
數據恢復工程師繼續分析資料庫碎片數據，修改資料庫錯誤數據，嘗試修復並掛起資料庫，最終成功恢復伺服器內的資料庫數據。交由客戶對所有數據進行驗證。
【伺服器數據恢復結論】
經過客戶對恢復數據進行驗證，確認伺服器及伺服器上的資料庫數據恢復完整、准確，本次數據恢復圓滿成功。
【伺服器數據恢復後記】
1、伺服器故障後應避免隨意拔插硬碟，避免硬碟盤序混亂。
2、避免對需要恢復數據的伺服器進行寫入和修改操作。
3、求助專業伺服器數據恢復公司的專業伺服器數據恢復工程師，切忌在未備份的情況對伺服器進行操作。
⑹ 下載模擬器軟體一直顯示數據連接錯誤請聯系管理員
1、登錄賬號、密碼、伺服器名稱、資料庫名稱登錄錯誤導致不能連接。解決方法：當正在使用的軟體出現資料庫不能連接時，一般就是伺服器名出現問題，更改伺服器名稱一般可以解決問題。2、沒能正確安裝SQL伺服器，也會導致資料庫連接不上。解決方法：如果是SQL資料庫未能能成功安裝，再次重新安裝時，可能會無法安裝，提示是存在一個未完成的安裝掛起。3、因許可權問題導致資料庫不能連接。解決方法：可以先暫時關閉防火牆或者殺毒軟體，看是否是這些軟體的安全設置所導致。(6)資料庫回復掛起擴展閱讀資料庫連接的技術特點如下：1、採用復雜的數據模型表示數據結構，數據冗餘小，易擴充，實現了數據共享。2、具有較高的數據和程序獨立性，資料庫的獨立性有物理獨立性和邏輯獨立性。3、資料庫系統為用戶提供了方便的用戶介面。4、資料庫系統提供4個方面的數據控制功能，分別是並發控制、恢復、完整性和安全性。資料庫中各個應用程序所使用的數據由資料庫系統統一規定，按照一定的數據模型組織和建立，由系統統一管理和集中控制。5、增加了系統的靈活性。
⑺ 緊急求救，怎樣才能恢復資料庫
資料庫被掛起了。你可以試一試用下面的方法恢復：
A.現象：Error 926
Severity Level 14
Error Message Text
Database 'xx' cannot be opened - it has been marked SUSPECT by recover Explanation
(1) 當你使用Transact_SQL命令操作這個資料庫的數據時, 出現這個信息, 這是一個嚴重的錯誤, 如果你要使用這個資料庫的數據, 必須改正這個錯誤.
(2) 啟動Backup Server, 後備master資料庫
1>mp database master to "/usr/sybase/master_mp.19991201"
2>go
(3) 用isql登錄到SQL Server, 須用sa帳號 (本文以pubs2資料庫為例)
1>sp_configure "allow updates", 1
2>go
1>begin tran
2>go
1>update master..sysdatabases
2>set status = -32768
3>Where name="pubs2"
4>go
如果得到(1 row affected),則
1>commit
2>go
否則
1>rollback
2>go
(4.1)如果條件允許，bcp out用戶數據或mp用戶資料庫
(5.1)這時重新啟動SQL Server, 再有sa帳號注冊到SQL Server.
1>begin tran
2>go
1>update master..sysdatabases
2>set status=0
3>Where name="pubs2"
4>go
如果得到(1 row affected),則
1>commit
2>go
否則
1>rollback
2>go
1>sp_configure "allow updates" ,0
2>go
(4) 如果你的資料庫原來有dboption(例如"select into","trunc log on chkpt"等), 你需要重新設置這些option..
(5) 運行dbcc命令檢查資料庫的一致性
isql -Usa -P -i dbcc.sql -o dbcc.out
dbcc.sql文件示例：
dbcc checkdb("pubs2")
go
dbcc checkalloc("pubs2")
go
dbcc checkcatalog("pubs2")
go
grep Msg dbcc.out
6) 後備用戶資料庫
1>mp database pubs2 on "/usr/sybase/pubs2_mp.19991201"
2>go
B.如何解決資料庫被標記為"suspect"的問題之二（ 資料庫設備損壞時的解決方案 ）？
A.現象： 926錯誤產生的原因有幾種。本文討論當資料庫設備初始化失敗( 設備文件丟失或文件讀寫許可權不正確)時，導致資料庫恢復失敗，出現926錯誤的情況。
(1) 請先恢復資料庫設備及讀寫許可權。
(2) 啟動Backup Server, 後備master資料庫
1>mp database master to "/usr/sybase/master_mp.19991201"
2>go
3) 用isql登錄到SQL Server, 須用sa帳號 (本文以pubs2資料庫為例)
1>sp_configure "allow updates", 1
2>go
1>begin tran
2>go
1>update master..sysdatabases
2>set status = status - 256
3>Where name="pubs2"
4>go
如果得到(1 row affected),則
1>commit
2>go
否則
1>rollback
2>go
(4) 重新啟動SQL Server, 運行dbcc命令檢查資料庫的一致性編輯生成dbcc.sql文件：
dbcc checkdb("pubs2")
go
dbcc checkalloc("pubs2")
go
dbcc checkcatalog("pubs2")
go
isql -Usa -P -i dbcc.sql -o dbcc.out
grep Msg dbcc.out
(5) 後備用戶資料庫
1>mp database pubs2 on "/usr/sybase/pubs2_mp.19991201"
2>go
⑻ 為什麼還原sqlserver資料庫的狀態一直都是正在還原
1、可能是被用作鏡像，被用作鏡像有一個伺服器是長期顯示正在還原。
2、很少情回況下，恢復答進程被掛起了。這個時候假設你要恢復並且回到可訪問狀態，要執行：
RESTORE database dbname with recovery
⑼ sqlserver資料庫恢復掛起怎麼辦
如果你的資料庫還處於掛起狀態，把我下面代碼的test改為你的專庫名，然後執行：屬
USE master
GO
ALTER DATABASE test SET SINGLE_USER
GO
ALTER DATABASE test SET EMERGENCY
GO
DBCC CHECKDB(test,REPAIR_ALLOW_DATA_LOSS)
go
ALTER DATABASE test SET ONLINE
GO
ALTER DATABASE test SET MULTI_USER
GO
⑽ 網站宕機 伺服器宕機 資料庫宕機 宕機怎麼辦
最近遇到個比較有意思的問題，伺服器宕掉後無法啟動，想了好多辦法，雖然解決了問題，數據沒有丟失，但是沒有按照自已的思路來，未免還是有些不甘。遇到問題不能慌，尤其是線上的環境，更不能緊張，心理素質對DBA來說也是一項挑戰，可能你的手一抖就會導致多少人無法正常使用業務，如果你沒有把握，請先把現場環境備份後再進行操作，避免數據的二次損壞，下面壹基比小喻說一下大概的思路吧。
1.檢查是否有備份，如果備份存在，binlog存在，那麼萬事大吉，一切都有挽回的餘地，慢慢來搞，只要你基礎扎實，數據還原只是時間的問題。
2.對於沒有備份的，那處理這個問題就有些棘手了，還得一步一步的來。
在my.cnf中[mysqld]下加上以下配置，採用強制恢復機制，看是否能夠啟動
[mysqld]
innodb_force_recovery=1
如果設置成1不能啟動，可以逐漸的將數據增大到6，下文會詳細說下1-6是什麼意思，如果在1-6之間啟動成功了，那麼你運氣還不錯，這時候不要恢復業務，趕緊把數據用邏輯方式導出來，再啟個新的實例把數據還原，有人會問，為什麼mysql已經啟動了，還要導出數據呢，原因在這：
當innodb_force_recovery被設置為大於0的時候 ，會阻止用戶insert,update,delete也就是你啟動的mysql不是一個正常的mysql服務，類似於windows系統下的安全模式。以下這段引於其它地方，具體地址不太清楚了，也可以從官方文檔中找到。
innodb_force_recovery被允許的非零值如下。一個更大的數字包含所有更小數字的預防措施。如果你能夠用一個多數是4的選項值來轉儲你的表，那麼你是比較安全的，只有一些在損壞的單獨頁面上的數據會丟失。一個為6的值更誇張，因為資料庫頁被留在一個陳舊的狀態，這個狀態反過來可以引發對B樹和其它資料庫結構的更多破壞。
innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)
即使伺服器檢測到一個損壞的頁，也讓伺服器運行著；試著讓SELECT * FROM tbl_name 跳過損壞的索引記錄和頁，這樣有助於轉儲表。
innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)
阻止主線程運行，如果崩潰可能在凈化操作過程中發生，這將阻止它。
innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)
恢復後不運行事務回滾。
innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入緩沖合並操作。如果你可能會導致一個崩潰。最好不要做這些操作，不要計算表統計表。
innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
啟動資料庫之時不查看未完成日誌：InnoDB把未完成的事務視為已提交的。
innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)
不要在恢復連接中做日誌前滾。
資料庫不能另外地帶著這些選項中被允許的選項來使用。作為一個安全措施，當innodb_force_recovery被設置為大於0的值時，InnoDB阻止用戶執行INSERT, UPDATE或DELETE操作.
即使強制恢復被使用，你也可以DROP或CREATE表。如果你知道一個給定的表正在導致回滾崩潰，你可以移除它。你也可以用這個來停止由失敗的大宗導入或失敗的ALTER TABLE導致的失控回滾。你可以殺掉mysqld進程，然後設置innodb_force_recovery為3，使得資料庫被掛起而不需要回滾，然後舍棄導致失控回滾的表。
關於上面進行邏輯備份也可能會遇到問題，可能會備份失敗，如果出錯，建議先按庫一個一個的備份，到哪個庫出錯後，再按照當前庫的表一個一個備份，表出錯根據表中主鍵一點一點備份，最終將大部分數據導出。如果你的數據不重要，可以容忍丟失，那麼可以當我說的都是廢話了。
3.如果還是不可以啟動，那麼恭喜你，你遇到挑戰了。
查看錯誤日誌，看沒有提示因為某個表的原因而導致啟動不了，可以先把損壞的表的ibd文件先從數據目錄mv走，再試著啟動，在數據已經恢復後，我把當時錯誤的文件拿到本地，做了測試，把幾個報錯的ibd文件mv走後，資料庫就可以正常啟動了，但是mv走的這幾個表數據會丟失。怎麼把這個表的數據弄回來呢，曾想過用在線表空間傳輸，但是.cfg文件卻沒有，這種方法沒有行通。後來用Percona Data Recovery Tool for InnoDB工具進行數據恢復，關於這個工具的介紹與操作，網上一大堆，我就不詳細說明了。