Базы данных Oracle - статьи


         

Анализ сети: анализ максимальных потоков


Функция анализа максимальных потоков предлагается для сети с единственным источником потока и единственной точкой стока. Для каждого соединения в потоковой сети существует связанная с ним пропускная способность. Цель этой функции состоит в том, чтобы найти максимальный допустимый поток, который может течь от исходного узла до узла стока. Такой тип анализа обычно приходится видеть при планировании сетей коммуникаций и логистики.



АННОТАЦИЯ


Моделирование, управление и анализ сетей являются стандартными задачами для геоинформационных систем (GIS). Анализ сети включает маршрутизацию (вычисление пути) в транспортных сетях, отслеживание доступности в коммунальных сетях и распределение ресурсов в задачах принятия решений и приложениях для управления отношениями с заказчиками (CRM). В этой статье мы представляем сетевую модель данных Oracle Spatial – опцию базы данных Oracle10g, которая позволяет пользователям моделировать и анализировать сети. Эта опция упрощает моделирование, анализ и управление сетями, так чтобы пользователи могли сосредоточиться на прикладной логике. Сетевая модель данных предлагает открытую, типовую модель данных, обладающую многими общеупотребительными возможностями анализа GIS. Кроме того, она полностью поддерживает объекты Oracle Spatial типа SDO_GEOMETRY. В этой статье обсуждаются приложения GIS, базирующиеся на сетевой модели данных Oracle Spatial.



API сетевой модели данных Oracle Spatial


Сетевая модель данных предлагает API для PL/SQL и Java для управления сетью, как на стороне клиента, так и в базе данных. API Java может быть также использован для анализа сети. Трехъярусная архитектура приложения для сетевой модели данных показана на



База данных Oracle 10g: Построение


Источник: Официальный технический документ Oracle, Май 2005 г.,



Базы данных Oracle - статьи


Анализ сети GIS может включить мониторинг сети, маршрутизацию сети и распределение в сети.



Интерфейсный пакет PL/SQL




До появления 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 (сеть, узлы, соединения и пути) определяются, как Java-интерфейсы и поэтому могут быть расширены. Эти интерфейсы определяют для сети и ее элементов необходимое поведение. В дополнение к этим интерфейсам, приложения могут использовать определяемые пользователем функции анализа, позволяя расширить возможности моделирования и анализа сетевой модели данных.



Моделирование сетевых приложений


Сетевая модель данных использует типовой подход к решению сетевых проблем, отделяя информацию о связности от специфической для приложения информации. На показано, как может быть смоделировано и проанализировано типичное сетевое приложение. Сначала информация о связности сети (стоимости подключения и соединения узлов) извлекается и отделяется от специфической для приложения информации. Если это необходимо, специфические для приложения атрибуты сохраняются: вместе с информацией о связности, или отдельно. Как только извлечена информация о связности, для типовой модели проводится сетевой анализ. Можно также учесть и дополнительные сетевые ограничения. Затем конечный результат отображается на связанные с приложением атрибуты и отображается. При таком подходе можно избежать использования настраиваемых сетевых решений и упростить управление данными для информации о связности и специфической для приложения информации.



Моделирование сети: направление соединений


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



НОВЫЕ ОПЦИИ В СЕТЕВОЙ МОДЕЛИ ДАННЫХ ORACLE SPATIAL 10G


Начиная с Oracle Spatial 10g Release 2, сетевая модель данных предлагает следующие опции:



Приложения для распределения в сети


Анализ распределения имеет дело с назначением целевых пунктов в пределах сети. Для представляющих интерес пунктов он обеспечивает информацию о зоне действия или охвате. Сетевая модель данных поддерживает следующие аналитические исследования распределения (см. ):

По стоимости: найдите все представляющие интерес пункты, находящиеся на некотором (не превышающем заданного) расстоянии от заданной точки. Самые близкие соседи: найдите N ресторанов, самых близких от заданной точки. Связующее дерево (сети) с минимальной стоимостью: найдите самый дешевый способ подключить все узлы.



Приложения маршрутизации сети


Анализ маршрутизации, или вычисление пути (вероятно, наиболее изученная тема в сетевых приложениях), подразделяется на следующие категории:

Самый короткий путь или самый быстрый путь (проблема транзитивного замыкания) (см. рисунок 7). K самых коротких путей: найдите K самых коротких путей от начального узла до узла-адресата. Задача коммивояжера (см. рисунок 7): найдите маршрут с минимальной стоимостью, который проходит через набор заданных местоположений.

Рисунок 7.Самый короткий путь и задача коммивояжера



Приложения мониторинга сети


