|
Сорри что длинно, но много вопросов.
Victor MetelitsaНакладные расходы, которые я имел в виду - это, во-первых, поддержание rollback segment'а, и во-вторых - записывание сведений блокировок прямо в страницы данных (лично я предпочитаю отдельный список и эскалацию блокировок). (Впервые слышу про эскалацию на табличное пространство). Список блокировок в памяти предпочли не вы, а IBM, вы используете то, что есть. Эскалация блокировок делает "нагрузочную кривую" шибко нелинейной для ДБ2, что не наблюдается у Оракла. Фактически у Оракла все активно изменяемые блоки с данными находятся в памяти, что нивелирует разницу в дизайне при малой транзакционной нагрузке. Подытоживая скажу, что организация блокировок дает возможность Ораклу выжить, работая медленнее из-за увеличенного i/o там, где ДБ2 станет раком из-зи нехватки памяти и экскалации блокировок. Согласен, что грязное чтение для ОЛТП будет просто панацеей в этом случае.
Victor MetelitsaНапомню, что в журнале транзакций DB2 записываются данные для наката и отката. В Oracle данные для отката идут в rollback segment, но в redo log попадают все данные для наката, в том числе и наката rollback segment. Получается, что откат записывается по два раза.
Оракл туда ещё много чего пишет. До тех пор, пока поток записи не превышает пропускную способность диска(-ов) для реду-логов, меня это мало заботит. Кстати, Оракл начиная с 9й версии имеет параметр, выставляющий время восстановления при сбое. То есть я знаю, что в случае чего у меня база восстановится за, скажем, 15 минут. Есть ли это в ДБ2 - пока нет.
Victor MetelitsaХранение блокировки прямо в странице данных приводит к тому, что в ряде случаев её придётся записать два раза.
Предположим, что блок 8К, средняя длина строки скажем 100 байт. Получаем около 80 строк на блок - это так, намёк. При изменении только одной строки в блоке, он пишется только один раз при коммите. Роллбек может потребовать прочесть измененный блок с диска, есть его уже пришлось записать (ДБ2 делает эскалацию при этих обстоятельствах)
Victor Metelitsa
Кстати, в ряде применений и режим грязного чтения (не путайте с фактом грязного чтения) совершенно нормален и корректен.
Как я уже упомянул, это требует соотв. дизайна приложения ("заточки" под ДБ2)
Victor Metelitsa
Про SQL почитайте кулинарную книжку. http://ourworld.compuserve.com/homepages/Graeme_Birchall/HTM_COOK.HTM.
Спасибо, интересно. Уже в фаворитах.
Victor Metelitsa
Но, чтобы пользоваться командой rman'а, надо понимать, что за ней стоит. Необходимо знать огромное количество подробностей, о которых я не забочусь, используя DB2. Это очень и очень сложная штука.
Проблема у ДБ2 в том, что очень мало задокументированных возможностей по управлению системой. IBM хочет, что бы мы воспринимали сервер как чёрный ящик. На самом деле сложность есть и там и там, но у Оракла есть возможность что-то подправить, у ДБ2 - как повезёт. В десятом оракле RMAN настраивается системой и там действительно можно делать бакап сказав backup database
Victor Metelitsa
Полагаю, те динамические планы IBM, о которых говорил инструктор, это совсем не то, про что вы подумали. У меня с английским в порядке. :) Курс называется DB2 UDB Performance Workshop. Много интересного рассказали про внутреннюю кухню, про два движка: CQE (старый) и SQE (новый). Про статический план, почему он не всегда "есть хорошо" и как с ним бороться.
Victor MetelitsaПро "DB2 и MS SQL Server любят фиксированную длину строк. Oracle оптимизирован для переменной" - прошу привести доказательства либо ссылку на источник.
см мой ответ 2gardenman
|
