Понимание и использование параллелизма в SQL Server

Публикация № 298872

Администрирование - Администрирование данных 1С

СКЛ SQL параллелизм parallelism

В введении в параллелизм мы использовали простой запрос, и связанный с ним реальный пример, чтобы исследовать модель, используемую SQL Server, чтобы позволить запросам автоматически извлечь выгоду из дополнительной вычислительной мощности, предоставляемой современными многоядерными серверами, не требуя от разработчика учитывать некоторые сложности, обычно связанные с многопоточной конструкцией.

3 марта 2011

Пол Уайт 

Оригинал статьи

Авторский перевод статьи, поэтому, если заметите какие-либо неточности, прошу отметить в комментариях.

SQLServer способен к неявному использованию параллелизма для ускорения запросов SQL. Как он это делает, и как вы можете быть уверены, что он это делает,  не совсем очевидно для большинства из нас. Пол Уайт начинает серию, которая делает все это простым для понимания, начиная с легкого уровня подсчета фасоли.

Многие опытные профессионалы баз данных приобрели несколько искаженный взгляд на параллельное выполнение запросов. Иногда это является следствием неудачных опытов с более ранними версиями SQLServer.  Однако,  часто, этот взгляд является результатом заблуждений, или недостаточностью мастерства владения методами, необходимыми для эффективной разработки и настройки запросов для параллельного выполнения.

Это первая в серии статей, которая обеспечит читателя с глубокими знаниями, необходимой информацией для использования параллельных функций обработки запросов, доступных в Microsoft SQL Server. Часть первая представляет собой пошаговое руководство по основам параллелизма в SQ LServer, освещая такие понятия, как «параллельное сканирование и поиск» (“parallel scans and seeks”), «работники» (“workers”), «потоки» (“threads”), «задачи»(” tasks”), «контекст выполнения» (“execution contexts”) и «операторы обмена» (“exchange operators”), которые координируют параллельную деятельность.

Будущие статьи обеспечат более полное представление о внутренней работе databaseengine, и покажут, как целенаправленный параллелизм может принести пользу не только хранилищам данных и системам поддержки принятия решений, обычно связанных с его использованием.

Часто думают, что основная нагрузка на систему ложится, прежде всего, при обработке транзакций (OLTP), однако, системы часто содержат запросы и процедуры, которые могли бы выиграть от надлежащего использования параллелизма.

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

Что такое параллелизм? 

Вы, наверное, слышали фразу "Много рук делают легкую работу". Идея состоит в том, что разделение задачи между несколькими людьми приводит к тому, что каждый человек делает меньше. С точки зрения отдельного человека, работа кажется гораздо легче, хотя это такое же количество работы, что делается в целом. Что еще более важно, если дополнительные люди могут выполнять их распределенные работы одновременно,  то общее время, необходимое для выполнения этой задачи уменьшается. 

Подсчет фасоли 

Представьте, что вы держите в руках большую стеклянную банку полную фасоли, и вас попросили её посчитать. Предположим, что вы в состоянии считать в среднем пять фасолин в секунду, это займет у вас чуть более десяти минут, чтобы определить, что именно этот сосуд содержит 3027 фасоли.

Если четыре ваших друга предлагают помочь с задачей, вы можете выбрать из ряда возможных стратегий, но давайте рассмотрим тот вариант, который четко отражает  стратегию SQL Server. Вы усадить своих друзей за столом с банкой в его центре и одним совком для извлечения бобов из банки. Вы попросите их, чтобы они использовали совок, когда нужно больше фасоли для подсчета. Каждый из друзей также имеет ручку и листок бумаги, чтобы сохранять текущую сумму количества фасоли, которое они подсчитали.

Как только человек заканчивает подсчет и находит банку пустой, каждый отдает свой общий индивидуальный итог вам. Вы собираете каждый промежуточный итог и добавляете его в общий итог. Когда вы получили промежуточный итог от каждого из ваших друзей, задача выполнена. С четырьмя людьми, считающими фасоль одновременно, вся задача выполнена в течение около двух с половиной минут - четырехкратным улучшением по сравнению с тем, если бы вы считали их все самостоятельно. Конечно, четыре человека работали в общей сложности десять минут (плюс несколько секунд, которые потребовались вам для того, чтобы добавить последний итог в общий итог).

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

Подсчет фасоли с SQL Server

SQL Server не может подсчитывать фасоль, поэтому мы попросим его подсчитать количество строк в таблице. Если таблица небольшая, SQL Server, скорее всего,  будет использовать план выполнения, как показано на рисунке 1. 


Рисунок 1: Последовательный план подсчета (Serial Counting Plan)

Этот план запроса использует одного рабочего - считает всю фасоль самостоятельно. Сам план очень прост: оператор “Stream Aggregate” подсчитывает строки, которые он получает от оператора “Index Scan” и возвращает результат как только все строки были обработаны. Вы могли бы выбрать подобную стратегию, если банка с фасолью была бы почти пуста, так как вы вряд ли сэкономите много времени, разделив небольшое количество фасоли среди ваших друзей, и дополнительные работники могли бы даже замедлить процесс, в связи с дополнительной стадией подсчета итогов.

С другой стороны, если таблица является достаточно большой, оптимизатор SQL Server может выбрать дополнительных работников, используя план запроса, как показано на рисунке 2. 


Рисунок 2: Параллельный план подсчета (Parallel Counting Plan)

Маленькие желтые значки со стрелками показывают операции, которые включают несколько работников. Каждому работнику назначается отдельная часть работы, и частичные результаты затем объединяют с получением конечного результата. Как показано в примере ручного подсчета фасоли, параллельный план имеет все шансы, чтобы завершиться значительно быстрее, чем последовательный план, потому что несколько работников будут активно подсчитывать строки одновременно.

Как параллелизм работает

Представьте себе на минуту, что SQL Server не имеет встроенную поддержку параллелизма. Вы могли бы попытаться повысить производительность оригинального запроса подсчета строк, вручную разбив запрос на одинаковые по размеру кусочки и запустив каждый из них одновременно на отдельном подключении к серверу. 


Рисунок 3: Ручной параллелизм (Manual Parallelism)

Каждый запрос на рисунке 3 написан для обработки отдельного диапазона строк таблицы, гарантируя, что каждая строка из таблицы обрабатывается только один раз в целом. Если повезет, SQL Server запустит каждый запрос на отдельном блоке обработки, и вы могли бы рассчитывать на получение трех частичных результатов примерно в треть времени. Естественно, вам все равно потребуется выполнить дополнительную стадию объединения результатов, чтобы получить правильный конечный результат.

Параллельное выполнение как множество последовательных планов

Пример «Ручного параллелизма» не столь далек от того, как SQL Server фактически осуществляет свою параллельную работу с запросами. Вспомним план параллельных запросов на рисунке 2, и предположим, что SQL Server выделяет три дополнительных работника на запрос во время его выполнения. Концептуально, мы можем перерисовать параллельный план, чтобы показать, что SQL Server запускает три последовательных плана одновременно (это представление не совсем точно, но мы это исправим в ближайшее время). 


Рисунок 4: Множество последовательных планов (Multiple Serial Plans) 

Каждому дополнительному работнику присваивается один из трех ветвей плана, которые сливаются  в оператор Сбора Потоков (Gather Streams operator). Обратите внимание, что только оператор Сбора Потоков (Gather Streams operator) содержит маленькую желтую иконку параллелизма; это сейчас единственный оператор, который взаимодействует с несколькими работниками. Эта общая стратегия подходит SQL Server по двум основным причинам. Во-первых, весь код, который SQL Server необходимо выполнить для реализации последовательных планов уже существует и был оптимизирован в течение многих лет и релизов продукта. Во-вторых, этот метод очень хорошо масштабируется: если больше работников доступно во время выполнения, SQL Server может легко добавить дополнительные ветви плана чтобы распределить работу на большее количество работников.

Количество дополнительных работников, которых SQL Server присваивает каждой области параллельного плана во время выполнения известно как степень параллелизма (Degree of parallelism - часто сокращенно DOP). SQL-сервер выбирает DOP непосредственно перед началом выполнение запроса, и это значение может меняться между выполнениями запроса без необходимости повторной компиляции плана. Максимальная DOP для каждой параллельной области определяется количеством логических блоков обработки (logical processing units) видимых SQL Server.

Параллельное сканирование (Parallel Scan) и поставщик параллельных страниц (Parallel Page Supplier)

Проблемой в концептуальном плане, показанном на рисунке 4, является то, что каждый оператор Index Scan будет считать каждую строку во всей совокупности ввода. Левая часть некорректна, план будет выдавать неправильные результаты и, вероятно, займет больше времени для выполнения, чем последовательная версия. Ручной пример параллелизма избежал этой проблемы, используя явное «ГДЕ» (“WHERE”) в каждом запросе и разделил входные строки на три одинаковых по размеру диапазона.

SQL Server не использует тот же подход, потому что, распределяя работу равномерно, можно предположить, что каждый запрос будет получать равную долю доступных вычислительных ресурсов, и что каждая строка данных потребует одинаковое усилие для обработки. В качестве простого примера, такого как подсчет строк в таблице (на сервере без другой деятельности) эти предположения вполне могут иметь место и три запроса могут действительно вернуть свои частичные результаты примерно за то же время.

В целом, однако, можно легко привести примеры, где эти предположения не будут допускаться в реальном мире, в связи с некоторым числом внешних или внутренних факторов. Например, один из запросов может быть запланирован на тот же логический процессор, который занят продолжительной  массовой загрузкой, в то время как другие остаются без нагрузки. В качестве альтернативы рассмотрим запрос, который включает в себя операцию соединения (Join), где объем работ, необходимых для обработки конкретной строки сильно зависит от того, соответствует ли она условию соединения или нет. Если некоторые запросы содержат больше соединяющих строк, чем другие, то время выполнения может варьироваться в широких пределах и общая производительность будет ограничена скоростью самого медленного работника.

Вместо того чтобы выделять фиксированное количество строк для каждого работника, SQL Server использует функцию хранения под названием поставщик параллельных страниц (Parallel Page Supplier) для распределения строк среди работников по требованию. Вы не увидите Parallel Page Supplierв графическом плане запроса, потому что он не является частью процессора запросов, но мы можем продлить иллюстрацию рисунка 4, чтобы показать, где он будет находиться и его связи:


Рисунок 5: Поставщик параллельных страниц (Parallel Page Supplier) 

Важным моментом является то, что это схема на основе спроса; Parallel Page Supplier отвечает на запросы работников, обеспечивая партию строк любому работнику, который должен еще поработать. Возвращаясь к аналогии подсчета фасоли, Parallel Page Supplier представлен совком, используемым для извлечения фасоли из банки. Один общий совок гарантирует, что нет двух людей, подсчитывающих ту же фасоль, с другой стороны, нет ничего, что может препятствовать человеку забирать больше фасоли для подсчета по мере необходимости. В частности, если один человек работает медленнее, чем другие, то этот человек просто реже пользуется совком, и другие работники будут подсчитывать больше фасоли, чтобы компенсировать это.

В SQL Server медленный работник делает меньше запросов к Parallel Page Supplier и таким образом обрабатывает меньше строк. Это не влияет на работу других работников, и они продолжают обработку строк в их максимальной производительности. Таким образом, схема на основе спроса обеспечивает определенную степень устойчивости к изменениям в рабочей пропускной способности. Вместо того чтобы быть связанным по скорости самого медленного работника, производительность схемы на основе спроса уменьшается незначительно, если у отдельного работника снижается производительность. Тем не менее, тот факт, что каждый работник может обрабатывать значительно отличающиеся количества строк, в зависимости от условий среды выполнения, может вызвать другие проблемы (к этой теме мы вернемся позже в этой серии).

Обратите внимание, что использование Parallel Page Supplier не мешает SQL Server использовать существующие оптимизации, такие как сканирование опережающего чтения (read-ahead scanning) (предварительную выборку данных из постоянного хранения). На самом деле, это может быть даже немного более эффективным  для трех работников  потребляющих строки из одного, базового физического сканирования, а не из трех отдельных сканов областей, которые мы видели в ручном примере параллелизма.

Parallel Page Supplier также не ограничивается использованием сканирования индексов; SQL Server использует Parallel Page Supplier всякий раз, когда несколько работников совместно читают структуру данных. Эта структура данных может быть массив, кластерная таблица или индекс, и операция может быть либо сканирования (scan) либо поиска (seek). Если последний пункт удивляет вас, считают, что Index Seek лишь частичное сканирование (scan) т.е. она стремится найти первую отобранную (qualifying) строку, а затем сканирует до конца отобранного диапазона.

Контексты исполнения (Execution Contexts)

Обратимся теперь к отдельным серверным соединениям, используемым в ручном примере параллелизма для достижения одновременного выполнения. Это не было бы эффективным для SQL Server, фактически создать несколько новых соединений для выполнения каждого параллельного запроса, но реальный механизм во многом похож. Вместо того, чтобы создавать отдельное соединение для каждого последовательного запроса, SQL Server использует облегченную конструкцию, известную как контексты исполнения (Execution Contexts).

Контекст выполнения происходит от части плана запроса, во время выполнения, заполняя детали, которые не были известны в то время, когда план был скомпилирован и оптимизирован. Эти детали включают ссылки на объекты, которые не существуют до момента выполнения (временная таблица, созданная в рамках одного пакета, например) и значения любых параметров и локальных переменных. Более подробная информация о контекстах - Microsoft White Page.

SQL Server запускает параллельный план, выводя контексты выполнения DOP для каждой параллельной области плана запроса, с использованием отдельного работника для запуска части последовательного плана содержащегося в каждом контексте. Для облегчения понимания концепции, на рисунке 6 показаны четыре контекста выполнения  созданных для параллельного плана подсчета, над которым мы работали до сих пор. Каждый цвет определяет область контекста исполнения, и хотя это не показано явно, Parallel Page Supplier снова используется для координации индексов. 


Рисунок 6: Контексты выполнения параллельного плана 

Самый левый контекст выполнения плана параллельного запроса (отображается красным цветом, на рисунке 6) играет особую координирующую роль и выполняется работником подключения , отправившего запрос. Это "первый" контекст выполнения известен как нулевой контекст выполнения, и связанный работник известен как нулевой поток (thread zero). Мы определим некоторые из этих терминов более точно в следующем разделе, а пока предположим, что «работник» и «поток» (thread) означает примерно то же самое.

Чтобы получить более конкретное представление абстрактных понятий, введенных в этом разделе, Рисунок 7 показывает информацию, полученную путем запуска параллельного запроса подсчета строк, с помощью опции SQL Server Management Studio (SSMS), «Include Actual Execution Plan».


Рисунок 7: параллельный план подсчета строк

Выноски показывают количество строк, обработанных каждым работником (потоком) в двух различных точках в плане. Информация поступила из окна SSMS Properties, которое может быть доступно при нажатии на оператора (или соединительной линии) и клавиши F4. Кроме того, вы можете щелкнуть правой кнопкой мыши на операторе или линии и выбрать «Свойства» («Properties») из всплывающего меню.

Читая справа, мы видим сколько строк рассчитывает каждый из трех работников в параллельной части плана; прошу заметить, что два работника обрабатывают приблизительно равное количество строк (около 40 000), а третий получает всего 32 000 строк из Parallel Page Supplier. Как уже говорилось ранее, процесс основанный на спросе означает, что точное число строк, обработанных каждым работником зависит от временных показателей и загрузки процессоров (в числе прочего) и часто колеблется между выполнениями запросов, даже на легкозагруженой машине.

Левая часть диаграммы показывает три частичных результата (по одному от каждого параллельного работника, выполняется в своем собственном контексте исполнения), которые собираются вместе и подвел их к одному результату 'thread zero'. Это причуда окна SSMS Properties что “thread zero” помечен как “thread 0”в параллельных частях графического плана, и как “all threads” в последовательной области. Если вы посмотрите на XML, на котором основан графический план,  'Счетчик выполнения каждого потока' всегда относится к «thread 0», никогда "All Threads".

Планировщики, работники и задачи (Schedulers, Workers, and Tasks)

В этой статье до сих пор используется взаимозаменяемые термины, такие как «thread» и «worker» (поток и работник). Теперь, кажется, настало время, чтобы точнее определить некоторые термины.

Планировщики (Schedulers)

Планировщик в SQL Server представляет собой логический процессор, который может быть физическим процессором, ядром процессора, или, возможно, одним из нескольких аппаратных потоков, работающих в пределах ядра (Hyper Threading). Основная цель планировщиков заключается в том, чтобы позволить SQL Server точно управлять собственным планированием потоков, а не полагаться на общие алгоритмы, используемых в операционных системах Windows. Каждый планировщик гарантирует, что только один совместно выполняющийся поток является работоспособным (насколько позволяет операционная система) в любой момент, который может иметь важные преимущества, такие как снижение переключения контекста, и снижение числа вызовов в ядре Windows. Часть третья этой серии охватывает внутреннее планирование задач и их исполнение более подробно.

Информация о планировщиках показана в просмотре системы динамического управления (DMV), sys.dm_os_schedulers.

Работники и Потоки (Workers and Threads)

Работник SQL Server является абстракцией, что представляет собой либо один поток операционной системы или набор потоков (fiber) (в зависимости от настройки конфигурации “lightweight pooling”). Очень немногие системы работают с включенным режимом “fiber-mode scheduling”, таким образом многие тексты (в том числе большая часть официальной документации) ссылаются на "рабочие потоки" (worker threads) - подчеркивая тот факт, что, для большинства практических целей, работник является потоком. Работник (поток) привязан к конкретному планировщику для всего срока службы. Информация о работниках показана в sys.dm_os_workersDMV.

Задачи (Tasks)

Онлайн книги так говорят о задачах: Задача представляет собой единицу работы, которая планируется на SQL Server. Работа может быть связана с одной или несколькими задачами. Например, параллельный запрос будет выполнять несколько задач.

Чтобы расширить этот довольно краткое определение, скажем, что задача – это часть работы выполняемая работником SQL Server. Работа, которая содержит только последовательные планы выполнения является одной задачей, и будет выполнена (от начала до конца) на одном подключении, предоставленном работнику. Это тот случай, когда даже если для выполнения запроса необходимо сделать паузу, чтобы дождаться некоего события для завершения (например, для чтения с диска). Одному работнику назначается одна задача, и он не может выполнять другие задачи, пока текущая задача не будет завершена полностью.

Контексты исполнения (Execution Contexts)

Если задача описывает работу, которую предстоит сделать, то контекст выполнения описывает где эта работа будет происходить. Каждая задача выполняется внутри одного контекста исполнения, которые были определены в колонке exec_context_id в sys.dm_os_tasksDMV(вы также можете увидеть контексты выполнения с помощью “ECID” колонки в просмотре обратной совместимости sys.sysprocesses).

Оператор обмена (The Exchange Operator)

Чтобы кратко резюмировать, мы видели, что SQL Server выполняет параллельный план путем совместного запуска нескольких экземпляров последовательного плана. Каждый последовательный план является одной задачей, выполняемой в отдельном рабочем потоке внутри собственного контекста выполнения. Последний ингредиент в параллельном плане оператор обмена, который является 'клеем' для SQL Serverи используется для соединения контекстов исполнения параллельного плана. В целом, комплексный план запроса может содержать любое количество последовательных или параллельных областей, соединенных операторами обмена.

До сих пор мы видели только один вариант оператора обмена, а именно «Gather streams», но оператор обмена может появиться в графических планов в других вариантах: 


Рисунок 8: Логические операторы обмена

Все виды операторов обмена служат для перемещения строк между одним или несколькими работниками, распределяя отдельные строки среди них. Различные виды логических операторов используются SQL Server, чтобы ввести новую последовательную или параллельную область или перераспределить строки на границе раздела между двумя параллельными областями.

Один физический оператор обмена более гибкий, чем его три логических варианта. Он может не только разделить, объединить, или перераспределить строки среди рабочих, подключенных к нему, но также:

·         использовать одну из пяти различных стратегий, чтобы определить какие исходящие данные направить на ввод строки

·         при необходимости сохранять порядок сортировки входных строк

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

Внутри обмена

Оператор обмена имеет две различных субкомпоненты:

·         Производителей (Producers), которые соединяются с рабочими на его входе

·         Потребители (Consumers), которые соединяются с работниками на его выходе

На рисунке 9 показано увеличенное изображение (разноцветное) “Gather Streams” оператора с рисунка 6. 


Рисунок 9: Внутри оператора обмена Gather Streams 

Каждый производитель собирает строки на его входе и упаковывает их в одном или нескольких буферах памяти. После того, как буфер заполнен, производитель отдает его потребителю. Каждый из производителей и потребителей работает на том же рабочем потоке в качестве контекста выполнения, к которому он подключен (общая раскраска). Потребитель обмена читает строку из буфера обмена, каждый раз, когда его попросил один из его родительских операторов (обозначенный красным цветом Stream Aggregate, в этом случае).

Одним из главных преимуществ данной конструкции является то, что сложности обычно связанные с обменом данными между несколькими потоками исполнения могут быть урегулированы SQL Server внутри одного оператора. Остальные, необменные операторы в плане работают последовательно, и не должны иметь дело с этим механизмом.

Оператор обмена использует буферы, чтобы свести к минимуму издержки и реализовать основной вид управления потоком (чтобы предотвратить быстрых производителей уйти слишком далеко вперед медленной работы потребителей, например). Точное расположение буферов зависит от типа обмена, требуется или нет сохранять порядок, и решение какому потребителю производитель строки должен её направить.

Маршрутизация Строки (Routing Rows)

Как уже отмечалось, оператор обмена может решать, к какому потребителю производитель должен направить конкретную строку. Это решение зависит от типа разделения (PartitioningType) указанного для обмена. Существует пять вариантов:

·         Хэш (hash) – наиболее распространен. Потребитель выбирается исходя из оценки хэш функции по одному или нескольким значениям столбцов в текущей строке

·         Круговая система (RoundRobin) – каждая новая строка посылается к следующему потребителю в определенной последовательности

·         Трансляция (Broadcast) – каждая строка отправляется всем потребителям

·         Спрос (Demand) – строка отсылается первому потребителю, который попросит её. Это единственный тип разделения, где строка направляется от производителя посредством потребителя внутри оператора обмена

·         Диапазон (Range) – Каждому потребителю присваивается неперекрывающийся диапазон значений. Диапазон, в который попадает входной столбец определяет какой потребитель получит строку.

Типы разделения «Спрос» и «Диапазон» встречаются гораздо реже, чем первые три, и, как правило, их можно увидеть только в планах запросов, которые работают с секционированными таблицами (Partitioned Tables). Тип «Спрос» используется в совместно размещенных разделах соединений для назначения идентификатора раздела к следующему рабочему потоку. Тип «Диапазон» используется, например, при создании секционированных индексов. Типы разделения, которые использовались, и любые значения столбцов, используемые в процессе, видны в графическом плане запроса: 


Рисунок 10: Информация о разделении обмена (Exchange Partitioning Information)

Наиболее распространенные типы разделения будут подробно описаны в следующих публикациях.

Сохранение порядка ввода

Оператор обмена необязательно может быть сконфигурирован так, чтобы сохранить порядок сортировки. Это полезно в планах, где строки, входящие в обмен уже отсортированы (сохраняя предыдущую сортировку, или как следствие упорядоченного чтения из индекса) таким образом, что полезно для более позднего оператора. Если обмен не сохранил порядок, оптимизатор должен будет ввести дополнительного оператора сортировки после обмена, чтобы восстановить необходимый порядок. К общим операторам, которые требуют отсортированные входные данные относятся Stream Aggregate, Segment, и Merge Join. На рисунке 11 показан сохраняющей порядок Repartition Streams обмен в действии: 


Рисунок 11: An Order-Preserving Repartition Streams Exchange

Строки, прибывающие на трех входах в обмен в определенном порядке (отсортированные, с точки зрения отдельных работников).Сохраняющей порядок обмен, известный как обмен слияния (merging exchange), гарантирует, что работник (и) на его выходе получать строки в том же порядке сортировки (при том, что распределение, как правило, разное, конечно).

Обмен  сбора потоков (Gather Stream Exchange) также может сохраняют порядок сортировки, при необходимости (также как обмен распределения потоков (Distribute Streams Exchange)). В любом случае, если обмен является обменом слияния (merging exchange), оператор обмена имеет атрибут «Сортировать по» (Order by) , как показано на рисунке 12: 


Рисунок 12: Атрибут «Сортировать по» обмена слияния (The 'Order By' Attribute of a Merging Exchange)

Обратите внимание, что обмен слияния (Merging Exchange) не выполняет никакой сортировки; она ограничивается сохранением порядок сортировки строк, поступающих на его входы. Обмен слияния может быть гораздо менее эффективным, чем вариант, не сохраняющий порядок и это связано с определенными проблемами производительности. Это уже другая тема, которую мы рассмотрим более подробно позже в других публикациях.

Резюме

В введении в параллелизм мы использовали простой запрос, и связанный с ним реальный пример, чтобы исследовать модель, используемую SQL Server, чтобы позволить запросам автоматически извлечь выгоду из дополнительной вычислительной мощности, предоставляемой современными многоядерными серверами, не требуя от разработчика учитывать некоторые сложности, обычно связанные с многопоточной конструкцией.

Мы видели, что план параллельных запросов может содержать любое количество параллельных и последовательных областей, связанных оператором обмена. Параллельные зоны расширяются на несколько последовательных запросов, каждый из которых использует один рабочий поток для обработки задачи в пределах контекста выполнения. Операторы обмена используются для распределения строк между работниками, и эти операторы существуют только в параллельном плане запроса, и  которые взаимодействуют непосредственно с более чем одним работником. Наконец, мы увидели, что SQL Server обеспечивает поставщика параллельных страниц, который позволяет нескольким работникам совместно сканировать таблицу или индекс, гарантируя правильные результаты.

Следующая часть этой серии основана на фундаментальных понятиях, рассмотренных в этом введении, и показывает как использовать  контекст выполнения, рабочие потоки, и операторы обмена в запросах, которые используют параллельный хэш (parallel hash) и соединения слиянием (merge joins). Мы также более подробно рассмотрим типы разделения обмена (Exchange Partitioning Types), оптимизацию запросов, которая возможна только в параллельных планах; ту оптимизацию, которая может привести к выполнению параллельного запроса, используя меньше процессорного времени, чем аналогичный последовательный запрос и быстрее возвращая результат запроса.


Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. AlX0id 26.08.14 13:30 Сейчас в теме
Интересно, но в 1С малоприменимо :)
З.Ы. Если быть более точным, то "в учетных системах 1с".
2. jan27 708 26.08.14 14:04 Сейчас в теме
(1) ну почему же, многие с успехом используют "ручной параллелизм"
3. baton_pk 401 26.08.14 19:55 Сейчас в теме
(2) jan27,
вот как-раз об этом-то и хотелось бы почитать поподробнее на соответствующем ресурсе :)
4. jan27 708 27.08.14 05:04 Сейчас в теме
5. baton_pk 401 27.08.14 16:07 Сейчас в теме
(4) jan27,
Вот там вот я читал. Я думал, вы имеете в виду, что эти многие используют "ручной параллелизм" именно средствами MS SQL.
Например, могу я перед запуском транзакции на сервере включить какой-нибудь могучий флаг?
6. jan27 708 28.08.14 05:09 Сейчас в теме
(5) если средствами MS SQL, то это уже не ручной параллелизм. А так, в настройках сервера есть Maximum Degree of Parallelism
7. AlX0id 28.08.14 14:32 Сейчас в теме
(2) jan27,
Ручной параллелизм - это, конечно, хорошо.. Но дюже геморройно будет выбирать данные для обработки так, чтобы они еще и не пересекались и не влияли на результаты друг друга..
8. jan27 708 28.08.14 14:42 Сейчас в теме
(7) если появится такая необходимость - почему нет?
9. jan27 708 28.08.14 15:15 Сейчас в теме
(7) вообще речь не о ручном параллелизме, а о параллелизме под управлением SQL сервера, который работает при MDOP, отличном от 1
kirinalex; +1 Ответить
10. AlX0id 29.08.14 10:42 Сейчас в теме
(9) jan27,
Если вести речь о неручном параллелизме, то можно наткнуться на:
Intra-query parallelism caused your server command to deadlock.
Transaction was deadlocked on thread communication buffer resources with another process and has been chosen as the deadlock victim

И везде решается эта проблема только отключением параллелизма как раз ) Или, быть может, есть другие методы? Я в скуле новичок, собсн - было бы интересно узнать мнение более опытных людей )
11. jan27 708 29.08.14 12:03 Сейчас в теме
(10) очевидное решение проблемы с параллелизмом - отключить его
обычно рекомендуют посмотреть какой запрос или транзакция приводит к такой ошибке

сколько процессоров, какой MDOP?
13. AlX0id 29.08.14 21:15 Сейчас в теме
(11) jan27,
Я как бы сам с такими запросами не встречался, но в процессе подготовки к сдаче экзамена ЭТВ неоднократно наталкивался на подобные рекомендации вида:
http://www.ravepoint.narod.ru/aticles/tecnology/1problems/2.htm
Да и на самом тренинге по эксперту отношение к оной опции (Max DOP) было неоднозначное..
14. jan27 708 01.09.14 05:06 Сейчас в теме
(13) почему то все игнорируют вариант оптимизации запроса :)
15. AlX0id 01.09.14 09:44 Сейчас в теме
(14) jan27,
Наверное потому, что напрямую изменить запрос SQL из 1С нельзя ) Плюс не всегда есть возможность вообще что-то менять в конфигурации..
И сами MS разработчики, как я понимаю из обсуждений, не предусматривали, что параллелизм будут использовать в OLTP-системах.. Ну, то есть, работать-то он будет, но предназначен не для них )
16. jan27 708 01.09.14 09:52 Сейчас в теме
(15) зачастую, достаточно оптимизировать запрос 1С + отключение параллелизма имеет смысл на сервере с малым количеством процессоров (2-4)
17. AlX0id 01.09.14 13:58 Сейчас в теме
(16) jan27,
А каким образом его оптимизировать для того, чтобы он мог исполняться параллельно? Например, вот получил я интраквери параллелизм еррор - дальше куда глядеть, опции максдоп, конечно? )
18. jan27 708 02.09.14 05:07 Сейчас в теме
19. AlX0id 02.09.14 23:41 Сейчас в теме
(18) jan27,
Как бы профайлер я видел, и даже оптимизировал запросы - это да )
Но вот как средствами профайлера проанализировать запрос, упавший на внутренней самоблокировке? Полагаю, что тут скорее вот сюда надо
20. jan27 708 03.09.14 05:20 Сейчас в теме
21. AlX0id 04.09.14 22:43 Сейчас в теме
(20) jan27,
чота со ссылками у инфостарту.. http://technet.microsoft.com/en-us/library/aa937543(v=sql.80).aspx

ЗЫ Сегодня таки залез попробовать у одного клиента параллелизм - в свойствах у него оказалось и так стояло maxdop = 0. Но значков, подобных тем, что в статье, я в профайлере почему-то не увидел.. Ну то есть графическое представление плана как было, так и осталось тем же.. Там надо какие-то специфические события для этого включать в трассу?
22. jan27 708 05.09.14 05:26 Сейчас в теме
(21) посмотри в Activity Monitor Последние тяжелые запросы + в запросе должны быть какие-либо соединения
24. AlX0id 05.09.14 09:52 Сейчас в теме
(22) jan27,
Ага,попробую - там как раз 2008 скуль стоит в отличии от большинства моих клиентов с 2005 )
Соединений-то в запросе не то, что гора, но очччень даже порядком )
25. jan27 708 05.09.14 11:47 Сейчас в теме
(24) вот здесь пример 1С запроса, который вызывает параллельный план http://infostart.ru/public/299976/
kirinalex; +1 Ответить
12. jan27 708 29.08.14 12:39 Сейчас в теме
26. kirinalex 2 14.05.20 18:46 Сейчас в теме
(7)
чтобы они еще и не пересекались и не влияли на результаты друг друга

в ручном варианте как раз легко принимать подобные решения
автоматически сложнее, если самому разрабатывать
27. kirinalex 2 14.05.20 18:48 Сейчас в теме
статья неплохая, но не хватает конкретный примеров, как помогать серверу использовать параллелизм, в какой форме давать ему данные
Оставьте свое сообщение

См. также

Повышение качества разработок и онлайн контроль ошибок Промо

Журнал регистрации v8 Абонемент ($m)

Анализ ошибок и сбор ошибок журнала регистраций из десятков и сотен баз в одном месте.

09.03.2018    26443    DitriX    48    

Резервные копии SQL с помощью планировщика виндовс и скрипта

Архивирование (backup) v8 Абонемент ($m)

Всем привет! Сильно не судите, в основном я создаю эту статью для себя, чтобы не забыть об этом, сразу скажу, что я не программист, но по долгу работы приходится решать вопросы. В данной статье я покажу код батника, с помощью которого я делаю резервное копирование баз данных 1С посредством SQL.

1 стартмани

12.03.2020    2045    VID1234    10    

Резервное копирование и восстановление БД 1С 8.3 на PostgreSQL 11.5

Архивирование (backup) v8 1cv8.cf Абонемент ($m)

Резервное копирование баз данных 1С является обязательным, чтобы в случае непредвиденной проблемы всегда была возможность все восстановить. В статье мы рассмотрим, как произвести резервное копирование и восстановление из копии базы 1 8.3, работающей на PostgreSQL 11.5.

1 стартмани

30.01.2020    10755    ClickUp    43    

Мультибазовая очистка Журнала регистрации с автоматическим перемещением архивных данных в указанный каталог

Журнал регистрации v8 Россия Абонемент ($m)

На сервере 1С со временем увеличивается в размерах папка , содержащая журналы регистрации 1С и как следствие может возникнуть проблема свободного пространства на системном жестком диске. Чтобы избежать роста папки, необходимо периодически очищать журнал регистрации 1С.

1 стартмани

26.12.2019    2978    bryantsev.yury    3    

Выводим из suspect базу 1С 7.7 на sql server 2000, а также "Перемещение баз данных SQL Server в новое местоположение с помощью операций Detach и Attach" Промо

Тестирование и исправление v7.7 1cv7.md Абонемент ($m)

База данных помечается Suspect, когда SQL Server не может читать файлы данных, связанные с базой данных с жесткого диска. В этом случае сделать бекап базы нельзя, но можно попробовать образ диска. После того как возможность читать файлы данных восстановлена, вы можете перезапустить службу SQL Server, и если возможно, произойдет автоматическое восстановление. Что делать, если информационная база 1С7.7 на SQL Server 2000 перешла в состояние suspect? Если это произошло утром и бекап сделан, Вы, конечно, можете грохнуть и раскатать базу заново (вечером это проблематичнее), но не торопитесь - возможно, поможет detach+attach или другие методы, изложенные в данной публикации.

1 стартмани

08.11.2016    20236    ksnik    3    

Как автоматически заполнить обработкой табличную часть документа "Ввод начальных остатков" (Тип операции = "Расчеты с партнерами"). 1С: ERP

Обработка документов Дебиторская и кредиторская задолженность v8 ERP2 БУ УУ Абонемент ($m)

В 1С: ERP (релиз 2.4.8.82) есть документ "Ввод начальных остатков". Он предназначен для переноса остатков из старых учетных программ при переходе на работу в новой конфигурации. В инструкциях на официальном сайте 1С пользователям новой конфигурации 1С: ERP предлагается заполнить этот документ. Каким образом они будут заполнять, не уточняется. Можно предположить, что предлагается интерактивно, вручную, ввести эти документы. Это следует из картинок в инструкции 1С. В данной статье я предлагаю способ автоматического программного заполнения документа "Ввод начальных остатков" с помощью обработки "Загрузка данных из табличного документа". При этом способе заполнения, время на процесс переноса остатков сокращается в десятки или даже сотни раз.

1 стартмани

20.12.2019    3078    pvlunegov    6    

Дополнительные расходы на основе перемещения запасов в УНФ (пошаговая разработка расширения конфигурации)

Обработка документов Учет ТМЦ Расширения v8 УНФ Россия УУ Абонемент ($m)

Доброго времени! Предлагаю небольшое расширение для конфигурации "Управление нашей фирмой", позволяющее включать документ "Перемещение запасов" в таблицу оснований документа "Дополнительные расходы".

1 стартмани

17.10.2019    6042    aximo    4    

Многопоточная обработка данных на примере перепроведения документов

Обработка документов Практика программирования v8 ERP2 УТ11 КА2 Абонемент ($m)

Дальнейшее развитие темы фоновой обработки данных - проведение документов в потоках. Настройка параметров и запуск основного процесса (менеджера потоков). Разбивка документов для проведения на не связанные друг с другом наборы и запуск дополнительных фоновых заданий для отдельных потоков. Отслеживание выполнения каждого потока в родительском сеансе.

1 стартмани

17.09.2019    8620    ids79    46    

XDTO - часть 3 Промо

Практика программирования Администрирование данных 1С v8 1cv8.cf Абонемент ($m)

Мы продолжаем цикл статей по изучению подсистемы XDTO в 1С:Предприятие. Это третья часть, в которой мы будем работать непосредственно с подсистемой, рассмотрим главные строительные блоки подсистемы и рассмотрим небольшой пример кода.

3 стартмани

28.01.2013    188753    Evil Beaver    172    

1С и PowerShell - обновление из хранилища

Администрирование данных 1С Инструментарий разработчика v8 Абонемент ($m)

Пример скрипта, упрощающего работу.

1 стартмани

29.08.2019    8180    Jokemas    24    

Централизованное управление кластером 1С Предприятия, состоящим из нескольких рабочих серверов, работающих на платформе GNU/Linux

Сервисные утилиты v8 Абонемент ($m)

При эксплуатации крупных информационных систем, в состав которых могут входить десятки серверов 1С Предприятия, зачастую возникают ситуации, требующие однотипных действий на всех серверах кластера 1С Предприятия или на всех серверах контура. В настоящей статье представлен способ централизованного управления серверами 1С Предприятия, работающими на платформе GNU/Linux. Подобный подход может быть использован и для других задач, возникающих в процессе эксплуатации крупных систем, с целью сокращения как временных затрат специалистов, так и времени простоя системы.

1 стартмани

26.08.2019    3661    Sloth    0    

1С + IIS + SSL: Перевод опубликованной базы на защищенное соединение https с сертификатом от Let's encrypt

Администрирование данных 1С v8 1С:CRM Абонемент ($m)

Всем Доброго времени! Предлагаю Вам небольшую базовую инструкцию, где я опишу, как быстро перевести опубликованную в веб базу 1С на защищенное https соединение, используя стандартный IIS сервер и бесплатный сертификат SSL от Let's encrypt.

1 стартмани

10.08.2019    19142    aximo    36    

Обновление типовой конфигурации сразу на несколько релизов (8.2) [не для начинающих] Промо

Администрирование данных 1С v8 1cv8.cf Россия Абонемент ($m)

Как обновить типовую конфигурацию с давно устаревшего релиза на текущий, но не тратить время на последовательное обновление через .cfu? Есть вариант, который позволяет сэкономить довольно много времени. Он не самый очевидный и несколько рискованный (потому и не для начинающих) – через файл .cf конфигурации поставщика. Взять такой .cf можно даже из нетиповой базы актуального релиза! Способ подходит для тех, кто по разным причинам не может обновиться через интернет. Да, И НЕ ЗАБЫВАЕМ ПРЕДВАРИТЕЛЬНО ОБНОВЛЯТЬ ПЛАТФОРМУ!!!

13.02.2012    171660    vvr908    139    

Упражнения на Перфоленте. Парсим технологический журнал 1С

Сервисные утилиты Инструментарий разработчика Практика программирования Разработка Абонемент ($m)

В статье рассматривается парсинг технологического журнала 1С на новом языке программирования Перфолента. Статья может быть полезна как для парсинга, так и для изучения некоторых особенностей языка.

1 стартмани

31.07.2019    7267    Perfolenta    62    

Как настроить автоматическое резервное копирование в MS SQL SERVER EXPRESS

Архивирование (backup) Абонемент ($m)

При использовании MS SQL Server редакции Express, которая является бесплатной, важно понимать, что она имеет ряд ограничений. Кроме того что размер базы данных при использовании MS SQL Server Express не может превышать 10 Гб, в составе этой редакции СУБД отсутствует SQL Server Agent, который позволяет создавать планы обслуживания баз данных для регулярного автоматического выполнения. В результате нет возможности автоматизировать резервное копирование базы данных штатными средствами. Однако выход из ситуации есть. В статье описана инструкция по настройке автоматического резервного копирования для MS SQL Server Express 2008.

1 стартмани

20.06.2019    12883    igordynets    7    

АИТП. Управляем множественными версиями платформы на серверах, под управлением ОС Linux

Администрирование данных 1С v8 Абонемент ($m)

В статье рассмотрен демонстрационный пример использования конфигурации АИТП, для автоматизации управления множественными версиями платформы 1С:Предприятие на серверах, под управлением ОС Linux.

1 стартмани

16.06.2019    7218    blackhole321    8    

Циклический бэкап по дням недели Промо

Архивирование (backup) v7.7 v8 1cv8.cf 1cv7.md Россия Абонемент ($m)

В интернете часто можно встретить статьи о том, как написать скрипты для автоматического архивирования баз MSSQL. Методика, в них предлагаемая создает новый архив каждый новый день. Более подробно об этом можно почитать в http://outcoldman.ru/ru/blog/show/127 Я предлагаю незначительное усовершенствование скриптов и генерацию архивов по дням недели с циклической их перезаписью. Скрипт тоже не полностью мой, а скомпонован из различных примеров, найденных в интернете, но, надеюсь, именно представленный вариант будет полезен не только мне.

1 стартмани

15.06.2010    39187    milkers    15    

АИТП. Управляем информационными базами

Администрирование данных 1С v8 Абонемент ($m)

В статье, на демонстрационном примере, рассматривается использование конфигурации АИТП для автоматизации управления информационными базами 1С:Предприятие.

1 стартмани

29.05.2019    4659    blackhole321    0    

Загрузка-выгрузка файлов по RDP с докачкой

Администрирование данных 1С Абонемент ($m)

PowerShell скрипт для загрузки/выгрузки больших файлов в RDP-сессии с использованием технологии BITS-transfer.

1 стартмани

16.05.2019    5696    VKislitsin    3    

Собственный алгоритм нумерации документов определенного вида

Практика программирования Обработка документов Разработка v8 БП3.0 Россия Абонемент ($m)

Создание собственного, отличного от платформенного алгоритма нумерации документов определенного вида.

1 стартмани

11.04.2019    2936    xan333    12    

Соответствие типов данных 1С:Предприятие 8.x в MS SQL 2008 Промо

Практика программирования Администрирование данных 1С Загрузка и выгрузка в Excel v8 1cv8.cf Абонемент ($m)

Соответствие типов данных 1С:Предприятие 8.x и MS SQL 2008

1 стартмани

13.01.2013    22111    YPermitin    8    

Сторнирование документов отсутствия по невыясненной причине после переноса данных. Замена на больничный лист. ЗУП 3.1.8

Обработка документов Бухгалтерский учет Зарплата Учет рабочего времени Зарплата Учет рабочего времени v8 v8::СПР ЗУП3.x Россия БУ Абонемент ($m)

Наши кадры в ЗУП 2.5 на время отсутствия документов о больничном вводят документ "Невыходы в организациях". Спокойно рассчитывают, а когда документы о больничном листе приносят - сторнируют невыход. В целом ничего криминального, и практика частая в различных организациях, но есть нюансы, при переходе на ЗУП 3.1.

1 стартмани

22.03.2019    4840    Mogilnikova    0    

Easy print своими руками

Администрирование данных 1С v8 ERP2 Россия Абонемент ($m)

Статья описывает альтернативные способы печати из терминальной сессии на локальный принтер.

1 стартмани

05.03.2019    2309    kolegov    8    

Баг или фича? Неожиданное поведение платформы

Практика программирования Тестирование и исправление Разработка v8 1cv8.cf Абонемент ($m)

Рассмотрим несколько случаев неожиданного поведения платформы 1С, а также что с этим можно cделать.

18.02.2019    22541    YPermitin    89    

1С и Windows Script Host (WSH) и Windows Management Instrumentation (WMI). ОТ ТЕОРИИ К ПРАКТИКЕ. Часть III. Реестр Промо

Универсальные обработки Администрирование данных 1С v8 1cv8.cf Абонемент ($m)

Описание возможностей Windows Script Host и Windows Management Instrumentation. Подборка "скриптовых" функций и процедур. Работа с реестром.

16.12.2012    37604    StepByStep    26    

Как отправить ошибки из журнала регистрации на почту?

Журнал регистрации v8 УПП1 Абонемент ($m)

Процедуры отправки ошибок из журнала регистрации на почту. Журнал регистрации выгружается в файл Excel, далее прикрепляется к письму. Для отправки писем создано регламентное задание.

1 стартмани

06.02.2019    8674    wowik    0    

PostgreSQL для 1С 8.3: ускоряем резервное копирование и восстановление для отдельной базы очень большого размера

Производительность и оптимизация (HighLoad) Тестирование и исправление v8 1cv8.cf Россия Абонемент ($m)

В этой статье разберем оптимизацию работы с моментальным снимком отдельной базы 1С в кластере PostgreSQL средствами pg_dump.exe, pg_restore.exe, psql.exe в среде Windows Server 2008,2012,2016. А также разберем проблемные ситуации и неожиданные ограничения при работе 1С в связке с PostgreSQL. Для Linux все аналогично.

1 стартмани

03.12.2018    27079    vsasav    69    

Имплементация системы мониторинга кластеров 1С (и лицензий)

Администрирование данных 1С v8 Абонемент ($m)

В этой статье мы научимся хранить данные о сеансах консоли кластеров 1С в СУБД, вынимать и агрегировать информацию о лицензиях.

1 стартмани

02.12.2018    10512    MrWonder    15    

1С и Windows Script Host (WSH) и Windows Management Instrumentation (WMI). ОТ ТЕОРИИ К ПРАКТИКЕ. Часть II Промо

Универсальные обработки Администрирование данных 1С v8 1cv8.cf Абонемент ($m)

Описание возможностей Windows Script Host и Windows Management Instrumentation. Подборка "скриптовых" функций и процедур.

16.12.2012    32195    StepByStep    7    

Какой SQL Server лучше для сервера 1С

Администрирование данных 1С v8 Абонемент ($m)

Нагрузочное тестирование TPC 1C Гилева, различных версий MSSQL и Windows server.

1 стартмани

03.11.2018    22292    demon_sl    146    

Go. Разбор лога технологического журнала. Достойная альтернатива perl'у

Сервисные утилиты Инструментарий разработчика v8 1cv8.cf Абонемент ($m)

Началось все с того, что я познакомился с перловыми скриптами для парса ТЖ которые размещены на kb.1c.ru (например в этой статье https://kb.1c.ru/articleView.jsp?id=113). По началу мне дико понравилось то, что перл разбирал гигабайты логов за считанные минуты, но позитив мой угасал обратно пропорционально с тем, насколько глубже я погружался в "кроличью нору" ....

1 стартмани

24.10.2018    19655    lazarenko    39    

Мониторинг журнала регистрации при помощи Powershell

Сервисные утилиты Журнал регистрации v8 Абонемент ($m)

Работа с журналом регистрации в формате SQLite внешними средствами на примере мониторинга изменений в конфигурации базы данных.

1 стартмани

12.07.2018    12659    user768334    7    

Журнал регистрации 1С (sql lite) в web app

Журнал регистрации v8 1cv8.cf Абонемент ($m)

Данная публикация рассматривает построение компонентного решения работы журнала регистрации в стороннем приложении(web app). Встала задача миграции sql lite жр во внешнюю базу. Данное решение было создано: 1. для хранения жр за весь период 2. для ускорения работы с жр 3. для ускорения сервера предприятия, так как именно он (а точнее рагент) пытается записать данные в жр sql lite(фактически файл на диске), после увеличения размера файла более 10 гб, поступали жалобы по вопросу быстродействия 1с (и не только ради этого) Данная публикация может быть полезной администраторам, программистам, оптимизаторам.

1 стартмани

09.07.2018    9166    dmarenin    8    

"Шоколадная" установка 1С

Администрирование данных 1С v8 Россия Абонемент ($m)

Статья о том, как быстро установить и настроить платформу 1С через одну команду: choco install 1c.

1 стартмани

27.06.2018    14316    Scorpion4eg    41    

Tool1CD: отрежем донорскую почку

Сервисные утилиты Разработка внешних компонент v8 Розница Абонемент ($m)

Ваша база мертва? Что ж, кое-что в ней ещё теплится.

1 стартмани

15.05.2018    18262    baton_pk    13    

Исполняемый .bat файл для резервного копирования 1С

Архивирование (backup) v8 1cv8.cf Абонемент ($m)

Простейшее решение для выгрузки .dt, доступное любому пользователю 1С.

1 стартмани

14.05.2018    23768    SergPetr    32    

Создание подключаемой обработки табличной части с диалогом запроса параметров заполнения (управляемые формы)

Обработка документов Обработка справочников Практика программирования v8::УФ 1cv8.cf Абонемент ($m)

Пошаговый пример покажет, как сделать обработку табличной части для документа, предварительно открывающую диалоговое окно, где пользователь может указать требуемые характеристики (параметры), по которым произойдет обработка.

1 стартмани

03.05.2018    46494    Mirage78    16    

Использование регулярных выражений (RegExp) в Linux

Сервисные утилиты Администрирование данных 1С Внешние источники данных v8 Абонемент ($m)

Описывается способ использования регулярных выражений (RegExp) в Linux с использованием тех же компонентов, что и в Windows (COM-объекты VBScript.RegExp).

1 стартмани

20.04.2018    8383    vsbronnikov    12    

Настройка регламентных заданий с использованием bat-файлов или vbs-скриптов через механизм Task Scheduler Windows

Администрирование данных 1С v8 Абонемент ($m)

Развернутое описание всех нюансов настройки регламентных заданий без редактирования конфигурации через внешние обработки 1С с использованием bat-файлов или скриптами через механизм Task Scheduler Windows.

1 стартмани

17.04.2018    10943    plebedinskiy    7    

Лицензия не получена: Ошибка программного лицензирования Error=-2147217394 (0x8004100E)

Администрирование данных 1С Информационная безопасность v8 Абонемент ($m)

Решение проблемы пропавшей лицензии и ошибки при ее восстановлении - "Лицензия не получена: Ошибка программного лицензирования Error=-2147217394 (0x8004100E)".

1 стартмани

06.04.2018    11224    a_titeev    4    

Настройка Dropbox как службы на терминальном сервере

Администрирование данных 1С Абонемент ($m)

Настройка Dropbox как службы на терминальном сервере на примере сервера Windows 2008 R2 x64. К сожалению, Dropbox не имеет своих инструментов для настройки синхронизации как сервиса Windows. Но иногда очень хочется это сделать, чтобы, например, бэкапы 1С своевременно синхронизировались с облачным хранилищем независимо от того, запущен терминальный сеанс под определенным пользователем или нет. 

1 стартмани

27.03.2018    10038    vdv2701    6    

Скрипт для установки платформы 1С

Администрирование данных 1С v8 Абонемент ($m)

Еще один баян по установке 1с8 на клиентских машинках без использования групповых политик безопасности.

1 стартмани

07.03.2018    8790    alex0402    7    

Мониторинг изменений рабочих конфигураций. Часть 1. Сохранение конфигураций из базы SQL без конфигуратора

Сервисные утилиты v8 1cv8.cf Абонемент ($m)

Выгружаем исходники из SQL напрямую скриптом, собираем CF и контролируем реальные изменения в рабочих базах из браузера.

1 стартмани

28.02.2018    19051    user768334    25    

Автоматическое оповещение пользователей при проведении документа Поступление товаров, с возможностью дублировать сообщения другому сотруднику

Практика программирования Обработка документов Документооборот и делопроизводство Документооборот и делопроизводство v8 v8::ОУ УТ11 Россия Абонемент ($m)

Данная разработка автоматически оповещает пользователя о поступлении товара по заказу клиента. Схема работы : Заказ клиента > Заказ поставщику > Поступление товаров. Оповещается пользователь, который создавал заказ клиента (менеджер). Оповещение выводится на экран и ждет подтверждения о прочтении. После подтверждения - фиксируется время прочтения оповещения. Есть возможность просматривать все сообщения по пользователю за любой период. Есть возможность дублировать сообщение другим пользователям. Например, если менеджер в отпуске, и его заменяет другой менеджер, и оповещения будут отправляться второму (третьему и т.д.).

1 стартмани

26.02.2018    12460    Natali307192013    8    

Обновление конфигураций на БСП, у которых в расширениях есть собственные объекты с данными

Практика программирования Тестирование и исправление v8 v8::УФ 1cv8.cf Абонемент ($m)

Показан способ обновления конфигураций, основанных на БСП, в тех случаях, когда в расширениях имеются собственные объекты данных (Справочники, Документы, Регистры сведений, Планы обмена).

1 стартмани

12.02.2018    21281    t.v.s.    41    

Восстановление данных из fullbackupdata Sony PC Companion. Часть 1: Телефонная книга

Архивирование (backup) Россия Абонемент ($m)

Друзья, довелось столкнуться с проблемой - есть телефон Sony с разбитым экраном, в котором осталась смс с очень важным номером телефона. Единственное, что удалось - сделать бэкап, подключив телефон к ноуту. И возник вопрос - что же делать дальше с файлами бэкапа, как из них получить в читабельном виде. "Простого" решения, чтобы восстановить данные, как оказалось, не существует. Но, существуют прекрасные люди, которые сделали целый урок по восстановлению данных из бэкап-файлов Android. Ниже перевод этой очень полезной статьи.

1 стартмани

13.01.2018    11025    user893870    0    

Практика доступа в базу 1С через протокол oData. Чтение данных

Сервисные утилиты Практика программирования Администрирование данных 1С v8 1cv8.cf Абонемент ($m)

Для чего нужен доступ в базу 1С через REST-интерфейс по протокол oData? Как его организовать? Как не будучи гуру в JavaScript и .NET получить быстрый визуальный доступ к данным базы 1С? Попробую дать ответ на эти вопросы и прокомментирую некоторые нюансы, с которыми я столкнулся.

1 стартмани

11.12.2017    90831    Dementor    50