EnОпция no reserve может привести к повреждению базы данных?
(c) kdv, iBase.ru, 21.03.2025, upd - 24.03.2025
До Firebird 2.1 расширение файла базы данных производилось отдельными страницами, при вставке, обновлении, и прочих операциях. Вообще «поштучное» увеличение файла БД достаточно ресурсоёмко для ввода-вывода.
В Firebird 2.1 был добавлен механизм, который увеличивает размер БД «пачками», чтобы не дёргать файловую систему одиночными запросами на увеличение файла БД. В том числе этот механизм существенно снижает фрагментацию файла БД в файловой системе.
В firebird.conf теперь есть параметр
Соответственно, новые страницы для новых данных – таблиц, версий, индексов и прочего – уже не требуют увеличения файла, а размещаются в этой заранее выделенной области.
И что самое важное – этот механизм предотвращает поломки базы данных, если место на диске с БД вдруг кончилось.
Теперь о no reserve. По умолчанию в базе данных на страницах данных при наполнении таблиц insert-ом сервер оставляет примерно 25% пустого места. Для того, чтобы впоследствии при изменении этих данных версии располагались рядом с данными, а не на отдельных страницах.
Но для «справочных» баз, тех, которые почти не модифицируются, или для тех, которые записываются на read-only носители, очень давно (еще в InterBase) был придуман параметр БД, при котором страницы данных заполняются полностью.
Некоторые администраторы БД решили, что «так будет работать быстрее», и поставили в своих базах опцию no reserve (есть она у вас или нет, вы можете найти в выводе gstat –h database). Это действительно дает некоторое ускорение, но только до тех пор, пока данные не модифицируются. Если сервер получил команду update/delete для модификации записи, то с no reserve версию уже нельзя расположить на заполненной странице, поэтому нужно создать новую страницу и поместить версию уже туда. В результате запись оказывается «размазанной» по нескольким страницам, что увеличивает дисковый ввод-вывод при чтении таких данных, и производительность наоборот, становится хуже.
А самое главное – включение no reserve выключает упомянутый выше механизм «пакетного» увеличения базы данных.
То есть, если для такой базы данных вдруг кончится место на диске, то скорее всего она будет повреждена.
Подробнее:
doc\README.DiskSpaceAllocation.txt
Как выключить no reserve? gfix –use reserve database.fdb
p.s. в принципе, было бы неплохо, если бы в Firebird опция no_reserve задавалась для каждой таблицы отдельно, а не для всей базы. Но увы, пока такого нет.
p.p.s. во всех версиях HQbird no reserve уже не влияет на блочное выделение места под новые страницы. В стандартном Firebird это будет исправлено в ближайших версиях (информация на 24.03.2025).
До Firebird 2.1 расширение файла базы данных производилось отдельными страницами, при вставке, обновлении, и прочих операциях. Вообще «поштучное» увеличение файла БД достаточно ресурсоёмко для ввода-вывода.
В Firebird 2.1 был добавлен механизм, который увеличивает размер БД «пачками», чтобы не дёргать файловую систему одиночными запросами на увеличение файла БД. В том числе этот механизм существенно снижает фрагментацию файла БД в файловой системе.
В firebird.conf теперь есть параметр
#DatabaseGrowthIncrement = 128M
Он означает, что при необходимости увеличения файла БД на одну страницу вместо этого файл БД увеличивается сразу на 128 мегабайт, либо на 1/16 размера БД, если база уже больше 2х гигабайт.Соответственно, новые страницы для новых данных – таблиц, версий, индексов и прочего – уже не требуют увеличения файла, а размещаются в этой заранее выделенной области.
И что самое важное – этот механизм предотвращает поломки базы данных, если место на диске с БД вдруг кончилось.
Теперь о no reserve. По умолчанию в базе данных на страницах данных при наполнении таблиц insert-ом сервер оставляет примерно 25% пустого места. Для того, чтобы впоследствии при изменении этих данных версии располагались рядом с данными, а не на отдельных страницах.
Но для «справочных» баз, тех, которые почти не модифицируются, или для тех, которые записываются на read-only носители, очень давно (еще в InterBase) был придуман параметр БД, при котором страницы данных заполняются полностью.
Некоторые администраторы БД решили, что «так будет работать быстрее», и поставили в своих базах опцию no reserve (есть она у вас или нет, вы можете найти в выводе gstat –h database). Это действительно дает некоторое ускорение, но только до тех пор, пока данные не модифицируются. Если сервер получил команду update/delete для модификации записи, то с no reserve версию уже нельзя расположить на заполненной странице, поэтому нужно создать новую страницу и поместить версию уже туда. В результате запись оказывается «размазанной» по нескольким страницам, что увеличивает дисковый ввод-вывод при чтении таких данных, и производительность наоборот, становится хуже.
А самое главное – включение no reserve выключает упомянутый выше механизм «пакетного» увеличения базы данных.
То есть, если для такой базы данных вдруг кончится место на диске, то скорее всего она будет повреждена.
Подробнее:
doc\README.DiskSpaceAllocation.txt
Как выключить no reserve? gfix –use reserve database.fdb
p.s. в принципе, было бы неплохо, если бы в Firebird опция no_reserve задавалась для каждой таблицы отдельно, а не для всей базы. Но увы, пока такого нет.
p.p.s. во всех версиях HQbird no reserve уже не влияет на блочное выделение места под новые страницы. В стандартном Firebird это будет исправлено в ближайших версиях (информация на 24.03.2025).