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

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

softwarer
И что же в этом нелогичного?

Действительно, что нелогичного в однонаправленных преобразованиях?.. В
математике нет обратного преобразования для возведения в квадрат, хэши
опять же... В Оракуле нет обратного преобразования для формата TM. Раз
нет, значит никому не было нужно. Да, топикстартер прав, Оракул логичен.
И вообще он впереди планеты всей. Некоторые, правда, считают, что эта
планета катится в ад, но и это логично. Все идите на Оракул!


Еще раз Ваши утверждения насчет обратности уже есть неверны, соответственно дальнейшая цепочка тоже.
6 июл 10, 19:51    [9060189]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
goldenfoods
Member

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

goldenfoods

Ну как быть с незкоммиченными транзакциями в момент аварийного
завершения работы сервера?

В момент завершения - никак, на то оно и аварийное. При последующем
запуске - пометить как откатившиеся и всё.


Как об этом узнает сервер? В нормальных СУБД это видно по журналу транзакций. Ну а как файерберд понимает, что транзакции были не полностью выполнены. Никак понять не могу. Могли бы Вы разъяснить?
6 июл 10, 19:54    [9060198]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Dimitry Sibiryakov
Member

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

goldenfoods

Ну а как файерберд понимает, что транзакции были не полностью выполнены.
Никак понять не могу. Могли бы Вы разъяснить?

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

Posted via ActualForum NNTP Server 1.4

6 июл 10, 20:14    [9060265]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov

Очень просто....Никаких логов не требуется.


Правильно я понимаю, что следствие такой "простоты" - как минимум не возможность Timе In Poinе Restore и всего другого функционала, связанного с наличием лога транзакций?
6 июл 10, 20:50    [9060398]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
goldenfoods
iscrafm
Saller, 97% всех пользователей компьютеров так поступают. Они все настолько суровы?


Откуда такая информация? Например я использую FreeBSD, Oracle Linux для серверной части. FreeBSD+gnome для десктопа и я думаю, таких как я очень много

позравляю. Ты входишь в 3%!
6 июл 10, 21:03    [9060443]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
prarklin
как минимум не возможность Timе In Poinе Restore и всего другого функционала, связанного с наличием лога транзакций?

не знаю, что Вы имеете в виду под "всего функционала". Если отсюда исключить ACID, то возможно, да.
Ну и, если в point in time используются маркеры времени, то в ФБ их нет.

goldenfoods
Вот почему категорически запрещено ставить файерберд для корпоративного использования. Просто вредно.

а вы не читайте всякую муйню. Это я Вам говорю как человек, который чинит базы IB/FB после сбоев оборудования (дисков, контроллеров и т.п.).

goldenfoods
Да файерберда лога нет вот и все факт нелогичности. Но вроде как появился.

не-лог-ичность от слова лог? Возможно. Насчет "вроде" - нет, не появился. Вы если чего про другие СУБД не знаете, Вы спрашивайте, а не наезжайте. Наезды они не красят наезжающего, совершенно.
6 июл 10, 21:07    [9060459]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
iscrafm
Member [заблокирован]

Откуда:
Сообщений: 35345
goldenfoods
Вот почему категорически запрещено ставить файерберд для корпоративного использования. Просто вредно. Лучше потратиться и купить оракл стандарт едишн ван стоит 180 долл пер юзер. А если вообще нет денег, то экспресс едишн очень удобен+получаешь бесплатно еще и разработку веб-интерефейса к базе. Такой себе акцесс а ля оракл получается.

Пипец (с) фильм
6 июл 10, 21:14    [9060483]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
hvlad
Member

Откуда:
Сообщений: 11551
pkarklin
Правильно я понимаю, что следствие такой "простоты" - как минимум не возможность Timе In Poinе Restore и всего другого функционала, связанного с наличием лога транзакций?
Насчёт PITR (point in time recovery) - не правильно.
Добавив маркеры времени к тр-циям и удерживая сборку мусора можно получить снимок всей БД на любой момент.
Насчёт "всего другого функционала" - уточните о чём именно речь.
6 июл 10, 22:17    [9060687]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Eugenkru10
Guest
Какова хера удаляют мои ответы?
Больше я тут отвечать не будут.
Пошёл он накуй этот тупорылый SergSuper - долбоёб какой то!
Эта сцука животное неблагодарное, он может тока Хер дрочить и посты удалять,
больше нихера он не может потому что он бездарь.
6 июл 10, 22:24    [9060717]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
Насчёт PITR (point in time recovery) - не правильно.
Добавив маркеры времени к тр-циям и удерживая сборку мусора можно получить снимок всей БД на любой момент.


Гм... А не проще ли будет, таки, сделать отдельный "честный" лог?! Что будете делать, если будет поврежден сам файл бд, в котором и "временные метки" и "мусор"?

hvlad
Насчёт "всего другого функционала" - уточните о чём именно речь.


Да все, что связано с использованием лога транзакций - репликация, зеркалирование.
6 июл 10, 22:27    [9060729]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Dimitry Sibiryakov
Member

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

pkarklin

Да все, что связано с использованием лога транзакций - репликация,
зеркалирование.

Отлично делаются и без лога.

Posted via ActualForum NNTP Server 1.4

6 июл 10, 22:44    [9060786]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov
Отлично делаются и без лога.


Готов выслушать архитектуру альтернативных решений...
6 июл 10, 22:49    [9060806]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Dimitry Sibiryakov
Member

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

pkarklin
Готов выслушать архитектуру альтернативных решений...

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_replicator

Posted via ActualForum NNTP Server 1.4

6 июл 10, 23:20    [9060912]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov

pkarklin
Готов выслушать архитектуру альтернативных решений...

http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_replicator


автор
...IBReplicator implements this architecture by way of a change log...


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

автор
InterBase Replication is not built into the database engine


Поэтому "change log" прикручивается "сбоку" в виде

автор
ordinary application which accesses the database via the InterBase client API
6 июл 10, 23:30    [9060950]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Dimitry Sibiryakov
Member

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

pkarklin

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

Ну это и ежу понятно. Если брать по большому счёту, то лог, ведущийся не
для всей базы, а для каждой отдельной записи и называется MGA.
Хотя, конечно, есть варианты... Не все в этом списке признаются в
ведении лога: http://www.firebirdfaq.org/faq249/

Posted via ActualForum NNTP Server 1.4

7 июл 10, 00:01    [9061068]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30232
pkarklin
Что будете делать, если будет поврежден сам файл бд, в котором и "временные метки" и "мусор"?

А что будете делать Вы? Ну, когда поврежден лог, а есть база, не рассматриваем :-)
А вот если будет повреждена база, но есть лог? Лог же не вечный, из него базу целиком не восстановить.
Понятно, что можно взять какой-то бэкап базы, и накатить сверху лог, если они "стыкуются".
Проблема в том, что FB настолько широко используется, что в массе стоит на компах с одним диском (в лучшем случае raid 1), и даже если этот комп обслуживает админ, то админ невероятно тупой, и не способен даже бэкапы регулярно делать.

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

Впрочем, я увлекся. Моя мысль была о том, что там, где в массе стоит ФБ, любое повреждение Оракловской базы или лога вызовет абсолютно тот же эффект, что и повреждение БД ФБ.
7 июл 10, 00:42    [9061218]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Yo.!
Guest
kdv

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

в оракле принято в таких условиях (1 hdd) уносить rsync'ом арклоги т.е. размер потерь будет совершенно несоизмерим, даже если админ поленится настроить адекватно размер REDO ...
7 июл 10, 01:02    [9061290]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Dimitry Sibiryakov
Member

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

Yo.!

в оракле принято в таких условиях (1 hdd) уносить rsync'ом арклоги

Это если админ вообще не отключит эти самые арклоги...

