ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / PostgreSQL 8.2: сравнения с Oracle и MS SQL
25 сообщений из 193, страница 6 из 8
  6  все
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34204617
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
Dimitry Sibiryakov
Aron
1. Log Shipping - доставка лога на другой SQL Server (в том числе, и
другой физически сервер)

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

А это-то как связано с журналом?
Posted via ActualForum NNTP Server 1.3
1 - все же не стоит путать репликацию и Log Shipping
2 - встречный вопрос, как Shadow-база связана с версионностью оригинальной?


Имхо, речь шла о надежности одних и других систем, а мы тут еще не упоминали еще кластеры
...
Рейтинг: 0 / 0
15.12.2006, 23:42
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34204661
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
AAronОшибка в том, что базы данных с журналами позволяют:
1. Log Shipping - доставка лога на другой SQL Server (в том числе, и другой физически сервер)
2. Mirroring - зеркалирование баз данных.Оба пункта возможны с испльзованием механизма инкрементного бекапа
...
Рейтинг: 0 / 0
16.12.2006, 01:00
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34204662
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
AAronИмхо, речь шла о надежности одних и других систем, а мы тут еще не упоминали еще кластеры Не вижу связи между кластерами и наличием журнала тр-ций
...
Рейтинг: 0 / 0
16.12.2006, 01:02
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34204778
wellx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wellx
Участник
AAronОшибка в том, что базы данных с журналами позволяют:
1. Log Shipping - доставка лога на другой SQL Server (в том числе, и другой физически сервер)


Лог транзакций, кроме всего прочего ,является общим узким местом всей базы т.к. абсолютно все процессы замыкаются на лог базы, что само приводит к повышенным требованиям к ресурсам сервера.
...
Рейтинг: 0 / 0
16.12.2006, 11:53
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205245
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
В Firebird инкрементальный бекап N+1-го уровня - дельта от N-го уровня. 0-ой уровень - полный бекап

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

wellxчто само приводит к повышенным требованиям к ресурсам сервера
Всего-лишь небольшая нагрузка на диск при регистрации изменений.
Если у тебя серьезная OLTP система - вынеси журнал транзакций на отдельный диск.
...
Рейтинг: 0 / 0
16.12.2006, 21:36
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205363
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
landy В Firebird инкрементальный бекап N+1-го уровня - дельта от N-го уровня. 0-ой уровень - полный бекап

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

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

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

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

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

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

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

landyНо там бывают такие варианты - что из за аварий разъезжаются системные таблицы и реальные данные(по типу потерянных кластеров на дисках).
Приходится за этим следитьДумаю что это, скажем так, особенности реализации, а не недостаток архитектуры :)
...
Рейтинг: 0 / 0
16.12.2006, 23:50
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205465
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Спор перешел в интересную область: "нужны журналы или нет". Из общих соображений, исходя из того что журналы поддерживаются во всех известных мне современных коммерческих СУБД (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. В случае если логи и страницы данных лежат вместе гибкого управления не получается. Вообще, спросите у Джима Старки, почему он считает что последовательные логи - это хорошо.
...
Рейтинг: 0 / 0
17.12.2006, 04:42
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205518
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Хвост тут не причём :) То, что пишется в БД пока делается бекап (не обязательно в "хвост"), попадёт в следующий бекап
Угу - если мы успеем этот бэкап сделать, а если пока делаем текущий бэкап или сразу после него авария - то все, данных нету. И что прикажете делать?
...
Рейтинг: 0 / 0
17.12.2006, 11:39
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205523
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
Метка изменения страницы. Каждый уровень бекапа имеет свою аналогичную метку.

Т е в процессе бэкапа БД лочится чтобы избежать неконсистентности данных при бэкапе(т к у FB и Oracle RDB одни корни, смею предположить что FB блокировочник как и Oracle RDB)?
Поэтому, чем чаще запускаем - тем чаще лочим, а при наличии длинных транзакций вообще тормоза настать должны ИМХО.
...
Рейтинг: 0 / 0
17.12.2006, 11:49
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205528
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
1. В ближайшее время СУБД будут функционировать на SMP машинах. Уже сегодня двухядерныем процессором никого не удивишь. Уже есть в продаже четерехядерные процессоры для десктопов. Производители процессоров столкулись с определенными технологическими проблемами в подъеме тактовой частоты, но пока еще могут уменьшать размер транзистора. Соответственно подъем производительности будет через увеличение числа ядер в процессоре.

