Документация Oracle на русском языке





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

Главная :: Карта


Oracle Database или Oracle RDBMS — объектно-реляционная система управления базами данных компании Oracle.



 

DeepEdit!

Программирование баз данных на Oracle, техническая документация, литература, статьи и публикации

  • Увеличить размер шрифта
  • Размер шрифта по умолчанию
  • Уменьшить размер шрифта

Избыточные ограничения в спецификации

збыточные ограничения в спецификации


Мы обсудили проблемы надежности, обусловленные неоднозначностью спецификаций. Спецификации, страдающие излишней подробностью, ничуть не лучше. Чрезмерная детализация требований часто приводит к тому, что спецификация противоречит цели оптимизации. Спецификация, содержащая определенные требования к повышению произво­дительности программы одновременно с повышением на 10 пунктов коэффициента попаданий в кэш буферов, может оказаться просто не­выполнимой. Вполне может получиться так, что повышение произво­дительности определенной программы приведет к резкому снижению коэффициента попаданий в кэш для системы в целом. Соответствую­щий пример приведен в [Millsap (2001b)].
Еще один забавный случай имел место, когда я работал в Oracle. Спе­цификация производительности требовала, чтобы в некотором кли­ент-серверном приложении переход с одного поля формы на другое за­нимал не более 0,5 секунды. Далее шло требование о расположении клиента системы в Сингапуре, а сервера - в Чикаго. Более того, специ­фикация запрещала модификацию имевшегося приложения, которое выполняло в среднем шесть синхронных обращений к базе данных по глобальной сети (WAN) для каждого поля.
Цель в том виде, как она была поставлена в спецификации, была недос­тижима в силу избыточных ограничений. Фактически она противоре­чила физическим законам нашей вселенной. Нет никакой возможно­сти за полсекунды шесть раз передать сообщение по сети из Сингапура в Чикаго и обратно. Даже при исключении всех составляющих време­ни отклика, за исключением минимального теоретически возможного времени распространения сигнала с максимальной теоретически воз­можной скоростью (т. е. без учета всех задержек в кабелях, концентра­торах, маршрутизаторах, базах данных и т. д.), шестикратное прохож­дение сигнала туда и обратно заняло бы не менее 0,6 секунды.
Доказательство: Допустим, что на время перехода от поля к полю не оказы­вают влияния никакие факторы, кроме скорости света. Скорость света в вакууме составляет приблизительно 299 792 458 метров в секунду. Рас­стояние между Сингапуром и Чикаго по поверхности Земли приблизитель­но 15 000 000 метров. Следовательно, расстояние пройденное при шести за­просах составит 2 х 6 х 15 000 000, т. е. приблизительно 180 000 000 метров для каждого поля. Из соотношения rt получаем d/r« 0,6 секунды на каждое поле. Если же учесть все отброшенные ранее факторы задерж­ки, время отклика будет еще больше. Следовательно, требования специфи­кации не могут быть выполнены. ЧТД.
Не существует способа выполнить требования спецификации, не осла­бив хотя бы одно из условий. Главный кандидат на сокращение - усло­вие, согласно которому переход к каждому полю должен сопровож­даться в среднем шестью обращениями клиента к серверу. Основной задачей этого проекта повышения производительности стало доказа­тельство того, что проект с такой спецификацией обречен на неудачу. До тех пор, пока доказательство не было представлено, люди продол­жали тратить время и деньги в погоне за недостижимой целью.
Хорошие проекты не рождаются из плохих спецификаций. Будь то не­четкая формулировка проблемы или невыполнимые условия в специ­фикации - в любом случае проект улучшения производительности не может быть основан на спецификации, содержащей ошибки.

 



jAntivirus