Posted via ActualForum NNTP Server 1.4

7 июл 10, 01:17    [9061345]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
hvlad
Member

Откуда:
Сообщений: 11551
pkarklin
hvlad
Насчёт PITR (point in time recovery) - не правильно.
Добавив маркеры времени к тр-циям и удерживая сборку мусора можно получить снимок всей БД на любой момент.


Гм... А не проще ли будет, таки, сделать отдельный "честный" лог?!
На мой персональный взгляд, "честный" лог может быть полезен в Firebird только с точки зрения производительности при записи - за счёт последовательного IO. Правда этот IO лишний, так что с ним не всё так хорошо, как некоторые считают. Ну и я не слышал, чтобы лог тр-ций в IB применяли именно для увеличения производительности.
Кстати, грядёт эпоха SSD, и вопрос random vs sequential IO практически закроется сам-собой.

pkarklin
Что будете делать, если будет поврежден сам файл бд, в котором и "временные метки" и "мусор"?
kdv частично ответил. Напомню только, что в Firebird используется стратегия записи careful writes, благодаря которой файл БД защищён от поломок из-за краха движка.

pkarklin
hvlad
Насчёт "всего другого функционала" - уточните о чём именно речь.


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

Зеркалирование - в IB испокон века есть shadow для зеркалирования файла БД (эдакий raid1).
Если речь о зеркалировании на другой сервер, то накат дельт инкрементного бекапа (а он многоуровневый, в отличие от MSSQL) с успехом заменит накат журналов тр-ций.
7 июл 10, 01:48    [9061413]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
в оракле говорят есть другая очень правильная и логичная фишка - NULL и пустая строка неразличимы
7 июл 10, 03:49    [9061478]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
kdv
А что будете делать Вы? Ну, когда поврежден лог, а есть база, не рассматриваем :-)
А вот если будет повреждена база, но есть лог? Лог же не вечный, из него базу целиком не восстановить.
Понятно, что можно взять какой-то бэкап базы, и накатить сверху лог, если они "стыкуются".


Необходимым условием возможности восстановления на момент сбоя (к примеру, поврежден файл бд) является наличие непрерывной цепочки бэкапов (разных типов) и полная модель восстановления. На реальном примере...

Есть некая бд, стратегия резервного копирования которой выглядит следующим образом:

1. Полный бэкап в воскресенье в 0:00;
2. Дифференциальный бэкап каждый день, кроме воскресенья, в 0:00;
3. Бэкап лога транзакций - каждый час.

Предположим, что в четверг в 17.45.13 происходит развал массива на котором лежит файл бд.

Действия админа в данном случаи при необходимости восстановления на момент сбоя:

1. Выполнить Tail-Log Backup - т.е. снять резервную копию лога транзакций, которые "накопились" с момента последнего бэкапа лога в 17.00;
2. Восстановить фуллбэкап от воскресенья;
3. Востановить дифф от четверга;
4. Востановить все бэкапы лога за четверг;
5. Восстановить бэкап лога, сделанный на шаге 1,

тем самым получив бд в состоянии, ровно до сбоя.

kdv
Проблема в том, что FB настолько широко используется, что в массе стоит на компах с одним диском (в лучшем случае raid 1), и даже если этот комп обслуживает админ, то админ невероятно тупой, и не способен даже бэкапы регулярно делать.


К сожалению, это проблема не только у FB.

kdv
Я понимаю, что это издержки "дешевизны" ФБ, но такова жизнь.


Да, но даже Экспресс редакция MS SQL имеет описанный выше функционал.

kdv
Моя мысль была о том, что там, где в массе стоит ФБ, любое повреждение Оракловской базы или лога вызовет абсолютно тот же эффект, что и повреждение БД ФБ.


По большому счету согласен, но все-тки здОрово иметь как можно больше возможностей для восстановления.
7 июл 10, 08:14    [9061606]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67383
Блог
StalkerS
в оракле говорят есть другая очень правильная и логичная фишка - NULL и пустая строка неразличимы

