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

Откуда:
Сообщений: 9365
hvlad
Мы не говорили о том, как избежать сбоя. Мы говорили о том, что сбой _уже произошёл_


Прекрасно, произошел сбой и у нас есть живая вадидная копия OnLine REDO
В чем проблема ?
18 дек 06, 15:08    [3550542]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
landy
Member

Откуда:
Сообщений: 1550
Ок, что будет с БД при потере RUJ ?


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

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


Именно поэтому при восстановлении после креша за накатом всегда следует откат всего незакоммиченного по уже восстановленному UNDO
Я уже потерял нить - о чём речь ?
Какой накат\откат, если он-лайн журнала нет ? В базе есть страницы с незакомиченными данными, но инф-ции для отката нет.
18 дек 06, 15:49    [3550876]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Apex
Member

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

Ну это смотря в какой БД. К примеру в Oracle RDB туда идут только закоммиченные транзакции(суть - только измененные данные).

Это не так. redo генерится во время изменения данных и копится в redo buffer,который сбрасывается на диск каждые 3 сек. или при заполнении больше чем на треть (и еще в паре случаев), а по commit в лог сбрасывается маркер окончания транзакции. При этом, лог Оракла содержит так же информацию об откате, т.к. защищает в том числе и данные сегментов отката.
18 дек 06, 15:50    [3550887]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Gluk (Kazan)
hvlad
Мы не говорили о том, как избежать сбоя. Мы говорили о том, что сбой _уже произошёл_


Прекрасно, произошел сбой и у нас есть живая вадидная копия OnLine REDO
В чем проблема ?
В том, что кто-то невнимательно читает :)
Мы обсуждаем случай, когда у нас _нет_ онлайн журнала. В этом и состоит сбой.
18 дек 06, 15:52    [3550902]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

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


Именно поэтому при восстановлении после креша за накатом всегда следует откат всего незакоммиченного по уже восстановленному UNDO
Я уже потерял нить - о чём речь ?
Какой накат\откат, если он-лайн журнала нет ? В базе есть страницы с незакомиченными данными, но инф-ции для отката нет.


Возможно я тоже потерял нить :( Если речь шла об Oracle, то информация для отката всегда в UNDO. В процессе восстановления, после наката всех логов (в том числе на UNDO), откатываются все неподтвержденные транзакции. До этого момента никого к грязным данным не пустят.
18 дек 06, 15:56    [3550934]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Apex
Member

Откуда: Made in USSR
Сообщений: 3910
hvlad
Gluk (Kazan)
hvlad
Мы не говорили о том, как избежать сбоя. Мы говорили о том, что сбой _уже произошёл_


Прекрасно, произошел сбой и у нас есть живая вадидная копия OnLine REDO
В чем проблема ?
В том, что кто-то невнимательно читает :)
Мы обсуждаем случай, когда у нас _нет_ онлайн журнала. В этом и состоит сбой.

В принципе это тоже самое, что и отсутствие инкрементального бэкапа в СУБД беж журнала транзакций.
Кстати, у меня все же есть сомнения, что инкрементальный бэкап можно делать столь часто, чтобы он мог конкурировать с журналом.
18 дек 06, 15:58    [3550953]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
hvlad
Gluk (Kazan)
hvlad
Мы не говорили о том, как избежать сбоя. Мы говорили о том, что сбой _уже произошёл_


Прекрасно, произошел сбой и у нас есть живая вадидная копия OnLine REDO
В чем проблема ?
В том, что кто-то невнимательно читает :)
Мы обсуждаем случай, когда у нас _нет_ онлайн журнала. В этом и состоит сбой.


Если у нас есть пропуск в журналал на момент краха, выполнить полное восстановление разумеется не удастся
18 дек 06, 15:59    [3550959]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
landy
Ок, что будет с БД при потере RUJ ?


При потере RUJ БД с неоткаченными данными. Я в этом случае беру бэкап и накатываю по журналам до последней закоммиченной транзакции(которые в логе)
Правильно. Т.е. сама база _не_ консистентна и её нужно восстанавливать из бекапов.
А теперь вернемся к началу этой беседы :

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

Откуда:
Сообщений: 11551
Gluk (Kazan)
hvlad
Мы обсуждаем случай, когда у нас _нет_ онлайн журнала. В этом и состоит сбой.


Если у нас есть пропуск в журналал на момент краха, выполнить полное восстановление разумеется не удастся
Об этом я и говорю :)
Т.е. механизм журналирования сам по себе не даёт 100% гарантии восстановления, как некоторые пытаются тут доказать
18 дек 06, 16:08    [3551040]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
hvlad
Т.е. в обеих системах возможны случаи потери данных :
в Firebird - с момента последнего бекапа (инкрементального или полного)
в системах с журналированием - с момента последнего архивирования журнала
пардон, но я так и не понял что подразумевается под крахом: внезапная перегрузка или выход из строя винчестера?
18 дек 06, 16:11    [3551067]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Apex
hvlad
Мы обсуждаем случай, когда у нас _нет_ онлайн журнала. В этом и состоит сбой.

В принципе это тоже самое, что и отсутствие инкрементального бэкапа в СУБД беж журнала транзакций
Да, конечно
Apex
Кстати, у меня все же есть сомнения, что инкрементальный бэкап можно делать столь часто, чтобы он мог конкурировать с журналом.
Это уже практическая сторона вопроса.
Инкрементальный бекап, возможно, дольше формируется (т.к. требует чтения БД, не обязательно всей), но содержит, как правило, меньше данных.
Так что я бы не стал делать однозначных оценок
18 дек 06, 16:16    [3551097]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
SergSuper
hvlad
Т.е. в обеих системах возможны случаи потери данных :
в Firebird - с момента последнего бекапа (инкрементального или полного)
в системах с журналированием - с момента последнего архивирования журнала
пардон, но я так и не понял что подразумевается под крахом: внезапная перегрузка или выход из строя винчестера?
Какая разница ? Ну, пусть будет выход из строя рейд-контроллера с журналами :)
18 дек 06, 16:17    [3551110]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
hvlad
SergSuper
hvlad
Т.е. в обеих системах возможны случаи потери данных :
в Firebird - с момента последнего бекапа (инкрементального или полного)
в системах с журналированием - с момента последнего архивирования журнала
пардон, но я так и не понял что подразумевается под крахом: внезапная перегрузка или выход из строя винчестера?
Какая разница ? Ну, пусть будет выход из строя рейд-контроллера с журналами :)

Т.е. сами винчестеры остались целы? Тогда например для MS SQL сохранятся все завершенные транзакции, т.к. после каждой транзакции идёт запись в журнал
18 дек 06, 16:26    [3551200]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
SergSuper
Т.е. сами винчестеры остались целы? Тогда например для MS SQL сохранятся все завершенные транзакции, т.к. после каждой транзакции идёт запись в журнал
Опять с начала всё начинать ?
В базе будут страницы с незакомиченными данными. Откатить их невозможно, ибо журнал погиб.
Я приводил даже ссылку на FAQ на этом сайте
18 дек 06, 16:49    [3551367]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
hvlad
SergSuper
hvlad
Т.е. в обеих системах возможны случаи потери данных :
в Firebird - с момента последнего бекапа (инкрементального или полного)
в системах с журналированием - с момента последнего архивирования журнала
пардон, но я так и не понял что подразумевается под крахом: внезапная перегрузка или выход из строя винчестера?
Какая разница ? Ну, пусть будет выход из строя рейд-контроллера с журналами :)


Расцепляем диски из зеркала и вытаскиваем REDO-логи (все остальное есть)
Надеюсь вы не собираетесь писать OnLine REDO на страйп или Боже упаси на RAID 5 ?
18 дек 06, 16:53    [3551404]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Кстати, даже если OnLine REDO погибли, можно восстановить БД в консистентном состоянии, просто на более ранний момент времени (в режиме ARCHIVELOG разумеется, архивные логи выносятся на STANDBY-сервер, так что в основной может падать бомба)
18 дек 06, 16:56    [3551430]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Gluk (Kazan)
Расцепляем диски из зеркала и вытаскиваем REDO-логи (все остальное есть)
Надеюсь вы не собираетесь писать OnLine REDO на страйп или Боже упаси на RAID 5 ?
Я не собираюсь описывать каким образом журнал оказался потерян. И я не спрашиваю здесь что делать, если он потерян :)

Мы рассмотрели ситуацию, когда возможна потеря данных в журналируемой СУБД.
Не нужно мне доказывать, что правильными методами вероятность потери журналов можно свести к 0.00001% - я это не оспариваю :)
18 дек 06, 16:59    [3551451]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32882

Привет, Gluk!
Ты пишешь:

Gluk
GK> Расцепляем диски из зеркала и вытаскиваем REDO-логи (все остальное есть)
щаззз.
это если диск рюхнулся, то да.
а если контроллер (как было сказано),
то шансы того, что данные будут валидны - мизерны.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.3

18 дек 06, 16:59    [3551452]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
wellx
Member

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

да где Вы видите узкое место при последовательной записи в лог? сколько вы МБ/с собираетесь писать? 10? 20? 200? Если OLTP база меняет махом в разных сессиях по 200 МБ данных (условно, конечно), то за это надо голову отрывать разработчикам.


Т.е по вашему операции с HDD уже не самое медленное место в компе? И если все меняющие данные потоки лезут к одному файлу лога - то это Вы не считаете узким местом системы? Проблема не в скорости записи на диск, проблема что все процессы борются за один ресурс и это есть потенциально узкое место.
18 дек 06, 18:02    [3551965]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
AAron
Member

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

да где Вы видите узкое место при последовательной записи в лог? сколько вы МБ/с собираетесь писать? 10? 20? 200? Если OLTP база меняет махом в разных сессиях по 200 МБ данных (условно, конечно), то за это надо голову отрывать разработчикам.


Т.е по вашему операции с HDD уже не самое медленное место в компе? И если все меняющие данные потоки лезут к одному файлу лога - то это Вы не считаете узким местом системы? Проблема не в скорости записи на диск, проблема что все процессы борются за один ресурс и это есть потенциально узкое место.

послушайте, когда Вы делаете логирование в многопоточной системе, вы даете каждому потоку право самостоятельно писать в лог? или же создаете отдельный поток, который сам уже занимается записью в лог, соблюдая при этом консистентность передаваемых сообщений?
Если первое, то я не удивлюсь, что вы еще и файл открываете/закрываете каждый раз.
В любом случае, файл журнала пишется последовательно, данные туда пишутся последовательно...
18 дек 06, 18:16    [3552030]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
hvlad
SergSuper
Т.е. сами винчестеры остались целы? Тогда например для MS SQL сохранятся все завершенные транзакции, т.к. после каждой транзакции идёт запись в журнал
Опять с начала всё начинать ?
В базе будут страницы с незакомиченными данными. Откатить их невозможно, ибо журнал погиб.
Я приводил даже ссылку на FAQ на этом сайте

Если журнал погиб - то естественно будет потеря информации, точно также как и при потере файла данных. Но это аппаратная проблема, которая решается аппаратно
18 дек 06, 23:11    [3552813]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Gluk (Kazan)
hvlad
SergSuper
hvlad
Т.е. в обеих системах возможны случаи потери данных :
в Firebird - с момента последнего бекапа (инкрементального или полного)
в системах с журналированием - с момента последнего архивирования журнала
пардон, но я так и не понял что подразумевается под крахом: внезапная перегрузка или выход из строя винчестера?
Какая разница ? Ну, пусть будет выход из строя рейд-контроллера с журналами :)


Расцепляем диски из зеркала и вытаскиваем REDO-логи (все остальное есть)
Надеюсь вы не собираетесь писать OnLine REDO на страйп или Боже упаси на RAID 5 ?


Я приводил встреченный мной на практике, крайне редкий и крайне неприятный расклад, при котором "поехала крыша" у RAID-контроллера в результате firmware ugrade. В данном случае имеем вот что:

1. Все данные введенные в систему после того как накрылся RAID-контроллер безвозвратно потеряны. Нет redo logs - нет point in time recovery. Тут hvlad прав.
2. Поскольку логи пишутся последовательно, а у грамотных DBA они еще и неспеша пишутся на ленту или на дешевенький массивчик ATA-дисков, то все старые логи до злополучного firmware ugrade с большой долей вероятности удастся спасти. Соответственно удастся восстановится на момент непосредственно перед злополучным апгрейдом.

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

Предположим что система "накрылась" через полчаса после злополучного апгрейда. В принципе абсолютно реальный сценарий. Оракл например очень не любит когда в блоках котрольные суммы не совпадают. Данные за эти полчаса "нарылись". Но! Мы делаем сильный ход, достав бэкап трехдневнрй давности, и накатив на него логи. Э вуаля, как говорят французы, база восттановалена на момент непосредственно перед апгрейдом.

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

В общем логи - штука удобная
19 дек 06, 06:16    [3553095]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Мимопроходящий

Привет, Gluk!
Ты пишешь:

Gluk
GK> Расцепляем диски из зеркала и вытаскиваем REDO-логи (все остальное есть)
щаззз.
это если диск рюхнулся, то да.
а если контроллер (как было сказано),
то шансы того, что данные будут валидны - мизерны.


Я же сказал, кроме зеркала в этом месте ничего использовать нельзя.
Помимо этого есть возможность софтварного зеркалирования REDO
19 дек 06, 08:32    [3553201]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL 8.2: сравнения с Oracle и MS SQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Зл0й
1. Все данные введенные в систему после того как накрылся RAID-контроллер безвозвратно потеряны. Нет redo logs - нет point in time recovery. Тут hvlad прав.


Нет OnLine REDO - ЕСТЬ point in time recovery
НЕТ полного восстановления
ЕСТЬ потерянные ТРАНЗАКЦИИ

база в КОНСИСТЕНТНОМ состоянии

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