JetShowPlan:Пример

Написах накратко за JetShowPlan в статията си за настройка на производителността на заявки за достъп. Както писах в тази статия, SQL е декларативен език. Когато пишете заявка, вие казвате на двигателя на базата данни какво ти искаш. Машината на базата данни решава как най-добре да постигна това вместо вас. Това като цяло е добре, тъй като оптимизирането на операции, базирани на набори, е трудно и оставянето на машината на базата данни да го направи вместо вас ви позволява да използвате знанията на онези, които посвещават живота си на този конкретен проблем.

Недостатъкът е, че как се превръща в черна кутия. Подавате малко SQL в черната кутия и излиза резултатен набор с куп данни. Двигателят на базата данни е изключително надежден при предоставянето на точно данните, които сте поискали. Проблемът е, че ефективността на извличането на данни може да бъде навсякъде. За да бъде ясно, лошата производителност почти никога не е вина на двигателя на базата данни. Обикновено проблемът е, че липсва индекс или филтриране на резултата от VBA функция или присъединяване към две свързани таблици, които се съхраняват във физически отделни места.

Когато възникне този проблем, имаме нужда от начин да го отстраним. Въведете JetShowPlan. Мислете за това като за специална отвертка, която ни позволява да разглобим черната кутия и да надникнем вътре, за да видим как двигателят на базата данни изпълнява SQL командите, с които го подаваме. С това знание можем да настроим SQL, да добавим индекс или по друг начин да адресираме източника на нашето затруднение в производителността.

Да започваме.

Ключ на регистъра

JetShowPlan работи, като записва плана на заявката (т.е. съдържанието на черната кутия) в текстов файл всеки път, когато двигателят на базата данни ACE/Jet изпълнява всякакво запитване. Този текстов файл се запълва бързо. Създаването на текстовия файл изисква ресурси, които допълнително намаляват производителността на заявката. По този начин искаме да активираме тази функция само когато активно отстраняваме проблем.

Тъй като това е инструмент за напреднали потребители, в потребителския интерфейс на Access няма настройка за активиране на този режим. Единственият начин да го включите или изключите е като зададете стойност в системния регистър. Стойността на системния регистър отговаря на следния модел (текстът в къдравите скоби служи като заместител):

[HKEY_LOCAL_MACHINE\SOFTWARE{\Wow6432Node}\Microsoft\Office\{xx}.0\Access Connectivity Engine\Engines\Debug]
"JETSHOWPLAN"="ON"

Съображения за версията и битността

Моделът на стойността на системния регистър, който показах по-горе, използва някакъв заместващ текст, за да отчете разликите между средите на Access. Текстът на номера на версията \{xx}.0\ трябва да бъде заменен с номера на версията, който съответства на версията на Access, инсталирана на вашето устройство:

12.0 :Access 2007
13.0 :пропуснато, за да се избегне задействане на трискаидекафоби
14.0 :Access 2010
15.0 :Access 2013
16.0 :Access 2016 &2019

\Wow6432Node („Wow“ означава „Windows 32-bit on Windows 64-bit“) се изисква само ако използвате 32-битова версия на Microsoft Access на 64-битова версия на Windows. Ако Access и Windows са 32-битови или и двете 64-битови, тогава тази „папка“ (или „ключ“ на жаргона на системния регистър) не е необходима.

Във VBA форма:

    If Is32BitAccess Xor Is32BitWindows Then
        IncludeWow6432Key = True
    Else
        IncludeWow6432Key = False
    End If

Например, 32-битова инсталация на Access 2010, работеща на 64-битов Windows, ще изисква следния запис в системния регистър:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Access Connectivity Engine\Engines\Debug]
"JETSHOWPLAN"="ON"

По същия начин, 64-битова инсталация на Access 2019 на 64-битов Windows ще изисква:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Access Connectivity Engine\Engines\Debug]
"JETSHOWPLAN"="ON"

Трябва също да отбележа, че първият път, когато създадете този запис, вероятно ще трябва да добавите ключа "Debug" (папка) и името и данните на стойността на JETSHOWPLAN.

Ето стъпките, за да направите това:

Изпълнете regedit като администратор
Отидете до клавиша „\Engines“, следвайки горните бележки
Щракнете с десния бутон върху „\Engines“ и изберете Нов -> Ключ
Преименувайте ключа от „Нов ключ №1“ на „Отстраняване на грешки“

След това ще трябва да добавите стойността на низа „JETSHOWPLAN“ с данните „ON ", за да активирате добавянето към showplan.out файл или „ИЗКЛ. ", за да спрете добавянето към файла.

Щракнете с десния бутон върху ключа "\Debug" и изберете New -> String Value
Преименувайте стойността от „Нова стойност №1“ на „JETSHOWPLAN“
Щракнете с десния бутон върху името на стойността „JETSHOWPLAN“ и изберете Промяна...
Задайте стойността на данните на ВКЛ. след това щракнете върху бутона [OK]

Следващият път, когато стартирате нов екземпляр на Access, той ще започне да добавя данни към файла Showplan.out. Всички екземпляри на Access, които вече работят, когато направите горните промени, няма да бъдат засегнати. Същото важи и за това, когато изключите настройката ИЗКЛ . Промените не влизат в сила, докато не стартирате нов msaccess.exe екземпляр. Не е необходимо да затваряте съществуващи екземпляри на Access; възможно е да има един отворен екземпляр на Access, който активно пише към showplan.out, докато друг екземпляр на Access не е.

Autohotkey скрипт

няма да лъжа; прескачане в regedit всеки път, когато искам да включа или изключа JetShowPlan, е досадно. Ако трябваше да го направя, едва ли щях да си правя труда. Но не трябва да правя това! Създадох бърз клавиш в Autohotkey, който включва и изключва JetShowPlan.

^#q:: ; Ctl + Win + Q  (feel free to use your own key combination)
    ;--== Toggle JETSHOWPLAN ==--
    
    ;----- BEGIN CONFIGURATION (make all changes here) -------------
    ShowPlanRegView = 64   ; set to 32 for 32-bit Access
    ShowPlanKey = SOFTWARE\Microsoft\Office\16.0\Access Connectivity Engine\Engines\Debug  ; change 16.0 to match Access version
    ;----- END CONFIGURATION ---------------------------------------
    
    SetRegView %ShowPlanRegView%
    RegRead ShowPlanSetting, HKEY_LOCAL_MACHINE\%ShowPlanKey%, JETSHOWPLAN
    If ( ShowPlanSetting = "OFF" ) {
            RegWrite REG_SZ, HKEY_LOCAL_MACHINE\%ShowPlanKey%, JETSHOWPLAN, ON
            If ErrorLevel
                MsgBox Error enabling JetShowPlan. Check permissions on:`n`nHKLM\%ShowPlanKey%`n`nfor user '%A_UserName%'
            Else
                MsgBox JetShowPlan set to ON
    } Else {
            RegWrite REG_SZ, HKEY_LOCAL_MACHINE\%ShowPlanKey%, JETSHOWPLAN, OFF
            If ErrorLevel
                MsgBox Error disabling JetShowPlan. Check permissions on:`n`nHKLM\%ShowPlanKey%`n`nfor user '%A_UserName%'
            Else
                MsgBox JetShowPlan set to OFF
    }
    SetRegView Default
    Return

Сега, когато искам да настроя заявките си, натискам [Ctl] + [Win] + [Q] и виждам поле за съобщение, което казва "JetShowPlan set to ON". Когато свърша, затварям Access, натискам [Ctl] + [Win] + [Q] и виждам „JetShowPlan е изключено“.

Коригиране на разрешенията

Имам два различни потребителски акаунта на Windows:един със стандартни разрешения, които използвам за ежедневна работа, и друг с администраторски разрешения за инсталиране на софтуер и т.н. Това е често срещана най-добра практика за сигурност.

Проблемът е, че ключът на системния регистър JetShowPlan е в HKLM кошера. По подразбиране само администраторите могат да правят промени в стойностите в този кошер. Това е досадно, защото когато се опитам да изпълня моя скрипт на Autohotkey, получавам следното съобщение за грешка:

Не се притеснявай обаче. Както подсказва съобщението по-горе, можем да поправим това. Най-добрата част е, че можем да го направим удобен, без да намаляваме нашата позиция за сигурност. Ето уловката.

Отворете regedit като администратор
Отидете до \Debug ключ
Щракнете с десния бутон върху \Debug и изберете Разрешения...
Щракнете върху бутона [Добавяне...]
Въведете потребителското име от полето за съобщения по-горе („Майк“), щракнете върху [Проверка на имената], след което щракнете върху [OK]
Разрешаване на [√] „Пълен контрол“ за потребителя
Щракнете върху [OK], за да запазите промените

Сега, когато натисна [Ctl] + [Win] + [Q], той включва и изключва JetShowPlan, като автоматично актуализира системния регистър.

Намиране на Showplan.out

Access няма да ви предупреди къде Jet/ACE машината за база данни добавя информация за плана на заявката, когато JetShowPlan е активиран. Прекарах повече време, отколкото искам да си призная, търсейки измамно копие на showplan.out . Този раздел ще ви спаси от споделянето на тази съдба.

Местоположение по подразбиране

Първото място за търсене е в папката Документи на текущия потребител. Например, моето потребителско име за Windows е "Mike", така че първото място, което очаквам да намеря файла, е:C:\Users\Mike\Documents\showplan.out .

Използване на CurDir()

Технически погледнато, showplan.out файл се създава в текущата работна директория. Това обикновено е папката Документи на текущия потребител, но не винаги. Безупречният начин да намерите местоположението на файла е да използвате CurDir() функция.

Можете да копирате, поставите и изпълните следния ред код в непосредствения прозорец на VBA IDE, за да отворите файла showplan.out (ако приемем, че сте активирали JetShowPlan в системния регистър):

Shell "notepad """ & CurDir & "\showplan.out""", vbNormalFocus

Промяна на изходното местоположение чрез ChDir()

Ако по някаква причина искате да посочите различно местоположение за showplan.out файл, можете да направите това с помощта на функцията ChDir(). Тази функция променя текущата работна директория. И както споменах по-рано, текущата директория е мястото, където showplan.out файлът се намира. Веднага след като промените текущата работна директория, JetShowPlan започва да пише в новата папка; няма нужда да затваряте и отваряте отново Access.

Защо може да искате да направите това? Да приемем, че искате да сравните три различни подхода за извличане на едни и същи данни. Пишете три различни заявки, за да видите как промените, които правите, влияят на плана на заявката. От showplan.out е толкова многословен, би било хубаво всяка заявка да има план в собствен файл. Това ще направи плановете за заявка по-лесни за сравняване. Ето как мога да го направя. Първата стъпка е да се уверите, че всяка от тези папки съществува. След това изпълнете следните редове код:

ChDir "C:\Users\Mike\Documents\Showplan\A"
DoCmd.OpenQuery "CollectTax1"
ChDir "C:\Users\Mike\Documents\Showplan\B"
DoCmd.OpenQuery "CollectTax2"
ChDir "C:\Users\Mike\Documents\Showplan\C"
DoCmd.OpenQuery "CollectTax3"
ChDir "C:\Users\Mike\Documents"

Използвайте всичко, което имате (или го изтеглете, ако не все още нямам)

Докато CurDir() ще ви даде окончателно местоположение за най-новите промени в showplan.out файл, той не може да ви каже какви са били предишните работни директории. И ако сте затворили екземпляра на Access, който създаде showplan.out файл, няма гаранция, че следващият екземпляр на Access, който отворите, ще има същата текуща директория.

Наскоро попаднах на удобна малка помощна програма, наречена „Всичко“. Това е малък изпълним файл, който индексира целия ви твърд диск само за няколко секунди. След като индексирането приключи, можете незабавно да търсите файлове или папки навсякъде на вашето устройство.

Можете да изтеглите Всичко от тук или чрез Chocolatey:choco install everything . Отворете Всичко , потърсете showplan.out , и след по-малко от секунда ще видите всеки екземпляр на showplan.out на вашия компютър заедно с датата на последната промяна. Иска ми се да имах този инструмент преди години.

Осмисляне на Showplan.out

Първият път, когато отворите showplan.out файл, очаквайте да бъдете объркани. Има много текст и голяма част от него е шум. Ето откъс от файл, генериран, когато отворих примерната база данни на Northwind:

Заявките, които започват с тилда (~ ) представлява необработен SQL, който е записан в листа със свойства на формуляр или отчет и не е запазен като постоянен обект на QueryDef. Основните интересни точки са номерираните стъпки за всяка заявка:01) , 02) , 03) и т.н. Искате да следвате тези стъпки, търсейки добри и лоши знаци, които могат да подсказват къде има проблеми.

Доколкото ми е известно, няма официална документация за форматирането и съдържанието на showplan.out файл. Това обаче е добре, защото няма да се увличаме по дреболии. Нашата основна цел е да идентифицираме очевидно очевидни проблеми и да се справим с тях. Тук важи правилото 80/20. Повечето от подобренията в производителността ще дойдат от едно или две прости промени в нашите заявки.

Добри знаци

Това е всичко за индекси. Искаме планът на заявката да използва индекси, особено в началните стъпки на многоетапна заявка. Две различни ключови думи показват, че се използват индекси:index и rushmore . Rushmore е кодовото име на технологията за оптимизация на заявки, първоначално разработена от Fox Software в началото на 80-те години. Microsoft купи компанията през 1992 г. и включи технологията в двигателя на базата данни Jet.

Заявките, които използват технологията Rushmore за обработка на индекси, работят по-бързо от тези, които използват индекси по по-традиционен начин. Технологията Rushmore може да се използва само с таблици на Access (както локални, така и свързани), заедно със свързани FoxPro и dBASE таблици. По-специално, Rushmore не може да се използва със свързани таблици на SQL Server. За да повишите производителността на свързаните таблици на SQL Server, често е по-добре да пишете преходни заявки, но това е извън обхвата на тази статия.

Лоши знаци

Има няколко лоши знака, за които трябва да внимавате в showplan.out файл. Простото присъствие на тези признаци не означава непременно, че има проблем. Въпреки това, ако отстранявате неизправност в заявка с лоша производителност, можете да мислите за тези думи като предупредителни знаци за потенциални проблеми:X-Prod , scanning , temp , temporary .

X-Prod ключова дума се появява, когато имате заявка с декартово присъединяване (известно също като кръстосано присъединяване или кръстосано произведение). Това обикновено се случва по погрешка, когато забравите да обедините две таблици в редактора Query-by-Example (QBE). Резултатът е, че всеки запис в таблица 1 се съпоставя с всеки запис в таблица 2. Общият брой записи е произведението от броя на двете таблици. Така че, ако таблица 1 има 7 записа, а таблица 2 има 9 записа, кръстосаното свързване на двете таблици връща 63 записа. Можете да си представите проблема, ако и двете таблици имат хиляди записи или повече.

01) Inner Join table 'Table1' to table 'Table2'
      using X-Prod join

Следващата ключова дума, за която трябва да внимавате, е сканиране . Ако механизмът на базата данни не може да използва индекс за филтриране на резултатите, той се връща към сканиране. Това означава, че трябва да проучи всеки ред поотделно, за да види дали отговаря на критериите за заявка. Когато видите тази дума в showplan.out файл, това често означава, че трябва да добавите индекс към колоната, която се сканира. Но не винаги! За колони с ниска кардиналност (само няколко уникални стойности, като например колона за състояние), обикновено има малка полза от добавянето на индекс. Веднъж добавен, индексът трябва да се поддържа. Това забавя вмъкването и заема дисково пространство. Освен това, ако производителността на заявката е приемлива за производствените данни, тогава добавянето на индекс към сканираната колона е преждевременна оптимизация (която трябва да избягвате).

И накрая, има temp и временни ключови думи. Те показват, че машината на базата данни е трябвало да извърши някаква операция на временна основа. Когато създаваме и запазваме querydef, този обект се записва с определени метаданни, за да се оптимизира повторното изпълнение. Очевидно такива метаданни се губят, когато временните индекси или обединения излязат извън обхвата. Тези ключови думи обикновено могат да бъдат игнорирани, но може да са в състояние да ви насочат в правилната посока, ако се затрудните при заявка с лоша ефективност без други по-очевидни недостатъци.

За да обобщим с твърде опростени термини:

ДОБРО > > > > > ЛОШО:
Rushmore> индекси> временен/временен> сканиране> X-Prod

Персонализиран език на Notepad++

Ако сте чели другата ми работа, знаете, че имам силни чувства относно увеличаването на съотношението сигнал/шум в програмирането (и живота като цяло). За тази цел създадох файл „Дефиниран от потребителя език“ в Notepad++, за да добавя подчертаване на синтаксиса към showplan.out файлове. Сега, когато отворя showplan.out файлове, те изглеждат като екранната снимка по-долу. Ключовите думи "ДОБРИ" са оцветени в син текст, а ключовите думи "ЛОШО" са оцветени в червен текст. Това е пример за направата на грешен код да изглежда грешен.

За да настроите това, изпълнете следните стъпки:

Отворете Notepad++
Език -> Език, определен от потребителя -> Определете своя език...
Щракнете върху [Създаване на нов...]
Въведете име:showplan.out
Щракнете върху [OK]
Отидете на _| Папка и по подразбиране|_ раздел
Под „Сгъване в стил код 2“ въведете Inputs за отворени и End inputs за затваряне
Отидете в раздела _|Списък с ключови думи|_
Щракнете върху [Styler] под 1-ва група и задайте цвят на преден план на червен
Въведете следните „ЛОШИ“ ключови думи в 1-ва група:
temp temporary scanning X-Prod
Щракнете върху [Styler] под 2-ра група и задайте цвят на преден план на син
Въведете следните „ДОБРИ“ ключови думи във 2-ра група:
rushmore index
Enter Ext.:out

Последни мисли

За разлика от SQL Server, механизмът на базата данни Jet/ACE не ви позволява директно да променяте плановете за изпълнение на заявка. Това означава, че можем да погледнем вътре в черната кутия с JetShowPlan, но не можем да го пренастроим, за да правим това, което искаме. Вместо това трябва да се съсредоточим върху това, което можем да контролираме:точният SQL, който го захранваме, и индексите и връзките между участващите таблици.

Използването на JetShowPlan има както краткосрочни, така и дългосрочни ползи. В краткосрочен план функцията ви позволява да коригирате тесните места във вашите приложения на Access. В дългосрочен план получавате представа за вътрешната работа на Access, което ви помага да избегнете пречките на първо място.