Регистр сведений

Регистры сведений — это прикладные объекты конфигурации. Они позволяют хранить в прикладном решении произвольные данные в разрезе нескольких измерений. Например, в регистре сведений можно хранить курсы валют в разрезе валют, или цены предприятия в разрезе номенклатуры и типа цен.

Структура

Информация в регистре сведений хранится в виде записей, каждая из которых содержит значения измерений и соответствующие им значения ресурсов.

Измерения регистра описывают разрезы, в которых хранится информация, а ресурсы регистра непосредственно содержат хранимую информацию. Например, для регистра сведений Цены товаров, который имеет следующую структуру:

записи, хранимые в базе данных, будут выглядеть следующим образом:

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

Периодичность

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

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

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

Подчинение регистратору

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

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

Например, изменение цен компании может производиться только определенным кругом лиц, и каждое такое изменение должно сопровождаться «бумажным» документом. В этом случае можно использовать режим подчинения регистратору, при котором изменение цен может быть выполнено только специальным документом — Изменение цен товаров.

Уникальность записей

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

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

Формы

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

Форма списка

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

Форма записи

Для просмотра и изменения отдельных записей регистра сведений используется форма записи. Как правило, она представляет данные в удобном для восприятия и редактирования виде:

Источник

Регистр сведений и регистр расчета. Просто о сложном

В система 1С существует 4 вида регистров:

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

Регистр накопления — это таблица данных, которая «накапливает» информацию из документов. Такие регистры составляют основу механизма учета движения средств: денег, товаров, материалов и так далее.

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

По своей структуре этот регистр напоминает регистр накопления и состоит из измерений, в разрезе которых хранятся произвольные данные ‒ ресурсы и реквизиты для хранения дополнительной информации.

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

Есть два подвида регистра сведений:

подчинен регистратору: документ делает записи при проведении;

не подчинен регистратору: запись осуществляется не при проведении документа.

Но и это еще не все. Есть еще одна особенность, которая отличает регистр сведений от других регистров: он может быть периодическим и непериодическим.

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

Возьмем для примера опять регистр сведений «Курсы валют». Данный регистр является периодическим, так как информация в нем изменяется каждый день, т.е. на каждый день мы получаем новый курс.

Исходя из всего вышенаписанного, структура регистра сведений выглядит следующим образом:

При этом мы понимаем, что наличие столбцов «Период» и «Регистратор» зависит от типа регистра.

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

Например, в регистре «Курсы валют» мы не можем встретить за один день по одной и той же валюте разные курсы. Такое состояние таблицы введет в ступор как самого пользователя, так и машину с ее алгоритмами.

Регистры сведений применяются для хранения различной информации, которая может использоваться в прикладных задачах. Информация в регистре сведений хранится в определенных разрезах, которые называются измерениями, а еще она может изменяться во времени. Записи в регистры сведений могут делать не только документы.

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

По своей структуре регистры расчета похожи на регистры накопления или регистры сведений. Они так же, как и регистры накопления имеют измерения, ресурсы, реквизиты. Но принцип действия регистров расчета абсолютно другой. Структура и принцип работы данного регистра тесно связаны с Планом видов расчета.

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

Один план видов расчета может использоваться в нескольких регистрах расчета, но один регистр расчета не может использовать несколько планов видов расчета одновременно.

Регистр расчета является таблицей, в которой хранятся рассчитанные данные. А в плане видов расчета хранятся алгоритмы расчета этих данных.

Данный регистр является периодическим. Каждая запись относится к определенному периоду времени. Параметр периода может быть:

Исходя из всего написанного выше, структура регистра расчета выглядит следующим образом:

Как уже говорилось, большая часть алгоритма расчета указывается в плане видов расчета. Рассмотрим, на что мы с вами можем повлиять на примере самого распространенного вида начисления «Оплата по окладу».

Сам план видов расчета чем-то напоминает справочник и выглядит следующим образом:

Открываем «Оплата по окладу» и на первой вкладке видим следующее:

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

Так как регистр расчета является периодическим, прослеживается зависимость не только от времени, но и от его вида. Что это значит? Это значит, что мы можем настроить разные виды времени, которые будут влиять на сам расчет показателей. Например работа в выходные оплачивается в двойном размере.

Также, мы можем указать некоторые зависимости, например, от территориального расположения: районный коэффициент влияет на конечный результат.

Мы с вами понимаем, что помимо оплаты по окладу, мы начисляем сотруднику командировочные, отпускные, больничные и т.д. И чтобы не произошло наложения одного вида расчета на другой, указывается их приоритет. Например, сотрудник с 1 по 10 число был в отпуске, мы ему начислили и выплатили отпускные, зарплату должны ему начислить теперь за период с 11 по 31 число, так как у отпуска приоритет выше и он «вытесняет» нашу оплату по окладу.

Кроме того, мы можем повлиять на следующее: будут ли рассчитываться НДФЛ и различные взносы, а также как отразить данный вид начисления в бухгалтерском учете.

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

Итак, как же выглядит наша таблица регистра расчета

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

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

Хотите узнавать о новых публикациях и быть в курсе наших новостей?Подпишитесь

Источник

Работа с регистрами сведений в 1С 8.3 и 8.2

Регистр сведений 1С 8 — объект метаданных, предназначенный для хранения справочной информации в разрезе определенных разработчиком измерений.

Типичный пример использования регистра сведений — хранение информации о курсе валют в разрезе валюты и периода.

Рассмотрим подробнее свойства и настройки регистра сведений.

Настройка и свойства регистра сведений 1С 8

Два главных свойства регистра сведения — Периодичность и Режим записи.

Это уникальные свойства регистра сведений, которых больше нет ни у одного объекта метаданных. Рассмотрим их подробнее.

Периодичность регистра сведений 1C

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

Периодичность может принимать следующие значения:

При выборе периодичности, отличной от варианта Непериодический, система будет контролировать уникальность записей в пределах заданного промежутка времени. Если запись не уникальна, система 1C выдаст сообщение Запись с такими ключевыми полями существует! и не даст произвести запись в базу данных.

А одна из главных особенностей периодического регистра сведений — возможность получать готовые значения «Среза первых» и «Среза последних». Эта информация позволяет очень быстро получить из базы данных информацию о последнем (первом) установленном значении на определенную дату.

Режим записи регистра сведений

В 1С 8.2 и 8.3 это свойство может быть либо в значении «Независимый», либо — «Подчинение регистратору». В первом случае записи можно будет произвести как программно, так и из формы списка регистра сведений. Во втором случае обязательно указание документа-регистратора записи. Это накладывает определенные ограничения, но в то же время открывает новые возможности.

Свойства измерения регистра сведений

Также следует обратить внимание на палитру свойств измерений регистра сведений 1С 8.3. Особенно на флаги Ведущее и Основной отбор:

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

Программная запись в регистр сведений 1С

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

Использование менеджера записи:

НоваяЗапись = РегистрыСведений.КурсыВалют.СоздатьМенеджерЗаписи();
НоваяЗапись.Валюта = Справочники.Валюты.НайтиПоНаименованию(«USD»);
НоваяЗапись.Период = Дата(31,12,2016);
НоваяЗапись.Курс = 100;
НоваяЗапись.Кратность = 1;
НоваяЗапись.Записать();

Использование набора записей регистра сведений 1С:

НовыйНаборЗаписей = РегистрыСведений.КурсыВалют.СоздатьНаборЗаписей();
//если вы не установите отбор — удалятся все записи регистра сведений
НовыйНаборЗаписей.Отбор.Валюта.Установить(Доллар, Истина);
НовыйНаборЗаписей.Отбор.Период.Установить(Дата(31,12,2016), Истина);
//формируем непосредственно запись набора
НоваяЗаписьНабора = НовыйНаборЗаписей.Добавить();
НоваяЗаписьНабора.Валюта = Справочники.Валюты.НайтиПоНаименованию(«USD»);
НоваяЗаписьНабора.Период = Дата(31,12,2016);
НоваяЗаписьНабора.Курс = 100;
НоваяЗаписьНабора.Кратность = 1;
НовыйНаборЗаписей.Записать();

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

Видеолекция по регистрам сведений в 1С для начинающих:

Если Вы начинаете изучать 1С программирование, рекомендуем наш бесплатный курс (не забудьте подписаться на YouTube — регулярно выходят новые видео):

К сожалению, мы физически не можем проконсультировать бесплатно всех желающих, но наша команда будет рада оказать услуги по внедрению и обслуживанию 1С. Более подробно о наших услугах можно узнать на странице Услуги 1С или просто позвоните по телефону +7 (499) 350 29 00. Мы работаем в Москве и области.

Источник

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

Получение начальной оценки интегральной производительности системы

Перед началом работ по оптимизации системы необходимо всегда получать начальную оценку производительности при помощи «Оценки интегральной производительности системы по методике APDEX».

Если по данным Apdex видим, что существуют такие ключевые операции, оценка производительности которых «Неприемлемо», «Очень плохо» или «Плохо», то необходимо выполнять работы по оптимизации таких операций в порядке их приоритетов.

Анализ сырых данных Apdex

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

По сырым данным Apdex нужно понять:

Если в полученном распределении имеется несколько пиков, то нужно понять:

Получим распределение времени выполнения операции.

Для этого необходимо воспользоваться обработкой «Оценка производительности», которая входит в состав одноименной подсистемы БСП и в ЦКК (Центр контроля качества, входит в состав Корпоративного инструментального пакета).

С помощью встроенной обработки «Оценка производительности» (её можно найти в настройках контрольной процедуры «Контроль производительности») существует возможность получать распределение времени выполнения одной или нескольких ключевых операций за любой период времени.

Как обработка получает распределение времени? Выбираются необходимые данные замеров времени по ключевой операции за интересующий нас период времени из регистра сведений ЗамерыВремени.

Регистр сведений ЗамерыВремени является частью подсистемы ОценкаПроизводительности, включенной в состав Библиотеки Стандартных Подсистем. Далее рассчитывается распределение частоты времени выполнения ключевой операции по периодам времени. Длительность периода выполнения выбирается экспертом самостоятельно в зависимости от целевого времени T и от сырых данных Apdex и настраивается на форме обработке. По умолчанию длительность периода 0,5 секунды. Очень желательно, чтобы среднее и медианное время выполнения операции попали в выбранный диапазон.

Рассмотрим, для примера ключевую операцию «Проведение документа «Заказ покупателя»».

Выберем длительность периода 1 секунда, и разобьём все значения замеров времени по периодам, например от 0 до 6 секунд. Каждый следующий замер времени из сырых данных Apdex будет отнесен к своему периоду. Например, замер операции, которая выполнилась за 1,51 секунды, будет отнесен к периоду от 1 до 2 (т.е. к периоду (1,2], или просто 2). Если операция выполнилась за 1 секунду, то её замер будет отнесен к периоду от 0 до 1 (т.е. к периоду (0,1], или просто 1). Когда определен период, к которому относится выбранный замер, счетчик числа замеров этого периода увеличивается на 1.

Также в обработке «Оценка производительности» существует возможность выбирать пользователей, по которых необходимо получить оценку производительности за выбранный период времени

В результате по данным замеров времени получаем следующее распределение времени выполнения операции.

Видим распределение времени выполнения операции с одним пиком.

Если время выполнения выглядит так:

то это говорит о неверно встроенных счетчиках замеров времени. Мы наблюдаем два пика, при этом первый из них меньше 0,5 секунды.

Такое распределение характерно для замеров проведения документов, которые начинаются, но не завершаются корректно из-за какой-либо ошибки выполнения операции.

Если время выполнения выглядит так:

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

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

Следующим шагом нужно будет попытаться воспроизвести время выполнения операции, которое:

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

Воспроизведение медленного выполнения операции

Необходимо правильно воспроизводить медленное выполнение операции.

Вы можете получить два результата:

При воспроизведении медленного выполнения операции необходимо всегда замерять время выполнения операции по секундомеру.

Очень важно понимать, какую именно операцию нужно воспроизвести. Мы не просто так искали пик распределения времени.

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

Необходимо всё делать на том же оборудовании. Желательно воспроизводить ровно в тех же самых условиях, конечно, не всегда это возможно.

При воспроизведении необходимо постараться получить условия, в которых операция выполняться быстро, медленно.

Например, пользователь в рабочей системе наиболее часто выполняет операцию за время, близкое к 4 секундам. А целевое время операции T = 1,5 секунды.

Если выполнять операцию в рабочее время, то мы «попадаем в пик», если выполнять операцию в нерабочее время, то мы воспроизводим 1,8 секунды.

Тут очень важно остановить, нарисовать линию, на которой отсечками указать, на что именно уходит время. Если этого не сделать, то можно принять неверное решение.

Далее, по очереди смотрим:

Если операция чаще всего выполняется в веб клиенте, нужно обязательно проверить скорость её выполнения в тонком клиенте и в различных браузерах.

Если воспроизводится медленное выполнение операции

Основной задачей будет: понять, НА ЧТО уходит большая часть времени выполнения операции.

В первую очередь предлагается получить:

Получать все выше перечисленные данные нужно от 1, 2 и 3 выполнения ключевой операции. Первое выполнение должно быть несколько дольше второго и третьего выполнения операции.

Для того чтобы правильно получить замер конфигуратором с серверной частью, нужно чтобы:

Более детально этот вопрос отражен в статье Отладка прикладных решений

Время выполнения всех запросов в однопользовательском режиме от одного выполнения операции можно получить, пользуясь:

Рассмотрим, как можно получить суммарное время выполнения всех запросов на примере MS SQL Server.

Для этого требуется собрать трассировку с помощью MS SQL Profiler по следующим классам событий от одного выполнения операции:

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

DatabaseID можно получить, выполнив запрос:

О том, как фильтровать события в трассировке, есть статья от Microsoft.

Трассировку от одного выполнения операции нужно сохранить в выбранную вами (любую, но НЕ рабочую базу) базу данных, как таблицу, назовем её trace_table_1.

Войдите в выбранную вами базу с помощью MS Server Management Studio и выполните запрос:

Достоинство такого подхода:

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

Для этого сначала подготовим файл logcgf.xml.

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

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

Внимание! При работе с СУБД Oracle НЕ нужно собирать планы при сборе технологического журнала, т.к. это приведет к значительному замедлению работы системы в целом.

Такой файл необходимо расположить на сервере в директории «\bin\conf».

В ОС Windows для технологической платформы версии 8.2.18.101 путь к расположению этого файла будет выглядеть так:

Необходимо до копирования файла logcfg.xml в указанную директорию подготовиться выполнить ключевую операцию.

Это нужно сделать для того, чтобы в собранный технологический журнал в директорию «C:\LOGS\KO1» не попали никакие другие запросы, которые не относятся к ключевой операции.

После того, как вы скопировали файл logcfg.xml с нужными настройками в «\bin\conf» нужно подождать 1 минуту и НЕ выполнять никаких действий.

Дело в том, что платформа читает файл logcfg.xml один раз в минуту, поэтому необходимо подождать и убедиться, что журнал начал собираться с нужными нам настройками.

Выполните операцию один раз и получите от ОДНОГО выполнения ключевой операции:

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

В этом событии DBMSSQL мы видим, что пользователь от имени «Анна» выполнил запрос в базе «db», который завершился в 50 минут 21,1251 секунду и длился 0,012 секунды.

На данном этапе нас интересуют не конкретные запросы и их планы, а общее время выполнения всех запросов. Очень важно понять: на ЧТО уходит время выполнения операции.

Нужно ответить на вопросы:

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

Только после того, когда будет совершенно точно известно, на что уходит больше всего времени, нужно расследовать, почему это происходит.

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

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

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

В этом случае стоит рассмотреть архитектурные способы оптимизации. Например:

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

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

Если не воспроизводится медленное выполнение операции

Если в однопользовательском режиме не воспроизводится медленное выполнение операции, нужно:

Одной из наиболее частых причин, из-за которой не воспроизводится медленное выполнение операции, является наличие очереди к ресурсам. Симптомом этой проблемы будет тот факт, что операция выполняется быстро именно в однопользовательском режиме, а в рабочее время скорость выполнения операции значительно ниже.

В ЦКК в подсистеме Мониторинга также возможно добавить один или несколько показателей производительности Apdex

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

По данным мониторинга можно оперативно среагировать на изменения производительности в системе по одной или нескольким операциям.

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

Причиной такой корреляции могут быть очереди на оборудовании. Для того чтобы их исключить, необходимо проанализировать загруженность оборудования на рабочих серверах «1С:Предприятия» и сервере СУБД.

Часто наиболее узким местом становится именно дисковая подсистема на серверах СУБД. Тут важно не торопиться и не принимать сразу решение о покупке дорогостоящего хранилища. Ситуацию можно значительно улучшить за меньшие деньги. Для этого понадобится понять, а какие именно запросы создают наибольшую нагрузку на дисковую подсистему сервера СУБД. В результате выявления наиболее узких мест, необходимо будет решать, как их устранить.

Также среди причин могут быть избыточные ожидания на блокировках. Для расследования этой проблемы необходимо подключить ЦУП и собрать аналитику по ожиданиям на блокировках за 15 минут работы системы.

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

Как найти запросы, создающие высокую нагрузку на дисковую подсистему сервера СУБД

Иногда возникает вопрос: как найти запросы, которые создают наибольшую нагрузку на диск. Для этих целей не правильно использовать ЦУП, особенно, если нагрузка на систему высокая. ЦУП получает информацию из технологического журнала, который станет узким местом в производительности системы (вместе с дисковой подсистемой, которая будет для этого использоваться) на время сбора полной аналитики (без фильтров по Длительности (Duration)) по запросам.

Ниже приведена методика на примере MS SQL Server. Если у вас используется другая СУБД, то смысл методики не меняется, изменится только инструмент.

1. Настройте MS SQL Profiler по классам событий

Для выбранных классов событий оставьте поля

Установите фильтры по DatabaseID (на исследуемую базу), Reads > N, где N может меняться от 1000000 до 10000. Начните с 1000000. В следующих трассировках можете уменьшить это число. Ваша трассировка должна быть достаточного объема, чтобы делать по ней выводы.

2. Соберите трассировку в пике нагрузки на систему в течение нескольких минут.

3. Сохраните трассировку в отдельную базу данных как таблицу.

4. Сгруппируйте все запросы по TextData, посчитав сумму Reads. Посчитайте суммарное число логических чтений, которое создает какой-либо запрос. В результате вы найдете один или несколько запросов, которые создают наибольшую нагрузку на чтение.

5. Теперь остается найти самый тяжелый (или несколько тяжелых) по числу чтений запрос в коде конфигурации. Например, можно настроить технологический журнал с фильтрами только на один запрос. Может выглядеть так:

Смысл в том, чтобы указать такие фильтры:

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

6. Проанализируйте план запроса, частоту выполнения запроса.

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

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

Источник