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

Откуда: Made in USSR
Сообщений: 3910
2 hvlad
Приношу извинения, часть диалога, действительно, не прочел.

hvlad
pavelvp
hvlad
Apex
А чем ты будешь свой вчерашний инкрементальный бэкап догонять до момента перед сбоем,чудо в перьях???
Ознакомься с предметом беседы, перед тем как хамить, ораклоид
Мне тоже интересно, действительно - чем?
А кто сказал, что он вчерашний ? На то он и инкрементальный, что делается быстро, и, кстати, может занимать намного меньше места чем журнал. Так шта - делайте хоть каждые 5 мин.

Если делать инкрементальный бэкап очень часто - то по сути это будет имитация журнала транзакций, но с худшей реализацией. Смысла в ней я не вижу.
hvlad

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

Есть страница, содержащая данные как-то таблицы, меняем одну строку, говорим commit - что уходит на диск? Мне кажется что целиком вся страница. Поправьте если не так.
15 дек 06, 12:00    [3541027]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Apex
hvlad
А кто сказал, что он вчерашний ? На то он и инкрементальный, что делается быстро, и, кстати, может занимать намного меньше места чем журнал. Так шта - делайте хоть каждые 5 мин.

Если делать инкрементальный бэкап очень часто - то по сути это будет имитация журнала транзакций, но с худшей реализацией. Смысла в ней я не вижу.
а) Это ни в коем случае не будет имитацией журнала тр-ций. Слишком разные процессы
б) С отсутствием жизненной необходимости журнала тр-ций мы уже смирились, не так ли ? :)
в) Реализация не обязана быть худшей

Apex
hvlad

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

Есть страница, содержащая данные как-то таблицы, меняем одну строку, говорим commit - что уходит на диск? Мне кажется что целиком вся страница. Поправьте если не так.
Конечно.
А что пойдёт в журнал тр-ций ? Даже если только изменённые данные + данные до изменения (а не старая + новая страницы), то что пойдёт в журнал при изменении 10 записей на странице в 10 разных апдейтах в однй тр-ции ?
15 дек 06, 12:55    [3541460]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
hvlad

б) С отсутствием жизненной необходимости журнала тр-ций мы уже смирились, не так ли ? :)

Не так. Про жизненную необходимость я и не говорил, я говорил про возможности восстановления. Если у тебя полетит один из дисков - т.е. только часть БД, то все что ты поимеешь - базу по состоянию, пусть даже 5 минут назад (последний инкрементальный бэкап). В случае с журналом я поимею ее вплоть до последней зафиксированной транзации перед сбоем. Разница есть.
hvlad
Конечно.

ОК. Давай рассуждать дальше. Итак, имеем 10 измененных строк в 10 разных страницах. Перед commit без журнала надо сбросить на диск все 10. Так? С журналом надо сбросить только одну страницу, содежращую записи обо всех изменения+некую доп. информацию - что в совокупности ненамного больше самой изменившейся информации, но гораздо меньше 10 страниц данных.
Идем дальше. Разумеется даже с журналом, наши 10 грязных страниц надо рано или поздно сбросить на диск, и разумеется тут мы проигрываем, т.к. надо сбросить 10 грязных страниц+страницу журнала, вместо просто 10 грязных страниц. Это когда транзакция одна. Теперь рассмотрим случай когда транзакций много. 10 транзакций последовательно меняют 10 строк в 10 разных страницах. Итого на диск уходит 100 страниц (уходят эти же 10, но каждая по 10 раз). С журналом уходит 10 старниц журнала с измененными данными + 10 страниц грязных данных. Поправь меня, если я где-то допустил ошибку.
15 дек 06, 13:33    [3541852]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
iscrafm
pavelvp
iscrafm
а ты наверное, несохраненным вовремя журналом?
Сам то понял, что сказал?
я понял, а ты? Судя по всему нет.
Я это делал :-) Журнал сохранён всегда! На то он и журнал.
15 дек 06, 13:49    [3542001]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
pavelvp
Я это делал :-) Журнал сохранён всегда! На то он и журнал.

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

Откуда:
Сообщений: 673
iscrafm
т.е. Вы backup логов не делаете?
тынц
15 дек 06, 14:06    [3542136]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
iscrafm
pavelvp
Я это делал :-) Журнал сохранён всегда! На то он и журнал.

т.е. Вы backup логов не делаете?


STANDBY
15 дек 06, 14:10    [3542174]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
Gluk (Kazan)

STANDBY

с этим то как раз понятно, это горячее резервирование, зеркало. Вопрос только был вроде в том, что если БД накрылась, и архива логов нет (standby и ли вручную), то база востанавливается по журналу на момент слета. А с наличием архива конечно все понятно, можно не разжевывать :)
15 дек 06, 14:51    [3542511]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
pavelvp
Member

Откуда:
Сообщений: 673
iscrafm
Вопрос только был вроде в том, что если БД накрылась, и архива логов нет (standby и ли вручную), то база востанавливается по журналу на момент слета. А с наличием архива конечно все понятно, можно не разжевывать :)
Ну а если ещё и сервер уничтожен направленным взрывом, то так и вообще капец :-)
15 дек 06, 14:56    [3542545]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
pavelvp
iscrafm
Вопрос только был вроде в том, что если БД накрылась, и архива логов нет (standby и ли вручную), то база востанавливается по журналу на момент слета. А с наличием архива конечно все понятно, можно не разжевывать :)
Ну а если ещё и сервер уничтожен направленным взрывом, то так и вообще капец :-)

можно не язвить, а почитать о чем говорил человек, к которому это все обращено было изначально. :) Тонкости всегда в деталях...
15 дек 06, 15:00    [3542571]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Apex
hvlad

б) С отсутствием жизненной необходимости журнала тр-ций мы уже смирились, не так ли ? :)

Не так. Про жизненную необходимость я и не говорил, я говорил про возможности восстановления. Если у тебя полетит один из дисков - т.е. только часть БД, то все что ты поимеешь - базу по состоянию, пусть даже 5 минут назад (последний инкрементальный бэкап). В случае с журналом я поимею ее вплоть до последней зафиксированной транзации перед сбоем. Разница есть.
Я спорил не с наличием разницы. А с утверждением о несерьёзности систем без явных журналов. Shadow позволяет иметь не меньшую степень надёжности

Apex
ОК. Давай рассуждать дальше. Итак, имеем 10 измененных строк в 10 разных страницах. Перед commit без журнала надо сбросить на диск все 10. Так? С журналом надо сбросить только одну страницу, содежращую записи обо всех изменения+некую доп. информацию - что в совокупности ненамного больше самой изменившейся информации, но гораздо меньше 10 страниц данных
Не совсем так. В журнал однозначно нужно записывать как старые данные, так и новые. Это минимум в 2 раза больше объёма изменённых данных

Apex
Идем дальше. Разумеется даже с журналом, наши 10 грязных страниц надо рано или поздно сбросить на диск, и разумеется тут мы проигрываем, т.к. надо сбросить 10 грязных страниц+страницу журнала, вместо просто 10 грязных страниц. Это когда транзакция одна. Теперь рассмотрим случай когда транзакций много. 10 транзакций последовательно меняют 10 строк в 10 разных страницах. Итого на диск уходит 100 страниц (уходят эти же 10, но каждая по 10 раз)
Да. Но это только если эти тр-ции работают строго последовательно. Т.е. тр-ция2 не трогает страницу, изменённую тр-цией1 пока тр-ция1 не закоммитится. А это характерно только для невысокой нагрузки.

Apex
С журналом уходит 10 старниц журнала с измененными данными + 10 страниц грязных данных. Поправь меня, если я где-то допустил ошибку.
В журнал таки пойдёт несколько больше 10-и страниц. А именно - не менее 210 "записей" (100 о старых данных, 100 о новых, 10 о коммитах). Но не в этом суть...

О чём спорим ?
а) о призводительности
б) о надёжности
в) о сравнительном объёме журнала и инкрементного бекапа
г) о "серьёзности" (не знаю что это такое)
?
15 дек 06, 15:08    [3542639]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Apex забанен
Guest
hvlad

Shadow позволяет иметь не меньшую степень надёжности

При бОльших требованиях к аппаратному обеспечению (обеспечить журнализацию проще, чем работу еще одного сервера).
hvlad

Apex
ОК. Давай рассуждать дальше. Итак, имеем 10 измененных строк в 10 разных страницах. Перед commit без журнала надо сбросить на диск все 10. Так? С журналом надо сбросить только одну страницу, содежращую записи обо всех изменения+некую доп. информацию - что в совокупности ненамного больше самой изменившейся информации, но гораздо меньше 10 страниц данных
Не совсем так. В журнал однозначно нужно записывать как старые данные, так и новые. Это минимум в 2 раза больше объёма изменённых данных

Верное уточнение, я это подразумевал, но явно не упомянул. Однако уточню и я: в 2 раза больше, только если имеем развнозначный update. Для insert или delete имеем почти тот же объем, что и объем новых/старых данных.
hvlad

Apex
Идем дальше. Разумеется даже с журналом, наши 10 грязных страниц надо рано или поздно сбросить на диск, и разумеется тут мы проигрываем, т.к. надо сбросить 10 грязных страниц+страницу журнала, вместо просто 10 грязных страниц. Это когда транзакция одна. Теперь рассмотрим случай когда транзакций много. 10 транзакций последовательно меняют 10 строк в 10 разных страницах. Итого на диск уходит 100 страниц (уходят эти же 10, но каждая по 10 раз)
Да. Но это только если эти тр-ции работают строго последовательно. Т.е. тр-ция2 не трогает страницу, изменённую тр-цией1 пока тр-ция1 не закоммитится. А это характерно только для невысокой нагрузки.

А если все-таки трогает, до того как первая закомитилась? Т1 внесла изменения в страницу А, Т2 внесла изменения в А, Т1 сказала commit - страница пошла на диск(?), Т2 сказала commit - что тогда? Страница опять пошла на диск или проверила, что она уже была сброшена на диск после чего Т2 в нее не вносла изменений и повторно можно не сбрасывать?
hvlad

Но не в этом суть...

О чём спорим ?
а) о призводительности
б) о надёжности
в) о сравнительном объёме журнала и инкрементного бекапа
г) о "серьёзности" (не знаю что это такое)
?

Я считаю, что СУБД с журналом транзакций имееют приимущество по совокупности пунктов а и б, перед СУБД не имеющими таковой.
15 дек 06, 15:57    [3543067]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Apex забанен
hvlad

Shadow позволяет иметь не меньшую степень надёжности

При бОльших требованиях к аппаратному обеспечению (обеспечить журнализацию проще, чем работу еще одного сервера).
Нет. Читайте внимательнее - я уже говорил, что shadow располагается на том же сервере. Это страничная копия файла БД

Apex забанен
hvlad
Apex
Идем дальше. Разумеется даже с журналом, наши 10 грязных страниц надо рано или поздно сбросить на диск, и разумеется тут мы проигрываем, т.к. надо сбросить 10 грязных страниц+страницу журнала, вместо просто 10 грязных страниц. Это когда транзакция одна. Теперь рассмотрим случай когда транзакций много. 10 транзакций последовательно меняют 10 строк в 10 разных страницах. Итого на диск уходит 100 страниц (уходят эти же 10, но каждая по 10 раз)
Да. Но это только если эти тр-ции работают строго последовательно. Т.е. тр-ция2 не трогает страницу, изменённую тр-цией1 пока тр-ция1 не закоммитится. А это характерно только для невысокой нагрузки.

А если все-таки трогает, до того как первая закомитилась? Т1 внесла изменения в страницу А, Т2 внесла изменения в А, Т1 сказала commit - страница пошла на диск(?), Т2 сказала commit - что тогда? Страница опять пошла на диск или проверила, что она уже была сброшена на диск после чего Т2 в нее не вносла изменений и повторно можно не сбрасывать?
Грязная страница, будучи сброшенной на диск, перестаёт быть грязной :) Конечно она будет записана только 1 раз

Apex забанен
hvlad

Но не в этом суть...

О чём спорим ?
а) о призводительности
б) о надёжности
в) о сравнительном объёме журнала и инкрементного бекапа
г) о "серьёзности" (не знаю что это такое)
?

Я считаю, что СУБД с журналом транзакций имееют приимущество по совокупности пунктов а и б, перед СУБД не имеющими таковой.
Считать что угодно и как угодно - ваше право. Истина от этого не зависит

PS А чего забанен-то ? Али я пропустил самое интересное ?
15 дек 06, 16:18    [3543271]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1550
hvlad
Не совсем так. В журнал однозначно нужно записывать как старые данные, так и новые. Это минимум в 2 раза больше объёма изменённых данных

Не совсем понятно - зачем? В журнал пишутся только новые закоммиченные данные
Накат журнала - это взять бэкап(со старыми данными) и последовательно провести изменения по журналу на новые данные.
Сделав n-1 таких операций - будем иметь "старые данные"
15 дек 06, 16:42    [3543498]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
landy
hvlad
Не совсем так. В журнал однозначно нужно записывать как старые данные, так и новые. Это минимум в 2 раза больше объёма изменённых данных

Не совсем понятно - зачем? В журнал пишутся только новые закоммиченные данные
Накат журнала - это взять бэкап(со старыми данными) и последовательно провести изменения по журналу на новые данные.
Сделав n-1 таких операций - будем иметь "старые данные"
Затем, что журнал позволяет не только накат закоммиченного, но и откат не закоммиченного.
15 дек 06, 16:48    [3543558]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
landy
В журнал пишутся только новые закоммиченные данные

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

Откуда:
Сообщений: 1550
Затем, что журнал позволяет не только накат закоммиченного, но и откат не закоммиченного.


Для отката используется обычно WAL механизм, при этом не обязательно писать эти данные в журнал(в общем случае) транзакций, для этого использовать WAL файл, который содержит данные только между чекпоинтами
В журнал обычно пишутся только закоммиченные транзакции.
Хотя в Oracle (и в Oracle RDB кстати) пишуться и старые и новые данные, что позволяет "проиграть" состояние БД в обратную сторону. Но это ИМХО фичи
Просто уточниим - мы обсуждаем конкретную БД или в общем?
15 дек 06, 17:04    [3543693]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7000
landy
мы обсуждаем конкретную БД или в общем?

когда речь заходит о преимуществах чего-то над чем-то, то "в общем" говорить становится затруднительно :-)
15 дек 06, 17:25    [3543882]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1550
Ну насколько я понял - все свалилось к обсуждению вопроса - нужны ли журналы транзакций?
Для меня - пока в Postgres не было механизмов наката по журналам(PITR) я его смотрел, но не рассматривал
как БД для серьезного использвания.
Насчет инкрементальных бэкапов - насколько я понимаю - они должны делаться относительно какой-то точки отсчета(первоначальный бэкап БД). Кроме того(во всяком случае в RDB это так) каждый последующий инкрементальный бэкап содержит все изменения с полного бэкапа(т е он растет). Для восстановления БД нужно накатить последний инкрементальный бэкап на полный бэкап БД.
В других БД это так же я думаю(т е как выполняя последующие инкрементальные бжкапы мы можем узнать что забэкапили на предыдущем, т е точка отсчета все равно полный бэкап)?
15 дек 06, 17:39    [3544024]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Apex забанен
Guest
hvlad
Это страничная копия файла БД

Я вообще понял, что они на одной машине, просто думал, что там второй сервер (SQL-сервер) БД поднимать надо.

hvlad
Считать что угодно и как угодно - ваше право. Истина от этого не зависит

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

hvlad
PS А чего забанен-то ? Али я пропустил самое интересное ?

Нежная психика модератора не пережила моего хамского поста:)
P.S. заметьте, я не обижаюсь:)
15 дек 06, 18:33    [3544309]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
landy
Ну насколько я понял - все свалилось к обсуждению вопроса - нужны ли журналы транзакций?
Для меня - пока в Postgres не было механизмов наката по журналам(PITR) я его смотрел, но не рассматривал
как БД для серьезного использвания.
Насчет инкрементальных бэкапов - насколько я понимаю - они должны делаться относительно какой-то точки отсчета(первоначальный бэкап БД). Кроме того(во всяком случае в RDB это так) каждый последующий инкрементальный бэкап содержит все изменения с полного бэкапа(т е он растет). Для восстановления БД нужно накатить последний инкрементальный бэкап на полный бэкап БД.
В других БД это так же я думаю(т е как выполняя последующие инкрементальные бжкапы мы можем узнать что забэкапили на предыдущем, т е точка отсчета все равно полный бэкап)?
В Firebird инкрементальный бекап N+1-го уровня - дельта от N-го уровня. 0-ой уровень - полный бекап
15 дек 06, 19:02    [3544402]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Dimitry Sibiryakov
Member

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

Позвольте подытожить:

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

В БД без журналов принудительно записывается сама база. В случае с
shadow - на оба диска. В результате после смерти базы мы сразу имеем ее
полную копию.

В итоге вторые БД чуть медленее в работе, но быстрее в восстановлении.
Что и подтверждается всей вышетекущей дискуссией. Если я чего упустил -
поправьте.

Posted via ActualForum NNTP Server 1.3

15 дек 06, 21:38    [3544788]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
AAron
Member

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

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

Aron

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

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

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

А это-то как связано с журналом?

Posted via ActualForum NNTP Server 1.3

15 дек 06, 22:24    [3544898]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Teilnehmer
Guest
nvlad
Shadow позволяет иметь не меньшую степень надёжности

Если из-за ошибок пользователя, администратора или приложения будут потеряны данные - Shadow не поможет. А журнал транзакций позволит восстановить состояние БД до нужного момента времени.
15 дек 06, 22:35    [3544919]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить