Dimitry Sibiryakov
Очень просто....Никаких логов не требуется.


Правильно я понимаю, что следствие такой "простоты" - как минимум не возможность Timе In Poinе Restore и всего другого функционала, связанного с наличием лога транзакций?

hvladНасчёт PITR (point in time recovery) - не правильно.
Добавив маркеры времени к тр-циям и удерживая сборку мусора можно получить снимок всей БД на любой момент.

Гм... А не проще ли будет, таки, сделать отдельный "честный" лог?! Что будете делать, если будет поврежден сам файл бд, в котором и "временные метки" и "мусор"?

hvladНасчёт "всего другого функционала" - уточните о чём именно речь.

Да все, что связано с использованием лога транзакций - репликация, зеркалирование.

Dimitry SibiryakovОтлично делаются и без лога.

Готов выслушать архитектуру альтернативных решений...

Dimitry Sibiryakov
pkarklinГотов выслушать архитектуру альтернативных решений...

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_replicator


автор...IBReplicator implements this architecture by way of a change log ...

Дык по другому то никак, ну никак без лога не обойтись. В том или ином его виде.

авторInterBase Replication is not built into the database engine

Поэтому "change log" прикручивается "сбоку" в виде

авторordinary application which accesses the database via the InterBase client API

kdvА что будете делать Вы? Ну, когда поврежден лог, а есть база, не рассматриваем :-)
А вот если будет повреждена база, но есть лог? Лог же не вечный, из него базу целиком не восстановить.
Понятно, что можно взять какой-то бэкап базы, и накатить сверху лог, если они "стыкуются".

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

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

1. Полный бэкап в воскресенье в 0:00;
2. Дифференциальный бэкап каждый день, кроме воскресенья, в 0:00;
3. Бэкап лога транзакций - каждый час.

Предположим, что в четверг в 17.45.13 происходит развал массива на котором лежит файл бд.

Действия админа в данном случаи при необходимости восстановления на момент сбоя:

1. Выполнить Tail-Log Backup - т.е. снять резервную копию лога транзакций, которые "накопились" с момента последнего бэкапа лога в 17.00;
2. Восстановить фуллбэкап от воскресенья;
3. Востановить дифф от четверга;
4. Востановить все бэкапы лога за четверг;
5. Восстановить бэкап лога, сделанный на шаге 1,

тем самым получив бд в состоянии, ровно до сбоя.

kdvПроблема в том, что FB настолько широко используется, что в массе стоит на компах с одним диском (в лучшем случае raid 1), и даже если этот комп обслуживает админ, то админ невероятно тупой, и не способен даже бэкапы регулярно делать .

К сожалению, это проблема не только у FB.

kdvЯ понимаю, что это издержки "дешевизны" ФБ, но такова жизнь.

Да, но даже Экспресс редакция MS SQL имеет описанный выше функционал.

kdvМоя мысль была о том, что там, где в массе стоит ФБ, любое повреждение Оракловской базы или лога вызовет абсолютно тот же эффект, что и повреждение БД ФБ.

По большому счету согласен, но все-тки здОрово иметь как можно больше возможностей для восстановления.

hvladНа мой персональный взгляд, "честный" лог может быть полезен в Firebird только с точки зрения производительности при записи - за счёт последовательного IO. Правда этот IO лишний, так что с ним не всё так хорошо, как некоторые считают. Ну и я не слышал, чтобы лог тр-ций в IB применяли именно для увеличения производительности.

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

hvladНапомню только, что в Firebird используется стратегия записи careful writes, благодаря которой файл БД защищён от поломок из-за краха движка.

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

hvladЗеркалирование - в IB испокон века есть shadow для зеркалирования файла БД (эдакий raid1).

Такое зеркалирование существовало еще в MS SQL 6.5.

hvladЕсли речь о зеркалировании на другой сервер, то накат дельт инкрементного бекапа (а он многоуровневый, в отличие от MSSQL) с успехом заменит накат журналов тр-ций .

Отквоченное соответствует Log Shippingу в MS SQL, и это совсем не зеркалирование, которое позволяет менять "на лету" роли серверов (principal\mirror), причем с автоматическим переподключеним клиента на зеркало в случае выхода из строя основного сервера.