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

Откуда: 127.0.0.1
Сообщений: 68070
Блог
dimitr
К слову - как Оракл определяет, откуда брать блок? Есть какая-то внутренняя таблица txn ID, принадлежащих RS?

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

dimitr
И еще - размер RS фиксирован админом или может динамически расширяться?

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

Другой момент - начиная с Oracle9, появился некий Automatic Undo Management. Из интересных Вам фич - в этом случае есть возможность зафиксировать время, в течение которого блок не будет повторно использован. Также в этом случае идет полностью динамическое распределение места - в чем, правда, я вижу возможность минусов. В старом варианте я мог выделить транзакции rollback segment и быть уверен, что она отработает до конца; здесь же технически существует возможность проблем в моей супертяжелой транзакции из-за суммарной нагрузки текущих транзакций. Причем написать задание так, чтобы оно "переживало" такую проблему, будет не очень легко.

dimitr
Немаленький FOR-цикл с изменением и коммитом внутри - результат гарантирован в течении десятка минут.

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

В общем - это безусловно вещь, которую нужно знать. Но заметных проблем она не доставляет.

dimitr
С удовольствием бы почитал на эту тему.

На уровне технической реализации - увы, не ко мне. Ключевой момент - именно версионность блоков. Полагаю, прелесть этого понятна - любые, сколь угодно сложные механизмы автоматом учитывают версионность; не надо думать, например, о расщеплении branch-узлов итп. Каждая сессия работает в своем виртуальном пространстве блоков.
17 янв 05, 18:08    [1251160]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
tru55
Member

Откуда: СПб
Сообщений: 19788
2 softwarer
Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO
17 янв 05, 18:28    [1251229]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 68070
Блог
tru55

Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO

В первую очередь, UNDO появляется только если выставить Automatic Undo Management, чего делать необязательно. Во-вторых же, UNDO Tablespace - это те же самые rollback segment-ы (их можно увидеть в системных вьюхах); просто их менеджментом (создание и прочее) занимается сервер.
17 янв 05, 18:42    [1251275]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
tru55
Member

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

Другой момент - начиная с Oracle9, появился некий Automatic Undo Management. Из интересных Вам фич - в этом случае есть возможность зафиксировать время, в течение которого блок не будет повторно использован. Также в этом случае идет полностью динамическое распределение места - в чем, правда, я вижу возможность минусов. В старом варианте я мог выделить транзакции rollback segment и быть уверен, что она отработает до конца; здесь же технически существует возможность проблем в моей супертяжелой транзакции из-за суммарной нагрузки текущих транзакций. Причем написать задание так, чтобы оно "переживало" такую проблему, будет не очень легко.


А

SET TRANSACTION USE ROLLBACK SEGMENT

никто не отменял, вне зависимости от UNDO_MANAGEMENT

К слову сказать, UNDO_RETENTION ("зафиксировать время") - это рекомендация, а не абсолют
17 янв 05, 18:45    [1251281]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
tru55
Member

Откуда: СПб
Сообщений: 19788
softwarer
tru55

Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO

В первую очередь, UNDO появляется только если выставить Automatic Undo Management, чего делать необязательно. Во-вторых же, UNDO Tablespace - это те же самые rollback segment-ы (их можно увидеть в системных вьюхах); просто их менеджментом (создание и прочее) занимается сервер.


Сорру, поспешил. Вопрос терминологии, просто в 9i используется термин "UNDO" вместо "ROLLBACK", причем вне зависимости от UNDO_MANAGEMENT, просто как понятие
17 янв 05, 18:50    [1251294]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 68070
Блог
tru55
SET TRANSACTION USE ROLLBACK SEGMENT
никто не отменял, вне зависимости от UNDO_MANAGEMENT

Вы в этом уверены? ;-)

SQL> select * from v$rollname;

USN NAME
--- ------------------------------
  0 SYSTEM
  1 _SYSSMU1$
  2 _SYSSMU2$
  3 _SYSSMU3$
  4 _SYSSMU4$
  5 _SYSSMU5$
  6 _SYSSMU6$
  7 _SYSSMU7$
  8 _SYSSMU8$
  9 _SYSSMU9$
 10 _SYSSMU10$

11 rows selected

set transaction use rollback segment "_SYSMU10$"

ORA-30019: Illegal rollback Segment operation in Automatic Undo mode

Вы просто воткнулись в режим совместимости - есть параметр 'undo_suppress_errors', который подавляет вывод ошибок в случае "отмененных" операций. То есть вместо выдачи ошибки, как в примере, сервер просто игнорирует эту команду.

tru55
К слову сказать, UNDO_RETENTION ("зафиксировать время") - это рекомендация, а не абсолют

Я не пытался "изнасиловать" этот параметр. Дока, однако, утверждает следующее:

Undo Retention Control

Long-running queries sometimes fail because undo information required for consistent read operations is no longer available. This happens when committed undo blocks are overwritten by active transactions.

Automatic undo management provides a way to explicitly control when undo space can be reused; that is, how long undo information is retained. A database administrator can specify a retention period by using the parameter UNDO_RETENTION. For example, if UNDO_RETENTION is set to 30 minutes, then all committed undo information in the system is retained for at least 30 minutes. This ensures that all queries running for 30 minutes or less, under usual circumstances, do not encounter the OER error, "snapshot too old."
17 янв 05, 19:25    [1251365]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7014
softwarer
Ключевой момент - именно версионность блоков. Полагаю, прелесть этого понятна - любые, сколь угодно сложные механизмы автоматом учитывают версионность; не надо думать, например, о расщеплении branch-узлов итп. Каждая сессия работает в своем виртуальном пространстве блоков.


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

Во-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?
17 янв 05, 19:29    [1251370]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 68070
Блог
dimitr
Во-первых, смею предположить, что это работает не для всех блоков. Тем же сиквенсам версионность крайне вредна, например. Впрочем, хранятся ли их значения в своих собственных блоках или в системной таблице с инкрементом через блокировку, я не в курсе.

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

В то же время я сейчас убедился в версионности блоков секвенсоров на следующем простом примере:

-- Сессия 1 --
create sequence isolated;
set transaction isolation level serializable;
select last_number from dba_sequences where sequence_name = 'ISOLATED';

-- Сессия 2 --
select isolated.nextval from dba_objects where rownum <= 10

-- Сессия 1 --
select last_number from dba_sequences where sequence_name = 'ISOLATED';
commit;
select last_number from dba_sequences where sequence_name = 'ISOLATED';

dimitr
Во-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?

Насколько я помню, в RBS хранится undo информация транзакции. К сожалению, эти вопросы не входят в круг моих "повседневных" знаний, поэтому не буду утверждать категорично.
17 янв 05, 20:04    [1251404]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 601

dimitr
Во-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?

Да две версии. Легко проверить, если создать очень маленький RBS и запустить несколько сессий, изменяющих записи, то экстенты в RBS кончаться намного раньше, чем в случае одной сесси. Я прверял на восьмёрке. На более поздних версиях не пробовал, но не думаю, что там что-то изменилось.
С другой стороны, если проводить просто вставку, а не изменение записей, то Оракул тоже что-то пишет в RBS. Неужели пустые блоки? Что он собирается откатывать?




Posted via ActualForum NNTP Server 1.1

18 янв 05, 12:58    [1252958]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 68070
Блог
protector

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

Откатывать придется "занятое место" в этих блоках - заново пометить его как свободное.
18 янв 05, 13:24    [1253133]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
RedALIEN
Member

Откуда:
Сообщений: 11
Если для автора топика еще актуален вопрос об GUI-инструментах для PG, могу посоветовать взглянуть сюда: http://www.sqlmanager.net. Есть версии для win и linux, последняя послабее будет. Но этот софт стоит денег после 30 дней :)
27 янв 05, 18:49    [1280046]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
актуален, конечно!
Спасибо за ссылку...
1 фев 05, 17:12    [1291564]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
посмотрел - мне нужно было под линукс, так там какая-то допотопная версия (8.0 уж точно не поддерживает). В принципе у аквы похожая функциональнось, хотя здесь понравилось автодополнение кода при написании SQL.
2 фев 05, 14:34    [1294336]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5]      все
Все форумы / Сравнение СУБД Ответить