В данном случае среднее значение (которое в статистике также часто называют математическим ожиданием) баланса составляет 54948,4654 при среднеквадратичном отклонении 25989,9271. Согласно законам математической статистики, это означает следующее распределение значений в таблице:
Пусть A - среднее, а S - среднеквадратичное отклонение, тогда:
Приблизительно 68% значений находятся в интервале от (A-S) до (A+S)
Приблизительно 95% значений находятся в интервале от (A-2 х S) до (A+2 х S)
Приблизительно 99.7% значений находятся в интервале от (A-3 х S) до (A + 3 х S)
Если распределение имеет такой вид, то его называют нормальным распределением. Однако хотелось бы получить равномерное, а не нормальное распределение. Вот наши значения: A = 54948,4654; S = 25989,9271
Следовательно, 68% данных лежат в диапазоне от 28958,5383 до 80938,3925, согласно следующим выражениям:
54948,4654 - 25989,9271 = 28958,5383
и
54948,4654 + 25989,9271 = 80938,3925
Эти значения показывают, что значения списка весьма разнообразны и не очень скучены вокруг среднего значения. Так что он удовлетворяет определению истинно случайной выборки. При создании тестового стенда для проверки предположений вам придется построить несколько случайных выборок данных, и исследования, подобные только что проведенным нами, помогут вам убедиться в случайности выборок. Мы еще вернемся к этой теме в следующем разделе.
Для этого проверьте статистическое распределение случайных данных в таблице.
Предположим, что вы создаете таблицу заказчиков и заполняете ее именами, которые впоследствии будут использоваться при поиске. Как сгенерировать такие значения? Например, должны ли значения быть произвольными наборами символов, как предложенные ниже?
Я получил эти значения, случайным образом нажимая на кнопки клавиатуры. Но они вряд смогут служить удачными примерами имен заказчиков. В конце концов, имена представляют собой некие определенные последовательности символов (как Jim или Jane), и при создании таблицы тестовых данных необходимо обеспечить максимальную похожесть тестовых значений на реальные. Ваши значения должны браться из множества известных значений, но случайным образом, а не по какому-то предопределенному правилу.
Еще одним важным аспектом, который необходимо учитывать, является распределение. Уникальных имен очень мало. Например, в США часто встречаются такие мужские имена, как John, James или Scott (но очень редко такие, как Arup). Так что при формировании тестовых данных необходимо, чтобы распределение было случайным, но при этом отражало и реальную статистическую модель. Например, будем считать, что среди нашего населения имена распределяются следующим образом:
10%
|
Alan
|
10%
|
Barbara
|
5%
|
Charles
|
5%
|
David
|
15%
|
Ellen
|
20%
|
Frank
|
10%
|
George
|
5%
|
Hillary
|
10%
|
Iris
|
10%
|
Josh
|
Если заполнить столбец FIRST_NAME таблицы ACCOUNTS согласно этому шаблону, то для 10% записей значением FIRST_NAME будет Alan, для других 10% - Barbara и т. д. Теперь давайте попытаемся заполнить остальные столбцы таким же образом, чтобы они отражали реальное положение вещей. Посмотрим на перечень столбцов измененной таблицы ACCOUNTS.
Предположим, что для того чтобы сделать распределение данных приближенным к реальному, я буду создавать данные для столбцов по шаблонам, приведенным в таблице.
Имя столбца
|
Описание
|
Шаблон данных
|
ACC_NO
|
Номер счета
|
Любое число, не более 10 разрядов
|
FIRST_NAME
|
Имя
|
10% - Alan 10% - Barbara 5% - Charles 5% - David 15% - Ellen 20% - Frank 10% - George 5% - Hillary 10% - Iris 10% - Josh
|
LAST_NAME
|
Фамилия
|
Любая буквенная строка длиной от 4 до 30 символов, при этом 25% значений - «Smith»
|
ACC_TYPE
|
Тип счета: сберегательный (savings), текущий (checking) и т. д.
|
20% на каждый из S, C, M, D и X
|
FOLIO_ID
|
Идентификатор листа из других систем
|
Половина - значения NULL, вторая половина - номер, связанный с номером счета
|
SUB_ACC_TYPE
|
Для клиентов- юридических лиц номера суб-счетов (если они есть)
|
75% - значения NULL. Из оставшихся: 5% - S 20% - C
|
ACC_OPEN_DT
|
Дата открытия счета
|
Дата в диапазоне от текущей и до 500 дней назад
|
ACC_MGR_ID
|
Идентификатор администратора данного счета
|
Существует 5 администраторов, счета между которыми распределены в следующем процентном отношении:
- 40%
- 10%
- 10%
- 10%
- 30%
|
Как видите, требования являются умеренно сложными и в точности отражают распределение данных в реальной базе данных. Реальные клиенты будут иметь такие имена, как «Josh» и «Ellen», а не «Xe- pqjEuF», поэтому имена следует выбирать из множества существующих имен. Фамилии в США встречаются самые разнообразные. Поэтому я выбрал полупроизвольное распределение, выделив 25% на чрезвычайно популярную фамилию «Smith». Остальные фамилии могут быть случайными.
Как же сгенерировать данные, отвечающие такому сложному набору правил? Я позаимствую пару страниц из учебника по теории вероятности и последую за теми авторами, которые любят использовать метод Монте-Карло. Следуя этому методу можно сгенерировать случайное число в диапазоне от 1 до 100 (включительно). Если промежуток времени достаточно велик, то вероятность генерирования какого-то конкретного числа (например, 6) будет равняться 0,01 или 1%. На самом деле вероятность генерирования любого числа равна 0,01. Если использовать те же рассуждения, то вероятность получения любого из двух чисел (например, 1 или 2), будет равняться 2%, а любого из трех чисел - 3%. Наконец, вероятность получения одного из чисел между 1 и 10 равна 10%. Используем эти знания для задания вероятности генерируемых случайных значений.
Обратимся, например, к значениям столбца ACC_TYPE, в котором с одинаковой вероятностью должны встречаться S, C, M, D и X, то есть вероятность каждого - 20%. Если генерировать целое число в промежутке от 1 до 5 (включительно), то вероятность появления каждого значения будет равна 20%. Затем используем SQL-функцию DECODE для получения значения ACC_TYPE на основе полученного числа.
Давайте посмотрим, что происходит. Сначала генерируется число от 1 до 5 (строка 1). Генерируемое число меньше максимального значения, передаваемого в параметре, поэтому я указал число 6. Число должно быть целым, поэтому в строке 1 использована функция FLOOR, которая отсекает дробную часть числа. Применяя к сгенерированному числу функцию DECODE, получаем одно из значений: S, C, M, D или X. Вероятность генерирования любого из чисел 1, 2, 3, 4 и 5 равна 20%, соответственно так же будут распределены и буквы: по 20% на каждую.
Этот способ удобен для генерирования случайных, но предопределенных значений (как в нашем примере). Так же можно получить практически любые предопределенные случайные значения.
Если вы вернетесь к требованиям для столбцов нашей таблицы, то заметите, что столбец FOLIO_ID несколько отличается от других. В нем должно быть заполнено только 50% значений, остальные должны содержать NULL. Как этого добиться?
Будем следовать тем же путем, что и в прошлый раз, добавив небольшую хитрость: проверку логического условия («да» или «нет»). При генерировании случайных чисел в диапазоне от 1 до 100 вероятность получения любого числа равна 1%. Следовательно, вероятность получения числа, меньшего, чем 51, составит ровно 50%. Используем этот факт в операторе CASE для получения значения.
В строке 2 проверяется, меньше ли полученное число, чем 51. Если меньше, то возвращаем NULL. Вероятность генерирования числа, меньшего, чем 51, равна 50%, поэтому мы получим 50% значений NULL. На другие 50% приходятся случайные числа в диапазоне от 1 до 100, которые можно использовать как FOLIO_ID.
Функция DMBS_RANDOM.STRING генерирует случайную строку, но фиксированной длины. Однако в реальности фамилии людей имеют переменную длину. Для столбца фамилий определено следующее требование: длина значений должна быть в промежутке между 4 и 30 символами. Для выполнения этого требования можно передавать функции STRING в качестве длины случайную величину, как мы это и сделаем в строке 6.
Теперь строки не только являются случайными, но и имеют случайные разные длины.
Кроме того, необходимо, чтобы 25% фамилий приходились на долю «Smith», а остальные были случайными. Комбинируем случайные строки и метод Монте-Карло:
Это выражение в 25 процентах случаев будет возвращать «Smith», а в остальное время - произвольную буквенную строку длиной от 4 до 30 символов.
Теперь, когда вы познакомились с составляющими процесса генерирования случайных чисел, сведем их все воедино. Напишем фрагмент PL/SQL-кода формирования записей о счетах. В этом разделе будем загружать 100000 записей в таблицу ACCOUNTS (приводится полный текст загружающей программы).
Как узнать, что наши старания привели к нужному результату? Как говорится, не попробуешь - не узнаешь. После загрузки данных проверяем реальное распределение:
Имена полностью отвечают запрошенному распределению. Например, если помните, мы хотели, чтобы 10% строк содержали имя «Alan». Имеем 9766 таких записей из 100000, что составляет приблизительно 10%. Мы хотели 15% записей с именем «Ellen», а получили 15,023% -
очень близко к запрошенному числу и статистически показательно. Можно проверить все остальные столбцы и убедиться в том, что они действительно распределены по выбранному шаблону.
Возможность генерирования случайных значений чрезвычайно важна для множества приложений. Случайный выбор является неотъемлемой частью шифрования, а также играет важную роль в различных других областях. В этой главе показано, как генерировать разнообразные случайные числа и строки различной точности и длины; как обеспечить случайность, используя должные методы задания начального значения последовательности случайных чисел; и как избежать генерирования неслучайных чисел, получаемых при использовании неизменного начального значения. Для того чтобы генерируемые значения лучше отражали картину реального мира, предложены способы создания случайных значений, соответствующих определенным статистическим шаблонам. Наконец, было рассказано о том, как проверить случайность полученных данных.
Администрирование базы данных требует выполнения множества задач. Некоторые из них запускаются сразу, без подготовки, другие должны выполняться регулярно в предопределенное время. В качестве примера можно привести сбор статистики для объектов базы данных, сбор сведений о свободном пространстве внутри базы данных, анализ проблем с экземпляром базы данных и передача по требованию соответствующей информации напрямую администратору базы данных и т. д. Эти задачи могут относиться как к базе данных, так и к операционной системе (например, проверка свободного пространства файловой системы, проверка доступности других серверов и т. д.). Любой администратор базы данных может привести сотню примеров, когда для некоторой задачи (обычно называемой заданием - job) необходимо обеспечить выполнение в определенный момент в будущем, а не выполнять ее незамедлительно.
В этой главе будут описаны возможности PL/SQL по управлению планировщиком заданий в базе данных, а также вне базы данных (но на том же сервере). Данная функциональность обеспечивается двумя встроенными пакетами: DBMS_JOB и DBMS_SCHEDULER. DBMS_JOB, появившийся в Oracle8i, имеет весьма ограниченные возможности. В Oracle 10g Release 1 он фактически заменен пакетом DBMS_SCHEDULER. Новый пакет является гораздо более мощным и надежным средством, так что следует использовать его вместо DBMS_JOB. Эта глава будет посвящена исключительно использованию DBMS_SCHEDULER. Программа Oracle Enterprise Manager с графическим пользовательским интерфейсом, входящая в Oracle 10g, позволяет управлять планировщиком заданий, но ее описание лежит за рамками нашего обсуждения.
Планировщик Oracle включает в себя четыре основных компонента, которые схематично представлены на рис. 8.1.
Окно, которое задает определенную длительность и схему выделения ресурсов для задания.
Параметр job_action, который определяет хранимую процедуру, анонимный блок PL/SQL или исполняемый файл операционной системы.
Параметр repeat_interval, который указывает, когда и как часто должно выполняться задание.
Дополнительно можно сопоставить заданию именованное расписание, которое будет содержать календарные строки. Параметр schedule_name может задавать расписание, окно или группу окон. Задание может выполнять не только действие, указанное в параметре job_action, но и именованную программу, которая ссылается на действия тех же типов, что и параметр job_action (это могут быть хранимые процедуры, анонимные блоки PL/SQL или исполняемые файлы операционной системы).
Задание может входить в определенный класс заданий. Классы заданий объединяют похожие задания и определяют для них некоторые общие свойства (например, уровень журналирования).
Окно определяет начальный и конечный моменты времени, а также план управления ресурсами. Если заданию сопоставлено окно, то выполнение задания начинается и заканчивается в моменты времени, определяемые окном. При этом выполнение задания регулируется
планом ресурсов, определенным для окна. Окно может быть элементом некоторого класса окон. Если заданию сопоставляется класс окон, то на задание действуют все окна класса.
Далее в главе все компоненты планировщика будут рассмотрены подробно и с примерами их использования.
Администратор базы данных Oracle, которому необходимо спланировать выполнение задания на какое-то определенное время в будущем или по расписанию через определенные промежутки времени, имеет две возможности для решения задачи:
Использовать планировщик операционной системы
Выполнить программу или сегмент кода из утилиты операционной системы, такой как cron в Unix или AT в Microsoft Windows. Эти средства позволяют выполнить команду определенной операционной системы. Можно даже запустить задание Oracle из внешнего интерфейса (обычно для этого необходимо создать его как сценарий SQL и запустить в командной строке SQL*Plus).
Использовать планировщик базы данных внутри Oracle
Определить операцию как задание в базе данных, которое должно быть выполнено единожды или периодически повторяться, с помощью пакета DBMS_SCHEDULER. Такое задание базы данных выполняется в контексте базы данных, а не операционной системы.
Если у вас есть возможность использовать стандартный планировщик операционной системы, зачем вообще задумываться о планировщике базы данных? Есть ряд весьма убедительных аргументов.
Зависимость от базы данных
Задание операционной системы работает вне зависимости от доступности базы данных. Что же произойдет, если задание по сбору статистики оптимизатора запустится в запланированное время, а база данных в этот момент по какой-то причине будет остановлена? Задание не выполнится, что может привести к ряду неприятных результатов. В случае со сбором статистики мы еще легко отделаемся, в других ситуациях последствия могут быть более серьезными. Предположим, например, что у вас есть задание операционной системы, которое выполняет ряд задач базы данных и операционной системы и в случае неудачи оповещает администратора базы данных. Если база данных остановлена, оповещение все равно выполняется, хотя и некорректно. Конечно, можно добавить в начало кода несколько строк, чтобы проверять доступность базы данных прежде, чем приступать к выполнению, но тогда придется добавлять
этот код в каждую утилиту, что может усложнить сопровождение. А вот задание базы данных будет выполняться только при запущенной базе данных, и никогда - при остановленной. Это обеспечивает более полный и точный контроль над процессом выполнения.
Защита
Задания являются частью базы данных, поэтому обеспечены такой же защитой, как и все другие объекты базы данных. Вы можете выдавать и отзывать привилегии на определенные задания для отдельных пользователей. При резервном копировании базы данных сохраняются и задания с соответствующей метаинформацией (такой как комментарии, расписания и т. д.).
Посмотрим на синтаксис команды cron в Unix и команды AT (Планировщик заданий) в Windows. Они абсолютно разные. Что если придется переносить базу данных с одной платформы на другую? Для соответствия новой платформе придется изменить каждый сценарий, а это весьма трудоемкая работа. Если же осуществлять управление заданиями из базы данных, то определения заданий будут перенесены на новую платформу вместе с базой данных; так что менять что бы то ни было в определении заданий не придется.
Независимость от места хранения утилит
Предположим, что вы сохранили все свои утилиты в каталоге /и01/ app/dbatools, а затем решили переместить их в другой каталог, и02/ app/dbatools. Если в качестве планировщика используется cron или AT, то такое простое изменение потребует внесения изменений в каждое определение вашего расписания. При использовании планировщика базы данных вообще нет необходимости в предоставлении информации о том, где находятся утилиты.
При вызове кода PL/SQL или даже простого сценария SQL из операционной системы необходимо передавать в выполняемое задание имя пользователя и пароль. Давайте рассмотрим простейший случай. Предположим, что у вас есть сценарий оболочки, который вызывает SQL-сценарий myjob. sql:
$ORACLE_HOME/bin/sqlplus -s scott/tiger @/u01/app/dbatools/my]ob.sql
В команду открытым текстом передается имя пользователя (scott) и его пароль (tiger). Любой пользователь может увидеть эту важнейшую информацию при помощи команды ps -aef, что, естественно, создает брешь в системе безопасности.
Можно попытаться минимизировать риск раскрытия пароля пользователя Scott, немного изменив сценарий. Поместим имя пользователя и пароль внутрь SQL-сценария myjob.sql в качестве информации для подключения к базу данных:
CONNECT scott/tiger blah ... blah ... blah ...
Тогда вызывающий сценарий будет выглядеть следующим образом:
Переключатель /nolog указывает SQL*Plus, что не следует ожидать ввода регистрационных данных в командной строке. Этот подход чуть лучше: имя пользователя и его пароль не видны при просмотре процесса. Однако если пользователь обратится к файлу сценария, то получит доступ к информации (а вы наверняка не хотите, чтобы пользователи видели чужие пароли).
Последним вариантом может стать использование так называемой OPS$-регистрации, которая позволяет операционной системе проводить аутентификацию пользователей. Может существовать Unix- пользователь scott и идентифицируемый извне Oracle-пользователь OPS$SCOTT. Задание cron выглядело бы следующим образом:
$ORACLE_HOME/bin/sqlplus -s / @/u01/app/dbatools/myjob.sql
Однако в этом главный недостаток метода. Он не только основан на том, что ваше регистрационное имя в Oracle совпадает с регистрационным именем в операционной системе, но и позволяет тому, кто получает доступ к вашему паролю операционной системы, подключиться к вашей схеме базы данных без аутентификации.
Если используется планировщик базы данных, то подобные сценарии не понадобятся, и пользовательский пароль никогда не будет раскрыт. Многие компании с высокими требованиями к безопасности имеют строгие правила относительно нераскрытия паролей ни при каких условиях. Для них единственным выходом является планирование в базе данных.
Гибкость
Если вы используете планировщик операционной системы и хотите изменить пароль пользователя, то вам придется изменить его во всех необходимых сценариях оболочки. Некоторые компании для минимизации подобных усилий создают общий центральный файл паролей и считывают его для каждого сценария оболочки. Это несколько упрощает работу, но создает другую проблему. Если пользователь хочет изменить пароль, необходимо изменить файл паролей. Если операционная система разрешает доступ к серверу базы данных только для администратора базы данных (а именно так и должно быть), то обычный пользователь не сможет изменить файл паролей и вынужден будет просить администратора о помощи. Привлечение посторонних к управлению своим паролем является весьма нежелательным.
Если используется планировщик базы данных, то в хранении пароля нет необходимости.
В общем и целом, при необходимости выполнения каких-то связанных с Oracle операций проще, надежнее и эффективнее использовать пакет DBMS_SCHEDULER.
Здесь и далее в главе для ссылки на систему планирования Oracle будем использовать названия DBMS_SCH EDULER или Планировщик (Scheduler).
Базовой единицей работы в планировании является задание. В этом разделе будет описано создание заданий и управление ими в базе данных при помощи процедуры CREATE_JOB пакета DBMS_SCHEDULER. Начнем с простого примера, иллюстрирующего саму идею планирования выполнения заданий.
Предположим, что мы работаем с банковским приложением и хотим обеспечить выполнение задания, которое ежедневно начисляет проценты на остаток на счете. Для начисления процентов используется хранимая процедура apply_interest. Используем программу CREATE_JOB пакета DBMS_SCHEDULER для создания задания планировщика apply_dai- ly_interest:
Строка
|
|
4
|
|
5
|
Параметр repeat_interval указывает, как часто задание должно запускаться. В данном случае ежедневно (об использовании интервалов мы подробно поговорим далее в главе).
|
6
|
Значение TRUE (также принимаемое по умолчанию) параметра активации означает, что задание будет незамедлительно активировано и запущено.
|
7
|
В этой строке можно указать необязательные комментарии для задания, которые впоследствии помогут понять, что делает задание.
|
После того как задание создано, сведения о нем можно найти в представлении словаря данных DBA_SCHEDULER_JOBS. Давайте взглянем на это представление, чтобы проверить результат вызова CREATE_JOB (далее в главе представление DBA_SCHEDULER_JOBS будет описано подробно).
Создано задание, которое вызывает хранимую процедуру. Если не принимать во внимание синтаксические отличия, то основная функциональность на первый взгляд кажется абсолютно идентичной предоставляемой пакетом DBMS_JOB. Однако, прочитав последующие разделы, вы поймете, насколько более широкие возможности поддерживает DBMS_SCHEDULER.
Для удобства просмотра приведем вывод в вертикальном формате: в левом столбце представлены названия столбцов, а в правом - их содержимое.
Предположим, необходимо создать задание, которое запускает сценарий Unix, а не программу PL/SQL. Типичным примером является инкрементальное резервное копирование RMAN. Полный путь сценария RMAN таков: u01/app/oracle/admin/tools/kick_rman_inc.sh. Будучи исполняемым файлом Unix, сценарий лишь частично попадает под юрисдикцию базы данных Oracle. Необходимо ли обращаться для его исполнения к заданию cron? Как уже говорилось выше, недостаток планировщика операционной системы заключается в том, что задание
будет выполняться даже при остановленной базе данных. В нашем же случае хотелось бы, чтобы задание выполнялось только при запущенной базе данных. Неоспоримым преимуществом пакета DBMS_SCHEDULER по сравнению с DBMS_JOB является его способность напрямую определять и выполнять внешние программы из контекста базы данных.
Рассмотрим пример использования процедуры CREATE_JOB пакета DBMS_SCHEDULER для планирования инкрементального резервного копирования RMAN.
Это задание вызывает исполняемый файл UNIX kick_rman_inc. sh. Об ратите внимание, что параметр job_type в строке 5 установлен в значе
ние EXECUTABLE.1
Процедуру CREATE_JOB можно использовать для создания заданий, вы зывающих анонимные блоки кода PL/SQL, например:
В данном случае параметр job_action содержит весь PL/SQL-блок DE- CLARE-BEGIN-END, завершенный точкой с запятой. Вы можете поместить любой корректный анонимный PL/SQL-блок вместо слова code.
После того как задание создано, информация о нем попадает в представление словаря данных DBA_SCHEDULER_JOBS. Приведем описание некоторых основных столбцов (полный перечень можно найти в приложении A).
Владелец задания.
Имя задания.
Если при создании задания пользователь указал идентификатор клиента для сеанса, он будет записан в данный столбец. Для задания идентификатора клиента можно вызвать функцию DBMS_SES- SION.SET_IDENTIFIER.
Если пользователь является глобальным (или корпоративным), то в данный столбец записывается идентификатор глобального пользователя.
Что делает задание. Для PL/SQL-блока отображается весь код. Для исполняемого файла и хранимой процедуры отображается название.
Календарная строка, задающая расписание выполнения задания (например, FREQ=DAILY; BYHOUR=2). (См. также далее раздел «Календарные строки».)
Активно ли задание (TRUE или FALSE).
Текущее состояние задания (например, SCHEDULED, RUNNING, SUCCEEDED, FAILED).
Количество запусков задания.
Количество неудачных выполнений задания.
В случае неудачного выполнения задания предпринимается повторная попытка выполнения. В данном столбце отображается количество повторных попыток. LAST_START_DATE
Продолжительность последнего выполнения задания.
Следующая (в расписании) дата выполнения задания.
Является ли задание системным (TRUE или FALSE).
Внесенные ранее комментарии.
Дополнительные столбцы будут рассматриваться по мере рассмотрения других аспектов функциональности пакета DBMS_SCHEDULER.
Мы знаем, как создать задание, теперь поговорим о том, как управлять этим созданным заданием (если не указано иное, то все задачи выполняются различными программами пакета DBMS_SCHEDULER).
| < Предыдущая | Следующая > |
|---|
