Копия базы 1С для отчетов. Или как выжить с тяжелой отчетностью

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

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

SQL Server репликация отчетность AlwaysOn бэкапирование копия базы обмен отчеты производительность.

Способы создания копии базы 1С для отчетов. Бэкапирование, репликация, AlwaysOn и другие страшные слова.

Проблема на пустом месте?

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

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

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

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

  • Операционные (OLTP), где ведется основная работа бизнеса. Работа этих систем критична для бизнеса, а остановка в случае нештатных ситуаций может стоить компании значительных средств.
  • Отчетные (OLAP), предназначены для сбора различных видов отчетов. За счет изолирования от операционной базы, формирование тяжелой аналитической отчетности не повлияет на производительность и стабильность ее работы. Обычно остановка этих баз не так сильно отзывается на работе компании.

Создать отдельную базу для отчетов можно несколькими путями:

  1. Сделать копию операционной базы данных.
  2. Организовать хранилище данных.

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

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

Внимание!!

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

Ах да, все примеры для клиент-серверных баз в контексте работы со SQL Server. Что-то будет актуально и для PostgreSQL.

Классический подход

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

Формирование и последующее разворачивание бэкапа делается через SQL Server Managment Studio в несколько простых шагов.

 
 Делаем бэкап, чтобы ничего не сломать

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

Плюсы:

  • Простота реализации и настройки.

Минусы:

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

Просто, эффективно, но медленно!

Скриптуем все!

Но что, если нужно обновлять отчетную базу чаще? Например, раз в сутки?

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

Например, так мы сформируем бэкап.

BACKUP DATABASE [SuperDatabase] 
	TO  DISK = N'F:\DBs\MSSQL14.MSSQLSERVER\MSSQL\Backup\SuperDatabase.bak' 
	-- Указываем флаг "Архивная копия только для копирования"
	-- Подробнее: docs.microsoft.com/ru-ru/sql/relational-databases/backup-restore/copy-only-backups-sql-server?view=sql-server-2017
	WITH  COPY_ONLY, 
	NOFORMAT, 
	NOINIT,  
	NAME = N'SuperDatabase-Полная База данных Резервное копирование', 
	SKIP, 
	NOREWIND, 
	NOUNLOAD, 
	STATS = 10

А потом обновим отчетную базу.

RESTORE DATABASE [SuperDatabase_ForReports] 
	FROM  DISK = N'F:\DBs\MSSQL14.MSSQLSERVER\MSSQL\Backup\SuperDatabase.bak' WITH  FILE = 1,  
	MOVE N'SuperDatabase' TO N'F:\DBs\MSSQL14.MSSQLSERVER\MSSQL\DATA\SuperDatabase_ForReports.mdf',  
	MOVE N'SuperDatabase_log' TO N'F:\DBs\MSSQL14.MSSQLSERVER\MSSQL\DATA\SuperDatabase_ForReports_log.ldf',  
	NOUNLOAD,
	-- Перезаписываем базу данных, если она уже была создана ранее
	REPLACE,
	STATS = 5

Чтобы этот процесс выполнялся автоматически раз в сутки создадим задание на SQL Server.

 
 Скрипт создания задания на SQL Server

Плюсы:

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

Минусы:

  • Не подходит для формирования оперативных отчетов.
  • Не подходит для формирования отчетности по прошлым периодам, если там интенсивно выполняется корректировка данных. Ну никто же так не делает! :)

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

Реплицируем через репликацию

Другой способ - это репликация стандартными средствами SQL Server. На самом деле, это не самый подходящий вариант передачи изменений баз 1С в их копию, потому что для его эффективной работы необходимо было бы добавить первичные ключи во все таблицы. Платформа 1С этого не делает. Конечно, можно было бы добавить ключи самостоятельно и, о боже, поддерживать при реструктуризации. Но, даже это бы не помогло, потому что для некоторых таблиц ключ просто невозможно добавить. Например, для таблицы "DBSchema", в которой только одно поле с типом "varbinary(max)".

Вообще, есть несколько основных видов репликации:

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

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

Мне удавалось запустить репликацию базы данных 1С через метод "Репликация транзакций", который был бы идеальным, если бы платформа корректно создавала первичные ключи для таблиц. Но мир не идеален, поэтому пришлось выполнять несколько дополнительных действий:

  1. Добавляем первичные ключи во все таблицы где есть кластерный индекс.
  2. После добавляем ключи в таблицы "кучи", если это возможно.
  3. Для таблиц, где первичный ключ добавить нельзя (например, та же таблица "DBSchema") добавляем свое числовое поле "ID" с автоинкрементом, которое и будет первичным ключом. Платформа 1С ничего об этом поле знать не будет.

Да, репликация работала, но это такая лютая схема, что лучше ее никогда не использовать и не продвигать дальше этапа экспериментов. К тому же, нужно позаботиться о том, чтобы в базе приемнике не изменялись данные. Но Вы можете попробовать :). Результаты моих экспериментов постепенно выкладываются здесь.

И так, что имеем.

Плюсы:

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

Минусы:

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

Таким образом, это для лютых извращенцев, которые не ищут легких путей! :)

Копия в реальном времени

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

Репликация при AlwaysOn может быть двух типов:

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

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

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

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

  • SQL Server 2012 и выше редакции Enterprise Edition. Также функционал доступен для Standard Edition, но с ограничениями:
    • Максимум 2 реплики (первичная и вторичная)
    • Нет доступа на чтение для второй реплики
    • Только одна база в каждой группе доступности.
  • Операционная система Windows Server 2012 и выше.
  • Настроенный отказоустойчивый кластер Windows (WSFC).

Таким образом, нужен квалифицированный администратор, лицензии на Windows Server и SQL Server редакции Enterprise. Цена может подходить не для всех. Процесс настройки рассматривать в статье не будем, но ознакомиться с самой простой конфигурацией по шагам Вы можете по следующим ссылкам:

Сейчас же остановимся на некоторых особенностях работы баз 1С с репликами AlwaysOn. Допустим, у нас сделана настройка асинхронной реплики. База данных на втором узле практически всегда находится в актуальном состоянии. Но находится она в режиме только для чтения! Мы развернули отдельный сервер 1С, добавили эту базу и попытались зайти в нее в режиме 1С:Предприятие. Первое, что мы увидим будет...

> Невосстановимая ошибка
> Ошибка при выполнении запроса POST к ресурсу /e1cib/modules/call:
> по причине:
> Соединение с сервером баз данных непригодно для использования после разрыва соединения администратором и будет переустановлено.
> Microsoft SQL Server Native Client 11.0: Failed to update database "YourDatabaseName" because the database is read-only.
> HRESULT=80004005, SQLSrvr: SQLSTATE=25000, state=2, Severity=10, native=3906, line=1

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

  1. Использовать толстый клиент обычного приложения с некоторыми модификациями конфигурации.
  2. Формировать отчеты через интеграцию (COM-соединение, веб-сервисы, HTTP-сервисы, OData-интерфейс).

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

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

Мысли напоследок

Вы дочитали до конца и задались вопросом: "Почему не использовать стандартные возможности платформы?". Например, создать базу и наполнять ее через обмены или вообще сделать узел УРБД. Справедливый вопрос! Но и ответ простой - скорость и производительность!

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

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

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

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

Хорошим и дешевым был бы способ репликации транзакций, но из-за особенностей баз 1С его сложно применять.

Самым доступным и распространенным остается способ через бэкапирование и разворачивание резервных копий со всеми вытекающими недостатками и ограничениями.

Все вышеперечисленное не является готовым решением или истиной, а лишь поверхностно отражает накопленный опыт автора. Есть чем дополнить или нашли ошибку? Добро пожаловать в комментарии или на GitHub!

