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

22.04.2019 47 Comments

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

, , , ,


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

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

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

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

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

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

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

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

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

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

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

Внимание!!

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

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

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

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

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

 

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

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

Плюсы:

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

Минусы:

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

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

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

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

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

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

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

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

RESTORE DATABASE [SuperDatabase_ForReports]
FROM  DISK = N'F:DBsMSSQL14.MSSQLSERVERMSSQLBackupSuperDatabase.bak' WITH  FILE = 1,
MOVE N'SuperDatabase' TO N'F:DBsMSSQL14.MSSQLSERVERMSSQLDATASuperDatabase_ForReports.mdf',
MOVE N'SuperDatabase_log' TO N'F:DBsMSSQL14.MSSQLSERVERMSSQLDATASuperDatabase_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!

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

Related Posts

47 Comments

  1. 3vs

    Юрий, а ежели, продолжая разговор из «Самый быстрый шринк на Диком Западе»,

    infostart.ru/public/1031815/

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

    можно получить OLTP свежую базу и «грязную» OLAP базу, которая, правда, не наполняется свежими данными, но вполне себе, доступна для отчётов, не накончиках пальцев, конечно, но всё же, а потом грязный дисковый массив можно отформатировать для очередной «рокировочки» (© Ельцин Б.Н.)?

    Reply ↓
  2. YPermitin

    (1) надо эксперементировать, как я и раньше говорил 🙂

    Но что-то мне подсказывает, что проблем можно больше огрести.

    Reply ↓
  3. ellavs

    Спасибо за систематизацию способов. Мы сами используем классику вручную. У нас на будущее («на будущее» просто потому что мне некогда этим заняться) висит такая задачка: периодическое поднятие копии базы (через бэкап на MS SQL), затем копия должна понимать, что она копия — соответственно останавливать выполнение регламентных заданий и в заголовках прописывать, что она копия. Плюс копия должна поднимать полномочия определенных пользователей, которым разрешено «баловаться» в копии базы. Скорее всего нужно сделать обработку, которая должна запускаться после восстановления бэкапа…

    Reply ↓
  4. YPermitin

    (3) Спасибо!

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

    Остальное, да. Это уже свои инструменьы и скрипты «допилить».

    Reply ↓
  5. baklanov_i

    (4) Блокировка заданий находится в свойствах базы на сервере 1с, разве нет?

    Reply ↓
  6. YPermitin

    (5) В БСП есть событие, которое вызывается при старте любого регламентного задания. Там проверяется является ли база тестовая или копия и в случае чего задание останавливается.

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

    А так да, на сервере можно запретить в свойствах информационной базы.

    Reply ↓
  7. starik-2005

    Не благодарите

    https://docs.microsoft.com/ru-ru/sql/relational-databases/replication/snapshot-replication?view=sql-server-2017

    ЗЫ: уже миллион раз говорил, что если кто хочет повысить скорость работы системы — пусть разделит OLAP и OLTP.

    Reply ↓
  8. YPermitin

    (7) спасибо за комментарий, но в статье же сказано про жиу репликацию.

    Снапшоты не самое производительное решение.

    Reply ↓
  9. starik-2005

    (8)

    Снапшоты не самое производительное решение.

    Создание моментального ридонли-снимка у меня занимало 7 секунд на базе в 200 гигов, так шта не знаю — не знаю…

    В постгресе вообще можно так:

    CRE ATE    DATABASE MyDBCopy WITH TEMPLATE MyDB
    Reply ↓
  10. YPermitin

    (9) посмотрите описание репликации снимков по той ссылке, которую сами оставили.

    Репликация транзакций лучшее решение для таких случаев. Но для 1С…

    Reply ↓
  11. starik-2005

    (10) репликация снимков не нужна — достаточно снимка. Побороть ридонли вполне можно — достаточно поменять конфу так., чтобы она ничего не писала при внешнем соединении, а там уже веб-сервис и таскание туда-сюда сериализованных схем компоновки, расшифровок и табличных документов. Я делал бесшовный механизм формирования отчетов из снапшота — отличное решение, которое снизило загрузку SQL сервера с 80% до 30% только лишь на гребанных блокировках.

    Reply ↓
  12. YPermitin

    (11) теперь я понял о чем Вы говорите!

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

    Но…. у них ведь есть ряд существенных ограничений. Самые критичные на мой взгляд:

    1. Снимок находится в дополнительной базе данных НА ТОМ ЖЕ инстансе SQL Server.

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

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

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

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

    Может подходит для небольших OLTP-баз. Но так как для моментальных снимков нужна еще и редакция Enterprise, то стоит ли ее для них использовать.

    Reply ↓
  13. starik-2005

    (12)

    Может подходит для небольших OLTP-баз. Но так как для моментальных снимков нужна еще и редакция Enterprise, то стоит ли ее для них использовать.

    Я выше уже написал, но повторюсь: снапшот дал выигрыш в производительности на базе размером 150-350 ГиБ, снизив нагрузку на сервер с 80% до 30% за счет того, что система перестала ждать на блокировках при вычитывании большого количества данных для формирования отчетов. Знаете, как организованы блокировки? Это некий цикл на проверку доступности ресурса, сделанный на С/Асме. Он кушает ресурсы сервера будь здоров. А нет блокировок — нет съедаемых ресурсов.

    Reply ↓
  14. YPermitin

    (13) я с Вами не спорю, но цифры лучше чем- то подтверждать.

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

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

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

    Reply ↓
  15. starik-2005

    (14)

    Какая нагрузка, от чего?

    500 юзверей, УТ 11 переработанна и дополненная, Овер 10к документов в день. Как-то так.

    Reply ↓
  16. YPermitin

    (15) в комментариях трудно такое обсуждать. Вот доступ бы на сервер :)))

    Рад, что Вам эта помогло. Главное результат!

    Reply ↓
  17. starik-2005

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

    Reply ↓
  18. YPermitin

    (17) у вас энтерпрайз. Не пробовали AlwaysOn использовать?

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

    Reply ↓
  19. starik-2005

    (18) с этим и не спорю, просто нет надобности в постоянной реплике, ибо три раза в день снапшот обновляется. Время создания снапшота — 7 секунд в среднем.

    Reply ↓
  20. YPermitin

    (19) тоже верно.

    Reply ↓
  21. Darklight
    Вы можете прочитать здесь

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


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

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

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

    Вот про это всё как раз было бы интересно почитать.

    Reply ↓
  22. YPermitin

    (21) спасибо, что нашли ошибку.

    Ссылку исправил. Продублирую еще и здесь: вот ссылка.

    Reply ↓
  23. Mortum

    А можно использовать transaction log shipping, который проще и не имеет ограничений?

    Reply ↓
  24. YPermitin

    (23) он больше используется для для целей резервного копирования и отказоустойчивости.

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

    Если есть готовность с эти бороться, то возможность ее использовать есть.

    Reply ↓
  25. rpgshnik

    (3) я бы почитал такую статью как это сделать 🙂

    Reply ↓
  26. Elf1k

    Вы забыли упомянуть о новой технологии 1с появившейся в платформе 8.3.14 и выше это технология «Дата акселератор» и «Механизм копий базы данных» так вот в крайней технологии сама платформа 1с ответственна за поддержание копии в актуальном состоянии при помощи метода КопииБазыДанных.Обновить() который можно встроить в любое место в коде конфигурации. А «Дата акселератор» выборочно загружает таблицы базы данных в оперативную память, что при правильном использовании в разы увеличивает скорость формирование отчетов.

    Reply ↓
  27. YPermitin

    (26) про дата акселератор читал, но не пользовался.

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

    Если у Вас есть опыт использования, то юыло бы интересно послушать.

    Reply ↓
  28. deminded

    (13) Скажите, снятие снапшота требует отключения всех соединений?

    Вообще вопрос интересует для Postgres

    Reply ↓
  29. PLAstic

    (26) Хотел было дописать тоже, но заметил ваш комментарий. Похоже, 1Сники сделали убийцу данной статьи.

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

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

    Источник .»

    Reply ↓
  30. YPermitin

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

    Ну и не забываем, что все это дуступно только с оицензией КОРП.

    Reply ↓
  31. starik-2005

    (28) для мсскула не надо ничего отключать. А для постгреса решается через снапшот файловой системы — там тоже моментально снимок делается. А как его прикрутить к инстансу постгри — думайте сами)))

    Reply ↓
  32. ellavs

    (25) если получится такое реализовать, постараюсь написать 🙂

    Reply ↓
  33. Elf1k

    (27)

    Если есть опыт использования, то юыло бы интересно послушать.

    Публикацию сотворил это моя первая так, что не судите строго 🙂 Собрал все данные в небольшую инструкцию и добавил немного своего. https://infostart.ru/public/1053895/

    Reply ↓
  34. YPermitin

    (33) прочитал. Плюс поставлю, сейчас ИС заглючил и говорит, что я уже ставил. Далее отпишусь уже в самой статье.

    Спасибо за труды!

    Reply ↓
  35. Glebis

    А почему никто не предлагает сделать запрос к Read only базе Always On группы используя в СКД внешний источник данных?

    Reply ↓
  36. vers139

    (24) Не согласен. Расписание снятия журнала транзакций, доставки и разворачивания на втором сервере можно настроить. По-умолчанию, каждые 15 минут.

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

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

    Кстати, настроенные отчёты СКД можно формировать в этой копии и из режима управляемого приложения.

    Reply ↓
  37. YPermitin

    (36)

    4) Не согласен.

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

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

    Нет ничего лучше AlwaysOn, если есть лицензия Enterprise 🙂

    Reply ↓
  38. YPermitin

    (35)

    d only базе Always On группы используя в СКД внешний источник данных?

    Так этот запрос еще надо собрать 🙂 Вариант жизнеспособный, конечно же. Но требует некоторых дополнительных усилий при разработке.

    Reply ↓
  39. vers139

    (37) если отчёт формируется больше 15 минут, то это вопрос или к медленности отчёта, или к пользователю, который пытается объять необъятное.

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

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

    Reply ↓
  40. Glebis

    (38)

    Так этот запрос еще надо собрать 🙂 Вариант жизнеспособный, конечно же. Но требует некоторых дополнительных усилий при разработке.

    Не понимаю в чем сложность:

    Добавить зеркальную базу Always On в любой 1С кластер.

    Сначала сделать стандартный отчет на СКД.

    Сделать общий модуль, куда бы передавался текст запроса из СКД отчета для выполнения на зеркальной базе.

    Переделать Отчет СКД на работу с данными из внешнего источника.

    У меня только один вопрос: как выполнить запрос в зеркальной базе? Если через COM объект, то это медленно. Лучше, конечно, сделать запрос на прямую в SQL без регистрации в кластере, но нужно переводить запрос в SQL нотацию с и обратно.

    Reply ↓
  41. YPermitin

    (40) я как-раз говорил про сложность сформировать SQLный запрос для обращения к реплике.

    Еще вариант, кроме COM-соединения, это использовать веб-сервис, через который отправлять текст запроса, а ответ получать в виде XDTO. Но это все равно медленнее SQL-запроса.

    Reply ↓
  42. kabanoff

    Спасибо за статью. Интересно опробовать AlwaysOn в действии.

    Как вариант, обойти readonly реплики можно (в теории) следующим образом:

    1. Определить круг таблиц, которые подлежат изменению в процессе работы с копией: Config, CommonSettings, Files, Params, v8users и т.д.

    2. Создать пустую копию БД, скопировать в нее эти таблицы из реплики.

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

    4. Пустить пользователей в эту копию БД, предварительно ограничив их правами доступа.

    Плюсы:

    1. Можно будет работать с репликой из 1С.

    2. Можно выбрать стратегию обновления копии:

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

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

    Минусы:

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

    Reply ↓
  43. 3vs

    (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

    Reply ↓
  44. YPermitin

    (43) вот это поворот!

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

    Конечно, это стек *nix, не знаю на сколько это сейчас интересно сообществу. Если у Вас уже есть результаты проб и ошибок, то напишите.

    Reply ↓
  45. 3vs

    (44)Юрий, это всё теория!

    У меня нет на работе железа даже один проксмокс поставить… 🙁

    Но эксперименты с FreeNas или XigmaNAS с ZFS впечатляют.

    Представьте, шифровальшик зашифровал все файлы на разделе под ZFS,

    Никаких проблем, восстанавливаем из снепшота информацию взад!

    В принципе, здесь можно развернуть хранилища на FreeNas или XigmaNAS

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

    Везёт автору книжки, у него, похоже, в Штатах там денег немеряно… 🙂

    Reply ↓
  46. 3vs

    (45)Кстати, в хранилищах на FreeNas или XigmaNAS можно использовать адаптеры InfiniBand

    ru.wikipedia.org/wiki/InfiniBand

    Соответственно можно между хранилищами построить очень быстрые каналы, да и Windows Server 2012 вроде как поддерживает такие адаптеры.

    Так что жЫрным конторам, обременённым наличием зелёной бумаги, есть куда вложить её!

    Reply ↓
  47. Yashazz

    Спасибо, отличная статья.

    Reply ↓

Leave a Comment

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