Reālais izpildes laiks varbūt ir interesants, bet parasti tas ir pēdējais kam pievēršu uzmanību. Ilgam vaicājuma izpildes laikam var būt dažādi iemesli, ja tie ir objektīvi un neuzlabojami, tad jau neko.. Iespējamie iemesli (manuprāt svarīgākie):
* jāveic daudz lasīšanas/rakstīšanas operāciju (Vaicājuma IO statistika)
* jāmoka procesors un jāveica aprēķini (CPU laiks- tas būs tālāk)
* milzu datu apjomi, kas jāpārsūta pa tīklu
* konkurence uz datiem (resursu slēgšana)
* lēns serveris
CPU patērētais laiks manuprāt jau ir daudz objektīvāks rādītājs (un parasti šo skatos iekš SQL Server Profiler). Joprojām atkarīgs no tā, uz kāda servera vaicājums tiek izpildīts- jo jaudīgāks procesors, jo mazāk laika vajadzīgs izpildei. Tāpat izpildot vaicājumu daudzas reizes, CPU laiks mazliet mainās. Laiks gan atšķiras minimāli. Atkarīgs ko vēl procesors dara tajā laikā. Lai arī tiek uzskaitīts tikai konkrētajam vaicājumam patērētais laiks, tomēr noslogotāka procesora gadījumā laiks ir nedaudz lielāks. Es to skaidroju ar kontekstu pārslēgšanās "izmaksām", bet nu tā ātrumā neizdodas atrast vai mans skaidrojums ir pareizs. Lai nu kā- rādītājs jebkurā gadījumā atšķiras minimāli un rādījumu rezultāti- viena servera gadījumā ir izvērtēšanas vērti.
Tad nu piemērs (tabulu izveide no raksta Vaicājuma IO statistika)- lai vienkāršāk varētu saprast rezultātus, no sākuma izpildu tikai komandu, kas pieslēguma ietvaros liek rādīt izpildes laikus:
set statistics time on(vai- labā poga vaicājuma izpildes logā Management studio, izvēlamies „Query Options”, tālāk „Advanced” un ieliekam ķeksīti pretī „Set Statistics TIME”)
Pēc tam izpildu vaicājumu:
select * from dbo.PiemeraTabIegūstu rezultātus:
Pirmā daļa ir laiks, kas patērēts lai vaicājumu "noformētu" datoram saprotamākā veidā un nokompilētu, savukārt otrā daļa attiecas uz vaicājuma izpildi (SQL Server Execution Times), tā arī ir tā, kas ir interesanta.
Pie šī vēl es noteikti atgriežoties apskatot konkrētus piemērus ar interesantākiem rezultātiem.
Nav komentāru:
Ierakstīt komentāru