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

Откуда: Москва
Сообщений: 4324
Dimitry Sibiryakov

Aron

1. Log Shipping - доставка лога на другой SQL Server (в том числе, и
другой физически сервер)

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

2. Mirroring - зеркалирование баз данных.

А это-то как связано с журналом?
Posted via ActualForum NNTP Server 1.3

1 - все же не стоит путать репликацию и Log Shipping
2 - встречный вопрос, как Shadow-база связана с версионностью оригинальной?


Имхо, речь шла о надежности одних и других систем, а мы тут еще не упоминали еще кластеры
15 дек 06, 23:42    [3545047]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
AAron
Ошибка в том, что базы данных с журналами позволяют:
1. Log Shipping - доставка лога на другой SQL Server (в том числе, и другой физически сервер)
2. Mirroring - зеркалирование баз данных.
Оба пункта возможны с испльзованием механизма инкрементного бекапа
16 дек 06, 01:00    [3545230]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
AAron
Имхо, речь шла о надежности одних и других систем, а мы тут еще не упоминали еще кластеры
Не вижу связи между кластерами и наличием журнала тр-ций
16 дек 06, 01:02    [3545233]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
wellx
Member

Откуда:
Сообщений: 70
AAron
Ошибка в том, что базы данных с журналами позволяют:
1. Log Shipping - доставка лога на другой SQL Server (в том числе, и другой физически сервер)


Лог транзакций, кроме всего прочего ,является общим узким местом всей базы т.к. абсолютно все процессы замыкаются на лог базы, что само приводит к повышенным требованиям к ресурсам сервера.
16 дек 06, 11:53    [3545511]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1557
В Firebird инкрементальный бекап N+1-го уровня - дельта от N-го уровня. 0-ой уровень - полный бекап


Т е при инкрементальном бэкапе в FB ставятся метки на страницах что они сбэкаплены(другой вариант - сравниваем временную метку времени изменения страницы с временем последнего инк бэкапа), либо сравниваются страницы с предыдущего инкрементального бэкапа и БД, для того чтобы решить - нужно ли бэкапить данные?
Но тогда чем чаще делаем, тем медленне все работает. Либо падает надежность - если время между бэкапами велико, а нагрузка на БД(изменения) высокая - теряем данные в случае аварии.
Опять же - чем больше БД, тем дольше время для просмотра и решения что бэкапить в инкрементальном бэкапе. Опять же - при большой нагрузке на БД , то что пишется в хвост не успеем забэкапить(за период принятия решения бэкапить/не бэкапить - пока всю БД просмотрим, изменения по БД могут быть велики). И откуда их брать?
Хотя для ускорения этого процесса возможно использование битовых масок измененных страниц в системных таблицах. Наверное это так и есть(видел как то FB - внутренняя организация очень похожа на Oracle RDB, знакомые RDB$SYSTEM, RDB$RELATIONS и т д) Но там бывают такие варианты - что из за аварий разъезжаются системные таблицы и реальные данные(по типу потерянных кластеров на дисках).
Приходится за этим следить
16 дек 06, 21:30    [3546287]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Teilnehmer
Guest
wellx
абсолютно все процессы замыкаются на лог базы

Никак нет. Не абсолютно все и не замыкаются . Только процесс изменения данных. В чтении не участвует.

wellx
что само приводит к повышенным требованиям к ресурсам сервера

Всего-лишь небольшая нагрузка на диск при регистрации изменений.
Если у тебя серьезная OLTP система - вынеси журнал транзакций на отдельный диск.
16 дек 06, 21:36    [3546295]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
landy
В Firebird инкрементальный бекап N+1-го уровня - дельта от N-го уровня. 0-ой уровень - полный бекап


Т е при инкрементальном бэкапе в FB ставятся метки на страницах что они сбэкаплены(другой вариант - сравниваем временную метку времени изменения страницы с временем последнего инк бэкапа), либо сравниваются страницы с предыдущего инкрементального бэкапа и БД, для того чтобы решить - нужно ли бэкапить данные?
Метка изменения страницы. Каждый уровень бекапа имеет свою аналогичную метку.

landy
Но тогда чем чаще делаем, тем медленне все работает
Почему ?

landy
Либо падает надежность - если время между бэкапами велико, а нагрузка на БД(изменения) высокая - теряем данные в случае аварии
Бекапы и нужны для защиты от аварий, не так ли ? :)

landy
Опять же - чем больше БД, тем дольше время для просмотра и решения что бэкапить в инкрементальном бэкапе
В текущей реализации - да

landy
Опять же - при большой нагрузке на БД , то что пишется в хвост не успеем забэкапить(за период принятия решения бэкапить/не бэкапить - пока всю БД просмотрим, изменения по БД могут быть велики). И откуда их брать?
Хвост тут не причём :) То, что пишется в БД пока делается бекап (не обязательно в "хвост"), попадёт в следующий бекап

landy
Хотя для ускорения этого процесса возможно использование битовых масок измененных страниц в системных таблицах. Наверное это так и есть
Нет, пока это не реализовано, хотя и исследуется такая возможность.
MSSQL, например, так и делает, но у них нет мультиуровневого инкрементального бекапа. Т.е. их инкрементальный бекап всегда содержит разницу от последнего полного.

landy
(видел как то FB - внутренняя организация очень похожа на Oracle RDB, знакомые RDB$SYSTEM, RDB$RELATIONS и т д)
Дык :) Общие корни однако

landy
Но там бывают такие варианты - что из за аварий разъезжаются системные таблицы и реальные данные(по типу потерянных кластеров на дисках).
Приходится за этим следить
Думаю что это, скажем так, особенности реализации, а не недостаток архитектуры :)
16 дек 06, 23:50    [3546558]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Спор перешел в интересную область: "нужны журналы или нет". Из общих соображений, исходя из того что журналы поддерживаются во всех известных мне современных коммерческих СУБД (Oracle, обе DB2 - unix/windows и z/OS, Informix, Sybase, Teradata, Tandem, ...), мне кажется что преимущества журналов перевешивают недостатки. В разработке коммерческих СУБД участвовали неглупые люди, такие как Джим Грей, Фил Бернштнейн. Наверное были серьезные причины выбрать лог.

Предлагаю сделать следующие допущения:

1. В ближайшее время СУБД будут функционировать на SMP машинах. Уже сегодня двухядерныем процессором никого не удивишь. Уже есть в продаже четерехядерные процессоры для десктопов. Производители процессоров столкулись с определенными технологическими проблемами в подъеме тактовой частоты, но пока еще могут уменьшать размер транзистора. Соответственно подъем производительности будет через увеличение числа ядер в процессоре.

2. Объемы данных для более-менее серьезных задач таковы, что для хранения используются дисковые массивы, причем возможно их несколько. Обсуждать достоинства и недостатки реализации применительно к десктопной конфигурации ИМХО особого смысла не имеет.

3. Предприятие предъявляет достаточно жесткие требования в к восстановимости данных в случаях
- отказа сервера
- отказа одного дискового массива "целиком и полностью"
- отказа одного или нескольких дисков в дисковом массиве

Предлагаю рассмотреть такую встреченную мною "засаду":
Данные лежат на дисковом массиве, конфигурация RAID 0+1, приходит производитель и приносит firmware upgrade, убедительно просит его поставить во избежание неприятных последствий вроде потери данных. Ставим firmware upgrade, после чего у нас рассинхронизируются зекрала, контрольные суммы в блоках не совпадают, в общем - полный "абзац". Несмотря на весь наш RAID данные потеряны.

К счастью у лога есть одно немаловажное достоинство - они пишутся последовательно. Соответственно все что было записано до firmware upgrade оказалось цело. Кстати у грамотных DBA логи неспеша пишутся на ленту, как раз на случай "засады" подобного рода. То есть последовательность лога и то что он отделен от остальных данных спасает ситуацию. В случае же если отдельного последовательного лога нет, версии хранятся в блоках данных, потеряли RAID - потеряли базу. Восстанавливаемся с крайнего бэкапа. Данные после оного потеряны.

Вообще, когда лог пишется отдельно от страниц данных, это позволяет гибко им управлять. Например я могу бюджетно страницы данных положить на RAID 0, а логи на RAID 0+1 или RAID1. В случае если логи и страницы данных лежат вместе гибкого управления не получается. Вообще, спросите у Джима Старки, почему он считает что последовательные логи - это хорошо.
17 дек 06, 04:42    [3546829]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1557
Хвост тут не причём :) То, что пишется в БД пока делается бекап (не обязательно в "хвост"), попадёт в следующий бекап

Угу - если мы успеем этот бэкап сделать, а если пока делаем текущий бэкап или сразу после него авария - то все, данных нету. И что прикажете делать?
17 дек 06, 11:39    [3546952]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1557
Метка изменения страницы. Каждый уровень бекапа имеет свою аналогичную метку.


Т е в процессе бэкапа БД лочится чтобы избежать неконсистентности данных при бэкапе(т к у FB и Oracle RDB одни корни, смею предположить что FB блокировочник как и Oracle RDB)?
Поэтому, чем чаще запускаем - тем чаще лочим, а при наличии длинных транзакций вообще тормоза настать должны ИМХО.
17 дек 06, 11:49    [3546960]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1557
1. В ближайшее время СУБД будут функционировать на SMP машинах. Уже сегодня двухядерныем процессором никого не удивишь. Уже есть в продаже четерехядерные процессоры для десктопов. Производители процессоров столкулись с определенными технологическими проблемами в подъеме тактовой частоты, но пока еще могут уменьшать размер транзистора. Соответственно подъем производительности будет через увеличение числа ядер в процессоре.

Они и сейчас уже многие функционируют, тот же PostgreSQL, не говоря уже о коммерческих БД.
Та же Oracle RDB может работать как на SMP машинах, так и в кластерах.
Тут возникает проблема в синхронизации кэша БД между экземплярами менеджера БД , работающего на разных процессорах. В SMP системах это в определенной степени проще реализовать, т к каждый процессор имеет доступ ко всей памяти. В кластерных системах требуются дополнительные аппаратные средства(обеспечивающие максимальную скорость передачи данных между узлами, желательно напрямую память-память, по типу Memory Channel на Alpha Servers)
17 дек 06, 12:00    [3546966]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
landy
Хвост тут не причём :) То, что пишется в БД пока делается бекап (не обязательно в "хвост"), попадёт в следующий бекап

Угу - если мы успеем этот бэкап сделать, а если пока делаем текущий бэкап или сразу после него авария - то все, данных нету. И что прикажете делать?
То же, что делают при потере логов тр-ций :)
17 дек 06, 12:39    [3547009]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
landy
Метка изменения страницы. Каждый уровень бекапа имеет свою аналогичную метку.


Т е в процессе бэкапа БД лочится чтобы избежать неконсистентности данных при бэкапе
Не совсем так. Файл БД лочится, но при этом создаётся difference файл, в который перенаправляется write и часть read. Пока файл БД залочен его можно даже копировать обычным способом. После того, как инкрементный бекап создан, изменения из difference файла сливаются в основной файл БД. Процесс устойчив к сбоям, т.е. может быть продолжен после рестарта сервера

landy
(т к у FB и Oracle RDB одни корни, смею предположить что FB блокировочник как и Oracle RDB)?
Нет. FB - версионник (чистейшей воды :) )

landy
Поэтому, чем чаще запускаем - тем чаще лочим, а при наличии длинных транзакций вообще тормоза настать должны ИМХО.
Нет, это не так
17 дек 06, 12:46    [3547014]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
Зл0й
Спор перешел в интересную область: "нужны журналы или нет"
Я спорю не с нужностью журнала как такового, а с безапелляционными утверждениями что система без журнала не имеет права быть "серьёзной"

Зл0й
Из общих соображений, исходя из того что журналы поддерживаются во всех известных мне современных коммерческих СУБД (Oracle, обе DB2 - unix/windows и z/OS, Informix, Sybase, Teradata, Tandem, ...), мне кажется что преимущества журналов перевешивают недостатки. В разработке коммерческих СУБД участвовали неглупые люди, такие как Джим Грей, Фил Бернштнейн. Наверное были серьезные причины выбрать лог
Не бывает универсальных решений, пригодных во всех случаях. А насчёт неглупых людей... см. ниже :)

Зл0й
То есть последовательность лога и то что он отделен от остальных данных спасает ситуацию. В случае же если отдельного последовательного лога нет, версии хранятся в блоках данных, потеряли RAID - потеряли базу. Восстанавливаемся с крайнего бэкапа. Данные после оного потеряны.
Сохраняйте инкрементальные бекапы, а не логи, и восстанавливайтесь с них. Хватит по кругу ходить

Зл0й
Вообще, когда лог пишется отдельно от страниц данных, это позволяет гибко им управлять. Например я могу бюджетно страницы данных положить на RAID 0, а логи на RAID 0+1 или RAID1. В случае если логи и страницы данных лежат вместе гибкого управления не получается. Вообще, спросите у Джима Старки, почему он считает что последовательные логи - это хорошо.
Вы же не включили Джима в список "неглупых людей" выше - а ссылаетесь на него :) Причём по памяти, т.е. не точно. Или давайте точную цитату, или не давайте вообще. Особенно когда дело касается самого Джима Старки. Который кстати, ненавидит администрирование и категорически против введения, например, партиционирования таблиц. Ибо этим должны управлять железки, по его Великому мнению :)

Что я хотел этим сказать ? Не сотвори себе кумира - не более того :)
17 дек 06, 12:58    [3547030]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1557
То же, что делают при потере логов тр-ций :)

При потере логов у нас есть сама БД с данными, заметьте коректная. Целостность(незавершенные транзакции)
обеспечивают WAL механизмы. В лог идут только закоммиченные транзакции(в общем случае).
Поэтому при потере лога мы теряем только в надежности, если продолжаем работать.
Создаем новый лог - и работаем дальше.
При потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.
Время сброса(чекпоинты) в лог намного короче времени между выполнениями двух последовательных инкрементальных бэкапов. Консистентность обеспечивается WAL механизмами
17 дек 06, 20:57    [3547623]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
landy
То же, что делают при потере логов тр-ций :)

При потере логов у нас есть сама БД с данными, заметьте коректная.
Это не обязательно так. Изменённые страницы вполне могут быть записаны в БД до коммита. Наличие журнала позволит разобраться с этими данными при краше сервера. Но мы рассматриваем ситуацию, когда журнала нет.

Вот пример1 (обратим внимание на REPAIR_ALLOW_DATA_LOSS на 9-ом шаге)

landy
Целостность(незавершенные транзакции)
обеспечивают WAL механизмы. В лог идут только закоммиченные транзакции(в общем случае)
В лог идут все операции, независимо от коммита и часто гораздо раньше, чем он произойдёт

landy
Поэтому при потере лога мы теряем только в надежности, если продолжаем работать.
Создаем новый лог - и работаем дальше.
Увы нет :)

landy
При потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.
Чем это отличается от восстановления до последнего инкрементного бекапа ? :)

landy
Время сброса(чекпоинты) в лог намного короче времени между выполнениями двух последовательных инкрементальных бэкапов
Не факт. Но даже если и факт - что это даёт ? Короткий интервал между чекпойнтами никак не сократит время жизни тр-ции, скорее наоборот :)
18 дек 06, 11:51    [3549069]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
hvlad
landy
При потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.
Чем это отличается от восстановления до последнего инкрементного бекапа ? :)


А что, есть возможность снимать инкрементный бакап после КАЖДОЙ закомиченной транзакции ?
18 дек 06, 12:11    [3549214]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
Gluk (Kazan)
hvlad
landy
При потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.
Чем это отличается от восстановления до последнего инкрементного бекапа ? :)


А что, есть возможность снимать инкрементный бакап после КАЖДОЙ закомиченной транзакции ?
Речь шла о потере он-лайнового (не сархивированного) журнала.
18 дек 06, 12:54    [3549526]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
hvlad
Gluk (Kazan)
hvlad
landy
При потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.
Чем это отличается от восстановления до последнего инкрементного бекапа ? :)


А что, есть возможность снимать инкрементный бакап после КАЖДОЙ закомиченной транзакции ?
Речь шла о потере он-лайнового (не сархивированного) журнала.


1. OnLine журналы можно зеркалировать софтверно или аппаратно
2. Если склероз не изменяет в 9-ке можно потребовать чтобы commit не возвращал управление пока изменения не будут сохранены в REDO STANDBY-я (в ущерб производительности разумеется)
18 дек 06, 13:21    [3549753]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
wellx
Member

Откуда:
Сообщений: 70
Teilnehmer
wellx
абсолютно все процессы замыкаются на лог базы

Никак нет. Не абсолютно все и не замыкаются . Только процесс изменения данных. В чтении не участвует.

wellx
что само приводит к повышенным требованиям к ресурсам сервера

Всего-лишь небольшая нагрузка на диск при регистрации изменений.
Если у тебя серьезная OLTP система - вынеси журнал транзакций на отдельный диск.


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

З.Ы. Просветите немного, но я считал Оракл более версионником нежели блокировочником, да и блокировки тоже у оракла не те что и Sybase, MS SQL. Или я где-то кардинально не прав?
18 дек 06, 13:27    [3549799]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
wellx
Teilnehmer
wellx
абсолютно все процессы замыкаются на лог базы

Никак нет. Не абсолютно все и не замыкаются . Только процесс изменения данных. В чтении не участвует.

wellx
что само приводит к повышенным требованиям к ресурсам сервера

Всего-лишь небольшая нагрузка на диск при регистрации изменений.
Если у тебя серьезная OLTP система - вынеси журнал транзакций на отдельный диск.


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

З.Ы. Просветите немного, но я считал Оракл более версионником нежели блокировочником, да и блокировки тоже у оракла не те что и Sybase, MS SQL. Или я где-то кардинально не прав?

да где Вы видите узкое место при последовательной записи в лог? сколько вы МБ/с собираетесь писать? 10? 20? 200? Если OLTP база меняет махом в разных сессиях по 200 МБ данных (условно, конечно), то за это надо голову отрывать разработчикам.
18 дек 06, 13:32    [3549847]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1557
В лог идут все операции, независимо от коммита и часто гораздо раньше, чем он произойдёт

Ну это смотря в какой БД. К примеру в Oracle RDB туда идут только закоммиченные транзакции(суть - только измененные данные). Смысла писать туда rollback транзакции небольшой.
Для отката БД в консистентное состояние используются WAL механизмы(в Oracle RDB - RUJ , recovery unit journal - это отдельный объект, который к журналам не имеет отношения.)
В случае "поломки" диска с журналами, Бд переходит в режим read-only. Отсоединяем журналы и запускаем БД - по RUJ идет откат незакоммиченных транзакций, БД консистентна. Далее как уж сами пожелаете работать. Другое дело, что в Postgres WAL используется как и журнал транзакций.
Oracle RDB - это блокировщик чистой воды, в отличие от Oracle
18 дек 06, 13:55    [3550038]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
Gluk (Kazan)
hvlad
Gluk (Kazan)
hvlad
landy
При потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.
Чем это отличается от восстановления до последнего инкрементного бекапа ? :)


А что, есть возможность снимать инкрементный бакап после КАЖДОЙ закомиченной транзакции ?
Речь шла о потере он-лайнового (не сархивированного) журнала.


1. OnLine журналы можно зеркалировать софтверно или аппаратно
2. Если склероз не изменяет в 9-ке можно потребовать чтобы commit не возвращал управление пока изменения не будут сохранены в REDO STANDBY-я (в ущерб производительности разумеется)
1. Мы не говорили о том, как избежать сбоя. Мы говорили о том, что сбой _уже произошёл_
2. Это не означает отсутствие сброса не закомиченных данных в БД. Например, при нехватке буферов для чтения очередной порции данных
18 дек 06, 14:41    [3550376]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11554
landy
В лог идут все операции, независимо от коммита и часто гораздо раньше, чем он произойдёт

Ну это смотря в какой БД. К примеру в Oracle RDB туда идут только закоммиченные транзакции(суть - только измененные данные). Смысла писать туда rollback транзакции небольшой.
Для отката БД в консистентное состояние используются WAL механизмы(в Oracle RDB - RUJ , recovery unit journal - это отдельный объект, который к журналам не имеет отношения.)
В случае "поломки" диска с журналами, Бд переходит в режим read-only. Отсоединяем журналы и запускаем БД - по RUJ идет откат незакоммиченных транзакций, БД консистентна
Это всё терминология, какая разница...
Ок, что будет с БД при потере RUJ ?
18 дек 06, 14:46    [3550416]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
hvlad
2. Это не означает отсутствие сброса не закомиченных данных в БД. Например, при нехватке буферов для чтения очередной порции данных


Именно поэтому при восстановлении после креша за накатом всегда следует откат всего незакоммиченного по уже восстановленному UNDO
18 дек 06, 15:04    [3550521]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 5 [6] 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить