Хамгийн их параллелизм (DOP) нь SQL серверийн тохиргооны дэвшилтэт сонголт бөгөөд олон асуултын сэдэв болж, олон нийтлэлийн сэдэв болсон. Энэхүү блог нийтлэлд зохиогч энэ сонголт юу болох, хэрхэн ашиглах талаар тодорхой мэдээлэл өгөх болно гэж найдаж байна.

Нэгдүгээрт, зохиогч дээрх сонголт нь олон холболт (эсвэл хэрэглэгчдэд) үйлчлэх үед SQL Server хэдэн процессор ашиглаж болохыг тогтоосон гэсэн эргэлзээг арилгахыг хүсч байна - тийм биш! Хэрэв SQL Server нь сул зогсолттой дөрвөн процессорт хандах эрхтэй бөгөөд бүх дөрвөн процессорыг ашиглахаар тохируулагдсан бол параллелизмын дээд түвшингээс үл хамааран бүх дөрвөн процессорыг ашиглана.

Тэгэхээр энэ сонголт юу хийх вэ? Энэ сонголт нь SQL серверийн нэг асуулгад ашиглаж болох процессоруудын дээд хэмжээг тогтоодог. Хэрэв SQL сервер рүү асуулга буцаж ирэх ёстой их хэмжээний эзэлхүүнӨгөгдөл (олон бичлэгүүд), заримдаа үүнийг хэд хэдэн жижиг асуулгад хувааж параллель болгох нь утга учиртай бөгөөд тус бүр нь өөрийн дэд мөрүүдийг буцаана. Тиймээс SQL сервер нь олон процессор, улмаар олон процессортой системүүдийг ашиглах боломжтой олон тооныБүх асуулгын бүртгэлийг нэг процессортой системээс хурдан буцаах боломжтой.

SQL сервер нь "Intra Query Parallelism" (асуулгаа олон хэлхээнд тараах) үүсгэхээс өмнө авч үзэх ёстой олон шалгуур байдаг бөгөөд тэдгээрийг энд дэлгэрэнгүй тайлбарлах нь утгагүй юм. Та тэдгээрийг BOL дээр "Degree of parallelism" гэж хайж олох боломжтой. Зэрэгцээ болгох шийдвэр нь процессорын санах ойн боломж, ялангуяа процессорууд өөрсдөө байгаа эсэх дээр суурилдаг гэжээ.

Тиймээс бид яагаад энэ сонголтыг ашиглах ёстой гэж бодож байна вэ, учир нь үүнийг анхдагч утгаар нь үлдээх нь (SQL сервер нь параллелчлалыг өөрөө шийддэг) заримдаа хүсээгүй үр дагаварт хүргэж болзошгүй юм. Эдгээр эффектүүд дараах байдалтай байна.

• Зэрэгцээ асуулга нь удаан ажилладаг.
• Асуулгын гүйцэтгэлийн хугацаа тодорхой бус болж, энэ нь хэрэглэгчдийг бухимдуулж болно. Гүйцэтгэлийн хугацаа дараахь шалтгааны улмаас өөрчлөгдөж болно.
  • Асуулга нь заримдаа зэрэгцээ байж болох ч заримдаа үгүй.
  • Хэрэв процессорууд өмнө нь ачаалал ихтэй байсан бол хүсэлтийг зэрэгцээ хүсэлтээр хааж болно.

Үргэлжлүүлэхийн өмнө зохиогч параллелизмын дотоод зохион байгуулалтад шумбах шаардлагагүй гэдгийг тэмдэглэхийг хүсч байна. Хэрэв та үүнийг сонирхож байгаа бол "Books on Line" номын "Зэрэгцээ асуулга боловсруулах" нийтлэлийг уншиж болно, энд энэ мэдээллийг илүү дэлгэрэнгүй танилцуулсан болно. Зохиолч параллелизмын дотоод зохион байгуулалтын талаар мэдэх ёстой хоёр л чухал зүйл гэж үздэг.

1. Зэрэгцээ хүсэлт нь "Зэрэгцээ байдлын дээд зэрэг" сонголтод зааснаас илүү олон хэлхээ үүсгэж болзошгүй. DOP 4 нь арван хоёроос дээш урсгал, дөрөв нь асуулгад, мөн төрөл, хэлхээ, агрегат, угсралт гэх мэт нэмэлт урсгалуудыг үүсгэж болно.
2. Асуулгын параллел байдал нь CXPACKET эсвэл 0X0200 хүлээх төрөлтэй өөр SPID хүлээлтийг үүсгэж болно. Үүнийг системийн процесст CXPACKET зэрэгтэй зэрэгцээ ажиллагаа хүлээж байгаа SPID-г олоход ашиглаж болно. Энэ ажлыг хөнгөвчлөхийн тулд зохиогч өөрийн блогт байгаа хадгалагдсан процедурыг ашиглахыг санал болгож байна: track_waitstats.

Тиймээс "Зэрэгцээ байдлаар асуулга удааширч магадгүй" яагаад?

• Хэрэв систем нь маш сул байвал нэвтрүүлэх чадвардискний дэд системүүд, дараа нь асуулга задлан шинжилж байх үед түүний задрал нь параллелизмгүйгээр илүү удаан үргэлжлэх болно.
• Зэрэгцээ ашиглагдаж, дараа нь эхлүүлсэн өөр процессоор үүсгэгдсэн процессорын боломжит өгөгдлийн хазайлт эсвэл өгөгдлийн мужийг түгжих гэх мэт.
• Хэрэв предикатын индекс байхгүй бол хүснэгтийг сканнердах болно. Асуулга доторх зэрэгцээ үйлдэл нь дараалсан гүйцэтгэлийн төлөвлөгөө, зөв ​​индекстэй асуулга илүү хурдан ажиллах болно гэдгийг нууж болно.

Дээр дурдсан параллелизмын үр нөлөө нь асуулгын параллелчлалын дотоод механикийг OLTP програмуудад ашиглахад тохиромжгүй гэсэн санааг танд хүргэх ёстой. Эдгээр нь асуулгын гүйцэтгэлийн хугацааг өөрчлөх нь хэрэглэгчдийг бухимдуулдаг программууд бөгөөд олон хэрэглэгчдэд нэгэн зэрэг үйлчилдэг сервер нь эдгээр програмууд дахь процессорын ажлын ачааллын хувийн шинж чанараас шалтгаалан зэрэгцээ гүйцэтгэлийн төлөвлөгөөг сонгох боломжгүй юм.

Тиймээс, хэрэв та параллелизмыг ашиглах гэж байгаа бол энэ нь олон тооны асуулга байдаггүй, гэхдээ тэдгээр нь нэлээд хүнд бөгөөд хүчирхэг төхөөрөмж дээр ажилладаг өгөгдөл олборлох ажил (өгөгдлийн агуулах), шийдвэр гаргах эсвэл тайлагнах системд хэрэгтэй болно. их хэмжээний үйлдлийн санах ойтой сервер.

Хэрэв та параллелизмыг ашиглахаар шийдсэн бол DOP-д ямар утгыг тохируулах ёстой вэ? Хэрэв танд 8 процессор байгаа бол DOP = 4 гэж тохируулах нь энэ механизмын сайн туршлага бөгөөд энэ нь хамгийн оновчтой тохиргоо байх магадлалтай. Гэхдээ ийм байдлаар ажиллана гэсэн баталгаа байхгүй. Үүнд итгэлтэй байх цорын ганц арга бол DOP-ийн өөр утгыг шалгах явдал юм. Нэмж дурдахад зохиолч өөрийн эмпирик зөвлөгөө өгөхийг хүссэн бөгөөд энэ тоог бэлэн байгаа процессоруудын талаас илүүд нь хэзээ ч бүү тавь. Хэрэв зохиогч зургаагаас цөөн процессортой байсан бол DOP-ийг 1 болгож тохируулах бөгөөд энэ нь параллель байдлыг идэвхгүй болгодог. Хэрэв энэ нь зөвхөн нэг хэрэглэгчийн процессыг (зарим өгөгдөл хайх технологи эсвэл тайлагнах даалгавар) дэмждэг мэдээллийн сантай байсан бол онцгой тохиолдол гаргаж магадгүй бөгөөд энэ тохиолдолд онцгой тохиолдол болгон DOP-ийг 0 (үндсэн) болгож тохируулах боломжтой. SQL Server нь асуулгатай зэрэгцүүлэх эсэхээ өөрөө шийдэх боломжийг олгодог.

Өгүүллийг дуусгахын өмнө зохиогч индексүүдийг зэрэгцээ үүсгэх нь таны DOP-д тохируулсан тооноос хамаарна гэдгийг анхааруулахыг хүссэн. Энэ нь та энэ үйлдлийн гүйцэтгэлийг сайжруулахын тулд индекс үүсгэх эсвэл дахин үүсгэх үед үүнийг өөрчлөхийг хүсч болно гэсэн үг бөгөөд мэдээжийн хэрэг та асуулгад MAXDOP зөвлөмжийг ашиглаж болох бөгөөд энэ нь тохиргоонд тохируулсан утгыг үл тоомсорлож болно. ачаалал багатай үед ашиглах боломжтой.

Эцэст нь хэлэхэд, алдааны улмаас таны хүсэлт зэрэгцсэн үед удааширч болзошгүй тул сервер дээрээ хамгийн сүүлийн үеийн үйлчилгээний багц суулгасан эсэхээ шалгаарай.

REATE proc track_waitstats
@num_samples int = 10
,@delaynum int = 1
,@delaytype nvarchar ( 10 )="минут"
AS
-- Т.Дэвидсон
-- Энэхүү хадгалагдсан процедурыг = IS= гэж заасан бөгөөд ямар ч баталгаагүй,
-- болон бага хурал эрхгүй.
-- Оруулсан скриптийн дээжийг ашиглах нь нөхцөлийн дагуу явагдана
-- http://www.microsoft.com/info/cpyright.htm дээр заасан
-- @num_samples нь хүлээлгийн статистикийг авах тоо юм,
-- анхдагч нь 10 удаа. Анхдагч саатлын интервал нь 1 минут байна
-- саатал нь саатлын интервал юм. delaytype нь эсэхийг тодорхойлно
-- саатлын интервал нь минут эсвэл секунд байна
-- байхгүй бол waitstats хүснэгт үүсгэх, үгүй ​​бол таслах

тоологдохгүй
байхгүй бол (сонго 1 name = "waitstats" sysobjects-аас)
Хүснэгтийн хүлээх статуудыг үүсгэх(varchar( 80 ),
тоон хүсэлт ( 20 ,1 ),
тоон ( 20 ,1 ),
тоон ( 20 ,1 ),
одоо datetime өгөгдмөл getdate())
эс бөгөөс хүснэгтийн хүлээх статуудыг тайруулна

dbcc sqlperf (хүлээлтийн статистик, тодорхой) -- хүлээлтийн статистикийг арилгах

@i int гэж зарлах
,@delay varchar ( 8 )
,@dt varchar ( 3 )
,@одоо огноо
,@totalwait тоон ( 20 ,1 )
,@endtime datetime
,@begintime datetime
,@hr int
,@мин дот
,@sec int

@i = сонгоно уу 1
@dt = жижиг жижиг (@delaytype) сонгох
"минут" дараа нь "м" байх үед
"минут" дараа нь "м" үед
"мин" дараа нь "м" үед
"мм" дараа нь "м" үед
"ми" дараа нь "м" үед
"m" дараа нь "m" үед
"секунд" дараа нь "s"
"хоёр дахь" үед дараа нь "s"
үед "сек" дараа нь "s"
"ss" үед дараа нь "s"
үед "s" дараа нь "s"
өөр @delaytype
Төгсгөл

хэрэв @dt байхгүй бол ("s", "m")
Эхлэх
хэвлэх "Сагацлын төрлийг жишээлбэл секунд эсвэл минут оруулна уу"
буцах
Төгсгөл

хэрэв @dt = "s"
Эхлэх
@sec = @delaynum % сонгох 60
сонгох @мин = cast((@delaynum / 60 ) int шиг)
сонгох @цаг = дамжуулах((@мин / 60 ) int шиг)
@мин = @мин % сонгох 60
Төгсгөл

хэрэв @dt = "m"
Эхлэх
@sec=-г сонгоно уу 0
@min = @delaynum % сонгох 60
сонгох @hr = cast((@delaynum / 60 ) int шиг)
Төгсгөл

@delay = баруун ("0" + хөрвүүлэх(varchar() 2 ),@цаг), 2 ) + ":" +
2 ),@мин), 2 ) + ":" +
+ баруун("0" +хувиргах(varchar( 2 ),@сек), 2 )

хэрэв @цаг > 23 эсвэл @ мин > 59 эсвэл @сек > 59
Эхлэх
сонгох "hh:mm:ss саатал > 23:59:59"
"сааталтын интервалыг сонгоод бичнэ үү: " + хөрвүүлэх (varchar ( 10 )
,@delaynum) + "," + @delaytype + " " руу хөрвүүлдэг
+ @ саатал
буцах
Төгсгөл

байхад (@i<= @num_samples)
Эхлэх
хүлээх статуудад оруулах(, хүсэлт,
,)
exec("dbcc sqlperf(хүлээлтийн тоо)")
@i = @i +-г сонгоно уу 1
саатал @ саатал хүлээх
Төгсгөл

Хүлээлтийн статистикийн тайлан үүсгэх
get_waitstats-г ажиллуул

--//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/

get_waitstats proc ҮҮСГЭ
AS
-- Энэхүү хадгалагдсан процедурыг = IS= гэж заасан бөгөөд ямар ч баталгаагүй бөгөөд
-- хурал ямар ч эрхгүй.
-- Оруулсан скриптийн дээжийг ашиглах нь заасан нөхцлийн дагуу явагдана
-- http://www.microsoft.com/info/cpyright.htm хаягаар
--
-- энэ процесс нь хүлээлгийн төрлөөр хүлээх статтын тайланг үүсгэх болно
-- хувь
-- track_waitstats ажиллаж байх үед ажиллуулж болно

тоологдохгүй

@now datetime-г зарлана
,@totalwait тоон ( 20 ,1 )
,@endtime datetime
,@begintime datetime
,@hr int
,@мин дот
,@sec int

@now=max (одоо),@begintime=min (одоо),@endtime=max (одоо) сонгоно уу.
waitstats-аас = "Нийт"

Хүлээлт, унтах, нөөцийн_дараалалыг Total-аас хас

@totalwait = sum() +-г сонгоно уу 1 хүлээлтийн статуудаас
хаана байхгүй ("WAITFOR" , "SLEEP" , "RESOURCE_QUEUE"
, "Нийт" , "***нийт***" ) ба одоо = @одоо

Тохируулсан нийлбэр дүнг оруулах, хувиар буурахаар эрэмбэлэх

Хүлээлтийн статуудыг устгана уу. Энд = "***нийт***" ба одоо = @одоо

хүлээлгийн статуудад оруулах "***нийт***"-г сонгоно уу.
,0
,@totalwait
,@totalwait
, @ одоо

сонгох
,
, хувь = цутгамал ( 100 */@totalwait тоогоор ( 20 ,1 ))
хүлээлтийн статуудаас
хаана байхгүй ("WAITFOR" , "SLEEP" , "RESOURCE_QUEUE", "Нийт" )
одоо = @одоо
хувиар бууруулах

Энэхүү богино тэмдэглэлд би Microsoft SQL Server дээрх зэрэгцээ тохиргооны нарийн төвөгтэй байдлын талаар бага зэрэг ярихыг хүсч байна. Та нарын олонхи нь SQL Server-д маш удаан хугацаанд ашиглагдаж ирсэн Max Degree od Parallelism сонголтыг эртнээс мэддэг байсан. Анхдагч байдлаар энэ нь 0-д тохируулагдсан бөгөөд энэ нь SQL Server нь параллелизмын оновчтой түвшинг, өөрөөр хэлбэл нэг зааврыг гүйцэтгэхэд оролцдог процессор / урсгалын тоог өөрөө сонгоно гэсэн үг юм. Би одоо зогсоож, энэ сонголтыг ямар үнэ цэнтэй болгох нь дээр гэж ярихгүй - энэ бол тусдаа тэмдэглэлийн сэдэв юм. Би зөвхөн энэ сонголтын утга нь асуулгын гүйцэтгэлд хэрхэн нөлөөлөхийг авч үзэх болно. Жишээлбэл, доорх зурагт энэ сонголтыг 1 гэж тохируулсан бөгөөд энэ нь бүх асуулгын зэрэгцээ төлөвлөгөөг анхдагчаар идэвхгүй болгосон гэсэн үг юм.

Энэ сонголтыг дараах T-SQL тушаалаар үзэх боломжтой:

Үнэн хэрэгтээ аливаа өгөгдмөл асуулгын төлөвлөгөө дараалсан байх болно. Жишээлбэл:

Гэсэн хэдий ч хөгжүүлэгч болон аливаа хэрэглэгч зөвлөмжийг ашиглан үүнд нөлөөлөх боломжтой хэвээр байна. Үүнийг хийхийн тулд та хүссэн параллелизмын түвшинг зааж өгөх хэрэгтэй бөгөөд хүссэн асуулгын төлөвлөгөөг үүсгэнэ, жишээлбэл:

Хэрэв бид энэ асуулгыг sys.dm_exec_query_profiles харагдацаар ажиглавал энэ нь үнэхээр 10 хэлхээнд хийгдэж байгааг харах болно.

Тиймээс, системд хөгжүүлэгчид болон хэрэглэгчид "хурдасгах" боломжтой нууц нүх хэвээр байна (энд би үүнийг тусгайлан хашилтанд оруулав, учир нь үргэлж их хэмжээний параллель байдал нь асуулгын гүйцэтгэлийн хугацааг багасгахад хүргэдэггүй) параллелизмын зэргийг нэмэгдүүлэх замаар . Гэхдээ ийм байдлаар тэд олон хяналтгүй зэрэгцээ хүсэлтүүдийг нэгэн зэрэг эхлүүлснээр серверийг зүгээр л "алж" чадна. Бид энэ талаар юу хийж чадах вэ? Энд нөөцийн захирагч аврах ажилд ирдэг бөгөөд энэ нь танд өөр өөр хэрэглэгчийн бүлгүүдийн хооронд нөөцийг маш уян хатан хуваарилах боломжийг олгодог маш хүчирхэг бөгөөд бүрэн дутуу үнэлэгдсэн систем юм. Дахин хэлэхэд, энэ нь хэрхэн ажилладаг, ямар чадвартай болохыг би ярихгүй. Би зүгээр л түүний зэрэгцээ хязгаарлалтын тохиргоо үүнд хэрхэн нөлөөлөх талаар дэлгэрэнгүй ярих болно. Эхлээд анхдагч тохиргоог харцгаая:

Дахин хэлэхэд сонголт нь анхдагчаар 0-д тохируулагдсан бөгөөд хамгийн дээд зэрэглэлийг сонгох шийдвэр нь SQL Server-ийн өршөөлөөр байгааг бид харж байна. Одоо би энэ утгыг 5 болгож өөрчилбөл юу болохыг харцгаая. Би нөөцийн захирагчийн ангиллын функцийг ч тодорхойлоогүй байгаа бөгөөд үндсэн бүлгийг өөрчилж байна. Гэхдээ миний жишээн дээр яг одоо бүх зүйл хэрхэн ажилладагийг шалгах, ойлгохын тулд энэ нь хангалттай юм. Тиймээс би хүн бүрт параллелизмын дээд хэмжээг 5 утас хүртэл хязгаарлаж байна. Сонголт гэдгийг санаарай Параллелизмын дээд зэрэг, бидний өмнө нь харж байсан 1-д тохируулагдсан хэвээр байна. Хэрэв бид одоо анхны асуулгынхаа гүйцэтгэлийн төлөвлөгөөг харвал анхдагч байдлаар энэ нь дараалсан байх ба maxdop 10 сонголттой бол зэрэгцээ байх болно. Гэхдээ хэрэв бид зэрэгцээ төлөвлөгөө хэрэгжүүлбэл сонирхолтой зүйлийг харах болно.

Одоо сонголт байгаа хэдий ч бидний хүсэлтийг зөвхөн 5 урсгалаар гүйцэтгэж байна maxdopЭнэ нь 10 утгатай байна. Мөн хэрэв та асуулгад maxdop сонголт 4-ийг зааж өгвөл энэ нь 4 хэлхээнд хийгдэх болно (Resource Governor дээрх сонголтыг 5 болгож тохируулсан). Энэ тохиолдолд зөвлөмж maxdopНөөцийн захирагч тохиргооноос бага тул нэмэлт хязгаарлалт тавихгүй. Би үүний жишээг хэлэхээ больсон.

Тиймээс, Resource Governor нь асуулгад параллелизмын дээд хэмжээг аль хэдийн хязгаарладаг илүү хүчирхэг хэрэгсэл бөгөөд өөр өөр хэрэглэгчдийн бүлгүүдэд энэ зэрэглэлийг өөр өөрөөр тохируулах боломжтой. Үүний зэрэгцээ сонголт Параллелизмын дээд зэрэгодоо ч гэсэн ажиллаж байгаа бөгөөд бага ч гэсэн хийдэг (эсвэл нөөцийн захирагчтай хослуулсан үед админ, хөгжүүлэгчид болон хэрэглэгчдийг бага зэрэг төөрөлдүүлдэг). Цаашилбал, эдгээр 2 параметрийн утгыг тохируулах сонголтууд нь зөвхөн таны төсөөллөөр хязгаарлагддаг боловч зөвхөн хоёр зүйлийг санах нь чухал юм. Параллелизмын дээд зэрэгболон сануулга maxdopХүсэлт нь аль төлөвлөгөөг үүсгэх, энэ хүсэлтэд хамгийн их хэдэн хэлхээ үүсгэх боломжтой байх зэрэгт нөлөөлдөг бөгөөд нөөцийн захирагч дээрх хүсэлтийг ажиллах үед аль хэдийн хязгаарладаг.

Зорилтот: 1С асуулгатай ажиллахад SQL параллелизмын нөлөөг судлах

Уран зохиол:

Туршилтын орчин:

