|
|
|||||||||||||||||||||||||||||
|
Наиболее важные возможности для АБД Oracle Database 10g: Выпуск 2 - Дополнительные свойства. Часть 2: Возможности управленияИсточник: Oracle Magazine
Часть 2: Возможности управления Источник: сайт корпорации Oracle, раздел "Технологические статьи" (Technical Articles), 01 июля 2005, Аруп Нанда, Oracle ACE, представляет свой список наиболее важных новых возможностей для администраторов баз данных. Ранее на русском языке опубликованы:
Самоуправляемая база данных становится более таковой при наличии инструментария командной строки Автоматического Управления Памятью Хранения (ASM), непосредственного доступа в SGA, поддержки оперативного переопределения секций и другого. В этом Выпуске представлены: Инструментарий командной строки ASM ASM - Автоматическое управление памятью хранения (Oracle Automatic Storage Management -ASM; см. Часть 1 ( http://www.oracle.com/technology/pub/articles/10gdba/nanda_10gr2dba_part1.html ) этой серии [ прим. OM/RE : скорее всего речь идет о первой серии статей А.Нанда, где в "Неделя 8" рассматривается ASM. Русский перевод этой статьи: http://www.oracle.com/global/ru/oramag/nov2004/admin_10g_20f_4.html ]) - это специализированная файловая система, введенная в Oracle Database 10 g Выпуск 1, обеспечивающая необходимую и достаточную поддержку управления файлами данных. Администрирование ASM осуществляется посредством команд SQL или, в случае необходимости, через интерфейс Oracle Enterprise Manager. Аналогично, она наблюдаема через SQL-интерфейс или GUI (графический интерфейс пользователя). Такое решение удовлетворяет большинство АБД, но некоторые системные администраторы (sysadmins), незнакомые с SQL, не принимают идею изучения SQL. С другой стороны, вы, как АБД, не будете, вероятно, в большом восторге от предоставления не-АБД возможности обращения к Oracle Enterprise Manager. В Oracle Database 10g Выпуск 2 новый инструментарий командной строки ASM ликвидирует этот разрыв. Его интерфейс, названный asmcmd, позволяет делать много операций с файлами данных, сохраняемых в дисковых группах (diskgroups) ASM, которые сродни файловым системам и соответствующим файлам. Этот инструмент основан на Perl, так что он должен быть прописан в пути (path). Если путь к Perl должным образом не установлен, можно создать мягкую ссылку (soft link) к директории, где располагается Perl, или же только изменять файл asmcmd, в котором отразить правильный путь к исполняемой Perl-программе. Не забудьте установить [переменную среды] ORACLE_SID для экземпляра ASM (обычно +ASM), который отличен от экземпляра собственно базы данных, функционирующей на сервере. Вызовите команду, набрав asmcmd -p опция -p устанавливает отображение текущего пути в приглашении (prompt). Теперь испробуем некоторые очень простые команды. После установки приглашения командной строки (ASMCMD>), введем команду ls, чтобы увидеть все смонтированные дисковые группы (diskgroups). ASMCMD [+] > ls DGROUP1/ DGROUP10/ DGROUP2/ DGROUP3/ DGROUP4/ DGROUP5/ DGROUP6/ DGROUP7/ DGROUP8/ DGROUP9/ Здесь можно увидеть все созданные и смонтированные дисковые группы для экземпляра ASM (от DGROUP1 до DGROUP10). Теперь посмотрим на дисковую группу DGROUP1. Подобно изменению директории можно зайти в дисковую группу, использовав команду cd. ASMCMD [+] > cd dgroup1 Если вы находитесь UNIX-подобной операционной системе (OS) или даже в Windows, то можно перейти на директорию предыдущего уровня, введя команду "cd ..". Теперь посмотрим, какие файлы были созданы в этой дисковой группе. ASMCMD [+dgroup1] > ls ORCL/ Хорошо, в настоящий момент дисковая группа содержит ниже еще одну директорию - ORCL. видно, что это - директория, поскольку за ее именем стоит символ слеш (/). Зайдем (cd) в эту директорию и посмотрим (ls) на ее содержимое. ASMCMD [+dgroup1] > cd orcl ASMCMD [+dgroup1/orcl] > ls CONTROLFILE/ PARAMETERFILE/ control01.ctl => +DGROUP1/ORCL/CONTROLFILE/Current.256.551928759 spfileorcl.ora => +DGROUP1/ORCL/PARAMETERFILE/spfile.257.551932189 ASMCMD [+dgroup1/orcl] > В дополнение к командам cd и ls можно использовать другие UNIX-подобные команды, например, rm (удалить директорию или файл), mkdir (создать директорию), и find (найти файлы и директории). Приведем некоторые дополнительные команды: lsdg (сокращение для list diskgroup ) - чтобы идентифицировать диски, смонтированные этим экземпляром ASM, используется команда lsdg. ASMCMD [+] > lsdg State Type Rebal Unbal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Name MOUNTED EXTERN N N 512 4096 1048576 100 40 0 40 0 DGROUP1/ MOUNTED EXTERN N N 512 4096 1048576 100 33 0 33 0 DGROUP10/ MOUNTED EXTERN N N 512 4096 1048576 100 41 0 41 0 DGROUP2/ MOUNTED EXTERN N N 512 4096 1048576 1000 787 0 787 0 DGROUP3/ MOUNTED EXTERN N N 512 4096 1048576 1000 537 0 537 0 DGROUP4/ MOUNTED EXTERN N N 512 4096 1048576 1000 928 0 928 0 DGROUP5/ MOUNTED EXTERN N N 512 4096 1048576 1000 742 0 742 0 DGROUP6/ MOUNTED EXTERN N N 512 4096 1048576 1000 943 0 943 0 DGROUP7/ MOUNTED EXTERN N N 512 4096 1048576 1000 950 0 950 0 DGROUP8/ MOUNTED EXTERN N N 512 4096 1048576 100 33 0 33 0 DGROUP9/ Дополнительно к отображению имен дисков lsdg показывает много другой уместной информации, например, распределено пространства, сколько из него свободно, сколько дисков в группе находятся в автономном (offline) состоянии. Эта информация намного упрощает диагностику проблем. du (сокращение для disk utilization ) - теперь, когда ASM-диски заполнены данными, можно узнать, сколько пространства занято в дисковых группах. Для этой цели можно использовать команду du, также как она используется в UNIX, Linux или Windows. Чтобы определить используемое пространство в некой директории, просто введем: ASMCMD [+] > du /dgroup1 Used_MB Mirror_used_MB 9 9 Команда показывает, что используется 9MB. Поскольку задействовано внешнее зеркалирование (external mirroring), полное использование диска включает еще 9 MB (Mirror_used_MB). Если бы использовался нормальный параметр избыточности (normal redundancy parameter) ASM-дисков, это число было бы другим. help (справка) - разве инструментарий бывает без справки (help)? Не надо помнить ни одной из этих команд. Только введите help, и появляется список команд. Далее можно ввести help <command>, чтобы узнать данные об определенной команде. Например, ниже мы хотим получить информацию о команде mkalias. ASMCMD [+] > help mkalias mkalias <system_alias> <user_alias> Create the specified user_alias for the system_alias. The user_alias must reside in the same diskgroup as the system_alias, and only one user_alias is permitted per file. The SQLPLUS equivalent is "alter diskgroup <dg_name> add alias <user_alias> for <system_alias>". Как можно видеть, этот богатый набор команд делает ASM весьма управляемой файловой системой, даже без надобности познавать интерфейс SQL или Oracle Enterprise Manager. Эти команды легко помещаются в скрипты оболочки и становятся более приемлемыми для широкого диапазона пользователей. Удаление пустых файлов данных (Drop Empty Datafiles) Представьте себе, что допущена довольно-таки обычная ошибка: файл данных только что добавлен в неправильную директорию или к не тому табличному пространству. Не все еще потеряно; файл данных пока не содержит никаких данных, поэтому его легко можно удалить (drop), не так ли? К сожалению, нет. До Oracle Database 10g Выпуск 2 единственной безупречной (clean) возможностью удаления (removing) файла данных было удаление (drop) всего табличного пространства, а затем его восстановление без этого злополучного файла. Если же табличное пространство содержит данные, нужно пройти отнимающий много времени и трудоемкий процесс сохранения данных в отдельном месте и восстановления табличного пространства. В дополнение к неудобству подобного процесса, он делает табличное пространство недоступным. К счастью, в Oracle Database 10g Выпуск 2 этот процесс упрощен: можно удалить (drop) только файл данных. Например, следующая команда удалит обозначенный файл данных из табличного пространства, а также с сервера. alter tablespace users drop datafile '/tmp/users01.dbf' / Однако, есть пара ограничений: удаляемый файл данных должен быть пустой. Нельзя удалить последний ( в смысле, единственный - ред .) файл данных в табличном пространстве; должно быть удалено самое табличное пространство. А также табличное пространство должно быть оперативным (online) и находиться в состоянии read-write (чтение-запись). Прямой доступ в SGA в зависших/медленных системах Когда пользователи часто [жалуются] на медлительность базы данных, а также на частые тайм-ауты, первое, что сделает большинство АБД, это - соединиться с базой данных как SYSDBA и проверить события ожидания (wait events). Но что происходит, если экземпляр завис, и даже вы (SYSDBA) не можете войти (login)? В этом случае бесполезны ваши даже самые мощные и изящные запросы поиска неисправностей и улаживания конфликтов (troubleshooting). В Oracle Database 10g Выпуск 2 по требованию обстоятельств [утилита] Oracle Enterprise Manager Grid Control может по вашему запросу присоединиться непосредственно к SGA и таким образом непосредственно получить данные о состоянии процесса. Этот так называемый Memory Access Mode (режим доступа к памяти) расширяет возможность эффективного использования Oracle Enterprise Manager даже тогда, когда экземпляр испытывает серьезные проблемы. И самое лучшее, это делается автоматически, когда SQL-доступ в сущности невозможен. Посмотрим, как это работает. В пользовательском интерфейсе (UI) Oracle Enterprise Manager выберем закладку Performance и прокрутим вниз до нижней части страницы до секции, помеченной как "Related Links", которая выводит экран, подобный показанному ниже.
Обратите внимание на ссылку, названную "Monitor in Memory Access Mode" ("Монитор в Режиме Доступа к памяти"). Щелчок по ссылке поднимает показываемый ниже экран. Обратите внимание на ниспадающее меню "View Mode" ("Режим представления"), в котором выбрана опция "Memory Access" ("Доступ к памяти").
Ниспадающее меню "View Mode" можно использовать для управление тем, как Oracle Enterprise Manager получает данные. В этом случае ("Memory Access") будут показаны данные, поступающие из памяти. Также здесь можно выбрать "SQL Access" ("Доступ SQL") для выборки [данных] из представлений производительности (performance views). Обратите внимание, что режим Memory Access не является заменной для SQL-доступа; он предназначен только для критических ситуаций, когда SQL-доступ недоступен. Кроме того, режим Memory Access предоставляет только то подмножество данных, которое пригодно для анализа зависших сессий. (Больше на этой теме я расскажу в следующей статье "Performance features" ("Особенности производительности").) Оперативное переопределение секций (Redefine a Partition Online) Когда у АБД нет технологического времени (downtime - время простоя), чтобы сделать изменения в таблице, например, ее секционирование, большинство из них прибегают к он-лайновому инструменту переопределения, DBMS_REDEFINITION. Этот инструмент позволяет изменять определения объектов, заданные при их ассемблировании. Однако, DBMS_REDEFINITION имеет ограничение, которое в некоторых случаях может его применение бесполезным. Например, надо переместить секции таблицы в другое табличное пространство. Чтобы сделать это, необходимо переместить таблицу целиком, даже если она секционирована. Если таблица большая, такое решение генерирует такое многожество redo- и undo- записей, что наличием секций нельзя воспользоваться. Однако, если можно было бы перемещать по одной секции одновременно, это существенно сократило бы потребности во времени, пространстве и redo/undo. Oracle Database 10g Выпуск 2 позволяет сделать именно это: можно переопределить единственную секцию таблицы, используя или Oracle Enterprise Manager или командную строку. Давайте рассмотрим пример использования командной строки. Возмем таблицу по имени ACCOUNTS с 11 секциями, которые все находятся в одном и том же табличном пространстве USERS. Надо переместить их в другое табличное пространство ACCDATA, который было создано специально для этой таблицы. Надо перемещать таблицу по одной секции одновременно. Сначала создадим промежуточную таблицу с той же самой структурой как ACCOUNTS таблицы, но с данными в табличном пространстве ACCDATA. SQL> create table accounts_int 2 tablespace accdata 3 as 4 select * from accounts 5 where 1=2 6 / Обратите внимание, где теперь расположены секции: SQL> select partition_name, tablespace_name, num_rows 2 from user_tab_partitions 3 / PARTITION_NAME TABLESPACE_NAME NUM_ROWS ------------------------------ ------------------------------ ---------- P1 USERS 1014 P2 USERS 1042 P3 USERS 1002 P4 USERS 964 P5 USERS 990 P6 USERS 1042 P7 USERS 915 P8 USERS 983 P9 USERS 1047 P10 USERS 1001 PMAX USERS 0 11 rows selected. Все секции находится в табличном пространстве USERS. Теперь переместим первую секцию P1 в табличное пространство ACCDATA. SQL> begin 2 dbms_redefinition.start_redef_table ( 3 uname => 'ARUP', 4 orig_table => 'ACCOUNTS', 5 int_table => 'ACCOUNTS_INT', 6 part_name => 'P1' 7 ); 8 end; 9 / PL/SQL procedure successfully completed. Обратите внимание на строку 6, где параметр part_name определяет секцию, которая будет реорганизована. Если этот параметр опущен, будут одновременно переопределены все секции. Теперь синхронизируем промежуточную таблицу с первоначальной таблицей. (Это надо сделать, только если были модификации, прошедшие в таблице ACCOUNTS.) SQL> begin 2 dbms_redefinition.sync_interim_table ( 3 uname => 'ARUP', 4 orig_table => 'ACCOUNTS', 5 int_table => 'ACCOUNTS_INT', 6 part_name => 'P1' 7 ); 8 end; 9 / PL/SQL procedure successfully completed. SQL> begin 2 dbms_redefinition.finish_redef_table ( 3 uname => 'ARUP', 4 orig_table => 'ACCOUNTS', 5 int_table => 'ACCOUNTS_INT', 6 part_name => 'P1' 7 ); 8 end; 9 / PL/SQL procedure successfully completed. Удостоверимся, что секция P1 действительно была перемещена в табличное пространство ACCDATA. SQL> select partition_name, tablespace_name, num_rows 2 from user_tab_partitions 3 / PARTITION_NAME TABLESPACE_NAME NUM_ROWS ------------------------------ ------------------------------ ---------- P1 ACCDATA 1014 P2 USERS 1042 P3 USERS 1002 P4 USERS 964 P5 USERS 990 P6 USERS 1042 P7 USERS 915 P8 USERS 983 P9 USERS 1047 P10 USERS 1001 PMAX USERS 0 11 rows selected. На месте. Повторим ту же самую процедуру для других секций. Сопоставим. Если бы реорганизовалась таблица целиком, то иначе была бы ошибка. Однако, проводя процесс для отдельной секции, снижаются требования к пространству и уменьшается undo-генерирация только для этой секции. Эта мощная и полезная особенность дает возможность оперативно реорганизовывать очень большие объекты - как наиболее секционируемые объекты. Кроме того, обратите внимание, что статистические данные также копируются в переопределенную таблицу, что показано в значениях NUM_RWS в приведенном выше запросе; поэтому не нужно восстановить статистику для недавно созданной таблицы или секций. Проверка целостности блоков в памяти, а не только на диске Активный экземпляр базы данных перемещает много данных - из сеанса пользователя в буферный кэш, из кэша на диск и наоборот. Все эти передвижения могут сделать блок данных восприимчивым к искажению. Oracle гарантирует целостность данных блока, вычисляя контрольную сумму значений данных перед записью блока на диск. Это значение контрольной суммы также записывается на диск. Когда блок читается с диска, процесс считывания снова вычисляет контрольную сумму, а затем сравнивает ее с сохраненным значением. Если данные разрушены, контрольные суммы будут отличаться, тем самым выявляется повреждение. Поскольку большинство манипуляций происходит в памяти, было бы разумно исполнять эту проверку непосредственно в источнике, которым является буферный кэш. В Oracle Database 10g Выпуск 2 можно заставить базу данных выполнить также проверку в памяти, устанавив в FULL параметр инициализации DB_BLOCK_CHECKSUM. После этой установки Oracle вычисляет контрольную сумму перед любым изменением и сравнивает контрольную сумму с сохраненным значением. Такое решение выявляет любое нарушение целостности данных непосредственно в памяти и сразу же сообщает об ошибках, что является очень полезным для предотвращения нарушения целостности данных на дисковом уровне, также как и для предотвращения его прохождения в резервную (standby) базу данных. Пожалуйста, обратите внимание, что по умолчанию этот параметр установлен в FALSE в отличие от предыдущих Выпусков, где он установлен в TRUE. Оперативное изменение установок инсталляции (Online Limit Changes) Когда требуется изменить параметры, определенные в процессе создания базы данных, например, MAXDATAFILES, MAXLOGFILES и так далее, как следует поступать? До Oracle Database 10g Выпуск 2 единственной возможностью было выполнение следующих шагов:
Само собой разумеется, это решение снижает готовность. Кроме того, поскольку RMAN хранит метаданные о резервирных копиях в управляющем файле, также как и в директории, то эта информация утрачивается в ходе подобного процесса. Управляющий файл (controlfile) создается в режиме RESETLOGS, поэтому какая-то часть информации о резервированиях также может быть потеряна. В Oracle Database 10g Выпуск 2 не надо обновить управляющий файл, чтобы изменить эти параметры. Таким образом, вы не потеряете сохраненную в нем RMAN-информацию. Более быстрый Запуск (Faster Startup) Времена, когда динозавры правляли землей и память2GB считалась большой, ушли. Сейчас не редко можно увидеть большие буферные кэши до 100GB. Время старта экземпляра может составлять от нескольких минут до нескольких часов, чтобы проинициализировать буферный кэш такого размера. Если более внимательно посмотреть на эту ситуацию, то стоит обратить внимание, что когда стартует экземпляр базы данных, не требуется полный буферный кэш. Сразу после старта экземпляра буферный кэш пуст, он постепенно заполняется, когда пользователи выбирают данные из таблиц. Поэтому нет никакой необходимости инициализировать весь буферный кэш, когда стартует экземпляр. В Oracle Database 10g Выпуск 2 это обстоятельство нашло отражение в логике запуска. Когда стартует экземпляр, инициализируется только 10% буферного кэша; остальная память будет проинициализирована процессом контрольной точки после того, как база данных открыта. Такое новое решение значительно уменьшает время запуска экземпляра. Имейте, однако, в виду, что пока полный буферный кэш не проинициализирован, задание размера автоматического буферного кэша не возможно. Управление несколькими объектами в Oracle Enterprise Manager Что обычно делает АБД, когда несколько схемных объектов становятся инвалидными? Наиболее вероятно, что он создает SQL-скрипт, который динамически сгенерирует другой скрипт, который перекомпилирует инвалидные объекты. По крайней мере, это - предпочтительный подход, не нуждающийся в дополнительном инструментарии. Но не лучше, если бы можно было использовать для той цели утилиту Oracle Enterprise Manager Grid? Не только выбирать инвалидный объект и щелчком перекомпилировать его, но по существу выбирать несколько инвалидных объектов и одновременно перекомпилировать их одним щелчком? Oracle Database 10g Выпуск 2 допускает такую способность. Как ниже показано на рисунке, все, что нужно сделать, это отметить позиции списка объектов. После этого следует выбрать "Compile" в ниспадающем списке следом за рядом "Actions", чтобы одновременно перекомпилировать все объекты.
Кроме перекомпиляции можно выполнить много других действий, например, [выполнить] DDL создания (creating) или удаления (dropping) объектов. Аудит-следы в формате XML (Audit Trails in XML Format) Если вы в течение долгого времени использовали встроенные в Oracle инструментальные средства аудита, то, возможно, заметили, что есть одна очень полезная возможность - способность записывать аудит-следы в файловой системе. Возможность записи [аудит]-входов в файловой системе, а не непосредственно в базе данных, устанавливает дополнительный уровень защиты. Все, что нужно сделать, это задать два параметра инициализации: audit_file_dest = '/auditfs' audit_trail = xml и перестартовать экземпляр. Однако, эти два параметра не являются динамическими; коль скоро они установлены, аудит-следы будут размещаться в директории /auditfs. Параметр audit_file_dest является дополнительным; значение по умолчанию - директория $ORACLE_HOME/rdbms/audit. Файлы аудит-следов будут представлять собой XML-файлы с расширением .xml. Приведем пример аудит-следа в формате XML: - <Audit xmlns="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-10_2.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/dbserver_audittrail-10_2.xsd"> <Version>10.2</Version> - <AuditRecord> <Audit_Type>8</Audit_Type> <EntryId>1</EntryId> <Extended_Timestamp>2005-03-05T20:52:51.012045</Extended_Timestamp> <DB_User>/</DB_User> <OS_User>oracle</OS_User> <Userhost>oradba</Userhost> <OS_Process>18067</OS_Process> <Terminal>pts/0</Terminal> <Instance_Number>0</Instance_Number> <Returncode>0</Returncode> <OS_Privilege>SYSDBA</OS_Privilege> <Sql_Text>CONNECT</Sql_Text> </AuditRecord> </Audit> Для того чтобы извлечь полезную информацию, эти трассовые файлы могут быть легко проанализированы любым синтаксическим XML- анализатором. Их можно даже загрузить в базу данных как XML-типы, а затем выполнить к ним SQL-запрос, используя XML Query, как было показано в первой серии статей. В Oracle Database 10g Выпуск 2 можно объединить этот XML [-файл] с SQL-запросом и выбрать от него [данные], как будто все достается из единого SQL-источника. Также существует предопределенное динамическое представление V$XML_AUDIT_TRAIL, которое выбирает данне по фиксированной таблице X$XML_AUDIT_TRAIL. Это динамическое представление иметь сходство с регулярным представлением аудит-следов DBA_AUDIT_TRAIL. Для АБД, владеющего аудит-следами в XML-формате, открываются широкие возможности для манипулирования файлами посредством XML-парсеров и редакторов от третьих фирм, а также для публикации отчетов при помощи инструментальных средств, которые принимают XML, как входные данные. Более нет нужды в разработке своего собственного парсера (синтаксического анализатора), чтобы интерпретировать файлы аудит-следов. Автоматический сегментный советчик (Automatic Segment Advisor) Знаете ли вы, какие сегменты обладают большим объемом свободного пространства за "водоразделом" (high-water mark - высшая точка заполнения сегмента данными) и какую пользу можно извлечь из реорганизации? Можно использовать интерфейс утилиты Oracle Enterprise Manager, представленной в Oracle Database 10g , указав определенное табличное пространство, чтобы идентифицировать потенциальных кандидатов. Но если ваша база данных содержит несколько сотен табличных пространств, возможно, что вы не можете делать это каждый день. Но даже если бы это можно было сделать, не каждое табличное пространство содержит сегменты, которые требуется реорганизовывать. Поэтому хорошо бы иметь автоматический инструмент, который упреждающе бы просматривал сегменты и сообщал обо всех потенциальных кандидатах на реорганизацию. Oracle Database 10g Выпуск 2 предоставляет пакет DBMS_SPACE, куоторый обеспечивает эту возможность. Встроенная функция ASA_RECOMMENDATIONS показывает подобные сегменты; поскольку эта функция с конвейерной организацией (pipelined), ее нужно использовать следующим образом: select * from table (dbms_space.asa_recommendations()); Большое количество столбцов может помешать четко увидеть выходной листинг. Поэтому приведем только один отчет, показанный в вертикальном формате. TABLESPACE_NAME : USERS SEGMENT_OWNER : ARUP SEGMENT_NAME : ACCOUNTS SEGMENT_TYPE : TABLE PARTITION PARTITION_NAME : P7 ALLOCATED_SPACE : 0 USED_SPACE : 0 RECLAIMABLE_SPACE : 0 CHAIN_ROWEXCESS : 17 RECOMMENDATIONS : The object has chained rows that can be removed (Этот объект содержит сцепленные записи, которые можно удалить при реорганизации) by re-org. C1 : C2 : C3 : TASK_ID : 261 MESG_ID : 0 Из листинга следует, что секция P7 таблицы ACCOUNTS в схеме ARUP содержит сцепленные записи. Выполнив реорганизацию, можно ускорить операции полного сканирования этой секции таблицы. Эта информация собирается автоматически спланированной работой, которая выполняется в предопределенном интервале обслуживания (между 10PM и 6AM в будние дни и от полудня (12 дня) субботы до полудня понедельника). Эти интервалы можно изменить, используя Oracle Enterprise Manager. В течение этого время работа просматривает сегменты- кандидаты. Если это сканирование не сможет закончиться в отведенное время, работа приостанавливается и продолжается в интервале обслуживания следующего дня. The job stores the information about the segments and tablespaces inspected in a table named wri$_segadv_objlist. You can see the information on the segments inspected in the view DBA_AUTO_SEGADV_CTL. Работа сохраняет информацию о сегментах и просмотренных табличных пространствах в таблице, называемой wri$_segadv_objlist. Информацию о просмотренных сегментах можно увидеть в представлении DBA_AUTO_SEGADV_CTL. Пособытийное планирование (Event-Based Scheduling) Планировщик Oracle Scheduler, представленный в Oracle Database 10g Выпуск 1, является системой планирования работ следующего поколения, заменяя собой поставляемый пакет DBMS_JOB. Механизм Планировщика (Scheduler) имеет много существенных преимуществ перед указанным пакетом, что изначально было описано по адресу http://www.oracle.com/technology/pub/articles/10gdba/week19_10gdba.html [см. русский перевод этой статьи в нашем журнале по адресу http://www.oracle.com/global/ru/oramag/june2005/admin_10g_20f_9.html ]. В первом Выпуске Oracle Scheduler работы были привязаны и вызвались по времени. Но что если, например, надо базировать, запускать работу по наступлению некоего события? Например, если Account Manager заменяет учетную запись, можно пожелать, чтобы пакетная программа автоматически воспряла (kick) и повторно вычислила бы доход и переопубликовала отчеты. Этот тип пособытийного запуска может быть использован в механизме Планировщика Scheduler Oracle Database 10g Выпуск 2. События сообщаются Планировщику через AQ (Advanced Queueing - механизм расширенного управления очередями), где полезный груз (payload) представляет собой объектный тип. So, first, you need to create an AQ, for instance proc_queue, where any such events will be enqueued. Next, you have to create a schedule based on this event. Поскольку сначала нужно создать AQ, например proc_queue, где любые такие события будут поставлены в очередь (enqueued). Затем необходимо создать план-график (schedule) для этого события. begin dbms_scheduler.create_event_schedule ( schedule_name => 'accadmin.acc_mgr_change', start_date => systimestamp, event_condition => 'tab.user_data.event_name = ''acc_mgr_change''', queue_spec => 'proc_queue'); end; Затем надо создать работу (job), которая идет по этому план-графику. В качестве альтернативы можно спланировать работу непосредственно, не создавая сначала план-график. begin dbms_scheduler.create_job ( job_name => acc_mgr_change, program_name => acc_mgr_change_procs, start_date => 'systimestamp, event_condition => 'tab.user_data.event_name = ''acc_mgr_change''', queue_spec => 'proc_queue' enabled => true); end; Значение по умолчанию - UNLIMITED. Пособытийное планирование очень полезно в тех случаях, когда наступление события, а не определенного момента времени является фактором, определяющим запуск работы. В части 3 - http://www.oracle.com/technology/pub/articles/10gdba/nanda_10gr2dba_part3.html этой серии я расскажу об особенностях производительности (Performance features)
|
|