Буду ждать)

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

Логический дамп тоже online.

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

А что не так с online-бэкапом например? Бэкапы всегда были вполне себе online всегда в Firebird.

Приходите, все расскажем)

У нас jvm тоже запущена из ядра и тоже работает с базой напрямую из ядра. JDBC только интерфейс. А драйвер мы тоже контрибьютим и развиваем.

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

Был бы очень благодарен за тьму сценариев повреждения файлов. А в случае сбоя ничего не надо накатывать. Все целостно и так. Нулевое время восстановления. Ни одна СУБД так не умеет.

На той, чтобы предоставить обычный доступ к интерфейсу JDBC внутри той-же или новой транзакции и позволить внешней подпрограмме получить доступ к содержимому БД с целью обработки данных.

По надежности вы понимаете неверно. СУБД Ред База Данных поддерживает все свойства ACID и всегда поддерживала. Лог транзакций не единственный способ обеспечения этих свойств. Применяется так называемый Careful Write, поддерживающий консистентное состояние БД на диске в любой момент времени. Посмотрите на канале Ютуб курс "Администрирование". Там об этом было. Или следите за каналом. Мы планируем подробнее об этом рассказать.

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

Здравствуйте!

Спасибо за внимательность и вопрос.

В статье википедии эти правки внесены анонимом без указания источников. Именно это комментировать не корректно. Но постараюсь ответить на Ваш вопрос.

На сегодняшний день суммарный объем ЦБД достигает 240ТБ. А отдельно взятой 15ТБ.
Предел для СУБД Ред База Данных 3.0 составляет 64ТБ. В версии СУБД Ред База Данных 5.0 этот предел значительно увеличен за счет табличных пространств. Об этом можно послушать тут.

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

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

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

Много полезного есть на канале https://www.youtube.com/c/RedDatabase

Не надо. Уже давно есть IDENTITY COLUMN.

http://www.firebirdsql.org/file/documentation/chunk/en/refdocs/fblangref40/fblangref40-ddl-table.html

тестИровщиков

Наскальная живопись

Что-то не написали они ядро кажется.

Выиграть 5 градусов при таком усложнении вообще штука спорная)

Google Reader-а хватило

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

Да и требовать публиковать всякое не надо. Может имеет смысл поощрить, продвинуть, помочь при условии открытости и востребованности. Тогда все по согласию и на пользу.

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

Шарикову бы понравился такой робот

А школы, вузы и больницы уже отвязали? Поэтому только они?

А для других бюджетных организаций они не подойдут? Там такая архитектура процессора не годится?