Windows Server 2008 R2 Enterprise

MS SQL Server 2008 R2

1С Enterprise 8.2.19.90

Зураг 1. SQL шинж чанарууд "Ерөнхий"

Зураг 2. SQL шинж чанарууд "Advanced"

Багаж хэрэгсэл:

SQL серверийн профайл

Query Console 1C

Туршилтын хүсэлт:

СОНГОХ

AK.Name AS Нэр

FROM

Мэдээллийн бүртгэл.Хаяг ангилагч AS AK

ДОТООД НЭГДСЭНМэдээллийн бүртгэл.Хаяг ангилагч AS AK1

SW AK.Code = AK1.Code

Сургалт:

Бид SQL server Profiler-ийг эхлүүлж, холболт үүсгэж, үйл явдал, баганыг Зураг 3-т үзүүлсэн шиг тэмдэглэнэ.

Зураг 3. Trace шинж чанарууд

Манай баазын сонголтыг хийж байна

Зураг 4. Өгөгдлийн сангаар шүүнэ

Товчлол:

Зэрэгцээ байдлын хамгийн дээд түвшин - MDOP

Зэрэгцээ байдлын зардлын босго - зардал

Дараалсан асуулгын төлөвлөгөөг турших (MDOP = 1)

Зураг 5. Query Console - 20 секундын гүйцэтгэлийн хугацаа

SQL серверийн параметр "Зэрэгцээ байдлын дээд зэрэг" нь 1 (зэрэглэл байхгүй) гэж тохируулсан. Бид профайл үүсгэгчийн үр дүнг хардаг (Зураг 6)

Зураг 6. Дараалсан асуулгын төлөвлөгөө

SQL сервер нь дараалсан асуулгын төлөвлөгөөг үүсгэсэн бөгөөд үүнд: CPU-ийн нийт ачаалал = 6.750 (сек), асуулга гүйцэтгэх хугацаа = 7.097 (сек)

Зэрэгцээ асуулгын төлөвлөгөөний туршилт (MDOP = 0, зардал =5)

Бид SQL серверийг параллелизм горимд оруулав (SQL Query дээр):

мастерыг ашиглах;

EXEC sp_configure "дэвшилтэт сонголтыг харуулах" , 1;

ДАХИН ТОХИРУУЛАХ ТЭМДЭГЛЭЛИЙГ ХҮЧИН ТОГТООХ

мастерыг ашиглах;

exec sp_configure "зэрэгцээний дээд зэрэг" , 0;

ДАХИН ТОХИРУУЛАХ ТЭМДЭГЛЭЛИЙГ ХҮЧИН ТОГТООХ

Ижил хайлтыг гүйцэтгэх (Зураг 7)

Зураг 7. Query Console - 16 сек гүйцэтгэх хугацаа

Профайл үүсгэгчийн үр дүнг шалгаж байна (Зураг 8)

Зураг 8. Зэрэгцээ асуулгын төлөвлөгөө

SQL сервер энэ удаад зэрэгцээ асуулгын төлөвлөгөөг бүрдүүлж, CPU-ийн нийт ачаалал = 7.905 секунд, асуулгын үргэлжлэх хугацаа = 3.458 секунд байна.

Дараалсан асуулгын төлөвлөгөөг турших (MDOP = 0, зардал = 150)

"Зэрэгцээний зардлын босго" параметрийг ашиглан зэрэгцээ төлөвлөгөөг арилгахыг хичээцгээе. Анхдагчаар параметрийг 5 гэж тохируулсан байна. Манай тохиолдолд бид 150 (SQL Query-д) утгатай зэрэгцээ төлөвлөгөө үүсэхээс салж чадсан.

мастерыг ашиглах;

exec sp_configure "зэрэгцээ байдлын зардлын босго", 150 ;

Бид эдгээр нөхцөлд хүсэлтийн гүйцэтгэлийг шалгадаг (Зураг 9)

Зураг 9. Query Console - 20 секундын гүйцэтгэлийн хугацаа

Бид үр дүнг профайлаар шалгана (Зураг 10)

Зураг 10. Дараалсан асуулгын төлөвлөгөө.

SQL Server нь дараалсан асуулгын төлөвлөгөөг үүсгэсэн. CPU-ийн нийт хэрэглээ = 7.171 сек, асуулга гүйцэтгэх хугацаа = 7.864 сек.

Дүгнэлт:

SQL серверийн зэрэгцээ асуулгын төлөвлөгөөг ашиглан 1С Enterprise орчинд туршилтын хүсэлтийг гүйцэтгэх нь дараалсан төлөвлөгөөтэй харьцуулахад гүйцэтгэлийн мэдэгдэхүйц өсөлтийг өгдөг (16 сек. эсрэг 20 сек. - 4 сек. нэмэгдүүлэх)

Зэрэгцээ асуулгын төлөвлөгөөг ашиглах үед SQL серверийн тестийн асуулгын гүйцэтгэл нь цуваа асуулгын төлөвлөгөөг ашиглахаас хоёр дахин хурдан байдаг (3.5 секундын эсрэг 7.1 секунд)

SQL серверийн параллелизмыг зөвхөн MDOP параметрээр зогсохгүй "Сost threshold for parallelism" параметрийг ашиглан тохируулж болно.

• заавар

Энэхүү гарын авлага нь SharePoint 2013-д ашиглагдах SQL Server 2012-ийн англи хувилбарыг суулгах энгийн орос хэл дээрх гарын авлагыг хайж буй эхлэгчдэд зориулагдсан болно.
Энэ нийтлэл нь мэргэжлийн хүмүүст зориулагдаагүй болно.

Бүх ажлыг 3 үе шатанд хуваана.

• SQL Server 2012 суулгаж байна
• Параллелизмын хамгийн дээд түвшний серверийн тохиргооны сонголтыг тохируулж байна
• SharePoint 2013-ийг суулгахад зориулагдсан бүртгэлийн эрхийг тохируулж байна

Мөн нийтлэлд MS Windows Server 2012 R2 Standard дээр Microsoft .NET Framework 3.5-ыг суулгах үйл явцыг тайлбарласан болно.

Анхаар: тайралт дор маш олон зураг байна!

SQL Server 2012 суулгаж байна

1. Суулгахаасаа өмнө хатуу диск дээрээ хангалттай зай байгаа эсэхийг шалгах хэрэгтэй (миний хувьд энэ нь 2.7 ГБ болсон).
Түгээлтийн иж бүрдлийг эхлүүлсний дараа зүйлийг сонгоно уу " Суурилуулалт"зүүн цэсэнд, дараа нь " зүйл дээр дарна уу " Шинэ SQL серверийг дангаар нь суулгах эсвэл одоо байгаа суулгацын онцлогуудыг нэмнэ үү":

2. Суулгах мастер эхэлнэ. Тэр шалгах болно. Та "Дэлгэрэнгүйг харуулах" товчийг дарж дэлгэрэнгүй тайланг харах боломжтой.

3. Нарийвчилсан тайлан. "OK" товчийг дарна уу:

4. Бүтээгдэхүүний түлхүүрийг оруулаад "Дараах" товчийг дарна уу:

5. Бид лицензийн гэрээний нөхцлийг хүлээн зөвшөөрч байна.
Үүнийг хийхийн тулд хайрцгийг шалгана уу Би лицензийн нөхцлийг хүлээн зөвшөөрч байна

6. "Тохируулах үүрэг" алхам дээр эхний зүйлийг сонгоно уу " SQL серверийн онцлогийг суулгах". "Дараах" товчийг дарна уу:

7. "Онцлог сонгох" алхам дээр " Өгөгдлийн сангийн хөдөлгүүрийн үйлчилгээ", "Удирдлагын хэрэгслүүд-Үндсэн"ба" Удирдлагын хэрэгслүүд - Бүрэн". Дараа нь "Дараах" товчийг дарна уу:

8. Дараа нь суулгагч өөр шалгалт хийнэ. Та "Дэлгэрэнгүйг харуулах" товчийг дарж дэлгэрэнгүй тайланг харах боломжтой.

9. Нарийвчилсан тайлан. (Энэ үе шатанд би "Microsoft .NET Framework 3.5 суулгасан ..." дүрэмд алдаа гарлаа. Доорх дэлгэрэнгүй мэдээлэл). "Дараах" товчийг дарна уу:

10. "Instance Configuration" алхамд та SQL Server үйлчилгээний жишээг тохируулах ёстой.
Дахин хэлэхэд энэ нийтлэл нь эхлэгчдэд зориулагдсан болно. Тиймээс бид өмнө нь SQL серверийг таны сервер дээр суулгаагүй гэж таамаглаж байгаа бөгөөд энэ нь бид бүх үндсэн тохиргоог орхих болно гэсэн үг юм. "Дараах" товчийг дарна уу:

11. Энэ алхамд суулгах мастер нь дискний зайны шаардлагыг харуулах болно. "Дараах" товчийг дарна уу:

12. "Серверийн тохиргоо" алхам дээр та үйлчилгээний домэйн бүртгэлийг зааж өгөх ёстой " SQL Server мэдээллийн сангийн хөдөлгүүр". "Бүртгэлийн нэр" болон "Нууц үг" талбаруудыг бөглөсний дараа "Дараах" товчийг дарна уу:

13. "Өгөгдлийн сангийн хөдөлгүүрийн тохиргоо" алхам дээр одоогийн хэрэглэгчийг SQL серверийн администраторуудад нэмэхэд хангалттай. Үүнийг хийхийн тулд "Одоогийн хэрэглэгч нэмэх" товчийг дараад "Дараах" товчийг дарна уу.

14. Дараагийн алхамд "Дараах" товчийг дарна уу:

15. Дараа нь суулгах шидтэн тестийг дахин хийж үр дүнгээ харуулна. "Дараах" товчийг дарна уу:

16. "Суулгахад бэлэн" алхам дээр шидтэн хураангуй мэдээллийг харуулах болно. Энд та "Суулгах" товчийг дарах хэрэгтэй:

17. Суулгац дууссаны дараа гүйцэтгэсэн үйлдлүүдийн талаарх мэдээлэл гарч ирнэ.

18. Энэ үе шатанд компьютераа дахин эхлүүлэхийг зөвлөж байна. Зарим тохиолдолд (жишээ нь, Microsoft .NET Framework 3.5-ийг суулгах үед) суулгах шидтэн өөрөө компьютераа дахин эхлүүлэхийг хүссэн цонхыг харуулах болно. Бүү бууж өг.

Параллелизмын хамгийн дээд түвшний серверийн тохиргооны сонголтыг тохируулж байна

"Зэрэгцээ байдлын дээд зэрэг" параметрийн анхдагч утга нь 0 байна.
SharePoint 2013 нь энэ тохиргоог 1 байхыг шаарддаг.
Үүнийг засахад хялбар!

1. Гүй Microsoft SQL Server Management Studio(Эхлэх - Бүх програмууд - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. Серверийн холболтын дэлгэцэн дээр Connect товчийг дарна уу.

3. Өөрийн сервер дээр хулганы баруун товчийг дарж " Object Explorer"болон сонгох" Үл хөдлөх хөрөнгө":

4. Нээгдэх серверийн шинж чанаруудын цонхноос зүүн талын цэснээс "хуудсыг сонгоно уу" Дэвшилтэт"болон шинж чанаруудын жагсаалтыг дэлгэцийн хамгийн доод хэсэгт гүйлгэж үзнэ үү. Параметрийн утгыг тохируулна уу " Параллелизмын дээд зэрэг"д 1 болон "OK" товчийг дарна уу:

5. SQL Server Management Studio-г хааж болохгүй, бидэнд хэрэгтэй хэвээр байх болно.

SharePoint 2013-ийг суулгахад зориулагдсан бүртгэлийн эрхийг тохируулж байна

SharePoint 2013-ийг суулгах бүртгэл нь SQL Server дээр өндөр байх ёстой.
Энэ дансанд дараах үүргийг өгөхийг зөвлөж байна.

• dbcreator
• аюулгүй байдлын админ
• олон нийтийн

1. SQL Server Management Studio-д " Object Explorer"зүйлийг өргөжүүлэх" аюулгүй байдал". Дараа нь" дээр хулганы баруун товчийг дарна уу. Нэвтрэх"болон сонгох" Шинэ нэвтрэх":

2. "Нэвтрэх нэр" талбарт SharePoint 2013 програмыг суулгаж, тохируулахаар төлөвлөж буй акаунтын домайн нэрийг оруулна уу.

3. Зүүн талд байгаа цэснээс хуудсыг сонгоно уу " Серверийн үүрэг" болон "dbcreator" болон "securityadmin" дүрүүдийг шалгаад "нийтийн" үүрэг аль хэдийн шалгагдсан эсэхийг шалгана уу. Дараа нь "OK" товчийг дарна уу:

SQL сервер одоо SharePoint 2013 суулгахад бэлэн боллоо.

MS Windows Server 2012 R2 Standard дээр Microsoft .NET Framework 3.5 суулгаж байна

Догол зүйлийн 9-р алхамд " SQL Server 2012 суулгаж байна" Надад алдаа гарлаа: .NET Framework 3.5 суулгаагүй байна.
Энэ асуудлыг шийдэхийн тулд дараах алхмуудыг дагана уу.

1. Та консолыг нээх хэрэгтэй " серверийн менежер".

2. Зүүн талын цэснээс "Хяналтын самбар" гэсэн зүйлийг сонгоно уу.

3. Цонхны голд байрлах "Үүрэг ба онцлогуудыг нэмэх" зүйл дээр дарна уу.

4. Нээгдэх шидтэн дотроос "Эхлэхээсээ өмнө" алхмыг алгасах хэрэгтэй.

5. "Суулгах төрөл" гэсэн алхам дээр " Дүрд суурилсан эсвэл онцлогт суурилсан суурилуулалт". "Дараах" товчийг дарна уу.

6. Дараагийн алхамд бүх зүйлийг анхдагч байдлаар үлдээж, "Дараах" товчийг дарна уу.

7. "Дараах" товчийг дарж "Серверийн үүрэг" алхамыг алгасах.

8. "Онцлогууд" алхам дээр ".NET Framework 3.5-ийн онцлогууд" гэсэн нүдийг чагтална уу. Бид "Дараах" товчийг дарна.

9. Суулгах процесс дууссаны дараа та Add Roles and Features Wizard-ыг хааж болно.

10. Дууслаа!

Таны толгой дээрх бүх сайхан, амар амгалан тэнгэр!

P.S. Сансрын нисгэгчдийн өдрийн мэнд хүргэе!

Энэ нийтлэл нь зөвхөн MS SQL Server дээр төвлөрөх болно. Хэрэв та Oracle, DB2, Postrgre-тэй 1С-г ашиглахдаа "азаа туршиж үзэх" гэж байгаа бол энэ мэдээлэл танд ашиггүй болно. Гэхдээ та 1С-д юуны түрүүнд MS SQL Server-ийн мэргэжилтнүүд байдаг гэдгийг ойлгох хэрэгтэй. IBM-ийн хүчин чармайлтаар DB2 мэргэжилтнүүд бас бий. Та сайн эсвэл муу DBMS-ийн талаар удаан хугацаанд ярьж болно, нэг зүйл чухал, хамгийн "гөлгөр" 1С нь MS SQL сервертэй ажилладаг. "Урд талын" хамгийн сүүлийн үеийн мэдээллүүдээс харахад DB2-тэй ажиллах нь илүү эсвэл бага зохистой болсон. Би хувьдаа 8.1 хувилбар дээр DB2-тэй ажиллахын тулд 1С-г тохируулах туршлагатай байсан ч тэнд бүх зүйл тийм ч сайн биш байсан. Ямар ч тохиолдолд өөр DBMS-ийн сонголтыг MS SQL-д байхгүй боломжууд (ачаалал тэнцвэржүүлэгч, Grid гэх мэт) эсвэл санхүүгийн хувьд (Oracle-ийг аль хэдийн худалдаж авсан) эсвэл аль аль нь сонгох хэрэгтэй. платформ (бүх зүйл линукс дээр байдаг).

Тиймээс, MS SQL сервер дээр юу хийх хэрэгтэй вэ:

1) Хамгийн бага ба хамгийн их санах ойг тохируулна уу. Хамгийн бага нь системийн санах ойн тал юм. Хамгийн дээд тал нь - 2 ГБ багтаамжгүй системийн санах ой. Үүнийг Менежмент студигээр дамжуулан хийдэг - серверийн шинж чанарт:

2) Хэрэв "Процессорууд" таб дээр тэргүүлэх ач холбогдол өгөөгүй бол та тохируулах хэрэгтэй

3) Зэрэгцээ байдлын дээд хэмжээг 1 болгож тохируулна.

4) SQL Server Agent-ийг асааж, мэдээллийн баазын шуудангаа тохируулаарай - тэнд хэцүү зүйл байхгүй, би дэлгэрэнгүй тайлбарлахгүй.

5) Үйлчилгээний төлөвлөгөөг тохируулах:
Ерөнхий:
a) Статистикийн шинэчлэлт - 2 цаг тутамд
б) DBCC FREEPROCCACHE - 2 цаг тутамд
Суурь бүрийн хувьд:
a) Бүрэн нөөцлөх
б) Дифференциал нөөц
в) Индекс дефрагментаци - өдөр бүр
d) Индексийг сэргээх - амралтын өдрүүдийн шөнө
e) Мэдээллийн сангийн бүрэн бүтэн байдлыг шалгах - сард нэг удаа шөнийн цагаар амралтын өдрүүдэд

6) Өгөгдлийн сан бүрийн хувьд сэргээх загварыг Энгийн гэж тохируулахыг зөвлөж байна (properties дотор). Хэрэв танд 24/7 ажиллах систем байхгүй бөгөөд нэг мэдээллийн санд 1000-аас бага хэрэглэгч байхгүй бол ачаалах кластер байхгүй бөгөөд ямар нэгэн тоног төхөөрөмж (болон) эвдэрсэн тохиолдолд өгөгдлийг хамгийн ойрын хугацаанд сэргээх үүрэг хүлээсэн SLA-д гарын үсэг зураагүй байна. сүүлчийн нөөцлөлтийн үеэс биш) энэ зөвлөмж нь үндэслэлтэй байх болно. Үгүй бол та хэт ургасан Transzaction Log-ыг хаана байрлуулахаа тун удахгүй удаан бодож, бухимдах болно

7) tempdb мэдээллийн санг ердийн өгөгдлийн сангаас өөр диск рүү устгана уу - энэ нь RAID массивыг дахин тохируулж, гүйцэтгэлийг нь доройтуулах гэсэн үг ч гэсэн. Үгүй бол 1 хэрэглэгч бусад бүх хүмүүсийн ажлыг саатуулж болно. Хэрэв танд хатуу дискний оронд Hardware Accelereator байгаа бол мэдээжийн хэрэг та tempdb-г салгаж болохгүй, гэхдээ энэ нь зөвхөн байгаа тохиолдолд л хэрэг болно.

8) зарим хяналтын хэрэгслийг суулгах - Би http://www.quest.com/spotlight-on-sql-server-enterprise/-д дуртай.

9) Майкрософт компанийн шилдэг туршлагын анализатор - http://www.microsoft.com/download/en/details.aspx?id=15289 - зөвхөн тохиргоо хийхээс гадна олон асуудлыг шийдвэрлэхэд тусалдаг гайхалтай хэрэгсэл юм.

Товчхондоо бид энэ бүхнийг юуны төлөө хийв:

1) Санах ой. SQL сервер нь ямар нэг шалтгаанаар түүнд байгаа бүх санах ойг ашиглахгүй байх үед хамгийн бага утга нь таныг "гажиг" -аас аврах болно. Бүгдийг нь идэх хэрэгтэй! Хэрэв ижил SQL серверийн санах ойн ашиглалтыг оновчтой болгогч нь гэмтээхгүй гэж шийдсэн бол хамгийн их утга нь таныг солихоос хэмнэх болно ....

3) Маш чухал цэг - IHMO нь бүх гүйлгээний системд 1-д тохируулагдсан байх ёстой. Нэгдүгээрт, энэ нь 1 хүсэлтийг гүйцэтгэх гэж оролдсон янз бүрийн процессуудын хоорондох зарим түгжигдэхээс сэргийлж, улмаар биднийг зарим "хачин" алдаанаас авардаг. Хоёрдугаарт... 1 "алах" хүсэлт нь серверийн бүх нөөцийг авах боломжтой болох бөгөөд энэ нь системийн бусад хэрэглэгчидтэй харьцахдаа зарим талаараа шударга бус юм.Параметр өөрөө 1 хүсэлтийг хэдэн процессорын цөм боловсруулахыг тодорхойлдог.

5) Статистик болон процедурын кэшийг цэвэрлэх тухай - энэ нь "чихээр" боловч бид дахин индексжүүлэх талаар мартдаг. Үүний зэрэгцээ энэ журам нь маш чухал бөгөөд ялангуяа мэдээллийн сангийн хэмжээ нэмэгдэх тусам түүний ач холбогдол нэмэгддэг. Заримдаа индексийн хуваагдал дээр гүйцэтгэлийн 60 хүртэлх хувь нь алдагддаг.

7) Хэрэв танд Hardware Accelerator эсвэл өөр өөр хандалтын хурдтай 2 диск байгаа бол өгөгдлийн сан дахь файлын бүлгүүдийг хуваарилж, тусдаа хүснэгтүүдийг өөр өөр хандалтын хугацаатай өөр өөр дискний массив болгон хуваахыг зөвлөж байна. Эцсийн эцэст, "Агуулахад байгаа бараа" PH ба "Нэмэлт мэдээлэл хадгалах" лавлагаа нь хадгалахад тавигдах шаардлага нь үндсэндээ өөр 2 объект гэдэгтэй та санал нийлэх болно. Өгөгдлийн санд байгаа бүх файл, зургийг хурдан массив дээр хадгалах шаардлагагүй - та үүнийг тусад нь салгаж болно, тийм ч хурдан биш, гэхдээ маш их зайтай газар (мөн олон тооны файл байршуулахаас бүү ай. файлуудыг дараа нь мэдээллийн сан руу оруулна.