Разделение данных на текущую и архивную части. Использование механизма разделения данных вместо RLS Способы разделения информации

Windows

    разделение открытой и шифрованной информации - — [] Тематики защита информации EN red black isolation …

    разделение (текста) на блоки (в криптографии) - разделение (текста) на блоки формирование блоков (сообщения) — Тематики защита информации Синонимы формирование блоков (сообщения) EN blocking … Справочник технического переводчика

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

    разделение привилегий - Принцип открытия механизма защиты данных, при котором для доступа к ним необходимо указать не один, а два пароля (например, двумя лицами). [Домарев В.В. Безопасность информационных технологий. Системный подход.] Тематики защита информации EN… … Справочник технического переводчика

    разделение спектра сигнала на отдельные полосы - — Тематики защита информации EN band splitting … Справочник технического переводчика

    Разделение властей политико правовая теория, согласно которой государственная власть должна быть разделена на независимые друг от друга (но при необходимости контролирующие друг друга) ветви: законодательную, исполнительную и судебную.… … Википедия

    РАЗДЕЛЕНИЕ ВЛАСТЕЙ - политико правовая доктрина и конституционный принцип, лежащий в основе организации власти демократического государства. Согласно ему государственная власть должна быть разделена внутри себя для осуществления системы «сдержек и противовесов». Идея … Большая актуальная политическая энциклопедия

    Разделённая Корея Разделение Кореи на Северную и Южную Корею произошло в 1945 году после поражения Японии, до этого правившей Кореей, во Второй мировой войне … Википедия

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

    криптографическое разделение - Разделение информации с использованием различных ключей шифрования. Тематики защита информации EN cryptographic separation … Справочник технического переводчика

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

Книги

  • Теория информации. Учебное пособие для прикладного бакалавриата , Осокин А.Н.. В пособии рассмотрены этапы обращения информации в информационных системах, методы и модели измерения количества информации, датчики, описание сигналов (спектральное и вейвлет-представление…

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

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

Свойство общего реквизита-разделителя – Разделение пользователей 1С – позволяет установить доступность списка пользователей в зависимости от использования разделителей.

Если разделитель включен для пользователя, то он будет виден в списке пользователей в режиме 1С Предприятие – иначе не виден.

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

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

Условное разделение 1С

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

Чтобы включить условное разделение 1С – нужно указать в свойстве общего реквизита-разделителя – Условное разделение 1С – , который будет отвечать за определение факта включения разделения 1С.

Возможно использовать константу с типом булево или реквизит справочника с типом булево.

Важно – у этой константы/этого справочника нужно отключить использование (выбрать Не использовать) в составе разделителей, только тогда его можно будет выбрать.

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

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

Примечания:

В этой статье

Обзор

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

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

Внимание:

Преимущества разделенной базы данных

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

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

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

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

    Как использовать параметр msinfo32 для проверки файловой системы?

    1. Нажмите кнопку Пуск и выберите команду выполнить .

      В диалоговом окне " выполнить " введите msinfo32 и нажмите кнопку ОК .

      В разделе Сводка системы щелкните значок "плюс" рядом с компонентом компоненты .

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

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

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

Подготовка

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

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

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

    Совет: Если пользователь изменяет данные при разделении базы данных, вы можете импортировать новые данные в серверную базу данных по завершении работы.

    Несмотря на то, что разделение базы данных - это один из способов предоставления общего доступа к данным, каждый, кто использует базу данных, должен иметь версию Microsoft Office Access, совместимую с форматом серверной базы данных. Например, если файл базы данных имеет формат ACCDB, пользователи не смогут получить доступ к своим данным с помощью Access 2003.

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

Разделение базы данных

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

    Откройте копию базы данных, которая находится на локальном жестком диске.

    На вкладке Работа с базами данных в группе Перемещение данных нажмите кнопку база данных Access . Запустится мастер разделения баз данных.

    Нажмите кнопку разделить базу данных .

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

    Примечания:

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

      Не изменяйте тип файла, если только некоторые пользователи не будут использовать более раннюю версию Access для доступа к данным.

      Вы можете ввести путь к сетевому ресурсу в поле имя файла перед именем файла. Например, если сетевое расположение для серверной базы данных - \\server1\share1\ , а имя файла для серверной базы данных - мидб_бе. accdb , вы можете ввести \\server1\share1\MyDB_be.accdb в поле имя файла .

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

    После завершения работы мастера отображается сообщение с подтверждением.

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

Ограничение изменения структуры серверной базы данных

Чтобы ограничить изменения, вносимые в клиентскую базу данных, которую вы распространяете, рекомендуется сохранить ее в виде скомпилированного двоичного файла (файл. ACCDE). Скомпилированный двоичный файл - это файл приложения базы данных, сохраненный вместе со всеми скомпилированными кодом Visual Basic Access (VBA). В компилированном двоичном файле Access отсутствует исходный код VBA. Пользователи не могут изменять структуру объектов в файле. ACCDE.

    Откройте файл базы данных переднего плана (ACCDB), который вы хотите сохранить как скомпилированный двоичный файл (ACCDE).

Распространение серверной базы данных

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

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

Выполните одно из указанных ниже действий.

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

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

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

Изменение используемой серверной базы данных

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

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

    На вкладке Внешние данные в группе Импорт _амп_ ссылки нажмите кнопку Диспетчер связанных таблиц .

    В диспетчере связанных таблиц выберите таблицы, которые находятся в текущей серверной базе данных.

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

    Установите флажок всегда проверять новое расположение и нажмите кнопку ОК .

    Найдите и выберите новую серверную базу данных.

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

На рис. 7 представлена ситуация, называемая конвейерной параллельностью (pipelined parallelism ). Запрос обрабатывается параллельно, но эта параллельность ограничена "трубой" (" pipe " ) - пропускной способностью диска, на котором находится вся таблица. Чтобы избежать возникновения конвейерной параллельности в системе с параллельной SQL-обработкой, используется разделение данных. На рис. 8 показано, что тот же самый параллельный запрос может быть выполнен намного быстрее после того, как информация большой таблицы разделена среди нескольких дисков.

Способы разделения данных

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

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

К сожалению, при выполнении некоторых запросов нельзя извлечь выгоду из предлагаемого Oracle8 разделения данных по диапазонам. Другим распространенным способом разделения является карусельное (round - robin ) разделение. При этом сервер случайным образом распределяет строки таблицы среди доступных разделов таблицы. Карусельное разделение может ускорить выполнение любых параллельных SQL-запросов, так как данные не разделяются специально для того, чтобы обработать какой-либо запрос. Чтобы распределить физические области хранения информации базы данныхOracleсреди нескольких дисков, обычно применяют различные сервисы внешней операционной системы. Например, в большинстве операционных систем, работающих с многопроцессорными компьютерами, имеются специальные утилиты для чередования дисков (disk striping ), позволяющие случайным образом распределять блоки файлов операционной системы среди нескольких дисков. При использовании карусельного разделения информации баз данныхOracleрекомендуется применять такие утилиты.

1.Преамбула.

Возникла необходимость организовать учет по двум организациям в одной ИБ. Ситуация не уникальная, но так сложилось, что наша сильно не типовая 250 гигобайтная УППшка работала довольно медленно, поэтому вместо RLS решили попробовать разделение данных. Что это такое, описано, например, или . Вкратце, если RLS дополняет условиями запросы SQL, то разделитель данных - это дополнительный столбец в таблицах на уровне СУБД, за счет чего механизм разделения должен работать пошустрее RLS.

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

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

2. Реализация

Платформа 8.2.19.90, без режима совместимости. СУБД - MSSQL Server 2008 R2 Standart.

Создали общий реквизит ОрганизацияРазделитель типа "число", согласились с предложением создать параметры сеанса, заполнили состав реквизита (включили несколько справочников, все документы, регистры накопления, бухгалтерии и расчета). Разделение данных - "Независимо и совместно". Значение параметра сеанса устанавливается из стандартных настроек пользователя в процедуре УстановкаПараметровСеанса в модуле сеанса:

Организация = УправлениеПользователями.ПолучитьЗначениеПоУмолчанию(глТекущийПользователь,"ОсновнаяОрганизация");
ПараметрыСеанса.ОрганизацияРазделительЗначение = Организация.ЗначениеРазделителя;

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

При отключенном разделении, когда ПараметрыСеанса.ОрганизацияРазделительИспользование = Ложь, платформа отказывается записывать документы, вываливаясь с ошибками типа "ОшибкаSDBL: ожидается выражение (pos=12)", поэтому давать пользователю записывать документы в таком варианте нельзя. Для надежности, создали подписки на событие "Перед записью" для объектов, входящих в состав общего реквизита:

Если ПараметрыСеанса.ОрганизацияРазделительИспользование = Ложь Тогда
#Если Клиент Тогда
Предупреждение("Нельзя записать, т.к. разделение данных отключено!");
#КонецЕсли
Отказ = Истина;
КонецЕсли;

План действий у нас был такой: готовим конфигурацию-приемник ИБ №1, проставляем значения общего реквизита = 1, загружаем данные из ИБ №2, после загрузки для всех объектов с пустым (равным 0) значением разделителя устанавливаем ОрганизацияРазделитель = 2.

Конфигурацию подготовили, возник вопрос, как установить значение общего реквизита для документов и их движений в закрытых периодах, причем быстро и без риска того, что полетят цифры в балансе? Через объектную модель 1С записывать разделитель отдельно от объекта невозможно, поэтому пришлось нарушить лицензионное соглашение выкручиваться и писать запрос для MS SQL. Поскольку в составе общего реквизита много объектов, а таблиц в скуле по этим объектам еще больше, написали обработку, генерирующую запрос для SQL (для каждого объекта метаданных, входящего в состав разделителя, писали "update " + Имя_БД + ".dbo._" + ИмяТаблицы + " set _" + ПолеОбщийРеквизит + " = 1";)

Значение проставили, перенесли часть данных из ИБ №2, начали тестировать.

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

Связано это с тем, что регистр бухгалтерии на уровне СУБД хранится как несколько таблиц, и не во всех таблицах было проставлено значение общего реквизита (для просмотра структуры использовали обработку ).


Хорошо, проставляем значение разделителя через MS SQL, аналитику видим. Теперь не работают отчеты. Оказывается, проблемы с запросами к виртуальным таблицам регистра бухгалтерии "Обороты" и "ОборотыДтКт":

(Fld27033 - это как раз общий реквизит в таблице регистра бухгалтерии)

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

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

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


Регистры сведений "починить" путем манипуляций с SQL не получилось (значение разделителя во всех таблицах установлено), поэтому просто исключили их из состава общего реквизита. После нескольких дней экспериментов, неудачными оказываются и попытки восстановить работоспособность вытеснения.

На этот момент принимаем решение выключить разделение данных и использовать-таки RLS. При установке разделения в "не использовать" натыкаемся на ошибки "Microsoft OLE DB Provider forSQL Server: CREATE UNIQUE INDEX terminated because a duplicate keywas found for index...". Т.е., вернуться в состояние до разделения так запросто не получается. Проблема с индексами таблиц перерасчетов, настроек хранения итогов и других. Дело в том, что в таблицах хранятся идентичные строки, отличающиеся только значением общего реквизита. При удалении общего реквизита появляются неуникальные записи. Придется удалить ненужные записи напрямую в MS SQL, примерно так (для таблицы перерасчетов):

Use base;
ALTER TABLE _CRgRecalc1399
ADD id INT IDENTITY(1,1);
GO
DELETE FROM _CRgRecalc1399
WHERE id < (SELECT MAX(id)
FROM _CRgRecalc1399 AS T1
WHERE _CRgRecalc1399._RecorderTRef = T1._RecorderTRef and
_CRgRecalc1399.[_RecorderRRef] = T1.[_RecorderRRef] and
_CRgRecalc1399.[_CalcKindRRef] = T1.[_CalcKindRRef] and
_CRgRecalc1399.[_Fld1400RRef] = T1.[_Fld1400RRef] and
_CRgRecalc1399.[_Fld1401RRef] = T1.[_Fld1401RRef] and
_CRgRecalc1399.[_Fld1402RRef] = T1.[_Fld1402RRef]
);
GO
ALTER TABLE _CRgRecalc1399
DROP COLUMN id;

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

3. Выводы.

Теплилась надежда, что на 8.3 проблемы решены. Не поленились, проверили на 8.3.4.482 (с отключенным режимом совместимости). Смотрели на практически типовой УПП-шке, с изменениями в конфигурации только по общему реквизиту. На этой тестовой базе разделение включили до ввода информации, т.е. платформа должна была корректно записывать значение разделителя во все таблицы, самостоятельно напрямую в MS SQL ничего не писали.

Результат:

    Проблема с запросами к виртуальным таблицам "Обороты" и "ОборотыДтКт" воспроизводится.

    Проблема с вытеснением воспроизводится.

    Проблема с записью в независимые регистры сведений воспроизводится.

    Проблема с выключением разделения - одним нажатием кнопки от него избавится не получится!

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