Какие объекты всегда имеют статус valid oracle

Обновлено: 04.07.2024

В том числе: Проверьте состояние экземпляра Oracle, проверьте процесс обслуживания Oracle, проверьте процесс мониторинга Oracle, всего три части.

1.1 Проверьте состояние экземпляра Oracle

Среди них «STATUS» указывает текущее состояние экземпляра Oracle, которое должно быть «OPEN», «DATABASE_STATUS» указывает текущее состояние базы данных Oracle, которое должно быть «ACTIVE».

1.2 Проверка состояния журнала онлайн Oracle

Выходной результат должен иметь более 3 записей (включая 3) записи, «STATUS» должен быть не «INVALID», не «DELETED». Примечание: «СТАТУС» пуст для обозначения нормального.

1.3 Проверьте состояние табличного пространства Oracle

СОСТОЯНИЕ должно быть ОНЛАЙН на выходе.

1.4 Проверьте состояние всех файлов данных Oracle

«STATUS» на выходе должно быть «ONLINE». или:

«STATUS» на выходе должно быть «ДОСТУПНО».

1.5 Проверка на недействительные объекты

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

1.6 Проверьте состояние всех сегментов отката

«СОСТОЯНИЕ» всех сегментов отката на выходе должно быть «ОНЛАЙН».

2. Проверьте использование ресурсов, связанных с Oracle

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

2.1 Проверьте значения соответствующих параметров в файле инициализации Oracle

Если LIMIT_VALU-MAX_UTILIZATION <= 5, это означает, что параметры инициализации Oracle, связанные с RESOURCE_NAME, должны быть скорректированы. Можно изменить, изменив файл параметров инициализации Oracle $ ORACLE_BASE / admin / CKDB / pfile / initORCL.ora.

2.2. Проверка соединения с базой данных

Проверьте, находится ли текущий номер подключения сеанса в пределах нормального диапазона.

Среди них: SID сеанса (сеанса), идентификационный номер;

USERNAME - имя пользователя, с которого был установлен разговор;

Какой инструмент используется для сеанса PROGRAM для подключения к базе данных;

STATUS Текущее состояние этого сеанса. ACTIVE означает, что сеанс выполняет определенные задачи. INACTIVE означает, что текущий сеанс не выполняет никаких операций.

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

(Обычно не рекомендуется использовать этот метод для разрыва соединения с базой данных, поэтому иногда сеанс не будет отключен. Легко вызвать прерывание соединения. Рекомендуется проверить spid операционной системы через sid и использовать ps –ef | grep spidno для подтверждения spid Не фоновый процесс ORACLE. Используйте команду kill -9 операционной системы, чтобы разорвать соединение)

Примечание. В приведенном выше примере сеансы с SID от 1 до 10 (столбец USERNAME пуст) являются фоновыми процессами Oracle и не выполняют никаких операций в этих сеансах.

2.3 Проверьте место на системном диске

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

Filesystem Size Used Avail Use% Mounted on

/dev/sda5 9.7G 3.9G 5.4G 42% /

/dev/sda1 479M 16M 438M 4% /boot

/dev/sda2 49G 19G 28G 41% /data

none 1014M 0 1014M 0% /dev/shm

2.4 Проверьте использование табличного пространства

select f.tablespace_name,
a.total,
f.free,
round((f.free / a.total) * 100) "% Free"
from (select tablespace_name, sum(bytes / (1024 * 1024)) total
from dba_data_files
group by tablespace_name) a,
(select tablespace_name, round(sum(bytes / (1024 * 1024))) free
from dba_free_space
group by tablespace_name) f
WHERE a.tablespace_name = f.tablespace_name(+)
order by "% Free";

Если процент простоя% Free составляет менее 10% (включая 10%), обратите внимание на увеличение файла данных для расширения табличного пространства вместо использования функции автоматического расширения файла данных. Пожалуйста, не добавляйте слишком много файлов данных в табличное пространство.Принцип увеличения файлов данных заключается в том, что размер каждого файла данных составляет 2G или 4G, а максимальное ограничение для автоматического расширения составляет 8G.

2.5 Проверьте некоторые расширенные ненормальные объекты

Если запись возвращается, расширение этих объектов почти достигло максимального значения расширения, когда оно было определено. Для этих объектов необходимо изменить параметры его структуры хранения.

2.6 Проверка содержимого системного табличного пространства

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

2.7 Проверьте следующее расширение объекта и максимальное значение расширения табличного пространства

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

3. Проверьте результаты резервного копирования базы данных Oracle

содержать:
a. Проверьте информацию журнала резервного копирования базы данных;
б. Проверьте время создания файлов в томе резервной копии;
c. Проверьте электронную почту пользователя оракула.
3.1. Проверьте информацию журнала резервного копирования базы данных

Предположение: временный каталог для резервного копирования - / backup / hotbakup, нам нужно проверить результат резервного копирования 22 июля 2009 года, а затем использовать следующую команду для проверки:

cat /backup/hotbackup/hotbackup-09-7-22.log|grep –i error

Файл журнала сценария резервного копирования - hotbackup-month-date-year.log, находящийся во временном каталоге резервного копирования. Если в файле есть «ОШИБКА:», это означает, что резервное копирование не было успешным, и существует проблема, которую необходимо проверить.

3.2 Проверьте время создания файлов в томе резервной копии

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

3.3 Проверьте электронную почту пользователя оракула

4. Проверьте производительность базы данных Oracle

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

4.1. Проверка базы данных на события ожидания

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

4.2 Получить оператор SQL с самым высоким показанием диска

4.3. Найти десятку плохо работающих SQL

4.4 Пять систем с наибольшим временем ожидания ждут сбора событий

4.5 Проверка долгосрочного SQL

4.6. Проверьте процесс, который потребляет больше всего процессора

4.7 Проверьте таблицы с высокой фрагментацией

4.8 Проверьте соотношение ввода-вывода в табличном пространстве

4.9 Проверьте соотношение ввода / вывода файловой системы

4.10 Проверка на тупик и обработку

Запрос информации о текущем объекте блокировки:

Уровень Oracle убивает сессию:

Сеанс уничтожения на уровне операционной системы:

5. Проверьте базу данных процессора, ввода-вывода, производительность памяти

Запишите использование ЦП, ввода-вывода, памяти и т. Д. Базы данных, используйте команды vmstat, iostat, sar, top и другие для сбора информации и проверки информации для определения использования ресурса.

5.1 Использование процессора:

top - 10:29:35 up 73 days, 19:54, 1 user, load average: 0.37, 0.38, 0.29

Tasks: 353 total, 2 running, 351 sleeping, 0 stopped, 0 zombie

Cpu(s): 1.2% us, 0.1% sy, 0.0% ni,98.8% id, 0.0% wa, 0.0% hi, 0.0% si

Mem: 16404472k total, 12887428k used, 3517044k free, 60796k buffers

Swap: 8385920k total, 665576k used, 7720344k free, 10358384k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

30495 oracle 15 0 8329m 866m 861m R 10 5.4 7:53.90 oracle

32501 oracle 15 0 8328m 1.7g 1.7g S 2 10.6 1:58.38 oracle

32503 oracle 15 0 8329m 1.6g 1.6g S 2 10.2 2:06.62 oracle

Обратите внимание на синий шрифт выше, эта часть представляет оставшийся ЦП системы. Когда среднее значение падает ниже 10%, это рассматривается как ненормальное использование ЦП. Вам необходимо записать это значение и записать состояние как ненормальное.

5.2 Использование памяти:

total used free shared buffers cached

Mem: 2026 1958 67 0 76 1556

-/+ buffers/cache: 326 1700

Swap: 5992 92 5900

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

5.3 Ситуация с системным вводом / выводом:

Linux 2.6.9-22.ELsmp (AS14) 07/29/2009

avg-cpu: %user %nice %sys%iowait %idle

0.16 0.00 0.05 0.36 99.43

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

sda 3.33 13.16 50.25 94483478 360665804

avg-cpu: %user %nice %sys%iowait %idle

0.00 0.00 0.00 0.00 100.00

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn

sda 0.00 0.00 0.00 0 0

Как показано выше, синий шрифт указывает состояние чтения и записи диска, а красный шрифт указывает состояние ожидания ввода-вывода ЦП.

5.4 Системная нагрузка:

12:08:37 up 162 days, 23:33, 15 users, load average: 0.01, 0.15, 0.10

Как показано выше, синий шрифт обозначает нагрузку на систему. Если следующие три значения превышают 2,5, это указывает на то, что система работает при перегрузке. Запишите это значение в таблицу проверки и сочтите его ненормальным.

5.5 Проверьте, есть ли процесс зомби

Некоторые процессы зомби блокируют нормальную работу других сервисов и регулярно убивают процессы зомби.

5.6 Проверьте ссылку на линию / миграцию

