Установки сервера

From SunFlurry wiki
Revision as of 12:37, 6 December 2020 by Admin (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Сервер хранит настройки в нескольких файлах инициализации, основной из которых по умолчанию называется sfsrv.ini (однако с помощью ключей запуска из командной строки, можно использовать другой файл для загрузки основных настроек). Обычно файлы настроек являются текстовыми файлами в форматах ANSI или UTF-16. Для формата UTF-16 в файле всегда должен присутствовать соответствующий BOM. Файл инициализации имеет структуру дерева и делится на ветки и переменные. Каждая ветка содержит полный путь и записывается в квадратных скобках (см. пример ниже). Каждая переменная записывается в виде <ИмяПеременной>="<Значение переменной>". При этом кавычки разрешается опускать. Файлы могут содержать комментарии. Комментарием является строка, начинающаяся на знак ; (точка с запятой). Многие файлы создаются и обновляются автоматически, поэтому, комментарии, введенные вручную, могут быть утеряны. Также нужно понимать, что изменения в файлах инициализации, обычно не становятся рабочими до остановки и запуска сервера (при остановке сервера все пользователи, имеющие соединение с ним в данный момент, форсированно завершат работу и все их несохраненные данные будут утеряны). Пример обычного файла инициализации: 

;Начало ветки Common
[Common]

;Переменные ветки Common
LogType="0"
Path="c:\files\data\"

;Начало ветки Common\Comm
[Common\Comm]

;Переменные ветки Common\Comm
ExecutablePathAndCmdLine="c:\files\data\file.exe "arg 1" "arg 2" 2"
DllPath="c:\files\data\file.dll"

;Начало ветки Update
[Update]
...

Ниже дана информация по всем файлам, связанным с изменением свойств работы сервера:

Основной файл настроек sfsrv.ini

Файл обычно хранится в бинарном каталоге сервера, и содержит основные настройки сервера, путь к файлам проекта, путь к библиотеке базы данных, а также настройки базы данных, которыми пользуется эта библиотека. Если в командной строке не указано иного, сервер загружает файл sfsrv.ini по умолчанию. Файл представляется собой текстовый файл инициализации в формате ANSI или UTF-16. В случае UTF-16, в файле должен присутствовать заголовок BOM. Ниже дается список веток и переменных, которые используются сервером в файле. Если ветка или переменная необходимы, они помечены как таковые, большинство же веток и переменных можно опустить. При установке системы с помощью программы-установщика в файле инициализации сервера могут присутствовать не все ветки и переменные, описанные ниже.

  • Ветка Common хранит общие установки сервера.
    • Переменная ServiceName указывает на имя сервиса, используемое данной копией программы сервера. По умолчанию это имя "sfsrv". В случае, когда на одной машине используется более одного сервера базы данных, до регистрации сервиса в системе, необходимо указать другое имя сервиса, так как в системе не может существовать более одного сервиса с одним и тем же именем. Регистрацию и удаление сервиса можно произвести непосредственно из командной строки, нет необходимости использовать программы-установщики. К примеру, чтобы изменить имя сервиса текущей базы данных с sfsrv на sfsrv2, нужно остановить сервер sfsrv.exe stop, отменить регистрацию сервиса sfsrv.exe deinstall, изменить значение этой переменной на sfsrv2 (или добавить переменную, если ее не существовало), зарегистрировать сервис снова sfsrv.exe install и запустить его sfsrv.exe start. Для дополнительной информации, см. статью Ключи запуска сервера из командной строки.
    • Переменная Loglevel задает то, насколько подробной будет информация в логах сервера (обычно это файл sfsrv.log). Значением переменной может быть число от 0 до 2, при этом при 0 логи записываться не будут, 2 в логах будет вестись максимально подробная информация. По умолчанию значение этой переменной равно 1.
    • Переменная LogFile задает имя файла для ведения логов сервером. По умолчанию это sfsrv.log, располагающийся в папке исполняемого файла сервера.
    • Переменная UpdateCataloguesRescanPeriod задает время сканирования каталогов обновлений клиентов _DeploymentBin_ConsoleClient и _DeploymentBin_GUIClient, находящихся в каталоге файлов проекта. Повторное сканирование необходимо для того, чтобы сервер заметил изменения файлов в этом каталоге. Если администратор выложил обновления этих файлов с помощью Студии или вручную, сервер получает из контрольные суммы и передает клиентам при их соединении с сервером, после чего клиент сравнивает их со своими локальными копиями исполняемых файлов и, если значения отличаются, запрашивает на сервере обновление. Переменная задается в секундах и по умолчанию имеет значение 20.
    • Переменная NoExecutableUpdates задает режим, когда исполняемые файлы сервера не будут обновляться при получении обновлений из Студии. Этот режим может быть полезен для старых баз, которые могут по-прежнему требовать обновлений проекта, однако, исполняемые файлы при этом обновлять не нужно. Кроме того, эту переменную необходимо установить разработчику, производящему изменения и компиляцию бинарных файлов сервера, это позволит остановить попытку из замены на старые файлы при каждом соединении Студии с локальным сервером разработчика. Переменная может принимать значения 0 (по умолчанию) и 1.
    • Переменная AcceptCrashLogs задает режим, когда логи отказов и ошибок программы принимаются данным сервером с клиентов и складываются в подкаталоги каталога CrashLogs, находящегося в папке с бинарными файлами сервера. Для доп. информации, см. Общая информация о сервере базы данных. По умолчанию, эта переменная равна 1 (принимать файлы). Так как на клиентах логи создаются во временной папке компьютера, при отсылке их на сервер, клиент не знает, при соединении с какой базой произошла ошибка. Если данный сервер является старой базой данных, собирать такие логи не имеет смысла, так как они, скорее всего, принадлежат другой базе данных, кроме того, для администраторов удобнее собирать логи в одном месте.
  • Ветка Connection (обязательна). Ветка хранит установки, связанные с регистрацией клиента на сервере. Эта ветка обязательно должна присутствовать.
    • Переменная Name задает имя базы данных. Эта информация является справочной.
    • Переменная Description задает краткое описание базы данных. Эта информация является справочной.
    • Переменная Source (обязательна) задает путь к папке с компилированными файлами проекта. Эта переменная обязательно должна присутствовать.
    • Переменная TCPPorts (обязательна) задает TCP/IP порты по которым сервер будет слушать подключения клиентов или Студии. Каждый порт может иметь номер от 1 до 65535. Обычно задается один порт, использование более одного порта может потребоваться в более сложных конфигурациях. Все порты при соединении будут равнозначны. В системе обычно невозможно открыть более одного порта с одним и тем же номером, поэтому для сервера старой базы, работающей на этом же компьютере, необходимо использовать другой порт, не совпадающий с портом рабочей базы. Если при запуске сервер не может открыть все порты для прослушивания, запуск будет завершен с ошибкой. По умолчанию, сервер использует порт 13521, однако использование этого порта строго не рекомендуется, если порт доступен из Интернета.
    • Переменная TCPPassword (обязательна) задает пароль сервера, при TCP/IP соединении. Клиент должен использовать такой же пароль, чтобы иметь возможность регистрации на сервере. Внимание: этот пароль не имеет ничего общего с паролем пользователя при входе в программу клиент. Это внутренний пароль при соединении клиента с сервером до того, как пользователь начинает вводить свое имя и пароль.
    • Переменная TCPTimeout задает тайм-аут ожидания данных сервером до того, как сервер будет считать, что его связь с клиентом была разорвана. Если клиент соединяется с сервером с помощью интернета, из-за проблем со связью, может возникнуть ситуация, когда клиент потерял связь с сервером, но сервер в данный момент не знает этого. Часто клиент блокирует какие-либо объекты или создает транзакцию, и серверу необходимо отключить клиента, если он связь с ним утеряна, чтобы освободить объекты и ресурсы системы. Поэтому, при загрузке или отправке пакетов, после определенного времени "молчания" отсутствия новой информации, сервер отключает клиента автоматически. Здесь задается такой период в миллисекундах. По умолчанию, это значение соответствует числу 300000 (5 минут), для локальных сетей рекомендуется устанавливать его в размере 60000 (1 минута).
    • Переменная AllowIPRanges позволяет задать диапазоны IP-адресов, подключения с которых будут разрешены. По умолчанию, сервер разрешает подключения с любых IP-адресов, если же эта переменная задана, сервер будет разрывать входящее подключение, если оно производится не с адреса, входящего в заданный диапазон. В данный момент можно задать только IPv4 диапазоны. Используется следующий формат, при задании диапазона адресов: <Адрес>/<Маска>[+<Адрес 2>/<Маска 2>...] (к примеру, 127.0.0.1/255.255.255.0+192.168.0.0/255.255.0.0).
    • Переменная CompressionMode позволяет задать форсированный режим сжатия пакетов при работе клиентов. Сжатие пакетов увеличивает нагрузку на процессор машины, на которой работает сервер, однако, это увеличение весьма незначительно. Кроме того, для сжатия пакета тратится дополнительное время, поэтому, для подключения по локальной сети, сжатие замедляет получение ответов сервера. Замедление также очень незначительное, поэтому, его влияние можно проигнорировать. В случае если сеть постоянно загружена, либо клиент подключен с сервером с помощью Интернета, сжатие может значительно ускорить работу с сервером, так как пакеты становятся меньше и пересылка их осуществляется быстрее. Даже для локальной сети сжатие может положительно сказаться на общей ее загрузке. Обычно сжатие настраивается на стороне клиента, однако, данная переменная задает форсированный режим сжатия. Переменная может принимать следующие значения:
      • 0 (по умолчанию) -- разрешить сжатие (сжатие будет настраиваться на стороне клиента).
      • 1 -- запретить сжатие (кроме IP адресов, указанных в переменной CompressionRanges).
      • 2 -- форсировать сжатие на любом подключении (кроме IP адресов, указанных в переменной NoCompressionRanges).
    • Переменная CompressionRanges позволяет задать диапазоны IP-адресов, при подключениях с которых сжатие пакетов (см. выше) будет форсировано. В данный момент можно задать только IPv4 диапазоны. Используется следующий формат, при задании диапазона адресов: <Адрес>/<Маска>[+<Адрес 2>/<Маска 2>...] (к примеру, 127.0.0.1/255.255.255.0+192.168.0.0/255.255.0.0).
    • Переменная NoCompressionRanges позволяет задать диапазоны IP-адресов, при подключениях с которых сжатие пакетов (см. выше) будет запрещено. В данный момент можно задать только IPv4 диапазоны. Используется следующий формат, при задании диапазона адресов: <Адрес>/<Маска>[+<Адрес 2>/<Маска 2>...] (к примеру, 127.0.0.1/255.255.255.0+192.168.0.0/255.255.0.0).
  • Ветка DBase (обязательна). Ветка хранит установки, связанные с базой данных, с загрузкой библиотеки для работы с базой данных, а также установки самой библиотеки.
    • Переменная SingleUserModeOnUpdates задает режим, когда при обновлении (изменении) структуры базы данных, библиотека будет устанавливать эксклюзивных однопользовательский режим. Изменение структуры обычно производится после обновления из Студии и, если к базе данных подключены внешние программы (к примеру, SQL Server Management Studio), есть вероятность, что обновление будет невозможно выполнить из-за занятости таблицы. Для того, чтобы убедиться, что внешние программы не влияют на обновление, сервер инициирует однопользовательский режим, производит требуемые изменения и возвращает к обычному режиму. Такой подход к обновлениям работает по умолчанию и рекомендуется к использованию. Данная переменная может принимать следующие значения:
      • 0 -- не использовать однопользовательский режим при обновлении (не рекомендуется).
      • 1 (по умолчанию) -- использовать однопользовательский режим при обновлении.
      • 2 (по умолчанию) -- производить попытку перехода в однопользовательский режим при обновлении, если он недоступен, оставлять сообщение в логах сервера, и продолжить выполнять обновление в обычном режиме (не рекомендуется).
    • Переменная EnsureUptimeBeforeStart задает режим ожидания готовности СУБД компьютера сразу после его перезапуска. Переменная имеет значение только если сервер находится на том же компьютере, что и СУБД, к которому он производит подключение. Из-за того, что сразу после запуска компьютера, сервис сервера может быть запущен до запуска ПО СУБД (и даже если ПО СУБД запускается раньше, его готовность к работе может наступить через 1-2 минуты после запуска), может возникнуть ситуация, когда сервер базы данных не сможет подключиться к базе данных, либо подключится к ней, но база данных будет отсутствовать, либо база данных будет найдена, но не будет принимать запросы, так как не будет готова. Это может привести к ошибкам в работе сервера, это представляет особенную проблему при подключении к СУБД в режиме ADO, так как последний представляет очень ограниченную информацию о состоянии СУБД и базы данных в момент подключения. Чтобы избежать проблем при подключении и увеличить устойчивость запуска сервера после перезагрузки машины, переменная задает время ожидания в секундах после запуска машины сервера до того момента, как сервер выполнит попытку подключения к СУБД. По умолчанию это время равно 60 секундам, обычно этого времени достаточно, однако, если база данных очень большая, либо СУБД работает с большим количеством баз данных одновременно, и сервер работает в режиме ADO, можно увеличить это время до 2 даже более минут. Не для всех типов СУБД эта переменная актуальна, при работе с СУБД SQLite3, к примеру, ее можно сделать равной нулю без какого-либо риска.
    • Переменная WorkerDll (обязательна) задает относительный или абсолютный путь к библиотеке, которая будет создавать подключения к базе данных. Обычно библиотека находится в той же папке, где располагается исполняемый файл сервера, но она также может находиться в подпапке папки сервера или в другой папке диска. Название файла библиотеки зависит от типа СУБД, к которой она производит подключение. Пример: Dll\MSSQL-ADO\MSSQL_ADO.dll. Большинство переменных ниже зависят от типа библиотеки, для одного типа они могут быть обязательны, для другого типа не иметь значения.
    • Переменная ADOProvider (MSSQL, для ADO-подключений) задает наименование поставщика ADO (тип OLE-сервера ADO) при использовании библиотеки работающей с MS SQL с помощью ADO. По умолчанию это значение равно SQLOLEDB.
    • Переменная ServerAddress (MSSQL и др., обязательна) задает адрес (или наименование машины) и наименование типа сервера (в режиме ADO), если это необходимо. Переменная записывается в виде <Адрес или имя машины>[\<Тип сервера>]. Адрес или имя машины могут представлять собой как IP-адрес SQL сервера (к примеру, 127.0.0.1), так и сетевое имя компьютера сервера (для локального компьютера можно использовать точку (.)). Тип сервера обычно не указывается, но может представлять наименование Instance MSSQL сервера, если она отличается от умолчания. Для Express версии MSSQL, необходимо указать \SQLExpress. Примеры: .\SQLExpress, Server1, 192.168.0.3 и т.п.
    • Переменная DatabaseName (MSSQL и др., обязательна) задает наименование базы данных, с которой будет происходить работа. Важно: сервер никогда не создает базу данных автоматически, если она отсутствовала в СУБД. Это важно из-за того, что администратор должен точно знать, где находятся файлы базы данных, чтобы они не создались на неверном диске и чтобы иметь быстрый доступ к ним. По умолчанию MSQSL располагает файлы баз данных глубоко в структуре папок диска в общей папке с файлами других базы данных, что не является оптимальным расположением файлов (файлы могут быть утеряны или забыты при переустановке операционной системы на компьютере). Поэтому, при настройке новой базы данных, администратор должен самостоятельно создать и назвать новую базу данных в ПО СУБД и указать в файле инициализации имя существующей БД.
    • Переменная ServerLogin (MSSQL и др., обязательна) задает имя пользователя для подключения к СУБД и базе данных. Обычно это административная учетная запись, для MSSQL часто sa. Учетная запись должна иметь полные права в СУБД для работы с базой данных. Внимание: учетная запись, задающаяся здесь, обычно не имеет отношения к учетным записям компьютера (для некоторых СУБД, это может быть не так).
    • Переменная ServerPassword (MSSQL и др., обязательна) задает пароль пользователя для подключения к СУБД и базе данных для логина, задающегося переменной ServerLogin.
    • Переменная SQLiteDll (SQLite, обязательна) задает относительный или абсолютный путь к библиотеке SQLite3, которая будет выполнять функции СУБД. Обычно библиотека находится в той же папке, где располагается исполняемый файл сервера, но она также может находиться в подпапке папки сервера или в другой папке диска. Обычно библиотека имеет название sqlite3.dll, она доступная для свободного скачивания с официального сайта SQLite. Кроме этой библиотеки, для работы с SQLite не требуется скачивание и установка других файлов. Важно: тип библиотеки (x86 или x64) должен совпадать с типом исполняемого файла сервера. Важно: библиотека должна иметь версию не ниже 3.33.0.
    • Переменная SQLiteCacheSize (SQLite, желательна) задает количество памяти, выделяемой под буфер таблиц при работе SQlite3. Переменная задается в мегабайтах. Чем больше это число, тем быстрее будут происходить повторные запросы к таблицам базы данных. Однако, так как исполняемый файл сервера и библиотека СУБД в случае SQLite3 находятся в одном процессе и делят адресное пространство, может получиться ситуация, когда библиотека SQLite3 использует большую часть памяти для своих нужд и сервер не сможет нормально работать при обслуживании запросов пользователей. Чтобы избежать такой ситуации для больших базы данных, необходимо использовать x64 версию сервера на машине с большим объемом памяти. Минимально возможное значение устанавливается в размере 2 Мб, максимальное возможное значение для x86 версий сервера устанавливается в размере 1400Мб, максимальное значение для x64 версий сервера не задано. Значение по умолчанию рассчитывается по следующему алгоритму:
      • Для x86 версий: 67% от полного размера физической памяти машины, но не больше 1400Мб и не меньше 2Мб.
      • Для x64 версий: 67% от полного размера физической памяти машины, но не меньше 2Мб.
    • Переменная SQLiteHeapLimit (SQLite) задает ограничение на полное использование памяти библиотекой SQLite. Это значение включает размер буфера, заданного в переменной SQLiteCacheSize а также временный буфер запросов, переменные и пр. Обычно это значение не установлено (по умолчанию равно нулю), так как SQLiteCacheSize чаще всего использует львиную долю затраченной памяти. При неверной установке, объемные запросы будут выдавать ошибку нехватки памяти. Значение не рекомендуется к изменению.
    • Переменная SQLiteCleanFloats (SQLite) задает режим граничной очистки (округления) вещественных чисел, получаемых от SQLite. Очистка производится по алгоритму системы (см. Числа, NumberToStr). Так как SQLite работает с числами средней точности Double, результаты вычислений могут накапливать ошибку в младших дробных знаках числа. Такие результаты могут немного отличаться от обычно получаемые от других СУБД, что может быть нежелательно для работы, поэтому по умолчанию эта переменная равна 1, позволяя уменьшить влияние расчетов с такими числами на результат. Переменную рекомендуется оставить включенной, однако, если база данных работает не с финансовой информацией, а с информацией произвольной точности (математические вычисления и пр.), данная переменная может иногда вносить (минимальные) искажения в результаты вычислений, поэтому, в этом случае, ее выгоднее отключить.
    • Переменная SQLiteDatabaseCollationPage (SQLite) задает кодовую страницу, которая будет использоваться при перекодировании текста из UTF-8 в ANSI. По умолчанию это значение равно 1251 для кириллической сборки библиотеки сервера. Подобное перекодирование обычно не производится для строковых данных, поэтому, эта переменная не является очень важной.
    • Переменная DatabaseFile (SQLite, обязательна) задает путь и имя файла базы данных SQLite. Кроме этого файла в том же каталоге, где он располагается, SQLite может создавать временные файлы с добавлением префиксов к расширению (к примеру -shm или -wal (Внимание! Файл <Имя>.<Расширение>-wal не является временным, а представляет собой часть базы данных SQLite, см. ниже)), либо временные файлы с расширением sftempdb. При создании новой базы данных, файл может отсутствовать, SQLite3 создаст его самостоятельно, после чего, при проведении аудита, в файле будет создана полная структура базы данных проекта.
    • Переменная SQLiteTempDBFile (SQLite) задает путь и имя файла базы данных, который будет использоваться для работы с функциями временных таблиц. Обычно система сама определяет имя этого файла на основании имени основной базы данных, и помещает его в тот же самый каталог, что и файл базы данных. Однако, если администратору необходимо, он может поместить этот файл в другой каталог или изменить его название по умолчанию. После остановки работы сервера, файл можно удалить, так как он не содержит каких-либо данных, имеющих значение, при запуске сервера, этот файл автоматически очищается. Файл должен располагаться на быстром носителе, иначе работа с функциями временных таблиц может быть замедлена.
    • Переменная SQLiteSynchronousWriting (SQLite) задает режим буферизации записи данных на диск SQLite (см. описание PRAGMA synchronous в документации SQLite). По умолчанию это значение не устанавливается и используется внутреннее умолчание библиотеки SQLite3.dll. Использование значений меньше 2 строго не рекомендуется. Переменная может принимать следующие значения:
      • 0 -- будет разрешен буфер записи операционной системы при записи. В данном режиме запись данных будет производиться гораздо быстрее, однако, существует очень высокая вероятность потерять данные или испортить базу данных при сбое питания на сервере.
      • 1 -- запись будет вестись в режиме "нормальный" с меньшей нагрузкой на диск и очень небольшой опасностью потерять данные, чем в режиме 2. В режиме записи WAL документация SQLite утверждает, что вероятность потерять данные практически отсутствует.
      • 2 -- запись будет вестись в режиме "полный" с большей нагрузкой на диск, чем в режиме "нормальный". Это режим медленнее, чем "нормальный", однако, вероятность потерять данные из-за сбоя питания машине сервера отсутствует. Данный режим рекомендуется к использованию.
      • 3 -- запись будет вестись в режиме "дополнительный" с еще большей нагрузкой на диск, чем в режиме "полный". Это режим может дополнительно повысить безопасность при записи в базу данных.
    • Переменная KeepTraceLogs (SQLite) задает режим, когда все запросы к базе данных и время их исполнения будут также фиксироваться в особом логе сервера. Этот режим отключен по умолчанию и может использоваться для отладки разработчиком системы. Так как при работе с SQLite невозможно использование внешнего профайлера, как, примеру, с MSSQL, библиотека сервера может вести собственный лог профайлера, который может потребоваться разработчику для оптимизации или исправления ошибок в запросах.
    • Переменная JournalMode (SQLite) задает режим записи в базу данных SQLite (см. описание PRAGMA journal_mode в документации SQLite). Режим имеет очень важное значение, так как напрямую влияет на скорость записи данных в базу данных. Переменная может принимать следующие значения:
      • DELETE -- журнал записи (дополнительный файл на диске) создается в момент транзактной записи и удаляется по ее окончании. Это самый медленный режим, он не рекомендуется к использованию.
      • TRUNCATE -- журнал записи (дополнительный файл на диске) создается в момент транзактной записи и очищается по ее окончании. Это медленный режим, он не рекомендуется к использованию.
      • PERSIST -- журнал записи (дополнительный файл на диске) создается в момент транзактной записи и его заголовок заполняется нулями по ее окончании. Это сравнительно медленный режим, он может быть использован, если режим WAL по какой-либо причине не подходит.
      • WAL (по умолчанию) -- журнал записи ведется как отдельный файл, данные поступают в него при любой записи и в определенные моменты, данные из него копируются в основной файл базы данных. Этот режим в 3-5 раз быстрее при обработке документов или сложной транзактной записи, чем другие безопасные режимы SQLite. У этого режима, однако, есть две важные особенности: при загрузке базы данных в режиме WAL, ее невозможно в дальнейшем перевести в любой другой режим; файл журнала на диске (обычно имеет расширение с суффиксом -wal), является частью базы данных (при копировании базы данных, в момент, когда сервер отключен, необходимо также скопировать и этот файл). Данный режим рекомендуется к использованию.
      • MEMORY -- журнал записи создается и ведется в системной памяти, если во время транзакции сервер будет остановлен или пропадет питание, информация в базе данных будет испорчена. Режим не рекомендуется к использованию, и может работать, для тестирования базы данных или ее быстрого заполнения с тем, чтобы потом использовать ее в других режимах.
      • OFF -- журнал записи не ведется вообще. Данный режим несовместим с работой системы, так как он не позволяет отменить транзакцию при ошибке внутри нее. С практической точки зрения, этот режим превращает базу данных в файл прямой записи без возможности работы с транзакциями.
  • Ветка EventLogs. Ветка хранит установки, связанные с ведением журнала регистрации событий базы данных.
    • Переменная LogsMode задает режим ведения таблицы журнала регистрации событий. Переменная может принимать следующие значения:
      • 0 (по умолчанию) -- таблица журнала регистрации событий ведется в текущей базе данных. Такой способ ведения журнала рекомендован. Если запись в журнал ведется внутри транзакции, она будет отменена в момент отмены транзакции совместно с отменой остальных изменений. Минусом такого подхода является увеличение скорости роста базы данных, так как журнал событий может накопить большое количество строк. В отличие от остальных таблиц базы данных, журнал разрешается очищать внешними средствами, если в этом есть необходимость.
      • 1 -- таблица журнала регистрации событий ведется в другой базе данных. Такой способ ведения журнала может использоваться, если необходимо заботиться о размере базы данных (к примеру, если используется MSSQL Express). Базу данных с журналом можно заархивировать и создать заново в любой момент, кроме того сервер с базой данных может находиться на другой машине. Однако, для такого способа ведения журнала нужно понимать, что если запись в журнал ведется внутри транзакции, она не будет отменена в момент отмены транзакции совместно с отменой остальных изменений. Этот минус не затрагивает базы данных в SQLite, для которых записи в журнал, находящийся в отдельной базе данных, входят в одну транзакцию с записями в основную базу данных.
      • 2 -- таблица журнала регистрации событий ведется в текстовом файле. События поступают в один файл в течение календарного месяца, после чего, создается новый файл. Файлы создаются в каталоге EventLogs каталога файлов проекта. Такой способ ведения журнала не рекомендуется к использованию, так как, как и для способа 1, если запись в журнал ведется внутри транзакции, она не будет отменена в момент отмены транзакции совместно с отменой остальных изменений, но самое важное, сервер в данный момент не поддерживает запросы к текстовому журналу, поэтому функция Query будет недоступна. Файл журнала ведется в формате UTF-16 и в нем могут присутствовать знаки с кодами <32.
      • 3 -- таблица журнала регистрации событий не будет вестись вообще.
    • Переменная LogsServerAddress (MSSQL и др.) задает адрес (или наименование машины) и наименование типа сервера (в режиме ADO), для хранения базы данных журнала регистрации событий. Эта переменная используется только, если переменная EventLogs равна 1. Переменная записывается в виде <Адрес или имя машины>[\<Тип сервера>]. Адрес или имя машины могут представлять собой как IP-адрес SQL сервера (к примеру, 127.0.0.1), так и сетевое имя компьютера сервера (для локального компьютера можно использовать точку (.)). Тип сервера обычно не указывается, но может представлять наименование Instance MSSQL сервера, если она отличается от умолчания. Для Express версии MSSQL, необходимо указать \SQLExpress. Примеры: .\SQLExpress, Server1, 192.168.0.3 и т.п.
    • Переменная LogsDatabaseName (MSSQL и др.) задает наименование базы данных журнала регистрации событий. Эта переменная используется только, если переменная EventLogs равна 1. Важно: сервер никогда не создает базу данных автоматически, если она отсутствовала в СУБД. Это важно из-за того, что администратор должен точно знать, где находятся файлы базы данных, чтобы они не создались на неверном диске и чтобы иметь быстрый доступ к ним. По умолчанию MSQSL располагает файлы баз данных глубоко в структуре папок диска в общей папке с файлами других базы данных, что не является оптимальным расположением файлов (файлы могут быть утеряны или забыты при переустановке операционной системы на компьютере). Поэтому, при настройке новой базы данных, администратор должен самостоятельно создать и назвать новую базу данных в ПО СУБД и указать в файле инициализации имя существующей БД.
    • Переменная LogsServerLogin (MSSQL и др.) задает имя пользователя для подключения к СУБД и базе данных журнала регистрации событий. Обычно это административная учетная запись, для MSSQL часто sa. Эта переменная используется только, если переменная EventLogs равна 1. Учетная запись должна иметь полные права в СУБД для работы с базой данных. Внимание: учетная запись, задающаяся здесь, обычно не имеет отношения к учетным записям компьютера (для некоторых СУБД, это может быть не так).
    • Переменная LogsServerPassword (MSSQL и др.) задает пароль пользователя для подключения к СУБД и базе данных журнала регистрации событий для логина, задающегося переменной ServerLogin. Эта переменная используется только, если переменная EventLogs равна 1.
    • Переменная LogsDatabaseFile (SQLite) задает путь и имя файла базы данных журнала регистрации событий SQLite. Эта переменная используется только, если переменная EventLogs равна 1.
    • Переменная UserNameFieldSize задает размер в символах поля UserName таблицы журнала регистрации событий. По умолчанию эта переменная равна нулю (поле имеет неограниченную длину и тип TEXT).
    • Переменная CommentFieldSize задает размер в символах поля Comment таблицы журнала регистрации событий. По умолчанию эта переменная равна нулю (поле имеет неограниченную длину и тип TEXT).
  • Ветка BackupServer хранит установки, связанные созданием резервных копий базы данных по расписанию, либо для возможности инициации создания таких копий с помощью функций InitiateBackupCreation и QueryBackupProgress. Ветка содержит произвольное количество подчиненных веток, каждая из которых должна быть названа уникально. Название подчиненных веток должно иметь вид: Task<Уникальное имя протокола копирования> (к примеру, Task132). Каждая из таких веток будет являться протоколом (задачей) резервного копирования. Ниже даны все возможные переменные, которые используются для задания алгоритма задачи резервного копирования.
    • Переменная TaskName (обязательна) используется для задания короткого уникального имени протокола копирования. По этому имени, задача может быть доступна из функции InitiateBackupCreation.
    • Переменная ExcludedPaths хранит список путей каталога данных проекта, которые необходимо исключить из резервного копирования. Пути всегда относительные, и могут содержать более одного наименования папки. К примеру, _DeploymentBin_ConsoleClient,_DeploymentBin_GUIClient,Temp\Касса. Из резервного копирования, к примеру, можно исключить каталог с картинками, если таковой имеется и он очень объемный. Этот каталог можно включить в резервное копирование раз в день, а каждые 2-4 часа производить копирование без этого каталога. Внимание: из резервного копирования необходимо исключать файлы, которые невозможно открыть на чтение, иначе копирование закончится неудачно, поэтому, если файлы базы данных, хранятся в каталоге файлов проекта, папку с этими файлами необходимо исключить с помощью этой переменной.
    • Переменная BackupTo (обязательна) задает путь в который будет выложен результат резервного копирования (копия). Результатом может быть как папка, так и файл архива (если заданы свойства архиватора). Данный путь может находиться в сети, в этом случае, программа выполнит создание резервной копии базы данных во временной папке текущего компьютера, прежде чем переместить его в место назначения.
    • Переменная TempFolder задает путь к папке с временными файлами. Если эта переменная не задана, используется системная папка временных файлов, однако, при создании резервной копии базы данных, если системная папка располагается на том же носителе, что и файлы базы данных, копирование может быть замедлено и будет увеличивать нагрузку на жесткий диск. В этом случае, выгодно указать папку на другом диске.
    • Переменная MaximalBackupsCount задает максимальное количество старых резервных копий, которые будут храниться в папке результата. Если выполнение резервного копирования закончится удачно и по окончании процесса в папке располагается большее количество копий, чем задано в этой переменной, копии сортируются по времени создания и самые старые лишние копии (папки или файлы) будут удалены. По умолчанию эта переменная равно 10. Количество хранимых копий зависит от размера одной резервной копии и вместимости жесткого диска папки назначения.
    • Переменная Schedule задает расписание, руководствуясь которым, резервное копирование будет происходить автоматически. Без задания расписания, протокол копирования может быть вызван только с помощью функции InitiateBackupCreation, которая, однако, может исполнять и те протоколы (задачи), для которых задано расписание. Расписание представляет собой список времен событий, отделенных запятыми. Каждое время события может быть задано в одном из следующих видов:
      • MMMM -- событие, заданное числом, будет исполняться каждые MMMM минут. К примеру, 30 будет исполняться каждые полчаса.
      • [-][<День недели>:]HH:MM -- событие, состоящее только из чисел, задает день в неделе, час и минуту, когда оно будет инициировано. День недели представляет собой число от 1 до 7. Первым днем считается понедельник, последним воскресенье. Если день недели не задан, событие будет выполняться каждый день в указанный час и минуту. Если при задании события первым символом идет минус (-), дата и время этого события будут исключены из расписания. Таким образом можно исключить создание резервной копии, к примеру, в воскресенье, когда изменения в базе данных не производятся (пример такого расписания: 05:00,-7:05:00). Если событие по каким-то причинам не состоялось в указанное время (возможно в это время выполнялось другое событие резервного копирования), оно может быть инициировано позже, но не более чем на полчаса после своего расписания.
      • [-]D<День месяца>:HH:MM -- событие, начинающееся с буквы D, задает день в месяце, час и минуту, когда оно будет инициировано. Если рабочий месяц не содержит указанного дня (указано число 30, и текущий месяц февраль), оно будет пропущено. Если при задании события первым символом идет минус (-), дата и время этого события будут исключены из расписания. Таким образом можно исключить создание резервной копии, к примеру, в определенные дни месяца, когда копирование будет выполняться по другой задаче в другую папку (пример такого расписания: 7:05:00,-D1:05:00,-D10:05:00,-D20:05:00 -- событие будет выполняться каждое воскресенье в пять утра, за исключением 1, 10 и 20 числа каждого месяца). Если событие по каким-то причинам не состоялось в указанное время (возможно в это время выполнялось другое событие резервного копирования), оно может быть инициировано позже, но не более чем на полчаса после своего расписания.
    • Переменная Archiver задает строку выполнения архиватора. Если эта переменная и переменная ArchiverExtension заданы, результатов работы протокола резервного копирования будут файлы архива, а не папки с файлами-копиями. Можно использовать любой архиватор, работающий из командной строки. Необходимо использовать ключи, которые запретят любые запросы к пользователю, так как на них некому будет отвечать и протокол копирования зависнет в ожидании и никогда не будет выполнен. Пример строки архиватора для 7zip: "C:\Program Files\7-Zip\7z.exe" a "%1%\%3%" -mx4 -sse -y -r "%1%\%2%\*.*" (заметьте, что в строке используются макросы, а использование кавычек обусловлено тем, что путь может содержать пробелы). При создании строки выполнения, можно использовать следующие макросы:
      • %1% -- полный путь к папке, в которой находится папка с файлами для архивации (она может находиться в папке временных файлов или временной папке в папке назначения, но она всегда находится на локальном диске, и не в сети).
      • %2% -- имя папки, в которой располагаются файлы архивации (обычно эта папка входит в архив).
      • %3% -- имя архивного файла в расширением, который требуется создать. Это имя может включать временный суффикс, который будет удален сервером при успешном окончании процесса архивации. Имя архива должно полностью совпадать с заданным в этом макросе, так как серверу необходимо точно знать, какой файл был создан.
    • Переменная ArchiverExtension задает расширение файла архиватора (для 7zip, к примеру, эта переменная должна быть задана как 7z). Если эта переменная и переменная Archiver заданы, результатов работы протокола резервного копирования будут файлы архива, а не папки с файлами-копиями.
    • Переменная ShrinkLogs задает режим, когда после выполнения резервного копирования базы данных, сервер выполнит процедуру резервного копирования и сжатия логов базы данных. Для некоторых типов СУБД (к примеру, SQLite), такая процедура не имеет значения. В этом случае, переменная будет игнорирована. По умолчанию эта переменная не задана. Для MSSQL важно выполнять периодическое сжатие логов базы данных, иначе, через определенное время, логи станут больше по размеру, чем сама база данных, и, если не следить за ними, могут заполнить носитель на котором содержится база данных, и тем самым вызвать остановку работы с базой данных.
  • Ветка UpdateServer устарела и больше не используется.

Файлы настроек, располагающиеся в папке LocalConfig папки проекта

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

  • Файл loginoptions.ini используется для настроек подключения клиентов к системе. Он представляет собой файл инициализации описанного выше формата (в формате ANSI или UTF-16). В файле присутствуют следующие ветки:
    • Ветка Common используется для задания общих установок входа.
      • Переменная StoreHashesOnly позволяет включать режим, когда пароли, введенные пользователями, не сохраняются в файле учетных записей, вместо паролей будут сохраняться хэши MD5. Это позволяет не открывать пароли пользователей администраторам системы. По умолчанию эта переменная равна нулю.
      • Переменные, связанные с формированием минимальной и максимальной длины паролей, а также их уровнем сложности также планируются для использования в данной ветке.
    • Ветка NTLM задает режим использования аутентификации с помощью NTLM для регистрации пользователей. Не наличия такой ветки, новые учетные записи пользователей могут быть введены только с помощью редактора учетных записей в клиенте или непосредственно с помощью текстового редактора в файл usercreds.ini.
      • Переменная UseNTLM задает режим, когда NTLM будет использован (значение должно быть равно 1). По умолчанию значение переменной равно нулю.
      • Переменная NTLMDomain задает домен или имя компьютера, к которому будут переадресовываться запросы по аутентификации пользователей. Если значение не задано, при запуске, сервер попытается найти это значение автоматически, и будет использовать имя домена, в который включен компьютер на котором быть запущен сервер.
      • Переменная UsersGroups задает группы пользователей (как они заданы в панели управления компьютера или в Active Directory домена), имеющих доступ к серверу. Группы пользователей должны перечисляться через запятые. Если эта переменная не задана, любые пользователи, имеющие учетную запись в домене, или учетные запись в файле usercreds.ini (некоторые учетные записи могут быть не связаны с NTLM и заданы вручную из редактора учетных записей в клиенте). будут иметь возможность работать на сервере. Если переменная задан, только пользователи, принадлежащие указанным группам (или группам последующих двух переменных) смогут регистрироваться на сервере. Рекомендуется задавать эту переменную, так как это повышает безопасность в сети.
      • Переменная PowerUsersGroups задает группы пользователей (как они заданы в панели управления компьютера или в Active Directory домена), которые будут обладать правами ограниченных администраторов (см. Общая информация о сервере базы данных). Группы пользователей должны перечисляться через запятые.
      • Переменная AdministratorsGroups задает группы пользователей (как они заданы в панели управления компьютера или в Active Directory домена), которые будут обладать полными правами администраторов (см. Общая информация о сервере базы данных). Группы пользователей должны перечисляться через запятые. Эту переменную рекомендуется задавать, если администраторов достаточно много, если же в программе работает две один-два администратора, безопаснее, установить свойства их учетных записей, как административные и отвязать их от аутентификации NTLM.
  • Файл usercreds.ini создается и ведется сервером автоматически, редактирование его с помощью текстового редактора возможно, но не рекомендуется. При редактировании файла с помощью редактора, сервер должен быть выключен. Файл обычно создается в формате UTF-16 с BOM и представляет собой стандартный файл инициализации, описанный выше. При редактировании учетных записей в визуальном клиенте (см. Общая информация о консольном и визуальном клиентах), сервер получает изменения и сохраняется их в этом файле. Файл также хранит дату и время первого и последнего входа каждого пользователя, поэтому, файл будет обновляться достаточно часто. Наряду с оригинальной версией файла, сервер хранит его предыдущую версию usercreds.bak, которая может пригодиться, если оригинальный файл был испорчен из-за сбоя или по каким-то другим причинам.
  • Файл dbaseLocal.ini обычно создается администратором вручную с помощью текстового редактора и может содержать те же переменные, что и файл dbase.ini, хранящийся в корневой папке файлов проекта и создаваемый непосредственно в Студии. Любая переменная локального файла заменяет значение файла, пришедшего с обменом из Студии. Это актуально и может использоваться для клиентов, если необходимо задать для текущей базы данных другое название, отображаемое в заголовке программы и в диалоге входа пользователя, чтобы пользователи не перепутали разные базы данных. Для редактирования этого файла из Студии см. Установки проекта. Локальный файл установок базы данных может содержать следующие переменные:
    • Name -- позволяет задать наименование проекта (в данном случае, может использоваться для задания наименования локальной базы данных).
    • BuildNumber, VersionName -- задает программные свойства проекта, доступные как из диалогов клиента, так и программно.
    • ExcludedFolders -- задает папки, исключенные из обмена при получении обновлений из Студии.
Retrieved from "http://sfsys.ru/index.php?title=Установки_сервера&oldid=3381"