Общая информация о сервере базы данных

• Начальная страница

Общая информация

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

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

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

Состав и назначение файлов сервера базы данных

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

• Исполняемый файл сервера (обычно sfsrv.exe) -- основной файл, принимающий соединения и обслуживающий запросы пользователей.
• Файлы инициализации сервера (обычно sfsrv.ini) -- файл с основными настройками сервера, задающими способ подключения в базе данных и путь к файлам проекта.
• Исполняемый файл обновления сервера (обычно SFCDepl.exe) -- файл не требуется для прямой работы сервера, однако используется им в момент поступления обновления ПО сервера или файлов проекта из Студии. Если этот файл отсутствует, он будет автоматически получен (или обновлен) из Студии в момент соединения разработчика с сервером.
• Файлы логов сервера (обычно sfsrv.log и SFCDepl.log) -- файлы, в которых сервер ведет лог работы, состоящий из датированных событий. Если сервер работает неверно, причину проблемы часто можно узнать из этих логов.
• Системная библиотека подключения к СУБД (для MS SQL, к примеру, это может быть MSSQL_ADO.dll или MSSQL_ODBC.dll) -- библиотека, которую использует сервер, для запросов к базе данных. В зависимости от типа используемого ПО СУБД, имя библиотеки может отличаться. Настройки библиотеки также хранятся в файле инициализации сервера (обычно sfsrv.ini). Кроме того, важно понимать версия библиотеки и версия исполняемого файла сервера должны совпадать, так как сервер и библиотека обмениваются внутренней информацией и если их версии различны, такая связка не будет правильно работать. При запуске сервер проверяет версию библиотеки, и отказывается запускаться, если версии не совпадают, однако, администратор также должен быть внимателен. Если используется 64-битный сервер, необходимо также использовать 64-битную версию библиотеки. Платформа (x86 или x64) сервера и библиотеки обычно не связана с платформой ПО СУБД, исключение составляют СУБД типа SQLite, которые работают внутри памяти образа сервера (т.е., загружаются в память, как системная библиотека).
• Папка сбора ошибок и отказов пользователей (обычно CrashLogs) -- папка в которую собираются логи отказов клиентов и программных ошибок. Логи отсортированы по наименованиям компьютеров и пользователей и содержат специфическую информацию, которая может использоваться разработчиком системы или разработчиком проекта для исправления ошибок. На разных платформах и версиях сервера вид логов может отличаться. Логи принимаются с клиентов только при наличии особой установки для этого в файле инициализации сервера.

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

• Папки бинарных файлов обновления клиентов (_DeploymentBin_ConsoleClient, _DeploymentBin_GUIClient) -- папки содержат обновления исполняемых файлов визуального и консольного клиентов. Если режим обновления бинарных файлов разрешен на клиенте, при его соединении с сервером, проверяется соответствие контрольных сумм исполняемых файлов в папке обновления сервера и рабочих файлов клиента. Если контрольные суммы каких-либо файлов не совпадают, производится загрузка обновленных файлов с сервера и, после ее окончания, перезапуск клиента и замена его файлов на загруженные. При работе в таком режиме, для старых баз, которые больше не привязаны к обновлению проекта Студии (к примеру, для баз прошлых лет), необходимо не забывать очищать папки обновления клиентов, чтобы исключить замену более новых файлов на старые в момент регистрации пользователей на сервере со старой базой данных.
• Основная папка с установками проекта (LocalConfig) -- папка содержит различные установки проекта, а также файлы структуры метаданных проекта. Большинство этих файлов загружаются клиентом до начала работы.
• Папка модулей, форм и таблиц проекта (Modules) -- папка содержит исходные и компилированные файлы модулей, форм, таблиц и других файлов (файлов инициализации и пр.), расположенных в структуре подпапок, повторяющей структуру данных проекта в Студии. Сервер передает клиентам требуемые для работы модули, формы и пр. файлы из вложенных папок данной папки.
• Временная папка обновлений (UpdateQueue) -- папка, хранящая временные файлы при обновлении конфигурации проекта, модулей проекта или бинарных файлов. Если обновление не производится в данный момент, эта папка будет пустой.
• Установки пользователей (UserSettings) -- папка хранит сохраненные настройки визуальных форм и другие различные установки пользователей системы. Программа проекта также может использовать вложенные папки этой папки для хранения информации, связанной с пользователями, получить имя папки для текущего пользователя можно с помощью функции GetUserDirectory.
• Дополнительные файлы установок проекта (dbase.ini, GuestRes.sfpack, MainRes.sfpack и пр.) -- файлы хранят дополнительную информацию по проекту, используемую при регистрации пользователя в базе данных. Эти файлы обычно обновляются из Студии.