Другие ссылки

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

Комментарии
Избранное Подписка Сортировка: Древо развёрнутое
Свернуть все
1. 3vs 22.04.19 07:17 Сейчас в теме
Юрий, а ежели, продолжая разговор из "Самый быстрый шринк на Диком Западе",
infostart.ru/public/1031815/
рассмотреть вариант со сливанием фрагментированной базы в пустой дисковый массив с одновременной дефрагментацией файлов базы,
можно получить OLTP свежую базу и "грязную" OLAP базу, которая, правда, не наполняется свежими данными, но вполне себе, доступна для отчётов, не накончиках пальцев, конечно, но всё же, а потом грязный дисковый массив можно отформатировать для очередной "рокировочки" (© Ельцин Б.Н.)?
YPermitin; +1 Ответить
2. YPermitin 8548 22.04.19 07:36 Сейчас в теме
(1) надо эксперементировать, как я и раньше говорил :)

Но что-то мне подсказывает, что проблем можно больше огрести.
3. ellavs 711 22.04.19 07:58 Сейчас в теме
Спасибо за систематизацию способов. Мы сами используем классику вручную. У нас на будущее ("на будущее" просто потому что мне некогда этим заняться) висит такая задачка: периодическое поднятие копии базы (через бэкап на MS SQL), затем копия должна понимать, что она копия - соответственно останавливать выполнение регламентных заданий и в заголовках прописывать, что она копия. Плюс копия должна поднимать полномочия определенных пользователей, которым разрешено "баловаться" в копии базы. Скорее всего нужно сделать обработку, которая должна запускаться после восстановления бэкапа...
rpgshnik; YPermitin; +2 Ответить
4. YPermitin 8548 22.04.19 08:10 Сейчас в теме
(3) Спасибо!

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

Остальное, да. Это уже свои инструменьы и скрипты "допилить".
5. baklanov_i 22.04.19 09:19 Сейчас в теме
(4) Блокировка заданий находится в свойствах базы на сервере 1с, разве нет?
6. YPermitin 8548 22.04.19 09:23 Сейчас в теме
(5) В БСП есть событие, которое вызывается при старте любого регламентного задания. Там проверяется является ли база тестовая или копия и в случае чего задание останавливается.

Для самописных если это событие вызывается, то проверка тоже сработает.

А так да, на сервере можно запретить в свойствах информационной базы.
25. rpgshnik 2185 23.04.19 04:57 Сейчас в теме
(3) я бы почитал такую статью как это сделать :)
32. ellavs 711 23.04.19 16:47 Сейчас в теме
(25) если получится такое реализовать, постараюсь написать :)
7. starik-2005 2172 22.04.19 09:56 Сейчас в теме
Не благодарите
https://docs.microsoft.com/ru-ru/sql/relational-databases/replication/snapshot-replication?view=sql-server-2017

ЗЫ: уже миллион раз говорил, что если кто хочет повысить скорость работы системы - пусть разделит OLAP и OLTP.
MaZaHacKa_13; acanta; YPermitin; +3 Ответить
8. YPermitin 8548 22.04.19 10:32 Сейчас в теме
(7) спасибо за комментарий, но в статье же сказано про жиу репликацию.

Снапшоты не самое производительное решение.
9. starik-2005 2172 22.04.19 10:36 Сейчас в теме
(8)
Снапшоты не самое производительное решение.
Создание моментального ридонли-снимка у меня занимало 7 секунд на базе в 200 гигов, так шта не знаю - не знаю...

В постгресе вообще можно так:
CRE ATE    DATABASE MyDBCopy WITH TEMPLATE MyDB
YPermitin; +1 Ответить
10. YPermitin 8548 22.04.19 10:42 Сейчас в теме
(9) посмотрите описание репликации снимков по той ссылке, которую сами оставили.

Репликация транзакций лучшее решение для таких случаев. Но для 1С...
11. starik-2005 2172 22.04.19 11:03 Сейчас в теме
(10) репликация снимков не нужна - достаточно снимка. Побороть ридонли вполне можно - достаточно поменять конфу так., чтобы она ничего не писала при внешнем соединении, а там уже веб-сервис и таскание туда-сюда сериализованных схем компоновки, расшифровок и табличных документов. Я делал бесшовный механизм формирования отчетов из снапшота - отличное решение, которое снизило загрузку SQL сервера с 80% до 30% только лишь на гребанных блокировках.
mickey.1cx; YPermitin; +2 Ответить
12. YPermitin 8548 22.04.19 11:54 Сейчас в теме
(11) теперь я понял о чем Вы говорите!

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

Но.... у них ведь есть ряд существенных ограничений. Самые критичные на мой взгляд:
1. Снимок находится в дополнительной базе данных НА ТОМ ЖЕ инстансе SQL Server.
2. При наличии снимков мы не смодем в случае аварии быстро восстановить базу ни из журналов, ни из полных бэкапов.
3. Снижение производительности, которое будет проявляться на нагруженных системах, т.к. снимки нужно будет поддерживать.

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

Тем более обязательное соседство на одном сервере с рабочей базой сводит на нет выйгрыш для OLAP, т.к. ресурсы рабочего окружения тяжелые отчеты будут "съедать".

Может подходит для небольших OLTP-баз. Но так как для моментальных снимков нужна еще и редакция Enterprise, то стоит ли ее для них использовать.
13. starik-2005 2172 22.04.19 12:05 Сейчас в теме
(12)
Может подходит для небольших OLTP-баз. Но так как для моментальных снимков нужна еще и редакция Enterprise, то стоит ли ее для них использовать.
Я выше уже написал, но повторюсь: снапшот дал выигрыш в производительности на базе размером 150-350 ГиБ, снизив нагрузку на сервер с 80% до 30% за счет того, что система перестала ждать на блокировках при вычитывании большого количества данных для формирования отчетов. Знаете, как организованы блокировки? Это некий цикл на проверку доступности ресурса, сделанный на С/Асме. Он кушает ресурсы сервера будь здоров. А нет блокировок - нет съедаемых ресурсов.
acanta; YPermitin; +2 Ответить
14. YPermitin 8548 22.04.19 12:09 Сейчас в теме
(13) я с Вами не спорю, но цифры лучше чем- то подтверждать.

Размер базы это не показатель, также как и общие цифры по нагрузке. Какая нагрузка, от чего? А как же общий пул буфферного кэша на обе базы?

Что такое блокировки я немного догадываюсь :)

Вообщем, не зная что там были за изначальные улсловия трудно что-либо обсуждать.
15. starik-2005 2172 22.04.19 12:48 Сейчас в теме
(14)
Какая нагрузка, от чего?
500 юзверей, УТ 11 переработанна и дополненная, Овер 10к документов в день. Как-то так.
YPermitin; +1 Ответить
16. YPermitin 8548 22.04.19 12:58 Сейчас в теме
(15) в комментариях трудно такое обсуждать. Вот доступ бы на сервер :)))

Рад, что Вам эта помогло. Главное результат!
17. starik-2005 2172 22.04.19 12:59 Сейчас в теме
(16) не просто помогло, а повысило доступность системы в разы. Количество дедлоков вообще обнулилось.
YPermitin; +1 Ответить
18. YPermitin 8548 22.04.19 13:01 Сейчас в теме
(17) у вас энтерпрайз. Не пробовали AlwaysOn использовать?

Вторая реплика будет в режиме реалного времени обновляться. Полюс если включить для нее параллелизм, то аналитические отчеты можно ускорить хорошо.
19. starik-2005 2172 22.04.19 13:04 Сейчас в теме
(18) с этим и не спорю, просто нет надобности в постоянной реплике, ибо три раза в день снапшот обновляется. Время создания снапшота - 7 секунд в среднем.
YPermitin; +1 Ответить
20. YPermitin 8548 22.04.19 13:10 Сейчас в теме
28. deminded 7 23.04.19 11:13 Сейчас в теме
(13) Скажите, снятие снапшота требует отключения всех соединений?
Вообще вопрос интересует для Postgres
31. starik-2005 2172 23.04.19 12:56 Сейчас в теме
(28) для мсскула не надо ничего отключать. А для постгреса решается через снапшот файловой системы - там тоже моментально снимок делается. А как его прикрутить к инстансу постгри - думайте сами)))
21. Darklight 22 22.04.19 14:19 Сейчас в теме

Ссылка не работает.


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

Использовать толстый клиент обычного приложения с некоторыми модификациями конфигурации.
Формировать отчеты через интеграцию (COM-соединение, веб-сервисы, HTTP-сервисы, OData-интерфейс).

Вот про это всё как раз было бы интересно почитать.
YPermitin; +1 Ответить
22. YPermitin 8548 22.04.19 14:24 Сейчас в теме
(21) спасибо, что нашли ошибку.

Ссылку исправил. Продублирую еще и здесь: вот ссылка.
23. Mortum 22.04.19 14:45 Сейчас в теме
А можно использовать transaction log shipping, который проще и не имеет ограничений?
vers139; YPermitin; +2 Ответить
24. YPermitin 8548 22.04.19 14:52 Сейчас в теме
(23) он больше используется для для целей резервного копирования и отказоустойчивости.

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

Если есть готовность с эти бороться, то возможность ее использовать есть.
36. vers139 51 30.04.19 12:41 Сейчас в теме
(24) Не согласен. Расписание снятия журнала транзакций, доставки и разворачивания на втором сервере можно настроить. По-умолчанию, каждые 15 минут.

Да, база находится в режиме Только для чтения. Но это также в Вашем варианте.

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

Кстати, настроенные отчёты СКД можно формировать в этой копии и из режима управляемого приложения.
YPermitin; +1 Ответить
37. YPermitin 8548 30.04.19 12:55 Сейчас в теме
(36)
4) Не согласен.


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

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

Нет ничего лучше AlwaysOn, если есть лицензия Enterprise :)
39. vers139 51 30.04.19 13:28 Сейчас в теме
(37) если отчёт формируется больше 15 минут, то это вопрос или к медленности отчёта, или к пользователю, который пытается объять необъятное.

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

Также преимуществом данного варианта в его простоте, т.е. просто бэкап журнала транзакций (именно журнала транзакций, а не полный бэкап базы), копирование файлов и разворачивание на втором сервере. Подобный алгоритм уже работает у многих администраторов. Здесь же всё можно выполнить, используя мастер действий за 5 минут.
26. Elf1k 53 23.04.19 08:12 Сейчас в теме
Вы забыли упомянуть о новой технологии 1с появившейся в платформе 8.3.14 и выше это технология "Дата акселератор" и "Механизм копий базы данных" так вот в крайней технологии сама платформа 1с ответственна за поддержание копии в актуальном состоянии при помощи метода КопииБазыДанных.Обновить() который можно встроить в любое место в коде конфигурации. А "Дата акселератор" выборочно загружает таблицы базы данных в оперативную память, что при правильном использовании в разы увеличивает скорость формирование отчетов.
PLAstic; YPermitin; +2 Ответить
27. YPermitin 8548 23.04.19 08:19 Сейчас в теме
(26) про дата акселератор читал, но не пользовался.

Честно, пока нет доверия к этим новым решениям. Если удастся посмотреть когда-нибудь, вот тогда можно и написать :)

Если у Вас есть опыт использования, то юыло бы интересно послушать.
Дмитрий74Чел; Elf1k; +2 Ответить
33. Elf1k 53 25.04.19 14:26 Сейчас в теме
(27)
Если есть опыт использования, то юыло бы интересно послушать.

Публикацию сотворил это моя первая так, что не судите строго :) Собрал все данные в небольшую инструкцию и добавил немного своего. https://infostart.ru/public/1053895/
YPermitin; +1 Ответить
34. YPermitin 8548 25.04.19 14:36 Сейчас в теме
(33) прочитал. Плюс поставлю, сейчас ИС заглючил и говорит, что я уже ставил. Далее отпишусь уже в самой статье.

Спасибо за труды!
29. PLAstic 253 23.04.19 12:40 Сейчас в теме
(26) Хотел было дописать тоже, но заметил ваш комментарий. Похоже, 1Сники сделали убийцу данной статьи.

"Реализована возможность размещать во внешней базе данных (относительно базы данных «1С:Предприятия») копии таблиц, использование которых в отчетах или запросах, вызывает повышенную нагрузку на используемую СУБД. Данный механизм поддерживается только при работе в клиент-серверном варианте работы.
Реализована возможность указания, в какой базе данных будет выполняться запрос или отчет.
Источник ."
YPermitin; +1 Ответить
30. YPermitin 8548 23.04.19 12:42 Сейчас в теме
(29) пока это все заявления, неизвестно на сколько стабильно это работает и как быстро. Надо сравнивать с корпоративным софтом, который выполняет те же функции.

Ну и не забываем, что все это дуступно только с оицензией КОРП.
Дмитрий74Чел; +1 Ответить
35. Glebis 11 30.04.19 12:38 Сейчас в теме
А почему никто не предлагает сделать запрос к Read only базе Always On группы используя в СКД внешний источник данных?
YPermitin; +1 Ответить
38. YPermitin 8548 30.04.19 12:57 Сейчас в теме
(35)
d only базе Always On группы используя в СКД внешний источник данных?


Так этот запрос еще надо собрать :) Вариант жизнеспособный, конечно же. Но требует некоторых дополнительных усилий при разработке.
40. Glebis 11 06.05.19 11:10 Сейчас в теме
(38)
Так этот запрос еще надо собрать :) Вариант жизнеспособный, конечно же. Но требует некоторых дополнительных усилий при разработке.
Не понимаю в чем сложность:
Добавить зеркальную базу Always On в любой 1С кластер.
Сначала сделать стандартный отчет на СКД.
Сделать общий модуль, куда бы передавался текст запроса из СКД отчета для выполнения на зеркальной базе.
Переделать Отчет СКД на работу с данными из внешнего источника.

У меня только один вопрос: как выполнить запрос в зеркальной базе? Если через COM объект, то это медленно. Лучше, конечно, сделать запрос на прямую в SQL без регистрации в кластере, но нужно переводить запрос в SQL нотацию с и обратно.
YPermitin; +1 Ответить
41. YPermitin 8548 06.05.19 11:14 Сейчас в теме
(40) я как-раз говорил про сложность сформировать SQLный запрос для обращения к реплике.

Еще вариант, кроме COM-соединения, это использовать веб-сервис, через который отправлять текст запроса, а ответ получать в виде XDTO. Но это все равно медленнее SQL-запроса.
43. 3vs 05.08.19 16:26 Сейчас в теме
(41)Юрий, а ежели использовать под базы системы с ZFS?
Тогда не надо извращений с базой только чтение?

Вот тут выдержка из интересной книжицы:
ZFS разработана для максимизации производительности диска. Она побивает rsync настолько сильно, что маме rsync требуется срочная медицинская помощь. ZFS поддерживает список блоков диска которые отличаются между каждым последующим снимком. Процесс репликации не требует определять какие файлы были изменены - наша файловая система уже имеет эту информацию. Процесс репликации начинает отправку этих блоков настолько быстро, насколько это возможно, немедленно. Так как изменённые блоки содержат все метаданые для пересборки данных файлов, процесс репликации даже не нуждается в знании того, какие файлы соотносятся с этими блоками.
Пока rsync обходит вашу файловую систему, просматривая каждый файл, проверяя его временной штамп, вычисляя контрольную сумму и сравнивая их с версиями на вашей другой стороне, ZFS уже завершит свою работу. Если у вас имеется 10ТБ данных, причём только 1ГБ изменён, rsync всё- таки вынужден проверять каждый файл. ZFS только захватывает 1ГБ изменённых блоков и отправляет их.
Источник:
onreader.mdl.ru/AdvancedZFS/content/Ch04.html

А вообще, книжка называется "Полная виртуализация. Базовая коммерческая редакция: Proxmox-freeNAS-Zentyal-pfSense"
Главное, всё сделано на опенсорсе!
onreader.mdl.ru/VirtualizationComplete/content/index.html
starik-2005; YPermitin; +2 Ответить
44. YPermitin 8548 05.08.19 16:32 Сейчас в теме
(43) вот это поворот!

Я это не пробовал, но интересно почитать и поэксперементировать.

Конечно, это стек *nix, не знаю на сколько это сейчас интересно сообществу. Если у Вас уже есть результаты проб и ошибок, то напишите.
45. 3vs 05.08.19 16:45 Сейчас в теме
(44)Юрий, это всё теория!
У меня нет на работе железа даже один проксмокс поставить... :-(

Но эксперименты с FreeNas или XigmaNAS с ZFS впечатляют.
Представьте, шифровальшик зашифровал все файлы на разделе под ZFS,
Никаких проблем, восстанавливаем из снепшота информацию взад!

В принципе, здесь можно развернуть хранилища на FreeNas или XigmaNAS
и попробовать поэкспериментировать с этим.
Везёт автору книжки, у него, похоже, в Штатах там денег немеряно... :-)
YPermitin; +1 Ответить
46. 3vs 05.08.19 19:55 Сейчас в теме
(45)Кстати, в хранилищах на FreeNas или XigmaNAS можно использовать адаптеры InfiniBand
ru.wikipedia.org/wiki/InfiniBand

Соответственно можно между хранилищами построить очень быстрые каналы, да и Windows Server 2012 вроде как поддерживает такие адаптеры.
Так что жЫрным конторам, обременённым наличием зелёной бумаги, есть куда вложить её!
49. starik-2005 2172 10.01.20 15:12 Сейчас в теме
(40)
Сделать общий модуль, куда бы передавался текст запроса из СКД отчета для выполнения на зеркальной базе.
Переделать Отчет СКД на работу с данными из внешнего источника.

У меня только один вопрос: как выполнить запрос в зеркальной базе? Если через COM объект, то это медленно. Лучше, конечно, сделать запрос на прямую в SQL без регистрации в кластере, но нужно переводить запрос в SQL нотацию с и обратно.
А зачем текст? Можно схему передавать. Да и СОМ не нужен - вебсервисы рулят, а схема сериализуется. В итоге полнофункциональный отчет, выполняющийся в другой базе, неотличимый от отчета из этой базы (мы в заголовок писали время актуальности снапшота и что отчет выполнен в нем, а не в локальной базе). В итоге т.к. вызывается стандартный компоновщик отчета в другой базе по переданной схеме со всеми расшифровками, то даже дописанный отчет (с кодом в модуле) отлично работает. А все эти СОМ и преобразованные запросы - это лишние сущности, в которых нет необходимости...
42. kabanoff 41 05.08.19 15:54 Сейчас в теме
Спасибо за статью. Интересно опробовать AlwaysOn в действии.

Как вариант, обойти readonly реплики можно (в теории) следующим образом:
1. Определить круг таблиц, которые подлежат изменению в процессе работы с копией: Config, CommonSettings, Files, Params, v8users и т.д.
2. Создать пустую копию БД, скопировать в нее эти таблицы из реплики.
3. Создать вьюхи по всем остальным таблицам. Это можно сделать автоматически скриптом. Вьюхи будут читать данные из реплики.
4. Пустить пользователей в эту копию БД, предварительно ограничив их правами доступа.

Плюсы:
1. Можно будет работать с репликой из 1С.
2. Можно выбрать стратегию обновления копии:
- пересоздавать все таблицы с заданной периодичностью либо по необходимости.
- пересоздавать только таблицы вьюх, остальные таблицы обновлять самостоятельно. Так, например, можно будет сделать свою конфигурацию для отчетности (правда, надо не забыть, чтобы она соотносилась со структурой самой БД) или вести свой список пользователей, кому необходим доступ к отчетности.

Минусы:
Сложность в первоначальной настройке такого стенда (как минимум, нужно выявить все таблицы, в которые 1С должна писать данные).
48. IT_Magnit 09.01.20 22:31 Сейчас в теме
(42)
Вариант, но вроде можно проще. С помощью дата акселератора.
На ИТС написано, что его можно использовать так:
"Для варианта использования внешней СУБД важно значение параметра Тип репликации. При значении "Стандартная" за актуальностью данных в копии следит сервис копий баз данных (значение по умолчанию, рекомендуется использовать его). При значении "Внешняя" за актуальностью данных в копии должен следить сторонний механизм, не относящийся к кластеру серверов "1С". "
Т.е. ты этот механизм можешь на реплику настроить, а дальше он все сам без создания сервисной базы с вьюхами.
47. Yashazz 3250 11.08.19 10:42 Сейчас в теме
Спасибо, отличная статья.
YPermitin; +1 Ответить
Оставьте свое сообщение

См. также

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

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

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

26.04.2019    10644    0    Aleksey.Bochkov    7    

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

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

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

25.05.2020    7250    0    starik-2005    216    

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

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

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

24.05.2020    5776    0    DataReducer    22    

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

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

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

12.05.2020    4288    0    SergeyN    3    

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

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

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

29.07.2018    11100    0    Aleksey.Bochkov    9    

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

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

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

27.04.2020    3516    0    ivanov660    5    

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

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

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

23.04.2020    2316    0    vasilev2015    6    

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

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

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

21.04.2020    2698    0    ivanov660    3    

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

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

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

30.10.2017    28637    0    MrWonder    42    

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

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

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

06.04.2020    9801    0    YPermitin    0    

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

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

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

31.03.2020    10934    0    informa1555    21    

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

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

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

31.03.2020    2688    0    vasilev2015    9    

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

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

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

05.08.2015    60212    0    Sergey.Noskov    119    

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

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

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

20.03.2020    3943    0    vasilev2015    21    

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

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

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

18.03.2020    5945    0    kaliuzhnyi    43    

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

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

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

02.03.2020    4296    0    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    2148    0    w.r.    1    

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

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

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

22.04.2015    39931    0    Gilev.Vyacheslav    1    

Простое обнаружение проблем производительности в 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    3450    0    w.r.    4    

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

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

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

17.02.2020    7889    0    Evil Beaver    13    

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

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

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

07.02.2020    8608    0    a.doroshkevich    17    

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

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

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

15.03.2015    39216    0    gallam99    17    

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

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

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

23.01.2020    5748    0    darkdan77    59    

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

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

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

23.01.2020    7032    0    Kaval88    26    

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

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

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

20.01.2020    5300    0    nixel    22    

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

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

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

19.12.2019    9734    0    ivanov660    16    

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

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

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

11.11.2019    6805    0    user826155    11    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

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

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    6821    0    EugeneSemyonov    11    

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

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

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

22.01.2014    66325    0    yuraos    112    

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

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

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

14.10.2019    16216    0    YPermitin    28    

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

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

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

30.09.2019    20505    0    YPermitin    14    

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

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

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

21.06.2013    53111    0    Антон Ширяев    116    

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

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

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

19.02.2013    53789    0    Gilev.Vyacheslav    46