CITKIT.ru
3 терабайта свободного софта!
Logo    
IT-рынок Новости мира IT Океан(!) софта на CITKIT.ru Форумы Поступления в библиотеку Учебный центр Курилка
CitForum    CITForum на CD Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

23.05.2005

Google
WWW CITForum.ru

Новости мира IT:

  • 11.05 - Intel создает свою группу по Open Source
  • 11.05 - Банк контролирует использование USB устройств при помощи DeviceLock
  • 11.05 - Microsoft устранила опасную дыру в Windows
  • 11.05 - "Корпорация ОСС" создает антимонопольный альянс операторов IP-телефонии
  • 11.05 - В Mac OS X найдены множественные уязвимости
  • 11.05 - "Билайн" запускает услугу "Мобильная почта"
  • 11.05 - Две критические уязвимости в браузере Firefox 1.0.3
  • 11.05 - IBM покупает начинающую Open Source-компанию Gluecode
  • 11.05 - Microsoft готова к битве с Open Source за школы
  • 11.05 - Sun завершит "открытие" Solaris в ближайшие 45 дней
  • 11.05 - Создатели браузера Firefox выпускают юбилейные монеты в честь 50 миллионов скачанных копий
  • 11.05 - Вышла пятая версия мобильной ОС от Microsoft
  • 11.05 - Поисковые движки умнеют быстрее, чем люди
  • 11.05 - Фишеры постоянно совершенствуются
  • 11.05 - Специалисты прогнозируют появление аналога Google Adsense от "Яндекс"
  • 06.05 - ICANN озаботилась проблемой торговых марок
  • 06.05 - Google патентует сортировку новостей
  • 06.05 - Intel готовит двуядерные процессоры второго поколения
  • 06.05 - Schoolforge-UK и OSC продвигают Open Source в школы
  • 06.05 - Новая версия рекламной программы подстрекает пользователей купить ПО для своего лечения
  • 06.05 - Microsoft продает ряд своих закрытых разработок
  • 06.05 - Google Labs анонсировал ускоритель интернета
  • 06.05 - Microsoft подвешивает пиратам "морковку"
  • 06.05 - В США входят в обиход "интеллектуальные" тележки для супермаркетов
  • 06.05 - Microsoft работает над аналогом PDF
  • 05.05 - Yahoo video search теперь доступен массам
  • 05.05 - Алмазы помогут бороться с хакерами
  • 05.05 - Интернет-охоту хотят запретить
  • 05.05 - Microsoft привлекает блоггеров для теста Longhorn
  • 05.05 - Основатель Red Hat предложил Стиву Джобсу помощь в решении проблемы с торговой маркой
  • 05.05 - Компьютерная система оргкомитета Кубка мира по футболу 2006 года пострадала от червя Sober
  • 04.05 - Cisco Systems представила многофункциональный продукт Adaptive Security Appliance 5500
  • 04.05 - Администрация Евросоюза поддержала идею всеевропейской интернет-библиотеки
  • 04.05 - Компьютерный вирус дарит билеты на чемпионат мира по футболу
  • 04.05 - Лаборатория Касперского: Обзор вирусной активности - апрель 2005
  • 04.05 - Microsoft хочет отсудить у россиянина два домена
  • 04.05 - Сделка между Lenovo и IBM завершена
  • 04.05 - Эпидемия червя Sober.p зафиксирована в Западной Европе
  • 04.05 - Panda Software публикует отчет о вирусной активности за апрель
  • 03.05 - Институт SANS обновил список наиболее опасных уязвимостей

    Архив новостей >>>


  • 2004 г.

    Сколько стоит update?

    Джонатан Льюис, www.jlcomp.demon.co.uk
    Перевод Валерия Кравчука

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

    Краткая история генераторов форм

    Было время, когда в SQL*Forms (так его тогда называли) было принято использовать единственный SQL-оператор обновления для блока. Этот оператор update обновлял (по значению rowid) каждый столбец таблицы, упоминающийся в блоке. Это казалось неплохой идеей, поскольку упрощало код и делало его более эффективным на клиенте: не нужно было решать вычислительно сложную задачу определения действиетльно измененных полей и динамически формировать SQL-оператор для обновления только соответствующих столбцов в базе данных.

    Потом, в районе версии Forms 4.5 (я могу ошибаться с версией - жду поправок), корпорация Oracle добавила флаг, который можно устанавливать для выбора либо одного оператора, "обновляющего все", либо динамически генерируемого оператора "обновлять только минимальный набор столбцов". Какая из этих опций лучше?

    Сколько стоит обновить столбец?

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

    Итак, что же может произойти при обновлении одного столбца в таблице в отдельной транзакции? Понятно, что строку надо заблокировать и данные изменить, а для этого - получить запись списка заинтересованных транзакций (Interested Transaction List - ITL) в блоке. Необходимо захватить слот таблицы транзакций (transaction table slot) в заголовке сегмента отмены (undo segment header) для использования в качестве глобально видимой "ссылки" на транзакцию, а также внести запись отмены в блок отмены, описывающую, как отменить изменения, только что выполненные в блоке данных. Изменения во всех трех блоках необходимо записать в журнал повторного выполнения (первоначально - в буфер журнала), и в этом простом случае потребуется только одна запись повторного выполнения (redo record).

    Затем, при фиксации транзакции в слоте таблицы транзакций записывается соответствующее значение номера системного изменения (commit SCN) и он помечается как свободный, а адрес использованного блока отмены тоже можно записать в пул свободных блоков в блоке заголовка сегмента отмены. Эти изменения в блоке заголовка сегмента отмены записываются в журнал повторного выполнения (в буфер), а для сброса буфера журнала на диск вызывается процесс записи журнала (log writer process - lgwr), после чего пользовательский процесс уведомляют, что транзакция успешно зафиксирована. (Oracle может, а в этом случае, скорее всего, и будет также очищать измененный блок данных, но не будет записывать выполненные при очистке изменения в журнал повторного выполнения).

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

    Затраты на получение записи ITL, блокирование и обновление строки, вероятно, не сильно изменятся, а затраты на получение блока заголовка сегмента отмены вообще не изменятся.

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

    Аналогично, существенно изменится и запись повторного выполнения. В идеале, запись повторного выполнения будет для этого изменения длиной около 200 байтов (плюс еще 200, связанных с с блоком заголовка сегмента и вектором аудита транзакции). Эта запись, вероятно, будет дополнена до 512 байтов (типичный минимальный размер блока ОС) всяким мусором при фиксации транзакции. Но основная запись повторного выполнения состоит, по сути, из двух векторов изменений - вектора для блока таблицы и вектора для записи отмены, - и оба они увеличатся в размере, потому что запись отмены будет включать старую версию всех столбцов, а запись повторного выполнения для таблицы - новую версию всех столбцов. Поэтому объем генерируемых данных повторного выполнения увеличивается в два-четыре раза, а во многих интенсивно загруженных системах скорость сброса данных повторного выполнения на диск часто является критической проблемой производительности.

    Но это еще не все

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

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

    Срабатывают ли строчные триггеры типа 'update of {список_столбцов}'?
    before row
    after row
    instead of
    Изменяются ли индексы, включающие такой столбец?
    Что, если это индексы на основе B*-дерева?
    А как насчет индексов на основе битовых карт?
    Что будет с индексами по функции (function-based indexes)?
    Как сервер будет обеспечивать целостность ссылок?
    Если этот столбец - подчиненный?
    Если этот столбец - главный?
    Триггеры

    Создадим простую таблицу с триггером и выполним действия, представленные ниже в листинге 1:

    Листинг 1

    create table t2 (
      id_gp number(4),
      id_p number(4),
      n2 number(4)
    );
    insert into t2 values (1,1,1);
    commit;
     
    create or replace trigger t2_bru
    before update of id_gp on t2
    for each row
    -- when (
    --   new.id_gp != old.id_gp
    --or new.id_gp is null and old.id_gp is not null
    --or old.id_gp is null and new.id_gp is not null
    -- )
    begin
      dbms_output.put_line('Updating');
    end;
    /
    
    column rid new_value m_rid
    
    select rowid rid 
    from t2 
    where rownum = 1;
    
    update t2 set id_gp = id_gp where rowid = '&m_rid';
    

    Триггер срабатывает. То же самое происходит и с триггером after-row update. Подтверждение моего предположения, что сработает и триггер instead of оставляю читателю в качестве упражнения.

    Фактически, строчный триггер before генерирует одну дополнительную запись отмены и одну дополнительную запись повторного выполнения, даже если ничего при этом не делает из-за добавления достаточно сложной конструкции when, которая в примере закомментирована. Так что, если есть выбор, немного эффективнее будет использовать строчные триггеры after.

    Индексы

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

    Итак, что же происходит при выполнении обновления без фактического изменения значения для столбца, входящего в простой индекс на основе B-дерева? Ничего. Сервер Oracle определяет, что проиндексированное значение не изменилось, и даже не обращается к индексу, не говоря уже про блокирование записи. Это верно и для простых индексов на основе битовых карт.

    Вы можете усомниться, а не произойдет ли что-то ужасное при переходе на индексы по функции - не будет ли вызываться функция "на всякий случай", правильно ли отслеживает сервер Oracle зависимости между функциями и используемыми в них столбцами? Ответ: все работает правильно, никаких лишних вычислений функции или проходов по индексу не будет. В качестве теста можно создать такую же таблицу, как в листинге 1, а затем выполнить следующие SQL-операторы:

    create or replace function my_fun (
      i1 in number,
      i2 in number
    ) return number deterministic
    as
    begin
      dbms_output.put_line('Testing function');
      return i1 + i2;
    end;
    /
    
    create index t2_idx on t2(my_fun(id_gp,id_p));
    
    update t2 set id_gp = id_gp where rowid = '&m_rid';
    
    update t2 set id_gp = id_gp + 1 where rowid = '&m_rid';
    

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

    Целостность ссылок

    Вот тут, вероятно, и наступает решающий момент для систем оперативной обработки транзакций (ООТ - OLTP). Их ждет двойной удар - сначала в подчиненной таблице, а потом и в главной.

    Возьмите таблицу из листинга 1 и вставьте в нее еще 9 одинаковых строк, чтобы всего их стало 10. Затем выполните следующие тесты и проверьте объем логического ввода/вывода и т.п.:

    update t2 set id_gp = id_gp;
    
    10 rows updated.
    
    alter table t1 
    add constraint t1_pk primary key (id_gp);
    
    alter table t2 
    add constraint t2_fk_p1 foreign key (id_gp) references t1;
    
    update t2 set id_gp = id_gp;
    10 rows updated
    

    Вы обнаружите, что количество прочитанных блоков db block gets (current mode gets) увеличится на 10 после добавления ограничения целостности. Почему? Потому что при каждом обновлении сервер Oracle проверяет ограничение внешнего ключа, и делает это путем просмотра индекса по первичному ключу в главной таблице с помощью current mode gets. Если главная таблица будет достаточно большой, может потребоваться три current mode gets для каждого избыточного обновления столбца в подчиненной таблице.

    Теперь перейдем к проблемам главной таблицы. Достаточно только попытаться выполнить обновление "без изменения" строки главной таблицы, если нет индекса по внешнему ключу, и вы обнаружите печально известную блокировку TM/4. Индексы по внешним ключам не обязательны, если значения первичного ключа не изменяются и не удаляются, но если вы сталкиваетесь со случайными "зависаниями" и сообщениях о взаимных блокировках, то, вероятно, вы столкнулись с классической проблемой, - вы сами первичные ключи не обновляете, а вот генератор приложений за кадром это делает.

    Компромисс будет всегда

    Вы могли уже решить, что пора переписывать массу кода. Но, написание кода, генерирующего идеальный SQL-оператор каждый раз, повышает вероятность ошибок. Компромисс между повышенным риском ошибки (а также временем на кодирование, тестирование и отладку) и производительностью всегда будет, так что, если сервер далек до полной загрузки, вполне допустимо и обоснованно будет игнорировать все описанные выше проблемы. По крайней мере, в краткосрочной перспективе.

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

    Теоретически, если в таблице есть N столбцов, тогда разных операторов update может быть power(2,N) - 1, и это если ограничиться только однострочными обновлениями по rowid. Если не увеличить соответственно разделяемый пул и не настроить несколько параметров, вроде session_cached_cursors, может оказаться, что экономия в одном месте оборачивается дополнительными проблемами (такими как конфликты доступа к библиотечному кэшу) в другом.

    Заключение

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

    --

    Джонатан Льюис (Jonathan Lewis) - независимый консультант с более чем 17-летним опытом использования Oracle. Он специализируется на физическом проектировании баз данных и стратегии использования сервера Oracle. Джонатан - автор книги "Practical Oracle 8i - Building Efficient Databases", опубликованной издательством Addison-Wesley, и один из наиболее известных лекторов среди специалистов по Oracle в Великобритании. Подробнее о его публикациях, презентациях и семинарах можно узнать на сайте www.jlcomp.demon.co.uk, где также находится список ЧаВО The Co-operative Oracle Users' FAQ по дискуссионным группам Usenet, связанным с СУБД Oracle.


    Эта статья первоначально была опубликована на сайте DBAzine.com, сетевом портале, посвященном проблемам различных СУБД и их решениям. Перевод публикуется с разрешения автора.


     


    ХАЙВЕЙ - лучший российский хостинг-провайдер: хостинг, регистрация доменов, услуга Ваша@почта, поддержка 24 часа


    NetPromoter - единственный российский профессиональный комплекс программ и сервисов для раскрутки сайта и интернет-статистики


    STSS - известный поставщик надежных серверных решений различного назначения на платформе Intel (Xeon) и AMD.


    5-55: the ITIL company. Практический опыт и теоретические знания на лучших семинарах по ITIL и процессам ITSM.


    Подписка на новости IT-портала CITForum.ru
    (библиотека, ftp-архив CITKIT.ru)

    Новые поступления в on-line библиотеку:

    28 апреля

  • Выбор первого дистрибутива Linux: Пособие для начинающих
  • Обфускация и защита программных продуктов
  • Анализ и оптимизация циклов с помощью производящих функций
  • Стратегии объектно-реляционного отображения: систематизация и анализ на основе паттернов

    26 апреля

  • Business Intelligence обещает значительный рост в 2005 году
  • Десять основных тенденций 2005 года в области Business Intelligence и Хранилищ данных
  • Управление эффективностью бизнеса и предсказуемость
  • Увеличение эффективности бизнеса: пять ошибок управления, которых следует избегать
  • Потребность в организационных данных: модель комплексного управления эффективностью бизнеса
  • Технология Хранилищ данных для государственных учреждений
  • Оцените, насколько совершенно ваше Хранилище данных

    21 апреля

  • Исполнение моделей при помощи виртуальной машины
  • Параллельные алгоритмы компьютерной алгебры
  • От стандарта до стандарта (о стандартизации оптических разъемов)
  • За штурвалом IP-станции

    Продолжение дискуссии читателей:

  • Линукс и пользователи, или что мне не нравится в Linux
  • Еще один взгляд на альтернативные ОС (и софт для них)
  • О некомпетентности пользователя Windows
  • Переписка Долгачева В.С. и Монахова В.В.

    19 апреля

  • Межпротокольный шлюз NAT-PT с функциями DNS-ALG и FTP-ALG для обеспечения взаимодействия между сетями IPv4 и IPv6
  • Рефакторинг архитектуры программного обеспечения: выделение слоев
  • Комбинаторика слов и построение тестовых последовательностей
  • Функциональное тестирование Web-приложений на основе технологии UniTesK

    14 апреля

  • Как организовать двойную парольную защиту данных в Oracle
  • Деревянный интерфейс

    Продолжение дискуссии читателей:

  • Microsoft против мира
  • Впечатления от прочитанного

    12 апреля

  • Крупные проблемы и текущие задачи исследований в области баз данных
  • Глава 2 из книги Т.Кайта "Oracle для профессионалов"Архитектура

    Дискуссия читателей о Linux и Windows:

  • Деньги правят миром, и у кого их больше, тот и прав!
  • О злокозненности некомпетентных пользователей, или почему я не люблю ограниченных пользователей Windows

    7 апреля

  • О доблести Билла Гейтса, или почему Windows лучше, чем LINUX или Mac OS
  • Витая пара - все ли так просто?!
  • Выбираем сервер печати
  • Один слой хорошо, а два - лучше (о пишущих DVD-приводах)

    5 апреля

  • Использование Caché SQL Gateway
  • Глава 19 из книги Т.Кайта "Oracle для профессионалов"Хранимые процедуры на языке Java
  • Что такое PostgreSQL?
  • Обновлен PostgreSQL FAQ

    31 марта

  • Использование Веб-сервисов в Caché
  • Защита на уровне строк (Oracle)
  • Секции в реальном мире

    29 марта

  • Разработка успешных приложений для Oracle - первая глава из книги Тома Кайта "Oracle для профессионалов"
  • Web-сервисы: растущие опасения (мнение аналитиков IDC)
  • Технология OLAP - мощная альтернатива электронным таблицам
  • Какой модной стала подготовка отчетности

    24 марта

  • Многоверсионность данных и управление параллельными транзакциями
  • Исключение из правил. Опыт разработки и внедрения финансовой корпоративной системы
  • Обнаружение компрометаций ядра Linux с помощью gdb
  • Корпоративная сервисная шина - "бюджетный" подход к решению задач интеграции
  • Сервис-ориентированная архитектура
  • Бизнес-процессы и XML

    22 марта

  • Доступно. И точка! (обзор точек беспроводного доступа)
  • Коммутаторы Fast/Gigabit Ethernet для "большой" сети
  • Push to Talk: нажми на кнопку и ...говори
  • Сети нового поколения и технология softswitch

    17 марта

  • Часто задаваемые вопросы о proxy (proxy FAQ)
  • Самонастраивающаяся база данных: управляемые приложения и настройка SQL
  • Еще раз о волоконных трассах
  • Настраиваем русский Unicode в FreeBSD-5.3.

    10 марта

  • Еще не сказанное о волоконной оптике
  • Wi-Fi на службе оператора
  • Пора менять платформу?
    (о сокетах LGA775 и PGA478)

    Oracle:

  • Детальный аудит для практических целей
  • Шифруем свои ресурсы данных

    3 марта

  • Требования к проекту. Классификация - первый шаг к пониманию
  • Gtk vs. Qt: драки не будет
  • Управление бизнесом "по максимуму": BPM для финансовых учреждений
  • Реализация решения по управлению эффективностью бизнеса
  • Новые SerialATA-винчестеры
  • Карман для сервера

    1 марта

  • Выбрать корпус - нет ничего проще?
  • Создание виртуальной сети с удаленной загрузкой узлов
  • Текущее состояние и перспективы развития рынка интеграционных технологий
  • Интеграция корпоративной информации: новое направление
  • Архитектурные подходы к консолидации

    24 февраля

  • Каждому проекту своя методология
  • Императив интеграции
  • Безопасность IP-телефонии - полевые зарисовки
  • О злокозненности Билла Гейтса, или почему я не люблю Windows

    22 февраля

  • Oracle10: шифруем данные
  • В версии Oracle10 "виртуальные частные базы данных" данных стали избирательнее
  • Каждому (пользователю) свое (данное в таблице)
    Часть 1
    Часть 2
  • Ускоряем интернет
  • Сетевая аутентификация на практике
  • В фокусе Microsoft Virtual Server 2005

    17 февраля

    Открыт новый раздел
    Все об Open Source

    Все новости >>>



  • IT-консалтинг Software Engineering Программирование Open Source СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей PR-акции, размещение рекламы - pr@citforum.ru, тел. +7 095 4119920 Пресс-релизы - manager@citforum.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
    Copyright © 1997-2000 CIT, © 2001-2004 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...