Доступные СУБД и особенности их использования

Сервер может работать с ограниченным числом СУБД, запросы к которым обрабатывает библиотека подключения к СУБД. На данный момент созданы подключаемые библиотеки для двух типов СУБД: MS SQL и SQlite3. Планируется поддержка других популярных СУБД (PostgreSQL, MySQL и пр.). Особенности, положительные и отрицательные черты разных СУБД рассмотрены ниже:

MS SQL является стандартной СУБД подходящей для работы организации любой величины, отличная масштабируемость и надежность делает ее основным выбором для рабочих баз данных организаций. Система может использовать MS SQL сервера начиная от 2000 версий, однако, рекомендуется использование по крайней мере 2005 версии. Возможно также использование Express версий.

• Положительные стороны MS SQL:
  • Высокая масштабируемость. Можно рассчитывать, что при любом количестве пользователей база данных будет работать практически без замедления. Резервное копирование, которое зачастую производится во время работы пользователей, не сказывается на их работе.
  • Высокая скорость работы запросов.
  • Встроенная высокая точность чисел. MS SQL использует финансовые вычисления с числами 128-битной (и даже 136-битной) точности. Кроме того, сложение чисел с заданным количеством знаков после десятичной точки, выполняется с абсолютной точностью. Это гарантирует не только корректную работу с произвольными периодами с большими числами, но и абсолютную точность при запросах агрегации за период. Для чисел произвольной точностью (т.е., без указанного ограничения по количеству знаков), MS SQL использует стандартный Double тип данных, это позволяет использовать 64-битные числа.
  • Высокая скорость резервного копирования. При резервном копировании работа пользователей практически не замедляется (см. Установки сервера).
  • Встроенный контроль сравнения международных строк и их хранение в UTF-16 позволяет более корректно сортировать строки с международными символами.
  • Хранение обычных строк ANSI в требуемой кодировке (задающейся для базы данных) уменьшает объем базы данных. Большинство строк для локальных баз данных хранятся в ANSI кодировках.
• Отрицательные стороны MS SQL:
  • Высокая стоимость лицензирования ПО СУБД, цены такого уровня доступны только для средних и больших организаций, что делает невозможным использование СУБД в розничных точках. Существует бесплатная Express версия, обладающая рядом ограничений, начиная от меньшей масштабируемости (ограниченное количество ядер процессора и ограничения по максимальной используемой памяти), заканчивая ограничением на размер базы данных. При использовании Express версии необходимо следить за размерами БД и производить обрезание базы данных, когда ее размер начинает приближаться к критическому, кроме того, логи журнала событий желательно хранить в отдельной базе данных, с тем, чтобы создать новую базу с логами, если предыдущая будет переполнена. Использование Express версий подходит для средних или маленьких организаций, а также для розничных точек.

SQLite представляет собой бесплатную системную библиотеку, работающую в памяти внутри образа сервера. SQLite обладает меньшей масштабируемостью, однако, его надежность достаточно высока. Система может работать с версиями SQLite3 начиная с 3.33.0.

• Положительные стороны SQLite:
  • Высокая скорость работы запросов (часто выше, чем у MS SQL).
  • Отсутствие необходимости в лицензировании. Бесплатность делает использование SQLite очень привлекательным для небольших организаций или розничных точек.
  • Отсутствие в необходимости установки дополнительного ПО на компьютер с сервером базы данных. Так как SQLite является системной библиотекой, все что требуется, это указание на нее в файле инициализации сервера.
  • Компактное хранение данных. База данных SQLite, как правило, меньше по размеру базы данных MS SQL (до полутора-двух раз).
