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

29.12.14

База данных - Инструменты администратора БД

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

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

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

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

Конечно, всё это можно делать с помощью стандартных средств 1С:Предприятия 8.х (например, консоли управления серверами 1С) или механизмов, имеющихся в некоторых типовых конфигурациях. Однако удобство применения повсеместно доступных средств, всё же, ограничено, затраты времени на управление блокировкой соединений можно сократить, а администраторы и разработчики при использовании стандартных механизмов вполне могут позволить себе не вполне корректно информировать пользователей о причинах и времени недоступности информационной базы. И позволю высказать своё мнение, что всё это вполне исправимо?


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

Для запрета установки новых соединений пользователями и начала завершения активных сеансов мы применяем вот такую форму:

Окно установки блокировки соединения с информационной базой

Вызвать её - это один клик мышки, заблокировать информационную базу - еще один (по большой красной кнопке "Заблокировать").

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

Окно снятия блокировки соединения с информационной базой

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

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

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

Уведомление пользователя о необходимости завершения сеанса

Еще через 3 минуты те пользователи, что продолжают работать, получат второе уведомление:

Повторное уведомление пользователя о необходимости завершения сеанса

Еще через 3 минуты те, кто не понимает, что такое завершить текущий сеанс или не смотрит на экран монитора, получат третье, последнее предупреждение:

Уведомление пользователя о скором принудительном завершении сеанса

Ну а через минуту, как и написано в уведомлении, сеанс будет корректно автоматически завершен клиентом "1С:Предприятия" (именно клиентом, а не будет разрорван в одностороннем порядке со стороны сервера).

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

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

Настройка параметров блокировки информационной базы

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

Сообщение о невозможности установки соединения с информационной базой

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

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


Пару слов про время недоступности, которое можно задать на форме в полях "с" и "по".

По умолчанию в поле "с" указывается время на Х минут больше от текущего времени, где Х - время, которое требуется для корректного поэтапного информирования пользователей и завершения сеансов. 15, 10, 7, 4 минут. Мы чаще всего используем 10-ти минутный интервал завершения сеансов.

При необходимости в этом поле можно задать любое другое время, с которого будет действовать запрет. Например, днем можно установить запрет на 23:00, т.е. на время, когда будет проводиться резервное копирование.

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

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

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

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

Сообщение о невозможности установки соединения с информационной базой с указанием ожидаемого времени завершения обслуживания


Но и это еще не всё. Часто мы проводим шаблонные операции. Типовое обновление в обед, которое обычно занимает 10 минут. Или резервное копирование, которое займет около часа. Даже указание ожидаемого времени завершения обслуживания можно избежать. Для самых отъявленных лентяев мы применяем шаблоны:

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

Т.е., если, например, нам нужно быстренько обновить информационную базу, что займет не более 5-ти минут, достаточно вызвать окно шаблонов и нажать на кнопке "ВКЛ" напротив первого шаблона. Картинки обычно помогают нашим администраторам осознать суть предлагаемых шаблонов без слов ;)


Описанную схему мы применяем на информационных базах, работающих под управлением "1С:Предприятия" 8.1 и 8.2. Скорее всего, и под 8.3 в свете недавнего выхода этой версии платформы, вполне возможно провести доработку подсистемы и применять её на практике.

Когда мы брались за разработку этих механизмов, я выставлял 2 главных требования:

  1. человечность и простота восприятия, ориентация на применение без необходимости глубоких познаний или интеллектуальных способностей (всё должно быть просто и удобно, как применять должно быть понятно и без инструкции);
  2. ориентация на минимизацию трудозатрат админов в сочетании с требованием корректного информирования при ограничении доступа пользователей к базам (промышленные объемы требуют отработки там, где при разовом применении можно было бы проделать на пару лишних действий).

Как думаете, получилось ли сделать то, что хотелось?

Блокировка запрет сеансы ограничение обслуживание

См. также

Автоподбор ролей для профилей и групп доступа в любых типовых базах 1С УТ 11, КА 2, ERP2, Розница 2/3, УНФ 16/3, БП 3, ЗУП 3 и подобных (УФ, Платформа 8.3.14+)

Инструменты администратора БД Роли и права 8.3.14 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:Документооборот 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)

Роли… Вы тратите много времени и сил на подбор ролей среди около 2400 в ERP или 1500 в Рознице 2, пытаясь понять какими правами они обладают? Вы все время смотрите права в конфигураторе или отчетах чтоб создать нормальные профили доступа? Вы хотите наглядно видеть какие права дает профиль и редактировать все в простом виде? А может хотите просто указать подсистему и дать права на просмотр и добавление на объекты и не лезть в дебри прав и чтоб обработка сама подобрала нужные роли? Все это теперь стало возможно! Обновление от 15.12.2023, версия 1.1.

12000 руб.

06.12.2023    2971    13    1    

34

SALE! 20%

Infostart УДиФ: Управление данными и формами

Инструменты администратора БД Инструментарий разработчика Роли и права Платформа 1С v8.3 Конфигурации 1cv8 Россия Платные (руб)

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

10000 8000 руб.

10.11.2023    3521    11    1    

34

SALE! 30%

PowerTools

Инструментарий разработчика Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

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

3600 2520 руб.

14.01.2013    177733    1073    0    

849

Ускоренное проведение документов (x4), устранение ошибок 60/62 счетов и зачет авансов (Бухгалтерия 3.0)

Закрытие периода Инструменты администратора БД Корректировка данных Бухгалтерский учет 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Платные (руб)

Расширение «Оперативное проведение» в 4 раза уменьшает время проведения документов и закрытия месяца. Является комплексным решением проблем 62 и 60 счетов. Оптимизирует проведение при включенной функциональной опции «Раздельный учет НДС». Используется в более 10 организациях уже 2 года. Совместимо с конфигурацией Бухгалтерия 3.0 (+КОРП).

14400 руб.

29.04.2020    27374    79    146    

59

Система хранения присоединенных файлов в томах на диске

Инструменты администратора БД Платформа 1С v8.3 1С:Комплексная автоматизация 1.х 1С:Управление производственным предприятием Платные (руб)

Конфигурация Комплексная автоматизация 1.1 (и УПП 1.3 тоже) хранит файлы и изображения в справочнике Хранилище дополнительной информации в реквизите Хранилище типа ХранилищеЗначений. Та же история с ВложениямиЭлектроннойПочты. Но при этом присоединенные файлы в Электронном документообороте хранит в томах на диске. Эта доработка позволяет использовать стандартный механизм хранения файлов, изображений и вложений электронных писем в томах на диске. При этом можно разделить тома хранения по объектам конфигурации.

4200 руб.

10.11.2015    61313    88    59    

73

"Менеджер потоков 2.1": УПП: "Восстановление партий"

Инструменты администратора БД Платформа 1С v8.3 1С:Управление производственным предприятием Россия Бухгалтерский учет Управленческий учет Платные (руб)

Как оптимизировать то, что, считалось, не поддается оптимизации? Как повысить доступность базы данных? Как проводить самую «времяемкую» операцию не по паре раз в неделю, а по несколько раз в день*? Ответ есть!

20000 руб.

12.09.2019    11745    5    9    

7

Брандмауэр для сервера 1С Предприятие 8 - внешнее управление сеансами

Инструменты администратора БД Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

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

3600 руб.

06.02.2017    31107    31    18    

47

Хранилище файлов на SQL

Инструменты администратора БД Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 Управленческий учет Платные (руб)

Привязка файлов / сканов к объектам 1С с сохранением их на SQL-сервере

12000 руб.

09.10.2019    10981    5    8    

9
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Alex1Cnic 148 30.12.14 09:49 Сейчас в теме
Интересно, но где же сами файлы обработок???
CTAKAH; Бурухтан Второй Второй; akR00b; 1cprogr_nsk; zorka-gold; Dragonim; mc2; Lyolik; Oleg1708; a_ageev; bashirov.rs; +11 Ответить
3. nimus 62 30.12.14 10:23 Сейчас в теме
(1) Alex1Cnic,

Всё это не только обработками реализуется. Это еще и обработчики ожидания на клиенте. Для интеграции с базами требуется сведение баз. Точнее будет сказать - подсистема, для интеграции с другими конфигурациями. Она актуальна только в случае, если конфигурация снята с поддержки.
6. Agapov_Stas 1 30.12.14 11:20 Сейчас в теме
(3) так к чему статья то не пойму?
Без файлов и без кода она ничего не дает - просто показать какие вы классные?) и как вы рубите пользователей ?)
9. nimus 62 30.12.14 12:40 Сейчас в теме
(6) Agapov_Stas,

Даже без файлов виден вариант организации достаточно удобного интерфейса управления и показана корректная схема информирования пользователей. Уверен, что и это может многим быть интересным ;)
10. bashirov.rs 31 30.12.14 12:47 Сейчас в теме
(1) Alex1Cnic, поддерживаю.

(5)
1) у вас при установке блокировки все ли пользователи будут "выброшены" из базы? Просто со стандартной обработкой такое случается. Всё время ожидания прошло, основная часть пользователей вышли, а пару пользователей осталось, хотя время ожидания парой превышает 10-15 минут.
2) С информационными сообщениями конечно не удивили - в стандартных обработках можно добиться такого же и даже проще.
3) Но ради удобства вы молодец все же! Плюс.
11. nimus 62 30.12.14 13:01 Сейчас в теме
(10) bashirov.rs,

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

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

За "+" спасибо )
12. bashirov.rs 31 31.12.14 07:33 Сейчас в теме
(11) стандартная обработка называется "Блокировка соединений с информационной базой" это в Бухгалтерии КОРП, в УТ и УПП вроде тоже так же называется. Поэтапное информирование есть, но более подробного, как у вас, конечно нет. Там возможно просто написать сообщение при завершении работы пользователей и никаких доработок не требуется. Подробно я сейчас не опишу конечно, только в вкратце:
1. Просит выйти (несколько раз предупреждает в определенном интервале времени);
2. Окончательное предупреждение с закрытием сеанса (с возможностью сохраниться);
3. При попытке войти в базу говорит что база заблокирована;
Автоматически снимается блокировка при истечении времени, которое вы установили (возможно снять самостоятельно).
Одним словом это тот же стандартный механизм который вы используете как я предполагаю.
13. nimus 62 31.12.14 09:55 Сейчас в теме
(12) bashirov.rs,

Да, понял о каком речь. Он еще в ряде конфигураций, я в УПП прошлых поколений видел раньше. У нас администраторы крайне ленились при таком варианте закрытия на обслуживание впечатывать корректные уведомления пользователей, как и ленились прогнозировать время завершения обслуживания. Но уж точно эта обработка лучше, чем через окно консоли управления серверами закрывать. Точнее там не только обработка. Она также тесно связана с рядом обработчиков, тикающих по таймеру на клиентах.
2. Agapov_Stas 1 30.12.14 10:20 Сейчас в теме
и под 8.3 в свете недавнего выхода этой версии платформы

Ничего себе недавнего )))
Возник вопрос - как отключаются сеансы пользователей? - то что у Вас написано, что они отключаются клиентом, а не сервером приводит к тому что не выбрасываются зависшие сеансы либо сеансы в которых выполняется какое либо продолжительное действие.
Если вы все делали через обработчик ожидания, то в ситуации когда пользователь запустит какую то обработку (например, перепроведение документов, которое будет выполняться Х часов) он отключен не будет!
4. nimus 62 30.12.14 10:25 Сейчас в теме
(2) Agapov_Stas,

Хороший вопрос, видно что в теме )
Сеансы завершаются последовательно в два этапа: первый - со стороны клиента обработчиком ожидания, второй - через com-соединение с сервером. Второй начинает выкидывать соединения по завершению указанного времени, т.е. когда все, кто мог, уже вышли. Именно вторая часть рубит зависшие сеансы.
5. nimus 62 30.12.14 10:29 Сейчас в теме
(2) Agapov_Stas,

Я писал о недавнем выходе ядра 8.3, а эта штуковенция уже 100 лет у нас применяется )
7. gubanoff 63 30.12.14 11:58 Сейчас в теме
Не увидел новаций. Использованы стандартные механизмы, только доработаны для "одного нажатия мышкой". Исходя из заголовка публикации "вместо стандартных механизмов" ожидал увидеть нечто новое. Расстроился :)
8. nimus 62 30.12.14 12:38 Сейчас в теме
(7) gubanoff,

Я постарался показать не альтернативный код, а альтернативный интерфейс управления запретом использования, потому этот материал в статьях, а не обработках ))

Моё мнение было выше - на крупных базах иногда мельчайшая тонкая доработка может сэкономить уйму времени и нервов. Вот это пример одной из таких доработок, которая для нас оказалась крайне полезной.
14. IgorS 43 31.12.14 11:27 Сейчас в теме
Без демонстрационной конфигурации с реализацией упомянутых механизмов вся статья - пустое "бла-бла-бла", полезный эффект от которого стремится к нулю.
MMF; mc2; wolfsoft; Lyolik; +4 Ответить
17. honeyform 02.01.15 10:25 Сейчас в теме
Одна из идей данной статьи – минимизировать влияние человеческого фактора на корректную работоспособность программного комплекса. При стандартных механизмах есть все риски как не до конца понятно описать сообщение, так и в принципе не предупредить о том, что мы «выбрасываем» пользователя из системы. Это если говорить только со стороны пользователя.

Теперь если со стороны администратора… Основная то суть оптимизации либо-какой системы не только в том, чтобы была отработана видимая часть для пользователя. Качество реализации так раз кроется «за ширмой». А как же драгоценное время на поддержку? Порой мы тратим слишком много времени на вещи, которые повторяем ежедневно. А что, если можно оптимизировать и эту часть? Ведь сэкономленные 5 минут на лишний вход в Конфигуратор, описание сообщения для пользователя при закрытии базы ежедневно (а может быть и несколько раз на день!) смогут накопить часы свободного времени! Ну а куда потратить это время - всегда найдется;) Даже продлить время на выполнение более интересных задач и повысить производительность в связи с переключением с задачи на задачу - уже позитив.

Так что как не крути – автору 5!

(14) IgorS,
Без демонстрационной конфигурации с реализацией упомянутых механизмов вся статья - пустое "бла-бла-бла", полезный эффект от которого стремится к нулю.

Порой толковая идея - это нечто большее, чем просто кусок кода. Как минимум - логику данного механизма можно применять не только при блокировке соединений... Здесь описаны вещи более глобального характера;) Если бы еще суметь применить такой подход при подготовке к свиданию=) Ведь по сути - повторяю те же самые действия! А вот нажать бы кнопку - и все готово! Не нужно огромный алгоритм держать в голове!)
А с другой стороны - по себе сужу... Человек - ленивое существо) Если получаю готовый работающий механизм - я до конца не вникаю в концепцию реализации, а иногда и совсем не задумываюсь о глубине проработки! А ведь можно так многие полезные идеи упустить;)
19. nimus 62 02.01.15 17:26 Сейчас в теме
(17), спасибо за внятный комментарий )

(18), по реализации столько отличий, что можно предложить найти 12 отличий ;)
32. karapuzzzz 63 08.01.15 16:24 Сейчас в теме
(19) ах, ну да. Тут все увидели Ваш код и смогли сравнить его с другими вариантами. А судя по возможностям, то та обработка почти ничем не отличается от Вашей. Мы же сравниваем функционал и идеологию подхода? Тогда отличий меньше чем 12.
26. webester 26 05.01.15 04:04 Сейчас в теме
(17)
Порой толковая идея - это нечто большее, чем просто кусок кода

В корне неверное убеждение. Есть мнение, что любая самая гениальная идея, ничто без реализации, в то время как реализация в любом случае несет в себе и саму идею и код в том числе, если он нужен для реализации. Картинки в статье для 99% прочитавших ее так и останутся картинками. А значит статья как таковая не имеет смысла, ну кроме как похвастаться.
27. nimus 62 05.01.15 11:05 Сейчас в теме
(26), как думаете, почему software-архитекторы оплачиваются в разы больше, чем кодеры? Сколько людей сможет сделать программу по ТЗ, а сколько может спроектировать программу так, чтобы на ее разработку ушло минимум времени, она решала все поставленные задачи и всем устраивала заказчика? Это я к тому, что к фразе "В корне неверное утверждение" корректнее было бы добавить "По моему мнению, ...".
15. Babuin 01.01.15 14:50 Сейчас в теме
меня больше вот это порадовало) явно что то не то в консерватории.
когда обновления работающих баз проводятся почти каждый день или по нескольку раз в день, когда количество пользователей исчисляется десятками, сотнями или тысячами

16. nimus 62 01.01.15 16:31 Сейчас в теме
24. Babuin 04.01.15 13:31 Сейчас в теме
(16) по несколько раз в день прерывать работу сотен и тысяч пользователей.
И резервное копирование в таких базах точно нужно делать не так.
или для резервного копирования в ночное время средствами конфигуратора "1С:Предприятия", а не сервера баз данных (размеры копии всё же очень значимо отличаются при применении этих подходов).


25. nimus 62 04.01.15 16:00 Сейчас в теме
(24), это от ситуации зависит. Например, мы обслуживаем 3 активно используемых программных комплекса, где количество пользователей находится как-раз между сотнями и тысячами. Но специфика их такова, что ночью с ними не работают. При размере баз около 200Гб, резервное копирование средствами SQL, конечно, возможно, но не позволяет хранить длительную историю копий, что иногда полезно. Резервные копии средствами 1C при этом в зависимости от конфигурации составляют от 2 до 10Гб. Обновление на этих комплексах проводится 1 или 2 раза в день. В 22:00 и, в экстренных ситуациях, в 12:00 (обеденное время работников предприятия). Вот в таком случае всё сказанное верно )
Конечно, если речь о круглосуточно используемых высоконагруженных комплексах, то обслуживание проводится не так. Но доработки и обновления всё равно нужны. Пусть и в середине ночи, но если есть шанс, что кто-то работает - надо пользователей попросить выйти корректно.
33. Babuin 08.01.15 18:23 Сейчас в теме
(25) когда обслуживаются такие комплексы как правило существуют такие понятия как SLA, время доступности систем, управление изменениями, релизами.т.д. Организовываается различные процессы и регламенты их регулирующие. Когда есть работающий процесс как правило достаточно работы консоли сервера и суперперделки по выгону пользователю нах не нужны.
Бэкап таких комплексов опять же только SQL. У sql есть замечательная фича сжатия бэкапа,если уж нужно организовать архив с большой глубиной хранения.
Итого такая фича по выгону пользователей нужна в небольших конторах, базах. Когда нет смысла организовывать процессы, обновлять конфу хоть ежечасно.
35. nimus 62 13.01.15 21:16 Сейчас в теме
(33) Babuin, В бекапе средствами SQL есть одно бо-о-ольшое отличие от бекапа, сделанного средствами 1С. Понять его можно изучив в профайлере размер наиболее крупных таблиц базы данных. Это таблицы остатков и оборотов регистров накопления, расчета, бухгалтерии. При качественной отработке производительности эти таблицы в сотни и тысячи раз превосходят по размеру таблицы самих регистров. Угадайте, попадают ли таблицы остатков и оборотов в бекап средствами SQL? Попадают. А в бекап средствами 1C не попадают. Благодаря этому в ряде случаев, например, как на наших базах, размер бекапа средствами 1С составляет примерно 2Гб, а средствами SQL - 200Гб. Всего 100-кратная разница. Разве она не стоит того, чтобы использовать доступный функционал, если специфика работы организации или предприятия позволяет на час ночью закрыть базу?
36. Babuin 14.01.15 13:31 Сейчас в теме
(35)
А в бекап средствами 1C не попадают.
Т.е если вы из этого dt файла загрузите базу, у вас этих таблиц не будет?)
200 ГБ бэкап сиквельный это уже со сжатием? т.е у вас база порядка 500 ГБ? и dt такой базы получается 2ГБ? что то где то несходится.
Самая главная причина почему не стоит делать DT для хранения информации, это то что есть вероятность невозможности загрузить этот dt.
Ну если уж на то пошло и dt нужны позарез, можно организовать промежуточную базу в которую средствами SQL загружать бэкап и оттуда уже выгружать dt не выгоняя пользователей.


37. nimus 62 14.01.15 17:21 Сейчас в теме
(36) Babuin, да, базы около 500Гб. Размер dt от 2 до 8Гб в зависимости от метода хранения истории изменений.
А таблицы остатков не попадают в dt-файлы, так как в этом нет необходимости. При поднятии базы остатки рассчитываются, а не загружаются.

С проблемами поднятия базы из dt файлов за 10 лет применения 1С на предприятии проблем не наблюдалось ни разу, а делается это ежедневно.

И дабы не впадать в пустую полемику, очень прошу обратить внимание, что для оговоренного варианта конкретно указаны условия, когда он полезен. В нашем случае такая схема обслуживания наиболее удачная, так как ночью базы не испльзуются, экономия дискового пространства значима и размер sql-копий не позволяет их записывать на ленточные носители. Если для Вас эти преимущества не значимы или нет возможности на час в сутки ограничивать работу с базой - конечно остается делать монстрокопии силами сервера баз данных. Но я точно знаю, что как минимум для ряда организаций описанная схема оказалась очень удобной.
18. Ted1982 68 02.01.15 16:50 Сейчас в теме
Тот же принцип и тот же функционал был реализован в данной обработке http://infostart.ru/public/90241/, которая была сделана уже очень давно (2011 год). Не понимаю, что нового/необычного в данной обработке.
20. break 33 03.01.15 07:16 Сейчас в теме
а как обстоят дела с уведомлением пользователя если 1С свернута? или включилась заставка?
21. nimus 62 03.01.15 11:31 Сейчас в теме
(20) - выводятся модальные окна в окне 1С. Т.е. на свернутой 1С помигает несколько раз приложение 1С, но само не развернется. Если пользователь не заметил и не закрыл сам, после 3-го уведомления приложение будет закрыто.
22. dyak84 03.01.15 12:19 Сейчас в теме
Автор как теоретическая статья ну просто на 5+. Как практически ничего нет, а картинками сыт не будеш. Выложите пожалуйста теперь практическую часть. Зарание спасибо
Бурухтан Второй Второй; zorka-gold; andy23; +3 Ответить
23. softgarant 62 03.01.15 13:36 Сейчас в теме
Вот и я не сдержался чтобы не высказать свое недовольство - а почему без куска кода. Да я читал что идея важна, но идейных много, это не эксклюзивная реализация, это субъективное мнение.
28. vslimv 05.01.15 13:23 Сейчас в теме
Вместо того чтобы ругаться со всеми и мерится заработком, выдавая философские тезисы, лучше бы выложили .cf или четко отказали людям.
29. nimus 62 05.01.15 13:55 Сейчас в теме
(28) vslimv, не стоит так перекручивать сказанное. И ругани не было, и заработками никто не мерялся. Но девушка выше написала умную мысль, поэтому я и попросил критикуя быть корректными.
По cf. Это публикация в разделе статей. Когда появится возможность запостить конфигурацию - она появится в другом разделе.
30. пользователь 05.01.15 17:52
Сообщение было скрыто модератором.
...
31. almas 254 06.01.15 09:50 Сейчас в теме
Примерно то-же самое на упр формах: http://infostart.ru/public/281099/
Жаль, что 1с-не понимает важности данного направления и не стремиться реализовать это в платформе.
34. Stim213 415 12.01.15 09:46 Сейчас в теме
Настоящий такой велосипед, блестящий и яркий, с лампочками и звоночками, почти как штатный одинесовский..

только зачем в одной базе 2 велосипеда - не понимаю
38. fishca 1254 20.01.15 11:15 Сейчас в теме
Самая главная причина почему не стоит делать DT для хранения информации, это то что есть вероятность невозможности загрузить этот dt.

Самая главная причина почему не стоит пить водку, это то что есть вероятность стать алкоголиком. :)
Оставьте свое сообщение