Создаем свои индексы для баз 1С. Со своей структурой и настройками!

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

Администрирование - Производительность и оптимизация (HighLoad)

1C 8 SQL Server индексы неплатформенные индексы оптимизация производительности недокументированные возможности

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

О чем речь

Это всего лишь еще одна статья об избитой теме неплатформыенных индексов в информационных базах платформы 1С. Мы поговорим о “плохих” практиках тюнинга, которые с одной стороны запрещены лицензионным соглашением фирмы 1С, а с другой являются наиболее эффективным средством оптимизации производительности запросов. Эдакий запретный плод!

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

  • Используется файловый режим работы информационной базы
  • Нет никаких проблем производительности и стабильности информационной системы
  • Считаете большой ошибкой выход за пределы экосистемы платформы 1С
  • Вы сотрудник фирмы “1С”

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

Будете читать дальше? Тогда отлично, поехали!

Зачем все это

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

Посмотрели? Задаетесь вопросом почему нужны еще какие-то дополнительные индексы?

Ответ на этот вопрос простой. Он даже проще, чем можно себе представить!

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

Ситуация усугубляется еще и тем, что добавление индексов через свойство полей “Индексировать” в конфигураторе имеет примитивные возможности для их настройки. Фактически, Вы можете только выбрать три варианта (да и то не всегда):

  • Не индексировать (с этим и так все понятно)
  • Индексировать (индекс по выбранному полю + доп. поля для уникальности комбинации значений)
  • Индексировать с дополнительным упорядочиванием (индекс по выбранному полю + поля упорядочивания, по которым обычно сортируют данные этой таблицы)

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

Вот Вам пару вопросов для обдумывания:

  • А что если нужно создать индекс сразу по нескольким реквизитам?
  • А если нужен индекс по пометке удаления?
  • Как построить эффективный индекс по любому полю с типом “Булево”?
  • Как добавить индексы в служебные таблицы, недоступные непосредственно в метаданных конфигурации (некоторые основные таблицы, таблицы итогов и др.?
  • Можно ли сделать покрывающий индекс, чтобы исключить операции Lookup к основной таблице или кластерному индексу?

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

  1. Почему бы не использовать произвольные индексы на уровне базы данных с произвольной структурой и настройками?
  2. Для чего тогда были придуманы фильтрованные индексы, покрывающие индексы, произвольные составные индексы, если платформа 1С их не использует? От лукавого? :)

А можно примеры?

Конечно, для наглядности рассмотрим в качестве примеров ответы на те самые вопросы, которые я написал выше. И так, погнали!

А что если нужно создать индекс сразу по нескольким реквизитам

Предположим, что у нас есть справочник “ФизическиеЛица” следующей структуры (некоторые поля пропущены). В самой таблице примерно 2 млн. записей.

Поле 1С Имя SQL Тип SQL
Ссылка _IDRRef binary(16)
ПометкаУдаления _Marked binary(1)
Код _Code nvarchar(10)
Наименование _Description nvarchar(50)
ДатаРождения _Fld11066 datetime2(0)
Фамилия _Fld105061 nvarchar(50)
Имя _Fld105062 nvarchar(50)
Отчество _Fld105063 nvarchar(50)
ДатаСоздания _Fld115447 datetime2(0)
РазделительДанных _Fld1551 numeric(7,0)

В конфигурации есть запрос поиска физического лица по комбинации полей Фамилия + Имя + Отчество + ДатаРождения.

ВЫБРАТЬ
	ФизическиеЛица.Ссылка КАК Ссылка
ИЗ
	Справочник.ФизическиеЛица КАК ФизическиеЛица
ГДЕ
	ФизическиеЛица.Фамилия = &Фамилия
	И ФизическиеЛица.Имя = &Имя
	И ФизическиеЛица.Отчество = &Отчество
	И ФизическиеЛица.ДатаРождения = &ДатаРождения

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

Конечно, можно поставить свойство “Индексирование” в “Индексировать” для каждого реквизита, но что это даст? СУБД сможет использовать один индекс в каждой конкретной операции плана запроса, при этом также будет учитываться актуальность статистики. Запрос 1С конвертируется в такой SQL-запрос.

SELECT
	T1._IDRRef
FROM dbo._Reference477 T1
WHERE ((T1._Fld1551 = @P1)) -- Разделитель данных, есть во всех типовых конфигурациях
	AND ((T1._Fld105061 = @P2) -- Фамилия
	AND (T1._Fld105062 = @P3) -- Имя
	AND (T1._Fld105063 = @P4) -- Отчество
	AND (T1._Fld11066 = @P5)) -- Дата рождения

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