• Отрицательные стороны SQLite:
  • Низкая масшабируемость. Большое количество пользователей, работающих одновременно, могут замедлить работу с базой данных, особенно, с операциями, производящими большое количество записей (обработка документов, сохранение документов или справочников с большим количеством строк в строчной части и т.п.). Из-за этого, SQLite рекомендуется использовать для баз данных с небольшим или средним количеством одновременно работающих пользователей. Использование твердотельных накопителей может уменьшить или решить эту проблему.
  • Резервное копирование может замедлить работу пользователей. Резервное копирование является важной операцией, которая должна выполняться регулярно, часто несколько раз в день. SQLite блокирует большое число таблиц при выполнении резервного копирования, что запрещает записи в таблицы до окончания операции (а она может затянуться на несколько минут).
  • Низкая или средняя скорость записи данных. SQLite3 имеет несколько режимов транзакции записи (см. документацию). Режим по умолчанию (WAL) самый быстрый при записи, однако, в этом режиме база данных на диске будет представлена двумя файлами, а не одним. Скорость обработки документов в этом режиме чуть медленнее (до 2 раз) по сравнению с MS SQL. В других режимах (обычно PERSIST, см. Установки сервера) база данных будет представлена только одним файлом (временные файлы после остановки сервера не имеют значения), однако, запись в таблицы будет происходить гораздо медленнее (в среднем почти в 3 раза, в синтетических текстах до 5 раз), чем в режиме WAL. Режим WAL также характеризуется тем, что после инициализации базы в таком режиме, невозможно перейти в другие режимы без создания новой базы.
  • Средняя точность чисел. SQLite использует числа типа Double для операций как с числами заданной точности, так как и с числами произвольной точности. Числа, записанные в таком формате содержат 64 бита информации. Вещественные числа, которыми оперируют клиенты системы (реализованные по умолчанию), используют 80 бит для данных, т.е. сервер будет работать с числами меньшей точности, чем клиент. Кроме меньшей длины чисел, сложение чисел с заданной точностью может накапливать ошибки в младших знаках, что, для большого количества сложений, может исказить результат. При работе с SQLite, в библиотеке предусмотрен обход этой проблемы для функций агрегации, типа SUM, однако при использовании формул внутри функций агрегации (к примеру, SUM(Остаток*1.5)), эта защита может быть отключена. В связи с вышесказанным, SQLite не рекомендуется для использования в базах данных с очень большим количеством записей.
  • Отсутствие встроенной сортировки строк с международными символами, вынуждает использовать простой алгоритм сортировки (библиотека, работающая с SQLite реализует такой алгоритм). Алгоритм работает корректно для большинства случаев, однако, возможны сложные случаи в определенных языках, когда сортировка слов может не совпадать со словарной.

PostgreSQL -- бесплатная СУБД, позиционируемая как альтернатива коммерческим СУБД типа MS SQL. Может использоваться для организаций произвольной величины, обладает хорошим функционалом. При установке СУБД необходимо также установить ODBC драйвер. Для 32-х битного сервера необходим 32-х битный ODBC, для 64-х битного сервера, соответственно 64-х битный ODBC драйвер. Система работает с PostgreSQL начиная с версии 9.6.

• Положительные стороны PostgreSQL:
  • Высокая скорость работы запросов (чуть медленнее, чем у MS SQL).
  • Высокая скорость записи данных (практически не уступающая MS SQL, выше, чем у SQLite3, к примеру, среднее время обработки сложного документа, которое для MySQL было 1480 мс. (см. ниже), для PostgreSQL получилось около 222 мс.)
  • Хорошая масштабируемость.
  • Высокая точность чисел Numeric, не уступающая MS SQL.
  • Отсутствие необходимости в лицензировании. Бесплатность делает использование PostgreSQL очень привлекательным как альтернатива MS SQL, в том числе для организаций с большим количеством пользователей и транзакций.
  • Сравнительно компактное хранение данных. База данных PostgreSQL обычно не больше, чем подобная база MS SQL.
  • Возможность управления базой данных с помощью сторонних утилит (в отличие от SQLite, где пользовательская сортировка делает невозможным, к примеру, переиндексацию с помощью внешних программ).
  • Хорошая скорость резервного копирования. Даже если резервное копирование не управляется непосредственно из текста SQL, при соответствующей настройке сервера, оно выполняется быстро, с небольшим замедлением для пользователей, причем, результатом будут сжатые бинарные данные, что экономит место на накопителе с резервными копиями (см. Установки сервера).
• Отрицательные стороны PostgreSQL:
  • Таблицы базы данных хранятся во множестве файлов, папка с файлами базы данных задается автоматически и ее положение трудно изменить. Это может доставить неудобство в администрировании и, если таблиц очень много, может не хватить файловых записей, выделяемых системой для открытия файлов (особенно на старых системах, типа Windows XP).
  • Ресурсоемкая и сравнительно неудобная утилита для работы с базой данных pgAdmin4 (спорно).

MySQL или MariaDB -- бесплатные СУБД, используемые в основном для Интернет сайтов. Проект MariaDB был создан из MySQL после того, как последнюю приобрела компания Oracle. СУБД достаточно похожи, однако, есть отличия в командах и наименованиях констант. Выбор, какую из СУБД использовать, лежит на плечах администратора системы, ниже по тексту даны некоторые соображения на этот счет. Библиотека подключения может работать с MySQL начиная с версии 5.1 (рекомендуется по крайней мере 5.7.9), с MariaDB начиная с версии 10.4.5 (рекомендуется по крайней мере 10.4.12). При установке СУБД необходимо также установить ODBC драйвер. Для 32-х битного сервера необходим 32-х битный ODBC, для 64-х битного сервера, соответственно 64-х битный ODBC драйвер. Для MariaDB можно использовать ODBC драйвер MySQL. Работа базы данных была протестирована с помощью драйвера версии 5.7.9 для MySQL и 3.0.9 для MariaDB (разные СУБД нумеруются по-разному, номера версий сравнивать нельзя).

• Положительные стороны MySQL/MariaDB:
  • Отсутствие необходимости в лицензировании. Бесплатность делает использование СУБД очень привлекательным для небольших и средних организаций.
  • Неплохая масштабируемость по сравнению с SQLite (спорно).
  • Высокая точность чисел Decimal, не уступающая MS SQL.
  • Возможность управления базой данных с помощью сторонних утилит (в отличие от SQLite, где пользовательская сортировка делает невозможным, к примеру, переиндексацию с помощью внешних программ).
• Отрицательные стороны MySQL/MariaDB:
  • Низкая скорость записи информации. Так как СУБД подобного рода используются в основном в окружении, где операции чтения являются доминирующими, скорость записи для них часто оставляет желать лучшего. Эта проблема может быть замаскирована с помощью быстрого твердотельного носителя.
  • Резервное копирование может замедлить работу пользователей. По визуальным оценкам, однако, это замедление меньше, чем в SQLite и зависит от используемого способа копирования (см. Установки сервера).
  • Не компактное хранение данных. Общий размер файлов базы данных на диске может быть на 20% больше, чем размер базы данных MS SQL.
  • Таблицы базы данных хранятся во множестве файлов, папка с файлами базы данных задается автоматически и ее положение трудно изменить. Это может доставить неудобство в администрировании и, если таблиц очень много, может не хватить файловых записей, выделяемых системой для открытия файлов (особенно на старых системах, типа Windows XP).

В Интернете можно встретить статьи о том, что MariaDB всегда быстрее, чем MySQL, по проведенным ниже тестам, при формировании сложных запросов обычно это так, однако, при записи в базу данных MySQL показал несколько более высокую скорость. Возможно, скорость записи на тестовой машине была связана с присутствует антивирусной программы, поэтому необходимо помнить, что СУБД работают с файлами и, если на сервере установлены антивирусные программы, очень важно добавить каталог с данными СУБД в исключения. Перед выбором СУБД, всегда рекомендуется провести собственное тестирование.

• Тесты проводились с версиями: MySQL 5.7.9, MariaDB 10.4.12, для обеих СУБД использовался драйвер MySQL ODBC Unicode 5.7.9, чтобы исключить возможность возникновения разницы в скорости из-за драйвера.
• Базы данных были восстановлены из дампа на один и тот же носитель, размер полученных баз данных на диске составил около 6Гб (восстанавливалась рабочая база данных).
• Время восстановления для MySQL заняло около 2.5 часов, для MariaDB около 3 часов.
• Средняя скорость обработки документа при обработке 200 документов с движениями в большом количестве накопителей для MariaDB составила 1730 мс., для MySQL 1480 мс. Так как обработка документа является очень комплексной задачей и использует временные таблицы, транзакции, много записывает и читает, можно считать ее наиболее тяжелой операцией, которую может выполнять СУБД. Показанная скорость очень низкая, SQLite3, и, тем более, MS SQL выполняют эту задачу гораздо быстрее (SQLite3 примерно в 5 раз, MS SQL примерно в 10 раз). Скорость может быть повышена при использовании быстрых носителей.
• MariaDB, однако, была быстрее при формировании отчетов и сложных запросов с присутствием объектов временных таблиц базы данных, иногда разница была очень значительной (несколько миллисекунд против нескольких секунд). Также в одном из запросов MySQL 5.7.9 вошел в (видимо) бесконечный цикл с полной загрузкой одного ядра процессора, после двух часов ожидания ответа сервер пришлось остановить, при этом MariaDB выполнила такой же запрос менее чем за секунду. Запрос был проанализирован (это был запрос WHERE IN (...) с несколькими операторами JOIN), но обойти эту проблему для MySQL не удалось (превращение IN в JOIN не помогло), вероятнее всего эта была ошибка в указанной версии MySQL. В связи с вышеуказанным, безопаснее использовать MariaDB для рабочей базы данных.

Регистрация пользователей на сервере, права пользователей

Для регистрации на сервере, пользователю требуется учетная запись. Сервер хранит учетные записи в текстовом файле usercreds.ini, находящемся в каталоге LocalConfig. Файл обычно не редактируется напрямую, учетные записи добавляются и редактируются из клиента при наличии административных прав. Такой способ работы, однако, часто неудобен для организаций с большим количеством пользователей, так как их учетные записи приходится заводить два раза -- один раз, как учетную запись операционной системы, второй раз, как учетную запись программы, кроме того, изменение пароля доступа пользователя в операционной системе не будет распространяться на его пароль в программе. Чтобы избежать лишней работы при администрировании и не компрометировать безопасность сети, сервер позволяет использовать также режим аутентификации с помощью протокола NTLM (на ОС Windows). В этом режиме пользователи операционной системы, принадлежащие указанным группам пользователей смогут зарегистрироваться на сервере даже без наличия учетной записи, которая будет создана автоматически при первом входе. Такие учетные записи привязаны к алгоритмам аутентификации операционной системы. При регистрации пользователя, сервер использует NTLM для проверки его пароля на указанной машине сети или на контроллере домена. В реальной работе на сервере часто используется смешанная аутентификация, привилегированные пользователи могут быть введены вручную (такие пользователи могут не иметь учетной записи операционной системы или иметь запись с другим именем регистрации), а обычные используют данные и пароль учетной системы.

Сервер различает пользователей по их правам. Пользователи делятся на три типа:

• Обычные пользователи. Имеют ограничения при выполнении следующий операций:
  • Не могут загружать с сервера содержимое или файлы из папок LocalConfig (кроме файла метаданных), а также исходные файлы проекта (с расширениями SF и SFG), которые обычно используются для отладки.
  • В списке пользователей, получаемом с сервера, отсутствуют данные по статистике соединения.
  • Не могут выполнять функции GetServerStoragesInformation, GetServerUsedSpaceInformation, GetServerLocksInformation, GetAccountNames.
  • Не могут сбрасывать сессии пользователей (обычно из списка пользователей визуального клиента).
  • Не могут переводить сервер в режим запрета регистрации новых пользователей (и обратно).
  • Не могут получать или сохранять изменения в учетных записях пользователей.
• Ограниченные администраторы. Имеют ограничения при выполнении следующий операций:
  • Не могут загружать с сервера содержимое или файлы из папок LocalConfig (кроме файла метаданных), а также исходные файлы проекта (с расширениями SF и SFG), которые обычно используются для отладки.
  • Не могут сбрасывать сессии пользователей (обычно из списка пользователей визуального клиента).
  • Не могут переводить сервер в режим запрета регистрации новых пользователей (и обратно).
  • Не могут получать или сохранять изменения в учетных записях пользователей.
• Администраторы. Не имеют дополнительных ограничений по их правам.

Режим аудита сервера, резервное копирование

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

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

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

• Была создана пустая база данных, при аудите сервер создает ее структуру и заполняет начальными данными.
• База данных была развернула из резервной копии, при этом со времени копирования в структуре данных проекта были сделаны изменения.
• Администратор (по ошибке) пытается использовать базу данных другого проекта. В этом случае, деструктивных изменений не выполняется, происходит сверка уникальных номеров (GUID) базы данных и проекта, если они не совпадают, сервер запущен не будет и в логах будет добавлена соответствующая ошибка.
• Администратор (по ошибке) пытается использовать архивную (старую) базу того же проекта. Такие базы обычно развернуты для того, чтобы пользователи могли получить доступ к старым данным, для развертывания базы данных, необходимо создать копию сервера с другим именем сервиса (см. Установки сервера).
• Структура базы данных была изменена сторонней программой.
• Аудит также изменяет базу данных (минимизируя деструктивные изменения) при принятии обновлений структуры из Студии (см. статью Развертывание проектов).
• Структура базы данных была повреждена в результате отказа оборудования. К сожалению, отделить такой тип расхождения от остальных зачастую невозможно, поэтому задачей администратора становится установка системы на безопасном и проверенном оборудовании с обязательным периодическим резервным копированием базы данных.

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

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

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