Да, есть. И с тех пор, как мне пришлось выполнить проект на MSSQL, я стал эту фишку очень ценить. А ещё в оракле есть даже третья очень правильная и логичная фишка - ограничение unique может быть наложено на nullable колонку и допускает наличие null более чем в одной записи.
7 июл 10, 08:29    [9061629]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
hvlad
На мой персональный взгляд, "честный" лог может быть полезен в Firebird только с точки зрения производительности при записи - за счёт последовательного IO. Правда этот IO лишний, так что с ним не всё так хорошо, как некоторые считают. Ну и я не слышал, чтобы лог тр-ций в IB применяли именно для увеличения производительности.


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

hvlad
Напомню только, что в Firebird используется стратегия записи careful writes, благодаря которой файл БД защищён от поломок из-за краха движка.


Согласитесь, что кроме поломок движка, существует еще множество других типов поломок (программных и аппаратных), которые могут привести к повреждению файла бд. и очень бы хотелось иметь возможность восстановления на момент сбоя.

hvlad
Зеркалирование - в IB испокон века есть shadow для зеркалирования файла БД (эдакий raid1).


Такое зеркалирование существовало еще в MS SQL 6.5.

hvlad
Если речь о зеркалировании на другой сервер, то накат дельт инкрементного бекапа (а он многоуровневый, в отличие от MSSQL) с успехом заменит накат журналов тр-ций.


Отквоченное соответствует Log Shippingу в MS SQL, и это совсем не зеркалирование, которое позволяет менять "на лету" роли серверов (principal\mirror), причем с автоматическим переподключеним клиента на зеркало в случае выхода из строя основного сервера.
7 июл 10, 08:31    [9061635]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
StalkerS
Member

Откуда: Melbourne
Сообщений: 1344
softwarer
Да, есть. И с тех пор, как мне пришлось выполнить проект на MSSQL, я стал эту фишку очень ценить.

я пожалуй тоже тогда начну очень ценить фишку mssql где null не рассматривается как пустая строка
softwarer

А ещё в оракле есть даже третья очень правильная и логичная фишка - ограничение unique может быть наложено на nullable колонку и допускает наличие null более чем в одной записи.

это вы типа к тому, что имеем одну нелогичную вещь, но уравновешиваем ее наличием другой логичной? Ну.. хорошо ) Кстати это-же означает что в unique столбец мы можем сложить несколько пустых строк... даже не знаю как тут с логичностью...

Предлагаю тогда пойти дальше и приравнять в оракле значения null и 0 для integer столбцов, так сказать для окончательной победы логики над здравым смыслом. Логика торжествует, планета катится в ад (с)
7 июл 10, 09:07    [9061700]     Ответить | Цитировать Сообщить модератору
 Re: Все таки Oracle впереди планеты всей!  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
StalkerS
softwarer
Да, есть. И с тех пор, как мне пришлось выполнить проект на MSSQL, я стал эту фишку очень ценить.

я пожалуй тоже тогда начну очень ценить фишку mssql где null не рассматривается как пустая строка
softwarer

А ещё в оракле есть даже третья очень правильная и логичная фишка - ограничение unique может быть наложено на nullable колонку и допускает наличие null более чем в одной записи.

это вы типа к тому, что имеем одну нелогичную вещь, но уравновешиваем ее наличием другой логичной? Ну.. хорошо ) Кстати это-же означает что в unique столбец мы можем сложить несколько пустых строк... даже не знаю как тут с логичностью...

Предлагаю тогда пойти дальше и приравнять в оракле значения null и 0 для integer столбцов, так сказать для окончательной победы логики над здравым смыслом. Логика торжествует, планета катится в ад (с)


Да плевать куда катится твоя логика. Тебе же сказали, фишка не логичная, не значит неудобная.
И лично я предпочитаю, чтобы удобство перевешивало логику (там где они конфликтуют).
7 июл 10, 09:12    [9061718]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить