Вирішення всіх питань тесту 1С: Професіонал з технологічних питань (Розділ №6)

«Запити та методи їх оптимізації».

06.01 – 5

План запиту, що формується SQL Server можна отримати як за допомогою SQL Server Profiler, так за допомогою технологічного журналу і ЦУП. А ось центр контролю якості, який входить в ЦУП не надає такої можливості. 

джерела:

Дивіться також:

06.02 – 2

якщо елемент plansql присутній, то буде включено збір планів запитів, які генерують СУБД при виконанні запитів «1С: Підприємства». Самі плани запитів розташовані у властивості planSQLText подій, пов’язаних з виконанням запитів конкретної СУБД (див.).

джерело:

06.03 – 1

Щоб отримати текст запиту так, як його отримує SQL Server, і побачити план запиту, потрібно зробити наступне:

  1. Запустити SQL Server Profiler
  2. Створити трасування. Можна використовувати стандартний шаблон.
  3. У властивостях трасування:
    1. Переконатися, що в неї входять події SQL: BatchStarted, SQL: BatchCompleted, RPC: Completed.
    2. Встановити галочку «усі події».
    3. Додати події Showplan Statistics Profile і Showplan XML StatisticsProfile з вузла Performance.
    4. Зняти галочку «усі події», залишаться тільки обрані.
    5. Встановити галочку «всі стовпці».
    6. Додати стовпець «DatabaseName».
    7. Зайти в «фільтри стовпців», поставити фільтр «DatabaseName» «Схоже на (Like)» <напісать_імя_своей_бази>
    8. Переконатися, що у події Showplan Statistics Profile включений столбецBinaryData.
    9. Зняти галочку «всі стовпці», залишаться тільки обрані.

джерело:

клас подій Showplan Statistics Profile відбувається, коли Microsoft SQL Server виконує інструкцію SQL. Включаються в ці події відомості являють собою частину даних, доступних в класі подій Showplan XML Statistics Profile.

Клас подій Showplan Statistics Profile виводить повні дані часу компіляції. Трасування, що містять профіль статистики інструкції Showplan, можуть значно знизити продуктивність. Щоб звести їх до мінімуму, зробіть використання цього класу подій доступним тільки для трассіровок, що спостерігають за окремими проблемами протягом короткого проміжку часу.

джерело:

клас подій Showplan XML Statistics Profile виникає, коли Microsoft SQL Server виконує інструкцію SQL. Увімкніть клас подій Showplan XML Statistics Profile для ідентифікації операторів Showplan в Microsoft SQL Server.

Клас подій Showplan XML Statistics Profile відображає повні дані етапу компіляції, тому трасування, які містять цей клас подій, можуть істотно збільшувати робоче навантаження. Щоб мінімізувати вноситься витрати, використовуйте цей клас подій тільки в трасування, що спостерігають за певними проблемами протягом нетривалого періоду часу.

джерело:

06.04 – 3

оператор Index Scan отримує всі записи некластерного індексу, зазначеного в стовпчику Argument. Index Scan є логічним і фізичним оператором.

джерело:

шпаргалка

  • Index Scan – Логічний і фізичний оператор, який витягує всі рядки з некластерізованний індексу, зазначеного в колонці Argument.
  • Clustered Index Scan – Логічний і фізичний оператор, який сканує кластерізованний індекс, визначений в колонці Argument.
  • Index Seek – Логічний і фізичний оператор, який використовує можливість пошуку індексів з метою вилучення рядків з некластерізованний індексу.
  • Clustered Index Seek – Логічний і фізична оператор, який використовує пошукову здатність індексів витягувати збережені рядки з кластерізованного індексу.

06.05 – 1

Щоб мати можливість виконувати запити, Компонент SQL Server Database Engine повинен аналізувати інструкцію і визначати найбільш ефективний спосіб доступу до необхідних даних. Цей аналіз обробляється компонентом, який називається оптимізатором запитів. Вхідні дані оптимізатора запитів включають сам запит, схему бази даних (визначення таблиць і індексів) і статистику бази даних. Вихідні дані оптимізатора запитів – це план виконання запиту, який іноді називається планом запиту або просто планом виконання.

План виконання запиту є визначення наступного:

  • Послідовності, в якій відбувається звернення до вихідних таблиць …
  • Методи, які використовуються для отримання даних з кожної таблиці …

джерело:

06.06 – 1

оператор Index Seek використовує можливості пошуку за індексами для отримання рядків з некластерного індексу, зазначеного в стовпчику Argument. Index Seek є логічним і фізичним оператором.

джерело:

шпаргалка:

  • Index Scan – Логічний і фізичний оператор, який витягує всі рядки з некластерізованний індексу, зазначеного в колонці Argument.
  • Clustered Index Scan – Логічний і фізичний оператор, який сканує кластерізованний індекс, визначений в колонці Argument.
  • Index Seek – Логічний і фізичний оператор, який використовує можливість пошуку індексів з метою вилучення рядків з некластерізованний індексу.
  • Clustered Index Seek – Логічний і фізична оператор, який використовує пошукову здатність індексів витягувати збережені рядки з кластерізованного індексу.

06.07 – 2

оператор Clustered Index Scan сканує кластерний індекс, вказаний в стовпці Argument. Clustered Index Scan є логічним і фізичним оператором.

джерело:

шпаргалка:

  • Index Scan – Логічний і фізичний оператор, який витягує всі рядки з некластерізованний індексу, зазначеного в колонці Argument.
  • Clustered Index Scan – Логічний і фізичний оператор, який сканує кластерізованний індекс, визначений в колонці Argument.
  • Index Seek – Логічний і фізичний оператор, який використовує можливість пошуку індексів з метою вилучення рядків з некластерізованний індексу.
  • Clustered Index Seek – Логічний і фізична оператор, який використовує пошукову здатність індексів витягувати збережені рядки з кластерізованного індексу.

06.08 – 4

оператор Clustered Index Seek використовує пошукові можливості індексів для отримання рядків з кластерного індексу, зазначеного в стовпчику Argument. Clustered Index Seek-це логічний і фізичний оператор.

джерело:

шпаргалка:

  • Index Scan – Логічний і фізичний оператор, який витягує всі рядки з некластерізованний індексу, зазначеного в колонці Argument.
  • Clustered Index Scan – Логічний і фізичний оператор, який сканує кластерізованний індекс, визначений в колонці Argument.
  • Index Seek – Логічний і фізичний оператор, який використовує можливість пошуку індексів з метою вилучення рядків з некластерізованний індексу.
  • Clustered Index Seek – Логічний і фізична оператор, який використовує пошукову здатність індексів витягувати збережені рядки з кластерізованного індексу.

06.09 – 4

оператор Table Scan отримує рядки з таблиці, зазначеної в стовпці Argument плану виконання запиту. Table Scan є логічним і фізичним оператором.

джерело:

06.10 – 5

Сканування – це отримання всіх записів. Різниця полягає лише в тому, що саме проходиться: кластерний індекс, некластерние індекс або сама таблиця.

джерело:

Clustered Index Scan сканує кластерний індекс, а Table Scan повертає всі рядки з таблиці, зазначеної в колонці Argument.

Clustered Index Scan використовується для сканування відсортованих таблиць цілком, а Table Scan – несортованих.

06.11 – 4

Сканування – це отримання всіх записів. Різниця полягає лише в тому, що саме проходиться: кластерний індекс, некластерние індекс або сама таблиця.

джерело:

Clustered Index Scan – операція, яка виконується над кластерним індексом, а Index Scan – операція, що виконує сканування некластерного індексу

06.12 – 2

послідовність елементів event визначає умова, при виконанні якого подія буде поміщено в журнал. У журнал поміщаються тільки такі події, які задовольняють умові. Інакше кажучи, якщо умова, яке визначається послідовністю елементів event, приймає значення Істина, то подія буде записано в журнал. 

В наявності є таке імена груп подій:

  • DBMSSQL – Виконання операторів SQL СУБД Microsoft SQL Server.

Кожна подія має набір властивостей. Кожна властивість має ім’я. Можлива присутність в подію декількох властивостей з однаковими іменами. Імена властивостей можуть використовуватися для фільтрації подій і властивостей. Великі і малі літери при порівнянні імен не розрізняються. Пусте умова в елементі property означатиме, що властивість буде виводитися при будь-якому умови.

  • Duration – тривалість події в десятитисячних частках секунди.

джерело:

подія  DBMSSQL дозволить зібрати всі SQL запити технологічної платформи 1С до СУБД MS SQL Server з фільтром по одній базі db.

джерело:

06.13 – 2

Документального підтвердження знайти не вдалося, проте правильну відповідь на сайті навчального тестування говорить про те, що подія НЕ БУДЕ записано в технологічний журнал в момент свого початку (наприклад, при початку виконання запиту), що і підтверджується практично. 

06.14 – 2

Речення ДЛЯ ЗМІНИ дозволяє завчасно заблокувати деякі дані (які можуть читатися транзакцією іншого з’єднання) вже при зчитуванні, щоб виключити взаємні блокування під час запису. ДЛЯ ЗМІНИ дає можливість вказати в запиті таблиці, зчитує дані яких передбачається змінювати. В цьому випадку іншу сполуку чекатиме звільнення цих даних вже в момент зчитування всередині транзакції, тобто не зможе прочитати заблоковані дані до тих пір, поки не буде завершена транзакція, яка наклала блокування. Блокування від зміни даних прочитуються в транзакції виконується незалежно від пропозиції ДЛЯ ЗМІНИ. Це означає, що якщо всередині будь-якої транзакції лічені деякі дані, то з іншого з’єднання ці дані не можуть бути змінені до тих пір, поки блокування не буде знято. Якщо запит виконується поза транзакції, то в ньому можуть бути лічені і заблоковані дані.

Блокування встановлюються в момент виконання запиту, скидаються ж при закінченні транзакції. У разі якщо запит виконується поза транзакції пропозицію ДЛЯ ЗМІНИ ігнорується.

джерело:

06.15 – 5

Речення ДЛЯ ЗМІНИ дозволяє завчасно заблокувати деякі дані (які можуть читатися транзакцією іншого з’єднання) вже при зчитуванні, щоб виключити взаємні блокування під час запису. ДЛЯ ЗМІНИ дає можливість вказати в запиті таблиці, зчитує дані яких передбачається змінювати. В цьому випадку іншу сполуку чекатиме звільнення цих даних вже в момент зчитування всередині транзакції, тобто не зможе прочитати заблоковані дані до тих пір, поки не буде завершена транзакція, яка наклала блокування.

джерело:

Таким чином, конструкція ДЛЯ ЗМІНИ використовується для захисту від взаимоблокировки, яка виникає при підвищенні рівня блокування в транзакціях з рівнем ізоляції:

  • REPEATABLE READ – забезпечує повторюваність читання даних. Якщо моя транзакція починає читати дані, то інша транзакція не може їх змінити до закінчення моєї транзакції.
  • SERIALIZABLE – послідовне виконання. Цей рівень ізоляції є максимальним і забезпечує повну ізоляцію транзакцій один від одного. Вирішуються всі розглянуті проблеми, включаючи проблему «фантомів».

джерело:

06.16 – 4

Data Definition Language (DDL) (Мова опису даних) – це сімейство комп’ютерних мов, які використовуються в комп’ютерних програмах для опису структури баз даних.

джерело:

шпаргалка:

  • DDL – Мова визначення даних, призначений для створення, видалення та модифікації таблиць бази даних.
  • DCL – Мова керування даними, призначений для забезпечення захисту бази даних.
  • DML – Сімейство комп’ютерних мов, які використовуються в комп’ютерних програмах або користувачами баз даних для отримання, вставки, видалення або зміни даних в базах даних.

06.17 – 2

Data Control Language (DCL) – підмножина мови управління базами даних SQL, призначене для здійснення адміністративних операцій, які присвоюють або скасовують право (привілей) використовувати базу даних, таблиці та інші об’єкти бази даних, а також виконувати ті чи інші оператори SQL.

джерело:

шпаргалка:

  • DDL – Мова визначення даних, призначений для створення, видалення та модифікації таблиць бази даних.
  • DCL – Мова керування даними, призначений для забезпечення захисту бази даних.
  • DML – Сімейство комп’ютерних мов, які використовуються в комп’ютерних програмах або користувачами баз даних для отримання, вставки, видалення або зміни даних в базах даних.

06.18 – 1

Data Manipulation Language (DML) (Мова управління (маніпулювання) даними) – це сімейство комп’ютерних мов, які використовуються в комп’ютерних програмах або користувачами баз даних для отримання, вставки, видалення або зміни даних в базах даних.

джерело:

шпаргалка:

  • DDL – Мова визначення даних, призначений для створення, видалення та модифікації таблиць бази даних.
  • DCL – Мова керування даними, призначений для забезпечення захисту бази даних.
  • DML – Сімейство комп’ютерних мов, які використовуються в комп’ютерних програмах або користувачами баз даних для отримання, вставки, видалення або зміни даних в базах даних.

06.19 – 4

Щоб мати можливість виконувати запити, Компонент SQL Server Database Engine повинен аналізувати інструкцію і визначати найбільш ефективний спосіб доступу до необхідних даних. Цей аналіз обробляється компонентом, який називається оптимізатором запитів. Вхідні дані оптимізатора запитів включають сам запит, схему бази даних (визначення таблиць і індексів) і статистику бази даних. Вихідні дані оптимізатора запитів – це план виконання запиту, який іноді називається планом запиту або просто планом виконання.

План виконання запиту є визначення наступного:

  • Послідовності, в якій відбувається звернення до вихідних таблиць …
  • Методи, які використовуються для отримання даних з кожної таблиці …

джерело:

06.20 – 3

Щоб отримати текст запиту так, як його отримує SQL Server, і побачити план запиту, потрібно зробити наступне:

  1. Запустити SQL Server Profiler
  2. Створити трасування. Можна використовувати стандартний шаблон.
  3. У властивостях трасування:
    1. Переконатися, що в неї входять події SQL: BatchStarted, SQL: BatchCompleted, RPC: Completed.
    2. Встановити галочку «усі події».
    3. Додати події Showplan Statistics Profile і Showplan XML StatisticsProfile з вузла Performance.
    4. Зняти галочку «усі події», залишаться тільки обрані.
    5. Встановити галочку «всі стовпці».
    6. Додати стовпець «DatabaseName».
    7. Зайти в «фільтри стовпців», поставити фільтр «DatabaseName» «Схоже на (Like)» <напісать_імя_своей_бази>
    8. Переконатися, що у події Showplan Statistics Profile включений столбецBinaryData.
    9. Зняти галочку «всі стовпці», залишаться тільки обрані.

джерело:

клас подій SQL: BatchCompleted вказує на завершення виконання пакета мови Transact-SQL

джерело:

клас подій RPC: Completed вказує, що віддалений виклик процедури завершено.

джерело:

клас подій Showplan Statistics Profile відбувається, коли Microsoft SQL Server виконує інструкцію SQL. Включаються в ці події відомості являють собою частину даних, доступних в класі подій Showplan XML Statistics Profile.

Клас подій Showplan Statistics Profile виводить повні дані часу компіляції. Трасування, що містять профіль статистики інструкції Showplan, можуть значно знизити продуктивність. Щоб звести їх до мінімуму, зробіть використання цього класу подій доступним тільки для трассіровок, що спостерігають за окремими проблемами протягом короткого проміжку часу.

джерело:

клас подій Showplan XML Statistics Profile виникає, коли Microsoft SQL Server виконує інструкцію SQL. Увімкніть клас подій Showplan XML Statistics Profile для ідентифікації операторів Showplan в Microsoft SQL Server.

Клас подій Showplan XML Statistics Profile відображає повні дані етапу компіляції, тому трасування, які містять цей клас подій, можуть істотно збільшувати робоче навантаження. Щоб мінімізувати вноситься витрати, використовуйте цей клас подій тільки в трасування, що спостерігають за певними проблемами протягом нетривалого періоду часу.

джерело:

06.21 – 2

Події класу Showplan XML відбуваються, коли Microsoft SQL Server виконує інструкцію SQL … Showplan XML зберігає план запиту, який створюється при оптимізації запиту. 

джерело:

06.22 – 2

Showplan XML for Query Compile – це подія аналогічно події SHOWPLAN XML за винятком того, що вихідні дані Showplan створюються тільки при компіляції (або перекомпіляції) запиту. Для подальших виконань, якщо план запиту витягується з кешу планів, інформація showplan не відображається. Ця подія менш затратно з точки зору продуктивності і найкраще підходить для швидкого перегляду створеного плану запиту.

джерело:

06.23 – 1

оператор Nested Loops в спрощеному вигляді порівнює кожен рядок однієї таблиці (званої зовнішньої таблицею) з кожної рядку іншої таблиці (званої внутрішньої таблицею), шукаючи ті рядки, які задовольняють предикату з’єднання. 

Утворені вкладені цикли і представляють той самий алгоритм, який дав назву з’єднанню вкладених ціклов.Все рядки повинні піддатися порівнянні, і, таким чином, вартість цього алгоритму пропорційна розміру зовнішньої таблиці, помноженому на розмір внутрішньої таблиці. Оскільки при збільшенні розмірів з’єднуються таблиць вартість зростає дуже сильно, на практиці її зменшують шляхом скорочення вибірки з внутрішньої таблиці, рядки якої обробляються для кожного рядка зовнішньої таблиці.

джерела:

Merge Join на відміну від з’єднання вкладених циклів, яке підтримує будь-які предикати з’єднання, вимагає існування не менше одного предиката з’єднання по еквівалентності. Крім того, одержувані з’єднанням злиттям дані повинні бути відсортовані по ключу з’єднання. Наприклад, якщо ми маємо предикат з’єднання «T1.a = T2.b», таблиця T1 повинна бути відсортована по T1.a, а таблиця T2 повинна бути сортована по T2.b.

З’єднання злиттям одночасно зчитує і порівнює два відсортованих вхідних потоку, по одному рядку за крок. На кожному з цих кроків відбувається порівняння з наступним рядком вхідного потоку. Якщо рядки рівні, виводиться приєднується рядок, і процес триває далі. Якщо рядки не рівні, виключається менше з двох вхідних значень, і процес триває. Так як вхідні потоки відсортовані, легко видно, що виключається рядок буде менше будь-який з решти рядків в будь-якому з вхідних потоків і, таким чином, не повинна брати участь в з’єднанні.

джерела:

Hash Join має багато спільного з з’єднанням злиттям. Подібно з’єднанню злиттям, для нього потрібні не менше одного предиката об’єднання по еквівалентності, воно підтримує залишкові предикати, а також всі зовнішні з’єднання і напівз’єднання. На відміну від з’єднання злиттям, для нього не потрібна наявність упорядкованих вхідних потоків і для підтримки повного зовнішнього з’єднання потрібна наявність предиката з’єднання по еквівалентності.

Hash Join виконується в дві стадії: компоновка і проба. Під час компонування здійснюється читання всіх рядків першого вхідного потоку (часто, його називають лівим потоком або потоком компонування), хешування рядків по ключам з’єднання еквівалентності і створення в оперативній пам’яті хеш-таблиці. Під час проби здійснюється читання всіх рядків другого вхідного потоку (часто його називають правим потоком або пробним потоком), хешування рядків цього потоку по тим же ключам з’єднання еквівалентності, а потім здійснюється перегляд або пошук відповідників рядків в хеш-таблиці. Так як хеш-функції можуть бути схильні до колізій (два різних значення ключа мають однаковий хеш), доводиться перевіряти кожне потенційне відповідність, що необхідно для гарантії того, що в цьому випадку дійсно схожість зумовлена ​​з’єднанням, а не колізією.

джерела:

Дивіться також:

06.24 – 1

Hash Join має багато спільного з з’єднанням злиттям. Подібно з’єднанню злиттям, для нього потрібні не менше одного предиката об’єднання по еквівалентності, воно підтримує залишкові предикати, а також всі зовнішні з’єднання і напівз’єднання. На відміну від з’єднання злиттям, для нього не потрібна наявність упорядкованих вхідних потоків і для підтримки повного зовнішнього з’єднання потрібна наявність предиката з’єднання по еквівалентності.

Hash Join виконується в дві стадії: компоновка і проба. Під час компонування здійснюється читання всіх рядків першого вхідного потоку (часто, його називають лівим потоком або потоком компонування), хешування рядків по ключам з’єднання еквівалентності і створення в оперативній пам’яті хеш-таблиці. Під час проби здійснюється читання всіх рядків другого вхідного потоку (часто його називають правим потоком або пробним потоком), хешування рядків цього потоку по тим же ключам з’єднання еквівалентності, а потім здійснюється перегляд або пошук відповідників рядків в хеш-таблиці. Так як хеш-функції можуть бути схильні до колізій (два різних значення ключа мають однаковий хеш), доводиться перевіряти кожне потенційне відповідність, що необхідно для гарантії того, що в цьому випадку дійсно схожість зумовлена ​​з’єднанням, а не колізією.

джерела:

06.25 – 3

Merge Join на відміну від з’єднання вкладених циклів, яке підтримує будь-які предикати з’єднання, вимагає існування не менше одного предиката з’єднання по еквівалентності. Крім того, одержувані з’єднанням злиттям дані повинні бути відсортовані по ключу з’єднання. Наприклад, якщо ми маємо предикат з’єднання «T1.a = T2.b», таблиця T1 повинна бути відсортована по T1.a, а таблиця T2 повинна бути сортована по T2.b.

З’єднання злиттям одночасно зчитує і порівнює два відсортованих вхідних потоку, по одному рядку за крок. На кожному з цих кроків відбувається порівняння з наступним рядком вхідного потоку. Якщо рядки рівні, виводиться приєднується рядок, і процес триває далі. Якщо рядки не рівні, виключається менше з двох вхідних значень, і процес триває. Так як вхідні потоки відсортовані, легко видно, що виключається рядок буде менше будь-який з решти рядків в будь-якому з вхідних потоків і, таким чином, не повинна брати участь в з’єднанні.

джерела:

Дивіться також:

06.26 – 1

оператор Nested Loops в спрощеному вигляді порівнює кожен рядок однієї таблиці (званої зовнішньої таблицею) з кожної рядку іншої таблиці (званої внутрішньої таблицею), шукаючи ті рядки, які задовольняють предикату з’єднання. 

Утворені вкладені цикли і представляють той самий алгоритм, який дав назву з’єднанню вкладених ціклов.Все рядки повинні піддатися порівнянні, і, таким чином, вартість цього алгоритму пропорційна розміру зовнішньої таблиці, помноженому на розмір внутрішньої таблиці. Оскільки при збільшенні розмірів з’єднуються таблиць вартість зростає дуже сильно, на практиці її зменшують шляхом скорочення вибірки з внутрішньої таблиці, рядки якої обробляються для кожного рядка зовнішньої таблиці.

джерела:

Дивіться також:

06.27 – 1

оператор Nested Loops в спрощеному вигляді порівнює кожен рядок однієї таблиці (званої зовнішньої таблицею) з кожної рядку іншої таблиці (званої внутрішньої таблицею), шукаючи ті рядки, які задовольняють предикату з’єднання. 

Утворені вкладені цикли і представляють той самий алгоритм, який дав назву з’єднанню вкладених ціклов.Все рядки повинні піддатися порівнянні, і, таким чином, вартість цього алгоритму пропорційна розміру зовнішньої таблиці, помноженому на розмір внутрішньої таблиці. Оскільки при збільшенні розмірів з’єднуються таблиць вартість зростає дуже сильно, на практиці її зменшують шляхом скорочення вибірки з внутрішньої таблиці, рядки якої обробляються для кожного рядка зовнішньої таблиці.

джерела:

Merge Join на відміну від з’єднання вкладених циклів, яке підтримує будь-які предикати з’єднання, вимагає існування не менше одного предиката з’єднання по еквівалентності. Крім того, одержувані з’єднанням злиттям дані повинні бути відсортовані по ключу з’єднання. Наприклад, якщо ми маємо предикат з’єднання «T1.a = T2.b», таблиця T1 повинна бути відсортована по T1.a, а таблиця T2 повинна бути сортована по T2.b.

З’єднання злиттям одночасно зчитує і порівнює два відсортованих вхідних потоку, по одному рядку за крок. На кожному з цих кроків відбувається порівняння з наступним рядком вхідного потоку. Якщо рядки рівні, виводиться приєднується рядок, і процес триває далі. Якщо рядки не рівні, виключається менше з двох вхідних значень, і процес триває. Так як вхідні потоки відсортовані, легко видно, що виключається рядок буде менше будь-який з решти рядків в будь-якому з вхідних потоків і, таким чином, не повинна брати участь в з’єднанні.

джерела:

Hash Join має багато спільного з з’єднанням злиттям. Подібно з’єднанню злиттям, для нього потрібні не менше одного предиката об’єднання по еквівалентності, воно підтримує залишкові предикати, а також всі зовнішні з’єднання і напівз’єднання. На відміну від з’єднання злиттям, для нього не потрібна наявність упорядкованих вхідних потоків і для підтримки повного зовнішнього з’єднання потрібна наявність предиката з’єднання по еквівалентності.

Hash Join виконується в дві стадії: компоновка і проба. Під час компонування здійснюється читання всіх рядків першого вхідного потоку (часто, його називають лівим потоком або потоком компонування), хешування рядків по ключам з’єднання еквівалентності і створення в оперативній пам’яті хеш-таблиці. Під час проби здійснюється читання всіх рядків другого вхідного потоку (часто його називають правим потоком або пробним потоком), хешування рядків цього потоку по тим же ключам з’єднання еквівалентності, а потім здійснюється перегляд або пошук відповідників рядків в хеш-таблиці. Так як хеш-функції можуть бути схильні до колізій (два різних значення ключа мають однаковий хеш), доводиться перевіряти кожне потенційне відповідність, що необхідно для гарантії того, що в цьому випадку дійсно схожість зумовлена ​​з’єднанням, а не колізією.

джерела:

Дивіться також:

06.28 – 1

При написанні запитів не слід використовувати з’єднання з вкладеними запитами. Слід з’єднувати один з одним тільки об’єкти метаданих або тимчасові таблиці. Якщо запит використовує з’єднання з вкладеними запитами, то його слід переписати з використанням тимчасових таблиць (не важливо з якого боку з’єднання знаходиться вкладений запит), крім випадку, коли вкладений запит сканує мало записів.

Якщо запит містить сполуки з вкладеними запитами, то це може привести до наступних негативних наслідків:

  • Вкрай повільне виконання запиту при слабкій завантаженні серверного обладнання. Уповільнення запиту може бути дуже значним (до декількох порядків);
  • Нестабільна робота запиту. При деяких умовах запит може працювати досить швидко, при інших – дуже повільно;
  • Значна різниця за часом виконання запиту на різних СУБД;
  • Підвищена чутливість запиту до актуальності і повноти статистик. Відразу після завершення оновлення статистик запит може працювати швидко, але через деякий час знову сповільнитися.

Оптимізатор сервера СУБД (незалежно від того, яку СУБД ви використовуєте) не завжди може правильно оптимізувати подібний запит. В даному випадку, проблемою для оптимізатора є вибір правильного способу з’єднання. Існують різні алгоритми з’єднання двох вибірок. Вибір того чи іншого алгоритму залежить від того, скільки записів буде міститися в одній і в іншій вибірці. У тому випадку, якщо ви поєднуєте дві фізичні таблиці, СУБД може легко визначити обсяг обох вибірок на підставі наявної статистики. Якщо ж одна із з’єднуваних вибірок є вкладений запит, то зрозуміти, яка кількість записів вона поверне, стає дуже складно. В цьому випадку СУБД може помилитися з вибором плану, що призведе до катастрофічного падіння продуктивності запиту.

джерело:

06.29 – 3

При написанні запитів не слід використовувати з’єднання з вкладеними запитами. Слід з’єднувати один з одним тільки об’єкти метаданих або тимчасові таблиці. Якщо запит використовує з’єднання з вкладеними запитами, то його слід переписати з використанням тимчасових таблиць (не важливо з якого боку з’єднання знаходиться вкладений запит), крім випадку, коли вкладений запит сканує мало записів.

Якщо запит містить сполуки з вкладеними запитами, то це може привести до наступних негативних наслідків:

  • Вкрай повільне виконання запиту при слабкій завантаженні серверного обладнання. Уповільнення запиту може бути дуже значним (до декількох порядків);
  • Нестабільна робота запиту. При деяких умовах запит може працювати досить швидко, при інших – дуже повільно;
  • Значна різниця за часом виконання запиту на різних СУБД;
  • Підвищена чутливість запиту до актуальності і повноти статистик. Відразу після завершення оновлення статистик запит може працювати швидко, але через деякий час знову сповільнитися.

Оптимізатор сервера СУБД (незалежно від того, яку СУБД ви використовуєте) не завжди може правильно оптимізувати подібний запит. В даному випадку, проблемою для оптимізатора є вибір правильного способу з’єднання. Існують різні алгоритми з’єднання двох вибірок. Вибір того чи іншого алгоритму залежить від того, скільки записів буде міститися в одній і в іншій вибірці. У тому випадку, якщо ви поєднуєте дві фізичні таблиці, СУБД може легко визначити обсяг обох вибірок на підставі наявної статистики. Якщо ж одна із з’єднуваних вибірок є вкладений запит, то зрозуміти, яка кількість записів вона поверне, стає дуже складно. В цьому випадку СУБД може помилитися з вибором плану, що призведе до катастрофічного падіння продуктивності запиту.

джерело:

06.30 – 3

При написанні запитів не слід використовувати з’єднання з вкладеними запитами. Слід з’єднувати один з одним тільки об’єкти метаданих або тимчасові таблиці. Якщо запит використовує з’єднання з вкладеними запитами, то його слід переписати з використанням тимчасових таблиць (Не важливо з якого боку з’єднання знаходиться вкладений запит), крім випадку, коли вкладений запит сканує мало записів.

  • Вкрай повільне виконання запиту при слабкій завантаженні серверного обладнання. Уповільнення запиту може бути дуже значним (до декількох порядків);
  • Нестабільна робота запиту. При деяких умовах запит може працювати досить швидко, при інших – дуже повільно;
  • Значна різниця за часом виконання запиту на різних СУБД;
  • Підвищена чутливість запиту до актуальності і повноти статистик. Відразу після завершення оновлення статистик запит може працювати швидко, але через деякий час знову сповільнитися.

Оптимізатор сервера СУБД (незалежно від того, яку СУБД ви використовуєте) не завжди може правильно оптимізувати подібний запит. В даному випадку, проблемою для оптимізатора є вибір правильного способу з’єднання. Існують різні алгоритми з’єднання двох вибірок. Вибір того чи іншого алгоритму залежить від того, скільки записів буде міститися в одній і в іншій вибірці. У тому випадку, якщо ви поєднуєте дві фізичні таблиці, СУБД може легко визначити обсяг обох вибірок на підставі наявної статистики. Якщо ж одна із з’єднуваних вибірок є вкладений запит, то зрозуміти, яка кількість записів вона поверне, стає дуже складно. В цьому випадку СУБД може помилитися з вибором плану, що призведе до катастрофічного падіння продуктивності запиту.

джерело:

06.31 – 4

Якщо в запиті використовується з’єднання з віртуальною таблицею мови запитів 1С: Підприємства (наприклад, РегістрНакопленія.Товари.Остаткі ()) і запит працює з незадовільною продуктивністю, то рекомендується винести звернення до віртуальної таблиці в окремий запит із збереженням результатів у тимчасової таблиці.

джерело:

06.32 – 3

У мові запитів можливо звертатися не тільки до полів вихідних таблиць запиту, перерахованих в реченні ІЗ, а й до полів таблиці, на яку посилається поле вихідної таблиці запиту, якщо це поле має контрольний тип. Імена полів при цьому пишуться «через точку». Застосування такої конструкції призводить до неявному з’єднанню з додатковими таблицями для отримання значень полів «через точку».

Велике число вихідних таблиць запиту призводить до його ускладнення і може значно збільшувати час його виконання. Особливо це важливо пам’ятати в тих випадках, коли поле таблиці посилального типу має складовою тип і може містити посилання на кілька таблиць. В такому випадку, отримання полів інших таблиць «через точку» від такого поля складеного типу призведе до з’єднання з усіма таблицями, посилання на які можуть виявитися в даному полі і в RLS до цих таблиць.

Для того щоб уникнути запитів з використанням великої кількості вихідних таблиць слід жертвувати компактністю зберігання даних заради продуктивності і поміщати відповідні дані в вихідну таблицю запиту.

При необхідності слід жертвувати компактністю і універсальністю коду заради продуктивності:

  • Як правило, для виконання конкретного запиту в даних умовах не потрібні всі можливі типи даної посилання. В цьому випадку, слід обмежити кількість можливих типів за допомогою функції ВИРАЗИТИ.
  • Якщо даний запит є універсальним і використовується в декількох різних ситуаціях (де типи посилання можуть бути різними), то можна формувати запит динамічно, підставляючи в функцію ВИРАЗИТИ той тип, який необхідний при даних умовах.

Це збільшить обсяг вихідного коду і, можливо, зробить його менш універсальним, але може істотно підвищити продуктивність і стабільність роботи запиту.

джерело:

06.33 – 2

У мові запитів можливо звертатися не тільки до полів вихідних таблиць запиту, перерахованих в реченні ІЗ, а й до полів таблиці, на яку посилається поле вихідної таблиці запиту, якщо це поле має контрольний тип. Імена полів при цьому пишуться «через точку». Застосування такої конструкції призводить до неявному з’єднанню з додатковими таблицями для отримання значень полів «через точку».

Велике число вихідних таблиць запиту призводить до його ускладнення і може значно збільшувати час його виконання. Особливо це важливо пам’ятати в тих випадках, коли поле таблиці посилального типу має складовою тип і може містити посилання на кілька таблиць. В такому випадку, отримання полів інших таблиць «через точку» від такого поля складеного типу призведе до з’єднання з усіма таблицями, посилання на які можуть виявитися в даному полі і в RLS до цих таблиць.

Для того щоб уникнути запитів з використанням великої кількості вихідних таблиць слід жертвувати компактністю зберігання даних заради продуктивності і поміщати відповідні дані в вихідну таблицю запиту.

При необхідності слід жертвувати компактністю і універсальністю коду заради продуктивності:

  • Як правило, для виконання конкретного запиту в даних умовах не потрібні всі можливі типи даної посилання. В цьому випадку, слід обмежити кількість можливих типів за допомогою функції ВИРАЗИТИ.
  • Якщо даний запит є універсальним і використовується в декількох різних ситуаціях (де типи посилання можуть бути різними), то можна формувати запит динамічно, підставляючи в функцію ВИРАЗИТИ той тип, який необхідний при даних умовах.

Це збільшить обсяг вихідного коду і, можливо, зробить його менш універсальним, але може істотно підвищити продуктивність і стабільність роботи запиту.

джерело:

06.34 – 1

Основні причини неоптимальною роботи запитів, діагностуються на рівні коду конфігурації і структури метаданих:

  • з’єднання з підзапитах
  • з’єднання з віртуальними таблицями
  • невідповідність індексів і умов запиту
  • використання логічного АБО в умовах
  • використання підзапитів в умови з’єднання
  • отримання даних через точку від полів складеного типу
  • фільтрація віртуальних таблиць без використання параметрів

джерело:

06.35 – 4

Переконайтеся в тому, що для всіх умов, використаних в запиті, є відповідні індекси.

Умови використовуються в наступних секціях запиту:

  • ВИБРАТИ … ІЗ … ДЕ <умова>
  • З’ЄДНАННЯ … ПО <умова>
  • ВИБРАТИ … ІЗ <ВіртуальнаяТабліца>(, <умова>)
  • МАЮТЬ <умова>

Для кожного умови повинен існувати відповідний індекс. Відповідним є індекс, що задовольняє наступним вимогам:

  1. Індекс містить всі поля перераховані в умови;
  2. Ці поля знаходяться в самому початку індексу;
  3. Ці поля йдуть підряд, тобто між ними не «вклинюються» поля, які не беруть участі в умови запиту;

джерело:

06.36 – 6

Підтвердження не знайшов, але очевидно, що підходять всі представлені варіанти відповідей, а саме:

  • Повільне виконання запиту при слабкій навантаженні на обладнання
  • Виникнення надлишкових блокувань.
  • Значна різниця за часом виконання запиту на різних СУБД.
  • Підвищена чутливість запиту до актуальності і повноти статистик.
  • Нестабільна робота запиту. При деяких умовах запит може працювати досить швидко, при інших – дуже повільно.

06.37 – 1

JOIN додає стовпці в результуючу таблицю, а UNION додає таблицю з тим же складом стовпців.

джерела:

06.38 – 2

При UNION повністю однакові рядки замінюються однією, на що витрачається додатковий час, навіть у випадках, коли однакових рядків в запитах свідомо бути не може.

джерело:

06.39 – 1

select
dbo_document180
where _number ‘ТД00%’
order _number

джерело:

06.40 – 3

delete
dbo_document180
where _number ‘ТД00-000003’

джерело:

06.41 – 1

delete
dbo_document180
where _number ‘ТД00-000003’

джерело:

06.42 – 2

select _number posted
dbo_document180
where _number ‘ТД00%’
 
union
 
select _number posted
dbo_document182 o
 
rder _number

джерело:

06.43 – 1

select
dbodocument180
inner dbodocument180_vt4131
dbodocument180_idrref dbodocument180_vt4131_idrref
where dbodocument180_number ‘ТД00%’

З’єднання outer join не існує.

Ссылка на основную публикацию