Hammaga salom! Yaqinda men hujjatni qayta ishlash uchun uzoq vaqt talab qiladigan muammoga duch keldim.

Kirish ma'lumotlari: "Ishlab chiqarish korxonalarini boshqarish, 1.3 nashri (1.3.52.1)" konfiguratsiyasi, "Kirish to'lov topshirig'i" hujjati. Shikoyat: ishchi ma'lumotlar bazasida ushlab turish 20-30 soniya davom etadi, bu qiziq, ma'lumotlar bazasi nusxasida xuddi shu hujjat 2-4 soniya davomida saqlanadi. Quyidagi tekshiruvlar va bu xatti-harakatlarning sabablari haqida o'qing.

Shunday qilib, yordam bilan ishlashni o'lchash O'ylaymanki, hamma uni qanday ishlatishni biladi, aybdor topildi:

Bunday holda, yozgichda bo'sh yozuvlar to'plami qayd etilgan, boshqacha qilib aytganda, bajarilishdan oldin harakatlar o'chirilgan. Shunisi e'tiborga loyiqki, ushbu protsedura 26 marta chaqirilgan, ya'ni. hujjatimiz yozishi mumkin bo'lgan har bir registr uchun.

Ishlash o'lchovlariga ko'ra, bu operatsiya 13 soniya davom etdi; agar siz o'rtacha hisoblasangiz, har bir registr uchun 0,5 soniya olasiz, abadiylik!

Hammamizga ma'lumki, biz yozib olishni optimallashtira olmaymiz, lekin bu erda xatolik borligi aniq.
Qo'shimcha tahlil qilish uchun oching SQL Server Profiler Va . Tahlil qilish uchun men voqea darslaridan foydalandim:

• Namoyish rejasi statistikasi profili
• XML statistikasi profilini ko'rsatish
• RPC tugallandi
• SQL: To'plam tugallandi.

Kuzatuv sozlamalarida mavjud SPID tomonidan filtrlash:

SPID - ma'lumotlar bazasi serverining jarayon identifikatori. 1C holatida, bu 1C serveri va ma'lumotlar bazasi o'rtasidagi aloqadir, uni 1C serverlarining boshqaruv konsolida "DBMSga ulanish" ustunida ko'rishingiz mumkin.

Agar ko'rsatiladi bu daqiqa ma'lumotlar bazasiga ulanish seans tomonidan ushlanadi: yo DBMS qo'ng'irog'i amalga oshirilmoqda yoki tranzaktsiya ochiq yoki kamida bitta vaqtinchalik jadval yaratilgan "Vaqtinchalik jadval menejeri" ob'ekti saqlanadi.

Keling, SPIDni saqlash uchun ishlov berishni yozaylik, unda bitta protsedura bo'ladi:

O'tkazilayotgan ulanish ob'ekti, bizning holatlarimizda vaqtinchalik jadval menejeri, ishlov beruvchi o'zgaruvchi sifatida aniqlanishi muhimdir. Biz qayta ishlashni ochamiz, protsedurani bajaramiz va u ochiq ekan, SPID tuzatiladi. 1C server boshqaruv konsolini oching:

Shunday qilib, SPID olindi, biz uning qiymatini filtrga kiritamiz va sessiyamiz uchun joriy ishchi ma'lumotlar bazasidan iz olamiz. Izni tahlil qilishda 11 soniya davom etgan operatsiya aniqlandi:

Ko'zimni tortgan narsa o'qishlar soni edi - 1872578 , lekin men bunga darhol ahamiyat bermadim va bu erda nima qilinayotganini va qaysi stol bilan ishlayotganini aniqlay boshladim.

exec sp_executesql <= @P2) AND (T1._Fld1466RRef = @P3)) OR ((T1._Period <= @P4) AND (T1._Fld1466RRef = @P5))) OR ((T1._Period <= @P6) AND (1=0)))’,N’@P1 varbinary(16),@P2 datetime2(3),@P3 varbinary(16),@P4 datetime2(3),@P5 varbinary(16),@P6 datetime2(3)’,0x8A2F00155DBF491211E87F56DD1A416E,’4018-05-31 23:59:59′,0x00000000000000000000000000000000,’4018-05-31 23:59:59′,0x9A95A0369F30F8DB11E46684B4F0A05F,’4018-05-31 23:59:59"

SQL so'rovidan ko'rinib turibdiki, jadval qayta ishlanadi "AccRg1465" Bu o'z-o'zidan qo'llab-quvvatlanadigan buxgalteriya registridagi jadval. So'rovni bajarish rejasining matnli ko'rinishi:

SQL so'rovini bajarish rejasidan ko'rinib turibdiki, hech qanday yomon narsa bo'lmaydi, jadval " AccRg1465", klasterli indeks qidiruvi hamma joyda qo'llaniladi.

Grafik rejada men ham noto'g'ri narsani ko'rmadim, garchi u menga juda shishgan bo'lib tuyuldi - hech qanday sababsiz birlashish va ikkita ichki halqa bor edi. Bu o'qishlar soni va ulkan ijro vaqti qayerdan keladi?

Yuqorida ta'kidlab o'tilganidek, muammo ma'lumotlar bazasining yangi nusxasida ko'rsatilmagan; nusxa ishchi ma'lumotlar bazasidan muammo paydo bo'lgandan keyin olingan, shuning uchun uning SQL Server Profiler-da xuddi shu hujjatdagi xatti-harakatlarini tahlil qilishga qaror qilindi.
Mana natijalar:

SQL da so'rov matni:

EXEC sp_executesql N"TOP 1 0x01 DBO._AccRg1465 T1 QAYERDAN TANGLANING (T1._RecorderTRef = 0x0000022D VA T1._RecorderRRef = @P1) VA ((((T1._Period)<= @P2) AND (T1._Fld1466RRef = @P3)) OR ((T1._Period <= @P4) AND (T1._Fld1466RRef = @P5))) OR ((T1._Period <= @P6) AND (1=0)))" , N"@P1 varbinary(16),@P2 datetime2(3),@P3 varbinary(16),@P4 datetime2(3),@P5 varbinary(16),@P6 datetime2(3)", 0x8A2F00155DBF491211E87F56DD1A416E, "4018-05-31 23:59:59" ,00, "4018-05-31 23:59:59" , 0x9A935A04601F1D460F1 1 8-05-31 23:59:59"

So'rovlar rejasining grafik ko'rinishi:

So'rov matnlari bir xil, ijro rejalari tubdan farq qiladi. Gap nima bo'lishi mumkin? Men SQl-dagi statistika haqida xato qildim, lekin ular ma'lumotlar bazasining ishlashi va nusxasi o'rtasida bir xil va statistika har bir jadval uchun ma'lumotlar bazasida saqlanadi:

Keling, batafsilroq tahlil qilaylik: agar statistika bir xil bo'lsa, lekin so'rovlar rejalari boshqacha bo'lsa, demak, optimallashtiruvchi so'rovlar rejasini tuzish uchun statistikaga kira olmaydi, lekin u foydalanadigan keshlangan rejaga ega. Biz ma'lumotlar bazamizdagi protsessual keshni tozalaymiz, buning uchun biz buyruqdan foydalanamiz

DBCC FLUSHPROCINDB(< database_id >)

Qayerda< database_id >ma’lumotlar bazasi identifikatori hisoblanadi. Ma'lumotlar bazasi identifikatorini bilish uchun siz skriptni ishga tushirishingiz kerak

sys dan nom, database_id ni tanlang. ma'lumotlar bazalari

u bizga ma'lumotlar bazalari ro'yxatini va ularning identifikatorlarini qaytaradi.

Biz yana izni olamiz:

So'rovlar rejasining matnli ko'rinishi:

So'rovlar rejasining grafik ko'rinishi:

Ko'rib turganingizdek, so'rovlar rejasi optimallashtiruvchi tomonidan qayta olindi va eski keshlanganidan foydalanilmadi, bajarish vaqti, o'qishlar soni kabi normal holatga qaytdi. Bunga nima sabab bo'lganligi aniq emas, ehtimol katta miqdordagi almashinuv yoki oldingi davrlarning yopilishi, aytish qiyin. Muntazam ma'lumotlar bazasiga texnik xizmat ko'rsatish sozlangan. Men keshlangan so‘rovlarni bajarish rejasi firibgarligiga birinchi marta duch keldim.

E'tiboringiz uchun rahmat!

Ushbu maqola sizga yordam berdimi?

6 ta javob

Sizning sharoitingizga bog'liq bo'lgan ijro rejasini olishning bir necha yo'li mavjud. Odatda rejani olish uchun SQL Server Management Studio dasturidan foydalanishingiz mumkin, ammo agar biron sababga ko'ra so'rovingizni SQL Server Management Studio'da bajara olmasangiz, rejani SQL Server Profiler orqali yoki rejani tekshirish orqali olish foydali bo'lishi mumkin. kesh.

1-usul - SQL Server Management Studio dasturidan foydalanish

SQL Server ijro rejasini yig'ishni osonlashtiradigan ba'zi qulay xususiyatlarga ega, shunchaki "Haqiqiy ijro rejasini qo'shish" menyu bandi (So'rovlar menyusida joylashgan) belgilanganligiga ishonch hosil qiling va sizniki odatdagidek ishlaydi.

Agar siz saqlangan protseduradagi bayonotlar uchun ijro rejasini olishga harakat qilsangiz, saqlangan protsedurani quyidagi kabi bajarasiz:

Exec p_Misol 42

So'rovingiz tugagach, natijalar panelida qo'shimcha Ijro rejasi yorlig'ini ko'rasiz. Agar siz koʻplab tasdiqlovlarni ishga tushirgan boʻlsangiz, ushbu yorliqda koʻplab rejalarni koʻrishingiz mumkin.

Bu yerda siz SQL Server Management Studio dasturida bajarilish rejasini tekshirishingiz yoki rejani sichqonchaning o‘ng tugmasi bilan bosib, rejani XML fayliga saqlash uchun “Ijro rejasini boshqa saqlash...” ni tanlashingiz mumkin.

2-usul - SHOWPLAN Options-dan foydalanish

Bu usul 1-usulga juda o'xshaydi (aslida bu SQL Server Management Studio ichki bajaradigan narsa), lekin men uni to'liqlik uchun kiritdim yoki agar sizda SQL Server Management Studio mavjud bo'lmasa.

So'rovni bajarishdan oldin, ishga tushiring bitta quyidagi operatorlar. Bayonot paketdagi yagona bayonot bo'lishi kerak, ya'ni. Siz bir vaqtning o'zida boshqa bayonotni bajara olmaysiz:

SET SHOWPLAN_TEXT ON SHOWPLAN_ALL SET SHOWPLAN_XML ON SET STATISTICS PROFINI ON SET STATISTICS XML ON -- Foydalanish uchun tavsiya etilgan variant.

Bu ulanish parametrlari, shuning uchun har bir ulanish uchun buni faqat bir marta ishga tushirishingiz kerak. Bundan buyon barcha boshlangan bayonotlar bilan birga bo'ladi qo'shimcha natijalar to'plami kerakli formatdagi ijro rejangizni o'z ichiga oladi - rejani ko'rish uchun odatdagidek so'rovingizni bajaring.

Tugatganingizdan so'ng, ushbu parametrni quyidagi bayonot bilan o'chirib qo'yishingiz mumkin:

SET<> OFF

Bajarish rejasi formatlarini solishtirish

Agar sizda kuchli afzallik bo'lsa, STATISTICS XML variantidan foydalanishni tavsiya qilaman. Ushbu parametr SQL Server Management Studio'da "Haqiqiy ijro rejasini qo'shish" opsiyasiga teng bo'lib, eng foydali formatda eng ko'p ma'lumotlarni taqdim etadi.

• SHOWPLAN_TEXT - so'rovni bajarmasdan asosiy matnga asoslangan taxminiy bajarish rejasini ko'rsatadi
• SHOWPLAN_ALL - so'rovni bajarmasdan, xarajat smetasi bilan taxminiy matnga asoslangan ijro rejasini ko'rsatadi
• SHOWPLAN_XML - XML-ga asoslangan taxminiy ijro rejasini so'rovni bajarmasdan xarajatlar smetasi bilan ko'rsatadi. Bu SQL Server Management Studio'da "Misol ijro rejasini ko'rsatish..." opsiyasiga teng.
• STATISTIKA PROFILI - so'rovni bajaradi va matn asosida haqiqiy bajarish rejasini ko'rsatadi.
• STATISTICS XML - so'rovni bajaradi va XML asosidagi haqiqiy ijro rejasini ko'rsatadi. Bu SQL Server Management Studio'da "Haqiqiy ijro rejasini qo'shish" opsiyasiga teng.

3-usul - SQL Server Profiler-dan foydalanish

Agar siz soʻrovni toʻgʻridan-toʻgʻri bajara olmasangiz (yoki soʻrovingiz toʻgʻridan-toʻgʻri bajarilganda sekin ishlamasa – esda tutingki, biz soʻrov rejasi yomon ishlashini xohlaymiz), u holda rejani SQL Server Profiler yordamida yozib olishingiz mumkin. G'oya "Showplan" voqealaridan birini ushlaydigan iz ishlayotgan vaqtda so'rovingizni bajarishdir.

E'tibor bering, yukingizga qarab Siz .. qila olasiz; siz ... mumkin ushbu usulni ishlab chiqarish muhitida qo'llang, ammo ehtiyot bo'lishingiz kerak. SQL Serverning profillash mexanizmlari ma'lumotlar bazasiga ta'sirni minimallashtirish uchun ishlab chiqilgan, ammo bu ishlashga ta'sir qilmaydi degani emas. Agar ma'lumotlar bazasidan yuqori darajada foydalanilgan bo'lsa, filtrlash va izingizdagi to'g'ri rejani aniqlashda muammolarga duch kelishingiz mumkin. Siz o'zingizning qimmatli ma'lumotlar bazasiga buni qilganingizdan mamnun ekanliklariga ishonch hosil qilish uchun DBA bilan tekshirishingiz kerak!

• SQL Server Profiler dasturini oching va izni yozmoqchi bo'lgan kerakli ma'lumotlar bazasiga ulanadigan yangi iz yarating.
• Voqeani tanlash yorlig'ida "Barcha voqealarni ko'rsatish" katagiga belgi qo'ying, "Performance" -> Showplan XML qatorini belgilang va trekni ishga tushiring.
• Iz ishlayotganda, sekin so'rovni ishga tushirish uchun nima qilish kerak bo'lsa, hamma narsani bajaring.
• So'rov tugashini va kuzatish to'xtaguncha kuting.
• Izni saqlash uchun SQL Server profilidagi xml rejasini sichqonchaning o'ng tugmasi bilan bosing va rejani XML fayliga saqlash uchun "Voqealar ma'lumotlarini chiqarish..." ni tanlang.

Siz olgan reja SQL Server Management Studio'da "Haqiqiy ijro rejasini qo'shish" opsiyasiga teng.

4-usul - so'rov keshini tekshirish

Agar siz so'rovingizni to'g'ridan-to'g'ri ishga tushira olmasangiz va profiler izini ham qo'lga kirita olmasangiz, SQL so'rovining kesh rejasini tekshirish orqali taxminiy rejani olishingiz kerak bo'ladi.

SQL Server DMV-larini so'rash orqali reja keshini tekshiramiz. Quyida barcha keshlangan so'rov rejalari (xml sifatida) va ularning SQL matni ro'yxatini ko'rsatadigan asosiy so'rov mavjud. Ko'pgina ma'lumotlar bazalarida natijalarni sizni qiziqtirgan rejalarga filtrlash uchun qo'shimcha filtrlash shartlarini ham qo'shishingiz kerak bo'ladi.

UseCounts, Cacheobjtype, Objtype, TEXT, query_planni sys.dm_exec_cached_plans dan TANGLASH CROSS APPLY sys.dm_exec_sql_text(plan_handle) CROSS APPLY sys.dm_exec_query_plan(plan_handle)

Ushbu so'rovni bajaring va rejani yangi oynada ochish uchun XML rejasini bosing - rejani XML formatida faylga saqlash uchun sichqonchaning o'ng tugmachasini bosing va "Ijro rejasini boshqa saqlash ..." ni tanlang.

Eslatmalar:

Ko'p omillar mavjudligi sababli (jadval va indeks sxemasidan saqlangan ma'lumotlar va jadval statistikasigacha) Har doim Sizni qiziqtirgan ma'lumotlar bazasidan ijro rejasini olishga harakat qiling (odatda ishlash muammosiga duch kelgan).

Siz shifrlangan saqlangan protseduralar uchun ijro rejasini bajara olmaysiz.

"haqiqiy" va "taxminiy" ijro rejalari