Примечание. Обычно таблица с длинными необработанными столбцами имеет ссылку на строку, находит строку миграции и сохраняет ее в таблице chained_rows. Если такой таблицы нет, выполните ее.

Вы можете увидеть, какие строки являются перенесенными строками по таблице имя_хеда, head_rowid в таблице chained_rows

5.7 Регулярный статистический анализ
Для системы, использующей Oracle Cost-Based-Optimizer, необходимо регулярно собирать и обновлять статистическую информацию объектов данных, чтобы оптимизатор мог составить правильный план объяснения на основе подготовленной информации. Статистическая информация должна обновляться в следующих ситуациях:
а. Изменения в приложении
б. Масштабная миграция данных, миграция исторических данных, импорт других данных и т. д.
C. Количество данных изменилось
Проверьте, нужно ли обновлять статистику таблицы или индекса, например:

Если количество строк сильно отличается, таблица должна обновлять статистическую информацию, поэтому рекомендуется собирать статистическую информацию раз в неделю, например:

5.8 Проверьте частоту попаданий в буфер

Если частота попаданий ниже 90%, вам нужно увеличить параметр базы данных db_cache_size.

5.9 Проверка коэффициента попадания в общий пул

Если оно ниже 95%, вам необходимо настроить приложение для использования переменных связывания или настроить размер общего пула параметров базы данных.

5.10 Проверьте область сортировки

Если отношение диск / (памятка + строка) слишком велико, вам нужно настроить sort_area_size (workarea_size_policy = false) или pga_aggregate_target (workarea_size_policy = true).

5.11 Проверьте буфер журнала

Если повторное размещение буфера повторных попыток / повторных записей превышает 1%, вам нужно увеличить log_buffer.

6. Проверьте безопасность базы данных

В этом разделе мы в основном проверяем безопасность базы данных Oracle, в том числе: проверяем информацию о безопасности системы, регулярно меняем пароль, всего две части.

6.1 Проверьте информацию журнала безопасности системы

Каталог файла журнала безопасности системы находится в / var / log, который в основном проверяет информацию журнала пользователя об успешном или неудачном входе в систему.

Проверьте журнал успешного входа в систему:

Jan 8 08:44:43 rac2 sshd[29559]: Accepted password for root from ::ffff:10.10.10.6 port 1119 ssh2……

Проверьте журнал неудачного входа в систему:

Jan 9 10:30:44 rac2 sshd[3071]: Invalid user ydbuser from ::ffff:192.168.3.5

Jan 9 10:30:56 rac2 sshd[3071]: Failed password for invalid user ydbuser from ::ffff:192.168.3.5 port 36005 ssh2

Jan 10 22:44:38 rac2 sshd[21611]: Failed password for root from ::ffff:10.10.10.6 port 1723 ssh2

6.2 Проверьте пользователя, чтобы сменить пароль

В системе баз данных часто бывает много пользователей, таких как: сторонние системы мониторинга баз данных, демонстрационные пользователи во время первоначальной установки базы данных, пользователи-администраторы и т. Д. Пароли этих пользователей часто пишутся, и многие люди знают, что они будут скрытыми мотивами. Люди привыкли атаковать систему и даже изменять данные. В число пользователей, которым необходимо изменить свои пароли, входят:
Пользователи администратора базы данных SYS, SYSTEM; другие пользователи.
После входа в систему введите cat / etc / passwd в командной строке, чтобы проверить, есть ли среди перечисленных пользователей неиспользуемые или странные учетные записи. Если он существует, он записывается как ненормальный.

Метод изменения пароля:

7. Другие проверки

В этом разделе мы в основном проверяем, является ли текущая задача crontab нормальной и не сработала ли работа Oracle. Существует шесть частей.

7.1 Проверьте, является ли текущая задача crontab нормальной

7.2 Сбой работы Oracle

Если есть проблемы, рекомендуется перестроить задание, например:

7.3. Контролировать рост объема данных

Согласно ежедневной проверке на этой неделе, найдите объекты базы данных с быстро расширяющимся пространством и примите соответствующие меры:

- Удалить исторические данные
Мобильные правила предусматривают, что в базе данных должно храниться не менее 6 месяцев исторических данных, поэтому предыдущие исторические данные можно рассмотреть для резервного копирования, а затем очистить, чтобы освободить занимаемое ими пространство ресурса.

--- Расширить табличное пространство

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

Выполнить оператор SQL:

Таким образом, команда SQL для создания управляющего файла будет сгенерирована в каталоге USER_DUMP_DEST (указан в файле параметров инициализации).

7.4 Проверка на неуспешные индексы

Примечание. Обычно состояние индекса в таблице разделов равно N / A. Если индекс не выполнен, перестройте его, например:

В этой статье я рассмотрю, как Java код, выполняющийся внутри СУБД Oracle, работает с данными в БД. Попутно продемонстрирую работу резолвера (resolver) встроенной Oracle JVM и экспериментально установлю, с какими правами выполняется Java код внутри СУБД - правами владельца кода (definer) или вызывающего пользователя (invoker). В заключение, я продемонстрирую использование SQLJ для включения команд SQL в исходный код JAVA.

Для экспериментов создам таблицу books и вставлю в нее пару строк:

Класс Connector будет предоставлять соединение с БД по умолчанию. Для этого не нужно задавать параметры соединения - это то же соединение, что используется текущим сеансом, в котором выполняется хранимый код Java. Соединение по умолчанию предоставляется серверным внутренним (server-side intrernal) JDBC драйвером.

Операции с таблицей books будет выполнять класс BooksDAO . На самом деле, это очень скромный DAO. Вместо типичного набора операций CRUD мой DAO поддерживает только чтение всех строк ( BooksDAO.listAll() ) и изменение указанной строки таблицы ( BooksDAO.update() ). Для краткости я не стал вводить класс Book , объекты которого представляли бы строку таблицы. Моя задача - продемонстрировать работу с БД из хранимого Java кода, а для этого вполне достаточно реализовать пару операций с таблицей.

Ошибки, если таковые возникают при выполнении команды CREATE AND RESOLVE JAVA SOURCE , можно посмотреть в системном вью user_errors . Для только что созданного объекта запрос будет таким:

Теперь создам PL/SQL обертку для методов класса BooksDAO , пакет demo_books_dao :

Вызову методы класса BooksDAO :

Обратите внимание, что метод BooksDAO.update() не выполняет COMMIT . Внутренний JDBC драйвер также не выполняет (и не поддерживает!) автокоммит, в результате можно откатить сделанные изменения:

До сих пор мои эксперименты ограничиывались работой с Java под одним и тем же пользователем. Это был пользователь ay .

Теперь попробуем вызывать методы класса BooksDAO под пользователем ay2 , который не является владельцем класса. Есть два способа сделать это:

предоставить пользователю ay2 права на выполнение PL/SQL пакета demo_books_dao , тогда пользователь ay2 сможет вызвать методы класса BooksDAO через процедуры-обертки, так же, как это делает пользователь ay ;
предоставить пользователю ay2 права на выполнение Java класса my/demo/BooksDAO , тогда пользователь ay2 сможет определить свой Java класс, вызывающий его методы, и создать PL/SQL обертку для методов собственного Java класса.

Как известно, PL/SQL код выполняется с правами владельца этого кода (если явно не указать, что код должен выполняться с правами вызывающего пользователя). То есть, вызванная нами процедура ay.demo_books_dao.list_all_books выполнилась с правами пользователя ay , который одновременно является владельцем хранимого Java класса BooksDAO и таблицы books .

Теперь попробуем второй способ.

Вызовем методы класса BooksDAO непосредственно под пользователем ay2 . PL/SQL процедура-обертка и оборачиваемый ею Java метод должны находиться в одной и той же схеме. Поэтому, под пользователем ay2 создадим Java класс-обертку для класса BooksDAO , принадлежащего пользователю ay . Для того, чтобы Java класс пользователя ay2 мог использовать класс BooksDAO в другой схеме, необходимо

выдать пользователю ay2 права на выполнение класса BooksDAO ;
при создании Java класса в схеме ay2 указать спецификацию резолвера, которая позволит отыскать класс в схеме ay .

В приведенном коде строка RESOLVER ((* AY) (* PUBLIC)) говорит о том, что классы, от которых зависит данный класс, нужно искать в схемах AY и PUBLIC . Попробуйте убрать спецификацию резолвера - и получите ошибки "cannot find symbol" :

В случае, когда спецификация резолвера не указана, резолвер ищет зависимости в текущей схеме и в схеме PUBLIC - такова спецификация резолвера по умолчанию.

Успешно создав валидный Java класс BooksDAOWrapper в схеме ay2 , создадим для него пакет-обертку в этой же схеме:

Вызовем процедуру list_all_books :

Мы получили ошибку "ORA-00942: table or view does not exis" . Дело в том, что хранимый Java код, в отличие от хранимого PL/SQL кода, по умолчанию выполняется с правами вызывающего пользователя(!), а не с правами владельца. Метод BooksDAOWrapper.listAll() не видит таблицы books потому, что ее не видит пользователь ay2 - владелец класса BooksDAOWrapper .

Итак, эксперименты с вызовами Java методов пользователем Oracle, который не является владельцем Java кода, показали

как использовать спецификацию резолвера в предложении CREATE AND RESOLVE JAVA SOURCE ,
что Java код выполняется с правами вызывающего пользователя, а не с правами владельца кода.

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

Найдем спецификацию резолвера для определенного нами класса в системном словаре Oracle:

Спецификации резолвера используются в предложениях CREATE JAVA , ALTER JAVA , и с утилитой loadjava . Несколько примеров спецификаций резолвера из документации Oracle:

Полезно запомнить, что

объект JAVA SOURCE приобретает статус VALID, если успешно откомпилирован;
объект JAVA CLASS приобретает статус VALID, если зависимости успешно разрешены;
объект JAVA RESOURCE всегда имеет статус VALID.

Для рассмотрения следующей темы вернусь к работе в схеме ay . Я собираюсь реализовать функциональность BooksDAO при помощи SQLJ.

SQLJ позволяет программисту писать меньше кода и делает программу более читабельной. Однако, SQLJ пригоден только для статических команд SQL. Если необходимо динамически конструировать и выполнять команды SQL, то нужно напрямую работать с JDBC API.

СУБД Oracle предоставляет

серверный внутренний препроцессор SQLJ, который преобразует предложения SQLJ в код Java, использующий серверный внутренний JDBC драйвер и соединение с БД по умолчанию;
утилиту командной строки sqlj , которая генерирует код Java, использующий обычный JDBC драйвер и параметризуемое соединение с БД.

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

В СУБД имеется также обычный тонкий (thin) драйвер, с помощью которого можно открывать соединения под другими пользователями и с другими серверами. Работа с тонким JDBC драйвером на сервере ничем не отличается от работы с клиентским тонким JDBC драйвером.

Итак, создадим класс BooksSQLJ , функционально аналогичный классу BooksDAO :

Создам обертку для методов класса BooksSQLJ :

Протестирую работу класса BooksSQLJ так же, как тестировал работу класса BooksDAO :

При компиляции программного модуля PL/SQL его исходный код сохраняется в базе данных Oracle. Это дает разработчикам два важных преимущества:

Информацию о программном коде можно получить с помощью запросов SQL. Разработчики могут писать запросы и даже целые программы PL/SQL , которые читают информацию из представлений словаря данных и даже могут изменять состояние кода приложения.
База данных Oracle управляет зависимостями между хранимыми объектами. В мире PL/ SQL не существует процесса «компоновки» исполняемых файлов, которые затем запускаются пользователями. База данных берет на себя все служебные операции, позволяя разработчику сосредоточиться на реализации бизнес-логики.

В следующих разделах представлены основные источники информации в словаре данных СУБД Oracle.

Представления словаря данных

Словарь данных 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 , будет рассказано далее.

Вывод и поиск исходного кода

Исходный код программ следует всегда хранить в текстовых файлах (или в средах разработки, предназначенных для хранения и работы с кодом 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 , чтобы в понедельник утром администратор мог проверить наличие данных обратной связи в интрасети.

Проверка ограничений размера

Представление 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 ). Эта информация позволяет быстро определить, какие программы в пакете используют модель привилегий вызывающей стороны или создателя. Пример такого запроса:

Анализ и изменение состояний триггеров

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

Включение или отключение всех триггеров для заданной таблицы. Вместо того чтобы писать код вручную, вы выполняете соответствующие команды DDL из кода PL/SQL. Пример такой программы приведен в статье «Сопровождение триггеров».
Поиск триггеров, выполняемых при изменении некоторых столбцов, но не имеющих предложения секции WHEN . Следующий запрос поможет найти триггеры, не имеющие секции WHEN , которые являются источниками потенциальных проблем:

Анализ аргументов

Представление 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 . Впрочем, эти два механизма отличаются некоторыми особенностями работы с типами данных.

Анализ использования идентификаторов (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*.*.

Зависимые объекты могут содержать в своем описании ссылки на следующие объекты базы данных:

При изменении определения ссылаемого объекта, зависимые объекты приобретают статус INVALID. Статус объекта отображается в колонке STATUS представления USER_OBJECTS словаря данных. В зависимости от характера произведенных изменений в описании ссылаемого объекта, зависимый объект или может быть автоматически перекомпилирован сервером базы данных, или не может быть использован без внесения поправок.

Зависимости могут быть прямыми, когда зависимый объект прямо ссылается на объекты базы данных, или непрямыми, когда зависимый объект ссылается на объекты базы данных через другие объекты (подпрограмма ссылается на представление, которое зависит от таблицы базы данных).

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

Информация о зависимостях

Информацию о прямых зависимостях между объектами базы данных можно получить через представление USER_DEPENDENCIES словаря данных.

Имя зависимого объекта базы данных

Тип зависимого объекта (PROCEDURE, FUNCTION, PACKAGE, PACKAGE BODY)

Схема, в которой находится ссылаемый объект

Имя ссылаемого объекта

Тип ссылаемого объекта

SQL> SELECT name, type, referenced_name, referenced_type

2 FROM user_dependencies

3 WHERE referenced_name='EMP';

NAME TYPE REFERENCED_NAME REFERENCED_T

PRES_SAL FUNCTION EMP TABLE

EMP_SAL PROCEDURE EMP TABLE

Чтобы получить информацию о непрямых зависимостях, необходимо заполнить таблицы базы данных DEPTREE и IDEPTREE, выполнив хранимую процедуру DEPTREE_FILL. Таблицы и процедура должны быть предварительно созданы администратором базы данных.

Перекомпиляция хранимых подпрограмм

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

Хранимые программные единицы могут быть перекомпилированы явно с помощью команд DDL ALTER PROCEDURE и ALTER FUNCTION.

ALTER PROCEDURE имя_процедуры COMPILE

ALTER FUNCTION имя_функции COMPILE

Перекомпиляция зависимых объектов пройдет успешно

· При добавлении колонки к ссылаемой таблице

· Если типы данных ссылаемых колонок не изменяются

SQL> ALTER TABLE emp ADD (comments VARCHAR2(100));

SQL> SELECT object_name, object_type, status FROM user_objects

2 WHERE object_type='PROCEDURE' OR object_type='FUNCTION';

OBJECT_NAME OBJECT_TYPE STATUS

EMP_SAL PROCEDURE INVALID

PRES_SAL FUNCTION INVALID

SQL> SELECT ename, sal, pres_sal(sal) FROM emp WHERE LOWER(job)='clerk';

ENAME SAL PRES_SAL(SAL)

ADAMS 1100 1600

MILLER 1300 1800

SQL> SELECT object_name, object_type, status FROM user_objects

2 WHERE object_type='PROCEDURE' OR object_type='FUNCTION';

OBJECT_NAME OBJECT_TYPE STATUS

EMP_SAL PROCEDURE INVALID

PRES_SAL FUNCTION VALID

Перекомпиляция зависимых объектов пройдет с ошибками, если

· Удален или переименован ссылаемый объект

· Изменен тип данных ссылаемой колонки

· Ссылаемое представление пересоздано с другими колонками

· Изменен список формальных параметров ссылаемой подпрограммы

SQL> RENAME emp TO emp_new;

SQL> SELECT object_name, object_type, status FROM user_objects

2 WHERE object_type='PROCEDURE' OR object_type='FUNCTION';

OBJECT_NAME OBJECT_TYPE STATUS

EMP_SAL PROCEDURE INVALID

PRES_SAL FUNCTION INVALID

SQL> SELECT ename, sal, pres_sal(sal) FROM emp WHERE LOWER(job)='clerk';

SELECT ename, sal, pres_sal(sal) FROM emp WHERE LOWER(job)='clerk'

ERROR at line 1:

ORA-00942: table or view does not exist

SQL> SELECT object_name, object_type, status FROM user_objects

2 WHERE object_type='PROCEDURE' OR object_type='FUNCTION';

OBJECT_NAME OBJECT_TYPE STATUS

EMP_SAL PROCEDURE INVALID

PRES_SAL FUNCTION INVALID

Чтобы перекомпиляция зависимых объектов после изменения определений ссылаемых объектов проходила успешно, выполняйте следующие рекомендации при создании программных единиц:

· Описывайте локальные идентификаторы, используя атрибуты %TYPE и %ROWTYPE

· При чтении данных из таблиц базы данных используйте нотацию SELECT *

· При добавлении данных в таблицу базы данных явно указывайте список колонок в предложении INSERT

Литература

1. Вильям Дж. Пэйдж Использование Oracle8/8i: пер. с англ. – М.: Издательский дом "Вильямс", 1999.

Читайте также: