Функция анализа максимальных потоков предлагается для сети с единственным источником потока и единственной точкой стока. Для каждого соединения в потоковой сети существует связанная с ним пропускная способность. Цель этой функции состоит в том, чтобы найти максимальный допустимый поток, который может течь от исходного узла до узла стока. Такой тип анализа обычно приходится видеть при планировании сетей коммуникаций и логистики.
Моделирование, управление и анализ сетей являются стандартными задачами для геоинформационных систем (GIS). Анализ сети включает маршрутизацию (вычисление пути) в транспортных сетях, отслеживание доступности в коммунальных сетях и распределение ресурсов в задачах принятия решений и приложениях для управления отношениями с заказчиками (CRM). В этой статье мы представляем сетевую модель данных Oracle Spatial – опцию базы данных Oracle10g, которая позволяет пользователям моделировать и анализировать сети. Эта опция упрощает моделирование, анализ и управление сетями, так чтобы пользователи могли сосредоточиться на прикладной логике. Сетевая модель данных предлагает открытую, типовую модель данных, обладающую многими общеупотребительными возможностями анализа GIS. Кроме того, она полностью поддерживает объекты Oracle Spatial типа SDO_GEOMETRY. В этой статье обсуждаются приложения GIS, базирующиеся на сетевой модели данных Oracle Spatial.
Сетевая модель данных предлагает API для PL/SQL и Java для управления сетью, как на стороне клиента, так и в базе данных. API Java может быть также использован для анализа сети. Трехъярусная архитектура приложения для сетевой модели данных показана на
Источник: Официальный технический документ Oracle, Май 2005 г.,
Анализ сети GIS может включить мониторинг сети, маршрутизацию сети и распределение в сети.
До появления Oracle Spatial 10g Release 2 для редактирования и анализа сети мог использоваться только API Java для сетевой модели данных. Теперь появился и интерфейсный пакет PL/SQL, который помогает пользователям редактировать и анализировать сети в среде PL/SQL. Предлагаемый интерфейсный пакет обеспечивает почти те же функциональные возможности, что и API Java. Это достигается с помощью хранимых в базе данных процедур Java и виртуальной машины Java в Oracle.
В этом разделе объясняется использование сетевой модели данных. Есть три основных шага.
Ограничения являются условиями, которые должны быть удовлетворены во время анализа. Сетевая модель данных поддерживает сетевые ограничения, чтобы приложения могли во время анализа накладывать на сеть специфические для приложения условия. Интерфейс Java NetworkConstraint может быть реализован пользователем, и успешно передан в любую аналитическую функцию сетевой модели данных. Рисунок 9 показывает аналитическую информацию, которая доступна пользователям для реализации их сетевых ограничений.
Рисунок 9.Аналитическая информация для сетевых ограничений
Ниже приводятся некоторые примеры сетевых ограничений:
Глубина (количество соединений), стоимость и ограничения MBR
Сетевой анализ может быть ограничен на основании глубины пути поиска, предельного значения стоимости или области (минимальный ограничивающий прямоугольник), в которой происходит анализ. Эти ограничения могут использоваться для определения предпочтительного подмножества возможных решений. Сетевая модель данных предлагает для этих общеупотребительных сетевых ограничений класс SystemConstraint (являющийся реализацией класса NetworkConstraint). Пользователи могут создать экземпляр SystemConstraint и использовать его при анализе.
Временно инактивированные узлы или соединения
Иногда узлы или соединения должны быть временно выключены перед началом анализа, например, строящиеся или реконструируемые сегменты дороги для дорожной сети, или водяные краны (узлы), закрытые в водопроводной сети на ремонт. Вы можете сделать узел или соединение неактивными, устанавливая их состояние на false (ложь). Являющиеся неактивными сетевые элементы не будут рассматриваться во время анализа. Отметьте, что изменение состояния узлов и соединений не затрагивает постоянную модель данных.
Маршрутизация с определенными типами соединений и узлов
Иногда сетевой анализ должен проводиться только для узлов и соединений определенных типов или с определенными требованиями.
Ограничения поворота
Ограничения поворота – это ограничения, в которых задействованы два соединения. Они часто встречаются в маршрутизации для транспортных сетей. В следующем примере запрещенный поворот представлен начальным соединением и конечным соединением (см. ). Для пересечений с ограничениями поворота, типа “никакого поворота “U”” или “никакого левого поворота”, если поиск сталкивается с соединением начала запрещенного поворота, поиск не продолжается до конечного соединения этого запрещенного поворота. Такой тип ограничения может быть легко смоделирован, если использовать NetworkConstraint, так как информация о текущем соединении и следующем соединении сделана доступной для пользователей.
Представления сети на Java (сеть, узлы, соединения и пути) определяются, как Java-интерфейсы и поэтому могут быть расширены. Эти интерфейсы определяют для сети и ее элементов необходимое поведение. В дополнение к этим интерфейсам, приложения могут использовать определяемые пользователем функции анализа, позволяя расширить возможности моделирования и анализа сетевой модели данных.
Сетевая модель данных использует типовой подход к решению сетевых проблем, отделяя информацию о связности от специфической для приложения информации. На показано, как может быть смоделировано и проанализировано типичное сетевое приложение. Сначала информация о связности сети (стоимости подключения и соединения узлов) извлекается и отделяется от специфической для приложения информации. Если это необходимо, специфические для приложения атрибуты сохраняются: вместе с информацией о связности, или отдельно. Как только извлечена информация о связности, для типовой модели проводится сетевой анализ. Можно также учесть и дополнительные сетевые ограничения. Затем конечный результат отображается на связанные с приложением атрибуты и отображается. При таком подходе можно избежать использования настраиваемых сетевых решений и упростить управление данными для информации о связности и специфической для приложения информации.
Направленность соединения может быть дополнительно определена на уровне соединения. В отличие от направленности сети, которая определяет направления соединений, направленная сеть может иметь соединения, которые являются либо направленными, либо двунаправленными. К таблице соединений может быть добавлен столбец BIDIRECTED, который используется для того, чтобы указать, является ли направленное соединение двунаправленным. Это усовершенствование в моделировании приводит к сокращению требований к памяти для направленных сетей с негомогенными направлениями соединений (однонаправленные и двунаправленные).
Начиная с Oracle Spatial 10g Release 2, сетевая модель данных предлагает следующие опции:
Анализ распределения имеет дело с назначением целевых пунктов в пределах сети. Для представляющих интерес пунктов он обеспечивает информацию о зоне действия или охвате. Сетевая модель данных поддерживает следующие аналитические исследования распределения (см. ):
По стоимости: найдите все представляющие интерес пункты, находящиеся на некотором (не превышающем заданного) расстоянии от заданной точки. Самые близкие соседи: найдите N ресторанов, самых близких от заданной точки. Связующее дерево (сети) с минимальной стоимостью: найдите самый дешевый способ подключить все узлы.
Анализ маршрутизации, или вычисление пути (вероятно, наиболее изученная тема в сетевых приложениях), подразделяется на следующие категории:
Самый короткий путь или самый быстрый путь (проблема транзитивного замыкания) (см. рисунок 7). K самых коротких путей: найдите K самых коротких путей от начального узла до узла-адресата. Задача коммивояжера (см. рисунок 7): найдите маршрут с минимальной стоимостью, который проходит через набор заданных местоположений.
Рисунок 7.Самый короткий путь и задача коммивояжера
Приложения мониторинга сети имеют дело с запросами типа “Действительно ли узел A доступен из узла B?” или "Какие узлы являются доступными или могут быть достигнуты из данного узла?” Такие запросы часто встречаются в водопроводных или электрических сетях. При другом типе анализа мониторинга требуется узнать, сколько связных компонент имеется в сети. На показано некоторое количество таких запросов.
Загрузите сеть в объект сети Java. Проведите анализ сети. Если это необходимо, сохраните полученный в результате путь.
Редактор сетевой модели данных – это автономное Java-приложение, которое помогает создавать, редактировать и визуализировать сети. Редактор поддерживает операции просмотра, типа панорамирования, изменения масштабов изображения (крупные планы) и автоматической подгонки размеров изображения. Кроме того, он предлагает функции для навигации между элементами сети. В редакторе поддерживаются все аналитические функции. Используя редактор, пользователи могут на стороне клиента буквально на пустом месте создать сеть и сохранить ее в базе данных. Конфигурацию редактора можно перестраивать в том, что касается стилей, цветов и размеров элементов. На рисунке 5 показан редактор сетевой модели данных.
Рисунок 5.Редактор сетевой модели данных
Сетевая модель данных состоит из двух частей: схема сети и сетевые API. Схема сети – это постоянное хранилище данных, используемое для хранения сетевой информации. Сетевые API содержат PL/SQL-пакет для управления данными в базе данных и API Java для управления данными и их анализа на стороне клиента (через драйверы JDBC Java).
Сетевые метаданные обеспечивают общую информацию о сетях. В нее включены следующие детали о сети:
Направленная или ненаправленная Логическая или пространственная Иерархическая или одноуровневая (простая) Информация об узлах, соединениях и путях Геометрическая информация – для пространственных сетей
Сетевая модель данных вводит концепцию сетевых ограничений, в которой предлагает механизм ведения сетевого анализа. Например, вы можете пожелать вычислить кратчайший путь, который проходит через сетевые соединения только определенного типа. Используя сетевые ограничения, приложения могут легко включить в механизм анализа сетевой модели данных специфическую для приложения логику, не зная, как этот механизм работает. Также в анализ могут быть включены другие ограничения, типа глубины пути или его стоимости. Сетевое ограничение – это Java-интерфейс, который должен быть реализован приложением.
Сеть Oracle содержит две таблицы: таблицу узлов и таблицу соединений. В случае необходимости может быть добавлена таблица путей. На показана схема сетевой модели данных, включающей эти таблицы. Схема предоставляет информацию, необходимую для управления сетью и ее анализа. К этим таблицам могут быть добавлены прикладные атрибуты, или на них можно сослаться из других прикладных таблиц (посредством внешних ключей). Следует отметить, что сетевая модель данных также способна обрабатывать и геометрическую информацию. Таким образом, сетевая модель данных может представлять и логические, и пространственные сетевые приложения. Добавление к логической сети геометрических данных позволит отображать и логические сети.
Сеть содержит сетевые метаданные, таблицу узлов и таблицу соединений. Кроме того, если это желательно, вместе с сетью может быть сохранена информация о пути (таблица пути и таблица соединений пути). На показано схематическое представление сети в базе данных. Отметьте, что в ней сохранена только информация о связности. Дополнительная прикладная информация может быть сохранена в сетевых таблицах, или в других таблицах, и ссылки на нее реализуются с помощью внешних ключей.
Создайте и заполните сетевые таблицы и добавьте в базу данных метаданные. Создайте для сети Java-объект, используя API Java, и сохраните его в базе данных.
Oracle Spatial Topology and Network Data Models, Oracle Corporation.
(Топология Oracle Spatial и сетевые модели данных) Oracle Spatial User’s Guide and Reference, Oracle Corporation.
(Руководство пользователя и справочник по Oracle Spatial) Oracle Linear Referencing System: A Technical White Paper, Oracle Corporation.
(Система отсчета Oracle Linear) Oracle Spatial Network Data Model: An Oracle Technical White Paper, Oracle Corporation (Сетевая модель данных Oracle Spatial)
Building GIS Applications Using the Oracle Spatial Network Data Model: An Oracle Technical White Paper
May 2005
Author: Jack Chenghua Wang
Contributors: Vishal Rao, Nicole Alexander
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
Copyright © 2005, Oracle. All rights reserved.
This document is provided for information purposes only and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed orally or implied
in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any
liability with respect to this document and no contractual obligations
are formed either directly or indirectly by this document. This document
may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle, JD Edwards, and PeopleSoft are registered trademarks of
Oracle Corporation and/or its affiliates. Other names may be trademarks
of their respective owners.
Поставка пространственной сетевой модели данных началась с базы данных Oracle10g. Предварительно в базу данных загружается PL/SQL-пакет, требующий, чтобы в наличии имелись файлы Java.jar; API Java поддерживают JDK (или JRE) версии 1.3 или более поздних версий. Кроме того, включен редактор сети, как инструмент для обслуживания сетевой модели данных. Для получения дополнительной информации, см. руководство Oracle Spatial Topology and Network Data Models.
Загрузите сеть из базы данных или XML-представления. Визуализируйте или редактируйте Java-объект сети, используя редактор сетевой модели данных. Если необходимо, сохраните сеть в базе данных.
В сетевой модели данных поддерживаются следующие аналитические исследования:
Самый короткий путь: кратчайший путь от узла A к узлу B Анализ доступности: действительно ли узел A доступен из узла B? Связующее дерево (сети) с минимальной стоимостью: каким будет дерево с минимальной стоимостью, соединяющее все узлы сети? Анализ предельной стоимости: какие узлы находятся (при заданной стоимости) в пределах достижимости для заданного узла? Ближайшие соседи: какие узлы входят в число N самых близких соседей данного узла? K кратчайших путей: какие K путей от узла A к узлу B являются кратчайшими? Анализ связных компонент: пометьте связные компоненты идентификаторами (ID). Операции с графами: объединение, пересечение и разность графов. Задача коммивояжера: определите маршрут с минимальной стоимостью, в результате которого будут посещены все города из заданного набора? Анализ максимальных потоков для единственного источника и единственного стока: каков максимальный допустимый поток, который может течь от исходного узла до узла стока? (Oracle Spatial 10g Release 2)
Oracle Spatial 10g Release 2 представляет eLocation Quick Start. Location service Java и XML APIs позволяют разработчикам приложений быстро и легко применять картографию, геокодирование и маршрутизацию как "новенькие", на основании данных, хранящихся в Oracle Spatial. API поставляется с примером HTML-интерфейса, позволяющего быстро начать создание приложений, связанных с определением направления движения, картографией и геокодированием. API для геокодирования и маршрутизации из Oracle Spatial может использоваться Oracle Application Server MapViewer, многими средствами картографии, предоставляемыми третьими фирмами, или пользовательскими приложениями.
Демонстрационные данные доступны в режиме реального времени. Наборы данных в формате, поддерживаемом Oracle Spatial 10g, также доступны у лидирующих поставщиков данных. Посетите сайт www.oracle.com/technology/products/spatial/ для получения более подробной информации.
Геокодирование, это процесс увязки географических ссылок, таких как адресов и почтовых кодов, с координатами местонахождения (долгота и широта). В Oracle Spatial, опции Oracle Database 10g, предоставляется полнофункциональный механизм геокодирования. Она предоставляет международную адресную стандартизацию, геокодирование и соответствие POI путем запроса геокодированных данных, хранимых в Oracle Database. Поддержка уникального неразобранного адреса добавляет гибкости и удобства прикладным приложениям.
Предоставляется PL/SQL API для геокодирования.
Новинка в 10g Release 2: Механизм геокодирования теперь поддерживает обратное геокодирование, пакетное геокодирование, и другие новые подпрограммы геокодирования.
Масштабируемый механизм маршрутизации предоставляет управление расстоянием, временем и направлением между адресами (или местонахождениями, которые были предварительно геокодированы). Он предоставляется в виде клиентской библиотеки на Java, которая может легко применяться как в Oracle Application Server или в отдельной среде OC4J.
Другие возможности включают: предпочитаемый самый быстрый или самый короткий маршрут, с кратко или детально описанными направлениями, а также временем и расстоянием в уличной сети от одного места до нескольких пунктов назначения.
Новинка в 10g Release 2: Механизм маршрутизации Spatial теперь расширен и предоставляет возможность определения расстояния до места назначения, времени и направлений между адресами для дюжины стран Западной Европы и более, включая Германию, Великобританию, Францию, и другие. Эти расширения делают возможной логистику, транспортировку и примененние пространственных сервисов, предоставляющих информацию о местонахождении объектов, и позволяют оказывать услуги по построению направления передвижения в этих странах.
Источник: корпорация Oracle, An Oracle White Paper, август 2005,
Oracle работает в направлении применения, управления, обеспечения и поддержки самых современных открытых стандартов в области пространственных сервисов и услуг, основанных на информации о местонахождении объектов.
Oracle является важным членом Open Geospatial Consortium (OGC) и активно участвует в Техническом Комитете. Oracle Spatial 10g Release 1 (10.1.0.4) скомпилирован с OpenGIS Simple Features Specification for SQL, Revision 1.1, Types and Functions Alternative. Oracle также поддерживает новый OGC Geographic Markup Language (GML), а также интерфейсы Open Location Service. Объектно-реляционная модель, используемая для хранения геометрических форм с помощью Oracle Spatial, также соответствует спецификациям представлений точек, линий, и многоугольников в SQL92.
ПОДДЕРЖКА ЛИДИРУЮЩИМИ ПОСТАВЩИКАМИ ГИС И СЕРВИСОВ, ОСНОВАННЫХ НА ИНФОРМАЦИИ О МЕСТОНАХОЖДЕНИИ ОБЪЕКТОВ
Oracle Spatial непосредственно взаимодействует с лидирующими поставщиками технологий GIS и сервисов, основанных на информации о местонахождении объектов. Уровень партнерской поддержки предоставляет разработчикам выбор наилучших из созданных инструментов, соответствующих их требованиям. С помощью Oracle Spatial 10g и инструментов, предоставляемых партнерами, разработчики могут быстро применять масштабируемые, обеспечивающие безопасность промышленные решения для GIS и пространственных сервисов.
Перечень партнеров см. в www.oracle.com/technology/products/spatial (нажмите “Partners”, под “Quick Picks”).
Oracle Spatial включает тип данных, который управляет геозависимыми растровыми образами (спутниковые изображения, удаленно воспринимаемые данные, координатные данные) в Oracle Database 10g. GeoRaster в Oracle Spatial предоставляет геозависимые образы; XML-схему для управления метаданными; и основные операции, такие как наложение, наклон и расслоение. Приложения в области охраны окружающей среды, оборонной/государственной безопасности, исследований в области энергетики и спутниковые порталы изображений могут извлечь пользу из этой мощной функциональности.
Новое в 10g Release 2: GeoRaster теперь поддерживает промышленный стандарт сжатия растра (изображения и ячеечных, или "сеточных") данных, включая JPEG (с потерей) и DEFLATE (без потери) стандарты. Другие пользовательские способы сжатия поддерживаются с помощью plugin-ов третьих фирм. Все функции GeoRaster, которые могут выполняться на несжатых GeoRaster объектах, могут выполняться и над сжатыми объектами. Удаленное распознавание образов преобразуется в очень большие наборы данных, растущие со скоростью терабайтов и более в день. Способность хранить и управлять этими изображениями в сжатом виде, это основное требование пользователей и администраторов баз данных. Потребители экономят деньги на стоимости памяти, когда размеры изображений уменьшаются до 80%. Это важно для приложений в области защиты/безопасности, сельского хозяйства и мониторинга качества окружающей среды.
Более подробную информацию о GeoRaster смотрите в отдельных документах Oracle White Paper на www.oracle.com/technology/products/spatial.
Oracle Spatial поддерживает хранение "измерительной" информации, связанной с линейной геометрией. Это позволяет связывать множество атрибутов или событий с некоторым сегментом линейной геометрии. Атрибуты и события хранятся в таблицах отдельно от геометрической фигуры, а сама геометрическая фигура может не дублироваться в таблице атрибутов. Линейная зависимость часто используется в транспорте для моделирования дорог и железных дорог и их параметров; коммунальными службами для моделирования каналов поставки нефти и газа и их параметров; поставщиками телекоммуникационных услуг.
Для манипулирования линейно-зависимой геометрией имеются такие функции, как, например, вырезание части линейных элементов топологии, соединение линейных элементов топологии и разделение линейных элементов топологии.
Полная геометрическая модель Земли принимает во внимание изгиб земной поверхности, когда выполняются вычисления геодезических данных. Таким образом, функции Oracle Spatial возвращают длину и площадь как проектных, так и геодезических данных. Oracle поддерживает более 30 наиболее распространенных единиц измерения расстояния и площади, таких как фут/квадратный фут, метр/квадратный метр, километр/квадратный километр, и т.п.
SQL уже достаточно долго поддерживает функции, которые используются для агрегирования результатов SQL-запроса. Функции пространственного агрегирования оперируют набором геометрических фигур, а не только одной или несколькими фигурами. Функция агрегирования выполняет некоторую агрегирующую операцию над набором входных геометрических фигур и возвращает единственный геометрический объект. Например, следующее предложение возвращает границу штата Теннесси, сгенерированную из всех округов Теннесси:
select sdo_aggr_union(sdoaggrtype(geom,0.5)) state from geod_counties where state_abrv='TN';
Поддерживаются и другие функции агрегирования, включающие объединение, центроиды и выпуклые оболочки; пользователи могут также создать свои функции агрегирования. Использование пространственного агрегирования улучшает производительность и упрощает кодирование.
Серверные возможности пространственного анализа включают классификацию, преобразование бинарного вида, ассоциирование и пространственную корреляцию – важны для коммерческих приложений.
Более подробную информацию о пространственных аналитических функциях смотрите в отдельных документах Oracle White Paper на www.oracle.com/technology/products/spatial .
Oracle Spatial предоставляет функции, которые выполняют геометрические вычисления, такие как вычисление площади многоугольника и периметр. Эти функции могут использоваться, например, для определения общей площади всех округов, граничащих с Passaic County (округом Пассейик), протяженности межштатных магистралей или длины границы штата.
Функции Oracle Spatial могут также генерировать новые конфигурации, такие как: буферы, объединения, пересечения и другие. Они могут использоваться, например, для описания региона продаж с помощью создания буфера длиной 5 миль вокруг всех точек продаж, поиска геометрического представления объединения двух регионов продаж или поиска пересечения двух регионов продаж.
Примечание 1. Oracle Locator – это механизм Oracle Database 10g (Standard Edition, Standard Edition One и Enterprise Edition), предоставляет основные пространственные возможности для бизнес-приложений и партнерских ГИС-приложений. Возможности включают хранение векторных данных и управление ими, индексирование, пространственный анализ взаимосвязей, поддержку систем координат (включая поддержку EPSG-модели), и другие.
Примечание 2. За описанием возможностей Oracle Locator, обращайтесь, пожалуйста, к публикациям “Oracle Locator: Location-Enabling Every Oracle Database” - техническое описание [перевод публикуется в этом выпуске OM/RE] и “Oracle Spatial Option and Oracle Locator” - краткая характеристика продукта [перевод публикуется в этом выпуске OM/RE]. Для полноты смотрите, пожалуйста, подробные листинги с возможностями Oracle Locator и Oracle Spatial в Приложении B в публикации “Oracle Spatial User’s Guide” и “Reference 10g Release 2(10.2)”.
Эта модель данных предоставляется для хранения сетевой структуры (графа) в Oracle Database 10g. В ней явно хранится и устанавливается соединение связанных узлами сетей и обеспечивается сетевой анализ такой, как наикратчайший путь и возможность соединения. К приложениям, которым требуются сетевые решения, относятся приложения для обеспечения транспортировки, транзита, приложений для коммунальных служб и медико-биологических учреждений (анализ биохимический путей).
Новинка в 10g Release 2: Сетевая модель данных теперь включает: PL/SQL-интерфейс для создания, редактирования и анализа сетевых данных; улучшенное моделирование данных для описания двунаправленных связей; функцию поиска максимального возможного потока от источника до конечного узла, возможность создания и использования сетевых ограничений целостности; и возможность указания стоимости с помощью PL/SQL-функции.
Более подробную информацию о сетевой модели данных Oracle Spatial ищите в отдельных документах Oracle White Paper на www.oracle.com/technology/products/spatial.
Oracle Spatial включает модель данных и схему, которые постоянно хранят топологию деталей рельефа и строгие требования к целостности данных карты и уровней карты. Другое достоинство в том, что топологические запросы обычно выполняются быстрее для запросов, входящих в такие отношения, как смежность, соединяемость и вхождение. Эти возможности полезны поставщикам систем землеустройства (кадастровых) и поставщикам пространственных данных.
Новинка в 10g Release 2: В базе данных теперь поддерживаются пространственные транзакции уровня деталей ландшафта с постоянной топологией. В предыдущей версии для вставки или изменения всех узлов, границ и элементов внешнего вида деталей ландшафта требовалось множество операций; теперь вставка или изменение деталей ландшафта выполняется как одна операция. Это существенно упрощает процесс обновления и поддержки наборов данных и уменьшает требуемый код.
Упрощен процесс экспорта топологии и импорта ее в целевую базу данных. Новые операторы, функции и процедуры делают топологическую модель данных еще более гибкой и простой в использовании.
Изменим обстоятельства запуска запроса, индексировав таблицу. План должен поменяться. Однако при включенном (по умолчанию) управлении планами мы этого не увидим. Примечательно, что убедиться в этом удастся только со второй попытки:
SQL> CONNECT scott/tiger Connected. SQL> create index emp_ename on emp ( ename );
Index created.
SQL> SELECT job FROM emp WHERE ename = 'MILLER';
JOB --------- CLERK
SQL> @showplan
PLAN_TABLE_OUTPUT --------------------------------------------------------------------
SQL_ID a7zgruuhu1nkf, child number 3
An uncaught error happened in prepare_sql_statement : ORA-01403: no data found
NOTE: cannot fetch plan for SQL_ID: a7zgruuhu1nkf, CHILD_NUMBER: 3 Please verify value of SQL_ID and CHILD_NUMBER; It could also be that the plan is no longer in cursor cache (check v$sql_plan)
8 rows selected.
SQL> SELECT job FROM emp WHERE ename = 'MILLER';
JOB --------- CLERK
SQL> @showplan
PLAN_TABLE_OUTPUT --------------------------------------------------------------------
EXPLAINED SQL STATEMENT: ------------------------ SELECT job FROM emp WHERE ename = 'MILLER'
Plan hash value: 3956160932
---------------------------------- | Id | Operation | Name | ---------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS FULL| EMP | ----------------------------------
Первый раз оптимизатор построил новый план, с учетом индекса, но в SMB его не обнаружилось. Тогда оптимизатор занес план в историю и выполнил запрос по единственному в основной линии плану – старому. Со второго раза рабочая область в shared pool оказалась заведена, но запрос по-прежнему был отработан по единственному в основной линии старому плану. Если же управление планами отключить, СУБД отработает по более выгодному в этой версии оптимизатора новому плану:
SQL> ALTER SESSION SET optimizer_use_sql_plan_baselines = FALSE;
Session altered.
SQL> SELECT job FROM emp WHERE ename = 'MILLER';
JOB --------- CLERK
SQL> @showplan
PLAN_TABLE_OUTPUT ------------------------------------------------------------------
EXPLAINED SQL STATEMENT: ------------------------ SELECT job FROM emp WHERE ename = 'MILLER'
Plan hash value: 106684950
------------------------------------------------- | Id | Operation | Name | ------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS BY INDEX ROWID| EMP | | 2 | INDEX RANGE SCAN | EMP_ENAME | -------------------------------------------------
Процедура ALTER_SQL_PLAN_BASELINE позволяет устанавливать атрибутам ENABLED, FIXED и AUTOPURGE плана требуемые значения явочным порядком. Пример:
EXECUTE :retcode := DBMS_SPM.ALTER_SQL_PLAN_BASELINE - ( :sqlhandle, 'SYS_SQL_PLAN_38c100c08916fd8c', 'enabled', 'no' )
SELECT :retcode "Plans disabled:" FROM dual;
@baseline :sqlhandle
Теперь система управления планами снова откажется применять «новый» план к запросу, несмотря на его присутствие в основной линии планов – благодаря нерабочему состоянию.
Владимир Пржиялковский,
Преподаватель технологий Oracle
А мои ти куряни – сведоми къмети: подъ трубами повити, подъ шеломы възлелеяны, конець копия въскръмлени; пути имь ведоми, яругы имь знаеми, луци у нихъ напряжени, тули отворени, сабли изъстрени; сами скачють, акы серыи влъци въ поле, ищучи себе чти, а князю славе. |
Слово о полку Игореве
Далее приводится пример, где в обстоятельства выдачи приложением запроса вносятся изменения в виде добавленного индекса. Положим, мы не очень уверены, как это отразится на обработке запроса. Дабы не просчитаться с непредвиденной потерей эффективности, построим для него основную линию, включающую прежний проверенный план. Таким образом после добавления в БД индекса запрос заведомо не ухудшит производительности, но возможно улучшит.
Для примера подобран нереально простой запрос. Это сделано осознано воимя доходчивости изложения техники.
В примере будут переключения в схемы SCOTT и SYS, но предполагается, что работа выполняется в SQL*Plus без выхода из этой программы, что позволит сохранить значения переменных.
Очистим для предотвращения путаницы общую область курсоров в shared pool (технически это необязательно, но упростит здесь обращение к нужным данным в shared pool), заведем рабочие переменные и сбросим ради простоты показа в файл текст для выдачи плана последнего запроса:
CONNECT / AS SYSDBA ALTER SYSTEM FLUSH SHARED_POOL; VARIABLE retcode NUMBER VARIABLE sqltext VARCHAR2 ( 1000 ) VARIABLE sqlhandle VARCHAR2 ( 30 ) VARIABLE sqlid VARCHAR2 ( 13 ) VARIABLE report CLOB SELECT * FROM TABLE ( DBMS_XPLAN.DISPLAY_CURSOR ( format => 'basic' ) ) . SAVE showplan REPLACE
Предполагается, что основная линия запросов изначально пуста. Исходно план запроса не зависит от того, применяет оптимизатор управление планами, или нет:
SQL> CONNECT scott/tiger Connected. SCOTT> SELECT job FROM emp WHERE ename = 'MILLER';
JOB --------- CLERK
SQL> @showplan
PLAN_TABLE_OUTPUT --------------------------------------------------------------------
EXPLAINED SQL STATEMENT: ------------------------ SELECT job FROM emp WHERE ename = 'MILLER'
Plan hash value: 3956160932
---------------------------------- | Id | Operation | Name | ---------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS FULL| EMP | ----------------------------------
13 rows selected.
SQL> ALTER SESSION SET optimizer_use_sql_plan_baselines = FALSE;
Session altered.
SQL> SELECT job FROM emp WHERE ename = 'MILLER';
JOB --------- CLERK
SQL> @showplan
PLAN_TABLE_OUTPUT --------------------------------------------------------------------
EXPLAINED SQL STATEMENT: ------------------------ SELECT job FROM emp WHERE ename = 'MILLER'
Plan hash value: 3956160932
---------------------------------- | Id | Operation | Name | ---------------------------------- | 0 | SELECT STATEMENT | | | 1 | TABLE ACCESS FULL| EMP | ----------------------------------
Основную линию планов какого-нибудь запроса можно пополнять («развивать», evolve): вручную либо автоматически.
Ручное пополнение основной линии в результате запуска задания на проверку приемлемости плана выполняется функцией EVOLVE_SQL_PLAN_BASELINE и демонстрировалось выше.
Процедура LOAD_PLANS_FROM_SQLSET позволяет загружать основную линию планы из настроечного набора (SQL tuning set). Настроечный набор может быть получен любым доступным путем, например перенесен из другой БД, возможно даже из версии 10.
Процедуры PACK_STGTAB_BASELINE и UNPACK_STGTAB_BASELINE разрешают сохранить планы основных линий в специально созданной таблице и загружать их из такой таблицы.
Включение в сеансе параметра СУБД OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES в состояние TRUE вызовет автоматическое пополнение SMB планами запросов, поступающих из приложения. Для запросов приложения, основные линии планов которых желательно исключить из процедуры автоматического пополнения (то есть «зафиксировать»), можно использовать значение атрибута FIXED = 'YES' планов, составляющих соответствующую линию. Наличие планов с атрибутом FIXED = 'YES' препятствует только автоматическому пополнению и не сказывается на возможности добавлять планы вручную, по SQL ID и по настроечному набору.
Автоматическое пополнение основных линий также может осуществляться в результате «одобрения» (принятия) администратором профиля, рекомендованного для запроса советником SQL Tuning Advisor. По умолчанию этот советник запускается автоматическим заданием в «окошко поддержки» СУБД ежесуточно.
Путь попадания плана в основную линию обозначен в таблице DBA_SQL_PLAN_BASELINES в поле ORIGIN:
SQL> SELECT 2 sql_handle, plan_name, origin
3 FROM 4 dba_sql_plan_baselines SQL> ;
SQL_HANDLE PLAN_NAME ORIGIN ------------------------ ----------------------------- ------------ SYS_SQL_dd7adbcd38c100c0 SYS_SQL_PLAN_38c100c08916fd8c AUTO-CAPTURE
SYS_SQL_dd7adbcd38c100c0 SYS_SQL_PLAN_38c100c0d8a279cc MANUAL-LOAD
Ручное удаление плана из основной линии выполняется функцией DROP_SQL_PLAN_BASELINE.
По результату выполненых действий в основной линии планов для нашего запроса оказалось два плана: с учетом индекса (признак ACCEPTED = 'NO') и без учета (признак ACCEPTED = 'YES'):
SQL> CONNECT / AS SYSDBA SQL> @baseline :sqlhandle
PLAN_NAME SQL_TEXT ENABLED ACCEPTED ------------------------------ --------------- ---------- ---------- SYS_SQL_PLAN_38c100c08916fd8c SELECT job FROM YES NO
emp WHERE enam e = 'MILLER'
SYS_SQL_PLAN_38c100c0d8a279cc SELECT job FROM YES YES
emp WHERE enam e = 'MILLER'
Можно выдать оптимизатору задание проверить с планы признаками ACCEPTED = 'NO' (то есть учтеные в SMB, но не причисленые к приемлемым) на эффективность и включить их в основную линию (пометить как «приемлемые»), если они окажутся не хуже ранее там имевшихся:
BEGIN SELECT DISTINCT sql_handle INTO :sqlhandle FROM dba_sql_plan_baselines WHERE DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE ( :sqltext ) = signature; END; / EXECUTE :report := - DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE ( sql_handle => :sqlhandle )
Первую проверку изменений в SMB выполним по признаку ACCEPTED в справочной таблице:
SQL> @baseline :sqlhandle
PLAN_NAME SQL_TEXT ENABLED ACCEPTED ------------------------------ --------------- ---------- ---------- SYS_SQL_PLAN_38c100c08916fd8c SELECT job FROM YES YES
emp WHERE enam e = 'MILLER'
SYS_SQL_PLAN_38c100c0d8a279cc SELECT job FROM YES YES emp WHERE enam e = 'MILLER'
Вторую проверку выполним по содержимому переменной REPORT, составленному функцией EVOLVE_SQL_PLAN_BASELINE:
SQL> SET LONG 10000 SQL> SELECT :report "Baseline evolution results:" FROM dual;
Baseline evolution results: --------------------------------------------------------------------- --------------------------------------------------------------------- Evolve SQL Plan Baseline Report ---------------------------------------------------------------------
Inputs: ------- SQL_HANDLE = SYS_SQL_dd7adbcd38c100c0
PLAN_NAME = TIME_LIMIT = DBMS_SPM.AUTO_LIMIT VERIFY = YES COMMIT = YES
Рассматривается система управления планами (SPM), введенная в версии Oracle 11 применительно к повторяющимся запросам приложения. Она позволяет формировать и хранить для запросов допустимые наборы планов (baselines), заставить СУБД работать только по ним и тем самым избежать в отдельных случаях непредусмотренного падения производительности при обработке.
Технически основные линии планов в составе SMB хранятся в AWR в табличном пространстве SYSAUX, и регламент их хранения определяется внутренними проверками и автоматикой AWR. Этот регламент задается следующими характеристиками:
максимальным процентом данных SMB в пространстве SYSAUX (от 1 до 50%, исходно 10%); максимальным периодом отсутствия интереса к плану, после чего он будет автоматически удален (от 5 до 523 недель, исходно 53).
Узнать текущие характеристики регламента накопления и хранения SMB можно запросом:
SELECT parameter_name, parameter_value FROM dba_sql_management_config
;
Изменить эти характеристики можно процедурой CONFIGURE, например:
EXECUTE DBMS_SPM.CONFIGURE ( - parameter_name => 'space_budget_percent' - , parameter_value => 20 )
SPM позволяет формировать «базу управления запросами» (SQL management base, SMB). Она располагается в AWR (automatic workload repository) и может пополняться и вычищаться как вручную, так и автоматикой AWR. В SMB для каждого представляющего интерес запроса можно накапливать историю его планов (plan history), а из нее формировать основную линию (baseline) планов. Суть «основной линии» в том, администратор формирует ее из планов, которые полагает («назначает») удовлетворительно производительными. Управление планами обработки на деле начнется при переводе оптимизатора CBO в специальный режим «учета SPM» (SPM aware optimizer). Тогда ни при какой смене обстоятельств запуска запроса (или всего приложения) оптимизатор не применит к нему план, хуже имеющихся в «основной линии».
Режим учета SPM (использования основных линий планов) устанавливается значением TRUE параметра СУБД OPTIMIZER_USE_SQL_PLAN_BASELINES. Это значение умолчательное. Изменить его можно как на уровне СУБД, так и отдельных сеансов.
При поступлении в СУБД запроса, для него вырабатывается план. Далее, если OPTIMIZER_USE_SQL_PLAN_BASELINES = FALSE, запрос выполняется по этому плану. Если = TRUE, и план присутствует и в истории планов, и в основной линии, он также принимается к исполнению. Если же план отсутствует либо в истории, либо в основной линии, для исполнения запроса будет выбран наиболее «легкий» из имеющихся в основной линии. Но если план отсутствует в истории, он дополнительно будет туда занесен.
Содержимое SMB представлено в таблице DBA_SQL_PLAN_BASELINES. На деле это, конечно, виртуальная таблица, то есть view, показывающая данные из реальных таблиц SQLOBJ$, SQLOBJ$AUXDATA и SQL$TEXT в схеме SYS). Эти данные общесистемные, а потому аналогичных таблиц с префиксами USER и ALL не существует. Вот некоторые поля этой таблицы:
SIGNATURE | «Подпись» запроса, вычисляемая по нормализованному тексту запроса (см. функцию DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE). |
SQL_TEXT | Текст запроса. |
SQL_HANDLE | Символьное выражение подписи, ключ для удобства поиска планов основной линии. |
PLAN_NAME | Символьное выражение для обозначения плана. |
ENABLED | Признак нахождения плана в рабочем состоянии. Если установить = 'NO', оптимизатор будет этот план игнорировать. |
ACCEPTED | Признак того, что план включен в основную линию как приемлемый. |
FIXED | Если в основной линии есть планы, помеченные FIXED = 'YES', считается, что основная линия для запроса не подлежит автоматической перестройке, то есть является фиксированой. |
AUTOPURGE | Признак, разрешающий автоматическое удаление плана из SBM автоматикой AWR по прошествии установленного времени. |
OPTIMIZER_COST, EXECUTIONS, CPU_TIME и др. | Общие количественные показатели плана. |
Помимо этого сведения о базовой линии планов для запроса в текстовом виде предоставляет функция DISPLAY_SQL_PLAN_BASELINE из пакета DBMS_XPLAN.
Совершению действий с SPM служит пакет DBMS_SPM. Этот же пакет используется в OEM для графического доступа к его собственной функциональности.
Далее SPM рассматривается на примере употребления непосредственно программным образом.
Система управления планами в Oracle способна не только сохранить производительность при смене обстоятельств запуска запросов, но и преподать пользователю уроки.
Рассмотрим план для запроса SELECT DISTINCT … (далее все аналогично для запросов с UNION и GROUP BY). Как известно, в версиях до 9 включительно этот запрос обрабатывался с применением внутренней сортировки SORT UNIQUE. С версии 10 оптимизатор предлагает для такого запроса план с HASH UNIQUE, внутренней процедурой расстановки строк, с «хешированием». Большинство пользователей, обративших на это внимание, посчитали его целесообразным новшеством, улучшающим производительность отработки. Однако попытка применить для таких запросов управление планами (хотя бы ради сохранения производительности) заставляет в этом усомниться.
Действительно, попробуем в стиле вышеизложеного построить основную линию планов для другого отправного случая и другого запроса. Выдадим:
ALTER SESSION SET optimizer_features_enable = '9.2.0'; ALTER SESSION SET optimizer_mode = ALL_ROWS; SELECT DISTINCT job FROM emp;
Включим план в основную линию, как выше. Это будет план с SORT UNIQUE. Поменяем обстоятельства выдачи запроса, например:
ALTER SESSION SET optimizer_features_enable = '11.1.0.6.1'; SELECT DISTINCT job FROM emp;
Получится план с HASH UNIQUE. Однако попытка дополнить им основную линию планов запроса функцией EVOLVE_SQL_PLAN_BASELINE обречена. SPM не считает новый план, который дают версии 10+ для этого запроса, лучше прежнего!
Более пристальное изучение обнаруживает, что план с HASH UNIQUE имеет большую стоимость обработки (cost), нежели «старый» с SORT UNIQUE (10 единиц против 5), хотя с ростом размера таблицы этот проигрыш и сокращается.
Я не нашел объяснения этому явлению, однако если здесь нет подводных камней, система управления планами способна и в этом случае предотвратить неожиданый нежелательный рост трат на обработку.
Вот случай, достойный памяти и занесения в литературу!
Плиний Младший, Панегирик императору Траяну
Сейчас для интересующего нас запроса СУБД завела рабочую память в общей области курсоров в shared pool. Загрузим оттуда план (первый по счету) в основную линию в базе управления запросами SMB, сославшись на идентификатор курсора SQL ID:
CONNECT / AS SYSDBA EXECUTE :sqltext := q'[SELECT job FROM emp WHERE ename = 'MILLER']' EXECUTE – SELECT sql_id INTO :sqlid FROM v$sqlarea WHERE sql_text = :sqltext EXECUTE :retcode := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE ( :sqlid )
Проверка:
SQL> SELECT :retcode "Plans selected:" FROM dual;
Plans selected: --------------- 1
Для простоты последующих обращений к таблице DBA_SQL_PLAN_BASELINES за сведениями о SMB запомним в файле еще один рабочий запрос. Он параметризован ключом прикладного запроса, который узнаем по тексту запроса и поместим в переменную SQLHANDLE:
COLUMN sql_text FORMAT A15 WRAP COLUMN enabled FORMAT A10 COLUMN accepted FORMAT A10 SELECT plan_name, sql_text, enabled, accepted FROM dba_sql_plan_baselines WHERE sql_handle = &1 . SAVE baseline REPLACE SET VERIFY OFF
BEGIN SELECT DISTINCT sql_handle INTO :sqlhandle
FROM dba_sql_plan_baselines WHERE DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE ( :sqltext ) = signature; END; /
Проверка:
SQL> PRINT sqlhandle
SQLHANDLE -------------------------------- SYS_SQL_dd7adbcd38c100c0
SQL> @baseline :sqlhandle
PLAN_NAME SQL_TEXT ENABLED ACCEPTED ------------------------------ --------------- ---------- ---------- SYS_SQL_PLAN_38c100c0d8a279cc SELECT job FROM YES YES
emp WHERE enam e = 'MILLER'
Несмотря на то, что в нашем случае запрос попал в SMB по ссылке на SQL ID, в самой базе он идентифицируется ключом SQL_HANDLE, который автоматически порождается по подписи запроса, в свою очередь вычисляемой по нормализованому тексту. Это позволяет хранить план в AWR долговременно, независимо от того, представлен ли запрос вообще в курсорной области в данный момент, и под каким именно SQL ID представлен.
Обратите внимание, что использованный способ загрузки плана в основную лонию автоматически выставил признаки ENABLED и ACCEPTED в состояние 'YES', то есть единственный пока план в SMB и в рабочем состоянии, и включен в основную линию.