Приложения мониторинга сети имеют дело с запросами типа “Действительно ли узел A доступен из узла B?” или "Какие узлы являются доступными или могут быть достигнуты из данного узла?” Такие запросы часто встречаются в водопроводных или электрических сетях. При другом типе анализа мониторинга требуется узнать, сколько связных компонент имеется в сети. На показано некоторое количество таких запросов.



Проведите анализ сети


Загрузите сеть в объект сети Java. Проведите анализ сети. Если это необходимо, сохраните полученный в результате путь.



РЕДАКТОР СЕТЕВОЙ МОДЕЛИ ДАННЫХ


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

Рисунок 5.Редактор сетевой модели данных



СЕТЕВАЯ МОДЕЛЬ ДАННЫХ ORACLE SPATIAL


Сетевая модель данных состоит из двух частей: схема сети и сетевые 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)



и приложения, имеющие дело как


Есть два общеупотребительных типа GIS-приложений: приложения, имеющие дело с пространственной близостью, и приложения, имеющие дело как с пространственной близостью, так и со связностью. Для многих приложений являются достаточными запросы о пространственной близости, в которых, главным образом, рассматриваются метрики типа Евклидовых или геодезических расстояний. Однако, имеются случаи, когда должны быть приняты во внимание вопросы связности, например, при отыскании наикратчайшего расстояния между двумя пунктами дорожной сети. Многие GIS-приложения являются сетями, которые требуют моделирования и анализа отношений между объектами (связности). На рисунке 1 показана дорожная сеть Нью-Йорка.

Рисунок 1.Дорожная сеть Нью-Йорка
(60384 узла, 151962 соединения. Источник: NavStreets от NavTech)
Начиная с выпуска 8.1.5, Oracle Spatial поддерживает пространственные объекты. Для управления базирующейся на пространственной близости информацией имеется полный набор индексов, операторов и функций. Сетевая модель данных расширяет Oracle Spatial, чтобы можно было иметь дело со связностью. В настоящее время есть много производителей GIS, предлагающих сетевые решения; однако, их решения могут иметь следующие проблемы:
Модель данных хранится в проприетарных (составляющих чью-то собственность) форматах файла, и не может быть объединена с базой данных заказчика. Модель данных и аналитические возможности не могут быть расширены. Прикладная информация не может быть отделена от информации о связности. Непосредственно не поддерживаются управление пространственной информацией и иерархические отношения.
Чтобы разрешить эти проблемы, сетевая модель данных Oracle Spatial делает следующее:
Обеспечивает открытую и постоянную сетевую модель данных. Сетевая модель данных хранится в базе данных как реляционные таблицы и управляется через SQL. Упрощает сетевую организацию и анализ данных
Предлагаются API PL/SQL и Java для сетевой организации и анализа данных.
Разделяет информацию и прикладная информация в модели данных


Информация о связности может быть отделена от прикладной информации. Управление и прикладной информацией, и информацией о связности происходит в базе данных. Однако, для анализа сети требуется только информация о связности.
Позволяет расширять модель данных и возможности анализа
API Java предлагает представления сетевых элементов как Java-интерфейсов. Пользователи могут определять свои собственные элементы сети, расширяя эти интерфейсы. В результате пользователи могут реализовать свои собственные (определяемые пользователем) представления и аналитические функции.
Интегрирует с технологией Oracle Spatial для управления пространственной информацией
Сетевая модель данных поддерживает все типы данных Oracle Spatial.
Эта статья организована следующим образом: в ней представлена схема базы данных для сетевой модели данных, ее API и архитектура; показано, как использовать модель данных; представлено несколько сетевых GIS-приложений, построенных поверх модели данных. Кроме того, в ней проводится обсуждение, как использовать для увеличения возможностей анализа сетевые ограничения, и как применяется редактор сетевой модели данных, используемый для редактирования и визуализации сети.

Сетевая модель данных Oracle Spatial,


Сетевая модель данных Oracle Spatial, доступная начиная с Oracle Spatial 10g, является родовой средой моделирования и анализа сетей (графов) для сетевых приложений. Были обсуждены приложения GIS для маршрутизации, мониторинга и распределения. Сетевая модель данных предлагает открытый, удобный в работе, масштабируемый, эффективный и управляемый подход к разработке сетевых приложений GIS. В настоящее время мы работаем с нашими заказчиками и партнерами над расширением возможностей моделирования и анализа сетевой модели данных.

ELOCATION QUICK START (ТОЛЬКО В 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/ для получения более подробной информации.



ГЕОКОДИРОВАНИЕ (УЛУЧШЕНО В 10G RELEASE 2)


Геокодирование, это процесс увязки географических ссылок, таких как адресов и почтовых кодов, с координатами местонахождения (долгота и широта). В Oracle Spatial, опции Oracle Database 10g, предоставляется полнофункциональный механизм геокодирования. Она предоставляет международную адресную стандартизацию, геокодирование и соответствие POI путем запроса геокодированных данных, хранимых в Oracle Database. Поддержка уникального неразобранного адреса добавляет гибкости и удобства прикладным приложениям.

Предоставляется PL/SQL API для геокодирования.

Новинка в 10g Release 2: Механизм геокодирования теперь поддерживает обратное геокодирование, пакетное геокодирование, и другие новые подпрограммы геокодирования.



МЕХАНИЗМ МАРШРУТИЗАЦИИ (УЛУЧШЕНО В 10G RELEASE 2)


Масштабируемый механизм маршрутизации предоставляет управление расстоянием, временем и направлением между адресами (или местонахождениями, которые были предварительно геокодированы). Он предоставляется в виде клиентской библиотеки на Java, которая может легко применяться как в Oracle Application Server или в отдельной среде OC4J.

Другие возможности включают: предпочитаемый самый быстрый или самый короткий маршрут, с кратко или детально описанными направлениями, а также временем и расстоянием в уличной сети от одного места до нескольких пунктов назначения.

Новинка в 10g Release 2: Механизм маршрутизации Spatial теперь расширен и предоставляет возможность определения расстояния до места назначения, времени и направлений между адресами для дюжины стран Западной Европы и более, включая Германию, Великобританию, Францию, и другие. Эти расширения делают возможной логистику, транспортировку и примененние пространственных сервисов, предоставляющих информацию о местонахождении объектов, и позволяют оказывать услуги по построению направления передвижения в этих странах.



Oracle Spatial 10g – опция обеспечения пространственных данных(Oracle Spatial 10g)


Источник: корпорация 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”).



ПОДДЕРЖКА ГЕОРАСТРА (УЛУЧШЕНА В 10G RELEASE 2)


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';

Поддерживаются и другие функции агрегирования, включающие объединение, центроиды и выпуклые оболочки; пользователи могут также создать свои функции агрегирования. Использование пространственного агрегирования улучшает производительность и упрощает кодирование.



ПРОСТРАНСТВЕННЫЕ АНАЛИТИЧЕСКИЕ ФУНКЦИИ (ВВЕДЕНО В 10G RELEASE 1)


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

Более подробную информацию о пространственных аналитических функциях смотрите в отдельных документах 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)”.



СЕТЕВАЯ МОДЕЛЬ ДАННЫХ (УЛУЧШЕНА В 10G RELEASE 2)


Эта модель данных предоставляется для хранения сетевой структуры (графа) в Oracle Database 10g. В ней явно хранится и устанавливается соединение связанных узлами сетей и обеспечивается сетевой анализ такой, как наикратчайший путь и возможность соединения. К приложениям, которым требуются сетевые решения, относятся приложения для обеспечения транспортировки, транзита, приложений для коммунальных служб и медико-биологических учреждений (анализ биохимический путей).

Новинка в 10g Release 2: Сетевая модель данных теперь включает: PL/SQL-интерфейс для создания, редактирования и анализа сетевых данных; улучшенное моделирование данных для описания двунаправленных связей; функцию поиска максимального возможного потока от источника до конечного узла, возможность создания и использования сетевых ограничений целостности; и возможность указания стоимости с помощью PL/SQL-функции.

Более подробную информацию о сетевой модели данных Oracle Spatial ищите в отдельных документах Oracle White Paper на www.oracle.com/technology/products/spatial.



ТОПОГРАФИЧЕСКАЯ МОДЕЛЬ ДАННЫХ (УЛУЧШЕНА В 10G RELEASE 2)


Oracle Spatial включает модель данных и схему, которые постоянно хранят топологию деталей рельефа и строгие требования к целостности данных карты и уровней карты. Другое достоинство в том, что топологические запросы обычно выполняются быстрее для запросов, входящих в такие отношения, как смежность, соединяемость и вхождение. Эти возможности полезны поставщикам систем землеустройства (кадастровых) и поставщикам пространственных данных.

Новинка в 10g Release 2: В базе данных теперь поддерживаются пространственные транзакции уровня деталей ландшафта с постоянной топологией. В предыдущей версии для вставки или изменения всех узлов, границ и элементов внешнего вида деталей ландшафта требовалось множество операций; теперь вставка или изменение деталей ландшафта выполняется как одна операция. Это существенно упрощает процесс обновления и поддержки наборов данных и уменьшает требуемый код.

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



