Июнь 2004
Профессионалу администратору
Аруп Нанда
Oracle Database 10g:
20 наиболее привлекательных для АБД возможностей
(Oracle Database 10g: The Top 20 Features for DBAs
by Arup Nanda)
Источник: журнал Oracle Magazine,
OTN Technical Articles (
http://www.oracle.com/oramag/webcolumns/windex.html),
http://otn.oracle.com/pub/articles/10gdba/index.html
В течение 20 недель Arup Nanda, “Лучший АБД 2003 года” по версии журнала Oracle Magazine,
расскажет о наиболее, по его мнению? привлекательных для администраторов баз данных возможностях Oracle Database 10g.
[От редакции OM/RE: не дожидаясь завершнения всей серии мы начинаем
публикацию переводов этих заметно окрашенных индивидуальной авторской интонацией
небольших по объему заметок, но удивительно емких по содержаниею и точных по существу рассматриваемых вопроcов. В каждом выпуске журнала предполагается по две-четыре “недели” от Arup Nanda с тем, чтобы завершение русского варианта не сильно отстало от оригинала.]
План публикаций
|
Week 1 |
Flashback Versions Query |
Ретроспективные версии запроса |
|
Week 2 |
Rollback Monitoring |
Мониторинг отката |
|
Week 3 |
Tablespace Management |
Управление табличными пространствами |
|
Week 4 |
Oracle Data Pump |
Утилита Oracle Data Pump |
|
Week 5 |
Flashback Table |
Ретроспективная таблица |
|
Week 6 |
Automatic Workload Repository |
Репозиторий автоматизации нагрузки |
|
Week 7 |
SQL*Plus Rel 10.1 |
Утилита SQL*Plus выпуска 10.1 |
|
Week 8 |
Automatic Storage Management |
Автоматическое управление памятью |
|
Week 9 |
RMAN |
Утилита RMAN |
|
Week 10 |
Auditing |
Аудит |
|
Week 11 |
Wait Interface |
Интерфейс ожидания |
|
Week 12 |
Materialized Views |
Материализованные представления |
|
Week 13 |
Enterprise Manager 10g |
Утилита Enterprise Manager 10g |
|
Week 14 |
Virtual Private Database |
Виртуальная частная база данных |
|
Week 15 |
Automatic Segment Management |
Автоматическое управление сегментами |
|
Week 16 |
Transportable Tablespaces |
Транспортабельные табличные простанства |
|
Week 17 |
Automatic Shared Memory Management |
Автоматическое управление разделяемой памятью |
|
Week 18 |
SQL Advisor and ADDM |
SQL-консультант и ADDM |
|
Week 19 |
Scheduler |
Планировщик |
|
Week 20 |
Best of the Rest |
Лучшее напоследок |
За прошедшие 27 лет Oracle сделал огромные усовершенствования своего основного изделия - базы данных. Сейчас этот продукт - не только всемирно востребованная и надежная база данных, но и часть полной инфраструктуры программного обеспечения вычислений уровня предприятия. Каждый новый релиз демонстрирувет такие головокружительные новые возможности и особенности, что разработчики, IT- менеджеры и даже закаленные АБД иногда приходят в растерянность от того, какие же из новых свойств будут им более всего полезны.
В лице Oracle Database 10g АБД получили в свои руки одну из наиболее глубоких новых систем когда-либо выпускавшихся Oracle. И поэтому АБД, которые потратят какое-то время на понимание правильного применения новых технологий Oracle в их повседневной работе, будут только рады многим новым механизмам, сберегающим время и, разумеется, деньги.
Oracle предлагает много новых инструментов, которые весьма эффективно помогают в работе АБД (и, возможно, более приятных), освобождая время АБД для стратегических, творческих занятий, не говоря уже о ночных сменах и дежурствах по выходным дням. Oracle Database 10g - это действительно то, что нужно большинству АБД.
В течение следующих 20 недель я проведу вас по лабиринтам этого нового мощного релиза, рассказав о 20 наиболее привлекательных, на мой взгляд, особенностях Oracle Database 10g применительно к задачам администратора баз данных. В этом списке есть как элементарные вопросы, например, задание табличного пространства по умолчанию при создании пользователей, так и продвинутые, например, новая возможность Automatic Storage Management (Автоматическое Управление Памятью).
В этих заметках я представлю краткий сфокусированный анализ новых средств и технологий. Основная цель - описать функции и преимущества, которые вы можете получить от использования этих возможностей с тем, чтобы вы применили их в своей работе как можно быстрее.
Я буду рад вашим вопросам, комментариям и впечатлениям об этих заметках. За дело!
Arup Nanda (arup@proligence.com) - менеджер систем баз данных Starwood Hotels and Resorts - работает АБД Oracle уже более 10 лет. В 2003 году журнал “Oracle Magazine” назвал его “Лучшим АБД года”. Arup - постоянный докладчик и автор в связанных с Oracle конференциях и журналах; он является редактором журнала “Select Journal” и членом “New York Oracle User Group Executive Committee”. Он соавтор книги “Oracle Privacy Security Auditing (Rampant TechPress)”.
Неделя 1.
Flashback Versions Query –
это движущееся кино, а не неподвижный снимок
(Get a Movie, Not a Picture: Flashback Versions Query)
Источник: http://otn.oracle.com/pub/articles/10gdba/week1_10gdba.html
Немедленная идентификация всех изменений записи без дополнительной установок
В Oracle 9i мы увидели первое пришествие “машины времени” ("time machine"), представленной в виде Flashback Query, механизма ретроспективных (flashback) запросов. Эта опция позволяет администратору базы данных (АБД) видеть значение столбца в течение определенного времени [в прошлом] столь долго, пока запасенная копия блока (before-image – этот термин был принят в Oracle5. Вот уж не думал, что встречу его через 10 лет, через 5 поколений Oracle – прим.гл.ред. А.Бачина) доступна в undo-сегменте (сегменте отката). Однако механизм Flashback Query обеспечивает только снимок (snapshot) данных на фиксированный момент времени, а не предоставление последовательного изменения данных за определенный отрезок времени. Некоторые же приложения, например, управление оборотом иностранной валюты, могут требовать просмотра изменения данных за весь период времени, а не в двух его точках [начала и конца периода – ред.]. Oracle 10g, благодаря опции Flashback Versions Query (Ретроспективные Версии Запроса), может легко и рационально выполнять эту задачу.
Запрос изменений таблицы.
Для примера рассмотрим банковское приложение управления оборотом иностранной валюты. База данных содержит таблицу RATES для записи курса валют в определенные моменты времени.
SQL> desc rates
Name Null? Type
----------------- -------- ------------
CURRENCY VARCHAR2(4)
RATE NUMBER(15,10)
Эта таблица сохраняет коэффициенты обмена (exchange rate) US$ по отношению к другим валютам, которые перечислены в столбце CURRENCY. В ходе финансовой деятельности коэффициенты обмена валют не только обновляются, но их изменения записываются в хронологической последовательности. Такой подход необходим, так как банковские транзакции могут происходить как бы в прошлом ("past time"), чтобы приспособится к потерям времени при денежных переводах. Например, если транзакция произошла в 10:12 AM, но была задействована, начиная с 9:12АМ, то соответствующий коэффициент будет отнесен к 9:12АМ, а не к текущему моменту времени.
До сих пор единственным видом использования созданной хронологической таблицы коэффициентов было хранение изменений коэффициентов с последующим запросом о наличии таковой истории. Другая опция – собственно запись в RATES начального и конечного значений времени применимости обменного курса. Когда происходит изменение, в существующей строке по значению SYSDATE обновляется столбец END_TIME и вставляется новая строка, у которой END_TIME содержит
NULL.
Однако базе данных Oracle 10g механизм Flashback Versions Query избавляет от необходимости держать хронологическую таблицу и хранить начальные и конечные отметки времени. Теперь же, используя эту возможность, можно получить значение записи в определенное время в прошлом без дополнительной установки.
Для примера представим, что АБД в процессе нормальной работы несколько раз обновляет обменный коэффициент или даже удаляет и вставляет заново его значение:
insert into rates values ('EURO',1.1012);
commit;
update rates set rate = 1.1014;
commit;
update rates set rate = 1.1013;
commit;
delete rates;
commit;
insert into rates values ('EURO',1.1016);
commit;
update rates set rate = 1.1011;
commit;
После этой серии действий АБД выбирает текущее значение столбца RATE:
SQL> select * from rates;
CURR RATE
---- ----------
EURO 1.1011
На выходе запроса показано текущее значение RATE, но не все его значения с момента создания строки. Таким образом, используя Flashback Query, можно получить значение в данный момент времени. Но больший интерес представляет построение аудит-трассы (audit trail) изменений, то есть нечто похожего на [непрерывную] видеозапись изменений, а не серию снимков в точно заданные моменты.
Следующий запрос показывает изменения, сделанные в таблице:
select versions_starttime, versions_endtime, versions_xid,
versions_operation, rate
from rates versions between timestamp minvalue and maxvalue
order by VERSIONS_STARTTIME
/
VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V RATE
---------------------- ---------------------- ---------------- - ----------
01-DEC-03 03.57.12 PM 01-DEC-03 03.57.30 PM 0002002800000C61 I 1.1012
01-DEC-03 03.57.30 PM 01-DEC-03 03.57.39 PM 000A000A00000029 U 1.1014
01-DEC-03 03.57.39 PM 01-DEC-03 03.57.55 PM 000A000B00000029 U 1.1013
01-DEC-03 03.57.55 PM 000A000C00000029 D 1.1013
01-DEC-03 03.58.07 PM 01-DEC-03 03.58.17 PM 000A000D00000029 I 1.1016
01-DEC-03 03.58.17 PM 000A000E00000029 U 1.1011
Обратите внимание, что выше показаны все изменения конкретной строки, даже если эта строка была удалена и вставлена заново. Столбец VERSION_OPERATION показывает, какая операция (Insert/Update/Delete - вставить/обновить/удалить) была применена в строке. Это получено без применения хронологической таблицы или дополнительного столбца.
В описанном выше запросе столбцы versions_starttime, versions_endtime, versions_xid, versions_operation являются псевдо-столбцами, которые подобны всем хорошо известным [псевдо-столбцам] ROWNUM и LEVEL. Другие псевдо-столбцы, такие как VERSIONS_STARTSCN и VERSIONS_ENDSCN, показывают SCN (System Change Number – системный номер изменения) на тот момент времени. Столбец version_xid показывает идентификатор транзакции, которая меняла строку. Подробнее о транзакции можно узнать из представления FLASHBACK_TRANSACTION_QUERY, где столбец XID показывает идентификатор транзакции. Для примера воспользуемся значением 000A000D00000029 из столбца VERSIONS_XID предыдущего примера. Тогда следующее предложение показывает действующее значение UNDO_SQL.
SELECT UNDO_SQL
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = '000A000D00000029';
UNDO_SQL
----------------------------------------------------------------------------
insert into "ANANDA"."RATES"("CURRENCY","RATE") values ('EURO','1.1013');
Дополнительно к предыдущему и в числе другой информации из этого представления можно получить временные отметки и SCN (the timestamp and SCN) начала запроса и фиксации транзакции.
Нахождение изменений в течение периода
Теперь давайте посмотрим, как можно эффективно использовать информацию. Предположим, что надо найти значение RATE в 3:57:54 РМ. Сделаем запрос:
select rate, versions_starttime, versions_endtime
from rates versions
between timestamp
to_date('12/1/2003 15:57:54','mm/dd/yyyy hh24:mi:ss')
and to_date('12/1/2003 16:57:55','mm/dd/yyyy hh24:mi:ss')
/
RATE VERSIONS_STARTTIME VERSIONS_ENDTIME
---------- ---------------------- ----------------------
1.1011
Этот запрос аналогичен другим flashback-запросам. В этом примере начальное и конечное время отсутствует, что указывает на то, что коэффициент не изменялся в течение этого периода времени, точнее, он включает в себя период времени. Вы также можете использовать SCN, чтобы найти любое значение версии в прошлом. Значения SCN могут быть получены из псевдо-столбцов VERSIONS_STARTSCN и VERSIONS_ENDSCN. Например:
select rate, versions_starttime, versions_endtime
from rates versions
between scn 1000 and 1001
/
Используя ключевые слова MINVALUE и MAXVALUE, можно отобразить все изменения из доступных undo-сегментов. Также можно задать конкретную дату или значение SCN в качестве одной из граничных точек диапазона, а другую - как литерал MINVALUE или MAXVALUE. Например, ниже следует запрос, который показывает нам не все изменения, а только начиная с 3:57:52 РМ:
select versions_starttime, versions_endtime, versions_xid,
versions_operation, rate
from rates versions between timestamp
to_date('12/11/2003 15:57:52', 'mm/dd/yyyy hh24:mi:ss')
and maxvalue
order by VERSIONS_STARTTIME
/
VERSIONS_STARTTIME VERSIONS_ENDTIME VERSIONS_XID V RATE
---------------------- ---------------------- ---------------- - ----------
01-DEC-03 03.57.55 PM 000A000C00000029 D 1.1013
01-DEC-03 03.58.07 PM 01-DEC-03 03.58.17 PM 000A000D00000029 I 1.1016
01-DEC-03 03.58.17 PM 000A000E00000029 U 1.1011
Заключение
Flashback Versions Query идеально реплицирует текущие переменные значения, отслеживая изменения таблицы. Это преимущество позволяет получать не конкретное значение в прошлом, а все изменения за период, настолько далекий, насколько доступны данные в undoсегментах. Следовательно, максимум доступных версий зависит от параметра UNDO_RETENTION.
Неделя 2.
До коле же?: Мониторинг отката.
(How Much Longer?: Rollback Monitoring)
Источник: http://otn.oracle.com/pub/articles/10gdba/week2_10gdba.html
Дадим пользователям точную оценку продолжительности операции отката.
Ах, вы еще там? И на как долго?
Знакомо звучит? Эти вопросы вы можете слышать все чаще и чаще по пути в любимый детский развлекательный парк. Хотели бы вы точно ответить, сколько это займет у вас времени, а еще лучше самим узнать ответ?
Аналогично и здесь. Когда откатывается долго работающая транзакция, всегда найдутся несколько пользователей, внимательно следящих за вашей работой и задающих такие же вопросы. Эти вопросы оправданы, потому что транзакция накладывает блокировки, и нормальная обработка часто выглядит как протекание отката.
В базе данных Oracle 9i и далее вы можете задать запрос:
SELECT USED_UREC FROM VSTRANSACTION;
который показывает число undo-записей, используемых текущей транзакцией. И если она
откатывается [прим.ред.: в тексте букв. executed repeatedly – выполняется повторно], то эти значения будут непрерывно уменьшаться, так как процесс отката освобождает undo-записи в ходе своего протекания. Затем можно подсчитать коэффициент, взяв последовательность интервалов, и экстраполировать результат, чтобы приблизительно рассчитать конечное время.
Несмотря на то, что в представлении VSTRASACTION имеется столбец START_TIME, он показывает только начальное время всей транзакции (то есть, до того как случился откат). Следовательно, экстраполяция оказывается в стороне, и вы не имеете возможности узнать, когда в действительности произошел откат [прим.ред.: скорее всего, имеется в виду, когда произошло событие, породившее начало процесса отката].
Расширенная статистика отката транзакции
В Oracle Database 10g эта задача тривиальна. Когда происходит откат транзакции, событие записывают в представление VSSESSION_LONGOPS, которое показывает долго работающие транзакции. По замыслу отката, если процесс занимает больше, чем 6 секунд, запись появляется в представлении. После того, как откат произведен, вы, наверно, скроете экран своего монитора от любопытных глаз и выполните следующий запрос:
select time_remaining
from v$session_longops
where sid = <sid of the session doing the rollback>;
Теперь, когда понятно, насколько важным является представление V$SESSION_LONGOPS, давайте посмотрим, что еще оно в состоянии предложить. Это представление было доступно и до Oracle Database 10g, но информация по откаченной транзакции не сохранялась. Чтобы показать все столбцы в читаемом виде, удобно использовать функцию PRINT_TABLE, описанную Tom Kyte на AskTom.com. Эта процедура отображает столбцы табличным способом, что лучше обычного линейного.
SQL> set serveroutput on size 999999
SQL> exec print_table('select * from v$session_longops where sid = 9')
SID : 9
SERIAL# : 68
OPNAME : Transaction Rollback
TARGET :
TARGET_DESC : xid:0x000e.01c.00000067
SOFAR : 10234
TOTALWORK : 20554
UNITS : Blocks
START_TIME : 07-dec-2003 21:20:07
LAST_UPDATE_TIME : 07-dec-2003 21:21:24
TIME_REMAINING : 77
ELAPSED_SECONDS : 77
CONTEXT : 0
MESSAGE : Transaction Rollback: xid:0x000e.01c.00000067 :
10234 out of 20554 Blocks done
USERNAME : SYS
SQL_ADDRESS : 00000003B719ED08
SQL_HASH_VALUE : 1430203031
SQL_ID : 306w9c5amyanr
QCSID : 0
Давайте более внимательно рассмотрим каждый из этих столбцов. Там может быть больше одной долго работающей операции в сессии, особенно потому что представление содержит архив всех длительно работающих операций предыдущих сессий. Столбец OPNAME демонстрирует, что эта запись является "Transaction Rollback", что направляет нас в правильном направлении. Столбец TIME_REMAINING показывает приблизительный остаток времени в секундах, описанный ранее, а столбец ELAPSED_SECONDS – время, затраченное до настоящего момента.
Итак, каким же образом эта таблица предлагает оценивать остаточное время? Ключ к разгадке может быть найден в столбцах TOTALWORK (общее количество сделанной “работы”) и SOFAR, который показывает, как много сделано к настоящему моменту. Единица работы показана в столбце UNITS. В нашем случае, в блоках. Поэтому видно, что из суммарного числа 20,554 блока до настоящего момента были откачены 10,234 блока. Операция до сих пор занимала 77 секунд. Следовательно, оставшиеся блоки будут откачены за:
77 * ( 10234 / (20554-10234) ) ≈ 77 секунд.
Но вам нет необходимости проделывать такой путь для получения результата, так как он указан точно [прим.ред.: выше был рассмотрен столбец TIME_REMAINING]. И, наконец, столбец LAST_UPDATE_TIME указывает время, до которого содержание представления является текущим, что усиливает интерпретацию результатов.
SQL-предложение
Другой важной частью информации является идентификатор SQL-предложения, для которого был осуществлен откат. Ранее для получения SQL-предложения, для которого был выполнен откат, применялись [столбцы] SQL_ADDRESS и SQL_HASH_VALUE. Новый столбец SQL_ID соответствует SQL_ID из представления V$SQL, как показано далее:
SELECT SQL_TEXT
FROM V$SQL
WHERE SQL_ID = <value of SQL_ID from V$SESSION_LONGOPS>;
Этот запрос возвращает [текст] SQL-предложения, которое было откачено, обеспечивая, таким образом, дополнительную проверку по адресу и хэш-функции SQL-предложения.
Параллельное восстановление экземпляра
Если DML-операция была параллельной, то столбец QCSID показывает SID сеансов сервера параллельных запросов. В случае параллельного отката, такого как во время восстановления текущего и результирующего экземпляра неудавшейся транзакции, эта информация часто бывает полезна.
Например, предположим, что во время обновления экземпляр завершился ненормально. Когда экземпляр поднимается снова, сбойная транзакция откатывается. Если задан параметр инициализации, разрешающий параллельное восстановление, то и откат выполняется параллельно, а не последовательно, как при обычном откате транзакции. Следующей задачей является приблизительный подсчет общего времени процесса отката.
Представление V$FAST_START_TRANSACTIONS показывает все транзакции, для которых откат совершился со сбоем. Похожее представление V$FAST_START_SERVERS показывает число серверов параллельных запросов, задействованных в откате. Эти два представления были доступны в предыдущих версиях, но новый столбец XID, который показывает идентификатор транзакции, делает соединения проще. В Oracle 9i и ранее вы должны были объединять представления по трем столбцам (USN – номер undo-сегмента, SLT – номер слота (Slot Number) undo- сегмента, SEQ – порядковый номер). Родительские установки показаны в [столбцах] PARENTUSN, PARENTSLT и PARENTSEQ. В Oracle Database 10g же нужно только соединить [указанные выше представления] по столбцу XID, а родительский XID индицируется по интуитивному имени: PXID.
Наиболее используемой является информация из столбца RCVSERVERS представления V$FAST_START_TRANSACTIONS. Если задействован процесс параллельного отката, то число серверов параллельных запросов показано в этом столбце. Вы можете проверить его, чтобы узнать, сколько стартовало параллельных запросов:
select rcvservers from v$fast_start_transactions;
Если на выходе показана только 1, то транзакция будет откачена обычно, с помощью SMON процесса – явно неэффективного способа, чтобы это сделать. Можно параметру инициализации RECOVERY_PARALLELISM присвоить другое значения, нежели 0 или 1, и перезапустить экземпляр для возможности параллельного отката. Вы можете выполнить:
ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK = HIGH
для создания в 4 раза превышающих число процессоров машины (as much as 4 times the number of CPUs) параллельных серверов.
Если на выходе предыдущего запроса не 1, то параллельный откат имеет место. Вы можете запросить то же самое представление (V$FAST_START_TRANSACTIONS), чтобы получить родительскую и дочернюю транзакции (идентификатор родительской транзакции – PXID, дочерней - XID). XID может быть использован для соединения этого представления с V$FAST_START_SERVERS, чтобы получить дополнительную информацию.
Вывод
В заключение, если долго работающая транзакция откатывается в Oracle 10g, будь это сеанс параллельного восстановления экземпляра или пользовательский оператор отката, все что нужно сделать - это посмотреть в представление V$SESSION_LONGOPS и оценить в секундах, как долго займет действо.
А теперь, если это помогло предсказать вам момент время завершения, в парк развлечений!
| 
