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