Единственным правильным источником для получения сборки является официальный сайт. Дистрибутивы из остальных источников использовать нежелательно, это может быть потенциально опасным.
Официальный источник (он же официальный сайт) — https://reddatabase.ru/ru/downloads/.
В разделе «Загрузки» можно увидеть все файлы, доступные для скачивания. Необходимо быть зарегистрированным пользователем. При этом, если учетная запись имеет соответствующие допуски, то список доступных для скачивания продуктов шире.
Чтобы релиз-кандидаты были доступны для скачивания, необходимо в своем профиле установить флаг для параметра «Показывать релиз-кандидаты», в этом случае можно видеть свежие версии, которые, вероятно, в последующем станут релизами. Это может потребоваться, если есть подозрения, что в релиз-кандидате была исправлена какая-либо серьезная ошибка. У каждой версии есть описание, можно просмотреть список изменений и исправленных проблем.
Клиентам выдается учетная запись (логин и пароль) с доступом к приобретенным продуктам.
Основные файлы на странице загрузки:
Документация доступна на официальном сайте СУБД РЕД Базы Данных — 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 — не рекомендована к использованию, в дальнейшем, возможно, будет изъята из дистрибутива.
Сравнение версии 3.0 с версией 2.6, а также с Firebird 3.0 находится на официальном сайте в разделе «Продукты» — https://reddatabase.ru/ru/comparison/.
Основные различия описаны на официальном сайте в разделе «Продукты» — https://reddatabase.ru/ru/editions/.
Необходимо предоставить права на выполнение. Далее можно выполнять установку в графическом либо в текстовом режиме.
Для назначения прав выполните команду:
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. Если оперативной памяти в избытке, первым можно указать каталог, смонтированный в ОЗУ. Рекомендуется временные каталоги размещать в разделах, отличных от размещения БД. После настройки необходимо следить за состоянием этих каталогов для своевременного исправления возникающих проблем. Пример:
FIREBIRD_TMP
TEMP
TMP
TempDirectories = /var/tmp;/mnt/ssd;/mnt/hdd_tmp
TempCacheLimit — используется для ограничения объёма временного пространства, которое может быть кешировано в оперативной памяти. В этом пространстве будут сохраняться данные сортировок, буферов записи, небольших временных блобов перед материализацией и т.д. В целях увеличения производительности, желательно установить это значение больше длины временных файлов в каталогах TempDirectories, если это позволяет объем доступной оперативной памяти.
Ключевые параметры конфигурационного файла firebird.conf для кеширования:
DefaultDbCachePages — количество страниц одной базы данных, находящихся в кеш-памяти одновременно. Супер-сервер использует единый кеш (по умолчанию 2048 страниц), т. е. DefaultDbCachePages общий для всех подключений. В архитектуре Classic используется свой кеш на каждый процесс, поэтому в архитектуре Super значение необходимо устанавливать больше. Измеряется в количестве страниц, поэтому от размера 1 страницы будет зависеть размер памяти, которая будет задействована под кеш.
DefaultDbCachePages
Предполагается использовать четверть ОЗУ для нужд кеша СУБД.
Значение кеша задается параметром page buffer (см. вывод gstat -h) для каждой БД в отдельности, либо значением DefaultDbCachePages из конфигурационного файла firebird.conf для всего сервера, либо параметром DefaultDbCachePages в конфигурационном файле databases.conf.
page buffer
gstat -h
В приоритете - параметр page buffer, если page buffer = 0, то значение берется из конфигурационных файлов.
page buffer = 0
Архитектура Super:
MemorySize/(4*PageSize)
Архитектура Classic:
MemorySize/(4*ConnNum*PageSize)
Настройку можно уточнять по итогу мониторинга сервера: учесть объемы для сортировки, файловый кеш, ядро ОС, другие приложения. Самый важный параметр, на который стоит обратить внимание — это количество чтений (Read) страниц и количество Fetch страниц. Fetch — страница берется из кеша (из памяти), если в кеше её нет, то она читается с диска (что замедляет скорость работы). Чем ближе эти значения (write и cache) друг к другу, тем хуже. В идеально прогретом кеше чтений почти не будет, будет только запись — это в архитектуре "супер". В классике кеш у коннектов разный, поэтому чтений там больше. Это связано с необходимостью записи страниц.
FileSystemCacheThreshold — если значение указано больше, чем в DefaultDBCachePages, то включается использование файлового кэша. Если значение меньше — отключается. Предопределённых рекомендаций не существует. Подбор оптимального значения параметра зависит от диска и нагрузки, поэтому необходимо наблюдать за использованием диска и подбирать оптимальное значение. Для Classic оптимальный параметр обязателен, для Super менее критичен.
Далее перечислены ключевые параметры, касающиеся авторизации:
Srp
Legacy_Auth
Win_Sspi
Multifactor
Gss
Прочие важные параметры firebird.conf:
rdb_lock_print -d <database> | <alias>
Hash lengths
Для увеличения допустимого числа процессов СУБД и доступных им ресурсов:
nproc
nofile
vm.max_map_count
vm.max_map_count=256000
sysctl -p
Environment = FIREBIRD_TMP=/path/to/tmp
tmpfs /tmp tmpfs size=32G 0 0
transparent Huge Pages
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
Необходимо изучить содержимое каталога установки СУБД.
Актуально для 3.0+:
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 необходимо:
остановить СУБД и проверить статус службы командой:
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:
Переименование:
sudo mv /opt/RedDatabase /opt/RedDatabase_3.0.5.116
установить новую версию СУБД, используя установочный бинарный файл, для этого назначить необходимые права:
и запустить установку:
Из каталога со старой версией СУБД скопировать в новый каталог необходимые конфигурации (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:
-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
Transaction inventory pages lost
internal Firebird consistency check (cannot continue after replication failure)
Типовой ремонт заключается в процедуре резервного копирования (gbak -b -v -g) и восстановления (gbak -c -v -o) поврежденной базы данных.
gbak -b -v -g
gbak -c -v -o
Ни в коем случае нельзя удалять поврежденную БД до полного завершения ремонта.
В данном случае можно попробовать перекомпилировать проблемные процедуры и еще раз сделать резервную копию. Если используется СУБД 3.0 и выше, восстановить такую резервную копию можно с ключом -ig, который восстановит процедуру с пустым BLR. Далее её необходимо перекомпилировать из исходников.
-ig
В данном случае БД можно восстановить с пропуском данных проблемной таблицы (или нескольких таблиц). Для этого используется ключ -skip_d. Пример команды:
-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:
gstat
-h
/opt/RedDatabase/bin/gstat -h /path/to/database.fdb
В выводе нужно обратить внимание на маркеры:
Oldest transaction, Oldest active, Oldest snapshot, Next transaction.
Разница между Oldest transaction и Oldest snapshot должна стремиться к единице. Однако зачастую разница этих параметров достигает больших значений, что негативно влияет на производительность. Для решения данной проблемы рекомендуется регулярная (ежедневная) сборка мусора.
Oldest transaction
Oldest snapshot
Принудительный сбор мусора в БД производится утилитой gfix:
gfix
/opt/RedDatabase/bin/gfix -sweep /path/to/database.fdb
Утилитой gbak, стандартная команда выглядит следующим образом:
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. При успешном завершении лог заканчивается следующими строками:
-y
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.
Версия СУБД и версия символов должны строго совпадать.
Далее архив необходимо распаковать в нужное место. Для этого:
На этом установка закончена.
Необходимо использовать systemd-coredump для автоматического сбора дампов:
https://redos.red-soft.ru/base/manual/utilites/coredump/?sphrase_id=285533
Репликация — непрерывное копирование (реплицирование) данных (изменений этих данных) с одного сервера (master) на один или несколько других (slave, реплика, зеркало).
В СУБД Ред База Данных реализовано два вида логической репликации:
Примеры настройки репликации описаны Руководстве администратора в подразделе "Настройка системы репликации".
Утилита rdblogmgr – запускать на мастере:
sudo rdblogmgr -u sysdba -p masterkey -d /db/replicated.fdb
В выводе можно увидеть следующие параметры:
Пример вывода:
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:
-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, при этом таблицы без первичного ключа не будут реплицироваться на базу зеркала.
exclude_without_pk = true
Трейс (аудит) — инструмент для аудита событий, происходящих внутри БД, позволяет просматривать:
Информации может быть много, поэтому в конфигурационном файле доступны различные фильтры (например, по подключению или по времени). Аудит можно сделать на уровне сервера (системный), а можно открыть интерактивную сессию аудита.
enabled
enabled = true
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;
С помощью SQL-запроса в любом менеджере БД:
EXECUTE BLOCK AS DECLARE VARIABLE stmt VARCHAR (1000); BEGIN for select 'ALTER INDEX '||rdb$index_name ||' ACTIVE;' from rdb$indices where (rdb$system_flag is null or rdb$system_flag = 0) and RDB$INDEX_INACTIVE > 0 order by rdb$foreign_key nulls first into :stmt do EXECUTE STATEMENT :stmt; END
SELECT S.RDB$INDEX_NAME, S.RDB$FIELD_NAME FROM RDB$INDICES I NATURAL JOIN RDB$INDEX_SEGMENTS S WHERE I.RDB$RELATION_NAME='MYTABLE' ORDER BY S.RDB$FIELD_POSITION
где вместо 'MYTABLE' необходимо указать имя нужной таблицы.
SELECT RDB$USER FROM RDB$USER_PRIVILEGES WHERE RDB$RELATION_NAME='COUNTRY' AND RDB$PRIVILEGE='I' AND RDB$USER_TYPE=13 AND RDB$OBJECT_TYPE=0
SELECT MON$ATTACHMENT_ID FROM MON$ATTACHMENTS WHERE DATEDIFF (HOUR, MON$TIMESTAMP, CURRENT_TIMESTAMP) > 24
Для их принудительного завершения:
DELETE FROM MON$ATTACHMENTS WHERE DATEDIFF (HOUR, MON$TIMESTAMP, CURRENT_TIMESTAMP) > 24
DELETE FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID IN ( SELECT MON$ATTACHMENT_ID FROM MON$TRANSACTIONS WHERE DATEDIFF (HOUR, MON$TIMESTAMP, CURRENT_TIMESTAMP) > 24)
DELETE FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID IN ( SELECT MON$ATTACHMENT_ID FROM MON$STATEMENTS WHERE DATEDIFF (HOUR, MON$TIMESTAMP, CURRENT_TIMESTAMP) > 24)
SELECT MON$SQL_TEXT FROM MON$STATEMENTS WHERE MON$STAT_ID = (SELECT FIRST 1 MON$STAT_ID FROM MON$IO_STATS WHERE MON$STAT_GROUP=3 ORDER BY MON$PAGE_READS DESC)
Для их завершения:
DELETE FROM MON$ATTACHMENTS WHERE MON$STAT_ID = (SELECT FIRST 1 MON$STAT_ID FROM MON$IO_STATS WHERE MON$STAT_GROUP=1 ORDER BY MON$PAGE_READS DESC) MON$RECORD_STATS
SELECT MON$SQL_TEXT FROM MON$STATEMENTS WHERE MON$STAT_ID = (SELECT FIRST 1 MON$STAT_ID FROM MON$MEMORY_USAGE WHERE MON$STAT_GROUP=3 ORDER BY MON$MEMORY_USED DESC)
SELECT MON$REMOTE_ADDRESS, MON$REMOTE_PROCESS FROM MON$ATTACHMENTS WHERE MON$STAT_ID = (SELECT FIRST 1 MON$STAT_ID FROM MON$MEMORY_USAGE WHERE MON$STAT_GROUP=1 ORDER BY MON$MEMORY_USED DESC)
Для этих целей можно использовать утилиту isql. С помощью нее можно создавать базу данных, подключаться и выполнять SQL-запросы в базе данных.
isql
Доступна в любой редакции СУБД, входит в состав дистрибутива.
ISQL — это утилита командной строки для работы с базами данных РЕД Базы Данных при помощи языка структурированных запросов (Structured Query Language — SQL).
Пример команды для подключения:
/opt/RedDatabase/bin/isql -u sysdba -p masterkey localhost:employee
где:
Подробное описание возможностей данной утилиты доступно в Руководстве администратора в разделе «Утилита ISQL».
Нехватка места на разделе с базой данных чревата поломкой самой базы, поэтому рекомендуется на разделе иметь хотя бы 30% свободного места (минимум 10%). При этом в логе могут появляться ошибки вида:
my.server.local (master) Sun Sep 20 04:43:29 2020 Database: /path/to/database.fdb ERROR: Log file /path/to/repl/logs/database.fdb.log-142 write failed (error 28)my.server.local (master) Sun Sep 20 04:43:29 2020 Database: /path/to/database.fdb WARNING: Slave is to be detached after error. Replica may become inconsistent at this point.
1. Наличие мусора и выполнение регулярной сборки мусора.
2. Наличие свободного места в ключевых разделах:
3. Загрузку ОЗУ (параметр available в выводе free -m).
available
free -m
4. Лог firebird.log (сообщения об ошибках, остановках сервиса).
5. Системный лог (сообщения об аварийном завершении).
6. Проверка лога создания резервной копии и тестового восстановления резервной копии.
7. Поверка наличия долгих транзакций.
Для проверки размера объектов в БД необходимо собрать статистику по файлу базы данных с помощью команды:
/opt/RedDatabase/bin/gstat -user sysdba -password masterkey -a -r -s my_database.fdb > /home/user/Загрузки/full_gstat.txt
По окончании выполнения команды будет сформирован файл /home/user/Загрузки/full_gstat.txt, используемый далее для подсчета размера объектов.
Пример вывода статистики:
Database "/databases/my_base.fdb" Gstat execution time Fri Dec 22 11:15:11 2023 Database header page information: Flags 0 Generation 164 System Change Number 0 Page size 8192 Server RedDatabase ODS version 12.3 Oldest transaction 126 Oldest active 127 Oldest snapshot 127 Next transaction 127 Autosweep gap 1 Sequence number 0 Next attachment ID 27 Implementation HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc Shadow count 0 Page buffers 0 Next header page 0 Database dialect 3 Creation date Dec 22, 2023 10:36:15 Attributes force write Variable header data: Sweep interval: 20000 Database GUID: {EA77BD7A-868B-4459-F5A2-3E578634467F} *END* ... DOCUMENT (132) Primary pointer page: 204, Index root page: 205 Total formats: 1, used formats: 1 Average record length: 524.10, total records: 1000000 Average version length: 0.00, total versions: 0, max versions: 0 Average fragment length: 0.00, total fragments: 0, max fragments: 0 Average unpacked length: 1010.00, compression ratio: 1.93 Pointer pages: 45, data page slots: 72056 Data pages: 72056, average fill: 92% Primary pages: 72056, secondary pages: 0, swept pages: 0 Empty pages: 3, full pages: 72052 Fill distribution: 0 - 19% = 3 20 - 39% = 0 40 - 59% = 0 60 - 79% = 0 80 - 99% = 72053
Для определения размера таблицы в выводе следует обратить внимание на параметр Data pages, затем умножить количество Data pages нужной таблицы на размер страницы базы данных (размер страницы определяется параметром Page size из заголовка базы данных). В результате будет получен размер данных таблицы в байтах без учета блобов и индексов.
Data pages
Page size
Например, таблица DOCUMENT по статистике имеет 72056 страниц, размер одной страницы — 8192 Б. Размер таблицы равен 72056 х 8192 = ~563 МБ, среднее заполнение 92%.
Размер блобов
Для определения размера блобов в выводе следует обратить внимание на строку Blobs, содержащую значение параметра total length. Если в таблице есть блобы, то в статистике таблицы будет присутствовать следующая строка:
Blobs
total length
Blobs: 1289124, total length: 12577030488, blob pages: 863868
Здесь параметр total length равен 12577030488 — т.е. примерно 11,7 ГБ.
Размер индексов
Для определения размера индексов следует обратить внимание на значение параметра leaf buckets, затем умножить значение параметра leaf buckets на размер страницы базы данных (размер страницы определяется параметром Page size из заголовка базы данных). В результате будет получен размер индекса. Например:
leaf buckets
Index RDB$PRIMARY27 (0) Root page: 72963, depth: 3, leaf buckets: 1205, nodes: 1000000 Average node length: 9.71, total dup: 0, max dup: 0 Average key length: 6.72, compression ratio: 1.00 Average prefix length: 3.01, average data length: 3.74 Clustering factor: 999982, ratio: 1.00 Fill distribution: 0 - 19% = 1 20 - 39% = 0 40 - 59% = 0 60 - 79% = 0 80 - 99% = 1204
Здесь параметр leaf buckets имеет размер 1205 страниц, размер одной страницы (из статистики) — 8192 Б. Размер индекса равен 1205 х 8192 = ~9,4 МБ.
Дата последнего изменения: 22.05.2024
Если вы нашли ошибку, пожалуйста, выделите текст и нажмите Ctrl+Enter.
Нажимая «Отправить запрос», вы соглашаетесь с условиями обработки персональных данных.
Вы будете получать только актуальную информацию по обновлению безопасности
Подписываясь на уведомления, вы соглашаетесь с условиями обработки персональных данных.
На ваш почтовый адрес отправлено письмо с подтверждением подписки.
