求助sqlserver服務(wù)器壓力問(wèn)題

剛才參考了這個(gè)

創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、安次網(wǎng)絡(luò)推廣、小程序設(shè)計(jì)、安次網(wǎng)絡(luò)營(yíng)銷、安次企業(yè)策劃、安次品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營(yíng)等，從售前售中售后，我們都將竭誠(chéng)為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)建站為所有大學(xué)生創(chuàng)業(yè)者提供安次建站搭建服務(wù)，24小時(shí)服務(wù)熱線：13518219792，官方網(wǎng)址：m.rwnh.cn

看了你幾個(gè)出現(xiàn)次數(shù)比較多的等待，下面可以參考，另外，癥狀和解決方案-LATCH_XX

這意味著

存在非頁(yè)閂鎖

使用sys.dm_os_latch_stats來(lái)分析哪一個(gè)閂鎖等待時(shí)間過(guò)長(zhǎng)

和其它同時(shí)發(fā)生的等待類型結(jié)合查看

比如說(shuō)CXPACKET和LATCH_EX與ACCESS_METHODs_SCAN_RANGE_GENERATOR往

往意味著存在大量掃描

癥狀和解決方案-LCK_M_XX

解決方案基于最開(kāi)始被阻塞進(jìn)程的等待類型

一個(gè)查范圍更新或掃描造成的鎖升級(jí)

癥狀和解決方案-

SOS_SCHEDULER_YIELD

這意味著

線程用完4毫秒的時(shí)間片，主動(dòng)放棄CPU

存在自旋鎖

不一定是CPU問(wèn)題（CPU問(wèn)題往往體現(xiàn)在長(zhǎng)Runnable隊(duì)列或大量signal

wait）

通過(guò)執(zhí)行計(jì)劃查看是否存在大量掃描

查看等待類型

避免望文生義

更多分析

注意：該方式?jīng)]有Resource_wait等待類型，因此一些查另外關(guān)于sqltrace的，參考這個(gè)

另外你的服務(wù)器硬件配置還有數(shù)據(jù)庫(kù)大小是什么樣的？

建議你查詢一下執(zhí)行次數(shù)最多的sql和最耗費(fèi)IO的sql，看看執(zhí)行計(jì)劃是不是缺少索引之類的

如何判斷MSSQL數(shù)據(jù)庫(kù)磁盤(pán)出現(xiàn)了瓶頸

具體問(wèn)題具體分析，舉例來(lái)說(shuō)明為什么磁盤(pán)IO成瓶頸數(shù)據(jù)庫(kù)的性能急速下降了。

為什么當(dāng)磁盤(pán)IO成瓶頸之后, 數(shù)據(jù)庫(kù)的性能不是達(dá)到飽和的平衡狀態(tài)，而是急劇下降。為什么數(shù)據(jù)庫(kù)的性能有非常明顯的分界點(diǎn)，原因是什么？

相信大部分做數(shù)據(jù)庫(kù)運(yùn)維的朋友，都遇到這種情況。 數(shù)據(jù)庫(kù)在前一天性能表現(xiàn)的相當(dāng)穩(wěn)定，數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間也很正常，但就在今天，在業(yè)務(wù)人員反饋業(yè)務(wù)流量沒(méi)有任何上升的情況下，數(shù)據(jù)庫(kù)的變得不穩(wěn)定了，有時(shí)候一個(gè)最簡(jiǎn)單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什么了？

dba此時(shí)心中有無(wú)限的疑惑，到底是什么原因呢? 磁盤(pán)IO性能變差了？還是業(yè)務(wù)運(yùn)維人員反饋的流量壓根就不對(duì)？ 還是數(shù)據(jù)庫(kù)內(nèi)部出問(wèn)題？昨天不是還好好的嗎？

當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)響應(yīng)時(shí)間不穩(wěn)定的時(shí)候，我們?cè)诓僮飨到y(tǒng)上會(huì)看到磁盤(pán)的利用率會(huì)比較高，如果觀察仔細(xì)一點(diǎn)，還可以看到，存在一些讀的IO. 數(shù)據(jù)庫(kù)服務(wù)器如果存在大量的寫(xiě)IO,性能一般都是正常跟穩(wěn)定的，但只要存在少量的讀IO,則性能開(kāi)始出現(xiàn)抖動(dòng)，存在大量的讀IO時(shí)（排除配備非常高速磁盤(pán)的機(jī)器），對(duì)于在線交易的數(shù)據(jù)庫(kù)系統(tǒng)來(lái)說(shuō)，大概性能就雪崩了。為什么操作系統(tǒng)上看到的磁盤(pán)讀IO跟寫(xiě)IO所帶來(lái)的性能差距這么大呢？

如果親之前沒(méi)有注意到上述的現(xiàn)象，親對(duì)上述的結(jié)論也是懷疑。但請(qǐng)看下面的分解。

在寫(xiě)這個(gè)文章之前，作者閱讀了大量跟的IO相關(guān)的代碼，如異步IO線程的相關(guān)的，innodb_buffer池相關(guān)的，以及跟讀數(shù)據(jù)塊最相關(guān)的核心函數(shù)buf_page_get_gen函數(shù)以及其調(diào)用的相關(guān)子函數(shù)。為了將文章寫(xiě)得通俗點(diǎn)，看起來(lái)不那么累，因此不再一行一行的將代碼解析寫(xiě)出來(lái)。

咱們先來(lái)提問(wèn)題。?buf_page_get_gen函數(shù)的作用是從Buffer bool里面讀數(shù)據(jù)頁(yè)，可能存在以下幾種情況。

提問(wèn). 數(shù)據(jù)頁(yè)不在buffer bool 里面該怎么辦？

回答：去讀文件，將文件中的數(shù)據(jù)頁(yè)加載到buffer pool里面。下面是函數(shù)buffer_read_page的函數(shù)，作用是將物理數(shù)據(jù)頁(yè)加載到buffer pool, 圖片中顯示

buffer_read_page函數(shù)棧的頂層是pread64(),調(diào)用了操作系統(tǒng)的讀函數(shù)。

buf_read_page的代碼

如果去讀文件，則需要等待物理讀IO的完成，如果此時(shí)IO沒(méi)有及時(shí)響應(yīng)，則存在堵塞。這是一個(gè)同步讀的操作，如果不完成該線程無(wú)法繼續(xù)后續(xù)的步驟。因?yàn)樾枰臄?shù)據(jù)頁(yè)不再buffer 中，無(wú)法直接使用該數(shù)據(jù)頁(yè)，必須等待操作系統(tǒng)完成IO .

再接著上面的回答提問(wèn)：

當(dāng)?shù)诙?huì)話線程執(zhí)行sql的時(shí)候，也需要去訪問(wèn)相同的數(shù)據(jù)頁(yè)，它是等待上面的線程將這個(gè)數(shù)據(jù)頁(yè)讀入到緩存中，還是自己再發(fā)起一個(gè)讀磁盤(pán)的然后加載到buffer的請(qǐng)求呢？?? 代碼告訴我們，是前者，等待第一個(gè)請(qǐng)求該數(shù)據(jù)頁(yè)的線程讀入buffer pool。

試想一下，如果第一個(gè)請(qǐng)求該數(shù)據(jù)頁(yè)的線程因?yàn)榇疟P(pán)IO瓶頸，遲遲沒(méi)有將物理數(shù)據(jù)頁(yè)讀入buffer pool, 這個(gè)時(shí)間區(qū)間拖得越長(zhǎng)，則造成等待該數(shù)據(jù)塊的用戶線程就越多。對(duì)高并發(fā)的系統(tǒng)來(lái)說(shuō)，將造成大量的等待。 等待數(shù)據(jù)頁(yè)讀入的函數(shù)是buf_wait_for_read，下面是該函數(shù)相關(guān)的棧。

通過(guò)解析buf_wait_for_read函數(shù)的下層函數(shù)，我們知道其實(shí)通過(guò)首先自旋加鎖pin的方式，超過(guò)設(shè)定的自旋次數(shù)之后，進(jìn)入等待，等待IO完成被喚醒。這樣節(jié)省不停自旋pin時(shí)消耗的cpu,但需要付出被喚起時(shí)的開(kāi)銷。

再繼續(xù)擴(kuò)展問(wèn)題： 如果會(huì)話線程A 經(jīng)過(guò)物理IO將數(shù)據(jù)頁(yè)1001讀入buffer之后，他需要修改這個(gè)頁(yè)，而在會(huì)話線程A之后的其他的同樣需要訪問(wèn)數(shù)據(jù)頁(yè)1001的會(huì)話線程，即使在數(shù)據(jù)頁(yè)1001被入讀buffer pool之后，將仍然處于等待中。因?yàn)樵跀?shù)據(jù)頁(yè)上讀取或者更新的時(shí)候，同樣需要上鎖，這樣才能保證數(shù)據(jù)頁(yè)并發(fā)讀取/更新的一致性。

由此可見(jiàn)，當(dāng)一個(gè)高并發(fā)的系統(tǒng)，出現(xiàn)了熱點(diǎn)數(shù)據(jù)頁(yè)需要從磁盤(pán)上加載到buffer pool中時(shí)，造成的延遲，是難以想象的。因此排在等待熱點(diǎn)頁(yè)隊(duì)列最后的會(huì)話線程最后才得到需要的頁(yè)，響應(yīng)時(shí)間也就越長(zhǎng)，這就是造成了一個(gè)簡(jiǎn)單的sql需要執(zhí)行幾十秒的原因。

再回頭來(lái)看上面的問(wèn)題，mysql數(shù)據(jù)庫(kù)出現(xiàn)性能下降時(shí)，可以看到操作系統(tǒng)有讀IO。 原因是，在數(shù)據(jù)庫(kù)對(duì)數(shù)據(jù)頁(yè)的更改，是在內(nèi)存中的，然后通過(guò)檢查點(diǎn)線程進(jìn)行異步寫(xiě)盤(pán)，這個(gè)異步的寫(xiě)操作是不堵塞執(zhí)行sql的會(huì)話線程的。所以，即使看到操作系統(tǒng)上有大量的寫(xiě)IO，數(shù)據(jù)庫(kù)的性能也是很平穩(wěn)的。但當(dāng)用戶線程需要查找的數(shù)據(jù)頁(yè)不在buffer pool中時(shí)，則會(huì)從磁盤(pán)上讀取，在一個(gè)熱點(diǎn)數(shù)據(jù)頁(yè)不是非常多的情況下，我們?cè)O(shè)置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數(shù)據(jù)頁(yè)，因此一般都不會(huì)出現(xiàn)缺頁(yè)的情況，也就是在操作系統(tǒng)上基本看不到讀的IO。 ?當(dāng)出現(xiàn)讀的IO時(shí)，原因時(shí)在執(zhí)行buf_read_page_low函數(shù)，從磁盤(pán)上讀取數(shù)據(jù)頁(yè)到buffer pool, 則數(shù)據(jù)庫(kù)的性能則開(kāi)始下降，當(dāng)出現(xiàn)大量的讀IO，數(shù)據(jù)庫(kù)的性能會(huì)非常差。

如何識(shí)別sql server中的io瓶頸

當(dāng)數(shù)據(jù)頁(yè)經(jīng)常從緩沖池中移進(jìn)移出的時(shí)候，I/O子系統(tǒng)就會(huì)成為SQLServer性能問(wèn)題的關(guān)鍵因素之一。事務(wù)日志和tempdb同樣也會(huì)產(chǎn)生重大

的I/O壓力。因此，你必須確保你的I/O子系統(tǒng)能按照預(yù)期運(yùn)行。否則你將會(huì)成為響應(yīng)時(shí)間增長(zhǎng)和頻繁超時(shí)的受害者。在這篇文章中，將描述如何使用內(nèi)置工具

識(shí)別I/O相關(guān)瓶頸，并提供一些磁盤(pán)配置的方法：

性能計(jì)數(shù)器（Performance Monitor）：

可以使用性能計(jì)數(shù)器來(lái)檢查I/O子系統(tǒng)的負(fù)荷。下面的計(jì)數(shù)器可用于檢查磁盤(pán)性能：

PhysicalDisk Object:Avg.DiskQueue Length：計(jì)算從物理磁盤(pán)中的平均

讀和寫(xiě)的請(qǐng)求隊(duì)列。過(guò)高的值代表磁盤(pán)操作處于等待狀態(tài)。當(dāng)這個(gè)值在SQLServer峰值時(shí)長(zhǎng)期超過(guò)2，證明需要注意了。如果有多個(gè)硬盤(pán)，就需要把這些數(shù)

值除以2。比如，有4個(gè)硬盤(pán)，且隊(duì)列為10，那么平均值就是10/4=2.5，雖然也證明需要關(guān)注，但不能使用10這個(gè)值。

Avg.Disk Sec/Read和Avg.Disk Sec/Write：顯示從磁盤(pán)讀或者寫(xiě)入磁盤(pán)的平均時(shí)間。10ms內(nèi)是很好的表現(xiàn)，20以下還算能接受。高于此值證明存在問(wèn)題。

Physical Disk:%Disk Time：在磁盤(pán)忙于讀或者寫(xiě)請(qǐng)求的時(shí)候持續(xù)時(shí)間的比率。根據(jù)拇指定律，此值應(yīng)該小于50%。

Disk Reads/Sec和Disk Writes/Sec計(jì)數(shù)器顯示出在磁盤(pán)中讀寫(xiě)操作的速率。這兩個(gè)值應(yīng)該小于磁盤(pán)能力的85%。當(dāng)超過(guò)此值，磁盤(pán)的訪問(wèn)時(shí)間將以指數(shù)方式增長(zhǎng)。

可以通過(guò)以下方式來(lái)計(jì)算逐漸增長(zhǎng)的負(fù)載的能力。一種方法是使用SQLIO。你應(yīng)該找到吞吐量比較穩(wěn)定，但緩慢增長(zhǎng)。

可以使用以下公式來(lái)計(jì)算RAID配置：

Raid 0: I/O per disk = (reads + writes) / number ofdisks

Raid 1: I/O per disk = [reads + (writes*2)] / 2

Raid 5: I/O per disk = [reads + (writes*4)] / number of disks

Raid 10: I/O per disk = [reads + (writes*2)] / number of disks

比如：對(duì)于RAID 1，如果得到下面的計(jì)數(shù)器：

Disk Reads/sec = 90

Disk Writes/sec =75

根據(jù)公式：[reads + (writes*2)] / 2 or [90 + (75*2)] / 2 = 120I/Os每個(gè)磁盤(pán)。

動(dòng)態(tài)管理視圖（DMVs）：

有很多游泳的DMVs可以用于檢查I/O瓶頸：

當(dāng)一個(gè)頁(yè)面被用于讀或者寫(xiě)訪問(wèn)且頁(yè)面在緩沖池中不存在或不可用時(shí)，會(huì)引發(fā)一個(gè)I/O閂鎖等待（I/O

latch），它會(huì)在PAGEIOLATCH_EX/PAGEIOLATCH_SH（具體根據(jù)請(qǐng)求類型而定）。這些等待表明一個(gè)I/O瓶頸?？梢允褂?/p>

sys.dm_os_wait_stats找到閂鎖等待的信息。如果你保存了SQLServer正常運(yùn)行下的waiting_task_counts和

wait_time_ms值，并且于此次的值做對(duì)比，可以識(shí)別出I/O問(wèn)題：

select *

from sys.dm_os_wait_stats

where wait_type like 'PAGEIOLATCH%'

order by wait_type asc

掛起的I/O請(qǐng)求可以在下面查詢中查到，并且用于識(shí)別那個(gè)磁盤(pán)負(fù)責(zé)的這個(gè)瓶頸：

select database_id,

file_id,

io_stall,

io_pending_ms_ticks,

scheduler_address

from sys.dm_io_virtual_file_stats(NULL, NULL) iovfs,

sys.dm_io_pending_io_requests as iopior

where iovfs.file_handle = iopior.io_handle

磁盤(pán)碎片（Disk Fragmentation）：

建議你檢查磁盤(pán)碎片和配置用于SQLServer實(shí)例的磁盤(pán)。在NTFS文件系統(tǒng)中的碎片會(huì)產(chǎn)生嚴(yán)重的性能影響。磁盤(pán)需要經(jīng)常整理碎片并且指定整理碎片計(jì)劃。研究表明，一些情況下SAN在整理碎片后性能更差。因此，SAN必須根據(jù)實(shí)際情況對(duì)待。

NTFS上的索引碎片同樣能引起高I/O好用。但是這和在SANs中的效果是不一樣的。

磁盤(pán)配置/最佳實(shí)踐：

常規(guī)情況，你應(yīng)該把日志文件和數(shù)據(jù)文件分開(kāi)存放以獲得更好的性能。對(duì)于重負(fù)載的數(shù)據(jù)文件（包括tempdb）的I/O特性是隨機(jī)讀取。對(duì)于日志文件，是順序訪問(wèn)的，除非事務(wù)需要回滾。

對(duì)于內(nèi)置磁盤(pán)僅僅可以用于數(shù)據(jù)庫(kù)日志文件，因?yàn)樗鼈儗?duì)順序I/O有很好的性能，但是對(duì)隨機(jī)I/O性能低下。

數(shù)據(jù)庫(kù)的數(shù)據(jù)和日志文件應(yīng)該放在對(duì)應(yīng)專用的磁盤(pán)中。確保良好的性能。建議日志文件放在兩個(gè)內(nèi)置磁盤(pán)，并配置為RAID 1。數(shù)據(jù)文件駐留在僅用于給SQLServer訪問(wèn)的SAN系統(tǒng)中，并只被查詢和報(bào)表控制。特殊訪問(wèn)應(yīng)該被禁止。

寫(xiě)緩沖在可能的情況下應(yīng)該被允許，并保證斷電也能使用。

為了盡可能保證對(duì)于OLTP系統(tǒng)的I/O瓶頸影響最小化，不應(yīng)該把OLAP和OLTP環(huán)境混合。并且保證你的代碼優(yōu)化及有合適的索引來(lái)避免不必要的I/O。

如何識(shí)別SQL Server中的IO瓶頸

我們可能經(jīng)常會(huì)遇到SQLServer數(shù)據(jù)庫(kù)頻繁關(guān)閉的情況。在分析了內(nèi)存和CPU使用情況后，我們需要繼續(xù)調(diào)查根源是否在I/O。我們應(yīng)該如何識(shí)別SQLServer是否有I/O相關(guān)的瓶頸？

解決：

當(dāng)數(shù)據(jù)頁(yè)經(jīng)常從緩沖池中移進(jìn)移出的時(shí)候，I/O子系統(tǒng)就會(huì)成為SQLServer性能問(wèn)題的關(guān)鍵因素之一。事務(wù)日志和tempdb同樣也會(huì)產(chǎn)生重大的I/O壓力。因此，你必須確保你的I/O子系統(tǒng)能按照預(yù)期運(yùn)行。否則你將會(huì)成為響應(yīng)時(shí)間增長(zhǎng)和頻繁超時(shí)的受害者。在這篇文章中，將描述如何使用內(nèi)置工具識(shí)別I/O相關(guān)瓶頸，并提供一些磁盤(pán)配置的方法：

性能計(jì)數(shù)器（Performance Monitor）：

可以使用性能計(jì)數(shù)器來(lái)檢查I/O子系統(tǒng)的負(fù)荷。下面的計(jì)數(shù)器可用于檢查磁盤(pán)性能：

PhysicalDisk Object:Avg.DiskQueue

Length：計(jì)算從物理磁盤(pán)中的平均讀和寫(xiě)的請(qǐng)求隊(duì)列。過(guò)高的值代表磁盤(pán)操作處于等待狀態(tài)。當(dāng)這個(gè)值在SQLServer峰值時(shí)長(zhǎng)期超過(guò)2，證明需要注意了。如果有多個(gè)硬盤(pán)，就需要把這些數(shù)值除以2。比如，有4個(gè)硬盤(pán)，且隊(duì)列為10，那么平均值就是10/4=2.5，雖然也證明需要關(guān)注，但不能使用10這個(gè)值。

Avg.Disk Sec/Read和Avg.Disk

Sec/Write：顯示從磁盤(pán)讀或者寫(xiě)入磁盤(pán)的平均時(shí)間。10ms內(nèi)是很好的表現(xiàn)，20以下還算能接受。高于此值證明存在問(wèn)題。

Physical Disk:%Disk

Time：在磁盤(pán)忙于讀或者寫(xiě)請(qǐng)求的時(shí)候持續(xù)時(shí)間的比率。根據(jù)拇指定律，此值應(yīng)該小于50%。

Disk Reads/Sec和Disk

Writes/Sec計(jì)數(shù)器顯示出在磁盤(pán)中讀寫(xiě)操作的速率。這兩個(gè)值應(yīng)該小于磁盤(pán)能力的85%。當(dāng)超過(guò)此值，磁盤(pán)的訪問(wèn)時(shí)間將以指數(shù)方式增長(zhǎng)。

可以通過(guò)以下方式來(lái)計(jì)算逐漸增長(zhǎng)的負(fù)載的能力。一種方法是使用SQLIO。你應(yīng)該找到吞吐量比較穩(wěn)定，但緩慢增長(zhǎng)。

可以使用以下公式來(lái)計(jì)算RAID配置：

Raid 0: I/O per disk = (reads + writes) / number

ofdisks

Raid 1: I/O per disk = [reads + (writes*2)] /

2

Raid 5: I/O per disk = [reads + (writes*4)] / number of

disks

Raid

10: I/O per disk = [reads +

(writes*2)] / number of disks

比如：對(duì)于RAID 1，如果得到下面的計(jì)數(shù)器：

Disk Reads/sec = 90

Disk

Writes/sec =75

根據(jù)公式：[reads + (writes*2)] / 2 or [90 + (75*2)] /

2 = 120I/Os每個(gè)磁盤(pán)。

動(dòng)態(tài)管理視圖（DMVs）：

有很多游泳的DMVs可以用于檢查I/O瓶頸：

當(dāng)一個(gè)頁(yè)面被用于讀或者寫(xiě)訪問(wèn)且頁(yè)面在緩沖池中不存在或不可用時(shí)，會(huì)引發(fā)一個(gè)I/O閂鎖等待（I/O

latch），它會(huì)在PAGEIOLATCH_EX/PAGEIOLATCH_SH（具體根據(jù)請(qǐng)求類型而定）。這些等待表明一個(gè)I/O瓶頸?？梢允褂胹ys.dm_os_wait_stats找到閂鎖等待的信息。如果你保存了SQLServer正常運(yùn)行下的waiting_task_counts和wait_time_ms值，并且于此次的值做對(duì)比，可以識(shí)別出I/O問(wèn)題：

select *

from sys.dm_os_wait_stats

where wait_type like

'PAGEIOLATCH%'

order by wait_type asc

掛起的I/O請(qǐng)求可以在下面查詢中查到，并且用于識(shí)別那個(gè)磁盤(pán)負(fù)責(zé)的這個(gè)瓶頸：

select database_id,

file_id,

io_stall,

io_pending_ms_ticks,

scheduler_address

from sys.dm_io_virtual_file_stats(NULL, NULL) iovfs,

sys.dm_io_pending_io_requests as iopior

where iovfs.file_handle = iopior.io_handle

磁盤(pán)碎片（Disk Fragmentation）：

建議你檢查磁盤(pán)碎片和配置用于SQLServer實(shí)例的磁盤(pán)。在NTFS文件系統(tǒng)中的碎片會(huì)產(chǎn)生嚴(yán)重的性能影響。磁盤(pán)需要經(jīng)常整理碎片并且指定整理碎片計(jì)劃。研究表明，一些情況下SAN在整理碎片后性能更差。因此，SAN必須根據(jù)實(shí)際情況對(duì)待。

NTFS上的索引碎片同樣能引起高I/O好用。但是這和在SANs中的效果是不一樣的。

磁盤(pán)配置/最佳實(shí)踐：

常規(guī)情況，你應(yīng)該把日志文件和數(shù)據(jù)文件分開(kāi)存放以獲得更好的性能。對(duì)于重負(fù)載的數(shù)據(jù)文件（包括tempdb）的I/O特性是隨機(jī)讀取。對(duì)于日志文件，是順序訪問(wèn)的，除非事務(wù)需要回滾。

對(duì)于內(nèi)置磁盤(pán)僅僅可以用于數(shù)據(jù)庫(kù)日志文件，因?yàn)樗鼈儗?duì)順序I/O有很好的性能，但是對(duì)隨機(jī)I/O性能低下。

數(shù)據(jù)庫(kù)的數(shù)據(jù)和日志文件應(yīng)該放在對(duì)應(yīng)專用的磁盤(pán)中。確保良好的性能。建議日志文件放在兩個(gè)內(nèi)置磁盤(pán)，并配置為RAID

1。數(shù)據(jù)文件駐留在僅用于給SQLServer訪問(wèn)的SAN系統(tǒng)中，并只被查詢和報(bào)表控制。特殊訪問(wèn)應(yīng)該被禁止。

寫(xiě)緩沖在可能的情況下應(yīng)該被允許，并保證斷電也能使用。

為了盡可能保證對(duì)于OLTP系統(tǒng)的I/O瓶頸影響最小化，不應(yīng)該把OLAP和OLTP環(huán)境混合。并且保證你的代碼優(yōu)化及有合適的索引來(lái)避免不必要的I/O。

SqlServer2008R2 插入數(shù)據(jù)超時(shí)

在數(shù)據(jù)庫(kù)鏈接沒(méi)有問(wèn)題的前提下，這個(gè)屬于數(shù)據(jù)庫(kù)請(qǐng)求超時(shí)，關(guān)鍵點(diǎn)是你的sql語(yǔ)句，斷點(diǎn)跟蹤把最終要執(zhí)行的sql語(yǔ)句復(fù)制下來(lái)在sql里面執(zhí)行一下試試，本人也碰到的統(tǒng)樣的問(wèn)題，兩個(gè)視圖和一個(gè)表聯(lián)合查詢，在sqlserver2008里面執(zhí)行需要50多秒才得到結(jié)果，建議優(yōu)化一下sql語(yǔ)句，提高sql語(yǔ)句執(zhí)行的效率。

本文標(biāo)題：閂鎖sqlserver,古代木門(mén)門(mén)閂鎖
文章轉(zhuǎn)載：http://m.rwnh.cn/article24/dscddje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、手機(jī)網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計(jì)、Google、電子商務(wù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)