это опция Oracle Database 10g


Oracle Spatial - это опция Oracle Database 10g Enterprise Edition, включающая дополнительные возможности по обработке пространственных данных для поддержки ГИС-приложений, пространственных сервисов (location-based services), то есть предназначенных для обработки и/или предоставления информации о местонахождении объектов, и промышленных геоинформационных систем.
Oracle Spatial расширяет возможности централизованного поиска, включенные в каждой базе данных Oracle с Oracle Locator. Усовершенствованное управление данными и возможности пространственного анализа включают генерацию буферов, пространственное агрегирование, вычисление площади и протяженности, а также линейные зависимости. Первая версия Oracle Spatial 10g предоставляет тип данных GeoRaster для хранения и управления изображением и помещенными на сетку растровыми представлениями данных и метаданных, сетевые и топографические модели данных, геокодирование и маршрутизацию, функции пространственного анализа и “добычи” данных. Эти новые существенные возможности удовлетворяют основным бизнес-требованиям государственного сектора, оборонных предприятий, логистических компаний, исследовательских подразделений энергетического комплекса, компаний, использующих деловую географическую информацию, и медико-биологических учреждений. Вторая версия Oracle Spatial 10g предоставляет eLocation Quick Start, набор Java API для быстрого и упрощенного применения при составлении карт, геокодировании и маршрутизации, и улучшенные возможности первой версии. Наряду с производительностью, масштабируемостью, и безопасностью Oracle Database 10g, Oracle Spatial 10g, это наиболее усовершенствованная платформа среди пространственных баз данных, доступная для применения в коммерческих предприятиях.
В целом этот документ описывает возможности, включенные только в Oracle Spatial, не вдаваясь в детали Oracle Locator.

Опция Oracle Spatial предоставляет дополнительные


Опция Oracle Spatial предоставляет дополнительные пространственные возможности в Oracle Database 10g, адресованные к критическим для бизнеса потребностям потребителей в области традиционных GIS, таких как оборона, государственная безопасность, землеустройство, транспортировка, а также других областей, в том числе медико-биологических наук.
Oracle Spatial и Oracle Database Enterprise Edition - это решение для пользователей, которые имеют GIS-приложения, требующие дополнительного пространственного анализа и обработки на стороне сервера. В первой версии Oracle Spatial 10g представлены новые значительные возможности. Открытый формат GeoRaster поддерживает хранение изображений и управление ими, что требуется государственному сектору, обороне, и исследовательским подразделениям энергетического комплекса. Сетевые и топографические модели данных требуются в приложениях для транспортировки, коммунальных служб, землеустройства, медико-биологических наук и пространственных сервисов. Механизм геокодирования и маршрутизации, встроенный на стороне сервера, поддерживает применение сервисов, основанных на информации о местонахождении объектов, а функции пространственного анализа улучшают бизнес-приложения. Вторая версия Oracle Spatial 10g продолжает совершенствовать эти возможности, и добавляет функцию eLocation Quick Start для быстрого и простого применения для составления карт, геокодирования, и маршрутизации.
Oracle охватывает 80-90% от всего рынка управления геопространственными базами данных (IDC, Oracle 10g: Spatial Capabilities for Enterprise Solutions, Sonnen and Morris, Feb. 2005). Потребители и партнеры надеются с помощью Oracle улучшить производительность, масштабируемость, безопасность данных и легкость в использовании их пространственных приложений. Oracle Spatial поддерживается всеми лидирующими поставщиками GIS и сервисов, основанных на информации о местонахождении объектов. Oracle Spatial 10g предоставляет наиболее усовершенствованные пространственные возможности, доступные сегодня в системе управления реляционными базами данных и возможности управления несогласованными производственными данными в Oracle Database 10g – в результате чего он становится лидирующей платформой управления геопространственной базой данных для GIS и промышленных пространственных систем.


Oracle Spatial 10g

August 2005
Authors: Jean Ihm, Xavier Lopez

Contributing Authors: Jim Steiner, Siva Ravada, Dan Abugov, Jayant Sharma
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. OGC, OpenGIS®, and CERTIFIED OGC COMPLIANT are trademarks or registered trademarks of Open Geospatial Consortium, Inc. in the United States and in other countries. Other names may be trademarks of their respective owners.

Использование основной линии планов запроса оптимизатором CBO


Изменим обстоятельства запуска запроса, индексировав таблицу. План должен поменяться. Однако при включенном (по умолчанию) управлении планами мы этого не увидим. Примечательно, что убедиться в этом удастся только со второй попытки:

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 | -------------------------------------------------



Изменение свойств планов в SMB


Процедура 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


Plan: SYS_SQL_PLAN_38c100c08916fd8c

----------------------------------- Plan was verified: Time used .06 seconds. Passed performance criterion: Compound improvement ratio >= 1.5. Plan was changed to an accepted plan.

Baseline Plan Test Plan Improv. Ratio

------------- --------- ------------- Execution Status: COMPLETE COMPLETE Rows Processed: 1 1 Elapsed Time(ms): 0 0 CPU Time(ms): 0 0 Buffer Gets: 3 2 1.5

Disk Reads: 0 0 Direct Writes: 0 0 Fetches: 0 0 Executions: 1 1

--------------------------------------------------------------------- Report Summary --------------------------------------------------------------------- Number of SQL plan baselines verified: 1. Number of SQL plan baselines evolved: 1.

Вердикт о влючении плана в основную линию производится на основании сравнения взвешенных суммарных оценок поперечисленным в отчете показателям («Compound improvement ratio»; точное правило не оглашается). В нашем случае он оказался благоприятным для плана-кандидата (коэффициент улучшения эффективности >= 1.5).

Теперь можно проверить прежним манером, как появление второго плана в основной линии отразилось на отработке запроса, выдав последовательность:

CONNECT scott/tiger SELECT job FROM emp WHERE ename = 'MILLER'; @showplan ALTER SESSION SET optimizer_use_sql_plan_baselines = FALSE; SELECT job FROM emp WHERE ename = 'MILLER'; @showplan

На этот раз планы окажутся одинаковыми, «новыми» (INDEX RANGE SCAN → TABLE ACCESS BY INDEX ROWID).


Реферат


Рассматривается система управления планами (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


Система управления планами в 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), хотя с ростом размера таблицы этот проигрыш и сокращается.

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



Как известно, СУБД, получив от


Как известно, СУБД, получив от приложения запрос, сначала строит программу вычисления ответа («план»), и тут же эту программу отрабатывает. Теоретически план можно построить наилучшим образом: получить множество всех возможных для данного запроса планов и выбрать из них наиболее поизводительный в нужном отношении. На практике же любая промышленная СУБД, включая Oracle, вырабатывает план на скорую руку, достигая при этом приемлемого времени ответа, но зато жертвуя точностью решения задачи. Как следствие, применяемые к поступающим запросам планы нередко оказываются не самыми лучшими, и общая производительность СУБД страдает.
Для решения этой проблемы фирма Oracle, равно как и прочие разработчики, дает пользователю средства вмешиваться в выработку плана СУБД. Косвенное вмешательство достигается воздействием на факторы, влияющие на выработку оптимизатором планов: параметры СУБД и сеанса, показатели статистики объектов запроса, употребление подсказок. Прямое вмешательство состоит в диктовке СУБД, какие именно планы следует использовать для конкретных запросов.
Исторически первым инструментом последней категории стали «очертания» (outline) запросов, появившиеся в версии 8.1. «Очертание» запроса – это план, «схваченный» в подходящий момент времени и сохраненный для последующего употребления. Пользователь получает возможность в пределах конкретных сеансов «включать» «очертание», заставляя СУБД пользоваться этим конкретным планом независимо от текущих обстоятельств. После версии 11 эта техника фиксации плана прекращает свое официальное существование.
Вторым по времени инструментом стал «профиль» (profile) запроса, введенный в версии 10. Профили могут возникнуть в результате специальной процедуры анализа СУБД запроса, представляющего интерес, в рамках работы советника SQL Tuning Advisor. Пользователь имеет право в любой момент включить имеющийся профиль, и тогда текущий план запроса подкорректируется в сторону улучшения. Влиянием на применяемый СУБД план будет включение и отключение профиля по мере необходимости.
В версии 11 в Oracle появилось третье по счету средство указания СУБД, каким определенным планом ей воспользоваться при обработке того или иного запроса. Оно получило название «управления планами»: SQL plan management (SPM). Его основное назначение – не дать возможность пустить обработку повторяющихся запросов приложения по «плохому» плану. «Плохим» же план может оказаться ненароком при смене обстоятельств очередного поступления запроса – значений переменных привязки, статистики объектов, переменных СУБД или сеанса и даже версии СУБД или ОС.

Загрузка плана в базу управления запросами


Вот случай, достойный памяти и занесения в литературу!

Плиний Младший, Панегирик императору Траяну

Сейчас для интересующего нас запроса СУБД завела рабочую память в общей области курсоров в 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 и в рабочем состоянии, и включен в основную линию.