Решение всех вопросов теста 1С:Профессионал по технологическим вопросам (Раздел №6)

   


Ниже приводится решение всех вопросов для подготовки к аттестации 1С:Профессионал по технологическим вопросам. Текстов самих вопросов и вариантов ответов нет. Предполагается, что у вас имеется книга «Комплект вопросов сертификационного экзамена «1С:Профессионал» по технологическим вопросам с примерами решений». Я ни в комем случае не призываю заучивать ответы, а рекомендую прорешивать и анализировать каждый вопрос, ведь сдача данного экзамена, это лишь первый шаг к сертификации 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 * 
from dbo._document180 
where _number like 'ТД00%' 
order by _number

Источник:

06.40 — 3

delete 
from dbo._document180 
where _number = 'ТД00-000003'

Источник:

06.41 — 1

delete 
from dbo._document180 
where _number = 'ТД00-000003'

Источник:

06.42 — 2

select _number, posted 
from dbo._document180 
where _number like 'ТД00%' 
 
union all 
 
select _number, posted 
from dbo._document182 o
 
rder by _number

Источник:

06.43 — 1

select * 
from dbo.document180 
    inner join dbo.document180_vt4131 
    on dbo.document180._idrref = dbo.document180_vt4131._idrref 
where dbo.document180._number like 'ТД00%'

Соединения outer join не существует.

Источник:

06.44 — 3

DBORACLE ‑ исполнение операторов SQL СУБД Oracle Database

Источник:

06.45 — 3

DB2 ‑ исполнение операторов SQL СУБД DB2

Источник:

06.46 — 3

DBPOSTGRS ‑ исполнение операторов SQL СУБД PostgreSQL

Источник:

06.47 — 4

DBV8DBENG ‑ исполнение операторов SQL файловой СУБД

Источник:

06.48 — 2

EDS ‑ работа с внешними источниками данных

Источник:

Помогла ли вам данная статья?
Да, спасибо, помогла.
Немного помогла.
Совсем не помогла.
Не то, что я искал(а).
Смотреть результаты
Запись опубликована в рубрике Эксперт 1С с метками , . Добавьте в закладки постоянную ссылку.


10 Responses to Решение всех вопросов теста 1С:Профессионал по технологическим вопросам (Раздел №6)

  1. Concrete говорит:

    Скажите, а ответы на разделы с 7 по 14 будут выкладываться?

  2. Concrete говорит:

    Здравствуйте! Огромное спасибо за решения. Скажите, разделы 7 — 14 выкладываться будут?

  3. Дмитрий говорит:

    Отличная статья, помогло, будут ли статьи по разделам 7 — 14 ?

  4. CSiER говорит:

    06.13 — 2 — запись попадает в ТЖ в момент завершения события, при этом указывается время окончания и длительность (сам формат не предполагает записи в момент возникновения).

  5. Виталий Онянов говорит:

    Вышел новый сборник задач (издание 2). Сначала эти статьи надо переписать, потом продолжу. Есть в планах, да.

    • Аноним говорит:

      Спасибо, очень ждем

    • Петр говорит:

      Виталий, я прошёл 6 разделов с комплектом вопросов редакции 2 и нашёл только одно отличие, отписал в комментариях раздела. То есть все эти статьи переписывать нет нужды, они по прежнему актуальны.
      Далее я продолжаю двигаться по сборнику вопросов и в любом случае буду конспектировать информацию по ответам для себя. Если это поможет при наполнении сайта, то могу поделиться информацией.

      • Виталий Онянов говорит:

        Да, конечно, я сам после сдачи экзамена к продолжению цикла статей интерес потерял. Если у вас будет готовый материал — с радостью опубликую.

      • Антон говорит:

        Пётр, очень надо. Зачёт в карму, если победите этот вопрос.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *