Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Funny_Falcon
Member

Откуда:
Сообщений: 447
Teilnehmer
Таки версии - это не журнал и у firebird - действительно совсем нет журналирования! А СУБД без журнала транзакций - это не серьезно...

Ну не обязательно.
В блокировочниках журнал обязан быть для UNDO во время ROLLBACK. В версионниках типа Oracle и InnoDB (MySQL) ещё и для версий данных.

PostgreSQL и Firebird не имеют этих проблем по определению.

Также журнал нужен, если запись в сами таблицы кэшируется (для REDO во время восстановления).
Именно поэтому в PostgreSQL он всё таки есть.

А FireBird наверно сразу данные на диск сбрасывает. Так это? careful write это что?
14 дек 06, 18:10    [3538369]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Funny_Falcon
Member

Откуда:
Сообщений: 447
Читаю про careful write.
1. да, это сброс всех данных сразу на диск, но по окончании транзакции. (Здесь я задумался: а если я изменил данных больше, чем помещается в памяти?)
2. в interbase 6.0 по умолчанию sync режим записи отключён. А в firebird ?
3. из-за careful write Firebird не может делать backward index scan - поиск по индексу в обратном направлении. PostgreSQL (да и многие другие) может.
14 дек 06, 18:28    [3538453]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11553
Funny_Falcon
Читаю про careful write.
1. да, это сброс всех данных сразу на диск, но по окончании транзакции. (Здесь я задумался: а если я изменил данных больше, чем помещается в памяти?)
2. в interbase 6.0 по умолчанию sync режим записи отключён. А в firebird ?
3. из-за careful write Firebird не может делать backward index scan - поиск по индексу в обратном направлении. PostgreSQL (да и многие другие) может.

Careful write - это запись данных на диск в определённом порядке. В двух словах - если pageA ссылается на pageB, то сначала должна быть записана pageB.

1. Данные сбрасываются на диск : (а) до коммита по мере необходимости и (б) все что осталось в кеше (для данной тр-ции) по коммиту.
Это не зависит от архитектуры - у других данные по коммиту сбрасываются в лог и пишутся в БД в отложенном режиме.

2. В FB на Windows включен, на остальных платформах выключен

3. Нет. Не из-за careful write. А для гарантии безблокировочной работы (речь о блокировках страниц индекса). В принципе более сложный алгоритм уже обсуждён и ждёт того, кто его реализует. Но потребность невелика :)

PS Обсуждение деталей работы FB здесь офтопик, imho. Есть более правильный форум - велкам туда, если есть желание :)
14 дек 06, 19:08    [3538622]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11553
Teilnehmer
hvlad
Версии - это и есть журнал.


Таки версии - это не журнал и у firebird - действительно совсем нет журналирования! А СУБД без журнала транзакций - это не серьезно...
А вот это тот самый не юмор, который не есть нормально.

Teilnehmer - если есть другие аргументы, кроме "не серьёзно", - давайте их сюда.
Иначе - не надо воздух сотрясать
14 дек 06, 19:15    [3538646]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Teilnehmer
Guest
другие аргументы, кроме "не серьезно":
главный аргумент: наличие журнала транзакций позволит мне восстановить БД после сбоя диска, до состояния предшествующему этому сбою. А в FB, у меня будет всего-лишь последний backup базы, что обычно не приемлимо.
14 дек 06, 20:17    [3538786]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54783

Teilnehmer

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

Т.е. если основной файл базы испарился со взрывом, его можно полностью
восстановить по логу? Логи хранятся с начала времен?
Или наоборот: при уничтожении диска с логом, основная база находится в
состоянии "до сбоя"?

Posted via ActualForum NNTP Server 1.3

14 дек 06, 22:17    [3539007]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Dimitry Sibiryakov

Teilnehmer

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

Т.е. если основной файл базы испарился со взрывом, его можно полностью
восстановить по логу?

Да
Teilnehmer

Логи хранятся с начала времен?

Можно и не с начала времен. Достаточно лишь с момента последнего полного бэкапа.
Teilnehmer

Или наоборот: при уничтожении диска с логом, основная база находится в
состоянии "до сбоя"?

В состоянии на момент последнего чекпоинта - сброса изменений из лога в файл БД.
14 дек 06, 22:45    [3539062]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11553
Teilnehmer
другие аргументы, кроме "не серьезно":
главный аргумент: наличие журнала транзакций позволит мне восстановить БД после сбоя диска, до состояния предшествующему этому сбою. А в FB, у меня будет всего-лишь последний backup базы, что обычно не приемлимо.
Для тех, кому не приемлемо часто делать полные бекапы, сделали инкрементный физический бекап.
Журналы тут совершенно не при чём
14 дек 06, 22:50    [3539068]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
Teilnehmer
hvlad
Версии - это и есть журнал.


Таки версии - это не журнал и у firebird - действительно совсем нет журналирования! А СУБД без журнала транзакций - это не серьезно...

Именно. Журнал - это грубо говоря, когда берем копию базы трех дневной давности и применяем к ней журнал, в результате чего получаем консистентную БД по состоянию на последнюю зафиксированную транзакцию перед сбоем.
14 дек 06, 23:08    [3539108]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
hvlad
Teilnehmer
другие аргументы, кроме "не серьезно":
главный аргумент: наличие журнала транзакций позволит мне восстановить БД после сбоя диска, до состояния предшествующему этому сбою. А в FB, у меня будет всего-лишь последний backup базы, что обычно не приемлимо.
Для тех, кому не приемлемо часто делать полные бекапы, сделали инкрементный физический бекап.
Журналы тут совершенно не при чём

А чем ты будешь свой вчерашний инкрементальный бэкап догонять до момента перед сбоем,чудо в перьях???
Модератор: забанен до субботы


Сообщение было отредактировано: 15 дек 06, 15:15
15 дек 06, 00:13    [3539195]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11553
Apex
hvlad
Teilnehmer
другие аргументы, кроме "не серьезно":
главный аргумент: наличие журнала транзакций позволит мне восстановить БД после сбоя диска, до состояния предшествующему этому сбою. А в FB, у меня будет всего-лишь последний backup базы, что обычно не приемлимо.
Для тех, кому не приемлемо часто делать полные бекапы, сделали инкрементный физический бекап.
Журналы тут совершенно не при чём

А чем ты будешь свой вчерашний инкрементальный бэкап догонять до момента перед сбоем,чудо в перьях???
Ознакомься с предметом беседы, перед тем как хамить, ораклоид
15 дек 06, 00:33    [3539222]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
наконец-то профессиональными терминами заговорили.
15 дек 06, 00:47    [3539235]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Apex
А чем ты будешь свой вчерашний инкрементальный бэкап догонять до момента перед сбоем,чудо в перьях???

а ты наверное, несохраненным вовремя журналом?
15 дек 06, 00:49    [3539237]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
iscrafm
а ты наверное, несохраненным вовремя журналом?
Сам то понял, что сказал?
15 дек 06, 08:34    [3539538]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
hvlad
Apex
А чем ты будешь свой вчерашний инкрементальный бэкап догонять до момента перед сбоем,чудо в перьях???
Ознакомься с предметом беседы, перед тем как хамить, ораклоид
Мне тоже интересно, действительно - чем?
15 дек 06, 08:40    [3539545]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Funny_Falcon

В блокировочниках журнал обязан быть для UNDO во время ROLLBACK. В версионниках типа Oracle и InnoDB (MySQL) ещё и для версий данных.


В Oracle журнал используется ТОЛЬКО для восстановления. Ни для rollback-ов, ни для версионности. Для этих целей ведется UNDO (также защищенный журналом)
15 дек 06, 09:20    [3539668]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
iscrafm
Apex
А чем ты будешь свой вчерашний инкрементальный бэкап догонять до момента перед сбоем,чудо в перьях???

а ты наверное, несохраненным вовремя журналом?


Журнал сохраняется ПОСТОЯННО в процессе работы, в STANDBY-конфигурации на другой сервер.
Так что он всегда сохранен вовремя :) тем и ценен
15 дек 06, 09:45    [3539800]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Funny_Falcon
Member

Откуда:
Сообщений: 447
Gluk (Kazan)
В Oracle журнал используется ТОЛЬКО для восстановления. Ни для rollback-ов, ни для версионности. Для этих целей ведется UNDO (также защищенный журналом)

Прошу прощения. Я действительно всех тонкостей не знаю.

Apex
Teilnehmer

hvlad
Версии - это и есть журнал.


Таки версии - это не журнал и у firebird - действительно совсем нет журналирования! А СУБД без журнала транзакций - это не серьезно...


Именно. Журнал - это грубо говоря, когда берем копию базы трех дневной давности и применяем к ней журнал, в результате чего получаем консистентную БД по состоянию на последнюю зафиксированную транзакцию перед сбоем.


Careful write - и база консистентна не только перед сбоем, но и после него!!! Вообще в любой момент времени!!!
А платят за это отсутствие backward index scan и небольшой потерей скорости (по сравнению с Oracle, разумеется)

А восстановление на любой момент времени - Incremental Backup. Как часто делаешь, так часто и восстанавливаешься.
Не знаю как в Oracle, но в SQLServer нужно было логи тоже архивировать (backup-ить), чтобы потом по ним восстановить.
Ибо если у тебя база полетела, то и за консистентность логов ты тоже отвечать не можешь!!!

Разница конечно же есть, но она не в сути, а в объёмах. Кому-то выгоднее журнал архивить, кому-то - инкрементный бэкап.

Gluk (Kazan)
Журнал сохраняется ПОСТОЯННО в процессе работы, в STANDBY-конфигурации на другой сервер.
Так что он всегда сохранен вовремя :) тем и ценен

Первая дельная мысль. В PostgreSQL >= 8.0 тоже самое сделали.
Правда в Firebird есть mirror database. Но, наверное, это не полная альтернатива.

hvlad
PS Обсуждение деталей работы FB здесь офтопик, imho. Есть более правильный форум - велкам туда, если есть желание :)

По-моему этот форум назвается "Сравнение СУБД". Или я ошибаюсь?
Кстати, спасибо за ответы.
hvlad
3. Нет. Не из-за careful write. А для гарантии безблокировочной работы (речь о блокировках страниц индекса). В принципе более сложный алгоритм уже обсуждён и ждёт того, кто его реализует. Но потребность невелика :)

Знаешь, я тоже это не из пальца высосал, а прочитал в официальной документации Interbase (какую-то ссылку вчера Google выкинул по запросу carefull writes Interbase или careful writer Interbase).
Суть в том, что если pageA ссылается на pageB, то pageB пишется на диск раньше чем pageA. Но чтобы по индексу можно было искать в обоих направлениях, нужен двухсвязный список, т.е. чтобы pageA ссылалась на pageB и pageB ссылалась на pageA. И что тогда писать первым?
15 дек 06, 09:59    [3539880]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Funny_Falcon
Первая дельная мысль. В PostgreSQL >= 8.0 тоже самое сделали.
Правда в Firebird есть mirror database. Но, наверное, это не полная альтернатива.


Собственно в отношении IB/FB меня всегда интересовал этот вопрос. Можно ли как-то накатить последний бакап (полный или инкрементальный) непосредственно до момента креша. Я не говорю о лечении той базы что осталась после креша, это отдельная тема.

В Oracle это делается накатом архивированных и текущих журналов на последний полный физический бакап. Поскольку в IB/FB журналов нет, этого сделать очевидно нельзя ?
Поэтому аналогичные задачи решаются восстановлением порушенной базы, так ?
Плюс в некоторых клонах имеется возможность зеркалировать все изменения на физическую копию базы на другом сервере ?
15 дек 06, 10:13    [3539982]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
pavelvp
iscrafm
а ты наверное, несохраненным вовремя журналом?
Сам то понял, что сказал?

я понял, а ты? Судя по всему нет.
15 дек 06, 10:26    [3540074]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11553
pavelvp
hvlad
Apex
А чем ты будешь свой вчерашний инкрементальный бэкап догонять до момента перед сбоем,чудо в перьях???
Ознакомься с предметом беседы, перед тем как хамить, ораклоид
Мне тоже интересно, действительно - чем?
А кто сказал, что он вчерашний ? На то он и инкрементальный, что делается быстро, и, кстати, может занимать намного меньше места чем журнал. Так шта - делайте хоть каждые 5 мин.
15 дек 06, 10:46    [3540259]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
Gluk (Kazan)
Собственно в отношении IB/FB меня всегда интересовал этот вопрос. Можно ли как-то накатить последний бакап (полный или инкрементальный) непосредственно до момента креша.

нельзя. Соответственно, неподдерживается и PITR. В FB2 можно к этому приблизиться с помощью инкрементального бекапа, но это все равно не идеальное решение. В IB8 сделали WAL, но реальных краш-тестов еще никто не проводил.
15 дек 06, 10:53    [3540315]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11553
Funny_Falcon
Careful write - и база консистентна не только перед сбоем, но и после него!!! Вообще в любой момент времени!!!
А платят за это отсутствие backward index scan и небольшой потерей скорости (по сравнению с Oracle, разумеется)
Ещё раз - backward index scan не имеет никакого отношения к careful write. Мне можешь поверить.
Скорость теряется за счёт не упорядоченной по физическим номерам страниц записи на диск. С логом (последовательно записываемым) этой проблемы нет. Но есть другая - нужно писать в лог намного больше инф-ции, а потом её же (не всю конечно) писать ещё раз в БД

Funny_Falcon
Разница конечно же есть, но она не в сути, а в объёмах. Кому-то выгоднее журнал архивить, кому-то - инкрементный бэкап
Инкрементный бэкап по определению не может быть больше журнала

Funny_Falcon
Правда в Firebird есть mirror database. Но, наверное, это не полная альтернатива.
Не mirror, а shadow - аналог софтверного RAID1

Funny_Falcon
hvlad
PS Обсуждение деталей работы FB здесь офтопик, imho. Есть более правильный форум - велкам туда, если есть желание :)

По-моему этот форум назвается "Сравнение СУБД". Или я ошибаюсь?
Кстати, спасибо за ответы.
Всегда пожалуйста :)

Funny_Falcon
hvlad
3. Нет. Не из-за careful write. А для гарантии безблокировочной работы (речь о блокировках страниц индекса). В принципе более сложный алгоритм уже обсуждён и ждёт того, кто его реализует. Но потребность невелика :)

Знаешь, я тоже это не из пальца высосал, а прочитал в официальной документации Interbase (какую-то ссылку вчера Google выкинул по запросу carefull writes Interbase или careful writer Interbase).
Суть в том, что если pageA ссылается на pageB, то pageB пишется на диск раньше чем pageA. Но чтобы по индексу можно было искать в обоих направлениях, нужен двухсвязный список, т.е. чтобы pageA ссылалась на pageB и pageB ссылалась на pageA. И что тогда писать первым?
Видишь ли, у меня есть источники несколько более надёжные и правильные, чем "официальная документация Interbase" и тем более чем "какую-то ссылку вчера Google выкинул"
В случае, когда страницы имеют ссылки друг на друга, одна из них пишется на диск сразу в момент обнаружения циклической зависимости
15 дек 06, 10:55    [3540332]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11553
Gluk (Kazan)
Плюс в некоторых клонах имеется возможность зеркалировать все изменения на физическую копию базы на другом сервере ?
Нет. Есть shadow - зеркало БД на том же сервере. Это очень старая фича, ей много лет :)
Зеркалирование на другой сервер пока только рассматривается
15 дек 06, 11:06    [3540467]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
hvlad
Gluk (Kazan)
Плюс в некоторых клонах имеется возможность зеркалировать все изменения на физическую копию базы на другом сервере ?
Нет. Есть shadow - зеркало БД на том же сервере. Это очень старая фича, ей много лет :)
Зеркалирование на другой сервер пока только рассматривается


Ага, спасибо, понятно
15 дек 06, 11:14    [3540552]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить