Мастер создания копии информационной базы для отчетности

0. 9823 28.08.20 11:34 Сейчас в теме
Прототип инструмента для подготовки реплики в режиме только для чтения к использованию. Позволяет использовать "read-only" реплики как обычные информационные базы 1С.

Перейти к публикации

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. starik-2005 2214 28.08.20 17:31 Сейчас в теме
Мы делали в конторе прям вот так, как нельзя, но если очень надо, то можно ))) Выпилили все попытки записать что-то в базу при создании сеанса для web-сервиса. В итоге любой отчет можно было выполнить как в текущей базе, так и в реплике (снапшот 300 ГБ базы делался менее 10 сек трижды в день и туда мы запускали всех озверелых бухов и это ОЧЕНЬ СИЛЬНО сократило загрузку SQL-сервера).

В общем достаточно было добавить в модуль любого (у нас все отчеты были на СКД, но многие из них компоновались вручную - отчеты для сравнения разных баз, например) отчет ПЯТЬ строк кода, и он появлялся в списке отчетов, которые можно было бы выполнять в реплике. Более того, даже роботы, которые формировали отчет, формировали его в реплике, если он был прописан в настройке, и даже не догадывались об этом. Более того, расшифровки прекрасно работали и тоже формировались в реплике. И всего-то пять строк кода на модуль любого отчета и никаких строк кода в форме отчета, его менеджере или даже в общей форме - только модуль )))
YPermitin; +1 Ответить
2. YPermitin 9823 28.08.20 17:33 Сейчас в теме
3. starik-2005 2214 28.08.20 17:37 Сейчас в теме
(2) обычным мелкоскуловским снапшотом.
4. YPermitin 9823 28.08.20 17:57 Сейчас в теме
(3) я помню, что мы об этом год назад говорили.

Если ограничения снапшота не помеха, то конечно это хорошо.
А если все, что-то из написаного в разделе "Ограничения по базе данных-источнику" по ссылке мешает их использовать, то это уже проблема.

Плюс то что это на том же инстансе со всеми вытекающими и т.д.

Но если помогло, то круть :)
5. starik-2005 2214 28.08.20 21:19 Сейчас в теме
(4)
А если все, что-то из написаного в разделе "Ограничения по базе данных-источнику" по ссылке мешает их использовать, то это уже проблема.
Сдается мне, что в этом разделе мало что можно применить к 1С. А сам моментальный снимок - это версия состояния БД, в которой хранятся лишь измененные в основном инстансе страницы. Если в БД минимум изменений, то для снапшота нужно минимум дискового пространства. И чем чаще делается снапшот, тем меньше дисковой памяти на его поддержание уходит. Ну и никаких блокировок при чтении.
6. YPermitin 9823 29.08.20 00:47 Сейчас в теме
(5) На тех системах, где производительность была важна, я бы не смог применить снимки.

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

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

>> 2. Производительность снижается по причине увеличения количества операций ввода-вывода
Тут присутствует негативное влияние. Конечно операций записи всегда намного меньше, чем чтений (по крайней мере для систем 1С), но при массовых миграциях данных, интеграциях и т.д. это может быть заметно. Ситуация чем-то напоминает влияние сжатия данных, но влияет оно только в части записи.

Еще важное ограничение:
>> Моментальный снимок базы данных должен создаваться и оставаться на том же экземпляре сервера, что и база данных-источник.
Обычно копию базы для OLAP-нагрузок создают на отдельном сервере. Обосновывается это тем, что один инстанс имеет единый буфферный кэш. Тяжелые аналитические отчеты и их запросы этот кэш быстро вымывают, что влияет на скорость выполнения операций транзакционной базы. Влияет негативно. Если мы выносим отчетную базу на отдельный сервер, то это влияние исключается. Можно посмотреть показатель производительности "SQLServer:Buffer Manager\Page life expectancy". Если страницы не задерживаются в кэше, то значит есть тяжелые запросы.
Я это к тому, что если основная база и снапшот продолжают располагаться на одном сервере, то проблемы вымывания кэша никак не решаются.
Плюс отдельный инстанс позволяет для отчетной базы изменить те же настройки параллелизма, что даст отчетам новую жизнь.
Снапшоты плюсов в этой части не дают.

Поэтому я вижу использование там, где:
1. Система не находится под постоянной нагрузкой в части изменения данных.
2. Простейшая стратегия бэкапирования.
3. Нет цели разделения оперативной и отчетной нагрузки.
4. Есть цель решить проблему избыточных блокировок СУБД при чтении. Но это уже не так актуально с появлением RCSI и управляемых блокировок.

В общем, как-то так.
Unknown31; Lansi; +2 Ответить
7. starik-2005 2214 29.08.20 10:48 Сейчас в теме
(6)
Поэтому я вижу использование там, где:
1. Система не находится под постоянной нагрузкой в части изменения данных.

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

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

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

Но да, снапшот не забекапишь - да и кому такая ересь в голову прийти может?

3. Нет цели разделения оперативной и отчетной нагрузки.

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

4. Есть цель решить проблему избыточных блокировок СУБД при чтении. Но это уже не так актуально с появлением RCSI и управляемых блокировок.


Факт остается фактом: включили снапшот изолейшн - стало чуть лучше, но нагрузка на сервер осталась очень высокой - из-за механизмов обеспечения консистентности СУБД. Вынесли отчеты в снапшот - нагрузка УПАЛА В ДВА РАЗА.

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

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

НО! Основная замута в том, что многие товарищи покупают себе память - она сейчас сравнительно не дорогая, - но не получают от этой памяти никаких преимуществ. Она просто выдирается мелкософтовским скулом до порога ограничений, а когда ее вдруг перестает хватать, то часть информации скул теряет, освобождая для новых пачек данных (был, кстати, мастеркласс на эту тему на митапе про постгрес и скул). Вот у тебя много памяти, вот ты и пишешь, и читаешь, и читаешь много. Вот начал ты много читать - скулу не стало хватать памяти для поддержки оперативного кеша с данными об остатках взаиморасчетов и товаров, и он просто освободил эти данные для того, чтобы загрузить туда данные отчета - все эти миллионы временных таблиц, сворачиваемых в финальном блоке запроса, как любят это делать 1С-неги, получившие степень "спеца по платформе". В итоге у тебя при следующей транзакции происходит чтение оперативных данных с диска, а для их размещения в памяти еще что-нибудь нужное освобождается в этой конкретной базе. Когда все в этой базе закончится, начнется освобождение того, что было поначитано в другой базе. Ну и т.д. А разделил инстанс, и большую часть времени отчетная база освобождает себе данные себя самой от предыдущих отчетов, а не данные оперативной базы, которые этой оперативной базе понадобились бы. Ведь внутри одного инстанса у скула нет приоритета, какие данные важнее, а какие можно освободить - он просто грохает, что более старое, и все.
8. YPermitin 9823 29.08.20 11:39 Сейчас в теме
(7) как и год назад Вы проигнорировали все факты что я написал и просто сказали, что у Вас все хорошо :) Только оьщие слова.

Бессмысленое обсуждение получилось. Вы либо меня троллите, либо просто игнорируете:)))

Продолжать смысла нет.
9. starik-2005 2214 29.08.20 21:11 Сейчас в теме
(8)
Продолжать смысла нет.
Так и Вы все мои аргументы игнорируете, даже не пытаясь понять.

Если сервер на одном инстансе и отчеты собирает, и транзакции пишет, то если инстансы разделить, то количество операций ввода-выводе не поменяется. Я, например, не понимаю, с чем тут можно спорить? Нет блокировок - нет тормозов. А бэкапы - ну кто ж снапшот бэкапит, а для бэкапа транзакций основной базы нет никаких ограничений, только при восстановлении снапшот нужно будет прибить, а это не проблема совершенно.
Оставьте свое сообщение
Вопросы с вознаграждением