kdv,
Таким образом в ФБ, если старт копирования начался в 12.00 и длился 10 минут, то в случае аварии в 12.11 восстановить БД возможно на 12.00, и потерять все между 12.00 и 12.11. В отличии от ms sql, где во время копирования из дата файлов, еще и лог забэкапиться, Таким образом мы восстановимся на 12.10 (с откатом всех транзакций незафиксированных и с накатом зафиксированных, но не попавших в дата файл на 12.10!)
А если мы так озабочены потерей данных в ФБ, то нужно делать полное копирование каждую минуту(?), например, если размер БД 100 Гб, а данных прибавилось 100 байт за минуту, то мы делаем копию размером 100 Гб+100 байт еще раз? Или есть понятие "дифференциальный" бэкап?
Это к моему вопросу 1.

Dimitry SibiryakovЛюбитель MSSQL в случае аварии в 12.11 восстановить БД возможно на 12.00, и
потерять все между 12.00 и 12.11.
Поэтому человечество уже довольно давно придумало RAID.


Который не спасает от ошибок пользователей, в отличии от СУБД с нормальным журналом транзакций.

dimitrЛюбитель MSSQLИли есть понятие "дифференциальный" бэкап?
таки есть

То есть, нужно будет делать дифф. бэкап каждую минуту (копировать измененные страницы данных от предыдущего полного бэкапа целиком), вместо того, чтобы бэкапить просто инструкции.
Пока вопрос №1 не раскрыт, и очень сомнительно использование ФБ в промышленных приложениях.

hvladЛюбитель MSSQLТо есть, нужно будет делать дифф. бэкап каждую минуту (копировать измененные страницы данных от предыдущего полного бэкапа целиком)В Firebird дифф. бэкап может копировать только данные, изменённые после предыдущего дифф. бекапа.

Любитель MSSQLвместо того, чтобы бэкапить просто инструкцииПохоже, кому-то нужно освежить свои знания о любимой СУБД.

Это называется инкрементальный бэкап.

Dimitry SibiryakovЛюбитель MSSQLКоторый не спасает от ошибок пользователей, в отличии от СУБД с
нормальным журналом транзакций.
Журнал транзакций позволяет выборочно откатить закоммиченные транзакции? Или как с его
помощью восстановить запись, ошибочно удалённую месяц назад?..


да позволяет, если транзакция была "именована"
да можно. Разворачиваете резервную копию месячной давности на том же экземпляре и обычным запросом выбираете ее и вставляете ее в такую же таблицу текущей БД

Dimitry SibiryakovЛюбитель MSSQLда позволяет, если транзакция была "именована"
И многие ошибающиеся пользователи у Вас именуют свои транзакции?..

Любитель MSSQLда можно. Разворачиваете резервную копию месячной давности на том же
экземпляре и обычным запросом выбираете ее и вставляете ее в такую же таблицу текущей БД

И в каком месте это эксклюзивная возможность журнала транзакций?


Ну это можете делать Вы как разработчик прикладного софта
Журнал транзакций позволяет восстановится в прошлое, что недоступно ФБ

ДринкинсDirksDRDirksDR,

Сорри, эксплорер глюкнул. Переподключение с повтором данных.

Зачем ты этим дерьмом пользуешься?

По теме: таблица неверна. Кроссплатформенности у мсскл нет. Никаких доводов ЗА нет. А вот ПРОТИВ - мно-о-о-ого.

1. Зачем нужна кроссплатформенность?
2. Какие доводы против?

авторавторда позволяет, если транзакция была "именована"
да можно. Разворачиваете резервную копию месячной давности на том же экземпляре и обычным запросом выбираете ее и вставляете ее в такую же таблицу текущей БД
Если эта запись была создана и удалена исключительно между бэкапами(полными/инкрементальными), то да, её можно найти только в бэкапе журнала транзакций (в MS SQL при ведении журнала в режиме FULL или BULK_LOGGED с периодическими бэкапами).
Что делает высоковероятным отсутствие возможности восстановить

авторСчитайте, что в Firebird ведется журнал транзакций в файле базы данных (аналогично режиму SIMPLE в MS SQL, т.е. без возможности бэкапа журнала).

Не совсем одно и тоже , так у журнала транзакций есть и другое преимущество. Он позволяет направить последовательный доступ к диску, в отличии от хранении лога и данных в одном файле, где идет "случайный доступ"

Dimitry Sibiryakovkdvвы зациклились на своем журнале транзакций.
Ну надо же хоть из чего-то высосать хоть какое-то преимущество MS SQL над остальными.
Пусть и чисто сферическое в вакууме.


Не какое-то, а подавляющее и ничего высасывать не надо. FireBird не способен работать под сильной транзакционной нагрузкой даже от 50 пользователей.

Это бесплатное изделие для встроенных БД read-only, например, для записи базы ГАИ или телефонного справочника.

Любитель MSSQLвместо того, чтобы бэкапить просто инструкции
Похоже, кому-то нужно освежить свои знания о любимой СУБД.[/quot]
Ну и страницы данных разумеется.