Last ddl time oracle что это
Oracle предлагает специальный пакет по имени DBMS_FLASHBACK, который позволяет видеть согласованную версию базы данных на указанный момент времени (или SCN-номер). Важное преимущество пакета DBMS_FLASHBACK перед другими средствами Flashback связано с возможностью использования существующего кода PL/SQL для извлечения старых данных без добавления конструкций AS OF и VERSION BETWEEN, что необходимо при использовании других средств Flashback.
В качестве стартовой точки запроса можно специфицировать либо временную метку, либо номер SCN. В приведенном ниже простом примере, иллюстрирующем применение пакета DBMS_FLASHBACK, запрос сначала используется для получения количества строк, которые в данный момент имеются в таблице employees:
Предположим, что необходимо узнать количество строк, которое присутствовало в таблице 11 декабря 2008 г. Для указания интересующего момента времени в прошлом можно вызвать процедуру DBMS_FLASHBACK.ENABLE_AT_TIME, как показано в следующем коде:
Если вы предпочитаете использовать SCN-номер вместо временной метки, то вместо этого должны применить процедуру DBMS_FLASHBACK.ENABLE_AT_SYSTEM_CHANGE_NUMBER. Для получения корректного номера SCN следует воспользоваться процедурой DBMS_FLASHBACK.GET_SYSTEM_CHANGE.
Затем выдайте тот же запрос, что и ранее. Теперь результат вывода отобразит содержимое таблицы emp на 11 декабря 2008 г., а не на текущий момент. Обратите внимание,что применять в запросе конструкцию AS OF не потребуется, поскольку используется пакет DBMS_FLASHBACK.
Вот запрос, который даст вывод на 11 декабря 2008 г.:
Завершив выполнение запроса для извлечения результатов на какой-то момент времени в прошлом, отключите пакет DBMS_FLASHBACK следующим образом:
Включение средства Flashback Query в предыдущем примере позволило увидеть,сколько строк было в таблице в определенный момент времени в прошлом. С помощью простого запроса вы узнали, что таблица emp содержала 525 строк на указанный момент времени в прошлом. При желании для извлечения старых данных можно использовать курсоры, чтобы либо сравнить их с современными данными в таблице emp, либо,если необходимо, вставить их в таблицу emp. Открыть курсор необходимо до отключения средства DBMS_FLASHBACK; затем нужно и сохранить результаты, чтобы их можно было в дальнейшем сравнить или вставить.
Применяйте пакет DBMS_FLASHBACK в случаях, когда код не должен затрагиваться, например, в пакетных приложениях. Пакет DBMS_FLASHBACK полезен, если нужно несколько раз указать определенный момент времени в прошлом, чтобы извлечь старые данные. Для восстановления утерянных данных служат и другие методы, однако Flashback Query дает шанс просто проанализировать или проверить старые данные, даже в ситуациях, когда восстанавливать их не нужно.
Совет. Чтобы гарантировать согласованность данных, не забудьте выдать команду COMMIT или ROLLBACK перед использованием операции Flashback любого рода.
Анализ использования идентификаторов (Oracle Database 11g)
Проходит совсем немного времени, и рост объема и сложности кодовой базы создает серьезные проблемы с сопровождением и эволюцией. Допустим, мне потребовалось реализовать новую возможность в части существующей программы. Как убедиться в том, что я правильно оцениваю последствия от появления новой функции, и внести все необходимые изменения? До выхода Oracle Database 11g инструменты, которые могли использоваться для анализа последствий, в основном ограничивались запросами к ALL_DEPENDENCIES и ALL_SOURCE . Теперь, с появлением PL/Scope , я могу выполнять намного более подробный и полезный анализ.
PL/Scope собирает информацию об идентификаторах в исходном коде PL/SQL при компиляции кода и предоставляет собранную информацию в статических представлениях словарей данных. Собранная информация, доступная через USER_IDENTIFIERS , содержит очень подробные сведения о типах и использовании (включая объявления, ссылки, присваивание и т. д.) каждого идентификатора, а также о местонахождении использования в исходном коде.
Описание представления USER_IDENTIFIERS :
Name | Null? | Type |
NAME | VARCHAR2(128) | |
SIGNATURE | VARCHAR2(32) | |
TYPE | VARCHAR2(18) | |
OBJECT_NAME | NOT NULL | VARCHAR2(128) |
OBJECT_TYPE | VARCHAR2(13) | |
USAGE | VARCHAR2(11) | |
USAGE_ID | NUMBER | |
LINE | NUMBER | |
COL | NUMBER | |
USAGE_CONTEXT_ID | NUMBER |
Вы можете писать запросы к USER_IDENTIFIERS для поиска в коде разнообразной информации, включая нарушения правил об именах. Такие редакторы P L/SQL , как Toad, наверняка скоро начнут предоставлять доступ к данным PL/Scope , упрощая их использование для анализа кода. А пока этого не произошло, вам придется строить собственные запросы (или использовать написанные и опубликованные другими разработчиками).
Чтобы использовать PL/Scope , необходимо сначала приказать компилятору PL/SQL проанализировать идентификаторы программы в процессе компиляции. Для этого следует изменить значение параметра компилятора PLSC0PE_SETTINGS . Это можно делать на уровне сеанса и даже для отдельной программы, как в следующем примере:
Чтобы узнать значение PLSC0PE_SETTINGS для любой конкретной программы, обратитесь с запросом к USER_PLSQL_0BJECT_SETTINGS .
После включения PL/Scope при компиляции программы Oracle будет заполнять словарь данных подробной информацией об использовании каждого идентификатора в программе (переменные, типы, программы и т. д.).
Рассмотрим несколько примеров использования PL/Scope . Допустим, я создаю следующую спецификацию пакета и процедуру с включенной поддержкой PL/Scope:
Настройки PL/Scope проверяются следующим образом:
Проверка объявлений, обнаруженных в процессе компиляции этих двух программ:
Теперь я могу получить информацию обо всех локально объявляемых переменных:
Впечатляет, однако возможности PL/Scope этим не ограничиваются. Я могу получить информацию обо всех местах программы, в которых используется эта переменная, а также о типе использования:
Даже из этих простых примеров видно, что PL/Scope предоставляет выдающиеся возможности для того, чтобы лучше разобраться в коде и проанализировать изменения. Лукас Джеллема из AMIS предоставил более интересные и сложные примеры использования PL/Scope для проверки имен. Соответствующие запросы содержатся в файле 11g_plscope_amis.sql на сайте книги.
Кроме того, я создал вспомогательный пакет и демонстрационные сценарии, которые помогут вам начать работу с PL/Scope. Просмотрите файлы plscope_helper*.* , а также другие файлы plscope*.*.
ALL_OBJECTS describes all objects accessible to the current user.
DBA_OBJECTS describes all objects in the database.
USER_OBJECTS describes all objects owned by the current user. This view does not display the OWNER column.
Owner of the object
Name of the object
Name of the subobject (for example, partition)
Dictionary object number of the object
Dictionary object number of the segment that contains the object.
Note: OBJECT_ID and DATA_OBJECT_ID display data dictionary metadata. Do not confuse these numbers with the unique 16-byte object identifier ( object ID ) that Oracle Database assigns to row objects in object tables in the system.
Type of the object (such as TABLE , INDEX )
Timestamp for the creation of the object
Timestamp for the last modification of the object and dependent objects resulting from a DDL statement (including grants and revokes)
Timestamp for the specification of the object (character data)
Status of the object:
Indicates whether the object is temporary (the current session can see only data that it placed in this object itself) ( Y ) or not ( N )
Indicates whether the name of this object was system-generated ( Y ) or not ( N )
Indicates whether this is a secondary object created by the ODCIIndexCreate method of the Oracle Data Cartridge ( Y ) or not ( N )
Namespace for the object
Name of the edition in which the object is actual
DATA LINK - If the object is data-linked or a data link to an object in the root
METADATA LINK - If the object is metadata-linked or a metadata link to an object in the root
EXTENDED DATA LINK - If the object is extended-data-linked or an extended data link to an object in the root
NONE - If none of the above applies
Y - For objects marked EDITIONABLE
N - For objects marked NONEDITIONABLE
NULL - For objects whose type is not editionable in the database
Denotes whether the object was created, and is maintained, by Oracle-supplied scripts (such as catalog.sql or catproc.sql). An object for which this column has the value Y must not be changed in any way except by running an Oracle-supplied script.
Indicates whether the object is an Application common object ( Y ) or not ( N )
Default collation for the object
Indicates whether this object is duplicated on this shard ( Y ) or not ( N )
Анализ аргументов
Представление USER_ARGUMENTS может оказаться исключительно полезным для программиста: оно содержит информацию о каждом аргументе каждой хранимой программы в вашей схеме. Оно одновременно предоставляет разнообразную информацию об аргументах в разобранном виде и запутанную структуру, с которой очень трудно работать. Простой сценарий SQL*Plus для вывода содержимого USER_ARGUMENTS для всех программ в заданном пакете:
Более совершенная программа на базе PL/SQL для вывода содержимого USER_ARGUMENTS находится в файле show_aN_arguments.sp на сайте книги.
Вы также можете создавать более конкретные запросы к представлению USER_ARGUMENTS для выявления возможных проблем с качеством кодовой базой. Например, Oracle рекомендует воздерживаться от использования типа LONG и использовать вместо него LOB . Кроме того, тип данных CHAR с фиксированной длиной может создать проблемы; намного лучше использовать VARCHAR2 . Следующий запрос выявляет использование этих типов в определениях аргументов:
Представление USER_ARGUMENTS может использоваться даже для получения информации о программах пакета, которую трудно получить другим способом. Предположим, я хочу получить список всех процедур и функций, определенных в спецификации пакета. Что вы говорите? «Нет проблем — просто выдать запрос к USER_PROCEDURES ». И это был бы хороший ответ. вот только USER_PROCEDURES не сообщит вам, является ли программа функцией или процедурой (причем в зависимости от перегрузки она может быть и той и другой!)
Представление USER_ARGUMENTS содержит нужную информацию, но она хранится в далеко не очевидном формате. Чтобы определить, является ли программа функцией или процедурой, можно поискать в USER_ARGUMENTS строку данной комбинации «пакет/ программа», у которой значение POSITION равно 0. Это значение Oracle использует для хранения «аргумента» RETURN функции. Если оно отсутствует, значит, программа должна быть процедурой.
Следующая функция использует эту логику для возвращения строки, обозначающей тип программы (если она перегружена для обоих типов, функция возвращает строку « FUNCTION, PROCEDURE »). Обратите внимание: функция list_to_string , используемая в теле функции, определяется в файле:
Наконец, следует сказать, что встроенный пакет DBMS_DESCRIBE предоставляет программный интерфейс PL/SQL , который возвращает почти ту же информацию, что и USER_ARGUMENTS . Впрочем, эти два механизма отличаются некоторыми особенностями работы с типами данных.
Вывод и поиск исходного кода
Исходный код программ следует всегда хранить в текстовых файлах (или в средах разработки, предназначенных для хранения и работы с кодом PL/SQL за пределами Oracle). Однако хранение программ в базе данных позволяет использовать SQL-запросы для анализа исходного кода по всем модулям, что непросто сделать в текстовом редакторе.
Представление USER_SOURCE содержит исходный код всех объектов, принадлежащих текущему пользователю. Его структура такова:
Name | Null? | Type |
NAME | NOT NULL | VARCHAR2(30) |
TYPE | VARCHAR2(12) | |
LINE | NOT NULL | NUMBER |
TEXT | VARCHAR2(4000) |
Здесь NAME — имя объекта, TYPE — его тип (от программ PL/SQL до блоков Java и исходного кода триггеров), LINE — номер строки, а TEXT — текст исходного кода. Представление USER_SOURCE является чрезвычайно ценным источником информации для разработчиков. При помощи соответствующих запросов разработчик может:
- вывести строку исходного кода с заданным номером;
- проверить стандарты кодирования;
- выявить возможные ошибки и дефекты в исходном коде;
- найти программные конструкции, не выявляемые из других представлений. Предположим, в проекте действует правило, согласно которому отдельные разработчики никогда не должны жестко кодировать пользовательские номера ошибок из диапазона от -20 999 до -20 000 (поскольку это может привести к возникновению конфликтов). Конечно, руководитель проекта не может помешать разработчику написать следующую строку:
Но зато он может создать пакет, который находит все программы с подобными фрагментами. Это очень простой пакет, а его главная процедура имеет вид:
После компиляции этого пакета в схеме можно проверить присутствие в программах значений -20NNN :
Обратите внимание: третья строка не противоречит правилам; она выводится только потому, что условие отбора сформулировано недостаточно жестко.
Конечно, этот аналитический инструмент весьма примитивен, но при желании его можно усовершенствовать. Можно, к примеру, генерировать HTML-документ с информацией, размещая его в интрасети, или выполнять сценарии valstd каждое воскресенье средствами DBMS_JOB , чтобы в понедельник утром администратор мог проверить наличие данных обратной связи в интрасети.
DBA_TAB_PARTITIONS
Представление DBA_TAB_PARTITIONS подобно представлению DBA_TABLES, но содержит детальную информацию о разделах таблиц. Благодаря DBA_TAB_PARTITIONS, можно узнать имя раздела, его максимальные значения, информацию о хранении раздела,статистику по разделу, а также прочую информацию, которая доступна в представлении DBA_TABLES. В листинге ниже показан простой запрос, использующий представление DBA_TAB_PARTITIONS.
Синтаксис Flashback Versions Query
Средство Flashback Versions Query позволяет извлекать все зафиксированные версии табличных данных между двумя моментами времени. Если, например, вы обновили строку таблицы 10 раз, то Flashback Versions Query выдаст десять версий этой строки.
Полный синтаксис Flashback Versions Query выглядит следующим образом:
Использование конструкции VERSIONS в запросе вернет множество версий строки.В предыдущем операторе синтаксиса конструкция VERSIONS могла бы применяться как часть обычного оператора SELECT, с добавленной к нему конструкцией BETWEEN. Также можно специфицировать конструкцию SCN или TIMESTAMP. Выражения начала и конца задаются с помощью MINVALUE и MAXVALUE, указывающие начальное и конечное время интервала, для которого ищутся разные версии строки. MINVALUE и MAXVALUE разрешаются во временные метки или номера SCN самых старых и самых новых данных, доступных в базе.
На заметку! Следует убедиться, что начало и конец интервала, ограниченного либо номерами SCN, либо временными метками, не выходят за пределы времени, указанного параметром UNDO_RETENTION. Хотя допускается указать начальную и конечную временные точки, которые находятся за пределами интервала, определенного параметром UNDO_RETENTION, такой запрос может не сработать.
Обратите внимание, что конструкция AS OF не обязательна, и когда она присутствует, база данных извлечет все строки, соответствующие конкретному номеру SCN или временной метке. Если используется конструкция VERSIONS, как в VERSIONS BETWEEM SCN MINVALUE and MAXVALUE, без необязательной конструкции AS OF, то данные извлекаются в таком виде, как они есть в текущем сеансе. В случае добавления AS OF данные извлекаются в соответствии с указанным номером SCN или моментом времени:
На заметку! Конструкцию VERSIONS можно также использовать в подзапросах операторов DML и DDL.
DBA_OBJECTS
Представление DBA_OBJECTS содержит информацию обо всех объектах базы данных, включая таблицы, индексы, пакеты, процедуры, функции, измерения, материализованные представления, планы ресурсов, типы, последовательности, синонимы, триггеры, представления и разделы таблиц (оно же секционирование). Как несложно догадаться, это представления удобно, когда нужно знать общую информацию относительно любого объекта базы данных. В листинге ниже показан запрос, предназначенный для нахождения времени создания и времени последней модификации объекта (LAST_DDL_TIME). Этот тип запроса поможет идентифицировать время модификации определенного объекта, что часто используется в процессе аудита.
Ответы 4
LAST_DDL_TIME - это последний раз, когда он был скомпилирован. TIMESTAMP - это последний раз, когда он был изменен.
Может потребоваться перекомпиляция процедур, даже если они не изменились при изменении зависимости.
я не могу найти user_objects. Ошибка при выполнении этого запроса
@Harie - это потому, что этот вопрос касается Oracle, а не SQL Server.
Соответствует ли описание LAST_DDL_TIME и TIMESTAMP ? Я только что перекомпилировал тело пакета (оно было недействительным): alter package foo compile body reuse settings; и оба столбца были обновлены. Другое отличие состоит в том, что я запрашиваю DBA_OBJECTS (но это не имеет значения?).
@ user272735 На какой у вас версии Oracle? Я думаю, что они улучшили некоторые вещи, связанные с зависимостями, в 11, которые могли бы это изменить.
@ user272735 В таком случае, похоже, я ошибаюсь. Возможно, вам стоит опубликовать ответ с выводом сценария, показывающим это.
можно ли также узнать, с какой машины он был скомпилирован?
Следующий запрос будет выполняться в Oracle
@Thilakan - Если вы собираетесь запросить ALL_OBJECTS , вы должны включить предикат в OWNER , иначе вы можете получить несколько строк в дополнение к предикату OBJECT_TYPE из ответа WW пару лет назад. Вы, вероятно, также должны отметить, что ALL_OBJECTS содержит все объекты, которые текущий пользователь имеет привилегии, не для всех объектов в базе данных, которые будут в DBA_OBJECTS .
Существует несколько важных представлений словаря базы данных, которые можно использовать для нахождения детальной информации о любом из объектов базы данных, о которых говорилось в этой главе. Администраторы баз данных также интенсивно используют представления словаря данных, чтобы управлять различными объектами схемы. Здесь приводится краткий список важнейших представлений, часть из которых упоминалась выше. Полные данные о типах информации, которую можно получить от каждого из этих представлений, доступны по команде DESCRIBE (например, DESCRIBE DBA_CATALOG).
В этой статье блога будут описаны некоторые важные представления словаря данных, которые помогут управлять объектами, не хранящими данные (т.е. объектами, которые не относятся к таблицам и индексам). Ниже приведен список важнейших представлений словаря данных для просмотра объектов базы данных.
- DBA_SYNONYMS. Информация о синонимах базы данных.
- DBA_TRIGGERS. Информация о триггерах.
- DBA_SEQUENCES. Информация о созданных пользователем последовательностях.
- DBA_DB_LINKS. Информация о связях базы данных.
Как упоминалось ранее, представление DBA_OBJECTS предоставляет важную информацию обо всех перечисленных объектах, наряду с некоторыми другими типами объектов базы данных. Однако перечисленные представления содержат детальную информацию о каждом объекте, такую как исходный текст триггера, которую вы не получите из представления DBA_OBJECTS.
Управление такими объектами, как таблицы и представления, осуществляется ссылкой на представления словаря данных, наподобие DBA_TABLES и DBA_VIEWS. Существуют также отдельные представления для секционированных таблиц. Давайте рассмотрим ключевые представления словаря данных, относящиеся к таблицам и индексам.
DBA_MVIEWS
Представление словаря DBA_MVIEWS сообщает все о материализованных представлениях в базе данных, в том числе информацию, включено ли для них средство переписывания запросов. В листинге ниже демонстрируется использования этого представления.
DBA_EXTERNAL_TABLES
Представление DBA_EXTERNAL_TABLES показывает подробности о любой внешней таблице в базе данных, включая их тип доступа, параметры доступа и информацию о каталоге.
INDEX_STATS
Представление INDEX_STATS полезно для того, чтобы узнать, насколько эффективно индекс использует свое пространство. Крупные индексы имеют тенденцию со временем становиться несбалансированными, если происходит много удалений данных таблицы (а, следовательно, и индекса). Ваша цель — не упускать из виду эти крупные индексы,чтобы сохранять их сбалансированными.
Обратите внимание, что представление INDEX_STATS наполняется, только когда таблица подвергается анализу с помощью команды ANALYZE, как показано ниже:
Запрос из листинга ниже, использующий представление INDEX_STATS, помогает определить необходимость в перестройке индекса. Чтобы определить, следует ли перестраивать индекс, в запросе необходимо сосредоточиться на перечисленных ниже столбцах представления INDEX_STATS.
При компиляции программного модуля PL/SQL его исходный код сохраняется в базе данных Oracle. Это дает разработчикам два важных преимущества:
- Информацию о программном коде можно получить с помощью запросов SQL. Разработчики могут писать запросы и даже целые программы PL/SQL , которые читают информацию из представлений словаря данных и даже могут изменять состояние кода приложения.
- База данных Oracle управляет зависимостями между хранимыми объектами. В мире PL/ SQL не существует процесса «компоновки» исполняемых файлов, которые затем запускаются пользователями. База данных берет на себя все служебные операции, позволяя разработчику сосредоточиться на реализации бизнес-логики.
В следующих разделах представлены основные источники информации в словаре данных СУБД Oracle.
Анализ и изменение состояний триггеров
Запросы к триггерным представлениям ( USER_TRIGGERS, USER_TRIG_COLUMNS ) обычно используются для решения следующих задач:
- Включение или отключение всех триггеров для заданной таблицы. Вместо того чтобы писать код вручную, вы выполняете соответствующие команды DDL из кода PL/SQL. Пример такой программы приведен в статье «Сопровождение триггеров».
- Поиск триггеров, выполняемых при изменении некоторых столбцов, но не имеющих предложения секции WHEN . Следующий запрос поможет найти триггеры, не имеющие секции WHEN , которые являются источниками потенциальных проблем:
DBA_PART_TABLES
Представление DBA_PART_TABLES содержит информацию о типе схемы раздела и прочих параметрах хранения разделов и подразделов. Узнать тип каждого раздела каждой секционированной таблицы можно с помощью следующего запроса:
Псевдостолбцы Flashback Versions Query
Вывод Flashback Versions Query отличается от вывода обычного оператора SELECT.Вывод может показать множество версий одной и той же строки, причем каждая строка вывода представляет каждый случай вставки, обновления или удаления исходной строки. В дополнение к значениям столбцов, специфицированных в операторе SELECT, Oracle предоставит значения набора псевдостолбцов для каждой версии строки. Эти псевдостолбцы содержат метаданные о различных версиях строки, включая тип операции, начало и конец транзакции и т.д. Эти псевдостолбцы в точности сообщают, когда строка была модифицирована, и что было сделано со строкой в этот момент времени.
Ниже приведено краткое описание каждого псевдостолбца в выводе Flashback Versions Query.
- VERSIONS_STARTSCN и VERSIONS_STARTTIME. Эти псевдостолбцы сообщают номер SCN и временную метку, когда была создана конкретная строка. Если значение VERSIONS_STARTTIME равно null, значит, строка была создана до нижней границы временного периода запроса.
- VERSIONS_ENDSCN и VERSIONS_ENDTIME. Эти псевдостолбцы сообщают, когда конкретная строка устарела (expired). Если столбец VERSIONS_ENDTIME равен null,это значит, что строка является текущей или что она была удалена.
- VERSIONS_OPERATION. Этот псевдостолбец предоставляет информацию о типе операции DML, выполненной над конкретной строкой. Он может принимать одно из трех возможных значений: I — вставка, D — удаление, U — обновление.
- VERSIONS_XID. Этот псевдостолбец отображает уникальный идентификатор транзакции, в результате которого получена данная версия строки.
На заметку! Индекс-таблица (IOT) показывает операцию обновления как операции удаления и вставки. Средство Flashback Versions Query отобразит удаленную и вставленную строки как две независимые версии. Первая версия в псевдостолбце VERSIONS_OPERATION должна содержать D (операция удаления), а следующая — I (операция вставки).
Если версия строки была создана перед MINVALUE начала запроса, узнать значение начальной временной метки или номер SCN невозможно, и псевдостолбцы VERSIONS_STARTSCN и VERSIONS_STARTTIME будут содержать значение null, т.е. это значит, что в сегментах отмены для этой строки хронология отсутствует.
Псевдостолбцы VERSIONS_ENDSCN и VERSIONS_ENDTIME сообщат, когда данная версия строки устарела. Если данная версия остается текущей на момент запуска Flashback Versions Query, то псевдостолбцы VERSIONS_ENDSCN и VERSIONS_ENDTIME будут равны null. Аналогично, если версия строки была удалена из таблицы, в этих двух псевдостолбцах будут присутствовать значения null.
DBA_IND_COLUMNS
Представления DBA_IND_COLUMNS по структуре подобно представлению DBA_CONS_COLUMNS и содержит информацию обо всех проиндексированных столбцах каждой таблицы. Эта информация важна при настройке производительности, когда вы замечаете,что запрос использует индекс, но вы не знаете точно, на каких столбцах этот индекс определен. Запрос, приведенный в листинге ниже, показывает, что таблица имеет индексы, определенные на неверных столбцах.
Совет. Взглянув на столбец INDEX_NAME, можно легко идентифицировать составные ключи. Если одно и то же вхождение INDEX_NAME появляется больше одного раза, значит, это составной ключ; и столбцы, являющиеся его частью, показаны в столбце COLUMN_NAME. Например,INVENTORY_PK — первичный ключ таблицы INVENTORIES, определенный на двух столбцах:PRODUCT_ID и WAREHOUSE_ID. Порядок столбцов в определении составного ключа можно узнать с помощью столбца COLUMN_POSITION.
Проверка ограничений размера
Представление USER_0BJECT_SIZE предоставляет информацию о размере программ, хранимых в базе данных:
- S0URCE_SIZE — размер исходного кода в байтах. Код должен находиться в памяти во время компиляции (включая динамическую/автоматическую перекомпиляцию).
- PARSED_SIZE — размер объекта в байтах после разбора. Эта форма должна находиться в памяти при компиляции любого объекта, ссылающегося на данный объект.
- C0DE_SIZE — размер кода в байтах. Код должен находиться в памяти при выполнении объекта.
Следующий запрос выводит кодовые объекты с размером больше заданного. Например, вы можете выполнить этот запрос для идентификации программ, закрепляемых в базе данных средствами DBMS_SHARED_P00L для того, чтобы свести к минимуму подгрузку кода в SGA :
Получение свойств хранимого кода
Представление USER_PLSQL_0BJECT_SETTINGS (появившееся в Oracle10g) содержит информацию о следующих параметрах компиляции хранимого объекта PL/SQL :
- PLSQL_OPTIMIZE_LEVEL — уровень оптимизации, использовавшийся при компиляции объекта.
- PLSQL_CODE_TYPE — режим компиляции объекта.
- PLSQL_DEBUG — признак отладочной компиляции.
- PLSQL_WARNINGS — настройки предупреждений, использовавшиеся при компиляции объекта.
- NLS_LENGTH_SEMANTICS — семантика длины NLS, использовавшаяся при компиляции объекта.
Пара примеров возможного применения этого представления:
- Поиск программ, не использующих все возможности оптимизирующего компилятора (уровень оптимизации 1 или 0):
- Проверка отключения предупреждений у хранимых программ:
В представлении USER_PROCEDURES перечисляются все функции и процедуры с их свойствами. В частности, в представление USER_PROCEDURES включается настройка модели authid для программы ( definer или current_user ). Эта информация позволяет быстро определить, какие программы в пакете используют модель привилегий вызывающей стороны или создателя. Пример такого запроса:
DBA_VIEWS
Как известно, представления — это результаты запросов к некоторым таблицам базы данных. Представление словаря данных DBA_VIEWS позволяет увидеть SQL-запросы, лежащие в основе представлений. В листинге ниже показано, как получить текст представления OS_CUSTOMERS, принадлежащего пользователю oe.
Совет. Чтобы обеспечить полное отображение текста при использовании представления DBA_VIEWS, установите большое значение переменной long (например, SET LONG 2000). В противном случае вы увидите лишь несколько первых строк определения представления.
Ограничения и наблюдения за Flashback Versions Query
Ниже перечислены основные ограничения средства Flashback Versions Query.
- Это средство можно использовать для опроса действительных таблиц, но не представлений.
- Нельзя применять конструкцию VERSIONS в операциях DDL.
- Запрос игнорирует физические изменения строки, произошедшие, например, во время уменьшения размеров сегмента.
- Это средство нельзя применять для работы с внешними или временными таблицами.
Если требуется запросить прошлые данные на точный момент времени, необходимо использовать номер SCN, поскольку реальное время может отклоняться до трех секунд в ту или иную сторону от того, что задается во временной метке. В Oracle Database 11g номера SCN используются внутренне, и они отображаются на временные метки с точностью в три секунды. Потенциальный зазор между SCN и временными метками может вызвать проблемы, когда вы пытаетесь выполнить ретроспективу к точному моменту времени, следующему непосредственно за операцией DDL. Предположим, что вы создали новую таблицу. В случае использования временной метки Flashback Versions Query может начать чуть ранее точного времени создания таблицы и полностью потерять ее. В этом случае вместо ожидаемых результатов Flashback Versions Query вы получите ошибку. Используя номер SCN вместо временной метки, этой проблемы можно избежать.
Для этого я желательно ищу SQL-запрос, но могут быть полезны и другие варианты.
Будучи разработчиком веб-приложений, легко впасть в заблуждение, считая, что приложение без JavaScript не имеет права на жизнь. Нам становится удобно.
Если вы ищете пакет для быстрой интеграции календаря с выбором даты в ваше приложения, то библиотека Flatpickr отлично справится с этой задачей.
Клиент для URL-адресов, cURL, позволяет взаимодействовать с множеством различных серверов по множеству различных протоколов с синтаксисом URL.
У каждого из нас бывали случаи, когда нам нужно отцентрировать блочный элемент, но мы не знаем, как это сделать. Даже если мы реализуем какой-то.
DBA_TAB_MODIFICATIONS
Представление DBA_TAB_MODIFICATIONS показывает все изменения DML в таблице,произошедшие с момента последнего сбора статистики по этой таблице. Вот запрос к этому представлению:
База данных не обновляет представление DBA_TAB_MODIFICATIONS в реальном времени. Следовательно, вы можете и не увидеть изменений в различных таблицах, немедленно отраженных в этом представлении.
DBA_TAB_COLUMNS
Предположим, вы нужно узнать среднюю длину каждой строки таблицы или значение по умолчанию каждого столбца (если таковое есть). Представление DBA_TAB_COLUMNS — отличный способ быстро получить всю детальную информацию о столбцах таблиц схемы, как показано в листинге ниже.
Flashback Versions Query
Средство Flashback Versions Query предоставляет хронологию строки, позволяя извлекать все версии строки между любыми двумя точками времени или двумя номерами SCN. Новая версия строки создается при каждом выполнении COMMIT. Если вы вставите строку, а затем обновите или удалите ее, в таблице будет представлена только последняя версия. Если нужно точно узнать, какие изменения претерпела строка за определенный период времени, для этого можно применить средство Flashback Versions Query, которое вернет по одной строке для каждой версии каждой строки в таблице. Это средство идеально для целей аудита таблиц и отмены ошибочных изменений данных.
Ниже перечислены некоторые моменты, касающиеся средства Flashback Versions Query, о которых следует помнить.
- Извлекать можно только фиксированные (commited) версии строки.
- Наряду с текущими, запрос извлечет все удаленные строки.
- Запрос извлечет все строки, которые были удалены и затем вставлены вновь.
- Запрос выведет результат в форме таблицы, содержащей по строке на каждую версию каждой строки исходной таблицы, существовавшую в заданный период времени или временной интервал.
Извлекая хронологию строк таблицы, можно провести аудит изменений и узнать, какие транзакции изменили строку.
Представления словаря данных
Словарь данных Oracle — настоящие джунгли! Он изобилует полезной информацией, но найти путь к цели порой бывает очень непросто. В нем сотни представлений, основанных на сотнях таблиц, множество сложных взаимосвязей, специальных кодов и слишком много неоптимизированных определений представлений. Вскоре мы рассмотрим подмножество важнейших представлений, а пока выделим три типа (или уровня) представлений словаря данных:
- USER_* — представления с информацией об объектах базы данных, принадлежащих текущей схеме.
- ALL_* — представления с информацией об объектах базы данных, доступных в текущей схеме (либо принадлежащих ей, либо доступных благодаря соответствующим привилегиям). Обычно они содержат те же столбцы, что и соответствующие представления USER , с добавлением столбца OWNER в представлениях ALL .
- DBA_* — представления с информацией обо всех объектах базы данных. Обычно содержат те же столбцы, что и соответствующие представления ALL . Исключение составляют представления v$ , gx$ и x$ .
В этой статье мы будем работать с представлениями USER ; вы можете легко изменить любые сценарии и приемы, чтобы они работали с представлениями ALL , добавив в свою логику столбец OWNER . Вероятно, для разработчика PL/SQL самыми полезными будут следующие представления:
- USER_ARGUMENTS — аргументы (параметры) всех процедур и функций схемы.
- USER_DEPENDENCIES — все зависимости (входящие и исходящие) для принадлежащих текущей схеме объектов. Представление в основном используется Oracle для пометки неработоспособных объектов, а также средой разработки для вывода информации зависимостей в программах просмотра объектов. Примечание: для полного анализа зависимостей следует использовать представление ALL_DEPENDENCIES на случай, если программная единица будет вызвана другой программной единицей, принадлежащей другой схеме.
- USER_ERRORS — текущий набор ошибок компиляции для всех хранимых объектов (включая триггеры). Представление используется командой SQL*Plus SHOW ERRORS , описанной в этом блоге. Вы также можете писать собственные запросы к этому представлению.
- USER_IDENTIFIERS — представление появилось в Oracle11g , а для его заполнения используется утилита PL/Scope . Содержит информацию обо всех идентификаторах (имена программ, переменных и т. д.) в кодовой базе; исключительно полезный инструмент анализа кода.
- USER_0BJECTS — объекты, принадлежащие текущей схеме. Например, при помощи этого представления можно узнать, помечен ли объект как неработоспособный ( INVALID ), найти все пакеты, в имени которых присутствует EMP, и т. д.
- USER_0BJECT_SIZE — размер принадлежащих текущей схеме объектов. Точнее, это представление возвращает информацию о размере исходного, разобранного и откомпилированного кода. И хотя оно в основном используется компилятором и ядром времени выполнения, вы можете воспользоваться им для поиска больших программ в вашей среде — кандидатов для размещения в SGA .
- USER_PLSQL_0B3ECT_SETTINGS — представление появилось в Oracle10g. Содержит информацию о характеристиках объектов PL/SQL, которые могут изменяться командами DDL ALTER и SET : уровни оптимизации, параметры отладки и т. д.
- USER_PR0CEDURES — информация о хранимых программах (не только процедурах, как можно было бы подумать по названию) — например, модель AUTHID, признак детерминированности функций и т. д.).
- USER_S0URCE — исходный код всех принадлежащих текущей схеме объектов (в Oracle9i и выше — вместе с триггерами баз данных и исходным кодом Java). Это очень удобное представление — вы можете применять к нему всевозможные средства анализа исходного кода, используя SQL и особенно Oracle Text.
- USER_ST0RED_SETTINGS — флаги компилятора PL/SQL. Это представление поможет узнать, какие программы были откомпилированы в код аппаратной платформы.
- USER_TRIGGERS и USER_TRIG_C0LUMNS — триггеры базы данных, принадлежащие текущей схеме (включая исходный код и описание инициирующих событий), а также столбцы, связанные с триггерами.
Для просмотра структуры любого из этих представлений можно либо воспользоваться
командой DESCRIBE в SQI*Plus , либо обратиться к документации Oracle. Примеры использования этих представлений приведены в следующем разделе.
Вывод информации о хранимых объектах
В представлении USER_0BJECTS содержится ключевая информация об объекте:
- 0BJECT_name — имя объекта.
- OBJECT_TYPE — тип объекта ( PACKAGE, FUNCTI0N, TRIGGER и т. д.).
- STATUS — состояние объекта ( VALID или INVALID ).
- LAST_DDL_TIME — время последнего изменения объекта.
Следующий сценарий SQL*Plus выводит информацию о состоянии объектов PL/SQL :
Результат работы сценария выглядит примерно так:
OBJECT_TYPE | OBJECT_NAME | STATUS |
FUNCTION | DEVELOP ANALYSIS | INVALID |
NUMBER OF ATOMICS | INVALID | |
PACKAGE | CONFIG_PKG | VALID |
EXCHDLR PKG | VALID |
Обратите внимание на два модуля с пометкой INVALID . О том, как вернуть программный модуль в действительное состояние VALID , будет рассказано далее.
DBA_TABLES
Представление DBA_TABLES содержит информацию обо всех реляционных таблицах базы данных. Представление DBA_TABLES — основной справочник для нахождения информации о хранении, количестве строк в таблице, состоянии протоколирования, информации буферного пула и многих других деталях. Ниже приведен простой пример запроса представления DBA_TABLES:
На заметку! Представление DBA_ALL_TABLES содержит информацию обо всех объектных и реляционных таблицах в базе данных, в то время как представление DBA_TABLES ограничено только реляционными таблицами.
Представление DBA_TABLES служит для нахождения таких вещей, как включено ли сжатие и отслеживание зависимостей на уровне строки, и была ли таблица уничтожена и помещена в корзину (Recycle Bin).
DBA_INDEXES
Представление словаря DBA_INDEXES служит для того, чтобы узнать все необходимое об индексах в базе данных, включая имя индекса, его тип, таблицу и табличное пространство, к которому он относится. Определенные столбцы, наподобие BLEVEL (сообщает уровень B-дерева индекса) и DISTINCT_KEYS (количество разных значений ключа индекс), наполняются, только если собрана статистика по индексу с использованием пакета DBMS_STATS.
Использование Flashback Versions Query
Чтобы понять возможность и мощь средства Flashback Versions Query, давайте рассмотрим простой пример, показанный в листинге ниже.
Пример в листинге 8.1 извлекает три версии строки о сотруднике с номером (emp_id) 222. Номер SCN для AS OF равен 7920. То есть мы хотим знать, какие версии строки существуют с этим номером SCN. Хотя вы видите три версии в выводе, только одна из версий относится к интересующему SCN. Так какая же?
Прочтем вывод запроса снизу вверх. Уделим особое внимание столбцам START_SCN и END_SCN. Все строки будут иметь START_SCN, но некоторые могут иметь null в столбце END_SCN, если версия строки актуальна для текущего номера SCN.
Первая строка, которая вставила (операция I) сотрудника по имени Nick c SCN-номером 2266, является последней версией строки. Поскольку END_SCN у нее равен null, вы знаете, что эта строка еще существует и с SCN-номером 7920. Если посмотреть столбец OPERATION, вы увидите букву D во второй версии (со START_SCN, равным 0864); это указывает, что средняя строка была удалена (возможно, нечаянно), и эта строка не существует для SCN-номера 7920. Таким образом, первая строка отражает тот факт, что строка была повторно вставлена, но с другим именем сотрудника. Последняя, или третья, строка имеет номер END_SCN, поэтому ясно, что эта строка устарела на SCN-номер 0864. Это была изначально вставленная версия этой строки, на что указывает значение I (вставка) в столбце OPERATION.
На заметку! Чтобы использовать вместо SCN-номеров временные метки, обозначающие интервал времени для извлечения разных версий строки, потребуется заменить конструкцию VERSIONS BETWEEN SCN nn AND nn конструкцией VERSIONS BETWEEN TIMESTAMP..
Читайте также: