Часто задаваемые вопросы по СУБД РЕД База Данных (FAQ)

1.7 Часто задаваемые вопросы по СУБД РЕД База Данных (FAQ)

Где скачать СУБД РЕД База Данных?

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

Официальный источник (он же официальный сайт) — https://reddatabase.ru/ru/downloads/.

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

Чтобы релиз-кандидаты были доступны для скачивания, необходимо в своем профиле установить флаг для параметра «Показывать релиз-кандидаты», в этом случае можно видеть свежие версии, которые, вероятно, в последующем станут релизами. Это может потребоваться, если есть подозрения, что в релиз-кандидате была исправлена какая-либо серьезная ошибка. У каждой версии есть описание, можно просмотреть список изменений и исправленных проблем.

Клиентам выдается учетная запись (логин и пароль) с доступом к приобретенным продуктам.

Основные файлы на странице загрузки:

.bin — установочный файл для ОС семейства Linux;
.tar.gz — архив с файлами СУБД для ОС семейства Linux;
.exe — установочный файл для ОС семейства Windows;
.zip — архив с файлами СУБД для ОС семейства Windows;
*dbg-linux-x86_64.tar.gz — отладочные символы для СУБД, установленной на ОС семейства Linux;
*dbg-windows-x86_64.zip — отладочные символы для СУБД, установленной на ОС семейства Windows.

Где скачать документацию на СУБД РЕД База Данных?

Документация доступна на официальном сайте СУБД РЕД Базы Данных — https://reddatabase.ru/ru/documentation/.

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

Где найти видеоролики по СУБД РЕД Базе Данных?

Обучающие видеоролики доступны на официальных каналах СУБД РЕД База Данных:

на RuTube — https://rutube.ru/channel/29879950/;
на Яндекс.Дзен — https://dzen.ru/reddatabase.

Какие есть информационные ресурсы в Интернете по СУБД РЕД Базе Данных?

СУБД Ред База Данных в Telegram — https://t.me/reddatabase.

Канал СУБД Ред База Данных на RuTube — https://rutube.ru/channel/29879950/.

Канал СУБД Ред База Данных на Яндекс.Дзен — https://dzen.ru/reddatabase.

Список наиболее значительных изменений в новых версиях СУБД РЕД База Данных — https://reddatabase.ru/ru/news/.

Площадка для общения СУБД РЕД База Данных и Firebird — https://t.me/firebird_reddatabase.

Какую архитектуру СУБД выбрать?

Архитектура Super — рекомендована к использованию на версии 3.0.9+. Имеет общий кеш, в версии 3.0 она стала действительно многопоточной, до этого она не была ориентирована на многоядерные процессоры. Страничный кеш общий, что дает увеличение производительности. Однако при аварийном завершении того самого единственного процесса, аварийно прекращает свою работу весь сервер.

Архитектура Classic — классическая архитектура, где каждый коннект происходит в отдельном процессе. Каждый процесс имеет собственный кеш данных, что является более надежным решением, но в то же время, в ряде случаев, показывает производительность ниже, чем архитектура Super.

Архитектура Superclassic — не рекомендована к использованию, в дальнейшем, возможно, будет изъята из дистрибутива.

Чем отличается текущая версия СУБД от Firebird?

Сравнение версии 3.0 с версией 2.6, а также с Firebird 3.0 находится на официальном сайте в разделе «Продукты» — https://reddatabase.ru/ru/comparison/.

Чем отличается одна редакция СУБД от другой?

Основные различия описаны на официальном сайте в разделе «Продукты» — https://reddatabase.ru/ru/editions/.

Как установить СУБД на Linux?

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

Для назначения прав выполните команду:

sudo chmod a+x /path/to/rdb.bin

Для установки в графическом режиме выполните:

./rdb.bin

Далее следуйте инструкциям установщика.

Для установки в текстовом режиме выполните команду:

./rdb.bin --mode text

Далее следуйте инструкциям установщика.

В чем заключается типовая настройка СУБД после её установки?

Ключевые параметры конфигурационного файла firebird.conf для временных файлов:

TempTableDirectories — это каталог, в котором будут создаваться файлы временных таблиц, сейчас они создаются в каталоге /tmp.
TempDirectories — список временных каталогов для сортировок, временных таблиц и т. п., разделяются точкой с запятой (;), используются по порядку. При отсутствии параметра используются переменные окружения FIREBIRD_TMP, TEMP, TMP, поэтому в systemd необходимо прописать параметр FIREBIRD_TMP. Рекомендуется упорядочить каталоги по скорости доступа, сначала оперативная помять, затем ssd, затем hdd. Если оперативной памяти в избытке, первым можно указать каталог, смонтированный в ОЗУ. Рекомендуется временные каталоги размещать в разделах, отличных от размещения БД. После настройки необходимо следить за состоянием этих каталогов для своевременного исправления возникающих проблем. Пример:
```
TempDirectories = /var/tmp;/mnt/ssd;/mnt/hdd_tmp  
```
TempCacheLimit — используется для ограничения объёма временного пространства, которое может быть кешировано в оперативной памяти. В этом пространстве будут сохраняться данные сортировок, буферов записи, небольших временных блобов перед материализацией и т.д. В целях увеличения производительности, желательно установить это значение больше длины временных файлов в каталогах TempDirectories, если это позволяет объем доступной оперативной памяти.

Ключевые параметры конфигурационного файла firebird.conf для кеширования:

DefaultDbCachePages — количество страниц одной базы данных, находящихся в кеш-памяти одновременно. Супер-сервер использует единый кеш (по умолчанию 2048 страниц), т. е. DefaultDbCachePages общий для всех подключений. В архитектуре Classic используется свой кеш на каждый процесс, поэтому в архитектуре Super значение необходимо устанавливать больше. Измеряется в количестве страниц, поэтому от размера 1 страницы будет зависеть размер памяти, которая будет задействована под кеш.
Предполагается использовать четверть ОЗУ для нужд кеша СУБД.
Значение кеша задается параметром page buffer (см. вывод gstat -h) для каждой БД в отдельности, либо значением DefaultDbCachePages из конфигурационного файла firebird.conf для всего сервера, либо параметром DefaultDbCachePages в конфигурационном файле databases.conf.
В приоритете - параметр page buffer, если page buffer = 0, то значение берется из конфигурационных файлов.
Архитектура Super:
```
MemorySize/(4*PageSize)
```
Архитектура Classic:
```
MemorySize/(4*ConnNum*PageSize)
```
Настройку можно уточнять по итогу мониторинга сервера: учесть объемы для сортировки, файловый кеш, ядро ОС, другие приложения. Самый важный параметр, на который стоит обратить внимание — это количество чтений (Read) страниц и количество Fetch страниц. Fetch — страница берется из кеша (из памяти), если в кеше её нет, то она читается с диска (что замедляет скорость работы). Чем ближе эти значения (write и cache) друг к другу, тем хуже. В идеально прогретом кеше чтений почти не будет, будет только запись — это в архитектуре "супер". В классике кеш у коннектов разный, поэтому чтений там больше. Это связано с необходимостью записи страниц.
FileSystemCacheThreshold — если значение указано больше, чем в DefaultDBCachePages, то включается использование файлового кэша. Если значение меньше — отключается. Предопределённых рекомендаций не существует. Подбор оптимального значения параметра зависит от диска и нагрузки, поэтому необходимо наблюдать за использованием диска и подбирать оптимальное значение. Для Classic оптимальный параметр обязателен, для Super менее критичен.

Далее перечислены ключевые параметры, касающиеся авторизации:

AuthServer и AuthClient — набор методов аутентификации, разрешенных на сервере и клиенте:
- Безопасная парольная (Srp) аутентификация;
- Традиционная (Legacy_Auth) аутентификация;
- Доверительная (Win_Sspi) аутентификация для ОС Windows;
- Многофакторная (Multifactor) аутентификация с применением политик безопасности;
- Доверенная аутентификация через механизм GSSAPI (Gss)
UserManager — плагин для работы с базой данных пользователей:
- Srp;
- Legacy_UserManager;
- Multifactor_Manager.
- Используется первый плагин из списка
DefaultUserManagers — набор стандартных плагинов, в которых по умолчанию будет создаваться пользователь или менятся пароль у пользователя.

Прочие важные параметры firebird.conf:

ServerMode — режим работы сервера (Super, Classic, SuperClassic), требуется перезапуск при изменении, при смене режима необходимо корректировать параметр кеша.
RemoteBindAddress — позволяет привязать входящие соединения к определенному сетевому интерфейсу. При этом все входящие соединения через другие сетевые интерфейсы будут запрещены.
LockAcquireSpins — количество попыток, которые будут сделаны в условном режиме захвата мьютекса таблицы блокировок. Этот параметр позволяет, вместо обращения к ядру, ждать некую атомарную переменную, что уменьшает количество тактов процессора на межпроцессорные вызовы.
LockHashSlots — число слотов хэширования блокировок. Следует увеличивать если под нагрузкой в таблице блокировок много коллизий. См. позднее rdb_lock_print -d <database> | <alias> и Hash lengths. Как правило выставляется по максимуму, из опыта.

В чем заключается типовая настройка сервера после установки СУБД?

Для увеличения допустимого числа процессов СУБД и доступных им ресурсов:

в /etc/security/limits.conf лимиты nproc и nofile для пользователя, от имени которого запускается СУБД (firebird), устанавливаются в 10000;
параметр ядра vm.max_map_count необходимо увеличить до 256000, написав в /etc/sysctl.conf строку:
```
vm.max_map_count=256000  
```
Для немедленного применения настройки необходимо выполнить:
```
sysctl -p  
```
для systemd-систем в /usr/lib/systemd/firebird.service пропишите:
```
Environment = FIREBIRD_TMP=/path/to/tmp  
```
При наличии достаточного объема RAM можно смонтировать в память временный каталог, куда сервер будет выгружать файлы. Для этого в /etc/fstab необходимо строку:
```
tmpfs /tmp tmpfs size=32G 0 0  
```
где 32G — максимальный размер, до которого может расшириться временный каталог в памяти;
отключить transparent Huge Pages, например, записав в /etc/rc.local:
```
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled  
```

Как понять, какая редакция СУБД Ред База данных у меня установлена?

Необходимо изучить содержимое каталога установки СУБД.

Актуально для 3.0+:

если есть replication.conf — это промышленная редакция;
если его нет, но есть jvm.args — это стандартная редакция;
иначе открытая.

Если есть возможность подключиться к любой БД на сервере, то редакцию можно определить, выполнив запрос:

select rdb$get_context('SYSTEM', 'EDITION') from rdb$database;

Как узнать установленную версию СУБД?

Для определения установленной версии СУБД можно воспользоваться утилитой gbak с ключом -z, например:

/opt/RedDatabase/bin/gbak -z

Пример вывода команды:

gbak:gbak version LI-V3.0.9.0 RedDatabase 3.0 rc.5 (6dcadeecf66529566457de89e35603e10380fa17)  
gbak: ERROR:requires both input and output filenames  
gbak:Exiting before completion due to errors

где LI-V3.0.9.0 RedDatabase 3.0 rc.5 — версия СУБД.

Как обновить СУБД на Linux (минорное обновление)?

Для обновления СУБД на Linux необходимо:

остановить СУБД и проверить статус службы командой:
```
sudo systemctl stop firebird  
systemctl status firebird
```
Закомментировать алиас в databases.conf и через isql проверить, что к БД нет подключений:
```
select count(*) from mon$attachments;  
exit;  
```
Проверить, что БД никто не использует утилитой lsof (от root или sudo), не должны выводиться pid'ы процессов:
```
sudo lsof /path/to/db.fdb  
sudo lsof /opt/RedDatabase/security3.fdb
```
Переименовать /opt/RedDatabase в /opt/RedDatabase_<старая_версия>. Старую версию можно узнать например с помощью утилиты gbak:
```
/opt/RedDatabase/bin/gbak -z
```
Переименование:
```
sudo mv /opt/RedDatabase /opt/RedDatabase_3.0.5.116
```
установить новую версию СУБД, используя установочный бинарный файл, для этого назначить необходимые права:
```
sudo chmod a+x /path/to/rdb.bin  
```
и запустить установку:
```
./rdb.bin
```
Из каталога со старой версией СУБД скопировать в новый каталог необходимые конфигурации (directories.conf, databases.conf, firebird.conf, fbtrace_sec.conf, fbtrace_dba.conf, replication.conf, fbjava.yaml), дополнительные плагины (если такие имеются) и базы данных безопасности (security3.fdb, java-security.fdb);
раскомментировать алиас базы в databases.conf:
запустить РЕД Базу Данных и проверить статус службы (должно быть active (running));
```
sudo systemctl start firebird  
systemctl status firebird  
```
проверить успешность подключения к базе по сетевому протоколу через isql (полный путь до файла БД):
```
/opt/RedDatabase/bin/isql -u sysdba -p masterkey localhost:alias  
```

Как проверить БД на наличие ошибок?

Проверить БД на наличие ошибок можно утилитой gfix, требуется монопольный доступ к БД:

/opt/RedDatabase/bin/gfix -v -full /path/to/database.fdb

gfix может попытаться исправить некоторые некритичные ошибки. Для отмены исправления некритичных ошибок необходимо добавить ключ -n:

/opt/RedDatabase/bin/gfix -v -full -n /path/to/database.fdb

Какие ошибки можно считать критичными при проверке?

Все ошибки файла БД после проверки фиксируются в логе /opt/RedDatabase/firebird.log. Список наиболее критичных из них:

internal Firebird consistency check (cannot find tip page) — нарушение некоторой целостности, например, не получается найти страницу, на которой отмечен статус транзакции, или находится не та страница;
Error while trying to {read from, write to} file — не может прочитать/записать файл БД;
internal Firebird consistency check (decompression overran buffer) — например, при декомпрессии какой-либо записи обнаруживается, что она превышает размер положенного буфера;
Pointer page (sequence NUM) {lost, inconsistent} — потеряна страница указателей;
Missing index root page — потеря root page для индекса;
Transaction inventory pages lost — потерянная страница транзакций;
internal Firebird consistency check (cannot continue after replication failure).

В чем заключается типовой ремонт базы данных?

Типовой ремонт заключается в процедуре резервного копирования (gbak -b -v -g) и восстановления (gbak -c -v -o) поврежденной базы данных.

Ни в коем случае нельзя удалять поврежденную БД до полного завершения ремонта.

Что делать с ошибкой invalid request BLR при восстановлении резервной копии?

В данном случае можно попробовать перекомпилировать проблемные процедуры и еще раз сделать резервную копию. Если используется СУБД 3.0 и выше, восстановить такую резервную копию можно с ключом -ig, который восстановит процедуру с пустым BLR. Далее её необходимо перекомпилировать из исходников.

Что делать, если процесс создания резервной копии или процесс ее восстановления аварийно завершается при прохождении данных из определенной таблицы?

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

/opt/RedDatabase/bin/gbak -user SYSDBA -pas masterkey -b -v -g -skip_d '(TABLE_NAME_1|TABLE_NAME_2)' /path/to/database.fdb /path/to/backup.fbk -y /path/to/backup.log

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

Как проверить наличие мусора в БД?

Утилитой gstat с ключом -h:

/opt/RedDatabase/bin/gstat -h /path/to/database.fdb

В выводе нужно обратить внимание на маркеры:

Oldest transaction, Oldest active, Oldest snapshot, Next transaction.

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

Как принудительно собрать мусор в БД?

Принудительный сбор мусора в БД производится утилитой gfix:

/opt/RedDatabase/bin/gfix -sweep /path/to/database.fdb

Как сделать резервную копию базы данных?

Утилитой gbak, стандартная команда выглядит следующим образом:

/opt/RedDatabase/bin/gbak -user SYSDBA -pas masterkey -b -v -g /path/to/database.fdb /path/to/backup.fbk -y /path/to/backup.log

Для того чтобы убедиться, что процесс создания резервного копирования успешно завершился, необходимо проверить его лог, формирование которого определяется ключом -y (см. команду создания резервной копии) — /path/to/backup.log. При успешном завершении лог заканчивается следующими строками:

gbak:writing names mapping  
gbak:closing file, committing, and finishing. 82432 bytes written  
gbak:stopped at Mon Aug 22 11:37:08 2022

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

Как восстановить резервную копию БД?

Восстановление резервной копии БД производится утилитой gbak. Стандартная команда выглядит следующим образом:

/opt/RedDatabase/bin/gbak -user SYSDBA -pas masterkey -c -v -o /path/to/backup.fbk /path/to/database.fdb -y /path/to/restore.log

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

Для того чтобы убедиться, что восстановление резервной копии успешно завершено, следует проверить его лог, формирование которого определяется ключом -y (см. команду восстановления резервной копии) — /path/to/restore.log.

При успешном завершении лог заканчивается следующими строками:

gbak:fixing views dbkey length  
gbak:updating ownership of packages, procedures and tables  
gbak:adding missing privileges  
gbak:adjusting system generators  
gbak:finishing, closing, and going home  
gbak:adjusting the ONLINE and FORCED WRITES flags  
gbak:stopped at Mon Aug 22 11:52:21 2022

БД переводится в ONLINE-режим.

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

Как установить на сервер отладочные символы для РЕД Базы данных и для чего они нужны?

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

Для установки необходимо скачать нужный архив с официального сайта. В названии архива присутствует обозначение dbg и версия отладочных символов, например, RedDatabase-3.0.9-dbg-linux-x86_64.tar.gz.

Важно!

Версия СУБД и версия символов должны строго совпадать.

Далее архив необходимо распаковать в нужное место. Для этого:

перейдите в mc;
перейдите в папку с отладочными символами;
откройте архив как обычную директорию;
в подкаталогах из архива существуют скрытые папки debug, в которых как раз и находятся все отладочные символы. Скопируйте все каталоги из архива в директорию RedDatabase (каждый каталог из архива в соответствующий ему каталог в /opt/RedDatabase).

На этом установка закончена.

Как настроить сбор дампов на Linux?

Необходимо использовать systemd-coredump для автоматического сбора дампов:

https://redos.red-soft.ru/base/manual/utilites/coredump/?sphrase_id=285533

Что такое репликация и как её настроить?

Репликация — непрерывное копирование (реплицирование) данных (изменений этих данных) с одного сервера (master) на один или несколько других (slave, реплика, зеркало).

В СУБД Ред База Данных реализовано два вида логической репликации:

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

Примеры настройки репликации описаны Руководстве администратора в подразделе "Настройка системы репликации".

Как проверить работу асинхронной репликации?

Утилита rdblogmgr – запускать на мастере:

sudo rdblogmgr -u sysdba -p masterkey -d /db/replicated.fdb

В выводе можно увидеть следующие параметры:

current sequence – текущий сегмент;
last modified – последнее изменение;
total log size – всего в логе байт в 1 сегменте;
free segments – свободных сегментов 1, полных сегментов 0, архивных 0.

Пример вывода:

Log status:

  Current sequence: 8
  Last modified: 2023-12-13 16:48:19
  Total log size: 946259 bytes in 2 segments
  Free segments: 2, full segments: 0, archived segments: 0

Утилита rdbreplmgr – запускать на зеркале с ключом -s:

sudo rdbreplmgr -u sysdba -p masterkey /db/replica.fdb -s

В выводе команды можно увидеть:

Control file — контрольный файл, содержит текущие счетчики пролитых логов, сколько осталось, сколько активных транзакций (бывает так, что в одном сегменте транзакция стартует, а в другом завершается, и в итоге сегмент можно удалить, когда все транзакции в нем завершены), при переинициализации его нужно удалять;
Current segment — количество обработанных сегментов, должно постоянно расти;
Oldest segment — количество старых сегментов, должно быть в значении absent;
Oldest segment — в идеале absent;
Total segments in the queue — количество сегментов в очереди на обработку, в идеале должно стремиться к 0.

Пример вывода:

Status for replica /opt/db/red.fdb:
Master database: 192.168.1.10:/opt/db/red.fdb
Master GUID: {71615D98-0551-48D3-EE94-9441AFF3FE04}
Archive directory: /mnt/repl/logsrdb/arch/
Control file: /mnt/repl/logsrdb/arch/{71615D98-0551-48D3-EE94-9441AFF3FE04}
Current segment: 16 (as of 2020-06-17 09:36:35)
Oldest segment: absent
Total segments in the queue: 1

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

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

my-server (slave) Tue Dec 22 11:24:35 2020  
Database: /path/to/database.fdb  
ERROR: Table MY_TABLE has no unique key

В конфигурационном файле replication.conf на мастере необходимо прописать параметр exclude_without_pk = true, при этом таблицы без первичного ключа не будут реплицироваться на базу зеркала.

Что такое трейс и как его запустить?

Трейс (аудит) — инструмент для аудита событий, происходящих внутри БД, позволяет просматривать:

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

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

системный аудит — запуск происходит с помощью раскомментирования и изменения параметра enabled в конфигурационном файле fbtrace.conf — enabled = true;
интерактивный сеанс аудита — запуск происходит с помощью утилиты rdbtracemgr и заранее подготовленного конфигурационного файла.
```
rdbtracemgr <параметры_подключения> <действия> [<параметры>]
```

Пример команды:

/opt/RedDatabase/bin/rdbtracemgr -SE service_mgr -START -NAME my_trace -CONFIG my_cfg.txt

Как найти неактивные индексы?

Для этого необходимо подключиться к базе данных и выполнить SQL-запрос в любом менеджере БД:

select rdb$index_name from rdb$indices where (rdb$system_flag is null or rdb$system_flag = 0) and RDB$INDEX_INACTIVE > 0;

Как активировать все неактивные индексы?