九個(gè)步驟來解決SQL服務(wù)器的問題

 我們都是時(shí)有發(fā)生的問題，我們需要努力通過一些解決問題的步驟來確定為什么發(fā)生問題。在這些情況下，你需要像一個(gè)犯罪現(xiàn)場調(diào)查員造成的發(fā)現(xiàn)根。不，我們不把黃警示膠帶在我們的服務(wù)器，我們的網(wǎng)絡(luò)電纜，和我們的臺式機(jī)。 然而，有時(shí)我們會拔掉網(wǎng)線來防止機(jī)器被進(jìn)一步污染。管這個(gè)問題，你需要做一些法醫(yī)分析，確定問題的原因。

信息收集階段

為了診斷首先需要收集一些有關(guān)問題的信息問題。你還需要檢查日志文件以確定什么樣的系統(tǒng)錯(cuò)誤信息和日志記錄的存在，可能會對你有幫助的問題診斷。下面是一組時(shí)應(yīng)該考慮通過你的分析信息收集階段的步驟。

步驟1：收集事實(shí)

任何解決問題的練習(xí)的第一步是收集事實(shí)。你需要知道什么樣的問題發(fā)生。這就是你需要訪談客戶，或程序員了解如何以及何時(shí)發(fā)生的問題。你需要確定它是否是全系統(tǒng)的，還是更多的是局限于一個(gè)特定的應(yīng)用程序或組件 ，申請。你還需要知道 時(shí)間在問題發(fā)生時(shí)，它是否仍然是一個(gè)問題。除此之外，你需要知道的最后一次系統(tǒng)正確工作。你需要確定是否有任何新的系統(tǒng)或應(yīng)用變化引入可能引起的問題。有一些事實(shí)問題你可以開始尋找線索，可能有助于找出問題的根本原因。

步驟2：在不同的環(huán)境和機(jī)器測試

值得在不同環(huán)境下的測試，如果你有他們。這是一個(gè)事實(shí)的收集工作，但我把它拼寫出來作為一個(gè)單獨(dú)的步驟，因?yàn)楹芏啻蔚慕?jīng)驗(yàn)豐富的員工 不想執(zhí)行測試在不同的環(huán)境當(dāng)他們收集事實(shí)。你會發(fā)現(xiàn)只有一個(gè)環(huán)境受到影響，一系列的環(huán)境或 所有環(huán)境。如果只有一個(gè)環(huán)境影響的問題，可能是一個(gè)與環(huán)境 配置問題，或其他的工作環(huán)境。

此外，你可能想嘗試不同的客戶機(jī)，服務(wù)器或應(yīng)用程序。偶爾，你會發(fā)現(xiàn)一個(gè)不同的配置或設(shè)置造成應(yīng)用工作，或不工作。你需要了解所有的 不同的設(shè)置和配置選項(xiàng)然后文件的那些工作。

步驟3：檢查SQL Server錯(cuò)誤日志

SQL Server創(chuàng)建一個(gè)日志文件稱為“日志”。一個(gè)新的日志文件創(chuàng)建 每次SQL Server啟動(dòng)。默認(rèn)情況下，SQL Server六 保持舊的錯(cuò)誤日志文件，每一個(gè)有序列號相關(guān)。的 錯(cuò)誤日志文件默認(rèn)存儲在“日志”文件夾內(nèi)的 標(biāo)準(zhǔn)”…Files\Microsoft SQL服務(wù)器…”文件夾 結(jié)構(gòu)。

發(fā)現(xiàn)與時(shí)間的問題時(shí)，首次發(fā)生日志文件�？词欠裼性谙�息被由SQL Server輸出任何異常。有時(shí)如果SQL Server檢測到變化，或者遇到問題，它將被記錄在錯(cuò)誤日志文件。

步驟4：查看事件日志

你應(yīng)該使用事件查看器查看不同的事件日志記錄。事件日志中包含的信息警告和錯(cuò)誤。你應(yīng)該 看所有事件發(fā)生不久之前，期間和確定問題的 時(shí)間后。你需要確保你復(fù)習(xí)的“應(yīng)用”和“系統(tǒng)”事件，以及“安全”事件。

步驟5：檢查默認(rèn)痕跡

默認(rèn)跟蹤，如前所述，是一種微量啟動(dòng)SQLServer 時(shí)自動(dòng)啟動(dòng)，如果默認(rèn)跟蹤選項(xiàng)啟用。在現(xiàn)代飛機(jī) 類似飛行記錄器。這種跟蹤捕獲所有配置更改實(shí)例。通過回顧默認(rèn)跟蹤信息你可以確定什么樣的數(shù)據(jù)庫的變化可能是由期間被查出有問題。

默認(rèn)跟蹤文件存儲在同一個(gè)日志文件夾中的日志。他們被命名為“l(fā)og_xxx。真相與和解委員會”，其中xxx是一個(gè)序列號。 可以打開這些文件分析器看到記錄的事件�；蛘撸�您可以使用“fn_trace_gettable”功能過程的 文件使用T-SQL：

SELECT *

從fn_trace_gettable

（c：Files\Microsoft SQL servermssql。1mssqlloglog_155 TRC，默認(rèn)；

步驟6：檢討改變 日志

審查你的組織的變更日志。我希望你的組織有一個(gè)。一個(gè) 更改日志的集中位置，確定所有的變化都 介紹。如果您的組織有一個(gè)，這有助于識別 最近發(fā)生的任何變化。這個(gè)日志可能會為你提供一些線索來 為什么一個(gè)特定的問題發(fā)生，特別是如果應(yīng)用程序， 有問題是近日已修改。如果你的 組織沒有更改日志，然后在步驟1中你可能會問一個(gè) 程序員當(dāng)最后的應(yīng)用改變了。

分析階段

現(xiàn)在你已經(jīng)收集了一些信息，你需要分析的數(shù)據(jù)你聚集。審查每一步收集信息。尋找異常，將支持由客戶或程序員發(fā)現(xiàn)問題。

把以上1個(gè)步驟確定的情況來確定每個(gè) 日志和跟蹤文件可以幫助你找出問題出現(xiàn)的 �？稍诿恳徊娇纯词欠裼腥魏尉�索會讓你更好地了解是什么原因造成的信息審查。

在你做了這樣的分析，你可能是幸運(yùn)的，找出問題的原因 。然而，會有一些時(shí)候，以上步驟不屈服 解決問題。在這種情況下，你需要繼續(xù)前進(jìn)，做一些 額外的測試和信息收集。

額外的測試和信息收集

如果你不能通過審查不同的系統(tǒng)日志中發(fā)現(xiàn)的問題，或者默認(rèn)跟蹤需要分析導(dǎo)致問題的實(shí)際過程。這意味著你可能要看代碼甚至運(yùn)行不同的測試。這里確定的步驟只有起點(diǎn)的休息。他們應(yīng)該幫助你組織你的想法如何 你可能去進(jìn)行更多的測試和收集更多的信息 幫助你解決手頭的問題。

步驟7：制定測試計(jì)劃

坐下來與客戶和應(yīng)用程序和文件都會通過=步驟，這是造成問題。許多這樣的 信息可能已經(jīng)在步驟1中收集的，但它至少是值得去 一遍。如果問題重復(fù)鑒定。如果不能 重復(fù)則可能難以確定是什么引起的問題。這里的 點(diǎn)是確定應(yīng)用程序是如何連接到SQL Server和 T-SQL代碼被執(zhí)行�；�于被調(diào)查你將需要開發(fā)一套測試運(yùn)行，你可能想捕捉來確定什么什么信息的問題。做任何測試之前，我建議你去下一步。

步驟8：備份數(shù)據(jù)庫

在繼續(xù)做額外的測試，并 故障分析，這可能是明智的問題做數(shù)據(jù)庫備份。 備份可全，微分或日志備份取決于你當(dāng)前的 數(shù)據(jù)庫備份策略，你的過去和現(xiàn)狀。這 備份將提供你一個(gè)恢復(fù)點(diǎn)應(yīng)該要開始調(diào)整SQL Server為您診斷故障排除步驟6中確定的步驟 部分。

步驟9：執(zhí)行額外的測試和測井

把你的測試邏輯塊盡可能小。這些步驟 連接到SQL Server的測試，你可能會考慮將SQL Server 儀使您可以監(jiān)視什么樣的T-SQL語句和批處理被 執(zhí)行。分析器將允許您捕獲正在運(yùn)行的代碼，這 有時(shí)是不同于程序員的期望，有時(shí)儀和 額外的步驟都需要縮小是什么原因造成目前的問題 。

CSI的方法來解決問題

其中最有價(jià)值的東西作為一個(gè)DBA是幫助程序員和 客戶解決問題。更難的問題是解決大 獎(jiǎng)勵(lì)。以上，我已經(jīng)確定要排除 問題逐步逼近。該方法確定了一些日志，看一些工具來使用，以 幫助您識別并解決問題。你會發(fā)現(xiàn)這些步驟做 不一定滿足你的需求，這是好的。重要的一點(diǎn)是 明白你需要制定和遵循一個(gè)故障排除過程中 你的環(huán)境。有一個(gè)問題集的步驟和工具，可以讓你 開發(fā)一種方法，你可以用在解決問題 迅速積極主動(dòng)，有條不紊地。