Haqiqiy bajarish rejasi bu SQL Server so'rovni haqiqatda bajaradi, SQL Serverning taxminiy bajarish rejasi esa so'rovni bajarmasdan nima qilishi mumkinligi ustida ishlaydi. Mantiqiy jihatdan ekvivalent bo'lsa-da, amaldagi ijro rejasi ancha foydalidir, chunki u so'rov bajarilganda aslida nima sodir bo'lganligi haqida qo'shimcha ma'lumotlar va statistik ma'lumotlarni o'z ichiga oladi. Bu SQL server baholashlari o'chirilganda (masalan, statistik ma'lumotlar eskirganida) muammolarni tashxislashda muhim ahamiyatga ega.

So'rovni bajarish rejasini qanday izohlash mumkin?

Bu bepul kitob uchun etarli mavzu.

Ba'zida allaqachon e'lon qilingan keng qamrovli javobga qo'shimcha ravishda, ma'lumot olish uchun dasturli ravishda ijro rejasiga kirish imkoniyatiga ega bo'lish foydalidir. Buning uchun namuna kodi quyida keltirilgan.

E'lon qiling @TraceID INT EXEC StartCapture @@SPID, @TraceID OUTPUT EXEC sp_help "sys.objects" /*<-- Call your stored proc of interest here.*/ EXEC StopCapture @TraceID

So'rovlarni bajarish rejalarini olish va chuqur tahlil qilish uchun mening sevimli vositam SQL Sentry Plan Explorer. Bu SSMSga qaraganda ancha qulay, foydalanuvchilar uchun qulay va batafsil tahlil qilish va ijro rejalarini vizuallashtirish uchun to'liqroq.

Asbob qanday funksiyalarni taklif qilishini tushunishingiz uchun ekran misoli:

Bu asbobda mavjud ko'rinishlardan faqat bittasi. Ilova oynasining pastki qismidagi yorliqlar to'plamiga e'tibor bering, ular har xil turdagi ijro rejasi ko'rinishlarini va foydali qo'shimcha ma'lumotlarni olish imkonini beradi.

Bundan tashqari, men uning bepul versiyasida uni har kuni ishlatishingizga xalaqit beradigan yoki oxir-oqibat Pro versiyasini sotib olishga majbur qiladigan hech qanday cheklovlarni sezmadim. Shunday qilib, agar siz bepul versiyadan foydalanishni afzal ko'rsangiz, hech narsa taqiqlangan emas.

Oldingi javoblarda tasvirlangan usullardan tashqari, siz bepul ijro rejasini ko'ruvchi va so'rovlarni optimallashtirish vositasi ApexSQL Planidan ham foydalanishingiz mumkin (men yaqinda duch kelganman).

Siz ApexSQL rejasini SQL Server Management Studio-ga o'rnatishingiz va integratsiya qilishingiz mumkin, shuning uchun ijro rejalarini SSMS-dan to'g'ridan-to'g'ri ko'rish mumkin.

ApexSQL rejasida bashorat qilingan ijro rejalarini ko'ring

• Tugmasini bosing Yangi so'rov SSMS-da so'rov matnini so'rov matn maydoniga joylashtiring. Sichqonchaning o'ng tugmachasini bosing va kontekst menyusidan "Namunaviy ijro rejasini ko'rsatish" ni tanlang.

1. Bajarish rejasi diagrammasi natijalar bo'limida Ijroni rejalashtirish yorlig'ini ko'rsatadi. Keyin ijro rejasini o'ng tugmasini bosing va kontekst menyusidan "ApexSQL rejasida ochish" opsiyasini tanlang.

1. Taxminiy bajarilish rejasi ApexSQL rejasida ochiladi va so'rovlarni optimallashtirish uchun tahlil qilinishi mumkin.

ApexSQL rejasida haqiqiy ijro rejalarini ko'rish

Haqiqiy so'rovni bajarish rejasini ko'rish uchun yuqorida aytib o'tilgan ikkinchi bosqichga o'ting, ammo hozir, taxminiy reja paydo bo'lgach, ApexSQL rejasidagi asosiy lenta panelidagi "Haqiqiy" tugmasini bosing.

Haqiqiy tugmani bosgandan so'ng, haqiqiy ijro rejasi boshqa ijro rejasi ma'lumotlari bilan birga xarajatlar parametrlarining batafsil ko'rinishi bilan ko'rsatiladi.

Ijro rejalarini ko'rish haqida batafsil ma'lumotni ushbu havola orqali topishingiz mumkin.

So'rov rejalarini query_post_execution_showplan hodisasi orqali kengaytirilgan tadbirlar seansidan olish mumkin. XEvent seansiga misol:

/* "So'rovlar tafsilotlarini kuzatish" shablonlari orqali yaratilgan. */ SERVERDA VOQEA SESSIYANI YARATISH EVENT QO'SHISH sqlserver.query_post_execution_showplan(ACTION(package0.event_sequence,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash.sqlserver,qserversql_plan_hash.ssqserver,sqlserver.ext) er.tsql_ frame,sqlserver.tsql_stack)), / * Xohlaganingizdek, quyidagi hodisalardan birini olib tashlang (yoki qo'shimcha hodisalarni qo'shing). */ HOQIYo'NI QO'SHISH sqlserver.error_reported(ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.query_plan_serversh,sqlserver.query_plan_serversh,q qlserver.t sql_frame,sqlserver.tsql_stack ) QERDA (.(.,(4)) VA .(.,(0)))), EVENT QO'SHISH sqlserver.module_end(SET collect_statement=(1) ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver) . plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack) QAYERDA (.(.,(4)() .EV,D) sqlserver.rpc_completed(ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.query_plan_hash,sqlserver.query_plan_hash,sqlserver.extertsqserversqserversqserversqserver,sqlserver.client_app_name,sqlserver.database_id _ frame,sqlserver.tsql_stack) QAYERDA (. ( .,(4)) VA .(.,(0))), EVENT QO'SHISH sqlserver.sp_statement_completed(SET collect_object_name=(1) ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserverer,sqlserver. query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack) QAYERDA (.(.,(4)) VA .(.,(0))), ADsql_batted(ENT) ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.session_id,sqlserver.sqlserver.sql.sql. _st ack) QAYERDA (.(.,() 4 )) VA .(.,(0)))), EVENT QO‘SHISH sqlserver.sql_statement_completed(ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.database_id,sqlserver.plan_handle,sqlserver.plan_handle,sqlserver.plan_handle,sqlserver. sion_id , sqlserver.sql_text,sqlserver.tsql_frame,sqlserver.tsql_stack) QAYERDA (.(.,(4)) VA .(.,(0))) TARGET paketini0.ring_bufer QO'SHING (MAX_MEMORY=4096 KB,LESSENT_LOVENT_MOVENT_MOVENT_MOV=4096 KB DISPATCH_L ATENCY =30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=YO'Q,TRACK_CAUSALITY=ON,STARTUP_STATE=OFF) O'TISH

Seans yaratilgandan so'ng (SSMS da), Ob'ekt brauzeriga o'ting va Manage | ga o'ting Kengaytirilgan tadbirlar | Seanslar. "GetExecutionPlan" sessiyasini o'ng tugmasini bosing va uni ishga tushiring. Uni o'ng tugmasini bosing va "Jonli ma'lumotlarni tomosha qilish" -ni tanlang.

Keyin yangi so'rovlar oynasini oching va bir yoki bir nechta so'rovlarni bajaring. AdventureWorks uchun bitta:

AdventureWorks dan foydalanish; Mahsulot nomi sifatida p.Name ni tanlang, chegirmasiz sotuvlar = (Buyurtma miqdori * birlik narxi), chegirmalar = ((Buyurtma miqdori * birlik narxi) * birlik narx chegirmasi) ishlab chiqarishdan.Mahsulot AS P ICHKI QO‘SHILING Sales.Sod.OrderDetail AS sod ID =pORDID.Product. Mahsulot nomi DESC; BOSH

Bir yoki ikki daqiqadan so'ng siz "GetExecutionPlan: Live Data" yorlig'ida ba'zi natijalarni ko'rasiz. To‘rdagi query_post_execution_showplan voqealaridan birini tanlang, so‘ngra panjara ostidagi So‘rovlar rejasi yorlig‘ini bosing. Bu shunday ko'rinishi kerak:

EDIT: XEvent kodi va skrinshot SQL/SSMS 2012 w/SP2 dan yaratilgan. Agar siz SQL 2008/R2 dan foydalanayotgan bo'lsangiz, uni ishga tushirish uchun skriptni o'rnatishingiz mumkin. Ammo bu versiyada GUI yo'q, shuning uchun siz showplan XML faylini chiqarib, *.sqlplan fayli sifatida saqlashingiz va SSMSda ochishingiz kerak bo'ladi. Bu og'ir. XEvents SQL 2005 yoki undan oldingi versiyalarida mavjud emas edi. Shunday qilib, agar siz SQL 2012 yoki undan keyingi versiyada bo'lmasangiz, men bu erda e'lon qilingan boshqa javoblardan birini tavsiya qilaman.

baham ko'ring

SQL Server 2005 da soʻrovlarni optimallashtirish, SQL Server 2005 maʼlumotlar bazasi statistikasi, STATISTIKA YARATISH, STATISTIKANI YANGILASH, NO COUNT YOQISH, soʻrovlarni bajarish rejalari, mantiqiy oʻqishlar soni, optimallashtiruvchi maslahatlar, MAXDOP, OPTIMIZE UCHUN, oʻquv qoʻllanmalar rejasi (screate guides_),

Agar unumdorlikni optimallashtirishning boshqa barcha usullari allaqachon tugagan bo'lsa, SQL Server ishlab chiquvchilari va ma'murlari o'zlarining ixtiyorida so'nggi zaxiraga ega - individual so'rovlarning bajarilishini optimallashtirish. Misol uchun, agar sizning vazifangiz bitta aniq hisobotni yaratishni tezlashtirishni talab qilsa, siz ushbu hisobotni yaratish uchun ishlatiladigan so'rovni tahlil qilishingiz va agar u maqbul bo'lmasa, uning rejasini o'zgartirishga harakat qilishingiz mumkin.

Ko'pgina mutaxassislar so'rovlarni optimallashtirishga noaniq munosabatda bo'lishadi. Bir tomondan, so'rovlarni bajarish rejalarini yaratuvchi Query Optimizer dasturiy modulining ishlashi SQL Server 2000 va SQL Server 2005 da ko'plab adolatli tanqidlarga sabab bo'ladi. Oracle va Informix-dan shunga o'xshash modullarga. Boshqa tomondan, qo'lda so'rovlarni optimallashtirish juda ko'p mehnat talab qiladigan jarayondir. Siz bunday optimallashtirishga ko'p vaqt sarflashingiz mumkin va oxir-oqibat, hech narsa optimallashtirilmaganligini bilib olishingiz mumkin: Query Optimizer tomonidan dastlab taklif qilingan reja eng maqbul bo'lib chiqdi (bu ko'p hollarda sodir bo'ladi). Bundan tashqari, bir muncha vaqt o'tgach (ma'lumotlar bazasiga yangi ma'lumot qo'shgandan keyin) qo'lda yaratgan so'rovlarni bajarish rejasi suboptimal bo'lib chiqishi va so'rovlarni bajarishda unumdorlikni pasaytirishi mumkin.

Shuni ham yodda tutingki, Query Optimizer eng yaxshi so'rov rejalarini tanlash uchun to'g'ri statistik ma'lumotni talab qiladi. Muallifning tajribasiga ko'ra, hamma ma'murlar nima ekanligini bilishmaydi, biz sizga statistika haqida ko'proq ma'lumot beramiz.

Statistika- bu jadval ustunlaridagi ma'lumotlarni taqsimlash haqida maxsus xizmat ma'lumotlari. Tasavvur qilaylik, masalan, Sankt-Peterburg shahrida yashovchi barcha Ivanovlarni qaytarish kerak bo'lgan so'rov bajarilmoqda. Faraz qilaylik, ushbu jadvaldagi yozuvlarning 90% ustunida bir xil qiymatga ega Shahar - "Sankt-Peterburg". Albatta, so'rovlarni bajarish nuqtai nazaridan, birinchi navbatda jadvaldagi barcha Ivanovlarni tanlash foydaliroqdir (ular aniq 90% bo'lmaydi), so'ngra ustun qiymatini tekshiring. Shahar har bir tanlangan yozuv uchun. Biroq, ustundagi qiymatlar qanday taqsimlanganligini bilish uchun avval so'rovni bajarishingiz kerak. Shuning uchun SQL Server mustaqil ravishda bunday so'rovlarni bajarishni boshlaydi va keyin ma'lumotlarning taqsimlanishi haqidagi ma'lumotlarni (bu statistika deb ataladi) ma'lumotlar bazasining xizmat jadvallarida saqlaydi.

SQL Server 2005 ma'lumotlar bazalari uchun standart sozlamalar mavjud AUTO_CREATE_STATISTICS Va AUTO_UPDATE_STATISTICS. Bunday holda, ma'lumotlar bazasi ustunlari uchun statistika avtomatik ravishda yaratiladi va yangilanadi. Eng katta va eng muhim ma'lumotlar bazalari uchun statistikani yaratish va yangilash operatsiyalari joriy foydalanuvchi tajribasiga xalaqit berishi mumkin. Shuning uchun, bunday ma'lumotlar bazalari uchun ba'zan bu parametrlar o'chiriladi va statistikani yaratish va yangilash operatsiyalari tunda qo'lda amalga oshiriladi. Buning uchun ishlatiladigan buyruqlar STATISTIKA YARATING Va STATISTIKANI YANGILASH.

Endi so'rovlarni optimallashtirish haqida gapiraylik.

Qilish kerak bo'lgan birinchi narsa, birinchi navbatda optimallashtirishga tobe bo'lgan so'rovlarni topishdir. Buni qilishning eng oson yo'li - so'rovning davomiyligi uchun filtrni o'rnatish (filtr) Davomiyligi derazada TahrirlashFiltr(Fitrni tahrirlash), bu tugma yordamida ochilishi mumkin UstunFiltrlar tabda VoqealarTanlash seans xususiyatlarini kuzatish oynasi). Masalan, optimallashtirish uchun nomzodlar bajarilish vaqti 5 soniyadan ortiq bo'lgan so'rovlarni o'z ichiga olishi mumkin. Ma'lumotlar bazasini sozlash bo'yicha maslahatchi tomonidan taqdim etilgan so'rov ma'lumotlaridan ham foydalanishingiz mumkin.

Keyin ulanishlar, saqlangan protseduralar va funktsiyalar uchun parametr o'rnatilganligini tekshirishingiz kerak NOCOUNT. Siz uni buyruq yordamida o'rnatishingiz mumkin NO COUNT NI YOQING. Ushbu parametrni o'rnatishda, birinchi navbatda, serverdan qaytish va so'rov natijalaridagi qatorlar soni haqidagi ma'lumotni ko'rsatish o'chiriladi (ya'ni qator). "N qator(lar)ga ta'sir qildi" tabda Xabarlar(C xabarlari) Management Studio'da so'rovni bajarishda kod bilan ishlash uchun oynalar). Ikkinchidan, maxsus server xabarini uzatish o'chirilgan DONE_IN_PROC, har bir saqlangan protsedura bosqichi uchun sukut bo'yicha qaytariladi. Ko'pgina saqlangan protseduralarni chaqirishda sizga faqat ularning bajarilishi natijasi kerak bo'ladi va hech kim har bir bosqich uchun qayta ishlangan qatorlar soniga e'tibor bermaydi. Shuning uchun, parametrni o'rnating NOCOUNT saqlangan protseduralar uchun ularning ish faoliyatini sezilarli darajada yaxshilash mumkin. Muntazam so'rovlarni bajarish tezligi ham oshadi, lekin kamroq darajada (10% gacha).

Shundan so'ng siz so'rovlarni bajarish rejalari bilan ishlashni boshlashingiz mumkin.

So'rovni bajarish rejasini ko'rishning eng oson yo'li SQL Server Management Studio'dan. Kutilayotgan so'rovni bajarish rejasi haqida ma'lumot olish uchun siz menyudan foydalanishingiz mumkin So'rov(So'rov) tanlash buyrug'i DispleyHisoblanganIjroReja(Kutilayotgan ijro rejasini ko'rsatish). Agar so'rovni bajarishning haqiqiy rejasini bilmoqchi bo'lsangiz, uni bajarishdan oldin parametrni o'sha menyuda o'rnatishingiz mumkin. O'z ichiga oladiHaqiqiyIjroReja(Haqiqiy ijro rejasini o'z ichiga oladi). Bunday holda, so'rovni bajargandan so'ng, SQL Server Management Studio'da natijalar oynasida boshqa yorliq paydo bo'ladi. IjroReja(Ijro rejasi), u haqiqiy so'rovni bajarish rejasini ko'rsatadi. Sichqonchani har qanday bosqich ustiga olib borganingizda, bu haqda qo'shimcha ma'lumot olishingiz mumkin (11.15-rasm).

Guruch. 11.15. SQL Server Management Studio'da so'rovlarni bajarish rejasi

So'rovni bajarish rejasida, rasmda ko'rib turganingizdek, ko'plab elementlar bo'lishi mumkin. Ularni tushunish, shuningdek, boshqa ijro rejasini taklif qilish juda qiyin vazifadir. Aytish kerakki, mumkin bo'lgan elementlarning har biri o'z sharoitida optimaldir. Shuning uchun odatda so'rovlarni optimallashtirish bosqichlari quyidagicha ko'rinadi:

q Birinchidan, Management Studio oynasida buyruqni bajaring STATISTIKA IO YOQISH. Natijada, so'rovning har bir bajarilishidan keyin qo'shimcha ma'lumotlar ko'rsatiladi. Unda bizni faqat bitta parametrning qiymati qiziqtiradi - Mantiqiy o'qishlar. Bu parametr so'rovlarni bajarishda mantiqiy o'qishlar sonini, ya'ni keshning ta'sirini (keshdan ham, diskdan ham o'qishlar soni) hisobga olmagan holda berilgan so'rovni bajarishda qancha o'qish operatsiyalarini bajarish kerakligini anglatadi. Bu eng muhim parametr. Jismoniy o'qishlar soni (faqat diskdan o'qiladi) unchalik vakillik ma'lumoti emas, chunki bu jadvallarga oldingi kirishlar mavjudmi yoki yo'qligiga bog'liq. Vaqt statistikasi ham o'zgaruvchan va server o'sha paytda bajaradigan boshqa operatsiyalarga bog'liq. Ammo mantiqiy o'qishlar soni eng ob'ektiv ko'rsatkich bo'lib, unga qo'shimcha omillar eng kam ta'sir qiladi;

q keyin so'rovni bajarish rejasini o'zgartirishga harakat qiling va har bir reja uchun mantiqiy o'qishlarning umumiy sonini bilib oling. Odatda, so'rovni bajarish rejasi optimallashtiruvchi maslahatlar yordamida o'zgartiriladi. Ular optimallashtiruvchiga qaysi ijro rejasidan foydalanishni aniq aytib berishadi.

SQL Server 2005 da optimallashtirish bo'yicha ko'plab maslahatlar mavjud. Siz ular haqida ma'lumotni Books Online-da o'qishingiz mumkin (yorliqdagi ro'yxatda Indeks(indeks) tanlanishi kerak So'rovMaslahatlar [SQLServer](So'rov bo'yicha maslahatlar), Qo'shilishMaslahatlar(Maslahatlarga qo'shilish) yoki JadvalMaslahatlar [SQLServer](Jadval bo'yicha maslahatlar)). Eng ko'p ishlatiladigan maslahatlar:

q NOLOCK, ROWLOCK, PAGLOCK, TABLOK, QULFLANISH, READCOMMITTEDLOCK, UPDLOCK, XLOCK- bu maslahatlar qulflarni boshqarish uchun ishlatiladi (11.5.7 bo'limga qarang);

q TEZ qatorlar soni - so'rovni bajarish rejasi tanlanadi, unda belgilangan qatorlar soni (yozuvlar to'plamining boshidan birinchisi) imkon qadar tezroq ko'rsatiladi. Agar foydalanuvchi aniq birinchi yozuvlarga muhtoj bo'lsa (masalan, so'nggi buyurtmalar), unda bu maslahat ularni iloji boricha tezroq dastur oynasiga yuklash uchun ishlatilishi mumkin;

q MAJBUR TARTIBI- so'rovni bajarishda jadvallarni birlashtirish aynan shu jadvallar so'rovda ro'yxatga olingan tartibda amalga oshiriladi;

q MAXDOP(Maksimum Parallelizm darajasidan - so'rovni parallellashtirishning maksimal darajasi) - bu maslahat yordamida so'rovni bajarish uchun ishlatilishi mumkin bo'lgan protsessorlarning maksimal soni ko'rsatilgan. Odatda bu maslahat ikki holatda qo'llaniladi:

· protsessorlar o'rtasida almashish tufayli ( kontekstalmashtirish) so'rovni bajarish tezligi ancha kamayadi. Ushbu xatti-harakatlar ko'p protsessorli tizimlarda SQL Server 2000 uchun odatiy hol edi;

· Agar ba'zi og'ir so'rovlar joriy foydalanuvchi tajribasiga minimal ta'sir ko'rsatishini xohlasangiz;

q UCHUN OPPTIMIZLASH- bu maslahat so'rov unga berilgan parametrning ma'lum bir qiymati uchun optimallashtirilganligini belgilash imkonini beradi (masalan, filtr qiymati uchun QAYERDA);

q REJA FOYDALANISH- bu eng kuchli imkoniyat. Bunday maslahatdan foydalanib, rejani XML formatida satr qiymati sifatida o'tkazish orqali so'rovni bajarish rejasini aniq belgilashingiz mumkin. Maslahat REJA FOYDALANISH faqat SQL Server 2005 da paydo bo'lgan (oldingi versiyalarda so'rovlarni bajarish rejalarini aniq belgilash mumkin edi, lekin bu boshqa vositalar yordamida amalga oshirildi). XML formatidagi reja qo'lda yozilishi yoki avtomatik tarzda yaratilishi mumkin (masalan, 11.15-rasmda ko'rsatilgan ijro rejasi bilan grafik ekranga sichqonchaning o'ng tugmachasini bosish va kontekst menyusidagi buyruqni tanlash orqali) SaqlashIjroRejaSifatida(Ijro rejasini shunday saqlang)).

SQL Server 2005 so'rov matnini o'zgartirmasdan so'rovni bajarish rejasini qo'lda o'zgartirish imkonini beruvchi muhim yangi xususiyatni taqdim etadi. Ko'pincha so'rov kodini o'zgartirib bo'lmaydi: u kompilyatsiya qilingan dasturning kodiga ulangan. Ushbu muammoni hal qilish uchun SQL Server 2005 saqlangan protsedurani taqdim etdi sp_create_plan_guide. Bu sizga deb atalmish yaratish imkonini beradi Amalga oshirish rejasi bo'yicha qo'llanmalar (rejaqo'llanmalar), mos keladigan so'rovlarga avtomatik ravishda qo'llaniladi.

Agar siz dastur tomonidan ma'lumotlar bazasiga yuborilgan so'rovlarni tahlil qilayotgan bo'lsangiz, birinchi navbatda quyidagi fikrlarga e'tibor berish mantiqan to'g'ri keladi:

q so'rovni bajarish rejalarida operatsiya qanchalik tez-tez paydo bo'lishi JadvalSkanerlash(To'liq jadvalni skanerlash). Ko'rinib turibdiki, indekslar yordamida jadvalga kirish samaraliroq bo'ladi;

q kodda kursorlardan foydalaniladimi. Kursorlar dastur sintaksisi jihatidan juda oddiy, lekin unumdorligi jihatidan nihoyatda samarasiz. Ko'pincha siz boshqa sintaktik konstruktsiyalar yordamida kursorlardan foydalanishdan qochishingiz va tezlikda katta daromad olishingiz mumkin;

q kod vaqtinchalik jadvallardan yoki ma'lumotlar turidan foydalanadimi Jadval. Vaqtinchalik jadvallarni yaratish va ular bilan ishlash juda ko'p resurslarni talab qiladi, shuning uchun iloji bo'lsa, ulardan qochish kerak;

q Vaqtinchalik jadvallarni yaratish bilan bir qatorda, ularning tuzilishini o'zgartirish tizim resurslarini sezilarli darajada sarflashni ham talab qiladi. Shuning uchun, vaqtinchalik jadvallar tuzilishini o'zgartirish buyruqlari darhol sizning e'tiboringizni jalb qilishi kerak. Odatda barcha kerakli ustunlar bilan vaqtinchalik jadvalni darhol yaratish mumkin;

q ba'zan so'rovlar ilovaga kerak bo'lganidan ko'proq ma'lumotni qaytaradi (qo'shimcha ustunlar yoki qatorlar). Albatta, bu hosildorlikni oshirmaydi;

q agar ilova serverga buyruqlar yuborsa IJRO ET, keyin ularni saqlangan protsedura chaqiruvi bilan almashtirish haqida o'ylash mantiqan sp_executesql. U oddiy buyruqqa nisbatan ishlash afzalliklariga ega IJRO ET;

q Ishlashni yaxshilashga ba'zan saqlangan protseduralarni qayta kompilyatsiya qilish va yangi so'rovlarni bajarish rejalarini yaratish zaruratini bartaraf etish orqali erishish mumkin. Siz parametrlardan foydalanishga e'tibor berishingiz kerak, saqlangan protsedura kodida DML va DDL buyruqlarini aralashtirmaslikka harakat qiling va ulanish parametrlari mos kelishiga ishonch hosil qiling. ANSI_DEFAULTS SOZLASH, ANSI_NULLS ni o'rnating, ANSI_PADDING SOZLASH, ANSI_WARNINGS ni o‘rnating Va CONCAT_NULL_YIELDS_NULL so'rovlar o'rtasida o'zgarmagan (bunday parametrlarga har qanday o'zgartirish eski ijro rejalarini bekor qiladi). Odatda, muammo ushbu parametrlar individual so'rov darajasida yoki saqlangan protsedura kodida o'rnatilganda paydo bo'lishi mumkin.

E'tibor bering, har qanday holatda ham so'rovlarni bajarish rejalarini qo'lda yaratish va maslahatlardan foydalanish oxirgi chora hisoblanadi va iloji bo'lsa, undan qochish kerak.

SQL so'rovlarini bajarish rejasi, yoki so'rovlar rejasi - bu SQL so'rovini bajarish uchun zarur bo'lgan qadamlar yoki DBMS ko'rsatmalari ketma-ketligi. Har bir bosqichda ushbu SQL so'rovini bajarish bosqichini boshlagan operatsiya yakuniy natijani yaratishi yoki keyingi qayta ishlash uchun ishlatilishi mumkin bo'lgan ma'lumotlar qatorini oladi. SQL so'rovlarini bajarish rejasi ko'rsatmalari SELECT, INSERT, SQL FOR DBMS tomonidan bajariladigan operatsiyalar ketma-ketligi sifatida ifodalanadi. o'chirish va yangilash. So'rovlar rejasining mazmuni odatda daraxt tuzilmasida ifodalanadi va quyidagi ma'lumotlarni o'z ichiga oladi:

• ma'lumotlar manbalarini ulash tartibi (jadvallar, ko'rinishlar va boshqalar);
• har bir ma'lumot manbasiga kirish usuli;
• ma'lumotlar manbalarini ulash usullari;
• ma'lumotlarni tanlash, saralash va umumlashtirishni cheklash operatsiyalari;
• har bir operatsiyaning narxi va jiddiyligi;
• bo'lish va parallellikdan foydalanish mumkin. SQL so'rovlarini bajarish rejasi tomonidan taqdim etilgan ma'lumotlar ishlab chiquvchiga optimallashtiruvchi SQL operatsiyalarini bajarish uchun qaysi yondashuv va usullarni tanlashini ko'rish imkonini beradi.

SQL so'rovlarini bajarish rejasini talqin qilish

SQL so'rovini bajarish rejasini vizualizatsiya qilish asboblar va ishlab chiqish vositalariga bog'liq bo'lib, ular so'rovi tahlil qilish uchun qiziqish uyg'otadigan DBMSning bir qismi bo'lishi mumkin yoki ma'lum bir DBMS bilan bevosita bog'liq bo'lmagan alohida tijorat yoki erkin tarqatiladigan dasturiy mahsulotlar bo'lishi mumkin. ishlab chiqaruvchi. Bir yoki boshqa so'rovlar rejasini vizualizatsiya qilish vositasidan foydalanish, odatda, taqdim etilgan so'rovlar rejasi tasvirlangan narsalarni idrok etishga sezilarli ta'sir ko'rsatmaydi. Muayyan so'rovni bajarishda optimallashtiruvchi qaysi yo'ldan borishini tahlil qilish jarayonida hal qiluvchi omil so'rovlar rejasida taqdim etilgan ma'lumotlarni to'g'ri talqin qilish qobiliyatidir.

Yuqorida aytib o'tilganidek, SQL so'rovlari rejasi nafaqat SQL operatsiyalarini bajarish ketma-ketligini, balki ushbu operatsiyalar o'rtasidagi munosabatlarni ham tavsiflovchi daraxt tuzilmasiga ega. So'rovlar rejasi daraxtidagi har bir tugun tartiblash yoki jadvalga kirish usuli kabi operatsiya hisoblanadi. Tugunlar o'rtasida ota-ona munosabatlari mavjud. Ota-onalar va bolalar munosabatlari quyidagi qoidalar bilan tartibga solinadi:

• ota-onaning bir yoki bir nechta farzandi bo'lishi mumkin;
• bolaning faqat bitta ota-onasi bor;
• ota-ona operatsiyasiga ega bo'lmagan operatsiya daraxtning tepasi;
• SQL so'rovlar rejasini vizualizatsiya qilish usuliga qarab, bola ota-onaga nisbatan ba'zi bir chekinish bilan joylashtirilgan. Bir ota-onaning avlodlari ota-onasidan bir xil masofada joylashgan.

Keling, SQL so'rovlarini bajarish rejasi tomonidan taqdim etilgan ma'lumotlarni batafsil ko'rib chiqaylik. Berilgan misollar Oracle DBMS muhitida bajarildi. Oracle SQL Developer so'rovlarni bajarish va SQL so'rovlar rejasini vizualizatsiya qilish uchun vosita sifatida ishlatilgan. SQL so'rov rejasining bir qismi rasmda ko'rsatilgan. 10.11.

I Id I Operation

• 0RDER_ITEMS

PR0DUCT_INF0RMATI0N_PK MAHSULOT HAQIDA MA'LUMOT

TANLASH TANLASH BAJORI TARTIBINI INDEX ROWID BO'YICHA INDEKS KO'LQARLAR BO'YICHA SARTALASH.

Guruch. 10.11. Oracle DBMS muhitida SQL so'rovlarini bajarish rejasining fragmenti

So'rovlar rejasi operatsiyalarining aloqa qoidalaridan foydalanib, ularning quyidagi rasmiy tavsifini belgilashimiz mumkin.

0-operatsiya so'rovlar rejasi daraxtining ildizidir. Ildizda bitta bola bor: 1-operatsiya.

Operatsiya 1 - operatsiya bitta bolaga ega: operatsiya 2.

2-operatsiya - operatsiyaning ikkita bolasi bor: 3-operatsiya va 6-operatsiya.

3-operatsiya - operatsiyaning ikkita bolasi bor: 4-operatsiya va 5-operatsiya.

Operatsiya 4 - operatsiyada bolalar yo'q.

Operatsiya 5 - operatsiyada bolalar yo'q.

Operatsiya 6 - operatsiyada bolalar yo'q.

So'rov rejasi operatsiyalari o'rtasidagi ota-ona va bolaning o'zaro ta'siri rasmda ko'rsatilgan. 10.12.

So'rovlar rejasida bajariladigan amallarni uch turga bo'lish mumkin: mustaqil, bog'lanmagan birlashma operatsiyalari va bog'langan birlashma operatsiyalari (10.13-rasm).

Avtonom		Bog'liq bo'lmagan operatsiyalar		Tegishli operatsiyalar
operatsiyalar		uyushmalar		uyushmalar

Guruch. 10.12.

Guruch. 10.13.

Avtonom operatsiyalar - Bular ko'pi bilan bitta bola operatsiyasi bo'lgan operatsiyalardir.

Avtonom operatsiyalarni bajarish uchun quyidagi qoidalarni quyidagicha shakllantirish mumkin.

• 2. Har bir bola operatsiyasi faqat bir marta bajariladi.
• 3. Har bir kichik operatsiya o'z natijasini asosiy operatsiyaga qaytaradi.

Shaklda. 10.14-rasmda quyidagi so'rovlar rejasi ko'rsatilgan:

Buyurtmalardan o.order_id ,o.order_status ni tanlang o BUYURTMA BY o.order_status

Ushbu so'rov faqat mustaqil operatsiyalarni o'z ichiga oladi.

Avtonom operatsiyalarga rioya qilish qoidalarini hisobga olgan holda, ularni bajarish ketma-ketligi quyidagicha bo'ladi.

• 1. 1-sonli avtonom operatsiyalarga amal qilish qoidasiga muvofiq birinchi navbatda ID = 2 bo'lgan operatsiya bajariladi.Buyurtmalar jadvalining barcha satrlari ketma-ket o'qiladi.
• 2. Keyin ID = 1 bilan amal bajariladi.ID = 2 bo'lgan operatsiya tomonidan qaytarilgan qatorlar ORDER BY saralash bandining shartlariga ko'ra tartiblanadi.
• 3. ID = 0 bo'lgan operatsiya bajariladi.Olingan ma'lumotlar to'plami qaytariladi.

Cheklanmagan ittifoq operatsiyalari

Cheklanmagan ittifoq operatsiyalari bir nechta mustaqil bajariladigan asosiy operatsiyalarga ega operatsiyalar. Misol: HASH JOIN, MERGE JOIN, CORISECTION, MINUS, UNION ALL.

Bog'lanmagan qo'shilish operatsiyalari ishlaydigan quyidagi qoidalarni quyidagicha shakllantirish mumkin.

• 1. Bola operatsiyasi ota-ona operatsiyasidan oldin bajariladi.
• 2. Child operatsiyalar ketma-ket bajariladi, bu qiymatlarning o'sish tartibida eng kichik operatsiya ID qiymatidan boshlab.
• 3. Har bir keyingi bola operatsiyasi boshlanishidan oldin joriy operatsiya to'liq bajarilishi kerak.
• 4. Har bir bola operatsiyasi boshqa bola operatsiyalaridan qat'iy nazar, faqat bir marta bajariladi.
• 5. Har bir kichik operatsiya o'z natijasini asosiy operatsiyaga qaytaradi.

Shaklda. 10.15-rasmda quyidagi so'rovlar rejasi ko'rsatilgan:

Buyurtmalardan o.order_id ni tanlang o UNION ALL

order_items oi dan oi.order_id ni tanlang

Ushbu so'rovda bog'lanmagan qo'shilish operatsiyasi mavjud UNION hammasi. Qolgan ikkita operatsiya avtonomdir.

Guruch. 10.15. Bog'lanmagan qo'shilish operatsiyalari, so'rovlar rejasi

	1 TANLANGAN BAJORI I

Bir-biriga bog'liq bo'lmagan qo'shilish operatsiyalariga rioya qilish qoidalarini hisobga olgan holda, ularni bajarish ketma-ketligi quyidagicha bo'ladi.

• 1. Quyidagi bog'liq bo'lmagan birlashma operatsiyalarining 1 va 2 qoidalariga muvofiq, birinchi bo'lib ID = 2 bilan operatsiya bajariladi.Buyurtmalar jadvalining barcha satrlari ketma-ket o'qiladi.
• 2. 5-qoidaga muvofiq, ID = 2 bo'lgan operatsiya 1-bosqichda o'qilgan ID = 1 bilan ota-ona operatsiyasining qatorlarini qaytaradi.
• 3. ID = 3 bo'lgan operatsiya ID = 2 bo'lgan operatsiya tugagachgina bajarila boshlaydi.
• 4. ID = 2 bilan operatsiya bajarilgandan so'ng ID = 3 bilan operatsiya boshlanadi. order_items jadvalining barcha qatorlari ketma-ket o'qiladi.
• 5. 5-qoidaga muvofiq, ID = 3 bo'lgan operatsiya 4-bosqichda o'qilgan ID = 1 bilan ota-operatsiya qatorlarini qaytaradi.
• 6. ID = 1 bilan operatsiya uning barcha asosiy operatsiyalaridan (ID = 2 va ID = 3 bilan) olingan ma'lumotlarga asoslangan ma'lumotlarning natija to'plamini hosil qiladi.
• 7. ID = 0 bo'lgan operatsiya bajariladi.Olingan ma'lumotlar to'plami qaytariladi.

Shunday qilib, shuni ta'kidlash mumkinki, mustaqil qo'shilish operatsiyasi o'zining pastki operatsiyalarini ketma-ket bajaradi.

Bog'langan qo'shilish operatsiyalari

Bog'langan qo'shilish operatsiyalari - Bular bir nechta asosiy operatsiyalarga ega bo'lgan operatsiyalar bo'lib, ulardan biri boshqalarining bajarilishini nazorat qiladi. Misol: ichki o'rnatilgan tsikllar, yangilash.

Zanjirlangan qo'shilish operatsiyalari ishlaydigan quyidagi qoidalarni quyidagicha shakllantirish mumkin.

• 1. Bola operatsiyasi ota-ona operatsiyasidan oldin bajariladi.
• 2. Eng past operatsiya raqami (ID) bo'lgan bola operatsiyasi qolgan qo'shimcha operatsiyalarning bajarilishini nazorat qiladi.
• 3. Umumiy ota-operatsiyaga ega bo'lgan qo'shimcha operatsiyalar ushbu qiymatlarning o'sish tartibida operatsiya identifikatorining eng past qiymatidan boshlab bajariladi. Qolgan asosiy amallar ketma-ket bajarilmaydi.
• 4. Faqat birinchi bola operatsiyasi bir marta bajariladi. Boshqa barcha bolalar operatsiyalari bir necha marta bajariladi yoki umuman bajarilmaydi.

Shaklda. 10.16-rasmda quyidagi so'rovlar rejasi ko'rsatilgan:

FROM order_items oi, buyurtmalar o

QAYERDA o.order_id= oi.order_id

VA oi.product_id>100

VA o.customer_id 100 dan 1000 gacha

Bu soʻrovda tegishli birlashma amali, NESTED LOOPS mavjud.

I Id I Operation

		TANLANGAN BAYOR |

Guruch. 10.16. Bog'langan qo'shilish operatsiyalari, so'rovlar rejasi

Zanjirlangan qo'shilish operatsiyalariga rioya qilish qoidalarini hisobga olgan holda, ularni bajarish ketma-ketligi quyidagicha bo'ladi.

• 1. Quyidagi zanjirli qo'shilish operatsiyalarining 1 va 2 qoidalariga ko'ra, ID = 2 bilan operatsiya birinchi bo'lib bajarilishi kerak, ammo 1D = 2 va 1D = 3 bilan operatsiyalar avtonomdir va keyingi avtonom operatsiyalarning 1-qoidasiga muvofiq, ID = 2 bo'lgan operatsiya birinchi bo'lib bajariladi ID = 3. ORDCUSTOMERIX indeks diapazoni quyidagi shart asosida ko'riladi: o. mijoz identifikatori 100 dan 1000 gacha.
• 2. ID=3 bo‘lgan operatsiya 1-bosqichda olingan Rowld qatori identifikatorlari ro‘yxatini asosiy amalga qaytaradi (Sh=2 bilan).
• 3. ID = 2 bilan operatsiya buyurtmalar jadvalidagi satrlarni o'qiydi, unda Rowld qiymati 2-bosqichda olingan Rowld qiymatlari ro'yxatiga mos keladi.
• 4. ID = 2 bo'lgan operatsiya asosiy operatsiyaning o'qish satrlarini qaytaradi (ID = 1 bilan).
• 5. ID = 2 bo'lgan operatsiya tomonidan qaytarilgan har bir qator uchun operatsiyaning ikkinchi bola operatsiyasi (ID = 4 bilan) bajariladi. o'rnatilgan halqalar. Ya'ni ID = 2 bo'lgan operatsiya orqali qaytarilgan har bir qator uchun birlashma atributida moslikni topish uchun order_items jadvalini to'liq ketma-ket skanerlash amalga oshiriladi.
• 6. 5-bosqich ID = 2 bo'lgan operatsiya tomonidan qaytarilgan qatorlar soni qancha marta takrorlanadi.
• 7. ID = 1 bo'lgan operatsiya asosiy operatsiya natijalarini qaytaradi (ID = 0 bilan).
• 8. ID = 0 bo'lgan operatsiya bajariladi.Olingan ma'lumotlar to'plami qaytariladi.

Tahlil qilinayotgan so'rovning murakkabligiga qarab, uni bajarish rejasi ancha murakkab tuzilishga ega bo'lishi mumkin, birinchi qarashda uni izohlash qiyin. Yuqorida tavsiflangan qoidalarning uslubiy bajarilishi va operatsiyalarning parchalanishi har qanday murakkablikdagi SQL so'rovini bajarish rejasini samarali tahlil qilish imkonini beradi. Keling, mijozlar ro'yxatini, ular sotib olgan tovarlar soni va ularning umumiy narxini yaratadigan so'rov misolini ko'rib chiqaylik:

SELECT s. mijoz_ismi,

COUNT(DISTINCT oi.product_id) mahsulot_qty sifatida,

SUM(oi.miqdor* oi.birlik_narxi) jami_xarajat sifatida oe.buyurtmalardan o INNER JOIN mijozlari c ON

o.customer_id=c.customer_id

INNER JOIN oe.order_items oi ON o.order_id= oi.order_id GROUP BY c. maxsus_birinchi_ism

Ushbu so'rovlar rejasining amallar ketma-ketligi rasmda ko'rsatilgan. 10.17.

I-BAYoTNI TANLASH

GURUH BOʻYICHA SARTALASH YG

	JADVALGA TO'LIQ
	INDEKS DIOMONASINI KO'RISH
ROWIDd INDEX BO'YICHA JADVAL KIRISH
JADVALGA TO'LIQ

Guruch. 10.17. So'rov rejasi, operatsiyalar ketma-ketligi

Keling, rasmda keltirilgan 80b so'rovini bajarish rejasini talqin qilishning mumkin bo'lgan yondashuvini tasvirlaylik. 10.17. Ushbu yondashuv ikkita asosiy bosqichni o'z ichiga oladi: operatsiyalarni bloklarga ajratish va operatsiyalar tartibini aniqlash.

Birinchi bosqichda bajarilayotgan operatsiyalarni bloklarga ajratish kerak. Buning uchun biz barcha ittifoq operatsiyalarini topamiz, ya'ni. bir nechta asosiy operatsiyalarga ega bo'lgan operatsiyalar (10.17-rasmda bu 2, 3 va 4-operatsiyalar) va bu bolalar operatsiyalarini bloklarga ajrating. Natijada, rasmdagi misoldan foydalanish. 10.17, biz uchta kasaba uyushma operatsiyasini va ettita operatsiyalar blokini olamiz.

Ikkinchi bosqichda operatsiyalar bloklarini bajarish ketma-ketligi aniqlanadi. Buning uchun siz yuqorida tavsiflangan amallarni bajarish qoidalarini qo'llashingiz kerak. Keling, identifikatsiya raqami (III) ga nisbatan har bir operatsiyani bajarish bo'yicha bir qator mulohazalarni amalga oshiramiz.

Sh = 0 operatsiyasi avtonom bo'lib, sSh = 1 operatsiyasining ota-onasi hisoblanadi.

Yu = 1 operatsiyasi ham avtonomdir; W = 2 operatsiyaning ota-onasi bo'lib, Y = 0 operatsiyasidan oldin bajariladi.

GO = 2 operatsiyasi bog'liq bo'lmagan birlashma operatsiyasi bo'lib, Yu = 3, Yu = 8 operatsiyalari uchun asosiy operatsiya hisoblanadi. GO = 2 operatsiyasi GO = 1 operatsiyasidan oldin bajariladi.

GO = 3 operatsiyasi bog'langan birlashma operatsiyasi bo'lib, u GO = 4, GO = 7 operatsiyalari uchun asosiy operatsiya hisoblanadi. GO = 3 operatsiyasi GO = 2 operatsiyasidan oldin bajariladi.

GO = 4 operatsiyasi bog'langan birlashma operatsiyasi bo'lib, u GO = 5, GO = 6 operatsiyalari uchun asosiy operatsiya hisoblanadi. GO = 4 operatsiyasi GO = 3 operatsiyasidan oldin bajariladi.

GO = 5 operatsiyasi avtonom operatsiya bo'lib, GO = 4 operatsiyasidan oldin bajariladi.

GO = 6 operatsiyasi avtonom operatsiya bo'lib, GO = 5 operatsiyasidan oldin bajariladi.

Operatsiya GO = 7 avtonom operatsiya bo'lib, "C" operatsiyalar bloki bajarilgandan so'ng amalga oshiriladi.

GO = 8 operatsiyasi avtonom operatsiya bo'lib, "E" operatsiyalari blokidan keyin amalga oshiriladi.

Yuqoridagi fikrlash va quyidagi qoidalarga asoslanib, biz bajarilgan operatsiyalar ketma-ketligini shakllantiramiz:

• 1. Avtonom operatsiya GO = 5 birinchi bo'lib amalga oshiriladi, bog'langan qo'shilish operatsiyalari ketma-ketligi qoidalariga qarang. Butun jadval ketma-ket o'qiladi.
• 2. GO = 5 operatsiya natijasi - o'qilgan jadval qatorlari - GO = 4 operatsiyasiga o'tkaziladi.
• 3. GO = 4 operatsiyasi bajariladi: GO = 5 operatsiyasi bilan qaytarilgan har bir qator uchun GO = 6 operatsiyasi bajariladi.Ya'ni indeks diapazoni birlashma atributiga qarshi skanerdan o'tkaziladi. Yaou1s1 qator identifikatorlari ro'yxatini olish.
• 4. GO = 4 operatsiya natijasi GO = 3 operatsiyasiga o'tkaziladi. Ya'ni Kosh1s1 qator identifikatorlari ro'yxati o'tkaziladi.
• 5. GO = 3 operatsiyasi bajariladi: “C” operatsiyalar blokining ishlashi natijasida qaytarilgan har bir 11ou1s1 qiymati uchun GO = 7 operatsiyasi bajariladi, ya'ni. jadval satrlari Sh = 4 operatsiyasini bajargandan so'ng olingan ITMI qator identifikatorlarining berilgan ro'yxatidan o'qiladi.
• 6. GO = 8 avtonom operatsiyasi bajariladi - butun jadvalni ketma-ket o'qish.
• 7. Bir-biriga bog'liq bo'lmagan birlashma operatsiyasi GO = 2 bajariladi: birlashma "E" va "E" operatsiya bloklari natijalarini xeshlash orqali amalga oshiriladi.
• 8. GO = 2 operatsiya natijasi GO = 1 operatsiyasiga o'tkaziladi.
• 9. GO = 1 bog'liq bo'lmagan birlashtirish operatsiyasi bajariladi: GO = 2 operatsiyasi natijasida olingan ma'lumotlar jamlanadi va saralanadi.
• 10. GO = 0 operatsiyasi bajariladi, natijada olingan ma'lumotlar to'plami qaytariladi.

Operatsiyalarning asosiy turlari uchun tuzilgan quyidagi qoidalar BSGO so'rovini bajarish rejalarining ko'pchiligiga nisbatan qo'llaniladi. Biroq, BSGO so'rovlarida quyidagi qoidalarda tasvirlangan operatsiyalar tartibini buzishni nazarda tutadigan konstruktsiyalar mavjud. Bunday holatlar, masalan, quyi so'rovlar yoki qo'shilishga qarshi predikatlardan foydalanish natijasida yuzaga kelishi mumkin. Qanday bo'lmasin, BSGO so'rovini bajarish rejasini sharhlash jarayoni faqat BSGO so'rovini bajarishda optimallashtiruvchi nima qilishini eng aniq tahlil qilishni ta'minlaydigan bir qator qoidalardan foydalanishni anglatmaydi. Boshqa BSGO so'rovi har doim individual holatdir; va uning ma'lumotlar bazasida qanday bajarilishi ko'plab omillarga bog'liq, shu jumladan ma'lumotlar bazasi versiyasi versiyasi, ma'lumotlar bazasi bazasi nusxasi joylashtirilgan operatsion tizim versiyasi va turi, foydalaniladigan apparat, 80b so'rovi muallifining malakasi, va boshqalar.

1 msdevcon.ru #msdevcon

3 Olontsev Sergey SQL Server MCM, MVP Kasperskiy laboratoriyasi

4 Strukturaviy so'rovlar tili

5 Misol so‘rovi HumanResources’dan pers.firstname, pers.lastname, emp.jobtitle, emp.nationalidnumberni tanlang.Employee as pers as pers.businessentityid = emp.businessentityid, bunda pers.firstname = N"Jon" va emp.hiredate >= " "

6 Mantiqiy so‘rovlar daraxti Project pers.firstname, pers.lastname, emp.jobtitle, emp.nationalidnumber D A T A Filtr Pers.firstname = N"John" va emp.hiredate qo‘shiling >= " " pers.businessentityid = emp.businessentityid Person.Person as pers Data Get Data Get HumanResources.Employee emp sifatida

7 So'rovlar rejasi T-SQL so'rovi jismoniy darajada qanday bajarilishini ko'rsatadi.

8 Bir necha usul

9 DEMO Oddiy reja Jadvaldagi barcha ma'lumotlarni tanlash, so'rov rejasini qanday olish

11 Init() operator usullari Init() usuli jismoniy operatorni o'zini ishga tushirishga va kerakli ma'lumotlar tuzilmalarini tayyorlashga olib keladi. Jismoniy operator Init() ga ko'p qo'ng'iroqlarni qabul qilishi mumkin, garchi u odatda faqat bittasini qabul qiladi. GetNext() GetNext() usuli jismoniy operatorga maʼlumotlarning birinchi yoki keyingi qatorini olishiga sabab boʻladi. Jismoniy operator ko'p GetNext() qo'ng'iroqlarini qabul qilishi mumkin yoki hech kimni qabul qilmasligi mumkin. GetNext() usuli ma'lumotlarning bir qatorini qaytaradi va uni chaqirish soni Showplan bayonotining chiqishidagi ActualRows qiymati bilan ko'rsatiladi. Close() Close() usuli chaqirilganda jismoniy operator biroz tozalashni amalga oshiradi va yopiladi. Jismoniy operator Close() ga faqat bitta qo'ng'iroqni qabul qiladi.

12 Operatorlar o'rtasidagi o'zaro aloqa 1-operator 2-operator 3

13 Operatorlar o'rtasidagi o'zaro ta'sir 1. Qator operatorini 1-operator 2-operator 3-ni so'rash

14 Operatorlar o'rtasidagi o'zaro aloqa 1. So'rov qatori 2. So'rov qatori operatori 1 Operator 2 Operator 3

15 Operatorlar o'rtasidagi o'zaro aloqa 1. So'rov qatori 2. So'rov qatori operatori 1 Operator 2 Operator 3 3. Qatorni yuborish

16 Operatorlar o'rtasidagi o'zaro aloqa 1. So'rov qatori 2. So'rov qatori operatori 1 operator 2 operator 3 4. Qatorni yuborish 3. Qatorni yuborish

17 Operatorlar o'rtasidagi o'zaro aloqa 1. So'rov qatori 2. So'rov qatori operatori 1 Operator 2 Operator 3 4. Qatorni yuborish 3. Qatorni yuborish

18 DEMO Operator TOP Yoki nima uchun operatorni iterator deb atash yaxshiroq

19 Jadvallar mavjud emas!

20 HoBT 1-sahifa 2-sahifa 3-sahifa 4-qator 1-qator 3-qator 5-qator 7-qator 2-qator 4-qator 6-qator 8-qator

21 HoBT sahifasi sahifasi sahifasi sahifasi sahifasi sahifasi

22 DEMO Ma'lumotlarga kirish operatorlari Scan, Seek, Lookup

23 Kimning ma'lumotlar bazasida faqat bitta jadval mavjud?

24 ta o'rnatilgan halqalar, xesh qo'shilish va birlashtirish

25 Operatorlarni qo‘shish Yuvalangan halqalar ichki birlashma, chap tashqi birlashma, chap yarim birlashma, chapga qarshi yarim qo‘shish Birlashtirish Birlashma ichki birlashma, chap tashqi birlashma, chap yarim birlashma, chapga qarshi yarim qo‘shish, o‘ng tashqi birlashma, o‘ng yarim qo‘shish, o‘ngga qarshi yarim qo‘shish , union Xash Barcha turdagi mantiqiy operatsiyalarga qo'shiling

26 DEMO Birlashish, tartiblash va birinchi operator Nested Loops, Merge Join, Hash Join, Saralash, Birinchi operator

27 Ogohlantirishlar

28 DEMO So'rovlar rejalaridagi xatolar va ogohlantirishlar

29 Men hech narsani bilmasligimni bilaman. Sokrat

30 DEMO Noaniq narsaning kichik misoli

31 Soʻrov rejalarini diagnostika qilish -- Eng koʻp CPU sarflaydigan TOP 10 ta soʻrov va ularning rejalari top(10) pastki qatorni (t.text, qs.statement_start_offset / 2, qs.statement_end_offset = -1, keyin esa len(t.text)) tanlaydi. (qs.statement_end_offset - qs.statement_start_offset) / 2 end), qs.execution_count, cast (qs.jami_ishchi_vaqti / o'nli kasr (18, 2)) jami_ishchi_vaqti_ms, cast (qs.jami_ishchi_vaqti * 1. / _ count / exec sifatida). (18, 2)) avg_worker_time_ms, cast(p.query_plan as xml) as query_plan from sys.dm_exec_query_stats as qs cross qo'llash sys.dm_exec_sql_text(qs.sql_handle) as t cross apply sys_plantext_,execplantext_(sys_plantsqdsq_) _start_offset , qs.statement_end_offset) qs.total_worker_time desc bo'yicha p tartibi sifatida; ket

32 Katta so‘rov rejalarini o‘qish texnikasi Ularni mantiqiy bloklarga bo‘lib, asta-sekin tahlil qilib ko‘ring. SSMS-da, reja grafik ko'rsatilganda, so'rovlar rejasi bo'ylab osonroq harakatlanish uchun pastki o'ng burchakda tugma paydo bo'ladi. XQuery\XPath-dan foydalanishingiz mumkin.

33 DEMO Katta so'rovlar rejasi

35 DEMO SQL Sentry Plan Explorer

36 Xulosa qilib olaylik Birinchi operator Optimallashtirish darajasi Kompilyatsiya vaqti Keshdagi o'lcham Parametrlar, Kompilyatsiya qiymatlari Erta tugatish sababi Iteratorlarning narxi birinchi navbatda eng yuqori narxga ega operatorlarni ko'rib chiqing. Shuni yodda tutingki, bu faqat taxminiy qiymatlar (hatto haqiqiy ijro rejalarida ham).

37 Xatcho'p\Kalitlarni qidirishni umumlashtiramiz. Agar ulardan bir nechtasi bo'lsa, unda hech qanday muammo yo'q. Agar ular ko'p bo'lsa, qoplama indeksini yaratish ulardan xalos bo'lishga yordam beradi. Ogohlantirishlar Nima uchun bu sodir bo'lganligini tekshirishingiz va kerak bo'lganda harakat qilishingiz kerak.

38 Xulosa qilib olaylik Operatorlar orasidagi ulanishlar (ma'lumotlar oqimi) Ulanish qanchalik qalin bo'lsa, bu operatorlar o'rtasida shunchalik ko'p ma'lumotlar uzatiladi. Ba'zi bosqichlarda ma'lumotlar oqimi keskin oshsa, ayniqsa diqqat qilish kerak. Jadvallarni birlashtirish tartibi Ma'lumotlar oqimlari qanchalik kichik bo'lsa, ularga qo'shilish shunchalik oson bo'ladi. Shuning uchun, birinchi navbatda, natijada ma'lumotlar oqimi kichikroq bo'lgan jadvallarga qo'shilishingiz kerak.

39 Xulosa skanerlash Skanerlash muammo borligini anglatmaydi. Qidiruvni yanada samaraliroq qilish uchun jadvalda indeks yetarli bo'lmagan bo'lishi mumkin. Boshqa tomondan, agar siz jadvalning to'liq yoki katta qismini tanlashingiz kerak bo'lsa, skanerlash yanada samarali bo'ladi. Qidiruv hammasi yaxshi degani emas. Klasterli bo'lmagan indekslar bo'yicha ko'p sonli qidiruvlar muammo bo'lishi mumkin. Reja haqida siz bilmagan har qanday narsa muammo bo'lishi mumkin.

40 ta savol

41 Kontaktlar Olontsev Sergey Kasperskiy laboratoriyasi

42 2013 Microsoft korporatsiyasi. Barcha huquqlar himoyalangan. Microsoft, Windows, Windows Vista va boshqa mahsulot nomlari AQShda roʻyxatdan oʻtgan savdo belgilari va/yoki savdo belgilaridir yoki boʻlishi mumkin. va/yoki boshqa mamlakatlar. Bu yerdagi maʼlumotlar faqat maʼlumot uchun moʻljallangan va ushbu taqdimot sanasidagi Microsoft korporatsiyasining joriy koʻrinishini ifodalaydi. Microsoft o'zgaruvchan bozor sharoitlariga javob berishi kerakligi sababli, bu Microsoft tomonidan majburiyat sifatida talqin qilinmasligi kerak va Microsoft ushbu taqdimot sanasidan keyin taqdim etilgan har qanday ma'lumotlarning to'g'riligiga kafolat bera olmaydi. MICROSOFT MUSHBU TAQDIMATDAGI MA'LUMOTLARGA OCHIQ, KO'P YOKI QONUNIY KAFOLATLAR BERMAYDI.