Они и сейчас уже многие функционируют, тот же PostgreSQL, не говоря уже о коммерческих БД.
Та же Oracle RDB может работать как на SMP машинах, так и в кластерах.
Тут возникает проблема в синхронизации кэша БД между экземплярами менеджера БД , работающего на разных процессорах. В SMP системах это в определенной степени проще реализовать, т к каждый процессор имеет доступ ко всей памяти. В кластерных системах требуются дополнительные аппаратные средства(обеспечивающие максимальную скорость передачи данных между узлами, желательно напрямую память-память, по типу Memory Channel на Alpha Servers)
...
Рейтинг: 0 / 0
17.12.2006, 12:00
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205559
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
landy Хвост тут не причём :) То, что пишется в БД пока делается бекап (не обязательно в "хвост"), попадёт в следующий бекап
Угу - если мы успеем этот бэкап сделать, а если пока делаем текущий бэкап или сразу после него авария - то все, данных нету. И что прикажете делать?То же, что делают при потере логов тр-ций :)
...
Рейтинг: 0 / 0
17.12.2006, 12:39
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205563
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
landy Метка изменения страницы. Каждый уровень бекапа имеет свою аналогичную метку.

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

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

landyПоэтому, чем чаще запускаем - тем чаще лочим, а при наличии длинных транзакций вообще тормоза настать должны ИМХО.Нет, это не так
...
Рейтинг: 0 / 0
17.12.2006, 12:46
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34205575
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Зл0йСпор перешел в интересную область: "нужны журналы или нет"Я спорю не с нужностью журнала как такового, а с безапелляционными утверждениями что система без журнала не имеет права быть "серьёзной"

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

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

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

Что я хотел этим сказать ? Не сотвори себе кумира - не более того :)
...
Рейтинг: 0 / 0
17.12.2006, 12:58
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34206010
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
То же, что делают при потере логов тр-ций :)
При потере логов у нас есть сама БД с данными, заметьте коректная. Целостность(незавершенные транзакции)
обеспечивают WAL механизмы. В лог идут только закоммиченные транзакции(в общем случае).
Поэтому при потере лога мы теряем только в надежности, если продолжаем работать.
Создаем новый лог - и работаем дальше.
При потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.
Время сброса(чекпоинты) в лог намного короче времени между выполнениями двух последовательных инкрементальных бэкапов. Консистентность обеспечивается WAL механизмами
...
Рейтинг: 0 / 0
17.12.2006, 20:57
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34206818
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
landy То же, что делают при потере логов тр-ций :)
При потере логов у нас есть сама БД с данными, заметьте коректная. Это не обязательно так. Изменённые страницы вполне могут быть записаны в БД до коммита. Наличие журнала позволит разобраться с этими данными при краше сервера. Но мы рассматриваем ситуацию, когда журнала нет.

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

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

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

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

landyВремя сброса(чекпоинты) в лог намного короче времени между выполнениями двух последовательных инкрементальных бэкаповНе факт. Но даже если и факт - что это даёт ? Короткий интервал между чекпойнтами никак не сократит время жизни тр-ции, скорее наоборот :)
...
Рейтинг: 0 / 0
18.12.2006, 11:51
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34206900
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
hvlad landyПри потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.Чем это отличается от восстановления до последнего инкрементного бекапа ? :)


А что, есть возможность снимать инкрементный бакап после КАЖДОЙ закомиченной транзакции ?
...
Рейтинг: 0 / 0
18.12.2006, 12:11
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34207080
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Gluk (Kazan) hvlad landyПри потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.Чем это отличается от восстановления до последнего инкрементного бекапа ? :)


А что, есть возможность снимать инкрементный бакап после КАЖДОЙ закомиченной транзакции ?Речь шла о потере он-лайнового (не сархивированного) журнала.
...
Рейтинг: 0 / 0
18.12.2006, 12:54
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34207216
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
hvlad Gluk (Kazan) hvlad landyПри потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.Чем это отличается от восстановления до последнего инкрементного бекапа ? :)


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

1. OnLine журналы можно зеркалировать софтверно или аппаратно
2. Если склероз не изменяет в 9-ке можно потребовать чтобы commit не возвращал управление пока изменения не будут сохранены в REDO STANDBY-я (в ущерб производительности разумеется)
...
Рейтинг: 0 / 0
18.12.2006, 13:21
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34207244
wellx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wellx
Участник
Teilnehmer wellxабсолютно все процессы замыкаются на лог базы
Никак нет. Не абсолютно все и не замыкаются . Только процесс изменения данных. В чтении не участвует.

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

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

З.Ы. Просветите немного, но я считал Оракл более версионником нежели блокировочником, да и блокировки тоже у оракла не те что и Sybase, MS SQL. Или я где-то кардинально не прав?
...
Рейтинг: 0 / 0
18.12.2006, 13:27
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34207268
AAron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
AAron
Участник
wellx Teilnehmer wellxабсолютно все процессы замыкаются на лог базы
Никак нет. Не абсолютно все и не замыкаются . Только процесс изменения данных. В чтении не участвует.

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

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

З.Ы. Просветите немного, но я считал Оракл более версионником нежели блокировочником, да и блокировки тоже у оракла не те что и Sybase, MS SQL. Или я где-то кардинально не прав?
да где Вы видите узкое место при последовательной записи в лог? сколько вы МБ/с собираетесь писать? 10? 20? 200? Если OLTP база меняет махом в разных сессиях по 200 МБ данных (условно, конечно), то за это надо голову отрывать разработчикам.
...
Рейтинг: 0 / 0
18.12.2006, 13:32
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34207367
landy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
landy
Участник
В лог идут все операции, независимо от коммита и часто гораздо раньше, чем он произойдёт

Ну это смотря в какой БД. К примеру в Oracle RDB туда идут только закоммиченные транзакции(суть - только измененные данные). Смысла писать туда rollback транзакции небольшой.
Для отката БД в консистентное состояние используются WAL механизмы(в Oracle RDB - RUJ , recovery unit journal - это отдельный объект, который к журналам не имеет отношения.)
В случае "поломки" диска с журналами, Бд переходит в режим read-only. Отсоединяем журналы и запускаем БД - по RUJ идет откат незакоммиченных транзакций, БД консистентна. Далее как уж сами пожелаете работать. Другое дело, что в Postgres WAL используется как и журнал транзакций.
Oracle RDB - это блокировщик чистой воды, в отличие от Oracle
...
Рейтинг: 0 / 0
18.12.2006, 13:55
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34207559
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Gluk (Kazan) hvlad Gluk (Kazan) hvlad landyПри потере БД - берем бэкап и накатываем до последней закоммиченной транзакции.Чем это отличается от восстановления до последнего инкрементного бекапа ? :)


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

1. OnLine журналы можно зеркалировать софтверно или аппаратно
2. Если склероз не изменяет в 9-ке можно потребовать чтобы commit не возвращал управление пока изменения не будут сохранены в REDO STANDBY-я (в ущерб производительности разумеется)1. Мы не говорили о том, как избежать сбоя. Мы говорили о том, что сбой _уже произошёл_
2. Это не означает отсутствие сброса не закомиченных данных в БД. Например, при нехватке буферов для чтения очередной порции данных
...
Рейтинг: 0 / 0
18.12.2006, 14:41
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34207581
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
landy В лог идут все операции, независимо от коммита и часто гораздо раньше, чем он произойдёт

Ну это смотря в какой БД. К примеру в Oracle RDB туда идут только закоммиченные транзакции(суть - только измененные данные). Смысла писать туда rollback транзакции небольшой.
Для отката БД в консистентное состояние используются WAL механизмы(в Oracle RDB - RUJ , recovery unit journal - это отдельный объект, который к журналам не имеет отношения.)
В случае "поломки" диска с журналами, Бд переходит в режим read-only. Отсоединяем журналы и запускаем БД - по RUJ идет откат незакоммиченных транзакций, БД консистентнаЭто всё терминология, какая разница...
Ок, что будет с БД при потере RUJ ?
...
Рейтинг: 0 / 0
18.12.2006, 14:46
| Ответить | Цитировать | Написать  
PostgreSQL 8.2: сравнения с Oracle и MS SQL
    #34207634
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
hvlad2. Это не означает отсутствие сброса не закомиченных данных в БД. Например, при нехватке буферов для чтения очередной порции данных

Именно поэтому при восстановлении после креша за накатом всегда следует откат всего незакоммиченного по уже восстановленному UNDO
...
Рейтинг: 0 / 0
18.12.2006, 15:04
| Ответить | Цитировать | Написать  
25 сообщений из 193, страница 6 из 8
  6  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / PostgreSQL 8.2: сравнения с Oracle и MS SQL
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=34206010&tid=1552961]:
 0ms
get settings:
 9ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 41ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 63ms
get tp. blocked users:
 1ms
others: 13ms
total:  155ms
созд. / загр.: 155ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]