Архив для категории: Дмитрий Кузьменко

Уже который раз встречаю написание опций gbak (Firebird, InterBase) не думая.
Пишут,
gbak -c -r …

Еще в сентябре 2013 года, на презентации RAD Studio XE5 я докладывал про IBLite, как с ним работать на мобильных устройствах.
http://www.youtube.com/watch?v=YMs1buTLI1Y
Однако сразу же возник вопрос — где находится база данных на смартфоне, как ее «вытащить», обновить, и так далее. Покопавшись в разных местах, ясного ответа не нашел, а экспериментировать вслепую, или перечитывать тонны абстрактной документации по Андроиду, не хотелось.

И вот, к счастью, нашелся человек, который просто и понятно объяснил, где что и как:

Рекомендую блог Андрея Ефимова, особенно статьи:

Deployment Manager или куда ещё можно задеплоить файлы

Получаем список доступных устройств хранения информации
(должна быть правка под мою Sony Xperia V)

Обновляем файл базы данных без перезапуска приложения
(тут про SQLite, но можно легко переделать и на IBLite)

Собственно, эти статьи, и тестирование кода явились как бы хорошим пинком в правильном направлении, в результате которого я форсирую проведение экспериментов в этой области. Что выйдет быстрее — вебинар с Embarcadero или статья в блоге, пока не знаю. Ждите новостей.

На этот пост спровоцировало разбирательство на sql.ru. Там много страниц, можно не читать, здесь я обобщу полученный опыт.

Итак, СУБД Firebird и InterBase обычно используют файловый кэш при работе с БД. Вернее сказать, не «используют кэш», а при открытии файла БД указывают опции, которые включают или выключают этот кэш в определенных случаях.
Одновременно, они используют свой собственный кэш страниц БД.

Самый первый и известный случай изменения режима , это режим Forced Writes, т.е. в терминах CreateFile (Windows) включение (ON) или выключение (OFF) флага FILE_FLAG_WRITE_THROUGH. При ON операционная система осуществляет запись сразу на диск (или в контроллер raid, и т.д.). При OFF операционная система кэширует изменяемые страницы в RAM (подробнее о режимах кэша Windows).
Однако, у Firebird и InterBase существует понятие careful writes, когда изменяемые страницы записываются на диск в таком порядке, чтобы в случае внезапного сбоя (например, reset) база данных осталась максимально целой. Поскольку при OFF (включенном write cache ОС) порядок записи определяется операционной системой, а не СУБД, в случае reset БД может оказаться, скажем, в «физически нецелостном» состоянии.

Например, если добавляется новая запись, а места на страницах БД для этого нет, то создается новая страница, запись размещается на ней, затем ссылка на страницу добавляется в Pointer pages таблицы, после чего в соответствующую inventory pages для новой страницы заносится флаг «занято».
Если все это попадает в кэш ОС, то страница inventory pages может попасть на диск раньше новой страницы с записью, в результате чего при reset окажется, что страница как бы занята, и таблица ссылается на нее, а на деле в этой странице мусор (еще ничего не записано).

Что интересно, до определенного момента в Firebird на Linux режим Forced Writes = ON не поддерживался, т.е. всегда было OFF (исправлено в FB 2.1)

Вторым из режимов кэша, или режимов открытия файлов, является флаг FILE_FLAG_NO_BUFFERING (Windows), который выключает кэш ОС для этого файла вообще, т.е. в том числе и на чтение.
Мы давно экспериментировали с этим флагом в Yaffil, и выяснили, что на обычных дисках производительность резко просаживается (у IB и FB, да и у Yaffil, собственный кэш не умеет делать prefetch, в отличие от ОС), а также, что худший вариант — когда размер страницы не совпадает с размером кластера файловой системы.
В общем, по результатам теста этот флаг было решено оставить в покое.

Со временем кэш дисков, контроллеров и вообще систем хранения сильно вырос, и стал достаточно умным. Так что на некоторых устройствах есть смысл во включении Direct I/O.
Для InterBase возможность отключить кэш ОС была введена в версии XE.
В Firebird такая возможность появилась в 2.5. Для всех баз на сервере direct I/O можно включить путем установки опции FileSystemCacheThreshold=0 в firebird.conf.
Что интересно, режим direct I/O включается не только этим нулем, а и в том случае, если указанный размер кэша БД (DefaultDBCachePages в firebird.conf или page buffers в конкретной БД) больше, чем FileSystemCacheThreshold.
То есть, поскольку FileSystemCacheThreshold по умолчанию 65536, то режим direct I/O включится, если размер кэша в конфиге или БД указан больше этого значения.

Попасть на эти грабли могут разве что пользователи Firebird с архитектурой SuperServer, потому что у Classic и SuperClassic раздельный кэш БД, и выставлять значения кэша больше 65к страниц никому и в голову не придет — сервер тут же начнет отжирать память. Например, для страницы 8к 65к страниц кэша станут 512 мегабайтами RAM, потребляемыми на каждого пользователя.

С другой стороны, у SuperServer кэш БД общий для всех пользователей, и поэтому вполне разумно указать его побольше, особенно если размер БД как минимум 1 гигабайт.
Но как только вы включите такой кэш, «внезапно» для БД отрубится файловый кэш операционной системы (если не изменить параметры по умолчанию в firebird.conf).

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

Дополнения:

• на Linux указанные режимы открытия файлов это O_SYNC и O_DIRECT.
• после включения direct I/O режим Forced Writes уже не имеет значения (будет всегда ON)
• в Firebird 2.5.2 исправлена еще одна проблема с кэшем Windows.

Продолжаем. Я не случайно остановился после установки SEP, поскольку дальнейшие действия возможны в двух «опциях». InterBase поддерживает два алгоритма шифрования. DES и AES. DES можно использовать по умолчанию, в том числе в редакциях Trial и Developer, а вот AES можно включить только в полной (купленной) редакции. Впрочем, в использовании DES или AES нет никакой разницы, кроме, разумеется, факта, что AES является более сильным алгоритмом, и пришел на смену DES (для вскрытия которого несколько лет назад были даже созданы специализированные микросхемы). У DES длина ключа 56 байт, у AES — 128-256 байт.

Тем не менее, для проверки будет достаточно DES. Напомню, что шифровать можно как базу целиком, так и отдельные столбцы, поэтому я на всякий случай создам 3 разных ключа шифрования. Логинимся под SYSDSO, выполняем команды

CREATE ENCRYPTION db_des for DES 
CREATE ENCRYPTION kname_des for DES 
CREATE ENCRYPTION sname_des for DES

все созданные ключи хранятся в таблице RDB$ENCRYPTIONS. Вообще команда CREATE ENCRYPTION сложнее:

create encryption key-name [as default] [for {AES | DES}]
[with length number-ofbits [bits]]
[password {‘user-password’ | system encryption password}]
[init_vector {NULL | random}] [pad {NULL | random}]
[description ‘some user description’]

Length — можно использовать только для AES, указывая длину ключа 128, 192 или 256 бит. 128 по умолчанию для AES.
Password — только для ключей, которыми шифруют столбцы. Можно использовать для дополнительной аутентификации при расшифровке зашифрованных столбцов.
Init-vector — random включает Ciper Block Changing, при которой для одинаковых значений генерируется разный зашифрованный текст. При null для этого используется Electronic Codebook (в DataDef.pdf на странице 214 это указано как Electronic Cookbook). Null по умолчанию.
Pad — при random padding одинаковые значения могут давать разный результат шифрования. Null по умолчанию.

! включение init-vector random или pad random делают невозможным создание индекса по зашифрованному столбцу, при попытке проиндексировать такой столбец сервер выдаст ошибку. Нужно отметить, что и без init-vector и pad с поиском по индексированным зашифрованным столбцам не все хорошо, об этом будет дальше.

Чтобы пользователи могли зашифровать базу или столбцы, SYSDSO должен дать им гранты на использование ключей. Я даю гранты SYSDBA

GRANT ENCRYPT ON ENCRYPTION db_des to SYSDBA; 
GRANT ENCRYPT ON ENCRYPTION kname_des to SYSDBA; 
GRANT ENCRYPT ON ENCRYPTION sname_des to SYSDBA;

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

Продолжение следует.

Отличная конференция была, все прошло замечательно. Правда, я прочитал какой-то бредовый доклад (с моей точки зрения), спутанный из-за предыдущего доклада Сергея Кузнецова.
В финале Embarcadero раздало какое-то чудовищное количество призов (флэшек, кружек, маек и т.п.) Раздача (розыгрыш по заполненным анкетам) заняла минут 30 минимум, в ускоренном темпе. Такое впечатление, что почти треть посетителей получили призы.
Человек 10 не получили призы, потому что ушли раньше.