升級的主要操作在以下幾步:
1、將SQL Server 2000 中的你要升遷的數據庫做分離操作,復制出每個(gè)數據庫的兩個(gè)文件(一般一個(gè)MDF、一個(gè)LDF,不清楚的話(huà),去查看每個(gè)數據庫的屬性)。
2、安裝SQL Server 2008 R2。如果原數據庫非常重要,請用新的計算機服務(wù)器進(jìn)行操作,不要在原來(lái)的服務(wù)器上操作。
3、在SQL Server 2008 R2上進(jìn)行附加操作,將復制出的數據庫文件附加進(jìn)去,工作即告完成。
如果你正在負責一個(gè)基于SQL Server的項目,或者你剛剛接觸SQL Server,你都有可能要面臨一些數據庫性能的問(wèn)題,這篇文章會(huì )為你提供一些有用的指導(其中大多數也可以用于其它的DBMS)。
在這里,我不打算介紹使用SQL Server的竅門(mén),也不能提供一個(gè)包治百病的方案,我所做的是總結一些經(jīng)驗----關(guān)于如何形成一個(gè)好的設計。 這些經(jīng)驗來(lái)自我過(guò)去幾年中經(jīng)受的教訓,一直來(lái),我看到許多同樣的設計錯誤被一次又一次的重復。
你了解你用的工具嗎?不要輕視這一點(diǎn),這是我在這篇文章中講述的最關(guān)鍵的一條。也許你也看到有很多的SQL Server程序員沒(méi)有掌握全部的T-SQL命令和SQL Server提供的那些有用的工具。
“什么?我要浪費一個(gè)月的時(shí)間來(lái)學(xué)習那些我永遠也不會(huì )用到的SQL命令???”,你也許會(huì )這樣說(shuō)。對的,你不需要這樣做。
但是你應該用一個(gè)周末瀏覽所有的T-SQL命令。在這里,你的任務(wù)是了解,將來(lái),當你設計一個(gè)查詢(xún)時(shí),你會(huì )記起來(lái):“對了,這里有一個(gè)命令可以完全實(shí)現我需要的功能”,于是,到MSDN查看這個(gè)命令的確切語(yǔ)法。
不要使用游標讓我再重復一遍:不要使用游標。如果你想破壞整個(gè)系統的性能的話(huà),它們倒是你最有效的首選辦法。
大多數的初學(xué)者都使用游標,而沒(méi)有意識到它們對性能造成的影響。它們占用內存,還用它們那些不可思議的方式鎖定表,另外,它們簡(jiǎn)直就像蝸牛。
而最糟糕的是,它們可以使你的DBA所能做的一切性能優(yōu)化等于沒(méi)做。 不知你是否知道每執行一次FETCH就等于執行一次SELECT命令?這意味著(zhù)如果你的游標有10000條記錄,它將執行10000次SELECT!如果你使用一組SELECT、UPDATE或者DELETE來(lái)完成相應的工作,那將有效率的多。
初學(xué)者一般認為使用游標是一種比較熟悉和舒適的編程方式,可很不幸,這會(huì )導致糟糕的性能。 顯然,SQL的總體目的是你要實(shí)現什么,而不是怎樣實(shí)現。
我曾經(jīng)用T-SQL重寫(xiě)了一個(gè)基于游標的存儲過(guò)程,那個(gè)表只有100,000條記錄,原來(lái)的存儲過(guò)程用了40分鐘才執行完畢,而新的存儲過(guò)程只用了10秒鐘。在這里,我想你應該可以看到一個(gè)不稱(chēng)職的程序員究竟在干了什么!!!我們可以寫(xiě)一個(gè)小程序來(lái)取得和處理數據并且更新數據庫,這樣做有時(shí)會(huì )更有效。
記住:對于循環(huán),T-SQL無(wú)能為力。
CTP1已經(jīng)可以下載了。
感覺(jué)這次數據庫引擎確實(shí)有了不少的增強,之前很多人抱怨MS只重視BI不重視數據庫引擎。一),Hekaton支持OLTP的in-memory 數據庫引擎,據我了解,Hekaton的storage engine處理事務(wù)的方式跟傳統的引擎有極大的區別,據微軟稱(chēng),客戶(hù)使用之后,在不改動(dòng)代碼/極小改動(dòng)的情況下,性能提升了10多倍。
但據國內一些MVP反應,他們使用內部版本的測試情況看來(lái),性能沒(méi)有提升的那么多。為啥Hekaton那么快?因為跟傳統數據庫主要有如下特點(diǎn),1,Hekaton采用optimistic multiversion concurrency control (MVCC)機制,也就是采用Hekaton的事務(wù)不再需要LOCK/latch,號稱(chēng)無(wú)blocking(根據我觀(guān)察,blocking還是有的,比如說(shuō)在conflict檢查的時(shí)候,但是沒(méi)有了LOCK/latch,blocking肯定大大減少),無(wú)deadlock。
2,Hekaton處理的數據預先全部存儲在內存中,所以避免了 physical io.3,Transaction Logging事務(wù)跟傳統數據庫引擎又很大的區別。傳統數據庫只能順序寫(xiě)日志,而Hekaton可以并行寫(xiě)多個(gè)日志流了!,并且不使用write-ahead logging ,Hekaton何時(shí)做logging?答案是只有在驗證事務(wù)可以成功提交(很拗口吧,何為驗證事務(wù)可以成功提交?這是MVCC概念,有空詳細講)的情況下才開(kāi)始做logging,同事Hekaton沒(méi)有UNDO的概念,為啥沒(méi)有UNDO,因為它沒(méi)有寫(xiě)臟頁(yè)的概念。
4,會(huì )將T-SQL編譯為native code,據微軟測試,有多倍的性能提升。所以個(gè)人感覺(jué)假如你的系統有上面這些瓶頸,比如LOCK/latch,Transaction Logging的寫(xiě)等問(wèn)題,那你的提升是很明顯的。
二)resource governor已經(jīng)支持對IO 控制。三)Buffer pool 對SSD的利用大大的增加了性能(這個(gè)不是平時(shí)說(shuō)簡(jiǎn)單的替換硬盤(pán)是SSD,不過(guò)詳細的我也沒(méi)有研究過(guò):-))四)Query-processing方面的重新設計。
Cardinality Estimator的算法已經(jīng)重寫(xiě)了,更加準確的cardinality estimates.五)ColumnStore Index已經(jīng)現在可更新了不過(guò)這個(gè)更多應該引用在BI方面。
查詢(xún)速度慢的原因很多,常見(jiàn)如下幾種:
1、沒(méi)有索引或者沒(méi)有用到索引(這是查詢(xún)慢最常見(jiàn)的問(wèn)題,是程序設計的缺陷)
2、I/O吞吐量小,形成了瓶頸效應。
3、沒(méi)有創(chuàng )建計算列導致查詢(xún)不優(yōu)化。
4、內存不足
5、網(wǎng)絡(luò )速度慢
6、查詢(xún)出的數據量過(guò)大(可以采用多次查詢(xún),其他的方法降低數據量)
7、鎖或者死鎖(這也是查詢(xún)慢最常見(jiàn)的問(wèn)題,是程序設計的缺陷)
8、sp_lock,sp_who,活動(dòng)的用戶(hù)查看,原因是讀寫(xiě)競爭資源。
9、返回了不必要的行和列
10、查詢(xún)語(yǔ)句不好,沒(méi)有優(yōu)化
可以通過(guò)如下方法來(lái)優(yōu)化查詢(xún):
1、把數據、日志、索引放到不同的I/O設備上,數據庫增加讀取速度,以前可以將Tempdb應放在RAID0上,SQL2000不在支持。數據量(尺寸)越大,提高I/O越重要.
2、縱向、橫向分割表,減少表的尺寸(sp_spaceuse)
3、升級硬件
4、根據查詢(xún)條件,建立索引,優(yōu)化索引、優(yōu)化訪(fǎng)問(wèn)方式,限制結果集的數據量。注意填充因子要適當(最好是使用默認值0)。索引應該盡量小,使用字節數小的列建索引好(參照索引的創(chuàng )建),不要對有限的幾個(gè)值的字段建單一索引如性別字段
聲明:本網(wǎng)站尊重并保護知識產(chǎn)權,根據《信息網(wǎng)絡(luò )傳播權保護條例》,如果我們轉載的作品侵犯了您的權利,請在一個(gè)月內通知我們,我們會(huì )及時(shí)刪除。
蜀ICP備2020033479號-4 Copyright ? 2016 學(xué)習?shū)B(niǎo). 頁(yè)面生成時(shí)間:3.645秒