Nested Loops(Inner Join, OUTER REFERENCES:([T1].[_IDRRef], [T1].[_Fld1551]) OPTIMIZED)
  |--Merge Join(Inner Join, 
  |    |            MERGE:([T1].[_Fld1551], [T1].[_IDRRef])=([T1].[_Fld1551], [T1].[_IDRRef]), 
  |    |            RESIDUAL:([DB].[dbo].[_Reference477].[_Fld1551] as [T1].[_Fld1551] = [DB].[dbo].[_Reference477].[_Fld1551] as [T1].[_Fld1551] 
  |    |                AND [DB].[dbo].[_Reference477].[_IDRRef] as [T1].[_IDRRef] = [DB].[dbo].[_Reference477].[_IDRRef] as [T1].[_IDRRef]))
  |    |--Index Seek(OBJECT:([DB].[dbo].[_Reference477].[_Reference477_ByFieldFld11066] AS [T1]), 
  |    |                SEEK:([T1].[_Fld1551]=[@P1] AND [T1].[_Fld11066]=[@P5]) ORDERED FORWARD)                                            
  |    |--Index Seek(OBJECT:([DB].[dbo].[_Reference477].[_Reference477_ByFieldFld105062] AS [T1]), 
  |    |                SEEK:([T1].[_Fld1551]=[@P1] AND [T1].[_Fld105062]=[@P3]) ORDERED FORWARD)
  |--Clustered Index Seek(OBJECT:([DB].[dbo].[_Reference477].[_Reference477HPK] AS [T1]), 
  |                         SEEK:([T1].[_Fld1551]=[DB].[dbo].[_Reference477].[_Fld1551] as [T1].[_Fld1551] 
  |                             AND [T1].[_IDRRef]=[DB].[dbo].[_Reference477].[_IDRRef] as [T1].[_IDRRef]), 
  |                        WHERE:([DB].[dbo].[_Reference477].[_Fld105061] as [T1].[_Fld105061]=[@P2] 

Описание основных действий при выполнении плана запроса следующие.

  Порядок   Операция   Количество прочитанных строк   Описание
1. Index Seek 94 Поиск по индексу “_Reference477_ByFieldFld11066” для реквизита “ДатаРождения”. Повезло, для выбранной даты рождения всего 94 значения, хорошая селективность.
2. Index Seek 10006 Поиск по индексу “_Reference477_ByFieldFld105062” для поля “Имя”. Тут все намного хуже, т.к селективность у этого поля ниже, ведь имя у многих физических лиц может совпадать.
3. Merge Join 2 Объединение результатов 1 и 2 операции методом слияния. В результате получаем две фактически одинаковые строки.
4. Clustered Index Seek 1 Выполняется операция Key Lookup для получения полей запроса, которые не были получены в предыдущих операциях. Key Lookup как известно всегда достаточно тяжелая операция.
5. Nested Loops 1 Вложенным циклом соединяются результаты 3 и 4 операции и получаем итоговый результат запроса - всего 1 строку.

Итог:

  • 419 логических чтений
  • 11 миллисекунд времени выполнения
  • 16 миллисекунд CPU
  • Выборка некоторых частей плана запроса отбирает 10000 записей, но в итоговый результат отбирается всего 1

Вот вам и индексы. 4 индекса, а эффективности никакой. Но нас ничто не остановит, мы создадим свой индекс с произвольными полями и нужной структурой!

CREATE UNIQUE NONCLUSTERED INDEX [_ByNameAndBirthday] ON [dbo].[_Reference477]
(
	[_Fld105061] ASC, -- Фамилия
	[_Fld105062] ASC, -- Имя
	[_Fld105063] ASC, -- Отчество
	[_Fld11066] ASC,  -- Дата рождения
	[_IDRRef] ASC     -- Ссылка
)

Выполним запрос поиска еще раз и вот результат!

Index Seek(OBJECT:([DB].[dbo].[_Reference477].[_ByNameAndBirthday] AS [T1]), 
    SEEK:([T1].[_Fld105061]=[@P2] AND [T1].[_Fld105062]=[@P3] 
        AND [T1].[_Fld105063]=[@P4] AND [T1].[_Fld11066]=[@P5]),  
    WHERE:([DB].[dbo].[_Reference477].[_Fld1551] as [T1].[_Fld1551]=[@P1]) ORDERED FORWARD) 

План запроса стал значительно проще.

  Порядок   Операция   Количество прочитанных строк   Описание
1. Index Seek 1 Операция поиска в некластеризованном индексе “_ByNameAndBirthday”. Поскольку индекс содержит все необходимые поля выборки запроса, то обращение к кластерному индексу отсутствует, т.е. индекс является покрывающим.

Итог:

  • 337 логических чтений
  • 2 миллисекунд времени выполнения
  • 0 миллисекунд CPU (фактически значение незначительное, поэтому не было отловлено трассировкой)
  • План выполнения содержит только одну операцию “Index Seek”, которая фактически читает только 1 строку.

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

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

А если нужен индекс по пометке удаления

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

И так, платформа не даст создать такой индекс, но мы то знаем решение!

CREATE NONCLUSTERED INDEX [_ByDeletionMarkAndCreationDate] ON [dbo].[_Reference477]
(
	[_Marked] ASC,   -- Пометка удаления
	[_Fld115447] ASC,-- Дата создания
	[_IDRRef] ASC    -- Ссылка
)
-- Сделаем фильтрованный индекс
-- В индекс попадают только те записи, у которых установлена пометка удаления
WHERE [_Marked] = 0x01

Что это за условие “WHERE”? SQL Server поддерживает фильтрованные индексы, в которых можно ограничить какие данные в него попадут. Если нужна более подробная информация, то Welcome! Самое главное, что нужно знать - фильтрованные индексы улучшают производительность, качество плана выполнения, расходы на обслуживание и хранение. Очень жаль, что платформа 1С не использует такие возможности СУБД.

Проверим новый индекс запросом.

ВЫБРАТЬ
	ФизическиеЛица.Ссылка КАК Ссылка
ИЗ
	Справочник.ФизическиеЛица КАК ФизическиеЛица
ГДЕ
	ФизическиеЛица.ПометкаУдаления
	И ФизическиеЛица.ДатаСоздания МЕЖДУ &НачалоПериода И &КонецПериода

И вот план запроса.

Nested Loops(Inner Join, OUTER REFERENCES:([Expr1007], [Expr1008], [Expr1009]))
  |--Merge Interval
  |    |--Concatenation
  |         |--Compute Scalar(DEFINE:(([Expr1002],[Expr1003],[Expr1001])
  |         |               =GetRangeWithMismatchedTypes([@P2],NULL,(22))))
  |              |--Constant Scan
  |         |--Compute Scalar(DEFINE:(([Expr1005],[Expr1006],[Expr1004])
  |         |               =GetRangeWithMismatchedTypes(NULL,[@P3],(42))))
  |              |--Constant Scan
  |--Index Seek(OBJECT:([DB].[dbo].[_Reference477].[_ByDeletionMarkAndCreationDate] AS [T1]), 
  |  SEEK:([T1].[_Marked]=0x01 AND [T1].[_Fld115447] > [Expr1007] AND [T1].[_Fld115447] < [Expr1008]),  
  |  WHERE:([DB].[dbo].[_Reference477].[_Fld1551] as [T1].[_Fld1551]=[@P1]) ORDERED FORWARD)  

То что надо! Подробно, как в прошлый раз, описывать план запроса не будем, но вот что стоит заметить: единственная значимая операция здесь - это “Index Seek”, которая как-раз и использует наш новый индекс “_ByDeletionMarkAndCreationDate”. Никаких обращений к основной таблице / кластерному индексу не выполнялось, то есть индекс полностью удовлетворяет условиям и полям выборки запроса, является покрывающим.

Итог:

  • Время выполнения 7 миллисекунд
  • Количество логических чтений = 459
  • Время затраченное CPU 16 миллисекунд
  • План запроса простейший, самая значимая часть - это поиск по индексу “_ByDeletionMarkAndCreationDate”
  • Количество прочитанных строк - 3 (столько помеченных на удаление элементов за указанный период)

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

  • фильтрованный индекс занимает 1 страницу и включает в себя 3 строки конечного уровня.
  • полный индекс занимает 10319 страниц и содержит 2451400 строк конечного уровня.

А если не видно разницы, то зачем платить больше? :)

Таким же способом можно добавлять индексы для любых полей с типом “Булево” и это всегда будет эффективнее, чем добавлять индексы платформенными средствами.

Можно ли сделать покрывающий индекс

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

Покрывающий индекс - это такой индекс, который полностью удовлетворяет условиям запроса. В таких случаях в планах запроса будут отсутствовать операции типа Key Lookup, “добирающие” необходимые поля из таблицы или кластерного индекса (если у таблицы нет кластерного индекса, то операция называется RID Lookup).

Можно лишь добавить, что злоупотреблять покрывающими индексами не стоит и нужно хорошо подумать, прежде чем их создавать. Но это относится вообще ко всем индексам, подходите к ним с умом. Покрывающие индексы могут создаваться либо включением необходимых полей непосредственно в индексируемые поля, либо в покрывающие поля (INCLUDE). Например, можно создать индекс по ФИО + ДатеРождения, но дополнить его полями “Наименование” и “Код”. О преимуществах индекса с включенными полями можно ознакомиться здесь, но главное - это возможность значительно повысить производительность за счет включения в индекс всех необходимых для запроса полей без учета ограничения длины ключа и типов данных.

CREATE UNIQUE NONCLUSTERED INDEX [_IncludeIndex] ON [dbo].[_Reference477]
(
	[_Fld105061] ASC, -- Фамилия
	[_Fld105062] ASC, -- Имя
	[_Fld105063] ASC, -- Отчество
	[_Fld11066] ASC,  -- Дата рождения
	[_IDRRef] ASC     -- Ссылка
)
INCLUDE ( 	
	-- Включенные столбцы
	[_Code],		-- Код
	[_Description]  -- Наименование
)

Теперь, если выполнить запрос из предыдущего примера, но с выбором полей “Наименование” и “Код”, то новый индекс позволит выполнить его максимально эффективно.

ВЫБРАТЬ
	ФизическиеЛица.Ссылка КАК Ссылка,
	ФизическиеЛица.Наименование,
	ФизическиеЛица.Код
ИЗ
	Справочник.ФизическиеЛица КАК ФизическиеЛица
ГДЕ
	ФизическиеЛица.Фамилия = &Фамилия
	И ФизическиеЛица.Имя = &Имя
	И ФизическиеЛица.Отчество = &Отчество
	И ФизическиеЛица.ДатаРождения = &ДатаРождения

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

Как добавить индексы в служебные таблицы

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

Итак, у нас есть регистр бухгалтерии “Хозрасчетный”. Думаю, что все с ним знакомы. В конфигурации есть запросы к физической таблице регистра нескольких видов.

ВЫБРАТЬ
	Хозрасчетный.Регистратор,
	Хозрасчетный.НомерСтроки,
	Хозрасчетный.СчетКт,
	Хозрасчетный.Сумма
ИЗ
	РегистрБухгалтерии.Хозрасчетный КАК Хозрасчетный
ГДЕ
	Хозрасчетный.Активность = &Активность
	И Хозрасчетный.СчетДт = &СчетДт
	И Хозрасчетный.Период МЕЖДУ &НачалоПериода И &КонецПериода

А также вот такой запрос.

ВЫБРАТЬ
	Хозрасчетный.Регистратор,
	Хозрасчетный.НомерСтроки,
	Хозрасчетный.СчетДт,
	Хозрасчетный.Сумма
ИЗ
	РегистрБухгалтерии.Хозрасчетный КАК Хозрасчетный
ГДЕ
	Хозрасчетный.Активность = &Активность
	И Хозрасчетный.СчетКт = &СчетКт
	И Хозрасчетный.Период МЕЖДУ &НачалоПериода И &КонецПериода

Индексов в основной таблице регистра бухгалтерии, которые бы удовлетворяли этим запросом, просто нет. Частично запросы покрываются индексом по счету ДТ и индексом по счету КТ, но с некоторыми оговорками:

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

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

-- Индекс для первого запроса
CREATE NONCLUSTERED INDEX [_CustomIndex1] ON [dbo].[_AccRg1595]
(
	[_Fld1551] ASC, -- Разделитель данных
	[_AccountDtRRef] ASC, -- Счет ДТ
	[_Period] ASC, -- Период
	[_Active] ASC -- Активность
)
INCLUDE ( 	[_RecorderTRef],
	[_RecorderRRef], -- Регистратор
	[_LineNo], -- Номер строки
	[_AccountCtRRef], -- Счет КТ
	[_Fld1599] -- Сумма
)

-- Индекс для второго запроса
CREATE NONCLUSTERED INDEX [_CustomIndex2] ON [dbo].[_AccRg1595]
(
	[_Fld1551] ASC, -- Разделитель данных
	[_AccountCtRRef] ASC, -- Счет ДТ
	[_Period] ASC, -- Период
	[_Active] ASC -- Активность
)
INCLUDE ( 	[_RecorderTRef],
	[_RecorderRRef], -- Регистратор
	[_LineNo], -- Номер строки
	[_AccountDtRRef], -- Счет КТ
	[_Fld1599] -- Сумма
)

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

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

А в чем подвох?

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

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

Не стоит забывать и про еще один подводный камень - это нарушение лицензионного соглашения фирмы “1С”, а именно 65 пункта, в котором явно сказано, что использовать недокументированные возможности нельзя ни при каких обстоятельствах, даже если сильно хочется. Думайте сами - решайте сами.

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

Идем своим путем

В далеком 2014 году на глаза попала статья от Brent Ozar про костыльный подход создания индексов с помощью DDL-триггеров. Смысл его был в том, что при создании таблицы запускался наш произвольный скрипт, который бы и добавлял нужные индексы. Это действительно “особый” подход, только перейдите на эту страницу и посмотрите на изображение :)

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

Спустя пару лет встретился с еще одним материалом, на этот раз в центре сообщества разработчиков 1С - на ИнфостартеАлексей Бочков описывал подход по использованию сжатия таблиц и индексов средствами SQL Server, а в качестве инструмента сохранения сжатия при реструктуризации предлагал использовать тот же подход - через DDL-триггеры. Понял, что тема актуальна и используется многими. Особенно порадовал комментарий от Михаила Максимова.

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

  1. Создал служебную базу с настройками сжатия и произвольными правилами обработки событий создания таблиц и индексов в виде скриптов.
  2. Добавил скрипты предоставления прав для служебных баз.
  3. Создал глобальные триггеры обработки этих событий.
  4. Для того, чтобы снизить риски ошибок скриптов в произвольных правилах, все неплатформенные индексы и другие произвольные действия выполняются после включения следующей настройки:
SET XACT_ABORT OFF;

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

CREATE TRIGGER [CustomSettingsMaintenance_OnTableCreate]
ON ALL SERVER 
AFTER CREATE_TABLE 
AS

BEGIN
	SET NOCOUNT ON;

	-- В случае возникновения ошибок продолжаем работу
	SET XACT_ABORT OFF;

	DECLARE @SchemaName SYSNAME,
		@TableName SYSNAME,
		@DatabaseName SYSNAME,
		@cmd nvarchar(max)

    	SELECT @TableName = EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]','SYSNAME')
		SELECT @SchemaName = EVENTDATA().value('(/EVENT_INSTANCE/SchemaName)[1]','SYSNAME')
		SELECT @DatabaseName = EVENTDATA().value('(/EVENT_INSTANCE/DatabaseName)[1]','SYSNAME');

	-- Здесь запускаем скрипт создания индекса 
	-- с учетом параметров @TableName, @SchemaName, @DatabaseName

	-- Возвращаем значение по умолчанию для ситуаций с ошибками в транзакции
  	SET XACT_ABORT ON;

END

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

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

Вместо заключения

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

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

P.S. Повторю еще раз - ни в коем случае не делайте все то, что Вы здесь прочитали! Это плохие практики разработки, ни к чему хорошему они не приведут!

P.P.S. Но если Вы все же решились, то желаю Вам удачи!

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

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Repich 509 05.11.18 16:06 Сейчас в теме
Насколько я понимаю, в случае использования нового режима реструктуризации, самодельные индексы в общем случае останутся на месте.
3. МихаилМ 05.11.18 16:38 Сейчас в теме
(1) можно таблицы подменять представлениями (например для использования общего кладра(фиаса)) .

(0) решена ли в Ваших разработках проблема долгого копирования данных (по 1000 записей) из старой таблицы в новую ?
8. YPermitin 9795 05.11.18 19:31 Сейчас в теме
(3) Это не проблема неплатформенных индексов. Я бы вообще не назвал это проблемой.

Но есть известные пути ускорения реструктуризации на больших таблицах, когда такой путь "перезаливки" данных из старой таблицы в новую мешал обновлению информационной базы. Имеет ли смысл его здесь описывать.
6. YPermitin 9795 05.11.18 19:29 Сейчас в теме
(1) на сколько я понимаю и "ДА" и "НЕТ".

Но подробнее не скажу, т.к. плотно не изучал работу новой реструктуризации. Была попытка использования в начале ее появления, но столкнулся с .... непреодолимыми проблемами на тот момент.
9. Repich 509 05.11.18 19:38 Сейчас в теме
(6) Мы в пятницу кстати натолкнулись на преодолимые проблемы, была проблема в конфигурации, которая для старого режима была вполне себе проходной, а вот для нового оказалась непреодолимой, в результате которой падала в exception.
14. herfis 374 06.11.18 10:44 Сейчас в теме
Я бы очень тщательно взвешивал за и против, принимая решение об использовании своих индексов. Даже при наличии хороших спецов по сиквелу. ИМХО, имеет смысл только на тяжелых продуктовых базах, где без тонких настроек не обойтись и которые на постоянном сопровождении у спецов с поставленной культурой разработки. База знаний, инструкции и т.п.
(1) Я бы на это не полагался. Случаи разные бывают, особенно учитывая что новый режим опционален.
darkdan77; dabu-dabu; Silenser; Fox-trot; YPermitin; +5 Ответить
15. YPermitin 9795 06.11.18 10:47 Сейчас в теме
(14) Полностью поддерживаю Ваши слова.
Без знаний SQL Server за это дело лучше вообще не браться.
16. herfis 374 06.11.18 10:54 Сейчас в теме
(15)
Без знаний SQL Server за это дело лучше вообще не браться.

Проблема в том, что "знание SQL Server" - это примерно как "знание боевых искусств". Его всю жизнь получать можно :) Слишком много ньюансов и неоднозначных компромиссов, познание которых требует глубокой практики.
17. YPermitin 9795 06.11.18 11:13 Сейчас в теме
(16) Главное не сдаваться :)

Так можно про любую сферу сказать, в т.ч. и 1С.
19. herfis 374 06.11.18 11:51 Сейчас в теме
(17) Ясен пень. Просто меня умиляют формулировки типа "ну, конечно нужно иметь знания SQL Sever". Насколько глубокие - вот вопрос из вопросов :)
(18) Это типа само собой входит в "знание SQL Server". Как и оверхед по дисковому пространству. Который даже в случае обычных индексов может быть очень существенным. Вы ведь не будете создавать доп-индексы на маленьких табличках? :) Про покрывающие индексы я вообще молчу.
YPermitin; ImHunter; +2 Ответить
20. YPermitin 9795 06.11.18 11:57 Сейчас в теме
(19)
Ясен пен


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

Никто же не спорит.
21. herfis 374 06.11.18 12:30 Сейчас в теме
(20)
Никто же не спорит.

Так и я не спорю. И статья хорошая.
Просто ИМХО в таких статьях нужно больше запугивать расписывая возможные недостатки и жирнее намекать на необходимость получения дополнительных знаний :) Желательно со ссылками на хорошие профильные материалы.
Ведь целевая аудитория - кто? Те, кто вряд ли обладает достаточными знаниями и способен оценить степень их нехватки. Иначе зачем им эта статья?
22. YPermitin 9795 06.11.18 12:42 Сейчас в теме
(21) Картинки к статье должно быть достаточно :)))
freelancer; +1 Ответить
2. МихаилМ 05.11.18 16:31 Сейчас в теме
ddl триггеры появились в ms sql 2005. а статья в 2018 . ну лучше поздно...
7. YPermitin 9795 05.11.18 19:29 Сейчас в теме
(2) Не думаю, что вопрос, почему такое никто не написал раньше, относится ко мне :)
4. nomadon 391 05.11.18 18:07 Сейчас в теме
Действия направленные против лицензионной политики преследуются законом?
5. YPermitin 9795 05.11.18 19:26 Сейчас в теме
(4) Я не могу здесь Вам дать точный ответ на этот вопрос.
10. geron4 162 06.11.18 07:27 Сейчас в теме
(4) Никто Вас преследовать не будет, проблема может возникнуть, если Вы с Вашей конфигурацией обратитесь в 1С с какой-нить претензией, вероятно Вам откажут в помощи.
Fox-trot; +1 Ответить
13. palsergeich 06.11.18 10:26 Сейчас в теме
(10)
(4) 1с на обучении говорит что нельзя, но если прям ваще надо надо, то можно. Потому что иногда это единственный выход.
Но официально они это не одобряют.

Не совсем так, для оказания помощи они потребуют привести базу к типовому функционалу, потому что за кастомные механизмы они не отвечают
andron77777; +1 Ответить
12. palsergeich 06.11.18 10:19 Сейчас в теме
(4) 1с на обучении говорит что нельзя, но если прям ваще надо надо, то можно. Потому что иногда это единственный выход.
Но официально они это не одобряют.
11. SkyJack 06.11.18 10:16 Сейчас в теме
Большое спасибо за статью. Добавил в закладки.
18. ImHunter 202 06.11.18 11:40 Сейчас в теме
(0) Не описан еще один подвох.
СУБД будет тратить доп.ресурсы на актуализацию еще одного (добавленного) индекса при CRUD-операциях изменении данных в проиндексированной таблице.
23. Slava_prog 06.11.18 13:33 Сейчас в теме
Спасибо очень познавательно. Хотелось бы аналогичный материал для PostgreSQL
24. YPermitin 9795 06.11.18 14:05 Сейчас в теме
(23) Все что здесь сказано относится и к PG, но с некоторыми оговорками (большими и маленькими).

На заметку взял, но заниматься PG не очень хочется :)
25. aximo 1637 07.11.18 08:46 Сейчас в теме
(24) хорошая статья, напишите - на базах какого объема вы стали делать подобное?

по практическому опыту - у нас доросла торговая база до 7 млн. документов за 2 года - много это или нет. Потом, было принято решение сделать срез :)
26. YPermitin 9795 07.11.18 10:52 Сейчас в теме
(25) от 100 ГБ и выше, в т.ч. и базы больше 1 ТБ.

Срез это больше как обезболивающее с побочными эффектами :)
Но не осуждаю! )
user600203_7377360; mrsmrv; +2 Ответить
27. Darklight 24 08.11.18 14:29 Сейчас в теме

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

Представляю это почти каждый рабочий день ;-)
Может, когда-нибудь да сделают. Но, если сделают, это точно выйдет за рамки PROF-лицензии на платформу - это уже тонкая настройка, не для всех (надо ограничить шаловливые ручонки) - это функционал действительно для тех, только, кто знает толк в преимуществах КОРПоративных фишек платформы, и купил соответствующую лицензию.

А вообще - я себе такую функционал представляю в рамках инструмента, за пределами конфигуратора. Размышляя о том, что нас может когда-нибудь ждать в 1С Предприятие 9 - мне видится логичным создания отдельного инструмента по мониторингу и тюненгу производительности + основные фишки, касающиеся администрирования ИБ и кластерной инфраструктуры тоже там же должны быть: этакий пылесос, совмещающий средства по настройке отдельных параметров в СУБД (ну там регламентное обслуживание хотя бы, ведение статистики и распараллеливание запросов...) + вот такие фишки по настройке индексов (включая сбор данных из СУБД по желаемым индексам), ну и заодно настройка сегментирования и файловых групп + некоторый функционал ЦУП по настройке анализу тех журнала, сбору счетчиков, здесь же и анализ журнала регистрации + ЦКК для анализа стабильности системы и возникших ошибок + средства администрирования кластера тоже надо включить в этот инструмент + управление лицензиями тоже здесь же + я бы ещё и управление пользователями правами пользователей тоже включил бы в этот инструмент + тут же должен быть контроль за внешними компонентами, внешними обработками и прочими программными модулями - что разрешено, что запрещено (поэлементно или с разрешёнными ЭЦП поставщиков - ну тут в основном имеются в виду программисты, которые это всё будут подготавливать) + инструментарий по настройке резервного копирования. И заниматься эти функционалом должны, по хорошему, не программисты, а специальные администраторы (баз данных) или эксперты по тех. вопросам. А в конфигурации, программистам дал бы возможность создавать, в метаданных как бы свои параметризованные источники данных (как виртуальные таблицы, а на языке СУБД - представления или даже процедуры, т.к. нужна поддержка временных таблиц) - тогда большая часть запросов к данным должна переместиться в такие источники, которые смог бы уже анализировать администратор баз данных в своём инструменте (собирая и анализируя статистику их использования) - и создавать нужные индексы. Да, управление агрегатами тоже бы вынес из конфигуратора в этот новый инструмент. Ну не должен программист решать такие тонкие нюансы производительности - в тех, компаниях, где это действительно актуально должен быть свой специалист по вопросам производительности СУБД и 1С, ну или хотя бы должен проводиться периодический внешний аудит.
И всё это должно быть в одном инструменте, реализованным не как конфигурация, а как часть платформы - но в виде отельного приложения с отдельным уровнем доступа.
YPermitin; +1 Ответить
28. YPermitin 9795 08.11.18 15:01 Сейчас в теме
(27)
Представляю это почти каждый рабочий день ;-)


Боюсь, что мы этого никогда не увидим от фирмы "1С" и будем мечтать и дальше, потому что это выходит далеко за пределы назначения самой платформы. Это скорее аналог некоторой платформы, как Microsoft .NET, которая обросла огромной экосистемой.

Для платформы 1С это нереально, т.к. задачи иные и уровень разработки другой.
Да и смысл делать все эти прослойки в самой платформе, если есть огромное количество отличных сторонних инструментов. Все что требуется от 1С - не мешать их использовать.
29. Darklight 24 08.11.18 15:21 Сейчас в теме
(28)1С может сама и не делать - а лицензировать создание таких инструментов другим разрабочтикам - с перекладыванием ответственности на них. Но платформа 1С: Предприятие (в отличии от Microsoft .NET) является коммерческим продуктом - и компания 1С, продавая её, делает на этом бизнес. Тому пример - разделение лицензий платформы (пока в серверной части) на МИНИ/ПРОФ/КОРП с разной стоимостью - чтобы заполнить разные сегменты рынка. Чтобы более дорогие лицензии были востребованы они должны включать в себя расширенный инструментарий, особенно тот, который как раз нужен потребителям в этом сегменте - чтобы у них был стимул переходить на более дорогие решения.
YPermitin; +1 Ответить
30. YPermitin 9795 08.11.18 17:17 Сейчас в теме
(29) в этом случае - да, согласен.
31. kuza_87 26 16.10.19 18:08 Сейчас в теме
Спасибо за статью, очень помогло. Создал для документа индекс по дате и пометке удаления. На всякий пожарный сделал перестроение, реорганизацию, очистил процедурный кэш. Делаю запрос с отбором по дате + пометке удаления. Смотрю в профайлере, а запрос всё равно происходит к индексу, где нет пометки удаления. Как заставить оптимизатор делать запрос к нужному индексу? Или он решил что ему дешевле сделать запрос к непокрывающему индексу?
32. vis_tmp 30 01.06.20 17:03 Сейчас в теме
Отличная статья "Создаем свои индексы для баз 1С" - спасибо!
Оставьте свое сообщение

См. также

Диспетчер Хранилища Запросов в SQL Server 2016+ (он же Query Store) Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

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

26.04.2019    11517    Aleksey.Bochkov    7    

Анализ проблем производительности по динамике мониторинга RAS 1C

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

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

07.10.2020    2587    ivanov660    12    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

Производительность и оптимизация (HighLoad) v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    3255    Nykyanen    16    

Описание почти всех событий технологического журнала

Технологический журнал v8 Бесплатно (free)

Краткое описание событий технологического журнала с примерами. Все для быстрого старта.

19.08.2020    6579    YPermitin    29    

Опыт миграции из собственного датацентра в облако AWS Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Хотя данная публикация и не имеет прямого отношения к 1С, она может быть интересна тем, кто занимается крупными базами данных на MS SQL Server. Описывается опыт миграции баз данных в облако AWS в компании glassdoor.com, где я занимался этим проектом. Это первый драфт текста, получившийся довольно скомканным - в процессе буду дополнять.

29.07.2018    11560    Aleksey.Bochkov    9    

SQL для 1С: пишем правильно, красиво, сложно

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Многие программисты боятся работать с Null, считая, что от этих данных в запросах нужно избавляться. О том, как с помощью Null-полей в запросе решать востребованные в учете задачи по выборке данных, на конференции Infostart Event 2019 Inception рассказал ведущий разработчик ГК WiseAdvice Дмитрий Дудин.

14.08.2020    9413    dmurk    30    

Нестандартные блокировки при работе с OLAP-нагрузкой

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    1928    Филин    7    

Автоматическая классификация ошибок технологического журнала

Технологический журнал v8 1cv8.cf Бесплатно (free)

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

25.06.2020    2740    ivanov660    12    

Исследование технологического журнала 1С при помощи регулярных выражений в блокноте Промо

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Все из тех, кто пробовали сдать на сертификат "Эксперт по технологическим вопросам 1С", сталкивались с методикой ЦКТП - разбор файлов технологического журнала при помощи консоли bash. Я, в свою очередь,внёс изменения в данную методику. Мне хотелось достичь более понятного вида и сфокусироваться на Perl, в качестве предпочтительного средства обработки файлов ТЖ. Вот что из этого вышло:

30.10.2017    29786    MrWonder    42    

Выбор процессора для 1С: конец споров или начало?

Производительность и оптимизация (HighLoad) Бесплатно (free)

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

25.05.2020    11156    starik-2005    232    

Выявляем и оптимизируем ресурсоемкие запросы 1С:Предприятия

Производительность и оптимизация (HighLoad) Администрирование СУБД Технологический журнал Структура метаданных v8::Запросы Бесплатно (free)

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

24.05.2020    7445    DataReducer    22    

Учимся готовить кроликов с редиской: опыт применения Rabbit MQ и Redis в интеграционных проектах

Производительность и оптимизация (HighLoad) Интеграция Бесплатно (free)

При построении мощных производительных отказоустойчивых решений для интеграции во всем мире активно используются технологии обработки очередей сообщений с помощью брокера RabbitMQ и кэш-сервера Redis. О практическом опыте использования этих технологий при построении ИТ-ландшафта, включающего системы на 1С, на конференции Infostart Event 2019 Inception рассказал Сергей Наумов.

12.05.2020    5604    SergeyN    3    

Опыт оптимизации и контроля производительности в БД с 3000 пользователей Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

05.08.2015    61409    Sergey.Noskov    119    

Ок, Лариса! Мониторинг проблем производительности с применением нейронных сетей

Производительность и оптимизация (HighLoad) Бесплатно (free)

Проводить мониторинг производительности вручную, выявляя закономерности в куче графиков и десятках таблиц, довольно сложно. Но это не значит, что разбираться с инцидентами нужно только после жалоб от пользователей. О том, как обучить нейронную сеть и заставить ее оповещать о проблемах, на конференции Infostart Event 2019 Inception рассказал начальник сектора разработки ООО «Группа Полипластик» Владимир Крючков.

27.04.2020    4153    ivanov660    5    

Пример поиска ошибок в технологическом журнале

Технологический журнал Производительность и оптимизация (HighLoad) Бесплатно (free)

Примеры bash - скриптов для поиска ошибок в технологическом журнале.

23.04.2020    2888    vasilev2015    7    

Фреймворк "Мониторинг производительности". Руководство пользователя

Производительность и оптимизация (HighLoad) Бесплатно (free)

Описание и руководство "Мониторинг производительности": краткое описание конфигурации, сборник из статей, примеров - собрано в одном файле.

21.04.2020    3522    ivanov660    3    

Долго открывается конфигуратор Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    41063    Gilev.Vyacheslav    1    

Эти занимательные временные таблицы

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    11758    YPermitin    0    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

Производительность и оптимизация (HighLoad) WEB Интеграция Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    13020    informa1555    31    

Многострочный контекст событий

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

31.03.2020    3160    vasilev2015    9    

Сжатие баз данных 1С:Предприятие в MS SQL Server Промо

Администрирование данных 1С Россия Бесплатно (free)

Тема сжатия баз данных 1С в настоящий момент довольно часто обсуждается. Достоинства сжатия известны – уменьшение размера базы данных, уменьшение нагрузки на дисковую подсистему и некоторое ускорение выполнения тяжелых операций чтения/записи. Из недостатков – небольшое увеличение нагрузки на процессоры сервера СУБД за счет расхода ресурсов на компрессию/декомпрессию данных. Но при использовании в качестве MSSQL и DB2 (за Oracle и PostgreSQL не скажу, т.к. не знаю) есть один «подводный камень» - при выполнении реструктуризации происходит декомпрессия новых таблиц и индексов. Происходить это может как при выполнении обновления конфигурации с изменением структуры метаданных, так и при выполнении тестирования и исправления ИБ (реиндексация пересоздает только индексы, а реструктуризация – и таблицы, и индексы). «Проблема» кроется в том, что признак сжатия устанавливается индивидуально для каждой таблицы и индекса.

29.01.2012    88565    Aleksey.Bochkov    57    

Анализ взаимоблокировок

Производительность и оптимизация (HighLoad) Технологический журнал v8 Бесплатно (free)

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

20.03.2020    4950    vasilev2015    24    

Многопоточность

Практика программирования Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    7219    kaliuzhnyi    43    

Повышенная нагрузка на диски сервера баз данных SQL Server Промо

Производительность и оптимизация (HighLoad) Бесплатно (free)

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

15.03.2015    40493    gallam99    17    

Улучшение пооперационного планирования в 1С:ERP 2.4 внешними средствами

Математика и алгоритмы Производительность и оптимизация (HighLoad) Бесплатно (free)

Задача построения оптимального производственного расписания требует сравнения тысяч и десятков тысяч вариантов. Выполнять такие вычисления средствами платформы 1С Предприятие нецелесообразно. Как реализовать пооперационное планирование с использованием генетических алгоритмов и параллельных вычислений в докладе на конференции Infostart Event 2019 Inception рассказал генеральный директор компании «ИНТЕХ» Сергей Сафаров.

02.03.2020    5379    ildarovich    7    

Делаем быстрее POSTGRESQL COUNT (*)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Laurenz Albe "POSTGRESQL COUNT(*) MADE FAST". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/postgresql-count-made-fast/

28.02.2020    2725    w.r.    1    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    67418    yuraos    112    

Простое обнаружение проблем производительности в PostgreSQL

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Hans-Jürgen Schönig "DETECTING PERFORMANCE PROBLEMS EASILY IN POSTGRESQL". Оригинал доступен по ссылке https://www.cybertec-postgresql.com/en/detecting-performance-problems-easily-in-postgresql/ Актуально для всех 1С ников, перешедших с MS SQL на Postgres

20.02.2020    4272    w.r.    4    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

Производительность и оптимизация (HighLoad) v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    9728    Evil Beaver    13    

Держи данные в тепле, транзакции в холоде, а VACUUM в голоде

Производительность и оптимизация (HighLoad) Бесплатно (free)

Чтобы база работала быстро – в ней нужен порядок. Это касается как MS SQL, так и PostgreSQL. Как настроить базу, чтобы в ней поддерживался порядок, какие регламентные операции нужно проводить, чтобы данные чистились, индексы перестраивались и оперативная память высвобождалась в своём выступлении на конференции Infostart Event 2019 Inception поделился руководитель ИТ в компании «ИнфоСофт» Антон Дорошкевич. 

07.02.2020    10769    a.doroshkevich    20    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

Производительность и оптимизация (HighLoad) v8 УТ10 УПП1 Бесплатно (free)

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

21.06.2013    54528    Антон Ширяев    117    

Оптимизатор запросов. Вторая часть

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

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

23.01.2020    6456    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    7918    Kaval88    26    

Атака сервера кнопонажималкой

Нагрузочное тестирование Инструментарий разработчика Бесплатно (free)

Чтобы убедиться, что продукт выдержит планируемую нагрузку, необходимо провести нагрузочное тестирование – написать сценарии пользовательских действий и запустить их в несколько потоков, чтобы заранее найти проблемы в бизнес-логике и «узкие места». О том, как упростить написание сценариев тестирования для конфигурации Тест-центр с помощью фреймворка Vanessa Automation на конференции Infostart Event 2019 Inception рассказал ведущий программист компании «ПервыйБИТ» Никита Грызлов.

20.01.2020    6005    nixel    22    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    54796    Gilev.Vyacheslav    46    

Активный 2019 год на Инфостарт

О сообществе О жизни Бесплатно (free)

О прошедшем 2019 годе в 100 и 500 словах.

26.12.2019    5976    YPermitin    24    

Мониторим производительность с помощью 1С RAS

Инструментарий разработчика Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Подключаемся и анализируем данные через 1С RAS. Необходимо выполнить 5 пунктов и серьезный инструмент мониторинга будет у вас в руках.

19.12.2019    11642    ivanov660    16    

Самые распространенные заблуждения об индексах в мире 1С

Администрирование данных 1С Администрирование СУБД Бесплатно (free)

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

28.11.2019    20774    YPermitin    50    

Параллельные вычисления в 1С 8 Промо

Производительность и оптимизация (HighLoad) v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    30098    gallam99    19    

История роста и работы команд 1С в условиях HighLoad и BigData

Автоматизация ИТ-компании Производительность и оптимизация (HighLoad) Бесплатно (free)

Современные потребности бизнеса заставляют программистов 1С решать все более сложные задачи. А главные требования, которым необходимо соответствовать, – вовремя поставлять ценности высокого качества. С какими сложностями приходится сталкиваться в работе программистам в динамично развивающейся брокерской сфере, и как их решают, на конференции Infostart Event 2018 Education рассказал начальник отдела интеграции БКС Технологии Сергей Артемов.

11.11.2019    7636    user826155    11    

Об общих реквизитах

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

Общие реквизиты. Что за ними скрывается?

28.10.2019    13650    YPermitin    30    

Обслуживание баз данных. Не так просто, как кажется

Производительность и оптимизация (HighLoad) Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    17872    YPermitin    28    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    42287    madmpro    32    

Набор скриптов для знакомства с SQL Server

Производительность и оптимизация (HighLoad) Администрирование СУБД Бесплатно (free)

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

30.09.2019    22257    YPermitin    15    

Мониторинг высоконагруженной системы

Производительность и оптимизация (HighLoad) v8 Бесплатно (free)

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    9079    Repich    5    

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

Администрирование данных 1С Zabbix v8 Бесплатно (free)

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    18765    Sloth    24    

Подбор оборудования для информационных систем на платформе 1С

Интеграция Производительность и оптимизация (HighLoad) Бесплатно (free)

При подборе оборудования по рекомендациям с сайта ИТС возникает противоречие: проводить ли нагрузочные тесты, чтобы определить возможную нагрузку, или достаточно просто взять данные из таблиц статистики? О том, какую тактику применить в том или ином случае, на конференции INFOSTART EVENT 2018 Education рассказал начальник отдела разработки компании IBS Филиппов Евгений.

09.09.2019    9171    jf2000    8    

Руководство по SQL: Как лучше писать запросы (Часть 2)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию продолжение перевода статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Первая часть доступна по ссылке https://infostart.ru/public/1115809/

03.09.2019    7608    w.r.    2    

Руководство по SQL: Как лучше писать запросы (Часть 1)

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Karlijn Willems SQL Tutorial: How To Write Better Queries". Оригинал доступен по ссылке https://www.datacamp.com/community/tutorials/sql-tutorial-query. Узнайте о антипаттернах, планах выполнения, time complexity, настройке запросов и оптимизации в SQL.

30.08.2019    10947    w.r.    19    

Использование Union вместо OR

Производительность и оптимизация (HighLoad) Бесплатно (free)

Предлагаю вашему вниманию перевод статьи Derek Dieter "Using Union Instead of OR". Оригинал доступен по ссылке http://sqlserverplanet.com/optimization/using-union-instead-of-or.

22.08.2019    4043    w.r.    35