СУБД. Оптимальность хранения данных.

[DIzer]

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

[alexus]

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

Понятно...

[ilovb]

Если выделить самую суть:
До момента фиксации транзакции на жестком диске обязательно присутствуют и новые и старые данные.

Присутствуют. Но какое это имеет отношению к журналу транзакций?..

То, что вы не знаете зачем нужен журнал транзакций, я еще в начале ветки понял.

http://oberspace.dyndns.org/index.php/topic,220.msg4916.html#msg4916

[ilovb]

И что из этого следует?.. Блокировка и версионность - два принципиально разных механизма. И даже, если СУБД поддерживает оба из них, то это не означает, что она их поддерживает одновременно! "Размыть" и/или "смешать" эти механизмы невозможно в принципе. Я же Вам подробно описал суть того и другого механизма...

Бан на гугле? Почитайте про MS SQL 2005

Ну, начните же думать, наконец.

Я не переставал, чтобы начинать....

[ilovb]

Примеры чего СУБД?.. Да, пожалуйста, те кто не поддерживал/не поддерживает транзакций MySQL, FoxPro, Access, большинство "объектных" СУБД и пр. Они же не соответствуют и требованиям ACID... естественно.

FoxPro, Access - кто бы сомневался. Файловая система NTFS больше на СУБД похожа, чем эти изделия.
Школьные поделки - это тоже СУБД?
Если так, то я пас обсуждать это.

1С в файловом режиме также работает, но ее никто СУБД не называет.

MySQL вроде поддерживает транзакции. Может быть внешними средствами. Не знаю. Искать лень.

[ilovb]

alexus, у меня есть подозрение, что вы не по теме ветки пишете.
Вы контекст не потеряли?

Еще раз:

До момента фиксации транзакции на жестком диске обязательно присутствуют и новые и старые данные.

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

Место на жестком диске при выполнении транзакций все равно нужно выделять.
Это очевидно.
Может вам схему нарисовать?

Вы помните тему и о чем мы говорим?

Это Вам придётся учитывать (я с MS SQL не работаю), на Firebird, к примеру, никакого журнала транзакций нет.

[alexus]

Если выделить самую суть:
До момента фиксации транзакции на жестком диске обязательно присутствуют и новые и старые данные.

Присутствуют. Но какое это имеет отношению к журналу транзакций?..

То, что вы не знаете зачем нужен журнал транзакций, я еще в начале ветки понял.

Ну-ну...

[DIzer]

Спасибо господа,    мне определенно нравится этот форум....

[DIzer]

С другой стороны, поддержка журнала для версионных СУБД не такое трудное дело (в отличие от блокировочных), и почему команда Firebird до сих пор этого не сделала, для меня остаётся загадкой.

Ответ на это вопрос достаточно прост (с моей точки зрения) - в идейном плане Птица полагается на  подлежащую ОС - и по этому надежность хранения данных во многом определяется ОС, с другой стороны- дурабильность имеет смысл только для тех случаев когда внештатные ситуации НЕ ВЕДУТ к порче самой БД. А проблемы о которых вы говорите ведут в 90 процентах к тому , что базу нужно будет восстанавливать из бэкапа... но тогда извините какой смысл заниматься логгированием ради Д. То есть, причина в том что Птичка СПРОЕКТИРОВАНА недостаточно надежной для подобных ситуаций - и никаким логом это дело не выправишь...

[alexus]

С другой стороны, поддержка журнала для версионных СУБД не такое трудное дело (в отличие от блокировочных), и почему команда Firebird до сих пор этого не сделала, для меня остаётся загадкой.

Ответ на это вопрос достаточно прост (с моей точки зрения) - в идейном плане Птица полагается на  подлежащую ОС - и по этому надежность хранения данных во многом определяется ОС, с другой стороны- дурабильность имеет смысл только для тех случаев когда внештатные ситуации НЕ ВЕДУТ к порче самой БД. А проблемы о которых вы говорите ведут в 90 процентах к тому , что базу нужно будет восстанавливать из бэкапа... но тогда извините какой смысл заниматься логгированием ради Д. То есть, причина в том что Птичка СПРОЕКТИРОВАНА недостаточно надежной для подобных ситуаций - и никаким логом это дело не выправишь...

Что значит не выправишь?.. Есть последний backup, есть журнал зафиксированных изменений. Восстанавливаем БД из backup и накатываем все изменения по журналу. Всё. Теперь БД в актуальном состоянии (в том состоянии, после которого произошло обрушение). И при чём здесь ОС?.. А Firebird очень надёжная система, у меня есть заказчик (промышленное предприятие), где система работает с 2001 года... без администрирования. Backup делается по расписанию. Два-три раза в год мы ставим обновления и проверяем работоспособность системы (восстанавливаем из backup, прогоняем тесты). Да, и от других заказчиков нареканий на работу СУБД не поступало ни разу, хотя условия работы СУБД бывают весьма экзотические.

[DIzer]

С другой стороны, поддержка журнала для версионных СУБД не такое трудное дело (в отличие от блокировочных), и почему команда Firebird до сих пор этого не сделала, для меня остаётся загадкой.

Ответ на это вопрос достаточно прост (с моей точки зрения) - в идейном плане Птица полагается на  подлежащую ОС - и по этому надежность хранения данных во многом определяется ОС, с другой стороны- дурабильность имеет смысл только для тех случаев когда внештатные ситуации НЕ ВЕДУТ к порче самой БД. А проблемы о которых вы говорите ведут в 90 процентах к тому , что базу нужно будет восстанавливать из бэкапа... но тогда извините какой смысл заниматься логгированием ради Д. То есть, причина в том что Птичка СПРОЕКТИРОВАНА недостаточно надежной для подобных ситуаций - и никаким логом это дело не выправишь...

Что значит не выправишь?.. Есть последний backup, есть журнал зафиксированных изменений. Восстанавливаем БД из backup и накатываем все изменения по журналу. Всё. Теперь БД в актуальном состоянии (в том состоянии, после которого произошло обрушение). И при чём здесь ОС?.. А Firebird очень надёжная система, у меня есть заказчик (промышленное предприятие), где система работает с 2001 года... без администрирования. Backup делается по расписанию. Два-три раза в год мы ставим обновления и проверяем работоспособность системы (восстанавливаем из backup, прогоняем тесты). Да, и от других заказчиков нареканий на работу СУБД не поступало ни разу, хотя условия работы СУБД бывают весьма экзотические.

1. Вопрос в том, где этот журнал будет хранится - если следовать традиции - в том же файле gdb - то журнал  может попортиться   с большей вероятностью.
2. При том, что используются системные функции работы с диском (не может оптимизировано работать с голым железом)
3. Да , надежная (падать сервер может часто, но к порче данных это не приводит) - и это показывает, что для типичных областей использования Птицы  заложенного запаса прочности хватает без логгирования,  а следовательно усилия разработчиков вполне  можно направить в другое русло.

[alexus]

1. Вопрос в том, где этот журнал будет хранится - если следовать традиции - в том же файле gdb - то журнал  может попортиться   с большей вероятностью.

"Традиционно" журнал должен хранится отдельно от БД, желательно иметь более одного журнала на разных носителях.

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

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

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

Ну, хорошо. Работаю люди с системой целый день, по ночам делается backup. Сервер жёстко "упал" в конце рабочего дня, похоронив БД... Что будем людям говорить?.. Может быть backup делать через каждые пять минут (при продолжительности выполнения backup - 30-40 мин.)?..

[DIzer]

1. традиционно - в стиле Птицы  - все хранится одном файле
2. И почему тогда Оракл, DB2 - это делать могут... наверно оттого что разработчикам делать нечего... 

[alexus]

1. традиционно - в стиле Птицы  - все хранится одном файле

А как же security2.fdb? Да, он один на сервер, но всё же... не всё хранится в одном файле. Сортировка записей происходит во внешнем [временном] файле. Внешние (external) таблицы хранятся во внешних файлах. Библиотеки udf тоже внешние файлы...
Да, и надо ли стремиться к тому, чтобы всё хранить в одном файле?..

[DIzer]

3. Частично от таких бед помогает теневое копирование (вот его и можно развивать как альтернативу логгированию).